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


92

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

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

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

同様に、SOAP over HTTPはXML over HTTPとどのように異なりますか?やっぱりSOAPはSOAP名前空間を持つXML文書でもあります。


回答:


97

ドキュメントスタイルとRPCスタイルのWebサービスの違いを説明できる人はいますか?

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

ドキュメント・スタイルのモデルを使用することの利点は、あなたがSOAPボディにあなたがいる限り、SOAPメッセージの本文の内容は、任意のXMLインスタンスであるとして、それを好きなように構造化することができるということです。ドキュメントスタイルは、メッセージ指向スタイルとも呼ばれます。

ただし、 RPCスタイルモデルでは、SOAPリクエストボディの構造に、オペレーション名とメソッドパラメータのセットの両方が含まれている必要があります。RPCスタイルモデルは、メッセージ本文に含まれるXMLインスタンスに特定の構造を想定しています。

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

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

(SOAP)エンコードされた使用モデルでは、メッセージはXSDデータ型を使用する必要がありますが、メッセージの構造はユーザー定義のXMLスキーマに準拠する必要はありません。これにより、メッセージ本文を検証したり、メッセージ本文に対してXSLTベースの変換を使用したりすることが困難になります。

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

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

この記事の「どのスタイルのWSDLを使用する必要がありますか?読むことをお勧めしますさまざまなスタイルと、モデルを使用してWSDLバインディングをSOAPメッセージに変換し、それらの相対的な長所と短所をうまく説明しているRussell Butekによる。

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

違いがわかるところが「RESPONSE」!

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応答メッセージで気付いたように、ドキュメントスタイルの場合にSOAP応答メッセージを検証できますが、RPCスタイルのWebサービスでは検証できません。
  • RPCスタイルを使用することの基本的な欠点は、よりリッチなデータ型をサポートしないことであり、Documentスタイルを使用することの、よりリッチなデータ型を定義するためにXSDの形式にいくらか複雑さをもたらすことです。
  • これらの中から1つを選択するかどうかは、操作/メソッドの要件と予期されるクライアントによって異なります。

同様に、SOAP over HTTPはXML over HTTPとどのように異なりますか?やっぱりSOAPはSOAP名前空間を持つXML文書でもあります。ここでの違いは何ですか?

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

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

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

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


「どのスタイルのWSDLを使用すればよいですか?」記事リンク。
Boolean_Type

23

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

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


20

WSDL定義では、バインディングには操作が含まれます。ここでは、各操作のスタイルを示します。

Document: WSDLファイルで、インラインのあるタイプの詳細を指定するか、XSDドキュメントをインポートします。これは、疎結合になるサービスメソッドによって交換される複雑なデータタイプの構造(スキーマ)を記述します。ドキュメントスタイルがデフォルトです。

  • 利点
    • このDocumentスタイルを使用して、事前定義されたスキーマに対して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でタイプセクションを使用できます


参照にあるものを繰り返すだけです。この説明は、違いを理解するのに役立ちませんでした。
5

1
これは、間違いなくリファレンスやドキュメントからではありません-文法の誤りがたくさんあります
specialize

7

JAX-WS RPCおよびドキュメントスタイルが次のように使用される主なシナリオ :

  • リモートプロシージャコール(RPC)消費者がカプセル化されたデータを持つ単一の論理アプリケーションまたはコンポーネントとしてウェブサービスを見たときのパターンが使用されます。要求メッセージと応答メッセージは、プロシージャコールの入力パラメータと出力パラメータに直接マップされます。

    このタイプの例として、RPCパターンには、支払いサービスや株価サービスなどがあります。

  • ドキュメントベースのパターンは、消費者が要求文書は情報の完全なユニットを表し、長く実行しているビジネス・プロセスとして、Webサービスを閲覧する状況で使用されています。このタイプのWebサービスには、たとえば、融資機関からの入札を含む応答ドキュメントを含むクレジットアプリケーション要求ドキュメントの場合と同様に、人間の相互作用が含まれる場合があります。実行時間の長いビジネスプロセスでは、要求されたドキュメントをすぐに返すことができない場合があるため、ドキュメントベースのパターンは、非同期通信アーキテクチャでよく見られます。SOAPのドキュメント/リテラル​​バリエーションは、ドキュメントベースのWebサービスパターンを実装するために使用されます。


3

RPC Literal、Document Literal、Document Wrapped SOAP Webサービスの違いについてお伺いします。

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

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

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

Document WrappedをWebサービスのタイプとして選択することをお勧めします。

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

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

WSDLの例とJavaに重点を置いたコードの詳細なチュートリアル:SOAPとJAX-WS、RPCとドキュメントWebサービス


2

ドキュメント
ドキュメントスタイルのメッセージは、事前定義されたスキーマに対して検証できます。ドキュメントスタイルでは、SOAPメッセージは単一のドキュメントとして送信されます。スキーマの例:

  <types>  
   <xsd:schema> <xsd:import namespace="http://example.com/" 
    schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>  
   </xsd:schema>  
  </types>

ドキュメントスタイルのSOAP本文メッセージの例

  <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タイプに制限され、結果のWSDLはパラメータを定義および制約するタイプセクションもあります

リテラル デフォルトのスタイル。データはスキーマに従ってシリアル化されます。データ型はメッセージで指定されていませんが、soapメッセージの作成にはschema(namespace)への参照が使用されます。

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

スキーマフリー

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.