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



Стаття | Article    

Download

В роботі розглянуто можливості використаня сервіс-оріентованої архітектури для побудови систем виконання бізнес-процесів. Також представлено загальну математичну модель для такої системи і показано переваги сервіс-орієнтованої архітектури на прикладі бізнес-процесу описаного мовою BPEL.

Троцький Сергій Олександрович

аспірант, «КПІ» ім. Сікорського

Погорілий Юрій Анатолійович

студент, «КПІ» ім. Сікорського

Коломійчук Микита Сергійович

студент, «КПІ» ім. Сікорського

Вовк Євгеній Андрійович

студент, «КПІ» ім. Сікорського

Україна, Київ

Using a component approach in the design of the services for business processes management systems

Describes usage of service-oriented architecture for the construction of the business processes execution systems. Also presents general mathematical model for such systems and the advantages of service-oriented architecture on the example of the business process which described in BPEL language.

Key words: SOA -Service-oriented architecture, SOAP - Simple Object Access Protocol, XML- Extensible Markup Language, Web- service.

Sergii Trotskyi

Igor Sikorsky Kyiv Polytechnic Institute

Yurii Pohorilyi

Igor Sikorsky Kyiv Polytechnic Institute

Mykyta Kolomiichuk

Igor Sikorsky Kyiv Polytechnic Institute

Yevgeny Vovk

Igor Sikorsky Kyiv Polytechnic Institute

Ukraine, Kyiv

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

Загальна математична модель компоненто-базованої інформаційної системи

Задача ( Task ) – це деяка одиниця роботи (unit of work), що має на бути зроблена на протязі деякого часу, та яка має на меті обробку вхідних даних за допомогою певного алгоритму.

Компонент в SOA архітектурі – це програмний модуль що виконує одну або більше задач. Компоненти комбінуються в сервіси. Сервіси виконують певні процеси.

Архітектура програмного забезпечення інформаційної системи, яка побудована на базі компоненто – базового підходу може бути визначена за допомогою множин

- це множина компонентів системи;

- це множина бізнес процесів;

- це множина взаємозалежностей між компонентами системи;

- це множина сервісів системи;

- це множина взаємозалежностей між сервісами системи;

- це множина задач;

- це множина взаємозалежностей між задачами.

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

Формулювання проблеми та методологія

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

У загальному випадку бізнес-процес – це сукупність взаємопов'язаних заходів і завдань, спрямованих на створення певного продукту або послуги для споживачів. Бізнес-процеси виконуються в середині кожної організації, незалежно від того, формалізовані вони чи ні. Популярна сьогодні система умовних позначень (нотація) BPMN визначає скінченний набір графічних елементів для описання бізнес-процесу:

- Об'єкти потоку управління: події, дії та логічні оператори;

- З'єднувальні об'єкти: потік управління, потік повідомлень та асоціації;

- Ролі: пули і доріжки;

- Артефакти: дані, групи і текстові анотації.

Найменшою елементарною дією в бізнес-процесі є завдання (task). З точки зору автоматизації бізнес-процесів, саме завдання є головним цільовим об'єктом. Інші елементи пов’язані з розв’язанням задач оркестрування, координування, та ін. Для цих задач успішно застосовують мови виконання бізнес-процес, наприклад, BPEL.

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

Загальна структура бізнес-процесу складається з декількох етапів, кожен з яких може бути розбитий на більш фундаментальні одиниці, які ми називаємо Задача (Task), які можуть бути використані різними процесами. Послідовність виконуваних дій ( W ) може бути зображена, як об’єднання різних бізнес процесів ( P ):

Кожна задача є незалежною одна від одної:

для будь – яких i та _j_.

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

Процес можливо описати наступним чином:

Таким чином можливо побудувати матрицю взаємодія процесів та задач

де 1 відповідає така конфігурація коли процес включає дану задачу, а 0 відповідає конфігурація коли дана задача не включається до складу даного процесу [5].

Бізнес-процеси виконуються всередині кожної організації, незалежно від того, формалізовані вони чи ні. Популярна сьогодні система умовних позначень (нотація) BPMN визначає скінченний набір графічних елементів для описання бізнес-процесу [1]:

- Об'єкти потоку управління: події, дії та логічні оператори;

- З'єднувальні об'єкти: потік управління, потік повідомлень та асоціації;

- Ролі: пули і доріжки;

- Артефакти: дані, групи і текстові анотації.

