Лекція 6. Інтеграція додатків і інформаційних ресурсів

Поява концепції сервісно-орієнтованої архітектури (service-oriented architecture, SOA) стало закономірним кроком на шляху пошуку розв’язання однієї з найбільш нагальних і складних проблем ІТ-індустрії – проблеми інтеграції додатків.

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

Як вирішується завдання інтеграції програм? Традиційний підхід – побудова проміжного програмного шару того чи іншого типу. Оптимальною для об’єднання різнорідних платформ і рішень виглядала технологія взаємодії розподілених об’єктів CORBA, що дозволяла інкапсулювати бізнес-логіку додатків, що виконуються на різних платформах і створених з використанням різних мов програмування, організувавши зв’язок між ними на базі строго описаних інтерфейсів. Аналогічні можливості – правда, з природним обмеженням гетерогенності – пропонувала корпорація Microsoft в рамках своєї компонентної моделі DCOM. Однак цим рішенням не вистачало універсальності; навіть застосування CORBA сильно залежало від реалізації в продуктах різних постачальників, з’являлися нові об’єктні моделі, які не підтримують CORBA, інтеграція як і раніше реалізовувалася на досить низькому рівні, практично виключаючи можливість динамічного зміни зв’язків між додатками в ході виконання. Важливо і те, що всі пропоновані засоби інтеграції фокусувалися на технологічних особливостях реалізації програм і не дозволяли враховувати специфіку бізнес-процесів, в яких ці програми використовувалися.

У той же час нові потреби бізнесу диктують і нові умови інтеграції. Динамічність ІТ-середовища, її націленість на вирішення бізнес-завдань, необхідність швидких змін у відповідь на зміну цих завдань – Ці характеристики набувають ключового значення при проектуванні або реформуванні корпоративних ІТ-інфраструктур. У цих умовах окремі, “точкові” рішення по інтеграції настільки ускладнюють і саму інфраструктуру, і процес управління нею, що стають абсолютно неприйнятними. Уявімо собі, наприклад, що в компанії існує кілька програм, кожна з яких інтегровано з усіма іншими за допомогою відповідних інтерфейсів. Якщо таких програм – n, то все буде потрібно n (n-1) інтерфейсів. З додаванням всього лише одного нового додатка з’явиться 2n нових інтерфейсів, для яких буде потрібно відповідне документування, тестування і підтримка. У прикладі на рис. 1 п’ять взаємодіючих програм породжують 20 інтерфейсів, а додавання шостого програми зажадає ще 10. При цьому доведеться вносити модифікації в код кожного з існуючих програм для обліку нових інтерфейсів і проводити відповідне тестування. Щоб уникнути цього, потрібна модель інтеграції, яка дозволить максимально спростити процес додавання нових додатків і мінімізує кількість інтерфейсів взаємодії.

Рис. 1. Пряма інтеграція додатків

Ще одна серйозна проблема – надмірність програмних компонентів і складність їх багаторазового використання. В [1] наводиться приклад програмної інфраструктури банку, що включає в себе кілька груп додатків для різних напрямків банківської діяльності, які були розроблені в рамках ніяк не пов’язаних між собою проектів. В результаті, з більшою часткою ймовірності можлива ситуація, коли одна функція (скажімо, отримання балансу по вкладу) реалізована багаторазово в системі автоматизації банкоматів, в системі підтримки філій і в системі розрахунків за кредитними картками, – навіть якщо всі ці системи використовують одні і ті ж дані про рахунок з загальної бази даних. А тепер припустимо, що банк має намір розробити нові системи, наприклад, для обслуговування клієнтів в Internet або видачі позик в режимі on-line. Розширення функціональності програмного середовища банку спричинить додаткову надмірність, якщо в цьому середовищі відсутні механізми багаторазового використання компонентів, що підтримують різні завдання бізнесу.

Всі ці інтеграційні проблеми і призвели до появи ідеї сервісно-орієнтованої архітектури (service-oriented architecture, SOA). Для вирішення цих проблем простого набору технологій вже недостатньо. Потрібен загальний, архітектурний підхід, концепція архітектури програмного середовища підприємства, в якій можлива адекватна потребам бізнесу динаміка розробки, інтеграції та експлуатації програм. Ідея SOA полягає у створенні архітектурної платформи, яка забезпечить швидку консолідацію розподілених компонентів – сервісів – в єдине рішення для підтримки певних бізнес-процесів. Різні визначення сервісно-орієнтованої архітектури сьогодні дають і аналітики, і виробники програмних систем. Вони не завжди збігаються в деталях, але загальний зміст їх єдиний – SOA пропонує новий підхід до створення розподілених інфраструктур, в яких програмні ресурси розглядаються як сервіси, що надаються через мережу.