メッセージ・インフローとトランザクション・インフロー

メッセージ・インフローとトランザクション・インフローの概要

メッセージ・インフローとは、リソース・アダプタを使用した、EISからアプリケーション・サーバーへのインバウンド通信のことです。インバウンド・メッセージは、WebLogic Serverとリソース・アダプタの外部にあるトランザクション・マネージャが制御しているトランザクションの一部である場合もあります。

以下の図は、リソース・アダプタにおけるメッセージング・インフローとトランザクション・インフローの仕組みの概要と、ワーク・マネージャが果たす役割を示したものです。トランザクション・インフローの詳細は、「トランザクション・インフロー」も参照してください。

図7-1 メッセージ・インフローとトランザクション・インフローのアーキテクチャ

「図7-1 メッセージ・インフローとトランザクション・インフローのアーキテクチャ」の説明

アーキテクチャのコンポーネント

図7-1には、次のコンポーネントが含まれます。

クライアント・アプリケーション。WebLogic Server上で動作するアプリケーションへ接続しますが、EISにも接続する必要があります。
外部システム。この場合は、EIS (エンタープライズ情報システム)です。
アプリケーション・コンポーネント(EJB)。クライアント・アプリケーションがリソース・アダプタを介してアウトバウンド・リクエストをEISにアウトバウンドするために使用します。
メッセージ・エンドポイント・アプリケーション(メッセージドリブンBeanやその他のJava EEコンポーネント)。リソース・アダプタを介してEISからインバウンド・メッセージをインバウンドするために使用されます。
WebLogic Serverワーク・マネージャとそれに関連付けられた1つまたは複数のスレッド。リソース・アダプタはWorkインスタンスをワーク・マネージャに送信して、インバウンド・メッセージの処理やその他のアクションを行います。
外部のトランザクション・マネージャ。EISからのメッセージのトランザクション・インフローでは、WebLogic Serverトランザクション・マネージャが外部のトランザクション・マネージャに従属します。
WebLogic Serverコネクタ・コンテナ。この中にリソース・アダプタがデプロイされます。コンテナでは以下のものを管理します。
- EISとの双方向(インバウンドおよびアウトバウンド)通信を提供する、デプロイされたリソース・アダプタ。
- アクティブなWorkインスタンス。
- 複数の管理対象接続(MC1、...、MCn)。リソース・アダプタからEISへの物理的なアウトバウンド接続を表現するオブジェクトです。
- 接続ハンドル(C-handle)。リソース・アダプタの接続ファクトリからアプリケーション・コンポーネントに返されます。アプリケーション・コンポーネントがEISとの通信に使用します。
- 複数のアクティブ化仕様のうちの1つ。ここでは、特定のメッセージ・リスナー・タイプMLT-jに対応するアクティブ化仕様(ActivationSpec)があります。ActivationSpecクラスの要件の詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第13章「Message Inflow」を参照してください。
- コンテナが保持している接続プールの1つ。特定のManagedConnectionFactoryに対応し、管理対象接続を管理するために使用されます(この場合はMCF-2。コネクタ・コンテナには、1つのEISとの接続やさまざまなEISとの接続など、各種の接続に対応する複数の接続プールを含めることができます)。
- MessageEndpointFactory。EJBコンテナが作成し、リソース・アダプタがMessageEndpointインスタンス(MDBプールのMDBインスタンス)のプロキシを作成するために使用します。
外部のメッセージ・ソース。EISまたはメッセージ・プロバイダです。

インバウンド通信のシナリオ

この節では、図に示されている基本的なインバウンド通信のシナリオについて説明します。インバウンド・メッセージがEISで発生し、リソース・アダプタに流入して、メッセージドリブンBeanによって処理される仕組みを紹介します。関連情報は、図1-1を参照してください。

一般的で簡略化されたインバウンド・シーケンスのステップは次のとおりです。

