Current state and extention problems of the service-oriented paradigm
Based on the analysis of the development of software engineering, the main principles and sources of the service-oriented paradigm are identified. The architectural features and basic templates of service-oriented applications and the standards on which they are based are considered. The software en...
Saved in:
| Date: | 2025 |
|---|---|
| Main Authors: | , , , |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
PROBLEMS IN PROGRAMMING
2025
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/833 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-833 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/71/39640cc7cea447d93cc0d8ca9b0b9771.pdf |
| spelling |
pp_isofts_kiev_ua-article-8332025-10-29T11:11:04Z Current state and extention problems of the service-oriented paradigm Сучасний стан та проблеми розвитку сервіс-орієнтованої парадигми Andon, P.I. Subotin, S.V. Perkonos, P.I. Tverdokhlib, E.M. automation of scientific research; integrated information infrastructure; corporate information systems; service-oriented architecture; Semantic Web; semantic web service; ontology UDC 681.3 автоматизація наукових досліджень; інтегрована інформаційна інфраструктура; кор поративні інформаційні системи; сервіс-орієнтована архітектура; Семантичний веб; семантичний веб сервіс; онтологія УДК 681.3 Based on the analysis of the development of software engineering, the main principles and sources of the service-oriented paradigm are identified. The architectural features and basic templates of service-oriented applications and the standards on which they are based are considered. The software engineering of service oriented application development and the current state of its support tools are described. The main problems of building service-oriented applications are identified and ways to overcome them are proposed.Problems in programming 2025; 2: 3-19 На основі аналізу розвитку програмної інженерії визначені основні принципи та джерела сервіс орієнтованої парадигми. Розглянуті архітектурні особливості та основні шаблони сервіс орієнтованих застосувань та стандарти, на яких вони ґрунтуються. Надана характеристика програм ної інженерії розробки сервіс-орієнтованих застосувань та сучасного стану засобів її підтримки. Ви явлені основні проблеми побудови сервіс-орієнтованих застосувань та запропоновані шляхи їх подо лання.Problems in programming 2025; 2: 3-19 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-09-07 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/833 10.15407/pp2025.02.003 PROBLEMS IN PROGRAMMING; No 2 (2025); 3-19 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2025); 3-19 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2025); 3-19 1727-4907 10.15407/pp2025.02 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/833/884 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-10-29T11:11:04Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
automation of scientific research integrated information infrastructure corporate information systems service-oriented architecture Semantic Web semantic web service ontology UDC 681.3 |
| spellingShingle |
automation of scientific research integrated information infrastructure corporate information systems service-oriented architecture Semantic Web semantic web service ontology UDC 681.3 Andon, P.I. Subotin, S.V. Perkonos, P.I. Tverdokhlib, E.M. Current state and extention problems of the service-oriented paradigm |
| topic_facet |
automation of scientific research integrated information infrastructure corporate information systems service-oriented architecture Semantic Web semantic web service ontology UDC 681.3 автоматизація наукових досліджень інтегрована інформаційна інфраструктура кор поративні інформаційні системи сервіс-орієнтована архітектура Семантичний веб семантичний веб сервіс онтологія УДК 681.3 |
| format |
Article |
| author |
Andon, P.I. Subotin, S.V. Perkonos, P.I. Tverdokhlib, E.M. |
| author_facet |
Andon, P.I. Subotin, S.V. Perkonos, P.I. Tverdokhlib, E.M. |
| author_sort |
Andon, P.I. |
| title |
Current state and extention problems of the service-oriented paradigm |
| title_short |
Current state and extention problems of the service-oriented paradigm |
| title_full |
Current state and extention problems of the service-oriented paradigm |
| title_fullStr |
Current state and extention problems of the service-oriented paradigm |
| title_full_unstemmed |
Current state and extention problems of the service-oriented paradigm |
| title_sort |
current state and extention problems of the service-oriented paradigm |
| title_alt |
Сучасний стан та проблеми розвитку сервіс-орієнтованої парадигми |
| description |
Based on the analysis of the development of software engineering, the main principles and sources of the service-oriented paradigm are identified. The architectural features and basic templates of service-oriented applications and the standards on which they are based are considered. The software engineering of service oriented application development and the current state of its support tools are described. The main problems of building service-oriented applications are identified and ways to overcome them are proposed.Problems in programming 2025; 2: 3-19 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/833 |
| work_keys_str_mv |
AT andonpi currentstateandextentionproblemsoftheserviceorientedparadigm AT subotinsv currentstateandextentionproblemsoftheserviceorientedparadigm AT perkonospi currentstateandextentionproblemsoftheserviceorientedparadigm AT tverdokhlibem currentstateandextentionproblemsoftheserviceorientedparadigm AT andonpi sučasnijstantaproblemirozvitkuservísoríêntovanoíparadigmi AT subotinsv sučasnijstantaproblemirozvitkuservísoríêntovanoíparadigmi AT perkonospi sučasnijstantaproblemirozvitkuservísoríêntovanoíparadigmi AT tverdokhlibem sučasnijstantaproblemirozvitkuservísoríêntovanoíparadigmi |
| first_indexed |
2025-09-17T09:24:54Z |
| last_indexed |
2025-10-30T02:15:22Z |
| _version_ |
1850410901799174144 |
| fulltext |
Програмна інженерія – прикладні методи
3
© П.І. Андон, С.В. Суботін, П.І. Перконос, Є.М. Твердохліб, 2025
ISSN 1727-4907. Проблеми програмування. 2025. №2
УДК 681.3 http://doi.org/10.15407/pp2025.02.003
П.І. Андон, С.В. Суботін, П.І. Перконос, Є.М. Твердохліб
СУЧАСНИЙ СТАН ТА ПРОБЛЕМИ РОЗВИТКУ
СЕРВІС-ОРІЄНТОВАНОЇ ПАРАДИГМИ
На основі аналізу розвитку програмної інженерії визначені основні принципи та джерела сервіс-
орієнтованої парадигми. Розглянуті архітектурні особливості та основні шаблони сервіс -
орієнтованих застосувань та стандарти, на яких вони ґрунтуються. Надана характеристика програм-
ної інженерії розробки сервіс-орієнтованих застосувань та сучасного стану засобів її підтримки. Ви-
явлені основні проблеми побудови сервіс-орієнтованих застосувань та запропоновані шляхи їх подо-
лання.
Ключові слова: автоматизація наукових досліджень, інтегрована інформаційна інфраструктура, кор-
поративні інформаційні системи, сервіс-орієнтована архітектура, Semantic Web, семантичний веб-
сервіс, онтологія.
Ph.I. Andon, S.V. Subotin, P.I. Perkonos, Ie.M. Tverdokhlib
CURRENT STATE AND EXTENTION PROBLEMS
OF THE SERVICE-ORIENTED PARADIGM
Based on the analysis of the development of software engineering, the main principles and sources of the
service-oriented paradigm are identified. The architectural features and basic templates of service-oriented
applications and the standards on which they are based are considered. The software engineering of service-
oriented application development and the current state of its support tools are described. The main problems
of building service-oriented applications are identified and ways to overcome them are proposed.
Keywords: automation of scientific research, integrated information infrastructure, corporate information
systems, service-oriented architecture, Semantic Web, semantic web service, ontology.
Вступ
В умовах всеосяжної інформатиза-
ції суспільства та насиченості його обчис-
лювальними ресурсами, поєднаними ві-
домчими та глобальними мережами, домі-
нуючою парадигмою побудови та викори-
стання програмних засобів стає сервіс-
орієнтована парадигма. Тому розуміння
основних принципів та джерел становлен-
ня цієї парадигми, архітектурних особли-
востей, стандартів, що лежать в її основі,
сучасного стану засобів програмної інже-
нерії, котрі забезпечують створення та ви-
користання розподілених сервіс-
орієнтованих застосувань, є запорукою
ефективного створення та використання
прикладних програмних засобів.
Джерела та еволюція сервіс-
орієнтованої парадигми
Сервіс-орієнована парадигма сфор-
мувалась в результаті еволюції програмної
інженерії відповідно до розвитку обчис-
лювальної інфраструктури й потреб суспі-
льства та успадкувала принципи й методи,
відпрацьовані в попередніх парадигмах,
що домінували в різні часи (рис.1).
Рис. 1. Еволюція програмної інженерії
Один з основних принципів - прин-
цип повторного використання коду набу-
вав різних форм у різних парадигмах по-
Програмна інженерія – прикладні методи
4
чинаючи з машинно-орієнтованого про-
грамування. Поява універсальних мов про-
грамування (Алгол, Фортран) дозволила
повторно використовувати програми на
комп’ютерах із різною системою команд, а
також компонувати складні алгоритми з
типових частин завдяки процедурній пара-
дигмі програмування.
Складність процесів, що автомати-
зувались, швидко зростала, і логіка їх ви-
конання, заснована на операторах прямих
посилань, ставала неконтрольованою та
важкою для супроводження. Для забезпе-
чення прозорості алгоритмів були запро-
поновані типові принципи організації логі-
ки виконання, засновані на прозорих конс-
трукціях послідовного, умовного та циклі-
чного виконання, відомі як структурне
програмування . Мови програмування, за-
сновані на цій парадигмі (Pl/1, Pascаl, C),
швидко витіснили застарілі Fortran та
Algol. Структурна парадигма започаткува-
ла модульний принцип побудови програм,
згідно з якою складна система декомпозу-
ється на ряд модулів, які могли розробля-
тись незалежно різними виконавцями і по-
тім збиратись у готову систему.
Але для цього потрібно було здійс-
нювати попереднє проєктування системи,
виходячи з вимог до її функціональності.
Для забезпечення проєктування програм-
них систем виникла методологія моделю-
вання різних аспектів систем за допомо-
гою графічних нотацій SADT (structured
analysis and design technique) [1].
Централізована обробка даних різ-
ними користувачами на одній «потужній»
ЕОМ забезпечила взаємодію користувачів
та використання напрацювань за рахунок
їх розміщення в спільній файловій системі
мейнфрейму та обміну даними й програ-
мами на магнітних носіях.
Наступним кроком організації при-
кладних застосувань була розробка баз да-
них (БД) - пойменованих сукупностей да-
них, організованих за певними правилами,
що передбачають загальні принципи опи-
су, зберігання і маніпулювання даними,
незалежно від прикладних програм. Перші
БД, запропоновані для використання на
мейнфреймах, використовували ієрархічну
або мережеву (графову) модель взає-
мозв’язків між записами БД та відповідні
мови опису та доступу до даних, швидко
витіснених більш гнучкою реляційною
моделлю даних, яка стала однією із скла-
дових методології SADT та відтворена в
CASE середовищах. Зберігання даних у
централізованому структурованому схо-
вищі зі стандартизованими методами дос-
тупу до них спростило користувачам обмін
даними та забезпечило поєднання програм,
що автоматизують окремі операції техно-
логічного ланцюга в єдину систему з авто-
матичною передачею даних між ними.
З появою мікропроцесорів обчис-
лювальна інфраструктура підприємств по-
чала стрімко змінюватись. Поряд із
мейнфреймами з’явились міні та персона-
льні комп’ютери, вартість придбання та
утримання яких була значно меншою, а за
продуктивністю вони практично не посту-
палися мейнфреймам. Тому підприємства
швидко насичувались персональними
комп’ютерами, і обробка даних почала ви-
конуватись розподілено на багатьох робо-
чих місцях, розосереджених по всьому
підприємству. Однак водночас виникла
потреба інформаційної взаємодії та спіль-
ного використання даних і програмних на-
працювань, яка на мейнфреймах вирішу-
валася природним чином за рахунок
централізованої обробки на одній ЕОМ і
розміщення даних в її файловій системі та
базах даних.
Ця проблема була швидко вирішена
шляхом поєднання окремих розподілених
на підприємстві комп’ютерів у мережу за-
вдяки досвіду забезпечення доступу до
мейнфреймів з терміналів, віддалених на
багато сотень, а то й тисяч кілометрів че-
рез канали зв’язку. Локальні мережі забез-
печили сумісне використання розподіле-
них обчислювальних ресурсів підприємст-
ва і доступ до спільної файлової системи
та баз даних. Монолітна архітектура прик-
ладних систем, притаманна мейнфреймам,
практично була витіснена дволанковою
клієнт-серверною архітектурою, за якою
функціонал структурованого зберігання та
доступу до даних виконувався окремим за-
стосуванням (СУБД) на окремому сервері.
Їх обробка відбувалася на інших застосун-
ках, які взаємодіяли з сервером за стандар-
Програмна інженерія – прикладні методи
5
тними мережевими протоколами та стан-
дартною мовою запитів до даних.
Подальшим розвитком структурно-
го програмування стала об’єктно-
орієнтована парадигма (ООП), яка поєдна-
ла в одній конструкції (класі) структуру
опису об’єкта автоматизації та його пове-
дінку (процедуру обробки його даних) і
розглядала прикладну систему як динаміч-
ну сукупність взаємодіючих об’єктів. Ме-
ханізми інкапсуляції структури опису
об’єктів та їхньої поведінки значно спрос-
тили логіку прикладної системи, а механі-
зми наслідування та поліморфізму гнуч-
кість повторного використання готових
рішень. Тому в широко доступні структур-
ні мови програмування додавалась підтри-
мка об’єктно-орієнтованої парадигми (C-
>C++, Pascal->Object Pascal), створювались
нові мови підтримки ООП (JAVA, Python).
Також, як і для методології струк-
турного програмування, були запропоно-
вані методології IDEF та відповідні CASE
засоби, для моделювання систем в ООП
була запропонована методологія UML [2].
Повторне використання реалізова-
них алгоритмів у новій прикладній системі
в процедурній або в об’єктно-орієнтованій
парадигмі потребувала їхньої компіляції та
зв’язування із власним кодом у монолітну,
виконувану в одному адресному просторі
програму. Водночас розробник був обме-
жений у використанні готових рішень ра-
мками платформи розробки своєї системи.
Тому фірма Microsoft запропонувала тех-
нологію СOM (Component object model) -
виклику методів об’єктів, засновану на
стандартизації опису інтерфейсу методів.
Водночас код виконується паралельно на
тій же ЕОМ в окремому адресному прос-
торі як готовий компонент і не потребує
компіляції та вбудовування в прикладну
систему. За приклад використання цієї те-
хнології можна навести механізми ОLE
(Object linking and embeding) вбудовування
в документи офісних систем частин, обро-
бка яких здійснюється іншими застосуван-
нями. Наступним кроком розвитку СOM
технології стала специфікація DCOM
(distributed COM), яка дозволяла здійсню-
вати віддалений виклик процедур об’єктів,
що створені та існують іншою програмою
на іншій ЕОМ з передачею параметрів та
отриманням результату по мережі. На-
жаль, ці специфікації були реалізовані
тільки в рамках операційної системи
Microsoft Windows. Тому групою OMG бу-
ла розроблена альтернативна специфікація
CORBA цього механізму інтеграції ізольо-
ваних систем, розроблених різни-
ми мовами програмування, працюючих в
різних вузлах мережі на різних платфор-
мах та взаємодіючих одна з одною так са-
мо просто, наче вони знаходились в адрес-
ному просторі одного процесу, що можна
вважати початком сервіс-орієнтованої па-
радигми.
Перша глобальна мережа
ARPANET створювалась як закрита мере-
жа військового призначення під контролем
міністерства оборони США. Розроблені в її
рамках протоколи ТСP/IP [3] адресації ву-
злів та передачі пакетів даних між ними
були закритими та заборонені для викори-
стання у відкритих проєктах. Після закрит-
тя 1989 року проєкту ARPANET ця забо-
рона була знята, що сприяло стрімкому
нарощуванню поєднання вже існуючих
локальних мереж в єдину глобальну мере-
жу і використання служб передачі файлів
та електронної пошти, створених в рамках
проєкту ARPANET.
Для забезпечення сумісності апара-
тури та програмного забезпечення вузлів
глобальної мережі 1994 року було створе-
но консорціум W3C, покликаний розроб-
ляти єдині принципи та стандарти (реко-
мендації) Інтернету. На основі одного з
перших стандартів – мови розмітки текс-
тових документів із гіперпосиланнями
НТМL та протоколу прикладного рівня
передачі даних у мережі інтернет http [4]
були створені програми браузерів, що під-
тримують взаємодію користувача через
мережу з програмою, що виконується на
віддаленому сервері. Це здійснюється че-
рез відображення сформованого програ-
мою документа мовою НTML та відправки
підготовлених користувачем даних для ви-
конання програми. Такі триланкові WEB
застосування на сьогодні практично витіс-
нили традиційні дволанкові клієнт-
серверні застосування, оскільки не потре-
бують розгортання на машині користувача,
Програмна інженерія – прикладні методи
6
доступні з будь-якого робочого місця,
під’єднаного до Інтернету, в тому числі з
мобільного смартфону, та можуть надава-
тись у користування як сервіс і не потре-
бують від користувача підтримки та об-
слуговування.
Протокол HTTP не накладає ніяких
обмежень на структуру та формат даних,
що передаються, тому за його допомогою
можна розповсюдити технологію CORBA
та DCOM віддаленого виклику процедур
та забезпечити взаємодію не тільки корис-
тувача з прикладними застосуваннями че-
рез браузер, а й між будь-якими застосу-
ваннями, виконуваними на вузлах Internet
мережі. Для цього консорціум W3C, вра-
ховуючи досвід використання НTML для
кодування інтерфейсу користувача, адап-
тував його для представлення будь-яких
структурованих даних XML (extended
markup language) та на його основі визна-
чив стандарт міжпрограмної взаємодії че-
рез інтернет SOAP (simple object access
protocol) [5], який був значно спрощений
порівнянно з CORBA. Підтримка SOAP
була реалізована в різних платформах про-
грамування та швидко витіснила CORBA
для організації взаємодії прикладних за-
стосувань як в рамках одного підприємст-
ва ESB (Enterprise Service Bus), так і між
підприємствами (B2B).
Завдяки широкому розповсюджен-
ню WEB-застосувань за технологією
AJAX, що використовує взаємодією кори-
стувачів через браузер із вбудованим інте-
рпретатором мови JAVAscript, більш по-
пулярним для організації програмного ін-
терфейсу програм через інтернет став архі-
тектурний стиль REST, запропонований
Роєм Філдінгом 2000 року [6].
Цей підхід почав витісняти прото-
кол SOAP завдяки тому, що він передбачає
віддалений виклик процедур та отримання
результату напряму за протоколом НTTP,
підтримка якого вбудована в JAVAscript. А
формат обміну не обмежується і може бу-
ти використаний прийнятий в JAVAscript
формат JSON, більш компактний, ніж
XML, і тому організація взаємодії здійс-
нюється простіше та ефективніше.
Віддалений виклик процедур мере-
жею на основі стандарту SOAP або REST
технології для виконання певної обробки
або отримання потрібних даних забезпечує
використання готових програмних рішень
без необхідності їхньої компіляції та
зв’язування в єдиний модуль, скористав-
шись вже розгорнутим ПЗ на власній ін-
фраструктурі або на інфраструктурі поста-
чальника ПЗ як сервісу. Це в свою чергу
дозволяє компонувати прикладні системи
автоматизації бізнес-процесів на основі ав-
тономних програмних компонент – серві-
сів, кожний з яких виконує чітко визначе-
ну бізнес логіку у власному операційному
оточенні, отримує запит на виконання та
повертає результат, використовуючи стан-
дартні протоколи та чітко визначений ін-
терфейс.
Така розподілена сервіс-орієнтована
архітектура прикладних систем в умовах
розвинутого Iнтернету стала домінуючою
та поступово витісняє традиційні локальні
та клієнт-серверні застосування завдяки:
скороченню витрат та термінів
розробки потрібного програмного забезпе-
чення за рахунок декомпозиції складної
системи на більш керовані автономні ком-
поненти (мікросервіси), використання го-
тових сервісів, доступних в Інтернеті;
забезпеченню використання
програмних систем та окремих компонент
без необхідності їхнього розміщення та
обслуговування на власних технічних ре-
сурсах;
колективному використанню
програмних систем та окремих її компо-
нент;
масштабуванню та модифікації
системи відповідно до потреб шляхом до-
давання нових компонент або заміщення
продуктивнішими.
Сервіс-орієнтовані системи суттєво
відрізняються від традиційних десктоп та
клієнт-серверних застосувань своєю роз-
поділеною природою та асинхронним ви-
конанням обробки даних на різних вузлах.
Тому технологія та засоби розробки
програмного забезпечення на всіх етапах
починають розвиватись з урахуванням цих
особливостей та підтримувати подіє-
орієнтовану парадигму програмування, яка
Програмна інженерія – прикладні методи
7
забезпечує синхронізацію одночасного ви-
конання окремих процедур процесу.
Архітектурні особливості та
шаблони сервіс-орієнтованої
парадигми
Згідно із базовою моделлю [7] сер-
віс-орієнтована архітектура - це парадигма
побудови прикладних систем на основі ви-
користання взаємодіючих розподілених
програмних компонент, які виконуються в
різних операційних оточеннях, що можуть
належати і бути під контролем різних вла-
сників.
Рис. 2. СОА
У сервіс-орієнтованому застосуван-
ні частина функціональності не реалізуєть-
ся, а її виконання делегується іншому за-
стосуванню-серверу через надсилання по-
відомлення-запиту на виконання потрібної
дії та отримання результату за узгодженим
протоколом. Застосування-сервер забезпе-
чує виконання чітко визначеної функціо-
нальності (сервісу) у відповідь на отрима-
не повідомлення та відправку результату
виконання в чітко визначеному форматі.
Зазвичай, це отримання інформації, яку
підтримує провайдер, або зміна стану
об’єкта в зоні відповідальності провайде-
ра. Водночас клієнт для виконання потріб-
ної йому функціональності може викорис-
товувати різні сервіси від різних постача-
льників, організовуючи логіку свого про-
цесу відповідно до отриманих результатів
виконання. В свою чергу сервіс для вико-
нання своєї функціональності також може
використовувати інші сервіси, як свої, так і
від інших постачальників.
Застосування-сервер розробляється,
розгортається та підтримується постачаль-
ником сервісу (провайдером), який гаран-
тує виконання сервісу за запитами потен-
ційних користувачів за визначеним прото-
колом відповідно до умов постачання на
ресурсах провайдера. Для того, щоб корис-
тувач зміг скористатися сервісом, постача-
льник має забезпечити наступні властиво-
сті та складові сервісу:
Виявлення сервісу потенційними
користувачами повинно забезпечуватись
постачальником через публікацію опису
його сервісу на сайтах, загальнодоступних
реєстрах, адресного інформування або ін-
шим чином.
Зацікавленість передбачає, що сер-
віс виконує потрібну функціональність по-
тенційним користувачам на прийнятних
умовах, які викладаються в його описі.
Доступність передбачає, що сервіс
забезпечує взаємодію через спільне з поте-
нційними користувачами комунікаційне
середовище (як правило, інтернет) за узго-
дженими протоколами (зазвичай, розпо-
всюджені стандарти) а також адресою, які
визначені в описі, та готовий виконувати
запити на прийнятних умовах, які викла-
даються в описі (як правило, 24/7).
Інтерфейс визначає формат і струк-
туру даних вхідного та вихідного повідом-
лень, на основі яких сервіс виконує визна-
чену функціональність, а застосування-
клієнт отримує результати виконання, на
основі яких будує логіку своїх процесів.
Для цього крім формату та структури да-
них, що передаються, обидві сторони по-
винні однаково інтерпретувати інформа-
цію, якою обмінюються. Тобто використо-
вувати однакову семантику (онтологію)
даних, наданих у повідомленнях і яка має
бути надана в описі сервісу.
Функціональність провайдер реалі-
зує сервіс на власний розсуд, враховуючи
потреби потенційних користувачів і надає
відомості про результати виконання серві-
су, не вдаючись у деталі «як саме він це
робить». Користувач зі свого боку викори-
стовує сервіс як «чорну скриньку» для за-
доволення власних потреб, надаючи дані
для виконання завдання та отримуючи по-
трібний результат через опублікований ін-
Програмна інженерія – прикладні методи
8
терфейс. Водночас сервіс може здійснюва-
ти додаткову обробку, яка не опублікову-
ється і не є суттєвою для використання
сервісу потенційним користувачем, але
необхідна для підтримки стану об’єкта та
роботи сервісу, якими він опікується. Для
правильного використання сервісу крім
структури та семантики повідомлень клі-
єнт має бути обізнаний про дії, які виконує
сервіс та їх вплив на стан спільних об’єктів
споживача та постачальника.
Умови використання публікуються
в описі сервісу та визначають підстави на-
дання доступу (комерційна основа, вироб-
ничі взаємовідносини, вільний доступ).
QoS визначає якість надання послуг
(швидкість відклику, обсяги, надійність,
вартість тощо ), які повинні додаватися до
опису сервісу оптимального вибору потрі-
бного користувачу сервісу серед наявних
пропозицій.
Базова модель СОА визначає зага-
льні принципи побудови сервіс-
орієнтованих систем, конкретні реалізації
котрих можуть відрізнятися стандартами
взаємодії із сервісами, які використову-
ються, топологією взаємозв’язків, типами
інтерфейсів тощо.
Зокрема, розрізняють дві топологі-
чні архітектурні моделі композиції сервісів
для реалізації бізнес-процесів:
Оркестровка використовує центра-
льний керуючий сервіс, який, подібно до
диригента в оркестрі, координує виконан-
ня окремих сервісів, що реалізують части-
ну складного процесу, викликаючи їх у по-
трібній черзі. Центральний процес органі-
зує логіку виконання складного процесу,
контролюючи результати виконання окре-
мих кроків та формуючи послідовність ви-
кликів потрібних сервісів. Остання дія за-
лежить від результатів виконання попере-
дніх для забезпечення виконання компози-
тного сервісу.
Хореографія не має централізовано-
го контролю над процесом подібно до ко-
манди танцюристів, кожний з яких знає
своє завдання та взаємодіє з партнерами на
основі визначених правил.
Складність процесів, які реалізу-
ються прикладним застосуванням в моно-
літній архітектурі обмежено можливостя-
ми комп’ютера, на якому воно виконується
і, як правило, не виходить за межі процесів
одного або декількох підрозділів підпри-
ємства. Тому для забезпечення складних
процесів у межах всього підприємства по-
трібно інтегрувати окремі монолітні засто-
сування, що автоматизують окремі ланки
таких процесів, з виконанням їх у відпо-
відності з встановленими бізнес-
правилами. Також має забезпечуватися ав-
томатична передача даних між ними на за-
садах розподіленої сервіс-орієнтованої ар-
хітектури.
Для інтеграції окремих компонент у
межах однієї організації застосовуються
різні методи (архітектурні шаблони) та ві-
дповідні інструменти. Одним із перших
таких шаблонів можна визначити корпора-
тивну сервісну шину (ESB), яка підтримує
обмін даних між різнорідними застосуван-
нями в режимі реального часу. Організації
можуть підключати застосування до
централізованої шини, досягаючи мініма-
льних витрат на реалізацію інтерфейсу,
використовуючи протоколи та компоненти
платформи-застосування. ESB у свою чер-
гу пропонує централізовану платформу,
яка стандартизує та надає сервіси для пе-
ретворення різних форматів даних, прото-
колів передачі даних, маршрутизації пові-
домлень на основі онтологічного мета-
опису застосувань та їхньої взаємодії . Це
спрощує організаціям обслуговування та
масштабування своїх застосувань та керу-
вання ними.
З комерційної точки зору розрізня-
ють різні типи сервісів:
Внутрішні сервіси - такі, що підт-
римуються та використовуються організа-
цією для виконання власних процесів.
B2B (buisines to buisines) – сервіси,
що підтримуються та надаються партнера-
ми для забезпечення взаємодії в спільних
процесах.
B2C (buisines to consumer) – сервіси,
що підтримуються організацією та нада-
ються клієнтам для взаємодії з бізнесом, в
тому числі для надання послуг, зокрема і
на комерційній основі.
G2B (government to buisines) – серві-
си, що підтримуються державою та нада-
Програмна інженерія – прикладні методи
9
ються суб’єктам господарювання для на-
дання адміністративних послуг.
На сьогодні використання корпора-
тивних сервісних шин (ESB) обмежено в
основному застарілими системами, що по-
требують взаємодії компонент за різними
протоколами. Розвиток Інтернету та всео-
сяжне впровадження WEB-протоколів пе-
редачі даних практично витіснило інші
протоколи. Тому складна архітектура з
громіздкою централізованою шиною, че-
рез яку взаємодіють монолітні прикладні
застосування, повсюдно замінюється архі-
тектурами на основі WEB сервісів, а моно-
літні застосування декомпозуються на ряд
слабко зв’язаних легких застосувань – мік-
росервісів, які взаємодіють один з одним
через АPI (програмний інтерфейс). Клієнт-
серверні десктоп-застосування, які поєд-
нують бізнес логіку та користувацький ін-
терфейс витісняються триланковими за-
стосуваннями з організацією взаємодії з
користувачем через WEB інтерфейс за до-
помогою браузера. Це спрощує доступ до
прикладних систем та дозволяє розповсю-
джувати та надавати програмне забезпе-
чення як послугу (сервіс) не тільки через
програмний інтерфейс, а й через інтерфейс
користувача.
Завдяки такій архітектурі значно
спрощується масштабування системи та її
гнучкість. Автономні сервіси можна легко
переміщувати з одного сервера на інший,
поєднувати сервіси в єдину систему ево-
люційним шляхом у процесі експлуатації
без необхідності перезбирати монолітне
застосування під час зміни або додавання
функціональності.
Впровадження не потребує повного
переналаштування процесів та надає мож-
ливість використовувати звичні, добре за-
рекомендовані застосування. Достатньо
лише додати відповідний інтерфейс для
вже готової функціональності.
Мікросервісна архітектура дає під-
приємству можливість швидше адаптува-
тись до змін бізнесу, замінюючи реаліза-
цію сервісу, залишаючи незмінним його
інтерфейс. Використання стандартних
протоколів взаємодії дозволяє поєднувати
компоненти, розроблені на різних плат-
формах та різними мовами.
Сервіс-орієнтована архітектура
пропонує розробнику новий підхід до ви-
користання готових рішень без необхідно-
сті вбудови його коду в монолітне застосу-
вання. Замість цього надається композиція
складних сервісів із готових розгорнутих
сервісів, що реалізують частини процесу.
Одночасно сервіси можуть бути розподі-
лені в мережі і навіть належати різним
компаніям та надаватись як послуги, не
потребуючи розгортання та підтримки.
Розподілена сервісна архітектура
прикладних застосувань суттєво відрізня-
ється від монолітних застосувань, які ви-
конуються в межах адресного простору
одного процесора та взаємодіють через
спільну оперативну пам’ять та базу даних.
Забезпечення взаємодії окремих
компонент сервіс-орієнтованої системи
(сервісів), що виконуються на різних про-
цесорах та використовують власні бази да-
них для зберігання своїх даних, потребує
інших архітектурних підходів, заснованих
на обміні повідомленнями через мережу.
Залежно від потреб організація обміну по-
відомленнями може здійснюватися синх-
ронно або асинхронно.
Синхронний запит/відповідь перед-
бачає відправку клієнтом запиту видавцю
сервісу та очікування відповіді від видав-
ця. Виконання клієнта блокується на час
очікування та його виконання продовжу-
ється після отримання відповіді
Асинхронний запит/відповідь пе-
редбачає відправку клієнтом запиту без
очікування відповіді. Клієнт не блокується
на час очікування, а обробка відповіді
здійснюється обробником події після над-
ходження відповіді.
Рис. 3. Основні компоненти СОА
Програмна інженерія – прикладні методи
10
Взаємодія здійснюється через від-
далений виклик (RPI- remoute procedure
invocartion) сервісу через транспортний
протокол мережі, переважно через посере-
дництво НTTP cервера, який бере на себе
багатопоточне прослуховування мереже-
вого каналу приймання вхідного повідом-
лення та передачу його на виконання сер-
вісу та відправлення результату виконан-
ня. Крім того, асинхронна взаємодія може
здійснюватись через посередництво так
званих брокерів.
Взаємодія через віддалений доступ
обумовлює жорстку залежність від сервісу
видавника та вимагає його постійної гото-
вності, що не завжди можливо, оскільки
завжди існує ризик часткової відмови на
запит, який може бути обумовлений збоя-
ми обладнання та мережевого каналу або
недоступністю сервісу у зв’язку з техніч-
ним обслуговуванням. Крім того, сервіс
може бути перевантаженим та не відпові-
дати на запити вчасно.
Тому СОА-система повинна перед-
бачати відповідні заходи для запобігання
таких ситуацій. Для цього можуть бути
використані наступні шаблони:
Мережевий час очікування. Повто-
рювання запиту у разі перевищеня певного
часу очікування, що може запобігти впли-
ву збоїв.
Обмеження кількості запитів. Піс-
ля обумовленої кількості невдалих запитів,
блокує ймовірно недоступний сервіс.
Запобіжник перевіряє доступність
сервісу контрольним викликом через пев-
ний час та за потреби знімає блокування.
Виклик сервісу здійснюється за йо-
го мережевою адресою, яка може змінюва-
тись у випадку фізичного переміщення
сервісу, що призводить до відмови його
клієнтів та потребує відповідного корегу-
вання адреси в коді клієнта, його перезби-
рання та перевстановлення. В разі викори-
стання сервісів на власних ресурсах ситуа-
ція може бути полегшена використанням
конфігураційних файлів, які корегуються
під час переміщення сервісів, що допомгає
уникнути необхідності перезбирання кліє-
нтів. Однак адреси екземплярів зовнішніх
сервісів під контролем інших організацій а
також сервісів, розміщених у хмарних се-
редовищах, можуть мінятися динамічно.
Більше того, набір цих екземплярів може
постійно мінятися через постійне масшта-
бування, відмови та оновлення, що потре-
бує засобів динамічного виявлення актуа-
льних адрес сервісів. Механізм динамічно-
го виявлення сервісів заснований на вико-
ристанні реєстру, здійснюється адміністра-
тором або автоматично самим сервісом
вбудованими засобами. Функції такого ре-
єстру може виконувати, зокрема, звичай-
ний DNS сервер.
Такий механізм виявлення дозволяє
легко масштабувати систему у разі пере-
вантаження певних сервісів та динамічно
балансувати навантаження. Якщо кількість
запитів до сервісу починає перевищувати
його можливості, запускається ще один
або кілька екземплярів, які реєструються в
реєстрі, й запит спрямовується до якогось
із них, використовуючи одну із стратегій
балансування:
Round Robin - обслуговування по
колу, за якого кожний наступний запит пе-
редається наступному зареєстрованому в
реєстрі екземпляру;
Weighted Round Robin - враховує
продуктивність екземпляру, визначену ва-
говим коефіцієнтом;
Least Connections - враховує кіль-
кість підключень до екземплярів на даний
момент;
Destination Hash Scheduling і Source
Hash Scheduling Sticky Sessions - враховує
зони мережевого розташування клієнта на
основі IP-адреси.
Механізм взаємодії сервісів через
RPI потребує активності обох компонент,
чого не завжди можна досягти. Цього не-
доліку можна уникнути в архітектурі на
основі обміну повідомленнями через посе-
редництво брокерів подібно архітектурі
ESB. Згідно із цим механізмом сервіс -
відправник записує повідомлення в канал,
а отримувач зчитує його з цього каналу.
Під час відправки повідомлення активність
отримувача не обов’язкова, оскільки пові-
домлення зберігається в каналі доки отри-
мувач його не прочитає та не опрацює.
Повідомлення складається із заго-
ловку, який містить метадані щодо пові-
домлення, включаючи ідентифікатор пові-
Програмна інженерія – прикладні методи
11
домлення та зворотну адресу, що визначає
канал, куди потрібно спрямувати повідом-
лення-відповідь, та тіло повідомлення, яке
містить власне дані в узгодженому форма-
ті (текстовому або двійковому).
За специфікою обробки повідом-
лень розглядають два типи каналів:
̶ «крапка — крапка» - використо-
вуються для доставки повідомлення тільки
одному отримувачу, який зчитує їх із цьо-
го каналу та обробляє його. Як правило,
через такі канали передаються повідом-
лення типу «команда»;
̶ «видавець — підписник» доста-
вляє кожне повідомлення всім підключе-
ним споживачам. Зазвичай через такі кана-
ли передаються повідомлення типу «по-
дія».
Взаємодія за допомогою повідом-
лень за своєю природою асинхронна, оскі-
льки після відправлення повідомлення
сервіс не очікує відповіді, а сам ініціює йо-
го отримання з відповідного каналу, вико-
ристовуючи ідентифікатор повідомлення
наданого в повідомленні запиту разом з
каналом відправника. Крім того, на відмі-
ну від віддаленого виклику, відповіді мо-
жуть оброблятися будь - яким екземпля-
ром сервісу, незалежно від того, який ек-
земпляр здійснив запит.
API асинхронного сервісу, який ви-
користовує обмін повідомленнями крім
операцій включає опис подій, які він пуб-
лікує в каналах типу видавець-підписник.
Також, як і для віддаленого виклику
сервісу взаємодія через повідомлення пот-
ребує знання дислокації «каналів» в мере-
жі та протоколів доставки повідомлень.
Тому повинен використовуватись меха-
нізм виявлення, але не для адреси сервісу,
а для його каналів. Також, як і під час від-
даленого виклику, потрібно гарантувати
доступність «каналу», що може бути про-
блематичним у разі великого його заван-
таження. З цими проблемами можна впо-
ратися успішніше, використовуючи не
пряму відсилку повідомлень в канал, а че-
рез посередництво спеціального сервісу-
брокера. Він не аналізує тіло запитів, а
лише виконує приймання повідомлень та
їх збереження в своїй базі даних і видачу
повідомлень на запити споживачів.
Для виконання запиту клієнта до-
статньо взаємодіяти лише з брокером та
відправляти повідомлення у відповідний
канал. Клієнту не потрібно використовува-
ти механізм виявлення сервісу та турбува-
тись про масштабування.
Брокер буферизує повідомлення до-
ти, доки вони не зможуть бути оброблені, і
взаємодія сервісів в системі буде здійсню-
ватись навіть у разі тимчасової недоступ-
ності сервісу-виконавця.
Потенційно вузьке місце продукти-
вності централізованого обробника пові-
домлень долається завдяки відсутності
прикладної обробки повідомлення, а лише
його збереженням в БД а також через ба-
лансування навантаження сервісу-брокера.
Брокер може протоколювати процес
обміну повідомленнями, авторизації під
час доступу до каналів та виконувати інші
функції, пов’язані з обміном.
Залежно від організації зберігання
повідомлень, розрізняють два типи бро-
керів:
Брокер повідомлень - сервіс, який
приймає повідомлення від клієнта та збері-
гає його в одній або декількох чергах ви-
давництв сервісів доти, доки сервіс видав-
ця не забере повідомлення зі своєї черги та
не виконає відповідні дії, результатом яких
може бути розміщення відповіді в черзі
клієнтського сервісу.
Брокер подій - використовує пара-
дигму видавця-підписника. При цьому в
брокері повідомлень кожний сервіс не має
власної черги. Замість цього клієнти роз-
міщують повідомлення в базі брокера в
чергах відповідно до типу повідомлення,
на яке підписуються сервіси-обробники,
які отримують ці повідомлення від брокера
подій на основі адреси, наданої під час пі-
дписки або шляхом запитів до брокера.
В сервіс-орієнтованому застосуван-
ні окремі сервіси мають «власну модель»
БД, тому потребують підтримки розподі-
лених транзакцій. Механізм двофазної фі-
ксації (2PC), яку використовують в моно-
літних застосуваннях під час роботи з де-
кількома базами даних передбачає жорст-
ку взаємозалежність та доступність серві-
сів у процесі виконання розподіленої тран-
Програмна інженерія – прикладні методи
12
закції, що суперечить принципу слабкої
зв'язаності сервісів в СОА.
Згідно з відомою САР теоремою
Брюєра [8] неможливо одночасно забезпе-
чити: узгодженість даних в усіх вузлах
(Consistency), доступність вуз-
лів(Availability), стійкість до розділення
(Partition tolerance). Оскільки в сервіс-
орієнтованому застосуванні апріорі підт-
римується Partition tolerance, неможливо
забезпечити Consistency або Availability,
які потрібні для 2PC, тому для підтримки
розподілених транзакцій в СОА застосову-
ється інший архітектурний шаблон «опові-
дання» «SAGA». Цей шаблон забезпечує
узгодженість даних, користуючись послі-
довністю прямих та компенсуючих транза-
кцій, які координуються асинхронними
повідомленнями.
Рис. 4. Архітектура сервісу в СОА
Архітектура сервісів відрізняється
від пошарової архітектури (MVC, MVP,
MVPP) монолітних застосувань. Сервіси в
СОА зазвичай реалізують бізнес логіку
операцій пов’язаних з одним суб’єктом,
відстежують його стан у своїй автономній
БД та виконують свій функціонал за запи-
тами через API. Тому архітектурно сервіс
має не пошарову архітектуру, а так звану
шестигранну [9] з ядром (рис 2), яке вико-
нує бізнес-логіку, та адаптерами, які забез-
печують взаємодію. Механізм віддаленого
виклику сервісу заснований на викорис-
танні програмного інтерфейсу (API) серві-
су, який визначає перелік операцій, що
можуть викликатись, та подій, що можуть
генеруватись під час виконання. Для кож-
ної операції визначаються формат та сема-
нтика даних, необхідних для її виконання,
а також формат та семантика результату
виконання операції. Для події визначається
її тип, формат та семантика пов’язаних да-
них, що публікуються в каналі взаємодії.
Клієнтська бізнес-логіка для віддаленого
виконання операції зовнішнім сервісом
звертається до проксі-інтерфейсу – класу
адаптера, який інкапсулює узгоджений
АPI. RPI-проксі формує та відправляє че-
рез мережевий протокол (як правило
HTTP) повідомлення-запит сервісу. Запит
приймається класом-адаптером RPI-
сервер, який витягує з повідомлення дані
відповідно до АPI, та викликає бізнес-
логіку сервісу . Після відпрацювання біз-
нес-логіка сервісу викликає метод RPI-
серверу, який запаковує результат вико-
нання відповідно до API, та відправляє ві-
дповідь через мережевий протокол, який
приймається методом RPI-проксі. А той
витягує дані результату та викликає обро-
бку результату клієнтською бізнес-
логікою. Водночас надсилання HTTP запи-
ту клієнтом може здійснюватися синхрон-
но так, що процес клієнта очікує відповідь
сервісу, або асинхронно таким чином, що
процес клієнта продовжується, а обробка
результату здійснюється методом–
обробником події приходу результату
HTTP-запиту, який вказується у надсилан-
ні запиту.
Завдяки цьому внутрішні зміни біз-
нес-логіки операцій не впливають на кліє-
нтів, якщо не змінюється API.
Стандарти сервіс-орієнтованої
парадигми
Сервіс-орієнтована архітектура
прикладних систем покладається на взає-
модію її окремих компонент, що функціо-
нують на різних платформах в різних об-
числювальних середовищах, підпорядко-
ваних різним організаціям через повідом-
лення по мережі. Це в свою чергу потребує
узгоджених правил (протоколів) прийо-
му/передачі даних, їхніх форматів як на
фізичному, так і на логічному рівні, які
підтримуються різними платформами, а
також метаопису компонент та їхніх інтер-
фейсів.
Програмна інженерія – прикладні методи
13
Рис. 5. Стандарти СОА
Для впорядкування досвіду та дося-
гнення сумісності продуктів підтримки ло-
кальних мереж від різних виробників, які
стрімко почали розвиватись, міжнародна
організація із стандартизації OSI (Open
system interconnection) розробила базову
модель мережевої взаємодії, яку офіційно
опублікувала 1983 року. Паралельно в
процесі розвитку глобальних мереж
Internet Інженерною радою Інтернету IETF
(Internet Engeniering Task Force) була сфо-
рмована альтернативна модель TCP/IP і
відповідний стек протоколів, які поступово
стали домінуючими, яка складалась із 4
шарів (замість 7 рівнів OSI):
Канальний рівень (network access
layer) визначає параметри фізичного сере-
довища передачі та спосіб кодування да-
них.
Міжмережевий рівень (Internet
layer) регулює передачу даних з однієї ме-
режі в іншу. На цьому рівні працюють ма-
ршрутизатори, які спрямовують пакети до
потрібної мережі за її адресою.
Транспортний рівень визначає ме-
ханізми перевірки правильності пересилки
та доставки пакетів потрібному застосу-
ванню в правильному порядку з підтвер-
дженням доставки (TCP) або без підтвер-
дження (UDP).
Прикладний рівень забезпечує узго-
джені правила та формати обміну інфор-
мації між прикладними застосуваннями.
Залежно від призначення прикладного за-
стосування можуть бути різні протоколи
прикладного рівня. Наприклад, протокол
HTTP для інтернет-браузерів, протокол
FTP - для передавання файлів, протоколу,
SMTP для електронної пошти, в тому числі
усі стандарти, що регламентують сервісно-
орієнтовану взаємодію.
Протоколи прикладного рівня для
взаємодії прикладних застосувань через
мережу почали з’являтися із 1970-х років.
Зокрема, стандарт DCE/RPC визначив ме-
ханізм віддаленого виклику процедури, що
виконується в іншому адресному просторі,
з передачею необхідних параметрів та
отриманням результатів через мережу,
аналогічно передачі параметрів по значен-
ню через стек ОП в монолітному застосу-
ванні.
Пізніше компанія Microsoft розпо-
всюдила свою компонентну технологію
СОМ взаємодії різних об’єктних застосу-
вань в одному адресному просторі (так
званий механізм OLE) на розподілені сис-
теми DCOM, додавши механізм віддалено-
го виклику методів об’єкта, існуючого в
застосуванні, що виконується на іншому
комп’ютері (сервері) з маршалінгом (пере-
дачею даних між клієнтом та сервером че-
рез мережу) на тих же засадах, що і відда-
лений виклик процедур (RPC), використо-
вуючи метаопис інтерфейсу методів
об’єктів спеціальною мовою опису інтер-
фейсу (Interface Definition Language). Од-
нак ця технологія та стандарт дозволяє по-
єднувати тільки застосування під опера-
ційною системою Windows.
Для формування кросплатформених
механізмів взаємодії прикладних застосу-
вань групою OMG (Оbject Management
Group ), до складу якої входять представ-
ники найбільших виробників програмного
забезпечення, було розроблено технологію
та відповідний стандарт CORBA (Common
Object Reqest Broker). Технологія заснова-
на на використанні спеціальної мови опису
інтерфейсу (IDL-Interface Definition
Language) з об’єктами, які виконуються на
серверах розподіленої системи та пробле-
мно-незалежних компонент (ORB core), які
забезпечують створення/виявлення екзем-
плярів об’єктів та віддаленого виклику їх-
ніх методів, використовуючи програмні
адаптери (Stubs/Sceleton), які генеруються
автоматично за описом інтерфейсу мовою
IDL.
Програмна інженерія – прикладні методи
14
Водночас швидко розвивається
Всесвітня павутина WWW, заснована на
доступі до текстової та графічної інформа-
ції на основі обміну контентом у форматі
HTML між браузером та сервером через
протокол прикладного рівня HTTP. Завдя-
ки цьому підтримка протоколу HTTP вбу-
дована практично в усі операційні системи
та платформи.
Платформонезалежна базова модель
структурованого документа (DOM), запро-
понована консорціумом W3C, що опіку-
ється стандартами WEB, та призначена для
роботи з документами мовою розмітки до-
кумента HTML отримала реалізації прак-
тично усіма мовами програмування та ши-
роко використовувалась не тільки в брау-
зерах для роботи з HTML-документами, а
й в прикладних застосуваннях для роботи з
документами в форматі розширюваної мо-
ви розмітки XML, також запропонована
консорціумом для текстового представ-
лення структурованих даних опису
об’єктів.
Тому компанією Microsoft 1998 ро-
ку було запропоновано та передано консо-
рціуму W3C для подальшого супроводу та
розповсюдження спрощений протокол
SOAP (Simple Object Access Protokol) вза-
ємодії прикладних застосувань через Інте-
рнет на основі віддаленого виклику проце-
дур обміну даними в текстовому форматі
XML. Цей протокол було доповнено ще
двома взаємопов’язаними специфікаціями,
що забезпечують процеси публікації прик-
ладних застосувань в Інтернет-середовищі
(Вебсервісів) та їх використання:
SOAP – визначає порядок виконан-
ня обміну повідомленнями, синтаксис та
основну структуру повідомлення, правила
їхнього формування та інтерпретації у від-
правника та приймальника.
WSDL - визначає формальний опис
програмного інтерфейсу (API) WEB серві-
су, який по суті є ХМL схемою SOAP по-
відомлень за правилами XSD
UDDI - визначає стандартний API
обмін з реєстром та XML-схему онтологі-
чного опису SOAP WEB сервісів, в якому
постачальники сервісів можуть розміщу-
вати інформацію про себе, сервіси, які во-
ни забезпечують, та порядок їх викорис-
тання, в тому числі посилання на WSDL
специфікацію сервісу.
Крім цієї трійки стандартів, регла-
ментуючих основні етапи взаємодії SOAP
сервісів, W3C визначила низку так званих
WS-* XSD специфікацій API відносно різ-
них аспектів організації взаємодії між сер-
вісами – (автентифікація, безпека, розподі-
лені транзакції тощо).
Протокол SOAP покладається на
формат XML, обмежує його застосування,
обумовлене накладними витратами у пере-
даванні даних в інших форматах, більш
пристосованих для конкретної прикладної
галузі застосування сервісів. Зокрема, од-
ним з найпоширених споживачів сервісів є
WEB застосування, які працюють у сере-
довищі браузерів та викликають сервіси
скріптами мовою JAVAscript, прийнятої за
стандартну, та яка має підтримку практич-
но в усіх браузерах. У стандарті цієї мови
визначений інший формат текстового уяв-
лення структурованих даних JSON, від-
мінний від XML, та більш компактний, що
ускладнює використання SOAP сервісів у
WEB застосуваннях.
Тому 2000 року Рой Філдинг в своїй
дисертації [6] виклав основні принципи
технології взаємодії застосувань через ін-
тернет на основі прямого використання
протоколу НTTP без обмеження на формат
передачі даних.
Ця технологія або архітектурний
стиль отримала назву REST
(REpresentational State Transfer ). І, хоча не
отримала «офіційного» статусу стандарту,
але швидко стала домінуючою в галузі
сервіс-орієнтованих застосувань завдяки
забезпеченню корисних властивостей:
широке розповсюдження базо-
вого HTTP протоколу;
надійність (через відсутність не-
обхідності зберігати стан клієнта під час
взаємодії);
продуктивність (через викорис-
тання кешу);
масштабування (через викорис-
тання посередників – брокерів та балансу-
вальників);
Програмна інженерія – прикладні методи
15
простота інтерфейсів (відсут-
ність необхідності підтримки формального
опису).
Відсутність обмежень на формат
повідомлень дозволяє використовувати
будь-який найбільш доцільний формат по-
відомлень, виходячи з призначення серві-
су, в тому числі той самий XML, як в
SOAP. Однак більшої популярності набув
формат JSON за рахунок своєї лаконічнос-
ті в порівнянні з ХML (що забезпечує бі-
льшу продуктивність через зменшення
трафіку) та підтримці в JavaScript (вбудо-
ваної мови браузерів). Крім того, він до-
зволяє використання бінарних форматів,
таких як Avro або Protocol Buffers, що зда-
тні в деяких випадках ще більше скороти-
ти трафік при взаємодії.
Асинхронна взаємодія застосувань
передбачає застосування спільного схови-
ща або брокера для тимчасового зберіган-
ня повідомлень. Водночас постачальники
та споживачі повідомлень мають викорис-
товувати узгоджені протоколи та формати,
що дозволяють виявити призначені їм по-
відомлення в спільному середовищі та об-
робити їх. Для цього авторитетні організа-
ції із розробки стандартів СОА пропону-
ють протоколи підтримки асинхронної
взаємодії за різними схемами, такими як
крапка – крапка, або публікація/підписка:
AMQP – Advancing Message
Queuing Protocol,
MQTT – Message Queuing Telemetry
Transport,
STOMP – Simple/Streaming Text
Oriented Protocol,
DDS- Data Distribution Service.
Розробка сервіс-орієнтованих за-
стосувань покладається в основному на
композицію процесів із готових рішень,
що реалізують окремі операції – частини
процесу. Для цього потрібно спочатку де-
композувати бізнес-процеси, що автомати-
зуються на окремі операції, визначити по-
трібні сервіси, які можуть їх виконати та
знайти готові рішення, або розробити нові
в разі відсутності потрібних. Така робота
потребує методів моделювання процесів,
зрозумілих як системним аналітикам–
фахівцям у предметній галузі, так і про-
грамістам, що їх реалізують. Для проєкту-
вання монолітних застосувань використо-
вувались відповідні графічні нотації, що
дозволяють наочно представити склад
операцій їхньої взаємозв’язки та послідов-
ність виконання. В структурних застосу-
ваннях це нотації IDEF в об’єктно-
орієнтованиx - UML. Сервіс-орієнтовані
застосування часто використовують подіє-
орієнтовані механізми взаємодії, які не
підтримуються в цих нотаціях. Тому гру-
пою OMG було розроблено нотацію BPMN
(Buisines Process Modeling Notation ), яка
усуває цей недолік. Крім графічного пред-
ставлення ця специфікація визначає екві-
валентний формальний опис процесів мо-
віою ХML відповідної схеми.
Якщо в таку модель додати специ-
фікацію реалізацій та інтерфейсів складо-
вих сервісів, а також умов, що визначають
послідовність їх виконання, то таку модель
можна інтерпретувати для виконання про-
цесу. Таку специфікацію BPEL (Buisines
Process Execution Language) для оркестру-
вання SOAP сервісів, засновану мовою
XML, також було запропоновано IBM та
передано в OASIS для супроводу.
Програмна інженерія сервіс-
орієнтованої парадигми
Технологія розробки, впровадження
та супроводу сервіс-орієнтованих систем
суттєво відрізняється від розробки систем
монолітної архітектури через їхню розпо-
ділену природу. Сервіс-орієнтований під-
хід починає застосовуватись тоді, коли
предметна галузь системи перетинає межі
організацій та підрозділів та її об’єм почи-
нає перевищувати наявні обчислювальні
можливості комп’ютерів а супровід стає
погано керовану через необхідність реагу-
вання на зміни великої кількості процесів,
поєднаних в монолітному застосуванні.
Для виконання процесів сервіс-
орієнтовані системи використовують ком-
поненти, які знаходяться в зоні відповіда-
льності різних підрозділів і навіть органі-
зацій, і тому потребують узгодження про-
грамних інтерфейсів для інформаційної
взаємодії та послідовності їх виконання і
відповідно проєктування та декомпозиції
складних процесів.
Програмна інженерія – прикладні методи
16
Декомпозиція сервіс-орієнтованої
системи на окремі компоненти – сервіси
заснована на предметно-орієнтованому
проєктуванні, згідно з яким до функціона-
льності сервісу залучаються операції,
пов’язані з відносно самостійною групою
ресурсів, що гарантує слабку зв’язаність
сервісу.
В основу декомпозиції системи на
сервіси можна покласти принципи єдиної
відповідальності (Single Responsibility
Principle, SRP) та узгоджених змін
(Common Closure Principle, CCP), запози-
чені з об’єктно-орієнтованого проєкту-
вання.
Згідно із принципом SRP кожен
сервіс повинен мати лише одне призна-
чення і відповідно єдину причину для змі-
ни, а згідно із принципом CCP причини
зміни операцій сервісу мають бути одна-
кові.
Дотримання цих принципів деком-
позиції дозволить мінімізувати кількість
сервісів, які потрібно буде редагувати та
розгортати зі зміною якоїсь вимоги.
Окремі операції спроєктованої сис-
теми можуть бути вже реалізовані різними
провайдерами в сервісах, розгорнутих на
їхніх ресурсах та доступних для викорис-
тання . Щоб скористатися таким готовим
сервісом, клієнт повинен бути обізнаним із
функціоналом, програмним інтерфейсом
(API), адресою сервісу та умовами надан-
ня. А для цього провайдер сервісу повинен
опублікувати такий опис на ресурсах, дос-
тупних потенційним користувачам.
Для SOAP WEB сервісів був запро-
понований стандарт UDDI онтологічних
мета описів сервісів та інтерфейс доступу
до них для створення як публічних, так і
відомчих репозиторіїв. Цей стандарт був
відтворений у різних реалізаціях як репо-
зиторіїв, так і їхніх клієнтів, що забезпечу-
вали публікацію мета-описів сервісів, по-
шук сервісів за елементами специфікації,
отримання опису API.
Однак згодом Rest сервіси значно
потіснили SOAP, тому UDDI репозиторії
не виправдали очікуваного поширення.
2006р. IBM, Microsoft та SAP оголосили
про закриття своїх загальнодоступних
UDDI вузлів. 2007 року завершена підтри-
мка UDDI в OASIS. 2010 року Microsoft
оголосила про припинення підтримки
UDDI в Windows Server. Тому пошук пот-
рібних сервісів та їхніх постачальників
може здійснюватися в основному за допо-
могою загальних пошукових механізмів
інтернету на основі ключових слів, а отри-
мання опису їх API здійснювати зі знайде-
ного сайту. Питання створення репозиторі-
їв для забезпечення пошуку потрібних
сервісів за їхнім онтологічним описом за-
лишається відкритим. Водночас онтологі-
чні схеми в таких репозиторіях не повинні
обмежуватись одним стандартом та перед-
бачати в своєму описі визначення прото-
колів та форматів взаємодії. Додавання в
онтологію опису крім синтаксичного опи-
су АPI ще семантики функціональності та
повідомлень сервісу та існуючих екземп-
лярів може розширити призначення репо-
зиторію не тільки для пошуку потрібних
сервісів, а й для виявлення потрібних сер-
вісів в процесі виконання з балансуванням
навантаження та оптимізацією витрат. До-
цільно розглянути підхід створення розпо-
ділених репозиторіїв на базі WSIL (Wev
Servcies inspection language), запропонова-
ний сумісно IBM та Microsoft.
Композитні сервіси, що реалізують
поєднання окремих сервісів для виконання
складних процесів відповідно до спроекто-
ваної бізнес-логіки, можуть розроблятися
на будь-якій платформі з використанням
бібліотек підтримки стандартних протоко-
лів взаємодії . Для організації асинхронних
відкладених викликів сервісів можна ви-
користовувати готові брокери повідом-
лень. Крім того, для композиції сервісів,
спроєктованих у стандартних нотаціях
(BPMN, BPEL), можна реалізовувати за
допомогою спеціалізованих платформ та
інтерпретаторів, що їх підтримують.
Деякі операції можуть потребувати
втручання людини для вводу даних, необ-
хідних для виконання сервісу та аналізу
результатів його виконання для ухвалення
рішень.
Такі операції реалізуються здебіль-
шого WEB застосуванням, побудованим за
AJAX технологією.
Водночас інтерфейс користувача
для браузера формується за допомогою
Програмна інженерія – прикладні методи
17
спеціалізованих фреймворків, а для викли-
ку сервісів використовуються засоби підт-
римки HTTP протоколу, присутні практи-
чно на усіх платформах.
Якщо для операцій не знайшлося
готової реалізації, потрібно створити від-
повідні компоненти сервіси. Окремий сер-
віс розробляється як неінтерактивне моно-
літне застосування, яке відстежує стан ре-
сурсів в окремій базі даних та видачу цьо-
го стану за запитами через програмні інте-
рфейси.
Сервіс розробляється, переважно, в
об’єктно-орієнтованій парадигмі з викори-
станням бібліотек підтримки протоколів та
стандартних форматів повідомлень для об-
раної платформи розробки.
Прослуховування мережевого кана-
лу, прийом та відправку повідомлень, як
правило, делегується HTTP-серверу, взає-
модія з яким здійснюється за обумовлени-
ми протоколами (CGI, JavaServlet …), під-
тримка яких вбудована у відповідні бібліо-
теки.
Методологія структурного проєкту-
вання та програмування SADT , що засто-
совувалась для розробки складних монолі-
тних систем, рано чи пізно стикається з
проблемою росту термінів випуску версій
системи у зв’язку з неконтрольованим зро-
станням кількості залежностей. В резуль-
таті система не взмозі реагувати на зміни
бізнес правил та умов виконання процесів
у прийнятні терміни.
Розробка складних систем у сервіс-
орієнтованій архітектурі взмозі швидко ре-
агувати на зміни бізнес правил та умов ви-
користання за рахунок того, що вона скла-
дається з відносно невеликих частин. Ко-
манда ж розробників сервісу може бути
невеликою та розвивати й підтримувати
сервіс у разі зміни внутрішніх правил ви-
конання операцій сервісу незалежно від
інших пов’язаних сервісів, доки зовнішній
узгоджений програмний інтерфейс зали-
шається незмінним. Однак зберегти АРI
вдається не завжди, тому для забезпечення
працездатності усієї СОА-системи у разі
заміни версії сервісу, потрібно забезпечу-
вати сумісність версій або підтримку всіх
версій API, доки вони використовуються
його клієнтами. Подолати такі негаразди
допомагає специфікація семантичного вер-
сіонування, згідно з якою номер версії фо-
рмується з трьох частин, які інкременту-
ються під час випуску нової версії відпо-
відно до характеру змін:
Major – під час внесення в API не-
сумісних змін (видаляються параметри або
змінюється їхня семантика).
Minor – під час зміни API з підтри-
мкою зворотної сумісності (додавання но-
вих атрибутів до запиту або відповіді; до-
давання нових операцій. Водночас сервіси
повинні надавати значення за замовченням
для нових атрибутів, а клієнти можуть іг-
норувати будь-які зайві атрибути).
Patch - виправлення помилок з підт-
римкою зворотної сумісності.
Відповідність версії АPI сервісу та
клієнта здійснюється на основі номера ве-
рсії, що вказується в повідомленні. Внося-
чи мажорні зміни, важливо підтримувати і
попередні версії API, для чого номер версії
може бути частиною адреси сервісу.
Така методологія швидкого реагу-
вання на зміни бізнес-правил та постійного
вдосконалення системи отримала назву
екстремального програмування (AGILE),
заснованого на 12 простих принципах [10],
одним з яких є принцип тісної взаємодії
розробників та користувачів системи
(DEVelop & OPerationS).
Для дотримання цих принципів ма-
ксимально автоматизується взаємодія роз-
робників та користувачів, а також операції
технологічного циклу випуску версій сер-
вісів із застосуванням відповідних засобів
для планування модифікацій та їх реаліза-
ції, тестування та розгортання.
Висновки
Сервіс-орієнтована парадигма по-
будови складних розподілених систем є
закономірним результатом еволюції підхо-
дів до розробки від процедурних та
об’єктно-орієнтованих монолітних систем
в єдиному адресному просторі до взаємо-
діючих мережею слабко зв’язаних компо-
нентів у розподіленому середовищі.
Сервіс-орієнтована парадигма
уможливлює створення прикладних сис-
тем шляхом інтеграції готових компонент
Програмна інженерія – прикладні методи
18
в єдиний технологічний ланцюг без необ-
хідності поєднання їх в монолітне застосу-
вання та розгортання на власних ресурсах.
Використання їх, як є, на ресурсах провай-
дера на основі стандартів взаємодії та уз-
годженого програмного інтерфейсу (API) є
практично доцільним. Rest API на основі
HTTP та JSON домінує та практично виті-
снив рішення на основі стандартів взаємо-
дії SOAP. Зокрема, загальні реєстри UDDI
публікації онтологічних описів SOAP сер-
вісів, які дозволяли здійснювати пошук го-
тових сервісів, необхідних для компону-
вання прикладної системи, стали неактуа-
льними. Хоча потреба в пошуку готових
рішень залишається. Тому створення ана-
логічних загальнодоступних реєстрів гото-
вих рішень з онтологією опису, не обме-
женою протоколом SOAP, є актуальним
завданням.
Функціонал, для якого не знайдено
відповідного готового рішення розробля-
ється як на традиційних компілюючих
платформах, так і в сучасних інтерпретую-
чих платформах WEB програмування в
об’єктно-орієнтованій парадигмі з дотри-
манням стандартів взаємодії SOAP та
REST.
Відпрацьована формальна методо-
логія SADT організації розробки моноліт-
них застосувань витіснена більш гнучкою
методологією екстремального програму-
вання AGILE, яка значно скорочує трива-
лість технологічного циклу розроб-
ки/впровадження, та дозволяє швидше ре-
агувати на зміни правил виконання бізнес
процесів. Дотримання принципів екстре-
мального програмування потребує викори-
стання спеціалізованих програмних засобів
організації розробки включно із плануван-
ням та відстеженням завдань, а також – ав-
томатизацією тестування та розгортанням
версій системи.
Література
1. А.Пискун, Краткий путеводитель по се-
мейству нотаций IDEF.
https://www.antonpiskun.pro/kratkij-
putevoditel-po-semejstvu-notaczij-idef/
2. Donald Bell, UML basics: An introduction to
the Unified Modeling Language.
https://cs.nyu.edu/~jcf/classes/g22.2440-
001_sp06/handouts/UMLBasics.pdf
3. С.Фейт, TCP/IP Архітектура, протоколи,
реалізація. ISBN 5-85582-072-6
https://coollib.cc/b/163834-sidni-m-feyt-tcp-
ip-arhitektura-protokolyi-realizatsiya-
vklyuchaya-ip-versii-6-i-ip-security/read
4. Internet Engineering Task Force (IETF)
Request for Comments: 7540 May 2015
Hypertext Transfer Protocol Version 2
(HTTP/2)
https://datatracker.ietf.org/doc/html/rfc7540
5. D.Tidwell, J.Snell, P.Kulchenko,
Programming Web Services with SOAP.
https://theswissbay.ch/pdf/Gentoomen%20Lib
rary/Programming/CSharp/OReilly%20-
%20Programming%20Web%20Services%20
with%20Soap.pdf
6. R.Th.Fielding, Architectural Styles and the
Design of Network-based Software
Architectures,
https://ics.uci.edu/~fielding/pubs/dissertation/t
op.htm
7. OASIS. Reference Model for Service
Oriented Architecture 1.0 Committee
Specification 1, 2 August 2006
https://groups.oasis-
open.org/higherlogic/ws/public/download/196
79/soa-rm-cs.pdf/latest
8. S.Gilbert, N.Lynch, Brewer's Conjecture and
the Feasibility of Consistent, Available,
Partition-Tolerant Web Services
https://web.archive.org/web/20160213135959
/http://citeseerx.ist.psu.edu/viewdoc/download
?doi=10.1.1.20.1495&rep=rep1&type=pdf
9. К.Ричардсон, Микросервисы: Патерны ра-
зработки и рефакторинга. Издательский
дом “Питер”, 2020.
https://coderbooks.ru/mikroservisy-patterny-
razrabotki-i-refaktoringa
10. Agile-маніфест розробки програмного за-
безпечення,
https://agilemanifesto.org/iso/uk/manifesto.ht
ml
References
1. A.Piskun, A Brief Guide to the Notation
Family IDEF.
https://www.antonpiskun.pro/kratkij-
putevoditel-po-semejstvu-notaczij-idef/
2. Donald Bell, UML basics: An introduction to
the Unified Modeling Language.
https://cs.nyu.edu/~jcf/classes/g22.2440-
001_sp06/handouts/UMLBasics.pdf
3. S.Fate, TCP/IP Architecture, protocols,
implementation. ISBN 5-85582-072-6
Програмна інженерія – прикладні методи
19
https://coollib.cc/b/163834-sidni-m-feyt-tcp-
ip-arhitektura-protokolyi-realizatsiya-
vklyuchaya-ip-versii-6-i-ip-security/read
4. Internet Engineering Task Force (IETF)
Request for Comments: 7540 May 2015
Hypertext Transfer Protocol Version 2
(HTTP/2)
https://datatracker.ietf.org/doc/html/rfc7540
5. D.Tidwell, J.Snell, P.Kulchenko,
Programming Web Services with SOAP.
https://theswissbay.ch/pdf/Gentoomen%20Lib
rary/Programming/CSharp/OReilly%20-
%20Programming%20Web%20Services%20
with%20Soap.pdf
6. R.Th.Fielding, Architectural Styles and the
Design of Network-based Software
Architectures,
https://ics.uci.edu/~fielding/pubs/dissertation/t
op.htm
7. OASIS. Reference Model for Service
Oriented Architecture 1.0 Committee
Specification 1, 2 August 2006
https://groups.oasis-
open.org/higherlogic/ws/public/download/196
79/soa-rm-cs.pdf/latest
8. S.Gilbert, N.Lynch, Brewer's Conjecture and
the Feasibility of Consistent, Available,
Partition-Tolerant Web Services
https://web.archive.org/web/20160213135959
/http://citeseerx.ist.psu.edu/viewdoc/download
?doi=10.1.1.20.1495&rep=rep1&type=pdf
9. K.Richardson, Microservices: Patterns of
development and refactoring. Publishing
house "Piter", 2020.
https://coderbooks.ru/mikroservisy-patterny-
razrabotki-i-refaktoringa
10. Agile-software development manifesto,
https://agilemanifesto.org/iso/uk/manifesto.ht
ml
Одержано: 12.04.2025
Внутрішня рецензія отримана: 19.04.2025
Зовнішня рецензія отримана: 28.04.2025
Про авторів:
1Андон Пилип Іларіонович,
академік НАН України.
https://orcid.org/0009-0000-1737-5579.
1Суботін Сергій Васильович,
науковий співробітник.
https://orcid.org/0000-0002-5958-0259.
1Перконос Петро Іванович,
науковий співробітник.
https://orcid.org/0000-0002-5958-0260.
1Твердохліб Євген Миколайович,
кандидат технічних наук,
старший науковий співробітник.
https://orcid.org/0000-0001-6594-5468.
Місце роботи авторів:
1Інститут програмних систем
НАН України,
тел. +38-044-522-62-42
E-mail: ukrprog@isofts.kiev.ua
www.iss.nas.gov.ua
|