ISSN 2225-7551

Є.В. Риндич, канд. техн. наук

Чернігівський державний технологічний університет, м. Чернігів, Україна

СЕРВІСНО-ОРІЄНТОВАНА АРХІТЕКТУРА ІНФОРМАЦІЙНИХ СИСТЕМ
У СФЕРІ НАДАННЯ ТРАНСПОРТНИХ ПОСЛУГ

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

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

Определено особенности методики сервисно-ориентированной архитектуры. Проанализировано на адекватность использование механизма SOA для информационных систем предприятий, которые предоставляют транспортные услуги. Предложено использовать архитектуру на базе веб-сервисов для предприятий, которые предоставляют транспортные услуги.

Ключевые слова: сервисно-ориентированная архитектура, информационная система, бизнес-процес, интеграция данных, сфера транспортных услуг.

The features of methodology of the service-oriented architecture are certain. It is analysed on adequacy of application of mechanism of SОА for the informative systems of companies providing transportation services. An architecture based on the use of web services for companies that provide transportation services.

Key words: service-oriented architecture, informative system, business process, integration of data, tourist sphere.

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

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

Відсутність інтегрованості приводить до того, що використання інформаційних технологій є неефективним. Це пов’язано з відсутністю архітектурних стандартів у зазначеній галузі, однак попит модернізації сучасних інформаційних систем автотранспортних підприємств стає все більш актуальною [1; 2].

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

Така зміна позиції розробників викликала в інформаційних системах потужний напрям у теорії, методах і технології розроблення систем – моделювання й управління бізнес-процесами, на основі якого були створені всі відомі ERP-системи [3].

Сучасні напрямки розвитку управління роботами зміщується в сторону управління бізнес-процесами. Бізнес-процес визначає, що має бути зроблено та встановлює відношення вхідних та вихідних даних. Такі зміни в побудовах інформаційних систем мають на меті використання сервісно-орієнтованої архітектури (SOA), а саме виділення сервіс-елементів, з яких синтезуються бізнес-процеси.

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

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

Програмні комплекси, розроблені відповідно до сервісно-орієнтованої архітектури, звичайно, реалізуються як набір веб-служб, що взаємодіють за протоколом SOAP, але існують і інші реалізації (Jini, CORBA, на основі REST).

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

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

- побудову нових бізнес-функцій;

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

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

Сервісно-орієнтована архітектура обов’язково передбачає наявність таких компонентів: постачальника, реєстру та споживача сервісів. Взаємодія між компонентами має на меті спростити пошук та доступ до сервісів [5]. Загальна схема сервісно-орієнтованої архітектури інтеграційної платформи у сфері надання транспортних послуг наведена на рис. 1.

SOA – це така архітектура додатка, в якої компоненти або сервіси, маючи погоджені загальні інтерфейси, використовують єдині правила (контракт) для визначення того, як викликати сервіси і як вони взаємодіятимуть один з одним. У цій системі поняття “клієнт” і “сервер” абсолютно ситуативні. В одному випадку додаток може працювати як клієнтський і викликати зовнішній сервіс, а деякий час після цього, він може стати постачальником сервісів під час звернення до нього іншим застосуванням з метою виконання будь-яких завдань. Якщо SOA розроблена правильно, вона здатна здійснити побудову і підтримку інтеграції, побудованої за архітектурою “клієнт-споживач” [3]. Використовуючи SOA, підприємства, що входять до загальної транспортної інфраструктури, можуть гнучко і динамічно генерувати нові сервіси, комбінуючи логіку існуючих застосувань та представляючи її за допомогою повторного використання сервісів.

 

Рис. 1. Загальна схема сервісно-орієнтованої архітектури інтеграційної платформи
у сфері надання транспортних послуг

Архітектура SOA використовується для скорочення витрат, оскільки під час створення цієї архітектури користувалися такими принципами [3]:

- архітектура, не прив’язана до якоїсь конкретної технології;

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

- незалежність організації системи від вживаних мов програмування;

- використання сервісів, незалежних від конкретних застосувань, з одноманітними

- інтерфейсами доступу до них;

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

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

Основна частина.

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

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

У завдання серверної частини входить:

- відображення положення транспортних засобів на карті;

- перерахунок та розсилка графіків руху транспорту;

- збереження і відображення історії руху транспортних засобів;

- виявлення ситуацій відхилень від маршрутів;

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

- ведення картотеки водіїв, підрахунок порушень та втрат прибутку для кожного з них;

- повідомлення диспетчера про виявлені порушення, нестандартні ситуації, втрати виручки;

- аналіз зібраної статистичної інформації для виявлення дефектів маршрутів.

