НТВ плюс 

SOAP Web-сервис средствами Spring-WS

Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…

Введение

Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:
  1. SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
  2. WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.
Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «Web-сервисы Java». Там на протяжении первых 200 страниц идет подробнейшее описание каждого тега стандартов SOAP и WSDL. Стоит ли это делать? На мой взгляд нет, т.к. все это на Java создается автоматически, а вам нужно лишь написать содержимое методов, которые предполагается удалено вызывать. Так вот, в Java появился такой API, как JAX-RPC. Если кто не знает, когда говорят, что в Java есть такой-то API, это означает, что есть пакет с набором классов, которые инкапсулируют рассматриваемую технологию. JAX-RPC долго развивался от версии к версии и в конечном итоге превратился в JAX-WS. WS, очевидно, означает WebService и можно подумать, что это простое переименование RPC в популярное нынче словечко. Это не так, т.к. теперь веб-сервисы отошли от первоначальной задумки и позволяют не просто вызывать удаленные методы, но и просто посылать сообщения-документы в формате SOAP. Зачем это нужно я пока не знаю, вряд ли ответ здесь будет «на всякий случай, вдруг понадобится». Сам бы хотел узнать от более опытных товарищей. Ну и последнее, далее появился еще JAX-RS для так называемых RESTful веб-сервисов, но это тема отдельной статьи. На этом введение можно заканчивать, т.к. далее мы будем учиться работать с JAX-WS.

Общий подход

В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:
  1. Описать интерфейс нашего веб-сервиса
  2. Реализовать этот интерфейс
  3. Запустить наш веб-сервис
  4. Написать клиента и удаленно вызвать нужный метод веб-сервиса
Запуск веб-сервиса можно производить разными способами: либо описать класс с методом main и запустить веб-сервис непосредственно, как сервер, либо задеплоить его на сервер типа Tomcat или любой другой. Во втором случае мы сами не запускаем новый сервер и не открываем еще один порт на компьютере, а просто говорим контейнеру сервлетов Tomcat, что «мы написали тут классы веб-сервиса, опубликуй их, пожалуйста, чтобы все, кто к тебе обратиться, могли нашим веб-сервисом воспользоваться». В независимости от способа запуска веб-сервиса, клиент у нас будет один и тот же.

Сервер

Запустим IDEA и создадим новый проект Create New Project . Укажем имя HelloWebService и нажмем кнопку Next , далее кнопку Finish . В папке src создадим пакет ru.javarush.ws . В этом пакете создадим интерфейс HelloWebService: package ru. javarush. ws; // это аннотации, т.е. способ отметить наши классы и методы, // как связанные с веб-сервисной технологией import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // говорим, что наш интерфейс будет работать как веб-сервис @WebService // говорим, что веб-сервис будет использоваться для вызова методов @SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService { // говорим, что этот метод можно вызывать удаленно @WebMethod public String getHelloString (String name) ; } В этом коде классы WebService и WebMethod являются так называемыми аннотациям и ничего не делают, кроме как помечают наш интерфейс и его метод, как веб-сервис. Это же относится и к классу SOAPBinding . Разница лишь в том, что SOAPBinding – это аннотация с параметрами. В данном случае используется параметр style со значением, говорящим, что веб-сервис будет работать не через сообщения-документы, а как классический RPC, т.е. для вызова метода. Давайте реализуем логику нашего интерфейса и создадим в нашем пакете класс HelloWebServiceImpl . Кстати, замечу, что окончание класса на Impl – это соглашение в Java, по которому так обозначают реализацию интерфейсов (Impl – от слова implementation, т.е. реализация). Это не требование и вы вольны назвать класс как хотите, но правила хорошего тона того требуют: package ru. javarush. ws; // таже аннотация, что и при описании интерфейса, import javax. jws. WebService; // но здесь используется с параметром endpointInterface, // указывающим полное имя класса интерфейса нашего веб-сервиса @WebService (endpointInterface = "ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implements HelloWebService { @Override public String getHelloString (String name) { // просто возвращаем приветствие return "Hello, " + name + "!" ; } } Запустим наш веб-сервис как самостоятельный сервер, т.е. без участия всяких Tomcat и серверов приложений (это тема отдельного разговора). Для этого в структуре проекта в папке src создадим пакет ru.javarush.endpoint , а в нем создадим класс HelloWebServicePublisher с методом main: package ru. javarush. endpoint; // класс, для запуска веб-сервера с веб-сервисами import javax. xml. ws. Endpoint; // класс нашего веб-сервиса import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher { public static void main (String. . . args) { // запускаем веб-сервер на порту 1986 // и по адресу, указанному в первом аргументе, // запускаем веб-сервис, передаваемый во втором аргументе Endpoint. publish ("http://localhost:1986/wss/hello" , new HelloWebServiceImpl () ) ; } } Теперь запустим этот класс, нажав Shift+F10 . В консоли ничего не появится, но сервер запущен. В этом можно убедиться набрав в браузере строку http://localhost:1986/wss/hello?wsdl . Открывшаяся страница, с одной стороны, доказывает, что у нас на компьютере (localhost) запустился веб-сервер (http://) на порту 1986, а, с другой стороны, показывает WSDL описание нашего веб-сервиса. Если вы остановите приложение, то описание станет недоступно, как и сам веб-сервис, поэтому делать этого не будем, а перейдем к написанию клиента.

