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

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


У першій статті серії, “Моделювання SOA: Частина 1. Ідентифікація сервісу” (див. врізку Інші статті серії угорі ліворуч), розповідалося про принципи ідентифікації сервісів, що відповідають бізнес-вимогам. Спочатку ми визначили, які бізнес-завдання повинні бути вирішені і які цілі досягнуті для реалізації бізнес-місії. Потім ми змоделювали бізнес-операції і бізнес-процеси, необхідні для виконання завдань та досягнення цілей. Після цього ми розглянули бізнес-процес як кооперацію сервісів, що представляє собою контракт про вимоги до сервісу, який повинен виконуватися нашим майбутнім рішенням. Згодом ми використовували цей контракт про вимоги як допоміжний засіб для ідентифікації сервісів і потенційних взаємовідносин між ними. Завдяки цьому ми отримали формальний механізм ідентифікації значущих для бізнесу сервісів з прив’язкою до бізнес-цілям і бізнес-завдань, для виконання яких вони призначені.


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


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


Опис специфікації сервісу


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


В ідеалі ця інформація повинна розміщуватися в одному місці. Це значно полегшить пошук ресурсів для сервісів багаторазового використання в специфікації репозиторіїв і отримання всієї необхідної інформації, при цьому не доведеться переміщатися між безліччю різних документів або шукати пов’язані елементи. Як мінімум, специфікація включає наступну інформацію:



Як і у всіх інших статтях цієї серії, ми скористаємося наявними інструментами IBM Rational і IBM WebSphere для створення артефактів рішення і їх взаємної прив’язки, завдяки чому ми зможемо перевірити відповідність нашого рішення вимогам і більш ефективно управляти змінами. У таблиці 1 представлений процес, який ми будемо використовувати для розробки прикладу, а також інструменти, які ми будемо застосовувати для створення артефактів. Крім того, ми адаптуємо універсальна мова моделювання (UML) до моделювання сервісів, додавши профіль IBM Software Services Profile до UML-моделям в IBM Rational Software Architect.


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






















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

Перегляд ідентифікації сервісів


Давайте почнемо з перегляду бізнес-вимог і ідентифікованих нами сервісів, які повинні забезпечувати їх виконання (про це детально розповідалося в статті “Моделювання SOA: Частина 1. Ідентифікація сервісу “). На малюнку 1 бізнес-вимоги показані у вигляді кооперації ролей в бізнесі, відповідальностей ролей і правил взаємодії ролей.


Рисунок 1. Контракт про вимоги до сервісу
Контракт про вимоги до сервісу


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


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


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


І, нарешті, на малюнку 3 показано, як можна використовувати ці сервіси для виконання бізнес-вимог.


Рисунок 3. Як сервіси виконують контракт про вимоги до сервісів
Діаграма послідовності, що показує відповідність сервісу контрактом про вимоги до сервісу


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


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


Типи специфікацій сервісів


Специфікація сервісу повинна надавати таку інформацію:



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


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


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


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


Рисунок 4. Специфікація сервісу планування
Код специфікації сервісу планування


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


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


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


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


Специфікація сервісу надає інформацію про все, що потрібно знати про сервіс, включаючи вимоги, яким ви повинні відповідати, щоб використовувати сервіс (такі вимоги іноді називають “угодою про використання” (Див. статтю Деніелса (Daniels) і Чізмана (Cheesman) в розділі Ресурси)), Та вимоги, яким повинен задовольняти реалізатор сервісу (їх іноді називають “Угодою про реалізації “). Це майже та ж інформація, яка необхідна для збору бізнес-вимог; за винятком предметної області та рівня деталізації. Це цілком зрозуміло, тому що в специфікації в контракті про вимоги до сервісу ми визначаємо, як взаємодіють між собою споживач і постачальник сервісу.


В даному випадку для визначення специфікації сервісу ми використовуємо абстрактний клас, як показано на малюнку 5.


Рисунок 5. Специфікація сервісу доставки
Діаграма послідовності для специфікації сервісу доставки


Специфікація ShippingService визначає дві ролі:



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


Між ролями оператора доставки і оператора замовлень ми бачимо сполучну лінію. Вона показує, що протокол викликає певну взаємодію ролей. Елемент “взаємодія” requestShipping, який належить до класу ShippingService, показує, в чому саме полягає взаємодія.


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


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


Сервіс Інвойсування


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


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


Даний протокол документований в специфікації сервісу InvoicingService , Яка показана на малюнку 6. Зверніть увагу на те, що ця специфікація сервісу також реалізує прецедент Invoicing. Прецеденти можна використовувати для представлення специфічних вимог сервісів. Специфікація сервісу складається з двох ролей: “Оператор Інвойсування” і “Оператор замовлень”. Ці ролі мають, відповідно, тип реалізованого інтерфейсу ” Invoicing “і використовуваного інтерфейсу InvoiceProcessing . Дані інтерфейси інкапсулюють відповідальності ролей (функціональні можливості або операції сервісу або вимоги). Діяльність InvoicingService в специфікації сервісу визначає протокол використання операцій сервісу, реальна взаємодія, що може відбуватися між ролями “оператор замовлень” і “оператор Інвойсування”.


Малюнок 6. Специфікація InvoicingService
Діаграма послідовності для специфікації InvoicingService


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


