ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング
11gリリース1 (10.3.6)
B60996-04
  目次へ移動
目次
前
前 		 次
次		  

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

次の項では、WebLogicリソース・アダプタで着信接続を使用してメッセージ・インフローとトランザクション・インフローを扱う方法について説明します。

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

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

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

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

図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クラスの要件の詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)の第12章「Message Inflow」を参照してください。

    • コンテナが保持している接続プールの1つ。特定のManagedConnectionFactoryに対応し、管理対象接続を管理するために使用されます(この場合はMCF-2。コネクタ・コンテナには、1つのEISとの接続やさまざまなEISとの接続など、各種の接続に対応する複数の接続プールを含めることができます)。

    • MessageEndpointFactory。EJBコンテナが作成し、リソース・アダプタがMessageEndpointインスタンス(MDBプールのMDBインスタンス)のプロキシを作成するために使用します。

  • 外部のメッセージ・ソース。EISまたはメッセージ・プロバイダです。

着信通信のシナリオ

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

一般的で簡略化された着信シーケンスの手順は次のとおりです。

  1. EISはメッセージをリソース・アダプタに送信します。

  2. リソース・アダプタはメッセージを検査して、メッセージのタイプを判断します。

  3. リソース・アダプタはWorkオブジェクトを作成してワーク・マネージャに送信できます。ワーク・マネージャは以降の作業を別のスレッドで実行し、その間にリソース・アダプタは他の着信メッセージを待機し続けることができます。

  4. メッセージ・タイプに基づいて、リソース・アダプタは(直接またはWorkインスタンスの一環として)、メッセージの送信先となる正しいメッセージ・エンド・ポイントをルックアップします。

  5. 必要なメッセージ・エンド・ポイントの種類に応じたメッセージ・エンド・ポイント・ファクトリを使用して、リソース・アダプタはメッセージ・エンド・ポイントを作成します(このエンド・ポイントは、MDBプールのメッセージドリブンBeanインスタンスへのプロキシです)。

  6. リソース・アダプタはエンド・ポイントのメッセージ・リスナー・メソッドを呼び出して、EISから受信したメッセージに基づくメッセージ・コンテンツをエンド・ポイントに渡します。

  7. メッセージは以下のいずれかの方法でMDBによって処理されます。

    1. MDBがメッセージを直接処理して、その結果をリソース・アダプタ経由でEISに戻します。

    2. MDBが他のアプリケーション・コンポーネントにメッセージを配信します。

    3. クライアントが取り出せるようにMDBがメッセージをキューに入れます。

    4. MDBがクライアント・アプリケーションと直接通信します。

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

EISからアプリケーション・サーバーへの着信通信をサポートするリソース・アダプタは、通常以下のものを備えています。

着信メッセージの処理

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

  • メッセージをローカルで、つまり、他のコンポーネントを呼び出さずにResourceAdapter Beanの内部で処理します。

  • 別のアプリケーション・コンポーネントにメッセージを渡します。たとえば、EJBをルックアップしてそのEJBのメソッドを呼び出すことができます。

  • メッセージ・エンドポイントにメッセージを送信します。通常、メッセージ・エンドポイントはメッセージドリブンBean (MDB)です。詳細は、付録7「メッセージ・エンドポイント(メッセージドリブンBean)へのメッセージ・インフロー」を参照してください。

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

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

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

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

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

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

