Литвинов / Системи розподіленої обробки інформації.release

описує учасників і інструменти для кожної зі стадій. Узяті разом, ці інстру-

менти становлять повну архітектуру BPM-рішення [Khan].

Життєвий цикл BPM

8.1.2. Принципи СОА

Стратегія виконання даної вимоги (інтеграції "бізнес - інформаційна система") щодо сервісно-орієнтованої архітектури складається у використан-

ні таких принципів як: стандартизація контрактів, слабка зв'язність компоне-

нтів (loosely coupling), абстракція, повторне використання, автономність,

зменшення залежності логіки компонентів від стану й відстрочене виконання

(statelessness), побудова модулів шляхом композиції існуючих сервісів (composibility), здатність до виявлення/знаходженя ресурсів (discoverability). При цьому очікуваним ефектом є: скорочення залежності між логічними підсис-

темами, компонентами, що беруть участь в автоматизації бізнес-процесів;

можливість повторного використання одного компонента для різних цілей,

процесів; масштабованість додатка; підвищення швидкості зміни й додавання нової функціональності.

180

Центральним поняттям СОА є поняття програмного сервісу [Kaplan, 2007], який можна визначити, як деякий слабо-зв'язаний, мета-орієнтований,

у відмінності від завдання/функції, компонент, що володіє достатнім ступе-

нем автономності (незалежності від користувача й інших підсистем). При цьому автономність компоненту розуміється, як приховування від користу-

вача питань підтримки, установки, зміни компоненту, методів забезпечення його стабільної роботи. Користувач користується послугою, задаючи параме-

три й не замислюючись щодо особливості її якісного функціонування. Про-

грамні сервіси є одним з підвидів програмних агентів і відповідно включають ряд їх характеристик: реактивність, асинхронність, автономність, наявність середовища хостинга, мобільність [Martin, 1996].

Сервіс може бути також представлений як набір функціональних мож-

ливостей-послуг (capabilities), що надається компонентом. При цьому виді-

ляють дві складові: логіка-реалізація, що становить тіло сервісу, й фасад-

контракт (edge), що дозволяє забезпечити його використання.

З сервісом також пов’язане поняття точки доступу (end point) , що ви-

значає логічну адресу (URI - Uniform Resource Identifier), за якою користувач може знайти контракт. Логічна адреса далі відповідними службами транслю-

ється у IP-адресу, порт, ім’я сервісу, композиція яких ідентифікує додаток.

Робота з сервісами базується на передачі повідомлень з застосуванням стан-

дартних протоколів (HTTP, SOAP). Структура сервісу наведена на рис. 45.

Зв'язок основних принципів показаний на рис.46. Основою СОА явля-

ється стандартизація контрактів. Стандартизація базується в першу чергу на стандартах описання політик, функцій та типів (рис.47), але до цього прин-

ципу відносять також і структурованість та логічну цільність сервісів – уник-

нення порушень принципу розподілу повноважень (separation of concerns).

181

Рис.45. Структура сервісу

Кожний сервіс є цінним IT-активом (valuable asset), який відповідає стратегічним цілям підприємства, тому до розробки сервісів підходять серйо-

зно. Важливим для СОА є початок побудови системи з визначенням контрак-

тів (contract first) – контракти з’являються до реалізації компонентів додат-

ків. Контракти же визначаються на базі специфікацій -моделей бізнес-

процесів .

182

Client

End-point

Рис.47. Принцип стандартизації контрактів

Принцип абстрактності сервісів полягає у створенні агностичних іне-

роперабельних сервісів, які не тільки не залежать від платформи та засобів реалізації, але й від змін бізнес правил, процесів. Важливою складовою абст-

ракції є приховування деталей реалізації логіки сервісу, - так за оболонкою сервісу може стояти застаріле ПЗ (legacy software), множина компонентів,

пов’язаних з базою даних або ієрархія сервісів. Це забезпечує поступовий пе-

рехід підприємства до СОА, адаптуючи вже існуючі підсистеми до інтегро-

ваного середовища.

Основною ціллю СОА є створення деякого реєстру автономних норма-

лізованих сервісів (service inventory), що відповідають бізнес-функціям (essential business processes), і формування на базі композиції елементарних сер-

вісів-компонентів служб, відповідальних за автоматизацію діючих бізнес-

процесів (рис.48). Виділення таких автономних сервісів – непроста задача,

вирішення якої залежить від нормалізації бізнес-функцій, повноти описання бізнес-процесів, вірного формування контрактів. Тому існує ствердження,

що нормалізація сервісів не відповідає принципам гнучких методів розробки

(counter-agile) і цілком залежить від розробника. Важливими принципами при цьому являються розподілення відповідальності (SR – single responsibility) та

183

виділення інтерфейсів (IS – interface segregation). Автономність сервісів – ос-

нова повторного використання компонентів, легкої адаптації ПЗ до змін, під-

вищення якості, збереження коштів на розробку та підтримку ПЗ (визнача-

ються коефіцієнтом повертання інвестицій – ROI return of investments). При цьому слід відзначити, що використання нормалізованих сервісів залежить від здатності їх находження у реєстрі на замову розробника або користувача.

Такий пошук здійснюється за функціональними можливостями, класом дія-

льності, призначенням, розробником та іншими властивостями, які мають бу-

ти наданні з поставкою сервісу. Описання сервісів складають базу знань. За управління даною базою відповідає система, яка може бути доступна корис-

тувачу через локальний або публічний сервіс. Вона відповідає за класифіка-

цію і винахід (discovery) необхідного сервісу або групи сервісів у відповідь на замовлення.

Рис.48. Принцип нормалізації сервісів

Принцип щодо можливості створення композиції (composability) базу-

