Вибір технології для інтеграції прикладних систем підприємства (EAI) – JCA, JMS або Web-сервіси?, Комерція, Різне, статті

Введення


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


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


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


В даний час зростаюча потреба в гнучкому доступі до бізнес-сервісів та незалежності клієнтів задовольняється за рахунок архітектур, побудованих на інтерфейсах. Серед архітектур на основі інтерфейсу можна назвати такі технології, як Web-сервіси, архітектура коннектора J2C J2C Connector Architecture (JCA) та сервіс обміну повідомленнями Java Java Message Service (JMS). Ці технології також включають всі варіанти шаблонів команд, ізолюючих клієнтський код від реалізації бізнес-сервісу. Крім того, описані інфраструктури виклику можна викликати з сполучного ПО EAI, і навпаки.


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


Характеристики Web-сервісів, JCA і JMS


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


Web-сервіси


Web-сервіс являє собою реалізацію сервіс-орієнтованої архітектури (Services Oriented Architecture, SOA). Архітектура SOA складається з трьох компонентів: постачальника, брокера і ініціатора запитів, слабо пов’язаних між собою. Постачальник пропонує бізнес-сервіс, який представляє собою конкретну реалізацію, яка для ініціатора запитів не є безпосередньо видимою. Ініціатор запитів отримує від брокера структуру інформації, яку він повинен використовувати для відправки та отримання від постачальника, і протокол, який необхідно використовувати для доступу до цього сервісу. Ініціатору запитів невідомий спосіб реалізації бізнес-сервісу постачальником.


Web-сервіси визначаються як обов’язковий бізнес-інтерфейс між ініціатором запитів і постачальником, а не як загальний канал для всіх бізнес-запитів. Web-сервіси мають кілька змінних характеристик, а саме:



JCA


Архітектура коннектора Java (Java Connector Architecture) задовольняє, головним чином, потреба в жорстко зв’язаному доступі до бізнес-логікою інформаційної системи підприємства (Enterprise Information Systems, EIS). Архітектура коннектора підтримує адаптацію ресурсів, при якій безпека, транзакції та комунікації J2EE перетворюються у відповідні технології EIS.


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


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


JMS


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


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


Незалежність ритмів роботи. Інфраструктури JMS працюють в асинхронному режимі, але пропонують також можливість імітації синхронного режиму запит / відповідь. Це дає можливість вихідної і цільової системі працювати одночасно, без вимушених очікувань протилежної системи.


Гарантія доставки інформації. Інфраструктури JMS можуть керувати повідомленнями в транзакційному режимі і гарантувати доставку повідомлень (але ніяких гарантій щодо своєчасності доставки не надається).


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


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


Вибір інтерфейсних технологій


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


У багатьох випадках самим природним способом доступу до інтегрованої інформаційної системи підприємства (EIS) CICS або IMS є використання архітектури коннектора Java (JCA). Навпаки, якщо вам необхідний доступ до додатків. NET, ви, ймовірно, виберете інтерфейс Web-сервісу. В будь-яких інших випадках, можливо, ви вирішите використовувати інтерфейс JMS, який дозволить здійснювати обмін повідомленнями з невеликими обмеженнями щодо мови реалізації.


Для прийняття рішень користуйтеся наступними орієнтирами:


У вас вже є прикладні Java-системи або ви плануєте впровадити подібну систему: Використовуйте JMS або JCA.


Необхідно організувати взаємодію з партнерами: Використовуйте для транспорту і підключення Web-сервіси.


Необхідно подолати мовний бар’єр: Використовуйте JMS або Web-сервіси.


Наступним важливим для прийняття рішення фактором є зона мережі Інтернет, інтранет або екстранет. Зона визначає, який ступінь гнучкості ви можете собі дозволити при виборі транспортного протоколу. Розгортання в мережі Інтернет, швидше за все, зажадає використання слабо пов’язаних через протокол HTTP Web-сервісів. Це буде мережа з уже наявними міжмережевим екраном та інфраструктурою демілітаризованої зони (DMZ); при цьому ви зможете мінімізувати витрати. JMS і JCA більше підходять як протоколів мереж інтранет або екстранет. JMS більше підходить для асинхронного режиму або імітації синхронного режиму, а JCA – для більш жорсткого зв’язку.


Що спільного у цих варіантів?


