Integration and service composition based on model
In the paper we would like to introduce a frame- work for designing and developing Semantic Web Service application that integrates a several enterprises and composes results from a different services by applying techniques, methodologies and notations provided by Software Engineering and Business pr...
Збережено в:
| Дата: | 2022 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2022
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/498 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-498 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/0e/806030f13577f008f6f13ce00ab3d50e.pdf |
| spelling |
pp_isofts_kiev_ua-article-4982023-01-15T19:35:30Z Integration and service composition based on model Інтеграція та композиція сервісів на основі моделі Dyvak, Yu. Mamedov, T. Integrations of Program Systems; Web Service Composition; Business Process modeling; Semantic web services; Model Driven Design; Methodologies UDC 004.422 Інтеграція програмних систем;Композиція веб-сервісів; Моделювання бізнес процесів; Семантичні веб-сервіси; Розробка через моделювання; Методологія УДК 004.422 In the paper we would like to introduce a frame- work for designing and developing Semantic Web Service application that integrates a several enterprises and composes results from a different services by applying techniques, methodologies and notations provided by Software Engineering and Business process modeling. We propose to use existing business modeling techniques (BPMN, BPLWS, OWL-S, WSDL, WebML) for modeling the cross enterprise processes, for enterprise integrations and web service compositions. The main purpose is to designing and developing semantically rich Web applications, with semiautomatic defining semantic descriptions from the business process model that increase the efficiency of design and decrease the extra work necessary for processing semantically annotated information which passing through the enterprises.Problems in programming 2022; 2: 37-46 У цій роботі я хотів би представити новий підхід для розробки застосунку і архітектури для роботи із семантичними веб-сервісами, який інтегрує декілька інтерпрайзів та поєднує результати з різних сервісів через застосування технік, методологій та анотацій. Підхід формулюється разом із розробкою програмного забезпечення та моделюванням бізнес процесів. Ми пропонуємо застосовувати існуючі техніки моделювання бізнес процесів (BPMN, BPLWS, OWL-S, WSDL, WebML) для моделювання процесів, які проходять через декілька застосунків, для інтеграції програмних систем та веб-сервіс композиції. Головна мета - знайти методологію для розробки семантично багатих веб-застосунків із напівавтоматичним визначенням семантичного опису сервісу з моделі бізнес процесів. Це підвищить якість проєктування та зменшить обсяг додаткової роботи у розробці застосунків з обробкою семантично анотованої інформації, що проходить через підприємства.Problems in programming 2022; 2: 37-46 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2022-09-26 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/498 10.15407/pp2022.02.037 PROBLEMS IN PROGRAMMING; No 2 (2022); 37-46 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2022); 37-46 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2022); 37-46 1727-4907 10.15407/pp2022.02 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/498/496 Copyright (c) 2022 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2023-01-15T19:35:30Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
Integrations of Program Systems Web Service Composition Business Process modeling Semantic web services Model Driven Design Methodologies UDC 004.422 |
| spellingShingle |
Integrations of Program Systems Web Service Composition Business Process modeling Semantic web services Model Driven Design Methodologies UDC 004.422 Dyvak, Yu. Mamedov, T. Integration and service composition based on model |
| topic_facet |
Integrations of Program Systems Web Service Composition Business Process modeling Semantic web services Model Driven Design Methodologies UDC 004.422 Інтеграція програмних систем;Композиція веб-сервісів Моделювання бізнес процесів Семантичні веб-сервіси Розробка через моделювання Методологія УДК 004.422 |
| format |
Article |
| author |
Dyvak, Yu. Mamedov, T. |
| author_facet |
Dyvak, Yu. Mamedov, T. |
| author_sort |
Dyvak, Yu. |
| title |
Integration and service composition based on model |
| title_short |
Integration and service composition based on model |
| title_full |
Integration and service composition based on model |
| title_fullStr |
Integration and service composition based on model |
| title_full_unstemmed |
Integration and service composition based on model |
| title_sort |
integration and service composition based on model |
| title_alt |
Інтеграція та композиція сервісів на основі моделі |
| description |
In the paper we would like to introduce a frame- work for designing and developing Semantic Web Service application that integrates a several enterprises and composes results from a different services by applying techniques, methodologies and notations provided by Software Engineering and Business process modeling. We propose to use existing business modeling techniques (BPMN, BPLWS, OWL-S, WSDL, WebML) for modeling the cross enterprise processes, for enterprise integrations and web service compositions. The main purpose is to designing and developing semantically rich Web applications, with semiautomatic defining semantic descriptions from the business process model that increase the efficiency of design and decrease the extra work necessary for processing semantically annotated information which passing through the enterprises.Problems in programming 2022; 2: 37-46 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2022 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/498 |
| work_keys_str_mv |
AT dyvakyu integrationandservicecompositionbasedonmodel AT mamedovt integrationandservicecompositionbasedonmodel AT dyvakyu íntegracíâtakompozicíâservísívnaosnovímodelí AT mamedovt íntegracíâtakompozicíâservísívnaosnovímodelí |
| first_indexed |
2025-07-17T09:35:44Z |
| last_indexed |
2025-07-17T09:35:44Z |
| _version_ |
1850412848340008960 |
| fulltext |
37
Програмування для комп’ютерних мереж та Інтернет
Вступ
Працюючи інтеграційним інжене-
ром і інтегруючи застосунки з усього сві-
ту, я виділив декілька проблем, з якими
мав справу щодня. Серед них інтеграція
двох незалежних застосунків між собою,
інтеграція веб-сервісів із застосунками,
і композиція веб-сервісів для отримання
більш відповідного результату за мен-
ший проміжок часу. Звісно, ці проблеми
можна розглядати і вирішувати окремо
одна від одної, але, якщо розглядати їх
разом, можна знайти нові шляхи вирі-
шення. Дана стаття – це спроба знайти
новий підхід для вирішення поставле-
них задач.
Усі аспекти корпоративного світу
розроблені на основі бізнес-процесів, і
часто ці бізнес-процеси проходять через
декілька корпоративних застосунків,
а іноді ці застосунки належать різним
вендорам. Робота через декілька засто-
сунків потребуе асинхронного зв′язку
між ними і здійснюється за часто змі-
нюваними сценаріями. Такі інтеграційні
рішення, як описані в [1] : Файл транс-
фер, Спільна база данних, Віддалений
виклик процедур та Надсилання пові-
домлень – це опис підходів у загально-
му плані, конкретні реалізації інтегра-
цій. Такі, зокрема, як мости, інтеграція
через дані, надсилання повідомлень,
інтеграція на рівні компонентів, ін-
теграція через інтерфейси, брокери,
(ESB) enterprise service buses, інте-
граційні сервери та інтеграційні архі-
тектури. Всі вони мають обмеження та
застосовуються в конкретних зважених
випадках. Якщо ми хочему обійти деякі
обмеження ми можемо застосувати се-
мантичні веб сервіси, саме семанти-
ка дозволить обійти деякі обмеження.
Семантичні веб сервіси - це парадигма
програмування яка базується на анотації
процесів та само-описуючої реалізації,
яка може бути застосована для побудо-
ви крос-корпоративних за стосунків, що
вирізняються гнучкістю, автоматич-
ним виявленням ресурсів, та динаміч-
ним розвитком застосунку. Одна з най-
важливіших задач це адаптувати семан-
тичні технології та семантичні анотації
до вже розроблених коммпонентів та
застосунків. Напівавтоматичний підхід
може бути застосований для виділення
семантичного опису веб-сервісів.
Запропонований підхід базуєть-
ся на принципах розробки за стосунків,
які працюють на основі моделей. Це
означає, що спочатку ми маємо тіль-
ки модель, а згодом на основі цієї мо-
УДК 004.42 http://doi.org/10.15407/pp2022.02.037
Ю. Дивак, Т. Мамедов
ІНТЕГРАЦІЯ І КОМПОЗИЦІЯ
ВЕБ-СЕРВІСІВ НА ОСНОВІ МОДЕЛІ
Анотація. В цій роботі я хотів би представити новий підхід для розробки застосунку і архітектури для
роботи із семантичними веб-сервісами який інтегрує декілька корпоративних застосунків та поєднує
результати з різних сервісів через застосування технік, методологій та анотацій, забезпечених техноло-
гіями розробки програмних систем і моделюванням бізнес-процесів. Я пропоную застосовувати існу-
ючі техніки моделювання бізнес-процесів (BPMN, BPLWS, OWL-S, WSDL, WebML) для моделювання
процесів, які проходять через декілька застосунків, для інтеграції програмних систем та композиції
веб-сервісів. Головна мета - знайти методологію для розробки семантично багатих веб-застосунків з
напівавтоматичним визначенням семантичного опису сервісу для моделі бізнес процесів. Це підви-
щить якість проєктування та зменшить обсяг додаткової роботи при розробці застосунків з обробкою
семантично анотованої інформації, що проходить через корпоративні застосунки.
Ключові слова: Інтеграція програмних систем, Композиція веб-сервісів, Моделювання бізнес-проце-
сів, Семантичні веб-сервіси, Проєктування, засноване на моделюванні, Методології
© Ю. Дивак, Т. Мамедов, 2022
ISSN 1727-4907. Проблеми програмування. 2022. № 2
38
Програмування для комп’ютерних мереж та Інтернет
делі застосунок будує схему виконання
процесів, в якій будує композицію веб-
сервісів, шукаються описи веб-сервісів
у спеціальних репозиторіях. Далі згідно
зі схемою виконуються запити до веб-
сервісів, збираються і компонуються
прийнятні відповідно до критеріїв ре-
зультати. Результат отримує користувач
програмної системи. Інший підхід, по-
будований на основі роботи з моделлю
процесів, описаний в [2] і [4], пропону-
ється для додаткового вивчення.
Під час розробки нового підходу
треба реалізувати декілька аспектів про-
єктування:
• Розробка продукту, який працює
на вищому рівні абстракції глобальної хо-
реографії веб-сервісів для взаємодії між
застосунками і веб-сервісами.
• Робота згідно із запропонованою
бізнес-моделлю. Модель не прив’язана
до конкретних сервісів чи компонентів.
Опис композиції веб-сервісів, забезпече-
ний за допомогою анотацій, дає додатко-
вий рівень абстракції моделі.
• Архітектура пропонує рішення
для роботи декількох корпоративних за
стосунків, працюючих одночасно.
• Архітектура пропонує рішення
для роботи з декількома веб-сервісами чи
акторами.
Приклади застосування
У цій статті ми спробуємо застосу-
вати такий підхід до реального випадку,
де ми маємо за стосунок, який працює із
сервісами. Цей застосунок має комбінува-
ти результати виконання декількох серві-
сів в одну задовільну відповідь кінцевому
користовачеві згідно з наданої бізнес-мо-
делі. В загальному плані композиція ви-
глядає, як на рисунку 1.
Схема запитів на рисунку 2 пока-
зує взаємодію між сервісами та місьця,
де запит може бути перервано. Під час
дослідження ми маємо брати до уваги,
що наша система не повинна обмежува-
тися тільки двома взаємодіючими сер-
вісами. Вона має працювати із сотнями
і тисячами різних сервісів, налаштову-
вати взаємодію правильно та підбирати
найбільш відповідні сервіси для компо-
зиції та об’єднувати результати їх вико-
нання.
Ми можемо застосувати однако-
вий підхід для будь-якого випадку, де нам
потрібна композиція декількох сервісів.
Другий приклад, зображений на рисунку
3 та 4, описує композицію сервісу броню-
вання квитків на літак і бронювання но-
мера в готелі.
Загальні принципи
побудови системи
У загальному прикладі SOAP архі-
тектури ми маємо декілька рівнів:
Рівень користувачів сервісів – в на-
шому конкретному випадку користувачі
сервісів - це за стосунки, розроблені різ-
ними способами (B2B, Portals, .NET, JS,
Java, Salesforce, Microsoft Dynamics CRM,
etc.), які користуються сервісами через
медіатор і отримують скомпонований ре-
зультат виконання запиту з декількох сер-
вісів. Це можуть бути як портали, готові
рішення на основі CRM систем, або на-
писані програми, які можуть бути взагалі
без серверної частини і забезпечувати до-
Рисунок 1. Схема композиції сервісів (приклад 1)
39
Програмування для комп’ютерних мереж та Інтернет
Рисунок 2. Схема виконання (приклад 1)
Рисунок 3. Схема композиції сервісів (приклад 2)
40
Програмування для комп’ютерних мереж та Інтернет
ступ через медіатор до сервісів через роз-
роблений UI, або системи, в яких тільки
частина серверного застосунку замінена
на роботу через медіатор із зовнішніми
сервісами.
Рівень бізнес-процесів – В нашо-
му конкретному випадку це документ
(скрипт, модель бізнес-процесів, BPEL
процеси), який описує бізнес-процеси в
семантичній манері. Ми отримуємо цей
документ від клієнта і згідно з ним забез-
печуємо композицію сервісів і поверта-
ємо задовільний результат. Клієнт може
не турбуватися про пошук і композицію
свервісів, про все піклується медіатор.
Рівень сервісів (композиція) – в на-
шому випадку ми маємо сховище, або де-
кілька окремих сховищ, де зберігаються
описи сервісів в форматах: WSDL, XML,
SCHEMA, або WS-Policy. Сховища для
описів сервісів можуть бути різні. Напри-
клад, файлове сховище, SQL, або NoSQL
база даних, UDDI репозиторії, де збері-
гається необмежена або обмежена кіль-
кість описів для сервісів, які ми можемо
використовувати. Медіатор підключений
до сховищ і здійснює пошук у сховищах
сервісів, які найбільш відповідають опи-
сові сервісу в документі [4].
Рівень компонентів та операційних
систем – цей рівень виходить за межі до-
слідження в цій статті і реалізація покла-
дається на розробників сервісів.
Агрегатори – це за стосунки, які
компонують результати виконання запи-
тів у декілька сервісів, зазвичай служать
спільній меті - комбінувати відповіді з
декількох сервісів та трансформувати
в загальну відповідь, яка підходить для
кінцевого користувача. Зокрема, це може
бути пошук певного продукту та додат-
кової інформації про нього. Водночас ми
повинні агрегувати результати з різних
сервісів (онлайн-магазинів) та комбіну-
Рисунок 4. Схема виконання композиції (приклад 2)
41
Програмування для комп’ютерних мереж та Інтернет
вати їх в якусь структуровану відповідь.
Інший агрегатор може знаходити рейси
літаків від різних компаній, номери різ-
них готелів та сортувати за прийнятною
ціною або за датами, чи пересадками та
поєднувати рейси з доступними номера-
ми в готелях. Це все збирається та компо-
нується у відповідний формат, зрозумі-
лий кінцевому користувачеві (кінцевим
користувачем в нашому прикладі є так
само застосунки).
Агрегатори в свою чергу не мо-
жуть забезпечити дослідження простору
інтернету для виявлення нових сервісів
та використання їх у системі. Для цьо-
го інснують спеціальні кравлери, такі ж,
що використовуються, наприклад Гуглом
для індексації веб-сторінок. У нашій сис-
темі може використовуватися кровлер,
що збирає описи сервісів, а також ми
можемо використовувати сховище, нала-
штоване вручну.
У цій статті ми поговоремо про де-
кілька компонентів і розробок щодо по-
будови посередника, який може викорис-
товуватися замість частини бекенду.
Медіатор під’єднаний до сервісів
або апішок та отримує дані, що відпові-
дають переданим параметрам. Однак тут
маємо проблему: якщо один сервіс стає
недоступним, ми не можемо отримати
з нього відповідь. Тому медіатор може
отримати дані з інших сервісів, система
динамічна.
Витрати на розробку сервісів або
інтеграцій з уже існуючими сервісами,
можуть бути знижені завдяки такій сис-
темі, адже вона може взяти на себе час-
тину роботи з динамічної композиції веб-
сервісів.
За основу для нової архітекту-
ри системи для інтеграції із сервісами і
композиції веб-сервісів взято стандартну
архітектуру SOAP за стосунку, яка зобра-
жена на рисунку 5, і перероблено згідно з
нашими вимогами до системи.
Вже існує схоже рішення і розроб-
ка схожого за стосунку, який забезпечує
композицію сервісів. Цей застосунок
розроблявся 2013 року групою дослідни-
ків, і принципи його роботи описані в [5].
Архітектуру системи iServe зображено
на рисунку 6.
Проблеми
Маємо зважати на проблеми, що
виникають під час розробки подібних
систем, які стосуються виконання, проєк-
тування та розробки системи.
Під час виконання ми можемо
стикнутися з такими проблемами як: До-
ступність сервісу; надійність системи,
Рисунок 5. SOAP Архітектура
42
Програмування для комп’ютерних мереж та Інтернет
довговічність (як довго ми можемо її
використовувати), масштабованість,
зручність використання, безпека, мож-
ливість налаштування, продуктив-
ність, обмеження.
Під час проєктування і розробки
маємо інші проблеми: можливість по-
вторного використання, розширюва-
ність, портативність, сумісність, мо-
дульність, тестованість, локалізація та
інтернаціоналізація.
Затримки
У подібних системах, де існує
декілька компонентів, які взаємодіють
через протокол HTTP, цей протокол є
найслабшим місцем. Навантаження на
систему може перевищити допустимі
ліміти пропускання даних, що призведе
до затримки відповіді на запити. Вирі-
шенням такої проблеми може бути робо-
та декількох таких систем одночасно на
кількох серверах і балансування запитів
між застосунками за допомогою напри-
клад NGINX або на рівні застосунків
(балансування між застосунками від-
бувається на рівні компонентів). Можна
також мати систему яка буде автоматич-
но збільшувати кількість застосунків і
серверів залежно від навантаження сис-
теми. Позаяк наша система складається
з декількох компонентів, то їх можна
запускати на окремих серверах, тим са-
мим розподіляти навантаження між сер-
верами.
Також можна розбивати нашу ком-
позицію на загальні частини і тоді ре-
зультати виконання деяких частин, які
використовуються найчастіше, зберігати
в кеші застосунку для прискорення до-
ступу до результатів виконання (Таким
чином ми можемо отримати композицію
композицій веб-сервісів).
Надійність
Інша проблема може виникнути,
якщо один з сервісів, опис якого зберіга-
ється в сховищі, стає недоступним. Мож-
ливий випадок, коли ми безмежно довго
чекаємо на відповідь сервісу. Але в нашо-
му випадку медіатор автоматично переві-
ряє доступність сервісів для композиції.
Якщо ж сервіс недоступний – шукає за-
міну з інших описів сервісів, які зберіга-
ються в сховищі.
Відповідність результату
Проблема відповідності полягає в
тому, чи відповідає результат виконання
композиції тим параметрам і вимогам,
які ставить користувач системи. Відпо-
відність повністю лягає на бік медіатора.
Для забезпечення більшої відпо-
відності результату виконання компози-
ції вхідним параметрам, в нашій систе-
мі не потрібно кешувати окремі запити
Рисунок 6. iServe архітектура
43
Програмування для комп’ютерних мереж та Інтернет
до сервісів, бо нам потрібна тільки ак-
туальна інформація, і ми легко можемо
замінити один сервіс іншим у побудові
маршруту, один результат виконання за-
міниться іншим.
Кешування може бути корисним,
якщо ми хочемо прискорити виконання
композиції. До прикладу, ми можемо збе-
рігати на рівні кеша застосунку певну вже
готову композицію і повертати результат
виконання з кеша, водночас оминаючи
повторну композмцію 2 - 3 - 4 сервісів
(Композиція композицій).
Доступність
Інша проблема полягає в тому, що
всі сервіси різні, і ми мусимо по-різному
з ними взаємодіяти. Вирішенням може
бути – взаємодія через єдиний інтерфейс,
що забезпечить взаємозаміну сервісів ін-
шими, зручність взаємодії із сервісами, у
разі, якщо їх велика кількість і є швидкий
перехід від одного сервісу до іншого.
В єдиному інтерфейсі також має
бути передбачатися можливість перевір-
ки сервісу на доступність і маркування
його як недоступний або доступний, і пе-
ріодичну перевірку доступності сервісів.
Компоненти
1. Користувачі сервісів
Найпростішим користувачем сис-
теми може бути звичайна HTML сторін-
ка, що автоматично надсилає стандарти-
ний документ, який описує бізнес-про-
цеси і композицію сервісів та написа-
ний, наприклад, за допомогою BPLWS
або OWL-S (модель бізнес-процесів)
до нашої системи. Цей документ отри-
мує відповідь і рендерить її на сторінці.
Основна задача документу, який ми над-
силаємо до медіатора - це опис станів,
умов та параметрів для сервісів. За до-
помогою цього підходу ми зберігаємо
час на розробку взаємодії із сервісами
і доручаємо всю роботу медіатору. Той
робить композицію в автоматичному
режимі, повертаючи клієнту результат,
який відповідає переданим параметрам.
Обов’язковою є фронт-енд частина, коли
клієнт може обійтися без серверної час-
тини застосунку.
2. Модель бізнес-процесів
Документ (Execution script), який
передається від клієнта до медіатора. Во-
чевидь цей документ - звичайний тексто-
вий файл, складений за допомогою пев-
них правил і принципів, в якому є пара-
метри такі, як передумови та умови, пере-
вірки, сутності та моделі даних.
У цьому документі ми можемо опи-
сати дані (Модель даних), очікуючи, що
вони будуть повернуті з медіатора до клі-
єнта, а також які між ними зв′язки.
3. Медіатор
Медіатор приймає запити від клі-
єнтів, контролює вхідні параметри, під-
бирає потрібні сервіси за параметрами,
складає маршрут виконання композиції
та виконує запити, компонує результат
і відповідає клієнту. Це центральний і
найважливіший компонент нашої систе-
ми, який отримує багато запитів на ком-
позицію, працює зі сховищами описів
сервісів, перевіряє сервіси на доступ-
ність та працює із сервісами, збираючи
відповіді. Коли медіатор парсить доку-
мент розбираючи всі вхідні і визідні па-
раметри сервісів, він підбирає сервіси з
бази і знаходить найкоротші маршрути.
Медіатор у постійному контакті із сер-
вісами.
Ми можемо маніпулювати пара-
метрами також на рівні побудови марш-
руту для отримання найкращого резуль-
тату (преобробка), та обробляти дані,
отримані із сервісів вже згодом (посто-
бробка) таким чином досягяючи найкра-
щого результату виконання композиції.
Важливо чітко розуміти, який резуль-
тат ми хочемо отримати, який результат
композиції для досягнення більш точ-
ного результату. Це дозволить підібра-
ти відповідні сервіси з більш надійни-
ми результатами, скласти більш вдалий
маршрут виконання композиції сервісів,
а на етапі пост обробки - узагальнити
результати так, щоб задовольнити вимо-
ги клієнтів застосунку.
4.Сховище описів сервісів
Опис веб сервісу може зберігати-
ся по-різному. Наприклад, це може бути
44
Програмування для комп’ютерних мереж та Інтернет
Рисунок 7. Взаємодія медіатора з сервісами
р
файлове сховище, де зберігаються тек-
стові документи у форматі WSDL (як
зроблено частково в застосунку iServe
[5]) з описами сервісів. Це можуть бути
описи, які зберігаються в реляційній
базі даних, з якої ми отримуємо опис в
зібраному вигляді з декількох таблиць.
Це може бути також документоорієн-
тована база, яка використовує JSON як
документ (NoSql). Описи зберігають ін-
формацію про ендпоінти, URLs, вхідні
параметри сервісу, вихідні параметри
сервісу, кондішени та прекондішени,
моделі тощо. Також ми можемо викорис-
товувати UDDI репозиторії як сховища
для описів сервісів (як зроблено частко-
во в застосунку iServe[5]), публічні або
приватні репозиторії. В цьому випадку
наш медіатор стає користувачем репози-
торію [3].
5. Веб-кравлер
Що ж до веб-кравлера, ми має-
мо на увазі окремий за стосунок, який
в автоматичному режими здійснює по-
шук мережею інтернет доступних веб-
сервісів. Прикладом застосування та-
кого типу систем є індексація гуглом
сторінок в інтернеті. Таким чином наша
база даних описів веб-сервісів для по-
дальшої взаємодії може весь час допо-
вннюватися, а це забезпечить кращий
результат виконання композиції і вза-
ємодії із сервісами.
Архітектура
На рисунку нижче ми можемо ба-
чити, як виглядає вся система в загаль-
ному плані. Всі компоненти системи
працюють разом у тісній взаємодії для
досягнення єдиного результату. А саме:
Рисунок 8. Взаємодія медіатора з репозиторіями і конкретним сервісом
45
Програмування для комп’ютерних мереж та Інтернет
збір даних із зовнішніх джерел, компо-
зиція результатів виконання сервісів та
конструювання загального результату
виконання композиції, який відповідає
вхідним параметрам і вимогам для ре-
зультату. Одна з основних переваг такої
системи - це (як ми бачимо на рисунку
10) гнучкість. Усі компоненти працю-
ють незалежно і можуть бути покращені
откремо один від одного без втручання
у роботу інших компонентів. Клієнти
застосунку можуть бути розроблені за
допомогою будь-якої з відомих техно-
логій розробки і проєктування програм-
них систем.
Висновок і майбутня праця
Нова архітектура може допомог-
ти кінцевим користувачам отримати
кращий результат за коротший проміж-
ок часу і водночас значно скоротити
витрати на розробку окремих компо-
нентів, інтеграції та композиції серві-
сів. Цей підхід покращує вже існуючі
підходи до композиції веб-сервісів й
інтеграції із зовнішніми сервісами, а
також дає можливість застосувати до
цієї архітектури принципи антології
(тому що інтеграція і композиція за-
снована на моделі). Наступні роботи
будуть пов′язані із конкретною реа-
лізацію медіатора і застосування ал-
горитмів для отримання кращого ре-
зультату композиції та інтеграції, що
забезпечить підвищення продуктив-
ності та покращить інші характерис-
тики системи. Ми спробуємо виміряти
продуктивність системи із застосуван-
ням різних підходів до композиції і
оберемо найкращий варіант реалізації
медіатора.
Алгоритми, які можуть бути засто-
совані при композиції веб-сервісів в рам-
ках цієї архітектури.
• Єврестичні алгоритми пошуку,
• A* Алгоритм,
• Мурашиний алгоритм,
• Генетичний алгоритм,
Рисунок 9. Додатковий веб-кровлер для автоматичного пошуку
описів сервісів та додавання в базу
Рисунок 10. Архітектура для композиції сервісів
46
Програмування для комп’ютерних мереж та Інтернет
• Алгоритми динамічного програ-
мування,
• Метод гілок і меж.
Залежно від вимог ми можемо об-
рати відповідніший алгоритм.
Література
1. Dyvak Y. A. (2021) Analytical review
of existing approaches to integration of
program systems.
2 Brambilla M., Celino I., Ceri S., Cerizza D.,
Della Valle E., Michele Facca F., (2006) A
Software Engineering Approach to Design
and Development of Semantic Web Service
Applications.
3. Andon P. I. (2014) The Problems of
programming in the semantic web
environment. UkrPROG`2014
4. Arpinar B., Aleman-Meza B., Zhang R.,
Maduko A., (2012) Ontology-driven Web
services composition platform.
5. C. Pedrinaci, D. Liu, M. Maleshkova, D.
Lambert (2014) iServe: a Linked Services
Publishing Platform
Отримано: 04.07.2022
Про авторів
Дивак Юрій, аспірант
Мамедов Турал, аспірант
ORCID: 0000-0001-6016-999X
Місце роботи:
Інститут програмних систем
НАН України, 03187, м. Київ-187,
проспект Академіка Глушкова, 40.
yurii.dyvak@gmail.com
|