Моделювання SOA: Частина 5. Реалізація сервісу, Різне, Програмування, статті

У чотирьох попередніх статтях серії (див. врізку “Інші статті серії” угорі ліворуч) ми використовували бізнес-аналіз для ідентифікації значущих для бізнесу сервісів (“Моделювання SOA. Частина 1. Ідентифікація сервісу “), необхідних для вирішення бізнес-завдань та досягнення бізнес-цілей. Потім ми створили специфікації сервісів і використовували протоколи (” Моделювання SOA. Частина 2. Створення специфікації сервісу “), необхідні для вирішення ІТ-задач. Потім ми створили проектні моделі надання та використання сервісів (“Моделювання SOA. Частина 3. Реалізація сервісу,” “Моделювання SOA. Частина 4. Компонування сервісу”). В результаті ми отримали технологічно-нейтральну, але закінчену модель архітектурно змодельованого рішення сервісу. В даній, заключної, статті серії ми поговоримо про практичне створення реалізації, узгодженої з архітектурними та проектними рішеннями, документованими в моделі сервісу. Ми згенеруємо реалізацію для конкретної платформи, скориставшись принципом керованої моделями розробки і функцією перетворення UML-SOA з програмного пакета IBM Rational Software Architect для створення Web-сервісу з SOA-моделі.

Контекст даної статті


У попередніх статтях ми створили закінчену модель SOA-рішення, що задовольняє бізнес-вимогам. Отже, нам відомо, яким вимогам задовольняє архітектура рішення і що необхідно буде змінити, якщо ці вимоги зміняться.


Щоб здійснити розгортання і запустити Web-сервіс, необхідно створити практичну реалізацію, яка узгоджується з архітектурними та проектними рішеннями, документованими в моделі. Ми моли б створити таке рішення вручну, скориставшись як направляючої схеми моделлю рішення. Але щоб забезпечити коректну реалізацію архітектурного рішення, потрібно було б багато часу і висока кваліфікація розробника; при цьому робота була б стомлюючої і ми навряд чи змогли б уникнути помилок. Безумовно, створити рішення вручну можна, і модель була б дуже корисна в якості направляючої схеми рішення. Але наявність закінченої, формальної, верифікованої моделі дає нам можливість використовувати принцип керованої моделями розробки (model-driven development, MDD), щоб створити один або більше скелетів рішення з моделі, а потім закінчити рішення, написавши деталізований код в переносних специфічною середовищі програмування. Саме про це ми поговоримо в даній статті. Ми скористаємося функцією перетворення UML-SOA з програмного пакета IBM ® Rational ® Software Architect для створення рішення Web-сервісу, яке можна буде безпосередньо використовувати в IBM ® WebSphere ® Integration Developer для реалізації, тестування і розгортання готового рішення.


Як і в інших статтях серії, ми будемо використовувати інструменти IBM Rational і IBM WebSphere для створення артефактів рішення і прив’язки їх один до одного, щоб можна було перевірити відповідність рішення вимогам і більш ефективно управляти змінами. У таблиці 1 перераховані всі процеси, які ми будемо використовувати при розробці прикладу, а також інструменти, які будуть використовуватися для створення артефактів.


Таблиця 1. Ролі, завдання та інструменти процесу розробки






















Роль Завдання Інструменти
Бізнес-виконавець Формулювання бізнес-завдань і цілей IBM® Rational® RequisitePro®
Бізнес-аналітик Аналіз бізнес-вимог IBM® WebSphere® Business Modeler
Розробник архітектури програмного забезпечення Розробка архітектури рішення IBM Rational Software Architect
Розробник Web-сервісів Реалізація рішення IBM ® Rational ® Application Developer і IBM WebSphere Integration Developer

Давайте почнемо з перегляду сервісів та учасників сервісів, створених у попередніх статтях.


Перегляд специфікації сервісів, вимог та аналіз використання.


На малюнку 1 показані специфікації сервісів, які були ідентифіковані як необхідні для виконання бізнес-вимог. Це ті сервіси, які можуть виконувати ролі в контракті про бізнес-вимогах до сервісу.


Рисунок 1. Топологія сервісу
Service topology


На малюнку 2 показана модель даних сервісу. Це модель інформації, якою обмінюються споживачі і постачальники сервісу; вона використовується для визначення параметрів операцій сервісу.


Рисунок 2. Модель даних сервісу
Service data model


Сервіс планування Scheduling


На малюнку 3 показана закінчена специфікація сервісу Scheduling.


Рисунок 3. Специфікація сервісу планування Scheduling
The Scheduling service specification


