- PR -

JAXMはどこに？

«前のページへ 1|2
投稿者投稿内容
よねくら
常連さん
会議室デビュー日: 2002/04/24
投稿数: 29
投稿日時: 2003-09-25 12:46
回答ありがとうございました。

引用:

しかしながら、これがNotificationやSolicit-Response型のメッセージングをサポートする場合、トピックベーストメッセージングをサポートする場合などjavax.xml.messagingパッケージ内のインタフェースは便利だと思います。J2EEでいえば、メッセージドリブンBeanでSOAPを利用するシーンなどを想定してみてください。


そのような、SOAPの事例は聞かないですよね。SOAPはWebサービスで使うもの、それ以外の用途はない、なんていう固定観念があるのでしょうか。HTTPでP2Pのメッセージ交換ならSAAJで十分ですよね。
Paul
ベテラン
会議室デビュー日: 2002/04/30
投稿数: 75
お住まい・勤務地: 東京
投稿日時: 2003-09-25 17:57
中込です。

引用:

そのような、SOAPの事例は聞かないですよね。SOAPはWebサービスで使うもの、それ以外の用途はない、なんていう固定観念があるのでしょうか。HTTPでP2Pのメッセージ交換ならSAAJで十分ですよね。

SOAP over SMTP(POP3)を実装し、先日、ソリューションとしての販売をアナウンスしました。
http://www.beacon-it.co.jp/news/pressrelease/2003/p20030909.shtml
実際にはSAAJを使ったのですが、JAXMのインタフェースを実装した方がデザインとしてはきれいだったかもしれないと思っています。

いずれにしましても、トランスポートプロトコルが限定されないのがSOAPの利点です。ところが、WS-I Basic Profileでは、これをHTTP(およびHTTPS)に限定するというアプローチをとっています。トレードオフは十分理解できますが、私にはとても忌々しきことに思えます。
よねくら
常連さん
会議室デビュー日: 2002/04/24
投稿数: 29
投稿日時: 2003-09-25 18:16
引用:

いずれにしましても、トランスポートプロトコルが限定されないのがSOAPの利点です。ところが、WS-I Basic Profileでは、これをHTTP(およびHTTPS)に限定するというアプローチをとっています。トレードオフは十分理解できますが、私にはとても忌々しきことに思えます。


Webサービスの発端が、MSのDCOMの代替であるということを考えると、同期型のプロトコルのみを対象とするのは仕方ないのかなぁという感じです。

ところで、SOAP over SMTP は興味深いですね。リクエストとレスポンスのメッセージの対応付けは、SOAPヘッダを使うのですか？
Paul
ベテラン
会議室デビュー日: 2002/04/30
投稿数: 75
お住まい・勤務地: 東京
投稿日時: 2003-09-25 18:39
中込です。

引用:

ところで、SOAP over SMTP は興味深いですね。リクエストとレスポンスのメッセージの対応付けは、SOAPヘッダを使うのですか？

プロトコルバインディングヘッダを使いました。
具体的には Message-Id: の値を References: ヘッダに設定するようにしました。
よねくら
常連さん
会議室デビュー日: 2002/04/24
投稿数: 29
投稿日時: 2003-09-25 18:50
引用:

プロトコルバインディングヘッダを使いました。


そうですか。
つくづく、SOAPヘッダは何のためにあるのかと思いますね。そもそも、ヘッダを使わなければ、エンベロープも意味がないように思います。
Paul
ベテラン
会議室デビュー日: 2002/04/30
投稿数: 75
お住まい・勤務地: 東京
投稿日時: 2003-09-26 10:28
引用:

つくづく、SOAPヘッダは何のためにあるのかと思いますね。そもそも、ヘッダを使わなければ、エンベロープも意味がないように思います。

SOAPヘッダは重要です。SOAPの主要な拡張メカニズムであるからです。

当方がSOAP over SMTPの実装において、リクエストとレスポンスの対応付けにプロトコルバインディングヘッダを利用し、SOAPヘッダを利用しなかった理由は、SOAPヘッダを軽視したためではありません。
SMTP(POP3)というトランスポートにおいてのみ意味を持つ情報を、SOAPという上位のプロトコルで管理すべきではないと判断したからです。トランスポート独自の問題は極力そのレイヤで自己解決する方が、サービスに対するトランスポート独立のデザインを確保しやすかったのです。

反対に、トランスポートに依存しないSOAP拡張はSOAPヘッダに入れるべきです。たとえば、セション管理なども、CookieやURL書き換えなどのを使うのではなく、SOAPヘッダを利用することでトランスポート独立になります。ただ、標準がない段階での実装(SOAPヘッダの任意の利用)は、あくまで独自実装となってしまうため、デメリットも大きいのです。
そこで、WS-Security、WS-Routing、WS-Reliability、WS-Transaction、WS-Coordination等々、この拡張メカニズム(SOAPヘッダ)を利用した標準の制定が盛んに行われているのです。今後ますますその重要性は高まっていくことでしょう。

[ メッセージ編集済み 編集者: nakagome 編集日時 2003-09-27 20:58 ]
«前のページへ 1|2

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