Клиент

В папке проекта src создадим пакет ru.javarush.client , а в нем класс HelloWebServiceClient с методом main: package ru. javarush. client; // нужно, чтобы получить wsdl описание и через него // дотянуться до самого веб-сервиса import java. net. URL; // такой эксепшн возникнет при работе с объектом URL import java. net. MalformedURLException; // классы, чтобы пропарсить xml-ку c wsdl описанием // и дотянуться до тега service в нем import javax. xml. namespace. QName; import javax. xml. ws. Service; // интерфейс нашего веб-сервиса (нам больше и нужно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient { public static void main (String args) throws MalformedURLException { // создаем ссылку на wsdl описание URL url = new URL ("http://localhost:1986/wss/hello?wsdl" ) ; // Параметры следующего конструктора смотрим в самом первом теге WSDL описания - definitions // 1-ый аргумент смотрим в атрибуте targetNamespace // 2-ой аргумент смотрим в атрибуте name QName qname = new QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ) ; // Теперь мы можем дотянуться до тега service в wsdl описании, Service service = Service. create (url, qname) ; // а далее и до вложенного в него тега port, чтобы // получить ссылку на удаленный от нас объект веб-сервиса HelloWebService hello = service. getPort (HelloWebService. class ) ; // Ура! Теперь можно вызывать удаленный метод System. out. println (hello. getHelloString ("JavaRush" ) ) ; } } Максимум комментариев по коду я дал в листинге. Добавить мне нечего, поэтому запускаем (Shift+F10). Мы должны в консоли увидеть текст: Hello, JavaRush! Если не увидели, то видимо забыли запустить веб-сервис.

Заключение

В данном топике был представлен краткий экскурс в веб-сервисы. Еще раз скажу, что многое из того, что я написал – это мои догадки по поводу того, как это работает, и поэтому мне не стоит сильно доверять. Буду признателен, если знающие люди меня поправят, ведь тогда я чему-нибудь научусь. UPD.

В главе 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 - служит элемент . В этом элементе необязательным атрибутом name можно дать имя описанию. Кроме того, это удобное место для введения используемых в описании пространств имен.

Описания WSDL активно используют различные пространства имен. Кроме собственных имен, язык WSDL часто использует имена типов и элементов языка описания схем XSD (см. главу 1) и имена языка протокола SOAP. Пространство имен языка WSDL часто описывается как пространство имен по умолчанию. Идентификатор пространства имен последней на время написания этих строк версии WSDL 1.2 был равен http://www.w3.org/2002/07/wsdl . Целевое пространство имен, идентификатор которого определяется атрибутом обычно получает префикс tns (target namespace).

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

? - определяет сложные типы, используемые Web-службой, с помощью языка XSD или другого языка описания типов. Этот элемент не нужен, если Web-служба применяет только простые типы, описанные в языке XSD.

? - описывает каждое SOAP-послание: запрос, ответ, пересылку документов. В этот элемент вкладываются элементы Описывающие неделимые с точки зрения WSDL части послания. Для посланий процедурного типа каждый элемент Может описывать имя и тип одного аргумента запроса или тип возвращаемого значения. Для посланий документного типа элементы Могут описывать каждую часть послания "multipart/related". Это абстрактное описание затем конкретизируется элементами .

? Описывает интерфейс Web-службы, называемый в языке WSDL пунктом назначения (endpoint) или портом (port) прибытия послания. Он описывается как набор Web-услуг, называемых в языке WSDL операциями. Переводя это описание на язык программирования можно заметить, что порт хорошо соотносится с интерфейсом Java, а каждая операция - с методом этого интерфейса. Операции описываются вложенными элементами , описывающими каждую отдельную услугу. Услуга описывается действиями, которые разбиты на четыре вида. Это два простых действия: "получение послания", "отправка ответа", и два комбинированных действия: "отправка послания - получение ответа" или, наоборот, "получение послания - отправка ответа". Получение и отправка, в свою очередь, описываются вложенными элементами и , а сообщение об ошибке - элементом . Получаемые и отправляемые послания уже должны быть описаны элементами , элементы , И ссылаются на НИХ СВОИМ атрибутом message.

