Порівняння типів архітектури систем сервісів

This paper studies modern architectures of services systems SOA (service-oriented architecture) and EDA (event-driven architecture), their advantages and drawbacks, capabilities, and feasibility of constructing the unified service-oriented architecture EDSOA (event-driven service-oriented architectu...

Full description

Saved in:

Bibliographic Details
Date:	2015
Main Author:	Petrenko, О. О.
Format:	Article
Language:	Ukrainian
Published:	The National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute" 2015
Online Access:	https://journal.iasa.kpi.ua/article/view/59442
Tags:	Add Tag No Tags, Be the first to tag this record!
Journal Title:	System research and information technologies
Download file:

Institution

System research and information technologies

_version_	1867334257944297472
author	Petrenko, О. О.
author_facet	Petrenko, О. О.
author_institution_txt_mv	[ { "author": "О. О. Petrenko", "institution": "аспірант Навчально-наукового комплексу \"Інститут прикладного системного аналізу\" НТУУ \"КПІ\" МОН та НАН України, Київ" } ]
author_sort	Petrenko, О. О.
baseUrl_str	http://journal.iasa.kpi.ua/oai
collection	OJS
datestamp_date	2016-07-21T13:49:47Z
description	This paper studies modern architectures of services systems SOA (service-oriented architecture) and EDA (event-driven architecture), their advantages and drawbacks, capabilities, and feasibility of constructing the unified service-oriented architecture EDSOA (event-driven service-oriented architecture). It is shown that events connect services by transferring the state of a business process from one service, which define and publish events, to other services, which are started by actual events. In its turn, it is justified, that services unify events by transferring the data about moving one state of a process into another. In this work, a special attention is paid to questions related to an effective implementation of a proposed hybrid solution of architecture EDSOA and its application for modeling business processes as services.
first_indexed	2025-07-17T10:19:51Z
format	Article
fulltext	 О.О. Петренко, 2015 48 ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 УДК 004.046: 004.896: 004.942 ПОРІВНЯННЯ ТИПІВ АРХІТЕКТУРИ СИСТЕМ СЕРВІСІВ О.О. ПЕТРЕНКО Розглянуто сучасні архітектури систем сервісів SOA (service-oriented architecture — cервісно-орієнтована архітектура) й EDA (event-driven architecture - подійно-орієнтована архітектура), їх переваги і вади, можливість і доцільність побудови об’єднаної сервісно-орієнтованої архітектури EDSOA (event-driven service-oriented architecture — подійно-керована сервісно-оріентована архітектура). Показано, що події з’єднують сервіси за допомогою передачі стану бізнес-процесу від одного сервісу, який визначає і публікує події, до інших сер- вісів, які запускаються конкретними подіями. В свою чергу, обґрунтовано, що сервіси об’єднують події за допомогою передачі даних про перехід одного стану процесу в інший. Особливу увагу в роботі приділено питанням ефективної реалізації запропонованого гібридного рішення архітектури EDSOA до моделю- вання бізнес-процесів як сервісів. ВСТУП Нещодавно з ініціативи фірми IBM було сформовано науку про сервіси, ме- неджмент і SSME (service science management and engineering — наука про сервіси, менеджмент і інжиніринг), що покликана дослідити основні прин- ципи функціонування складних систем сервісів, шляхи створення, масшта- бування і вдосконалення таких систем. Варто особливо підкреслити, що роз- виток науки про сервіси спирається на два таких відомих технічних нововведення в інформаційних технологіях, як технологія SaaS, коли про- грамне забезпечення використовується і орендується через інтернет як хмарний сервіс, і SOA (service-oriented architecture — cервісно-орієнтована архітекту- ра) як базовий стиль архітектури у процесі проектування складних розподі- лених систем. Масштаб, складність і взаємозалежність сучасних систем сервісів у зв’язку з глобалізацією, демографічними змінами та технологічними роз- робками досягли безпрецедентного рівня. У найбільш розвинених країнах більше 70% ВВП формується індустрією сервісів, у якій на сьогодні зайнято (за інформацією Міжнародної організація праці) більше половини людства [1, 2]. Сьогоднішня глобальна економіка вимагає від компаній розширення своїх бізнес-процесів за межі організацій та інтеграції бізнесу з партнерами. Необхідність інтеграції та взаємодії додатків у рамках сукупності великої кількості інформаційних систем самого підприємства або кількох підпри- ємств, об’єднаних у цілий партнерський ланцюжок, також справляють істо- тний вплив на доцільний вибір архітектури систем сервісів. Поняття «сервіс» і «процес» є взаємозалежними і їх можна використо- вувати на різних рівнях узагальнення. Наприклад, невеликий процес може бути організований у вигляді окремого сервісу у тому випадку, якщо його можна типізувати. У той же час процес може бути розбито на окремі серві- си, що взаємодіють між собою в рамках процесу. Якщо сервісів буде дуже Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 49 багато, то не буде досягнуто необхідної типізації, але якщо сервіси будуть занадто високорівневими, то їх застосування буде ускладнено через специ- фічні відмінності у бізнес-процесах. Відображаючи логіку бізнесу у формі веб-сервісів, можна формувати потоки завдань (workflows), спеціально на- лаштованих з урахуванням потреб підприємства. Термін «сервіс» має два основних загально прийнятих значення: еко- номічне, бізнес-орієнтоване значення, наприклад, як у виразі сервісний сек- тор економіки, ІТ- орієнтоване значення, веб-сервіс або SOA. У першому випадку акцент робиться на взаємодію у процесі обміну і на нематеріальний характер сервісу, а у другому — на технології програмного забезпечення, яке дозволяє підтримувати сумісність різних програмних модулів або аген- тів. У сучасних систем сервісів для економіки два значення зливаються, оскільки впровадження сучасної системи сервісів передбачає також інтег- рацію інформаційних систем як підсистем організаційної системи систем. У той же час зростає сервісний домен з орієнтацією на сучасні виробничі процеси, наприклад, через «сервітизацію» виробництва [3]. Ці сервісно- орієнтовані процеси також сприяють інтеграції виробничих процесів з інфо- рмаційними системами і конкретними ІТ-технологіями. Більшість сучасних знань було розроблено в період виробничої еконо- міки, зокрема, в галузі систем управління технічними об’єктами за допомо- гою ІТ-технологій. Індустрія послуг потребує створення своєї наукової бази, розроблення методики й інструментарію для розроблення систем сервісів, розгортання підготовки відповідних кадрiв, спроможних забезпечити подальше поширення i зміцнення індустрії послуг. SOA SOA замість монолітної пропонує блокову систему із взаємодіючих компо- нентів, у якій різні функціональні модулі додатків (сервіси), призначено для управління бізнес-процесами, що пов’язані між собою за допомогою чітко визначених інтерфейсів. Інтерфейси самі по собі незалежні від оточення і платформи, і тому така модель отримала назву моделі «слабкого зв’язку». Фактично суть концепції SOA полягає в уніфікації та автоматизації бізнес- процесів за допомогою типових компонентів — сервісів (наприклад, веб- сервіси використовують один стандарт — розширювану мову розмітки XML). При цьому створення, впровадження або зміна бізнес-процесу є ком- поновкою (оркестровкою) раніше розроблених сервісів, призначених для автоматизації бізнес-функцій. Для бізнесу SOA означає збільшення задоволеності клієнтів, реальну гнучкість бізнесу, швидкий час виходу на ринок, простоту співробітництва і низьку вартість бізнесу. Для ІТ-організацій SOA означає більшу продуктив- ність, зниження витрат на ІТ за рахунок прискорення розробки додатків, більш м’якого повторного використання сервісів, більш високої якості додатків, і в цілому більш швидкого реагування на запити бізнес-клієнтів для поліпшення і модифікації системи. На додаток до цього існує можли- вість використання сервісів незалежних постачальників, що забезпечує ще більшу цінність SOA. Слово «гнучкість» часто згадується у ході обговорен- ня переваг SOA і може бути інтерпретовано, з одного боку, як можливість О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 50 змінювати бізнес-процеси відповідно до змін вимог ринку і вимог клієнтів і, з другого, як здатність виконувати бізнес-процеси швидше або запускати швидше нові процеси, продукти і сервіси. Гнучкість і швидкість — реальні й відчутні переваги переходу на SOA і багаторазове використання сервісів. SOA є архітектурним підходом, який дозволяє розкласти функціональ- ність додатків на множину сервісів, розміщених у мережі. Веб-сервіси є тех- нологію реалізації концепції дизайну SOA. Існує велика кількість дослі- джень, присвячених вимогам надійності в SOA і, більш конкретно, веб- сервісів. Веб-спільнота розробила ряд специфікацій, які підтримують надій- ний обмін повідомленнями, управлінням транзакціями, реплікаціями і безпекою. Сервіси взаємодіють один з одним за допомогою шаблону син- хронного запиту і відповіді, що забезпечує щільне зчеплення між компонен- тами системи (рис. 1). До базових принципів SOA треба віднести [4]:  Слабке зв’язування сервісів — одна з найбільших переваг SOA. Слабко зв’язані модулі мають кілька добре відомих залежностей, а тісно пов’язані модулі мають багато невідомих залежностей. У суперечність зі слабким зв’язком між сервісами і можливістю їх повторного використан- ня застосування сервісу може бути ґрунтовним і щільним.  Стандартизація — стандарти SOA відкриті в тому сенсі, що будь- який виробник програмного забезпечення має право використовувати ці стандарти у процесі розробки архітектури SOA. Крім того, процес створення та перегляду стандартів є більш-менш демократичним, де будь-яка зацікав- лена сторона має право брати участь у всіх засіданнях, які призводять до рішень про стандарт.  Модульність — SOA реалізує сервіси, що підтримують чітко визна- чені модульні бізнес-функцій та інформаційні процеси. Ці модулі можуть надалі бути використані повторно і бути частиною бізнес-процесу. Модуль- ність сервісів призводять до поділення додатків на безліч дрібних модулів. Кожен модуль відповідає за одну окрему функцію у додатку.  Скомпонованість — здатність ефективно складати сервіси є найваж- ливішою вимогою для досягнення деяких із найбільш фундаментальних ці- Рис. 1. Архітектура SOA, керована запитами, де 1– 9 — послідовність запитів Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 51 лей сервіс-орієнтованих застосувань. Сервіси, які складаються, здатні брати участь у якості ефективних модулів. Модульна сервісна структура дозволяє створювати нові інформаційні системи, про які розробники сервісів можуть не мати жодного уявлення під час проектування сервісів.  Повторюваність — повторне використання сервісів як основна час- тина аналізу обслуговування та процесів проектування систем сервісів. Згідно з цим принципом сервіс може бути використаний більш ніж за одним сцена- рієм у різних бізнес-процесах або інформаційних системах.  Відкритість — сервіси мають бути легко ідентифіковані й зрозумі- лі, щоб забезпечити можливість їх повторного використання. Тому у процесі проектування сервісів необхідно враховувати «якість доступу» до сервісів та їх індивідуальні властивості незалежно від того, чи вони зареєстровані в депозитарії, чи ні.  Абстракція — цей принцип підкреслює необхідність приховувати так багато з основних деталей сервісів, як це можливо. Це забезпечує безпо- середньо описане раніше слабке зв’язування сервісів.  Зв’язок «один-на-один» — один із конкретних сервісів викликається у часі тільки одним із споживачів, але зв’язок є двонаправленим.  Синхронність — відповіді на запити відправляються назад до спо- живача в синхронному режимі.  Запуск процесу — потік управління зініціюється клієнтом (спожива- чем послуг).  Зернистість сервісів — рівень деталізації обслуговування. Сервіси в SOA є модулями бізнес-логіки досить високого рівня, завдяки чому взаємо- дія між ними зводиться до обмеженого числа повідомлень за змістом бізнес- логіки замість безлічі низькорівневих викликів, що враховують деталі реалі- зації сервісів. Такий підхід знижує навантаження на мережу і сприяє більш високій продуктивності системи.  Відсутність стану — сервіси проектуються так, щоб залишитися зі станом тільки за необхідності. Сервісам не варто покладатися на тривалий зв’язок між споживачем і постачальником, вони не мають також покладати- ся на попередні виклики. Орієнтація на сервіси та SOA може краще використовувати тоді, коли процеси або їх частини є стандартними, коли вони часто повторюються без змін, або коли декільком користувачам потрібно той же компонент процесу для виконання своїх завдань. Виклик (споживання) сервісів у SOA реалізу- ється віддалено за допомогою віддаленого виклику процедури RPC (remote procedure call — віддалений виклик процедур) на вимогу споживача серві- сів. SOA добре зарекомендувала себе для побудови великих корпоративних програмних додатків. Ціла низка розробників та інтеграторів пропонують інструменти і рішення на основі SOA (наприклад, платформи Intel SOA Expressway, JBoss SOA Platform, IBM WebSphere, Software AG webMethods, Oracle , BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, TIBCO). Однак практичне застосування всього потенціалу SOA ускладнюється через часту необхідність використовувати окремі сервіси з несумісними ін- терфейсами. Крім того, у бажанні створення підприємств реального часу, які О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 52 постійно підключені й завжди доступні в інтернеті, організації стикаються з більш різноманітними бізнес-сценаріями і виявляють потреби в альтерна- тивних шаблонах проектування на доповнення до синхронної керованої за- питом SOA. EDA EDA (event-driven architecture — подійно-орієнтована архітектура) містить в собі три базові компоненти: генератор події (датчик), оброблювач події і менеджер подій (відповідач). Менеджер подій реєструє всі події, які вини- кають в системі (зовнішні і внутрішні), відповідним чином ідентифікує і пе- редає оброблювачу подій. Якщо потрібний оброблювач за яких-небудь при- чин не доступний, подія в залежності від конкретної реалізації або ставиться в чергу, або передається іншому оброблювачу. Завдяки такій схемі система стає максимально гнучкою і чутливою до змін інформаційного середовища — у разі виникнення принципово нової події досить підключити новий оброб- лювач, не зачіпаючи ядра системи. Подібні системи зазвичай будуються на тригерах, що реагують на певні події та ініціюють відповідні веб-сервіси, рис. 2 [5]. Обидві нові архітектури SOA й EDA відрізняються від традиційної ар- хітектури тим, що бізнес-процес розбивається на малі й повторно викорис- товувані процедури. Ці процедури формалізуються і реалізуються у вигляді ІТ-компонентів, які слабо пов’язані і можуть бути інтегровані в динамічний і гнучкий засіб. SOA і EDA намагаються замінити і розбити старі і великі ус- падковані системи й архітектури на більш гнучкі і багаторазово використо- вувані бізнес- та ІТ-компоненти. Співвідношення між SOA й EDA є актуаль- ною темою для обговорення. Споживачі і дослідники дотримуються протилежних думок з приводу того, як сервіси та події мають взаємодіяти на Подія Сервіс Сервіс Подія Подія Сервіс Подія Подія Сервіс Сервіс Сервіс Сервіс Подія Зовнішня система Шлюз Рис. 2. EDA архітектура з подіями Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 53 різних рівнях, включаючи бізнес, інформацію та інформаційні системи. До базових принципів EDA треба віднести:  Роз’єднаність — джерело події знає тільки створену подію і не має жодного уявлення щодо її подальшого оброблення заходу або про зацікав- лені сторони. Цей принцип використовується у ході інтеграції роз’єднаних додатків і бізнес-процесів. Процес складається з декількох етапів. У EDA етапи не залежать фізично або логічно один від одного, так що кожен може бути змінено, не викликаючи побічних ефектів, на інші, поки повідомлення щодо подій не змінюються.  Повторюваність — вирішальним фактором у проектуванні подій є те, що вони мають бути спроектованими таким чином, щоб відповідати не тільки нинішнім вимогам, а й майбутнім потребам і поза сферою викорис- тання. Події мають бути розроблені в загальному вигляді, який забезпечує їх повторне використання.  Повідомлення у режимі реального часу — технічна інфраструктура має підтримувати створення в режимі реального часу подій і їх доставку. Персонал інфраструктури забезпечує в режимі реального часу перетворення інформації в знання, а потім в інтелектуальні наступні дії.  Свобода діяти — повідомлення не вказує, які дії виконуватиме споживач події. Це звіт, а не вимога. Споживачу притаманна логіка, яка ви- значає, як він буде реагувати. Величезну кількість подій може бути вироб- лено, але тільки деякі з них будуть споживаними.  Зв’язок «один-до-багатьох» — на одну конкретну подію може від- гукнутися багато передплатників.  Асинхронність — підтримка асинхронних операцій через повідом- лення про події.  Запуск процесу — потік управління, який визначається одержува- чем, базується на розміщених подіях.  Відсутність стану компонентів обробки подій — компоненти об- роблення подій не мають стану, але сама подія буде мати стан, визначений у ній. Для оброблення подій та ініціалізації веб-сервісів можуть бути викори- стані три стратегії: проста, потокова і комплексна. Просте оброблення по- лягає в ініціалізації веб-сервісів по мірі реєстрації відповідних подій. Основна перевага такої системи — це робота в режимі реального часу. Мінус очевид- ний — не враховується фактор пріоритету. Потокове оброблення враховує існуючі залежності веб-сервісів і об’єднує кілька сервісів в один загальний потік. Цей підхід виправдовує себе в системах з великими накладними ви- тратами на пошук і отримання інформації з бази даних. І, нарешті, комплекс- не оброблення — це так зване управління за відхиленнями. Будь-яка подія розцінюється як вихід системи зі стану рівноваги. Ініціалізація веб-сервісів переслідує єдину мету — повернути систему в стан рівноваги (між справою задовольняючи потреби клієнтів системи). Новітній хмарний механізм оброблення подій CEP (complex event proc- essing — комплексне оброблення подій) знаходиться в експлуатації з 2007 року [6]. У ньому реалізовано такі методи, як виявлення складних візерунків багатьох подій, кореляції подій і абстракції, ієрархії подій і виявлення від- О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 54 носин між ними, таких як причинність, підпорядкованість, синхронізація зв’язку з процесами, пов’язаними з подіями. У той час як SOA і оркестру- вання автоматизують процеси, CEP автоматизує інтелектуальну кореляцію і співвідношення між рішеннями, прийнятими персоналом. Система CEP дозволяє користувачам оброблювати випадкові, не пов’язані події, визнача- ти тенденції і передбачати результати. Заходи можуть бути вжито для запо- бігання негативного наслідку від виникнення події. Шаблони реакцій також можуть бути проаналізовано, щоб поліпшити основні процеси та інформа- ційні системи з метою запобігання майбутніх помилок. Бізнес-аналітики та керівники середньої ланки добре розуміють проце- си, керовані подіями, оскільки вони пов’язані з стандартними бізнес- процедурами, такими як відносини замовника і постачальника, операційні процедури, процеси і потоки завдань. Переваги ведення бізнесу в режимі реального часу з EDA зрозуміло:  Рішення приймаються, а потреби користувачів відразу задовольня- ються.  Бізнес-процеси адаптується швидко, щоб задовольнити попит або вирішити проблему.  CRM (customer relationship management — управління відносинами з клієнтами), підтримка, маркетинг і навіть ланцюжки постачань, можуть бути миттєво змінено.  Весь бізнес можна розглядати в режимі реального часу для підви- щення ефективності підприємства. ПОРІВНЯННЯ АРХІТЕКТУР EDA Й SOA EDA й SOA можуть бути реалізовані і функціонувати паралельно без будь- яких суперечностей. Існує три основні передумови для цієї природньої спів- праці. Перша — це спільні та визначені бізнес-цілі, друга — використання роз’єднаних компонентів і спільної моделі даних, третя — використання спільної інфраструктури і технологій. EDA й SOA є взаємодоповнюючими у багатьох аспектах. Додавши EDA на вершину SOA архітектури, можна отримати нові можливості. Обидві архітектури SOA й EDA є досить новими концепціями і знаходяться на ранніх стадіях становлення. Багато компаній сьогодні здійснюють впровадження SOA та реалізацію очікуваних користі й цінностей [7]. EDA протягом багатьох років використовувалася як техніч- ний шаблон проектування, який забезпечує масштабованість і високу про- дуктивність транзакцій. EDA як бізнес-концепція та архітектурний стиль все ще є новою і не підтримується прийнятими платформами і методами проек- тування. Ще однією серйозною проблемою є управління подіями. Проведення порівняння EDA й SOA можна сьогодні лише на основі лі- тературних джерел, оскільки бракує інформації щодо практичного досвіду організацій, де EDA експлуатуються. Обидві SOA й EDA націлені на узго- дження бізнесу та ІТ-технології, але за допомогою різних засобів. У той час, як SOA використовує бізнес-сервіси, EDA використовує бізнес-події для подолання розриву між бізнесом та ІТ. Результати порівняння зведено в таб- лиці, де виділено три основні напрямки: відображення бізнес-процесів Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 55 і бізнес-функцій, використання даних та інфраструктури, здатність до інтег- рації. Т а б л и ц я . Порівняльний аналіз EDA і SOA SOA EDA Відображення бізнес-процесів і бізнес-функцій Є архітектурним стилем, який визнає серві- си (функціональність), що відображають етапи бізнес-процесу і які створюють більш високий рівень гнучкості бізнесу та ІТ-середовища Є архітектурним стилем, що визнає події (повідомлення), що відображають зміни стану процесу, на які бізнес реагує згідно з планом і які забезпечують більш високий рівень гнучкості бізнесу та ІТ-середовища Фокусування на декомпозицію бізнес- процесу на сервіси, які слабко пов’язані між собою Фокусування на виявленні бізнес-подій, які визначаються змінами в стані бізнес- процесу підприємства Заохочення до повторного використання сервісів (реактивність) Заохочення до обміну інформацією та ви- користання бізнес-аналітики (активність) Використання даних Дані запитується тими, хто зацікавлений у цій інформації Дані поширюється в режимі реального часу серед тих, хто зацікавлений у цій інформа- ції і підписався на неї Сприяє повторному використанню і спільному вживанню даних у різних дода- тках і для декількох каналів доступу кінце- вих користувачів Сприяє миттєвій ідентифікації та реагуван- ню на події / інформацію, що управляють бізнес-процесом Дані як сервіс є архітектурним підходом, що послаблює тісні зв’язки між даними додатками, так що дані можуть контролю- ватися і поділятися по всьому підприємству Надмірність даних необхідна для збільшення рівня декомпозиції бізнес-процесу Інфраструктура і здатність до інтеграції Застосовується поетапне розроблення і підтримка великих розподілених додатків Застосовується поетапне розроблення і підтримка великих розподілених додатків Застосовується шаблон «Запит / Відповідь» Застосовується шаблон «Публікація / Підписка» Сервіси викликаються незалежно від технології їх виготовлення та місця знаходження Події формують повідомлення, що відпра- вляються незалежним програмним модулям, які абсолютно нічого не знають один про одного Одночасно лише один із конкретних сервісів викликається одним споживачем (зв'язок «один-до-одного») На одну конкретну подію може відгукнутися багато передплатників (зв’язок «один-до-багатьох») Сприяє інтеграції шляхом впровадження стандартів і ведення кроків обгортки, на- шарування і композиції Сприяє інтеграції, оскільки на повідомлен- ня про події можуть підписатися всі зацікавлені й потім обирати необхідні з них Виведення може використовувати синхронні та асинхронні моделі Використовуються лише асинхронні моделі Таким чином обидві архітектури SOA й EDA забезпечують перехід ор- ганізації зі старою архітектурою бізнес-процесів, заснованою на підтримці незалежними монолітними прикладними додатками, до нового типу архітек- О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 56 тури, яка базується на незалежних сервісах і подіях, яка є більш динамічною і допускає багаторазове використання компонентів. Обидві парадигми ве- дуть до довгострокових інвестицій у різних галузях, де вони можуть прине- сти користь, наприклад, шляхом:  доповнення існуючих інформаційних систем і представлення їх як сервісів, тим самим збільшити рентабельність і продовжити термін викорис- тання спадщини, а також знизити витрати на розробку нової функціональ- ності;  використання існуючих сервісів і подій для підтримки нових бізнес- процесів, які можуть бути розгорнуті на ринку більш швидко і з більш низь- кою вартістю;  повторного використання інваріантних міжгалузевих сервісів і подій для декількох бізнес-процесів, підрозділів або підприємств, що може приве- сти до збільшення добутку, тобто кращого повернення від інвестиції. Подійно-керований шаблон EDA сприяє декомпозиції пов’язаної сис- теми (або бізнес-процесу) у порівнянні з вимогою слабко-пов’язаної систе- ми для SOA. Тобто функціональні процеси в системі відправника, де відбу- лася бізнес-подія, не залежать від наявності та завершення віддалених процесів в розподілених низькорівневих системах. У той час, як в архітекту- рі, керованій запитом, система відправника повинна точно знати, які розпо- ділені сервіси відгукуються на виклик, тобто залежить від наявності та завер- шення цих віддалених сервісів. Архітектура EDA, керована подіями, має значення тільки тоді, коли по- дії опубліковані, споживається і поширюється в режимі реального часу. Якщо цей підхід застосовується в пасивних сценаріях оброблення подій, наприклад, орієнтованих на фіксовану графіку, то його ефективність не ду- же відрізняється від традиційних методів інтеграції даних, що використову- ються сьогодні. EDA притаманна тісна інтеграція з бізнес-процесами, у той час як для SOA завжди слабким місцем були точки входу кінцевих користувачів в силу їх неоднорідності за безліччю параметрів. На думку деяких експертів, як тільки SOA стає тісно зав’язана на бізнес-процесах організації, вона переро- джується в подійно-керовану архітектуру і набуває не властиву статичним системам гнучкість й адаптивність. Головна складність у ході розробки по- дієво-керованих додатків — це гарантування, що всі оброблювачі подій бу- дуть завершуватися досить швидко, щоб не блокувалися системні виклики. Тобто не для всіх додатків ця архітектура підходить, але вона успішно може працювати, якщо в якості оброблювачів подій використовуються веб- сервіси. ОБ’ЄДНАНА АРХІТЕКТУРА СИСТЕМИ СЕРВІСІВ З порівняльного розгляду SOA й EDA очевидний тісний зв’язок між двома їх основними компонентами (подіями та сервісами). Дві основні відносини між EDA й SOA теж очевидні. У першому відношенні через події підклю- чаються сервіси за допомогою передачі стану процесу і даних від одного сервісу, який виявляє і публікує події, до інших сервісів, які запускаються Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 57 у процесі появи конкретних подій. У другому відношенні сервіси генерують події, переводячи бізнес-процес з одного стану в інший. Іншими словами, подія фіксує стан, а сервіс змінює стан. Взаємодія між SOA й EDA при цьому здебільшого відбувається на двох різних рівнях (рис. 3).  На першому рівні події з’єднують сервіси за допомогою передачі стану процесу від одного сервісу, який визначає і публікує події, до інших сервісів, які запускаються конкретними подіями.  На другому рівні сервіси об’єднують події за допомогою передачі даних про перехід одного стану процесу в інший (споживач отримує подію і вживає необхідні заходи, які можуть призвести до виклику нових сервісів і формування нових подій). Важливо також відзначити, що взаємодія між SOA й EDA також може відбуватися на рівні інформаційної системи, а не тільки на рівні бізнес- процесів. В об’єднаних SOA й EDA сервіси більше не є тільки споживачами подій. Зовнішні / внутрішні інформаційні системи можуть також вживатися і виробляти події. Об’єднання концепцій SOA й EDA, пропонується називати EDSOA (event-driven service-oriented architecture — подійно-керована сервісно- орієнтована архітектура). Тільки формування бізнес-сервісів і бізнес-подій, а потім їх цільова ув’язка для рішень завдань бізнесу дозволяє домогтися стратегічних переваг для підприємства. При цьому EDA використовується для того, щоб «накинути» на всю програмну інфраструктуру організації «ме- режу» програмних датчиків і програмних агентів, а також апаратних датчиків, які стежать за подіями у всіх апаратних і програмних компонентах, відсте- жують значущі для бізнесу події і передають їх у центр прийняття рішень із сигналами, що асоційовані з цими подіями. Це дозволяє технологічно управляти бізнесом не наосліп, а маючи чітку картину всього, що відбува- ється в конкретний момент на підприємстві. Рис. 3. Взаємодія SOA й EDA О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 58 Як було зазначено раніше, важливо аналізуючи відносини між EDA й SOA враховувати рівень деталізації (зернистості) полій і сервісів. У добре визначеній архітектурі рівень деталізації бізнес-подій збігається з зерни- стістю бізнес-сервісів. Хоча рівень деталізації обох сервісів та подій має ве- лике значення, поки не зовсім зрозуміло, як обрано потрібний рівень деталі- зації на етапі визначення сервісів і подій. І навіть менш очевидно поки, як переконатися, що сервіси і події вибрані на одному рівні. Якщо говорити про SOA й EDA конвергенцію, можна вважати най- більш зручним рішенням цієї задачі використання сервісної шини підприєм- ства ESB (enterprise service bus — сервісна шина підприємства), яка діє в якості проміжного шару (або посередника) для забезпечення комунікації та інтеграції великомасштабних гетерогенних прикладних процесів. ESB підтримує всі можливості: як SOA, так й EDA — оскільки підтри- мує синхронні, а також асинхронні взаємодії між однією або багатьох заці- кавлених сторін. Це не стандарт, ні специфікація, а, швидше, велика кіль- кість відкритих та комерційних ESB, які розроблялися багатьма постачальниками і налаштовані відповідно до їх потреб. До найбільш відо- мих реалізацій ESB можна віднести Open ESB [8], Apache ServiceMix [9], JBoss ESB [10], IBM WebSphere ESB [11], Celtix IONA й ObjectWeb [12]. Варто також звернути увагу на вільно поширювану шину Mule [13]. Як показано на рис. 4, ESB містить бізнес-процеси, сервіси та події, які споживаються або виробляються. Використання ESB в якості проміжного ПЗ забезпечує наступні групи сервісів [14].  Транспортування: транспортний сервіс гарантує доставку повідом- лень та їх обмін між різними прикладними процесами. В ESB можна засто- сувати динамічну маршрутизацію (також на основі змісту) і відправку запи- тів за декількома напрямками. Це дозволяє ESB балансувати навантаження або механізми відмовостійкості.  Оброблення подій: сервіс подій дозволяє ESB обробляти події, мож- ливо, аналізувати та контролювати складні серії взаємопов’язаних подій. Для цього, більшість продуктів ESB забезпечує реалізацію специфікацій, присвячених організації подій, таких як WS-Notification й WS-Eventing [15].  Оркестрування: цей сервіс засновано на використанні BPEL техно- логій [15] і дозволяє ESB організовувати виконання ряду взаємозв’язаних сервісів. Під час роботи з подіями на кожному етапі бізнес-процесу сервіси вищого рівня організують роботу сервісів нижчого рівня. Рис. 4. Среднемесячные числа Вольфа Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 59  Пошуку: цей сервіс, включений до ESB, сприяє тому, що прикладні процеси виявляють відповідні сервіси, з якими вони взаємодіють [16].  Посередництва: цей сервіс посередництва є фундаментальним для напрямку бізнес-інтеграції. Він відповідає за: перетворення одного протоко- лу зв’язку на інший для того, щоб зробити можливим спілкування між гетеро- генними середовищами; перетворення змісту будь-якого повідомлення, а та- кож збагачення повідомлення додатковою інформацією для того, щоб будь- які дані, що передаються, були зрозумілими для будь-якого прикладного додатку. Крім перетворень, сервіс є відповідальним за безпеку, яка має ви- рішальне значення в міжорганізаційних взаємодіях, за вимоги якості QoS (наприклад, вимірювань, кешування, виявлення відмови і наступне віднов- лення). Основні обмеження ESB пов’язані з їх застосуванням тільки в суворо контрольованих умовах, де адміністратори можуть правильно конфігурува- ти, розгортати і, нарешті, тонко налаштовувати проміжне ПЗ, щоб отримати максимальну продуктивність і максимальний рівень надійності. Як тільки взаємодії перетинають кордони контрольованого середовища (яке, можливо, охоплює кілька незалежних адміністративних доменів), можливості цих платформ можуть непередбачувано деградувати — і загальний рівень об- слуговування не буде більше легко керованим. ESB є посередником, який пов’язує сервіси разом. ESB може бути реа- лізована різними способами: за допомогою класичних повідомлень; EAI (enterprise application integration — інтеграція корпоративних додатків); брокерських технологій; шляхом використання конкретної платформи ком- понентів, наприклад, інтеграції шин у сервері додатків J2EE (java 2 enterprise edition — обчислювальна корпоративна платформа Java). ESB також може бути поєднанням обох EAI й технології серверів додатків, але реалізація не має впливати на загальну архітектуру. ESB виступає як інтелектуальний шар для підключення інформаційних систем, різних даних та інших сервісів, які зазвичай розподілено по всьому ІТ-середовищу підприємства. Вона поєднує в собі можливості синхронного та асинхронного обміну повідомленнями з можливостями інтелектуальних перетворень і маршрутизації. Це гарантує, що повідомлення передаються надійно. ESB дозволяє інтелектуальне оброблення запитів на обслуговуван- ня і відповідей, але також подій і повідомлень. ESB не є новим продуктом, а новою концепцію інтеграції інформацій- них систем, координації ресурсів та управління інформацією. На відміну від багатьох попередніх підходів до підключення інформаційних систем, ESB забезпечує підключення програмного забезпечення, яке працює на різних платформах, написаних на різних мовах програмування, і використовує різні технології. ESB є архітектурним шаблоном, який полегшує і спрощує біз- нес-інтеграцію через посередницькі й транспортні сервіси. Вона виступає посередником для всіх комунікацій та взаємодій між різнорідними вузлами, як у сервіс-орієнтованої архітектурі (синхронний підхід «один-до-одного»), так у подійно-керованій архітектурі (асинхронний підхід «багато-до- багатьох»). На сьогодні ESB є найбільш ефективним засобом вирішення складних проблем інтеграції та є технічним рішенням, яке забезпечує найбіль- шу гнучкість бізнесу й ефективне з’єднання між різнорідними додатками. О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 60 Варто визнати, що EDSOA дозволяє домогтися поставлених цілей тіль- ки в тому випадку, якщо:  в інформаційній системі компанії буде структуровано й оформлено програмні компоненти, що реалізують сервіси, важливі для бізнесу (SOA складова);  інформаційну систему буде насичено програмними датчиками, що формують значущі для бізнесу події (EDA складова);  оперативне прийняття управлінських рішень буде автоматизовано за схемою, у якій реакція на бізнес-подію викликає старт бізнес-процесу, який ініціює запит на бізнес-сервіси (концепція EDSOA). На завершення варто навести слова відомого в світі фахівця Юхима Натиса з компанії Gartner Research, який радить «розглядати SOA як довго- строкову програмну архітектуру та інженерну практику, що вимагає наявно- сті відповідних кваліфікованих кадрів, але не як спосіб вирішення поточних проблем департаментів інформаційних технологій. Великі вигоди вимага- ють великих інвестицій. Ухвалення бізнес-семантики для сервісів і додаван- ня інтегрованої підтримки бізнес-подій вимагає великих систематичних зу- силь, і ці кроки необхідні для реалізації потенційних можливостей архітектури бізнес-компонентів у всій її повноті» . ВИСНОВКИ SOA й EDA є новими поняттями для багатьох організацій і вимагають зміни менталітету і підходів як всередині бізнесу, так і в ІТ-середовищі. Наприклад, австралійська компанія Springboard Research, опитавши майже 3 тис. ІТ- керівників в Австралії, Індії, Китаї та Сінгапурі (аж ніяк не найвідсталіший регіон), встановила, що тільки 21% з них розуміють суть концепції SOA [17]. За традицією ІТ-додатки і процеси орієнтовано на використання перед- бачуваних і повторюваних подій. Коли ж відбуваються помітні події, які відрізняються винятковістю, то це створює складнощі для значної частини бізнесу. Це робить доцільним впровадження об’єднаної EDSOA архітектури як основної для побудови складних сучасних систем сервісів. Але недосвід- ченість розробників прикладних додатків у розробці систем, керованих по- діями, і труднощі в декомпозиції бізнес-процесів на окремі компоненти стримують у цей час широке застосування парадигми EDSOA. Тим не менш, є також обнадійливі ознаки зацікавленості великих ІТ-виробників у новій технології (IBM, Microsoft, Google, Oracle тощо), які розпочали дослідження підходів з усунення вказаних труднощів [18–24]. Дуже важливо правильно виділити частину бізнесу організації, якій бу- де користь від EDSOA. Цей крок вимагає формування архітектури підпри- ємства, де буде визначено сферу використання задіяних сервісів і подій. Біз- нес-сервіси і події мають бути об’єднані таким чином, щоб забезпечити гнучку реконфігурацію процедур оброблення, можливо, шляхом викорис- тання декількох реакцій на подію. Усі ці заходи вимагають нової компетенції. Визначені сервіси, події й архітектура інтегруються в складний бізнес- процес. Конвергенція SOA й EDA потребує розробки нових надійних інфра- структур проміжного ПЗ для реалізації складних сценаріїв прикладних до- Порівняння типів архітектури систем сервісів Системні дослідження та інформаційні технології, 2015, № 4 61 датків (наприклад, ланцюгів постачань, фінансових операцій). Ці підходи, будучи об’єднаними разом, можуть забезпечити використання їх взаємно додаткових характеристик. У цьому сенсі технології ESB можуть бути вико- ристані для реалізації конвергенції SOA й EDA. Однак відсутність стандарту й існування безлічі конкретних постачальників ESB реалізацій (чи комер- ційних, чи відкритих) ставить підприємства перед важким вибором ESB, яка найкраще підходить до конкретних конфігурацій розгортання бізнес- процесу. Це може негативно позначитися на гнучкості, яка забезпечується цими рішеннями і контентом вимог бізнесу. Крім того, існуючі ESB є складними продуктами, які вимагають вели- ких зусиль для конфігурації, розгортання і налаштування. Це пояснюється, очевидно, великими масштабами впровадження систем сервісів, неоднорід- ністю і сильною динамікою, яка характеризує намічені сценарії, де проміж- не ПЗ має охоплювати кілька незалежно керованих адміністративних доме- нів. З цього погляду теперішні ESB представляють собою досить статичні рішення, позбавлені гнучкості, яка може бути забезпечена за допомогою автоматичної конфігурації, самооптимізації, самостійної адаптації та само- захисту функціональності. Таким чином, бажано, щоб у майбутньому було здійснено заходи з удосконалення ESBS з метою досягнення нових рівнів гнучкості в складних умовах застосування в індустрії сервісів. ЛІТЕРАТУРА 1. Maglio P. Service systems, service scientists, SSME, and innovation // Communica- tions of ACM. — 2006. — 49, issue 7. — P. 81–85. 2. Петренко О.О. Объекты и методы науки о сервисах // Системні дослідження та інформаційні технології. — 2015. — № 2. — С. 75–82. 3. Succeeding through service innovation: A service perspective for education, re- search, business and government. — http://www.ifm.eng.cam.ac.uk/uploads/ Re- sources/Reports/080428cambridge_ssme_whitepaper.pdf. 4. Service Oriented Architecture: SOA Features and Benefits. — https://www. open- group.org/soa/source-book/soa/soa_features.htm. 5. A model-driven ontology approach for manufacturing system interoperability and knowledge sharing. — http://www.researchgate.net/profile/Keith_Case/ publica- tion/257001871_A_model-driven_ontology_approach_for_manufacturing_system _interoperability_and_knowledge_sharing/links/00b49530dc9487310e000000.pdf. 6. Esper: Event Processing for Java. — http://www.espertech.com/products/esper.php. 7. Industrial SOA. — http://www.oracle.com/technetwork/articles/soa/ind-soa-toc- 1934143.html. 8. Enterprise Integration EAI vs. SOA vs. ESB. — http://ggatz.com/images/Enterprise_ 20Integration_20-_20SOA_20vs_20EAI_20vs_20ESB.pdf. 9. Apache Software Foundation. — http://servicemix.apache.org/home.html. 10. BossESB. — http://www.jboss.org/community/docs/DOC-10326. 11. ESB: The SOA communication center. — http://www-01.ibm.com/software/ integra- tion/wsesb/. 12. Celtix: The Open Source Java Enterprise Service Bus. — http://celtix.objectweb.org. 13. Event-driven services in SOA: Design an event-driven and service-oriented platform with Mule. — http://www.javaworld.com/article/2072262/soa/event-driven- services-in-soa.html. О.О. Петренко ISSN 1681–6048 System Research & Information Technologies, 2015, № 4 62 14. Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus. — http://www.ibm.com/developerworks/library/ws-soa- eda-esb/. 15. OASIS Web Services Notification. — https://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=wsn. 16. OASIS Web Services Business Process Execution Language. — https://www.oasis- open.org/committees/tc_home.php?wg_abbrev=wsbpel. 17. EDA как очередная инкарнация SOA. — http://ecm-journal.ru/post/EDA-kak- ocherednaja-inkarnacija-SOA.aspx. 18. Advancing soa with an event-driven architecture. — http://www.intersystems.com/ assets/Ensemble_SOA-EDA-6a940c1315b29eec545fa18db122dd47.pdf. 19. New to SOA and web services. — http://www.ibm.com/developerworks/ webser- vices/newto/. 20. Mixing Event Driven Computing, SOA, BPM and BI for Instant Responsiveness. — http://www.ebizq.net/blogs/firstlook/2007/10/post_17.php. 21. Event-Driven SOA: Events Meet Services. — http://www.oracle.com/technetwork/ articles/soa/schmutz-soa-eda-405955.html. 22. SOA and BPM Are Better Together. — ftp://public.dhe.ibm.com/software/ eg/soa/garbetter.pdf. 23. Implementing an Event-driven Service-oriented Architecture in TIP. — http://www.cs.waikato.ac.nz/pubs/wp/2010/uow-cs-wp-2010-02.pdf. 24. Event-Driven Architecture and SOA — Allies or Enemies? — http://wis.vsb.cz/ekf/ php/tsw/getfile.php?prispevekid=935. Надійшла 31.08.2015
id	journaliasakpiua-article-59442
institution	System research and information technologies
keywords_txt_mv	keywords
language	Ukrainian
last_indexed	2025-07-17T10:19:51Z
publishDate	2015
publisher	The National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute"
record_format	ojs
resource_txt_mv	journaliasakpiua/13/1b742cc01dea0521cbd767ba8476a313.pdf
spelling	journaliasakpiua-article-594422016-07-21T13:49:47Z A comparison of architecture types of services Сравнение типов архитектуры систем сервисов Порівняння типів архітектури систем сервісів Petrenko, О. О. This paper studies modern architectures of services systems SOA (service-oriented architecture) and EDA (event-driven architecture), their advantages and drawbacks, capabilities, and feasibility of constructing the unified service-oriented architecture EDSOA (event-driven service-oriented architecture). It is shown that events connect services by transferring the state of a business process from one service, which define and publish events, to other services, which are started by actual events. In its turn, it is justified, that services unify events by transferring the data about moving one state of a process into another. In this work, a special attention is paid to questions related to an effective implementation of a proposed hybrid solution of architecture EDSOA and its application for modeling business processes as services. Рассмотрены современные архитектуры систем сервисов SOA (service-oriented architecture — сервисно-ориентированная архитектура) и EDA (event-driven architecture — событийно-ориентированая архитектура), их преимущества и недостатки, возможности и целесообразность построения объединенной сервисно-ориентированной архитектуры EDSOA (event-driven service-oriented architecture — событийно-управляемая сервисно-ориентированная ар-хитектура). Показано, что события соединяют сервисы посредством передачи состояния бизнес-процесса от одного сервиса, который определяет и публикует события, к другим сервисам, которые запускаются конкретными событиями. В свою очередь, обосновано, что сервисы объединяют события посредством передачи данных о переходе одного состояния процесса в другой. Особое внимание в работе уделяется вопросам эффективной реализации предложенного гибридного решения архитектуры EDSOA и его применению для моделирования бизнес-процессов как сервисов. Розглянуто сучасні архітектури систем сервісів SOA (service-oriented architecture — cервісно-орієнтована архітектура) й EDA (event-driven architecture - подійно-орієнтована архітектура), їх переваги і вади, можливість і доцільність побудови об’єднаної сервісно-орієнтованої архітектури EDSOA (event-driven service-oriented architecture — подійно-керована сервісно-оріентована архітектура). Показано, що події з’єднують сервіси за допомогою передачі стану бізнес-процесу від одного сервісу, який визначає і публікує події, до інших сервісів, які запускаються конкретними подіями. В свою чергу, обґрунтовано, що сервіси об’єднують події за допомогою передачі даних про перехід одного стану процесу в інший. Особливу увагу в роботі приділено питанням ефективної реалізації запропонованого гібридного рішення архітектури EDSOA до моделювання бізнес-процесів як сервісів. The National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute" 2015-12-15 Article Article application/pdf https://journal.iasa.kpi.ua/article/view/59442 System research and information technologies; No. 4 (2015); 48-62 Системные исследования и информационные технологии; № 4 (2015); 48-62 Системні дослідження та інформаційні технології; № 4 (2015); 48-62 2308-8893 1681-6048 uk https://journal.iasa.kpi.ua/article/view/59442/55314 Copyright (c) 2021 System research and information technologies
spellingShingle	Petrenko, О. О. Порівняння типів архітектури систем сервісів
title	Порівняння типів архітектури систем сервісів
title_alt	A comparison of architecture types of services Сравнение типов архитектуры систем сервисов
title_full	Порівняння типів архітектури систем сервісів
title_fullStr	Порівняння типів архітектури систем сервісів
title_full_unstemmed	Порівняння типів архітектури систем сервісів
title_short	Порівняння типів архітектури систем сервісів
title_sort	порівняння типів архітектури систем сервісів
url	https://journal.iasa.kpi.ua/article/view/59442
work_keys_str_mv	AT petrenkooo acomparisonofarchitecturetypesofservices AT petrenkooo sravnenietipovarhitekturysistemservisov AT petrenkooo porívnânnâtipívarhítekturisistemservísív AT petrenkooo comparisonofarchitecturetypesofservices

Порівняння типів архітектури систем сервісів

Institution

Similar Items