Web-сервіси – це не синонім сервісів, пропонованих через SOAP. Будь фрагмент коду з Web services Description Language (WSDL) можна вважати описом функцій і протоколів доступу до Web-сервісу. Для кожного такого сервісу можна передбачити доступ через кілька транспортних протоколів і протоколів прикладного рівня.


Отже, ви можете застосувати підхід на основі WSDL, який описується і реалізується інфраструктурою виклику Web-сервісів Web services Invocation Framework (WSIF). Це дозволить вам об’єднати ваші варіанти інтеграції незалежно від зони мережі – інтранет, екстранет або інтернет.


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



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


Використання підходу на основі WSDL для Web-сервісів надає можливість відокремити абстрактний інтерфейс від реального стека протоколів. Цей підхід можна реалізувати двома способами, кожний з яких використовує WSIF:



  1. За допомогою IBM Web services Gateway (WSGW) можна виконати розгортання існуючих описів WSDL і зробити їх доступними через SOAP-канали. Прив’язкою для вхідної інформації є SOAP, а для виходить інформації – існуюче опис реалізації WSDL;
  2. За допомогою програмного продукту IBM WebSphere Studio Application Developer Integration Edition (WSAD-IE) існуючі описи WSDL переробляються і стають доступними через модулі доступу SOAP або RMI-IIOP.

Шаблони взаємодій


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


Керована подіями модель доставки даних без запиту


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


Стандартні слухачі для бізнес-сервісів часто використовують сервери JMS або HTTP. Керовані подіями bean-компоненти в EJB використовують JMS, тоді як Web-сервіси використовують HTTP.


У цій моделі доставки даних без запиту доставляються події запускають процеси. Спільнота розробників і користувачів Web-сервісів виконало велику роботу по формалізації координації (хореографії) цього процесу взаємодії. Організацію даної послідовності подій, зокрема, описують стандарти Web services Flow Language (WSFL, мова потоків для Web-сервісів) і Business Process Execution Language for Web services (BPEL4WS, мова виконання бізнес-процесів для Web-сервісів).



Синхронний режим запит / відповідь


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


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


Асинхронна модель


Всі три інтерфейсні технології – Web-сервіси, JMS і навіть JCA – можуть працювати в асинхронному режимі. Запити чи події будуть в цьому випадку пересилатися цільовій системі; при цьому очікується одержання тільки наступного відповіді: “Повідомлення було доставлено коректно.” Цей стиль взаємодій відноситься до типу “запустив і забув”.


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


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


Документ-орієнтована модель є методом реалізації справді одностороннього взаємодії.


Вимоги та міркування при виборі технології


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


Слабка або жорстка зв’язаність


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


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


Слабосвязанних системи можуть бути організовані наступними способами:



Тепер ми визначимо, які з описаних технологій підходять для жесткосвязанних, а які – для слабосвязанних рішень.


JCA – це технологія для жесткосвязанних систем.



JMS – це метод для слабосвязанних систем. Наприклад, JMS не надає механізму безпеки або прив’язки транзакцій до цільових системам, тільки до сполучній ПО для обміну повідомленнями. Обмін повідомленнями, як правило, є слабосвязанних з наступних причин:



JMS добре підходить для наступних ситуацій:



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


У разі Web-сервісів зв’язаність заснована і на визначенні інтерфейсу, і на прив’язці протоколів.



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



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


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


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


Переносимість і функціональна сумісність


Web-сервіси не накладають обмежень на використання мов програмування або операційних систем між викликає і викликуваним компонентами. Ймовірно, в найближчому майбутньому будуть вирішені деякі проблеми SOAP, наприклад ліквідовані відмінності між реалізацією Apache та іншими реалізаціями. Після вирішення цієї проблеми всі платформи, що підтримують Web-сервіси, будуть функціонально сумісними (включаючи платформи . NET і J2EE). Але навіть у цьому випадку код клієнтської або серверної реалізації Web-сервісу не буде мати переносимостью між рішеннями різних виробників. Код реалізації, написаний для. NET, звичайно, не буде працювати в середовищі J2EE.


JMS і JCA призначені тільки для Java-середовищ. В JCA переносимість досягається на стороні клієнтського коду, а функціональна сумісність обмежується певної цільової платформою. JMS для забезпечення функціональної сумісності на технічному рівні необхідна наявність Java-середовища на обох кінцях, а проте робоче навантаження повідомлення є незалежною, тому JMS може нести робочі навантаження Web-сервісів JAXM, SOAP.