EJB 2.1より前のメッセージドリブンBean (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へのメッセージ配信に関する主な要素は以下のとおりです。

メッセージドリブンBeanの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のメッセージドリブンEJBに関する項を参照してください。

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

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

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

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

  1. リソース・アダプタのweblogic-ra.xmlデプロイメント記述子でjndi-name要素を設定します。付録A「weblogic-ra.xmlスキーマ」の「jndi-name」を参照してください。

  2. リソース・アダプタの対応するjndi-name要素で設定された値と一致するように、weblogic-ejb-jar.xmlデプロイメント記述子のadapter-jndi-name要素を設定します。

  3. リソース・アダプタがMDBより先にデプロイされるとします(リソース・アダプタをデプロイする前にMDBをデプロイすることもできます。その場合、デプロイされたMDBはリソース・アダプタがデプロイされるまでポーリングします)。リソース・アダプタがデプロイされるときに、ResourceAdapter Beanは指定された名前でJNDIにバインドされます。

  4. MDBがデプロイされます。MDBコンテナは、リソース・アダプタをそのJNDI名でルックアップする、アプリケーション・サーバー固有のAPIを呼び出し、仕様で規定されているリソース・アダプタのendpointActivation(MessageEndpointFactory, ActivationSpec)メソッドを呼び出します。

  5. MDBコンテナはリソース・アダプタに、構成済みのActivationSpec (構成情報を含む)と、メッセージ・エンド・ポイント・インスタンスを作成するためのファクトリを提供します。

  6. リソース・アダプタは、後でメッセージ配信に使用するためにこの情報を保存します。それによって、リソース・アダプタは、MDBが実装しているメッセージ・リスナー・インタフェースを知ることができます。この情報は、MDBに配信されるメッセージの種類を判断するために重要です。

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

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

  1. メッセージがEISからリソース・アダプタに届きます。

  2. リソース・アダプタはメッセージを調べて、内部の表を検索することでそのタイプを判断します。リソース・アダプタは、メッセージ・タイプが特定のペア(MessageEndpointFactory、ActivationSpec)に対応していることを判断します。

  3. リソース・アダプタは、メッセージをMDBにディスパッチすべきかどうかを判断します。

  4. (MDBにディスパッチされる)メッセージ・エンド・ポイントのタイプのMessageEndpointFactoryを使用し、そのファクトリのcreateEndpoint()を呼び出すことで、リソース・アダプタはMDBインスタンスを作成します。

  5. リソース・アダプタはMDBインスタンスのメッセージ・リスナー・メソッドを呼び出し、必要な情報(着信メッセージの本文など)をMDBに渡します。

  6. メッセージ・リスナーが値を返さない場合、メッセージのディスパッチ・プロセスは完了します。

  7. メッセージ・リスナーが値を戻す場合、リソース・アダプタはその値の処理方法を判断します。EISとの規約に応じて、EISとさらに通信する場合、またはしない場合があります。

アクティブ化仕様

リソース・アダプタに、メッセージ・タイプとアクティブ化仕様とのマッピングを構成します。アクティブ化仕様は、javax.resource.spi.ActivationSpecを実装するJavaBeanです。リソース・アダプタでは、サポートするメッセージ・タイプごとにActivationSpecクラスを用意します。「着信接続の構成」で説明するように、メッセージ・タイプとアクティブ化仕様のマッピングはra.xmlデプロイメント記述子で構成します。ActivationSpecsの詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)の第12章「Message Inflow」を参照してください。

管理対象オブジェクト

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

  • グローバル - default-properties要素を使用して、リソース・アダプタのすべての管理対象オブジェクトに適用するパラメータを指定します。「表A-10 admin-object-group」の「default-properties」を参照してください。

  • グループ - 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およびリソース・アダプタからWebLogic Serverにトランザクションが流入する仕組みについて説明します。トランザクション・インフロー規約によって、リソース・アダプタは、EISが開始したトランザクション完了呼出しやクラッシュ・リカバリ呼出しを処理することができます。また、インポートされるトランザクションのACIDプロパティも維持されます。トランザクション・インフローの詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)の第14章「Transaction Inflow」を参照してください。

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

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

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

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

リソース・アダプタが外部のトランザクションに参加する仕組みを以下に例示します。詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)の項14.4、「Transaction Inflow Model」を参照してください。

  1. リソース・アダプタは新しい外部トランザクションIDを持つ着信メッセージを受信します。

  2. リソース・アダプタは外部トランザクションIDをデコードして、Xid (javax.transaction.xa.Xid)を作成します。

  3. リソース・アダプタはExecutionContext (javax.resource.spi.work.ExecutionContext)のインスタンスを作成して、作成済みのXidおよびトランザクション・タイムアウト値を設定します。

  4. リソース・アダプタは、着信メッセージを処理してメッセージ・エンド・ポイントに配信するために、新しいWorkオブジェクトを作成します。

  5. リソース・アダプタはWorkオブジェクトとExecutionContextをワーク・マネージャに送信して処理を委ねます。ここで、ワーク・マネージャは、トランザクションを登録してWebLogic Serverトランザクション・マネージャでトランザクションを開始するために必要な作業を実行します。

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

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

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

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

@LongRunning

このリリースでは、WLSの拡張アノテーション@LongRunningを紹介します。作業は長時間の作業項目である場合、このアノテーションをワーク・クラスに適用します。これを使用すると、WLS JCAワーク・マネージャがこの作業をワーク・スレッドにではなくデーモン・スレッドにスケジュールします。

各長期間の作業は独自のデーモン・スレッドで実行されるので、同時に実行する長期間の作業の数を最小化しようとします。同時に実行している長期間の作業の数が多すぎると、アプリケーション・サーバーのスレッド・リソースを使い果たすおそれがあり、サーバーのパフォーマンスと安定性に悪影響が発生します。WLSは、将来のリリースで許可されている同時長期間の作業の最大数に関する制限事項を紹介する場合があります。

『Oracle Fusion Middleware Oracle WebLogic Server 10.3.1 APIリファレンス』のアノテーション・タイプLongRunningに関する項を参照してください。

  前
前 		 次
次
  目次へ移動
目次