Моделювання 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. Ролі, завдання та інструменти процесу розробки



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


Малюнок 2. Модель даних сервісу


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


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


Малюнок 3. Специфікація сервісу планування Scheduling


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


Малюнок 4. Постачальник сервісу Productions


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


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


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


Малюнок 5. Специфікація сервісу ShippingService


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


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


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


Сервіс Invoicing


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


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


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


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


Малюнок 8. Реалізації сервісу Invoicer


Сервіс Purchasing


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


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


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


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


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


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


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


Дана діаграма дуже схожа на діаграму 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. Створення конфігурації перетворення


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


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


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



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

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


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


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


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


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


Якщо встановити для властивості "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. Результати перетворення


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


При налаштуванні конфігурації перетворення 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, її бізнес-об'єкти і інтерфейси


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


Малюнок 18. XSD-елементи, згенеровані з моделі даних сервісу


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


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


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


Кожен постачальник сервісів в 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


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


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


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


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


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


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


Постачальник сервісів 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


Зверніть увагу на те, що діаграма процесу 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 на малюнку 23 – OrderProcessor, Тобто таку ж, як у постачальника сервісу OrderProcessor, а не processPurchaseOrder, Як у надається операції.


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


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


Для компонента постачальника сервісів 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>

*

*