Введение

Web-сервисы (Web-службы) – это программные системы, которые однозначно идентифицируются своим Web-адресом со стандартизированными интерфейсами. Web-сервис обладает только программным интерфейсом, т.е. он предоставляет операции, которые могут быть вызваны удаленно (например внутри корпоративной сети или по сети Интернет). Задача Web-служб – предоставление услуг другим приложениям, как правило это Web-приложения. В настоящее время Web-сервисы становятся новыми фундаментальными элементами для построения сложных программных систем, реализующих сервис-ориентированную архитектуру (SOA) [1,2].

При широком использовании SOA необходимо для построения информационных систем необходимо, чтобы информация о предлагаемых разработчиком Web-сервисах была доступна, а поиск необходимого сервиса или хореографии сервисов не требовал бы больших затрат. Доступность информации достигается путём создания специализированных репозиториев, содержащих описания Web-служб [2]. Примером такого репозитория является UDDI (Universal Description Discovery & Integration) [3]. В качестве стандарта описаний Web-сервисов UDDI использует рекомендованный консорциумом W3C язык WSDL (Web Services Description Language) [4], а поиск осуществляется по ключевым словам, ассоциированных с этим описанием. Очевидно, что такой подход имеет ряд существенных недостатков, поскольку репозиторий не содержит информацию о семантике каждого сервиса. Так, два совершенно разных Web-сервиса могут иметь идентичные описания на WSDL. Решением данной проблемы является хранение в репозиториях семантических описаний Web-служб и использование их в процессе поиска. Web-сервисы с описанной семантикой называются семантическими Web-сервисами.

Семантический Web-сервис отличается от обычного web-сервиса тем, что обладает дополнительным уровнем семантического описания, заключающегося в том, что с операциями WSDL и с их входами и выходами связывается глобальный информационный ресурс в виде онтологии предметной области. Описание семантических Web-сервисов может быть реализовано в синтаксисе OWL-S [5], SAWSDL [6], SWRL [7]. В этих языках операциям WSDL соответствуют атомарные процессы с предусловиями и эффектами, а типам входов-выходов – классы онтологии предметной области. Например, OWL-S состоит из базовой онтологии, онтологии процесса, сервиса, модели сервиса. Этот язык обладает наиболее широкими возможностями и выразительностью из всех вышеперечисленных, а также был утвержден консорциумом W3C. [5]

Семантические Web-сервисы тесно связаны с такими понятием как семантический Web, поэтому их применение можно найти в таких трендах как открытые связанные данные, семантический социальный Web и семантические электронные библиотеки. [8]

Семантическое описание Web-сервиса

Для описания семантики Web-сервисов консорциум W3C предлагает использовать язык OWL-S совместно с RDF, RDFS, OWL. В OWL-S вводится понятие процесса. Это понятие упрощает представление потоков данных для разработчиков. Вводятся атомарные процессы, которые соответствуют операциям WSDL, а также составные процессы, которым соответствуют композиции Web-сервисов. [9]

Атомарный процесс – это процесс, который может быть непосредственно выполнен за одно взаимодействие с сервером, на котором работает реализующий данный процесс Web-сервис, т.е. взаимодействие клиента с сервисом, описанным при помощи атомарно процесса, происходит путем отправки Web-службе одного сообщения и получения от нее ответа. Таким образом, атомарный процесс OWL-S соответствует операции в WSDL описании сервиса.

Составной процесс – это процесс, требующий многошагового взаимодействия с сервером (серверами), на котором работают реализующие данный процесс атомарные сервисы. Таким образом, взаимодействие клиента с сервисом, описанным составным процессом, осуществляется при помощи отправки серии сообщений атомарным Web-службам в последовательности, точно определенной в описании составного процесса. [2]

Для составного процесса, состоящего только из атомарных: I – объединение множеств I всех атомарных процессов, входящих в составной. O – объединение множеств О всех атомарных процессов, входящих в составной, плюс выходы самого составного процесса, которые могут вычисляться на базе выходов атомарных процессов. Р – объединение множеств Р всех атомарных процессов, входящих в составной. Е – объединение множеств Е всех атомарных процессов, входящих в составной.

Таким образом, семантическое описание позволяет существенно уточнить поиск Web-сервисов, сводя его к поиску процессов. При этом процесс, в соответствии с рекомендациями W3C, представляется четверкой множеств <I, O, P, E>. [2,10]

В описании семантики четверкой множеств <I, O, P, E> никак не представлен алгоритм получения выходов на основании входов. Такую связь можно однозначно восстановить из описания онтологии предметной области лишь в некоторых случаях. Отображение входов процесса на его выходы должно быть задано явно в OWL-S описании множеством логических формул R. В результате каждый OWL-S процесс будет представлен пятеркой множеств <I, O, P, E, R>. [10]

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

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

Параллельная композиция – тип композиции, в котором процессы выполняются параллельно, при этом их вызов осуществляется одновременно, а результатом этой композиции служит процесс, входами которого является объединение входов всех процессов, подвергшихся композиции, а выходами – объединение всех выходов. [2,9,10]

Последовательная композиция

Последовательная композиция – композиция, в которой сервисы соединены и могут быть вызваны последовательно. Выходы предыдущего сервиса композиции являются входами последующего. (рис. 1).

Входом композиции этих процессов считается вход первого процесса и выходом – выход последнего процесса.

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>, I2 ⊆ O1;

Сse:<I1; O2; P1 & P2; Rse; E1 & E2>.

Предположим, что карты R1 и R2 – сервисы, реализуемые при помощи схемы:

R1(x1/type1,y1/type2;z1/type3,v1/type4,u1/type7);

R2(x2/type3,y2/type5;z2/type6);

Мы также знаем, что type4 есть type5, то есть ∀x/type4∃y/type5(x=y).

Тогда отображение, осуществляемое сервисом определяется как последовательного композиция Rse:

Rse(x1/type1,y1/type2;z2/type6)==∃z1/type3∃x2/type3∃v1/type4∃y2/type5∃u1/type7 R1(x1/type1,y1/type2;z1/type3,v1/type4,u1/type7) & (z1=x2) & (v1=y2) & R2(x2/type3, y2/type5; z2/type6)

Часть выхода система С1 (U1 / type7) также могут быть включены в выходной композиции, но это не будет чистой «Последовательностью». На практике необходимо решить задачу, когда невозможно найти службу, которая запускает следующую модель

Сabs:<Iabs; Oabs; Pabs; Rabs; Eabs>.

В этом случае делается попытка запустить такую модель в качестве последовательного соединения двух служб:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>.

Кандидаты на последовательное соединение находятся из условия: I1 = Iabs & I2 ⊆ O1 & Oabs ⊆ O2;

Если такой сервис найден, то необходимо доказать:

Pabs → P1 & P2;

Rabs == joinOI(R1,R2);

Eabs → E1 & E2; E1 & E2 → Eabs.

Disordered Composition (Any-Order)

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

Идея заключается в том, что если нет никакой разницы, какой из процессов начинает в первую очередь, то все входы и выходы обоих процессов обязательно должны быть проверены. То есть, количество входов и выходов обоих процессов должны быть одинаковыми и состояние совпадающие пары выход к входу должны быть выполнены. Проще, для выходов (рис 2).

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>, I1 = I2 и O1 = O2

Сao:<I1; O1; P1 & P2; join(R1,R2); E1 & E2>.

Пусть карты R1 и R2 – сервисы, реализованные с помощью схемы: R1(x1/type1,y1/type2;z1/type1,v1/type2);

R2(x2/type1,y2/type2;z2/type1,v2/type2).

Тогда служба, определенная над “неупорядоченной” служба состава С1 и С2 будут представлены отображения

Rao(x/type1,y/type2;z/type1,v/type2)==∃x1/type1∃y1/type2∃z1/type1∃v1/type2∃x2/type1∃y2/type2∃z2/type1∃v2/type2

R1(x1/type1,y1/type2;z1/type1,v1/type2) & z1=x2 & v1=y2 & x=x1 & y=y1 & z=z2 & v=v2

R2(x2/type1,y2/type2;z2/type1,v2/type2)

OR

R2(x2/type1,y2/type2;z2/type1,v2/type2) & Z2=x1 & v2=y1 & x=x2 & y=y2 & z=z2 & v=v2

R1(x1/type1,y1/type2;z1/type1,v1/type2)

В этом случае, задача разложения формулируется для последовательного подключения процессов.

Условная композиция

Условная композиция тип композиции, в которых выполнение одной из служб может быть достигнуто, только если выполняется условие (см рис.3):

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже:

С1:<I1; O1; P1; R1; E1>,

С2:<I2; O2; P2; R2; E2>.

Создание простой службы на основе этой конструкции является целесообразным, если выполняется следующее условие:

I1 = I2 and O1 = O2.

Сif:<I1; O1; P&P1 OR ¬P&P2; Rif; P&E1 OR ¬P&E2>.

Предположим, что карты R1 и R2 – сервисы, реализуемые при помощи схемы:

R1(x1/type1,y1/type2;z1/type3,v1/type4);

R2(x2/type1,y2/type2;z2/type3,v2/type4).

Тогда служба определяется условной композиции будет выполнять Rif:

Rif(x/type1,y/type2;z/type3,v/type4)== ∃x1/type1∃y1/type2∃z1/type3∃v1/type4∃xin/type1∃yin/type2 P(xin/type1,yin/type2) & R1(x1/type1,y1/type2;z1/type3,v1/type4) &x=x1 & y=y1 & z=z1 & v=v1 & x=xin & y=yin

OR

∃x2/type1∃y2/type2∃z2/type3∃v2/type4∃xin/type1∃yin/type2 ¬P(xin/type1,yin/type2) & R2(x2/type1,y2/type2;z2/type3,v2/type4) & x=x2 & y=y2 & z=z2 & v=v2 & x=xin & y=yin

Результаты этого анализа показывают, что только два управляющих структур – последовательные и параллельные полезны для автоматического состава процессов. Там должно быть процессом, который имеет вход полностью идентичные на вход желаемого процесса. Другие виды состава предлагается использовать для решения задач столкновения и invariation предлагаемых решений.

Пример поиска погодных условий в месте прилёта самолёта

Для описания процессов будем использовать стандартное представления логико-математического языка первого порядка, описанного в [10].

Пусть задан первый процесс, по номеру рейса возвращающий место назначения и время прибытия самолета:

S1(x/numFlight,y/destFlight, z/arrTimeFlight) == ∃i/Flight Flight_fnumber(i,x) & Flight_dest(i,y) & Flight_time(i,y)

Второй процесс ширину и долготу по названию города:

S2(x/location, y/latCoordinates, z/longCoordinates) = Location_coordinates(x,y,z)

Третий и четвертый процессы по долготе, ширине и времени выдает сведения о погоде, при этом третий процесс  работает с Северной и Южной Америкой (широта с -160 до -34), а четвертый со всем остальным миром

S3(x/latWeather,y/longWeather,z/Time,a/WeatherInfo)==∃i/Precipitation ∃j/Temperature Weather_coordinates(a,x,y) & Weather_time(a,z) & Weather_cond(a,i) & Weather_temp(a,j) & (y >= -160) & (y <= -34)

S4(x/latWeather,y/longWeather,z/Time,a/WeatherInfo) == ∃i/Precipitation ∃j/Temperature Weather_coordinates(a,x,y) & Weather_time(a,z) & Weather_cond(a,i) & Weather_temp(a,j) & (y <= -160) & (y >= -34)

Необходимо построить процесс, который по номеру рейса возвращает информацию о погодных условиях в месте прилёта. (рис.1)

S4(x/FlightNum, y/WeatherInfo) = ∃a/Flight ∃b/Time ∃c/Location ∃d/Temperature ∃e/Longtitude ∃f/Latitude  ∃g/Precipitation Flight_fnumber(a,x) & Flight_time(a,b) & Flight_dest(a,c) & Location_coordinates(c,e,f) & Weather_coordinates(y,e,f) & Weather_time(y,b) & Weather_cond(a,g) & Weather_temp(a,d)

С точки зрения логики, ясно, что последовательный вызов S1 и S2, а выбор между S3 и S4 решает поставленную задачу. Если предполагать автоматический подбор сервисов для решения задачи, то формально необходимо доказать

P(y) == (y >= -160) & (y <= -34)

S5(x/FlightNum, y/WeatherInfo) == (S1(x/numFlight, y/destFlight,z/arrTimeFlight) & S2(x/location, y/latCoordinates, z/longCoordinates)) & (P(y) ? S3(x/longWeather, y/longWeather, z/Time, a/WeatherInfo) : S4(x/longWeather, y/longWeather, z/Time,a/WeatherInfo))

Таблица 1. Концептуальная модель проблемной области.