? - перечисляет вложенными элементами Набор портов, связанных с одной Web-службой. Один и тот же порт может быть связан с несколькими службами.

? - описывает конкретный формат пересылки послания: протоколы, такие как SOAP или HTTP, способы упаковки послания, тип его содержимого: HTML, XML или другой MIME-тип послания. Каждый элемент может быть связан с несколькими такими элементами, по одному для каждого способа пересылки. В этот элемент вкладываются элементы, определенные в схеме выбранного протокола.

? < service > - указывает местоположение Web-службы как один или несколько портов. Каждый порт описывается вложенным элементом Содержащим адрес интерфейса Web-службы, заданный по правилам выбранного в элементе способа пересылки.

Кроме этих шести основных элементов есть еще два вспомогательных элемента.

? - включает файл с XSD-схемой описания WSDL или другой WSDL-файл.

Комментарий. Его можно включить в любой элемент

описания WSDL.

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

Элементы объясняют, КАК реализована Web-служба, каков протокол передачи посланий: HTTP, SMTP или какой-то другой, а также задает технические характеристики передачи данных.

Наконец, элементы показывают, ГДЕ находится Web-служба, связывая описание с конкретными адресами Web-службы.

Структура документа 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" />

name="EchoServService">

Binding="tns:EchoServiceSoapBinding" name="EchoService"> location=

"http://localhost:8080/axis/EchoService.jws" />

В листинге 4.2 мы в элементе определили префиксы всех нужных нам пространств имен. Далее мы описали запрос и ответ в двух элементах . Мы дали ИМ имена "getEchoRequest" И "getEchoRe- sponse". В запросе один аргумент типа xsd: string. Этот тип определен в языке XSD. Мы дали аргументу имя req, совпадающее с именем аргумента метода getEcho () . Значению, возвращаемому методом, мы дали имя return, его тип тоже xsd: string.

Имена "getEchoRequest" И "getEchoResponse" ИСПОЛЬЗОВаны В следующем элементе Для указания входных и выходных параметров Web- услуги. В него вложен один элемент . Это означает, что Web- служба предоставляет одну услугу, имя которой "getEcho" совпадает с именем метода, выполняющего эту услугу. В элементе указаны входной и выходной параметры услуги. Затем, элементом мы указали один способ пересылки посланий - SOAP-послания в процедурном стиле, пересылаемые по протоколу HTTP, на что указывает элемент

txarspcrt^=^"ht:tp^://?cheпas^.>пlscap^.c^rc^/?cap^/ht:tp^" />

Если применяется документный стиль SOAP, то в атрибуте style записывается значение "document".

Наконец, в элементе вложенным элементом Связываем элемент с элементом

, указывающим адрес, по которому расположена Web-служба.

В листинге 4.2 имена с префиксом soap конкретизировали описание послания и способы его пересылки. Посмотрим, какие конкретные протоколы предлагает спецификация WSDL 1.2.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.

Страница 2 из 3

Описание с помощью WSDL

SOAP работает очень хорошо, если о Web-службе все известно. Однако это не всегда так. Средством описания интерфейса для доступа к Web-службе является язык WSDL (Web Services Description Language - язык описания Web-служб). Этот стандарт совместно разработан компаниями IBM, Microsoft и webMethods. У каждой из этих трех компаний был собственный подход к разработке стандарта для описания Web-служб: IBM создала NASSL, Microsoft разработала SCL, а компания webMethods придумала WIDL.

Результатом их сотрудничества стала версия 1.1 языка WSDL, По поводу W3C следует отметить, что так же как и с SOAP, консорциум W3C на основе версии 1.1 разработал версию WSDL 1.2, которая теперь является рекомендацией W3C. WSDL-описание Web-службы содержит всю необходимую для использования этой службы информацию, включая доступные методы и их параметры. Эта информация содержится в следующих пяти элементах:

  • - поддерживаемые протоколы.
  • - сообщения Web-службы (запрос, ответ).
  • Все доступные методы.
  • - URI службы.
  • - используемые типы данных.

Вся эта информация хранится в корневом элементе WSDL-описания , В листинге ниже представлен пример WSDL-описания Web-службы.

WSDL-описание Web-службы