Ця специфікація сервісу являє собою простий інтерфейс, тому що в ній немає жодного цікавить нас протоколу, необхідного для використання сервісів планування. На малюнку 4 зображено схема постачальника, який надає сервіс Scheduling.


Рисунок 4. Постачальник сервісу Productions
The Productions service provider


Практичні реалізації поводжень requestProductionScheduling і sendShippingSchedule (відповідно, діяльності та непрозорого поведінки) докладно не показані на діаграмі, але в моделі вони визначені.


Сервіс доставки Shipping


На малюнку 5 показана специфікація сервісу доставки ShippingService.


Рисунок 5. Специфікація сервісу ShippingService
ShippingService service specification


Специфікація цього сервісу трохи складніше, тому що вона моделює взаємодію між оператором доставки і оператором замовлень у формі простого взаємодії в стилі зворотного виклику. На малюнку 6 зображена схема постачальника, який надає сервіс ShippingService.


Малюнок 6. Постачальник сервісу Shipper
The Shipper service provider


Непрозоре поведінка requestShipping, що є методом для надається операції requestShipping, викликає processSchedule на порту доставки в певній точці даної реалізації. Споживачі, що підключаються до цього порту, повинні надати реалізацію даної операції, яка могла б дати відповідь на запит.


Сервіс Invoicing


На малюнку 7 показана специфікація сервісу InvoicingService.


Малюнок 7. Специфікація сервісу InvoicingService.
The InvoicingService service specification


Даний протокол також є трохи більш складним. Він задає певний порядок використання функціональних можливостей сервісу. Передбачається, що споживач і постачальник будуть слідувати цим протоколом. В даному випадку одна з діяльностей використовується для визначення протоколу сервісу.


На малюнку 8 показана схема постачальника сервісу, що надає сервіс InvoicingService і методи, що мають функціональні можливості сервісу.


Рисунок 8. Реалізації сервісу Invoicer
Invoicer service implementations


Сервіс Purchasing


І нарешті, на малюнку 9 показана специфікація сервісу придбання Purchasing:


Малюнок 9. Специфікація сервісу придбання Purchasing.
The Purchasing service specification


Інтерфейс цього сервісу є функціональну можливість, визначену у вихідному бізнес-процесі “Обробка замовлень на придбання”. Він також представляє сервіс, ідентифікований і розроблений на основі даного бізнес-процесу.


На малюнку 10 показана схема постачальника сервісу, що надає сервіс Purchasing, а також сервіси, які він запитує для забезпечення своєї функціональності.


Малюнок 10. Постачальник сервісу OrderProcessor.
The OrderProcessor service provider


На малюнку 11 показаний метод для операції сервісу processPurchaseOrder, що використовує UML-діяльність.


Малюнок 11. Реалізація операції сервісу processPurchaseOrder
The processPurchaseOrder service operation implementation


Дана діаграма дуже схожа на діаграму IBM WebSphere Business Modeler для цього ж поведінки. У даному процесі операції сервісу InvoiceProcessing і ScheduleProcessing реалізуються через операції реєстрації подій Accept Event processInvoice і processSchedule. Зверніть увагу на те, що відповідні операції в інтерфейсах позначені як операції <<trigger>>, Це відображає їх здатність відповідати на дії AcceptCallActions (аналогічно приймання і AcceptEventActions, де тригером є подія SignalEvent). Ключове слово << trigger >> не підтримується уніфікованим мовою моделювання версії 2.0 (Unified Modeling Language 2, UML 2); воно використовується тільки для того, щоб зробити зрозумілішою реалізацію операцій. Зверніть увагу на те, що ці операції не будуть прийняті до тих пір, поки виконується діяльність processPurchaseOrder і поки потік управління не виконає дві операції Accept Call. Це говорить про те, що дана реалізація операції здатна визначити отримання відповідей на інші операції.


Передові методи моделювання сервісів


Моделювання з використанням UML 2 сприяє кращому розумінню систем, що лежать в основі реалізації, що дозволить нам абстрагуватися від сторонніх деталей. Моделювання ні в якому разі не є панацеєю, а для створення і розуміння якісних діаграм моделей як і раніше необхідні спеціальні знання. Це природний наслідок необхідності підтримувати досить загальну модель обчислювального середовища, яку можна використовувати в широкому діапазоні прикладних предметних областей і рівнів абстракції; крім цього моделювання являє семантичні схеми декількох переносних специфічних моделей виконання. Крім того, можливо, доведеться обмежити типи операцій або стилів у моделюванні діяльностей, щоб забезпечити ефективне перетворення таких моделей в цільову платформу виконання.


