Подтвердить что ты не робот

В чем разница между стилем документа и связью стиля RPC?

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

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

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

Аналогично, каким образом SOAP через HTTP отличается от XML через HTTP? В конце концов, SOAP также является XML-документом с пространством имен SOAP.

4b9b3361

ОТВЕТЫ

Ответ 1

Может ли какой-то орган объяснить мне различия между стилем документа и Веб-службы стиля 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 должен использовать? от Russell Butek, который хорошо обсуждает разные стиль и модели использования, чтобы перевести привязку 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 заключается в том, что он не поддержка более богатых типов данных и использование стиля Document - это то, что он приносит некоторую сложность в форме XSD для определения более богатых типы данных.
  • Выбор использования одного из них зависит от требования к работе/методам и ожидаемые клиенты.

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

  • Преимущество:
    • Используя этот стиль документа, мы можем проверять сообщения 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

Ответ 4

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

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

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

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

Ответ 5

Я думаю, что вы просите разницу между литературой RPC Literal, Document Literal и Web-сервисами, обернутыми документами.

Обратите внимание, что веб-службы Document разграничиваются в литеральные и завернутые, и они отличаются друг от друга. Одно из главных отличий заключается в том, что последний соответствует требованиям BP 1.1, а первый - нет.

Кроме того, в документе Literal операция, которая должна быть вызвана, не указывается в терминах ее имени, тогда как в Wrapped это. Это, я думаю, является значительной разницей в том, что вы легко можете определить имя операции, для которой нужен запрос.

В терминах литералов RPC и Document Wrapped запрос на документацию может быть легко проверен/проверен на соответствие схеме в WSDL - одно большое преимущество.

Я бы предложил использовать Document Wrapped в качестве выбора типа веб-сервиса из-за его преимуществ.

SOAP на HTTP - это протокол SOAP, связанный с HTTP в качестве носителя. SOAP может быть также SMTP или XXX. SOAP обеспечивает способ взаимодействия между сущностями (например, клиент и сервер), и оба объекта могут маршализовать аргументы/возвращаемые значения в соответствии с семантикой протокола.

Если вы используете XML через HTTP (и можете), его просто понимают как полезную нагрузку XML на HTTP-запрос/ответ. Вам нужно будет предоставить фреймворк для маршала/отмены, обработки ошибок и т.д.

Подробный учебник с примерами WSDL и кода с акцентом на Java: SOAP и JAX-WS, RPC и веб-службы документов

Ответ 6

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

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