Да уж... без стаканА не разберёшся, а ведь это один из самых простеньких(!) WSDL файлов. К сожалению, один из недостатков SOAP-расширения для РНР 5 связан с тем, что в отличие от других реализаций SOAP, оно не позволяет создавать WSDL-описания автоматически (во всяком случае, пока что). Наверняка этот недостаток исправят в будущих версиях РНР.

Кстати!

Для автоматического создания WSDL-описания вы можете использовать альтернативные реализации протокола SOAP в РНР:

Поиск в справочнике с помощью UDDI

Теперь, после того как мы знаем, как получать информацию о Web-службе и как ее запрашивать, нужно научиться находить такую службу. Для этой цели существует нечто похожее на "Желтые страницы", а именно - реестры UBR (Universal Business Registries - универсальные бизнес-реестры) - справочники Web-служб.

Существует несколько таких реестров, среди которых реестры компаний IBM, Microsoft, NTT-Com и SAP. Эти реестры синхронизируют свои данные, поэтому можно пользоваться любым из них. Текущей версией стандарта UDDI является версия UDDI 3.0, хотя большинство реализаций используют версию 2. Среди разработчиков этого стандарта такие компании-гиганты, как HP, Intel, Microsoft и Sun.

Для взаимодействия с UBR существует два типа API-интерфейсов: Inquiry API и Publish API . Интерфейс Inquiry API (Запрос) предназначен для запроса служб в реестрах UBR, а интерфейс Publish API (Публикация) позволяет разработчикам регистрировать свои службы . Похоже, что заполнение содержимого реестров спамом - это только вопрос времени:)

Кстати!

Существуют тестовые реестры, предназначенные для тестирования регистрации служб перед их размещением в "настоящих" реестрах.

Так выглядит запрос Web-службы:

sortByNameAsc sortByDateDesc %guid%

В примере выше видно, что UDDI-запрос инкапсулирован в SOAP-сообщение, поэтому выглядит он довольно знакомым. Ответом на запрос является также SOAP-документ, показанный ниже:

Web Services Guided Tour Sample Web services for Guided Tourbook Guided Tour StockQuote Service

Установка

Установить SOAP-расширение для PHP5 довольно легко. В Windows этот модуль находится в подкаталоге ext каталога установки РНР. Для его использования необходимо в файл php.ini добавить следующую строку: extension=php_soap.dll Для работы этому модулю требуется, которая включена в РНР 5 по умолчанию, по крайней мере, в Windows-версии.

WSDL (Web Services Description Language ) версии 1.1 был опубликован 15 марта 2001 года. WSDL - это формат, базирующийся на XML и использующийся для описания сетевых cервисов, при помощи сообщений, содержащих информация о том как осуществлять доступ к конкретному веб-сервису. WSDL расширяем, что позволяет описывать услуги (сервисы) и их сообщения независимо от того, какие форматы сообщений или сетевые протоколы используются для транспорта, однако, чаще всего используется WSDL 1.1 вместе с SOAP 1.1, HTTP GET/POST и MIME. Поскольку WSDL был разработан совместно с SOAP, в его разработке участвовали все те же фирмы Microsoft, Ariba и IBM. Если рассматривать документ WSDL интуитивно, то можно сказать, что он позволяет ответить на 4 вопроса :

1) что вы делаете? Ответ на этот вопрос дается в форме пригодной как для восприятия человеком так и форме воспринимаемой машиной. Ответ для чел-ка в тегах: <name />, <documentation />, для машины - <message />, <pointType >

2) на каком языке вы разговариваете? (какие типы вы используете?)Ответ в теге: <types />

3) как я буду с вами общаться? (как клиент будет обращаться к веб-службе?):HTTP или SMTP. Ответ находится в <binding />

4) где мне вас найти? (где я могу найти эту веб-службу или какой у нее URL?). Ответ находится: <service />

Структура:

Каждый документ WSDL можно разбить на три логические части:

1. определение типов данных - определение вида отправляемых и получаемых сервисом XML сообщений

2. абстрактные операции - список операций, которые могут быть выполнены с сообщениями

3. связывание сервисов - способ, которым сообщение будет доставлено

Документы WSDL можно создавать вручную, однако строгая формализация языка WSDL позволяет автоматизировать процесс написания WSDL -документов. Многие интсрументальные средства создания Web-служб содержат утилиты, которые автоматичеки создают WSDL -файлы, описывающие готовые Web-службы. Например средство создания Web-служб Apache Axis содержит в своем составе класс Java2WSDL , создающий WSDL -файл по классу или интерфейсу Java, описывающему Web-службу. Пакет IBM WSTK, в состав которого входит Axis , содержит утилиту java2wsdl , создающую и запускающую объект из этого класса. Она работает из командной строки.

