Поради з програмування Web-сервісів: Сервіс-орієнтоване моделювання та архітектура

1. Серія контенту:
2. Цей контент є частиною серії: Поради з програмування Web-сервісів
3. Сервіс-Орієнтована Архітектура: концептуальна модель
4. Малюнок 1: Концептуальна модель архітектурного стилю SOA
5. Малюнок 2: Атрибути SOA
6. контекст
7. Архітектурний шаблон для SOA
8. Малюнок 3: Рівні SOA
9. Як підійти до сервісно-орієнтованого моделювання та архітектури
10. Сервіс-орієнтоване моделювання: аналіз і проектування сервісів
11. Малюнок 4: Заходи щодо забезпечення сервіс-орієнтованого моделювання
12. Малюнок 5: Метод сервіс-орієнтованого моделювання та архітектури
13. ідентифікація сервісу
14. Класифікація або категоризація сервісу
15. аналіз підсистеми
16. Специфікація компонента
17. Розміщення сервісу
18. Реалізація сервісу
19. Висновок
20. Подякою
21. Ресурси для скачування

Поради з програмування Web-сервісів

Як визначати, задавати і реалізовувати сервіси для вашої SOA

Серія контенту:

Цей контент є частиною # з серії # статей: Поради з програмування Web-сервісів

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Поради з програмування Web-сервісів

Слідкуйте за виходом нових статей цієї серії.

Останнім часом навколо можливостей, пропонованих сервіс-орієнтованої архітектури (Service-oriented Architectures (SOA)) і їх реалізацій у вигляді Web-сервісів було багато шуму і активної реклами. Аналітики висловлювали припущення, експерти висловлювали свою думку, викладачі читали лекції на цю тему, а компанії активно намагалися продати те, що у них є, як продукти SOA. У всьому цьому часто упускати той факт, що SOA взагалі не є продуктом. Йдеться про заповнення простору між бізнесом та IT за допомогою набору IT-сервісів, орієнтованих на бізнес, і що використовують набір принципів побудови, шаблонів і методів.

У виданні ZDNet недавно прозвучало буквально наступне: "Гартнер припустив, що до 2008 року більше 60% корпорацій буде використовувати SOA як" керівного принципу "при створенні критично важливих додатків і процесів."

До розробки і реалізації SOA пред'являються великі вимоги. Якщо архітектура SOA складається не тільки з продуктів і стандартів, які допомагають її реалізувати (наприклад, через Web-сервіси), то які додаткові елементи необхідні для її реалізації? Сервіс-орієнтоване моделювання вимагає проведення додаткових заходів і наявності артефактів, які не присутні в традиційному Об'єктно-орієнтований аналіз та проектування (object-oriented analysis and design - OOAD). Стаття "Elements of Service-oriented Analysis and Design" описує деякі причини, за якими вам необхідно щось більше, ніж OOAD. У ній також йдеться про те, що управління бізнес-процесом або архітектурою підприємства (EA) і OOAD недостатньо відповідають процесу проведення аналізу та проектування. На додаток до вищесказаного, в довіднику IBM "Patterns: Service-Oriented Architecture and Web Services" розкриваються основні дії підходу сервіс-орієнтованого моделювання.

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

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

Все це є незначним кроком від використання звичайних "розподілених об'єктів". Йдеться про вигоду використання мережевих засобів: наприклад, коли сторони використовують комбінацію пошукових сервісів Amazon.com і Google, і поєднують їх з сервісами eBay для побудови власних гібридних рішень. Або, наприклад, коли агентство подорожей використовує систему бронювання авіаквитків, координує її з інформацією про ренту автомобілів і бронюванням номерів в готелі, оновлює свої записи і відправляє плановану карту маршруту в ваш органайзер. Незалежно від програми, для успішного створення SOA вам потрібні не просто хороші інструменти і стандартні, а щось більше. Вам необхідні якісь перспективні кроки для підтримки життєвого циклу вашої SOA - методики для аналізу, проектування і реалізації сервісів, потоків і компонентів. Таким чином, всім, зацікавленим в розробці корпоративного програми, необхідно чітко розуміти всі докладні кроки в сервіс-орієнтованому моделюванні та архітектури.

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

Сервіс-Орієнтована Архітектура: концептуальна модель

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

Метамодель, що представляє ці відносини відображена на малюнку 1 .

Малюнок 1: Концептуальна модель архітектурного стилю SOA

Архітектурний стиль і основні принципи

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