Підтримка транзакцій


JCA не у всіх випадках забезпечує наскрізну підтримку транзакцій для EIS. Як уже зазначалося раніше, постачальник коннектора реалізує контейнер, який передає контекст транзакції цільовим системам. Це здійснюється через контракт для систем управління транзакціями, в якому контейнер діє як диспетчер транзакцій, керуючий EIS як диспетчером ресурсів. Така поведінка засноване на стандарті XA (додаткову інформацію див у розділі Ресурси).


На даний момент Web-сервіси не забезпечують підтримку транзакцій. Розробники стандартів працюють над способами надання підтримки транзакцій в рамках слабосвязанной моделі, що відповідає стандартам WS-Coordination і WS-transaction. У майбутньому будуть доступні і слабозв’язаних модель з використанням компенсації, і жесткосвязанная модель з використанням XA-подібної моделі транзакцій.


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


Надійність


В даний час гарантія доставки забезпечується тільки через JMS (хоча щодо затримки повідомлення гарантії не надається). В майбутньому корпорації IBM, Microsoft, BEA і TIBCO планують спільну роботу по розробці стандартних механізмів для забезпечення безпеки обміну повідомленнями, надійності обміну повідомленнями у середовищі Web-сервісів. З цими стандартами можна ознайомитися на Web-сайті організації, займається розробкою Web-сервісів. Надійність підключень JCA завжди буде специфічною для кожного коннектора, тому JCA по суті своїй не передбачає забезпечення надійності.


Безпека


Безпека є найменш стандартизовану область. У специфікації JMS явним чином декларується, що безпека повинна забезпечуватися реалізацією постачальника JMS, яка повинна відповідати іншим стандартам J2EE. На щастя, IBM також дотримується цього стандарту. У разі JCA підтримка забезпечення безпеки буде залежати від функцій контейнера коннектора і цільової реалізації інформаційної системи підприємства.


Підтримка HTTPS може забезпечити певний рівень безпеки Web-сервісу на транспортному рівні. Однак після того, як Web-сервер дешифрує і аутентифікує запит, він виявляється вразливим, і тільки деякі реалізації Web-сервісів, які використовують розширення безпеки SOAP Security Extensions (SOAP-SEC), підтримують доступний на даний момент рівень безпеки. Роботи по стандартизації ведуться і для стандарту WS-Security, який в майбутньому має забезпечувати повну функціональну сумісність наскрізний моделі безпеки.


Висновок


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


У наступній таблиці узагальнюється все, сказане до цих пір, і підкреслюються критерії прийняття рішення:
































































  Web-сервіси  JMS  JCA  Примітки 
Зв’язаність інтерфейсу (абстрактне визначення сервісу) ТАК
Можливо динамічне виявлення інтерфейсу та проектування запиту
НІ
Незалежність робочого навантаження
ТАК ТАК означає жорстку пов’язаність
Технічна зв’язаність (стек протоколів) НІ
Завдяки WSIF клієнт не прив’язаний до клієнтської бібліотеці для конкретної реалізації протоколу
ТАК ТАК ТАК означає жорстку пов’язаність
Переносимість ТАК
Багатомовність
НІ
тільки Java-технології
НІ
тільки Java-технології
 
Надійність Прив’язка HTTP-R для SOAP ТАК Специфічна  
Підтримка транзакцій Планується в майбутньому
WS-Coordination проти WS-Transaction Compensation і XA-моделей
Обмежена по області дії
Тільки до точки входу в чергу
ТАК
XA-модель
 
Безпека Обмежена SOAP
SOAP-SEC, замінюється на WS-Security
Не є частиною стандарту, отже, специфічна для кожного виробника Інтеграція між EIS і J2EE  
Синхронний режим ТАК
Основне використання
Зробіть самі ТАК  
Асинхронний режим ТАК
Документ-орієнтований інтерфейс
ТАК Планується в майбутньому  
Керований подіями режим доставки повідомлень без запиту ТАК
Документ-орієнтований інтерфейс або підтримка потоків (WSFL, BPEL4WS)
ТАК Планується в майбутньому  



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


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

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

Ваш отзыв

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

*

*