9. Cервіс-орієнтована архітектура (соа)
Для того, щоб будувати сучасні і гнучкі розподілені програми, слід задовільняти наступні вимоги:
інтеграція ресурсів ПЗ вимагає початкової слабкої зв'язаності;
зв'язок повинен грунтуватися на широко відомих стандартах інтернету;
інтерфейси послуг повинні бути добре описані і загальнодоступні.
Вимоги не повинні бути пріоритетом, але їх застосування буде корисним:
ми можемо використовувати інші засоби для розробки програм;
ми можемо використовувати функціональність компаній третьої сторони, що зменшить вартість і збільшить продуктивність;
ми можемо продавати або ділитися сервісним ПЗ. Наприклад, ми можемо створити компонент про аукціон і продати його як сервісне ПЗ, а не програму.
Архітектура під назвою "сервіс-орієнтованная архітектура" задовольняє ці вимоги. Це дозволяє створювати динамічні, слабо зв'язані розподілені програми.
Зараз більшість систем будуються, грунтуючись на технологіях, які вимагають інтеграцію компонентів і середовища. Оскільки будь-яка невдача вимагає необхідність в змінах підсистем або компонентів, таке рішення проблеми збільшує витрати. Також існують обмеження на універсальну застосованість.
СОА має три головні ролі:
Постачальник послуг - це вузол (у інтернеті або інтранеті), який дає доступ до даного бізнес-компоненту з потрібною функціональністю.
Споживач послуг - використовує видалений компонент для створення власних програм. У СОА клієнт і споживач - вузли.
Оцінювач послуг - вузол мережі є сховищем описів послуг, на зразок жовтих сторінок. Творець компонентів розміщує інформацію разом з оцінювачем послуг, і клієнт може знайти ці послуги.
Малюнок 9.10.1. Архітектура СОА.
Взаємозв'язки між вузлами:
Розміщення. Постачальник послуг розміщує інформацію про його послуги, їх визначення, документацію і т.д.
Знаходження. Клієнти знаходять послуги, що знаходяться в сховищі.
Скріплення. Клієнти встановлюють зв'язок з послугою. Це вимагає авторизація.
Знаходження і скріплення може відбуватися автоматично. Наприклад, якщо програма дуже довго очікує відповіді одного провайдера, воно може переключитися на іншого провайдера.
Мережеві послуги, як реалізація СОА
Середовищем для СОА є інтернет. Там може бути знайдений кожен вузол. Зв'язок відбувається по протоколах TCP/IP, або HTTP - у вищих рівнях взаємодії відкритих систем.
Реалізація - XML веб-сервер-сервіс. Приклад реалізації СОА зображений на малюнку.
Малюнок 9.10.2. Реалізація СОА з використанням веб-сервісів.
Оцінювач послуг як веб-сервіс. Оцінювач послуг - вузловий сервер - UDDI (Universal Description, Discovery and Integration, універсальний опис, пошук і взаємодія). UDDI - це каталоги бізнес-компонентов, готових до використання.
Постачальник послуг - вузол, що надає мережеві XML веб-сервіси. Мережеві послуги надаються www-сервером (Apache або інформаційні інтернет-послуги).
Споживач послуг як веб-сервер-сервіс - вузол, який може бути зв'язаний через HTTP або SOAP, розуміє інтерфейс послуги, яку хоче використовувати, надає інструменти авторизації.
Як працюють інтернет-послуги?
Опис XML веб-сервісов.
Послідовність дій, викладених нижче, схожа у всій техніці програмістів.
Клієнти знаходять потрібну послугу в UDDI. Якщо відома адреса, файл WSDL з технічною специфікацією може бути завантажений. Всі платформи дозволяють створювати Proxy, заснований на WDL. Ідея полягає в тому, щоб заховати складність WDL і показати простий інтерфейс. Клас проксі містить список методів, які повертаються разом з своїми параметрами і типами.
Малюнок 9.10.3. Крок 1. Створення класу проксі, заснованого на WSDL.
Тепер у нас є вся інформація, потрібна для використання даного інтернет-сервісу. Мова програмування не має значення. Клас проксі дозволяє викликати видалені сервіси. Клас транслює повідомлення в повідомлення SOAP, яке зрозуміле для мережевої служби. Остання повертає відповідь у форматі SOAP і посилає її назад клієнтові. Все робиться за допомогою HTTP без потреби в постійному з'єднанні (запит/відповідь).
Малюнок 9.10.4. Крок 2. Зв'язок з мережевою службою через SOAP.