Analytical review of approaches to integration of software systems

Conducted comparison analysis of existing approaches to integrations of software systems, with the purpose of continuous design of new alternative approaches for resolving integration tasks and web-service composition tasks. Conducted integration of payment system with online store with one of the m...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2021
Автор:	Dyvak, Y.A.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2021
Теми:	Integrations of software systems web-service composition UDC 004.62
Онлайн доступ:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/450
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Problems in programming
Завантажити файл:

Репозитарії

Problems in programming

id	pp_isofts_kiev_ua-article-450
record_format	ojs
resource_txt_mv	ppisoftskievua/b1/e9ca11a337c0b43aef146edb9b169eb1.pdf
spelling	pp_isofts_kiev_ua-article-4502024-04-26T22:25:02Z Analytical review of approaches to integration of software systems Аналітичний огляд підходів до інтеграції програмних систем Dyvak, Y.A. Integrations of software systems; web-service composition UDC 004.62 інтеграція програмних систем; композиція веб-сервісів УДК 004.62 Conducted comparison analysis of existing approaches to integrations of software systems, with the purpose of continuous design of new alternative approaches for resolving integration tasks and web-service composition tasks. Conducted integration of payment system with online store with one of the mentioned approaches for a deeper understanding of problems that caused during the integrations of a software system. Were considered challenges that actual for integration developers during the integrations and methods for resolving raised issues. Defined the key moments of integrations of software systems and interactions between them that we should pay attention to. The subject of research needs a new points of view to the issue and new alternative approaches that might bring more flexibility, increase performance, and they will find the right place for applying in the field of integrations of software systems and the composition of web-services.Problems in programming 2021; 1: 36-48 Виконаний порівняльний аналіз існуючих підходів до інтеграції програмних систем, з метою подальшого розроблення нових альтернативних підходів для вирішення задач інтеграції і композиції веб сервісів. Проведено інтеграцію платіжної системи в Інтернет-магазин одним із зазначених методів для більш глибокого розуміння проблем, які виникають при інтеграції програмних систем. Розглянуті виклики які стоять перед розробниками під час інтеграцій систем, та методи вирішення поставлених задач. Визначено ключові моменти на які слід звернути увагу про інтеграції програмних систем і взаємодії між ними. Об’єкт вивчення потребує нового погляду на проблему і нових альтернативних підходів які принесуть більшу гнучкість, можуть підвищити продуктивність і знайти своє застосування в сфері інтеграції програмних систем і композиції веб-сервісів.Problems in programming 2021; 1: 36-48 Інститут програмних систем НАН України 2021-04-23 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/450 10.15407/pp2021.01.036 PROBLEMS IN PROGRAMMING; No 1 (2021); 36-48 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2021); 36-48 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2021); 36-48 1727-4907 10.15407/pp2021.01 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/450/454 Copyright (c) 2021 PROBLEMS IN PROGRAMMING
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2024-04-26T22:25:02Z
collection	OJS
language	Ukrainian
topic	Integrations of software systems web-service composition UDC 004.62
spellingShingle	Integrations of software systems web-service composition UDC 004.62 Dyvak, Y.A. Analytical review of approaches to integration of software systems
topic_facet	Integrations of software systems web-service composition UDC 004.62 інтеграція програмних систем композиція веб-сервісів УДК 004.62
format	Article
author	Dyvak, Y.A.
author_facet	Dyvak, Y.A.
author_sort	Dyvak, Y.A.
title	Analytical review of approaches to integration of software systems
title_short	Analytical review of approaches to integration of software systems
title_full	Analytical review of approaches to integration of software systems
title_fullStr	Analytical review of approaches to integration of software systems
title_full_unstemmed	Analytical review of approaches to integration of software systems
title_sort	analytical review of approaches to integration of software systems
title_alt	Аналітичний огляд підходів до інтеграції програмних систем
description	Conducted comparison analysis of existing approaches to integrations of software systems, with the purpose of continuous design of new alternative approaches for resolving integration tasks and web-service composition tasks. Conducted integration of payment system with online store with one of the mentioned approaches for a deeper understanding of problems that caused during the integrations of a software system. Were considered challenges that actual for integration developers during the integrations and methods for resolving raised issues. Defined the key moments of integrations of software systems and interactions between them that we should pay attention to. The subject of research needs a new points of view to the issue and new alternative approaches that might bring more flexibility, increase performance, and they will find the right place for applying in the field of integrations of software systems and the composition of web-services.Problems in programming 2021; 1: 36-48
publisher	Інститут програмних систем НАН України
publishDate	2021
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/450
work_keys_str_mv	AT dyvakya analyticalreviewofapproachestointegrationofsoftwaresystems AT dyvakya analítičnijoglâdpídhodívdoíntegracííprogramnihsistem
first_indexed	2024-09-16T04:08:00Z
last_indexed	2024-09-16T04:08:00Z
_version_	1818568306907414528
fulltext	Теоретичні та методологічні основи програмування © Ю. А. Дивак, 2021 36 ISSN 1727-4907. Проблеми програмування. 2021. № 1 УДК 004.62 https://doi.org/10.15407/pp2021.01.036 Ю.А. Дивак АНАЛІТИЧНИЙ ОГЛЯД ПІДХОДІВ ДО ІНТЕГРАЦІЇ ПРОГРАМНИХ СИСТЕМ Виконаний порівняльний аналіз існуючих підходів до інтеграції програмних систем, з метою подаль- шого розроблення нових альтернативних підходів для вирішення задач інтеграції і композиції веб сервісів. Проведено інтеграцію платіжної системи в Інтернет-магазин одним із зазначених методів для більш глибокого розуміння проблем які виникають при інтеграції програмних систем . Розглянуті виклики, які стоять перед розробниками під час інтеграцій систем, та методи вирішення поставлених задач. Визначено ключові моменти на які слід звернути уваги про інтеграції програмних систем і вза- ємодії між ними. Об’єкт вивчення потребує нового погляду на проблему і нових альтернативних під- ходів, які принесуть більшу гнучкість, можуть підвищити продуктивність , знайти своє застосування у сфері інтеграції програмних систем і композиції веб-сервісів. Ключові слова: Інтеграція програмних систем, композиція веб-сервісів. Вступ Великі компанії мають екосистеми, які включають у себе більше ніж одну програмну систему для підтримки бізнес процесів [1]. Наявність декількох систем працюючих разом дає багато переваг по відношенню до відокремлених незалеж- них монолітних систем: вони можуть пра- цювати узгоджено розподіляючи ресурси, мати більш широкий функціонал, працю- вати незалежно та об’єднувати результати роботи. Тому, в корпоративному середо- вищі в сфері інформаційних технологій існує проблема інтеграції декількох відо- кремлених систем. Основне питання цієї проблеми, це як змусити відокремлені системи працювати разом та забезпечити об’єднаний набір функцій? Деякі програ- ми можуть розроблятися власноруч вдома або в гаражі, тоді як інші купуються у сторонніх постачальників. Додатки пра- цюють на декількох комп’ютерах, які мо- жуть представляти кілька платформ і мо- жуть бути географічно розподіленими. Деякі програми можуть працювати поза межами підприємства зі сторони партне- рів або замовників. Доводиться інтегрува- ти програми які не були розроблені для інтеграції та взаємодії з іншими система- ми, та не можуть бути змінені, що ускла- днює завдання. Ці проблеми та інші поді- бні до них ускладнюють інтеграцію дода- тків і взаємодію між системами. Метою аналітичного огляду є розг- ляд існуючих підходів до інтеграції, для більш глибокого аналізу проблематики та розуміння потреб тих кого ця проблема стосується – це розробники корпоративних застосунків та інтеграційних рішень, кор- порації метою яких є інтеграція з партне- рами та колаборація з іншими учасниками ринку для досягнення економічних показ- ників і конкурентоспроможності, наукове товариство яке зацікавлене в розробці но- вих підходів до існуючих проблем та їх вирішення. Ми розглянемо декілька підхо- дів та визначимо позитивні та негативні сторони кожного з них. Критерії оцінки та визначення підходу для інтеграції програмних систем Інтеграція декількох систем потре- бує завжди різний набір властивостей і функцій, тому підходів з інтеграції існує декілька і кожен підхід задовольняє різні її потреби. Однак, як і будь-які складні тех- нологічні зусилля, інтеграція додатків включає цілий ряд міркувань та наслідків, які слід враховувати під час вибору підхо- ду до інтеграції. Критерії інтеграції мають бути вра- ховані під час вибору та розробки інтегра- ційного підходу. Який підхід інтеграції Теоретичні та методологічні основи програмування 37 корпоративних застосунків більш відпові- дає вказаним критеріям, такий і треба за- стосувати в конкретному випадку. Перший критерій – це сама інтег- рація програми. Чи потрібна інтеграція взагалі? Якщо можливо розробити окре- мий додаток, який не потребує взаємодії з будь-якими іншими програмами, то може- мо повністю уникнути всіх проблем пов’язаних з інтеграцією застосунків. Од- нак, навіть у простого підприємства є декі- лька програмних продуктів, які повинні працювати разом, щоб забезпечити взає- модію для працівників підприємства, пар- тнерів та клієнтів [3]. Зв’язність застосунків. Всі засто- сунки які приймають участь в інтеграції повинні мінімізувати свою залежність один від одного, щоб кожен міг розвива- тися незалежно, не створюючи проблем для інших. Тісно зв'язані програми роб- лять численні припущення про те, як пра- цюють інші програми (зазвичай на основі інтерфейсів, контрактів). Але коли про- грами змінюють і порушують ці припу- щення (інтерфейси, контракти), інтеграція порушується. Інтерфейс для інтеграції програм повинен бути достатньо конкрет- ним для реалізації корисної функціональ- ності, але достатньо загальним, щоб до- зволити цій реалізації змінюватися за не- обхідності [3]. Простота інтеграції. При інтеграції програми в корпоративному середовищі розробники повинні мінімізувати зміни в програмі та мінімізувати необхідну кіль- кість коду для інтеграції. Вирішення по- винно бути простим і зрозумілим. Проте, як правило, необхідні зміни та новий код, щоб забезпечити хорошу функціональність інтеграції, і підходи з найменшим впливом на програму можуть не забезпечити най- кращої інтеграції на підприємстві. Інтегра- ція повинна також забезпечувати гнуч- кість, що не завжди забезпечуються прос- тими рішеннями [3]. Технологія інтеграції. Різні методи інтеграції вимагають різного обсягу спеці- алізованого програмного та апаратного забезпечення. Ці спеціальні інструменти можуть бути дорогими і призвести до бло- кування постачальників (сервісів) та збі- льшити навантаження на розробників, які повинні розуміти як використовувати ін- струменти для інтеграції [3]. Формат даних. Інтегровані про- грами повинні узгоджувати формат даних, якими вони обмінюються, або повинні мати проміжний транслятор для уніфіка- ції програм, які використовують різні фо- рмати даних. З часом формат даних може еволюціонувати, змінюватись та розши- рюватись, що може вплинути на функціо- нальність програми. При чому узгодження повинно відбуватися як на загальному рівні (XML, JSON, BLOB), так і на рівні структур даних, які передаються між сис- темами [3]. Своєчасність даних. Інтеграція по- винна мінімізувати проміжок часу між програмами, коли одні відправляють дані, а інші отримують і можуть їх використо- вувати. Даними слід часто обмінюватися невеликими порціями, а не чекати обміну великим набором непов'язаних елементів, але канал передачі даних є вузьким місцем будь-якої системи, тому іноді краще зме- ншити кількість запитів між інтегрованими системами та відправляти дані одним на- бором, що підвищить швидкість взаємодії між системами. Інтегровані програми по- винні бути проінформовані, як тільки спі- льні дані будуть готові до споживання. Затримка обміну даними повинна врахову- ватися в інтеграційному дизайні; чим дов- ше триває доступ, тим більша вірогідність що дані застаріли і тим складнішою стає інтеграція [3]. Дані або функціональні можли- вості. Інтегровані програми можуть не обмінюватися даними, а використовува- ти функції, щоб кожна програма могла використовувати функціональність інших програм. Викликати віддалену функцію важко, і хоча це може здатися таким са- мим, як виклик локальної функції, воно працює зовсім по-іншому, що суттєво впливає на ефективність роботи інтеграції. Теоретичні та методологічні основи програмування 38 Прикладом такої інтеграції між двома ві- докремленими програмами, застосунком та базою даних, які можуть бути розташовані на різних серверах є можливість виклику віддалених процедур у базах даних Oracle та MySQL [3]. Асинхронність. Комп’ютерна об- робка, як правило, синхронна, це значить що процедура чекає, поки виконується її підпроцедура, але можливий варіант вико- нання процедури асинхронно коли проце- дура не буде чекати закінчення виконання підпроцедури, а виконає її у фоновому ре- жимі. Це особливо стосується інтегрова- них програм, де віддалена програма може не працювати, або мережа може бути не- доступною, у такому випадку вихідна про- грама може просто зробити доступними спільні дані або записати запит на виклик підпроцедури, але потім перейти до іншої роботи впевнена, що віддалений виклик буде викликано пізніше [3]. Існуючі підходи до інтеграції корпоративних застосунків Представлено декілька підходів для інтеграції застосунків. Кожен з них у бі- льшій чи в меншій мірі відповідає критері- ям інтеграції. Як стверджено G. Hohpe та B. Woolf [3] інтеграція програмних систем може бути виконана чотирма підходами які називаються: Передача файлів, Спільна база даних, Виклик віддаленої процедури, Обмін повідомленнями. 1. Передача файлів (by Martin Fowler). Кожна програма виробляє файли з даними якими вона ділиться з іншими застосунками. Та отримує файли з даними, які були вироблені іншими засто- сунками. Уявляючи, як організація працює з єдиного цілісного програмного забезпе- чення, розробленого з самого початку, щоб працювати в єдиній і цілісній формі. Звичайно, навіть найменші опера- ції не працюють так. Кілька програмних продуктів обробляють різні аспекти дія- льності підприємства. Це пов’язано з низ- кою причин. - Корпорації купують програмні системи, розроблені сторонніми організа- ціями. - Різні системи будуються в різний час, що призводить до різного вибору тех- нологій. - Будь-які системи будуються особами, досвід та уподобання яких приводить до різних підходів до побудови додатків. Розроблення програмного продукту та надання цінності компанії та бізнесу є більш важливим, ніж забезпечення вирі- шення питань інтеграції з іншими систе- мами, особливо коли ця інтеграція не до- дає ніякої цінності програмі, що розроб- люється. Як результат, будь-яка організа- ція повинна турбуватися про обмін інфо- рмацією між різними програмами. Вони можуть бути написані різними мовами, на основі різних платформ і з різними при- пущеннями про те, як працює бізнес. Зв’язування таких додатків вимагає вели- ких знань про розуміння того, як пов’язати програми як на бізнес-рівні, так і на технічному рівні. Щоб налагодити взаємодію, треба мінімізувати те, що пот- рібно знати програмі про те, як працюють інші програми. Потрібен загальний меха- нізм передачі даних, який може викорис- товуватися різними мовами та платфор- мами. Для цього потрібно мати мінімаль- ну кількість спеціалізованого обладнання та програмного забезпечення, використо- вуючи те, що є у наявності підприємства. Файли – це універсальний механізм збері- гання, вбудований в будь-яку корпорати- вну операційну систему, доступний на будь-якій мові підприємства. Найпрості- шим підходом було б якось інтегрувати програми за допомогою файлів (рис. 1). Нехай кожна програма створює файли, що містять інформацію, яку повин- ні використовувати інші програми. Інтег- ратори несуть відповідальність за перетво- рення файлів у різні формати. Важливим рішенням щодо файлів є формат, який використовувати. Дуже рід- ко результат однієї програми буде саме Теоретичні та методологічні основи програмування 39 Рис. 1. Інтеграція через Передачу файлів тим, що потрібно для іншої, тож дове- деться досить дорого обробляти та перет- ворювати файли. Всі програми, які вико- ристовують файл, повинні його прочита- ти, та вміти використовувати на ньому інструменти обробки. Як результат, із часом стандартні формати файлів вирос- ли. Системи мейнфреймів зазвичай вико- ристовують канали даних на основі фор- матів файлових систем COBOL. Системи Unix використовують текстові файли. Су- часність полягає у використанні XML та JSON. Навколо кожного з цих форматів склалася галузь читачів файлів, письмен- ників файлів та засобів трансформації. Інше питання, пов’язане з файлами, – це коли їх створювати та споживати. Оскіль- ки для створення та обробки файлу потрі- бні певні зусилля, але не має бажання надто часто працювати з ними. Зазвичай є якийсь регулярний діловий цикл, який визначає рішення: щоночі, щотижня, що- кварталу тощо. Програми пристосовують до конкретно часу в яких інформація у файлі доступна та є актуальною, і оброб- ляють його у свій час. Великою перева- гою файлів є те, що інтегратори не потре- бують знання внутрішніх елементів про- грами. Команда заявок зазвичай надає файл. Вміст та формат файлу узгоджу- ються з інтеграторами. В результаті різні додатки які приймають участь в інтеграції досить добре відокремлені один від одно- го. Кожна програма може вільно вносити внутрішні зміни, не впливаючи на інші програми, за умови, що вони все одно створюють однакові дані у файлах у тому ж форматі. Файли фактично стають інте- рфейсом кожного додатка. Частина того, що спрощує передачу файлів, полягає у тому, що не потрібні додаткові інструме- нти чи пакети інтеграції, але це також означає, що розробники повинні зробити багато роботи самостійно. Програми по- винні узгодити правила іменування фай- лів та каталоги, в яких вони відобража- ються. Автор файлу повинен реалізувати стратегію, щоб зберегти імена файлів уні- кальними. Програми повинні узгодити, як будуть видалятися, і визначатися старі файли. Додатки повинні впровадити ме- ханізм блокування або дотримуватися норми синхронізації, щоб гарантувати, що одна програма не намагається прочитати файл, а інша все ще пише його. Якщо всі програми не мають доступу до одного диска, тоді деяка програма повинна взяти на себе відповідальність за передачу фай- лу з одного диска на інший. Однією з найбільш очевидних проблем передачі файлів є те, що оновлення, як правило, зустрічаються нечасто, в результаті чого системи можуть вийти з синхронізації. Система керування клієнтами може обро- бляти зміну адреси та видавати файл ви- тягу щовечора, але система виставлення рахунків може відправити рахунок на ста- ру адресу того ж дня. Іноді відсутність синхронізації не є великою проблемою. Часто очікується певне відставання в отриманні інформації, навіть від комп’ютерів. В інших випадках викорис- тання несвіжої інформації є катастрофою для роботи програм. Вирішуючи, коли створювати файли, потрібно враховувати потреби споживачів у актуальності даних. Якщо клієнт того самого дня змінює свою адресу за допомогою двох різних систем, але одна з них помиляється і отримує не- правильну назву вулиці, то буде дві не- відповідні адреси клієнта. Тоді знадо- биться якийсь спосіб на вирішення цього питання. Чим довший період між переда- чею файлів, тим більш імовірною і несте- рпнішою стане ця проблема. Звичайно, Теоретичні та методологічні основи програмування 40 файли можна створювати частіше для під- тримки актуальності даних. Інша пробле- ма полягає в керуванні всіма створеними файлами. Повний перелік можливостей підходу основаного на файловій системі набагато ширший, але при обробці файлу витрачається багато ресурсів, що є надмі- рним, якщо хочемо швидко створити ба- гато файлів [3]. 2. Спільна база даних. Застосунки зберігають дані якими вони хочуть ділити- ся в спільній базі даних. Для сучасного бізнесу хочемо, щоб усі мали якомога більше актуальних да- них. Це не просто зменшення помилок, а збільшення довіри до даних. Швидке оно- влення також дозволяє краще усунути невідповідності. Чим частіше синхронізу- ємось, тим менше шансів отримати невід- повідності і тим менше зусиль витрачаємо на вирішення. Але якими б швидкими не були зміни, все одно будуть проблеми. Існує багато прикладів семантично- го дисонансу при застосуванні спільної бази даних, які набагато складніше розгля- дати, ніж суперечливі формати даних. (Для набагато глибшого обговорення цих пи- тань варто прочитати Data and reality, a timeless perspective on perceiving and man- aging information in our imprecise world, William Kent [4]). Якщо потрібна централізована, уз- годжена база даних, до якої мають спіль- ний доступ усі додатки, щоб кожен із них мав доступ до будь-якої спільної інформа- ції, і не було б за потрібне інтегрувати програми, через збереження своїх даних в одній спільній базі даних (рис. 2). Якщо сімейство інтегрованих до- датків покладається на одну і ту ж базу даних, то можемо бути впевнені, що вони завжди постійно узгоджуються. Якщо отримуємо одночасне оновлення окремого фрагмента даних з різних джерел, щоб уникнути колізій для цьо- го існують системи керування транзак- ціями, які керуються принципами ACID [5]. Використання спільної бази даних значно полегшується завдяки широкому розповсюдженню реляційних баз даних на базі SQL. Практично всі платформи для розробки додатків можуть працюва- ти з SQL, часто з досить складними інструментами. Тому не доведеться тур- буватися про декілька форматів файлів. Оскільки будь-яка програма в будь-якому випадку повинна використовувати SQL, це уникає додавання іншої технології, якою кожен може володіти. Оскільки всі використовують одну і ту ж базу да- них, це вирішує проблеми семантичного дисонансу [3]. Рис. 2. Інтеграція через Спільну базу даних Теоретичні та методологічні основи програмування 41 Однією з найбільших труднощів спільної бази даних є створення відповід- ного дизайну (мається на увазі архітекту- ра системи). Інтеграційна база даних по- винна мати схему, яка задовольнить пот- реби всіх клієнтських систем, ця схема завжди більш загальна і більш складна. База даних розробляється декількома ор- ганізаціями тому змінити щось у базі складно, через те, що зміни мають пого- джуватися між клієнтськими застосунка- ми. Розробка уніфікованої схеми, яка мо- же задовольнити потреби багатьох додат- ків, є дуже складною справою, що часто призводить до створення схеми, з якою програмістам важко працювати. Якщо критична програма, ймовірно, зазнає за- тримок для роботи з уніфікованою схе- мою, то часто виникає непереборний тиск для відокремлення. Конфлікти між відді- лами часто посилюють цю проблему. Ін- шим, більш жорстким обмеженням для спільної бази даних є зовнішні програмні системи. Частіше вони не працюватимуть з іншою схемою, окрім власної. Навіть якщо є якийсь простір для адаптації, це, швидше за все, буде набагато обмежені- шим, ніж хотіли б інтегратори. Ця про- блема також поширюється на інтеграцію після розробки. Навіть якщо впорядкува- ти всі свої програми, все одно виникне проблема інтеграції, якщо відбудеться злиття компаній. Кілька програм, які ви- користовують Спільну базу даних для частого читання та модифікації одних і тих самих даних, можуть спричинити ву- зькі місця у роботі та навіть тупикові си- туації, оскільки кожна програма блокує інші дані. Коли програми розподіляються між кількома комп’ютерами, база даних повинна бути розподілена також, щоб ко- жна програма могла отримати доступ до бази даних локально, що заплутує про- блему, на якому комп’ютері слід зберігати дані. Розподілена база даних із конфлік- тами блокування може легко стати пере- шкодою продуктивності [3]. Існує два підходи до застосування баз даних. База даних може бути або прив’язаною до конкретної системи і на- лежати їй, або вона може бути інтегра- ційною, і зберігати спільні дані з декіль- кох систем. Різниця між ними полягає у тому хто контролює потік даних. В останні часи розвивається сервісно- орієнтований підхід до розробки корпо- ративних програмних систем з власною базою даних, які взаємодіють через сер- вісні інтерфейси, ефективно замінюючи інтеграцію через спільну базу даних інте- грацією на основі виклику віддаленої процедури або обміном повідомлень. Плюс інтеграційної бази даних – це інтеграція, яка не потребує відокремленого шару інтеграційних сервісів у застосунку. Всі зміни в базі даних стають доступними для всіх клієнтських застосунків одночас- но, що робить спільні дані більш синхроні- зованими. З іншого боку спільна база даних веде до значних проблем тому, що вона стає точкою зв’язності застосунків. Зазви- чай це дуже глибока зв’язність, яка збіль- шує ризик пов’язаний із змінами системи та її розвитком. Більшість спеціалістів вважає, що треба уникати цього підходу для інтеграції. 3. Виклик віддалених процедур (by Martin Fowler) – кожен застосунок має процедури, які можна викликати віддалено і програми таким викликом запускають процес обміну даними. Парадигма RPC була використана для впровадження багатьох повсякденних систем. Від програм нижчого рівня, таких як Мережеві файлові системи [6] та відда- леного прямого доступу до пам'яті [7], до протоколів доступу до розвитку екосисте- ми мікросервісів, RPC використовується скрізь. RPC має різноманітні програми – SunNFS [6], Twitter Finagle (Eriksen, 2013), Apache Thrift (Prunicki, 2009), Java RMI [8], SOAP, CORBA (Group, 1991) та gRPC від Google (Google, n. d.). Існує декілька підходів до віддале- ного виклику процедур (RPC): CORBA, COM, .NET Remoting, Java RMI і т. д. Вони відрізняються за кількістю підтримуваних систем та простотою використання. Часто такі середовища мають додаткові можли- вості, такі як транзакції. Теоретичні та методологічні основи програмування 42 Передача файлів та спільна база да- них дозволяють програмам обмінюватися своїми даними, що є важливою частиною інтеграції програм, але просто обміну да- ними часто буває недостатньо. Часто зміни даних призводять до того, що доводиться робити зміни в різних додатках. Напри- клад, зміна адреси може бути простою зміною даних, або це може спричинити реєстрацію та юридичні процеси з ураху- ванням різних правил у різних юридичних юрисдикціях. Наявність однієї програми для виклику таких процесів у іншій вима- гало б від програм занадто багато знання про внутрішні функції інших програм. Ця проблема відображає класичні проблеми у розробці додатків. Одним з найпотужні- ших механізмів структурування при роз- робці додатків є механізм інкапсуляції – де модулі приховують свої дані через інтер- фейс виклику функції. Таким чином, вони можуть перехоплювати зміни в даних, щоб виконувати різні дії, які їм потрібно роби- ти, коли дані змінюються. Спільна база даних забезпечує велику, неінкапсульова- ну структуру даних, що значно ускладнює контроль даних. Передача файлів дозволяє програмі реагувати на зміни під час оброб- ки файлу, але процес затримується. Той факт, що спільна база даних має некапсу- льовані дані, також ускладнює ведення сімейства інтегрованих додатків. Багато змін у будь-якій програмі можуть спричи- нити зміни в базі даних, які мають значний вплив на кожен додаток. Як результат, си- стеми, які використовують спільну базу даних, часто дуже неохоче змінюють базу даних, а це означає, що робота з розробки додатків набагато менше реагує на зміни потреб бізнесу [3]. Необхідний механізм який дозво- лить одному застосунку викликати функції в інших застосунках, передавати дані, які потрібні для спільного використання та викликати функцію, яка інформує програ- му-отримувач як обробляти дані [3]. Розробка кожної програми – це ве- личезний проект з інкапсульованими да- ними. Забезпечення інтерфейсу, який до- зволяє іншим програмам взаємодіяти з цим застосунком [3]. Віддалений виклик процедур за- стосовує принципи інкапсуляції до інтег- рації застосунків (рис. 3). Якщо програма потребує деякої інформації, яка належить іншій програмі, вона напряму посилає за- пит до застосунку, який володіє інформа- цією. Якщо одній програмі необхідно змі- нити дані іншої, вона посилає запит для зміни інформації. Кожний застосунок під- тримує цілісність власних даних, а також може змінювати дані незалежно від інших застосунків. На сьогодні лідерами у викорис- танні є веб служби, які використовують такі стандарти як: SOAP і XML. Цінною особливістю є те, що вони легко працю- ють з HTTP, який проходить через бранд- мауери. Той факт, що існують методи які обробляють дані, спрощує семантичний дисонанс. Застосунки можуть забезпечува- ти декілька інтерфейсів для одних і тих же даних, дозволяючи одним користува- чам бачити один стиль, а іншим – інший. Оновлення можуть використовувати декі- лька інтерфейсів, що дає більшу можли- вість для підтримки декількох методів вза- ємодії. Однак інтеграторам не зручно Рис. 3. Віддалений виклик процедур Теоретичні та методологічні основи програмування 43 додавати конвертери, тому важливо узго- джувати інтерфейси взаємодії з іншими застосунками. Оскільки розробники звикли до ви- клику процедур, RPC добре співпрацює з тим до чого вони звикли. Насправді це скоріше недолік. Між віддаленими та ло- кальними викликами існує велика різниця у швидкодії та надійності. Якщо розроб- ники не розуміють як використовувати віддалені процедури правильно то це може призвести до розробки повільних та нена- дійних систем [8].Інкапсуляція допомагає зменшити зв’язок програм, усуваючи ве- лику спільну структуру даних, але про- грами ще досить тісно пов’язані між со- бою. Віддалені виклики, які підтримує кожна система, мають тенденцію пов’язувати різні системи у зростаючий вузол. Зокрема, послідовність – виконан- ня певних дій у певному порядку, яка мо- же ускладнити самостійну зміну систем. Це проблеми, які не важливі у межах од- нієї програми, а стають важливі при інте- грації декількох програм. Спеціалісти, розробляючи інтегра- цію як єдину програму, не підозрюють про правила зміни. 4. Відправлення повідомлень – кожна програма приєднана до спільної системи повідомлень, яка ділиться даними та запускає будь-які процедури використо- вуючи повідомлення (рис. 4). Асинхронні повідомлення – це принципово прагматична реакція на про- блеми розподілених систем. Надсилання повідомлення не вимагає одночасної робо- ти і готовності обох систем. Існує багато прикладів застосуван- ня підходу передачі повідомлень до інтег- рації застосунків через Enterprise Service Bus (ESB), це такі як Dell Boomi [9], In- formatica [10], JitterBit [11], MuleSoft [12], Oracle [13], SnapLogic [14], as well Guara- na [15]. Крім того, розгляд асинхронної ко- мунікації змушує розробників визнати, що робота з віддаленим додатком відбувається повільніше, що заохочує розробку компо- нентів з високою згуртованістю (багато роботи локально) та низькою адгезією (ви- біркова робота віддалено). Системи обміну повідомленнями також дозволяють роз’єд- нання, яке можливо отримати під час ви- користання передачі файлів. Повідомлення можуть бути трансформовані під час передачі, але ні відправник, ні отримувач не знають про трансформацію. Дійсно, роз'єднання дозволяє інтеграторам транс- лювати повідомлення на кілька приймачів, підтримує вибір одного з багатьох потен- ційних приймачів та інші топології, які Рис. 4. Інтеграція через відправку повідомлень Теоретичні та методологічні основи програмування 44 дозволяють інтеграцію відокремлювати від розробки додатків. Оскільки дані пробле- ми, як правило, відокремлюють розробку додатків від інтеграції програм, цей підхід працює скоріше з людською природою, а не проти. Трансформація означає, що ок- ремі програми можуть мати досить різні концептуальні моделі. Звичайно, це озна- чає, що відбудеться семантичний дисо- нанс, але з точки зору обміну повідомлен- нями. Міра, яку вживає Спільна база да- них, щоб уникнути семантичного дисона- нсу, занадто складна, щоб працювати на практиці, і не може бути виконана після об’єднання пакетів [3]. При надсиланні невеликих повідо- млень, дозволяється програмам взаємодія- ти між собою, а також обмінюватися да- ними. Можна запросити інформацію та швидко відповісти. Хоча така співпраця не буде такою швидкою, як віддалений ви- клик процедури, абоненту не потрібно зу- пинятися, поки обробляється повідомлен- ня та повертається відповідь. І обмін пові- домленнями не такий повільний, як дума- ють багато людей – багато рішень для об- міну повідомленнями зароджується у галу- зі фінансових послуг, де тисячі біржових котирувань або торгів повинні проходити через систему обміну повідомленнями що- секунди. Висока частота повідомлень у про- грамі обміну повідомленнями зменшує багато проблем із невідповідністю, що спричиняє неприємну передачу файлів, але не повністю їх усуває. Виникатимуть про- блеми із запізненням, оскільки системи не оновлюються одночасно. Асинхронний дизайн – це не те, що вивчає більшість програмістів, і в резуль- таті існує ціла низка різних правил і мето- дів характерних вивченню такого дизайну. Тестування та налагодження є суттєво складнішим у середовищі обміну повідом- леннями. Можливість перетворення повідом- лень має приємну перевагу, дозволяючи додаткам набагато відокремитись один від одного, ніж у віддаленому виклику проце- дур та передачі файлів. Але ця незалеж- ність насправді означає, що інтеграторам часто залишається писати багато безладно- го коду, щоб все поєднати. Вирішивши використовувати По- відомлення для системної інтеграції, іс- нує низка нових питань, які слід розгля- нути і практики, які використовуватиме- мо. Як передавати пакети даних? Відп- равник надсилає дані повідомлення отри- мувачу через канал повідомлення, що з'єднує відправника та отримувача. Як дізнатися куди надсилати дані? Якщо відправник не знає, куди направити дані, він може надіслати дані маршрутизатору повідомлень, який направить дані до на- лежного отримувача. Як дізнатися який формат даних використовувати? Якщо відправник та отримувач не погоджують- ся щодо формату даних, відправник може направити дані до Перекладача повідом- лень, який перетворить дані у формат отримувача, а потім перенаправить дані отримувачу. Якщо ви розробник додатків, то виникає питання як підключити про- граму до системи обміну повідомлен- нями? Додаток, який бажає використову- вати обмін повідомленнями, реалізує кін- цеві точки повідомлень для фактичного надсилання та отримання. Приклад інтеграції двох застосунків методом виклику віддалених процедур (RPC) Для більш глибокого розуміння проблем, які виникають під час інтеграції застосунків розглянемо практичний прик- лад інтеграції додатків через віддалений виклик процедур. Нам потрібно інтегрува- ти два застосунки один з яких є сервісом, який надає постачальник сервісу, у нашо- му випадку постачальником сервісу є про- цесінговий центр, а сервіс це платіжна си- стема, яка приймає платежі з банківських карт VISA та MASTERCARD та розподі- ляє платіж у будь-який банк утримуючи процент комісії. Споживачем сервісу є Інтернет- магазин з продажу будь-чого. Задача ускладняється тим, що взаємодія застосун- ків повинна бути налагоджена з двох сто- рін – із сторони кінцевого користувача Теоретичні та методологічні основи програмування 45 (frontend), а також із сторони застосунку (backend). Кожна позитивна відповідь з платіжної системи буде реєструватися в системі інтернет-магазину для подальшої обробки замовлення та відслідковування коштів на рахунках (рис. 5). Треба чітко розуміти, що ми маємо дві абсолютно незалежні системи у яких є фронтенд частина і бекенд частина які по- винні взаємодіяти між собою. Зі сторони кінцевого користувача інтеграція здійснюється за допомогою вбудованого айфрейму, якщо сервіс пла- тіжної системи побудований правильно з можливістю адаптації візуальної частини під потреби споживача сервісу, то кінце- вий користувач може не відрізнити вбу- дований сервіс і не зрозуміє, що водночас він працює з сервісом платіжної системи. Проблема CORS (крос-доменних запитів) та зберігання cookies сесії вирі- шуються за допомогою реверс проксі, який можна налаштувати, наприклад, за допо- могою веб серверу nginx. Зі сторони серверної частини засто- сунку інтеграція проводиться за допомо- гою підходу виклику віддалених процедур через REST API. Рис. 5. Інтеграція платіжної системи в Інтернет-магазин Теоретичні та методологічні основи програмування 46 Висновки Передача файлів дозволяє програ- мам обмінюватися даними, але це може бути не своєчасною, а своєчасність може бути критичною проблемою в інтеграції. Якщо зміни не працюють швидко через декілька додатків, то, можливо допустити неправильні дії через застарілість даних. Передача файлів також може недостатньо застосовувати формат даних. Багато про- блем при інтеграції виникають через несу- місні способи обробки даних. Часто вони представляють тонкі бізнес-проблеми, які можуть мати величезний ефект. Передача файлів дозволяє програмі реагувати на зміни під час обробки файлу, тримати про- грами дуже добре відокремленими, але ціною своєчасності даних. Системи просто не встигають одна за одною. Поведінка співпраці занадто повільна. Спільна база даних зберігає спіль- ні дані, але ціною зв’язку всіх застосунків з базою даних. Цей підхід теж не справля- ється зі спільною поведінкою. Передача файлів та Спільна база даних дозволяють програмам ділитися сво- їми даними, але не своїми функціональни- ми можливостями. Віддалений виклик процедур до- зволяє програмам обмінюватися функціо- налом, але тісно поєднує їх процеси. Часто завдання інтеграції полягає у тому, щоб зробити співпрацю між окремими систе- мами якомога своєчасною, не поєднуючи системи між собою, таким чином робить їх ненадійними, як з точки зору виконання програми, так і розробки програми. Зіткнувшись з цими проблемами, віддалений виклик процедури видається привабливим вибором. Але розширення моделі, яка використовується для одного додатка, при інтеграції додатків попадає на безліч інших слабких місць. Ці слабкі сто- рони починаються з основних проблем розподіленого розвитку. Незважаючи на те, що виклики віддалених процедур ви- глядають як місцеві виклики, вони не ді- ють однаково. Віддалені виклики відбува- ються повільніше і можуть не вдатися. Працюючи з кількома програмами, які об- мінюються даними на одному підприємст- ві, не бажано, щоб збій однієї програми призвів до збою в усіх інші програмах. Крім того, не бажано розробляти систему, вважаючи, що виклики швидкі (але вони можуть бути досить повільними), і щоб кожна програма розпізнавала деталі інших програм, навіть якщо це лише деталі про їх інтерфейси. Нам потрібно дещо на зразок пе- редачі файлів, де багато невеликих па- кетів даних можна швидко створити, легко передати, а програма-отримувач автоматично отримує повідомлення, коли новий пакет доступний для споживання. Передача потребує механізму повторної спроби, щоб переконатися, що вона успішна. Деталі будь-якої структури диска або бази даних для зберігання даних потрібно приховувати від про- грам, щоб, на відміну від Спільної бази даних, схема зберігання та деталі могли бути легко змінені, щоб відобразити зміни потреб підприємства. Одна про- грама повинна мати можливість надісла- ти пакет даних іншій програмі, щоб викликати поведінку в іншій програмі, наприклад, віддалений виклик процеду- ри, але без схильності до відмови. Передача даних повинна бути асинхрон- ною, щоб відправнику не потрібно було чекати на приймачі, особливо коли необ- хідна повторна спроба. Проблема інтеграції програмних систем залишається відкритою. Крім існуючих підходів до інтеграції, пред- мет потребує нових альтернативних під- ходів до інтеграції, які відкриють нові шляхи для налагодження взаємодії, запропонують нові можливості та покри- ють потреби корпоративних програмних систем [2]. Інтеграція декількох систем завжди потребує різний набір властиво- стей і функцій (таблиця), тому системи відрізняються за обсягом, за підходами і технологіями. Інтеграція корпоративних застосунків не проста річ, яка потребує зважених технічних а також бізнес рішень. Теоретичні та методологічні основи програмування 47 Таблиця. Порівняння властивостей існуючих підходів Передача файлів Спільна база даних RPC Повідомлення Зв’язність + + + – Швидкість – + – – Інтеграція функціональності – – + + Асинхронність – – – + Можливість відмови – – + + Гнучкість + – + + Література 1. Rosa-Siqueira F.J., Basto-Fernandes V. Frantz R.Z. (2017) Enterprise application integra- tion: Approaches and platforms to design and implement solutions in the cloud. 2. Soomro T.R., Awan A.H. (2012) Challenges and Future of Enterprise Application Integra- tion, UAE, International Journal of Computer Applications. 3. Hohpe G., Woolf B. (2003) Enterprise inte- gration patterns: Designing, building, and de- ploying messaging solutions, Addison-Wesley Professional. 4. Kent W. (2012) Data and reality, a timeless perspective on perceiving and managing in- formation in our imprecise world. USA Tech- nics Publications, LLC. 5. Kleppman M., (2017) Designing Data- Intensive Applications: The big ideas Behind Reliable, Scalable, and Maintainable Systems, USA, O’Reilly Media, Inc. 6. Sandberg R., Goldberg D., Kleiman S., Walsh D., & Lyon B. (1985). Design and im- plementation of the Sun network filesystem. In Proceedings of the Summer, USA CA, Sun Microsystems, Inc. 7. Kalia A., Kaminsky M., & Andersen D.G. FaSST: Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Data- gram RPCs. In 12th USENIX Symposium on Operating Systems Design and Implementa- tion, (OSDI 16: Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation) (P. 185–201). 8. Wollrath A., Riggs R., & Waldo J. (1996). A Distributed Object Model for the Java System, Conference on Object-Oriented Technologies Toronto, Ontario, Canada, June 1996. 9. Dell Boomi Home. https://boomi.com, 2017. 10. Informatica Home. https://www.informatica. com/products/cloud-integration, 2017. 11. Jitterbit Home. http://www.jitterbit.com, 2017 12. Mulesoft Home. https://www.mulesoft.com/, 2017. 13. Oracle Cloud Home. https://cloud.oracle. com/integration, 2017. 14. SnapLogic Home. https://www.snaplogic. com, 2017. 15. Frantz R.Z., Corchuelo R. (2016) On the de- sign of a maintainable software development kit to implement integration solutions. The Journal of Systems and Software, Journal of Systems and Software. Vol. 111, January 2016. P. 89–104. References 1. Rosa-Siqueira F.J., Basto-Fernandes V. Frantz R.Z. (2017) Enterprise application integra- tion: Approaches and platforms to design and implement solutions in the cloud. 2. Soomro T.R., Awan A.H. (2012) Challenges and Future of Enterprise Application Integra- tion, UAE, International Journal of Computer Applications. 3. Hohpe G., Woolf B. (2003) Enterprise inte- gration patterns: Designing, building, and de- ploying messaging solutions, Addison-Wesley Professional. Теоретичні та методологічні основи програмування 48 4. Kent W. (2012) Data and reality, a timeless perspective on perceiving and managing in- formation in our imprecise world. USA Tech- nics Publications, LLC. 5. Kleppman M., (2017) Designing Data- Intensive Applications: The big ideas Behind Reliable, Scalable, and Maintainable Systems, USA, O’Reilly Media, Inc. 6. Sandberg R., Goldberg D., Kleiman S., Walsh D., & Lyon B. (1985). Design and im- plementation of the Sun network filesystem. In Proceedings of the Summer, USA CA, Sun Microsystems, Inc. 7. Kalia A., Kaminsky M., & Andersen D.G. FaSST: Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Data- gram RPCs. In 12th USENIX Symposium on Operating Systems Design and Implementa- tion, (OSDI 16: Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation) (P. 185–201). 8. Wollrath A., Riggs R., & Waldo J. (1996). A Distributed Object Model for the Java System, Conference on Object-Oriented Technologies Toronto, Ontario, Canada, June 1996. 9. Dell Boomi Home. https://boomi.com, 2017. 10. Informatica Home. https://www.informatica. com/products/cloud-integration, 2017. 11. Jitterbit Home. http://www.jitterbit.com, 2017. 12. Mulesoft Home. https://www.mulesoft.com/, 2017. 13. Oracle Cloud Home. https://cloud.oracle. com/integration, 2017. 14. SnapLogic Home. https://www.snaplogic. com, 2017. 15. Frantz R.Z., Corchuelo R. (2016) On the de- sign of a maintainable software development kit to implement integration solutions. The Journal of Systems and Software, Journal of Systems and Software. Vol. 111, January 2016. P. 89–104. Одержано 20.01.2021 Про автора: Дивак Юрій Андрійович, аспірант Інституту програмних систем Національної академії наук України. Місце роботи автора: Integration Full-stack software engineer, Mediastream company. E-mail: yurii.dyvak@ukma.edu.ua Теоретичні та методологічні основи програмування 49

Analytical review of approaches to integration of software systems

Репозитарії

Схожі ресурси