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

Се́рвісно-орієнто́вана архітекту́ра (англ. 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[ред. | ред. код]

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

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

  • Використання поточних інвестицій.
  • Зменшення ризику, пов'язаного з впровадженням проектів в області автоматизації послуг і процесів.
  • Можливість безперервного поліпшення наданої послуги.
  • Скорочення числа звернень за технічною підтримкою.
  • Підвищення показника повернення інвестицій (ROI).
  • Перспективи

Джерела[ред. | ред. код]

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