SOA: підходи до реалізації, Інтеграція додатків і даних, Бази даних, статті

Поява концепції сервісно-орієнтованої архітектури (service-oriented architecture, SOA) стало закономірним кроком на шляху пошуку розв’язання однієї з найбільш нагальних і складних проблем ІТ-індустрії – проблеми інтеграції додатків.


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


Передумови


Як вирішується завдання інтеграції програм? Традиційний підхід – побудова проміжного програмного шару того чи іншого типу. Оптимальною для об’єднання різнорідних платформ і рішень виглядала технологія взаємодії розподілених об’єктів CORBA, що дозволяла інкапсулювати бізнес-логіку додатків, що виконуються на різних платформах і створених з використанням різних мов програмування, організувавши зв’язок між ними на базі строго описаних інтерфейсів. Аналогічні можливості – правда, з природним обмеженням гетерогенності – пропонувала корпорація Microsoft в рамках своєї компонентної моделі DCOM. Однак цим рішенням не вистачало універсальності; навіть застосування CORBA сильно залежало від реалізації в продуктах різних постачальників, з’являлися нові об’єктні моделі, які не підтримують CORBA, інтеграція як і раніше реалізовувалася на досить низькому рівні, практично виключаючи можливість динамічного зміни зв’язків між додатками в ході виконання. Важливо і те, що всі пропоновані засоби інтеграції фокусувалися на технологічних особливостях реалізації програм і не дозволяли враховувати специфіку бізнес-процесів, в яких ці програми використовувалися.


У той же час нові потреби бізнесу диктують і нові умови інтеграції. Динамічність ІТ-середовища, її націленість на вирішення бізнес-завдань, необхідність швидких змін у відповідь на зміну цих завдань – Ці характеристики набувають ключового значення при проектуванні або реформуванні корпоративних ІТ-інфраструктур. У цих умовах окремі, “точкові” рішення по інтеграції настільки ускладнюють і саму інфраструктуру, і процес управління нею, що стають абсолютно неприйнятними. Уявімо собі, наприклад, що в компанії існує кілька програм, кожна з яких інтегровано з усіма іншими за допомогою відповідних інтерфейсів. Якщо таких програм – n, то все буде потрібно n (n-1) інтерфейсів. З додаванням всього лише одного нового додатка з’явиться 2n нових інтерфейсів, для яких буде потрібно відповідне документування, тестування і підтримка. У прикладі на рис. 1 п’ять взаємодіючих програм породжують 20 інтерфейсів, а додавання шостого програми зажадає ще 10. При цьому доведеться вносити модифікації в код кожного з існуючих програм для обліку нових інтерфейсів і проводити відповідне тестування. Щоб уникнути цього, потрібна модель інтеграції, яка дозволить максимально спростити процес додавання нових додатків і мінімізує кількість інтерфейсів взаємодії.








Рис. 1. Пряма інтеграція додатків

Ще одна серйозна проблема – надмірність програмних компонентів і складність їх багаторазового використання. В [1] наводиться приклад програмної інфраструктури банку, що включає в себе кілька груп додатків для різних напрямків банківської діяльності, які були розроблені в рамках ніяк не пов’язаних між собою проектів. В результаті, з більшою часткою ймовірності можлива ситуація, коли одна функція (скажімо, отримання балансу по вкладу) реалізована багаторазово в системі автоматизації банкоматів, в системі підтримки філій і в системі розрахунків за кредитними картками, – навіть якщо всі ці системи використовують одні і ті ж дані про рахунок з загальної бази даних. А тепер припустимо, що банк має намір розробити нові системи, наприклад, для обслуговування клієнтів в Internet або видачі позик в режимі on-line. Розширення функціональності програмного середовища банку спричинить додаткову надмірність, якщо в цьому середовищі відсутні механізми багаторазового використання компонентів, що підтримують різні завдання бізнесу.


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


Характеристики SOA


