Может ли кто-нибудь объяснить мне разницу между веб-сервисами в стиле Document и RPC? Помимо JAX-RPC, следующей версией является JAX-WS, которая поддерживает стили Document и RPC. Я также понимаю, что веб-службы в стиле документа предназначены для асинхронной связи, когда клиент не будет блокироваться, пока не будет получен ответ.
В любом случае, используя JAX-WS, я в настоящее время аннотирую службу с помощью @Webservice , генерирую WSDL и из этого WSDL генерирую артефакты на стороне клиента.
После получения артефактов в обоих стилях я вызываю метод порта. Теперь это не отличается по стилю RPC и стилю документа. Так в чем же разница и где эта разница видна?
Точно так же, чем протокол SOAP через HTTP отличается от XML через HTTP? В конце концов, SOAP - это также XML-документ с пространством имен SOAP.
Ответы:
Существуют две модели стиля связи, которые используются для преобразования привязки WSDL в тело сообщения SOAP. Это: Документ и RPC.
Преимущество использования модели стиля документа является то , что вы можете структурировать телу SOAP так , как вы хотите его до тех пор , пока содержание тела SOAP сообщений является любым произвольным экземпляром XML. Стиль документа также называется стилем, ориентированным на сообщения .
Однако в модели стиля RPC структура тела запроса SOAP должна содержать как имя операции, так и набор параметров метода. Модель стиля RPC предполагает особую структуру экземпляра XML, содержащегося в теле сообщения.
Кроме того, существуют две модели использования кодирования, которые используются для преобразования привязки WSDL в сообщение SOAP. Они бывают: буквальными и закодированными.
При использовании модели буквального использования содержимое тела должно соответствовать структуре определяемой пользователем XML-схемы (XSD) . Преимущество двоякое. Во-первых, вы можете проверить тело сообщения с помощью определяемой пользователем XML-схемы, кроме того, вы также можете преобразовать сообщение, используя язык преобразования, такой как XSLT.
В модели использования с кодировкой (SOAP) сообщение должно использовать типы данных XSD, но структура сообщения не обязательно должна соответствовать какой-либо пользовательской схеме XML. Это затрудняет проверку тела сообщения или использование преобразований на основе XSLT в теле сообщения.
Комбинация различных стилей и моделей использования дает нам четыре разных способа преобразования привязки WSDL в сообщение SOAP.
Document/literal Document/encoded RPC/literal RPC/encodedЯ бы порекомендовал вам прочитать эту статью под названием Какой стиль WSDL мне следует использовать? Автор Рассел Бутек, в котором хорошо обсуждаются различные стили и модели использования для перевода привязки WSDL к сообщению SOAP, а также их относительные сильные и слабые стороны.
Место, где можно найти разницу, - это «ОТВЕТ»!
Стиль RPC:
package com.sample; import java.util.ArrayList; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; import javax.jws.soap.SOAPBinding.Style; @WebService @SOAPBinding(style=Style.RPC) public interface StockPrice { public String getStockPrice(String stockName); public ArrayList getStockPriceList(ArrayList stockNameList); }Сообщение SOAP для второй операции будет пустым и будет выглядеть так:
Ответ стиля RPC:
<ns2:getStockPriceListResponse xmlns:ns2="http://sample.com/"> <return/> </ns2:getStockPriceListResponse> </S:Body> </S:Envelope>Стиль документа:
package com.sample; import java.util.ArrayList; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; import javax.jws.soap.SOAPBinding.Style; @WebService @SOAPBinding(style=Style.DOCUMENT) public interface StockPrice { public String getStockPrice(String stockName); public ArrayList getStockPriceList(ArrayList stockNameList); }Если мы запустим клиент для указанного выше SEI, на выходе получим:
123 [123, 456]
Эти выходные данные показывают, что элементы ArrayList обмениваются между веб-службой и клиентом. Это изменение было сделано только путем изменения атрибута стиля аннотации SOAPBinding. Сообщение SOAP для второго метода с более богатым типом данных показано ниже для справки:
Ответ стиля документа:
<ns2:getStockPriceListResponse xmlns:ns2="http://sample.com/"> <return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">123</return> <return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">456</return> </ns2:getStockPriceListResponse> </S:Body> </S:Envelope>Вывод
Зачем нам нужен такой стандарт, как SOAP? Обмениваясь XML-документами через HTTP, две программы могут обмениваться обширной структурированной информацией без введения дополнительного стандарта, такого как SOAP, для явного описания формата конверта сообщения и способа кодирования структурированного содержимого.
SOAP предоставляет стандарт, так что разработчикам не нужно изобретать собственный формат сообщений XML для каждой службы, которую они хотят сделать доступной. Учитывая сигнатуру вызываемого метода службы, спецификация SOAP предписывает однозначный формат сообщения XML. Любой разработчик, знакомый со спецификацией SOAP, работающий на любом языке программирования, может сформулировать правильный запрос SOAP XML для конкретной службы и понять ответ службы, получив следующие сведения о службе.
Использование SOAP упрощает процесс представления существующего программного компонента как веб-службы, поскольку подпись метода службы идентифицирует структуру XML-документа, используемую как для запроса, так и для ответа.
источник
Веб-служба в стиле RPC использует имена метода и его параметры для создания XML-структур, представляющих стек вызовов метода. Стиль документа указывает, что тело SOAP содержит XML-документ, который можно проверить на соответствие предварительно определенному документу схемы XML.
Хорошая отправная точка: привязка SOAP: разница между веб-службами в стиле документов и RPC
источник
В определении WSDL привязки содержат операции, здесь есть стиль для каждой операции.
Документ: В файле WSDL он определяет детали типов, которые либо имеют встроенный, либо импортирует документ XSD, который описывает структуру (т.е. схему) сложных типов данных, которыми обмениваются эти методы службы, которые делают слабосвязанными. Стиль документа - по умолчанию.
В типах WSDL элемент выглядит следующим образом:
<types> <xsd:schema> <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/> </xsd:schema> </types>Схема импортируется из внешней ссылки.
RPC : в файле WSDL он не создает схему типов, в элементах сообщения он определяет атрибуты имени и типа, что делает их тесно связанными.
<types/> <message name="getHelloWorldAsString"> <part name="arg0" type="xsd:string"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="return" type="xsd:string"/> </message>RPC: нет типов в
документе WSDL : раздел типов будет доступен в WSDL
источник
Основной сценарий, в котором используются JAX-WS RPC и стиль документа , выглядит следующим образом:
Удаленный вызов процедур (RPC) шаблон используется , когда потребитель просматривает веб - службу в качестве единого логического приложения или компоненты с капсулированными данными. Сообщения запроса и ответа отображаются непосредственно на входные и выходные параметры вызова процедуры.
Примеры этого типа шаблона RPC могут включать в себя платежную службу или службу котировок акций.
Документ на основе шаблон используется в тех случаях , когда потребитель видом на веб - службу в качестве более длинного бизнес - процесса , в котором запрос документ представляет собой полный блок информации. Этот тип веб-службы может включать взаимодействие человека, например, с документом запроса кредитной заявки с ответным документом, содержащим заявки от кредитных организаций. Поскольку более длительные бизнес-процессы могут не иметь возможности немедленно вернуть запрошенный документ, шаблон на основе документов чаще встречается в архитектурах асинхронной связи. Вариант SOAP Document / literal используется для реализации шаблона веб-службы на основе документов.
источник
Я думаю, что вы спрашиваете о разнице между веб-службами RPC Literal, Document Literal и Document Wrapped SOAP.
Обратите внимание, что веб-сервисы Document также делятся на буквальные и упакованные, и они разные - одно из основных различий состоит в том, что последние соответствуют BP 1.1, а первые - нет.
Кроме того, в Document Literal вызываемая операция не указывается в терминах ее имени, тогда как в Wrapped это так. На мой взгляд, это существенная разница с точки зрения простого определения имени операции, для которой предназначен запрос.
Что касается литерала RPC по сравнению с Document Wrapped, то запрос Document Wrapped можно легко проверить на соответствие схеме в WSDL - это одно большое преимущество.
Я бы предложил использовать Document Wrapped в качестве предпочтительного типа веб-службы из-за ее преимуществ.
SOAP на HTTP - это протокол SOAP, привязанный к HTTP в качестве носителя. SOAP также может быть через SMTP или XXX. SOAP обеспечивает способ взаимодействия между объектами (например, клиентом и серверами), и оба объекта могут маршалировать аргументы операции / возвращаемые значения в соответствии с семантикой протокола.
Если вы использовали XML поверх HTTP (и можете), это просто понимается как полезная нагрузка XML в запросе / ответе HTTP. Вам нужно будет предоставить структуру для маршалинга / демаршализации, обработки ошибок и так далее.
Подробное руководство с примерами WSDL и кода с акцентом на Java: SOAP и JAX-WS, RPC и веб-службы документов.
источник
Документ
Сообщения в стиле документа можно проверить по заранее определенной схеме. В стиле документа сообщение SOAP отправляется как один документ. Пример схемы:
<types> <xsd:schema> <xsd:import namespace="http://example.com/" schemaLocation="http://localhost:8080/ws/hello?xsd=1"/> </xsd:schema> </types>Пример сообщения мыльного тела в стиле документа
<message name="getHelloWorldAsString"> <part name="parameters" element="tns:getHelloWorldAsString"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/> </message>Сообщение в стиле документа слабо связано.
Сообщения в стиле RPC RPC используют имя метода и параметры для создания структуры XML. сообщения сложно проверить по схеме. В стиле RPC сообщение SOAP отправляется как можно больше элементов.
<message name="getHelloWorldAsString"> <part name="arg0"> type="xsd:string"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="return" > type="xsd:string"/> </message>Здесь каждый параметр задается дискретно, сообщение стиля RPC тесно связано, обычно является статическим, требуя изменений для клиента при изменении сигнатуры метода.Стиль rpc ограничен очень простыми типами XSD, такими как String и Integer, и результирующий WSDL не будет даже есть раздел типов для определения и ограничения параметров
Literal По умолчанию стиль. Данные сериализуются в соответствии со схемой, тип данных не указан в сообщениях, но ссылка на схему (пространство имен) используется для создания мыльных сообщений.
<soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body>Кодированный тип данных, указанный в каждом параметре
<soap:body> <myMethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </myMethod> </soap:body>Схема бесплатно
источник