- PR -

Document/Literal or RPC/Encoded

1|2|3 次のページへ»
投稿者投稿内容
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-11-26 13:44
お世話になります。

Webサービスにおける通信方法において表題の２通りあると思いますが
いまいち理解しきれません。

色々見て調査はしているのですが、ニュアンスを理解しきれないのも
あります。

引用:

Document指向では送信するオブジェクトデータをそのまま SOAP Body 要素の子要素としてシリアライズします


引用:

style="document"の場合は、問い合わせにたいし、返答メッセージのBodyには構造体での戻り値ではなく、XML文書として埋め込まれます


いまいちピンときません。
おそらくイメージできないからだと思います。



今、Document/Literalが優位であるという風に言われていることから
何故優位なのかを知りたいと思っています。
引用:

Webサービスには次の２つの理由から、できうる限り Document/Literal のメッセージ・スタイルを使うべきです。まず、Web Service Interoperability (WS-I) Basic Profile 1.0に準拠する相互運用性が高まります。もう一つの理由はパフォーマンスに関連するこの記事に関係してきます。Document/Literal によって、メッセージはより小型、単純になります。SOAPメッセージ本体のXMLデータをメソッド名要素でラップする必要はなく、XMLエレメントにデータ・タイプ属性が挿入されません


データサイズが小さくて済むことが最大のメリットなのでしょうか？




まず、私の今のところの理解から行くと
・RPC/Encodedと比較してDocument/Literalはオブジェクトのシリアライズ回数
　が少ない。(※Document/Literalもシリアライズを行う場面はある)

このくらいなのですが・・。
この解釈自体間違ってるかも。

XML文書をそのままやり取りすると至るところで書かれていますが、結局双方
(サーバ・クライアント)の受け取り時には各プログラム言語にマッピングされ
シリアライズされると思うのですが合っていますでしょうか？
ただ、送信(クライアント→サーバ)時にはXML文書をそのまま渡すイメージ？
# ああ、でも結局プログラム言語からXML文書にシリアライズされるんじゃ・・
# ちょっと混乱します


また、サイズが小さいといいますが、たかだがメソッド名要素がなくなるだけ
のような気がするのですが、これがそんなに大きな要因になりえるのでしょうか？



こちらでWebLogic8を使い、簡単なサービスを作って、rpcとdocumentで引数
オブジェクトのサイズを変えてやり取りしてみましたが、クライアントから
のメソッドコール時間に両者変わりありませんでした。
性能面でも変わらない？


このような各種疑問がわいています。
どこか良い参考情報が載っている場所の紹介でも良いのでご助言お願いします。
kan
ベテラン
会議室デビュー日: 2002/11/28
投稿数: 55
投稿日時: 2004-11-26 16:38
IBM developerWorksの英語の記事ですけど、

Reap the benefits of document style Web services
http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.html

Which style of WSDL should I use?
http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-11-26 18:20
情報ありがとうございます。

英語は苦手ですが、ちょいと翻訳かけたりして
頑張ってみてみます。。
kan
ベテラン
会議室デビュー日: 2002/11/28
投稿数: 55
投稿日時: 2004-11-26 21:44
こんな感じでしょうか？

RPC/encoded -> ツールにおまかせすれば実装が簡単
Document/literal -> 相互運用性が高い、拡張性が高い、うまく設計・実装すれば性能がよい、データ量が多いときRPC/encodedよりは扱いやすい

WS-IではRPC/literalを推奨していたと思います。
kan
ベテラン
会議室デビュー日: 2002/11/28
投稿数: 55
投稿日時: 2004-11-27 13:31
RPC/encoded, Document/Literal, RPC/Literalの性能については以下に
説明があります。

Discover SOAP encoding's impact on Web service performance
http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-11-29 09:52
引用:

kanさんの書き込み (2004-11-26 21:44) より:
こんな感じでしょうか？

RPC/encoded -> ツールにおまかせすれば実装が簡単
Document/literal -> 相互運用性が高い、拡張性が高い、うまく設計・実装すれば性能がよい、データ量が多いときRPC/encodedよりは扱いやすい

WS-IではRPC/literalを推奨していたと思います。


色々ありがとうございます。

参考ページに関しては、かなり良い情報が載っていそうなので
参考にしてみます。

また、参考のページにも書いてありますが(ちらっと見た感じ)
引用:

RPC/encoded -> ツールにおまかせすれば実装が簡単

の感覚がいまいちわかりません。

現状試しているのはWebLogic8評価版なのですが
サーバ側(サービス側)での設定は非常に簡易にDocument/Literal
とRPC/Encodedを変更できます。
# style="rpc"かstyle="document"かの違いだけ。

開発者としては特に難しいことはないと思います。


これはツール側が進化してきて簡易になってきた
ということなのでしょうか。
一昔前はこんなことはなかった、ということでしょうか。
kan
ベテラン
会議室デビュー日: 2002/11/28
投稿数: 55
投稿日時: 2004-11-29 18:08
既存のコードからの自動生成に関して、.NET Frameworkは当初からdocument/literalと
rpc/encodedに対応してましたが、Javaのアプリサーバが対応したのは、最近かと思い
ます。
まだ対応していない製品もありますし、J2EE標準APIとしては、JAX-RPCのrpc/encoded
しかないと思います。

既存のコードがあってWebサービス化する場合よりも、やりとりするXML形式があって、
SOAPでラップする場合のdocument/literalについて考えてみると少し分かりやすいかと
思います。
(株)ぽち
ぬし
会議室デビュー日: 2002/09/10
投稿数: 376
投稿日時: 2004-11-29 19:58
色々コメントありがとうございます。

私も色々と見て感覚を養っているのですが

RPC
　相手のメソッド名を指定しなければならない
　まさにメソッドコールのイメージ
　シリアライズ・デシリアライズがS/C(サーバ・クライアント)で発生する

Document
　相手のメソッド名は気にしない。
　どういうことをしたいかという内容(メッセージ)を送る
　メッセージ解析がS/Cで発生する

というイメージを持っているのですがはずしてはいないでしょうか。


また、現状として

スタブが各種ツールにより自動生成され、スタブを通してアクセス(メソッドコール)
しているため、RPC,Documentどちらを使用していても開発者からしたらあまり変わり
はない。

と思っているのですが。

引用:

Document/literal -> 相互運用性が高い、拡張性が高い、うまく設計・実装すれば性能がよい、データ量が多いときRPC/encodedよりは扱いやすい


で言われている「拡張性」などでは、本来サービス側の引数の型が変化しても(int→
Stringなど)Document指向では、クライアントに影響はない(理想？)

ということなのでしょうか。
1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）