Наведемо формальне визначення сервісно-орієнтованої архітектури, яке сформульовано фахівцями корпорації IBM [1]: “SOA – це прикладна архітектура, в якій усі функції визначені як незалежні сервіси з викликуваними інтерфейсами. Звернення до цих сервісів в певній послідовності дозволяє реалізувати той чи інший бізнес-процес “. З точки зору розробників, ту ж думку можна передати дещо іншими словами: SOA – це компонентна модель, в якій різні функціональні одиниці додатків, звані сервісами, взаємодіють по мережі за допомогою інтерфейсів. Розшифруємо дані визначення.



  1. Всі функції додатків визначені як сервіси. Як сервісу може виступати як ціле додаток, так і окремі його функціональні модулі. Сервісами можуть бути прикладні функції, що реалізують певну бізнес-логіку, бізнес-транзакції, що складаються з декількох функцій більш низького рівня, і системні функції, що відбивають специфіку різних операційних платформ.
  2. Всі сервіси незалежні один від одного. Вони виконують певні дії за запитами, отриманими від інших сервісів, і повертають результати. Всі деталі цього повністю сховані: в концепції SOA сервіси – це “чорні ящики”.
  3. В інтерфейсі сервісу визначені параметри і описаний результат. Іншими словами, інтерфейс визначає суть сервісу, а не технологію його реалізації. На архітектурному рівні для звернення до сервісу не має значення, чи він локальним (реалізований у даній системі) або віддаленим (зовнішній по відношенню до неї), який протокол використовується для передачі виклику, які компоненти інфраструктури при цьому задіяні. SOA припускає наявність єдиної схеми поводження до сервісу незалежно від того, чи перебуває вони в тому ж самому додатку, в іншому адресному просторі багатопроцесорної системи, на іншій апаратній платформі в корпоративній intranet-мережі або в додатку до системі партнера.

Інтерфейси – ключові елементи SOA. Вони повинні бути нейтральними до специфіки реалізації сервісу, які визначаються апаратної платформою, операційною системою, мовою програмування. Подібний нейтралітет забезпечує універсальність взаємодії сервісів в різнорідної середовищі, а сервіси, інтегровані за допомогою таких інтерфейсів, є слабко зв’язаними (loose coupling). Слабка зв’язаність забезпечує просту і швидку адаптацію системи в цілому до змін у структурі та принципах реалізації сервісів. Таким чином, для SOA характерна гнучкість, здатність реагувати на зміни в бізнес-процесах динамічно і без складних трансформацій на інтеграційному рівні.


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


Багато авторів підкреслюють, що ідея SOA не нова і, по суті, не пов’язана з конкретними технологіями реалізації, що її зачатки вгадуються вже в CORBA і в програмному забезпеченні проміжного шару на базі обміну повідомленнями (message oriented middleware), що її не можна ототожнювати з Web-сервісами, які представляють собою сукупність технологій і стандартів. Все це вірно, однак саме поява Web-сервісів зробило SOA реальністю. Мова опису інтерфейсів у CORBA не забезпечує тієї незалежності від платформ, яка потрібна для побудови SOA, а тому дана модель дозволяє реалізувати тільки сильно пов’язану інтеграцію компонентів. З появою XML був відкритий шлях до створення нейтральних до платформи реалізації інтерфейсів. Заснований на XML мова опису Web-сервісів WSDL і використання XML для обміну повідомленнями між сервісами забезпечують той універсальний механізм взаємодії різнорідних компонентів, без якого неможливо реалізувати SOA.


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


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


Платформа реалізації SOA


Як відзначають аналітики компанії ZapThink, яка спеціалізується на питаннях SOA, і замовникам, і постачальникам необхідно усвідомити наступний принциповий момент: SOA – це не черговий варіант розподіленої обчислювального середовища, який, досягнувши стадії зрілості, буде існувати паралельно з іншими можливими варіантами [2]. У перспективі будь-яка архітектура ІТ-середовища – клієнт-серверна, многозвенная, побудована на базі шини повідомлень і т.д. – Повинна розглядатися в контексті орієнтації на сервіси. SOA – це більш високий рівень абстракції, який дає можливість об’єднати різні архітектурні стилі та моделі організації розподілених систем на різних платформах за допомогою слабо пов’язаних інтерфейсів і асинхронного взаємодії між ними.


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


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


