В этой статье я расскажу о том, что такое 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-формате.
На этом все, подписывайтесь на новые записи, оставляйте комментарии, вносите предложения по улучшению статьи.
Когда-то поставили передо мной задачу начать разработку Web-сервисов и дали мне сорцы простейшего проекта без каких-либо объяснений. Проект, конечно же, не запускался. Что такое Spring и как он работает, я тоже представления не имел. Адекватных статей по разработке Web-сервисов средствами Spring ни русскоязычных, ни англоязычных я тоже не смог найти. Пришлось разбираться во всем самому, оказалось все не так страшно.
И вот недавно я решил посмотреть, какие новые возможности добавились в Spring с тех пор, и обновить старые сервисы, что в результате и сподвигло меня на написание данной статьи.
Данная статья является руководством по разработке простейшего Web-сервиса, использующего SOAP -протокол, средствами Spring-WS.
И так, писать будем простейший сервис, принимающий имя пользователя и отправляющий приветствие и текущее время на сервере.
Далее запускаем Ant-build (надеюсь, вы его уже установили).
В Eclipse можно запустить так: ПКМ по файлу build.xml=> Run As => Ant Build.
Если через командную строку:
ant -buildfile build.xml
Ну и ждем завершения построения. После чего, можем проверить каталог проекта WEB-INF\lib на наличие соответствующей библиотеки (helloservice.jar).
Создаем файл HelloServiceEndpoint.java:
package org.example;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.ws.server.endpoint.annotation.Endpoint;
import org.springframework.ws.server.endpoint.annotation.PayloadRoot;
import org.example.helloService.ServiceRequestDocument;
import org.example.helloService.ServiceRequestDocument.ServiceRequest;
import org.example.helloService.ServiceResponseDocument;
import org.example.helloService.ServiceResponseDocument.ServiceResponse;
@Endpoint
public class HelloServiceEndpoint{
private static final String namespaceUri = "http://www.example.org/HelloService";
private HelloService helloService;
@Autowired
public void HelloService (HelloService helloService) {
this.helloService = helloService;
}
@PayloadRoot(localPart = "ServiceRequest", namespace = namespaceUri)
public ServiceResponseDocument getService(ServiceRequestDocument request) throws Exception {
ServiceRequestDocument reqDoc = request;
ServiceRequest req = reqDoc.getServiceRequest();
ServiceResponseDocument respDoc = ServiceResponseDocument.Factory.newInstance();
ServiceResponse resp = respDoc.addNewServiceResponse();
String userName = req.getName();
String helloMessage = testNewService.getHello(userName);
Calendar currentTime = testNewService.getCurrentTime();
resp.setHello(helloMessage);
resp.setCurrentTime(currentTime);
return respDoc;
}
}
Что же здесь сделано?
Аннотация @Endpoint
как раз и определяет, что данный класс будет обрабатывать входящие запросы.
namespaceUri
– то же пространство имен, что и указывалось при создании xml-схемы.
Теперь вернемся немного назад и вспомним про аннотацию @ Service . Если не вдаваться в подробности, чтобы не перегружать читателя лишней информацией, то эта аннотацию говорит Spring"у создать соответствующий объект. А аннотация @Autowired служит для инъекции (автоматической подстановки) соответствующего объекта. Конечно же при построении простых приложений в использовании данных аннотаций отсутствует смысл, но я решил все-такие не исключать их в данном примере.
В остальном опять же все должно быть ясно. Обратите внимание, что ServiceRequest, ServiceResponse и т.д. – это как раз те классы, которые были созданы на основе нашей xml-схемы.
Два последующих бина всегда будут неизменны. Суть их заключается в приеме и преобразовании запроса из Xml в Java-объект и дальнейшего обратного преобразования.
sws:dynamic-wsdl
отвечает за автоматическую генерацию WSDL-документа на основе созданной Xml-схемы.
location
указывает на путь к схеме.
locationUri
– адрес (относительно контейнера), по которому будет доступна WSDL-схема.
В моем случае WSDL доступен по следующему адресу:
localhost/HelloService/HelloService.wsdl
Для дальнейшей проверки нам потребуется soapUI (у меня версия 3.0.1).
Устанавливаем и запускаем его.
Создаем новый проект: File => New soapUI Project. В поле Initial WSDL/WADL вставляем ссылку на WSDL-схему (http://localhost/HelloService/HelloService.wsdl).
В созданном проекте открываем необходимый запрос. 
В поле Name вбиваем имя и жмем на кнопку «Send request»
В результате получаем ответ от сервера с приветствием и текущим временем.
Если что-то пошло не так, то опять перечитываем данную статью.
Язык описания Web-сервисов (WSDL)
В последних нескольких примерах вы могли видеть отдельные фрагменты WSDL-кода. Напомним, что WSDL – это основанная на XML грамматика, предназначенная для описания возможностей взаимодействия внешних клиентов с Web-методами, доступными по данному адресу URL в рамках каждого из поддерживаемых протоколов связи. Во многих отношениях WSDL-документ может рассматриваться, как "контракт" между клиентом Web-сервиса и самим Web-сервисом. Это еще один метаязык. В частности, WSDL используется для описания следующих характеристик любого доступного Web-метода:
Имя Web-метода XML;
Число, тип и порядок следования параметров (если таковые имеются);
Тип возвращаемого значения (если таковое предусмотрено);
Условия вызова HTTP GET, HTTP POST и SOAP.
В большинстве случаев WSDL-документы генерируются автоматически соответствующим Web-сервером. Напомним, что при добавлении суффикса?wsdl к адресу URL, указывающему на файл *.asmx, Web-сервер генерирует WSDL-документ для указанного Web-сервиса XML.
http://locаlhost/SomeWS/theWS.asmx?wsdl
Но если IIS автоматически генерирует WSDL-документ для данного Web-сервиса XML, зачем тогда нужно глубокое понимание синтаксиса генерируемых WSDL-данных? Ответ обычно зависит от того, как ваш сервис будет использоваться внешними приложениями. В случае Web-сервисов XML, предназначенных для "внутреннего" использования, сгенерированного Web-сервером WSDL-кода будет, как правило, достаточно.
Между тем. вполне возможно начать разработку Web-сервиса XML с создания WSDL-документа вручную (об этом уже говорилось выше). Главная идея начала разработки с создания WSDL-документа связана с вопросами совместимости. Вспомните о том, что до появления спецификации WSI различные инструменты построения Web-сервисов нередко генерировали несовместимые WSDL-описания. Если начинать разработку с WSDL-кода, вы можете построить документ так, как требуется.
Как вы можете догадаться, для начала разработки Web-сервиса XML с создания WSDL-документа требуется очень хорошее знание грамматики WSDL, обсуждение которой в контексте этой главы не предусмотрено. Но мы рассмотрим базовую структуру WSDL-документа. Разобравшись в основах, вы сможете оценить пользу утилиты командной строки wsdl.exe.
Замечание. Самую свежую информацию о языке WSDL можно найти на страницах http://www.w3.org/tr/wsdl .
Определение WSDL-документа
Действительный документ WSDL открывается и закрывается корневым элементом ‹definitions›. В открывающем дескрипторе обычно определяются различные атрибуты xmlns. Они задают пространства имен XML, определяющие различные подчиненные элементы. Как минимум, элемент ‹definitions› должен указать пространство имен, где определены сами элементы WSDL (http://schemas.xmlsoap.org/wsdl). Для того чтобы быть полезным, открывающий дескриптор ‹definitions› должен, кроме того, указать пространства имен XML, определяющие простые типы данных WSDL, типы XML-схемы, элементы SOAP, а также целевое пространство имен. Например, вот как выглядит раздел ‹definitions› для нашего Web-сервиса калькулятора.
‹wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.IntertechTraining.com/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemes.xmlsoap.оrg/wsdl/http/"
targetNamespace="http://www.IntertechTraining.com/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›
‹/wsdl :definitions›
В контексте корневого элемента вы можете найти пять подчиненных элементов. Общий вид WSDL-документа должен быть примерно таким.
‹?xml version="1.0" encoding="utf-8"?›
‹wsdl:definitions …›
‹wsdl:types›
‹!-- Список типов, доступных для данного Web-сервиса - -›
‹wsdl:/types›
‹wsdl:message›
‹!-- Формат сообщений - -›
‹wsdl:/message›
‹wsdl:portType›
‹!-- Информация портов - -›
‹wsdl:/portType›
‹wsdl:binding›
‹!-- Информация связывания - -›
‹wsdl:/binding›
‹wsdl:service›
‹!-– Информация о самом Web-сервисе XML - -›
‹wsdl:/service›
‹wsdl:/definitions›
Как и следует ожидать, каждый из этих подчиненных элементов будет содержать дополнительные элементы и атрибуты, уточняющие описание имеющихся возможностей. Давайте по очереди рассмотрим наиболее важные из допустимых узлов.
Элемент ‹types›
Сначала мы рассмотрим элемент ‹types›, который содержит описания всех типов данных, предлагаемых Web-сервисом. Вы, возможно, знаете, что язык XML сам определяет ряд "базовых" типов данных, и все они определены в рамках пространства имен XML http://www.w3.org/2001/XMLSchema (которое должно быть указано в контексте корневого элемента ‹definitions›). Возьмем, например, метод Subtract() нашего Web-сервиса калькулятора, имеющий два входных параметра целочисленного типа. В терминах WSDL тип System.Int32 среды CLR описывается в контексте элемента ‹complexType›.
‹s:еlement name= "Subtract"›
‹s:sequence›
‹s:element minOccurs="1 " maxOccurs="1 " name="x " type="s:int " /›
‹s:element minOccurs=""1 " maxOccurs="1 " name="y " type="s:int " /›
‹/ s:sequence›
‹/s:complexType›
‹/s:element›
Целое число, возвращаемое методом Subtract(), также описывается в рамках элемента ‹types›.
‹s:element name= "SubtractResponse "›
‹s:complexType›
‹s:sequence›
‹s:element minOccurs="1 " maxOccurs= "1 " name="SubtractResult " type="s:int "/›
‹/s:sequence›
‹ /s:complexType›
‹/s:element›
Если вы имеете Web-метод, возвращающий или получающий пользовательские типы данных, они также появятся в контексте элемента ‹complexType›. Детали того, как с помощью Web-метода сделать доступными пользовательские типы данных.NET, мы рассмотрим позже. Для примера предположим, что вы определили Web-мeтод, возвращающий структуру с именем Point.
public struct Point {
public string pointName;
WSDL-описание для этой "сложной структуры" будет выглядеть примерно так.
‹s:complexType name="Point "›
‹s:sequence›
‹s:element minOccurs="1 " maxOccurs="1 " name="x " type="s:int " /›
‹s:element minOccurs="1 "" maxOccurs="1 " name="y " type= "s:int " /›
‹s:element minOccurs="0 " maxOccurs="1 " name="рointName " type="s:string " /›
‹/s:sequence›
‹/s:complexType›
Элемент ‹message›
Элемент ‹message› используется для определения формата обмена запросами и ответами данного Web-метода. Поскольку один Web-сервис позволяет передачу множества сообщений между отправителем и получателем, одному WSDL-документу позволяется определять множество элементов ‹message›. Как правило, в этих определениях используются типы, указанные в рамках элемента ‹types›.
Независимо от количества элементов ‹message›, определенных в документе WSDL, они обычно "присутствуют" парами. Первое определение представляет входной формат сообщения, а второе – выходной формат того же сообщения. Например, метод Subtract() Web-сервиса CalculatorWebService определяет следующие элементы ‹message›.
‹wsdl:message name="SubtractSoapIn "›
‹wsdl:part name="parameters" element="tns:Subtract" /›
‹/wsdl:message›
‹wsdl: message name="SubtractSoapOut "›
‹wsdl:part name="parameters" element="tns:SubtractResponse" /›
‹/wsdl:message›
Здесь вы видите только связь SOAP соответствующего сервиса. Как говорилось в начале этой главы, Web-сервисы XML могут вызываться с помощью SOAP или HTTP-методов GET и POST. Но если вы разрешите связь HTTP POST (соответствующие объяснения будут предложены позже), генерируемый WSDL-код должен продемонстрировать следующие данные ‹message›.
‹wsdl: message name="SubtractHttpPostIn "›
‹part name="n1" type="s:string" /›
‹part name="n2" type="s:string" /›
‹wsdl:/message›
‹wsdl:message name="SubtractHttpPostOut "›
‹part name="Body" element="s0:int" /›
‹wsdl:/message›
Элементы ‹message› сами по себе не слишком полезны. Однако на эти определения сообщений ссылаются другие части WSDL-документа.
Замечание. Не все Web-методы требуют и запроса, и ответа. Если Web-метод является "односторонним", для него необходим только элемент ‹message› запроса. Обозначить Web-метод, как односторонний, можно с помощью атрибута .
Элемент ‹portType›
Элемент ‹portType› определяет различные связи, которые могут возникать между клиентом и сервером, и каждая такая связь представляется вложенным элементом ‹operation›. Несложно догадаться, что самыми типичными операциями здесь должны быть SOAP, HTTP GET и HTTP POST. Однако есть и другие операции. Например, односторонняя операция позволяет клиенту отправить сообщение данному Web-серверу, но не получить ответ (это похоже на вызов метода без ожидания возвращаемого значения). Операция "требование-ответ" позволяет серверу отправить, запрос во время ответа клиента (что можно рассматривать, как дополнение операции "запрос-ответ").
Чтобы проиллюстрировать формат необязательного вложенного элемента ‹operation›, рассмотрим WSDL-определение для метода Subtract().
‹wsdl portType name="CalculatorWebServiceSoap "›
‹wsdl:operation name="Subtract "›
‹wsdl:input message="tns:SubtractSoapIn " /›
‹wsdl:output message="tns:SubtractSoapOut " /›
‹ /wsdl:operation›
‹wsdl:/portType›
Обратите внимание на то, как элементы ‹input› и ‹output› ссылаются на соответствующее имя сообщения, определенное в рамках элемента ‹message›. Если бы для метода Subtract() был разрешен HTTP-метод POST, вы бы увидели следующий дополнительный элемент ‹operation›.
‹wsdl:portType name="CalculatorWebServiceHttpPost"›
‹wsdl:input message="s0:SubtractHttpPostIn
" /› ‹wsdl:output message= "s0:SubtractHttpPostOut
" /› ‹
wsdl:/operation› ‹wsdl:/portType› Наконец, учтите то, что если данный Web-метод описан с помощью свойства Description, элемент ‹operation› будет содержать вложенный элемент ‹documentation›. Элемент ‹binding› Этот элемент указывает точный формат обмена GET, POST и SOAP. Это самый "многословный" из всех элементов, содержащихся в контексте корневого элемента ‹definition›. Вот, например, определение элемента ‹binding› с описанием того, как вызывающая сторона может взаимодействовать с Web-методом MyMethod(). используя SOAP. ‹wsdl:binding name="СаlculatorWebServiceSoap12" type="tns:CalculatorWebServiceSoap
"› ‹soap12:binding transport="http://schemas.xmlsoap.org/soap/http
" /›
‹wsdl:operation name= "Subtract
"› ‹soap12:operation soapAction="http://www.IntertechTraining.com/Subtract
" style="document" /› ‹wsdl:input› ‹soap12:body use="literal
" /› ‹/wsdl:input› ‹wsdl:output› ‹soap12:body use="literal
" /› ‹/wsdl:output› ‹/wsdl:operation› ‹/wsdl:binding› Элемент ‹service› Наконец, у нас есть элемент ‹service›, который указывает характеристики самого Web-сервиса (например, его URL). Главной задачей этого элемента является описание множества портов, открытых данным Web-сервером. Для этого элемент ‹services› может использовать любое число вложенных элементов ‹port› (не путайте их с элементом ‹portType›). Вот как выглядит элемент ‹service› для CalculatorWebService. ‹wsdl:service name="CalculatorWebService
"› ‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›
Чудесный Web-сервис калькулятора
‹/wsdl:documentation› ‹wsdl:port name="CalculatorWebServiceSoap"
binding="tns
:CalculatorWebServiceSoap"
› ‹soap:address location="http://localhost:1109/CalculatorWebService/ Service.asmx"
/› ‹/wsdl:port› ‹wsdl:port name="CalculatorWebServiceSoap12"
binding= "tns
:CalculatorWebServiceSoap12
"› ‹soap12:address location="http://localhost:1109/CalculatorWebService/Service.asmx"
/› ‹/wsdl:port› ‹/wsdl:service› Итак, как видите, WSDL-код, автоматически возвращаемый сервером ITS, не является сверхсложным, но, поскольку WSDL представляет собой грамматику на основе XML, этот код достаточно "многословен". Тем не менее, теперь вы должны лучше понимать роль WSDL, так что давайте рассмотрим немного подробнее протоколы связи Web-сервисов XML. Замечание.
Напомним, что пространство имен System.Web.Services.Description содержит множество типов, которые позволяют программно читать и обрабатывать "сырой" WSDL-код (можете проверить сами, если вас это интересует). Предисловие
Заказчики заказчиков попросили заказчиков xsd файлы для структур, передаваемых реализуемыми Web-сервисами. Заказчики в ответ предложили заказчикам заказчиков сделать WSDL-ки. Т.о. неожиданно «на ровном месте» возникла необходимость сделать не просто xsd-схемы для валидации данных, а «целые WSDL-ки». Обычно WSDL-ки используются для SOAP, а у нас REST… Ранее я уже писал про
Введение
Термин Web-сервисы обычно ассоциируется с operation- или action-based сервисами, базирующимися на SOAP или WS* стандартах, таких как WS-Addressing или WS-Security. Термин REST Web-сервисы обычно относится к resource-based архитектуре Web-сервисов, передающих XML через HTTP. Каждый из этих архитектурных стилей имеет собственное место, но до недавнего времени, WSDL стандарт не поддерживал оба эти стиля. WSDL 1.1 HTTP binding был неадекватен для описания взаимодействия с помощью XML по HTTP, т.о. не было формального способа описать REST Web-сервисы с помощью WSDL. Публикация стандарта WSDL 2.0 (который был разработан с учётом необходимости описания REST Web-сервисов) в статусе рекомендации World Wide Web Consortium (W3C) дала язык для описания REST Web-сервисов. REST — архитектурный стиль трактующий Web как resource-centric приложение. Практически, это означает, что каждый URL в RESTful приложении представляет собой ресурс. URL-и просто понимать и запоминать. Например, книжный магазин может определить URL http://www.bookstore.com/books/ для списка продаваемых книг и http://www.bookstore.com/books/0321396855/ для деталей о конкретной книге с ISBN 0321396855. Это контрастирует с action-centric приложениями, обычно имеющими длинные сложношифованные URL-и, описывающими действия, которые необходимо выполнить, например http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855 . Параметры запроса используются для выбора необходимых данных. Используя пример книжного магазина, указание параметра subject ограничивает тематику книги. Например физика или детективы или к примеру URL http://www.bookstore.com/books/?subject=computers/eclipse — запрос возвращающий список книг про платформу Eclipse. Термин REST придумал Roy Fielding в своей кандидатской диссертации. Он рассматривал гиперссылки как средство для изменения (хранения) состояния приложения. Гиперлинки хранятся в ресурсах приложения и являются методом изменения состояния приложения, редиректа из одного состояния в другое. Обычно гиперлинки в (X)HTML предназначены для использования людьми, они не использовались в XML, который был предназначен для машинной обработки. Также как и (X)HTML, REST Web-сервисы испльзуют гиперлинки в XML. Традиционные Web-приложения получают доступ к ресурсам посредством HTTP GET или POST операций. RESTfull приложения работают с ресурсами в стиле «create, read, update, and delete (CRUD)» используя полные возможности HTTP протокола (POST, GET, PUT, and DELETE). Ещё одно важное замечание о REST приложении: RESTful приложения должны быть stateless. Это означает, что REST приложение не сохраняет никакого состояния сессии на стороне сервера. Вся информация, необходимая для выполнения запроса, передается в самом запросе. (Поэтому на повторяющиеся запросы сервер обязан отвечать одинаково прим. переводчика). Соответственно клиент может кешировать полученные ресурсы, что может значительно ускорить скорость работы приложения там, где сервис явно разрешает это. Чтобы узнать больше про REST, см ссылки к статье. WSDL и REST
WSDL содержит все детали о веб-сервисе, включая: Клиенты могут использовать перечисленные детали для взамодействия с сервисом. WSDL 2.0 был объявлен рекомендацией W3C в июне 2007. Эта версия WSDL стандарта была выпущена для решения проблем стандарта WSDL 1.1, многие из которых были обнаружены организацией Web Services Interoperability (WS-I). Кроме того в WSDL 2.0 улучшена поддержка HTTP bindings. WSDL сам является XML — подмножеством формально описывающим веб-сервис. Рассматривайте WSDL описание веб-сервиса как его API контракт с клиентом. В WSDL указывается адрес, допустимые способы передачи информации, интерфейса и типы сообщений веб-сервиса. Короче говоря, описание WSDL содержит всю информацию, необходимую клиенту для использования веб-сервиса. Применимость WSDL, выходит за пределы его использования в качестве контракта API. Являясь формальным определением, WSDL может быть использован софтом упрощающим реализацию веб-сервисов для таких операций как: Большинство программных средств для работы с веб-сервисами включают в себя поддержку WSDL 1.1. Последнее время растёт количество средств разработки веб-сервисов, поддерживающих WSDL 2.0. Проект Apache Web services состоит из двух подпроектов, которые в настоящее время поддерживают WSDL 2.0. Woden — парсер-валидатор WSDL 2.0 на базе Java. Apache Web services проект также предоставляет XSL (XSLT) трансформацию WSDL 2.0 под названием WSDL 2.0 pretty printer
, обеспечивающую лучшую человекочитаемость документа WSDL. Axis2 популярный engine веб-сервисов, (тоже от Apache) реализующий генерацию клиентского и серверного Java кода из документа WSDL 2.0. Описание REST веб-сервиса с помощью WSDL 2.0
Вы создаете книжный магазин, который с продвинутым URL: http://www.bookstore.com . Вы уже создали две службы REST Web: Ответ возвращается в XML-документах. Элемент interface
определяет список операций веб-сервиса, включая описание входных, выходных сообщений и сообщений об ошибках для операций, а также порядка передачи. Элемент binding
определяет, средства коммуникации клиента с веб-сервисом. В случае REST веб-сервисов, в качестве средства коммуникации указывается HTTP. Элемент service ассоциирует адреса веб-сервиса с конкретными интерфейсами (interface) и средствами коммуникации (binding). (Т.е. задает соответствие URL операции веб-сервиса и элементу binding
).
Привязываем book list к HTTP
Элемент binding
задает привязку веб-сервиса к конкретному протоколу передачи данных. Для привязки book list сервиса к HTTP нужно указать значение http://www.w3.org/ns/wsdl/http для атрибута type
элемента binding
. Элемент binding
может опционально ссылаться на interface
. Оставьте атрибут interface
пустым. Вы создадите его в следующем разделе. Если interface
ассоциирован с binding
, тогда binding
элемент может опционально определять дочерний элемент operation
, являющийся зеркальным для interface operation
элемента. Вам нужно создать заглушку элемента operation
и заполнить ссылку на operation
позже после создания interface
. Существует 4 HTTP communication метода Book list сервис читает запрос и соответственно оперирует с помощью HTTP GET. Установите метод GET для элемента operatioin используя атрибут method из WSDL 2.0 HTTP namespace. Для использования этого атрибута, вам нужно сначала определить namespace http://www.w3.org/ns/wsdl/http в элементе description
. Book list сервис binding определен на нижеследующем листинге. Укажите теперь binding
в элементе endpoint
: tns:BookListHTTPBinding.
Определение book list service operation
So far you’ve learned how to address and communicate with the book list Web service. Next you specify the book list service operation, which describes what the book list service does. Итак, вы научились задавать address и задавать binding (способ коммуникации) для веб-сервиса. Далее необходимо задать service operation, определяющую что делает book list веб-сервис. Элемент interface и его дочерний operation элемент используются для определения сервисных операций. В случае с book list, вы определяете одну операцию getBookList, возвращающую список книг. Затем определите три атрибута для элемента operation: Pattern
Используется для указания шаблона обмена сообщениями message exchange pattern
(MEP) для операции. MEP определяет последовательность сообщений для операции и их направление. В этом случае необходимо указать значение http://www.w3.org/ns/wsdl/in-out чтобы указать, что веб-сервис получает одно входное сообщение просьбой о списке книг, и посылает одно выходное сообщение со списком книг. Для поддержки этого MEP, указажите дочерние элементы input
и output
для элемента operation
. Эти элементы используют элементы описанные в XML schema, определяющие структуры сообщений. Подробности в следующем разделе. Style
Используется для указания дополнительной информации о работе. Укажите значение http://www.w3.org/ns/wsdl/style/iri , накладывающее ограничения на содержание входных элементов, такие как требование, что это только использовать XML schema элементы. wsdlx:safe
wsdlx:safe: From the WSDL extensions namespace, this attribute declares that this operation is idempotent. This type of operation doesn’t modify the resource and can therefore be called many times with the same results. To make use of this element, declare the WSDL extensions namespace http://www.w3.org/ns/wsdl-extensions on the description element. Этот атрибут из WSDL extentions namespace. Он определяет, что операция является idempotent
. Эта операция не модифицирует ресурс, поэтому может быть вызвана многократно с одинаковыми результатами. Чтобы использовать этот элемент, нужно объявить namespace WSDL extentions http://www.w3.org/ns/wsdl-extensions в корневом элементе (элементе description). Вы можете найти предопределенные Message Exchange Patterns, styles и wsdlx:safe определения по ссылке WSDL 2.0 Part 2: Adjuncts Ниже приведено определение book list сервиса с добавленным описанием interface
. После добавления interface теперь можно изменить binding operation элемент чтобы указать ссылки на описанные interface
и operation.
Определение сообщений сервиса book list operation
Веб-сервис book list использует два сообщения: входное и выходное. Вы должны описать структуры этих сообщений, чтобы клиентские программы знали что отправлять в адрес сервиса и что ожидать обратно. WSDL 2.0 supports multiple type systems for describing the message content, but XML schema is the only one in use. This section doesn’t cover the details of XML schema. XML schema is used in many other applications, like WSDL 1.1, and there are many good articles about it. This section highlights how to use XML schema for the book list REST Web service and how to use additional attributes defined by WSDL 2.0 to annotate a schema attribute. WSDL 2.0 поддерживает множество систем определения типов, но на практике используются только XML schema. Эта статья не вдается в детали XML schema. XML schema используется во многих других приложениях, например, WSDL 1.1, и есть много хороших статей о нем. (). В этом разделе демонстрируется, применение XML schema применительно к конкретному примеру REST сервиса book list, а также использование дополнительных атрибутов определенных в WSDL 2.0 для аннотации schema атрибута. Чтобы описать 2 сообщения для book list, необходимо описать 2 глобальных элемента. Ваше определение атрибута url использует в свою очередь 2 атрибута из WSDL extensions namespace. Атрибуты wsdlx:interface и wsdlx:binding задают interface и binding для сервиса. Программное обеспечение может использовать эту информацию для автоматического нахождения сервиса. Для использования этих атрибутов, укажите WSDL extentions namespace для элемента schema
. Также включите book details namespace из его WSDL 2.0 описания. XML schema для book list сервиса приведена ниже.
Для ссылки на input и output элементы, вы должны импортировать схему в ваш WSDL документ. Для импортирования сземы, используйте schema import элемент в разделе types как показано на листинге ниже. Кроме того, необходимо добавить ссылки на getBookList и Booklist элементы в interface operation input и output элементах и добавить пространства имен book list XML schema в корневой элемент WSDL. Готовый WSDL для book list веб-сервиса.
Примечание переводчика
Я позволил себе не переводить summary и ссылки. И то и другое смотреть у автора. в оригинальной статье . Надо сказать язык оригинала весьма тяжёл. Однако, надеюсь, статья окажется полезной. Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…
URL веб-сервиса
Механизмы коммуникации, корые понимает веб-сервис
Операции, которые может выполнять веб-сервис
Структура сообщений веб-сервиса
Введение
Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall.
Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:
Почему так кратко спросите вы? А по подробней нельзя? Наверное можно, но для этого придется обратиться к таким книгам как Машнин Т. «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 сообщения от клиента). Нам нужно сделать следующее:
Запуск веб-сервиса можно производить разными способами: либо описать класс с методом 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.сайт/"
,
"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.