ється на принципах автономності та абстрактності. У зв'язку із цим розрізня-

ють наступні види сервісів: сервіси-сутності, сервіси-завдання й сервіси-

функції. Сервіс-сутність (entity service) – це сервіс, що забезпечує роботу

(functional boundary) з бізнес-сутностями, такими як пацієнт, клієнт, службо-

вець інше. Даний тип сервісу відрізняється високим ступенем повторного використання, тому що він не залежить від конкретного бізнес-процесу, але розділяється ним. Сервіс-завдання (task service) – це сервіс, пов'язаний з ви-

184

конанням певного завдання або процесу. Він має меншу здатність повторно-

го використання і застосовується як контролер композиції, що відповідає за композицію інших більш агностичних сервісів (process-agnostic services).

Сервіс-утиліта (utility service) – це сервіс, призначений для підтримки функ-

ціональності системи й не зв'язаний безпосередньо з бізнес-контекстом сис-

теми. Сервіс-утиліти становлять шар технологічно-орієнтованих сервісів

(technology-oriented service layer).

Особливе місце займають сервіси-агрегати: диригування (orchestration)

та хореографії (choreography) (рис.49 ). Сервіси диригування базуються на формальному, імперативному описі послідовності дій та умов, за якими ці дії виконуються. У якості дій, як правило, використовується взаємодія з серві-

сами завдань. Сервіси диригування складають платформу автоматизації біз-

нес-процесів, пов’язуючи сервіси бізнес-функцій у відповідному порядку.

Хореографія – декларативне формальне описання координації множини уча-

сників із зазначенням їх ролей і спостереженням за обміном повідомленнями.

Choreography

Рис.49. Сервіси диригування та хореографії

Програмні комплекси, розроблені відповідно до СОА, часто реалізу-

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

185

(SOAP, WSDL, і т.п.) сервісів. Інтерфейс компонентів СОА-програми дозво-

ляє ізолювати деталі реалізації конкретного компоненту (ОС, платформи,

мови програмування, постачальника та інше) від інших компонентів. Таким чином, СОА надає гнучкий спосіб комбінування й багаторазового викорис-

тання компонентів для побудови складних розподілених програмних компле-

ксів.

8.2. Web-сервіси

Web-сервіси застосовуються для обміну даними між сервером і клієн-

том (рис. 50) - забезпечують мережевий доступ до функціональності програ-

много додатку на базі стандартних Інтернет-технологій з використанням про-

токолів HTTP, SMTP, XML-RPC, SOAP. Слід відзначити незалежність від платформи (операційної системи, середовища розташуван-ня) та засобів реа-

лізації (мови програмування) [Tidwell, 2001],[Cerami, 2002].

Application

Web-service

Рис. 50. Схема зв’язку між клієнтським додатком і кодом програми

На теперішній час створено багато web-систем, організованих на базі простої клієнт-серверної архітектури. У цьому випадку основою сайту є про-

цес, який має доступ до локальної файлової системи зберігання документів за допомогою Uniform Resource Locator (URL), котрий визначає місце знахо-

дження документа. На рис. 51 наведена схема обробки запита клієнту зі ста-

ндартним зв'язком між браузером та web-сервером з використанням протоко-

лу Hypertext Transfer Protocol (HTTP).

Поряд з цим існує швидко зростаюча група web-систем, які пропону-

ють загальні послуги віддаленого додатку без негайної взаємодії з кінцевими

186

чені дані приходять з HTML-форми. Після завершення заповнення форми на-

зва програми і зібрані значення параметрів передаються на сервер.

DB server

Рис. 53. Принцип взаємодії додатків за допомогою CGI

Після обробки документа сервер передає його на сторону клієнта.

Приклад запиту програмі CGI [CGI] <html><head><title>Guestbook Form</title></head> <body>

<form action="post.cgi" method="POST">

Your Name: <input type="text" name="name"><br>

Email Address: <input type="text" name="email"><br>

Comments:<br>

<textarea name="comments" rows="5" cols="60"></textarea><br>

<input type="submit" value="Send"> </form>

</body>

</html>

CGI - скрипт

#!/usr/bin/perl -wT use CGI qw(:standard);

use CGI::Carp qw(warningsToBrowser fatalsToBrowser);

188

use strict; print header;

print start_html("Thank You"); print h2("Thank You");

my %form;

foreach my $p (param()) { $form{$p} = param($p);

print "$p = $form{$p}<br>\n";

}

print end_html;

На сервері, де знаходиться сайт, повинно бути дозволено виконання

CGI –скриптів, і проблема такого підходу складається в тому, що скрипт, як і будь-яка інша програма, може виконувати системні команди на сервері, що становить потенційну загрозу безпеці [CGI], [CGI2].

Наступним важливим удосконаленням є те, що сервери стали спромо-

жні обробляти документ до передачі його клієнту. Документ може містити серверний скрипт, який виконується на сервері. Результат виконання сцена-

рію відправляється разом з іншою частиною документа до клієнта. Сам скрипт не передається. Серверні сценарії формують документ, додаючи ре-

зультати виконання сценарію.

Серверна обробка web-документів все частіше потребує більшої гнуч-

кості. Багато web-сайтів організовані на трьохрівневій архітектурі, яка скла-

дається з web-сервера, сервера додатків і баз даних. Наприклад, сервер може приймати запити клієнтів, робити пошук в базі даних щодо відповідних про-

дуктів, а потім побудувати інтерактивну web-сторінку із списком знайдених продуктів.

У відповідності з принципами СОА до Web-сервісу пред’являються на-

ступні вимоги: доступність через мережу Internet або intranet; використання стандартизованої системи повідомлень на базі XML; незалежність від ОС або

189