Програмні компоненти для вирішення всіх цих завдань утворюють платформу реалізації SOA. У ZapThink виділяють п’ять основних груп функцій програмних продуктів, необхідних для побудови SOA: це функції захисту, управління, підтримки процесів, інтеграції та інструментарію. Для того, щоб отримати працездатні програми в архітектурі SOA, обов’язковим для цих компонентів є проходження відкритим стандартам (Насамперед, стандартам Web-сервісів) і принципам сервісної орієнтації, таким як слабка зв’язаність, інкапсуляція змісту, асинхронність взаємодії.


П’ять категорій програмних рішень – це п’ять сегментів ринку програмного забезпечення, які з часом стануть частиною єдиного ринку засобів для реалізації SOA. У той же час, ці основи SOA є частиною “екосистеми” сучасного ринку програмного забезпечення, яка починає поступовий перехід до глобальної підтримки принципів орієнтації на сервіси. ZapThink призводить вражаючу діаграму ( рис. 2 ), Яка ілюструє взаємозв’язки між різними групами програмних продуктів (і відповідними сегментами цього ринку), їх положення щодо платформи реалізації SOA зараз і в найближчій перспективі.


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


Зелені блоки символізують ринки систем, пов’язаних з Web-сервісами. Вони також перебувають у перехідному стані, оскільки з’явилися порівняно недавно і з плином часу стануть частиною інших сегментів ринку сервісно-орієнтованих систем. У деяких випадках цей перехід вже фактично завершений, наприклад, для такої категорії продуктів, як СУБД, розраховані на безпосередню роботу з XML-даними. Постачальники цих рішень проявляли велику активність в 2002 році, але вже до середини 2003 року більшість з них або взагалі вийшли з гри, або були придбані іншими компаніями, або переорієнтували свою діяльність на інші стратегічні напрями, такі як оперативні сховища даних або системи управління контентом.


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


SOA за версією “Блакитного гіганта”


Ринок засобів реалізації SOA ще тільки формується, а тому жоден із сучасних постачальників програмного забезпечення поки не може запропонувати рішень з повним спектром необхідної функціональності [2]. Аналітики ZapThink виділяють кілька компаній, які вже мають солідний продуктовий багаж в тих областях, на базі яких розвивається перехід до SOA, і вже виконали чималу роботу з підтримки у своїх системах стандартів Web-сервісів і принципів SOA в цілому. Серед них компанії НР, IBM, Microsoft і Computer Associates, а також ряд гравців з більш сфокусованої спрямованістю, включаючи BEA Systems, Ascential Software, Sybase, Progress Software, webMethods, Software AG.


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


IBM пропонує чотирьохрівневий підхід до адаптації принципів SOA [3]. Кожен з рівнів може включати кілька етапів життєвого циклу сервісу, яких також чотири: створення (build), розгортання (deploy), використання (use), управління і захист (manage and secure).


Чотири етапи життєвого циклу сервісу


Створення сервісів увазі як побудова бізнес-моделі майбутнього програми в SOA, так і безпосередню розробку сервісів як багаторазово використовуваних компонентів із загальними, публікуються інтерфейсами. Для цього розробники повинні мати інструментарій, що забезпечує підтримку принципів SOA і необхідних стандартів для проектування моделі програми, розробки сервісу в цілому і входять до нього об’єктів, а також тестування програми в сервісно-орієнтованої середовищі. Для SOA необхідна модель компонентної розробки, яка дозволить створювати не тільки нові сервіси, але і включати в єдину сервісно-орієнтовану середу вже існуючі на підприємстві програми і програмні моделі. Засоби розробки, пропоновані IBM, забезпечують інтеграцію в SOA програмних компонентів, реалізованих в архітектурі CORBA або в середовищі з проміжним шаром на базі WebSphere MQ, успадкованих додатків, керованих за допомогою монітора транзакцій CICS, і т.д.


