У чому різниця між стилем документа та спілкуванням у стилі RPC?


92

Хтось може пояснити мені різницю між веб-послугами в стилі Document та RPC? Окрім JAX-RPC, наступною версією є JAX-WS, яка підтримує стилі Document і RPC. Я також розумію, що веб-послуги в стилі документа призначені для асинхронного спілкування, коли клієнт не буде блокувати до отримання відповіді.

У будь-якому випадку, використовуючи JAX-WS, я в даний час коментую службу @Webservice , генерую WSDL і з цього WSDL генерую артефакти на стороні клієнта.

Після отримання артефактів в обох стилях я викликаю метод на порту. Зараз це не відрізняється за стилем RPC та стилем документа. То в чому різниця і де ця різниця видно?

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


4
можливий дублікат веб-служб, що базуються
skaffman

Відповіді:


97

Чи може хтось пояснити мені різницю між стилем документа та веб-послугами у стилі 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, що використовується як для запиту, так і для відповіді.


Особлива подяка за "Який стиль WSDL я повинен використовувати?" посилання на статтю.
Boolean_Type

23

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

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


20

У визначенні 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


Просто повторив те, що є в посиланні. Це пояснення не допомогло мені зрозуміти різницю.
кінтунт

1
це, безумовно, не з посилання або документації - вона повна граматичних помилок
спеціалізація

7

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

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

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

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


3

Я думаю, що ви запитуєте різницю між веб-службами RPC Literal, Document Literal та Document Wrapped SOAP.

Зверніть увагу, що веб-служби Document розмежовуються на буквальні та обгорнуті, а також вони різні - одна з основних відмінностей полягає в тому, що остання відповідає стандарту BP 1.1, а перша - ні.

Крім того, у Document Literal операція, яку потрібно викликати, не вказана в термінах її назви, тоді як у Wrapped - це так. Я думаю, це суттєва різниця з точки зору легкого з’ясування назви операції, для якої призначений запит.

З точки зору літералу RPC в порівнянні з документом, який обертається, запит, який переноситься в документ, можна легко перевірити / перевірити на основі схеми в WSDL - одна велика перевага.

Я б запропонував використовувати Document Wrapped як тип веб-сервісу на вибір через його переваги.

SOAP на HTTP - це протокол SOAP, прив’язаний до HTTP як носія. SOAP також може бути через SMTP або XXX. SOAP забезпечує спосіб взаємодії між сутностями (наприклад, клієнтом та серверами), і обидві сутності можуть маршувати аргументи операцій / повертати значення відповідно до семантики протоколу.

Якщо ви використовували XML через HTTP (і можете), це просто розуміється як корисне навантаження XML на запит / відповідь HTTP. Вам потрібно буде надати основу для маршала / немаршала, обробки помилок тощо.

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


2

Документ
Повідомлення стилю документа можна перевірити за попередньо визначеною схемою. У стилі документа повідомлення 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 не буде навіть мати розділ типів для визначення та обмеження параметрів

Буквальний За замовчуванням стиль. Дані серіалізуються відповідно до схеми, тип даних, не вказаний у повідомленнях, але посилання на схему (простір імен) використовується для побудови мильних повідомлень.

   <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>

Схема безкоштовна

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.