Классы
Flight(x) WeatherInfo(x) Location(x)	FlightNumber(x) -> Digital(x) Temperature(x) -> Digital(x) Precipitation(x) -> String(x) Longitude(x) -> float(x) Latitude(x) -> float(x) Destination(x) -> String(x) ArrivalTime(x) -> TimeSpan(x) Time(x) -> TimeSpan(x)
Свойства
Flight_fnumber(x,y) -> Flight(x) & FlightNumber(y) : Flight_fnumber(x,y) & Flight_fnumber(x,z) -> y = z
Flight_dest(x,y) -> Flight(x) & Destination (y) : Flight_dest (x,y) & Flight_dest (x,z) -> y = z
Flight_time(x,y) -> Flight(x) & ArrivalTime(y) : Flight_time (x,y) & Flight_time (x,z) -> y = z
Location_coordinates(x,y,z) -> Location(x) & Longitude(y) & Latitude(z) -> Location_coordinates (x,y,z) & Location_coordinates (x,a,b) -> y=a & z=b
Weather_coordinates(x,y,z) -> WeatherInfo(x) & Longitude(y) & Latitude(z) -> Weather_coordinates (x,y,z) & Weather_coordinates (x,a,b) -> y=a & z=b
Weather_temp(x,y) -> WeatherInfo(x) & Temperature(y)  -> Weather_temp (x,y) & Weather_temp (x,z) -> y=z
Weather_cond(x,y) -> WeatherInfo(x) & Precipitation (y)  -> Weather_cond (x,y) & Weather_cond (x,z) -> y=z
Weather_time(x,y) -> WeatherInfo(x) & Time(y)  -> Weather_time (x,y) & Weather_time (x,z) -> y=z
Связи
Flight_location(x,y) = Flight(x) & Location(y)
Location_weather(x,y) = Location(x) & Weather(y)
Flight_weather(x,y,z) = Flight(x) & Weather(y) & Time(z)
Производные классы
destFlight(y) == ∃x  Flight_location(x,y) destFlight(y) -> Location(y)
arrTimeFlight(y) == ∃x Flight_time(x,y) arrTimeFlight (y) -> ArrivalTime(y)
locWeather(x,y) == ∃z Weather_coordinates(z,x,y) locWeather(x,y) -> WeatherInfo(z)
numFlight(y) == ∃x Flight_fnumber(x,y) numFlight(y) -> FlightNumber(y)
longCoordinates(y) == ∃x∀z  Location_coordinates(x,y,z) longCoordinates(y) -> Longitude(y)
latCoordinates(z) == ∃x∀y Location_coordinates(x,y,z) latCoordinates(z) -> Latitude(z)
longWeather(y) == ∃x∀z Weather_coordinates(x,y,z) longWeather(y) -> Longitude(y)
latWeather(z) == ∃x∀y Weather_coordinates(x,y,z) latWeather(z) ->Latitude(y)
condWeather(y) == ∃x  Weather_cond(x,y) condWeather(y) -> Precipitation(y)
tempWeather(y) == ∃x  Weather_temp(x,y) tempWeather(y) -> Temperature(y)
timeWeather(y) == ∃x Flight_time(x,y) timeWeather (y) -> Time(y)

То есть, S5(x/FlightNum, y/WeatherInfo) == ∃a/Flight ∃b/Time ∃c/Location ∃d/Temperature ∃e/Longtitude ∃f/Latitude ∃g/Precipitation Flight_fnumber(a,x) & Flight_time(a,b) & Flight_dest(a,c) & Location_coordinates(c,e,f) & Weather_coordinates(y,e,f) & Weather_time(y,b) & Weather_cond(a,g) & Weather_temp(a,d)

Заключение

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

Были продемонстрированы, что поиск для обоих атомных и композиционных процессами осуществляется по запросу, приведены в виде, должны сопровождаться доказательства утверждений, которые можно схематически выражается как:

Pquery <=> Pprocess, Rquery <=> Rprocess и Equery <=> Eprocess.

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

Библиографический список

1. В тексте: [1]. В затекстовой ссылке: Brogi A., Corfini.S., and Popescu R. Semantics-Based composition-oriented discovery of Web services // ACM Trans. Intell. Technol. September 2008.8.4. Artice 19
2. В тексте: [2]. В затекстовой ссылке: Хоботов А.А., Климов В.В., Климов В.П., Цыганов А.А., Щукин Б.А. Семантические Веб-сервисы, их поиск и композиция // Информационно-измерительные и управляющие системы. 2012. №8. Т.10. С. 34-39.
3. В тексте: [3]. В затекстовой ссылке: UDDI // Online Community for the Universal Description, Discovery…, http://uddi.xml.org
4. В тексте: [4]. В затекстовой ссылке: Web Service Desciption Language (WSDL 1.1.) // http://www.w3.org
5. В тексте: [5]. В затекстовой ссылке: OWL-S: Semantic Markup for Web Services // http:/www.w3.org/TR/sawsdl
6. В тексте: [6]. В затекстовой ссылке: Semantic Annotations for WSDL Working Group http://www.w3.org/2002/ws/sawsdl/
7. В тексте: [7]. В затекстовой ссылке: Semantic Web Rule Language. http://www.w3.org/Submission/SWRL/
8. В тексте: [8]. В затекстовой ссылке: Хорошевский В. Ф. Семантические технологии: ожидания и тренды // Открытые семантические технологии проектирования интеллектуальных систем. Материалы II международной научно-технической конференции. 2012.02.16-2012.02.18. С. 143-158.
9. В тексте: [9]. В затекстовой ссылке: Щукин Б.А. Семантические Web-сервисы // Информационно-измерительные и управляющие системы. 2013. №6. Т.11. С. 60-64.
10. В тексте: [10]. В затекстовой ссылке: Б.А. Щукин, Волченков Н.Г., Климов В.В., Дмитриенко А.И., Орлов А.В. Композиция семантических Web-сервисов // Информационно-измерительные и управляющие системы. 2011. №6. Т.9. С. 35-42.

---

Количество просмотров публикации: Please wait

Все статьи автора «zexir»