Перспективною для SOA може бути нова архітектура розробки на базі моделей (Model-Driven Architecture, MDA), запропонована консорціумом OMG. У цій архітектурі, яка підтримується у ряді продуктів сімейства IBM / Rational, розробка програм починається зі створення незалежної від специфіки реалізації моделі програми, на базі якої потім автоматично генерується модель для конкретної платформи і коди програми. Високий рівень абстракції при проектуванні програм в MDA добре узгоджується з підходами SOA, що представляє програми як сервіси, взаємодіють для реалізації певного бізнес-процесу.


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


Чотири рівні адаптації SOA


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


Рівень 1. Реалізація окремих Web-сервісів. Це початковий рівень розгортання SOA, на якому технології Web-сервісів використовуються для розробки нових програм або перетворення існуючих, наприклад, для інтеграції з допомогою WSDL-інтерфейсів систем, написаних на С + +, Cobol і Java. Тут компанії повинні реалізувати етапи створення та розгортання сервісів. Для створення пропонується інструментарій WebSphere Studio Application Developer, а також набір засобів Emerging Technology Toolkit, який дозволяє розробникам випробувати нові рішення в області Web-служб. Розгортання Web-сервісів підтримується сервером додатків WebSphere Application Server.


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


Платформа реалізації SOA


Як відзначають аналітики компанії ZapThink, яка спеціалізується на питаннях SOA, і замовникам, і постачальникам необхідно усвідомити наступний принциповий момент: SOA – це не черговий варіант розподіленої обчислювального середовища, який, досягнувши стадії зрілості, буде існувати паралельно з іншими можливими варіантами [2]. У перспективі будь-яка архітектура ІТ-середовища – клієнт-серверна, многозвенная, побудована на базі шини повідомлень і т.д. – Повинна розглядатися в контексті орієнтації на сервіси. SOA – це більш високий рівень абстракції, який дає можливість об’єднати різні архітектурні стилі та моделі організації розподілених систем на різних платформах за допомогою слабо пов’язаних інтерфейсів і асинхронного взаємодії між ними.


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


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


Програмні компоненти для вирішення всіх цих завдань утворюють платформу реалізації SOA. У ZapThink виділяють п’ять основних груп функцій програмних продуктів, необхідних для побудови SOA: це функції захисту, управління, підтримки процесів, інтеграції та інструментарію. Для того, щоб отримати працездатні програми в архітектурі SOA, обов’язковим для цих компонентів є проходження відкритим стандартам (Насамперед, стандартам Web-сервісів) і принципам сервісної орієнтації, таким як слабка зв’язаність, інкапсуляція змісту, асинхронність взаємодії.


П’ять категорій програмних рішень – це п’ять сегментів ринку програмного забезпечення, які з часом стануть частиною єдиного ринку засобів для реалізації SOA. У той же час, ці основи SOA є частиною “екосистеми” сучасного ринку програмного забезпечення, яка починає поступовий перехід до глобальної підтримки принципів орієнтації на сервіси. ZapThink призводить вражаючу діаграму ( рис. 2 ), Яка ілюструє взаємозв’язки між різними групами програмних продуктів (і відповідними сегментами цього ринку), їх положення щодо платформи реалізації SOA зараз і в найближчій перспективі.


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


Зелені блоки символізують ринки систем, пов’язаних з Web-сервісами. Вони також перебувають у перехідному стані, оскільки з’явилися порівняно недавно і з плином часу стануть частиною інших сегментів ринку сервісно-орієнтованих систем. У деяких випадках цей перехід вже фактично завершений, наприклад, для такої категорії продуктів, як СУБД, розраховані на безпосередню роботу з XML-даними. Постачальники цих рішень проявляли велику активність в 2002 році, але вже до середини 2003 року більшість з них або взагалі вийшли з гри, або були придбані іншими компаніями, або переорієнтували свою діяльність на інші стратегічні напрями, такі як оперативні сховища даних або системи управління контентом.


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


