Development of applications in service-oriented architecture of Semantic Web

Semantic service-oriented architecture is based on principles of service orientation, semantic modeling and intellectual and automated integration, defines basis for new technology which provides new tools of service integration, great adaptability to changes of business requirements and execution e...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2025
Автор:	Deretskiy, V.A.
Формат:	Стаття
Мова:	Russian
Опубліковано:	PROBLEMS IN PROGRAMMING 2025
Теми:	UDC 681.3
Онлайн доступ:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/847
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Problems in programming
Завантажити файл:

Репозитарії

Problems in programming

id	pp_isofts_kiev_ua-article-847
record_format	ojs
resource_txt_mv	ppisoftskievua/80/a5abde2ebf0a2bf78810a860778a7980.pdf
spelling	pp_isofts_kiev_ua-article-8472025-09-08T13:41:18Z Development of applications in service-oriented architecture of Semantic Web Разработка приложений в сервис-ориентированной архитектуре семантического Веб Розробка додатків у сервіс-орієнтованій архітектурі семантичного Веб Deretskiy, V.A. UDC 681.3 УДК 681.3 УДК 681.3 Semantic service-oriented architecture is based on principles of service orientation, semantic modeling and intellectual and automated integration, defines basis for new technology which provides new tools of service integration, great adaptability to changes of business requirements and execution environments. The architecture is defined, beginning from abstract business model of the semantic service application, finalizing with the services, processes and technologies and accordingly to the ontology modeling of Web services (WSMO).Prombles in programming 2010; 1: 66-78 Семантическая сервис-ориентированная архитектура основана на принципах сервисной ориентации, семантического моделирования, интеллектуальной и автоматизированной интеграции, определяет основу для новой технологии, которая обеспечивает новые средства интеграции сервисов, большую адаптивность к изменениям бизнес-требований и сред выполнения. Архитектура определяется, начиная от абстрактной бизнес-модели семантического сервисного приложения, завершая сервисами, процессами, технологиями и в соответствии с онтологией моделирования Веб-сервисов (WSMO).Prombles in programming 2010; 1: 66-78 Семантична сервіс-орієнтована архітектура заснована на принципах сервісної орієнтації, семантичного моделювання, інтелектуальної і автоматизованої інтеграції, визначає основу для нової технології, яка забезпечує нові засоби інтеграції сервісів, велику адаптивність до змін бізнес-вимог і середовищ виконання. Архітектура визначається, починаючи від абстрактної бізнес-моделі семантичного сервісного застосування, завершуючи сервісами, процесами, технологіями і відповідно до онтології моделювання Веб-сервісів (WSMO).Prombles in programming 2010; 1: 66-78 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-09-08 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/847 PROBLEMS IN PROGRAMMING; No 1 (2010); 66-78 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2010); 66-78 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2010); 66-78 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/847/898 Copyright (c) 2025 PROBLEMS IN PROGRAMMING
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2025-09-08T13:41:18Z
collection	OJS
language	Russian
topic	UDC 681.3
spellingShingle	UDC 681.3 Deretskiy, V.A. Development of applications in service-oriented architecture of Semantic Web
topic_facet	UDC 681.3 УДК 681.3 УДК 681.3
format	Article
author	Deretskiy, V.A.
author_facet	Deretskiy, V.A.
author_sort	Deretskiy, V.A.
title	Development of applications in service-oriented architecture of Semantic Web
title_short	Development of applications in service-oriented architecture of Semantic Web
title_full	Development of applications in service-oriented architecture of Semantic Web
title_fullStr	Development of applications in service-oriented architecture of Semantic Web
title_full_unstemmed	Development of applications in service-oriented architecture of Semantic Web
title_sort	development of applications in service-oriented architecture of semantic web
title_alt	Разработка приложений в сервис-ориентированной архитектуре семантического Веб Розробка додатків у сервіс-орієнтованій архітектурі семантичного Веб
description	Semantic service-oriented architecture is based on principles of service orientation, semantic modeling and intellectual and automated integration, defines basis for new technology which provides new tools of service integration, great adaptability to changes of business requirements and execution environments. The architecture is defined, beginning from abstract business model of the semantic service application, finalizing with the services, processes and technologies and accordingly to the ontology modeling of Web services (WSMO).Prombles in programming 2010; 1: 66-78
publisher	PROBLEMS IN PROGRAMMING
publishDate	2025
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/847
work_keys_str_mv	AT deretskiyva developmentofapplicationsinserviceorientedarchitectureofsemanticweb AT deretskiyva razrabotkapriloženijvservisorientirovannojarhitekturesemantičeskogoveb AT deretskiyva rozrobkadodatkívuservísoríêntovaníjarhítekturísemantičnogoveb
first_indexed	2025-09-17T09:25:34Z
last_indexed	2025-09-17T09:25:34Z
_version_	1850410913827389440
fulltext	Інтелектуальні інформаційні системи 66 УДК 681.3 В. Дерецкий РАЗРАБОТКА ПРИЛОЖЕНИЙ В СЕРВИС-ОРИЕНТИРОВАН- НОЙ АРХИТЕКТУРЕ СЕМАНТИЧЕСКОГО ВЕБ Семантическая сервис-ориентированная архитектура основана на принципах сервисной ориентации, семантического моделирования, интеллектуальной и автоматизированной интеграции, определяет ос- нову для новой технологии, которая обеспечивает новые средства интеграции сервисов, большую адап- тивность к изменениям бизнес-требований и сред выполнения. Архитектура определяется, начиная от абстрактной бизнес-модели семантического сервисного приложения, завершая сервисами, процессами, технологиями и в соответствии с онтологией моделирования Веб-сервисов (WSMO). Введение Для того, чтобы отвечать требова- ниям бизнеса, гибкости и динамики про- исходящих процессов, традиционные мо- нолитные приложения требуют замены на более мелкие единицы функциональности, которые можно комбинировать и собирать в сложные программные конструкции. Чтобы соответствовать этой парадигме информационным системам необходимо обеспечивать повторную конфигурацию для создания новых приложений, разви- ваемых как сервисы и наследуемые систе- мы. Движением в этом направлении явля- ется развитие парадигмы сервис- ориентированной архитектуры (SOA) с це- лью разрешения проблем динамики среды и адаптивности бизнес-процессов. SOA строится как уровневая модель сервисов, которая согласовывается с принципами свободного связывания сервисов, повтор- ного использования, подающихся обнару- жению и композиции. Идеи и существующие решения SOA, направленные на решение задач адаптивности бизнес-требований, являют- ся трудными для измерения без надлежа- щей степени автоматизации. При сегод- няшних сервисных технологиях таких как: WSDL, SOAP, UDDI и BPEL, которые реа- лизуют новые возможности SOA, обеспе- чивая частичную совместимость с помо- щью унификации технологического окру- жения, в котором осуществляется согласо- вание на уровне контента и процессов для каждого конкретного случая [1, 2]. Гибкость и расширяемость XML может определить только структуру и син- таксис данных. Без понятной для машины семантики сервисы могут быть размещены и связаны только во время их проектиро- вания, что в свою очередь ограничивает возможности автоматизации. Для преодо- ления этих недостатков предлагается рас- ширение SOA семантикой, которая обес- печивает масштабируемую интеграцию и адаптацию к изменениям, происходящих на этапах жизненного цикла программной системы. Семантика позволит определить развитые формальные модели, в которых определяются возможности сервисов и требования их потенциальных потребите- лей. Семантические данные, посредством которых осуществляется обмен между бизнес партнерами, могут быть одно- значно описаны в форме и в терминах он- тологий. С помощью семантических средств логического рассуждения SOA обеспечивает полную или частичную ав- томатизацию поиска сервисов, согласо- вания, посредничества, запуска на выпол- нение и композицию. Семантические сред- ства SOA не заменяют существующие тех- нологии интеграции. Цель подхода состо- ит в построении нового уровня сервисов, основанного на принятых существующих промышленных стандартах и технологиях используемых в пределах существующих инфраструктур. Мы представляем семантическую сервис-ориентированную архитектуру, ко- торая соответствует основным принципам управления и, которая обеспечивает ана- лиз, проектирование и поддержку архитек- туры в части посредничества, сервисной © В. Дерецкий, 2010 ISSN 1727-4907. Проблеми програмування. 2010. № 1 Інтелектуальні інформаційні системи 67 ориентации и логик обработки приложе- ний. Мы впервые определяем семантиче- скую архитектуру независимо от глобаль- ной перспективы, в основе которой поло- жены сервисные модели. Подробно опи- сываем сервисы и типы обработки, кото- рые обеспечивают архитектуру и техноло- гии, которые используются для построения сервисных приложений. 1. Принципы управления на основе знаний Семантическая сервис-ориентиро- ванная архитектура строится с использо- ванием принципов, которые определяют управление на основе знаний, разработку и выполнение приложений. Эти принципы отражают фундаментальные аспекты сервис-ориентированного и распределен- ного окружения семантической интегра- ции бизнес-сервисов [3]. Принципы вклю- чают: • принцип сервисной ориентации, обеспечивающий подходы для анализа, проектирования и выполнения при- ложений, которые основаны на возможно- стях сервисов – повторное использование, свободное связывание, абстрактное моде- лирование, композиционность, автоном- ность, поиск и др.; • семантический принцип, кото- рый обеспечивает формальное описание информации и динамические модели, до- пускающие автоматизацию решения задач с помощью логического рассуждения. Комбинируя этот принцип с принципом сервисной ориентации семантика позволя- ет определять такие характеристики серви- сов: масштабируемость, семантическую интероперабельность, формальные модели сервисов и онтологий, позволяющие обес- печить частичную или полную автомати- зацию решения задач, например, поиск сервисов, согласование, композицию сер- висов и другие; • принцип принятия решений, как одно из фундаментальных положений ис- кусственного интеллекта. Он обеспечивает такую характеристику архитектуры, кото- рая основана на целе-ориентированном поиске и выполнении сервисов. Пользова- тели описывают запросы как семантиче- ские цели независимые от самих сервисов, в то время как архитектура с помощью ло- гического рассуждения над целями и опи- саниями сервисов обеспечивает их наи- лучшее достижение. Пользователям не нужно быть осведомленным в логике об- работки, а заботиться только о результате и его качестве; • принцип распределенности, ко- торый позволяет агрегировать возможно- сти нескольких вычислительных объектов путем сотрудничества. Этот принцип обеспечивает выполнение множества сер- висов в сети, обеспечивая масштаби- руемость и требуемое качество процесса. 2. Семантическая сервис- ориентированная архитектура Семантическая сервис-ориентиро- ванная архитектура, построенная на выше- рассмотренных принципах, показана на рис. 1. Архитектура содержит следующие основные уровни: 1) пользователей или группы пользователей; 2) принятия реше- ний; 3) заказчиков сервисов; 4) посредни- ков сервисов, обеспечивающие интегра- цию и взаимодействие сервисов; 5) пос- тавщиков сервисов, обеспечивающие пуб- ликацию функциональности серверных систем как бизнес-сервисов. 2.1. Уровень пользователей пред- ставляет группы различных пользователей, использующие функциональность архи- тектуры для своих целей. Идентифициру- ют две основные группы пользователей: пользователи приложений и инженеры. Пользователи приложений составляют группу, для которой архитектура обеспе- чивает доступ к функциональности через специализированные приложения и ин- терфейсы. Например, пользователи могут вы- полнять обмен информацией для приобре- тения продукции или выполнять размеще- ние заказов, или выполнение финансовых сделок. Задача этого уровня состоит в том, чтобы позволить пользователям взаимо- действовать с бизнес-процессами он-лайн и, при этом, сократить физические взаимо- действия с процессами сервера. Інтелектуальні інформаційні системи 68 Рис. 1. Глобальная схема архитектуры Другая группа пользователей – ин- женеры, которая формирует уровень, обеспечивающий развитие и администри- рование задач в архитектуре. Эти задачи должны поддерживать жизненный цикл SOA, в том числе моделирование сервисов, создание, композицию, развертывание (публикация) и управление. В эту группу могут быть вовлечены такие пользователи: эксперты предметных областей (модели- рование, создание онтологий), админи- страторы системы (развертывание, упра- вление); конструкторы программного обеспечения и другие. 2.2. Уровень принятия решений представляет приложения и инструменты, которые поддерживают пользователей в части формирования запросов и прео- бразования их в форму пользовательских целей. Через уровень принятия решений, пользователь сможет формулировать проб- лему, обеспечивать взаимодействие с ар- хитектурой в процессе обработки запросов и получать желаемые результаты. Сервер- ные процессы этого уровня обеспечивают интерфейс для бизнес-процессов. Для это- го строятся специализированные прило- жения в требуемой предметной области, используя онтологии предметной области и инструменты разработки, обеспечиваю- щие необходимую функциональность для развития и администрирования задач в пределах архитектуры. Функциональность средств разра- ботки покрывают этапы жизненного цикла SOA, в том числе моделирование сервисов, создание, композицию, развертывание (публикация), управление и др. Интегрированная среда разработки (IDE – Integration Design Environment) обеспечивает формирование семантичес- ких описаний (сервисы, цели и онтологии), создание схем посредничества между по- средником и внешними системами. Объе- Пользователь 1 Пользователь 2 Системный администратор Инженер ПО Серверная система Х Бизнес сервис S1 Приложения (средства доступа, порталы доступа …) Онтологии ПрО Средства разработки (управления онтологиями, мониторинг) Сеть (Internet, Intranet, Extranet) Серверная система Z Бизнес сервис S2 Бизнес сервис S3 SEE (машина C) SEE (машина B) SEE машина A Уп рав ле- ни е вы по лне ни З а щ и т а Поиск Мониторинг Адаптация Оркестровка Медиатор Граудинг Формальные языки Рассуждения Коммуникации Разделение пространства сообщений SEE (машина D) Уровень посредника Уровень провайдера сервисов Посредник Базовый уровень Уровень пользователей Уровень принятия решений Уровень запроса сервисов Эксперт предметной области Інтелектуальні інформаційні системи 69 диняя эту функциональность, разработчик может создавать и управлять онтологиями, Веб-сервисами, целями и посредниками, создавать онтологии для посредников, встраивать их в среду посредников. 2.3. Уровень запросов сервисов. Клиенты системы формируют цели по- средством описания запросов и интер- фейсов, через которые осуществляется взаимодействие с потенциальными серви- сами. Средства для принятия решений ис- пользуют семантическую спецификацию сервисов. 2.4. Уровень посредника. Посре- дник является ядром архитектуры, обеспе- чивающий главную функциональность в части интеграции и взаимодействия биз- нес-сервисов. Посредники представляют семантическую среду выполнения серви- сов (SEE). SEE определяет необходимую концептуальную функциональность, кото- рая реализуется (полностью или частично) сервисами-посредниками. Функциональ- ность посредника используется на сле- дующих уровнях: вертикальный уровень, уровень посредника и базовый уровень. Среда выполнения основана на средствах WSMX и IRS-III [4, 5]. Вертикальный уровень определяет функциональность структуры посредника, которая используется базовыми уровнями, но остается невидимой для них. Эта тех- нология использует так называемый ”Гол- ливудский принцип”, который подра- зумевает ”не звоните нам, мы позвоним вам” [6]. Функциональность обеспечивает координацию и управление процессами в посреднике. Управление выполнением основано на управлении различными сценариями, называемыми семантиками выполнения, и реализует распределенное выполнение сервисов. Безопасность включает средства идентификации, аутентификации конфи- денциальности, кодирования данных, под- держку отслеживания и безотказности в пределах сценариев выполнения. Уровень посредника (брокера) обес- печивает: • поиск бизнес-сервисов, которые соответствуют цели заказчика; • оркестровку выполнения бизнес- процессов, включая переговоры между за- казчиком и поставщиком сервиса в преде- лах бизнес-процесса; • мониторинг осуществляет кон- троль выполнения сервисов и используется для сбора информации о сервисах, напри- мер, QOS – показатель качества, идентифи- кация сбоев в процессе выполнения и т.д.; • управление ошибками обеспечи- вает обработку ошибок при выполнении Веб-сервисов; • адаптацию, представляющую со- бой согласование пользовательских пред- почтений в пределах сценария выпол- нения, например, выбор сервиса обеспече- ния переговоров, заключение контракта; • посредничество, определяющее совместимость данных и процессов на функциональном уровне; • композицию сервисов в процессе выполнения потока работ (бизнес- процессов); • Граундинг, устанавливающий связь между семантическим уровнем (WSMO) и синтаксическим уровнем (WSDL), используемый при запуске серви- сов на выполнение. Базовый уровень включает функ- циональность, необходимую для успеш- ного выполнения процессов на уровне по- средника. Базовый уровень содержит: • формальные языки, определяю- щие синтаксические действия (например, анализ–Parsing), семантические языки, ис- пользующие семантическое описание сер- висов, целей и онтологий; • рассуждения, определяющие функциональность над семантическими описаниями; • репозитории для хранения эле- ментов системы – сервисов, онтологий; • средства, обеспечивающие внут- ренние и внешние коммуникации посред- ника. Посредник среды выполнения сер- висов обеспечивает распределенность, в данном случае ряд систем посредника объ- единяются путем разделяемых сообщений и, таким образом, обеспечивают масшта- бируемость процессов интеграции. Інтелектуальні інформаційні системи 70 2.5. Уровень поставщиков серви- сов. Поставщики сервисов обеспечивают различные серверные (back-end) системы. Серверная система служит для обеспече- ния функциональности заданной цели биз- нес-сервиса. В зависимости от развертыва- ния архитектуры и сценариев интеграции, сервера системы могут обеспечивать одну организацию (один поставщик сервисов) или множество организаций (много по- ставщиков сервисов), которые связаны по сети (Интернет, Интранет или Экстранет). Архитектура может обслуживать различ- ные модели интеграции: бизнес-бизнесу (B2B), приложение предприятию (EAI) или приложение приложению (A2A). Во всех моделях функциональность серверов представляется как семантическое описа- ние бизнес-сервисов. 3. Модель семантических сервисов WSMO Модель семантических сервисов формирует дополнительный уровень над существующими моделями Веб-сервисов, путем добавления семантической разметки для функциональных, не функциональных и динамических характеристик сервисов. Существует несколько инициатив в этой области, например, онтология модели- рования Веб-сервисов (WSMO) [7], Owl-s [8] и WSDL-s [9]. В соответствии с требованиями ар- хитектуры и принципами управления в предложенном подходе мы выбрали мо- дель WSMO. Выбор WSMO, а не других спецификаций (например, Owl-s) основы- вался на том, что WSMO явным образом сфокусирована на принятии решений и ин- теграции целей и сервисов, поэтому пол- ностью соответствует принципам семан- тического принятия решений и семантиче- ской организации сервисов. Кроме того, WSMO развивается как структура, которая включает: описание концептуальной моде- ли, определяющей характеристики Веб- сервисов: онтологии, цели, Веб-сервисы и посредники. Язык моделирования Веб- сервисов (WSML) [7, 10] представляет се- мейство онтологических языков, основан- ных на логических формализмах и уровнях логической выразительности, в том числе дескриптивной логики и логики програм- мирования. Среда выполнения Веб- сервисов (WSMX) – представляет собой средства для реализации системы посред- ника [11]. Инструментарий для моделиро- вания Веб-сервисов (WSMT) используется для разработки описаний таких объектов WSMO: сервисы, цели и онтологии. Обес- печивается также создание проекций по- средника на внешние системы. WSMO и его компоненты обеспечивают основы се- мантического моделирования сервисов и семантической технологии, которая может адаптироваться к требованиям предметных областей (например, путем расширения функциональности WSML,WSMX, WSMT и т.п.). Концептуальная модель WSMO представляет собой модель верхнего уров- ня, определяющая онтологию, исполь- зуемую для моделирования бизнес-серви- сов. Она же содержит описание онтологии, Веб-сервисов, целей и посредников. Онтологии обеспечивают формаль- ное определение семантики для WSMO. Двумя ключевыми отличиями онтологий являются принципы разделяемой концеп- туализации и формальной семантики. Об- щая концептуализация представляет собой средство, обеспечивающие инфор- мационную совместимость через незави- симые цели и описания Веб-сервисов. Веб-сервисы определяют функцио- нальные возможности и один или большее число интерфейсов, которые дают клиен- там сервиса возможность обращения к не- му. Возможности сервиса моделируются посредством использования пред- условия и предположения о состоянии инфор- мационного пространства и внешнего мира перед выполнением, выходные пост- усло- вия и результаты, определяющие состоя- ние после выполнения сервиса. Интерфей- сы сервиса разделяются на хореографию и оркестровку. Хореография определяет способ взаимодействия с сервисом, при этом оркестровка определяет декомпози- цию его функциональности в терминах других сервисов. Цели представляют описание запро- сов, которые хочет достичь пользователь. Цели WSMO описываются в терминах Інтелектуальні інформаційні системи 71 предметной области выполняемого запро- са заданного сервиса. Цель WSMO харак- теризуется возможностью запроса и ин- терфейсом запроса. Посредники представляют элемен- ты, которые нацелены на разрешение структурных, семантических или концеп- туальных несоответствий, которые появ- ляются между различными компонентами в пределах среды WSMO. Сравнение WSMO с его основным конкурентом Owl-s и другими подходами представлено в [12]. 4. Сценарий примера семантиче- ской сервис-ориентированной ар- хитектуры В этом разделе рассмотрим пример, на котором исследуются различные аспек- ты семантической сервис-ориентирован- ной архитектуры. Сценарий примера и его реализация основана на предложениях инициативы SWS Challenge [13], обеспе- чивающая стандартное множество слож- ных задач, основанных на индустриальных спецификациях и требованиях. Как пока- зано на рис. 2, сценарий включает различ- ных поставщиков сервисов (например, корпорации «Racer» и «Mueller»), которые предлагают поставки различной продук- ции через обращение к рынку «Moon». С другой стороны, есть запрашивающая сто- рона сервисов под названием «Blue», кото- рая намеревается купить определенную продукцию по возможно приемлемой цене [14]. Рынок «Moon» взаимодействует с электронным рынком на уровне системы- посредника семантической сервис-ориен- тированной архитектуры. Следуя сцена- рию «Moon» использует системы для взаимоотношений с клиентами (CRM) и расчетную систему (OMS), при этом «Blue» использует стандартную систему RosettaNet8 [15]. Рис. 2. Пример выполнения сервисной системы Управление от- ношениями с заказчиком Управление опе- рациями Описание Шлюз RosettaNet Компания Blue (инициатор сервиса) Электронный рынок MOON Сервис провайдеры Цель WSMO Интерфейс выполнения Возможность Т о ч к а д о с т у п а Встраивание Семантика выполнения Поиск WS Выбор Оркестровка Серверные системы Blue Посредник Серверные системы Miller Описание публикации Racer сервис Miller сервис Т о ч к а д о с т у п а WS Описание Возможность Интерфейс с запаздыванием Интерфейс с запаздыванием Репозиторий 1 а 3 b Выбор от L Запуск G, S 2 2 Встраивание WS 3 Інтелектуальні інформаційні системи 72 Инженеры, представляющие поль- зователей и поставщиков сервисов, ис- пользуют модели WSMO для моде- лирования сервисов и запросов к сервисам, так же используются различные онтологии и различные описания хореографии. В ча- стности, «Blue» посылает запрос и ожида- ет получения ответа согласно спе- цификации RosettaNet PIP3A4. С другой стороны, «Mueller» для того, чтобы обра- ботать запрос должен выполнять большое число взаимодействий с конечными систе- мами, например, для идентификации кли- ента в CRM, необходимо открывать заказ в OMS, добавить элементы и закрывать за- каз. Поэтому существуют проблемы функ- циональной совместимости между «Blue» и «Mueller» – «Blue» использует информа- ционную модель и хореографию, опреде- ленную PIP3A4, а «Mueller», использует информационную модель и хореографию, определенную системами CRM/OMS. Пользователи и поставщики серви- сов поддерживают интеграцию через реа- лизацию адаптеров серверных систем. Как компания «Blue», так и компания «Mueller» ответственны за поддержку этих адаптеров и их интеграцию с посред- никами через семантические описания и/или через интерфейсы с посредниками. Инженеры, представляющие поста- вщиков и пользователей сервисов соответ- ственно издают онтологии, использующие для спецификации цели WSMO и сервис- ных описаний. Кроме того, формируются правила проекции между онтологиями по- ставщиков и пользователей, онтологиями, используемыми в системе посредника. Сценарий работы представлен сле- дующим образом: все бизнес-партнеры, их модели и бизнес-сервисы используют WSMO. «Blue» посылает запрос к посред- нику системы на поставку оборудования. Запрос определяется в цели WSMO. По- средник получает цель. Семантика выпол- нения включает: поиск, выбор и оркест- ровку. Согласование сервисов для целево- го и потенциальных функциональных сер- висов выполняется на абстрактном уровне как в процессе поиска, так и на уровне об- разца. Абстрактный уровень поиска позво- ляет минимизировать число возможных согласований Веб-сервисов, которые обес- печивают заданную цель. Поиск на уровне образца осуществляет детальное согласо- вание, рассматривая как данные образца сервиса, так и цели. Выбор наилучшего сервиса («Mueller») основан на предпочте- ниях. Процесс оркестровки осуществляет выполнение переговоров между сервисами «Blue» и «Mueller», которые выполняют обработку описаний хореографии в соот- ветствии для «Blue» и сервисов «Mueller’s». 5. Представление сервиса Семантическая среда выполнения (SEE) обеспечивает декомпозицию сер- виса, которая позволяет разделить и упрос- тить сервисы, каждый из которых может иметь свою собственную структуру. Сле- дуя принципам SOA, архитектура SEE вы- деляет сервисы-посредники таким обра- зом, отделяя описания сервисов и их ин- терфейсы от выполнения. Такое разде- ление обеспечивает гибкость и масштаби- руемость при модернизации или замене функциональности сервисов посредников, которые используют заданные интер- фейсы. Сервисы обеспечивают требуемую функциональность для определенной цели. Сервисная ориентация разрешает горизон- тальное представление сервисов, кроме того отличают сервисы нескольких типов. По типу функциональности различаем два вида сервисов: • бизнес сервисы, представляющие собой сервисы, которые обеспечиваются различными серверными системами по- ставщиков сервисов. Бизнес-сервисы яв- ляются предметом интеграции и взаимо- действия в пределах архитектуры и могут обеспечивать требуемое значение для пользователей. В архитектуре, бизнес- сервисы публикуют поставщики сервисов путем формирования семантических опи- саний, согласованных с моделью WSMO. Бизнес-сервисы издаются и содержатся в хранилищах посредников; • сервисы-посредники представ- ляют собой вспомогательные средства для интеграции и взаимодействия бизнес- сервисов. Сервисы-посредники встраи- Інтелектуальні інформаційні системи 73 ваются в систему-посредник. На уровне абстракции бизнес- сервисов различают следующие два вида сервисов: • Веб-сервисы, представляющие собой общие сервисы, имеющие несколько форм и, которые далее могут конкре- тизироваться (например, приобретают би- лет на рейс); • сервисы, представляющие собой фактические образцы Веб-сервисов и, ко- торые обеспечивают конкретное значение для пользователей (например, приобрета- ют билет на рейс компании «Аэросвит» из Киева до Нью-Йорка). 5.1. Сервисы-посредники реали- зуют общую или частичную концеп- туальную функциональность посредника. Эти сервисы отражают среду реализации SEE посредника WSMX. Сервисы- посредники могут комбинироваться с про- цессами посредника, которые обеспе- чивают дополнительную функциональ- ность системы. Основными сервисами- посредниками в WSMO являются: Ядро можно рассматривать как сер- вис, который реализует управление вы- полнением, мониторинг, отработку оши- бок и формальные языки концептуального моделирования посредника. Ядро, реали- зующее коммуникацию и координацию процессов посредника определяется се- мантикой выполнения, которая определяет взаимодействие различных сервисов- посредников, обслуживающие процесс по- средника для заданной цели. Каждый про- цесс посредника запускается через внеш- ний интерфейс сервисом коммуникации и связан через другие внешние интерфейсы асинхронной связью в процессе взаимо- действия с посредником. В посреднике может существовать несколько семантик выполнения, которые обеспечивают про- цессы моделирования, создания, разверты- вания и управления, сокращая время раз- работки. Ядро посредника осуществляет также поддержку формального языка – анализатора, реализующий семантические сообщения в объектной модели WSMO4J [16]. Кроме того, ядро осуществляет рас- пределенные действия посредника, позво- ляющие взаимодействие с множеством фи- зических машин, используя общее про- странство сообщений. Разделение области сообщений обеспечивает абстракцию за- проса для распределенной архитектуры, которая обеспечивает масштабируемость процессов интеграции. Коммуникационный сервис реали- зует коммуникацию и Граундинг на уров- не концептуальной функциональности по- средника. Любое сообщение направлено или послано от посредника системы пере- дается через этот компонент. Интеграция семантических Веб-сервисов в системе осуществляется посредством сообщений, сопровождающих семантические описания данных в соответствии с моделью WSMO. Механизм, используемый для запуска сер- висов, основан на SOAP и WSDL спе- цификациях. Поэтому, компонент комму- никации также реализует механизмы для семантик Граундинга уровня WSMO и фи- зического уровня запуска сервисов. Сервис рассуждений реализует функциональность рассуждений в посред- нике. Он обеспечивает поддержку рассуж- дений над семантическими описаниями ресурсов. Рассуждение представляет собой важную функциональность, которая тре- буется в процессе выполнения, например, поиск, посредничество для данных, посредничество для процессов и т.п. К рассуждениям применяются различные требования, которые основаны на варианте языка WSML, используемого для семан- тических описаний. В основе рассуждений положена дескриптивная логика, которая нужна для того, чтобы использовать вари- анты языка WSML, язык Datalog или F- logic, положенные в основу рассуждений, когда используется WSML-flight или WSML-rule соответственно. Исполь- зование различных средств для рассуж- дений зависит от связи приложений и пол- ноты используемых семантических описа- ний в моделировании. Компонент рассуж- дений в дополнении к существующим рас- суждениям (WSML2Reasoner [17]) предла- гает универсальный уровень, который соответствует упомянутым требованиям. В зависимости от варианта WSML, запросы передаются машине рассуждений в про- зрачной форме. Рассуждения для WSML Інтелектуальні інформаційні системи 74 работоспособны также в WSML WG [18]. Сервис хранения обеспечивает хра- нение и управление различных объектов, в том числе целей, сервисов, онтологий и посредников (схемы правил). Все объекты описываются с использованием семан- тического языка WSML. Посредники данных. Посредник данных реализует концептуальную функ- циональность уровня посредника, которая помогает реализовать выполнение про- цессса, в случае если используются раз- личные онтологии при описании сервисов. Также он используется в процессе поиска сервисов в соответствии с запросами целей и сервисами, которые удовлетворяют це- лям или требуются в процессе переговоров между запросами и провайдерами серви- сов. Описания сервисных интерфейсов мо- гут использовать различные онтологии. Посредничество данных действует в соответствии со схемой правил между онтологиями, которые предварительно должны быть опубликованы в архитектуре перед тем, как реализуется посредни- чество. Эти правила должны быть созданы на этапе проектирования как часть средств управления онтологиями WSMT. Деталь- ное описание посредника данных для се- мантических Веб-сервисов рассма- тривается в [4]. Процессы посредника (медиатора) реализуют функциональность уровня по- средника. При реализации посредника ис- пользуются различные интерфейсы хорео- графии, определенные в описаниях серви- сов, которые используются в переговорах. Процессы-посредники применяются вме- сте с хореографией, медиатором данных и компонентами коммуникации, на этапе связи заказчика и поставщика сервиса. Пу- тем анализа процесса посредник решает возможные конфликты хореографии, в том числе остановки сообщения, в случае ко- гда сообщение не нужно для какой-либо хореографии, и в случае когда сообщения должны обмениваться в определенном по- рядке обеими сторонами и т.п. Детальная информация о концептуальном определе- нии процесса посредника и конфликтов хореографии рассматривается в [5]. Усовершенствование цели предста- вляет собой процесс создания абстрактной цели на основе конкретной цели. Абстрак- тная цель не содержит данных образца. Данные образца обеспечиваются отдельно из определения цели синхронно или асин- хронно, тогда как конкретная цель непо- средственно содержит встроенные данные образца, как часть определения WSMO. Например, WSMO конкретизирует цель, которая может содержать аксиоматику в форме ?x[namehasValue “HarryPotter"] memberOf book, тогда как абстрактная цель содержит аксиоматику в форме ?x memberOf book, где образец book (книга) указывается отдельно от определения цели. Поиск Веб-сервисов представляет собой процесс поиска сервисов, удовлет- воряющих требованиям заказчиков. Существуют несколько теоретико-мно- жественных отношений между описа- ниями сервисов, например, точное соот- ветствие, встроенное соответствие, пред- полагаемое соответствие, разделяемое со- ответствие и дизъюнктивное соответствие. Детальная информация о поиске Веб- сервисов в WSMO рассматривается в [6]. Поиск сервиса представляет собой процесс поиска сервиса, удовлетво- ряющего цели пользователя. Сервис согла- сованный на абстрактном уровне, согласо- вывается на уровне образца, в случае когда была бы получена дополнительная инфор- мация от поставщика сервисов, например, цена или пригодность продукта. Такая ин- формация обычно имеет динамические ха- рактеристики и не подходит для статиче- ских характеристик описания онтологии. Для этой цели выполняется взаимодейст- вие с запаздыванием. Детальная информа- ция о поиске сервисов в WSMO рассмот- рена в [7]. Выбор сервиса представляет собой процесс, в котором осуществляется выбор одного сервиса из множества сервисов- кандидатов, полученных в результате вы- полнения операции поиска, который луч- ше всего удовлетворяет пользовательским предпочтениям. Критерием выбора явля- ются различные не функциональные свой- ства, например, уровневые соглашения сервиса (SLA), качество сервиса (QOS) и Інтелектуальні інформаційні системи 75 т.п. которые могут выражать пользова- тельские предпочтения в виде не функ- циональных свойств описания цели. Де- тальная информация о выборе сервисов в WSMO рассматривается в [8]. Оркестровка. Процесс оркестровки осуществляет динамические переговоры между заказчиком и поставщиком серви- сов, обрабатывая интерфейсы хорео- графии. Оркестровка использует процессы взаимодействия с посредником и коммуни- кацию сервисов, которые вызываются ка- ждый раз при обмене сообщениями между заказчиком и поставщиком сервиса. 5.2. Бизнес-сервисы содержат спе- цификацию функциональности серверных (back-end) систем, которые описаны сред- ствами WSMO. Описание бизнес-сервисов издаются и сохраняются в хранилищах по- средника и управляются в посреднике как во время разработки (при создании серви- са), так и во время выполнения (связыва- ние с запаздыванием и выполнение серви- сов). Важным аспектом фазы создания сервисов является семантическое модели- рование бизнес-сервисов, которые опреде- ляются на следующих уровнях. Концептуальный уровень содержит спецификацию источников информации, которая используется для моделирования бизнес-сервисов. Эта информация пред- ставляет проблемно-зависимую часть, на- пример, схемы базы данных, стандарты сообщений, B2B стандарты или различные классификаторы для классификации про- мышленных объектов [15]. Информаия на- следуется из бизнес-процессов органи- зации, существующих стандартов, исполь- зуемых систем или существующие специи- фикации организационных систем (напри- мер, системы планирования ресурсов предприятия). Логический уровень представляет собой семантическую модель бизнес-про- цессов на различных стадиях выполнения. Для этой цели используем сервисную мо- дель WSMO вместе с языком семанти- ческой разметки WSML. WSMO опреде- ляет семантику сервисов, в том числе не- функциональные свойства, функцио- нальные свойства, интерфейсы (опреде- ляющие поведение) и онтологии, которые определяют информационные модели сер- висов. Кроме того обеспечивается Граун- динг от семантических описаний WSMO к WSDL и XML. Так же должны быть опре- делены схемы для запуска сервисов. Физический уровень представляет физическое окружение, используемое для запуска сервисов. Для этого используются WSDL и SOAP спецификации. Должен быть определен Граундинг между семан- тическими описаниями сервисов и WSDL. Такое определение Граундинга может быть представлено в описаниях WSMO на уровне интерфейса сервисов или описаний WSDL, используя подход семантических аннотаций для WSDL (SAWSDL) [13]. Оп- ределение Граундинга зависит от подхода моделирования. Семантическое моделирование биз- нес-сервисов использует сервисную мо- дель WSMO и дополнительную проб- лемно-зависимую информацию. Важным аспектом фазы моделирования является переход от семантического описания сер- виса (логический уровень) WSMO к WSDL описаниям (физический уровень). В WSMO Граундинг определяется для: • интерфейса сервиса WSMO и со- общений WSDL. Этот вид Граундинга конкретизирует ссылки для каждого ис- пользуемого понятия в интерфейсе сервиса к входным или выходным сообщениям, использованных в WSDL. • WSMO онтологии и схемы XML. Этот вид Граундинга конкретизирует схе- му подъема и понижения, определяющую проекцию схем XML и онтологий для того, чтобы выполнять преобразования образца в процессе запуска сервисов. Среди уровней моделирования се- мантических бизнес-сервисов отличают два подхода: нисходящий и восходящий. Нисходящий подход. В этом под- ходе явно не существует представления сервиса в WSDL и, поэтому его нужно создать на этапе создания/моделирования сервиса. В данном случае сервисы проек- тируются таким образом, чтобы они могли обработать семантические описания онто- логий и сервисов. Для Граундинга первого типа используются ссылки на понятия сер- виса, которые определяются в интерфейсе Інтелектуальні інформаційні системи 76 WSDL, его входных и выходных сообще- ний. Определение Граундинга второго ти- па связано с реализацией сервиса непо- средственно. Семантические сообщения передаются сервису, в котором выполняет- ся понижение. Обратно, подъем выполня- ется в сервисе для онтологии и передается посреднику, в котором выполняется обра- ботка согласно семантики выполнения. Информация о Граундинге WSMO рас- смотрена в [19]. Восходящий подход. В этом под- ходе предполагается, что существует ос- новное представление сервиса в WSDL. Определение Граундинга определяется та- ким же образом, как в нисходящем подхо- де. Однако, существуют отличия для опре- деления Граундинга второго типа. К опи- саниям WSDL прилагается схема, исполь- зующая спецификации SAWSDL. В ре- зультате понижения создается схема XML, которая передается согласно опреде- ленному интерфейсу Граундинга. В ре- зультате подъема создаются образцы он- тологии, которые используются для после- дующего выполнения посредником. Ин- формация о WSMO, Граудинге и исполь- зовании SAWSDL рассматривается в [20]. 6. Технология управления выпол- нением сервисов Управление выполнением сервиса- ми осуществляет ядро посредника, исполь- зующее JMX-расширений Java [21]. Вы- полнение сервисов соответствует трем главным функциональным требованиям: управление, коммуникация и координация, обработка семантики. 6.1. Управление. Мы делаем стро- гое разделение между операционной логи- кой и логикой управления, рассматривая их как ортогональные понятия. Ядро сис- темы управления представляет агент управления, который предлагает несколько сервисов. Основным является сервис на- чальной загрузки, который отвечает за конфигурирование функциональных ком- понент. Агент управления встраивается непосредственно в приложение. Сервис реализации управления использует методы управления через планируемые действия, и позволяет администрировать независимое управление и контролируемый интерфейс. Через этот интерфейс для каждой цели сервиса связываются ряд консолей управ- ления. В частности, поддерживается управление через терминальный интер- фейс, Веб браузер и Эклипс. Управление выполнением сервисов также используют виртуальный инстру- ментарий, чтобы управлять производи- тельностью системы и метрикой повыше- ния производительности. Может использо- ваться общая метрика для всех компо- нентов, можно использовать метрику к не- которым компонентам. Принципы управления выполне- нием сервисов распределенной архитек- туры служит средством для распределения компонентов. Однако, предпочитаемый путь к распределению состоит в органи- зации системы как федерации агентов. Каждый агент имеет свой собственный сервис управления выполнением и под- множество функциональных компонентов. Для того, чтобы скрыть сложность феде- рации по управлению приложением, обес- печивается единый тип агента, т.е. единая точка доступа к управлению и единые ин- терфейсы администрирования. 6.2. Коммуникация и координа- ция. Коммуникация основана на событиях в пределах посредника. В соответствии с [9], обмен сообщениями выполняется че- рез кортежи, которые обеспечивает общее пространство, разрешающее взаимодейст- вие между компонентами без прямого об- мена. Это взаимодействие выполняется путем использования механизма «издание- абонирование». Пространство кортежей разрешает коммуникацию между распре- деленными компонентами, выполняющи- мися как на локальных, так и на удаленных машинах. Технология пространства кортежей, используемая в посреднике, основана на подходе, рассмотренном в [10], в котором компоненты опубликованы и выполнена подписка на кортежи. Пространство управления передачи данных обеспечивает синхронизацию и устойчивость процесса. Пространство кортежа может быть компо- зитным, состоящим из множества распре- деленных и синхронизированных Інтелектуальні інформаційні системи 77 хранилищ кортежей. Инфраструктура коммуникации взаимодействует с транспортным уровнем. Через транспортный уровень, компонент подписывается на определенный тип со- бытия. Подобный механизм применяется, когда события опубликованы. 6.3. Семантика выполнения раз- решает выполнение функциональных ком- понентов, определяет логику посредника, которая реализует поведение проме- жуточного уровня. Управление выполне- нием сервиса обеспечивается структурой, которая позволяет выполнять семантику на множестве компонентов с множеством выполнений. В частности, управление вы- полнением сервисов обеспечивает жиз- ненный цикл семантики выполнения, управления и мониторинга. Выполнение основанное на определении семантики бу- дет использовать и производить опре- деленные виды событий. Одна оболочка инициирует событие с некоторым содер- жимым сообщения, а другая – потребляет это событие и реагирует на него. Заключение Семантическая сервис-ориентиро- ванная архитектура, рассмотренная в этой работе представляет новый подход к инте- грации и взаимодействия сервисов с по- мощью семантических языков и семан- тических моделей сервисов. Надстраивая онтологию Веб-сервиса и принимая во внимание принципы управления серви- сами, семантическое моделирование и проблемы принятия решений, архитектура обеспечивает средства частичной автома- тизации задач, например, поиск, посред- ничество, выбор и выполнение семанти- ческих Веб-сервисов. Важным аспектом, такой основы является интеграция, кото- рая основана на цели, поиске и запуске се- мантических сервисов, когда пользователи описывают запросы как цели независимо от сервисов, архитектура обеспечивает достижение цели с помощью логического рассуждения над семантическими описа- ниями. Пользователю не нужно быть осве- домленным в обработке логики, а забо- титься только о результате и его желатель- ном качестве. Основные принципы подхода состоят в том, что архитектура опреде- ляется от нескольких перспектив, пред- ставляя глобальный, сервисный, обрабаты- вающий вид и вид технологии. Глобаль- ный вид идентифицирует несколько уров- ней архитектуры, в том числе совместное использование ресурсов, проблемы приня- тия решений, заказчики сервисов, посред- ники и поставщики сервисов. Ядро архи- тектуры представлено на уровне посред- ника, для которого определена концепту- альная функциональность. Сервисная пер- спектива архитектуры определяет типы сервисов как промежуточные, так и биз- нес-сервисы, каждый тип сервисов обеспе- чивает спецификацию характеристик, сер- висы посредники осуществляют функцио- нальность посредника, а бизнес-сервисы могут моделироваться на основе семанти- ческой модели WSMO. Технология основана на посредни- честве, которое следует за распределен- ным принципом и обеспечивает поддерж- ку распределенного управления, коммуни- кации и координации процессов посред- ника. Один из главных аспектов архи- тектуры состоит в обеспечении гибкой ин- теграции сервисов, которая адаптивна к изменениям в бизнес требованиях. Обес- печивается способность к адаптации и из- менениям в серверных системах путем из- менений семантических описаний серви- сов. Конечная цель архитектуры в нашей работе состоит в определении уровня, в котором архитектуру можно адаптировать без изменений в коде и конфигурации. Адаптация будет исключительно основана на рассуждениях над семантическими опи- саниями сервисов, моделировании и свя- зывании. Предложенное расширение ре- шения направлено на покрытие боль- шинства стандартов B2B и объединении инфраструктуры, например, управление политиками, гарантия качества сервисов и т.п. В качестве цели возможно использо- вать дополнительные сценарии интеграции B2B, сосредотачиваясь на динамической композиции сервисов, которые расширяют функциональность сервисов посредника по обработке ошибок, безопасности, оркест- ровки и т.п. Інтелектуальні інформаційні системи 78 1. Андон П.І., Дерецький В.О. Проблеми ком- позиції сервісів в семантичному Web сере- довищі // Матеріали Міжнар. конф. «50 ро- ків Інституту кібернетики імені В.М. Глушкова НАН України». − К.; 24–26 гру- дня 2007. − К.; 2008. − С. 40−53. 2. Андон П., Дерецкий В. Проблеми пос- троения сервис-ориентированых приклад- ных информационных систем в Semantic Web среде на основе агентного подхода // Проблеми програмування. − 2006. − № 2-3. − C. 493–502. 3. http://www.sws-challenge.org 4. http://www.wsmx.org 5. http://kmi.open.ac.uk/projects/irs 6. http://www.gotdotnet.ru/blogs/bezzus/1211/ 7. Roman D., Keller U., Lausen et al. Web Ser- vice Modeling Ontology // Applied Ontolo- gies. – 2005. – P. 77–106. 8. Martin D. et al. Owl-s: Semantic markup for web services, version 1.1 available at http://www.daml.org/services/owl-s/1.1/. Member submission, W3C 2004. available from: http://www.w3.org/Submission/OWL-/ 9. Patil A., Oundhakar S., Sheth A., Verma K. Semantic Web Services: Meteor-SWeb Ser- vice Annotation Framework // In: 13th Inter- national Conf. on World Wide Web. –2004. – P. 553–562. 10. http://www.wsmo.org/wsml 11. Cimpian E., Mocan A. Wsmx process media- tion based on choreographies // In: Business Process Management Workshops. – 2005. – P. 130–143. 12. http://www.wsmo.org/TR/d24/d24.2/ 13. http://www.sws-challenge.org 14. Дерецкий В., Богданова M., Горошанский С. Подход к разработке программных при- ложений с использованием семантических Веб-сервисов // Проблеми програмування. − 2009. − № 4. − C. 59–70. 15. http://www.rosettanet.org 16. http://wsmo4j.sourceforge.net 17. http://tools.deri.org/wsml2reasoner 18. Web Service Modeling Toolkit. http://sourceforge.net/projects/wsmt 19. Kopeck´y J., Roman D., Moran M., Fensel D. Semantic web services grounding // In: AICT/ICIW. – 2006. – P.127. 20. http://www.w3.org/ws/sawsdl/ 21. Haselwanter, Thomas WSMX Core - A JMX Microkernel // PhD thesis, University of Inns- bruck. – 2005. Получено 04.12.2009 Об авторе: Дерецкий Валентин Александрович, кандидат физико-математических наук, ведущий научный сотрудник. Место работы автора: Институт программных систем НАН Украины. 03187, Киев-187, Проспект Академика Глушкова, 40. Тел.: 38 044 526 4342. e-mail: dva@isofts.kiev.ua.

Development of applications in service-oriented architecture of Semantic Web

Репозитарії

Схожі ресурси