Подходы и задачи композиции сервисов в семантическом Web окружении

Композиция Веб-сервисов вызывает значительный интерес в контексте проблематики семантической Веб-сети. Ее цели заключаются в том, чтобы сделать существующий Веб более эффективным и обеспечить гибкий подход к управлению всеми типами процессов. Ожидаемые программные приложения, построенные на основе к...

Full description

Saved in:

Bibliographic Details
Date:	2008
Main Author:	Дерецкий, В.А.
Format:	Article
Language:	Russian
Published:	Інститут програмних систем НАН України 2008
Subjects:	Формальні методи розробки програмного забезпечення
Online Access:	https://nasplib.isofts.kiev.ua/handle/123456789/2601
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 окружении / В.А. Дерецкий // Проблеми програмування. — 2008. — № 4. — С. 45-59. — Бібліогр.: 23 назв. — рос.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	nasplib_isofts_kiev_ua-123456789-2601
record_format	dspace
spelling	Дерецкий, В.А. 2008-12-15T13:21:09Z 2008-12-15T13:21:09Z 2008 Подходы и задачи композиции сервисов в семантическом Web окружении / В.А. Дерецкий // Проблеми програмування. — 2008. — № 4. — С. 45-59. — Бібліогр.: 23 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/2601 681.3 Композиция Веб-сервисов вызывает значительный интерес в контексте проблематики семантической Веб-сети. Ее цели заключаются в том, чтобы сделать существующий Веб более эффективным и обеспечить гибкий подход к управлению всеми типами процессов. Ожидаемые программные приложения, построенные на основе композиции сервисов, сделают более продвинутыми такие направления как Веб-коммерция, электронное правительство, электронная наука и другие. На сегодня композиция сервисов выполняется, как правило, вручную в процессе разработки приложений. Это требует много времени и программирования на достаточно низком уровне. В этой работе мы рассматриваем модель композиции Веб-сервисов, которая базируется на онтологиях. Подход к генерации композитного сервиса основан на декларативных описаниях. Формальной основой для композиции служат композиционные правила. Эти правила совмещают синтаксические и семантические характеристики сервисов для определения того, являются ли сервисы композитными. ----------------- Композиція Веб-сервісів в останній період викликає значний інтерес у контексті проблематики Семантичної мережі Інтернет. Її цілі полягають у тому, щоб зробити Веб більш ефективним та забезпечити гнучкий підхід до управління усіма типами процесів в Веб-середовищі. Очікувані програмні застосування на основі сервіс-композиції зроблять більш потужними такі задачі як Веб-комерція, Електронний уряд, Електронна наука тощо. На сьогодні композиція сервісів виконується, як правило, у ручну для кожного окремого випадку, в процесі розробки застосувань, забирає багато часу та містить багато помилок, які не в змозі передбачити розробник, а також потребує програмування на досить низькому рівні. В цій роботі ми розглядаємо модель композиції Веб-сервісів, що базується на онтологіях. Підхід до генерації композитного сервісу заснований на декларативних описах. Формальною основою для композиції ми використовуємо композиційні правила. Ці правила поєднують синтаксичні та семантичні засоби сервісів для визначення того, чи являються два сервіса композитними.----------------- The composition of web-services recently has attracted considerable interest within the context of problems of Semantic Web. Its objectives are to make а web more effective and provide flexible approach to the management of all types of processes in web-environment. The expected program applications on the basis of service composition will make more advanced such applications as Web-commerce, electronic government, electronic science, etc. Currently, the composition of services has been fulfilled as а rule manually for every individual case in the process of applications development, taking а lot of time and containing many errors, which is hardly possible to foresee by developer and also requires programming at rather narrow level. In this work we offer the model composition of Web-services, which is based on ontology. The approach to the generation of composite service is based on declarative descriptions. We use composition rules as the formal basis for composition. These rules combine syntactic and semantic means of services to determine whether those two services are composite. ru Інститут програмних систем НАН України Формальні методи розробки програмного забезпечення Подходы и задачи композиции сервисов в семантическом Web окружении Підходи та задачі композиції сервісів в семантичному web середовищі Approaches and tasks to the composition of services in the semantic web environment 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	2008
language	Russian
publisher	Інститут програмних систем НАН України
format	Article
title_alt	Підходи та задачі композиції сервісів в семантичному web середовищі Approaches and tasks to the composition of services in the semantic web environment
description	Композиция Веб-сервисов вызывает значительный интерес в контексте проблематики семантической Веб-сети. Ее цели заключаются в том, чтобы сделать существующий Веб более эффективным и обеспечить гибкий подход к управлению всеми типами процессов. Ожидаемые программные приложения, построенные на основе композиции сервисов, сделают более продвинутыми такие направления как Веб-коммерция, электронное правительство, электронная наука и другие. На сегодня композиция сервисов выполняется, как правило, вручную в процессе разработки приложений. Это требует много времени и программирования на достаточно низком уровне. В этой работе мы рассматриваем модель композиции Веб-сервисов, которая базируется на онтологиях. Подход к генерации композитного сервиса основан на декларативных описаниях. Формальной основой для композиции служат композиционные правила. Эти правила совмещают синтаксические и семантические характеристики сервисов для определения того, являются ли сервисы композитными. ----------------- Композиція Веб-сервісів в останній період викликає значний інтерес у контексті проблематики Семантичної мережі Інтернет. Її цілі полягають у тому, щоб зробити Веб більш ефективним та забезпечити гнучкий підхід до управління усіма типами процесів в Веб-середовищі. Очікувані програмні застосування на основі сервіс-композиції зроблять більш потужними такі задачі як Веб-комерція, Електронний уряд, Електронна наука тощо. На сьогодні композиція сервісів виконується, як правило, у ручну для кожного окремого випадку, в процесі розробки застосувань, забирає багато часу та містить багато помилок, які не в змозі передбачити розробник, а також потребує програмування на досить низькому рівні. В цій роботі ми розглядаємо модель композиції Веб-сервісів, що базується на онтологіях. Підхід до генерації композитного сервісу заснований на декларативних описах. Формальною основою для композиції ми використовуємо композиційні правила. Ці правила поєднують синтаксичні та семантичні засоби сервісів для визначення того, чи являються два сервіса композитними.----------------- The composition of web-services recently has attracted considerable interest within the context of problems of Semantic Web. Its objectives are to make а web more effective and provide flexible approach to the management of all types of processes in web-environment. The expected program applications on the basis of service composition will make more advanced such applications as Web-commerce, electronic government, electronic science, etc. Currently, the composition of services has been fulfilled as а rule manually for every individual case in the process of applications development, taking а lot of time and containing many errors, which is hardly possible to foresee by developer and also requires programming at rather narrow level. In this work we offer the model composition of Web-services, which is based on ontology. The approach to the generation of composite service is based on declarative descriptions. We use composition rules as the formal basis for composition. These rules combine syntactic and semantic means of services to determine whether those two services are composite.
issn	1727-4907
url	https://nasplib.isofts.kiev.ua/handle/123456789/2601
citation_txt	Подходы и задачи композиции сервисов в семантическом Web окружении / В.А. Дерецкий // Проблеми програмування. — 2008. — № 4. — С. 45-59. — Бібліогр.: 23 назв. — рос.
work_keys_str_mv	AT dereckiiva podhodyizadačikompoziciiservisovvsemantičeskomwebokruženii AT dereckiiva pídhoditazadačíkompozicííservísívvsemantičnomuwebseredoviŝí AT dereckiiva approachesandtaskstothecompositionofservicesinthesemanticwebenvironment
first_indexed	2025-11-24T11:50:26Z
last_indexed	2025-11-24T11:50:26Z
_version_	1850846377416851456
fulltext	Формальні методи розробки програмного забезпечення © В. Дерецкий, 2008 ISSN 1727-4907. Проблеми програмування. 2008. № 4 45 УДК 681.3 В. Дерецкий ПОДХОДЫ И ЗАДАЧИ КОМПОЗИЦИИ СЕРВИСОВ В СЕМАНТИЧЕСКОМ WEB ОКРУЖЕНИИ Композиция Веб-сервисов вызывает значительный интерес в контексте проблематики семантической Веб-сети. Ее цели заключаются в том, чтобы сделать существующий Веб более эффективным и обеспе- чить гибкий подход к управлению всеми типами процессов. Ожидаемые программные приложения, построенные на основе композиции сервисов, сделают более продвинутыми такие направления как Веб-коммерция, электронное правительство, электронная наука и другие. На сегодня композиция сервисов выполняется, как правило, вручную в процессе разработки приложений. Это требует много времени и программирования на достаточно низком уровне. В этой работе мы рассматриваем модель композиции Веб-сервисов, которая базируется на онтологиях. Подход к генерации композитного сервиса основан на декларативных описаниях. Формальной основой для композиции служат композиционные правила. Эти правила совмещают синтаксические и семантические характеристики сервисов для определения того, являются ли сервисы композитными. Вступление Концепция Семантического Веб направлена на расширение существую- щего Веб [1─4] в части определения и об- работки содержания информации. Оконча- тельная цель Семантической сети Интер- нет заключается в том, чтобы превратить Веб в среду, через которую данные могут быть разделены, понятны и обработаны автоматизированными или автоматиче- скими средствами, т.е. машинами. Развитие технологий Семантиче- ской Веб-сети является приоритетным заданием многих исследовательских проектов. Одним из ключевых проблем- ных понятий, в исследованиях является понятие Веб-сервиса [5], который пред- ставляет собой программную систему, представленную множеством связанных функций, к которым можно обратиться программно через сеть. Веб-сервисы пред- назначены для решения проблем интеро- перабельности и повторного использова- ния программ при взаимодействии ма- шина-машина в сети. Понятие сервиса по- степенно внедряется в бизнес, государст- венную деятельность, науку и другие от- расли. Примерами Веб-сервисов в бизнесе является электронная торговля акциями, проверка кредитов, электронные платежи. Веб-сервисы в государственных структу- рах обеспечивают функции различных со- циальных фондов. Широко распространенные стан- дарты на основе XML, включая: WSDL, SAWSDL, SOAP, UDDI, WSMO и MSSLI [5─9], инициируют интенсивные иссле- дования Веб-сервисов в промышленности и академических проектах. Одним из ва- жнейших назначений Семантической сети Интернет является использование ее как носителя сервисов. Эта новая модель дала бы возможность компаниям значительно уменьшить расходы на развертывание новых решений бизнеса и открытия новых возможностей. Идентифицируют два типа серви- сов: простые и композитные. Простой сер- вис представляет программную систему, созданную на основе Интернета, которая не использует другие Веб-сервисы для вы- полнения запроса пользователя. Сложный или композитный сервис определяется тем, что он использует совокупность функций простых или композитных серви- сов для выполнения своих заданий. При- мером композитного сервиса может быть автомобильный брокер, который получает данные для выполнения работ от агента по продаже автомобилей, финансирования и страхового обслуживания для обеспечения сервиса продажи [9]. Композиция сервисов стала цен- тральной задачей в исследованиях по Веб- Формальні методи розробки програмного забезпечення 46 сервисам. В этой области предложено не- сколько новых подходов [10─12]. Как пра- вило, все они требуют детального про- граммирования, который делает процесс композиции сервисов зависимым от про- граммиста-разработчика сервисов [13]. Разработчики композиции должны определить, какие действия должны быть выполнены композитным сервисом, и не интересоваться, какие сервисы необхо- димо вовлечь в выполнение и как вовле- ченные сервисы должны взаимодейство- вать. Процесс композиции сервисов вклю- чает такие операции: выбор сервисов, встраивание операций, определение сооб- щений разговора и другие, которые должны быть прозрачными для поль- зователей. Детализированные описания ко- мпозитного сервиса должны быть сгене- рованными из спецификации композиции. Семантика является важной и ос- новной составляющей для обеспечения композиции сервисов, в части проверки того, что выбранные для композиции сер- висы были корректными и отвечали требо- ваниям композиции. Такие средства могут быть синтаксическими (например, про- верка числа параметров, включенных в со- общение, которое посылается или получа- ется сервисом). Они также могут быть се- мантическими (например, состав бизнес- функций, которые предлагаются сервисной операцией или определение соответствия предметной области). Для определения се- мантических характеристик Веб-сервисов используется понятие онтологии, которая определяется как концептуализация, осно- ванная на семантической близости терми- нов в определенной предметной области [14]. Онтология ─ ключевое понятие для формального определения семантики и семантического управления процессами [15, 16]. Онтологии играют центральную роль в Семантической сети Интернет, расширяя синтаксическую интероперабе- льность сервисов до их семантической ин- тероперабельности [17]. В данной работе рассматриваем подход и модель композиции Веб-серви- сов, согласование концептов Веб-сервисов и онтологии, которые являются основой подхода. Для понимания и иллюстрации подхода композиции рассматривается приложение из электронной коммерции B2B «Продажа автомобилей» [18]. Модель композиции Веб-сервисов направлена на решение следующих задач: определение того, являются ли выбранные сервисы композитно-реали- зуемыми (Composability) [4]. Композитная реализуемость определяется путем про- верки возможностей сервисов взаимо- действовать друг с другом. В работе представлена модель композиции, на основе которой выполняется сравнение синтаксических и семантических характе- ристик Веб-сервисов, которые принимают участие в композиции; генерация композитного сервиса, при которой сохраняются вышеупомяну- тые характеристики композиции. Входом предложенной методики являются специ- фикации композиции высокого уровня. Кроме того, спецификация содержит спи- сок операций, которые будут выполнены в процессе композиции. Рассматривается архитектура и прототип системы композиции сервисов, в основе архитектуры используются такие стандарты Веб-сервисов: WSDL,SAWSDL, UDDI, SOAP, WSMO и др. 1. Семантические спецификации Веб-сервисов Процесс создания Веб-сервиса тре- бует его описания для того, что бы другие сервисы могли понять его возможности и узнать, как взаимодействовать с ним. Язык WSDL (язык описания Веб-сервисов) пред- назначен для описания операционных особенностей Веб-сервисов. WSDL стан- дартизируется в пределах консорциума W3C [6]. Главные лидеры промышленно- сти поддерживают и принимают участие в развитии WSDL. Однако WSDL почти не обеспечивает семантическое описание Веб-сервисов. Она главным образом вклю- Формальні методи розробки програмного забезпечення 47 чает конструкции, которые описывают Веб-сервис с синтаксической точки зрения. Чтобы отвечать определению Семантиче- ского Веб-сервиса, в работе используется подход, основанный на расширении WSDL семантическими характеристиками. Этот подход положен в основу выбора и компо- зиции Веб-сервисов с использованием ста- ндартов WSDL 2.0, WSDL 4j и SAWSDL [5, 6]. Другой ключевой момент подхода заключается в использовании онтологии для Веб-сервисов, которая определяется с помощью языка DAML+OIL. Он использует объектно-ориентированный подход, описывая онтологию в терминах классов, свойств и аксиом. Язык DAML+OIL основывается на предыдущих стандартах Веб-сервиса и онтологии, типа RDF и RDF-S, и расширяет эти языки примитивами моделирования (например, количество элементов). Для определения онтологии могут использоваться другие онтологические языки, типа OWL, OWL-S, WSMO [14]. Для моделирования онтологии вос- пользуемся моделью, которая базируется на ориентированных графах, узлы кото- рого представляют концепты онтологии. Множество узлов графа разделяется на «заполненных» и «незаполненных». «Не- заполненные» узлы ссылаются на кон- цепты, которые определены языком WSDL (например, имена, связи, входы). «Запол- ненные» узлы ссылаются на описания, по- лученные с помощью расширения WSDL семантическими характеристиками. Дуги представляют отношение между поня- тиями онтологии. Их маркируют коли- чеством элементов соответствующих от- ношений. Например, дуга «сервис > опе- рация» означает то, что сервис имеет одну или больше операций. Дуга «операция > >вход» означает то, что операция имеет больше одного входного сообщения. Оп- ределение Веб-сервиса заключается в оп- ределении каждого концепта соответст- вующей онтологии. В соответствии с классическим оп- ределением сервиса, рассмотрим три типа участников нашего подхода: провайдеры, композиционные конструкторы (конст- рукторы) и пользователи. Провайдеры определяются как объ- екты, которые специфицируют и предла- гают Веб-сервисы для использования. На- пример, справочное агентство по креди- там, которое предоставляет сервис истории кредитора. Провайдер является ответст- венным за описание Веб-сервиса, назначая каждому понятию сервиса значение в он- тологии. Конструкторы определяются как объекты, ответственные за определение композитного сервиса (например, компа- ния-посредник по продаже автомобилей). Формируются описание сервисов, на ос- нове которого генерируется композитный сервис. Этот сервис определяется и объявляется в реестре сервисов так, чтобы другие сервисы могли его обнаружить и использовать. Пользователи сервисов могут быть конечными пользователями (например, посредники по продаже автомобилей) или другие Веб-сервисы, которые вызывают необходимый Веб-сервис. Для иллюстрации подхода рассмот- рим приложение по продаже автомобилей, бизнес-схема которого рассматривается на сайте http://en.wikipedia.org/ wiki/ Lemon_ law. Допустим, что компания предо- ставляет автомобильному брокеру компо- зитный сервис, который предлагает пакеты продажи автомобилей. Клиенты компании формируют запросы брокеру по продаже. Брокер привлекает другие сервисы для выполнения своей работы, например, сервис по продаже автомобилей (CB), сервис страхования (IN), сервис проверки проблем (LC), сервис финансирования (FI), сервис кредитной истории клиента (CH), сервис регистрации (RG). Приблизительно такая же бизнес-схема используется в каждом автосалоне. Бизнес-схема процесса продажи ав- томобиля в нотации IDEF0 показана на рис. 1. Формальні методи розробки програмного забезпечення 48 Типичный сценарий использования сервиса СВ следующий: чтобы купить ав- томобиль определенной модели, клиент должен запустить на выполнение сервис СВ, вызывая функцию sendMePriceQuote, для получения ценовой характеристики автомобиля (1). Для получения ценовой характеристики, сервис, очевидно, взаимо- действовал бы с сервисом по продаже ав- томобилей через операцию priceQuote (1.1). Если бы клиент интересовался автомобилем, который уже был в исполь- зовании, он проверил бы его состояние и хронологию, вызывая операцию askForPro- blem Check (2). В свою очередь, эта опе- рация обращается к операции problem- Check (2.1). Клиент должен выполнить оплату за выбранный автомобиль, вызывая операцию applyForFinancing (3). Перед утверждением плана финансирования сервис проверяет платежеспособность кли- ента, вызывая операцию payingHistory CH (3.1). Если решение по предоставлению кредита положительно, то СВ вызывает операцию financingQuote, которая пред- лагает финансовые сервисы (3.2). Дальше, клиент пригласил бы страховую компа- нию, используя операцию insuranceQuote (4). Сервис СВ, очевидно, вызывал бы операцию applyforInsurance, предложен- ную страховым сервисом (4.1). В результате, от страхового сервиса DH получил бы параметры страховки, путем выполнения операции drivingRecord (4.2). И наконец, клиент может зарегистрировать автомобиль, используя сервис carRegistry, в результате выполнения которого клиент получит номер государственной регистра- ции. 1.1. Типы сообщений. Функци- ональные возможности Веб-сервиса досту- пны пользователям через запуск операций. Запуск операций сервисов осуществляется посредством передачи сообщений. В опе- рациях используют четыре типа со- общений (рис. 2): исходное одностороннее сообщение (notification); входное одностороннее сообщение (one-way); требование ответа (solicit-response); запрос-ответ (request-response). Рассмотрим особенности перечис- ленных типов сообщений. Операция посылает «исходное одностороннее сообщение (notification)» сервису, но не ожидает его в ответ. В случае односторонней операции «входное одностороннее сообщение (one-way)» сер- вис получает входное сообщение, но не по- сылает никакого сообщения в обратном направлении. Для типа сообщения «требо- вания ответа (solicit-response)» сервис генерирует исходное сообщение для полу- чения соответствующего входного сооб- http://www.carbroker.com.au/ Рис. 1 – Пример бизнес-схемы композитного сервиса продажи автомобилей USED AT: AUTHOR: IPS NANU DATE: REV:PROJECT: CS 06.09.2005 18.03.2008 NOTES: 1 2 3 4 5 6 7 8 9 10 WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT: A0 NODE: TITLE: NUMBER: A1 Запит на придбання авто Problem_checkAsk_for_problem_check 10 Веб-сервіс Брокер з продажу авто Car Broker Web-Service CB 20 Веб-сервіс страхування Insurens Beb-Service IN 30 Веб-сервіс фінансування Finansing Web-service FN 40 Веб-сервіс перевірки історії водіння (Driving History Web-Service) DH 50 Веб-сервіс Дилер продажу авто Car Dealer Web-Service CD 60 Веб-сервіс перевірки вживаного авто (Lemon-check) LC 70 Веб-сервіс кредитування (Credit History Web-service) CH 1.1 2 3 4 1 4.1 4.2 2.1 3.2 3.1 CB Веб-сервис «Брокер продажи авто» CD Веб-сервис «Дилер продажи авто» LC Веб-сервис «Проверкa использования авто» CН Веб-сервис «Кредитованиe авто» FN Веб-сервис «Финансирова- ние авто» DH Веб-сервис «Проверкa истории авто» IN Веб-сервис «Страховкa авто» Запрос покупк и авто 1. Формальні методи розробки програмного забезпечення 49 щения. В случае сообщения «запрос-ответ (request-response)» сервис получает вхо- дное сообщение, обрабатывает его и посы- лает соответствующее исходное сообще- ние. Для определения соответствия параметров сообщений используются типы данных 1), 2), но они не представляют семантику этих параметров. Например, ценовой параметр может быть в долларах США или гривнах, цену возможно пред- ставить как полную или цену без НДС. Чтобы моделировать такие ограничения, используют связывание каждого из пара- метров с его бизнес-ролью. В качестве зна- чений единиц параметров используют стандартные единицы измерения (длина, вес, код денег и так далее). Если параметр не имеет единицы (например, «имя»), тогда этот параметр будет иметь значение "none". Бизнес-роль определяет семантику соответствующего параметра. Значение семантики определяется в соответствии с предопределенной таксономией бизнес- ролей. Примером такой таксономии может быть классификатор товара и услуг. Сообщение М определяется как кортеж (P, T, U, R), где: P – множество имен параметров; Т:p > DataTypes – функция, назначающая тип данных к каждому пара- метру. DataTypes – множество типов дан- ных XML; U:P > единицы измерений – фун- кция, определяющая единицы измерения, которые используются для каждого пара- метра. Единицы измерения определяются таксономией единиц измерения; R:P > роли – функция, назначающая бизнес-роль для каждого параметра. Роли определяются таксономией бизнес-ролей. 1.2. Цель и категория. Семантика каждой операции сервиса описывается через цель и категорию. Цель содержит три атрибута: функция, синонимы и специализация. Функция определяет бизнес-фун- кциональность, обеспечивающаяся опера- цией сервиса. Примерами функций могут быть "запрос о ценах на автомобили", "заказ на кредитование". Чтобы опреде- лить функциональный признак бизнес-ро- лей параметров функций, используется широкий диапазон таксономий. Цель операции ikOP определяется кортежем (Fik, SNik, SPik), где Fik – бизнес- функции, определенные в пределах данной таксономии, SNik (синонимы) – множество альтернативных имен функции и SPik (специализация) – множество характери- стик функции ikOP . Каждая цель предварительно опре- деляется пространством имен в структуре XML, которая соответствует определенной таксономии. Например, операции цели может предшествовать пространство имен, указывающее на таксономию опреде- ленного бизнес-классификатора, например, RosettaNet или соответствующего отече- ственного классификатора товаров и услуг. Синонимы отвечают набору альтерна- тивных имен функции для операции. Категория операции определяется таким же образом, как и цель. Каждая категория содержит три признака: пред- метная область, синонимы и специализа- ция. Предметная область представляет область интересов для текущей операции. Примером областей может быть сфера работы "автомобильных дилеров" или "страхования". Таксономии предметных областей определяются принятыми станда- ртами в бизнесе и промышленности, кото- рые могут использоваться для определения предметной области. Синонимами области "автомобильные дилеры" являются "аген- ты по продаже автомобилей" или "автомо- бильные продавцы". Примером специа- лизации, связанной со "страхованием", является {"автомобиль", "дом"}. Это зна- чит, что соответствующая операция стра- хования обеспечивает страхование авто- мобиля и страхование дома или квартиры. Категория операции ikOP опре- делена кортежем (POik, SNik, SPik), где POik – область интересов операции, опре- деляющаяся в пределах выбранной таксономии, SNik (синонимы) – множество альтернативных областей и SPik (специа- лизация) – множество характеристик об- ласти операции ikOP . Формальні методи розробки програмного забезпечення 50 1.3. Качество операций сервисов. Несколько Веб-сервисов могут обеспечить "похожие" операции в соот- ветствии с описанием их сообщений, целей и категорий. Важно определить качес- твенные характеристики, которые помогут выбирать "лучшие" Веб-сервисы по определенным критериям. Определим три показателя качества для операций сервисов: стоимость, безопасность и секретность. Другие показатели, такие как время доступа, время ожидания ответа на сообщение, при необходимости могут рассматриваться дополнительно. Показатель качества «стоимость» указывает на количество денежных единиц, которые необходимо потратить для выполнения операции. Секретность и безопасность особенно важны в применениях E-government, где граждане озабочены утечкой их личной инфор- мации. Показатель безопасности – булевая переменная, указывающая на то, прошел ли обмен сообщениями между сервером и клиентами надежно (например, используя методики кодировки). Показатель секрет- ности содержит параметры, которые не до- лжны быть доступными для внешних объектов (кроме поставщика сервисов). Если параметр сервиса не включается в набор секретных параметров, то он не подлежит контролю на ограничение се- кретности. Далее определим понятие качества операции сервиса. Качество операции OPik опреде- ляется кортежем (Feesik, Securityik, Privacyik). Feesik – количество денежных единиц, которое необходимо потратить на выполнение OPik. Securityik – булева переменная, определяющая надежность обмена сообщениями при выполнении операции OPik. Privacyik – набор входных и исходных параметров, которые являются не доступными для внешних объектов. 1.4. Определение операций Веб- сервисов. Веб-сервисы доступны через операции. Каждая операция идентифици- руется именем и текстовым описанием, обобщающим функциональные особен- ности операции. Операция также опре- деляет способ передачи сообщений, вход- ные и/или выходные сообщения, цель и категорию. Далее представим определение операции сервиса. Операция сервиса OPik определена кортежем (Descriptionik, Modeik, Inik, Outik, Purposeik, Сategoryik, Qualityik), где Descriptionik – текстовое описание функциональности операции; Modeik – тип операции {“one_way”, ”notificatoin”, ”solisit-respons”, "respons- reply"}; Inik и Outik – тип (входное или вы- ходное) сообщение; Purposeik – описывает бизнес-функ- цию операции; Categoryik – описывает предметную область интересов операции; Qualityik – определяет качественные характеристики операции. Рассмотрим пример операции про- дажи автомобилей. Операция CB:: sendMePriceQuote определена кортежем (Desc, Vode, В, P, C, Q), где Desc = "операция возвращает цену на выбранный автомобиль"; Vode = "solicit-response" – требо- вание ответа. B представляет типы данных па- раметров: In = (P, T, U, R), где P = {VIN, price}; T(VIN) = "positiveInteger"; T(price) = = "float"; U(VIN) = "none"; U(price) = ="доллар США"; R(price) = "extendedPri- ce"; Out = (P, T), где P = {make, model, year, mileage}; T(make) = "string"; T(model)= "string"; T(year) = "gYear"; T(mileage) = "positiveInteger"; U(mileage) = ="км". P – представляет цель операции и определяется: P.Function = "запрос о стоимости"; P.Specialization = {"инфор- мация для пользователя"}; P.Synonyms = ={"стоимость"}; C – категория операции, опреде- ленная следующим образом: C.Domain = "автомобильные диле- ры"; C.Synonyms = {"агенты по продаже автомобилей"}; Формальні методи розробки програмного забезпечення 51 C.Specialization = {"автомобили, которые были в использовании"}; Q – качество операции, опреде- ленное следующим образом: Q.Fees = 0; Q.Security = “false"; Q.Privacy = 0 (т. е., нет слишком важной информации). Взаимодействия с сервисом выпол- няются согласно протоколу переговоров [7], которые определяются форматом сообщений и протоколом для сервисных операций. Взаимодействие сервисов осно- вано на следующих стандартах: SOAP: (Simple Object Access Protocol), HTTP_Get/Post MIME (Multipurpose Internet Mail Extensions). Сервис одновре- менно может выполнять несколько перего- воров. С каждым сервисом связываются цель и категория. Цель описывает функ- циональные возможности, которые пред- лагаются сервисными операциями. Каж- дый элемент цели сервиса ссылается на функцию определенной операции. Катего- рия описывает предметную область сер- виса. Она включает категории всех опера- ций, которые обеспечиваются сервисом. Область, представляющая интерес слож- ного сервиса, может отличаться от областей, которые представляют интерес его отдельных операций. Например, ком- позитный сервис продажи автомобилей связан с "автомобильными дилерами". Но он включает операции, связанные со "страхованием" (например, insuranceQuote) и "кредитованием" (например, financing- Quote). Формальное определение Веб-сер- виса. Веб-сервис WSi определяется кор- тежем (Descriptioni, OPi, Bindingsi, Purposei, Categoryi), где Descriptioni – текстовое описание функциональных возможностей сервиса; OPi – множество операций, которое обеспечивается сервисом WSi; Bindingi – набор протоколов перего- воров, которые поддерживаются WSi; Purposei = {Purposeik (OPik) \| OPik из OP i } множество операций цели; Categoryi = {Categoryik (OPik) \| OPik из OP i } AND {Categoryi (WSi)} – множе- ство категорий операций WSi . В качестве примера сервис по про- даже автомобилей (CD) (см. рис. 1) опре- делен кортежем (Desc, OP, B, P, C), где OP = {priceQuote, testDrive, special- Offers}; B = {"SOAP"}; P – цель сервиса, определена множеством {цель (priceQuote), цель (testDrive), цель (specialOf fers)}; C – категория сервиса, определена множеством {категория (priceQuote), категория (testDrive), категория (specialOffers)}, категория {category(CD)}. Элементы категории CD опреде- ляются следующим образом: category(CD).domain = “automobile dealers”; category(CD).synonyms = {“car dea- lers”, “car sellers”}; category(CD).specialization = {“used cars”}. 2. Моделирование реализуемости композиции Веб-сервисов Главная проблема композиции Веб- сервисов заключается в определении того, являются ли компоненты сервисов композитными. Например, было бы трудно или совсем невозможно вызывать операцию, если бы не было соответствия между параметрами, которые исполь- зуются этой операцией (например, типы данных, число параметров), переданные сервису клиентом. Определим два типа правил компо- зиционности, использующие синтаксиче- ские и семантические свойства Веб- сервисов. Синтаксические правила срав- нивают типы операций и протокол взаимодействия сервисов. Семантические правила сравнивают число параметров сообщений, бизнес-роли и единицы изме- рения. Операции семантической компози- ционности сравнивают семантику сервис- ных операций. Композиционность по параметрам качества сравнивает качественные свой- ства Веб-сервисов. Целостность или не- противоречивость сервисов проверяет, даст ли выбранная комбинация Веб-серви- сов ожидаемый результат. Формальні методи розробки програмного забезпечення 52 Определение непротиворечивости сервисов осуществляется на уровне множества сервисов, которые вовлекаются в композицию, в отличие от других правил, проверяющие композиционность на уровне операций. В нашей модели, сервисы вызывают функции внешних сервисов (например, автомобильный брокер), которые, в свою очередь, используют другие внешние сервисы для выполнения своих работ (например, страхование). Мы используем подход, определенный в стандартах WSMO [9], XLANG [19], WSFL [20] и BPEL4WS [21]. Веб-сервисы определяются в терминах WSDL, с расширением семан- тических возможностей этих средств. Допускается, что каждой операции на стороне сервера однозначно соответствует операция на стороне клиента и наоборот. 2.1. Определение композицион- ной реализуемости на основе взаимо- действия сервисов. Для взаимодействия Веб-сервисов должен обеспечиваться режим, при котором операция в одном сервисе должна быть связана с односторонней операцией в сервисе партнера. Так же, операция «требование- ответа» сопровождается операцией «ответ на запрос» в сервисе партнера. Например, операция CD::sendMePriceQuote (требо- вание ответа) приводит к CD::priceQuote (ответ на запрос), и СD::receivespecialoffers (односторонняя) CD::specialOffers (со- общение). Следующее правило определяет способ композиционности и проверяет, имеют ли две операции требуемый режим. Две операции OPik = (D ik, M ik, In ik, Out ik, P ik, C ik, Q ik) и OPjl = (Djl, Mjl, Injl, Outjl, Pjl, Cjl, Qjl) – композиционные по типу, если обеспечиваются условия соответствия режимов: (I) Mik = ="notification" и Mjl = "one-way"; или (II) Mik = "one-way" и Mjl = "notification"; или (III) Mik = "solicit-response" и Mjl = "request- response"; или (IV) Mik = "request-response" и Mjl = "solicit-response". Допустим, два Веб-сервиса обща- ются через операции, которые являются композиционными по типу. Поскольку эти Веб-сервисы могут поддерживать разные протоколы переговоров (например, SOAP, HTTP или MIME), важно обеспечить, чтобы они "поняли" друг друга по форматам сообщений и уровням про- токола. По крайней мере, один из прото- колов, который поддерживается Веб-сер- висом, должен быть поддержан другим. Например, сервис ожидает сообщения по протоколу MIME и взаимодействует с дру- гим сервисом, который формирует сооб- щение по протоколу HTTP. Следующее правило, названное композиционным связыванием, проверяет, чтобы Веб-сервисы поддерживали по крайней мере один общий протокол связы- вания. Композиционность сервисов WSi = = (Di,Oi, Bi, Pi, Ci) и WSj = (Dj, Oj, Bj, Pj, Cj) имеет место, если Bi ∩ Bj ≠ 0. 2.2. Композиционность по сооб- щениям. Взаимодействие Веб-сервисов осуществляется на основе метода обмена сообщениями («переговоров»). Сообщение состоит из одного или нескольких пара- метров и каждое из них имеет определен- ный тип данных. Важно проверить соот- ветствие типов данных каждого из пара- метров сообщения посылающего сервиса на совместимость с типами данных пара- метров, которые получает его партнер. Мы рассматриваем два метода проверки со- вместимости типов данных: непосредст- венный и косвенный. Два параметра непосредственно со- вместимы, если они имеют тот же тип дан- ных. Параметр p косвенно совместим из р', если тип данных параметра p получен из типа данных параметра p'. Например, параметр с типом positi- veInteger или типом short косвенно совме- стим с целочисленным параметром. Сле- дует отметить, что непосредственная и косвенная совместимость являются асим- метричными. Расширим понятие совместимости по типу данных таким образом: сообщение М совместимо с сообщением М' по типу данных, если каждый параметр М непо- средственно или косвенно совместим с параметром М'. Формальні методи розробки програмного забезпечення 53 Отметим, что не все параметры М' можно отобразить на параметры М. Вход- ное сообщение может использовать только подмножество параметров, которые ссы- лаются на исходное сообщение операции. Например, автомобильный провай- дер не интересуется цветом автомобилей, которые рекламируются как специальные предложения. В этом случае, он опреде- ляет входное сообщение CD::receive- SpecialOffers, которое составляется из следующих параметров: “make”, “model”, “year”, “mileage”, “price”. Входное сообщение совместимо с сообщением CD:: specialOffers, хотя исходное сообще- ние содержит дополнительный параметр. Допустим, параметр p совместим (непосредственно или косвенно) с пара- метром p'. Чтобы быть совместимыми, па- раметры p и p' должны иметь также со- вместимую семантику. Например, полная цена не должна сравниваться с ценой, ко- торая включает налоги. Также цена в дол- ларах США не должна сравниваться с це- ной в гривнах. В результате сравниваем единицы измерения и бизнес-роли p и p'. Оба параметра должны иметь одни и те же единицы измерения и бизнес-роли. Правила проверки композиционно- сти по сообщениям сравнивают входные и исходные сообщения каждой пары опера- ций. Идея заключается в проверке того, имеет ли каждая входная операция тип данных, который является совместимым с типом данных соответствующей исходной операции. Единицы измерения и бизнес- роль входа должны быть такими же, как единицы измерения и бизнес-роль соот- ветствующего выхода. Композиционность по сообщениям. Две операции OPik = (Dik, Mik, Inik, Outik, Pik, Cik, Qik) и OPjl = (Djl, Mjl, Injl, Outjl, Pjl, Cjl, Qjl) – композиционные по сообщениям если: 1. ∀ p∈Inik ∃ p’∈Injl, где p − совместимо по типам данных из p', U(p)= =U(p’) и R(p)= R(p’). 2. ∀ p∈Injl ∃ p’∈Inik, где p являе- тся типами данных, совместимыми с ти- пами данных из p’, U(p)= U(p’), и R(p)= =R(p’). 2.3. Композиционность операци- онной семантики. Совместимость целей и категорий связанных операций обеспечи- вается композиционностью операционной семантики, например, функция Сd::send- mepricequote ("запрос о стоимости") отли- чается от функции CD::testDrive ("пробная поездка"). Было бы некорректно сравни- вать эти операции, поскольку они предлагают разные бизнес-функции. Так же операция IN::applyForInsurance не со- вместима семантически с операцией CB::calculatePayment, поскольку эти опе- рации имеют разные области интересов ("страхование" и "кредитование", соответ- ственно). Чтобы определять совмести- мость между категориями операции, рас- смотрим следующие две: операции OPIK = (Dik, Mik, Inik, Outik, Pik, Cik, Qik) и OPJL = (Djl, Mjl, Injl, Outjl, Pjl, Cjl, Qjl) − совместимые если: 1. (Cik.Domain = Cjl.Domain) or (Cik.Domain∈Cjl.Synonyms) or (Cjl.Domain∈Cik.Synonyms) or (Cik.Synonyms ∩ Cjl.Synonyms ≠ Ø). 2. Cik.Specialization ⊆ Cjl.Specializa- tion. Первое условие проверяет пара- метры области интересов, которые должны быть подобными или синонимическими. Второе − гарантирует, что OPjl обеспечи- вает все характеристики категории OPik. Совместимость между целями определена таким же образом, как между категориями. Семантическая композиционность основа- на на понятии совместимости по катего- риям и целям. Операция OPik – семантически ком- позиционна с операцией OPjl, если цель операции OPik совместима с целью опера- ции OPjl и категория операции OPik со- вместима с категорией операции OPjl. Композиционность операционной семантики определим следующим обра- зом. Мы говорим, что операция OPik = =(Dik, Mik, Inik, Outik, Pik, Cik, Qik) – семанти- чески композиционная с операцией OPjl = = (Djl, Mjl, Injl, Outjl,Pjl, Cjl, Qjl), если Pik со- вместимы с Pjl , Cik и Cjl. Формальні методи розробки програмного забезпечення 54 2.4. Качество композиционности. Для определения качества компози- ционности проверяют свойства качества взаимодействующих операций. Рассмот- рим операцию OPik, привлекающая вне- шние сервисы для выполнения другой операции OPjl. Проверка композиционно- сти по стоимости подтверждает, что коли- чество денежных единиц, которое тратится на выполнение операции OPik, по крайней мере, равняется стоимости операции OPjl. Безопасность композиции гарантирует то, что если OPik использует механизмы безо- пасности (например, кодировка и строгое выполнение обязательств) для обмена со- общениями, то OPjl использует их также. Авторизация композиции сравнивает осо- бенности авторизации операций OPik и OPjl. Персональные настройки авториза- ции OPik должны быть включены в катего- рию авторизации, подтвержденными OPjl. Если провайдер OPik не хочет, чтобы параметр p был обнародован p ∈ Qualityik.privacy, то р ∈ Qualityjl.privacy. Качественная композиционность. Мы говорим, что OPik = (Dik, Mik, Inik, Outik, Pik, Cik, Qik) – качественно композицион- ная с OPjl = (Djl, Mjl, Injl, Outjl,Pjl, Cjl, Qjl), если: 1. Qik.Fees ≥ Qjl.Fees. 2. (Qik.Security = true) ⇒ (Qjl.Security = true). 3. Qik.Privacy ⊆ Qjl.Privacy. 2.5. Согласование сервисов (machmaking). Следующий важный аспект композиции сервисов заключается в объе- динении множества сервисов определе- нным способом для получения новой фун- кциональности. Например, сложно комби- нировать сервисы продажи автомобилей с сервисами гостиниц. Однако, объединение сервисов авиалиний и гостиничных серви- сов обеспечило бы композицию сервиса подготовки путешествия. Идея заклю- чается в том, чтобы определить правило, названное согласованием композиции, суть которого заключается в проверке то- го, являются ли композитные сервисы по- тенциально согласованными. Под согласо- ванием мы имеем в виду способ, по кото- рому композитный сервис обеспечивает новую функциональность. Для этого вводим понятие шаблонов композиции. Шаблон представляет собой граф, постро- енный на основе использования отноше- ния «следования» рис. 2. Как показано на рис. 3, Веб-сервис WSi предшествует дру- гому сервису WSj, если операция WSi вызы- вает операцию в WSj. Далее формально определим от- ношение «следования»: для заданных сервисов WSi = (Di,Oi, Bi, Pi, Ci) и WSj = (Dj, Oj, Bj, Pj, Cj), WSi следует за WSj, если ∃ OPik ∈ Oi и ∃ OPJL ∈ Oj \| (I) (Mik = “notification” и Mjl= = “one-way”); или (II) (Mik = “solicit- response” и Mjl = “request-response”). Рис. 2. Шаблон согласования композиции CS Дилер по продажам Справка Страховка Кредит, залог Дилер по продажам Страховка CS Формальні методи розробки програмного забезпечення 55 Шаблон композиции связан с каж- дым композитным сервисом и представ- ляет общую структуру сервиса. Отноше- ние следования моделируется ориентиро- ванным графом (V, E), где V – множество имен категорий сервисов и E – множество дуг. Заданная вершина отвечает композит- ному сервису и имеет значение "CS". Дуга (Vi, Vj) указывает на то, что сервис с кате- горией Vi предшествует сервису с катего- рией Vj. На рис. 4 представлена схема ком- позитного сервиса продажи автомобилей. Сервисы «Проверки чеков», «Кредитной истории», и «Истории вождения» пред- ставлены вершинами в графе, имеющие одну и ту же категорию «information». Шаблоны композиции используют- ся для того, чтобы сравнить значение новой функциональности в разных композициях. Согласованность композиции. Ком- позиция сервисов − согласованная, если граф шаблона нового сервиса является подграфом эталонного шаблона. Эталонные шаблоны отличаются от реальных. Шаблоны процесса и сами про- цессы используются в качестве априорной основы для определения композитного се- рвиса, использующиеся для проверки сог- ласованности композиционного сервиса, когда он сгенерирован. Важно отметить, что правило согласованности сервисов не используется для того, чтобы определить, является ли Веб-сервис композитным. Да- же если композиция не является согласова- нной, конструкторы должны решить, же- лают ли они рассматривать полученный состав сервисов как "приемлемый". Рис. 3. Типы сообщений сервисов WSi WSj WSi WSj Операция «требование ответа» (Solicit-Respons) Операция «запрос- ответ» (Request-Respons) Операция «Объявление» (Notification) Операция «Односторонняя» (One-Way) Рис. 4. Схема подхода к композиции сервисов Специфи- кация (Specification) Согласование (Matchmaking) Выбор (Selection) Генерация (Generation) Высокоуров- невое описание UDDI бизнес- регистры WSDL CSSL язык Правила композици CSSL специ- фикация План ком- позиции N Параметры качества композиции (QoC) Композитный сервис (сервисы, звязь сервисов, сообщения, поток управления ) План ком- позиции 1 Формальні методи розробки програмного забезпечення 56 3. Подход к композиции Веб-сервисов Подход к реализации композиции Веб-сервисов, основан на модели композиции и состоит из четырех концеп- туально отдельных фаз: спецификация, определение планов композиции, поиск и выбор сервисов и собственно композиция (см. рис. 4). Фаза спецификации допускает вы- сокоуровневое описание необходимой композиции, используя язык CSSL (Com- posite ServiceSpecification Language) [22]. Фаза определения композиции использует правила проверки композиционности для генерации планов композиции, которые отвечают спецификациям. Под планом композиции, подразумеваем список серви- сов, определение их взаимодействия друг с другом с целью формирования композит- ного сервиса. Алгоритм отбора сервисов использует входные спецификации, кото- рые формируются конструктором, и содер- жатся в репозитории (UDDI [8]). Сервисы специфицированы в нотации WSDL, кото- рая расширена семантическими конструк- циями. Конструкторы на фазе выбора оп- ределяют сгенерированный план компо- зитного сервиса на основе показателей ка- чества композиции (например, стоимость). Используя отобранный план, генерируется детализированное описание композитного сервиса. Это описание содержит список внешних сервисов для выполнения работ, схему связей между операциями сервисов и поток управления сервисами. Поток управления формируется множеством операций, которые выполняются серви- сами. Фаза спецификации требует вмеша- тельства конструктора для описания необ- ходимой композиции. На фазе согласова- ния сервисов генерируются планы компо- зиции, основанные на спецификации, кото- рая задана конструктором. Фаза выбора использует параметры ограничения для выбора лучшего плана. Такие параметры определяются конструктором в процессе спецификации. Фаза композиции обеспе- чивает описание композитного сервиса на заданном языке, например, WSFL [19]. 3.1. Фаза спецификации. Для спецификации композитного сервиса используем язык CSSL (Composite Service Specification Language), созданный на основе XML. CSSL обеспечивает описание высокого уровня композитного сервиса. Конструкторы должны иметь общую идею или бизнес-модель сервиса. Они не обязаны знать технические детали нового сервиса, характеристики составных сервисов и то, как они взаимодействуют между собой. Есть несколько отличий ме- жду языком CSSL и существующими язы- ками композиции сервисов. Язык CSSL определяет модель композиции на основе онтологии для обеспечения семантической поддержки возможностей Веб-сервисов. Большинство существующих языков не учитывают семантические возможности Веб-сервисов. CSSL расширяет язык WSDL таким образом, чтобы обеспечить: описание семантических особенностей Веб-сервисов; спецификацию потока упра- вления между операциями композитного сервиса, что делает композицию сервиса такой же простой, как и определение про- стых сервисов. Принятый подход позво- ляет поддерживать рекурсивную ком- позицию сервисов. Сложные сервисы мож- но рассматривать как сервисы WSDL и следовательно, использовать их как ком- поненты для новых композиций. Язык CSSL также допускает специ- фикации потока управления операциями композитного сервиса. Операции могут выполняться последовательно или парал- лельно. Например, спецификация сервиса автомобильного брокера показывает, что этот сервис сначала проверяет хронологию оплаты клиентов перед запросом финанси- рования. Следует отметить, что CSSL так- же позволяет специфицировать условия потоков управления. Например, сервис ав- томобильного брокера применяет опера- цию финансирования, только после про- верки, что клиент имеет позитивную хро- нологию оплат. Формальні методи розробки програмного забезпечення 57 3.2. Установление согласованно- сти сервисов. Следующим шагом после обеспечения спецификации CSSL является генерация соответствующих планов ком- позиции с использованием алгоритма сог- ласования. Поскольку число планов, ко- торые будут сгенерированы, может быть большим, конструкторы имеют возмож- ность отбора планов. Общая схема алгоритма согласова- ния заключается в отображении каждой операции OPik = (Dik, Mik, Inik, Outik, Pik, Cik, Qik) сложного сервиса WSi на операции OPjl = (Djl, Mjl, Injl, Outjl,Pjl, Cjl, Qjl) сущест- вующего сервиса WSj. Алгоритм ищет Веб- сервисы WSj = (Dj, Oj, Bj, Pj, Cj) так, чтобы Pik и Cik были совместимыми, по крайней мере, с одним элементом Pj и Cj, соот- ветственно. Дальше алгоритм проверяет, связаны ли сервисы композиционно. Веб- сервисы группируются в содружества. Каждое содружество сервисов представ- ляет кластер в соответствии с категорией. Сервисы, имеющие подобные категории и одну и ту же цель, принадлежат опреде- ленному содружеству. Использование сер- висных содружеств ускоряет процесс вы- явления необходимого для композиции сервиса. В случае если Cik не совместима с сервисами, принадлежащие содружеству WSJ, эти Веб-сервисы будут устранены из сервисного пространства для этой композиции. Для каждой пары операций (OPik, OPjl) проверяется режим композиционно- сти, операция семантической композици- онности и сообщения композиционности. Множество сервисов, для которых устанавливается соответствие, содержит все операции, которые были "встроены" в соответствующую сложную сервисную операцию. Использование этого набора сервисов предшествует генерация планов композиции, которые могут быть выве- дены из планов, и предварительно были сгенерированы. Например, рассмотрим следующие два плана: plan1 = {(opi1, opj1), (opi2, opj2)} и plan2 = {(opi1, opj3), (opi2, opj4)}. Тогда plan3 = {(opi1, opj1), (opi2, opj4)} и plan4 = {(opi1, opj3), (opi2, opj2)} могут быть выведены из plan1 и plan2, поэтому нет необходимости генерировать их заново. Для иллюстрации алгоритма опре- деления согласованности без потери общ- ности, рассмотрим трафик выполнения операций сервиса автомобильного брокера [18] receiveSpecialOffers. Шаг 1. Формируется множество переменных plan. Шаг 2. Выполняется поиск компо- нент сервиса (например, агент по продаже легковых автомобилей) поддерживающих SOAP протокол так, чтобы цель и катего- рия receiveSpecialOffers были совмести- мыми с целью и категорией сервиса. Шаг 3. Определяются операции сервиса car_dealer, которые являются со- вместимыми с receiveSpecialOffers. Алго- ритм также проверяет, чтобы эти две опе- рации не использовались вместе. Шаг 4. Определяется качество ком- позиционности операции receiveSpecial- Offers и specialOffers, имеющие подобные функции ("price-sales catalogue") и облас- ти ("automobile dealer"). Таким образом, операционная семантика является композиционной и обе операции − качест- венно композиционные. Шаг 5. Выполняется проверка опе- рации на композиционность по сообще- ниям. Входы receiveSpecialOffers сравни- ваются с выходами specialOffers. Следова- тельно, эти две операции − композици- онные по сообщениям. Шаг 6. Формируются и сохраня- ются шаблоны операций. Поскольку обе операции синтаксически и семантически композиционные, информация сохраняется в соответствующем шаблоне. Шаги 1 − 6 итерационно формируют сложные сер- висные операции. Шаг 7. Для всех операций автомо- бильного брокера проверяется готовность сгенерированного плана. 3.3. Фаза выбора. На фазе выбора генерируются несколько планов компози- ции. Обеспечевается выбор релевантных планов, осуществляется сравнение значе- ний параметров качества композиции: следования, релевантности и закончен- Формальні методи розробки програмного забезпечення 58 ности. Также могут быть определены другие параметры, основанные на показа- телях стоимости и времени. Для каждого плана определяется соответствующий шаблон композиции − Ст. Допустим, что СТ – подграф сохра- ненного шаблона STi. Используем функцию R, определяющую сохраненные шаблоны; R(STi), которые являются подграфами STi. Ранжирование СТ относи- тельно STi определяется следующим образом: Ranking(CT, STi) = R(STi)/ SUMn к = 1,n (R(STk)), где n – число сохраненных шаблонов. Композиционная релевантность. Обозначается как СR, дает приближенное значение композиции. Для этого сравни- ваются дуги шаблона композиции СТ с дугами сохраненного шаблона STi. CR(CT,STi) − отношение дуг СТ, которые встречаются в STi. Параметр полноты композиции. Определяет отношение операций компо- зитного сервиса с сервисами, которые мо- гут быть не "полностью" композитными. Действительно, если значение СС является относительно невысоким (например, 25%), то эти планы исключаются из разработки. В этом случае, конструкторы должны из- менить спецификацию (например, изме- нить типы данных) так, чтобы достичь со- вместимости с другим сервисом. Для сложного сервиса WSi: ( ) ( ) i i i Composable O CC WS O = . Планы композиции сортируются согласно их ранжированию. Конструкторы определяют пределы параметров завер- шенности. Планы будут возвращены кон- структорам, если их релевантность и за- конченность больше, чем установленные ограничения. Параметры могут быть опре- делены в пределах спецификаций CSSL таким образом, чтобы были отобраны и возвращены пользователям "лучшие" планы. 3.4. Фаза генерации описания композитного сервиса. Последняя фаза обеспечивает генерацию описания компо- зитного сервиса. Это описание включает список внешних сервисов, отношения между сервисными операциями, которые определяются сообщениями, потоком управления и потоком данных между сервисами. Важные особенности этой фазы заключаются в настройке и расширении. Настройка относится к способности гене- рировать сложные сервисные описания на разных языках типа WSFL (Web Services Flow Language) [20], XLANG и BPEL4WS (Business Process Execution Language forWeb Services) [21]. Расширяемость относится к воз- можности включать дополнительные языки композиции [23]. Структура планов композиции − достаточно абстрактна, что- бы ее использовать на промежуточном уровне между спецификациями CSSL и наиболее распространенными языками композиции Веб-сервисов. WSFL определяет два комплемен- тарных описания для сложного сервиса: flow model и global model. Модель потока определяет последовательность выполне- ния операций между составными серви- сами. Глобальная модель определяет, как взаимодействуют компоненты сервисов. Модель потока содержит множество дей- ствий. Каждое действие представляет от- дельный шаг всех бизнес-целей. Для по- иска информации по businessEntity каж- дого Веб-сервиса, сохраненного в регистре UDDI, используем операцию find() интер- фейса запроса UDDI. Глобальная модель включает мно- жество элементов встроенных связей. Ка- ждый элемент связи соответствует ото- бражению в плане композиции. Например, операция insuranceQuote связана с опера- цией applyForInsurance, предлагающая сервисом страхования. Выводы В этой работе рассмотрен подход к композиции Веб-сервисов, представлена модель, алгоритм, который генерирует сложный сервис на основе спецификации высокого уровня. Модель обеспечивает Формальні методи розробки програмного забезпечення 59 проверку композиционной реализованно- сти сервиса и композиционные правила, которые сравнивают синтаксические и семантические параметры Веб-сервисов. Определяется модель "оптимизации" сложного сервиса, основанная на качестве композиционных параметров сервисов. Развитие технологий семантических Веб-сервисов даст возможность создавать единственное унифицированное представ- ление семантического Веб-сервиса в различных применениях, позволит точно находить необходимую информацию, упрощать корпоративную интеграцию и интеграцию сетевых приложений в распределенном Веб-окружении. 1. Tim Berners-Lee, James Hendler and Ora Lassila. The Semantic Web. http://www. semwebcentral.org 2. Berners-Lee T. Services and semantics: Web architecture. http://www.w3.org/2001/04/30- tbl 3. W3C Semantic Web. http://www.w3.org/ 2001/sw 4. Bussler C., Fensel D., Maedche A. A concep- tual architecture for Semantic Web enabled Web services. SIGMOD Rec − 2002. 5. W3C Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl 6. Jacek Kopecky, Tomas Vitvar, Carine Bournez, Joel Farrell SAWSDL: Semantic Annotations for WSDFL and ML Schema. IEEE Internet Computing, Dec. − 2007. − P. 60−67. 7. W3C Simple Object Access Protocol (SOAP). http://www.w3.org/TR/soap 8. W3C Universal description, discovery, and integration (UDDI). http://www.uddi.org. 9. http://www.wsmo.org/ 10. Sheila A. McIlraith, Tran Cao Son, and Honglei Zen. Semantic Web Services, Stanford University. http://www.ksl.Stanford. edu. 11. Web Services. http://www306.ibm.com/soft ware/solutions/webservices/uddi 12. Андон П., Дерецкий В. Проблемы построе- ния сервис-ориентированных прикладных информационных систем в Semantic Web среде на основе агентного подхода, // Про- блемы программирования. − 2006. − № 2-3. − С. 493−502. 13. Brahim Medjahed1, Athman Bouguettaya1, Ahmed K. Elmagarmid Composing Web services on the Semantic Web // Published online: September 23, 2003. Springer-Verlag. 14. OWL Technical Committee. Web Ontology Language (OWL). http://www.w3.org/TR/ 2004 /WD-owlref 15. Andon Ph., Deretsky V. Control Oriented Ontology and Process Description for Cooperation Agents in Information Retrieval // Sixth International Scientific Conference „Electronic Computers and Informatics ECI’2004”. Kosice – Herlany, Slovakia: September 22-24, 2004. − P. 14–18. 16. McIlraith S.A., Son T.C., Zeng H. Semantic Web services. IEEE Intell Sys. − 2001. − 16(2). − P. 46–53. 17. Калиниченко Л.А. Методология организа- ции решения задач над множественными распределенными неоднородными источ- никами информации. ИПИ РАН. http://www.rfbr.ru /default.asp?doc_id=20786 18. http://www.carbroker.au/ 19. Florescu D., Grunhagen A., Kossmann D. XL: an XML Programming Language for Web service specification and composition. In: Proceedings of the WWW, conference, Honolulu, May 2002. − P. 65–76. 20. IBM (2003) Web Services Flow Language (WSFL). http://xml.coverpages.org/wsfl.html 21. A Comparison of XPDL, BPML and BPEL4WS // http://xml.coverpages.org /Shapiro-XPDL.pdf 22. https://www.ifi.uzh.ch/fileadmin/site/teaching /Diplomarbeiten/Abgeschlossene_Diplomarbe iten/Jahrgang_2007/Allemann_Jonas.pdf. 23. Wooldridge M. On the Sources of Comple- xity in Agent Design - In Applied Artificial Intelligence, 14(7), 2000. − P. 623–644. Получено 15.09.2008 Об авторе: Дерецкий Валентин Александрович, кандидат физико-математических наук, ведущий научный сотрудник. Место работы автора: Институт программных систем НАН Украины, 03187, Киев-187, проспект Академика Глушкова, 40. Тел.: 38 044 526 4342.

Подходы и задачи композиции сервисов в семантическом Web окружении

Institution

Similar Items