Протокол показує, що оператор замовлень повинен спочатку ініціювати обчислення ціни, і тільки після цього намагатися отримати остаточний розрахунок ціни. Після цього оператор замовлень повинен бути готовий відповісти на запит (в даному випадку, зворотний виклик) на обробку остаточного рахунку. Деякі споживачі, запитують сервіс Інвойсування, можуть виконувати й інші дії крім згаданих трьох, але протокол обмежує визначення послідовності цих специфічних дій. Зверніть увагу на те, що елемент ActivityPartitions в діяльності InvoicingService представляє ролі або властивості в класі InvoicingService. Дія виклику операції, що належить до якої-небудь секції, показує, що виклик здійснюється в ролі, яку представляє ця секція (цільовий вхідний точкою дії є роль, зображувана секцією діяльності).


В даному випадку має місце тільки одне взаємодія між оператором замовлень і сервісом Інвойсування, тому клас специфікації сервісу має тільки одне поведінка – ownedBehavor. В інших ситуаціях між споживачем і постачальником може бути кілька взаємодій, кожне з яких використовує окремий протокол. Специфікація сервісу буде містити поведінку ownedBehavior, Що визначає шаблони взаємодії для кожного з цих діалогів.


На даний момент нам невідомо, який постачальник сервісу реалізує InvoicingService . Ми також не знаємо, який споживач сервісу міг би його використовувати. Нам відомо лише те, що повинен зробити будь-який споживач, щоб використовувати цей сервіс, а також те, що повинен робити будь постачальник для того, щоб його реалізувати.


Специфікація придбання


І нарешті, остання специфікація визначає обробку замовлень на придбання (рисунок 7).


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


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


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


Повертаємося до топології сервісу


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


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


Рисунок 8. Детальна схема взаємодії сервісів
Детальна діаграма послідовності для взаємодії сервісів


Лінії, що з’єднують елементи компонента “Обробка замовлень”, показують очікувані взаємодії між цими підкомпонентів. Підписи над з’єднувальними лініями відповідають іменам відповідних їм контрактів, які в цьому випадку є протоколами для відповідних специфікацій сервісів. Вони показують, що ці елементи повинні будуть надавати і запитувати інтерфейси, які визначаються специфікацією сервісу, і використовувати зазначені інтерфейси відповідно до протоколу специфікації сервісу. Те, як саме це буде відбуватися, моделюється в описах реалізації сервісів, про яку буде розказано в наступній статті даної серії.


Ми також бачимо, що всі ці елементи будуть взаємодіяти особливим чином, що дозволяє забезпечити виконання вимог контракту “Обробка замовлень на придбання”. Таким чином, Обробка замовлень об’єднує два моменти:



Модель даних сервісу


Модель даних системи взаємовідносин з клієнтами, Customer Relationship Management (CRM), визначена в пакеті org :: crm, визначає всі дані, які використовуються усіма операціями сервісу в моделі “Обробка замовлень на придбання” в цьому прикладі (малюнок 9). Пакет CRM являє собою проект моделі даних сервісу “Управління взаєминами з клієнтами “, яку можна повторно використовувати в декількох сервісах, навіть якщо ці сервіси надаються різними організаціями. У даній статті ми не розглядаємо питання виявлення і нормалізації даних сервісу, а також їх ставлення до персистентності сутностей або фізичним джерел даних. Її тема – опис даних сервісу і документування моделі.


Малюнок 9. Модель предметної області сервісів CRM
Діаграма моделі предметної області сервісів CRM


Кожен тип даних <<message>> на малюнку 9 представляє дані сервісу. Дані сервісу – це дані, які беруть участь в обміні повідомленнями між споживачами і постачальниками сервісів. Типи даних параметрів для операцій сервісу відносяться або до повідомлень, або до примітивних типів.


Примітка:
повідомлення даних сервісу та повідомлення мови опису Web-сервісів Web Services Description Language (WSDL) – це не одне і те ж. Операція сервісу може мати будь-яку кількість входів і виходів з типами повідомлень або примітивними типами. Проект операцій сервісу може передбачати використання загальних входу, виходу і повідомлень про помилки, але це не є обов’язковим, в результаті може виникнути небажана зчеплення даних штампу.


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


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


Модель даних використовує стереотип <<id>> для ідентифікації атрибутів, які унікальним чином ідентифікують екземпляри містить їх класу. До цієї теми ми будемо неодноразово звертатися при моделюванні сервісів, тому що Web-сервіси та особливо мова виконання бізнес-процесів для Web-сервісів (Business Process Execution Language for Web Services, BPEL) використовують бізнес-дані для кореляції примірників або ідентифікації об’єкта по значенням.


Що далі


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


У наступній статті даної серії, “Моделювання SOA: частина 3. Реалізація сервісу”, докладно пояснюється, як реалізуються сервіси на практиці. При реалізації сервісу спочатку вирішують, які компоненти якими сервісами будуть надаватися. Це рішення надає важливе вплив на доступність, розподіл, безпека, обсяг транзакцій і зв’язаність сервісу. Після того, як рішення буде прийнято, можна визначити модель реалізації функціональних можливостей кожного сервісу, а значить і те, як насправді будуть використовуватися запитувані сервіси. Потім ми скористаємося функцією перетворення UML-SOA, що входить до складу пакета Rational Software Architect, для створення рішення Web-сервісів, яке можна буде використовувати безпосередньо в Rational Application Developer або 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>

*

*