web-dev-qa-db-ja.com

ドキュメントスタイルのコミュニケーションとRPCスタイルのコミュニケーションの違いは何ですか？

DocumentとRPCスタイルのWebサービスの違いを誰かが説明できますか？ JAX-RPCとは別に、次のバージョンはJAX-WSであり、ドキュメントスタイルとRPCスタイルの両方をサポートします。また、ドキュメントスタイルのWebサービスは、応答が受信されるまでクライアントがブロックしない非同期通信向けであることも理解しています。

どちらの方法でも、JAX-WSを使用して、現在@ Webserviceでサービスに注釈を付け、WSDLを生成し、そのWSDLからクライアント側の成果物を生成します。

両方のスタイルでアーティファクトを受信したら、ポートでメソッドを呼び出します。現在、これはRPCスタイルとDocumentスタイルに違いはありません。それで、違いは何であり、その違いはどこに見えますか？

同様に、HTTP上のSOAPはHTTP上のXMLとどのように異なりますか？結局、SOAPもSOAP名前空間を持つXMLドキュメントです。

web-servicessoapwsdljax-wsrpc
87
Amrin

DocumentスタイルのWebサービスとRPCスタイルのWebサービスの違いを説明できる人はいますか？

WSDLバインディングをSOAPメッセージ本文に変換するために使用される2つの通信スタイルモデルがあります。それらは：ドキュメントとRPC

ドキュメントスタイルモデルを使用する利点は、SOAPメッセージ本文のコンテンツがあれば、SOAP本文を自由に構成できることです。任意のXMLインスタンスです。ドキュメントスタイルは、Message-Oriented styleとも呼ばれます。

ただし、RPCスタイルモデルの場合、SOAP要求本文の構造には、操作名とメソッドパラメーターのセットの両方が含まれている必要があります。 RPCスタイルモデルは、メッセージ本文に含まれるXMLインスタンスの特定の構造を想定しています。

さらに、WSDLバインディングをSOAPメッセージに変換するために使用される2つのエンコード使用モデルがあります。 リテラル、エンコード

リテラル使用モデルを使用する場合、本文の内容はユーザー定義のXML-schema（XSD）構造に準拠する必要があります。利点は2つあります。たとえば、ユーザー定義のXMLスキーマを使用してメッセージ本文を検証できます。また、XSLTなどの変換言語を使用してメッセージを変換することもできます。

（SOAP）encoded use modelを使用すると、メッセージはXSDデータ型を使用する必要がありますが、メッセージの構造はユーザー定義のXMLスキーマに準拠する必要はありません。これにより、メッセージ本文の検証や、メッセージ本文でのXSLTベースの変換の使用が困難になります。

さまざまなスタイルと使用モデルの組み合わせにより、WSDLバインディングをSOAPメッセージに変換する4つの異なる方法が提供されます。

Document/literal
Document/encoded
RPC/literal
RPC/encoded

この記事を読むことをお勧めします どのWSDLのスタイルを使用する必要がありますか Russell Butekによる、異なるスタイルの素敵な議論があり、モデルを使用してWSDLバインディングをSOAPメッセージ、およびそれらの相対的な長所と短所。

両方の通信スタイルでアーティファクトが受信されると、ポートでメソッドを呼び出します。現在、これはRPCスタイルとDocumentスタイルに違いはありません。それで、違いは何ですか、その違いはどこに見えますか？

違いを見つけることができる場所は「応答」です！

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); 
}

2番目の操作の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要素がWebサービスとクライアント間で交換されていることを示しています。この変更は、SOAPBindingアノテーションのスタイル属性を変更することによってのみ行われました。リッチデータタイプの2番目のメソッドの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>

結論

  • 2つのSOAP応答メッセージでお気づきのように、DOCUMENTスタイルの場合はSOAP応答メッセージを検証できますが、RPCスタイルのWebサービスは検証できません。
  • 基本的なRPCスタイルを使用することの欠点は、より豊富なデータ型をサポートしないことであり、ドキュメントスタイルを使用することは、より豊富なデータ型を定義するためにXSDの形で複雑さをもたらすことです.
  • これらのいずれかを使用する選択は、操作/メソッドの要件と予想されるクライアントに依存します。

同様に、HTTPを介したSOAPは、HTTPを介したXMLとどのように異なりますか？結局、SOAPもSOAP名前空間を持つXMLドキュメントです。それで、ここの違いは何ですか？

SOAPのような標準が必要なのはなぜですか？ HTTPを介してXMLドキュメントを交換することにより、2つのプログラムは、メッセージエンベロープ形式と構造化コンテンツをエンコードする方法を明示的に記述するSOAPなどの追加標準を導入せずに、豊富な構造化情報を交換できます。

