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

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

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

У цій статті ми виконаємо збірку постачальників сервісу, створених в третій статті серії, щоб використовувати їх функціональні можливості в методі ще одного постачальника сервісу. Тобто ми створимо новий сервіс з комбінації інших сервісів. Описана методика компонування сервісу допускає необмежену рекурсивне використання на будь-якому наборі вимог і на якому рівні абстракції. Однак тут ми можемо зіткнутися з архітектурними обмеженнями, які можуть вплинути на деталізацію операцій сервісу, питання безпеки і продуктивності, обсяги обміну даними, вибір протоколу зв’язку на дротовому рівні і проблеми прив’язки, що може накладати обмеження на те, які сервіси і якими компонентами будуть надаватися. Зазначені проблеми визначають архітектуру рішення і в цій статті ми не будемо їх розглядати. Додаткову інформацію по цій важливій темі можна знайти в матеріалі “Розробка SOA-рішення за допомогою посилальної архітектури”.


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


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






















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

Перегляд реалізації сервісу


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


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


Постачальник сервісу Invoicer надає сервіс InvoicingProtocol, який призначений для обчислення первісної вартості замовлення на придбання і подальшого уточнення цієї вартості після того, як стане відома інформація про доставку. Підсумкова вартість замовлення залежить від того, де виробляються продукти і звідки вони повинні бути доставлені. Обчислення первісної вартості можна використовувати для того, щоб перевірити, чи має клієнт достатній кредит або не відмовився він від наміру придбати продукцію. Краще переконатися в цьому до заповнення форми замовлення.


На малюнку 2 показана схема постачальника сервісу Productions


Рисунок 2. Топологія сервісу Production
Production service topology diagram


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


На малюнку 3 показана схема постачальника сервісу Shipper.


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


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


Компонування сервісу


До цього моменту всі сервіси надаються якими постачальниками, і ми можемо використовувати їх в збірці, яка буде задовольняти вихідним бізнес-вимогам. Така збірка компонує і оркеструє сервіси відповідно до бізнес вимогами з метою надання методу для сервісу Purchasing. Ми створимо компонент OrderProcessor, який буде надавати сервіс Purchasing для обробки замовлень на придбання. Цей постачальник сервісу запитує сервіси, які визначаються специфікаціями сервісів InvoicingService, Scheduling і ShippingService. Потім ми створимо компонент OrderProcessing, що представляє собою збірку, що складається з примірників компонентів Invoicer, Productions і Shipper, і компонент OrderProcessor, який призначений для реалізації операції сервісу з обробки замовлень на придбання.


Постачальник сервісів Order Processor


Сервіс обробки замовлень на придбання визначено в специфікації сервісів Purchasing (також показаної на малюнку 4), яка включає наступну функціональну можливість (або операцію):


+ processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice


Цей сервіс буде надавати постачальник сервісу OrderProcessor. OrderProcessor – це компонент, що надає сервіс за допомогою узгодження інших постачальників сервісів; яких оркестром відповідно до контракту про вимоги. Тобто ряд аспектів наданого методу сервісу розробляється спеціально для використання інших постачальників сервісів відповідним способом. Даний компонент надає інтерфейс Purchasing через свій порт сервісу Purchasing. Через цей порт здійснюються всі взаємодії з покупцями, тим самим клієнтські компоненти покупців відокремлюються від взаємодій, які компоненти можуть здійснювати з іншими споживачами або постачальниками сервісів. Це обмежує зв’язаність в моделі, що спрощує внесення змін при зміні ринку, споживачів і постачальників сервісу.


Рисунок 4. Специфікація сервісу придбання Purchasing.
The Purchasing service specification diagram


На малюнку 5 зображено організація компонента OrderProcessor, яка відображається в поданні браузера проектів Project Explorer.


Рисунок 5. Функціональна бізнес-область управління замовленнями (пакет)
The order management business functional area (package) screen capture


Постачальник сервісів OrderProcessor належить до пакету org::ordermanagement, Який використовується для організації сервісів, що мають відношення до управління замовленнями. Крім того, пакет управління замовленнями містить відповідні інтерфейси сервісів, споживачів і постачальників сервісів.


На діаграмі OrderProcessor (рисунок 6) зображена зовнішня схема постачальника сервісів OrderProcessor разом з наданими і запитуваними їм сервісами. (Запитувані сервіси іноді називають вимогами , Це сприяє розмежуванню потреб і функціональних можливостей.) Зовнішня схема або “чорний ящик” – це те, що бачать споживачі постачальника сервісів. Внутрішня структура компонента, яка буде показана далі в цьому прикладі, являє собою внутрішню схему, або “білий ящик”, структури, що підтримує проект реалізації компоненту.


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


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


