Моделювання SOA: Частина 3. Реалізація сервісу

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


Про цю серії


У попередній статті серії, "Частина 1. Ідентифікація сервісу", розповідалося про принципи ідентифікації сервісів, що узгоджуються з бізнес-вимог. Ми почали з з'ясування бізнес-завдань і бізнес-цілей, що сприяють здійснення бізнес-місії. Потім ми змоделювали бізнес-операції і бізнес-процеси, необхідні для вирішення завдань і досягнення цілей. Після цього ми ідентифікували запитувані сервіси і потенційні взаємозв'язку між ними, скориставшись як допоміжного контракту бізнес-процесом.


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


У даній статті ми розповімо про розробку реальної моделі надання сервісу, або, в термінології уніфікованої мови моделювання Unified Modeling Language (UML), його реалізації. У процесі розробки реалізації сервісу спочатку вирішують, який компонент буде пропонувати сервіси, і які саме сервіси. Дане рішення виявляє помітний вплив на доступність, розподіленість, безпека, обсяг транзакцій і пов'язаність сервісу. Після того, як рішення буде прийнято, можна визначити модель реалізації функціональних можливостей кожного сервісу, а отже, і те, як насправді будуть використовуватися запитувані сервіси.


У наступній статті цієї серії, "Моделювання SOA: Частина 4. Компонування сервісу," ми розповімо про те, як можна комбінувати сервіси для створення нових сервісів. В останній статті серії, "Частина 5. Реалізація сервісу ", ми скористаємося функцією перетворення UML-SOA з пакета IBM ® Rational ® Software Architect для створення реалізації Web-сервісу, яку можна буде використовувати безпосередньо в IBM WebSphere Integration Developer для реалізації, тестування та розгортання готового рішення.


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


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



  1. Прийняття рішення про те, які постачальники і які сервіси будуть надавати;
  2. Розробка реалізацій сервісів;
  3. Збірка і підключення споживачів і постачальників сервісу; це необхідно для завершення моделювання реалізацій.

Прийняття рішення про те, які сервіси якими постачальниками (їх може бути більше, ніж один) будуть надаватися, обумовлюється багатьма факторами, включаючи наступні:



  • Де найімовірніше будуть використовуватися сервіси;
  • Де вони швидше за все будуть розгорнуті;
  • Яку якість сервісу необхідно;
  • Стабільна чи функціональної область;
  • Де очікується найбільше змін;
  • Який рівень зв'язності прийнятний для цієї предметної області;
  • Питання забезпечення безпеки;
  • Які технології платформи реалізації застосовуються;
  • Інтеграція та багаторазове використання наявних систем.

У цій статті ми не будемо детально аналізувати всі ці питання, ви знайдете їх повний опис в документації до методу сервіс-орієнтованого моделювання і архітектури IBM ® Service Oriented Modeling and Architecture (SOMA). У цій статті ми припускаємо, що ІТ-архітектори вже прийняли якесь рішення з приводу того, які постачальники будуть надавати сервіси, і які це будуть сервіси, тому ми можемо зосередитися на тому, як створити моделі цих постачальників і зібрати з них рішення для споживача.


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


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



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


На малюнку 2 показані специфікації сервісів, які були ідентифіковані як необхідні для виконання вимог. По суті, ми створюємо (набуваємо, повторно використовуємо, адаптуємо) сервіси, які здатні виконувати ролі в описаному контракті про вимоги до бізнес-сервісів.


Малюнок 2. Топологія сервісу



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


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



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


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



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


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


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



Цей протокол також більш складний, оскільки надаються і запитувані функціональні можливості сервісу повинні викликатися і отримувати відповіді на запити в певному порядку. У даному випадку одна з діяльностей використовується для визначення протоколу сервісу. Однак ми могли точно так само використовувати або взаємодія, або кінцевий автомат – це питання переваг розробника.


На малюнку 6 показано специфікація сервісу придбання Purchasing:


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



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


Тепер ми можемо приступити до розробки компонентів, що надають кожен із сервісів.


Реалізація сервісу


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


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


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


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


Інвойсінг


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


Ми почнемо розробку постачальника сервісу зі створення системного прецеденту, що визначає вимоги до нього, і компонента <<serviceProvider>> з ім'ям Invoicer, який буде реалізувати цей прецедент. Компонент Invoicer буде розміщуватися в пакеті credit, який імпортує пакет CRM (пакет управління взаємовідносинами з клієнтами), щоб використовувати загальні визначення даних сервісу (повідомлення). На малюнку 7 показано, що ми маємо на даний момент.


Малюнок 7. Початкова модель постачальника сервісу Invoicer



Постачальник сервісу Invoicer буде надавати сервіс InvoicingService. Для створення моделі ми додаємо до моделі Invoicer порт <<service>> , Що має тип специфікації сервісу InvoiceService . Всі сервіси типізовані в специфікації сервісу, яка визначає, які функціональні можливості надаються та запитуються, а також протокол, необхідний для його використання. На рисунку 8 показаний постачальник Invoicer після додавання сервісу інвойсінга.


Малюнок 8. Додавання сервісу InvoicingService до постачальника сервісу Invoicer



