WebLogicリソース・アダプタは、インバウンド接続を使用してメッセージ・インフローとトランザクション・インフローを処理します。これらのインバウンド接続では、EISとの間で使用される通信チャネルやプロトコル、リソース・アダプタによって認識されるメッセージ・タイプ、受信メッセージを処理してメッセージ・エンドポイントに送信するためのWorkインスタンスなど、いくつかの主要コンポーネントが必要になります。
メッセージ・インフローとは、リソース・アダプタを使用した、EISからアプリケーション・サーバーへのインバウンド通信のことです。インバウンド・メッセージは、WebLogic Serverとリソース・アダプタの外部にあるトランザクション・マネージャが制御しているトランザクションの一部である場合もあります。
以下の図は、リソース・アダプタにおけるメッセージング・インフローとトランザクション・インフローの仕組みの概要と、ワーク・マネージャが果たす役割を示したものです。トランザクション・インフローの詳細は、「トランザクション・インフロー」も参照してください。
図8-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によって処理される仕組みを紹介します。関連情報については、「図2-1」を参照してください。
一般的で簡略化されたインバウンド・シーケンスの手順は次のとおりです。
EISはメッセージをリソース・アダプタに送信します。
リソース・アダプタはメッセージを検査して、メッセージのタイプを判断します。
リソース・アダプタはWork
オブジェクトを作成してワーク・マネージャに送信できます。ワーク・マネージャは以降の作業を別のスレッドで実行し、その間にリソース・アダプタは他の着信メッセージを待機し続けることができます。
メッセージ・タイプに基づいて、リソース・アダプタは(直接またはWork
インスタンスの一環として)、メッセージの送信先となる正しいメッセージ・エンドポイントをルックアップします。
必要なメッセージ・エンドポイントの種類に応じたメッセージ・エンドポイント・ファクトリを使用して、リソース・アダプタはメッセージ・エンドポイントを作成します(このエンドポイントは、MDBプールのメッセージドリブンBeanインスタンスへのプロキシです)。
リソース・アダプタはエンドポイントのメッセージ・リスナー・メソッドを呼び出して、EISから受信したメッセージに基づくメッセージ・コンテンツをエンドポイントに渡します。
メッセージは以下のいずれかの方法でMDBによって処理されます。
MDBがメッセージを直接処理して、その結果をリソース・アダプタ経由でEISに戻します。
MDBが他のアプリケーション・コンポーネントにメッセージを配信します。
クライアントが取り出せるようにMDBがメッセージをキューに入れます。
MDBがクライアント・アプリケーションと直接通信します。
メッセージ・インフローを管理するために、EISからアプリケーション・サーバーへのインバウンド通信をサポートするリソース・アダプタには、通常、独自の通信チャネルとプロトコル、認識されたメッセージ・タイプのセット、およびディスパッチ・メカニズムが含まれています。
EISに接続して通信するには、独自の通信チャネルとプロトコルが必要です。通信チャネルとプロトコルは、リソース・アダプタがデプロイされているアプリケーション・サーバーからは見えません。「独自の通信チャネルとプロトコル」を参照してください。
リソース・アダプタによって認識される1つ以上のメッセージ・タイプが設定されている必要があります。
特定のタイプのメッセージをアプリケーション・サーバー内の別のコンポーネントにディスパッチするためにはディスパッチ・メカニズムが必要です。
リソース・アダプタでは、様々な方法でインバウンド・メッセージを処理できます。たとえば、次のような方法があります。
メッセージをローカルで、つまり、他のコンポーネントを呼び出さずにResourceAdapter
Beanの内部で処理します。
別のアプリケーション・コンポーネントにメッセージを渡します。たとえば、EJBをルックアップしてそのEJBのメソッドを呼び出すことができます。
メッセージ・エンドポイントにメッセージを送信します。通常、メッセージ・エンドポイントはメッセージドリブンBean (MDB)です。詳細は、「メッセージ・エンドポイント(メッセージドリブンBean)へのメッセージ・インフロー」を参照してください。
インバウンド・メッセージは、メッセージを送信しているEISに結果を戻すことができます。レスポンスをすぐに必要とするメッセージのことを同期的と呼びます(送信側システムはレスポンスを待機します)。また、これはリクエスト/レスポンス・メッセージングとも呼ばれます。リソース・アダプタとの同じやり取りの一部としてレスポンスを期待しないメッセージは、非同期的または通知ベースの通信と呼ばれます。リソース・アダプタでは、上記の3つの宛先のすべてについて、同期または非同期の通信をサポートできます。
リソース・アダプタとEISのトランザクションの機能に応じて、着信メッセージをトランザクション(XA)の一部とすることも、トランザクション非対応にすることもできます。メッセージがXAである場合、トランザクションの制御は、外部トランザクション・マネージャ(トランザクション・インフロー)またはアプリケーション・サーバーのトランザクション・マネージャによって管理されます。「トランザクション・インフロー」を参照してください。
ほとんどの場合、リソース・アダプタ内のインバウンド・メッセージは、Work
インスタンスを介して、別のスレッドでディスパッチされます。リソース・アダプタは、行うべき作業をWork
インスタンスにラップし、そのインスタンスをアプリケーション・サーバーのワーク・マネージャに送信して実行と管理を委ねます。リソース・アダプタは、作業のスケジューリング要件に応じて、doWork()
、startWork()
、またはscheduleWork()
メソッドを使用してWorkインスタンスを送信できます。
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に関する項を参照してください。
リソース・アダプタは、(スタンドアロンのRARとして)独立してデプロイすることも、エンタープライズ・アプリケーション(EAR)の一部としてデプロイすることもできます。MDBも、(スタンドアロンのJARとして)独立して、またはエンタープライズ・アプリケーション(EAR)の一部としてデプロイできます。どちらの場合でも、リソース・アダプタからメッセージが配信されるMDBを、リソース・アダプタにバインドする必要があります。次の項では、MDBとリソース・アダプタのバインドと、その後のメッセージング処理について説明します。
MDBとリソース・アダプタをバインドするには、次を行う必要があります:
weblogic-ra.xml
デプロイメント記述子でjndi-name
要素を設定します。weblogic-ra.xmlスキーマのExample A-を参照してください。jndi-name
要素で設定された値と一致するように、weblogic-ejb-jar.xml
デプロイメント記述子のadapter-jndi-name
要素を設定します。ResourceAdapter
Beanは指定された名前でJNDIにバインドされます。endpointActivation(MessageEndpointFactory, ActivationSpec)
メソッドを呼び出します。 ActivationSpec
(構成情報を含む)と、メッセージ・エンドポイント・インスタンスを作成するためのファクトリを提供します。メッセージがEISからリソース・アダプタに届くと、リソース・アダプタはそのディスパッチ先を判断します。イベントのシーケンスは次のようになります。
MessageEndpointFactory
、ActivationSpec
)に対応していることを判断します。MessageEndpointFactory
を使用し、そのファクトリのcreateEndpoint()
を呼び出すことで、リソース・アダプタはMDBインスタンスを作成します。リソース・アダプタに、メッセージ・タイプとアクティブ化仕様とのマッピングを構成します。アクティブ化仕様は、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は、リソース・アダプタを介してアプリケーション・サーバーにメッセージを渡すときに、メッセージの配信や作業を実行するためのトランザクション・コンテキストを渡すことができます。インバウンド・トランザクションは、リソース・アダプタおよびアプリケーション・サーバーの外部にあるトランザクション・マネージャによって制御されます。「メッセージ・エンドポイント(メッセージドリブン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
クラスでは次の処理が必要です。
javax.resource.spi.work.WorkContextProvider
インタフェースを実装します。
getWorkContexts()
メソッドでTransactionContext
インスタンスを作成して返します。
注意:
リソース・アダプタがTransactionContext
を使用する場合、アダプタではExecutionContext
を使用しないでください。
外部トランザクション・マネージャからの以降のXA呼出しは、リソース・アダプタを介して送信されて、WebLogic Serverトランザクション・マネージャに伝達されます。このように、リソース・アダプタは、外部トランザクション・マネージャと、リソース・マネージャとして機能するWebLogic Serverトランザクション・マネージャとの間で、XA呼出しのブリッジの役割を果たします。
リソース・アダプタが、リソース・アダプタと同じサーバー・インスタンス内で動作するアプリケーション・コンポーネントからリクエストを受け取り、そのリクエストが、リソース・アダプタ・リクエストと同じトランザクションの一部としてMDBに配信される必要がある場合、現在のスレッドのトランザクションからトランザクションIDを取得してTransactionContext
(またはExecutionContext
)に格納する必要があります。
この場合、WebLogic Serverは介在トランザクション・マネージャは使用しないで、MDBへのメッセージ配信に使用される作業スレッドにトランザクションを渡します。
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インスタンスの数が多すぎると、WebLogic Serverのスレッド・リソースを使い果たすおそれがあり、サーバーのパフォーマンスと安定性に悪影響を及ぼします。WebLogic Serverは、将来のリリースで、許可されている同時長期間の作業の最大数に関する制限事項を導入する可能性があります。
WebLogic Server管理コンソールを使用して、同時Work
インスタンス・リクエストの最大許容数を次のように設定できます。
次の点に注意してください。
同時Work
インスタンス・リクエストの最大許容数は、「長時間実行するWorkの監視」に記述されているように、WebLogic Server管理コンソールのリソース・アダプタ: モニタリング: ワークロードページにも表示されます
WebLogic Server管理コンソールを使用するかわりに、weblogic-ra.xml
ファイルでmax-concurrent-long-running-requests
要素を使用して、同時Work
インスタンス・リクエストの最大許容数を設定することもできます。詳細は、「connector-work-manager」を参照してください
ConnectorWorkManagerRuntimeMBeanは、リソース・アダプタの固有のワーク・マネージャに関する長時間実行ランタイム情報を次のMBean属性で公開します。
ConnectorWorkManagerRuntimeMBean.ActiveLongRunningRequests
— 現在アクティブな長時間実行Work
インスタンス・リクエストの数を返します。
ConnectorWorkManagerRuntimeMBean.CompletedLongRunningRequests
— 完了した長時間実行Work
インスタンス・リクエストの数を返します。
ConnectorWorkManagerRuntimeMBean.MaxConcurrentLongRunningRequests
— 同時Work
インスタンス・リクエストの最大許容数を返します。
現在アクティブな、または完了した長時間実行Work
インスタンス・リクエストの情報を、WebLogic Server管理コンソールを使用して表示する手順: