|
|
JMS は、エンタープライズ メッセージング システムにアクセスするための標準 API です。WebLogic JMS により、以下が実現します。
JMS の概要と機能については、JMS 相互運用性に関する説明と『WebLogic JMS のコンフィグレーションと管理』を参照してください。
この節では、Oracle Service Bus でサポートされる JMS 要求/応答のメッセージ ID と相関 ID のパターン、および Oracle Service Bus でこれらのパターンを使用して、Java API for Remote Procedure Call (JAX-RPC) Web サービスと相互運用する方法について説明します。例も示します。
メッセージングでは、プログラム間で配信が保証された高速非同期通信を行います。多くの場合、メッセージングはメッセージ指向ミドルウェア (MOM) と呼ばれるソフトウェアのレイヤとして実装されます。
エンタープライズ コンピューティングにおいて、プロセスやプロセス間の通信の信頼性がそれほど高くない場合でも、メッセージングによりプロセス間の通信の信頼性が高まります。プロセスで通信が必要になる理由は次のとおりです。
IBM WebSphere MQ を使用している場合、特定のメインフレームとの対話には非同期要求/応答メッセージを使用することをお勧めします。
メッセージングのパターンには、MOM で構築されたシステムの各部分間をフローするメッセージのフォーマットが記述されます。メッセージには、次のようなさまざまなタイプがあります。
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 プロキシ サービスまたはビジネス サービスの設計時に、Oracle Service Bus Console で [応答が必要である] チェック ボックスを選択し、JMS の転送コンフィグレーション ページで次のいずれかの相関パターンを選択します。
| 注意 : | プロキシ サービスに対する相関 ID のマッピングがメモリに格納されていないため、JMS 要求/応答メッセージングに信頼性のある応答が返されません。要求の送信後に応答が受信されるまでの間に障害または再起動が発生すると、その応答は破棄されます。JMS 要求/応答は使用せずに、一方向の JMS プロキシを 2 つ使用する状況も考えられます。その場合は、一方向の JMS プロキシの 1 つをメッセージの配信用に使用し、もう 1 つを逆方向の応答の配信用に使用します。 |
JMS プロキシ サービスおよびビジネス サービスの作成については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : 作成と管理」および「ビジネス サービス : 作成と管理」を参照してください。
以下の節では、これらのパターンについて説明します。2 つのパターンを比較するには、「メッセージ ID と相関 ID のパターンの比較」を参照してください。
Response URI を定義せずに、JMS メッセージ ID のパターンを使用してビジネス サービスを作成する場合は、Oracle Service Bus クラスタの各管理対象サーバの応答で使用するキューを指定します。これらのキューは、サービスの要求キューと連結する必要があります。プロキシ サービスは、ビジネス サービスを呼び出すときにこの情報を使用して JMSReplyTo プロパティを設定し、この要求を出した管理対象サーバによって応答が処理されるようにします。
JMS メッセージ ID のパターンを使用してプロキシ サービスを定義すると、プロキシ サービスは JMSReplyTo プロパティで指定されたキューに返信するため、ResponseURI を定義する必要はありません。ただし、応答メッセージに対して JMS 接続ファクトリの JNDI 名を指定できます。
| 注意 : | デフォルトでは、要求メッセージの接続ファクトリが使用されます。これが役立つのは、JMS 応答に対して非 XA 接続ファクトリを使用するが、要求に対して XA 接続ファクトリがある場合です。 |
| 注意 : | デプロイメント記述子を XA 対応リソース (JMS、TUXEDO、EJB) に適切に設定するには、プロキシ サービスを作成する前に、参照接続ファクトリの XA 属性を設定する必要があります。 |
呼び出されたサービスは、要求のメッセージ ID (JMS ヘッダ フィールド JMSMessageID の値) を応答の相関 ID にコピー (JMS ヘッダ フィールド JMSCorrelationID を設定) する必要があります。また、呼び出されたサービスは、JMSReplyTo ヘッダ フィールドに指定されたキューに返信する必要があります。
JMS メッセージ ID のパターンを選択すると、応答は適切な管理対象ノードに送信されます。
このパターンを使用する JMS プロキシ サービスは、追加のコンフィグレーションなしにクラスタで使用できます。JMS ビジネス サービスはクラスタで使用できます。ただし、管理対象サーバがクラスタに追加されると、すべてのビジネス サービスが無効になります。これを回避するには、応答キューの数が、Oracle Service Bus クラスタの JMS メッセージ ID 相関パターンを指定する管理対象サーバの数と同じになるようにします。
| 注意 : | JMS メッセージ ID 相関パターンは、プロキシ サービスが別のプロキシ サービスを呼び出す場合はサポートされません。 |
Java でビジネス サービスを設計するときは、キューに JMS 応答を送信する前に、応答の JMS 相関 ID の値を要求の JMS 相関 ID の値に設定します。JMS プロキシ サービスおよびビジネス サービスの作成については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : 作成と管理」および「ビジネス サービス : 作成と管理」を参照してください。
メッセージの受信時に JMS 相関 ID を取得するには、次のようにします。
String getJMSCorrelationID()
上記のメソッドは、特定のメッセージ ID またはアプリケーション固有の文字列値を表す相関 ID の値を返します。
メッセージの送信時に JMS 相関 ID を設定するには、次のようにします。
void setJMSCorrelationID(String correlationID)
2 つのパターンの相違について、表 2-1 にまとめます。
相関 ID のパターンが使用される場合、呼び出されたサービスは固定されたキューに応答します。応答は常に同じキューに置かれ、クライアントは応答が置かれるキューを制御できません。たとえば、10 のクライアントがメッセージを送信した場合、これらのクライアントはすべて同じキューから応答を取得します。このため、クライアントは応答キューのメッセージをフィルタして、各自に関連する応答を選択する必要があります。フィルタ条件を要求メッセージの相関 ID プロパティにコンフィグレーションし、これを応答の相関 ID プロパティに返すようにサーバをコンフィグレーションします。
メッセージ ID のパターンの場合、クライアントの JMSReplyTo プロパティによってサーバに応答の送信先を指示します。このキューはクライアントのサーバに固有であるため、別のクライアントへの応答は別のキューに置かれます。サーバは、応答の JMS 相関 ID を要求の JMS ID に設定します。
メッセージ ID による相関は、JMS アプリケーションだけではなく多くの IBM MQ アプリケーションでも一般に使用されており、要求と応答を関連付ける標準的な方法です。
メッセージ ID のパターンによる JMS 要求/応答を使用して、複数の WebLogic クライアント ドメインから対象 WebLogic ドメインを呼び出す場合は、要求キューと応答キューの両方を SAF キューとして設定できます。ただし、すべての応答に単一のキューを使用する相関 ID のパターンでは、このように設定することはできません。
Workshop for WebLogic では、HTTP/HTTPS に加え、JMS 転送を使用する JAX-RPC Web サービスを作成できます。このような JMS 転送の JAX-RPC Web サービスでは、操作に関連付けられた値を取得したり返したりするためのメカニズムとして JMS キューを使用します。JMS メッセージ ID のパターンを使用して、JMS 転送の JAX-RPC Web サービスを呼び出すことができます。
また、WebLogic clientgen の Ant タスクによって生成された JAX-RPC 静的スタブから、JMS 要求/応答 Oracle Service Bus プロキシ サービスを呼び出すこともできます。
JMS メッセージ ID のパターンを使用して JMS 転送の JAX-RPC Web サービスを呼び出すには、以下の手順を実行します。
このビジネス サービスは、JMS 転送を使用します。エンドポイント URI の JMS キュー JNDI 名の部分は、JMS 転送の JAX-RPC Web サービスの @WLJmsTransport アノテーションに指定したキュー属性と同じであることが必要です。次に例を示します。
jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue
[応答 JNDI 名] 領域の [送り先] フィールドに割り当てる JMS キューの JNDI 名は、[対象] フィールドに表示される WebLogic Server 名を対象とした JMS サーバに関連付けられている必要があります。
ルーティング アクションの [要求アクション] 領域には、発信要求アクションの転送ヘッダの設定を含める必要があります。転送ヘッダ アクションをコンフィグレーションするときは、発信要求アクションの 2 つの JMS ヘッダを追加する必要があります。転送ヘッダ アクションのコンフィグレーション方法の詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」にある「転送ヘッダ」を参照してください。
@WLJmsTransport アノテーションで) contextPath 属性と serviceUri 属性に指定した値を続けて入力して式を作成します。各属性の値の前にはスラッシュを入力します。たとえば、@WLJmsTransport アノテーションが次のように指定されているとします。
serviceUri="JmsTransportService",
queue="JmsTransportServiceRequestQueue"
)
転送ヘッダをコンフィグレーションする場合、[XQuery テキスト] 入力領域に次の式を入力します。
/transports/JmsTransportService
_wls_mimehdrContent_Type」と入力します。text/xml; charset=UTF-8」と入力します。
JAX-RPC WebLogic Server クライアントからプロキシ サービスを呼び出すシナリオでは、プロキシ サービスの着信応答に _wls_mimehdrContent_Type JMS ヘッダを設定する必要があります。
着信 JMS メッセージ ID のパターン要求に応答を出すときのヘッダを指定する必要があります。
たとえば、JAX-RPC クライアントから Oracle Service Bus プロキシ サービスを呼び出し、続いて WebLogic Server Web サービスを呼び出すシナリオでは、ルート ノードのコンフィグレーションは次のとおりです。
| 注意 : | 転送ヘッダ アクションのコンフィグレーション方法の詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス : アクション」にある「転送ヘッダ」を参照してください。 |
以下の例で、JMS メッセージ ID のパターンを使用するさまざまな方法について説明します。
図 2-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 発信応答キューを作成する必要があります。
図 2-2 は、Oracle Service Bus プロキシ サービスにメッセージを送信する JAX-RPC クライアントを表します (JAX-RPC 着信の場合)。JAX-RPC スタックは、応答を受信するために一時的なキューを使用します。Oracle Service Bus JMS 転送では、実行時にこの一時的なキューを使用します。
図 2-3 は、WebLogic Server JAX-RPC 要求/応答サービスと Oracle Service Bus プロキシ サービスとの相互運用性を表します (JAX-RPC 発信の場合)。
| 注意 : | 1 つ目の WebLogic Server ドメインのプロキシ サービスが 2 つ目のドメインのプロキシ サービスにメッセージを送信する必要がある場合、まずドメイン 1 のパススルー ビジネス サービスにメッセージをルーティングする必要があります。ドメイン 1 とドメイン 2 の間の JMS ストア アンド フォワードでは、ドメイン 2 のプロキシ サービスに着信要求メッセージを転送します。JMS 要求/応答を使用する場合、JMS ストア アンド フォワードを使用して、ドメイン 2 からドメイン 1 に着信応答メッセージを転送することもできます。この場合、ドメイン 2 のプロキシ サービスに対して、エクスポートされる着信要求キューとインポートされる着信応答キューをドメイン 2 でコンフィグレーションする必要があります。JMS ストア アンド フォワードのコンフィグレーションに特に注意する必要があります。 |
|