Композиция семантических веб-сервисов на основе их семантического описания - Реферат

Атомарный процесс - это процесс, который может быть непосредственно выполнен за одно взаимодействие с сервером, на котором работает реализующий данный процесс Web-сервис, т.е. взаимодействие клиента с сервисом, описанным при помощи атомарно процесса, происходит путем отправки Web-службе одного сообщения и получения от нее ответа. Параллельная композиция - тип композиции, в котором процессы выполняются параллельно, при этом их вызов осуществляется одновременно, а результатом этой композиции служит процесс, входами которого является объединение входов всех процессов, подвергшихся композиции, а выходами - объединение всех выходов. Предположим, что карты R1 и R2 - сервисы, реализуемые при помощи схемы: R1(x1/type1,y1/type2;z1/type3,v1/type4,u1/type7); Тогда отображение, осуществляемое сервисом определяется как последовательного композиция 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) Тогда служба определяется условной композиции будет выполнять 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Описание взаимоотношений между входами и выходами веб-сервисов в настоящее время не поддерживается. Были продемонстрированы, что поиск для обоих атомных и композиционных процессами осуществляется по запросу, приведены в виде, должны сопровождаться доказательства утверждений, которые можно схематически выражается как: Pquery Pprocess, Rquery Rprocess и Equery Eprocess.

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]

1. Семантическое описание 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, представляется четверкой множеств . [2,10]

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

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

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

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

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

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

IMG_90ef6cac-3bd2-4d24-8d4c-412fd8581d3e

Рис. 1. Последовательная композиция веб-сервисов

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

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже: С1:, С2:, I2 ? O1;

Cse:.

Предположим, что карты 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) также могут быть включены в выходной композиции, но это не будет чистой «Последовательностью». На практике необходимо решить задачу, когда невозможно найти службу, которая запускает следующую модель

Cabs:.

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

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

Если такой сервис найден, то необходимо доказать: Pabs > P1 & P2;

Rabs == JOINOI(R1,R2);

Eabs > E1 & E2; E1 & E2 > Eabs.

Disordered Composition (Any-Order)

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

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

IMG_bb4f35d5-fd5d-4e47-87f3-d22f7f7619c1

Рис. 2. Последовательная композиция веб-сервисов

Множественно-теоретическая модель соответствующих простых сервисов приведена ниже: С1:, С2:, I1 = I2 и O1 = O2

Cao:.

Пусть карты 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. Условная композиция

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

IMG_3435358c-c289-4260-a969-34ae689d7d2e

Рис. 3. Условная композиция веб-сервисов

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

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

Cif:.

Предположим, что карты 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 предлагаемых решений.

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

Для описания процессов будем использовать стандартное представления логико-математического языка первого порядка, описанного в [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 = -34)

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

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)

IMG_cd9c5656-2532-40fe-9a36-47e70d406454

Рис. 4. Связь процессов

С точки зрения логики, ясно, что последовательный вызов 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. 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. Хоботов А.А., Климов В.В., Климов В.П., Цыганов А.А., Щукин Б.А. Семантические Веб-сервисы, их поиск и композиция // Информационно-измерительные и управляющие системы. 2012. ? 8. Т. 10. С. 34-39.

3. UDDI // Online Community for the Universal Description, Discovery…, http://uddi.xml.org.

4. Web Service Desciption Language (WSDL 1.1.) // http://www.w3.org.

5. OWL-S: Semantic Markup for Web Services // http:/www.w3.org/TR/sawsdl.

6. Semantic Annotations for WSDL Working Group http://www.w3.org/2002/ws/sawsdl/.

7. Semantic Web Rule Language. http://www.w3.org/Submission/SWRL/.

8. Хорошевский В. Ф. Семантические технологии: ожидания и тренды // Открытые семантические технологии проектирования интеллектуальных систем. Материалы II международной научно-технической конференции. 2012.02.16-2012.02.18. С. 143-158.

9. Щукин Б.А. Семантические Web-сервисы // Информационно-измерительные и управляющие системы. 2013. № 6. Т. 11. С. 60-64.

10. Б.А. Щукин, Волченков Н.Г., Климов В.В., Дмитриенко А.И., Орлов А.В. Композиция семантических Web-сервисов // Информационно-измерительные и управляющие системы. 2011. № 6. Т. 9. С. 35-42.

Размещено на .ru