Элементы WSDL-документа

Опишем наиболее часто употребляемые теги WSDL:

Тег – это корневой тег всех WSDL-документов. Он определяет несколько пространств имен:

1)target Name space – это пространство имен нашей веб-службы

2)xmlns – стандартное пространство имен документа WSDL

3)xmlns: SOAP_ENC – пространство имен используемое для описания кодировки SOAP


4)xmlns: impl и intf – пространство имен реализации и определения нашей веб-службы

· Документ для определения веб-службы

· Документ для реализации веб-службы

Для простоты, как правило, используют 1 файл, который содержит всю информацию

Элемент - предоставляет информацию о данных, которые передаются от одной конечной точки к другой.

Для описания вызова RPC необходимо создать входной сообщение и выходное сообщение.

В рамках этого элемента можно указать параметры метода с помощью элемента

Элемент описывает и определяет операции или методы поддерживаемые веб-службой

Операции могут иметь входные сообщения, а также сообщения об ошибках.

Элемент - описывает, как операции определенные в типе порта будут передаваться по сети. Т.к. элемент использует тип порта, то он должен указывать тип определенный где-то ранее в документе.

Элемент - указывает где найти веб службу

Элемент import . Очень часто элемент service выделяется в свой wsdl документ из соображений практичности.

Для того, чтобы позволить собрать из нескольких wsdl документов один используется элемент import. Он позволяет включать один wsdl документ в другой.

Элемент types позволяет указать типы передаваемых данных если они не являются стандартными.

WSDL поддерживает 4 режима операций:

· операции типа one-way или односторонние операции. Сообщение посылается конечной точке службы. В этом случае операция описывается только одним входным сообщением.

· Request-Response – режим запрос-ответ. Этот режим операции является наиболее общим. В этом режиме описание операции содержит входное и выходное сообщение и необязательное сообщение об ошибке.

· Операция типа требование-ответ. В этом режиме конечной точкой является клиент другой конечной точки. Формат операции похож на режим запрос-ответ, но выходные данные перечисляются перед входными данными.

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

Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1).

Элемент связывания operation содержит данные для одноимённой операции связанного типа порта. Однако имя операции в общем случае не является уникальным (пример: перегрузка методов / функций — использование одинаковых имён с различными сигнатурами), потому его может быть недостаточно для однозначного определения целевой операции типа порта. В таких случаях целевая операция адресуется с помощью дополнительного задания соответствующих имён элементов wsdl:input и wsdl:output с помощью атрибута name .

Связывание должно устанавливать только один протокол.

Связывание не должно содержать информации об адресе.

Порт

Порт определяет отдельную конечную точку посредством установки адреса для связывания.

  1. <wsdl :definitions .... >
  2. <wsdl :service .... > *
  3. <wsdl :port name = "nmtoken" binding = "qname" > *
  4. <-- extensibility element (1) -->
  5. wsdl :port >
  6. wsdl :service >
  7. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см.).

Элементы расширения (1) используются для задания адреса.

Порт не должен задавать более одного адреса.

Порт не должен содержать любую информацию связывания, отличную от адреса.

Служба

Служба объединяет вместе набор связанных портов.

  1. <wsdl :definitions .... >
  2. <wsdl :service name = "nmtoken" > *
  3. <wsdl :port .... /> *
  4. wsdl :service >
  5. wsdl :definitions >

Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа.

Порты внутри службы связаны следующим образом:

  • Порты не взаимодействуют друг с другом (т.е. выход одного порта не является входом другого).
  • Если служба имеет несколько портов, которые разделяют общий тип порта, но используют разные связывания, либо имеют различные адреса, такие порты являются альтернативными. Каждый такой порт реализует логически эквивалентное поведение (в рамках ограничений транспорта и формата сообщений, накладываемых соответствующим связыванием). Это позволяет клиенту выбирать конкретный порт для обмена на основе различных критериев (поддержка транспортного протокола и т.д.).
  • Рассмотрев порты, можно определить поддерживаемые службой типы портов. На основе этих данных клиент может определить возможность взаимодействия с конкретной службой. Это полезно, если подразумевается связь между операциями из разных типов портов, и для выполнения определённой задачи требуется поддержка службой всех необходимых типов портов.
  1. Это вольный, частичный, дополненный перевод документа Web Services Description Language (WSDL) 1.1 от 15 Марта 2001
  2. Несклоняемыми написанными латиницей терминами оперировать крайне неудобно, к тому же они однозначно переводятся. Поэтому исходное имя даётся только при введении нового термина, а далее по тексту используется русский перевод.