SOAPは標準を提供するため、開発者は、利用可能にしたいサービスごとにカスタムXMLメッセージ形式を考案する必要がありません。呼び出されるサービスメソッドのシグネチャを指定すると、SOAP仕様は明確なXMLメッセージ形式を規定します。プログラミング言語で作業するSOAP仕様に精通している開発者は、特定のサービスに対する正しいSOAP XML要求を定式化し、次のサービスの詳細を取得することでサービスからの応答を理解できます。 。

  • サービス名
  • サービスによって実装されるメソッド名
  • 各メソッドのメソッドシグネチャ
  • サービス実装のアドレス（URIとして表現）

SOAPを使用すると、サービスのメソッドシグネチャが要求と応答の両方に使用されるXMLドキュメント構造を識別するため、既存のソフトウェアコンポーネントをWebサービスとして公開するプロセスが合理化されます。

91
09Q71AO534

RPCスタイルのWebサービスは、メソッドの名前とパラメーターを使用して、メソッドの呼び出しスタックを表すXML構造を生成します。ドキュメントスタイルは、SOAPボディに、事前定義されたXMLスキーマドキュメントに対して検証できるXMLドキュメントが含まれていることを示します。

良い出発点： SOAPバインディング：ドキュメントとRPCスタイルWebサービスの違い

23
Binu George

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で利用できます

17
Premraj

JAX-WS RPCおよびDocumentスタイルが使用される主なシナリオは次のとおりです。

  • リモートプロシージャコール（RPC）パターンは、コンシューマがWebサービスを、カプセル化されたデータを持つ単一の論理アプリケーションまたはコンポーネントとして表示するときに使用されます。要求および応答メッセージは、プロシージャコールの入力および出力パラメータに直接マップされます。

    このタイプのRPCパターンの例には、支払いサービスまたは株価サービスが含まれます。

  • document-based patternは、要求ドキュメントが情報の完全なユニットを表す、実行時間の長いビジネスプロセスとして消費者がWebサービスを見る状況で使用されます。このタイプのWebサービスには、貸出機関からの入札を含む応答ドキュメントを使用したクレジット申請リクエストドキュメントと同様に、例に対する人間の対話が含まれる場合があります。実行時間の長いビジネスプロセスでは要求されたドキュメントをすぐに返せない場合があるため、ドキュメントベースのパターンは非同期通信アーキテクチャでよく見られます。 SOAPのDocument/literalバリエーションは、ドキュメントベースのWebサービスパターンを実装するために使用されます。

7
Tarun Chaudhary

あなたが求めているのは、RPC Literal、Document Literal、Document Wrapped SOAP Webサービスの違いだと思います。

Document Webサービスはリテラルに区切られており、ラップされていることに注意してください。これらは主な違いの1つであり、後者はBP 1.1準拠であり、前者はそうではありません。

また、Document Literalでは、呼び出される操作は名前で指定されていませんが、Wrappedでは指定されています。これは、リクエストの対象となる操作名を簡単に把握できるという点で大きな違いだと思います。

RPCリテラルとDocument Wrappedの観点から、Document Wrappedリクエストは、WSDLのスキーマに対して簡単に検証/検証できます。これは大きな利点の1つです。

利点があるため、選択したWebサービスタイプとしてDocument Wrappedを使用することをお勧めします。

HTTP上のSOAPは、キャリアとしてHTTPにバインドされたSOAPプロトコルです。 SOAPは、SMTPまたはXXXでも可能です。 SOAPは、エンティティ（クライアントとサーバーなど）間の相互作用の方法を提供し、両方のエンティティは、プロトコルのセマンティクスに従って操作の引数/戻り値をマーシャリングできます。

XML over HTTPを使用していた場合（できます）、HTTP要求/応答のXMLペイロードであると単純に理解されます。マーシャリング/アンマーシャリング、エラー処理などのフレームワークを提供する必要があります。

Javaに重点を置いたWSDLとコードの例を含む詳細なチュートリアル： SOAPおよびJAX-WS、RPC対Document Web Services

3
Khanna111

ドキュメント
ドキュメントスタイルのメッセージは、事前定義されたスキーマに対して検証できます。ドキュメントスタイルでは、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スタイルはStringやIntegerなどの非常に単純なXSDタイプに制限され、結果のWSDLはパラメータを定義および制約するための型セクションもあります

Literalデフォルトのスタイル。データはスキーマに従ってシリアル化され、データ型はメッセージで指定されませんが、schema（namespace）への参照はsoapメッセージを構築するために使用されます。

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

スキーマフリー

1
Sumant Pandey