EISはメッセージをリソース・アダプタに送信します。
リソース・アダプタはメッセージを検査して、メッセージのタイプを判断します。
リソース・アダプタはWorkオブジェクトを作成してワーク・マネージャに送信できます。ワーク・マネージャは以降の作業を別のスレッドで実行し、その間にリソース・アダプタは他の着信メッセージを待機し続けることができます。
メッセージ・タイプに基づいて、リソース・アダプタは(直接またはWorkインスタンスの一環として)、メッセージの送信先となる正しいメッセージ・エンドポイントをルックアップします。
必要なメッセージ・エンドポイントの種類に応じたメッセージ・エンドポイント・ファクトリを使用して、リソース・アダプタはメッセージ・エンドポイントを作成します(このエンドポイントは、MDBプールのメッセージドリブンBeanインスタンスへのプロキシです)。
リソース・アダプタはエンドポイントのメッセージ・リスナー・メソッドを呼び出して、EISから受信したメッセージに基づくメッセージ・コンテンツをエンドポイントに渡します。
メッセージは以下のいずれかの方法でMDBによって処理されます。
1. MDBがメッセージを直接処理して、その結果をリソース・アダプタ経由でEISに戻します。
2. MDBが他のアプリケーション・コンポーネントにメッセージを配信します。
3. クライアントが取り出せるようにMDBがメッセージをキューに入れます。
4. MDBがクライアント・アプリケーションと直接通信します。

メッセージ・インフローの仕組み

メッセージ・インフローを管理するために、EISからアプリケーション・サーバーへのインバウンド通信をサポートするリソース・アダプタには、通常、独自の通信チャネルとプロトコル、認識されたメッセージ・タイプのセット、およびディスパッチ・メカニズムが含まれています。

EISに接続して通信するには、独自の通信チャネルとプロトコルが必要です。通信チャネルとプロトコルは、リソース・アダプタがデプロイされているアプリケーション・サーバーからは見えません。「独自の通信チャネルとプロトコル」を参照してください。
リソース・アダプタによって認識される1つ以上のメッセージ・タイプが設定されている必要があります。
特定のタイプのメッセージをアプリケーション・サーバー内の別のコンポーネントにディスパッチするためにはディスパッチ・メカニズムが必要です。

インバウンド・メッセージの処理

リソース・アダプタでは、様々な方法でインバウンド・メッセージを処理できます。たとえば、次のような方法があります。

メッセージをローカルで、つまり、他のコンポーネントを呼び出さずにResourceAdapter Beanの内部で処理します。
別のアプリケーション・コンポーネントにメッセージを渡します。たとえば、EJBをルックアップしてそのEJBのメソッドを呼び出すことができます。
メッセージ・エンドポイントにメッセージを送信します。通常、メッセージ・エンドポイントはメッセージドリブンBean (MDB)です。詳細は、「メッセージ・エンドポイント(メッセージドリブンBean)へのメッセージ・インフロー」を参照してください。

インバウンド・メッセージは、メッセージを送信しているEISに結果を戻すことができます。レスポンスをすぐに必要とするメッセージのことを同期的と呼びます(送信側システムはレスポンスを待機します)。また、これはリクエスト/レスポンス・メッセージングとも呼ばれます。リソース・アダプタとの同じやり取りの一部としてレスポンスを期待しないメッセージは、非同期的または通知ベースの通信と呼ばれます。リソース・アダプタでは、上記の3つの宛先のすべてについて、同期または非同期の通信をサポートできます。

リソース・アダプタとEISのトランザクションの機能に応じて、着信メッセージをトランザクション(XA)の一部とすることも、トランザクション非対応にすることもできます。メッセージがXAである場合、トランザクションの制御は、外部トランザクション・マネージャ(トランザクション・インフロー)またはアプリケーション・サーバーのトランザクション・マネージャによって管理されます。「トランザクション・インフロー」を参照してください。

ほとんどの場合、リソース・アダプタ内のインバウンド・メッセージは、Workインスタンスを介して、別のスレッドでディスパッチされます。リソース・アダプタは、行うべき作業をWorkインスタンスにラップし、そのインスタンスをアプリケーション・サーバーのワーク・マネージャに送信して実行と管理を委ねます。リソース・アダプタは、作業のスケジューリング要件に応じて、doWork()、startWork()、またはscheduleWork()メソッドを使用してWorkインスタンスを送信できます。

独自の通信チャネルとプロトコル

