В чем разница между стилем документа и стилем RPC? - PullRequest
87 голосов
/ 30 января 2012

Может кто-нибудь объяснить мне различия между веб-сервисами в стиле Document и RPC? Помимо JAX-RPC, следующая версия - JAX-WS, которая поддерживает как Document, так и RPC стили. Я также понимаю, что веб-сервисы в стиле документа предназначены для асинхронной связи, при которой клиент не блокируется, пока не получен ответ.

В любом случае, используя JAX-WS, я в настоящее время аннотирую службу с помощью @ Webservice , генерирую WSDL и из этого WSDL я генерирую артефакты на стороне клиента.

Как только артефакты получены, в обоих стилях я вызываю метод в порту. Теперь это не отличается стилем RPC и стилем документа. Так в чем же разница и где эта разница видна?

Точно так же, чем SOAP через HTTP отличается от XML через HTTP? Ведь SOAP - это также XML-документ с пространством имен SOAP.

Ответы [ 6 ]

90 голосов
/ 04 февраля 2015

Может ли какое-то тело объяснить мне разницу между стилем документа и Веб-сервисы в стиле RPC?

Существует две модели стиля связи, которые используются для преобразования привязки 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 и стиль документа. Так в чем же разница и где это разница видна?

Место, где вы можете найти разницу - "ОТВЕТ"!

Стиль 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, можно проверить ответное сообщение SOAP в случае стиля DOCUMENT, но не в веб-службах стиля RPC.
  • Основной недостаток использования стиля RPC заключается в том, что он не поддержка более богатых типов данных и использование стиля документа в том, что он приносит некоторую сложность в форме XSD для определения более богатых типы данных.
  • Выбор использования одного из них зависит от требования к операции / методу и ожидаемые клиенты.

Точно так же, чем SOAP по HTTP отличается от XML по HTTP? После все SOAP - это также XML-документ с пространством имен SOAP. Так что же разница здесь?

Зачем нам нужен такой стандарт, как SOAP?Обмениваясь XML-документами по HTTP, две программы могут обмениваться богатой структурированной информацией без введения дополнительного стандарта, такого как SOAP, для явного описания формата конверта сообщения и способа кодирования структурированного содержимого.

SOAP предоставляет стандартпоэтому разработчикам не нужно придумывать собственный формат сообщений XML для каждой службы, которую они хотят сделать доступной.Учитывая сигнатуру метода сервиса, который должен быть вызван, спецификация SOAP предписывает однозначный формат сообщения XML.Любой разработчик, знакомый со спецификацией SOAP и работающий на любом языке программирования, может сформулировать правильный запрос SOAP XML для конкретной службы и понять ответ от службы, получив следующие сведения о службе.

  • Имя службы
  • Имена методов, реализованные службой
  • Подпись метода каждого метода
  • Адрес реализации службы (выражается в виде URI)

ИспользованиеSOAP упрощает процесс представления существующего программного компонента в качестве веб-службы, поскольку сигнатура метода службы идентифицирует структуру документа XML, используемую как для запроса, так и для ответа.

23 голосов
/ 20 мая 2013

Веб-сервис в стиле RPC использует имена метода и его параметры для генерации XML-структур, представляющих стек вызовов метода. Стиль документа указывает, что тело SOAP содержит документ XML, который может быть проверен по заранее заданному документу схемы XML.

Хорошая отправная точка: Привязка SOAP: разница между документом и веб-службами в стиле RPC

17 голосов
/ 09 февраля 2015

В определении WSDL привязки содержат операции, здесь указывается стиль для каждой операции.

Документ: В файле WSDL он определяет детали типов, имеющие либо встроенный, либо импортирует документ XSD, который описывает структуру (т. Е. Схему) сложных типов данных, которыми обмениваются те сервисные методы, которые слабо связаны , Стиль документа по умолчанию.

  • Advantage :
    • Используя этот стиль документа, мы можем проверять сообщения SOAP по заранее определенной схеме. Он поддерживает типы данных и шаблоны XML.
    • слабосвязанный.
  • Недостаток : Немного трудно понять.

В 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>  
  • Преимущество : Легко понять.
  • Неудобство :
    • мы не можем проверить сообщения SOAP.
    • тесно связаны

RPC: В WSDL нет типов
Документ: Секция типов будет доступна в WSDL

7 голосов
/ 27 октября 2014

Основной сценарий, в котором JAX-WS RPC и Документ используются следующим образом:

  • Удаленный вызов процедуры (RPC) шаблон используется, когда потребитель рассматривает веб-службу как одно логическое приложение или компонент с инкапсулированными данными.Сообщения запроса и ответа отображаются непосредственно на входные и выходные параметры вызова процедуры.

    Примерами этого типа шаблона RPC могут быть служба платежей или служба котировок акций.

  • Шаблон на основе документов используется вситуации, когда потребитель рассматривает веб-службу как более длительный бизнес-процесс, где документ запроса представляет собой полную единицу информации.Этот тип веб-службы может включать взаимодействие с человеком для , например, , как с документом запроса кредитной заявки с ответным документом, содержащим заявки от кредитных учреждений.Поскольку более длительные бизнес-процессы могут не иметь возможности немедленно вернуть запрошенный документ, шаблон на основе документов чаще встречается в архитектурах асинхронной связи.Документ / буквальный вариант SOAP используется для реализации шаблона веб-службы на основе документов.

3 голосов
/ 22 декабря 2013

Я думаю, что вы спрашиваете, в чем разница между RPC Literal, Document Literal и веб-службами 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 и веб-службы документов

1 голос
/ 10 июня 2019

Документ
Сообщения в стиле документа могут быть проверены на соответствие предварительно определенной схеме.В стиле документа сообщение 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>

Схема бесплатная

...