Разработка приложений в сервис-ориентированной архитектуре семантического веб (часть 5)

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

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

Сервисы обеспечивают требуемую функциональность для определенной цели. Сервисная ориентация разрешает горизонтальное представление сервисов, кроме того отличают сервисы нескольких типов. По типу функциональности различаем два вида сервисов:

• бизнес сервисы, представляющие собой сервисы, которые обеспечиваются различными серверными системами поставщиков сервисов. Бизнес-сервисы являются предметом интеграции и взаимодействия в пределах архитектуры и могут обеспечивать требуемое значение для пользователей. В архитектуре, бизнес-сервисы публикуют поставщики сервисов путем формирования семантических описаний, согласованных с моделью WSMO. Бизнес-сервисы издаются и содержатся в хранилищах посредников;
• сервисы-посредники представляют собой вспомогательные средства для интеграции и взаимодействия бизнес-сервисов. Сервисы-посредники встраиваются в систему-посредник.

На уровне абстракции бизнес-сервисов различают следующие два вида сервисов:

• Веб-сервисы, представляющие собой общие сервисы, имеющие несколько форм и, которые далее могут конкретизироваться (например, приобретают билет на рейс);
• сервисы, представляющие собой фактические образцы Веб-сервисов и, которые обеспечивают конкретное значение для пользователей (например, приобретают билет на рейс компании «Аэросвит» из Киева до Нью-Йорка).

1. Сервисы-посредники реализуют общую или частичную концептуальную функциональность посредника. Эти сервисы отражают среду реализации SEE посредника WSMX. Сервисы-посредники могут комбинироваться с процессами посредника, которые обеспечивают дополнительную функциональность системы. Основными сервисами-посредниками в WSMO являются:

Ядро можно рассматривать как сервис, который реализует управление выполнением, мониторинг, отработку ошибок и формальные языки концептуального моделирования посредника. Ядро, реализующее коммуникацию и координацию процессов посредника определяется семантикой выполнения, которая определяет взаимодействие различных сервисов-посредников, обслуживающие процесс посредника для заданной цели. Каждый процесс посредника запускается через внешний интерфейс сервисом коммуникации и связан через другие внешние интерфейсы асинхронной связью в процессе взаимодействия с посредником. В посреднике может существовать несколько семантик выполнения, которые обеспечивают процессы моделирования, создания, развертывания и управления, сокращая время разработки. Ядро посредника осуществляет также поддержку формального языка -анализатора, реализующий семантические сообщения в объектной модели WSMO4J [16]. Кроме того, ядро осуществляет распределенные действия посредника, позволяющие взаимодействие с множеством физических машин, используя общее пространство сообщений. Разделение области сообщений обеспечивает абстракцию запроса для распределенной архитектуры, которая обеспечивает масштабируемость процессов интеграции.

Коммуникационный сервис реализует коммуникацию и Граундинг на уровне концептуальной функциональности посредника. Любое сообщение направлено или послано от посредника системы передается через этот компонент. Интеграция семантических Веб-сервисов в системе осуществляется посредством сообщений, сопровождающих семантические описания данных в соответствии с моделью WSMO. Механизм, используемый для запуска сервисов, основан на SOAP и WSDL спецификациях. Поэтому, компонент коммуникации также реализует механизмы для семантик Граундинга уровня WSMO и физического уровня запуска сервисов.

Сервис рассуждений реализует функциональность рассуждений в посреднике. Он обеспечивает поддержку рассуждений над семантическими описаниями ресурсов. Рассуждение представляет собой важную функциональность, которая требуется в процессе выполнения, например, поиск, посредничество для данных, посредничество для процессов и т. п. К рассуждениям применяются различные требования, которые основаны на варианте языка WSML, используемого для семантических описаний. В основе рассуждений положена дескриптивная логика, которая нужна для того, чтобы использовать варианты языка WSML, язык Datalog или F-logic, положенные в основу рассуждений, когда используется WSML-flight или WSML-rule соответственно. Использование различных средств для рассуждений зависит от связи приложений и полноты используемых семантических описаний в моделировании. Компонент рассуждений в дополнении к существующим рассуждениям (WSML2Reasoner [17]) предлагает универсальный уровень, который соответствует упомянутым требованиям. В зависимости от варианта WSML, запросы передаются машине рассуждений в прозрачной форме. Рассуждения для WSML работоспособны также в WSML WG.

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

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

Посредничество данных действует в соответствии со схемой правил между онтологиями, которые предварительно должны быть опубликованы в архитектуре перед тем, как реализуется посредничество. Эти правила должны быть созданы на этапе проектирования как часть средств управления онтологиями WSMT.

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

Усовершенствование цели представляет собой процесс создания абстрактной цели на основе конкретной цели. Абстрактная цель не содержит данных образца. Данные образца обеспечиваются отдельно из определения цели синхронно или асинхронно, тогда как конкретная цель непосредственно содержит встроенные данные образца, как часть определения WSMO. Например, WSMO конкретизирует цель, которая может содержать аксиоматику в форме ?x[namehasValue “HarryPotter”] memberOf book, тогда как абстрактная цель содержит аксиоматику в форме ?x memberOf book, где образец book (книга) указывается отдельно от определения цели.

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

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

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

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