У нашому випадку цільової платформою є технологія Web-сервісів і модель програмування IBM SOA, підтримувана середовищем WebSphere Integration Developer. Вона включає бізнес-об’єкти (XSD), інтерфейси (WSDL), збірки модулів (SCDL, попередник SCA від IBM), процеси (BPEL), SCDL (бізнес-форми кінцевих автоматів) і Java ™ компоненти. Щоб забезпечити підтримку перетворень UML-моделей для конкретної платформи Web-сервісів, нам доведеться використовувати деякі передові методи моделювання сервісів. Тобто спочатку нам потрібно налаштувати UML для моделювання архітектури SOA-рішення, а потім доведеться використовувати певний стиль моделювання, щоб нашу модель можна було транслювати в Web-сервіси.


Зазвичай настройка UML здійснюється за допомогою профілів. Профіль визначає кілька стереотипних класів, здатних доповнити один або більше метакласи UML додатковими властивостями або асоціаціями. Щоб ці доповнення стали доступними, ми застосовуємо профілі до UML-моделі. Як правило, ці профілі в керованої моделями архітектурі використовуються з двома цілями:




У деяких ситуаціях ці дві мети поєднуються. Наприклад, розширення для підтримки моделювання реляційних даних для UML складається з одного профілю, який одночасно доповнює UML засобами моделювання даних ERA (реляційні атрибути сутності) і надає розмітку, необхідну для перекладу моделей предметних областей UML в логічні моделі даних IBM ® Rational ® Data Architect (моделі LDM). Профіль IBM Software Services надає цю здвоєну роль для моделей, які перетворюються в Web-сервіси.


В інших випадках один профіль може використовуватися для підтримки моделювання, а інший – для підтримки перетворення. Для прикладу розглянемо випадок моделювання SOA-рішень, які передбачається реалізувати в середовищі Java ™ 2 Platform, Enterprise Edition (J2EE). Останню задачу можна виконати, застосувавши профіль Software Services і профіль перетворення Enterprise Java ™ Beans (EJB) до однієї і тієї ж моделі. Стереотипи профілю Software Services будуть застосовані до елементів моделі для підтримки моделювання сервісів, тоді як стереотипи профілю перетворення EJB будуть застосовані до елементів моделі – Для проведення перетворення UML-EJB програмного пакета Rational Software Architect в процесі генерації коду реалізації. Безумовно, цю ж SOA-модель можна перетворити в Web-сервіси за допомогою інструменту перетворення UML-SOA з пакета Rational Software Architect. Перетворення UML-SOA згенерує Web-сервіси, відключивши розмітку профілю Software Service. Це інструмент проігнорує розмітку для перетворення EJB.


У наступному розділі описуються деякі передові методи для SOA-моделей, які передбачається транслювати в Web-сервіси, а саме в Web-сервіси, реалізовані в моделі програмування IBM ® SOA і підтримувані інструментом WebSphere Integration Developer.


Моделювання даних


Параметри операції сервісу повинні мати або один з примітивних типів, або тип даних <<message>>. Розробники моделей не повинні робити жодних припущень про розміщення даних, семантиці call-by-value (виклик за значенням) або call-by-reference (виклик за посиланням), або про які-небудь неявних функціях управління паралелізмом. Припустимо, що наша реалізація сервісу працює з недокументальной копією даних, які можна передавати і / або перетворювати з вихідного джерела цих даних. Цим досягається мінімальна зв’язаність між користувачами і постачальниками сервісу.


Моделювання сервісів


За визначенням профілю IBM Software Services, компонент постачальника сервісів повинен реалізувати або використовувати інтерфейси не безпосередньо, а через порти сервісу. Завдяки цьому забезпечується оптимальна роз’єднаність між споживачами і постачальниками сервісу, підключеними до цього компоненту.


Моделювання діяльностей


Реальний постачальник сервісу моделює методи своїх операцій сервісу за допомогою вказівки поведінки для кожної операції.


Примітка
Реальний постачальник сервісу – це компонент, який не можна віднести ні до абстрактних компонентів, ні до компонентів <<specification>> .


Допускається використання будь-якої поведінки, але якщо цільової платформою моделі є платформа Web-сервісів, зручніше використовувати діяльність, яка легко може бути транслювала в BPEL WebSphere. Модель діяльності, показана на малюнку 11, є власною поведінкою компонента постачальника сервісу Order Processor, який є методом для операції processPurchaseOrder. Щодо такої діяльності необхідно пояснити деякі моменти:












Ці угоди використовуються для того, щоб спростити моделювання діяльностей та діаграми діяльностей і краще зіставити їх з кодом BPEL, який буде згенеровано на їх основі.


Перетворення в Web-сервіси


Перетворення вимагають використання конфігураційних файлів.


Налаштування конфігурації перетворень


Для настройки перетворення необхідно вибрати з меню команди File > New > Other > Transform Configuration (Рисунок 12).


Малюнок 12. Створення конфігурації перетворення
Creating a new transformation configuration


Для цього прикладу ми скористаємося перетворенням UML-SOA, як показано на малюнку 13.


Малюнок 13. Вибір перетворення UML-SOA
Selecting the UML-to-SOA transformation


Налаштування конфігурації більшості перетворень складається з трьох основних етапів:



  1. Вибору вихідних елементів перетворення;
  2. Вибору (або створення, а потім уже вибору) цільових елементів;
  3. Налаштування властивостей перетворення.

Допустимі вихідні елементи визначаються конкретним перетворенням, яке ви обрали. Як правило, рекомендується виконувати перетворення всієї моделі, а не її окремих частин. Цим гарантується, що моделі, що представляють собою окремі версії ресурсів, будуть вважатися одиницями компіляції по відношенню до перетворення моделі. Така ситуація спрощує управління моделями та обробку залежностей перетворенням завдяки забезпеченню відповідності змін в ресурсах в робочій області змін постановника і перетворення, які необхідно обробити для того, щоб гарантувати синхронізацію видобутих артефактів з відповідними вихідними елементами. Наприклад, не рекомендується вибрати окремий метод в Java-класі і скомпілювати тільки цей метод, а потім вставити його в байт коди для решти класу. Було б неможливо управляти таким процесом у швидко мінливому середовищі, і це вимагало б, щоб ви, а не компонувальники і компілятори, були інформовані про всі взаимозависимостях, компіляцію яких необхідно виконати після того, як відбулися зміни.


У даному прикладі модель “Обробка замовлень на придбання” є джерелом, а ми створюємо новий простий проект Eclipse в якості цільового об’єкта. В цьому проекті ми розмістимо всі елементи моделі (рисунок 14).


Малюнок 14. Налаштування конфігурації джерела і мети перетворення
Configuring the transformation sources and targets


Параметри конфігурації перетворення являють собою настройки перетворення, які зазвичай не підходять для розмітки в моделі. Вони, як правило, управляють загальними настройками, а не настройками, які застосовуються до окремих елементів моделі. Перетворення UML-SOA має всього кілька налаштувань, показаних на малюнку 15.


Малюнок 15. Налаштування конфігурації властивостей перетворення
Configuring the transformation properties


Якщо встановити для властивості “Process UML elements without stereotypes” значення True, то це буде означати, що використання профілю IBM Software Services фактично буде необов’язковим. Типи даних, компоненти та діяльності будуть перетворені у вирішення Web-сервісу, не вимагаючи застосування стереотипів <<message>>, <<service>> або <<serviceProvider>> ; Можливо, що ці стереотипи не будуть застосовані до конкретних елементів моделі, яким не потрібні їхні додаткові властивості.


На цьому конфігурація перетворення моделі PurchaseOrderProcess у вирішення Web-сервісу, який буде розміщено в проекті PurchaseOrderProcessWorkspace, закінчена.


Запуск перетворення


Виконання перетворення PurchaseOrderProcess2WebServices не відрізняється складністю:



  1. Виберіть конфігураційний файл перетворення PurchaseOrderProcess2WebServices.tc, Створений у попередньому розділі;
  2. У спадному меню виберіть команди Transform > UML-to-SOA.

Вибране перетворення виконується із заданими налаштуваннями конфігурації, при цьому початкова модель перетвориться в артефакти Web-сервісів, а результати перетворення розміщуються в проекті PurchaseOrderProcessWorkspace.


Порада:
Якщо в модель будуть внесені зміни, то вам буде потрібно виконати це перетворення ще раз.


Результати перетворення показані на малюнку 16 в поданні Modeling оглядача проектів Project Explorer.


Малюнок 16. Результати перетворення
Transformation results


Перевірка результатів


При настройці конфігурації перетворення UML-SOA необхідно вказати цільової проект, в якому будуть розміщені всі одержувані артефакти. Цей проект являє собою простий проект Eclipse, який містить або проекти бібліотек WebSphere Integration Developer, або проекти модулів, як говорилося в попередньому розділі.



