Підходи до композиції сервісів в семантичному WEB середовищі

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

Full description

Saved in:

Bibliographic Details
Date:	2007
Main Author:	Дерецький, В.О.
Format:	Article
Language:	Ukrainian
Published:	Інститут програмних систем НАН України 2007
Subjects:	Інформаційні системи
Online Access:	https://nasplib.isofts.kiev.ua/handle/123456789/290
Tags:	Add Tag No Tags, Be the first to tag this record!
Journal Title:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Cite this:	Підходи до композиції сервісів в семантичному WEB середовищі / В.А. Дерецький // Пробл. програмув. — 2007. — N 2. — C. 85-96. — Бібліогр.: 23 назв. — укp.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	nasplib_isofts_kiev_ua-123456789-290
record_format	dspace
spelling	Дерецький, В.О. 2008-02-22T18:44:20Z 2008-02-22T18:44:20Z 2007 Підходи до композиції сервісів в семантичному WEB середовищі / В.А. Дерецький // Пробл. програмув. — 2007. — N 2. — C. 85-96. — Бібліогр.: 23 назв. — укp. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/290 Технології мережних сервісів дозволяють програмним системам забезпечувати гнучкий і динамічний механізм інтеграції автономних систем програмного та інформаційного забезпечення в розподіленому мережному середовищі з ціллю вирішення задач користувача. Розробка та моделювання застосувань та інструментів для напів- та автоматичної композиції і аналізу сервісів потребує врахування їх семантичних і динамічних властивостей. Представлено стислий огляд основних понять, моделей і засобів, що лежать в основі композиції сервісів. uk Інститут програмних систем НАН України Інформаційні системи Підходи до композиції сервісів в семантичному WEB середовищі Article published earlier
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
title	Підходи до композиції сервісів в семантичному WEB середовищі
spellingShingle	Підходи до композиції сервісів в семантичному WEB середовищі Дерецький, В.О. Інформаційні системи
title_short	Підходи до композиції сервісів в семантичному WEB середовищі
title_full	Підходи до композиції сервісів в семантичному WEB середовищі
title_fullStr	Підходи до композиції сервісів в семантичному WEB середовищі
title_full_unstemmed	Підходи до композиції сервісів в семантичному WEB середовищі
title_sort	підходи до композиції сервісів в семантичному web середовищі
author	Дерецький, В.О.
author_facet	Дерецький, В.О.
topic	Інформаційні системи
topic_facet	Інформаційні системи
publishDate	2007
language	Ukrainian
publisher	Інститут програмних систем НАН України
format	Article
description	Технології мережних сервісів дозволяють програмним системам забезпечувати гнучкий і динамічний механізм інтеграції автономних систем програмного та інформаційного забезпечення в розподіленому мережному середовищі з ціллю вирішення задач користувача. Розробка та моделювання застосувань та інструментів для напів- та автоматичної композиції і аналізу сервісів потребує врахування їх семантичних і динамічних властивостей. Представлено стислий огляд основних понять, моделей і засобів, що лежать в основі композиції сервісів.
issn	1727-4907
url	https://nasplib.isofts.kiev.ua/handle/123456789/290
citation_txt	Підходи до композиції сервісів в семантичному WEB середовищі / В.А. Дерецький // Пробл. програмув. — 2007. — N 2. — C. 85-96. — Бібліогр.: 23 назв. — укp.
work_keys_str_mv	AT derecʹkiivo pídhodidokompozicííservísívvsemantičnomuwebseredoviŝí
first_indexed	2025-11-27T05:17:51Z
last_indexed	2025-11-27T05:17:51Z
_version_	1850797981361504256
fulltext	Інформаційні системи © В.А. Дерецький, 2007 ISSN 1727-4907. Проблеми програмування. 2007. № 2 85 УДК 681.3 В.А. Дерецький ПІДХОДИ ДО КОМПОЗИЦІЇ СЕРВІСІВ В СЕМАНТИЧНОМУ WEB СЕРЕДОВИЩІ Технології мережних сервісів дозволяють програмним системам забезпечувати гнучкий і динамічний механізм інтеграції автономних систем програмного і інформаційного забезпечення в розподіленому мережному середовищі з ціллю вирішення задач користувача. Розробка та моделювання застосувань і інструментів для напів та автоматичної композиції і аналізу сервісів потребує врахування їх семантич- них і динамічних властивостей. Ця робота представляє короткий огляд основних понять, моделей і за- собів, що лежать в основі композиції сервісів. Вступ Парадигма мережних сервісів спря- мована на забезпечення побудови та гнуч- кої, динамічної взаємодії різнорідних сер- вісів у мережі. Мережний сервіс – це про- грамна система яка ідентифікується URL, має інтерфейс який використовує засо- бами XML. Сервіс може бути доступним іншим програмним системам. У свою чер- гу ці системи можуть взаємодіяти з ме- режним сервісом (W3C) [1]. Модель мережного сервісу тради- ційно складається з трьох частин, постача- льника сервісу, реєстратора сервісу і кори- стувача сервісу. Постачальник сервісу створює або пропонує мережний сервіс, він же описує мережний сервіс у стандарт- ному форматі XML і публікує його в центральній службі реєстрації. Служба містить додаткову інформацію про поста- чальника сервісу, наприклад, адреса і кон- тактні реквізити компанії яка забезпечує сервіс та інші технічні деталі сервісу. Ко- ристувач сервісу отримує інформацію від служби реєстрації і використовує отрима- ний службовий опис, щоб зв'язати сервіс з іншими сервісами, або виконати визначені функції сервісу. Для того, щоб досягти коректної комунікації сервісів, що виконуються на різних платформах і написаних на різних мовах програмування, потрібні стандарти. Створені стандарти SOAP, WSDL, BPEL та інші, розроблені технології та засоби фі- рми IBM – WebSphere Toolkit, фірми Sun- Open Net Environment and JiniTM Network technology, фірми Microsoft-.Net та фірми Novell-One Net initiatives, HP має розробку e-speak, фірма BEA-WebLogic Integration та багато інших [2]. Окремі зусилля спря- мовані на дослідження та створення над- будови до зазначених стандартів та засо- бів, включаючи такі як DAML-S/OWL-S [3–5], які спрямовані на забезпечення під- вищення рівня інтелектуальності сервісів, зокрема, автоматичного пошуку, автома- тичної композиції, забезпечення ресурсами та моніторинг веб-сервісів, що спільно працюють для досягнення визначених ко- ристувачем цілей. Композиція веб-сервісів обумов- лена ситуацією, коли запит клієнта немож- ливо виконати єдиним сервісом, але мож- ливо виконати за допомогою об'єднання певних доступних сервісів у мережі. Окремі задачі композиції сервісів можна сформулювати таким чином: визначити моделі та методи для мо- делювання мережних сервісів та їх компо- зиції; визначити моделі та методи для пі- дтримки автоматизованої та автоматичної композиції; визначити моделі та методи для за- безпечення управління складовими мере- жних сервісів у процесі їх виконання; забезпечити поєднання новітніх пі- дходів та засобів з існуючими стандартами мережних сервісів. Мета цієї роботи – огляд моделей та засобів, що становлять основу композиції сервісів та пов’язаних з нею задач. Для виконання запиту користувача сукупністю мережних сервісів їх перш за все необхідно знайти серед чисельної кіль- кості сервісів у мережі та далі забезпечити Інформаційні системи 86 управління і координацію їх виконання. Управління взаємодією сервісів, або орке- стровка, має забезпечуватись потоками ін- формації, що міститься в повідомленнях, якими обмінюються сервіси. Загальну модель композиції серві- сів, можна представити у трьох вимірах, кожен з яких має свою метрику [6]. Вимір складності композитного сервісу визначає інформаційну місткість мов і моделей представлення сервісу. Наприклад, мова OWL-S в цьому вимірі має не високу міру, тому що засобами цієї мови сервіс опису- ється тільки параметрами вхідної та вихід- ної інформації. Мова WSDL, що описує структурну інформацію сервісу засобами XML, більш інформативна, але також ви- користовує тільки вхідну і вихідну інфор- мацію. Другий вимір описує внутрішню структуру сервісів на рівні процесів та представляється такими моделями, як BPEL, CSP і р-Calculus, модель Mіля, Рим- ська модель, мережі Петрі [7–10]. Ці мо- делі описують стани сервісу і відповідно послідовність активностей сервісу. Третій вимір – це здатність описувати “семан- тику”. В цьому вимірі мова OWL–S описує властивості сервісу на рівні входів та ви- ходів, а також конкретизує, як сервіс взає- модіє з абстрактною моделлю “реального світу” [11]. Представлення сервісів у тако- му «кластері» моделей робить вищезазна- чені засоби дуже потужними. У роботі розглянемо деякі з перелі- чених стандартів та моделей, спрямованих на вирішення задач композиції сервісів. Робота структурована таким чином. Розділ один містить огляд особливостей окремих стандартів, які використовуються в зада- чах композиції мережних сервісів. Розділ два містить опис задач та підходів до ком- позиції мережних сервісів. Розділ три міс- тить опис підходів до моделювання та ана- лізу автоматичної композиції мережних сервісів з використанням OWL-S та PSL моделей. Розділ чотири містить опис мо- делей, що лежать в основі автоматичної композиції. Розділ п’ять містить стислий підсумок та напрямок подальших дослі- джень моделей, методів композиції та ана- лізу мережних сервісів. 1. Особливості стандартів мережних сервісів Для розуміння парадигми мережних сервісів у контексті мети композиції роз- глянемо систему стандартів. Основна при- чина їх створення, як наприклад, SOAP і WSDL, полягає в забезпеченні певного ступеня гнучкості при об'єднанні мереж- них сервісів для створення більш складних комбінацій з урахуванням динаміки сере- довища. Основна мета впровадження стан- дарту UDDI – створення засобів, які мають забезпечити автоматизований пошук і, тим самим, полегшити створення складо- вих для композиції мережних сервісів. Стандарт BPEL забезпечує основу для ру- чної специфікації композиції мережних сервісів, використовуючи процедурну мо- ву, яка забезпечує координування активно- стей мережних сервісів. Більш потужні можливості мереж- них сервісів створюються шляхом залу- чення засобів DAML-S, OWL-S [11]. Ме- та використання цих засобів полягає в за- безпеченні зручних для читання машиною описів мережних сервісів, які дозволять автоматизувати пошук, ведення перегово- рів, ініціювання та виконання сервісів, здійснювати моніторинг сервісів у проце- сі їх активності. Мова OWL-S – мова онто- логій, що використовується для опису ме- режних сервісів у термінах їх входів, вихо- дів, передумов і умов отримання результа- тів, а також процесу виконання. Важливим в цьому стандарті є те, що OWL-S забезпе- чує формальний механізм для моделюван- ня ”реального світу” і опису того, як взає- модіють між собою окремі мережні серві- си. Стандартами також забезпечуються механізми для моделювання специфікації сервісів у нотації OWL-S. Модель існуючих стандартів мере- жних сервісів представляють шаровою структурою, яку показана на рис. 1. Мере- жні сервіси взаємодіють за допомогою пе- редачі повідомлень у форматі XML з ви- користанням типів. Стандарт SOAP вико- ристовується як протокол комунікації і пі- дпису для мережних сервісів, які визначає Інформаційні системи 87 стандарт WSDL. Функціональні описи ме- режних сервісів визначаються з викорис- танням вищих горизонтальних стандартів, наприклад, таких як, BPEL, WSCL, BPML, OWL-S. Запит XML і мережні рівні стандар- тів забезпечують основу для інтероперабе- льності або взаємодій між сервісами. Базо- вим стандартом для опису кожного серві- су є мережна мова опису сервісу WSDL [1]. Стандарт WSDL описує мережний сервіс через набір зовнішніх операцій. Во- ни можуть бути представлені через повід- омлення, або описом множини повідом- лень, які можуть бути посланими або отриманими сервісом. WSDL конкретизує “реакцію” при отриманні повідомлення. Якщо реагуюча дія оголошена “односто- ронньою”, сервіс не повертає відповідь, інакше він діє за правилом «запит- відповідь». Тип повідомлення, який повер- тається, також декларується. Таким чином описуються дії, які посилають повідом- лення, що виходять від сервісу. Дії “опо- віщення” посилають повідомлення без очі- кування відповіді, водночас як «дія опи- тування» чекає відповіді, з типом відпові- ді, що конкретизується цією дією. Повід- омлення, що надходять, та відповіді визна- чаються в конкретній XML схемі, яка ви- користовується в повідомленнях сервісу. Стандарт WSDL можна розглядати як про- довження традиційних засобів, що специ- фікують вхід-вихід у розподіленому обчи- сленні до peer-to-peer структур [12]. Сервіс у даному випадку розглядають і як сервер (через реагуючі дії), і як клієнт (через упе- реджуючі дії). Модель сервісів, що викладена за- собами WSDL, по суті не містить опису станів виконання сервісу. Стандарт WSDL 2.0 пропонує обмежену нотацію стану, яка дозволяє специфікувати визначені зразки повідомлень, які сервіс має задовольнити. Поки що внутрішній стан сервісу не ви- значається, але деяким режимам при вико- нанні сервісу потрібно контролювати цей стан (наприклад, щоб взаємодіяти корект- но з іншими сервісами). Мова WSCL [13] призначена для визначення вхідного та ви- хідного повідомлення сервісу, за суттю є обмеженим кінцевим автоматом над азбу- кою типів повідомлень. Такий автомат у контексті сервісів називається розмовою. Необхідно зазначити, що WSCL надзвичайно добре співпрацює з WSDL. Опис WSDL разом з переговорами сервісів WSCL використовують семантику сервісу, але тільки на період, коли зберігається стан внутрішнього виконання сервісу («короткою пам’яттю»). 1. Відкриті стандарти та засоби, що покладені в основу архітектури SOA Пошук (Discovery) Хореографія (Choreography) Композиція (Composition) Опис сервісу (Individual Service Description) Запит, повідомлення (Payload Messaging) Мережа (Network) UDDI WS- Choreography BPEL4WS OWL-S ServiceModel WSCL WSDL OWL-S ServiceProfile SOAP Протоколи взаємодії з сервісами HTTP, SMTP, FTP etc. Протоколи передачі даних 3GPP IMS SIP Інформаційні системи 88 Стандарти WSDL і WSCL тільки визначають мережні сервіси. Для компо- зиції сервісів необхідна мова на відповід- ному рівні абстракції. Мова BPEL розроб- лена як для «ручного» програмування ме- режних сервісів, так і для їх специфікації. Ідентифікують дві топології сервісів: “peer-to-peer” – кожен з кожним, і “hub- and-spoke” – з медіатором (посередником). Медіатори – це сервіси-посередники, які забезпечують координацію активностей інших мережних сервісів. Первинна мета BPEL була такою, щоб забезпечити мову для конкретизації поведінки сервісу посе- редника, а не як засіб, що призначений для універсального програмування. У противазі до BPEL, WS- хореографія [13] намагається конкретизу- вати на глобальному рівні спосіб поведін- ки складових сервісів. WSCDL робить на- голос на аспектах “хореографії”: ролі сер- вісів, інформації, що передається між сер- вісами, каналами, які забезпечують потоки інформації. У вершині стандартів визначений стандарт UDDI, який забезпечує реєстра- цію сервісів у різних застосуваннях [2]. Сервіси, що зареєстровані, можуть бути знайденими, якщо їх реєстрація забезпече- на цим стандартом. 2. Задачі та моделі композиції сервісів Ідентифікують такі проблеми ком- позиції сервісів. Координація мережних сервісів. Ін- фраструктура мережного сервісу задово- льняє вимогам простої взаємодії мереж- них сервісів. Але для композитного сервісу та складних сервісних застосувань необ- хідно координувати послідовність опера- цій, що виконуються різними сервісами для того, щоб гарантувати коректне та на- дійне їх спільне виконання. Потрібні нові протоколи і абстрактні моделі, які забезпе- чать точну координацію сервісів. Необ- хідно забезпечити моделювання і спрости- ти розробку композитних мережних серві- сів у частині їх координації. У цьому на- прямку спрямовані зусилля виробників на створення стандартів, наприклад, WS- координація фірми IBM або WS-CF фірми Sun [14–16]. Управління транзакціями взаємодії сервісів. Для реалізації схеми координації сервісів застосовують протоколи управ- ління транзакціями (WS-транзакції), які забезпечують короткотривалі операції, які викликані атомарними процесами, такими, що забезпечують довготривалі операції, що викликані бізнес процесами. Проблема полягає у тому, що в разі виконання довго- тривалої операції не завжди можливо га- рантувати такі властивості композитного сервісу як атомарність, цілісність і стій- кість виконання операцій. У цьому сенсі необхідно розширити можливість прото- колу транзакції. Наприклад, будувати WS- транзакції щодо схеми WS-координації для протоколів централізованої та одноранго- вої транзакції [14]. Моделі активності сервісу опису- ють приховані та явні транзакції між ста- нами сервісу. Для моделювання транзак- цій, використовуються властивості акти- вації, які описують засоби запуску транза- кцій, властивості операції які конкретизу- ють результат аварійного завершення сер- вісу і властивості резервуваня ресурсів протягом даного часу. У цьому напрямку розроблені абс- трактні моделі активності сервісу та моде- лі завершення, вони містять операції ком- пенсації дій у випадку аварійного завер- шення виконання. Наприклад, виклика- ється функція, яка відміняє виконання сер- вісу або резервування ресурсу. Контекст взаємодії сервісів. Тер- мін контекст має багато визначень. Щодо мережних сервісів, контекст визначається як деяка додаткова інформація, яка вико- ристовується мережним сервісом або кіль- кома сервісами, щоб забезпечити необхід- ну поведінку при виконанні сервісу. Кон- текст може містити інформацію, напри- клад, ім'я користувача, адреса, розташу- вання, пристрої, які використовуються, програмне забезпечення, засоби комуніка- ції тощо. Контекст може визначати сере- довище виконання сервіса та розширюва- тися новими типами інформації у будь- який час (динаміка середовища) без змін інфраструктури композитного сервісу. Інформаційні системи 89 Стандарт WS конкретизує контекст у час- тині його сумісного використання сервіса- ми та засоби управління контекстом [16]. Моделювання розмови. Модель роз- мови забезпечує динамічне зв'язування сервісів, створення схеми композиції сер- вісу, перевірку коректності композиції сервісу. Для реалізації розмови мережних сервісів використовуються засоби WSCL (Web Services Conversation Language), WSCI специфікація (Web Service Choreog- raphy Interface), а також WS-координація і WS-транзакції. Розроблені абстракції мо- делюються взаємодії сервісів, наприклад, з використанням машин Миля [6, 16–18]. Взаємодія здійснюється через асинхронні повідомлення з підтримкою черг повідом- лень. Контроль за виконанням сервісів. Моніторинг. Засоби визначення стану композитного сервісу в процесі його вико- нання дають змогу втрутитися в процес виконання з метою забезпечення корект- ності та надійності виконання сервіса що- до зміни середовища. Відрізняють центра- лізоване і розподілене виконання компо- зиційних веб-сервісів. Централізоване ви- конання подібне парадигмі клієнт-сервер. У даному випадку сервер є центральний планувальник, який контролює процес ви- конання складових сервісів. Наприклад, засоби e-flow працюють за принципами централізованого планування [19]. Розподілена парадигма припускає, що зв’язані мережні сервіси розділяють контекст їх виконання. Кожний з хостів, на якому виконується сервіс, має власного координатора, який співпрацює з коорди- наторами решти хостів, щоб гарантувати правильний порядок виконання складових сервісів. Використовується також гібридна форма, яка включає розподілену та централізовану парадигми управління. В цьому випадку сервіс може бути коорди- натором, та контролювати не один, а на- бір композитних мережних сервісів. Пошук мережних сервісів. Для по- шуку мережних сервісів пропонуються моделі, засновані на обмеженнях основної моделі пошуку мережних послуг – UDDI. Стандарт UDDI містить тільки функціона- льні характеристики і в загальному випад- ку не повністю використовуються. Розши- рення існуючої моделі пошуку здійсню- ється шляхом додавання додаткових сут- ностей сервісу. В цьому випадку процес публікації, пошуку і зв'язування мережно- го сервісу такий самий, але збільшуються можливості пошуку. Коли користувач шу- кає сервіс, він може крім функціональних характеристик використати додаткову ін- формацію і отримати більш релевантний результат пошуку. Модель специфікації сервісу міс- тить тако ж якісні параметри сервісу, які використовуються для пошуку: маштабо- ваність; ємність; потужність (час відповіді, затримка, пропускна здатність); надій- ність; гнучкість; виключення; точність; спосіб підтримки транзакцій; стандарти, що підтримуються; стабільність; вартість; повнота; безпека (аутентифікація, конфі- денційність, можливість трасування, ау- дит, криптування даних, безвідкатність, тощо). Якісні параменти сервісу орієнто- вані на застосування, що побудовані на P2P архітектурах. 3. Підходи до композиції сервісів Умовно підходи до композиції сер- вісів розділяються на два основних класи – статичний і динамічний. Статичний підхід до композиції є еквівалент ручної компо- зиції, яка виконується на етапі проекту- вання сервісу. Динамічні стратегії компо- зиції мережних сервісів використовують час. Розрізняють п'ять категорій компо- зиції: що орієнтується на модель і на біз- нес-правила, декларативна, автоматична і семантичних веб-сервісів композиції; Статична та динамічна компози- ція сервісів. Статична композиція викорис- товується на етапі проектування, коли плануються архітектура і проект системи. Вибираються компоненти, які зв'язуються разом, далі вони компілюются і розгорта- ються для виконання. Такий підхід відмін- но працює доти, доки компоненти сервісів не змінюются. Такі засоби як Biztalk фірми Інформаційні системи 90 Microsoft і WebLogic фірми Bea – це при- клади статичних засобів композиції. Якщо бізнес-процеси зміюються, надають нові послуги або замінюють старі, можуть виникнути несумісні випадки. У такому разі, це веде до зміни архітектури програмного забезпечення й необхідності використовувати інші сервіси або навіть замінити систему. В ідеальному випадку процеси сер- вісу мають прозоро адаптуватись до сере- довища, яке змінюється, до вимог середо- вища та користувача з мінімальним руч- ним втручанням. Розвинутою платформою яка сфо- кусована на динамічну композицію серві- сів є засоби Web Services Composition Platform фірми Sun, засоби e-flow фірми НР та інші [15, 17]. Композиція сервісів, що заснована на моделях управління (Model driven service composition). Процесс розробки композит- ного сервісу можливо представити чотир- ма етапами: визначення сервісу, плануван- ня, конструювання, виконання. Початковою фазою визначення сер- вісу є абстрактна метамодель сервісу, яка моделює компоненти сервісу та відношен- ня між ними. Цілями такого моделювання є вибір елементів композитного сервісу та правил їх композиції. Далі композиція сервісу зосереджу- ється на формуванні моделі управління потоками робіт. Композиція сервісів, яка заснована на бізнес-правилах. Вона визначається шляхом додавання бізнес-правил, що рег- ламентують: перед- та після- умови; опис подій, що мали місце при виконанні про- цесів композиції сервісу; потоку процесів; визначення та блокування активностей; визначення повідомлень, що містять вхід- ну та вихідну інформацію; опис ролей у процесі композиції сервісів. Правила композиції сервісів мож- ливо моделювати з використанням мови ОСL (Object Constraint Language). Бізнес- правила можна класифікувати таким чи- ном: • структурні правила для формування процесів та структури; • правила для планування пріоритету процесів у композиції; • правила управління даними та повід- омленнями; • правила поведінки для управління процесами та забезпечення цілісності композитного процесу; • правила використання ресурсів, ви- бору сервісів, провайдерів; • правила для визначення виключень у поведінці сервісів; • правила ролей для управління учас- никами, залученими у сервісі; • правила повідомлення для регулю- вання використовування інформації; • правила для управління поведінкою композиції сервісу відповідно щодо очікуваних або непередбачених подій та інші. Для опису абстракції високого рівня використовують мову UML (Unified Modelling Language), яка забезпечує опис бізнес-процесів, засоби підключення до інших стандартів, таких як BPEL4WS. Для формування бізнес-правил та опису потоку процесів використовується мова OCL, за- собами якої описуються умови вибору сервісів та їх зв’язування, формування структури композитного сервісу і форму- вання плану композиції сервісу. Декларативна композиція сервісів. Більшість підходів засновані на тому, що спочатку мають бути створені бізнес- процеси. Декларативний підхід суттєво відрізняється від підходів, що засновані на бізнес-правилах та має дві фази: початкова фаза полягає в визначенні цілей компози- ції та конструювання планів для кожної цілі. Наступна фаза полягає у тому, що для кожного плану здійснюється пошук відпо- відних сервісів та будується схема потоку робіт. Перша фаза реалізується на основі PDDL (Planning Domain Definition Len- guage) та засобів XML Web services Re- quest Language, які мають забезпечити ма- шино читані семантичні об’єкти та специ- фікацію абстракції поведінки сервісу. На- ступна фаза може бути реалізована на ос- нові існуючих мовних засобів моделюван- ня таких як BPEL. Інформаційні системи 91 З точки зору архітектури деклара- тивний підхід потребує перегляду концеп- ції опису сервісів та реєстру сервісів. На- приклад, засоби WSDL не забезпечують опис необхідних атрибутів сервісу, а засо- би UDDI не містять інформацію про те, що робить сервіс. Цільовий, або декларатив- ний підхід забезпечується мовою опису композитного сервісу, яка відображає за- пити користувачів, визначає нові типи ре- сурсів, функції та їх відносини на основі унікальних імен URI. Для реалізації тако- го підходу необхідно розробити модель координації сервісів та універсальний про- токол взаємодії. Автоматична композиція сервісів. На відміну від ручної композиції сервісів, автоматична композиція потребує викори- стання онтологій [16]. Відповідно щодо сервісів, онтологія визначається, як мно- жина об’єктів, які розділяють ту ж саму предметну область, та правила, за якими сервіси можуть бути описані та доступні. Онтологічні мови, такі як RDF, DAML-S (DARPA Agent Markup Language for Web services), DAML+OIL, або OWL (Ontology Web Language) забезпечують формальні специфікації і можуть описувати значення для складних класів властивостей. Засоби DAML-S забезпечують механізм для онто- логічної організації сервіса. В якості типів онтологій, необхідних для композиції сер- вісів є такі: метрик, одиниць виміру, оди- ниць коштів, властивостей, методів та інші. Модель автоматичної композиції сервісу потребує семантичного опису сер- вісу щодо його можливостей до взазаємо- дії [20]. WSDL не забезпечує семантичного опису сервісу. На рис. 2 показані розши- рення онтології сервісу семантичними ха- рактеристиками. Світлі об’єкти визнача- ють існуючі характеристики, сірі об’єкти визначають додаткові семантичні характе- ристики сервісу. Операції сервісів, що містяться у вхідних та вихідних повідомленнях, ви- значаються своїм найменуванням та інши- ми характеристиками. Після розширення онтології семантичними характеристиками стає можливим використати її у моделі композиції сервісів. Для цього вводять синтаксичні та семантичні правила. Синтаксичні правила визначають спосіб композиції сервісу. Вважають, що два сервіси є придатними до композиції, коли, з одного боку, кожен клієнт або сер- вер на яких розміщені сервіси, мають бути зв’язані каналами зв’язку, а з другого боку сервіси мають бути погоджені з відповід- ним транспортним протоколом обміну по- відомленнями. Семантичні правила забез- печують композиційність повідомлень, композиційність операційної семантики, якісну композиційність та композиційність надійності. Композиційність повідомлень, що надходять від клієнта, заснована на визна- ченні типів повідомлень, які використову- ються в параметрах запуску сервіса і ма- ють бути сумісними. Повідомлення суміс- ні, якщо вони сумісні за типами даних. Операційна композиційність має місце тоді, коли предметні області інтере- сів сумісні або синонімічні і, якщо операції забезпечують ті ж сімі характеристики. Якісна композиційність має місце коли сервіси мають тіж самі якісні харак- теристики, наприклад, безпеки або прав доступу до ресурсів. Для композиції сервісів вводять поняття схеми композиції, яка забезпечує композиційну надійність. Композиційна схема зв’язана з композиційним сервісом та використовується для порівняння дода- ткових значень. Наприклад, два незалежні сервіси, такі як замовлення на видання книжок та замовлення авіаквитків можуть бути композитними в разі, коли автори книг замовляють квитки для перельоту на місце їх видання для узгодження справ. Процес автоматичної композиції включає наступні процедури: специфікації, розмітки, вибору, генерації. Для цього ви- користовують різні розширення WSDL. Правила композиції інтегруються на фазі визначення. Вони використовуються для генерації композиційних планів, які задо- вольняють вимогам композиції. Здійсню- ється вибір найбільш відповідних компо- зиційних планів, визначаються обмеження. Інформаційні системи 92 Далі генерується результуючий компози- ційний сервіс. 4. Моделі, що лежать в основі автоматичної композиції Теоретичне вивчення автоматично- го синтезу композиції мережних сервісів знаходиться на початковій стадії. Моделі, що лежать в основі автоматичної компози- ції, мають свої корені в штучному інтелек- ті, логіці, обчислення ситуацій, теорії ав- томатів і тому залежать від вибраної філо- софської основи. Початкові результати з автоматичної композиції мережних серві- сів групуються навколо трьох моделей: (a) модель OWL-S [5], яка включає модель атомарних сервісів та модель їх взаємодії з абстракцією “реального світу”, (b) Римська модель [17], яка використовує абстрактну мову для представлення сервісів шляхом опису потоку процесів, що сформовані відповідними сервісами, і (c) модель ма- шини Миля [6], яка сфокусована на управлінні потоками процесів. Для представлення основних аспек- тів композиції введемо деякі обмеження. При взаємодії мережних сервісів, має бути забезпечена повна топологія сервісів та визначений протокол розмови між ними. Взаємодія сервісів має бути заснована або на використанні сервіса-посередника, або на використанні структури peer-to-peer (кожен з кожним). Якщо взаємодія сервісів заснована на використанні посередника, то це означає, що існує один мережний сер- віс, який названо посередником, і який ко- нтролює дії решти сервісів, визначених у моделі. В одноранговій моделі кожен сер- віс взаємодіє з іншими безпосередньо. Слід розрізняти типи композиції, які призначені для разового або багатора- зового використовування: у першому ви- Рис. 2. Розширення онтології WS domain (предметна область) binding (зв’язок) service (сервіс) name (ім’я) 1:1 1:1 1:1 1:{0,1} 1:1 1:n 1:n 1:1 1:1 1:1 1:1 11 1:1 1:n 1:n 1:n 1:n 1:n 1:n 1:1 synonym (синонім) specializatio n (спеціаліза category (категорія) operation (операція) description (опис) purpose (ціль) quality (якість) privacy (таємність) function (функція) synonym (синонім) specializatio n (спеціаліза security (захист) fees (гонорари) mode (вид) description (опис) business role (бізнес оutput (вихід) input (вхід) name (ім’я) unit (елемент) parameter (параметр) name (ім’я) data type (тип даних) 1:1 1:1 1:n 1:{0,1} 1:n 1:1 1:1 1:1 1:1 Інформаційні системи 93 падку алгоритм композиції викликається і виконується кожного разу, коли клієнт ідентифікує цільовий сервіс. У другому випадку алгоритм композиції сервісів мо- же бути виконаний один раз, а викликати- ся кілька разів тими самими або іншими клієнтами. Синтез сервіса-посередника на ос- нові атомарних складових сервісів з вико- ристанням моделі OWL-S заснований на побудові WorkFlow схеми (наприклад, ка- лендарний графік процесу, мережі Petri, складовий OWL-S сервіс тощо) [18–20], яка становить основу моделі управління, в якій атомарні сервіси викликаються для того, щоб координуватись для досягнення конкретної мети в межах визначеної конс- трукції. Ця WorkFlow схема має координу- ватися посередником і на практиці може використовувати стандарт BPEL. Задачі синтезу посередника дослі- джуються також з використанням римської моделі, в якій складові сервіси є загалом неатомарні і мають кожний свою схему потоку робіт, на відміну від моделі OWL- S, в якій атомарні сервіси абстрагуються від внутрішньої структури. Більш детально зупинимось на ви- користанні OWL-S моделей. Розглянемо основні аспекти моделі OWL-S та деякі результати композиції, що отримані з ви- користанням цієї моделі, а також підходу, заснованому на онтології числення преди- катів першого порядку для мережних сер- вісів. Моделі OWL-S відіграють основну роль в процесі моделювання взаємодії ме- режних сервісів з “реальним світом”. Базовий блок побудови моделі OWL-S – це нотація “процесу”, який включає як атомарні, так і складні проце- си. Процеси в нотації OWL-S конкретизо- вані з точністю до входів, виходів, вхідних умов і умов результатів. Розглянемо при- клад моделі OWL-S для двох атомарних сервісів, узятих з області комерції (купівлі- продажу товарів). У прикладі клієнт має використову- вати сервіс Select_goods для перевірки на- явності певної кількості товару, і якщо ре- зультат його задовольняє, то зарезервувати цей товар для послідуючої покупки. Пере- вірити свої фінансові можливості та при- дбати зарезервований товар, використову- ючи сервіс Purchase_goods. У нотації OWL-S ці сервіси мають вигляд, який по- казано на рис. 3. Після успішного виконання сервісу Select_goods видається повідомлення, що ці товари будуть зарезервовані для покуп- ки (наприклад, протягом 10 хв.). У випадку успішного резервування клієнт може звер- нутися до сервісу купівлі Purchase_goods, щоб фактично зробити покупку, викорис- товуючи банківський рахунок для пропла- ти. Сервіс Purchase_goods виконувати- меться, поки резервування дійсне, але ре- зультат цього виконання залежить від того, чи є достатні фінансові ресурси на рахун- Select_goods Input: goods_name, quantitu Output: price, reservation_id Pre-condition: the quantity of goods is available for sale Conditional effects: If true, then modify world state to reglect the fact that this goods is being for sale Purchase_goods Input: reservation id, billable_account Output: confirmation_id Pre-condition: reservation_id is valid and has not expired Conditional effects: If enough money ib billable_account then transfer of $$ to goods owner and transfer of goods to buyer If not ehough money then make reservation_id void Рис. 3. Приклад композиції сервісу в нотації OWL-S Інформаційні системи 94 ку. Складовий сервіс у нотації OWL-S мо- же бути створений за допомогою об'єд- нання цих двох атомарних сервісів, вико- ристовуючи послідовну конструкцію. У даному випадку виконання складового сервісу може залежати від умов виконання кожного атомарного сервісу. Для забезпечення формальної осно- ви моделювання взаємодії сервісів з «реа- льним світом» використовується підхід, заснований на численні ситуацій, що мо- делює факти, які можуть виникнути в різ- них “ситуаціях” при виконанні сервісів [19]. Для специфікації сервісів використо- вується мова PSL – Process Specification Language [21]. ISO стандартизувало цю мову, яка об'єднує аспекти числення ситу- ації. PSL має рівневу структуру з PSL- ядром та багатьма розширеннями для мо- делювання процесів. PSL-ядро забезпечує предикати першого порядку, які можуть використовуватися для опису основних блоків процесів та їх виконання. Основним класом у мові PSL є клас activity – активність, яка може розгляда- тися як модель процесу, вона може бути нульовою або складатися з кількох актив- ностей. Предикат occurrence_of (occ, а) ви- користовується для конкретизації процесу, а саме, що occ –результат активності а. Час, в даному випадку, представляється як параметр запиту на виконання процесу, в якому враховується початок та кінець процесу. Модель застосування створюється за допомогою об'єднання аксіоматики PSL з предикатами та пропозиціями, щоб сфо- рмувати теорію (логіку першого порядку). Модель цієї теорії може бути подана як дерево, вузли якого відповідають атомар- ним активностям, з переходами від однієї атомарної активності до іншої. Шлях у цьому дереві може розглядатися як мож- лива послідовність кроків виконання ком- позитного сервісу. Підхід до побудови проекції моделі OWL-S на PSL детально розглядається в [22]. Використаємо мову PSL для опису OWL-S нотації у прикладі покупки това- рів. У цьому прикладі ми можемо визначи- ти наступні відношення: Використаємо вищезгадані відно- шення для того, щоб конкретизувати пове- дінку атомарних сервісів, кожен з яких можна розглядати як атомарну активність в PSL нотації. Наприклад, якщо відно- шення select_goods задаються двома пара- метрами s, q – (назва, кількість), то відно- шення available_goods представляється трійкою параментрів – назва, кількість за запитом, ціна. r=(s, q' , p) при умові 'qq ≥ , де r- відношення «запит наявності товару», q – кількість доступного , p – ці- на, q' – кількість за запитом. Результат у даному випадку завжди існує, якщо виконується вхідна умова. На основі цього результату, може бути побудована активність резервування, яка має вигляд (s, q – q’, p, t), де s– назва; q – кількість; p – ціна; q’ – кількість за за- питом; t – час резервування. Є два підходи в контексті числення ситуацій. Згідно з першим підходом, від- ношення, наприклад, available_goods, пе- ретворюють за допомогою додавання но- вого поля, в нашому прикладі це значення часу резервування. Згідно з другим підхо- дом, що використовується в PSL відно- шення перетворюють у функцію, скажімо, f_available_goods, яка має три аргументи. Предикати PSL, володіння (hold) і попере- джування (prior) використовуються, щоб зв'язати істинні значення з умовами вико- ристання цієї функції. Available_goods(goods_name, qty, price) Reserved_goods(goods_name, qty, price, res_id) Purchase_reservation(res_id, start_time) Billable_account(acct_id, current_balance) - запит наявності товару певної кількості - резервування акцій - придбання зарезервованих акцій - контроль наявності коштів, їх проплата Інформаційні системи 95 Сукупність складових для побудови атомарних сервісів, їх конструкції визна- чаються в засобах GOLOG [22, 23], і від- повідають графічному стилю проектуван- ня, але в OWL-S вони розглядаються як декларативні обмеження в специфікації мережного сервісу. Ми зазначили два ключових підхо- ди, які стосуються автоматичної компози- ції з використанням моделей для OWL-S і OWL-S-подібних сервісів. Перший розро- блений у численні ситуації, де аспекти мо- делі OWL-S представляються засобами PSL. Мета композиції конкретизується в термінах загального результату, який дося- гається на всіх функціях, починаючи від деякого початкового стану, який включає значення вхідного аргументу. Інший підхід полягає у перетворенні атомарних проце- сів OWL-S у схему WorkFlow, яка відпові- дає всім можливим послідовностям актив- ностей процесів. Обчислювальна складність визна- чення існування композиції є експоненціа- льною. Для зменшення складності можуть застосовуватися різні евристики. Інший підхід до композиції сервісів у контексті моделі OWL-S розроблений в [11, 20, 22]. У цьому підході використову- ється мова GOLOG. Загальна програма може послідовно конкретизуватися, почи- наючи з атомарних сервісів OWL-S. Для побудови конкретної схеми, яка потрібна замовникові, можуть бути написані додат- кові обмеження. Далі виконується компо- зиція, яка відповідає гілці дерева схеми, і яка задовольняє певним властивостям. Для знаходження таких гілок використовується інтерпретатор ConGolog. Висновки Парадигма мережних сервісів іні- ціює дослідження та вирішення нових за- дач, серед яких є пошук відповідних моде- лей і абстракцій для представлення мере- жних сервісів та їх “поведінки”, і таких, що можуть підтримувати ефективне ство- рення алгоритмів композиції та аналізу сервісів. Інший аспект торкається засобів, які виконують статичну та динамічну пе- ревірку специфікацій мережних сервісів як на етапі компіляції, так і на етапі їх вико- нання з метою контролю цілісності засто- сувань. Друга категорія задач полягає у то- му, щоб прозоро забезпечити маніпулю- вання даними в контексті парадигми ме- режних сервісів і пов’язаних з нею станда- ртами. Існуючі стандарти і чисельні дослі- дження в даний час зосереджуються перш за все на моделі процесів, а не на потоці даних і маніпулюванні даними. Потрібні методи та засоби для мо- делювання перетворення даних, що відбу- вається в мережному сервісі, і які дозво- лять здійснювати міркування про поведін- ку даних при виконанні складового мере- жного сервісу. Для цього необхідно ство- рити моделі композиції сервісів, які були б більш відповідними для застосувань, і які спрямовані на обробку великих обсягів даних. 1. Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C. and Orchard, D. (2004) Web Services Architecture // W3C Working Group Note 11, February, W3C Technical Reports and Publications, http://www.w3.org/TR/ws-arch/ 2. Alonso G., Casati F., Kuno H., and Ma- chiraju V., Web Services. Concepts, Archi- tectures and Applications. Springer-Verlag, 2004. – P. 354. 3. Berardi D., Calvanese D., De Giacomo G., Hull R., and Mecella M.. Automatic compo- sition of web services in Colombo // In Proc. of 13th Itallian Symp. on Advanced Database Systems, June 2005. http://www.ai.sri.com/ WSS2005/final-versions/WSS2005_PP- Berardi.pdf 4. Berardi D., Calvanese D., De Giacomo G., Hull R., and Mecella M. Automatic Compo- sition of Transition-based Semantic Web Services with Messaging // Technical report, University of Rome, ”La Sapienza”, Roma.– – Italy: 2005, April. – P. 613–624. 5. Berardi Daniela, Calvanese Diego, De Giacomo Giuseppe, Hull Richard, Me- cella_Towards Massimo. AutomaticWeb Service Discovery and Composition in a Context with Semantics, Messages, and In- ternal Process Flow (A Position Paper). http://www.w3.org/2005/04/FSWS/Submissi ons/21/berardi-et-al-for-W3C-Frameworks- SWSs.pdf Інформаційні системи 96 6. Hull R., and Su J. Tools for Composite Web Services: A Short Overview. http://www.cs.toronto.edu/~libkin/dbtheory/ hullsu.pdf 7. Bloomberg J. The seven principles of ser- vice-oriented development // XML & Web Services, 3(5):32–33, 2002. Business Process Execution Language for Web Services (BPEL), Version 1.1. http://www.ibm.com /developerworks/library/ws-bpel 8. Milner R. Communicating and Mobile Sys- tems: The pi – calculus. Cambridge Univer- sity Press, 1999. – P. 161. 9. Hull Richard. Web Services Composition: A Story of Models, Automata, and Logics // http://ieeexplore.ieee. org/iel5/10245/32665/01530770.pdf?arnumb er=1530770&htry=0 10. Fu X., Bultan T., and Su J. Analysis of inter- acting BPEL web services//In Proc. Int. World Wide Web Conf. (WWW), May 2004. http://citeseer.ist.psu.edu/706792.html 11. Semantic Web Services Ontology (SWSO). http://www.daml.org/services/swsf/1.0/swso/ 12. Haas H. Architecture and future of web ser- vices: from SOAP to semantic web services// http://www.w3.org/2004/Talks/0520-hh-ws/, May 2004. 13. Web Services Choreography Description Language Version 1.0 (W3C Working Draft). 2004, December. http://www.w3.org/TR/ 2004/WD-ws-cdl-10-20041217/ 14. Freund T. and Storey T. (2002a, 2002b) Transactions in the World of Web Services, Part 1. An Overview of WS-transaction and WS-coordination // http://www.106.ibm.com/developerworks/ webservices/ library/ws-wstx1 15. Sun H., Wang X., Zhou B. and Zou P. (Research and Implementation of Dynamic Web Services Composition//APPT 2003, LNCS 2834, Springer-Verlag Berlin Heidelberg. – 2003. – P. 457–466. 16. Андон П., Дерецький В. Проблеми побудо- ви сервіс-орієнтованих прикладних інфо- рмаційних систем в semantic web середо- вищі на основі агентного підходу // Про- блеми програмування. –2006. –№ 2–3. – Р. 493-503. 17. Gösta Grahne and Victoria Kiricenko: Proc- ess Mediation in an Extended Roman Model. http://events.deri.at/ mediate2005/documents 18. Hamadi Rachid, Benatallah Boualem. A Petri Net-based Model for Web Service Composi- tion. http://crpit.com/confpapers/CRPITV17Hama di.pdf 19. Bock Conrad, Gruninger Michael. PSL:Asemantic domain for Flow models // Softw Syst Model. – 2005. – № 4. – Р. 209 - 231. 20. McIlraith Sheila, Cao Son Tran. Adapting Golog for Composition of Semantic Web Services. http://citeseer. ist.psu.edu/ mcil- raith01adapting.html 21. McIlraith Sheila A., Cao Son Tran, and Zeng Honglei. Semantic Web Services. Stanford University. http://portal.acm.org/citation.cfm?id=630625 &dl=&coll=&CFID=15151515&CFTOKEN =6184618 22. Gr¨uninger Michael, Kopena Joseph B. Planning and the Process Specification Lan- guage. http://portal.acm.org/cita- tion.cfm?id=958677 23. Lesperance Yves, Kelley Todd G., Mylopou- los John, and S.K. Yu Eric. Modeling Dy- namic Domains with ConGolog// In Confer- ence on Advanced Information Systems En- gineering. – 1999. – P. 365-380. Отримано 13.04.2007 Про автора: Дерецький Валентин Олександрович, кандидат фізико-математичних наук, провідний науковий співробітник. Місце роботи автора: Інститут програмних систем НАН України, 03187, Київ-187, проспект Академіка Глушкова, 40. Тел. (044) 526 4342 E-mail:dva@isofts.kiev.ua

Підходи до композиції сервісів в семантичному WEB середовищі

Institution

Similar Items