Компонент постачальника сервісу OrderProcessor настільки простий і стабільний, що в нашому прикладі архітектор та розробник вирішили не використовувати специфікацію сервісу. В результаті будь-який споживач сервісу, використовує компонент OrderProcessor, буде зчеплений з даною конкретною реалізацією. Чи виявиться такий проект адекватним, залежить від того, скільки сервісів буде використовуватися і скільки сервісів зміниться з плином часу. Рішення з приводу того, який рівень зв’язності прийнятний для конкретної системи, може прийняти тільки архітектор рішення.


Компонент OrderProcessor має також порти сервісу, що представляють собою вимоги для потреб, виставляються іншими постачальниками сервісів: Invoicing, Scheduling і Shipping. Ці постачальники надають сервіси, які компонент OrderProcessor використовує для реалізації наданих їм операцій сервісу.


Кожна з цих точок взаємодії сервісів пов’язана з простим протоколом, який впливає на надані і запитувані інтерфейси. Наприклад, точка взаємодії Invoicing запитує інтерфейс Invoicing, щоб ініціювати обчислення вартості і передати вартість доставки. Однак на обчислення вартості доставки може знадобитися певний час, тому OrderProcessor надає інтерфейс InvoiceProcessing через порт інвойсінга, щоб постачальник сервісу інвойсінга міг передати рахунок після того, як він буде готовий.


Модель проекту реалізації Order Processor


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


Внутрішня структура


Постачальник сервісу OrderProcessor надає єдину специфікацію сервісу, Purchasing, через свій порт сервісу придбання. Ця специфікація сервісу визначає єдину операцію, processPurchaseOrder. Постачальник сервісу повинен надати метод для всіх наданих ним операцій сервісу. У даному прикладі як методу операції processPurchaseOrder використовується Activity. Детально це показано у внутрішній структурі компонента OrderProcessor, що надає сервіс. Внутрішня структура OrderProcessor документується в діаграмах, інтерфейсах, класах і діяльностях, як видно з представлення Project Explorer на малюнку 7 і комбінованої структурної діаграми на рисунку 8.


Малюнок 7. Схема організації постачальника сервісів OrderProcessor
The organization of the OrderProcessor service provider diagram



У поданні Project Explorer відображається список компонентів постачальника OrderProcessor і метод (поведінка) для кожної наданої операції. У цьому прикладі використовується угоду про використання діаграми класу з ім’ям, відповідним імені компонента, в пакеті, що містить цей компонент, для того, щоб відобразити зовнішню схему. Ця діаграма зображена на малюнку 6 і в нижній частині малюнка 7. Комбінована структурна діаграма з ім’ям, відповідним імені компонента і міститься в цьому компоненті, відображає внутрішню схему структури постачальника сервісів. Описана діаграма знаходиться відразу під зображенням постачальника сервісів OrderProcessor на малюнку 7. Угоди полегшують координацію зовнішніх і внутрішніх схем учасників сервісу та складання діаграм, повністю відображають структуру компонента.


Комбінована структурна діаграма OrderProcessor, показана на малюнку 8, являє собою загальну схему внутрішньої структури постачальника сервісів. На ній ми знову бачимо елементи (порти і властивості), складові статичну структуру компонента.


Рисунок 8. Внутрішня структура постачальника сервісів OrderProcessor
The internal structure of the OrderProcessor service provider diagram



Внутрішня структура компонента OrderProcessor не відрізняється складністю. Цей компонент складається з портів сервісу для надаються і запитуваних інтерфейсів, а також з декількох інших властивостей, які керують станом постачальника сервісів. Властивість ID використовується для ідентифікації постачальника сервісів. В процесі виконання сервісу це властивість буде використовуватися для кореляції взаємодії споживачів і постачальників. Властивості schedule і shippingInfo являють собою інформацію, яка використовується в реалізації операції сервісу processPurchaseOrder.


Методи надаються операцій сервісу


Кожна операція сервісу, що надається постачальником сервісу, повинна бути реалізована будь-яким з наступних елементів:


Завдяки цьому єдина діяльність Activity зможе мати (як правило) більше однієї точки паралельного введення і відповідати декільком діяльностям отримання, вираженим на мову виконання бізнес-процесів Business Process Execution Language (BPEL). Операції AcceptEventActions зазвичай використовуються для обробки зворотних викликів з приводу повертається інформації з інших асинхронних операцій CallOperationActions.


У компоненті OrderProcessor присутні приклади обох стилів реалізації сервісів. Операція processPurchaseOrder має метод Activity з таким же ім’ям. Ця діяльність, зображена на малюнку 9, є поведінкою, яким володіє постачальник сервісів, що надає операцію сервісу.