リソース・アダプタでは、接続の構成情報を、ResourceAdapter beanのプロパティとして、またはActivationSpecオブジェクトのプロパティとしてなど、様々な手段でデプロイヤに公開できます。または、アウトバウンド・トラフィックと同じ通信チャネルをインバウンドにも使用する方法があります。こうすると、構成情報をアウトバウンド接続プールにも設定できます。

メッセージ・エンドポイント(メッセージドリブンBean)へのメッセージ・インフロー

EJB 2.1以降、メッセージドリブンBean (MDB)は、インバウンド・リソース・アダプタからのメッセージ配信に対応しています。EJB 2.1より前のMDBは、Java Message Service (JMS)のメッセージングのみをサポートしていました。つまり、MDBではonMessage(javax.jms.Message)メッセージ・リスナー・メソッドを含むjavax.jms.MessageListenerインタフェースを実装する必要がありました。MDBはJMSコンポーネントにバインドされ、JMSサブシステムがMDBのインスタンスのonMessage()メソッドを呼び出すことで、メッセージをMDBに配信していました。EJB 2.1では、JMSのみのMDBの制限はなくなりました。

リソース・アダプタを介したMDBへのメッセージ配信に関する主な要素は以下のとおりです。

(リソース・アダプタ/EISの規約により決定される)特定のタイプのインバウンド・メッセージ
リソース・アダプタが実装するActivationSpecオブジェクト
メッセージ・タイプとメッセージ・リスナー・インタフェース間のマッピング
特定のメッセージ・リスナー・インタフェースを実装するMDB
MDBとリソース・アダプタのデプロイメント時のバインド

メッセージドリブンBeanの詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のメッセージドリブンEJBに関する項を参照してください。

MDBとリソース・アダプタのデプロイメント時のバインド

リソース・アダプタは、(スタンドアロンのRARとして)独立してデプロイすることも、エンタープライズ・アプリケーション(EAR)の一部としてデプロイすることもできます。MDBも、(スタンドアロンのJARとして)独立して、またはエンタープライズ・アプリケーション(EAR)の一部としてデプロイできます。どちらの場合でも、リソース・アダプタからメッセージが配信されるMDBを、リソース・アダプタにバインドする必要があります。次の項では、MDBとリソース・アダプタのバインドと、その後のメッセージング処理について説明します。

MDBとリソース・アダプタのバインド

MDBとリソース・アダプタをバインドするには、次を行う必要があります:

リソース・アダプタのweblogic-ra.xmlデプロイメント記述子でjndi-name要素を設定します。weblogic-ra.xmlスキーマのExample A-を参照してください。
リソース・アダプタの対応するjndi-name要素で設定された値と一致するように、weblogic-ejb-jar.xmlデプロイメント記述子のadapter-jndi-name要素を設定します。
リソース・アダプタがMDBより先にデプロイされるとします(リソース・アダプタをデプロイする前にMDBをデプロイすることもできます。その場合、デプロイされたMDBはリソース・アダプタがデプロイされるまでポーリングします)。リソース・アダプタがデプロイされるときに、ResourceAdapter Beanは指定された名前でJNDIにバインドされます。
MDBがデプロイされます。MDBコンテナは、リソース・アダプタをそのJNDI名でルックアップする、アプリケーション・サーバー固有のAPIを呼び出し、仕様で規定されているリソース・アダプタのendpointActivation(MessageEndpointFactory, ActivationSpec)メソッドを呼び出します。
MDBコンテナはリソース・アダプタに、構成済みのActivationSpec (構成情報を含む)と、メッセージ・エンドポイント・インスタンスを作成するためのファクトリを提供します。
リソース・アダプタは、後でメッセージ配信に使用するためにこの情報を保存します。それによって、リソース・アダプタは、MDBが実装しているメッセージ・リスナー・インタフェースを知ることができます。この情報は、MDBに配信されるメッセージの種類を判断するために重要です。

メッセージのディスパッチ

メッセージがEISからリソース・アダプタに届くと、リソース・アダプタはそのディスパッチ先を判断します。イベントのシーケンスは次のようになります。