SOA за версією “Блакитного гіганта”


Ринок засобів реалізації SOA ще тільки формується, а тому жоден із сучасних постачальників програмного забезпечення поки не може запропонувати рішень з повним спектром необхідної функціональності [2]. Аналітики ZapThink виділяють кілька компаній, які вже мають солідний продуктовий багаж в тих областях, на базі яких розвивається перехід до SOA, і вже виконали чималу роботу з підтримки у своїх системах стандартів Web-сервісів і принципів SOA в цілому. Серед них компанії НР, IBM, Microsoft і Computer Associates, а також ряд гравців з більш сфокусованої спрямованістю, включаючи BEA Systems, Ascential Software, Sybase, Progress Software, webMethods, Software AG.


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


IBM пропонує чотирьохрівневий підхід до адаптації принципів SOA [3]. Кожен з рівнів може включати кілька етапів життєвого циклу сервісу, яких також чотири: створення (build), розгортання (deploy), використання (use), управління і захист (manage and secure).


Чотири етапи життєвого циклу сервісу


Створення сервісів увазі як побудова бізнес-моделі майбутнього програми в SOA, так і безпосередню розробку сервісів як багаторазово використовуваних компонентів із загальними, публікуються інтерфейсами. Для цього розробники повинні мати інструментарій, що забезпечує підтримку принципів SOA і необхідних стандартів для проектування моделі програми, розробки сервісу в цілому і входять до нього об’єктів, а також тестування програми в сервісно-орієнтованої середовищі. Для SOA необхідна модель компонентної розробки, яка дозволить створювати не тільки нові сервіси, але і включати в єдину сервісно-орієнтовану середу вже існуючі на підприємстві програми і програмні моделі. Засоби розробки, пропоновані IBM, забезпечують інтеграцію в SOA програмних компонентів, реалізованих в архітектурі CORBA або в середовищі з проміжним шаром на базі WebSphere MQ, успадкованих додатків, керованих за допомогою монітора транзакцій CICS, і т.д.


Перспективною для SOA може бути нова архітектура розробки на базі моделей (Model-Driven Architecture, MDA), запропонована консорціумом OMG. У цій архітектурі, яка підтримується у ряді продуктів сімейства IBM / Rational, розробка програм починається зі створення незалежної від специфіки реалізації моделі програми, на базі якої потім автоматично генерується модель для конкретної платформи і коди програми. Високий рівень абстракції при проектуванні програм в MDA добре узгоджується з підходами SOA, що представляє програми як сервіси, взаємодіють для реалізації певного бізнес-процесу.


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


Чотири рівні адаптації SOA


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


Рівень 1. Реалізація окремих Web-сервісів. Це початковий рівень розгортання SOA, на якому технології Web-сервісів використовуються для розробки нових програм або перетворення існуючих, наприклад, для інтеграції з допомогою WSDL-інтерфейсів систем, написаних на С + +, Cobol і Java. Тут компанії повинні реалізувати етапи створення та розгортання сервісів. Для створення пропонується інструментарій WebSphere Studio Application Developer, а також набір засобів Emerging Technology Toolkit, який дозволяє розробникам випробувати нові рішення в області Web-служб. Розгортання Web-сервісів підтримується сервером додатків WebSphere Application Server.


Ще один варіант – суто внутрішні зміни в бізнесі. Наприклад, будинок моди приймає рішення розширити свою роздрібну мережу за допомогою бутиків за принципом “магазин у магазині”. При цьому основна частина бізнес-операцій компанії залишиться без змін, але в її власній програмній системі повинні бути враховані нові умови угод про оренду. В даному випадку серйозного перегляду може піддатися внутрішня система компанії, але, завдяки SOA, це ніяк не відіб’ється на взаємодії з постачальниками.


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


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

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


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

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

Ваш отзыв

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

*

*