Малюнок 9. Реалізація операції сервісу processPurchaseOrder
The processPurchaseOrder Service Operation Implementation diagram



Дана діаграма дуже схожа на діаграму WebSphere Business Modeler для цього ж поведінки. У даному процесі операції сервісу InvoiceProcessing і ScheduleProcessing реалізуються через операції реєстрації подій processInvoice і processSchedule. Зверніть увагу на те, що відповідні операції в інтерфейсах помічені як trigger, щоб показати їх здатність відповідати на AcceptEventActions (аналогічно приймання і AcceptEventActions, де тригером є подія SignalEvent). Ключове слово trigger не підтримується UML 2 і включено в схему тільки для того, щоб зробити зрозуміліше спосіб реалізації цих операцій.


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


Виконання контрактів сервісу


Робота над компонентом OrderProcessor завершена. Нам залишилося виконати ще дві речі:


  1. Спочатку необхідно знову зв’язати постачальника сервісу OrderProcessor з бізнес-процесом, який моделює вимоги до цього постачальника;
  2. Потім ми повинні створити підсистему для підключення постачальників, здатну надати запитувані постачальником OrderProcessor інтерфейси, до відповідних портів сервісу.

В результаті ми отримаємо працездатну розгорнутих підсистему. У цьому розділі ми займемося зв’язуванням SOA-рішення з бізнес-вимог. У наступному розділі буде розказано про розгорнутих підсистемі.


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


На малюнку 10 показані вимоги для постачальника сервісів OrderProcessor за допомогою контракту сервісу, який надає орієнтоване на ролі подання бізнес-процесів, створених бізнес-аналітиком. Щоб показати, який контракт сервісу виконує постачальник сервісів OrderProcessor, в схему добавлена ​​кооперація.


Малюнок 10. Виконання контракту сервісу
Fulfilling the service contract diagram


Використання кооперації, яке на малюнку 10 позначено як contract , Являє собою екземпляр кооперації сервісів Purchase Order Process, яка зображена на наступному малюнку. Це визначає, що постачальник сервісу OrderProcessor виконує бізнес-вимоги процесу обробки замовлень на придбання Purchase Order Process. Прив’язки ролей показують, які ролі в контракті сервісу відповідають елементам постачальника сервісів. Наприклад, порт інвойсінга виконує роль Invoicing, а порт придбання виконує роль orderProcessor.


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


Малюнок 11. Контракт про вимоги до сервісу
Service Requirements contract diagram


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


Збірка підсистеми OrderProcessing


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


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


Малюнок 12. Збірка розгорнутих підсистеми з елементів
Assembling the parts into a deployable subsystem diagram


Підсистема OrderProcessing складається з примірників компонентів постачальників сервісів OrderProcessor, Invoicer, Productions і Shipper. Сервіс інвойсінга seller-компонента узгоджується з сервісом інвойсінга компонента Invoicer. Це коректне узгодження, оскільки специфікація сервісу інвойсінга компонента OrderProcessor є комплементарної специфікацією сервісу інвойсінга постачальника Invoicer. Компонент OrderProcessor запитує інтерфейс Invoicing у постачальника сервісу Invoicer. Він також надає інтерфейс InvoiceProcessing, що дозволяє постачальнику Invoicer отримувати оновлені рахунку.


Узгодження сервісів (примірників специфікацій сервісів) означає, що учасники згодні взаємодіяти через коннектори згідно специфікації сервісу, тобто вони згодні використовувати обумовлений в специфікації протокол. Специфікація сервісу визначає ролі, які узгоджуються учасники виконують у цьому протоколі. Коннектор каналів сервісу між портом інвойсінга споживача orderProcessor і портом інвойсінга постачальника Invoicer має контракт (деякий поведінка), яке представляє собою поведінку InvoicingService специфікації сервісу InvoicingService. Ім’я коннектора визначається за іменем його контракту відповідно до угоди. Від усіх з’єднань на кінцях цього коннектора вимагається дотримання даного контракту або протоколу. Коннектори формалізують використання взаємозалежностей в архітектурі сервісу.


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


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


Ми завершили створення підсистеми OrderProcessing; тепер вона готова до розгортання. Ця підсистема має певні екземпляри постачальників запитуваних сервісів, необхідних для повної реалізації сервісу processPurchaseOrder. Після розгортання інші споживачі сервісу можуть бути прив’язані до сервісу Purchasing seller-компонента OrderProcessor і викликати операції сервісу.


Резюме. Що далі


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


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

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


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

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

Ваш отзыв

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

*

*