На Рис. 1 у нотації BMPN 2.0 зображений спрощений узагальнений бізнес-процес. Він складеться з двох учасників: деякого програмного забезпечення (Customer system) та оператора (Operator), що взаємодіє з ним. У наведеному процесі дії, що автоматично виконуються системою (Auto-task) межують з діями, що потребують втручання людини (User task). При цьому, логіка виконання системних дій є невід’ємною частиною програмного забезпечення, що відповідає за виконання бізнес-процесу. Процес, побудований таким чином, може добре виконувати покладені на нього функції та має як переваги, насамперед, простоту та повний контроль над системою, так і недоліки, серед яких найбільш суттєвими є статичність процесу, висока складність розробки, складність підтримки та модифікації, складність повторного використання логіки виконання системних дій.

Рис. 1. Приклад бізнес-процесу

Частково усунути недоліки описані вище можна за рахунок впровадження сервіс-орієнтованої архітектури. Сервіс-орієнтована архітектура (Service-Oriented Architecture, SOA) становить собою стиль створення архітектури ІТ, спрямований на перетворення бізнесу в ряд пов'язаних сервісів –стандартних бізнес-задач, які можна при необхідності викликати через мережу [2]. Це може бути Інтернет, локальна мережа або географічно розподілена мережа, яка об'єднує різні технології і поєднує сервіси так чином, ніби вони встановлені на одній локальній машині. Для виконання певного бізнеc-завдання можна об'єднувати множину таких сервісів. Це дозволяє компаніям швидко адаптуватися до змін умов і вимог ринку.

Визначимо Web-сервіси як автономні, модульні програми, призначені для реалізації бізнес-процесів. Побудова і надання Web-сервісів спираються на ряд галузевих стандартів: WSDL (для описання сервісів), UDDI (для інформування та публікації); SOAP (для обміну повідомленнями) [3]. Ці специфікації не залежить від платформи і мови, завдяки чому користувачі

можуть пов'язувати різні компоненти з різних організаційних структур. Розглянемо сучасний підхід, при якому існуючий бізнес-процес буде виконуватися за допомогою інформаційної системи управління бізнес-процесами. А сам бізнес-процес, за виключенням логічних операцій та ручних дій, має підтримуватися існуючими Web-сервісами, задовольняючи основоположні принципи SOA.

Модифікований бізнес-процес, що задовольняє умови описаного підходу та характеризується такими перевагами:

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

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

- можливість використання Web-сервісів третіх сторін, що зменшує час на розробку системи;

- можливість повторного використання Web-сервісів у різних частинах та процесах системи.

В даному процесі логіка виконання системних дій винесена у Web-сервіси, що можуть бути реалізовані будь-якою мовою програмування та за допомогою будь-яких технологій. В основному потоці при цьому лишаються користувацькі дії та дії виклику Web-сервісів. Таким чином, ми можемо повністю перекласти виконання основного потоку на один з серверів виконання бізнес-процесів. Промисловим стандартом у даній галузі є Oracle BPEL Process Manager Server [4], що є сервером виконання бізнес-процесів, описаних мовою виконання бізнес-процесів BPEL (Business Process ExecutionLanguage). Головним недоліком, описаного вище сучасного і досить розповсюдженого підходу є необхідність ручного пошуку Web-сервісів та їх жорстка прив’язка до кожної дії бізнес процесу.

При цьому, за будь-яких змін у структурі Web-сервісу або виходу його з ладу – вся система будe непрацездатною. Для уникнення такої ситуації і надання більшої незалежності системам управління бізнес-процесів підприємства пропонується побудувати окрему систему, яка візьме на себе задачу пошуку та композиції Web-сервісів для підтримки будь-якого бізнес-процесу та зведе до мінімуму необхідність ручного втручання в бізнес-логіку процесу.

Висновок

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

Перелік посиланнь

$1.$ Information technology – Object Management Group Business Process Model and Notation, ISO/IEC 19510, 2013;

$2.$ Мохаммед И. Мабрук. Краткие основы SOA // IBM Developer Works [Електронний ресурс]. –2010.–Режим доступу до ресурсу: http://www.ibm.com/developerworks/ru/edu/ws\-soa\-ibmcertified/index.html

$3.$ Web Services Architecture – W3C Working Group Note 11. – The World Wide Web Consortium (W3C) [Електронний ресурс]. –2004. – Режим доступу до ресурсу: http://www.w3.org/TR/ws\-arch/.

$4.$ ORACLE Data Sheet – ORACLE BPEL Process Manager – Режим доступу: http://www.oracle.com/technetwork/middleware/bpel/overview/ds\-bpel\-11gr1\-1\-134826.pdf;

$5.$ McIlraith S. Semantic Web services /McIlraith S., Son T.C., Zeng H. // IEEE Intelligent Systems. Special Issue onthe Semantic Web. – 2001. – Vol. 16. – N. 2 – P. 46-53

Jun 15, 2017