Web service discovery systems in service-oriented architecture: problems and solutions
With emerging the paradigm of Service-Oriented Computing and increasing the number of available Web services on the Internet the request is augmenting for tools to perform discovery, selection, composition, and invocation of Web services. At present, a large number of approaches to Web service disco...
Saved in:
| Date: | 2017 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
PROBLEMS IN PROGRAMMING
2017
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/149 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-149 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/40/bd511bbbb38f8fe8486cb7bebbd3ec40.pdf |
| spelling |
pp_isofts_kiev_ua-article-1492018-07-18T12:48:08Z Web service discovery systems in service-oriented architecture: problems and solutions Системы обнаружения Web-сервисов в сервис-ориентированной архитектуре: проблемы и решения Системи виявлення Web-сервісів в сервіс-орієнтованій архітектурі: проблеми і рішення Remarovych, S.S. UDC 004.41 УДК 004.41 УДК 004.41 With emerging the paradigm of Service-Oriented Computing and increasing the number of available Web services on the Internet the request is augmenting for tools to perform discovery, selection, composition, and invocation of Web services. At present, a large number of approaches to Web service discovery are being proposed, which is due to a number of problems and possible solutions in the construction of Web service discovery systems. In this article the analytical overview of the challenges in the building and functioning of such systems is conducted, and the existing approaches to solving them are given. It is shown that the problem of Web service discovery can be illuminat-ed in description logic based on the “best covering”. С появлением парадигмы сервис-ориентированного вычисления и рас-тущим количеством доступных Web-сервисов в Интернете усиливается запрос на средства для выполнения обнаружения, выбора, композиции и вызова Web-сервисов. На сегодня предложено большое количество подходов по выявлению Web-сервисов, которое обусловлено рядом задач и их возможными решениями при построении систем обнаружения Web-сервисов. В этой статье проведен аналитический обзор задач, стоящих при разработке и функционировании таких систем, и приведены существующие подходы к их решению. Показано, что проблема обнаружения Web-сервисов может быть освещена в дескриптивной логике на основе «наилучшего покрытия» З появою парадигми сервіс-орієнтованого обчислення і зростаючою кількістю доступних Web-сервісів в Інтернеті посилюється запит на засоби для виконання виявлення, вибору, композиції і виклику Web-сервісів. На сьогодні запропонована велика кількість підходів щодо виявлення Web-сервісів, яка обумовлена низкою задач та їх можливими рішеннями при побудові систем виявлення Web-сервісів. У цій статті проведено аналітичний огляд задач, які постають при розробці і функціонуванні таких систем, та наведені існуючі підходи до їх вирішення. Показано, що проблема виявлення Web-сервісів може бути висвітлена в дескриптивній логіці на основі «найкращого покриття». PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2017-06-15 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/149 PROBLEMS IN PROGRAMMING; No 3 (2015) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 3 (2015) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 3 (2015) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/149/143 Copyright (c) 2017 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2018-07-18T12:48:08Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 004.41 |
| spellingShingle |
UDC 004.41 Remarovych, S.S. Web service discovery systems in service-oriented architecture: problems and solutions |
| topic_facet |
UDC 004.41 УДК 004.41 УДК 004.41 |
| format |
Article |
| author |
Remarovych, S.S. |
| author_facet |
Remarovych, S.S. |
| author_sort |
Remarovych, S.S. |
| title |
Web service discovery systems in service-oriented architecture: problems and solutions |
| title_short |
Web service discovery systems in service-oriented architecture: problems and solutions |
| title_full |
Web service discovery systems in service-oriented architecture: problems and solutions |
| title_fullStr |
Web service discovery systems in service-oriented architecture: problems and solutions |
| title_full_unstemmed |
Web service discovery systems in service-oriented architecture: problems and solutions |
| title_sort |
web service discovery systems in service-oriented architecture: problems and solutions |
| title_alt |
Системы обнаружения Web-сервисов в сервис-ориентированной архитектуре: проблемы и решения Системи виявлення Web-сервісів в сервіс-орієнтованій архітектурі: проблеми і рішення |
| description |
With emerging the paradigm of Service-Oriented Computing and increasing the number of available Web services on the Internet the request is augmenting for tools to perform discovery, selection, composition, and invocation of Web services. At present, a large number of approaches to Web service discovery are being proposed, which is due to a number of problems and possible solutions in the construction of Web service discovery systems. In this article the analytical overview of the challenges in the building and functioning of such systems is conducted, and the existing approaches to solving them are given. It is shown that the problem of Web service discovery can be illuminat-ed in description logic based on the “best covering”. |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2017 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/149 |
| work_keys_str_mv |
AT remarovychss webservicediscoverysystemsinserviceorientedarchitectureproblemsandsolutions AT remarovychss sistemyobnaruženiâwebservisovvservisorientirovannojarhitektureproblemyirešeniâ AT remarovychss sistemiviâvlennâwebservísívvservísoríêntovaníjarhítekturíproblemiíríšennâ |
| first_indexed |
2025-07-17T10:04:16Z |
| last_indexed |
2025-07-17T10:04:16Z |
| _version_ |
1850413076881342464 |
| fulltext |
Програмування для комп’ютерних мереж та Internet
© C.C. Ремарович, 2015
ISSN 1727-4907. Проблеми програмування. 2015. № 3 53
УДК 004.41
С.С. Ремарович
СИСТЕМИ ВИЯВЛЕННЯ WEB-СЕРВІСІВ
В СЕРВІС-ОРІЄНТОВАНІЙ АРХІТЕКТУРІ:
ПРОБЛЕМИ І РІШЕННЯ
З появою парадигми сервіс-орієнтованого обчислення і зростаючою кількістю доступних Web-сервісів
в Інтернеті посилюється запит на засоби для виконання виявлення, вибору, композиції і виклику Web-
сервісів. На сьогодні запропонована велика кількість підходів щодо виявлення Web-сервісів, яка обу-
мовлена низкою задач та їх можливими рішеннями при побудові систем виявлення Web-сервісів. У цій
статті проведено аналітичний огляд задач, які постають при розробці і функціонуванні таких систем, та
наведені існуючі підходи до їх вирішення. Показано, що проблема виявлення Web-сервісів може бути
висвітлена в дескриптивній логіці на основі «найкращого покриття».
Вступ
Сервіс-орієнтоване обчислення
(Service-Oriented Computing – SOC) явля-
ється новою обчислювальною парадиг-
мою, головна мета якої полягає у підтрим-
ці розробки розподілених застосувань в
гетерогенних середовищах [1]. SOC дозво-
ляє компонувати і збирати разом розподі-
лену функціональність для створення про-
грамних систем. Ця функціональність по-
ставляється у вигляді основних будівель-
них блоків, які називаються сервісами.
Сервіс може бути визначений як частина
функціональності, яка виконана зовнішнім
постачальником. Постачальники публіку-
ють свої сервіси в реєстрі сервісів, визна-
чаючи при цьому: умови включення, тех-
нічні обмеження, вимоги і семантичну ін-
формацію. З іншого боку, споживачі серві-
сів виявляють опубліковані сервіси через
реєстр, і, в свою чергу, вибирають і укла-
дають контракт з ним. SOC реалізується за
допомогою технологій Web-сервісів, оскі-
льки вони призначені для підтримки інте-
роперабельності взаємодії постачальник-
споживач через Інтернет [2, 3].
У зв’язку із великим значенням ви-
явлення сервісів для SOC парадигми, як
дослідники, так і практики розробляють
системи виявлення сервісів. Останнім ча-
сом Web-пошукові системи (наприклад,
Google) стали новим джерелом для знахо-
дження Web-сервісів [4], так як описи сер-
вісів, як правило, знаходяться на Web-
серверах, які скануються та індексуються
пошуковими системами. З іншого боку,
шляхом адаптації існуючих інформаційно-
пошукових методів (Information Retrieval -
IR), деякі дослідники запропонували вико-
ристовувати описи Web-сервісів як доку-
менти, тим самим зводячи проблему вияв-
лення відповідних сервісів до добре відо-
мої проблеми знаходження релевантних
документів [5]. Інші підходи запропонува-
ли анотувати описи сервісів метаданими,
які являють собою однозначні визначення
понять із загальної онтології (семантика),
що дало початок поняттю семантичних
Web-сервісів [6].
Існують істотні відмінності в під-
ходах до виявлення сервісів. Одна з осно-
вних відмінностей полягає у тому, як такі
підходи розглядають описи сервісів. На-
приклад, семантичні підходи залежать від
загальних онтологій і анотованих ресур-
сів, водночас як IR-підходи ґрунтуються
на текстових описах. Хоча системи вияв-
лення сервісів прагнуть вирішити одну й
ту ж проблему, вони можуть дуже відріз-
нятися одна від одної, і один з варіантів
може бути доречним у певному середо-
вищі, але не в інших. Різноманітність ва-
ріантів для виявлення Web-сервісів моти-
вує необхідність обґрунтованих критеріїв,
щоб охарактеризувати їх. Масштабова-
ність, відмовостійкість і відповідність
стандартам є важливими аспектами таких
систем.
В роботі [5] автори представили
комплексне дослідження методів, архітек-
тур і моделей, пов’язаних з виявленням
Програмування для комп’ютерних мереж та Internet
54
Web-сервісів, проаналізувавши більше 30
підходів для виявлення Web-сервісів (у
тому числі промислових та наукових). Во-
ни розробили таксономію для організації
цих підходів, на основі чотирьох основних
категорій: архітектура, стандарти, моделі і
QoS-дані (Quality of Service – QoS).
Альтернативним підходом до вияв-
лення Web-сервісів є WSIL (Web Services
Inspection Language), пропозиція IBM® і
Microsoft [7]. Коли ми виявляємо Web-
сервіс за допомогою стандарту UDDI
(Universal Description, Discovery and
Integration), то йдемо до централізованого
реєстру. WSIL дозволяє перейти безпосе-
редньо до постачальника сервісів і спита-
ти, які сервіси він надає. Специфікація
WSIL будується навколо моделі на основі
XML для побудови агрегації посилань на
існуючі описи Web-сервісів, які виставлені
з використанням стандартної технології
Web-сервера. WSIL забезпечує розподіле-
ний метод виявлення сервісів, який подає
посилання на описи сервісів у точці-
пропозиції постачальника сервісів, вказа-
вши, як інспектувати Web-сайт для досту-
пних Web-сервісів. Специфікація WSIL
визначає місце розташування на Web-
сайті, де можна шукати описи Web-
сервісів. Оскільки WSIL фокусується на
розподіленому виявленні сервісів, то спе-
цифікація WSIL доповнює UDDI, допома-
гаючи виявляти сервіси, які доступні на
Web-сайтах, та які ще не перераховані в
реєстрі UDDI.
У цій статті показано, що проблема
виявлення Web-сервісів може бути висвіт-
лена в дескриптивній логіці на основі
«найкращого покриття». Проведено аналі-
тичний огляд задач, які необхідно вирішу-
вати системам виявлення Web-сервісів, та
підходи до їх розв’язання, які існують на
сьогодні. Процес виявлення Web-сервісів
охоплює весь спектр завдань від запиту на
сервіс до виклику сервісу. Вирішення про-
блем, пов’язаних з виявленням сервісів,
залежить від рівня пошуку – синтаксич-
ний, чи семантичний; функціональний, чи
процесний; від того, який семантичний
формалізм використовується для опису
сервісів і як управляти цими описами.
Web-сервіси та їх стандарти
Перед тим, як розглядати задачі си-
стем виявлення Web-сервісів, важливо
спочатку уточнити, що саме означає «ви-
явлення Web-сервісів» і розглянути техно-
логії, які пов’язані з Web-сервісами. Хоча
існують різні пропозиції для виявлення
Web-сервісів, розуміння виявлення
(discovery) є дуже різним, і часто його плу-
тають з такими термінами, як вибір
(selection) і зіставлення (matching) [8]. Се-
ред невеликої кількості визначень вияв-
лення сервісів у літературі, найбільш офі-
ційне визначення є те, що викладено в [9]:
«Акт локалізації машинно-оброблюваного
опису ресурсу, пов’язаного з Web-
сервісом, що, можливо, був раніше неві-
домий, і, що відповідає деякому функціо-
нальному критерію. Він включає в себе
зіставлення набору функціональних та ін-
ших критеріїв з набором описів ресурсу.
Мета полягає в тому, щоб знайти відповід-
ний ресурс, пов’язаний з Web-сервісом».
Спочатку основна мета технології Web-
сервісів полягала у тому, щоб визначити
Web-сервіси в машинно-зрозумілій формі
для того, щоб автоматично виявляти їх ін-
шими учасниками (агентами або сервіса-
ми). В результаті, знаходження відповід-
них Web-сервісів розглядається як важли-
вий ключ до композиції сервісів, виклику і
виконання.
Виявлення Web-сервісів являє со-
бою процес пошуку Web-сервісів, які за-
довольняють певним вимогам. Система
виявлення сервісів пов’язує між собою
постачальників і споживачів сервісів. Про-
вайдери можуть використовувати систему
виявлення, щоб рекламувати свої сервіси,
а споживачі можуть використовувати її
для виявлення сервісів, які відповідають
їхнім потребам. Об’єктом пошуку системи
виявлення є Web-сервіс, тобто, його опис.
Розглянемо цю сутність.
Виявлення сервісів через Інтернет
посилається на сукупність технологічних
стандартів для модульних програм, які
можуть бути опубліковані, виявлені і ак-
тивізовані через Web [1]. Ця сукупність
складається з чотирьох рівнів: зв’язок, се-
ріалізація, опис і виявлення. Вичерпний
Програмування для комп’ютерних мереж та Internet
55
опис цих технологічних стандартів може
бути знайдений в роботі [10].
Визначення Web-сервісів згідно
W3C виглядає наступним чином: «Web-
сервіс являється програмною системою,
яка визначається URI (Uniform Resource
Identifier), чиї загальнодоступні інтерфей-
си та зв’язки визначені і описані за допо-
могою XML (Extensible Markup Language).
Його визначення може бути виявлене ін-
шими системами програмного забезпечен-
ня. Ці системи можуть потім взаємодіяти з
Web-сервісом в порядку, встановленому
його визначенням, використовуючи XML
засновані повідомлення, що передаються
через Інтернет-протоколи». Web-сервіси,
які посилені додатковими метаданими, що
виражають їх семантику, називаються се-
мантичними Web-сервісами [11].
Web-сервіси визначаються такими
елементами:
• входи I, тобто значення, які необ-
хідні сервісу для його виконання;
• виходи O, тобто значення, які ви-
робляються після виконання сервісу;
• попередні умови Р, тобто всі умо-
ви, які повинні бути дотримані, щоб гаран-
тувати успішне виконання сервісу;
• ефекти Е, тобто зміни в стані сві-
ту, які відбуваються у разі успішного або
неуспішного виконання сервісу.
Мета виявлення (запит) може бути
визначена подібним набором елементів: у
цьому випадку входи і попередні умови
виражають значення та умови, які відомі
тому, хто викликає, в той час як виходи і
ефекти являють собою очікувані результа-
ти виклику сервісу.
Крім функціональних характери-
стик, Web-сервіси описуються з точки зо-
ру не функціональних (QoS) аспектів (ва-
ртість, час відгуку, надійність, доступ-
ність, готовність, безпечність і т. д.).
В реальному світі наявні сервіси не
є атомарними, і не можуть взагалі бути ви-
конані в одному кроці запит-відповідь.
Взагалі, кожен компонентний сервіс може
бути вказаний як протокол взаємодії, де
різні «атомарні» виклики та відповіді були
об’єднані в складні шаблони виконання.
Хоча деталі точного протоколу, необхід-
ного для взаємодії з існуючим сервісом, не
важливі у виявленні, вони стають необхід-
ні, коли ми прагнемо до генерації компо-
зитних Web-сервісів, які є виконувані. З
цієї причини, композиція виконуваних
сервісів повинна мати справу з описами
Web-сервісів з точки зору складних проце-
сів, які складаються з довільних комбіна-
цій атомарних взаємодій, в стилі, напри-
клад, OWL-S моделей процесів [12] або на
основі абстрактної машинної моделі, як у
WSMO інтерфейсах [13], чи WS-BPEL
описів. Проблема композиції сервісів
означає побудувати новий сервіс (компо-
зитний сервіс), який виконує деяку потріб-
ну функціональність, взаємодіючи з наяв-
ними сервісами (компонентні сервіси).
Функціональність запиту може покрива-
тись набором сервісів.
Стандартним форматом для опису
Web-сервісів є мова опису WSDL (Web
Service Description Language) в XML-
форматі [14], яка представляє опис серві-
су у вигляді набору операцій, виклик яких
відбувається на основі обміну повідом-
леннями. В об’єктно-орієнтованих термі-
нах, WSDL-документ описує сервіс як
статичний інтерфейс, операцію як метод і
повідомлення, як аргументи методу (вхо-
ди і виходи). Цього може бути досить для
Web-сервісів, які беруть участь в обміні
повідомленнями без урахування станів.
Крім того, WSDL дозволяє провайдерам
також описати винятки як повідомлення.
Кожна частина WSDL документу може
містити документацію у вигляді комента-
рів. WSDL описи публікуються в реєстрах
сервісів.
Домінуючим стандартом для ре-
єстрів Web-сервісів є UDDI [15]. UDDI
специфікація забезпечує незалежний від
платформи спосіб опису і виявлення Web-
сервісів і постачальників Web-сервісів.
Структури даних UDDI забезпечують ос-
нову для опису базової інформації сервісу
і розширюваний механізм для вказівки
детальної інформації про доступ до сер-
вісу, використовуючи будь-яку стандарт-
ну мову опису. Специфікація UDDI орга-
нізовує три групи метаданих: білі, зелені
та жовті сторінки. Білі сторінки підтри-
мують бізнес-інформацію (наприклад, ад-
реса, контакт та інші відомі ідентифікато-
Програмування для комп’ютерних мереж та Internet
56
ри). Жовті сторінки зв’язують сервіс з
промисловими класифікаціями, заснова-
ними на стандартних таксономіях, як
United Nations Standard Products and
Services Code (UNSPSC), Standard
Industrial Classification (SIC) або North
American Industry Classification System
(NAICS) [16]. Зелені сторінки зберігають
технічну інформацію про сервіси, вистав-
лених одним або кількома підприємства-
ми, наприклад, WSDL-документ. Ця спе-
цифікація складається з чотирьох основ-
них типів даних, а саме businessEntity,
businessService, binding Template і tModel
(технічна модель), які визначені в XML.
UDDI являє собою основу для
інших підходів до виявлення Web-сервісів
і не призначений для того, щоб забезпе-
чити потужні можливості для виявлення
сервісів, але він призначений для забезпе-
чення стандартизованих форматів для
програмного бізнесу та виявлення серві-
сів, так що пошукові системи можуть бу-
ти побудовані на його вершині. UDDI на-
дає тільки перегляд за категоріями, і вста-
новлення відповідності на основі ключо-
вих слів при виявленні сервісу. Наскільки
нам відомо, існує безліч комерційних реа-
лізацій UDDI і тільки одна реалізація від-
крита. Apache Software Foundation підт-
римує jUDDI [17], альтернатива з відкри-
тим вихідним кодом.
Компонентні і композитні сервіси
можуть виражатися за допомогою мови
WS-BPEL (Business Process Execution
Language) [18], яка є де-факто стандартом
для опису поведінки Web-сервісів з ураху-
ванням станів. У WS-BPEL набір атомар-
них операцій зв’язку (invoke, receive і
reply) об’єднується в робочий процес
(workflow), який визначає процес, реалізо-
ваний сервісом зі станами. Атомарні зв'яз-
ки відповідають атомарним операціям
Web-сервісу і визначаються у WSDL спе-
цифікації.
За останні кілька років були прове-
дені дослідження, щоб додати значущі дані
до Web-сервісів, породивши таким чином
семантичні Web-сервіси [6]. Семантичні
Web-сервіси дали початок чотирьом осно-
вним напрямкам досліджень: визначення,
генерування, управління та використання
метаданих сервісу. У майбутньому припу-
скається, що програмні агенти, діючи в ін-
тересах своїх користувачів, будуть шукати
відповідні сервіси. Автоматичне укладання
контрактів з сервісами залежить від визна-
чення моделі для опису характеристик рів-
ня сервісу, а для виклику сервісу потрібні
дані про репутацію провайдерів і платіжна
інформація. Другий напрям досліджень
стосується того, що описи сервісів повинні
бути анотовані метаданими відповідно до
визначеної моделі. Третій напрямок дослі-
джень охоплює питання зберігання анота-
цій та їх ефективного добування з семан-
тичних реєстрів. І на кінець, семантичні
реєстри мають забезпечувати механізми
виявлення, які використовують переваги
від семантичних описів. Для автоматично-
го виявлення сервісів необхідно, щоб шу-
качі могли довіряти описам провайдерів.
Інтернет є дуже відкритим гетерогенним
середовищем, тому виникає серйозна про-
блема довіри між споживачами і постача-
льниками сервісів [19]. Це цікава пробле-
ма, яка представляє багато можливостей
для досліджень, які не тільки містять, як
забезпечити класичні не функціональні
QoS вимоги, такі як час відгуку або досту-
пність, але й функціональні (визначити
функціональність сервісу) та правові (лі-
цензування і авторські права) аспекти.
Анотації семантичних сервісів віді-
грають дуже важливу роль у виявленні
сервісів і впливають на архітектуру, алго-
ритми, інструменти та ефективність си-
стем виявлення сервісів.
Існує три основні формалізми для
визначення метамоделі, або типу семанти-
чної інформації, для опису Web-сервісів, а
саме OWL-S [20], WSMO [13] і WSDL-S
[21]. OWL-S, який був прийнятий як пред-
ставлення W3C в листопаді 2004 року, за-
безпечує основу для опису як функцій, так
і оголошень Web-сервісів за допомогою
OWL (Ontology Web Language). OWL є ре-
комендацією W3C для опису семантичних
відношень домену.
OWL-S являється однією з най-
більш часто вживаних мов для семантич-
них анотацій Web-сервісів. Це онтології
OWL, які надають конструкції, щоб ви-
значити сенс атомарних і композитних
Програмування для комп’ютерних мереж та Internet
57
сервісів. OWL заснована на дескриптивній
логіці. Основа OWL-S – клас Service з
трьома головними компонентами, які
представлені наступними класами:
Service Profile визначає, що сервіс
вимагає від споживачів і що він пропонує
їм. Він виражає те, які перетворення здій-
снюються сервісом, визначаючи I/O і пе-
ред-/пост-умови. З точки зору виявлення і
композиції, це найважливіша частина ви-
значення OWL-S сервісу.
Service Model визначає, як працює
сервіс з точки зору процесу. Модель ви-
значає сервіс як атомарний процес, або
композицію кількох атомарних сервісів.
Для цього процесу вона визначає, які вхід-
ні дані мають бути надані для його вико-
нання, які передумови мають виконувати-
ся, і які вихідні дані і ефекти створюються.
Цей опис має узгоджуватись з визначен-
нями I/O, перед-/пост-умов в Service
Profile.
Service Grounding визначає, як сер-
віс використовується. Він визначає прото-
кол зв’язку, формати повідомлень, методи
серіаліації, а також інші конкретні деталі
сервісу, необхідні для його виклику.
Ще однією ініціативою у цьому на-
прямку є WSMO (Web Service Modeling
Ontology) [13], яка забезпечує поглиблену
концептуальну модель для опису семанти-
ки сервісів і сприяє автоматизації вияв-
лення сервісу, композиції і виклику.
WSMO включає у себе чотири підсистеми:
онтології, щоб формалізувати знання пре-
дметної області; цілі, які описують мету
користувача; Web-сервіси та їх семантич-
ний опис і посередники для підтримки су-
місності та вирішення неоднорідності.
Опис WSMO елементів представлено за
допомогою Web Service Modeling Language
(WSML) [22]. WSMO також визначає кон-
цептуальну модель WSMX [23], середови-
ще виконання семантичних Web-сервісів.
Таким чином, WSMO, WSML і WSMX ут-
ворюють всеосяжний фреймворк для мо-
делювання, опису та виконання семантич-
них Web-сервісів.
WSDL-S дозволяє визначити семан-
тику сервісів, які описані у WSDL [14].
Замість того, щоб запропонувати нову мо-
ву, він визначає деякі розширення WSDL,
щоб семантично анотувати сервіси.
WSDL-S являється агностиком стосовно
мови визначення семантики. Семантична
модель предметної області може бути
представлена в OWL, RDF, WSML або
UML. WSDL-S пов'язує ці моделі з елеме-
нтами сервісу, визначених у WSDL. Один
Web-сервіс може бути анотований кілько-
ма семантичними моделями.
І запит, і оголошення сервісу ви-
значаються на мовах опису сервісів з пев-
ною виразністю. Така виразність надзви-
чайно впливає на якість процедури вияв-
лення. Крім того, повнота описів також
впливає і на процес встановлення відпо-
відності між запитами на сервіс і оголо-
шеними сервісами.
Одним з головних внесків OWL-S і
WSMO є можливість міркування і посере-
дництва над описами сервісів, яка підтри-
мується мовами, що лежать в їх основі,
тобто OWL і WSML.
Ефективність вирішення задач при
виявленні Web-сервісів залежить від обра-
ної моделі формалізації сервісу. Потрібен
формалізм, який забезпечуватиме гарне
семантичне анотування сервісів та підходи
для встановлення семантичної відповідно-
сті між оголошеним сервісом і запитом на
сервіс, а також автоматизованого ви-
явлення підходящих сервісів при побудові
композитного сервісу, який реалізує кон-
кретний бізнес-процес. Так як при побудо-
ві композитного сервісу поведінка компо-
нентних сервісів впливає на хід бізнес-
процесу, то формалізм повинен мати спра-
ву з динамічним аспектом (поведінкою)
сервісу. Це є одним з ключових аспектів,
що робить очевидною доцільність вико-
ристання дескриптивних логік (Description
logic - DL) [24] для опису сервісів, так як
DL забезпечує можливість міркувань для
сервісів, і таким чином дозволяє описати їх
динамічний аспект.
Формалізація виявлення
Web-сервісів на основі
покриття-виведення
Розглянемо підхід до виявлення
сервісів в контексті дескриптивної логіки.
Ключовим аспектом дескриптивних логік є
їх формальні семантики та підтримка су-
Програмування для комп’ютерних мереж та Internet
58
джень. Механізм виявлення сервісів пови-
нен підтримувати гнучке порівняння, оскі-
льки нереально очікувати точного збігу
запитів на сервіс та оголошення сервісу.
Пропонується використовувати операцію
різниці на описах сервісів. Така операція
дозволяє з підмножини описів Web-
сервісів витягти ту частину, яка є семанти-
чно спільною з заданим запитом на сервіс,
і ту частину, яка семантично відмінна від
запиту. Знаючи першу і останню частини,
можна ефективно вибрати відповідні Web-
сервіси. Алгоритм порівняння приймає у
якості вхідних даних запит на сервіс Q та
онтологію сервісів Т і знаходить множину
сервісів, що називається «краще покриття»
запиту Q, описи яких містять якомога бі-
льше спільного з інформацією запиту Q,
наскільки це можливо, і якнайменше лиш-
ньої інформації щодо Q, наскільки це мо-
жливо.
Наведемо низку визначень [25, 26].
Нехай nCCC ,..., ,1 і D – це дескрипції кон-
цептів:
C поглинається (включається в) D
(позначається C D ), якщо II
DC для
будь-якої інтерпретації I.
С еквівалентно D (позначається
DC ), якщо II
DC для всіх інтерпрета-
цій I.
D є найменшим спільним узагаль-
нювачем для nCCC ,...,1 ,2 (позначається
),...,( 1 nCCClcsD ,2 , lcs – least common
subsummer), якщо i iC D , для всіх i
)1( ni , та D є найменшою дескрипцією
концептів, що володіють даною властивіс-
тю, тобто, якщо D′ є дескрипцією концеп-
тів, що задовольняє умові iC D ,
ni 1 , то D D [27].
Інтенсіональні дескрипції, які мі-
стяться в базі знань, побудовані з викори-
станням дескриптивних логік, називаються
термінологією.
Визначення 1 (термінологія). Не-
хай A ім’я концепту та C – дескрипція
концепту. Тоді CA є визначенням кон-
цепту. Термінологія T – це кінцева множи-
на визначень концептів таких, що кожне
ім’я концепту зустрічається не більше од-
ного разу в лівій частині визначення.
Ім’я концепту A називається кон-
цептом, який визначений в термінології T,
якщо воно зустрічається в лівій частині
визначення концепту в термінології T. Ін-
шими словами, A називається атомарним
концептом.
Інтерпретація I задовольняє тве-
рдженню CA , якщо II
CA . Інтерпре-
тація I є моделлю для термінології T, якщо
I задовольняє всім твердженням в T.
Термінологія, яка побудована з ви-
користанням конструкторів мови L, нази-
вається L -термінологією. Далі вважаємо,
що термінологія T є ациклічною, тобто не
існує циклічних залежностей між визна-
ченнями концептів. Ациклічні термінології
можуть бути розгорнуті шляхом заміщен-
ня певних імен їх визначеннями до тих пір,
поки певні імена все ще будуть зустрічати-
ся в правих частинах визначень. Таким чи-
ном, поняття найменшого спільного узага-
льнювача (least common subsumer – lcs)
множини дескрипцій може бути розшире-
но до концептів, що містять певні імена. В
даному випадку, для позначення наймен-
шого спільного узагальнювача концептів C
і D щодо термінології T ми використовує-
мо вираз ), D(ClcsT (тобто, lcs застосову-
ється до розгорнутих описів C і D).
Визначення 2 (операція різниці)
[26]. Нехай C і D – дві дескрипції концеп-
тів такі, що C D . Різниця DC дескри-
пцій концептів C і D визначається наступ-
ним чином:
max
: { | }C D B B D C Π .
Різниця двох дескрипцій С і D ви-
значається як дескрипція, яка містить всю
інформацію, що є частиною дескрипції С,
але не входить до дескрипції D. Це визна-
чення операції різниці вимагає, щоб дру-
гий операнд включав у себе перший. Од-
нак, якщо операнди С і D не порівняні що-
до відношення включення, то різниця C−D
може бути задана шляхом побудови най-
меншого спільного узагальнювача С і D,
тобто ),(: DClcsCDC .
Програмування для комп’ютерних мереж та Internet
59
Визначення 3 (скорочена клаузаль-
на форма та структурна еквівалентність).
Нехай L – дескриптивна логіка. Клауза в
L – це дескрипція A з наступною власти-
вістю: ( ) ( ) ( )A B A B B A Π Τ .
Кожна кон’юнкція 1 nA AΠ... Π – це клау-
за, яка може бути представлена як множи-
на клауз 1{ , ..., }nA A .
1{ , ..., }nA A A називається скоро-
ченою множиною клауз, якщо 1n , або
жодна клауза не поглинає кон’юнкцію ін-
ших клауз: (1 ) : ii i n A ⋣ iAA \ . Тоді
множина A називається скороченою фор-
мою клауз (RCF – reduced clause form) ко-
жної дескрипції 1 nB A A Π... Π .
Нехай 1{ , ..., }nA A A та 1{ , ...B B
..., }mB будуть скороченими множинами
клауз в дескриптивній логіці L. A і B є ек-
вівалентними структурами (позначається
BA ), якщо: (1 ) 1 ,n m i i n j
.: i j i kk n A B B A
Якщо в дескриптивній логіці для
кожної дескрипції всі його RCF мають ек-
вівалентні структури, ми кажемо, що RCF
форми – структурно унікальні в цій логіці.
Операція структурної різниці ви-
значається як операція різниці множин, що
застосована до множин клауз, де порів-
няння клозів виконується на основі відно-
шення еквівалентності.
Тепер введемо поняття структур-
ного включення, так як воно визначене
в [26].
Визначення 4 (структурне вклю-
чення). Кажуть, що відношення включення
в дескриптивній логіці L буде структур-
ним, якщо для будь-якої клаузи LA та
будь-якої дескрипції 1 mB B B Π... Π L ,
яка задана RCF формою, виконується:
1 : iA B i m A B .
Формалізація задачі найкращого
покриття. Введемо деякі основні визна-
чення, що необхідні, щоб формально ви-
значити задачу найкращого покриття. Не-
хай L – DL зі структурним включенням, T -
L -термінологія, і Q ≢ – когерентна де-
скрипція L-концепту. Множина визначе-
них концептів, які зустрічаються в T, поз-
начається як ]},1[,{ niSS i T , де iS ≢ ,
],1[ ni . Далі ми вважаємо, що дескри-
пції концептів ],1[, niSi представляють-
ся своїми RCF-формами.
Визначення 5 (покриття). Покрит-
тям Q, що використовує термінологію T, є
кон’юнкція E деяких імен iS із T таких,
що: ), E(QlcsQ T ≢Q .
Отже, покриття концепту Q, що ви-
користовує термінологію T, визначається
як довільна кон'юнкція концептів, що зу-
стрічаються в T, які розділяють з Q деяку
загальну інформацію. Слід зауважити, що
покриття E концепту Q завжди сумісне з Q
(тобто, Q EΠ ≢ ), так як L – це DL з
структурно унікальними RCF та Q ≢ , та
iS ≢ , ],1[ ni .
Щоб визначити поняття найкращо-
го покриття, необхідно охарактеризувати
частину опису покриття E, що не містить-
ся в описі запиту Q, і частини запиту Q,
яка не міститься в описі його покриття E.
Визначення 6 (залишок та недоста-
ча) (rest and miss). Нехай Q – дескрипція
L-концепта та E – покриття Q, яке викори-
стовує термінологію T . Залишок Q щодо E,
позначається RestE(Q), визначається як:
),)( E(QlcsQQERest T .
Недостатня інформація запиту Q
щодо E, позначається MissE(Q), визнача-
ється як: ),)( E(QlcsEQissEM T .
Визначення 7 (найкраще покрит-
тя). Дескрипція концепту E називається
найкращим покриттям запиту Q, яка вико-
ристовує термінологію T, якщо:
E – це покриття Q, що використовує
T, та не існує жодного покриття E′ запиту
Q, що використовує T, такого, що (|Rest
E′(Q)|, |MissE′(Q)|) < (|RestE(Q)|, |MissE(Q)|),
де < – це лексикографічний порядковий
оператор.
Найкраще покриття визначається як
покриття, яке має, по-перше, найменший
залишок, по-друге, найменшу кількість не-
достатньої інформації.
Задача найкращого покриття, поз-
начається BCOV(T,Q), – це задача обчи-
слення всіх найкращих покриттів запиту Q,
Програмування для комп’ютерних мереж та Internet
60
що використовують термінологію T. Алго-
ритм найкращого покриття надано в [28].
Семантичне міркування для ви-
явлення Web-сервісів. Розглянемо запро-
понований механізм суджень, що може
використовуватися для автоматизації ви-
явлення Web-сервісів у контексті DAML-
S онтологій. Більш докладний опис цих
аспектів можна знайти в [29]. Як згадува-
лось вище, структура онтології сервісів
має три основні частини: ServiceProfile,
ServiceModel та ServiceGrounding. Про-
файл сервісу забезпечує інформацію про
сервіс, яка може використовуватися аген-
том, щоб визначити, чи задовольняє
сервіс його потребам.
Як пропонується в [30], відповід-
ність між запитом (виражається за допо-
могою профайлу сервісу) і оголошенням
сервісу визначається шляхом порівняння
всіх виходів запиту з виходами оголо-
шення сервісу та всіх входів оголошення
сервісу з вхідними даними запиту. Адап-
туємо цю ідею, але використаємо алго-
ритм обчислення найкращого покриття
замість алгоритму порівняння, заданого в
[30]. Механізм виявлення сервісу на осно-
ві заданого запиту на сервіс Q і онтології
T. має обчислити найкращу комбінацію
Web-сервісів, яка максимально, на скільки
можливо, задовольняє вихідним даним
запиту Q і яка вимагає, на скільки це мо-
жливо, мінімального числа вхідної інфор-
мації, не наданої в описі Q. Таку комбіна-
цію Web-сервісів ми назвемо найкращим
покриттям профайлу Q з використанням
T. Для вирішення даного завдання необхі-
дно розширити методи найкращого пок-
риття, представлені вище, щоб врахувати
описи профайлів, представлені далі.
Нехай ]},1[,{ niSi T – обмеже-
на онтологія і lSE ⊓…⊓ pS , де
],1[, npl , є кон’юнкцією декількох сер-
вісів, присутніх в T. Позначимо I(E) (від-
повідно O(E)) концепт, визначений за до-
помогою кон'юнкції всіх входів (відповід-
но виходів), що зустрічаються в секції
профайлу всіх сервісів iS , для всіх
],[ pli . Таким самим чином ми будемо
використовувати I(Q) (відповідно O(Q))
для позначення концепту, визначеного за
допомогою кон’юнкції всіх входів (відпо-
відно виходів), що зустрічаються в секції
профайлу в заданому запиті Q.
Розширимо поняття покриття, за-
лишку та недостачі до профайлів сервісів
наступним чином.
Визначення 8 (покриття профайлу
(Pcover)). Покриття профайлу запиту Q,
називається Pcover, що використовує тер-
мінологію T, є кон’юнкцією E деяких
сервісів iS з T таке, що
))(),(()( EOQOlcsQO T ≢ )(QO .
Отже, покриття Pcover запиту Q, що
використовує термінологію T, визначаєть-
ся як довільна кон’юнкція Web-сервісів,
які присутні в T, що розділяє з Q деякі
виходи.
Визначення 9 (залишок профайлу
(Prest) та недостача профайлу (Pmiss)).
Нехай Q запит на сервіс та E – покриття
запиту Q з використанням термінології T.
Prest запиту Q щодо E, що позначається
)(QestPr E , визначається наступним чи-
ном:
))(),(()()( EOQOlcsQOQestPr E T .
Недостатня інформація профайла про
Q щодо E позначається )(QPmissE
та визначається наступним чином:
))(),(()()( EIQIlcsEIQPmissE T .
Нарешті, поняття найкращого пок-
риття може бути розширене до профайлів
шляхом відповідної заміни у визначенні 7
[31] rest та miss на Prest та Pmiss профай-
лів. Розроблений алгоритм, названий
computeBProfileCov [28], обирає комбінації
сервісів, які найкраще збігаються із зада-
ним запитом, та ефективно обчислює ви-
ходи запиту, які не можуть бути задоволе-
ні наявними сервісами (тобто, Prest), а та-
кож входи, які потребуються обраними
сервісами та не надаються у запиті (тобто,
Pmiss).
Розглянемо приклад, який показує,
як може використовуватися поняття най-
кращого покриття профайлу для встанов-
лення відповідності між запитом на сервіс
та оголошеннями сервісів. Розглянемо он-
тологію Web-сервісів, що містить наступні
три сервіси:
Програмування для комп’ютерних мереж та Internet
61
ToTravel дозволяє зарезервувати
подорож, задану маршрутом (тобто, пунк-
том відправлення та пунктом прибуття),
датою і часом прибуття. Вхідні параметри:
Itinerary, Arrival. Вихідні параметри:
TripReservation.
FromTravel дозволяє зарезервувати
подорож, задану маршрутом та датою і ча-
сом відправлення. Вхідні параметри:
Itinerary, Departure. Вихідні параметри:
TripReservation.
Hotel дозволяє зарезервувати готель
по заданим пункту призначення і періоду
часу, який виражається термінами – дата
в’їзду та дата виїзду. Вхідні параметри:
Destination, StayDuration. Вихідні параме-
три: HotelReservation.
Приклад онтології туризму:
Itinerary ( 1 departurePlace) Π
(departurePlace.Location)Π
( 1 arrivalPlace) Π
)nce.LocatioarrivalPla(
Arrival ( 1 arrivalDate) Π
( arrivalDate.Date) Π
( 1 arrivalTime) Π )e.TimearrivalTim (
Departure ( 1departureDate) Π
( departureDate.Date) Π
( 1departureTime) Π
)ime.TimedepartureT(
Destination ( 1DestinationPlace) Π
)ationnPlace.Locdestinatio(
StayDuration ( 1 checkIn) Π
( checkIn.Date) Π ( 1checkOut) Π
)atecheckOut.D(
... ationTripReserv
... vationHotelReser
... CarRental
Профайли сервісів звертаються до
концептів, що визначені в онтології туриз-
му, для опису якої використовується син-
таксис звичайної дескриптивної логіки.
Дескрипція концепту Itinerary позначає
клас екземплярів, пункти відправлення
яких (відповідно пункти прибуття) є екзе-
мплярами концепту Location. Більше то-
го, екземпляри, які належать цьому класу,
повинні мати хоча б один пункт відправ-
лення (обмеження ) 1( lacedepartureP ) та
один пункт прибуття (обмеження
)1( cearrivalPla ). Вхідний параметр
сервісу ToTravel будується з використан-
ням кон’юнкції всіх його вхідних пара-
метрів наступним чином: ( )I ToTravel
Itinerary Arrival Π . За допомогою заміни
концептів Itinerary та Arrival їх описами,
ми отримуємо наступний еквівалентний
опис:
( ) ( 1departurePlace)I ToTravel Π
( destinationPlace.Location) Π
( 1 arrivalPlace) Π
( arrivalPlace.Location) Π
( 1arrivalDate) Π ( arrivalDate.Date) Π
( 1arrivalTime) Π )e.TimearrivalTim(
Входи і виходи інших Web-сервісів
обчислюються аналогічним чином. Роз-
глянемо запит на сервіс Q, який шукає
турпакет, що поєднує у собі подорож з го-
телем і прокатом автомобілів, враховуючи
місце відправлення, місце прибуття, дату
відправлення, пункт призначення (готель),
а також дати в'їзду та виїзду. Входи і ви-
ходи запиту Q можуть бути виражені на-
ступними описами:
( ) ( 1departurePlace)I Q Π
( departurePlace.Location) Π
( 1 arrivalPlace) Π
( arrivalPlace.Location) Π
( 1departureDate) Π
( departureDate.Date) Π
( 1destinationPlace) Π
( destinationPlace.Location) Π
( 1checkIn) Π ( checkIn.Date) Π
( 1checkOut) Π )atecheckOut.D(
( ) TripReservationO Q Π
HotelReservationΠ CarRental
Відповідність між запитом на сервіс
Q і трьома оголошеними сервісами, що за-
дані вище, може бути досягнуто шляхом
обчислення найкращого покриття профай-
лу для запиту Q з використанням цих
сервісів. Вийде наступний результат: най-
краще покриття профайлу – FromTravel,
Hotel; Prest – CarRental; Pmiss –
departureTime.
Програмування для комп’ютерних мереж та Internet
62
У даному прикладі, існує єдине
найкраще покриття профайлу для Q, що
відповідає дескрипції E Hotel Π
FromTravelΠ . Вибрані сервіси генерують
концепти TripReservation і HotelReser-
vation, які є частиною вихідних парамет-
рів, які вимагаються запитом Q. З описів
сервісів ми бачимо, що жоден з Web-
сервісів не забезпечує концепт CarRental.
Отже, найкращі покриття профайлу запи-
ту Q матимуть у точності наступний за-
лишок профайлу: carRentalQPrestE )( .
Залишок відповідає вихідному параметру
запита, який не може бути згенерований
жодним оголошеним сервісом. Більше
того, Pmiss відображає інформацію
(departureTime), яка потрібна на вхід виб-
раним сервісам, але не надається у вхід-
них параметрах запиту. Точніше, найкра-
ще покриття профайлу запиту Q матиме в
точності наступну недостатню інформа-
цію: ( ) ( 1 )EPmiss Q departureTime Π
).( TimeimedepartureT . Слід зазначити
що, хоча рішення E Hotel ToTravel Π
генерує такі ж вихідні параметри (тоб-
то, концепти TripReservation і Hotel-
Reservation), воно не буде обрано, так як
Pmiss більше, ніж при першому рішенні
(воно містить відношення arrivalTime і
arrivalDate ).
Задачі систем виявлення
семантичних Web-сервісів
Розглянемо процес виявлення Web-
сервісів, який схематично показано на
рисунку, та його основні задачі на основі
стандартного фреймворку системи вияв-
лення, представленого в роботі [32]. По-
стачальники сервісів публікують оголо-
шення про Web-сервіси в централізовано-
му сховищі через Web-сайт системи або на
власних Web-сайтах. Web-робот (Web
crawler) може зібрати всі ці семантичні
описи з окремих сайтів публікації і збері-
гати їх в централізованому сховищі без ві-
дома провайдерів. Запитувачі сервісів, що
шукають сервіси, які відповідають певним
вимогам, представляють свої запити пев-
ною мовою. Тут запитувачі сервісів і пос-
тачальники є загальними термінами, що
використовуються, наприклад, для позна-
чення окремих агентів, які беруть участь у
транзакціях. Репозиторій/реєстр сервісів
агрегує оголошені сервіси після вирішен-
ня проблем неоднорідності (якщо такі є)
за допомогою посередника. Коли ініцію-
ється запит на сервіс, то він спочатку по-
рівнюється з сервісами в репозиторії за
допомогою механізму метчмейкінгу
(matchmaking engine). Після цього отри-
мується набір підібраних сервісів, далі
відбувається узгодження сервісів за допо-
могою взаємодії з провайдерами для до-
ступу до динамічної інформації, якщо та-
ка є. Вибір сервісу проводиться з ураху-
ванням критеріїв, яким надає перевагу за-
питувач, та/або на основі не функціональ-
них (QoS) характеристик сервісу. Нареш-
ті, вибраний сервіс викликається і повер-
таються результати.
Як бачимо, процес виявлення Web-
сервісів охоплює весь спектр завдань від
запиту на сервіс до виклику сервісу. Вирі-
шення проблем, пов’язаних з виявленням
сервісів, залежить від того, як описати сер-
віси і як управляти цими описами. Розгля-
немо основні задачі, які мають бути вирі-
шені при розробці систем виявлення: пуб-
лікація, зберігання сервісів, створення за-
питів на сервіс, метчмейкінг сервісу, узго-
дження і вибір сервісу, інтеграція вияв-
лення і композиції сервісів та інші.
Публікація сервісу. Постачальники
сервісів проектують і розробляють сервіси
з певною бізнес-метою. Сервіси потім роз-
гортають на серверах, так що вони можуть
бути викликані іншими сервісами або аге-
нтами. Для того, щоб бути викликаними,
вони мають бути описані мовами опису,
такими як, наприклад, OWL-S, WSMO,
DL. Більшість інструментів у даний час
підтримують генерацію WSDL автоматич-
но, коли сервіси розгортаються. Файли
WSDL можуть бути анотовані WSDL-S
або SAWSDL, щоб вставити семантику. У
деяких випадках провайдери можуть та-
кож створювати свої власні мови семанти-
чного опису, такі як в DIANE [33]. Модуль
публікації надає користувачу програмний
інтерфейс для додавання, видалення або
Програмування для комп’ютерних мереж та Internet
63
Рисунок. Процес виявлення Web-сервісів
оновлення описів Web-сервісів, а також
додавання, видалення або оновлення опи-
сів провайдерів. Крім аутентифікації, за-
пит на публікацію, який ініціює процес
публікації, може включати в себе наступні
параметри: ідентифікатор постачальника
сервісу, URL (Uniform Resource Locator),
який вказує на документ, що описує сервіс,
довільне ім’я сервісу і необов’язковий тек-
стовий опис. Далі, на основі цих вхідних
даних відбувається процес, який включає
кілька етапів, як це представлено, напри-
клад, у проекті FUSION [34]. Відбувається
розбір документа, що представляє сервіс,
витягується семантична інформація про
входи і виходи сервісу. Наступним кроком
у процесі публікації є відображення отри-
маної інформації в UDDI-оголошення
сервісу. Створюється функціональний
профіль оголошення, який далі класифіку-
ється щодо усіх відомих функціональних
профілів запитів. Мета цієї процедури кла-
сифікації полягає у тому, щоб визначити
профілі запитів, які нове додане оголо-
шення сервісу може легко задовольнити.
Такий підхід збільшує час, необхідний
для завершення публікації оголошення про
сервіс, але суттєво скорочує час, необхід-
ний для виконання зіставлення під час ви-
явлення. Виразність мови опису надзви-
чайно впливає на якість процедури вияв-
лення. Крім того повнота описів також
впливає на процес зіставлення. Мова опи-
су має забезпечувати також можливість
представлення QoS-характеристик сервісу.
В роботах [35, 36] запропоновані
підходи для опису характеристик QoS за
рахунок розширення поточної моделі
UDDI. Ряд інших робіт висвітлюють під-
ходи до використання зібраної QoS-
інформації. Так, в роботі [37] пропонують
нову мову запитів, що дозволяє шукачам
заявити вимоги QoS. Для оцінки подібно-
сті між запитом, на основі UML (Unified
Modeling Language), і доступними серві-
сами використовується процес у два ета-
пи. На першому етапі витягуються сервіси
з операціями, які задовольняють не функ-
ціональні вимоги запиту. Другий крок ви-
користовує евристики подібності, заснова-
ної на граф-відповідності, для знаходжен-
ня операцій, які найкращим чином відпо-
відають запиту. Автори роботи [38] пред-
ставляють функцію ранжування Web-
сервісів відповідно до їх QoS-
характеристик, які були зібрані за допомо-
гою брокера. Функція обчислює матрицю,
яка представляє собою Web-сервіс у рядку
Реєстр
Web-
сервіси
Публікація описів
Список
сервісів
Запит на
сервіс
Пошук Узгодження Фільтрування Вибір Виклик
Web-
сервіси
Конкретні
пропозиції
Придатні
пропозиції
Вибрана
пропозиція
SOAP
повідомлення
Що ви
пропонуєте?
Програмування для комп’ютерних мереж та Internet
64
і кожен окремий параметр QoS в стовпці.
У зв’язку з тим, що параметри QoS варію-
ються в одиницях і величинах, значення
нормуються. Потім шукач визначає вектор
ваг, що вказує рівень важливості, призна-
чений кожному параметру QoS. Нарешті,
ці ваги вводяться в матрицю як фактори і
всі значення перераховуються. Рядок, який
максимізує суму його зважених парамет-
рів, являє собою перший за рейтингом
Web-сервіс і так далі.
Посередник. Описи сервісів і запи-
ти можуть бути описані на різних мовах,
що призводить до проблем неоднорідності.
Система виявлення має підтримувати по-
середництво між мовами або вирівняти
описи до стандартної мови. Крім того, мо-
жливе синтаксичне посередництво, яке до-
лає синонімію (слова, які представляють
одне і те ж поняття, але синтаксично відрі-
зняються один від одного), долає різні
WSDL-стилі для визначення типів даних.
Описи семантичних Web-сервісів і запити
можуть використовувати різні онтології.
Система виявлення має забезпечити посе-
редника між двома або більше онтологіями
для їх вирівнювання, або ж зобов’язати
постачальників і споживачів погодитися на
спільну онтологію.
Зберігання сервісів. Описи сервісів
будуть зберігатися в реєстрі сервісів або
базі даних. Онтології домену охоплюють
термінологію, яку використовують про-
вайдери і замовники для опису сервісів.
Потрібна відповідна технологія індексації
для розширеної обробки запитів. Різні мо-
ви опису можуть вимагати різних методів
для індексації та зберігання сервісів, зале-
жно від вимог застосувань. Реєстр може
класифікувати сервіси відповідно до їх
домену застосування, провайдера сервісів і
т. д. Важливо зазначити, що реєстр серві-
сів не містить фактичних екземплярів сер-
вісів, а тільки прив’язку описів сервісів до
фактичних екземплярів сервісів. Структура
реєстру має забезпечувати достатньо інфо-
рмації для процесу виявлення. Задача збе-
рігання сервісів тісно пов’язана з видом
архітектури, на яку буде покладена систе-
ма, тобто централізована або децентралі-
зована. Централізовані системи виявлення
покладаються на один єдиний глобальний
реєстр, а децентралізовані – на розподілені
технології, такі як Peer-to-Peer (P2P), щоб
публікувати описи сервісів на різних вуз-
лах. UDDI-реєстр з його синтаксичним
встановленням відповідності служить ос-
новою для багатьох систем виявлення
сервісів. Деякі підходи [39] розширюють
модель даних UDDI семантичними описа-
ми OWL-S, комбінуючи синтаксичне і се-
мантичне встановлення відповідності
(matchmaking).
Децентралізовані архітектури є
прийнятною альтернативою для досягнен-
ня належного рівня масштабованості, на-
дійності та відмовостійкості. Зокрема, з
Peer-to-Peer (P2P) [40] розподіленими архі-
тектурами, всі вузли-учасники передбача-
ють клієнтські і серверні завдання, розді-
ляють свої можливості і використовують
накопичені можливості учасників мережі.
Теоретично, ідеальна P2P підтримує не-
скінченну кількість вузлів, кумулятивні
можливості також нескінченні, і відмова
партнера не впливає на всю мережу. UDDI
специфікація визначає інтегрований реєстр
як один або більше децентралізованих вуз-
лів UDDI. Через децентралізований харак-
тер розподілених архітектур ефективне
опитування таких розподілених реєстрів
означає більш складні завдання [41].
Запит на сервіс оголошує намір
замовника (людина, агент, сервіс) щодо
необхідної функціональності сервісу. Це –
формальний чи неформальний опис функ-
ціональних і технічних можливостей
та/або обмежень, які мають бути задоволе-
ні виявленим сервісом. Запит визначається
на мові, виразність якої дуже впливає на
якість процедури виявлення. І запит, і ого-
лошення сервісу, зазвичай, визначаються
на мовах опису сервісів з певною виразніс-
тю. У системах виявлення сервісів на ос-
нові синтаксичних підходів запити форму-
люють на основі ключових слів і в тексто-
вій формі. Система Woogle [42], напри-
клад, очікує WSDL-документ як запит.
У системі FUSION [34] функціона-
льний профіль запиту й оголошення на
сервіс моделюються за єдиною онтологі-
єю. Профіль запиту може бути поперед-
ньо зареєстрований і проіндексований в
Програмування для комп’ютерних мереж та Internet
65
системі. При появі нового оголошення на
сервіс встановлюється відповідність між
існуючими профілями запитів.
Різні мови запитів дозволяють дося-
гти різних ступенів точності в результатах
пошуку. Результати пошуку, отримані за
допомогою семантичних анотацій, якісно
кращі, ніж результати, досягнуті підхода-
ми за ключовими словами, бо мови запитів
на основі семантики дозволяють шукачам
точно сформулювати свої потреби. У разі
запитів на основі обмежень і на основі се-
мантики, моделювання мети може вимага-
ти від розробників вивчати нову мову за-
питів.
Так в роботі [43] запропонована
мова EAGLE для вираження мети, яку має
задовольняти шуканий сервіс. В реальних
бізнес-сценаріях обмежень на типи вхід-
них і вихідних параметрів, шаблони взає-
модії і нефункціональні властивості Web-
сервісів буває недостатньо. В роботі [44]
запропонували мову специфікації мети,
яка є комбінацією μ-числення темпораль-
ної логіки та виразної дескриптивної ло-
гіки SHIQ(D). У системах на основі
WSMO запити описуються в термінах ці-
лей, тобто результатів, очікуваних запи-
тувачем.
Метчмейкінг сервісу (matchmaking)
– це метод зіставлення запитаного сервісу
з оголошеними сервісами. Результатом
метчмейкінгу є список оголошених серві-
сів разом з їх ступенем відповідності (DoM
– Degree of Match), який представляє, як
підходить оголошений сервіс. Він являєть-
ся найбільш важливим і складним проце-
сом у всьому процесі виявлення. Більшість
підходів метчмейкінгу сервісів використо-
вують атрибути IOPE (Inputs, Outputs,
Preconditions and Effects), описані в профі-
лі сервісу. Однак, незалежно від того, на
яких елементах застосований відповідний
алгоритм, найважливіша проблема
метчмейкінгу полягає у тому, що нереаль-
но очікувати, що оголошення і запити бу-
дуть в ідеальній парі. Поняття DoM має
справу з такими проблемами і може бути
неформально визначено як значення з упо-
рядкованого набору значень, яке виражає,
наскільки два об'єкти є подібними щодо
деякої метрики подібності. Такі об’єкти
можуть бути сервісами, атрибутами IOPE
або певними операціями сервісу. Алгоритм
метчмейкінгу сервісу, який обчислює
DoM, може використовуватися для того,
щоб оцінити виявлені сервіси згідно їх ре-
левантності до сформованого запиту.
Нехай S=(Is, Os) – сервіс та Q=(Iq,
Oq) – запит на сервіс, де:
Is, Iq – кінцеві множини входів
оголошення та запиту на сервіс,
Os, Oq – кінцеві множини вихо-
дів оголошення та запиту на сервіс.
Ступінь відповідності між двома
входами або двома виходами залежить від
відношення між концептами, які пов’язані
з цими входами або виходами, а саме, мі-
німальною відстанню між цими поняттями
у дереві таксономії. Розрізняють наступні
ступені відповідності [30]: Exact, PlugIn,
Subsumes, Fail. Exact – точне збігання
– можливе, коли Oq=Os, або Oq є підкла-
сом Os. PlugIn – більш слабкий зв’язок,
якщо Os включає Oq. Subsumes – якщо Oq
включає Os, то провайдер не повністю за-
довольняє запит. Це означає, що провай-
дер частково задовольняє мету, тому запи-
тувачу прийдеться виконати інші запити,
щоб досягти своєї мети. Fail – невдача,
якщо не знайдено будь-якого відношення
категоризації між Oq та Os.
Ми можемо класифікувати підходи
метчмейкінгу за різними критеріями. Одна
можлива класифікація наступна [45]:
• прямий: запит на сервіс узгоджу-
ється з одиничними оголошеннями серві-
сів;
• непрямий: запит на сервіс узго-
джується з композитними сервісами, які
побудовані з простих або складних робо-
чих процесів з оголошень одиночних
сервісів.
Крім того, можна було б також кла-
сифікувати метчмейкінг як: підтримка
DoM чи ні, використання тільки профілю
сервісу або іншої інформації про сервіс, а
також, оцінка подібності сервісів за допо-
могою заснованого на логіці міркування
або інших методів. Більшість підходів за-
сновані на онтологіях анотації сервісів,
виражених у дескриптивних логіках і, та-
ким чином, виконують метчінг на основі
DL [45, 46].
Програмування для комп’ютерних мереж та Internet
66
Виділяють наступні групи підходів
встановлення відповідності:
Семантичний метчінг здібностей.
Основна ідея полягає у тому, що «оголо-
шення відповідає запиту, якщо всі виходи
запиту відповідають виходам оголошення,
і всі входи оголошення відповідають вхо-
дам запиту». Таким чином, цей метод
приймає до уваги тільки входи і виходи
профілів сервісів під час метчмейкінгу.
Ступінь відповідності між двома виходами
або двома входами залежить від відно-
шення між концептами онтології домену,
пов’язаними з цими входами і виходами.
Багаторівневий метчінг. Процес
метчмейкінгу виконується на багатьох рів-
нях, тобто, між входами/виходами, катего-
ріями сервісу і іншими параметрами
сервісу (наприклад, QoS). Крім того, він
представляє поняття агрегації DoM, яке
може забезпечити більш модульне та ефе-
ктивне ранжування відповідних сервісів, за
допомогою призначення різних ваг різним
рівням метчінгу.
DL метчмейкінг на основі профілю
сервісу. Метчмейкінг сервісів виконується
через онтологію профілю сервісу. В цій
онтології кожен сервіс представлено скла-
дним DL виразом концепту, який описує
всі обмеження сервісу (входи, виходи і
т. д.). Таку онтологію можна розглядати як
заснований на логіці реєстр оголошень
сервісів. Як тільки така онтологія визна-
чена і містить всі доступні оголошення
сервісів, запити на сервіси можуть бути
виражені через концепти DL і вставлені в
неї. Потім може використовуватись меха-
нізм міркувань (reasoner) DL, щоб класи-
фікувати запит-концепт в онтології.
Підхід на основі графа. Опис серві-
су (запит або оголошення) представляють
у вигляді направленого графа (RDF-граф),
вершини якого – екземпляри концептів
(тобто, індивіди) і дуги – властивості (тоб-
то, ролі концепту), які зв’язують такі екзе-
мпляри. Корінь кожного графа – індивід,
який представляє оголошення/запит серві-
су. Метчмейкінг між двома графами, один
– представляє запит на сервіс, а інший –
представляє оголошення сервісу, викону-
ється рекурсивним алгоритмом, викори-
стовуючи метчінг стандартної категориза-
ції через оператор «subsumes» [47].
Непрямий метчінг на основі графа.
Непрямий метчінг відноситься до іденти-
фікації композицій сервісів, які найбільш
релевантні запиту користувача. У випадку
простої композиції, ми можемо думати про
них як про потоки робіт, подібних графу,
які можуть бути скорочені до «ланцюжків
сервісів» (тобто, нециклічні шляхи в графі
потоку робіт) у самих простих випадках
[48]. Основна ідея побудови простих ком-
позитних сервісів (тобто, ланцюжка серві-
сів) базується на наступному:
входи кожного сервісу, включеного
в композицію, мають відповідати входам,
отриманим із запиту на сервіс, або вихо-
дам попереднього сервісу в ланцюжку;
кожен вихід запиту на сервіс має
відповідати виходу останнього сервісу в
ланцюжку.
Непрямий метчінг на основі зворо-
тної побудови ланцюжка. Зворотна побу-
дова ланцюжка – цільова процедура мірку-
вання, подібна способу, яким працює мо-
ва Пролог. Основна ідея підходу полягає
у тому, що починаючи з сервісів, які
відповідають виходам запиту на сервіс, а
не його входам, ми рекурсивно пробуємо
з’єднати їх з іншими сервісами, поки не
знайдемо сервіс з усіма його входами, що
відповідають входам даного запиту на
сервіс [49].
Як згадувалось вище, реальні Web-
сервіси виступають як складні бізнес-
процеси і потребують опису у відповідних
мовах, як наприклад WS-BPEL, і моделю-
вання їх поведінки з урахуванням станів.
Виявлення Web-сервісів на функціональ-
ному рівні може не задовольняти користу-
вача, якщо він має вимоги на поведінку
сервісу. Щоб здійснювати пошук Web-
сервісів на процесному рівні, вони можуть
бути описані як системи переходів із стану
в стан (state transition system), при цьому
вимога пошуку описана в темпоральній
логіці. В роботі [50] пропонується алго-
ритм виявлення сервісів, який поєднує в
собі міркування про процедурні поведін-
ки, які мають задовольняти темпоральні
умови, а також онтологічні міркування
про семантику даних. Встановлення від-
Програмування для комп’ютерних мереж та Internet
67
повідності між запитом і сервісом зводить-
ся до проблеми перевірки моделі (model
checking).
Узгодження сервісу. Вирішення
цієї задачі необхідно після того, як замов-
ник отримує перелік сервісів, які відпові-
дають його запиту. Щоб зробити оптима-
льний вибір, між провайдером сервісу і
замовником можуть знадобитися перего-
вори. Для цього існують різні механізми,
починаючи від підходів простого вибору
на основі якісних властивостей сервісу
(QoS) [51] до складних переговорів або
схем аукціону. Укладаються контракти
між відповідними бізнес-партнерами і во-
ни формалізуються способом, зрозумілим
машині, щоб дозволити автоматичне ви-
конання та моніторинг.
Вибір сервісу являє собою етап ви-
значення того, який сервіс (сервіси) вико-
ристати для доставки потрібного сервісу.
Це остаточне рішення залежить від резуль-
татів метчмейкінгу і узгодження.
При наявності декількох Web-
сервісів з ідентичною функціональністю,
користувачі будуть розрізняти їх на основі
QoS, поняття, яке охоплює цілий ряд не-
функціональних властивостей таких як:
ціна, доступність, надійність і репутація
[52]. Ці властивості застосовуються як до
атомарних Web-сервісів, так і до компози-
тних Web-сервісів. Для того, щоб міркува-
ти про QoS-властивості Web-сервісів, не-
обхідна модель, яка охоплює описи Web-
сервісів з точки зору користувача. Така
модель має брати до уваги той факт, що
QoS включає у себе кілька розмірностей, і
той факт, що QoS композитних сервісів
визначається на основні QoS компонент-
них сервісів. Крім того, варто зазначити,
що сервіси зазвичай розповсюджуються
через Інтернет і що деякі з їх QoS-
характеристик (наприклад, доступність і
коефіцієнт успішного виконання) залежать
від каналу зв’язку і мають бути оцінені з
точки зору запитувача, а не постачальника.
Таким чином, за наявності, щонайменше,
двох сервісів, призначених для виконання
однієї і тієї ж задачі, опис запропонованого
QoS стає важливим фактором у розрізнен-
ні постачальників сервісів.
Web-робот. Система виявлення
Web-сервісів крім можливості публікації
сервісів може наповнювати реєстр сервісів
за допомогою Web-робота, метою якого є
збір семантичних описів Web-сервісів,
шляхом відвідування Інтернету, знахо-
дження головних Web-сайтів і розбір опи-
сів сервісів. Ці описи можуть бути вира-
жені в деякій мові, наприклад, OWL-S або
WSDL-S, або на будь-якій іншій мові роз-
мітки. Очевидно, що якщо видавець серві-
су не пропонує семантичний опис Web-
сервісу, опубліковані Web-сервіси не бу-
дуть збиратися в реєстри семантичних
Web-сервісів. Цей Web-робот є прикладом
цілеспрямованого шукача: він не просто
збирає все, з чим він стикається, він збирає
тільки описи семантичних Web-сервісів.
Очевидна проблема, яка виникає, це «роз-
сіяність» описів сервісів. Іншими словами,
не так багато семантичних описів Web-
сервісів в Інтернеті для збору і більшість
сторінок, відвіданих Web-роботом, не ма-
ють нічого спільного з семантичними
Web-сервісами. Ця задача системи вияв-
лення Web-сервісів спонукає до розробки
так званих спеціалізованих механізмів
пошуку (search engine), спрямованих на
виявлення описів Web-сервісів, як семан-
тичних (OWL-S, SAWSDL ), так і не се-
мантичних (WSDL) у Інтернеті. Такі по-
шукові механізми були запропоновані
останнім часом: Woogle [53], VUSE [54],
SWSE [55], OSSE [56], але немає доступ-
ної їх реалізації.
Інтеграція пошуку і композиції
Web-сервісів. Механізм виявлення сервісів
має включати можливості композиції сер-
вісів. Це робить композицію сервісів час-
тиною виявлення сервісів і навпаки. Задача
інтеграції пошуку і композиції виникає то-
ді, коли єдиний сервіс не може виконати
цілісну задачу (запит на сервіс). Запит мо-
же бути задоволений композицією сервісів
на функціональному рівні, тобто компози-
ція шляхом зіставлення передумов і ефек-
тів сервісів, описаних як атомарні компо-
ненти, які, враховуючи деякі входи, повер-
тають деякі виходи [57, 58].
Тим не менш, побудова композиції
не є тривіальним завданням. Треба мати
справу з різними умовами, вимогами і ре-
Програмування для комп’ютерних мереж та Internet
68
зультатами, отриманими від кожного ок-
ремого сервісу. Ця проблема може стати
ще більш складною через синтаксичний
опис сервісів і необхідність розуміння се-
мантики операцій. Крім того, процес вияв-
лення повторюється під час процесу ком-
позиції, тобто, водночас як композиція бу-
дується, нові сервіси мають бути виявлені
й об’єднані з композицією. Цей процес
продовжується до тих пір, поки не буде
отримано необхідну функціональність, не
буде більше знайдено збігів або досягаєть-
ся критерій зупинки процесу композиції
(наприклад, максимальна кількість сервісів
у композиції). В роботі [59] запропоновано
підхід, який дозволяє автоматичне вияв-
лення і композицію під час обробки запи-
ту. Він характеризується використанням
семантичних анотацій на основі SAWSDL,
щоб побудувати граф композиції.
Підхід до наскрізної (end-to-end) ін-
теграції виявлення і композиції, запропо-
нованої у дослідженні [60], працює в два
етапи. На першому етапі, тобто в момент
виявлення та протягом композиції на фун-
кціональному рівні, необхідно визначити
набір Web-сервісів, що взаємодіючи один з
одним, у змозі відповідати запиту компо-
зиції. У центрі уваги є необхідні входи і
надавані виходи сервісів, щоб отримати
виходи, необхідні користувачу. Напри-
клад, на цьому рівні ми виявляємо, що
сервіс «бронювання готелів» і сервіс «бро-
нювання авіаквитків», необхідні, щоб за-
довольнити запит на відпустку користува-
ча. На другому етапі, враховуючи набір
обраних Web-сервісів і з урахуванням мети
композиції, композиція рівня процесу від-
повідає за генерування автоматично вико-
нуваного композитного Web-сервісу. На-
приклад, дано моделі процесів двох досту-
пних Web-сервісів для «бронювання готе-
лів» і «бронювання польоту», ми прагнемо
генерувати виконуваний композитний сер-
віс, скажімо, «віртуальна туристична фір-
ма». Взаємодіючи з сервісами «бронюван-
ня готелів» і «бронювання польоту», ком-
позитний сервіс бронює готельні номери
та місця для польоту відповідно до заданої
мети.
Підхід до композиції сервісу функ-
ціонального рівня, запропонований в [61],
заснований на прямій побудові ланцюжка.
Неформально, ідея прямої побудови лан-
цюжка полягає у тому, щоб ітеративно ви-
брати можливий сервіс S і застосувати йо-
го до набору вхідних параметрів, які нада-
ються метою G (тобто, всі входи, необхідні
для S, мають бути доступні). Якщо засто-
сування S не вирішує цю проблему (тобто,
ще не всі виходи, необхідні для мети G,
доступні), то нова мета G′ може бути об-
числена з G і з виходів, породжених S, і в
цілому процес повторюється.
Деталізація результатів пошуку
системи виявлення. Це завдання полягає
у здатності системи виявлення сервісів
повертати описи сервісів на рівні описів
операцій. Деталізація результатів має важ-
ливе значення для виклику виявлених сер-
вісів. Операція визначається як найменша
частина програмного забезпечення, яку
шукач може викликати за допомогою
Web-сервісів. Розглянемо, наприклад,
Web-сервіс, який надає класичні операції
електронної пошти, такі як перевірка до-
стовірності адреси, фільтрування спаму і
відправка анонімних повідомлень. Якщо
цей сервіс повертається при пошуку серві-
су фільтру спаму, то споживач має про-
аналізувати опис Web-сервісу, щоб отри-
мати відповідну операцію. В ідеалі, вияв-
лення операцій дозволяє споживачам без-
посередньо викликати їх. І навпаки, якщо
деталізація результатів є «сервіс», то шу-
кач має розібрати опис знайденого сервісу,
щоб проаналізувати його операції. Тим не
менш, деякі сервіси представляють впо-
рядковані залежності між їх операціями.
Наприклад, платні Web-сервіси часто ви-
магають виклик операції, яка перевіряє об-
ліковий запис, наприклад, «log-in»,
перед викликом будь-якої іншої запропо-
нованої операції. У цьому контексті важ-
ливо, щоб шукач отримав також весь
опис сервісу.
Висновки
Парадигма сервіс-орієнтованого об-
числення замінює розробку конкретних
програмних компонентів комбінацією ви-
явлення сервісів, відбору та виклику. Оскі-
льки ця парадигма може бути реалізована
відповідно до різних масштабів, які варі-
Програмування для комп’ютерних мереж та Internet
69
юються від всередині програми до всере-
дині компанії, а також різні рівні автома-
тизації, то виявлення сервісів створює ба-
гато проблем. Ці проблеми ініціюють ряд
альтернатив для виявлення сервісів. У цій
роботі подана формалізація виявлення
Web-сервісів на основі покриття-
виведення в контексті дескриптивної логі-
ки. Представлено огляд основних задач і
існуючих підходів до їх вирішення при
створенні систем виявлення Web-сервісів.
Виявлення Web-сервісів залежить від се-
мантичного формалізму, який використо-
вують для опису сервісів. Рівень опису
сервісу – функціональний, чи рівень про-
цесу – впливає на методи моделювання
сервісів та алгоритми і методи встанов-
лення відповідності при виявленні серві-
сів. Середовище функціонування системи
виявлення потребує різних архітектур по-
будови систем. Взаємозалежність і різні
підходи до вирішення задач систем вияв-
лення Web-сервісів вплинули на появу ці-
лого ряду систем, про що свідчить велика
кількість оглядових статей у цьому напря-
мку. Ця робота дозволить зацікавленим
особам не тільки вибрати найбільш підхо-
дящий існуючий підхід для виявлення
Web-сервісів, а й мотивувати дослідження
методів отримання Web-сервісів, які більш
прийнятні для виявлення.
1. Erickson J., & Siau K. Web Service, Service-
Oriented Computing, and Service-Oriented
Architecture: Separating hype from reality //
Journal of Database Management. – 2008.
19(3). – P. 42–54.
2. Дерецкий В. Разработка приложений в сер-
вис-ориентированной архитектуре семан-
тического Веб // Пробдеми програмування.
− 2010. − № 1. − C. 66–78.
3. Li S.-H., Huang S.-M., Yen D. C., & Chang C.
C. Migrating legacy information systems to
Web Services architecture // Journal of
Database Management, 2007. – 18(4). –
P. 1–25.
4. Song H., Cheng D., Messer A., & Kalasapur
S. Web Service discovery using general-
purpose search engines // In Proceedings of
the IEEE International Conference on Web
Services. – 2007 – P. 265–271.
5. Garofalakis J.D., Panagis Y., Sakkopoulos E.,
& Tsakalidis, A.K. Contemporary Web
Service Discovery Mechanisms // Journal of
Web Engineering. – 2006. – 5(3). –
P. 265 – 290.
6. Paolucci M., & Sycara K. Autonomous
semantic Web Services // IEEE Internet
Computing. – 2003. – 7(5). – P. 34–41.
7. http://help.eclipse.org/juno/topic/org.eclipse.js
t.ws.doc.user/concepts/cwsil.html?cp=66_3_0
_0_3
8. Xia Wang and Wolfgang A. Halang.
Discovery and Selection of Semantic Web
Services, volume 453, 2013. Springer-Verlag
Berlin Heidelberg, studies in computational
intelligence edition, 2013.
9. WS-Gloss: http://www.w3.org/tr/ws-gloss/,
2004.
10. Yu Q., Liu X., Bouguettaya A., & Medjahed B.
Deploying and managing Web Services:
issues, solutions, and directions // The
International Journal on Very Large Data
Bases. – 2008. – 17(3). – P. 537–572.
11. Studer R., Grimm S., and Abecker A.
Semantic Web Services: Concepts,
Technologies, and Applications. Springer,
2007.
12. The OWL Services Coalition. OWL-S:
Semantic Markup forWeb Services. In
Technical White paper (OWL-S version 1.0),
2003.
13. http://www.w3.org/Submission/WSMO/.
14. WSDL, http://www.w3.org/TR/wsdl.
15. UDDI, http://uddi.xml.org/.
16. NAICS, http://www.naics.com.
17. jUDDI, http://ws.apache.org/juddi/.
18. http://docs.oasis-open.org/wsbpel/2.0/
OS/wsbpel-v2.0-OS.pdf
19. Wang S., Zhang L., & Ma N. A quantitative
measurement for reputation of Web Service
and providers based on cloud model // In
Proceedings of the International Conference
on Computational Intelligence for Modelling,
Control and Automation. Los Alamitos,
CA: IEEE Computer Society. – 2008. –
P. 500–505.
20. Martin D., Burstein M., Mcdermott D.,
Mcilraith S., Paolucci M., & Sycara K.
Bringing semantics to Web Services with
OWL-S. World Wide Web (Bussum). – 2007.
10(3). – P. 243–277.
21. Sivashanmugam K., Verma K., Sheth A. P., &
Miller J. A. Adding semantics to Web
Services standards. In Proceedings of the
2003 International Conference on Web
Services, Las Vegas, NV CSREA Press. –
2003. – P. 395–401.
22. Lausen H, et al. WSML – a language
framework for semantic web services. In:
http://help.eclipse.org/juno/topic/org.eclipse.jst.ws.doc.user/concepts/cwsil.html?cp=66_3_0_0_3
http://help.eclipse.org/juno/topic/org.eclipse.jst.ws.doc.user/concepts/cwsil.html?cp=66_3_0_0_3
http://help.eclipse.org/juno/topic/org.eclipse.jst.ws.doc.user/concepts/cwsil.html?cp=66_3_0_0_3
http://www.w3.org/Submission/WSMO/
Програмування для комп’ютерних мереж та Internet
70
Position paper for the W3C rules workshop.
Washington DC, USA. – 2005.
23. Sapkota B., et al D21.v0.1 WSMX Triple-
Space Computing. In: Sapkota B., Martin-
Recuerda F. (eds) WSMO working draft. –
2005.
24. S. Staab, R. Studer. Handbook on Ontologies.
Second edition.
25. E. by F. Baader, D. McGuinness, D. Nardi,
and P. F. Patel-Schneider. Description Logic
Handbook: Theory, Implementation and
Applications. Cambridge University Press,
2002.
26. Teege G. Making the difference: a subtraction
operation for description logics. In: Doyle J,
Sandewall E, Torasso P(eds) Proceedings of
KR’94, location, day month 1994. Morgan
Kaufmann, San Francisco. – 1994.
27. Baader F., KЁusters R., Molitor R.
Computing least common subsumer in
description logics with existential restrictions.
In: Dean T (ed) Proceedings of the 16th
international joint conference on AI,
Stockholm, Sweden, 31 July–6 August 1999,
P. 96–103.
28. Benatallah B., Hacid M.-S. et al. On
automating web services discovery // VLDB
J. – 2005. 14(1). – P. 84–96.
29. Benatallah B., Hacid M-S, Rey C., Toumani
F. Request rewriting-based Web service
discovery. In: Fensel D, Sycara K,
Mylopoulos J (eds) Proceedings of the
international Semantic Web conference
(ISWC 2003), Sanibel Island, FL, October
2003. Lecture notes in computer science, vol
2870. Springer, Berlin Heidelberg NewYork,
P. 242–257.
30. Paolucci M., Kawamura T., Payne T.R., &
Sycara K.P. Semantic matching of Web
services capabilities. In I. Horrocks & J.
Hendler (Eds.), First International Semantic
Web Conference on the Semantic Web,
Sardinia. Springer-Verlag. – 2002. – P. 333–
347.
31. Benatallah B., Hacid M.-S., Rey C., Toumani
F. Semantic reasoning for Web services
discovery. In: Proceedings of the WWW
workshop on e-services and the
SemanticWeb, Budapest, Hungary, May
2003.
32. Le Duy Ngan, Rajaraman Kanagasabai
Semantic Web service discovery: state-of-the-
art and research challenges, Pers Ubiquit
Comput. Springer-Verlag. – 2013. – 17. –
P. 1741–1752.
33. Kuster U. et al DIANE: a matchmaking-
centered framework for automated service
discovery, composition, binding, and
invocation on the web // Int J Electron
Commer. – 12(2). – P. 41–68.
34. http://www.seerc.org/fusion/semanticregistry.
35. Ran S. A model for Web Service discovery
with QoS. SIGecom Exchanges. 4(1). –
P. 1–10.
36. Overhage S., & Thomas P. Ws-specification:
Specifying Web Services using uddi
improvements // In Revised Papers from the
NODe 2002 Web and Database-Related
Workshops on Web, Web-Services, and
Database Systems, London, P. 100–119.
37. Kozlenkov A., Spanoudakis G., Zisman A.,
Fasoulas V., & Sanchez Cid, F. Architecture-
driven service discovery for service centric
systems // International Journal of Web
Services Research. – 2007. – 4(2). P. 82–113.
38. Al-Masri E., & Mahmoud Q.H. Qos-based
discovery and ranking of Web Services // In
Proceedings of the International Conference
on Computer Communications and Networks
Los Alamitos. – 2007. – P. 529–534.
39. Q. Qiu Q. Xiong Y. Yang and F. Luo, “Study
on ontology-based web service discovery” //
In IEEE Internationl Conference on Computer
Supported Cooperative Work in Design. –
2007. – Vol. 11, P. 641–645.
40. Gotthelf P., Zunino A., & Campo M. A. Peer-
To-Peer communication infrastructure for
groupware applications // International
Journal of Cooperative Information Systems.
– 2008. – 17(4). – P. 523–554.
41. Firat A., Wu L., & Madnick S. General
strategy for querying web sources in a data
federation environment // Journal of Database
Management. – 2009. – 20. P. 1–18.
42. Dong Z., Halevy A. Y., Madhavan J., Nemes
E., & Zhang J. Similarity search for Web
Services // In Proceedings of the Thirtieth
International Conference on VeryLarge Data
Bases, Toronto, ON, Canada. – 2004. –
P. 372–383.
43. U. Dal Lago M. Pistore and P.Traverso.
Planning with a Language for Extended Goals
// In Proc. AAI’02, 2002.
44. Sudhir Agarwal. A Goal Specification
Language for Automated Discovery and
Composition of Web Services. In Tsau Young
Lin, Laura Haas, Janusz Kacprzyk, Rajeev
Motwani, Andrei Broder, Howard Po,
International Conference on Web Intelligence
(WI `07), Silicon Valley, California,
USA, November, 2007. P. 528–534.
45. Tsetsos V., Anagnostopoulos C., and
Hadjiefthymiades S. Semantic web service
discovery: methods, algorithms and tools. In:
Програмування для комп’ютерних мереж та Internet
71
Cardoso, J. (ed.) Semantic Web Services:
Theory, Tools and Applications. Information
Science Reference, Hershey, PA. – 2007.
46. Baader F., Calvanese D., McGiuness D.,
Nardi D., & Patel-Schneider P. The
description logic handbook: Theory,
implementation, and applications. Cambridge:
Cambridge University Press. – 2003.
47. Trastour D., Bartolini C., & Gonzalez-
Castillo J. A Semantic Web approach to
service description for matchmaking of
services // Paper presented at the Semantic
Web Working Symposium, Stanford,
California. –2001.
48. Giv R.D., Kalali B., Zhang S., & Zhong N.
Algorithms for direct and indirect dynamic
matching of Web services (Tech. Rep.).
Waterloo, Ontario, Canada: University of
Waterloo, School of Computer Science. –
2004.
49. Brachman R., & Levesque H. Knowledge
representation and reasoning. San Francisco:
Morgan Kaufmann. – 2004.
50. Pagliarecci F., Pistore M., Spalazzi L., Tra-
verso P. Web service discovery at process-
level based on semantic annotation. In
Proceedings of the Fifteenth Italian
Symposium on Advanced Database Systems
(SEBD 2007), 17–20 June, Torre Canne, BR,
Italy, 2007.
51. Hung PCK, Zhang L-J. Behind the scenes of
web services negotiation and agreement. Int J
Web Serv Res (JWSR). – 2004. – 1(2). –
P. 37–57.
52. O’Sullivan J., Edmond D., and Hofstede A.t.,
“What’s in a Service?” Distributed and
Parallel Databases, 2002. – Vol. 12, nos. 2-3.
– P. 117–133.
53. Dong X., Halevy A., Madhavan J., Nemes E.,
Zhang J. Similarity search for web services,
Proceedings of VLDB, 2004.
54. Platzer C., Dustdar S. A Vector Space Search
Engine for Web Services // In Proceedings of
the 3rd European IEEE Conference on Web
Services, 2005.
55. Ma C., Song M., Xu K., Zhang X., Web
Service discovery research and
implementation based on semantic search
engine // 2nd Symposium on Web Society,
2010.
56. Dan G. New ideas for Web service discovery-
ontology-based prototype system of service
search engine, 2nd International Conference
on Software Technology and Engineering,
2010.
57. Paolucci M., Sycara K., Kawamura T.
Delivering Semantic Web Services. In Proc.
WWW2003, 2002.
58. I. Constantinescu, B. Faltings, W. Binder.
Typed Based Service Composition. In Proc.
WWW2004, 2004.
59. Hobold G.C., Siqueira F. Discovery of
semantic web services compositions based on
SAWSDL annotations. In: IEEE 19th
international conference on web services.
Hawaii, USA. – 2012.
60. http://knowledgeweb.semanticweb.org/semant
icportal/deliverables/D2.4.6.1v2.pdf
61. Ruben Lara. Definition of semantics for web
service discovery and composition.
Knowledge Web Deliverable D2.4.2, 2004.
Одержано 07.05.2015
Про автора:
Ремарович Світлана Станіславівна,
науковий співробітник.
Місце роботи автора:
Інститут програмних
систем НАН України,
Проспект Академіка Глушкова, 40.
Тел.: 526 6249.
Е-mail: svitlana.remarovich@gmail.com
|