Ці проекти можна імпортувати в робочу область WebSphere Integration Developer. Можна також в якості робочої області використовувати цільової проект, що складається з усіх проектів, згенерованих з набору перетворень UML-SOA пов’язаних SOA-моделей.



  1. Просто запустіть інструмент WebSphere Integration Developer і виберіть цільову папку в якості робочої області;
  2. Потім імпортуйте всі проекти з цієї папки в обрану робочу область.

Порада:
Можливо, буде корисно відключити функцію автоматичної компонування Automatic Build до тих пір, поки не будуть імпортовані всі проекти, це дозволить прискорити імпорт.


Модель і бібліотеки


Кожна модель у вибраному при налаштуванні конфігурації джерелі транслюється в бібліотеку WebSphere Integration Developer з ім’ям, що збігається з ім’ям моделі. Ця бібліотека містить XSD-елементи для кожного класу і типу даних вихідної моделі, а також визначення WSDL для кожного UML-інтерфейсу. Бібліотеки визначають бізнес-об’єкти та інтерфейси, які використовуються усіма модулями WebSphere, згенерували з компонентів обраного в настройках перетворення джерела.


На малюнку 17 показані імпортовані згенеровані проекти бібліотек і модулів в середовищі WebSphere Integration Developer; бібліотека PurchaseOrderProcess розгорнута, щоб в панелі відображалися бізнес-об’єкти і інтерфейси. Зверніть увагу на те, що папки і простір імен в WebSphere прямо відповідають структурі пакета в UML-моделі сервісу. Завдяки цьому досягається узгоджене управління простором імен та підтримка багаторазового використання у всіх ресурсах і інструментах.


Малюнок 17. Бібліотека ProcessPurchaseOrder, її бізнес-об’єкти і інтерфейси
The ProcessPurchaseOrder library and its business objects and interfaces


Давайте уважніше розглянемо бізнес-об’єкти та інтерфейси і порівняємо їх з вихідними UML-елементами. На малюнку 18 за допомогою редактора WebSphere Integration Developer Business Object editor з відкритим бізнес-об’єктом PurchaseOrder показані XSD-елементи, згенеровані з показаної на малюнку 2 моделі даних сервісу. Як ми бачимо, XSD-елементи точно відповідають їх вихідним типам даних <<message>>. Натисніть і відпустіть ліву кнопку миші на малюнку, щоб переглянути згенерований джерело.


Малюнок 18. XSD-елементи, згенеровані з моделі даних сервісу
The XSDs generated from the service data model


Кожен UML-інтерфейс перетвориться в portType WSDL. Код WSDL, згенерований для інтерфейсу Invoicing на малюнку 7, Показаний на малюнку 19. Натисніть і відпустіть ліву кнопку миші на цьому малюнку, щоб переглянути згенерований вихідний код WSDL. І в цьому випадку код WSDL дуже схожий на UML-інтерфейс.


Малюнок 19. Згенерований для інтерфейсу Invoicing код WSDL
WSDL generated for the Invoicing interface


Складання компонентів і модулів


Кожен постачальник сервісів в UML-моделі сервісів перетворюється в модуль WebSphere Integration Developer. До теперішнього часу не існує стандарту на збірку постачальників і користувачів (споживачів) сервісів. Отже, WebSphere Integration Developer версії 6.0.2 використовує фірмову ранню версію компонентної архітектури сервісів, Service Component Architecture (SCA). Складання модулів є документовані файли компонентів, в яких використовується мова опису компонентів сервісів Service Component Description Language (SCDL), мова XML-документів для SCA. Кілька компаній об’єднали свої зусилля для розробки стандарту SCA шляхом спільної роботи цих компаній. Див додаткову інформацію на Web-сайті Open SOA.


Перетворення UML-SOA створює модулі WebSphere Integration Developer для кожного компонента постачальника сервісів, щоб максимізувати багаторазове використання цих компонентів. Модулі SCA неможливо зібрати з інших модулів. Однак вони можуть імпортувати сервіси з інших модулів і використовувати їх опосередковано. Отже, з’єднання між постачальниками і споживачами сервісів в UML реалізуються як прив’язки між елементами імпорту та експорту модуля в WebSphere Integration Developer. Для прикладу розглянемо постачальник сервісу Invoicer, зображений на малюнку 8.


На малюнку 20 показана схема відповідної збірки модуля WebSphere Integration Developer. Для кожного порту сервісу створені елементи імпорту та експорту модуля. SCA не може забезпечити підтримку наданих і запитуваних інтерфейсів для однієї і тієї ж точки взаємодії, отже, для портів сервісу, які надають і запитують інтерфейси, будуть створені окремі елементи експорту та імпорту. Сервіс invoicingExport експортує надається інтерфейс Invoicing, тоді як invoicingImport імпортує запитуваний інтерфейс InvoiceProcessing на порту сервісу Invoicing постачальника сервісу Invoicer.