Архітектура SOA є масштабованої IT-архітектурою на рівні підприємства для з'єднання ресурсів на вимогу. В архітектурі SOA ресурси доступні для учасників підприємства, лінії бізнесу і т.д. (Зазвичай шляхом поширення безлічі додатків в підприємстві або між декількома підприємствами). Вона складається з набору бізнес-орієнтованих IT-сервісів, які колективно задовольняють завданням і бізнес-процесів організації. Ці сервіси можна групувати в композитні додатки і викликати їх через стандартні протоколи, як показано на малюнку 2 .

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

Малюнок 2: Атрибути SOA

Швидкість адаптації бізнесу до змін досягається IT-системами, пропонованими SOA. Ці системи є гнучкими, в основному в частині розподілу інтерфейсу, реалізації і прив'язки (протоколів). Подібна гнучкість дозволяє відстрочити прийняття рішення щодо вибору постачальника сервісу в заданий момент часу на основі нових бізнес вимог. Такими вимогами можуть бути функціональні і не функціональні вимоги, наприклад продуктивність, безпеку, масштабованість і т.д.

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

контекст

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

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

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

Для перенесення на SOA нам необхідні деякі додаткові елементи, що виходять за межі сервісного моделювання:

• Моделі вибору і готовності. Наскільки дозріло ваше підприємство для переходу на архітектуру SOA і Web-сервіси? Кожен рівень готовності має свої вимоги.
• Загальна оцінка. Чи є у вас плани? Чи добре ви знайомі з Web-сервісами? Наскільки хороша ваша архітектура? Чи слід вам йти в тому ж напрямку? Чи підійде вашій задачі корпоративна архітектура SOA? Вирішили ви всі свої питання і завдання?
• Визначення стратегії і планування. Як ви плануєте здійснити перехід на SOA? Які кроки, інструменти, методики, технології, стандарти і приготування вам слід взяти до уваги? Який ваш план і бачення, як ви збираєтеся досягти мети?
• Управління. Чи повинен існуючий API або можливість стати сервісом? Якщо немає, то що є прийнятним? Кожен сервіс повинен бути створений з метою принесення бізнесу якоїсь вигоди. Як ви будете керувати цим процесом без точної стратегії?
• Реалізація кращих способів. Які з перевірених способів реалізації безпеки, продуктивності та відповідності стандартам забезпечення сумісності потрібно змінити?

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

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

Архітектурний шаблон для SOA

Абстрактний погляд на SOA зображує її як частково багаторівневу архітектуру композитних (складових) сервісів, вивірених з бізнес-процесами. на малюнку 3 відображається уявлення такого типу архітектури.

