Сервісно-орієнтована архітектура

Се́рвісно-орієнто́вана архітекту́ра (англ. Service-oriented architecture, SOA) — архітектурний шаблон програмного забезпечення, модульний підхід до розробки програмного забезпечення, заснований на використанні розподілених, слабко пов'язаних замінних компонентів, оснащених стандартизованими інтерфейсами для взаємодії за стандартизованими протоколами.

Значення ред.

За словами Клайва Фінкельштейна^[en], автора інформаційної інженерії^[en], до появи концепції SOA при розробці систем відправним моментом для програмування бізнес-логіки слугували діаграми робочих потоків і блок-схеми систем. Розроблені вручну програми ретельно тестувалися, після чого впроваджувалися. Сьогодні ситуація змінилася докорінно: сучасні інструменти управління бізнес-процесами дозволяють обійтися без ручної розробки та тестування. Так, за допомогою методів моделювання можна перевіряти коректність виконання бізнес-логіки, представленої в діаграмах, а потім автоматично отримувати описи цих діаграм на XML-мовах управління бізнес-процесами.

На думку Клайва Фінкельштейна, така технологія управління бізнес-процесами є великим кроком вперед з точки зору підвищення ефективності розробки систем; за значимістю її можна порівняти із створенням наприкінці 50-х років компіляторів мови високого рівня. Дійсно, даний підхід дозволяє спростити виклик Web-сервісів з будь-якого місця розташування і їх виконання на основі бізнес-правил. Крім того, при зміні цих правил, коригується відповідна логіка в діаграмах: діаграми автоматично генеруються заново. Таким чином, закладаються передумови для переходу від повільного ручного кодування, використовуваного зараз при створенні систем, до автоматизованого. Завдяки цьому компанії зможуть реалізовувати зміни бізнес-правил за хвилини або години, а не за місяць або рік.^{[джерело?]}

Основні поняття ред.

Дуже часто становлення того чи іншого підходу супроводжується появою невірних або хибних трактувань, як це було, наприклад, з концепцією федеративного сховища даних. Не оминуло стороною це і сервіс-орієнтовану архітектуру. Так вважає представник компанії BEA Джерімі Уестерман (Jeremy Westerman). Саме тому в одній із своїх статей, присвячених SOA, він спеціально зупиняється на «проблемних місцях» і наводить докладні пояснення:

SOA не є чимось новим: IT-відділи компаній успішно створювали і розгортали застосунки, що підтримують сервіс-орієнтовану архітектуру, вже багато років — задовго до появи XML і Web-сервісів.
SOA — це не технологія, а спосіб проектування і організації інформаційної архітектури та бізнес-функціональності.
Купівля найновіших продуктів, що реалізують XML і Web-сервіси, не означає побудову застосунків згідно з принципами SOA.

Джерімі Уестерман дає наступне визначення SOA: це парадигма, призначена для проектування, розробки та управління дискретних одиниць логіки (сервісів) в обчислювальному середовищі. Застосування цього підходу вимагає від розробників проектування застосунків як набору сервісів, навіть якщо переваги такого рішення відразу неочевидні. Розробники повинні вийти за межі своїх застосунків і розміркувати, як скористатися вже наявними сервісами, або вивчити, як їхні сервіси можуть бути використані їх колегами.

SOA підштовхує до використання альтернативних технологій і підходів (таких як обмін повідомленнями) для побудови застосунків за допомогою зв'язування сервісів, а не за допомогою написання нового програмного коду. У цьому випадку, за належного проектування, застосування повідомленнь між застосунками дозволяє компаніям своєчасно реагувати на зміну ринкових умов — налаштовувати процес обміну повідомленнями, а не розробляти нові програми.

Ще донедавна термін «сервіс-орієнтована архітектура» був синонімом «Web-сервіс». SOA — виклик Web-сервісів за допомогою засобів і мов управління бізнес-процесами. SOA — це термін, який з'явився для опису виконуваних компонентів — таких як Web-сервіси — які можуть викликатися іншими програмами, які виступають клієнтами або споживачами цих сервісів. Ці сервіси можуть бути повністю сучасними — або навіть застарілими — прикладними програмами, які можна активізувати як "чорну скриню". Від розробника не потрібно знати, як працює програма, необхідно лише розуміти які вхідні та вихідні дані потрібні, і як викликати певні програми для виконання. У найзагальнішому вигляді SOA припускає наявність трьох основних учасників: постачальника сервісу, споживача сервісу та реєстру сервісів. Взаємодія учасників виглядає досить просто: постачальник сервісу реєструє свої сервіси в реєстрі, а споживач звертається до реєстру із запитом.

Для використання сервісу необхідно дотримуватися угоди про інтерфейс для звернення до сервісу — інтерфейс повинен не залежати від платформи. SOA реалізує масштабованість сервісів — можливість додавання сервісів, а також їх модернізацію. Постачальник сервісу і його споживач виявляються непов'язаними — вони спілкуються за допомогою повідомлень. Оскільки інтерфейс не повинен залежати від платформи, то і технологія, використовувана для визначення повідомлень, також не повинна залежати від платформи. Тому, як правило, повідомлення є XML-документами, які відповідають певній XML-схемі.

Дійсно, відкриті стандарти, що описують XML і Web-сервіси, дозволяють застосовувати SOA до всіх технологій і застосунків, встановлених в компанії. Як відомо, Web-сервіси базуються на широко поширених і відкритих протоколах: HTTP, XML, UDDI, WSDL і SOAP. Саме ці стандарти реалізують основні вимоги SOA — по-перше, сервіс має піддаватися динамічному виявленню і виклику (UDDI, WSDL і SOAP), по-друге, повинен використовуватися незалежний від платформи інтерфейс (XML). Нарешті, HTTP забезпечує функціональну сумісність.

Переваги використання SOA ред.

Перш ніж, перерахувати переваги використання SOA, буде доречним нагадати, що переваги бувають різні: стратегічні і тактичні. SOA має ряд переваг як стратегічних, так і тактичних.

Стратегічна цінність SOA ред.

Скорочення часу реалізації проектів, або «часу виходу на ринок».

Підвищення продуктивності.

Швидша і дешевша інтеграція застосунків і інтеграція B2B.

Тактичні переваги SOA ред.

Простіша розробка і впровадження застосунків.

Використання поточних інвестицій.

Зменшення ризику, пов'язаного з впровадженням проектів в області автоматизації послуг і процесів.

Можливість безперервного поліпшення наданої послуги.

Скорочення числа звернень за технічною підтримкою.

Підвищення показника повернення інвестицій (ROI).

Перспективи

Джерела ред.

Див. також ред.

Це незавершена стаття про програмування.
Ви можете допомогти проєкту, виправивши або дописавши її.