メッセージがEISからリソース・アダプタに届きます。
リソース・アダプタはメッセージを調べて、内部の表を検索することでそのタイプを判断します。リソース・アダプタは、メッセージ・タイプが特定のペア(MessageEndpointFactory、ActivationSpec)に対応していることを判断します。
リソース・アダプタは、メッセージをMDBにディスパッチすべきかどうかを判断します。
(MDBにディスパッチされる)メッセージ・エンドポイントのタイプのMessageEndpointFactoryを使用し、そのファクトリのcreateEndpoint()を呼び出すことで、リソース・アダプタはMDBインスタンスを作成します。
リソース・アダプタはMDBインスタンスのメッセージ・リスナー・メソッドを呼び出し、必要な情報(着信メッセージの本文など)をMDBに渡します。
メッセージ・リスナーが値を返さない場合、メッセージのディスパッチ・プロセスは完了します。
メッセージ・リスナーが値を戻す場合、リソース・アダプタはその値の処理方法を判断します。EISとの規約に応じて、EISとさらに通信する場合、またはしない場合があります。

アクティブ化仕様

リソース・アダプタに、メッセージ・タイプとアクティブ化仕様とのマッピングを構成します。アクティブ化仕様は、javax.resource.spi.ActivationSpecを実装するJavaBeanです。リソース・アダプタでは、サポートするメッセージ・タイプごとにActivationSpecクラスを用意します。「インバウンド接続の構成」で説明するように、メッセージ・タイプとアクティブ化仕様のマッピングはra.xmlデプロイメント記述子で構成します。ActivationSpecsの詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第13章「Message Inflow」を参照してください。

管理対象オブジェクト

『JSR 322: Java EE Connector Architecture 1.6』の13.4.2.3項で説明されているように、リソース・アダプタでは、メッセージング・スタイルやメッセージ・プロバイダに固有の管理対象オブジェクトを表す、オプションのJavaBeanクラスのJavaクラス名とインタフェース型を提供することができます。ra.xmlおよびweblogic-ra.xmlデプロイメント記述子ファイルのadmin-objects要素で、管理対象オブジェクトを構成します。発信接続や他のWebLogicリソース・アダプタの構成要素と同じように、次の3つのレベルで管理対象オブジェクトを定義できます。

グローバル - default-properties要素を使用して、リソース・アダプタのすべての管理対象オブジェクトに適用するパラメータを指定します。表A-15のweblogic-ra.xmlスキーマを参照してください。
グループ - admin-object-group要素を使用して、ra.xmlデプロイメント記述子で指定された特定の管理対象オブジェクト・グループに属する、すべての管理対象オブジェクトに適用するパラメータを指定します。グループで指定されたプロパティは、グローバル・レベルで指定されたパラメータをオーバーライドします。「admin-object-group」を参照してください。

admin-object-interface要素(admin-object-group要素のサブ要素)は、各admin-object-groupに必須の一意の要素(キー)として機能します。weblogic-ra.xmlのadmin-object-interface要素とra.xmlのadmin-object-interface要素の間には1対1の関係がなければなりません。
インスタンス - weblogic-ra.xmlデプロイメント記述子のadmin-object-instance要素を使用して、各管理対象オブジェクト・グループの下に管理対象オブジェクト・インスタンスを指定できます。これは、リソース・アダプタに対する個別の管理対象オブジェクトに相当します。admin-object-properties下位要素を使用して、インスタンス・レベルでプロパティを指定することもできます。インスタンス・レベルで指定されたプロパティは、グループ・レベルやグローバル・レベルで指定されたプロパティをオーバーライドします。「admin-object-instance」を参照してください。

トランザクション・インフロー

トランザクション・インフローは、トランザクション・インフロー規約によって確立します。トランザクション・インフロー規約によって、リソース・アダプタは、EISが開始したトランザクション完了呼出しやクラッシュ・リカバリ呼出しを処理できます。また、トランザクション・インフロー規約により、インポートされるトランザクションのACIDプロパティも維持されます。トランザクション・インフローの詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第15章「Transaction Inflow」を参照してください。

