ドキュメントスタイルと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サービスとして公開するプロセスが合理化されます。