| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11g リリース1(11.1.1.4.0) B61435-02 |
|
 前 |
 次 |
以下の項では、Oracle Service BusとWebLogic JMS間、およびOracle Service BusとWebSphere MQ間の相互運用性に関連する機能および概念について説明します。
Java API for XML-Remote Procedure Call (JAX-RPC)は、J2EEを使用してWebサービスを構築しデプロイするコアJava APIと見なすことができます。JAX-RPCは、XML型とJava型とのマッピングの複雑さや、XML SOAPメッセージの処理に関する低レベルの詳細を開発者から切り離すことで、Webサービス・アプリケーションを構築するための簡単かつ堅牢なプラットフォームを提供します。JAX-RPCは、次の2つのプログラミング・モデルを提供することによって、メソッド呼出しパラダイムを導入します。
JavaクラスまたはステートレスEJBコンポーネントを使用してWebサービス・エンドポイントを開発するためのサーバー側モデル
ローカル・オブジェクトとしてWebサービスにアクセスするJavaクライアントを構築するためのクライアント側モデル
JAX-RPCでは、SOAPの使用と、他のテクノロジによって構築されたその他のWebサービスとの相互運用性が要求されます。ステートレス・セッションEJB、またはビジネス・ロジックを実行するJavaクラスがすでにある場合、J2EEではJAX-RPCを使用した標準的な方法でサービスとしてエクスポーズできます。
すべて のOracle Service Busのサービス・タイプでJMSトランスポートがサポートされています。2.3項「プロキシ・サービスの操作」および2.2項「ビジネス・サービスの操作」の説明に従って、JMSトランスポートを使用するようにプロキシ・サービスとビジネス・サービスを構成する必要があります。
Oracle WebLogic Server JMSの詳細は、次の項目を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のアプリケーションの管理に関する項
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSサーバーの構成に関するトピック
|
注意: Oracle Service Busでは、リモート・トランザクション・サポートの構成に不可欠なMQ Extended Transactional Clientがサポートされています。 |
メッセージングは次のように分類できます。
一方向
同期のリクエスト/レスポンス
非同期のリクエスト/レスポンス
ただし、JMSでのメッセージングは、一方向または非同期のリクエスト/レスポンスのみです。JMSを使用した非同期のリクエスト/レスポンス・メッセージングは、HTTPまたはHTTPSを使用したメッセージングにかわるものです。
非同期のリクエスト/レスポンス・メッセージングを使用する利点は次のとおりです。
レスポンスを待機する間、リクエスト・スレッドがブロックされることはありません。これにより、多数のブロッキング・リクエスト/レスポンス呼出しが行われた場合に生じる可能性のある、スレッドの管理上の問題が解消されます。ただし、HTTPとHTTPSは、操作の非ブロッキング・モードをサポートしています。
メッセージングは次が可能であるため、HTTPよりも信頼できます:
ディスク上に保持される
サービスを利用できないときに、キューに格納される
メッセージの処理時にサーバーにエラーや障害が発生した場合、メッセージを再配信できます。
IBM WebSphere MQを使用している場合、特定のメインフレームとの対話には非同期のリクエスト/レスポンス・メッセージを使用することをお薦めします。非同期サービスは、使用するJMSリクエスト/レスポンス・パターンに応じて相関IDまたはメッセージIDを返す必要があります。Oracle Service Busで使用するどちらのID形式も、IBM WebSphere MQとの互換性およびMQネイティブ・インタフェースを使用する対象サービスとの互換性があります。詳細は、30.8項「JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン」を参照してください。
非同期のリクエスト/レスポンス・メッセージは、アウトバウンド・トランスポートとインバウンド・トランスポートによって処理されます。つまり、トランスポート方式固有のデータである$outboundと$inboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのメッセージ・フローに違いはありません。
Oracle Service Busは、同期と非同期のリクエスト/レスポンスのブリッジングをサポートしています。たとえば、HTTPを使用してプロキシ・サービスを呼び出すことができ、呼び出されたプロキシ・サービスは、JMSリクエスト/レスポンス・ビジネス・サービスにルーティングされます。これを同期から非同期へのサービスの切替えと呼びます。
SOAPはトランスポート方式に依存しないため、SOAPトランスポートでHTTPのかわりにJMSを使用できます。特に企業顧客の場合、SOAP/JMSトランスポートが必要となります。Oracle Service Busは、JMSリクエスト/レスポンスでのSOAPメッセージをサポートしています。また、SOAPベースのOracle WebLogic Serverクライアントおよびサービスとの相互運用もサポートしています。
JMSは、信頼性の高いメッセージング方法でもあります。
JMSバインドを使用してOracle WebLogic Serverでサービスを構成するときは、次のSOAP-JMS URL形式をOracle WebLogic Serverで使用してください。
jms://host:port/contextURI/serviceName?URI=destJndiName
Oracle Service Busでサービスを構成する場合、URLは次の形式で指定する必要があります。
jms://host:port/connection_factory/jndi_destination
どちらの形式でも同じjndi_destinationを使用します。jndi_destinationは、対象Oracle WebLogic Serverの既存のQueueConnectionFactoryのJNDI名である必要があります。
Oracle Service BusからOracle WebLogic Serverサービスを呼び出す場合は、リクエストをビジネス・サービスに送信する前に、メッセージ・フロー内でアウトバウンド変数($outbound)に値/contextURI/serviceNameのJMSプロパティとしてURIを設定する必要があります。このプロパティを設定するには、トランスポート・ヘッダー・アクションを使用します。
$outboundの設定の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のインバウンド変数とアウトバウンド変数に関する項を参照してください。
Oracle WebLogic Server Web ServicesクライアントがOracle Service Busプロキシ・サービスを呼び出す場合、URIプロパティは無視されます。ただし、トランスポート・ヘッダー・アクションのパススルー・オプションを使用すると、呼び出されるサービスにパススルーできます。詳細は、2.4.32項「メッセージ・フローへのトランスポート・ヘッダー・アクションの追加と構成」を参照してください。
Oracle Service Busで呼び出すことができるのは、バージョン9.2以降で実行されているOracle WebLogicリクエスト/レスポンス・サービスのみです。ただし、一方向のJMSサービスも呼び出すことができます。
ドメイン間JMS呼出しのレスポンス・キューを構成する場合は、リクエスト側の管理対象サーバーごとに個別のレスポンス・キューを設定します。
たとえば、Oracle WebLogic Serverドメインと通信する2つのOracle Service Busクラスタ・ドメイン(ドメインAとドメインB)があります。このドメインには2つの管理対象サーバーがあるとします。ドメインAに3つの管理対象サーバー、ドメインBに4つの管理対象サーバーがある場合、ドメインAとドメインBにレスポンスを返すには、レスポンス・キューとして機能する7つ(3 + 4 = 7)の異なるキューをOracle WebLogic Serverドメインに構成する必要があります。これらのキューは、(Oracle WebLogic Serverドメインの両方の管理対象サーバーにメンバーを持つ)分散キューである場合もあります。
|
注意: 異なるリモート・ドメインによってホストされている複数のプロキシ・サービスからJMSリクエストを受信するには、リクエスト側の各ドメインに対応する個別のレスポンス・キューのセットを使用して、JMSビジネス・サービスをホストするバックエンドのドメインを構成する必要があります。 |
複数のドメインを使用する作業では、構成が次の要件に準拠していることを確認します。
Oracle WebLogic Serverインスタンス名およびドメイン名が一意です。
WebLogic JMSサーバー名がドメイン内で一意です。
永続メッセージ用にJMSファイル・ストアを使用している場合、そのJMSファイル・ストア名がドメイン間に渡って一意でなければなりません。
JMSサーバー名に関しては次のルールを確認します。
同じドメインに重複したJMSサーバー名を持つことはできません。重複したJMSサーバー名があると、メッセージが特定のJMSサーバーの宛先に送信されたときに、Oracle Service Busはメッセージの送信先のサーバーを判別できません。
ストア・アンド・フォワード(SAF)を使用している場合は、異なるドメインに重複したJMSサーバー名があってもかまいません。
ドメイン間通信の場合、ReplyTo機能を使用するときに、重複したJMSサーバー名が問題になることがあります。特定のドメインから送信されたReplyToメッセージは、元のメッセージを送信したドメインではなく、そのメッセージを受信した同じドメイン上のJMSサーバーに返されます。
WebLogic JMSの構成と管理方法については、以下を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のアプリケーションの管理に関する項
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSサーバーの構成に関するトピック
Oracle Service Busでは、異種のエンドポイント間での相互運用性を確保するため、使用されるコンテンツ・タイプ、JMSタイプ、およびエンコーディングをメッセージ・フローの構成時にそれぞれ制御できます。JMSタイプはバイトまたはテキスト(非Javaタイプ・メッセージの場合)のいずれかです。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のコンテンツ・タイプ、JMSタイプおよびエンコーディングに関する項を参照してください。
明示的にエラーを定義するWSDLを使用している場合、XMLエラーのタイプに対し、WebLogic clientgenツールによってjava.lang.Exceptionというサブクラスが生成されます。Oracle WebLogic Server JAX-RPCスタックがSOAPレスポンス・メッセージを検査し、レスポンス・メッセージにSOAPフォルトが含まれると判断すると、そのエラーをclientgen生成の例外Javaクラスにマップしようとします。
たとえば、次のコード・リストに示す定義がWSDLに含まれる場合、clientgenツールはjava.lang.Exceptionを拡張した com.bea.test.TheFaultType Javaクラスを生成します。このサービス・スタブの関連メソッドが呼び出されると、JAX-RPCクライアントがcom.bea.test.TheFaultTypeを受け取る可能性があります。
例30-1 WSDL定義のサンプル
<definitions ... xmlns:s0="http://www.oracle.com/test/">
...
<types>
<xsd:schema targetNamespace="http://www.oracle.com/test/">
...
<xsd:complexType name="theFaultType">
<xsd:sequence>
<xsd:element name="ID" type="xsd:int" />
<xsd:element name="message" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="theFault" type="theFaultType" />
</xsd:schema>
</types>
...
<message name="theFaultMessage">
<part element="s0:theFaultPart" name="theFault" />
</message>
...
<binding ...>
<operation ...>
<soap:operation soapAction="..." style="document" />
<input ...>
...
</input>
<output ...>
...
</output>
<fault ...>
<soap:fault name="theFaultPart" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>
SOAPメッセージには正しい形式のエラーが含まれ、JAX-RPCスタックが正しい例外をスローできるようになっている必要があります。エラーをOracle Service Busメッセージ・フロー内部で作成する場合は、次の操作を行います。
$body変数のノードを次のSOAPのサンプルで置き換えます。
例30-2 SOAPのサンプル
<soap-env:Body>
<soap-env:Fault>
<faultcode
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">soap:Server</faultcode>
<faultstring>Some literal string</faultstring>
<detail>
<test:theFault>
<test:ID>Any user defined code</test:Id>
<test:message>A specific literal message</test:message>
</test:theFault>
</detail>
</soap-env:Fault>
</soap-env:Body>
説明:
soap-envは、http://schemas.xmlsoap.org/soap/envelope/ネームスペースのシステム接頭辞です。
testは、http://www.oracle.com/test/の接頭辞です。
test接頭辞がOracle Service Busにとって既知ではない場合は、宣言する必要があります。
失敗時の返信アクションを構成します。
Oracle Service Busコンソールで返信アクションを構成する方法の詳細は、2.4.22項「メッセージ・フローへの返信アクションの追加と構成」を参照してください。
clientgenを使用して、Webサービスを呼び出すために必要なクライアント側のアーティファクト(JAX-RPCスタブなど)を生成します。『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービス・リファレンス』のAntタスク・リファレンスに関する項を参照してください。
Oracle Service Busは、WebSphere MQ JMSインタフェースを介してWebSphere MQに接続します。つまり、Oracle Service BusはWebSphere MQ JMSクライアントです。
WebSphere MQは、次の2通りの方法でOracle Service Busと対話できます。
Oracle Service BusがWebSphere MQのフロント・エンドとして機能し、他のアプリケーションからのサービス・リクエストを受け入れ、それらをWebSphere MQリクエストに変換します。
WebSphere MQがOracle Service Busを介して他のアプリケーションにメッセージを送信します。
詳細は、33.9.1項「WebSphere MQ JMSインタフェースの使用」を参照してください。
JMSは、エンタープライズ・メッセージング・システムにアクセスするための標準APIです。Oracle WebLogic JMSにより次の機能が実現します。
メッセージング・システムを共有するJavaアプリケーション間でメッセージを交換できます。
メッセージの作成、送信、および受信に使用する標準インタフェースが用意されているため、アプリケーション開発が簡略化されます。
JMSの概要および機能は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』を参照してください。
ここでは、Oracle Service BusでサポートされるJMSリクエスト/レスポンスのメッセージIDと相関IDのパターン、およびOracle Service Busでこれらのパターンを使用して、Java API for Remote Procedure Call (JAX-RPC) Webサービスと相互運用する方法について説明します。例も示します。
以下の内容について説明します。
メッセージングでは、プログラム間で配信が保証された高速非同期通信を行います。多くの場合、メッセージングはメッセージ指向ミドルウェア(MOM)と呼ばれるソフトウェアのレイヤーとして実装されます。
エンタープライズ・コンピューティングにおいて、プロセスやプロセス間の通信の信頼性がそれほど高くない場合でも、メッセージングによりプロセス間の通信の信頼性が高まります。プロセスで通信が必要になる理由は次のとおりです。
あるプロセスのデータを別のプロセスに送信する必要があります。
あるプロセスが別のプロセスのプロシージャをリモートから呼び出す必要があります。
IBM WebSphere MQを使用している場合、特定のメインフレームとの対話には非同期リクエスト/レスポンス・メッセージを使用することをお薦めします。
メッセージングのパターンには、MOMで構築されたシステムの各部分間をフローするメッセージのフォーマットが記述されます。メッセージには、次のような様々なタイプがあります。
メッセージング・システムでプロシージャ・コールのセマンティクスを実行できるようにするコマンド・メッセージ。
メッセージング・システムが情報(コマンド・メッセージの結果として送信側に返す情報など)をトランスポートできるようにするドキュメント・メッセージ。
メッセージングを使用してイベントの通知を実行するイベント・メッセージ。
リモート・プロシージャ・コールの結果のセマンティクスを処理する応答メッセージ。応答メッセージでは、成功した結果と失敗した結果の両方を処理できる必要があります。
リクエストを作成するプログラムが応答送信時のチャネルを識別できるようにする応答指定子。
リクエスト元のプログラムが特定のレスポンスをリクエストに関連付けることを可能にする相関ID。渡されたデータが複数のメッセージにわたる場合は、シーケンス識別子により、受信側は元のデータを正確に再構築できます。
送信側がメッセージを配信または無視することによって期限を設定できるようにするメッセージ有効期限。
受信側がメッセージの受信率を制御できるようにするメッセージ抑制。
Oracle Service Busの場合、各応答メッセージに、リクエスト・メッセージと応答を関連付ける相関IDと呼ばれるユニークな識別子を含める必要があります。
呼出し側は、リクエスト・メッセージの作成時に、現在未完了の他のすべてのリクエスト(応答をまだ受信していないリクエストなど)の識別子とは異なる一意の識別子をリクエストに割り当てます。受信側は、リクエストを処理するときにこの識別子を保存し、リクエストの識別子を応答に追加します。
呼出し側は、応答を処理するときにリクエストの識別子を使用してリクエストを応答に関連付けます。この識別子は、呼出し側が各応答とリクエストの関連付けに使用するため、相関IDと呼ばれます。
通常、相関IDはメッセージのヘッダーに配置されます。このIDは、呼出し側が受信側に伝達するコマンドまたはデータに含まれるわけではありません。
受信側は、リクエストのIDを保存し、呼出し側のために応答に追加します。メッセージ本文は2つのシステム間で送信されるコンテンツであり、IDはコンテンツの一部ではないため、IDはヘッダーに追加されます。
リクエスト・メッセージには、IDを相関IDプロパティとして格納することも、単にメッセージIDプロパティとして格納することもできます。IDが相関IDとして使用されている場合、どのメッセージがリクエストでどのメッセージが応答か混乱を招くおそれがあります。リクエストにメッセージIDが含まれ、相関IDは含まれていない場合、応答にはそのリクエストのメッセージIDと同じ相関IDが含まれます。
Oracle Service Busで内部的に使用される相関IDの形式はWebSphere MQの形式と互換性があり、MQネイティブのインタフェースが使用されている対象サービスで動作します。
アウトバウンド・トランスポートでは、非同期のリクエスト/レスポンス・メッセージを処理します。つまり、トランスポート方式固有のデータである$outboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのメッセージ・フローに違いはありません。
JMSリクエスト/レスポンス・ビジネス・サービスまたはプロキシ・サービスを定義するときには、まず設計パターンを選択する必要があります。これを行うには、JMSプロキシ・サービスでは「レスポンスが必要」オプション、JMSビジネス・サービスでは「レスポンス・キュー」オプションを選択し、JMSの「トランスポート構成」ページで次のいずれかの相関パターンを選択します。
JMS相関ID - デフォルトのパターン
JMSメッセージID
JMSプロキシ・サービスおよビジネス・サービスの作成の詳細は、2.3項「プロキシ・サービスの操作」および2.2項「ビジネス・サービスの操作」を参照してください。
次の項では、これらのパターンについて説明します。2つのパターンを比較するには、30.8.4項「メッセージIDと相関IDのパターンの比較」を参照してください。
JMSメッセージIDのパターンを使用してビジネス・サービスを作成する場合は、レスポンスが1つのURIに送信されるように構成できます。あるいは、フェイルオーバーをサポートするために、Oracle Service Busクラスタの各管理対象サーバー上の各リクエストURIに対してレスポンス・キューを構成できます。これらのキューは、サービスのリクエスト・キューと同じ場所に存在する必要があります。プロキシ・サービスは、ビジネス・サービスを呼び出すときにこの情報を使用してJMSReplyToプロパティを設定し、このリクエストを出した管理対象サーバーによってレスポンスが処理されるようにします。
JMSメッセージIDのパターンを使用してプロキシ・サービスを定義すると、プロキシ・サービスはJMSReplyToプロパティで指定されたキューに返信するため、ResponseURIを定義する必要はありません。ただし、レスポンス・メッセージに対してJMS接続ファクトリのJNDI名を指定できます。
|
注意: デフォルトでは、リクエスト・メッセージの接続ファクトリが使用されます。これが役立つのは、JMSレスポンスに対して非XA接続ファクトリを使用するが、リクエストに対してXA接続ファクトリがある場合です。デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。 |
呼び出されたサービスは、リクエストのメッセージID(JMSヘッダー・フィールドJMSMessageIDの値)をレスポンスの相関IDにコピー(JMSヘッダー・フィールドJMSCorrelationIDを設定)する必要があります。また、呼び出されたサービスは、JMSReplyToヘッダー・フィールドに指定されたキューに返信する必要があります。
JMSメッセージIDのパターンを選択すると、レスポンスは適切な管理対象ノードに送信されます。
このパターンを使用するJMSプロキシ・サービスは、追加の構成なしにクラスタで使用できます。JMSビジネス・サービスはクラスタで使用できます。ただし、管理対象サーバーがクラスタに追加されると、すべてのビジネス・サービスが無効になります。これを回避するには、レスポンス・キューの数が、Oracle Service BusクラスタのJMSメッセージID相関パターンを指定する管理対象サーバーの数と同じになるようにします。
|
注意: JMSメッセージID相関パターンは、プロキシ・サービスが別のプロキシ・サービスを呼び出す場合はサポートされません。 |
ビジネス・サービスをJavaで設計するときは、レスポンスのJMS相関IDの値をリクエストのJMS相関IDの値に設定してから、JMSレスポンスをキューに送信するようにします。
メッセージの受信時にJMS相関IDを取得するには、次のようにします。
String getJMSCorrelationID()
上記のメソッドは、特定のメッセージIDまたはアプリケーション固有の値を表す相関IDの値を文字列として返します。
メッセージの送信時にJMS相関IDを設定するには、次のようにします。
void setJMSCorrelationID(String correlationID)
JMSリクエスト/レスポンス・パターンは次の点で異なります。
レスポンスをリクエストと関連させる方法
レスポンス・キューの選択
2つのパターンの相違について、表30-1にまとめます。
表30-1 メッセージIDと相関IDのパターンの相違点
| JMSパターン名 | レスポンス・キュー | 相関ID |
|---|---|---|
|
相関IDのパターン |
すべてのレスポンスは固定された同じキューに入れられます。 |
サーバーはリクエストの相関IDをレスポンスの相関IDにコピーします。 |
|
メッセージIDのパターン |
レスポンスは、 |
サーバーはリクエストのメッセージIDをレスポンスの相関IDにコピーします。 |
相関IDのパターンが使用される場合、呼び出されたサービスは、リクエストURIに対応するキューに応答します。レスポンスは常に同じキューに置かれ、クライアントはレスポンスが置かれるキューを制御できません。たとえば、10のクライアントがリクエストURI「A」にメッセージを送信した場合、これらのクライアントはすべてリクエストURI「A」に対応するキューからレスポンスを取得します。このため、クライアントはレスポンス・キューのメッセージをフィルタして、各自に関連するレスポンスを選択する必要があります。フィルタ条件をリクエスト・メッセージの相関IDプロパティに構成し、これをレスポンスの相関IDプロパティに返すようにサーバーを構成します。
メッセージIDのパターンの場合、クライアントのJMSReplyToプロパティによってサーバーにレスポンスの送信先を指示します。このキューはクライアントのサーバーに固有であるため、別のクライアントへのレスポンスは別のキューに置かれます。サーバーは、レスポンスのJMS相関IDをリクエストのJMSメッセージIDに設定します。
メッセージIDによる相関は、JMSアプリケーションだけではなく多くのIBM MQアプリケーションでも一般に使用されており、リクエストとレスポンスを関連付ける標準的な方法です。
メッセージIDのパターンによるJMSリクエスト/レスポンスを使用して、複数のOracle WebLogicクライアント・ドメインから対象Oracle WebLogicドメインを呼び出す場合は、リクエスト・キューとレスポンス・キューの両方をSAFキューとして設定できます。ただし、所定のリクエストURIに対するすべてのレスポンスに単一のキューを使用する相関IDのパターンでは、このように設定することはできません。
相関IDのパターンには主に2つの利点があります。
レスポンス・キューの構成が簡単であり、クラスタに管理対象サーバーが新しく追加されるたびに変更する必要はありません。
ドメインのプロキシ・サービスが同じドメインの別のプロキシ・サービスを呼び出す必要がある場合、相関IDも使用できます。
Oracle Service Bus開発環境では、HTTP/HTTPSに加え、JMSトランスポートを使用するJAX-RPC Webサービスを作成できます。このようなJMSトランスポートのJAX-RPC Webサービスでは、操作に関連付けられた値を取得したり返したりするためのメカニズムとしてJMSキューを使用します。JMSメッセージIDのパターンを使用して、JMSトランスポートのJAX-RPC Webサービスを呼び出すことができます。
また、Oracle WebLogic clientgenのAntタスクによって生成されたJAX-RPC静的スタブから、JMSリクエスト/レスポンスOracle Service Busプロキシ・サービスを呼び出すこともできます。
ここででは次のトピックについて説明します。
JMSメッセージIDのパターンを使用してJMSトランスポートのJAX-RPC Webサービスを呼び出すには、次の手順を実行します:
JMSメッセージIDのパターンを使用してJMSトランスポートのJAX-RPC Webサービスを呼び出す、JMSリクエスト/レスポンスOracle Service Busビジネス・サービスを作成します。詳細は、3.1.15項「JMSトランスポート構成ページ(ビジネス・サービス)」を参照してください。
このビジネス・サービスは、JMSトランスポートを使用します。エンドポイントURIのJMSキューJNDI名の部分は、JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransportアノテーションに指定したキュー属性と同じであることが必要です。例:
jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue
「対象 - 宛先」領域の「宛先」フィールドに割り当てるJMSキューのJNDI名は、「宛先」フィールドに表示されるOracle WebLogic Server名を対象としたJMSサーバーに関連付けられている必要があります。
ステップ1で作成したJMSリクエスト/レスポンス・ビジネス・サービスへのルーティング(またはサービス・コールアウト)アクションを含むOracle Service Busプロキシ・サービスを作成します。
ルーティング・アクションの「リクエスト・アクション」領域には、アウトバウンド・リクエスト・アクションのトランスポート・ヘッダーの設定を含める必要があります。トランスポート・ヘッダー・アクションを構成するときは、アウトバウンド・リクエスト・アクションの2つのJMSヘッダーを追加する必要があります。トランスポート・ヘッダー・アクションの構成方法の詳細は、2.4.32項「メッセージ・フローへのトランスポート・ヘッダー・アクションの追加と構成」を参照してください。
次に、手順を簡単に説明します。
トランスポート・ヘッダー・アクションを構成するには、「ヘッダーを追加」フィールドの「その他」を選択し、表示されたフィールドにURIを入力します。
「ヘッダーを式に設定」を選択し、(JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransportアノテーションで)contextPath属性とserviceUri属性に指定した値を続けて入力して式を作成します。各属性の値の前にはスラッシュを入力します。たとえば、@WLJmsTransportアノテーションが次のように指定されているとします。
@WLJmsTransport( contextPath="transports", serviceUri="JmsTransportService", portName="JmsTransportPort", queue="JmsTransportServiceRequestQueue" )
トランスポート・ヘッダーを構成する場合、「XQueryテキスト」入力領域に次の式を入力します。
/transports/JmsTransportService
2つ目のJMSヘッダーを指定するには、「ヘッダーの追加」フィールドの「その他」をもう一度選択し、関連するフィールドに_wls_mimehdrContent_Typeと入力します。
「ヘッダーを式に設定」を選択し、「XQueryテキスト」入力領域にtext/xml; charset=UTF-8と入力します。
JAX-RPC WebLogic Serverクライアントからプロキシ・サービスを呼び出すシナリオでは、プロキシ・サービスのインバウンド・レスポンスに_wls_mimehdrContent_Type JMSヘッダーを設定する必要があります。
着信JMSメッセージIDのパターン・リクエストにレスポンスを出すときのヘッダーを指定する必要があります。
たとえば、JAX-RPCクライアントからOracle Service Busプロキシ・サービスを呼び出し、続いてOracle WebLogic Server Webサービスを呼び出すシナリオでは、ルート・ノードの構成は次のとおりです。
リクエスト・パイプラインの場合
Webサービス・コンテキストのトランスポート・ヘッダーを、URI(例:interop/AllocJmsDocLit)に設定します。
_wls_mimehdrContent_Typeのトランスポート・ヘッダーを、text/xml; charset=UTF-8に設定します。
「トランスポート・ヘッダーを設定」メニュー項目から「アウトバウンド・リクエスト」を選択します。
「パイプラインを介してすべてのヘッダーを渡す」を有効にします。
レスポンス・パイプラインの場合
空のトランスポート・ヘッダーを追加し、「トランスポート・ヘッダーを設定」メニューから「インバウンド・レスポンス」を選択します。
「パイプラインを介してすべてのヘッダーを渡す」を有効にします。
以下の例で、JMSメッセージIDのパターンを使用する様々な方法について説明します。
30.8.6.2項「例2: Oracle Service Busプロキシ・サービスを使用したJAX-RPCクライアント」
30.8.6.3項「例3: Oracle WebLogic Server JAX-RPCリクエスト/レスポンス・サービスのクライアントとしてのOracle Service Bus」
図30-1では、リクエスト/レスポンス通信においてMQサービスをホストするサーバーがリクエストのメッセージIDをレスポンスの相関IDに返し、レスポンスをreplyToキューに送信します。レスポンスが戻り、JMSメッセージIDを使用して関連付けられます。Oracle Service BusのreplyTo宛先は、ビジネス・サービスの構成時に、クラスタのOracle Service Busノードごとに1つ設定されています。また、JMSまたはMQネイティブ・クライアントが、JMSメッセージIDのパターンを使用してJMSリクエスト/レスポンス・プロキシ・サービスを呼び出すことができます。クライアントは、レスポンスを受け取るキューにreplyToプロパティを設定する必要があります。
この使い方で重要なのは、JMSメッセージIDがリクエスト/レスポンス・メッセージの相関を行うことです。また、クラスタ・サーバーと同じ数のMQ Seriesアウトバウンド・レスポンス・キューを作成する必要があります。
図30-1 JMSメッセージIDを使用してリクエスト/レスポンス・メッセージの相関を行うMQサービス
図30-2は、Oracle Service Busプロキシ・サービスにメッセージを送信するJAX-RPCクライアントを表します(JAX-RPCインバウンドの場合)。JAX-RPCスタックは、レスポンスを受信するために一時的なキューを使用します。Oracle Service Bus JMSトランスポートでは、実行時にこの一時的なキューを使用します。
図30-2 Oracle Service Busプロキシ・サービスを使用したJAX-RPCクライアント
図30-3は、Oracle WebLogic Server JAX-RPCリクエスト/レスポンス・サービスとOracle Service Busプロキシ・サービスとの相互運用性を表します(JAX-RPCアウトバウンドの場合)。
図30-3 Oracle WebLogic Server JAX-RPCリクエスト/レスポンス・サービスのクライアントとしてのOracle Service Bus
|
注意: 1つ目のOracle WebLogic Serverドメインのプロキシ・サービスが2つ目のドメインのプロキシ・サービスにメッセージを送信する必要がある場合、まずドメイン1のパススルー・ビジネス・サービスにメッセージをルーティングする必要があります。ドメイン1とドメイン2の間のJMSストア・アンド・フォワードでは、ドメイン2のプロキシ・サービスにインバウンド・リクエスト・メッセージを転送します。JMSリクエスト/レスポンスを使用する場合、JMSストア・アンド・フォワードを使用して、ドメイン2からドメイン1にインバウンド・レスポンス・メッセージを転送することもできます。この場合、ドメイン2のプロキシ・サービスに対して、エクスポートされるインバウンド・リクエスト・キューとインポートされるインバウンド・レスポンス・キューをドメイン2で構成する必要があります。JMSストア・アンド・フォワードの構成に特に注意する必要があります。 |
JMSは、すべてのサービス・タイプのプロキシ・サービスおよびビジネス・サービス(トランスポート型付きサービスのビジネス・サービスを除く)の転送プロトコルとして選択できます。以下の各項で説明するように、プロキシ・サービスおよびビジネス・サービスはJMSトランスポートを使用するように構成できます。
詳細は、2.2項「ビジネス・サービスの操作」および2.3項「プロキシ・サービスの操作」を参照してください。ビジネス・サービスのエラー処理の詳細は、30.9.5項「エラー処理」を参照してください。
プロキシ・サービスを構成する場合は、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。詳細は、30.9.2項「トランスポート・ヘッダー」を参照してください。
Oracle Service BusとWebSphere MQの相互運用性の詳細は、第33章「MQトランスポート」を参照してください。
Oracle Service Busでは、サービスを構成するとき、あるいはオプションでカスタム・ワーク・マネージャをWLSに構成するとき、デフォルトのディスパッチ・ポリシーを使用できます。
プロキシ・サービスを構成するときに、エンドポイントURIが次の形式の場合、JMS転送プロトコルを選択できます。
jms://<host:port[,host:port]*/connection_factory/jndi_destination>
説明:
hostは、サービスをホストするシステムの名前です。
portは、接続を行うポート番号です。
[,host:port]*は、対応するポートで複数のホストを構成できることを示します。
connection_factoryは、JNDI接続ファクトリの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
jndi_destinationは、JNDI宛先の名前です。
JMS宛先に複数のサーバーを指定するには、jms://host1:port,host2:port/connection_factory/jndi_destinationという形式のURIを使用します。
ここで、connection_factoryは、接続ファクトリ・キューの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
JMS転送プロトコルを使用するプロキシ・サービスを構成するには、3.1.16項「JMSトランスポート構成ページ(プロキシ・サービス)」を参照してください。
JMSトランスポートに関連する各種のヘッダーを表30-2に示します。順序単位ヘッダー(JMS_BEA_UnitOfOrder)を除き、すべてのヘッダーはアウトバウンド・リクエストとインバウンド・レスポンスの両方で共通になっています。
表30-2 JMSトランスポート・ヘッダー
| ヘッダー | 説明 |
|---|---|
|
JMSMessageID |
JMSMessageIDヘッダー・フィールドは、プロバイダによって送信されたメッセージをユニークに識別する値を格納します。 |
|
JMSDeliveryMode |
JMSDeliveryModeヘッダー・フィールドは、メッセージの送信時に指定された配信モードを格納します。 |
|
JMSExpiration |
このヘッダー・フィールドは、送信メソッドで指定された存続時間と現在のGMT値の合計として算出されるメッセージの有効期限を格納します。 |
|
JMSPriority |
JMSPriorityヘッダー・フィールドは、メッセージの優先度を格納します。 メッセージを送信すると、このフィールドは無視されます。送信操作が完了すると、メッセージを送信したメソッドによって指定された値が保持されます。 |
|
JMSType |
JMSTypeヘッダー・フィールドは、メッセージの送信時にクライアントによって指定されたメッセージ・タイプを格納します。 |
|
JMSCorrelation ID |
メッセージを別のメッセージにリンクするために使用されます。たとえば、リクエスト・メッセージをレスポンス・メッセージにリンクできます。 |
|
JMSXAppID |
JMSで定義されるプロパティの1つで、メッセージを送信するアプリケーションのIDを指定します。このプロパティは、JMSプロバイダによって設定されます。 |
|
JMSXGroupID |
JMSで定義されるプロパティの1つで、メッセージが属するメッセージ・グループのグループIDを指定します。このプロパティは、クライアントによって設定されます。 |
|
JMSXGroupSeq |
JMSで定義されるプロパティの1つで、メッセージ・グループ内でのメッセージの順序を指定します。 |
|
JMS_IBM_Format |
アプリケーション・データの性質が含まれます。詳細は、 |
|
JMS_IBM_Report_Exception |
例外レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、 |
|
JMS_IBM_Report_Expiration |
期限切れレポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、 |
|
JMS_IBM_Report_COA |
着信確認レポートを要求します。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、 |
|
JMS_IBM_Report_COD |
配信確認レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、 |
|
JMS_IBM_Report_PAN |
肯定アクション通知レポートを要求します。詳細は、 |
|
JMS_IBM_Report_NAN |
肯定アクション通知レポートをリクエストします。詳細は、 |
|
JMS_IBM_Report_Pass_Msg_ID |
レポートまたは返信メッセージのメッセージ識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、 |
|
JMS_IBM_Report_Pass_Correl_ID |
レポートまたは返信メッセージの相関識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、 |
|
JMS_IBM_Report_Discard_Msg |
指定の宛先に配信できなかった場合にメッセージを廃棄するようにリクエストします。詳細は、 |
|
JMS_IBM_MsgType |
メッセージのタイプ。詳細は、 |
|
JMS_IBM_Feedback |
これはレポート・メッセージの性質を指定します。詳細は、 |
|
JMS_IBM_Last_Msg_In_Group |
メッセージがメッセージ・グループの最後のメッセージかどうかを指定します。詳細は、 |
|
JMS_BEA_UnitOfOrder |
このヘッダーはリクエストおよびレスポンスに有効です。 |
メッセージ・フローでは、インバウンド・リクエストおよびアウトバウンド・リクエストの両方についてトランスポート・ヘッダーを構成できます。JMSトランスポートに関連するトランスポート・ヘッダーについては、30.9.2項「トランスポート・ヘッダー」を参照してください。
パイプラインで、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダーの値を設定します。トランスポート・ヘッダー・アクションの追加については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート・ヘッダー・アクションの追加に関する項を参照してください。
|
注意: JMSトランスポート・ヘッダーの制限の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のテスト・コンソールにおけるランタイムのトランスポート設定の使用方法に関する項および『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトランスポート・ヘッダー・アクションで指定するトランスポート・ヘッダー値の制約に関する項を参照してください。 |
JMSトランスポートを使用してJavaオブジェクトを直接送信できます。リクエストまたはレスポンスでJavaオブジェクトのサポートを有効にするには、「メッセージ・サービス」タイプのプロキシまたはビジネス・サービス(あるいはその両方)を作成してから、「メッセージング」ページで「Java」を選択します。このページの対象は、Oracle Service BusでJavaオブジェクトを送信しているか、受信しているかによって、リクエストまたはレスポンス(あるいはその両方)になります。
JMS宛先からのJavaオブジェクトのデキューには、Javaオブジェクトのデシリアライズが伴います。この処理を有効にするには、JARファイルにデキューされる予定のJavaオブジェクトのJavaクラスをパッケージ化して、JARをOracle Service Busプロジェクトにインポートする必要があります。次に、サービスに対するJMSトランスポート固有の構成ページで、「クライアントJar」フィールドでJARを選択します。「クライアントJar」フィールドは、リクエストのメッセージ・タイプとしてJavaを選択しているときはJMSプロキシ・サービスで、また、レスポンスのメッセージ・タイプとしてJavaを選択しているときはビジネス・サービスで使用できます。詳細は、4.2項「ビジネス・サービスの構成」および4.3項「プロキシ・サービスの構成」を参照してください。
Oracle Service BusのJavaオブジェクトはパイプライン・オブジェクト・リポジトリに格納され、SOAP本文で<java-content ref="jcid" />要素および属性として参照されます。jcidはオブジェクト・リポジトリ内のオブジェクトに対するキーです。Javaオブジェクトがnullの場合、そのオブジェクトはパイプラインでref="jcid:null"として表されます。
各メッセージで使用可能なJavaオブジェクトは1つだけです。
Javaタイプのメッセージ・タイプについて、Oracle Service Busはラージ・メッセージ(コンテンツ・ストリーミング)や、テスト・コンソールでのJavaタイプ・サービスのテストはサポートしていません。
ビジネス・サービスを構成するときに、エンドポイントURIが次の形式の場合、JMS転送プロトコルを選択できます。
jms://<host:port[,host:port]*/connection_factory/jndi_destination >
説明:
hostは、サービスをホストするシステムの名前です。
portは、接続を行うポート番号です。
[,host:port]*は、対応するポートで複数のホストを構成できることを示します。
connection_factoryは、JNDI接続ファクトリの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
jndi_destinationは、JNDI宛先の名前です。
JMS宛先に複数のサーバーを指定するには、jms://host1:port,host2:port/connection_factory/jndi_destinationという形式のURIを使用します。
ここで、connection_factoryは、接続ファクトリ・キューの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
JMSビジネス・サービスを登録する場合、WSDLファイルのURIをサービス定義に追加するときに、手動で編集する必要があります。URIの形式は次のとおりです。
jms://<host>:<port>/connection_factory/jndi_destination
JMS転送プロトコルを使用するビジネス・サービスを構成するには、3.1.15項「JMSトランスポート構成ページ(ビジネス・サービス)」を参照してください。
|
注意: ビジネス・サービスでJMS IDによるレスポンス相関を使用するようにJMSリクエスト/レスポンス・アプリケーションを構成するには、以下の作業を行う必要があります。
|
アプリケーション・エラーおよび通信エラーを処理するJMSトランスポート・ビジネス・サービスは、以下のように構成できます。
アプリケーション・エラー
アプリケーション・エラーが発生したときにビジネス・サービスのエンドポイントURIを再試行するかどうかを指定できます。詳細は、4.2.4項「ビジネス・サービスの「トランスポート構成」ページ」の「アプリケーション・エラーの再試行」オプションを参照してください。
リクエスト/レスポンスを使用するように構成されたJMSビジネス・サービスでは、レスポンス・メッセージのSystem.getProperty("com.bea.wli.sb.transports.jms.ErrorPropertyName", "SERVER_ERROR")プロパティがtrueである場合にアプリケーション・エラーが発生します。このシナリオでは、JMSトランスポート・プロバイダは、TRANSPORT_ERROR_APPLICATIONエラー・コードを使用してエラー・メソッドを呼び出します。
通信エラー
通信エラーが発生したときにビジネス・サービスのURIをオフラインにするように構成できます。ビジネス・サービスの操作設定を構成するときに、指定した再試行間隔の後、ビジネス・サービスのエンドポイントURIがオフラインになるように設定できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスの操作設定の構成に関する項およびビジネス・サービスのエンドポイントURIメトリックの表示に関する項を参照してください。
次のアクティビティのいずれかでJMS例外またはネーミング例外が発生すると、通信エラーが発生します。
JMS接続ファクトリのルックアップ
JMS接続ファクトリからのJMS接続の作成
接続オブジェクトを使用したJMSセッションの作成
JMS宛先のルックアップ
セッション・オブジェクトからの送信者の作成
送信者および宛先オブジェクトを使用したJMSメッセージの送信
Javaオブジェクトにおけるパイプライン例外
Javaオブジェクト・メッセージのビジネス・サービスまたはJavaコールアウトへのルーティング中などに、JMSプロキシ・サービスで例外が発生したら、プロキシ・サービスが例外インスタンスにアクセスして、それを呼出し元のクライアントに返すことができるように、メッセージ・ペイロードを正しく書式設定してください。必ず、ペイロードは次の形式に従ってください。
<soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<ctx:java-content ref="key1"
xmlns:ctx="http://www.bea.com/wli/sb/context" />
</soap:Body>
ここで、key1はオブジェクト・リポジトリ内のJavaオブジェクトに対するキーです。ペイロードがこの形式ではない場合、パイプラインはnullのペイロードをインバウンドJMSトランスポートに渡します。
エラー・ハンドラの使用
Javaオブジェクトに関連するパイプライン・エラーは、エラー・ハンドラを使用して捕捉できます。エラー・ハンドラの$fault変数には、例外インスタンスへの参照が含まれます("java-exception"要素)。
$fault変数に例外インスタンスへの参照が含まれない状況では、エラー・ハンドラ内でJavaコールアウトを使用できます。これによって利用可能な$fault情報を使用して、例外インスタンスが前述の$bodyペイロード形式で生成されます。インバウンドJMSトランスポートへのペイロードとして$bodyが使用可能になるように、失敗時の返信操作を使用する必要があります。
