Веб-сервисы представляют собой технологию интеграции приложений, которая может использоваться в Internet. В качестве примера возможного использования веб-сервисов рассмотрим планирование путешествий. Обычно в такой ситуации требуются: заказ билетов на самолет, бронирование мест в гостинице, аренда автомобиля и, возможно, использование услуг местных компаний, организующих экскурсии.
Традиционно используя Internet, вам придется посетить сервер авиакомпании, сервер гостиницы или сети гостиниц, сервер компании по аренде автомобилей и сервер компании, специализирующейся на организации экскурсий в выбранном вами месте. Все эти действия могут занять достаточно много времени, прежде чем вы достигнете цели. И при этом ни одна из задействованных вами компаний не будет знать, каковы ваши планы, а следовательно, не сможет оптимизировать ваше время. Проблема заключается в том, что компании, специализирующиеся на отдельных областях - авиа, гостиничной, прокате автомобилей и т.п., в большинстве случаев замкнуты сами на себя и используют собственные средства хранения и представления данных.
Более удобно было бы запустить приложение, которое бы приняло от вас необходимую информацию и выполнило все рутинные действия - заказ билетов, бронирование гостиницы и т. п. - автоматически, без вашего участия. Чтобы это стало возможным, вы должны использовать веб-сервисы. Давайте рассмотрим, что изменится в этом случае.
Предположим, авиакомпания предоставляет веб-сервис, позволяющий приложениям получать список рейсов между двумя городами для заданной даты. В этом случае больше не требуется обращаться к веб-узлу авиакомпании и указывать различные критерии поиска - вся необходимая информация доступна в виде единого XML-документа. Теперь предположим, что авиакомпания, отель и агентство по прокату автомобилей предоставляют веб-сервисы, позволяющие программно приобретать билеты, бронировать номера и арендовать автомобили. В этом случае можно объединить вызовы всех этих сервисов в единое приложение, которое сможет выполнить всю рутинную работу без участия пользователя.
Впрочем, на этом функциональность нового класса веб-приложений не заканчивается. Наше приложение может, например, периодически обращаться к веб- сервису авиакомпании для определения статуса рейса и в случае его задержки оповещать сервисы гостиницы, службы проката и т.п. для продления бронирования.
Помимо очевидного повышения качества обслуживания клиентов использование веб-сервисов имеет множество других преимуществ. Например, если агентство проката автомобилей знает, что ваш рейс задерживается, оно может более гибко распорядиться своими автомобилями. По мере возрастания числа веб-сервисов мы сможем увидеть более комплексные примеры их использования. Однако следует отметить, что внедрение концепции веб-сервисов требует не только пересмотра многих бизнес-правил и схем взаимодействия между отраслями и секторами той или иной отрасли, но и повышения безопасности обмена данными.
Рассмотрев практическое применение веб-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.
стандарты
Как мы уже знаем, в основе веб-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet - ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты веб-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).
Веб-сервисы базируются на трех основных веб-стандартах:
SOAP (Simple Object Access Protocol) - протокол для посылки сообщений по протоколу HTTP и другим Internet-протоколам;
WSDL (Web Services Description Language) - язык для описания программных интерфейсов веб-сервисов;
UDDI (Universal Description, Discovery and Integration) - стандарт для индексации веб-сервисов.
Серверы приложений являются хранилищами веб-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.
Существующие веб-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые веб-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) веб-сервиса. Веб-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.
В следующих разделах мы рассмотрим три основных веб-стандарта, на которых базируются веб-сервисы - SOAP, WSDL и UDDI - более подробно.
SOAP - Simple Object Access Protocol
SOAP - это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его спецификация была направлена на рассмотрение комитетом W3C.
Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.
SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Приведем пример запроса в формате SOAP:
А вот ответ:
xmlns:SOAP-ENV="http:///envelope"
SOAP-ENV:encodingStyle="http:///encoding//"
Спецификация SOAP определяет формат кодирования, который, в свою очередь, задает способ представления данных в XML-формате.
WSDL - Web Services Description Language
Для того чтобы приложения могли использовать веб-сервисы, программные интерфейсы последних должны быть детально описаны - с этой точки зрения язык WSDL играет ту же роль, что и язык Interface Definition Language (IDL) в распределенных вычислениях. Описание может включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т. п.
Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL). Вот пример скелета описания сервисов на языке WSDL:
xmlns="http://(soaporg)/wsdl/">
...
Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций - запросов и ответов.
UDDI - Universal Description, Discovery and Integration
Задача UDDI - предоставить механизм для обнаружения веб-сервисов. UDDI задает бизнес-реестр, в котором провайдеры веб-сервисов могут регистрировать сервисы, а разработчики - искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в веб-реестр), в одном из которых разработчики могут зарегистрировать свои веб-сервисы, после чего данные будут автоматически реплицированы в другие реестры.
UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model.
Элемент Business Entity описывает индустрию, предоставляющую данный веб-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.
Business Service - это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.
Вместе Binding Template и Technology Model определяют веб-сервис. Technology Model содержит абстрактное описание, а Binding Template - конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.
Бизнес-реестр UDDI сам является SOAP веб-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.
Реферат слушателя ИКСИ, научный руководитель – Сергей Кунегин
Каждый веб-сервис предоставляет документ WSDL (Web Service Description Language - язык описания веб-сервиса), в котором описывается все, что клиенту необходимо для работы с этим сервисом. WSDL-документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого веб-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio .NET и.NET Framework. Благодаря указанным средствам использование веб-сервиса является таким же простым, как и применение локального класса.
WSDL-документ имеет основанный на XML формат, в соответствии с которым информация подразделяется на пять групп. Первые три группы представляют собой абстрактные определения, не зависящие от особенностей платформы, сети или языка, а оставшиеся две группы включают конкретные описания.
Протокол soap
Связь между веб-сервисами и их клиентами осуществляется посредством сообщений в формате XML.
SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора веб-сервисов.
Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML-формате.
Кроме сообщений SOAP, для обмена данными с сервисами.NET можно использовать методы GET и POST протокола HTTP.
Преимущества применения формата SOAP перед другими форматами для передачи данных:
Кодировать в XML структуры данных и наборы DataSet с использованием SOAP так же легко, как и данные простых скалярных типов.
При использовании SOAP-сообщений предоставляются дополнительные инструменты, позволяющие легко добавлять, например, функции обеспечения безопасности или трассировки.
Имеются наборы инструментов SOAP для различных языков программирования (и даже для предыдущих версий Microsoft C++ и Visual Basic). Иначе, для того чтобы обеспечить связь с сервисом посредством методов GET и POST протокола HTTP, придется, очевидно, самостоятельно конструировать строку запроса, а затем проводить синтаксический анализ ответа.
Стандарт disco
Стандарт DISCO предоставляет простейший способ получения доступа к файлам манифестов, позволяющий группировать ссылки на веб-сервисы.
DISCO-файл может включать файлы различных веб-серверов и поддерживает "динамический поиск" - автоматический поиск каталога файлов веб-сервисов на сервере.
Файлы манифеста полезны тем, что объединяют множество веб-сервисов в единственном списке, однако они не позволяют клиентам отыскивать веб-сервисы определенного типа без указания наименования компании-разработчика.
Спецификация uddi
Спецификация UDDI (Universal Description, Discovery, and Integration - универсальное описание, поиск и интеграция) позволяет избежать указанных проблем посредством использования специального хранилища (репозитория), где предприятия и организации могут размещать данные о предоставляемых ими сервисах. Инициаторами создания технологии UDDI стали более 100 компаний (полный список можно найти по адресу http://www.uddi.org/community.html), включая Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации UDDI, которая по истечении 18 месяцев была стандартизирована.
Информация в этом репозитории должна обновляться вручную. С этой целью некоторые "узловые операторы" хранят идентичные копии репозитория UDDI. Эти компании обеспечивают хранение указанного репозитория и бесплатный доступ к нему для популяризации веб-серисов. Кроме того, Майкрософт включила версию UDDI в программное обеспечение сервера Windows .NET для использования в корпоративных сетях интранета.
В хранилище UDDI содержатся сведения о предприятиях, предоставляющих веб-сервисы, о типе каждого сервиса и связях с информацией и спецификациями, относящимися к этим сервисам. Интерфейс UDDI сам по себе представляет собой веб-сервис. Для регистрации или поиска службы следует отправить SOAP-сообщение.
Главными недостатками веб-сервисов являются меньшая производительность и больший размер сетевого трафика по сравнению с такими технологиями как RMI, CORBA, DCOM за счет использования текстовых XML-сообщений.
В главе 2 мы говорили о том, что после создания Web-службы на сервере в виде сервлета, страницы JSP, JWS-файла, компонента EJB или другого объекта, следует описать состав и возможности Web-службы на языке, не зависящем от платформы, операционной системы, системы программирования, использованной при создании Web-службы. Это описание регистрируется в общедоступном месте Интернета, например, реестре UDDI или ebXML, или хранится на сервере Web-службы. Описание должно содержать полную и точную информацию обо всех услугах, предоставляемых Web-службой, способы получения услуг, содержимое запроса на получение услуги, формат предоставляемой информации.
Одно из средств точного и единообразного описания Web-услуг - язык WSDL, созданный консорциумом W3C. Этот язык - еще одна реализация XML. Его последняя рекомендованная спецификация всегда публикуется на странице http://www.w3.org/TR/wsdI . Во время написания книги на черновой стадии была версия WSDL 1.2, которую мы и опишем в этой главе.
Состав документа WSDL
Корневым элементом документа XML - описания WSDL - служит элемент
Описания WSDL активно используют различные пространства имен. Кроме собственных имен, язык WSDL часто использует имена типов и элементов языка описания схем XSD (см. главу 1) и имена языка протокола SOAP. Пространство имен языка WSDL часто описывается как пространство имен по умолчанию. Идентификатор пространства имен последней на время написания этих строк версии WSDL 1.2 был равен http://www.w3.org/2002/07/wsdl . Целевое пространство имен, идентификатор которого определяется атрибутом обычно получает префикс tns (target namespace).
В корневой элемент
?
?
?
?
?
? < service > - указывает местоположение Web-службы как один или несколько портов. Каждый порт описывается вложенным элементом
Кроме этих шести основных элементов есть еще два вспомогательных элемента.
?
Комментарий. Его можно включить в любой элемент
описания WSDL.
Можно сказать, что элементы
Элементы
Наконец, элементы
Структура документа WSDL показана в листинге 4.1. Символы в квадратных скобках не содержатся в документе. Они показывают повторяемость элемента или атрибута в описании Web-службы:
Символ [?] означает, что элемент или атрибут может появиться в документе нуль или один раз;
Символ [*] означает, что элемент может появиться нуль или несколько раз;
Символ [+] означает, что элемент может появиться один или несколько раз;
Отсутствие символа в квадратных скобках означает, что атрибут должен появиться ровно один раз.
j Листинг 4.1. Схема WSDL-документа
targetNamespace="nfleH l ra«iij location="URI-aflpec" /> [*] Произвольный комментарий Описания сложных и нестандартных типов.
Абстрактное описание SOAP-послания как набора составляющих его частей.
Абстрактное описание Web-службы как набора операций (услуг). Описание услуги как получения (input) и отправки (output, fault) посланий. Получаемое послание. Отправляемое message="nMH соотв. элемента Отправляемое сообщение об ошибке. type="MMH соотв. элемента Детали конкретного протокола. Они определяются в схеме этого протокола. -> Сюда записываются элементы, описывающие детали конкретной операции. -> Сюда записываются элементы, описывающие детали конкретного получаемого послания. -> Сюда записываются элементы, описывающие детали конкретного отправляемого послания. ->
Сюда записываются элементы, описывающие детали конкретного сообщения об ошибке. ->
serviceType="MMH соотв. элемента Описание интерфейса Web-службы как набора портов.
binding="nMH соотв. элемента Сюда записывается обязательный и единственный адрес интерфейса Web-службы, записанный по правилам протокола, указанного в элементе
Каждый конкретный протокол пересылки посланий - SOAP, HTTP, FTP, SMTP - добавляет к шести основным и двум вспомогательным элементам языка WSDL свои дополнительные элементы, описывающие особенности данного протокола.
Приведем простой пример. В листинге 3.14 мы записали в виде класса Java простейшую Web-службу, возвращающую без всякой обработки присланный запрос:
public class EchoService{
public String getEcho (String req) { return req;
В листинге 4.2 приведено описание этой Web-службы на языке WSDL, использующее протокол SOAP.
Листинг 4.2. Описание Web-службы EchoService
version="1.0" encoding="UTF-8" ?>
targetNamespace="http://echoservice.com/echoservice.wsdl" xmlns="http://www.w3.org/2002/07/wsdl" xmlns:tns="http://echoservice.com/echoservice.wsdl" xmlns:soap="http://www.w3.org/2002/07/wsdl/soapl2" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
transport="http://schemas.xmlsoap.org/soap/http" /> "http://schemas.xmlsoap.org/soap/encoding/" namespace= "http: //echoservice. ccm/echcservice .wsdl" use="encoded" /> ^oapKbocy enccdingStyle= "http: //schemas .xmlsoap. org/soap/encoding/" namespace= "http: //echoservice. c^/ech^service .wsdl" use="encoded" /> "http://localhost:8080/axis/EchoService.jws" /> В листинге 4.2 мы в элементе Имена "getEchoRequest" И "getEchoResponse" ИСПОЛЬЗОВаны В следующем элементе txarspcrt^=^"ht:tp^://?cheпas^.>пlscap^.c^rc^/?cap^/ht:tp^" /> Если применяется документный стиль SOAP, то в атрибуте style записывается значение "document". Наконец, в элементе В листинге 4.2 имена с префиксом soap конкретизировали описание послания и способы его пересылки. Посмотрим, какие конкретные протоколы предлагает спецификация WSDL 1.2. Литература:
Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.
В этой статье я расскажу о том, что такое WSDL-файл, зачем он нужен и как с ним работать. Карта статьи
Что такое WSDL
WSDL — это язык описания веб-сервиса, имеющий структуру XML. Основное назначение WSDL-файла — это интерфейс доступа к функциям сервиса, возвращаемым типам данных; путь к серверу, обрабатывающему запросы и т.д. Путь к wsdl-файлу обычно имеет вид http://host/services/wsdl/gbdar-v2-2.wsdl Существует множество инструментов, библиотек, предназначенных для чтения WSDL-файла. SoapUi
Одним из таких инструментов является soapUi (). Установив дистрибутив, предназначенный для вашей платформы, вы сможете создать новый проект командой File/New SoapUi project. В диалоге создания нового проекта оставляем включенной галочку Create sample requests Выполнение запросов
В новом проекте будут автоматически созданы шаблоны запросов для сервиса, описание которого содержится в wsdl-файле. Слева в дереве Вы увидите перечень функций, содержащихся в WSDL-файле. Я раскрою функцию Replication. Внутри нее присутствует запрос Request1, дважды щелкнув по которому, мы увидим диалог с шаблоном запроса, вместо параметров по умолчанию будут проставлены знаки вопроса. Чтобы функция корректно выполнилась, необходимо заполнить все параметры, не помеченные тегом Optional, после чего нажать зеленый треугольник в верхнем левом углу диалога. Если все параметры указаны верно, справа появится ответ сервиса на запрос. SoapUi предоставляет возможность просмотра параметров WSDL-файла, для этого необходимо дважды щелкнуть по наименованию интерфейса (помечен зеленой иконкой в дереве WSDL-файла, у меня — gdbar-v2-2SOAP). В диалоговом окне вы можете найти: Генерация документации
SoapUi позволяет нам генерировать документацию по функциям WSDL. Для этого щелкните правой кнопкой по интерфейсу и вызовите команду Generate Documentation.
В результате получим подробный мануал в html-формате. На этом все, подписывайтесь на новые записи, оставляйте комментарии, вносите предложения по улучшению статьи. Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1). Элемент связывания operation содержит данные для одноимённой операции связанного типа порта. Однако имя операции в общем случае не является уникальным (пример: перегрузка методов / функций — использование одинаковых имён с различными сигнатурами), потому его может быть недостаточно для однозначного определения целевой операции типа порта. В таких случаях целевая операция адресуется с помощью дополнительного задания соответствующих имён элементов wsdl:input и wsdl:output с помощью атрибута name . Связывание должно
устанавливать только один протокол. Связывание не должно
содержать информации об адресе. Порт определяет отдельную конечную точку посредством установки адреса для связывания. Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см.). Элементы расширения (1) используются для задания адреса. Порт не должен
задавать более одного адреса. Порт не должен
содержать любую информацию связывания, отличную от адреса. Служба объединяет вместе набор связанных портов. Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа. Порты внутри службы связаны следующим образом:
Порт
Служба