Малюнок 20. Збірка модуля Invoicer
Invoicer module assembly


Зверніть увагу на ім’я модуля. Модуль являє собою проект Eclipse, але оскільки модель є елементом багаторазового використання, вона повинна дозволяти колізії імен, як будь-який інший елемент багаторазового використання. За угодою, яке використовується перетворенням UML-SOA, створювані модулі отримують імена на основі повної уточненого імені компонента постачальника сервісів, за визначенням пакета, до якого він входить. Внаслідок цього імена виходять дуже довгими, що може викликати проблеми з виконанням на платформі Windows через обмеження на довжину URL. Довгі імена модулів можна легко перетворити в більш короткі імена, оскільки конфлікти імен коректно вирішуються в контексті багаторазового використання.


З компонента Productions ми отримали ще одну збірку модуля, яка зображена на малюнку 21. Цей модуль не має елемента імпорту, оскільки даний порт сервісу не запитує ні одного інтерфейсу.


Малюнок 21. Збірка модуля Production
Productions module assembly


Обидва цих модуля використовують процеси BPEL для практичної реалізації сервісів, що надаються відповідними їм компонентами постачальників сервісів. Про те, як це відбувається, докладно розповідається в наступному розділі.


На малюнку 22 зображено збірка модуля, створеного для компонента OrderProcessor раніше, на малюнку 10.


Малюнок 22. Збірка модуля OrderProcessor
OrderProcessor module assembly


Постачальник сервісів OrderProcessor надає сервіс Purchasing і має вимоги для сервісів Invoicing, Sheduling і Shipping. Канали сервісу, які пов’язують компоненти постачальників і споживачів на малюнку 10, реалізуються як елементи імпорту в модулі OrderProcessor, прив’язані до елементів експорту відповідних постачальників сервісів. Це робить можливим ефективне багаторазове використання модулів в WebSphere Integration Developer і зберігає UML-моделі сервісів незалежно від еволюції SCA. Коли SCA буде стандартизована, то в UML-моделі сервісів не доведеться вносити зміни; достатньо буде оновити перетворення.


UML-діяльності і BPEL-процеси


Кожна функціональна можливість (операція), що надається постачальником сервісу, повинна бути якимось чином реалізована. Реалізації розробляються в UML з використанням або поведінки методу для кожної операції, або дії Accept Call в будь-якому іншому поведінці. Останній метод забезпечує додаткове поділ користувачів і постачальників, дозволяючи постачальнику визначати момент, в який він хоче і може відповісти на запит, а не змушуючи його відповідати негайно, як тільки операція буде викликана користувачем сервісу.


SCA в WebSphere Integration Developer використовує інший підхід. Кожен елемент експорту повинен бути пов’язаний з яким-небудь компонентом в збірці, що надає реалізацію для операцій в даному інтерфейсі. Кожен компонент в SCA має свій тип реалізації:



Постачальник сервісів OrderProcessor, зображений на малюнках 10 і 22, Надає одну функціональну можливість для обробки замовлень на придбання через свій сервіс Purchasing. Реалізацією цієї операції в UML-моделі була діяльність. Перетворення UML-SOA створює з цієї діяльності процес BPEL, а потім використовує його як реалізації експортованої операції.


Малюнок 23. Реалізація компоненту процесу OrderProcessor
OrderProcessor process component implementation


Зверніть увагу на те, що діаграма процесу BPEL на малюнку 23 дуже схожа на діаграму діяльності, показану на малюнку 11. Детальну інформацію про перетворення UML-діяльності в BPEL-процес можна знайти в розділі Help програмного пакета Rational Software Architect.


Відділення інтерфейсу від реалізації


Як уже говорилося раніше, WebSphere Integration Developer SCA реалізує надані функціональні можливості за допомогою підключення елементів експорту, які надають інтерфейси компоненту, реалізує надані операції. Оскільки компонент характеризується типом реалізації, всі операції, які надаються всіма інтерфейсами даного елемента експорту, повинні бути реалізовані одним і тим же способом. Це пов’язує тип реалізації з усіма інтерфейсами елемента експорту. (Елемент експорту може бути підключений і реалізований тільки одним компонентом.) Якщо розробник бажає змінити тип реалізації конкретної операції (наприклад, з завдання, що виконується людиною (“human task”), на автоматизований сервіс, реалізований на Java), то вихідний код всіх інтерфейсів необхідно буде перебудувати, щоб інші елементи експорту можна було підключити до компонентів інших типів реалізації. Це, в свою чергу, вимагатиме зміни всіх користувачів таких інтерфейсів. Така зв’язаність проекту інтерфейсу з типом реалізації може перешкоджати динамічності бізнесу, для підтримки якої і планувалася розробка SOA-рішення.


