Веб сервисы. WSDL
Web-сервисы. В самом общем виде понятие Web-сервиса можно определить как сервис (услугу) которая предоставляется через WWW с использованием языка XML и протокола HTTP. Web-сервисы могут инкапсулировать как простейшие бизнес-функции типа «запрос-ответ», до полномасштабных взаимодействий бизнес-процессов. Службы могут создаваться заново или строиться на основе существующих приложений методом «обертывания». Свойства Web-сервисов. Все Web-сервисы обладают имеют следующими свойствами: · являются самодостаточными, т.е. с клиентской стороны не требуется никакого дополнительного программного обеспечения кроме языка программирования, поддерживающего работу с XML и HTTP, а на серверной стороне требуются только HTTP-сервер, поддерживающий работу с посланиями. · являются самоописываемыми, поскольку метаданные, описывают сообщения передается вместе с сообщением и не требуется никаких внешних хранилищ метаданных; · могут быть опубликованы, обнаружены и вызваны через Интернет причем для этого используют простые установившиеся стандарты, такие как HTTP и существующая сетевая инфраструктура; · являются модульными, т. е. простые Web-сервисы могут объединяться в более сложные, причем это может быть сделано разными способами, либо при помощи механизма рабочих процессов, либо посредством прямого вызова Web-сервисов из других реализации Web-сервисов; · инвариантны к способу реализации, т.е. клиент и сервер могут быть реализованы в разных средах с использованием разных языков программирования, причем для клиента не имеет значения на какой платформе реализован сервер и наоборот; · открыты и основаны на стандартах, технической основой Web-сервисов являются XML и HTTP, значительная часть технологии Web-сервисов создана с использованием проектов с открытым исходным кодом; · имеют свободные связи, по сравнению с другими, в частности, компонентными технологиями для Web-сервисов требуется более простой уровень координации, который позволяет осуществлять достаточно гибкую реконфигурацию для обеспечения интеграции нужных сервисов; · являются динамическими, поскольку имеется возможность обнаруживать службы в процессе функционирования, при этом имеется возможность из распространения не влияя на работу клиентов, которые их используют; · являются действенным средством интеграции унаследованных приложений. WSDL используется для описания интерфейсов Web services. Средствами WSDL можно описать, где находится Web-сервис и каким образом к нему следует обращаться. WSDL описание позволяет создавать независимое от платформы и языка реализации описание Web-сервиса. Нетрудно заметить, что WSDL имеет много общего с IDL, используемым в RPC. WSDL описание представляет собой XML документ, структура которого показана на рис. 5.2. <definitions>
</definitions>
Рис. 5.2. Структура XML документа В качестве корневого элементы WSDL описания используется элемент <definitions>, в который вкладываются семь элементов, пят из которых являются основными, а два - вспомогательными. В качестве основных выступают следующие элементы: - <types>; - <message>; - <portType>; - <binding>. В качестве вспомогательных выступают элементы: - <import>; - <documentation>. Каждый элемента имеет собственное имя, определяемое обязательным атрибутом name. Имена используются для ссылки на отдельные элементы. Элемент <types>; присутствует, если требуется определить сложные типы с помощью языка XSD. В противном случае данный элемент отсутствует. Элемент <message>; описывает каждое из SOAP посланий в терминах «запрос-ответ». В этот элемент вкладываются элементы <part>. При использовании процедурного стиля в каждый такой элемент описывается имя и тип одного аргумента запроса или возвращаемого значения. При использовании документного стиля элементы <part> могут описывать отдельную часть послания MIME-типа "multipart/related". Элемент <portType>; описывает интерфейс Web-службы, который также называют пунктом назначения (endpoint) или портом (port), сервисов, называемых операциями. Отдельные операции описываются как вложенными элементы <operation>, которая описывает отдельный сервис. Имеется 4 вида сервисов. Два простых действия (получение послания и отправка ответа) и два комбинированных действия (отправка послания — получение ответа и получение послания — отправка ответа). Действия типа получение и отправка посланий описываются вложенными элементами <input> и <output>, а также сообщением об ошибке (элемент <fault>). Элемент <serviceType>; содержит множество вложенных элементов <portType>. Один и тот же порт может быть связан с несколькими сервисами. Элемент <binding>; описывает формат пересылки послания: протоколы и его тип. Каждый элемент <message> может быть связан с несколькими такими элементами<binding>, по одному для каждого способа пересылки. Элемент <service> определяет место нахождения сервиса как один или несколько портов, каждый из которых описывается вложенным элементом <port>, содержащим адрес интерфейса Web-сервисы. Кроме перечисленных выше основных элементов есть еще два вспомогательных элемента. Элемент <import> включает файл с XSD схемой описания WSDL или другой WSDL-файл. Элемент <documentation> представляет собой комментарий, который можно включить в любой элемент описания WSDL. Принято говорить, что элементы <types>, <message> и <portType> определяют какие именно услуги предоставляет данный сервис. Элементы <binding> определяет как реализована Web-служба, т.е. как к ней обращаться. Элементы <service> определяет где располагается сервис. Ниже в качестве примера приведен фрагмент WSDL описания.
<?xml version="1.0" encoding="UTF-8"?> name="SynonymService" targetNamespace="http://www.vocab.ru/Thesaurus.wsdl" xmlns="http://www.w3.org/ns/wsdl" ........ <wsdl:definitions... <wsdl:message name="getSynonymResponse"> <wsdl:part name="synonym" type="SOAP-ENC:string"/> </wsdl:message> <wsdl:message name="getSynonymRequest"> <wsdl:part name="word" type="SOAP-ENC:string"/> </wsdl:message> <wsdl:portType name="Synonyms"> <wsdl:operation name="getSynonym" parameterOrder="word"> <wsdl:input message="intf: getSynonymRequest"/> <wsdl:output message="intf:getSynonymResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="getSynonymSoapBinding" type="intf:Thesaurus"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getSynonym"> <wsdlsoap:operation soapAction=""/> <wsdl:input> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:myDirectory" use="encoded"/> </wsdl:input> <wsdl:output> <wsdlsoap:body encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:myDirectory" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="SynonymService"> <wsdl:port binding="intf: getSynonymSoapBinding" name="Thesaurus"> <wsdlsoap:address location="http://localhost:8080/axis/services/Thesaurus"/> </wsdl:port> </wsdl:service> <documentation> Thesaurus WSDL File</documentation> </wsdl:definitions>
Предполагается, что данное описание находится в файле Thesaurus.wsdl. Имя сервиса SynonymService определено в элементе service. Далее определяются используемые пространства имен (часть определений пропущена). В элементах <wsdl:message> описаны используемые типы SOAP посланий. Используется два типа сообщений, которые называются getSynonymRespons и getSynonymReques. Первое содержит поле synonym, а второе – поле word. Оба поля представляют собой строки символов. Элемент <wsdl:portType> называется Synonyms и выполняет только одну операцию getSynonym, которая получает входную переменную word. Входное послание имеет имя getSynonymRequest, а выходное – getSynonymResponse. Элемент <wsdl:binding"> называется getSynonymSoapBinding. В нем указывается, что сервис работает в режиме запрос-ответ (использует rpc – стиль), использует в качестве транспорта протокол HTTP, работает с SOAP посланиями и выполняет операцию getSynonym. Затем в терминах SOAP повторяется описание операции getSynonym. В элементе <wsdl:service>, который называется SynonymService, указывается место нахождения сервиса. Элемент <documentation> может содержать любые комментарии. Поскольку в рассматриваемом примере не используются сложные типы, то элемент <types> отсутствует. WSDL спецификация может быть получена автоматически из файла реализации Web services, например, из Java файла или из описания интерфейса. Имеется много разных систем поддержки работы с Web services. Одной из наиболее популярных является Apache eXtensible Interaction System (AXIS). Можно выделить два альтернативных подхода к разработке Web сервисов: подход по принципу «сверху-вниз и подход «снизу-вверх». В первом случае разработка начинается с разработки WSDL описание, которое используется для генерации скелетона и стаба, затем к ним добавляется бизнес логика. Во втором случае разработка начинается с создания кода, который используется для генерации WSDL описания. Например, в рамках существующих инструментальных средств имеются утилиты для выполнения упомянутых выше преобразований [35, 36]. UDDI UDDI представляет собой техническую спецификацию, которая используется для построения распределенных репозитариев, которые позволяют отдельным организациям опуликовывать и находить требуемые сервисы. Если клиенту известно место нахождения сервиса и способа работы с ним, то надобности и UDDI реестре отпадает. Реестр UDDI (UDDI Business Registry) представляет собой распределенную базу данных и по принципу работы подобна системе DNS. Для пользователя Реестр UDDI доступен как Web сервис. Спецификация UDDI была разработана в 2000 году фирмами IBM, Microsoft и Ariba. На момент написания данной книге последняя версия 3.х (http://uddi.org/pubs/uddi_v3.htm). В начале 2000-х годов многие крупные компании организовали и содержали открытые (public) UDDI-реестры, где каждый желающий мог зарегистрировать собственный сервис и найти нужный сервис. UDDI представляет собой документ в формате XML. UDDI имеет 3-х уровневую организацию. На верхнем уровне UDDI реестр представляет собой справочник, работающий по принципу Белых страниц, которые содержат базовую информацию о бизнесе, включая название, описание и контактную информацию (телефон, факс, Web сайт и т.п.) и бизнес идентификатор. На втором уровне UDDI реестр представляет собой Желтые страницы, в которых бизнес информация классифицируется по типу бизнеса, производимым продуктам. На третьем уровне UDDI реестр можно рассматривать как Зеленые страницы, где описаны способы доступа к сервисам. Состав реестра UDDI. Реестр UDDI содержит четыре основные элемента и дополнительные элементы. Основные элементы: - бизнес сущности; - бизнес сервисы; - модель привязки; - техническая модель сервиса. Дополнительные элементы: - утверждения; - информация; - подписка. Элемент бизнес сущность <businessEntity>; содержит уникальный в пределах реестра ключ UUID (Unique Universal Identifier), название фирмы (вложенный элемент <name>), описание сферы деятельности организации, типы предоставляемых сервисов, контактная информация, ссылки URL. Небольшой организации обычно соответствует одна бизнес сущность, а большой организации, имеющей большое количество подразделений может соответствовать несколько бизнес сущностей. Элементы бизнес сервисы <businessServices>; вкладываются в элемент бизнес сущность и описывает каждый из предоставляемых сервисов. В состав описания входит ключ UUID сервиса (serviceKey), имя сервиса (вложенный элемент <name>), описание и (или) ссылки на более подробную информацию. (Предоставляемые сервисы – это не обязательно Web-сервисы.) Элементы модели привязки элемент <bindingTempiates>; вкладываются в элемент <businesService> и описывают конкретные способы работы с данным сервисом. Это могу быть либо прямые ссылки в форме URL, либо косвенными, например, в форме WSDL описания. Каждый элемент типа <bindingTempiate> имеет уникальный ключ UUID указателя содержит ссылку на соответствующий ему элемент <tModel>. Элемент техническая модель сервиса <tModel> (technical Model) представляет собой подробное формальное описание каждой услуги. Данный элемент используется программным обеспечением и обычно оформляется как отдельный документ XML. Кроме перечисленных выше, в UUID реестре имеются дополнительные элементы. Элемент утверждение <publisherAssertion>; представляет собой описание отношений между фирмами. Примерами отношений могут служить "parent-child"), т.е. одна организация является подразделением другой. Утверждение типа "identity"означает, что речь идет об одной и той же организации. Элемент информация <operationalInfo>; содержит дату создания и последней модификации записи в реестре, идентификатор узла реестра, идентификатор владельца информации. Ниже приведено описание структуры UUID реестра.
<businessDetail> <businessEntity businessKey=” [Уникальный идентификатор] ”> Имена, описания, контакты,.. <businessServices> <businessService serviceKey=” [ Уникальный идентификатор] ” businessKey=” [Уникальный идентификатор] ”> Имена, описания,.. <bindingTemplates> <bindingTemplate bindingKey=” [ Уникальный идентификатор] ” serviceKey=” [Уникальный идентификатор] ”> описания.. <accessPoint URLType=” http ”> http://www... </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo> <tModelKey> [ Уникальный идентификатор] </tModelKey> Descriptions,.. <instanceDetails> Описания, URL,.. </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> ... </bindingTemplates> <categoryBag>...<tModelKey>[ Уникальный идентификатор] </tModelKey>... </categoryBag> </businessService> ... </businessServices> <identifierBag>...<tModelKey> [Уникальный идентификатор] </tModelKey>... </identifierBag> <categoryBag>...<tModelKey> [Уникальный идентификатор] </tModelKey>...</categoryBag> </businessEntity> ... </businessDetail>
Программный интерфейс UDDI. Для работы с реестром UDDI пользователю предоставляется API. Функции, входящие в состав UDDI API, модно разделить на четыре группы: · функции, позволяющие регистрировать и изменять описания сервисов в UDDI реестре, которые называют save_xxx функции; · функции для получения информации о сервисах, которые называют get_xxx функции; · функции для поиска сервисов, которые называют find_xxx функции; · функции для удаления сервисов, которые называют delete_xxx функции; Под символами "ххх" имеется в виду тип объекта ("business", "service", "binding", "tModel"). С точки зрения пользователя, UDDI реестр – это Web-сервис, для обращения к которому ему следует направить SOAP послание, поэтому пользовательский интерфейс можно определить и в терминах SOAP посланий, которые можно направлять на вход реестра. Для работы с UDDI реестром существует много библиотек классов и отдельных функций, написанных на различных языках. В средее Java программистов часто используется пакет классов UDDI4J (UDDI for Java), разработанный фирмой IBM, который доступен на сайте http://sourceforge.net/projects/uddi4j/. (На момент написания книги последней версией была версия 2.0.5 от 2006 года.) В данном пакете все обращения к реестру UDDI идут через класс-посредник UDDIProxy, который преобразует все обращения в функции UDDI API. Методы этого класса называются так же, как и функции UDDI API: save_business (), find_service () и т.п. Они возвращают объекты классов, которые представляют собой SOAP-структуры [32, 33].
|
