SOAP Over Java Messaging Service

作者 Boris Lublinsky , 翻訳者 鰈崎 義之 - CSKシステムズ 投稿日 2009年7月26日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

SOAP ,

JMS ,

メッセージング ,

Java EE ,

Java ,

Webサービス ,

SOA ,

W3C ,

言語 ,

仕様 ,

エンタープライズアーキテクチャ ,

Architecture ,

プログラミング

共有 |

原文(投稿日：2009/6/17)へのリンク

W3Cは、Java Message Service (JMS) をサポートするメッセージングシステムと、SOAP(SOAP 1.1とSOAP 1.2の両方)がバインドする仕様を定義している、SOAP over Java Message Service 1.0 のW3C勧告候補をリリースした。この勧告の主な目的は、

... 異なるWebサービスベンダ実装間の相互運用性を確実にすることである。それにより顧客は、インフラストラクチャの一部として、自身のWebサービスを実装することも可能となり、ベンダが提供するWebサービスとの相互運用性を得ることもできるだろう。

仕様は2つの主要な部分から成り立っている。SOAP/JMSの下位プロトコルバインディング - 標準準拠の実装には必須仕様 - と SOAP/JMSバインディングのためのWSDL(1.1と2.0の両方)の使い方 - 標準準拠の実装には任意仕様 - である。

SOAPの下位トランスポートバインディングは、Java Message Serviceを使ってSOAPメッセージを送受信する時のルールを定義している。SOAP/JMSの下位プロトコルバインディングでは、JMSの特徴・特性がどのようにSOAP書式レベルで"見えて"いるか、JMSの呼出がどのようにSOAPをサポートする必要があるか、メッセージコンテントがどのような特性とヘッダ - 例えば priority、soapAction、targetService のような - を含んでいてどう処理されるか、JMSサービスへの接続の詳細などを対象としている。

仕様では、soapjms:lookupVariantを通じてサービス宛先への接続を一般化している。それは、与えられた宛先名を見つけるために使われる技術を記述する 。仕様で必須となっている唯一のlookupVariantは、JNDIベースの jms-variant:jndi である。JNDIベースの lookupVariantをサポートするために、他の接続特性 - soapjms:destinationName、soapjms:jndiConnectionFactoryName、soapjms:jndiInitialContextFactory、soapjms:jndiURL、soapjms:jndiContextParameterType - が用意されている。JNDIでない場合の検索は、実装者が適切なマッピングを用意する必要がある。

仕様では、JMS独自のメッセージヘッダを公開することを可能にする、SOAPパラメータのセットも定義している。この中には、soapjms:deliveryMode、soapjms:timeToLive、soapjms:priority、soapjms:replyToName、soapjms:topicReplyToNameを含む。最後の2つは、基本SOAP定義でないWS-Addressingに属しているため、完全に場違いのようにも見える。

更なる柔軟性がSOAP仕様のJMSメッセージ特性を定義することにより提供されている。

• soapjms:targetService - サービスリクエストをディスパッチするためにターゲット実装によって使われる。一つのキュー上に多重多数のサービスがアクセスすることを可能にする
• soapjms:bindingVersion - 使用するSOAPバインディングのバージョンを示すために使われる
• soapjms:contentType - 一番目のメッセージペイロードのMIMEタイプを指定する。SOAP1.1、SOAP1.2、添付つきSOAPメッセージ、MTOMのどのメッセージペイロードを一番目のペイロードとして使っているかも特定する
• soapjms:soapAction - SOAP/HTTPとまったく同じ方法で使う
• soapjms:isFault - メッセージがフォルトメッセージであることを示す
• soapjms:requestURI - サービスのJMS URIを指定する。仕様では、宛先とパラメータ属性を表しているクエリパラメータ付のJMS宛先URIとして定義している

また仕様では、JMSメッセージタイプ、セキュリティ関連、メッセージ交換パターンも話題にしている。

仕様の第2章は、JMSバインディングのオペレーションの使用や制御を指示するために、WSDLをどのように使う必要があるかを記述している。

WSDL1.1の場合、仕様は以下のような拡張を定義している。

• wsdl11soap11:binding 要素のトランスポート属性は、JMSトランスポートを反映する新しいURLを取得する
• WSDL仕様によって明示的に禁止されているにもかかわらず、SOAPActionヘッダの使用を許可する
• バインディングのふるまい(接続パラメータ、ランタイム設定)を制御するためのさまざまなプロパティをセットする方法を定義する
• JMS URIを使用してサービスの位置を決める

そしてWSDL 2.0の場合、拡張は以下のようになっている。

• wsoap:protocolバインディング要素の属性は、JMSトランスポートを反映する新しいURLを取得する
• バインディングのふるまい(接続パラメータ、ランタイム設定)を制御するためのさまざまなプロパティをセットする方法を定義する
• JMS URIを使用してサービスの位置を決める

SOAP over HTTP はメッセージング実装の相互運用を可能にするが、無停止稼動やデータ損失ゼロを達成する必要がある多くのミッションクリティカルシステムにおいては、メッセージングは、より適切な下位の配送手段をサポートしなければならない。その結果、Javaと.NETの両方における多くのWebサービス実装は、独自実装のSOAP over メッセージングのサポートを提供している。この観点から、SOAPのメッセージへのバインディングの仕様は長年の懸案だった。

一方、SOAPのJMSへのマッピングの仕様は、仕様のゴール"...異なるWebサービスベンダ実装間の相互運用性を確実にする"への解決策を提供しているとは思えない。まず、この仕様は、.NETやメインフレーム実装を除外して、SOAPとJMSをバインドするだけである。また、この仕様は、SOAPと単一の企業内でさえ相互運用性の問題の原因となり得るJNDIを結び付ける。- 典型的には複数の異なるアプリケーションサーバクラスタは、それぞれ独自のJNDI実装がある。最後に、Advanced Message Queuing Protocol (AMQP)が使われない限り、異なるベンダーのメッセージング実装間の相互運用性が確実になることはない。