EISは、リソース・アダプタを介してアプリケーション・サーバーにメッセージを渡すときに、メッセージの配信や作業を実行するためのトランザクション・コンテキストを渡すことができます。インバウンド・トランザクションは、リソース・アダプタおよびアプリケーション・サーバーの外部にあるトランザクション・マネージャによって制御されます。「メッセージ・エンドポイント(メッセージドリブンBean)へのメッセージ・インフロー」を参照してください。

リソース・アダプタは、トランザクション制御において、EISとアプリケーション・サーバー間のブリッジとして機能することもできます。つまり、リソース・アダプタはメッセージを受信し、そのメッセージを、外部トランザクション・マネージャとのトランザクションに参加するためにXAコールバックとして解釈します。

WebLogic Serverは、介在トランザクション・マネージャを通じて、外部トランザクション・マネージャのXAリソースとして機能できます。WebLogic Serverトランザクション・マネージャは、そのようなトランザクションの場合、外部トランザクションIDをWebLogic Server固有のトランザクションIDにマップします。

WebLogic Serverトランザクション・マネージャは、外部トランザクション・マネージャに従属しています。つまり、外部トランザクション・マネージャが、トランザクションが成功するかロールバックされるかを最終的に判断します。『Oracle WebLogic Server JTAアプリケーションの開発』のサード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加に関する項を参照してください。リソース・アダプタがそのようなトランザクションに参加する機能は、Java EEコネクタ・アーキテクチャ1.6の一部として、Java EE標準APIで公開されています。

リソース・アダプタが外部のトランザクションに参加する仕組みを次の手順で示します。詳細は、『JSR 322: Java EE Connector Architecture 1.6』の15.4項「Transaction Inflow Model,」を参照してください。

リソース・アダプタはインバウンド・メッセージを、着信メッセージとともに到着したトランザクション・コンテキストとともに受信します。
リソース・アダプタはjavax.transaction.xa.Xidインスタンスを使用してトランザクション・コンテキストを表します。
リソース・アダプタは、着信メッセージを処理してメッセージ・エンドポイントに配信するために新しいWorkインスタンスを作成します。また、ExecutionContext (javax.resource.spi.work.ExecutionContext)のインスタンスを作成して、作成済みのXidおよびトランザクション・タイムアウト値を設定します。コネクタ・アーキテクチャのバージョン1.6は標準クラス、TransactionContextを定義します。このクラスは、EISのトランザクション・コンテキストをアプリケーション・サーバーに伝播するため、ExecutionContextのかわりにリソース・アダプタで使用される場合があります。
リソース・アダプタはWorkオブジェクトとTransactionContext (またはExecutionContext)をワーク・マネージャに送信して処理を委ねます。ここで、ワーク・マネージャは、トランザクションを登録してWebLogic Serverトランザクション・マネージャでトランザクションを開始するために必要な作業を実行します。

TransactionContextを使用するため、Workクラスでは次の処理が必要です。
1. javax.resource.spi.work.WorkContextProviderインタフェースを実装します。
2. getWorkContexts()メソッドでTransactionContextインスタンスを作成して返します。
ノート:

リソース・アダプタがTransactionContextを使用する場合、アダプタではExecutionContextを使用しないでください。
外部トランザクション・マネージャからの以降のXA呼出しは、リソース・アダプタを介して送信されて、WebLogic Serverトランザクション・マネージャに伝達されます。このように、リソース・アダプタは、外部トランザクション・マネージャと、リソース・マネージャとして機能するWebLogic Serverトランザクション・マネージャとの間で、XA呼出しのブリッジの役割を果たします。

ローカルで管理されるトランザクションでのトランザクション・インフロー・モデルの使用

リソース・アダプタが、リソース・アダプタと同じサーバー・インスタンス内で動作するアプリケーション・コンポーネントからリクエストを受け取り、そのリクエストが、リソース・アダプタ・リクエストと同じトランザクションの一部としてMDBに配信される必要がある場合、現在のスレッドのトランザクションからトランザクションIDを取得してTransactionContext (またはExecutionContext)に格納する必要があります。

この場合、WebLogic Serverは介在トランザクション・マネージャは使用しないで、MDBへのメッセージ配信に使用される作業スレッドにトランザクションを渡します。