За типом сервісу ми можемо визначити, що він надає інтерфейс Invoicing і запитує інтерфейс InvoiceProcessing. Крім того, за типом сервісу ми можемо зробити висновок, що повинен зробити споживач при підключенні до сервісу, щоб використовувати цей сервіс, і що постачальник Invoicer (або будь-який інший постачальник) повинен зробити, щоб його реалізувати. Будь-яке використання і реалізація сервісу повинні бути узгоджені зі специфікацією сервісу і його протоколом.


Порт <<service>> (Порт інвойсінга) також може визначати можливі прив'язки, що надаються компонентом Invoicer для використання в поєднанні з іншими компонентами. Решта допустимі принципи прив'язки, наприклад "RMI over IIOP" (Remote Method Invocation over Internet Inter-ORB Protocol, Віддалений виклик методу через протокол інтернету Inter-ORB) або "SOAP over HTTP", також можуть справляти значний ефект на продуктивність, доступність і безпека сервісу. Отже, ці питання повинні бути вирішені на етапі розробки сервісу, незважаючи на те, що вони можуть бути переносних специфічними. Як мінімум, проект рішення повинен вирішувати питання про те, чи буде підключення до сервісу локальним і / або віддаленим.


Постачальник Invoicer надає інтерфейс Invoicing, що має дві операції:


  • initiatePriceCalculation;
  • completePriceCalculation.

Постачальник Invoicer повинен надати проект реалізації або метод для кожної з цих операцій сервісу. Цей метод, крім того, повинен викликати операцію processInvoice інтерфейсу InvoiceProcessing після завершення обчислення вартості. На малюнку 9 зображена схема компонента Invoicer, який є власником двох поводжень, імена яких збігаються з іменами надаються операцій.
Малюнок 9. Реалізації сервісу Invoicer



Діяльність completePriceCalculation являє собою метод для операції Invoicing::completePriceCalculation сервісу. Він використовує нечітке правило для обчислення підсумкової вартості, а потім викликає операцію InvoiceProcessing::processInvoice на порту інвойсінга. (Цільовий вхідний точкою операції processInvoice служить порт інвойсінга.) Зверніть увагу на те, що це узгоджується з протоколом інвойсінга за визначенням специфікації сервісу InvoicingService.


Нечітке поведінку initiatePriceCalculation являє собою метод для операції сервісу initiatePricesCalculation. Ця операція реалізується за допомогою Java-™ коду, записаного в тілі нечіткого поведінки.


Планування виробництва


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


Компонент Productions надає інтерфейс Scheduling через порт планування, див. малюнок 10. Порт <<service>> визначає можливі стилі прив'язки, доступні на цьому порту.


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



Методи операції сервісу – це поведінки requestProductionsScheduling і sendShippingSchedule. Деталі цих реалізацій не показані на діаграмі, вони можуть бути реалізовані розробником з використанням більш підходящих, переносних мов програмування.


Доставка


Сервіс доставки надає інтерфейс Shipping для доставки товарів на замовлення, заповненим покупцем. Сервісу також необхідний інтерфейс ScheduleProcessing, Щоб відправити запит на обробку готового розкладу споживачеві.


На малюнку 11 показано, що сервіс Shipper надає інтерфейс здійснено у відповідності з визначенням специфікації сервісу ShippingService.


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



Комплементації типів


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


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


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


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


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


Для прикладу розглянемо інтерфейс сервісу InvoicingService. На малюнку 12 показано комплементарна реалізація сервісу InvoicingService з ім'ям ~ InvoicingService.


Малюнок 12. ~ InvoicingService, комплементарна реалізація сервісу InvoicingService



Тут використовується той же угоду про призначення імен, як і для основної специфікації сервісу, за винятком того, що ім'я починається з символу ~ (Символ тильди). Можна використовувати будь-яку угоду про призначення імен, але вибраного угоду слід використовувати послідовно, щоб полегшити впізнаваність взаємозв'язку між цими типами. ~InvoicingService має такі ж внутрішню структуру і поведінки, що і InvoidingService. Ця реалізація просто використовує інтерфейси, що надаються сервісом InvoicingService, І реалізує запитувані інтерфейси.


У майбутніх версіях розширення IBM Software Service Profile for UML планується ввести поняття порту вимоги для розрізнення вимог від різних функціональних можливостей. Потім порт вимоги може використовувати той же тип, що і порт сервісу, тим самим усувається необхідність визначення комплементарних типів. Порт вимоги вказує на те, що функціональні можливості сервісу використовуються, тоді як порт сервісу вказує на те, що вони надаються.


Що далі


На цьому ми закінчили ідентифікацію, створення специфікації та реалізацію проекту сервісів, споживачів і постачальників, необхідних для вирішення бізнес-завдань. У результаті ми отримали технологічно-нейтральну модель архітектурного рішення сервісу. Але ми ще не створили модель споживача сервісу, що може зібрати разом сервіси, надані постачальниками Invoicer, Productions і Shipper, і використовувати їх для обробки замовлень на придбання. У наступній статті серії, "Моделювання SOA: Частина 4. Компонування сервісу," розповідається про те, як зібрати і з'єднати ці постачальники сервісів і про те, як координувати їх взаємодії для того, щоб створити комплексне рішення, що задовольняє бізнес-вимогам.


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


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

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

Ваш отзыв

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

*

*