Клієнтська частина виконує такі функції:

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

- динамічно синхронізувати з сервером графік руху у разі його зміни;

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

- повідомляти водія про те, скільки пасажирів зайшло на зупинці;

- відловлювати різкі стрибки у втраті палива, що є ознакою його крадіжки;

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

Здобутком України в цьому напрямку можна вважати систему transit.in.ua, яка впроваджена ТОВ «Міський диспетчерський центр» м. Дніпропетровськ у кінці 2012 року [6]. Ця система у режимі реального часу дозволяє відслідковувати маршрутні засоби на мапі міста (рис. 2).

 

Рис. 2. Інтерфейс системи transit.in.ua

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

2. Стандарти веб-сервісів, які можна використати під час створення інформаційної системи у сфері надання транспортних послуг.

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

- WSDL – мова опису сервісів;

- SOAP – протокол обміну повідомленнями;

- UDDI – універсальний формат каталогу для пошуку та інтеграції веб-сервісів;

- BPEL – мова реалізації бізнес-процесів.

Композиція веб-сервісів на основі елементарних робіт здійснюється за допомогою мови реалізації бізнес-процесів – Business Process Execution Language (BPEL). Вона з’явилася як результат об’єднання мови WSFL (Web Services Flow Language), розробленої корпорацією IBM, і мови XLANG, створеної в Microsoft. Мова розроблена на нотації XML.

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

- прийняття запиту на включення роботи у процес;

- перевірка опису й у разі збігу параметрів – підготовку позитивного відгуку на запит;

- відхилення запиту з видачею обґрунтування.

Як правило, BPEL формує потік робіт, що складається з послідовностей логічних дій або активних операцій, кожній з яких відповідає свій квадратик на діаграмі потоку робіт або функція програмного коду. При цьому можливі дві форми використання BPEL [3]:

1. Виконуваний BPEL – процес, який також розглядається як сервіс і може бути вузлом оркестрування. Програмні продукти, що реалізують виконувані BPEL-процеси, називаються BPEL-engine (двигун BPEL-процесу). Тут один виконуваний процес може включати інший, що дає ефект включення одного оркестрування (послідовності сервісів) в інший.

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

– визначає поведінку елементів організаційної структури, що підтримує процес;

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

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

Мова опису зовнішніх інтерфейсів веб-служби WSDL (Web Services Description Language) використовується для передачі від провайдера послуг до споживача. Оскільки основою цієї мови є XML (eXtensible Markup Language) – текстовий опис, то передача даних не залежить ні від платформи, ні від мови програмування. Версія WSDL 2.0 має переваги, пов’язані зі спрощеною реалізацією REST-сервісів.

SOAP (Simple Object Access Protocol) – протокол обміну повідомленнями, який також написаний у форматі XML і призначений для передачі даних із веб-сервісів. Файли SOAP, що створюються автоматично, включають дані з опису сервісів у форматі WSDL. Перевагою SOAP є те, що він може використовуватись з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP.

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

Архітектура може бути представлена у стандартному для веб-сервісів вигляді – складатися з чотирьох рівнів (рис. 3).

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

 

Рис. 3. Архітектура веб-сервісу інформаційної системи у сфері надання транспортних послуг

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

Запропоноване застосування сервісної орієнтації SОА не вимагає разових великих витрат і повного знищення звичного процесу функціонування системи, а лише приводить до більшої гнучкості та розширення функціоналу таких систем.

Список використаних джерел

1. На Чернігівщині розробляється нова Стратегія розвитку пасажирського автомобільного транспорту [Електронний ресурс]. − Режим доступу : http://monitor.cn.ua/ua/economics/4202.

2. Концепция развития городского пассажирского транспорта в городе Донецке на период до 2020 года [Электронный ресурс]. − Режим доступа : http://transport.donetsk.ua/concepcia.php.

3. Угрин Д. І. Дослідження сервісно-орієнтованої архітектури як інтеграційної платформи в туристичні сфері / Д. І. Угрин, В. В. Литвин // Вісник Національного університету "Львівська політехніка" : збірник наукових праць. Тематичний випуск "Інформаційні системи та мережі". – Львів : Національний університет "Львівська політехніка", 2011. – № 699. – С. 260-270.

4. Сервісно-орієнтована архітектура [Електронний ресурс]. − Режим доступу : http://uk.wikipedia.org/wiki/SOA.

5. Сервис-ориентированная архитектура [Электронный ресурс]. − Режим доступа : http://www.citforum.idknet.com/internet/webservice/soa/.

6. 99 % маршруток оборудованы системой GPS-контроля [Электронный ресурс]. − Режим доступа : http://gorod.dp.ua/news/76153.