Відносини між сервісами і компонентами полягають в тому, що компоненти рівня підприємства (розгалужені компоненти підприємства або бізнес-лінії) реалізують сервіси і несуть відповідальність за забезпечення їх функціональності і якості обслуговування. Потоки бізнес-процесів можуть спиратися на те, що я називаю хореографією (об'єднанням) розкритих сервісів в композитні (складові) додатки. Архітектура інтеграції підтримує маршрутизацію, посередництво і трансляцію цих сервісів, компонентів і потоків з використанням корпоративної сервісної шини (Enterprise Service Bus - ESB). Розгорнуті сервіси повинні контролюватися і управлятися для забезпечення якості сервісу і суворого дотримання не функціональних вимог.

Малюнок 3: Рівні SOA

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

Ось як приблизно виглядає макет документа, що описує архітектуру SOA:

1. Область дії <Для якої області підприємства призначена архітектура?>
2. Рівень операційної системи
   1. упаковані програми
   2. замовні додатки
   3. архітектурні рішення
3. Рівень корпоративних компонентів
   1. Функціональні області, підтримувані даними корпоративними компонентами
   2. <Які області інтересів бізнесу, завдання і процеси підтримуються даними корпоративними компонентами>
   3. Рішення по управлінню
      1. <Критерій, за яким вибираються корпоративні компоненти в даній організації клієнта>
   4. архітектурні рішення
4. рівень сервісів
   1. Класифіковане портфоліо сервісів
   2. архітектурні рішення
5. Бізнес процес і складовою рівень
   1. Бізнес-процеси, представлені як сукупність дій
   2. архітектурні рішення
      1. <Які процеси необхідно пов'язати в сукупність дій, а з яких створити додаток?>
6. Рівень забезпечення доступу або презентації
   1. <Включення на цьому рівні документів по Web-сервісів і SOA, якщо такі існують. Наприклад, використання портлетів для виклику Web-сервісів на рівні призначеного для користувача інтерфейсу і включення функціональності на даному рівні>
7. рівень інтеграції
   1. <Включення розгляду використання ESB>
   2. <Як слід дотримуватися необхідних угод про рівень послуг (SLAs) і якості обслуговування (QoS) сервісу>
   3. Питання забезпечення безпеки і їх рішення
   4. Питання забезпечення продуктивності і їх рішення
   5. Питання обмежень в технології і стандарти і їх рішення
   6. Контроль і управління сервісами
      1. Опис і пропоновані рішення

Тепер опишемо рівні більш детально і обговоримо будова кожного з них.

Рівень 1: Рівень операційної системи. Складається з існуючих замовлених додатків, званих також успадкованими системами. Включає в себе існуючі упаковані додатки системи управління взаємозв'язками (CRM) і планування ресурсів підприємства (ERP), а також ранні об'єктно-орієнтовані реалізації системи, а заодно і додатки для управління бізнесом. Багаторівнева архітектура SOA може допомогти поліпшити вже існуючі системи та сприяти їх інтеграції з використанням сервіс-орієнтованих методів.

Рівень 2: Рівень корпоративних компонентів. Корпоративні компоненти несуть відповідальність за забезпечення функціональності та підтримання якості обслуговування (QoS) сервісів. Ці компоненти є керованим, регульованим набором корпоративних коштів які розташовані на рівні корпоративної або бізнес-одиниці. Як кошти корпоративного масштабу, вони несуть відповідальність за забезпечення відповідності угодам про рівень послуг (SLA) шляхом застосування кращих методів проектування. Для реалізації компонентів, управління робочим навантаженням, отказоустойчивостью і балансування навантаження даний рівень зазвичай використовує такі технології, засновані на використанні контейнерів, як сервери додатків.

Рівень 3: Рівень сервісів. У цьому рівні знаходяться сервіси, відібрані бізнесом. Вони можуть бути виявленими або ж бути статично пов'язаними і надалі зібраними в композитний (складовою) сервіс. Даний рівень розкриття сервісів забезпечує механізм для прийняття компонентів масштабу підприємства, спеціальних бізнес-компонентів, а в деяких випадках і компонентів для певного проекту. Крім цього він виводить підмножина їх інтерфейсів в форму опису сервісів. Таким чином, корпоративні компоненти забезпечують реалізацію сервісу в період роботи, використовуючи функціональність, надану їх інтерфейсами. В даному рівні інтерфейси експортуються як опису сервісу, в якому вони розкриті для використання. Вони можуть існувати окремо або як композитний (складовою) сервіс.

Рівень 4: Рівень об'єднання (хореографії) бізнес процесів. У цьому рівні визначається способи об'єднання сервісів, визначених у Рівні 3. Сервіси пов'язані в потік шляхом угруповання (хореографії) і, отже, вони діють спільно як окремий додаток. Подібні додатки підтримують особливі ситуації і бізнес-процеси. Тут для проектування потоків додатки можуть використовуватися такі візуальні інструменти компонування, як IBM® WebSphere® Business Integration Modeler або Websphere Application Developer Integration Edition.

Рівень 5: Рівень доступу або Презентації. Незважаючі на ті, что цею рівень зазвічай Не бере во время Обговорення SOA, поступово ВІН становится все більш значущих. Тут ВІН збережений з причини зростаючої конвергенція стандартів, таких як Web Services for Remote Portlets Version 2.0 и других технологій, Які прагнуть вівесті Web-сервіси на рівень інтерфейсу додатка або Презентації. Цей рівень можна представіті як рівень, Який необходимо Прийняти до уваги в Наступний розробка. Важливо також звернути увагу на те, що SOA відокремлює призначений для користувача інтерфейс від компонентів, і в якості альтернативи вам може знадобитися забезпечення наскрізного рішення між каналом доступу та сервісом або набором сервісів.

Рівень 6: Інтеграція (ESB). Цей рівень допускає інтеграцію сервісів шляхом подання перевіреного набору таких можливостей, як інтелектуальна маршрутизація, посередництво протоколів та інших механізмів перетворень, зазвичай описаних як ESB (див. ПОСИЛАННЯ ). Мова опису Web-сервісів (WSDL) визначає зв'язок, яка містить в собі місцезнаходження сервісу. З іншого боку, ESB для інтеграції забезпечує механізм, незалежний від місцезнаходження.

Рівень 7: Якість обслуговування (QoS). Цей рівень надає можливості для моніторингу, управління і підтримки таких аспектів якості обслуговування, як забезпечення безпеки, продуктивності і доступності. Він є фоновим процесом, що використовують механізми запитів і відповідей, і інструменти, які контролюють загальний стан додатків SOA. Сюди включені всі важливі стандартні реалізації WS-Management і інших значущих протоколів і стандартів, що реалізують якість обслуговування для SOA.

Як підійти до сервісно-орієнтованого моделювання та архітектури

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

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

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

Зрештою, використовуючи моделювання типу завдання-сервіс, ви користуєтеся перехресним підходом для скорочення явного кількості кандидатур сервісів, які можуть бути вже визначені. Є більш розумний підхід: спочатку слід виконати спадний спосіб, потім моделювання типу завдання-сервіс, і, нарешті, висхідний аналіз успадкованих коштів. Чим швидше ви приведете проект до керованого і реалістичного набору, тим раніше ви зможете реалізувати завдання, сфокусувавшись на ключових сервісах, які необхідно розкрити, з описами сервісів, які формують наріжний камінь SOA.

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

Сервіс-орієнтована інтеграція є розвитком Інтеграції Додатків Підприємств (Enterprise Application Integration, скор. EAI), в якій власницькі зв'язку замінюються зв'язками, заснованими на стандартах. Такий зв'язок здійснюється через поняття ESB, в якому місце розташування є прозорим, і забезпечує гнучкий набір можливостей маршрутизації, посередництва і перетворення.

Сервіс-орієнтоване моделювання: аналіз і проектування сервісів

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

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

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

Малюнок 4: Заходи щодо забезпечення сервіс-орієнтованого моделювання

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

Заходи, описані вище, можна відобразити у вигляді потоків в сервіс-орієнтованому моделюванні і архітектурному методі, як це показано на малюнку 5 .

Малюнок 5: Метод сервіс-орієнтованого моделювання та архітектури

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

ідентифікація сервісу

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

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

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

Класифікація або категоризація сервісу

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

аналіз підсистеми

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

Специфікація компонента

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

• дані
• Правила
• сервіси
• настроюється профіль
• варіації

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

Розміщення сервісу

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

• медіаторами
• фасадами
• об'єктами Rule
• налаштованим профілями
• фекторі

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

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

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

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

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

Висновок

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

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

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

Подякою

Автор висловлює глибоку вдячність допомоги при написанні статті своїм шановним колегам і друзям: Luba Cherbakov, Kerrie Holley, George Galambos, Sugandh Mehta, David Janson, Shankar Kalyana, Ed Calunzinski, Abdul Allam, Peter Holm, Krishnan Ramachandran, Jenny Ang, Jonathan Adams , Sunil Dube, Ralph Wiest, Olaf Zimmerman, Emily Plachy, Kathy Yglesias-Reece, David Mott.

Ресурси для скачування

Схожі тими

• Оригінальна стаття "Service-oriented modeling and architecture"
• Стаття "Elements of Service-oriented Analysis and Design" , (DeveloperWorks, червень 2004) надає більш детальну інформацію з даного міждисциплінарного способу моделювання стосовно до проектів SOA.
• Стаття з довідника SG24-6303-00 "Patterns: Service-oriented Architecture and Web Services" , Грудень 2004, Автор: Endrei M., et al.
• на сайті WebServices.Org ™ представлена більш детальна інформація по темі Цільовий підхід до ідентифікації та специфікації корпоративного компонента, Communications of the ACM, Грудень 2002 Автори: K. Levi, A. Arsanjani.
• Стаття з книги "Proceedings of the ICSM: 628-." Видавництва IEEE Press 2002. під назвою Externalizing Component Manners to Achieve Greater Maintainability through a Highly Re -Configurable Architectural Style . Автори: Ali Arsanjani, James J. Alpigini, and Hussein Zedan.
• Web-сайт "Patterns and Best-practices", автором якого є Ali Arsanjani, містить більш детальну інформацію по темі The Enterprise Component Pattern .
• Стаття з довідника SG24-6346-00 під назвою "Patterns: Implementing an SOA with the Enterprise Service Bus" , Август 2004. Автори: Martin Keen, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren.
• Безліч інформативних статей і посібників з розробки додатків Web-сервісів на сайті Web Services and SOA zone .
• ПОСИЛАННЯ по темі:
  Elements of Service-oriented Analysis and Design
  Patterns: Service-oriented Architecture and Web Services

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів