Содержание к диссертации
Введение
Глава 1. Методы описания семантики в глобальной телекомуникационной сети
1.1. Введение в описание семантики и логики телекоммуникационных сетей 9
1.2. Основные спецификации для представления информационных ресурсов в глобальной сети 18
1.3. Инструментальные средства разработки для DAML+OIL 25
1.4. Постановка задачи исследования 28
Выводы 38
Глава 2. Разработка алгоритма обнаружения семантического web-сервиса в сети 40
2.1. Разработка алгоритма обнаружения 40
2.2. Разработка алгоритма сопоставления входных параметров 44
2.3. Разработка алгоритма сопоставления выходных параметров . 51
2.4. Разработка алгоритма сопоставления профиля 58
2.5. Разработка алгоритма сопоставления определенным пользователем 61
2.6. Результаты обнаружения Web-сервиса 64
Выводы 67
Глава 3. Архитектура и реализация системы обнаружения семантического web-сервиса в глобальной сети 68
3.1. Разработка архитектуры системы поиска семантического Web-сервиса в распределенной информационной системе 68
3.1.1. Автоматическое обнаружение описания DAML-S 70
3.1.2. Комплексирование алгоритма сопоставления и реестр UDDI 72
3.2. Система контроля над версиями Web-сервисов 76
3.3. Автоматическое отображение OWL документов на языке программирования Java 87
3.3.1. Разработка отображения OWL документов на языке JAVA 89
3.4. Экспериментальный анализ разработанный системы 98
3.4.1. Точность выполнения алгоритма сопоставления 99
3.4.2. Анализ времени выполнения семантического сопоставления 100
Выводы 103
Заключение 104
Приложение 105
П. 1. Исходные коды алгоритмов сопоставления 105
П.2. Исходные коды типов данных реестр UDDI 107
П.З. Акт внедрения результатов работы 115
Принятые в тексте сокращения 118
Список литературы
- Основные спецификации для представления информационных ресурсов в глобальной сети
- Постановка задачи исследования
- Разработка алгоритма сопоставления выходных параметров
- Комплексирование алгоритма сопоставления и реестр UDDI
Введение к работе
Бурное развитие глобальной сети Интернет привело к тому, что ее информационное наполнение стало не только громадным по объему, но и очень разнообразным. В 2007 году отмечается 16 лет World Wide Web. В течение этих пятнадцати лет существующая сеть web представляет собой гигантское количество информации в формате, приспособленном для человеческого восприятия. Пользователь может переходить с одной ссылки на другую, давать запросы различным поисковым системам или же находить сайты, просто вводя их адреса. И хотя Web-страницы весьма привлекательны для человека, для компьютерной программы же, обрабатывающей их содержимое, они не более чем строчки из случайных символов.
В марте 1989 года, сотрудник Европейской лаборатории физики элементарных частиц (CERN) в Женеве, обратился к руководству CERN с идеей создания распределенной информационной системы для обмена результатами исследований между учеными, находящимися в разных учреждениях и разных странах. Проект "World Wide Web: Proposal for Hypertext Project" [1] предложил объединить все информационные ресурсы CERN в систему, которая бы позволила легко переходить от одного документа к другому посредством гиперссылок.
Универсальная система URL-адресов и технология гипертекста в сочетании с поисковыми программами образовали среду, где информация не только передается, но и интеллектуально обрабатывается. Под интеллектуальной обработкой имеется в виду не просто техническое преобразование информации (например, шифрование), а такие процессы, которые аналогичны человеческому мышлению. Например, автоматизированное собирание объектов в множества по определенным признакам, установление отношений между этими множествами (распознавание образов) и т.п. Несколько лет назад математик Дмитрий Манин придумал для описания этих механизмов забавный термин "платонова метрика" - своего рода "расстояние между идеями". В Сети Платонова метрика заменяет метрику Евклида. Физическое расстояние между двумя серверами может быть огромно, но если оба сайта посвящены, например, кошкам, то при наборе слова "кошка" в поисковой системе эти сайты окажутся очень близки по идее - как две гиперссылки, стоящие на одной странице [2].
Компьютерная программа не способна загрузить произвольный документ, будь то Web-страница или какой-то файл, понять его содержание. Она, конечно, может сделать некие догадки, основываясь на HTML- или XML-тэгах, но всё равно требуется человек-программист, который должен разобраться в них и понять смысл, или семантику, каждого из тэгов. С точки зрения компьютера, существующая Сеть WWW — это полная неразбериха. К счастью, выход есть - это Семантическая Сеть.
Семантическая Сеть должна стать неким дополнением сети WWW, состоящим из понятной машинам информации. Реализация этой новой сети станет, возможна благодаря ряду новых стандартов, разрабатываемых WWW-Консорциумом (W3C) [3]. Когда Семантическая Сеть наберёт обороты, значительное число информационных ресурсов будут пригодными для использования как человеком, так и программными агентами. Другими словами, программные приложения наконец-то научаться читать Internet.
Подобно тому, как Семантическая Сеть является расширением обычной сети WWW, Семантические Web-сервисы расширяют понятие обычных Web-сервисов (рис. 1). Идея Web-сервисов была разработана такими гигантами компьютерной индустрии как Sun, Oracle, HP, Microsoft и IBM. В этой идее ничего нового, но это большой шаг вперед к упрощенному доступу к программам через сеть.
Web-сервис [4] - это методы и данные, предоставляемые для использования внешними приложениями, которые работают с сервисами посредством стандартных протоколов и форматов данных. Web-сервисы полностью независимы от языка и платформы реализации [4]. Web-сервис,
2. Разработана архитектура информационной системы поиска семантического Web-сервиса на основе алгоритма сопоставления.
3. Разработана система контроля над версиями Web-сервисов, предоставлены шаблоны решения проблем, возникающих при выпуске новых версий Web-сервисов.
Методы исследования опираются на результаты дискретной математики, теории объектно-ориентированного проектирования, шаблонное проектирование и методами математического моделирования.
Научная новизна работы заключаются в следующем:
1. Разработан алгоритм сопоставления для обнаружения семантического Web-сервиса.
2. Построена модель архитектуры информационной системы для использования алгоритма сопоставления.
3. Разработан информационный реестр для публикации семантических Web-сервисов.
4. Решена задача контроля над версиями Web-сервисов в реестре UDDI.
Практическая ценность полученных в работе результатов заключается в следующем:
1. Разработанные алгоритмы сопоставления увеличивают эффективность семантического поиска для обнаружения Web-сервисов.
2. Имеется принципиальная возможность использования разработанной модели архитектуры для автоматического обнаружения и композиции Web-сервисов.
3. Результаты исследования контроль над версиями Web-сервисов можно использовать в любом информационном реестре для упрощения задачи контроля над версиями Web-сервисов.
4. Разработанный реестр может быть использован в качестве замены других коммерческих информационных реестров семантических Web-сервисов, что может повысить эффективность поиска различных сервисов.
На защиту выносятся следующие основные положения:
1. Алгоритм сопоставления Web-сервисов для обнаружения семантического Web-сервиса.
2. Модель архитектуры информационных систем для обнаружения и композиции семантических Web-сервисов.
3. Алгоритм контроля над различными версиями Web-сервисов.
4. Алгоритм предоставления онтологии в интерфейсе Java. Публикации и апробация диссертационной работы.
По материалам диссертации опубликовано 1 статья, 8 тезисов докладов и свидетельство на программный продукт. Доклады сделаны на международных научно-технических конференциях (Международной научно-технической конференция "Новые методологии проектирования изделий микроэлектроники", Владимир, 2004; Международной научно-технической конференции "Перспективные технологии в средствах передачи информации - ПТСПИ", Владимир, 2005; Международной конференции "IV международной технической конференции, 14-18 ноября 2006, МИРЭА", г. Москва, 2006; XII Всероссийская научно - техническая конференция "студентов, молодых ученых и специалистов НИТ - 2007", Рязань. 2007; Восьмая Международная научно - техническая конференция "Измерение, контроль, информатизация ИКИ - 2007", г. Барнаул. 2007), научно-технических советах ООО "Форс-центр разработки" и других предприятий отрасли.
Авторские права на созданные диссертантом программные комплексы оформлены в виде авторского свидетельства на программный продукт [136]. Внедрение результатов исследования.
Результаты диссертационной работы использованы в виде рекомендаций при построении архитектуры автоматизирований системы в проекте АС "Обеспечение" фирмы «Форс-центр разработки» а также при активном участии автора разработан и построен в фирме «Трейд виза» реестр «CUDDI» семантических Web-сервисов.
Основные спецификации для представления информационных ресурсов в глобальной сети
Онтология получила достаточно широкое распространение в задачах представления знаний и инженерии знаний, семантической интеграции информационных ресурсов, информационного поиска и т.д. В науке об «искусственном интеллекте» [26], онтология - это "спецификация концептуализации предметной области", или упрощенно, документ или файл, формально задающий отношения между терминами. Это своего рода словарь понятий предметной области и совокупность, явным образом, выраженных предположений относительно смысла этих понятий.
Чаще всего онтология представляется как иерархия понятий, связанных отношениями некоторых определенных видов. Такие определения онтологии используются в различных классификациях [26]. Развитые онтологии формализуются средствами языков логики и допускают возможности логического вывода.
В простейшем случае онтологии можно использовать для повышения точности поиска [26] в сети, поисковая система будет выдавать только такие сайты, где упоминается в точности искомое понятие, а не произвольные страницы, в тексте которых встретилось заданное ключевое слово.
Общеизвестно, что в различных предметных областях, одни и те же понятия могут быть представлены разными терминами. Механизм онтологии в этих случаях позволяет формировать осмысленные иерархические [27] взаимосвязи между объектами, т.е. реализовать нечеткий поиск, способно находить даже такие необходимые пользовательские ресурсы, в которых не будут ни одного слова из исходного запроса.
Предполагается [27], что "интеллектуальные" приложения будут использовать онтологии, чтобы получаемую в результате поиска информацию со связанной с ней структурой знаний и правилами вывода. Механизмы поиска могут применять онтологии для выборки страниц с синтаксически различными, но семантически одинаковыми словами. Онтологии также могут использоваться для организации обмена данными и интеграции программ.
Такая интеллектуальная программа, интерпретирующая онтологии [27] сможет вывести, например, если Корнельский Университет находится в городе Итаке, который расположен в штате Нью-Йорк, который, в свою очередь, есть часть США, то адрес этого университета следует писать в американском формате.
Разработка «язык описания структурированных онтологии OWL» [28] стало в последнее время одним из наиболее важных звеньев работ по семантическому Web, проводимых консорциумом W3C. Формальная семантика OWL описывает, как получить логические выводы на основе онтологии, т. е. получить факты, которые не представлены буквально, а следуют из семантики онтологии. Эти выводы [28] могут базироваться на анализе одного документа или множества документов, распределенных в сети. Последнее обеспечивается возможностью онтологии быть связанными, включая прямой импорт информации из других онтологии. Чтобы написать онтологию, которая может однозначно интерпретироваться и использоваться программными агентами, задействуются синтаксис и формальная семантика OWL [29].
На практике, создание онтологии начинается с иерархии классов понятий [29], составляющих предметную область. Фундаментальным таксономическим конструктором [30] для классов является rdfs:subClassOf. Он связывает более частный класс с более общим классом. Если X - подкласс Y, то каждый представитель X - также представитель Y. Отношение rdfs:subClassOf является транзитивным. Если X - подкласс Y, и Y - подкласс Z, то X - подкласс Z. Ниже приведены описания классов и подклассов, заимствованные из рекомендаций W3C и связанные с предметной областью -виноделием.
Постановка задачи исследования
Цель работы заключается в разработке механизма, который поможет выбрать подходящий семантически Web-сервис в оркестровке Web-сервисов. Алгоритмы, разработанные, для решения поставленной задачи будут выбирать Web-сервис на базе доступной семантической информации, закодированной в DAML-S. В результате будет определено ранжирование для совместимости Web-сервиса и запрошенных потребностей. Маловероятно, что существует Web-сервис, который может обеспечить решение запроса пользователя. На основе ранжирования, компьютерные программы или клиенты могут решать сами, использовать ли найденные Web-сервисы, или нет, то есть, соответствуют ли они требованиям запроса. Этот механизм является сочетающимся алгоритмом.
Рассмотрим проблему обнаружения семантического Web-сервиса. Для решения этой задачи требуется язык, который позволил бы отображать возможности Web-сервиса.
Принимается DAML-S [54] как язык описания сервиса, поскольку он обеспечивает семантическое описание, которое распределяется от абстрактного описания возможностей сервиса до протокола взаимодействия в обмене сообщениями с другими сервисами.
DAML-S имеет способности для описания семантики Web-сервиса на основе XML стандарта. Стандарты, например, как SOAP и WSDL предназначены для обеспечения описание механизмов транспортировки сообщения, а также для описания интерфейса каждого Web-сервиса. Тем не менее, ни SOAP и ни WSDL не способны для автоматического обнаружения сервиса на основе их возможностей. Другой стандарт на основе XML - это UDDI [55]; он обеспечивает регистрацию предприятий и Web-сервисов. UDDI описывает предприятие их физическими атрибутами как, например, название, адрес и сервисы, которые они обеспечивают и т. д. Кроме того, описание UDDI располагает набором атрибутов под названием TModels [55], которые описывают дополнительные характеристики, такие как, например, классификация сервиса в пределах таксономии, например, NAICS [56]. Поскольку UDDI не предоставляет возможности сервиса, он не играет никакой роли в поиске Web-сервиса на основе их возможности.
Ограничения на базе стандартов XML, рассмотренные выше, являются недостатком описания явной семантики: два идентичных описания XML могут означать весьма разные вещи в зависимости от контекста их использования. Это оказывается [57] основным ограничением для сопоставления способности сервиса. Фактически, этот критический аспект не способен составить запрос на семантическом уровне. Это является причиной невыполнения запроса, поскольку запрашивающая сторона не знает, какие услуги будут приведены. В противном случае клиент мог бы обратиться непосредственно к поставщикам сервисов за необходимой информацией. Кроме того, провайдеры и запрашивающие стороны имеют весьма разные перспективы и разное знание об одном и том же сервисе.
Нереально ожидать что, предоставляемый сервис и запрос к сервису будут одинаковы, или существует такой сервис, который точно бы выполнял потребности запрашивающей стороны. Например, сервис может представляться как сервис по поставке финансовых новостей, в это же время клиенту нужен сервис, который сообщает о прогнозе погоды. Задача сочетающегося алгоритма [58] в том, чтобы использовать семантическое описание сервиса и запроса к сервису, чтобы определить их степень несовпадения и найти ссылку на тот сервис, который более точно соответствует запросу.
Язык DAML-S поддерживает требуемую способность семантического представления сервиса через свою плотную связь с языком DAML+OIL. Язык DAML+OIL поддерживает категоризацию [59] в понятиях таксономии. Кроме того, DAML+OIL допускает определение отношений между понятиями чтобы, например, была возможность выражать следующие отношения: X - часть Y, отношение R существует между X и Y. Основным ограничением DAML+OIL является недостаток определения хорошо сформированных формул и невозможность связного доказательства теоремы [60-63].
Язык DAML-S сам по себе является онтологией, описывающий организацию Web-сервиса. Существует четыре основных класса (или понятий), а именно: Service, ServiceProJile, ServiceModel и ServiceGrounding [64].
Класс Service обеспечивает организационную точку входа для любого описания Web-сервиса. Этот класс имеет три свойства: Presents, describedBy и support. Соответственно, области этих свойств - классы ServiceProfde, ServiceModel и ServiceGrounding. Каждый экземпляр класса Service имеет свойства (это может быть любое описание Web-сервиса). Свойство presents имеет потомка класса ServiceProfile, свойство describedBy имеет потомка класса ServiceModel и свойство support имеет потомка класса ServiceGrounding. Т.е каждый экземпляр класса Service [65] представляет собой один ServiceProfile, описывается через ServiceModel и поддерживается ServiceGrounding.
Разработка алгоритма сопоставления выходных параметров
В сопоставлении выходного параметра необходимо определять насколько точно совпадают выходные параметры предоставляемого сервиса с параметрами запрошенного сервиса.
Во время сопоставления выходного параметра алгоритм пытается найти сопоставление для каждого выходного параметра запрошенного сервиса. В этом случае также используется ранжирование сопоставление-свойство и сопоставление-тип, чтобы найти отношение между двумя выходными параметрами. Тем не менее, теперь роли обновлены. Это означает, что степень Subproperty признана в том случае, когда выход предоставляемого сервиса является под свойством выхода запрошенного сервиса. Степень Subsumes выставляется каждый раз, когда тип выходного параметра запрошенного сервиса относится к категории типа выходного параметра предоставляемого сервиса.
Аналогичным образом можно определить сопоставление-свойство следующим образом: 1. Эквивалент «Equivalent». Оба выходных параметра обозначают одно и то же свойство. 2. Подсвойство «Subproperty». Выходной параметр предлагаемого сервиса является под свойством выходного параметра запрошенного сервиса. 3. Неклассифицированы «Unclassified». Выходные параметры запрошенного сервиса, либо предлагаемого сервиса не классифицированы. 4. Неудачно «Fail». Если ни одно из вышеуказанных условий не выполняются.
Степени сопоставления типа для выходных параметров следующие: 1. Эквивалент «Equivalent». Оба типа обозначают одно и то же понятие. 2. Подсвойство «Subproperty». Тип выходного параметра предлагаемого сервиса является подтипом выходного параметра запрошенного сервиса. 3. Обратное отношение «Invert Subsumes». Тип выходного параметра предлагаемого сервиса относился к общему типу выходного параметра запрошенного сервиса. 4. Неудачно «Fail». Если ни одно из вышеуказанных условий не выполняется.
Переключение порядка аргументов для сопоставления выходных параметров при использовании функции гankForPammeters позволяет использовать ранжирование, которое было определено в таблице 2.1, и получить результат сопоставления выходного параметра, как показано в таблице 2.3. Для каждого выходного параметра запрошенного сервиса алгоритм пытается найти сопоставление выходного параметра предлагаемого сервиса с самым большим рангом. Как было отмечено, эти два выходных параметра затем формируют выходную пару.
Как было показано при сопоставлении входного параметра, имеется степень PARTIAL_FAIL, когда один выходной параметр запрошенного сервиса остается несогласованным. В этом сценарии предлагаемый сервис может соответствовать некоторым выходным параметрам запрошенного сервиса, но оставляет, по крайней мере, один выходной параметр несогласованным. PARTIAL_FAIL также может оказаться полезным в определенных ситуациях. Можно рассмотреть пример, где запрашивающая сторона ищет функцию, которая обеспечивает результаты поиска книг и представляет эту информацию своим пользователям через Web. Запрашивающая сторона или клиент ожидает, что Web-сервис будет возвращать информацию о цене, авторе, названии, число ISBN и т.п. Предоставляемый сервис, который возвращает только часть этой информации, может все еще быть полезным для запрашивающей стороны, так как клиенты могут все еще найти их желаемую книгу, исходя из этой частичной информации. Листинг 2.2 показывает сочетающийся алгоритм выходного параметра в языке Java. Список reqOutParams и advOutParams представляют собой коллекции, которые содержат все выходные параметры
Комплексирование алгоритма сопоставления и реестр UDDI
С помощью автоматического обнаружения DAML-S документов, расширяется архитектура, где клиент может использовать существующие технологии, как например, UDDI и в то же время может получать информацию из семантического описания, предусмотренного DAML-S. Этот механизм проиллюстрирован на рисунке 3.3. Шаг 1: Сервис-провайдер регистрирует свой Web-сервис в реестре UDDI; Шаг 2: Сервер UDDI возвращает все найденные Web-сервисы, которые входят в конкретную категорию; Шаг 3: Сервер UDDI возвращает адреса Web-сервисов. Но они не включают семантическую информацию; Шаг 4: Клиент запрашивает семантическую информацию у провайдера сервиса с суффиксом damls; Шаг 5: Провайдер Web-сервиса возвращает семантическую информацию; Шаг 6: DAML-S затем будет соответствовать требованиям клиента. Далее клиент может решить, какой Web-сервис соответствует наилучшим образом (если соответствие существует). 3. Возвращать адрес сервиса 6. Сопоставления спецификаций по требованием Алгоритм сопоставления
Локальное подключение алгоритм сопоставления Можно рассмотреть пример, где клиент использует специфический сервис (например, котировка, прогноз погоды и т.п.). Клиент запрашивает реестр UDDI для сервиса в категории "Информационное Обслуживание" и получает все адреса зарегистрированных услуг в этой категории. Популярные сервисы, как, например, получение котировки, могут иметь свою собственную категорию, но много услуг может входить и в более общую категорию. Клиент, тем не менее, все еще может определить сервис, сочетая семантическую информацию, которую он получает непосредственно из адресов реестра UDDI.
Фундаментальное различие между этими двумя методами - это место выполнение сочетающегося алгоритма. В первой архитектуре сочетающийся алгоритм выполнен на стороне сервера. Клиент отправляет свой запрос к центральной базе данных сервера, и сервер находит соответствие между запросом и имеющимися сервисами, которые зарегистрированы в базе данных. Сервер затем возвращает адреса или информацию о сервисах. Во второй архитектуре клиент получает DAMLS-спецификации, затем локально выполняет сочетающийся алгоритм в соответствии с собственными требованиями и в конечном счете решает, какой Web-сервис вызвать.
Преимущество первого метода состоит в том, что клиенту или агенту приходится тратить меньше усилий, так как сервер выполняет весь поиск сервиса и фактическое сопоставление. Центральный сервер предоставляет легкий и удобный путь для нахождения нужного Web-сервиса. Много работы и времени может быть сохранено при использовании существующих компонентов инфраструктуры и механизмов.
Недостаток первой архитектуры в том, что клиент теряет управление над выполнением алгоритма сопоставления. Пользователь должен доверять центральному серверу в предоставлении сервиса желаемого функционального назначения. Разные серверы реализуют разные алгоритмы сопоставления и не все серверы дают возможность управлять ходом выполнения алгоритма. Это может провести к неудовлетворительным результатам. Клиент может и не получить точное сопоставление Web-сервиса из центрального сервера, хотя на сервере существует Web-сервис, который удовлетворяет всеми требованиями клиента, потому что выполненное сопоставление алгоритма не работает в желаемом алгоритме. Эта проблема решается, если сервер позволяет клиенту выбирать алгоритм сопоставления из всех существующих алгоритмов, находящихся на сервере, или управлять ходом выполнения сочетающегося алгоритма.
Достоинство локального выполнения алгоритма сопоставления состоит в том, что клиент может выбирать необходимый ему алгоритм сопоставления. В этом случае ход выполнения алгоритма сопоставления Web-сервиса может управляться параметрами. Таким образом, клиент может модифицировать функциональное назначение в соответствии со своими требованиями. Таким образом, можно достичь более точного результата, чем при использовании первой архитектуры.
Тем не менее, недостаток второго метода состоит в более сложной реализации в отличие от первой архитектуры. Это требует много времени и работы над реализацией алгоритма сопоставления и комплексированием этого приложения с реестром. Необходимо отметить, что в модернизации системы, которая использует локальное подключения алгоритма сопоставления, требуется отсоединять все системы на некоторое время.