UML не має такої пов’язаності специфікації і реалізації. Кожна надається операція в UML може мати поведінка методу, що є діяльністю, взаємодією, кінцевим автоматом або непрозорим поведінкою (кодом). Розробник моделі проектує реалізацію кожної операції незалежно. Це може привести до ситуації (див. рисунок 4), В якій один і той же компонент постачальника сервісів використовує різні типи поведінки для різних операцій, що надаються через один і той же інтерфейс. Нам потрібен який-небудь спосіб для трансляції постачальників сервісу в Web-сервіси.


При цьому необхідно враховувати ще один фактор. В UML створюються екземпляри компонентів, а не поводжень, якими вони володіють. Отже, ідентифікатор і життєвий цикл примірника однакові для всіх поводжень одного компонента. Крім того, компонент встановлює контекст галузі діяльності для всіх поводжень, якими він володіє, тим самим дозволяючи цим поведінки спільно використовувати доступ до інформації про стан компонентів (властивостям і портам). Отже, здійснюючи трансляцію в Web-сервіси, ми повинні мати елемент, який буде керувати ідентифікатором, життєвим циклом і загальним станом, інакше ми не зможемо реалізувати семантичні схеми UML. Саме тут нам допоможе мова виконання бізнес-процесів Business Process Execution Language (BPEL) (див. додаткову інформацію про BPEL в розділі Ресурси).


Замість того, щоб створювати окремий компонент SCA, який реалізує кожне поведінку постачальника сервісів в збірці модуля, ми створимо один процес BPEL, який буде відповідати самому компоненту. Зверніть увагу на те, що ім’я процесу BPEL на малюнку 23OrderProcessor, Тобто таке ж, як у постачальника сервісу OrderProcessor, а не processPurchaseOrder, Як у наданої операції.


Давайте уважно розглянемо рисунок 4, Щоб зрозуміти, яким чином компонент Productions транслюється в Web-сервіси WebSphere Integration Developer. Зверніть увагу, що проект реалізації для requestProductionScheduling використовує діяльність (Activity) (деталі реалізації не показані), а sendShippingSchedule використовує непрозоре поведінка (OpaqueBehavior) з реалізацією, представленої у вигляді Java-коду. Збірка модуля для цього постачальника сервісу показана на малюнку 21, А компонент Productions Process – на малюнку 24.


Малюнок 24. Реалізація постачальника сервісу Productions
The Productions service provider implementation


Для компонента постачальника сервісів Productions створюється процес BPEL. Властивість identity постачальника сервісів використовується для визначення кореляції для всіх діяльностей Invoke, Receive і Reply в цьому процесі. Кожна надається компонентом операція реалізується небудь фрагментом цього процесу. Спочатку процес вибирає елемент, який буде використовуватися для передачі кожного запиту операції. Потім для кожної операції створюється область дії, щоб надати місце для змінних, що визначаються в UML-поведінці. Згодом область дії буде містити результат трансляції поведінки. Якщо поведінка було діяльністю UML, то область дії буде містити код BPEL, згенерована з цієї діяльності. Якщо поведінка мало тип “непрозоре поведінка” (OpaqueBehavior) мовою Java, то тіло поведінки копіюється в фрагменти діяльності на Java в області дії. Якщо поведінка мало тип “невизначений поведінка” (OpaqueBehavior) мовою HTML або Java ™ Server Pages (JSP), то в область дії додається діяльність Human Task.


Завдяки цьому досягається поділ інтерфейсів і їх реалізацій. Наприклад, якщо розробник моделі вирішить змінити реалізацію операції сервісу з “human task” на автоматизований Java-сервіс, то потрібно буде змінити тільки елемент “human task” в області дії цієї операції. Клієнти не дізнаються про зміну реалізації до тих пір, поки не помітять, що сервіс функціонує швидше і їм не потрібно робити стільки роботи, як раніше.


Загалом, зрозуміло, що мова йде про щось складне і заплутаному; але ситуація, швидше за все, зміниться після стандартизації SCA. Однак роз’єднання, поділ інтересів, багаторазове використання і динамічність рішень є основними характеристиками SOA, хоча отримати їх не завжди просто.


Завершення роботи над вирішенням


Інструмент перетворення UML-SOA не генерує закінченого рішення (поки що). Причина полягає в тому, що робота по вставці деталей реалізації в моделі була б складніше, ніж дії з розміщення їх в платформенно-специфічних артефактах за допомогою редакторів, призначених для цієї мети. Крім того, в діяльностях UML 2 є ряд функцій, які поки неможливо транслювати в BPEL. Вони будуть додані в майбутніх версіях. Детальна інформація про те, які функції підтримуються конкретними версіями, доступна в розділі Help програмного пакета Rational Software Architect.


Зазвичай WebSphere Integration Developer доводиться виконувати деякі або всі з наступних діяльностей процесу розробки.



  1. Додавання Java-коду для непрозорого поведінки, якщо цей код не був наданий в моделі. Навіть в тому випадку, якщо Java-код є в тілі непрозорого поведінки, в ньому можуть бути помилки, оскільки Content Assist і компіляція Java не інтегровані (Поки що) з функціями моделювання в Rational Software Architect;
  2. Додавання кореляцій для бізнес-процесів. Кореляція визначає інформацію, необхідну для ідентифікації екземплярів компонента, вона до цих пір не підтримується інструментом перетворення UML-SOA. Введення підтримки кореляції планується в однієї з наступних версій;
  3. Створення інтерфейсу користувача (UI) для завдань, що виконуються оператором-людиною (human task). Розробник UML-моделі може включити код JSP або HTML в тіло непрозорого поведінки. Але як і Java-код, цей код може бути неповним або містити помилки. Щоб закінчити створення користувальницького інтерфейсу (UI) додатки, розробнику інтеграції потрібно буде використовувати редактор Human Task editor, редактор сторінок Page Designer, портал або інші інструменти для створення закінчених “human tasks”, які будуть зручними в застосуванні і відрізнятися хорошим дизайном;
  4. Налаштування конфігурації моделі моніторингу. На даний момент інструмент перетворення UML-SOA не може надати жодної інформації для моніторингу, що дозволяє оцінити ключові показники ефективності (KPI), але їх можна змоделювати як обмеження для сервісів і постачальників сервісів. Розробник інтеграції може використовувати інструмент Monitor Model Editor в WebSphere Integration Developer для того, щоб вибрати, які дані потрібно збирати для оновлень імітацій, а також в якості бізнес-показників і параметрів.

Зведене резюме серії статей


На цьому ми закінчуємо серію статей, присвячену моделювання сервісів в Rational Software Architect з використанням профілю IBM Software Services (див. врізку Інші статті серії угорі ліворуч). У першій статті, “Моделювання SOA. Частина 1. Ідентифікація сервісу”, Розповідалося про те, як використовувати моделі бізнес-процесів і кооперації сервісів для того, щоб визначити контракт про вимоги, що описує, як необхідно узгодити і оркеструвати набір сервісів для вирішення деяких задач. Контракти сервісів часто використовуються для того, щоб визначити, що необхідно виконати для досягнення бізнес-цілей. Далі, при ідентифікації сервісів, які представляють собою реальні бізнес-цінності, можуть виявитися корисними кооперації сервісів.


У статті “Моделювання SOA. Частина 2. Специфікація сервісів” ми показали, як моделювати деталі специфікації з точки зору постачальника. У специфікації сервісу вказується інформація, необхідна потенційному споживачеві для того, щоб визначити, чи можна застосувати даний сервіс для вирішення своїх завдань, і якщо можна, то як його використовувати на практиці. Крім того, специфікація сервісу визначає, що повинен зробити постачальник для реалізації сервісу.


У наступних статтях, “Моделювання SOA. Частина 3. Реалізація сервісу” і “Моделювання SOA. Частина 4. Компонування сервісів” розповідалося про те, як створюються проекти і моделі компонентів, що мають або запитують сервіси, і як реалізуються операції сервісів. У цих статтях також описувалося, як постачальники сервісів вказують виконувані ними контракти, що дозволяє знову зв’язати постачальники сервісу з завданнями, цілями, процесами і вимогами бізнесу.


В останній статті описувалася реалізація сервісів на платформі Web-сервісів, підтримуваної IBM WebSphere Integration Developer за допомогою інструменту перетворення IBM UML-SOA. Середа WebSphere Integration Developer підтримує модель програмування SOA, яка узгоджується з проектами ідентифікації, специфікації і реалізації, документованими в Rational Software Architect. За допомогою WebSphere Integration Developer можна завершити програмування сервісів, а потім згенерувати інтерфейс користувача для виконання завдань оператором-людиною, виконати тестування та розгортання SOA-рішення.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*