長時間実行するWorkの構成および管理

WebLogic ServerではHintsContext.LONGRUNNING_HINTの使用をサポートしており、リソース・アダプタのWorkクラスでtrueに設定されている場合、Workインスタンスが、WebLogic ServerによってWorkスレッドではなく別のデーモン・スレッドでスケジューリングされる、長時間実行するWorkアイテムとして設定されます。LONGRUNNING_HINTは、WebLogic Serverの拡張注釈@LongRunningと同じ機能を実行します。

WebLogic ServerはConnectorWorkManagerRuntimeMBeanを提供することでコネクタ・アーキテクチャ1.6を拡張し、この中には長時間実行するWorkインスタンスを構成および監視するための属性が含まれます。この属性も、次の項で説明するとおり、WebLogic Server管理コンソールで公開されます。

@LongRunning拡張注釈の詳細は、Oracle WebLogic Server Java APIリファレンスのLongRunningに関する項を参照してください。

同時に長時間実行するWorkインスタンスの最大数の設定

長時間実行するワークはそれぞれ固有のデーモン・スレッドで実行されるため、同時に長時間実行するWorkインスタンスの数は最小限にすることをお薦めします。同時に長時間実行するWorkインスタンスの数が多すぎると、WebLogic Serverのスレッド・リソースを使い果たすおそれがあり、サーバーのパフォーマンスと安定性に悪影響を及ぼします。WebLogic Serverは、将来のリリースで、許可されている同時長期間の作業の最大数に関する制限事項を導入する可能性があります。

WebLogic Server管理コンソールを使用して、同時Workインスタンス・リクエストの最大許容数を次のように設定できます。

「デプロイメントのサマリー」>「制御」ページでリソース・アダプタを選択します。
「構成」>「ワークロード」を選択します。
必要に応じて「同時長時間実行リクエストの最大数」に新しい値を入力し、「保存」をクリックします。

新しい値を保存すると、「デプロイメント・プラン保存アシスタント」が表示され、デプロイメント・プラン・ファイルのパスの選択または入力が求められます。デプロイメント・プランの操作の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverデプロイメントに関する項を参照してください。

次の点に注意してください。

同時Workインスタンス・リクエストの最大許容数は、「長時間実行するWorkの監視」に記述されているように、WebLogic Server管理コンソールのリソース・アダプタ: モニタリング: ワークロードページにも表示されます
WebLogic Server管理コンソールを使用するかわりに、weblogic-ra.xmlファイルでmax-concurrent-long-running-requests要素を使用して、同時Workインスタンス・リクエストの最大許容数を設定することもできます。詳細は、「connector-work-manager」を参照してください

長時間実行するWorkの監視

ConnectorWorkManagerRuntimeMBeanは、リソース・アダプタの固有のワーク・マネージャに関する長時間実行ランタイム情報を次のMBean属性で公開します:

ConnectorWorkManagerRuntimeMBean.ActiveLongRunningRequests — 現在アクティブな長時間実行Workインスタンス・リクエストの数を返します。
ConnectorWorkManagerRuntimeMBean.CompletedLongRunningRequests — 完了した長時間実行Workインスタンス・リクエストの数を返します。
ConnectorWorkManagerRuntimeMBean.MaxConcurrentLongRunningRequests — 同時Workインスタンス・リクエストの最大許容数を返します。

現在アクティブな、または完了した長時間実行Workインスタンス・リクエストの情報を、WebLogic Server管理コンソールを使用して表示するには:

「デプロイメントのサマリー」>「制御」ページでリソース・アダプタを選択します。

「監視」>「ワークロード」を選択します。

長時間実行Workインスタンス・リクエストに関する次の情報は、「長時間実行ワーク・マネージャ」表から得られます。

表7-1 「長時間実行ワーク・マネージャ」表の列の説明

列名	説明
アクティブなリクエスト	現在アクティブな長時間実行`Work`インスタンス・リクエストの数
完了したリクエスト	完了した長時間実行`Work`インスタンス・リクエストの数
許可された最大同時リクエスト数	同時`Work`インスタンス・リクエストの最大許容数