アダプタの開発

サービス アダプタの開発

サービス接続は、クライアントから XML 要求ドキュメントを受け取ると、基底の EIS で該当する関数を呼び出します。サービス接続はメッセージのコンシューマであり、応答を返す場合と返さない場合があります。サービス接続では、以下の 4 つの機能が実行されます。

この節では、以下の内容を扱います。

WebLogic Integration に限定されない J2EE 準拠アダプタ

この節では、WebLogic Integration で使用するアダプタを開発する手順を中心に説明します。また一部の手順を修正することで、WebLogic Integration 環境以外で使用できるアダプタも ADK で開発できます。手順については、「WebLogic Integration に限定されないアダプタの作成」を参照してください。

実行時環境のサービス接続

図 6-1 および図 6-2 は、実行時環境でサービス接続を使用する場合に実行される処理を示します。図 6-1 は非同期サービス接続、図 6-2 は同期サービス接続を示します。

イベント フロー

図 6-3 は、サービス接続の開発手順の概要です。

手順 1 : 環境要件の調査

サービス接続の開発を始める前に、そのサポート環境に必要なリソースを確認する必要があります。この節では、開発環境における要件を詳しく説明します。必要なリソースの完全なリストについては、「アダプタ設定ワークシート」を参照してください。

手順 2 : 開発環境のコンフィグレーション

この節では、環境をコンフィグレーションするための 4 つの手順 (手順 2a から 2d まで) を説明します。

手順 2a : ディレクトリ構造の設定

WebLogic Integration のインストール時に、アダプタを実行するだけでなく ADK を使用するために必要なディレクトリ構造も作成されます。ADK 関連のファイルは WLI_HOME/adapters/ ディレクトリに格納されています。WLI_HOME は、WebLogic Integration のインストール ディレクトリです。インストール時に、WLI_HOME ディレクトリに必要なディレクトリおよびファイルが作成されていることを必ず確認してください。

以下の表では、WLI_HOME のディレクトリ構造を説明します。

web.xml および weblogic.xml 記述子ファイル

通常、アダプタの web.xml および weblogic.xml 記述子は、非常に単純なパターンに従います。これらのファイルには、設計時の Web アプリケーションのすべての JSP ページの名前およびその他の設定情報が記述されます。多くのアダプタの Web 記述子は非常に似ているため、ADK には自動的に Web 記述子を生成する方法が用意されています。そのためアダプタ開発者は、サイズが大きく、他のアダプタの Web 記述子とほとんど一致するような Web 記述子を管理する必要がなくなります。

使用するアダプタの Ant build.xml で特別な Ant 対象をインクルードおよび呼び出すことで、Web アプリケーション記述子を生成しなければならないことがあります。GenerateAdapterTemplate を使用して ADK のサンプル アダプタのクローンを作成する場合、生成される build.xml には必要な Ant 対象およびその対象を使用するための呼び出しがすでに含まれています。WLI_HOME/adapters/sample/project/build.xml file を参照して、generate_web_descriptors 対象を検索してください。この Ant 対象には web-gen.properties と呼ばれるファイルがあり、そこに格納されている情報から web.xml および weblogic.xml 記述子を生成します。サンプル アダプタ build.xml では、この対象は packages 対象の最上位付近で呼び出されます。

サンプル アダプタには web-gen.properties ファイルがテンプレートとして含まれ、使用するアダプタに合わせてこのファイルを修正できます。このファイルには以下のプロパティが記述されています。

GenerateAdapterTemplate で生成されたこのファイルのコピーに、使用するアダプタに適切な情報を記述します。元のファイルは変更しないでください。

ビルド時に、generate_web_descriptors 対象は web-gen.properties ファイルの情報を置き換え、使用するアダプタの設計時 Web アプリケーションに対応する web.xml および weblogic.xml 記述子を生成します。記述子は、使用するアダプタの src/war/WEB-INF ディレクトリに配置されます。

web.xml および weblogic.xml 記述子を厳密に制御する場合は、build.xml ファイル内の generate_web_descriptors への呼び出しをすべてコメント アウトすると web.xml および weblogic.xml 記述子を手動で管理できます。

ディレクトリ構造内での開発ツリーの作成

GenerateAdapterTemplate で開発ツリーのクローンを作成すると、自動的に WLI_HOME/adapters/sample の下にあるすべてのディレクトリの内容のクローンが作成され、新しい開発環境を反映するように更新されます。

この変更は WLI_HOME/adapters/ADAPTER/src/overview.html ファイルにも反映されます。ADAPTER は、新しい開発ディレクトリの名前です。このファイルには、新しいアダプタの config.xml ファイルにコピー アンド ペーストして、そのアダプタをホストするように WebLogic Integration を設定できるコードもあります。

手順 2b : アダプタ論理名の割り当て

アダプタに論理名を割り当てます。通常、この名前は、ベンダ名、アダプタに接続する EIS のタイプ、および EIS のバージョン番号の 3 つの項目を、以下のようにアンダースコアで区切って表します。

vendor_EIS-type_EIS-version

以下に例を示します。

BEA_WLS_SAMPLE_ADK

アダプタの論理名の詳細については、「アダプタ論理名」を参照してください。

手順 2c : ビルド プロセスの設定

ADK では、100% Pure Java ベースのビルド ツールである Ant をベースとするビルド プロセスが採用されます。Ant の詳細については、「Ant ベースのビルド プロセス」を参照してください。Ant の使用方法の詳細については、以下の URL を参照してください。

http://jakarta.apache.org/ant/index.html

ADK に用意されたサンプル アダプタ (WLI_HOME/adapters/sample/project 内) には、サンプル アダプタの Ant ビルド ファイル build.xml が含まれます。このファイルには、J2EE 準拠アダプタのビルドに必要なタスクが指定されています。GenerateAdapterTemplate ユーティリティを実行してアダプタの開発ツリーのクローンを作成すると、そのアダプタ専用の build.xml が作成されます。この自動ファイル生成により、サンプルの build.xml をカスタマイズする必要がなくなり、コードの正確さが保証されます。GenerateAdapterTemplate ユーティリティの使用方法の詳細については、「カスタム開発環境の作成」を参照してください。

マニフェスト ファイル

GenerateAdapterTemplate によって生成されるファイルに、マニフェスト ファイル MANIFEST.MF があります。このファイルには、このファイルを使用する各コンポーネントに対するクラスロード指示が定義されています。マニフェスト ファイルは、ear/META-INF を除く /META-INF ディレクトリごとに作成されます。

コード リスト 6-1 に、サンプル アダプタに付属のマニフェスト ファイルの例を示します。

Manifest-Version: 1.0

Created-By: BEA Systems, Inc.

Class-Path: shared.jar

このファイルの最初の 2 行には、バージョンおよびベンダ情報が定義されます。3 行目には、関連するクラスパスまたはクラスロード指示が定義されます。Class-Path プロパティには、コンポーネントが必要とするリソースへの参照および共有 JAR ファイルのリストが設定されます (リストのファイル名はスペース区切りで指定)。JAR ファイルが EAR ファイルの共有領域に格納されていることを確認してください (詳細については、「エンタープライズ アーカイブ (EAR) ファイル」を参照)。

JAR ツールでは、Class-Path: 行の長さの上限は 72 文字です。72 文字を超える行は、改行して 2 行目以降の各行の先頭にスペースを配置する必要があります。以下に例を示します。

Class-Path: .....72 文字のクラスパス
<スペース>クラスパスの続き

ADK のサンプル アダプタでは、以下の Ant コマンドにより、すべての共有 JAR ファイルが 1 つの JAR ファイル (shared.jar) に結合されています。

<jar jarfile='${LIB_DIR}/shared.jar'>
<zipfileset src='${LIB_DIR}/${JAR_FILE}'>
<exclude name='META-INF/MANIFEST.MF'/>
</zipfileset> 
<zipfileset src='${WLI_LIB_DIR}/adk.jar'>
<exclude name='META-INF/MANIFEST.MF'/>
</zipfileset>
<zipfileset src='${WLI_LIB_DIR}/adk-eventgenerator.jar'> 
<exclude name='META-INF/MANIFEST.MF'/> 
</zipfileset>
<zipfileset src='${WLI_LIB_DIR}/wlai-core.jar'>
<exclude name='META-INF/MANIFEST.MF'/>
</zipfileset>
<zipfileset src='${WLI_LIB_DIR}/wlai-client.jar'> 
<exclude name='META-INF/MANIFEST.MF'/>
</zipfileset>
</jar>

build.xml のコンポーネント

build.xml の動作内容を確認するには、ファイルを開いてコンポーネントを調べます。この節では、主なファイル要素を説明します。build.xml の内容を確認する場合は、ここに記載された説明を参照してください。

手順 2d : メッセージ バンドルの作成

エンドユーザ向けのメッセージはメッセージ バンドルに格納する必要があります。メッセージ バンドルは、2 つ以上の自然言語でメッセージを生成できる「key=value」の組み合わせを含む .properties テキスト ファイルです。実行時にロケールおよび地域言語が指定されると、メッセージの内容が、該当する key=value の組み合わせに基づいて解釈され、メッセージがユーザのロケールに適切な言語で表示されます。

メッセージ バンドルは、通常は src ツリーのルートである WLI_HOME/adapters/adapter/src/bundle_name-base.properties に格納されます。bundle_name はアダプタの論理名です。前述したように、この基本メッセージ バンドルは、ADK.properties バンドル (WLI_HOME/adapters/src/ADK.properties 内) と結合することによって、実行時にロードされる最終的な bundle_name.properties ファイルを作成します。これにより、アダプタのメッセージ バンドル ファイル内に物理的にコピーまたは保持することなく、最終的なバンドルに ADK で定義されたプロパティを組み込むことができます。そのため、WebLogic Integration の新しいリリースが公開され、新しいロケールがサポートされる際に、これらのプロパティを更新またはアップグレードできます。

メッセージ バンドルの作成方法の詳細については、以下のサイトの JavaSoft チュートリアルでインターナショナライゼーションについて参照してください。

http://java.sun.com/docs/books/tutorial/i18n/index.html

手順 3 : SPI の実装

サービス プロバイダ インタフェース (Service Provider Interface : SPI) には、EIS 接続の提供および管理、トランザクションの境界設定の確立、およびサービス呼び出しのフレームワークの提供を行うオブジェクトが用意されています。すべての J2EE 準拠アダプタが、javax.resource.spi パッケージにあるこれらのインタフェースを実装する必要があります。

この節では、SPI の実装に使用できるインタフェースを説明します。SPI の実装作業には、少なくとも 3 つのインタフェースが必要です (「基本的な SPI の実装」を参照)。各インタフェースについて詳しく説明し、ADK に付属のサンプル アダプタでの拡張方法を紹介します。

最初に、3 つの必須インタフェースを説明します。次に、その他のインタフェースについて詳しく説明し、さらにそれらの使用目的や、アダプタで使用した場合の利点についても説明します。

基本的な SPI の実装

使用するアダプタ用の SPI を実装するには、少なくとも以下の 3 つのインタフェースを拡張する必要があります。

これら 3 つのインタフェースは、上記の順番で実装するのが理想的です。

この 3 つのインタフェースのほかに、使用するアダプタの要件に合わせて、この手順で説明するインタフェースを任意に実装できます。

ManagedConnectionFactory

javax.resource.spi.ManagedConnectionFactory

ManagedConnectionFactory インタフェースは、ManagedConnection および EIS 固有の接続ファクトリ インスタンスのファクトリです。このインタフェースは、ManagedConnection インスタンスのマッチングと作成を行うメソッドを提供して、接続プールをサポートします。

トランザクションの境界設定

ManagedConnectionFactory に必須のコンポーネントは、トランザクションの境界設定です。1 つのトランザクションにプログラムのどの文をインクルードするかを決定する機能が必要です。J2EE は、アプリケーション サーバとアダプタ (およびその基底のリソース マネージャ) との間のトランザクションの管理規約を定義します。トランザクションの管理規約は、2 つの部分で構成されます。この規約は、使用するトランザクションのタイプによって異なります。トランザクションには、以下の 2 つのタイプがあります。

XA 準拠トランザクション

分散トランザクション処理 (Distributed Transaction Processing : DTP) 環境では、javax.transaction.xa.XAResource ベースの規約がトランザクション マネージャとリソース マネージャ間で決定されます。JDBC ドライバまたは JMS プロバイダはこのインタフェースを実装して、グローバル トランザクションと、データベースまたはメッセージ サービス接続との間の関連付けをサポートします。

XAResource インタフェースは、外部トランザクション マネージャがトランザクションを制御する環境内でアプリケーション プログラムが使用することを目的とした任意のトランザクション リソースによってサポート可能なインタフェースです。

そのようなリソースの例として、アプリケーションが複数のデータベース接続を介してデータにアクセスするようなデータベース管理システムが挙げられます。各データベース接続は、トランザクション リソースとして、トランザクション マネージャに登録されます。トランザクション マネージャは、グローバル トランザクションに参加する接続ごとに XAResource を取得します。トランザクション マネージャは、start() メソッドを使用してグローバル トランザクションとリソースを関連付け、end() メソッドを使用してトランザクションとリソースの関連付けを解除します。リソース マネージャは、グローバル トランザクションを、start() メソッド呼び出しと end() メソッド呼び出しの間でそのデータに対して行われたすべての作業に関連付けます。

トランザクションのコミット時、トランザクション マネージャは、トランザクションを 2 フェーズ コミット プロトコルに従って準備、コミット、またはロール バックするようにリソース マネージャに指示します。

ローカル トランザクション

ローカル トランザクションの管理規約は、アダプタが javax.resource.spi.LocalTransaction インタフェースを実装して、基底のリソース マネージャで実行されるローカル トランザクションをサポートする際に確立されます。この規約によって、アプリケーション サーバがトランザクション管理のインフラストラクチャと実行時環境を提供できます。アプリケーション コンポーネントはこのトランザクション インフラストラクチャを利用して、使用するコンポーネントレベルのトランザクション モデルをサポートします。

トランザクションの境界設定のサポートの詳細については、以下の URL を参照してください。

http://java.sun.com/blueprints/guidelines/
designing_enterprise_applications/transaction_management/
platform/index.html

ADK の実装

ADK には、AbstractManagedConnectionFactory というアダプタの抽象基盤が用意されています。この基盤には、以下の機能があります。

以下の主要メソッドには、独自の実装が必要です。

以下の節で、これらのメソッドについて説明します。

createConnectionFactory()

createConnectionFactory() は、アダプタのアプリケーション レベルの接続ハンドル用ファクトリです。つまり、アダプタのクライアントは、このメソッドにより返されたオブジェクトを使用して EIS への接続ハンドルを取得します。

アダプタが CCI インタフェースをサポートする場合、com.bea.adapter.cci.ConnectionFactoryImpl のインスタンス、またはこのクラスの拡張を返すことをお勧めします。このメソッドを正しく実装するポイントは、ConnectionManager、LogContext、および ResourceAdapterMetaData をクライアント API に伝播することです。

protected Object
    createConnectionFactory(ConnectionManager connectionManager,
                            String strAdapterName,
                            String strAdapterDescription,
                            String strAdapterVersion,
                            String strVendorName)
    throws ResourceException

createManagedConnection()

createManagedConnection() は、使用するアダプタ用の ManagedConnection インスタンスの作成に使用します。以下のリストに、このメソッドの例を示します。

public ManagedConnection
createManagedConnection(Subject subject, ConnectionRequestInfo
info)
throws ResourceException

ManagedConnection インスタンスは、EIS との通信に必要な負荷の高いリソースをカプセル化します。このメソッドは、ConnectionManager がクライアントの要求を満たすために新しい ManagedConnection が必要と判断した場合に、ConnectionManager によって呼び出されます。アダプタの一般的な設計では、このメソッドで EIS との通信に必要なリソースを開き、そのリソースを新しい ManagedConnection インスタンスに渡すようにします。

checkState()

AbstractManagedConnectionFactory は、ファクトリに関する処理を実行する前に checkState() メソッドを呼び出します。このメソッドを使用して、ManagedConnectionFactory が担当する SPI タスクを実行する際に初期化する必要があるすべてのメンバーが正しく初期化されていることを確認します。

このメソッドは、以下のように実装します。

protected boolean checkState()

equals()

equals() メソッドは、オブジェクト引数が等しいかどうかをテストします。このメソッドは、ConnectionManager が接続プールの管理に使用するので、正しく実装する必要があります。等価の比較において、このメソッドは重要なメンバーをすべてインクルードする必要があります。

このメソッドは、以下のように実装します。

public boolean equals(Object obj)

hashCode()

hashCode() メソッドは、ファクトリで使用するハッシュ コードを提供します。また、ConnectionManager による接続プールの管理にも使用されます。このため、このメソッドは、オブジェクトのユニーク性を決定するプロパティに基づいて hashCode を生成します。

このメソッドは、以下のように実装します。

public int hashCode()

matchManagedConnections()

ManagedConnectionFactory は matchManagedConnections() メソッドを実装する必要があります。AbstractManagedConnectionFactory は、AbstractManagedConnection の compareCredentials() メソッドに依存する matchManagedConnections() メソッドを実装します。

管理対象接続にロジックを適合させるためには、AbstractManagedConnection クラスが提供する compareCredentials() メソッドをオーバーライドする必要があります。このメソッドは、ManagedConnectionFactory が接続を ConnectionManager に対する接続要求と一致させる場合に呼び出されます。

現在は、AbstractManagedConnectionFactory の実装は、指定された Subject/ConnectionRequestInfo パラメータから PasswordCredential を抽出します。どちらのパラメータも NULL であれば、このインスタンスの ManagedConnectionFactory が適正であることが保証されるため、このメソッドは true を返します。この実装を、以下のリストに示します。

public boolean compareCredentials(Subject subject,
                           ConnectionRequestInfo info)
            throws ResourceException
     {
       ILogger logger = getLogger();

次に、ADK の ManagedConnectionFactory を使用して、JAAS Subject または SPI ConnectionRequestInfo から、PasswordCredential を抽出する必要があります。以下のリストに例を示します。

PasswordCredential pc = getFactory().
getPasswordCredential(subject, info);
     if (pc == null)
     {
       logger.debug(this.toString() + ": compareCredentials

上記のリストでは、JAAS Subject および ConnectionRequestInfo が NULL であり、一致が予想されることを意味します。このメソッドは、このインスタンスのファクトリが適正であることが確認されてから呼び出されます。このため、Subject と ConnectionRequestInfo が両方とも NULL の場合は、デフォルトで資格が一致します。したがって、この接続の ping 結果により、比較結果の出力が決まります。以下のリストに、プログラムから接続を ping する方法を示します。

return ping();
}
        boolean bUserNameMatch = true;
        String strPcUserName = pc.getUserName();
           if (m_strUserName != null)
{

logger.debug(this.toString() + ": compareCredentials >>> comparing
  my username ["+m_strUserName+"] with client username
   ["+strPcUserName+"]");

次に、ユーザが Subject または ConnectionRequestInfo で指定されたユーザと一致するかどうか確認する必要があります。このアダプタでは再認証がサポートされていないため、ユーザ名が一致しない場合、このインスタンスは要求に対応できません。以下のコードは要求に対応できます。

bUserNameMatch = m_strUserName.equals(strPcUserName);

ユーザ名が一致したら、接続が有効であることを確認するために ping を行います。名前が一致しない場合は、ping する必要はありません。

接続を ping するには、以下のコードを使用します。

return bUserNameMatch ? ping() : false;

実装の説明

管理対象シナリオの場合、アプリケーション サーバは、アダプタの ManagedConnectionFactory の matchManagedConnections() メソッドを呼び出します。この指定では、アプリケーション サーバがどの ManagedConnectionFactory を使用して接続要求に対応するかを決定する方法を指示していません。ADK の AbstractManagedConnectionFactory は、matchManagedConnections() を実装します。

この実装では、最初に「これ」(つまり、ConnectionManager が matchManagedConnections を呼び出した対象の ManagedConnectionFactory インスタンス) と、アプリケーション サーバによって提供されたセット内の各 ManagedConnection の ManagedConnectionFactory との比較を行います。同じ ManagedConnectionFactory を持つセット内の各 ManagedConnection に対して、この実装は compareCredentials() メソッドを呼び出します。このメソッドにより、各 ManagedConnection オブジェクトが要求に対応できるかどうかを判別できます。

matchManagedConnections() は、ConnectionManager から呼び出されて (コード リスト 6-22 を参照)、管理しているプール内で有効な接続を検索します。このメソッドから NULL が返された場合、ConnectionManager は、createManagedConnection() を呼び出し、EIS に新しい接続を割り当てます。

public ManagedConnection
matchManagedConnections(Set connectionSet,
                            Subject subject,
                            ConnectionRequestInfo info)
        throws ResourceException

このクラスでは、以下の方法で接続のマッチングを行います。

デプロイメント時に必要な AbstractManagedConnectionFactory プロパティ

AbstractManagedConnectionFactory の基本実装を使用するには、デプロイメント時に以下の表のプロパティを指定する必要があります。

ADK のその他の主要な ManagedConnectionFactory 機能

ADK のサンプル アダプタは、AbstractManagedConnectionFactory を拡張する sample.spi.ManagedConnectionFactoryImpl と呼ばれるクラスを提供します。このクラスは、ADK の基本クラスを拡張する方法の例として使用してください。

ManagedConnectionFactory と呼ばれるサンプル アダプタの実装コードの完全なリストについては、以下を参照してください。

WLI_HOME/adapters/sample/src/sample/spi/
ManagedConnectionFactoryImpl.java

ManagedConnection

javax.resource.spi.ManagedConnection

ManagedConnection オブジェクトは、EIS に対する接続設定に必要なすべての負荷の高いリソースをカプセル化します。ManagedConnection インスタンスは、基底の EIS に対する物理的な接続を表します。ManagedConnection オブジェクトは、管理対象環境でアプリケーション サーバによってプールされます。

ADK の実装

ADK では ManagedConnection の抽象実装を提供しています。この基本クラスは、接続イベント リスナおよび複数アプリケーションレベルの接続ハンドルを ManagedConnection のインスタンスごとに管理するロジックを提供します。

ManagedConnection インタフェースを実装する場合、基底の EIS が提供するトランザクションの境界設定のサポートを決定する必要があります。トランザクションの境界設定の詳細については、「トランザクションの境界設定」を参照してください。

ADK には、javax.resource.spi.ManagedConnection インタフェースの抽象実装である AbstractManagedConnection が用意されています。以下の機能があります。

ADK に付属しているサンプル アダプタには、AbstractManagedConnection を拡張する ManagedConnectionImpl が用意されています。サンプル アダプタ ManagedConnection の完全なコード リストは、以下を参照してください。

WLI_HOME/adapters/sample/src/sample/spi/
ManagedConnectionFactoryImpl.java

ManagedConnectionMetaData

javax.resource.spi.ManagedConnectionMetaData

ManagedConnectionMetaData インタフェースは、ManagedConnection インスタンスに関連付けられた、基底の EIS インスタンスに関する情報を提供します。アプリケーション サーバは、この情報を使用して、接続した EIS インスタンスに関する実行時情報を取得します。

ADK の実装

ADK には、javax.resource.spi.ManagedConnectionMetaData および javax.resource.cci.ConnectionMetaData の 2 つのインタフェースの抽象実装である AbstractManagedConnectionMetaData が用意されています。以下の機能があります。

ADK に付属のサンプル アダプタには、AbstractManagedConnectionMetaData を拡張する ConnectionMetaDataImpl が用意されています。アダプタの完全なコード リストは、以下を参照してください。

WLI_HOME/adapters/sample/src/sample/spi/ConnectionMetaDataImpl.java

ConnectionEventListener

javax.resource.spi.ConnectionEventListener

ConnectionEventListener インタフェースは、アプリケーション サーバが ManagedConnection インスタンスからの通知を受信できるようにするイベント コールバック メカニズムを提供します。

ADK の実装

ADK には、ConnectionEventListener の 2 つの具象実装が用意されています。

ほとんどの場合は、ADK に用意されたこの 2 つの実装で十分なので、このインタフェースの独自の実装を用意する必要はありません。

ConnectionManager

javax.resource.spi.ConnectionManager

ConnectionManager インタフェースは、アダプタが接続要求をアプリケーション サーバに渡すのに使用できるフックを提供します。

ADK の実装

ADK には、このインタフェースの具象実装、com.bea.adapter.spi.NonManagedConnectionManager が用意されています。この実装は、非管理対象環境で実行中のアダプタに基本接続マネージャを提供します。管理対象環境では、このインタフェースはアプリケーション サーバによって提供されます。ほとんどの場合に、ADK が提供する実装を使用できます。

NonManagedConnectionManager は、javax.resource.spi.ConnectionManager インタフェースの具象実装です。これは、アダプタの非管理シナリオにおいて ConnectionManager として機能しますが、接続プールなどのサービスの品質は提供しません。

ConnectionRequestInfo

javax.resource.spi.ConnectionRequestInfo

ConnectionRequestInfo インタフェースにより、アダプタが独自の要求に固有のデータ構造を接続要求のフローに渡すことができます。アダプタは、空のインタフェースを拡張して、接続要求に対する独自のデータ構造をサポートします。

ADK の実装

ADK には、javax.resource.spi.ConnectionRequestInfo インタフェースの具象実装が用意されています。このインタフェースは、ConnectionRequestInfoMap と呼ばれます。これは、ユーザ名やパスワードなど、接続が確立されるときに要求される情報への java.util.Map インタフェースを提供します。

LocalTransaction

javax.resource.spi.LocalTransaction

LocalTransaction インタフェースは、EIS リソース マネージャ内で管理されているトランザクションをサポートするため、外部トランザクション マネージャは必要ありません。

ADK の実装

ADK には、このインタフェースの抽象実装である AbstractLocalTransaction が用意されており、LocalTransaction の EIS 固有の部分の実装に専念できます。具体的には、以下の機能があります。

手順 4 : CCI の実装

J2EE 準拠アプリケーションは、クライアント インタフェースを使用してバックエンド システムにアクセスできます。クライアント インタフェースは、クライアント アプリケーションとバックエンド システム間のデータ フローを管理しますが、コンテナまたはアプリケーション サーバとアダプタとのやり取りに関する可視性を持ちません。クライアント インタフェースは、EIS との対話における要求および応答のレコードのフォーマットを指定します。

最初に、アダプタが J2EE 準拠 CCI (Common Client Interface) をサポートする必要があるかどうかを判断する必要があります。現在の J2EE 仕様では CCI は必須ではありませんが、将来のバージョンでは必須になることが予想されます。このため、ADK では、アダプタの CCI インタフェースの実装を支援することに重点を置いています。

この節の利用方法

この節 (手順 4 : CCI の実装) では、CCI の実装に使用できるいくつかのインタフェースを説明します。CCI の実装には、少なくとも 2 つのインタフェースが必要です (「基本的な CCI の実装」を参照)。各インタフェースについて詳しく説明し、ADK に付属のサンプル アダプタでの拡張方法を紹介します。

この 2 つの必須インタフェースの説明に続いて、その他のインタフェースの詳細やこれらのインタフェースを使用する理由や利点を説明します。

基本的な CCI の実装

使用するアダプタ用の CCI を実装するには、少なくとも以下の 2 つのインタフェースを拡張する必要があります。

この 2 つのインタフェースは、できるだけ上記の順番で実装してください。

また、アダプタに必要な以下のインタフェースを任意に実装できます。

Connection

javax.resource.cci.Connection

Connection は、クライアントが基底の物理接続にアクセスするときに使用する、アプリケーションレベルのハンドルを表します。Connection インスタンスに関連付けられた実際の物理接続は、ManagedConnection インスタンスによって表されます。

クライアントは、ConnectionFactory インスタンスの getConnection() メソッドを使用することにより、Connection インスタンスを取得します。Connection は、0 個以上の Interaction インスタンスと関連付けることができます。

ADK の実装

ADK には、このインタフェースの抽象実装である AbstractConnection が用意されています。この実装には以下の機能があります。

このクラスは、以下のメソッドの実装を提供して拡張する必要があります。

public Interaction createInteraction()

throws ResourceException

このメソッドは、この接続に関連付けられた対話を作成します。この対話により、アプリケーションが EIS 関数を実行できるようになります。このメソッドの動作は、以下のとおりです。

Interaction

javax.resource.cci.Interaction

javax.resource.cci.Interaction により、コンポーネントは EIS 関数を実行できます。Interaction インスタンスは、EIS インスタンスと対話する以下の方法をサポートします。

Interaction インスタンスは接続から作成され、Interaction インスタンスと Connection インスタンス間の関連付けを維持するために必要です。close() メソッドは、対話のためにアダプタが維持するすべてのリソースを解放します。Interaction インスタンスをクローズしても、関連付けられた Connection インスタンスのクローズはトリガされません。

ADK の実装

ADK には、このインタフェースの実装である AbstractInteraction が用意されています。この実装では、以下の機能があります。

このインタフェースには、execute() が実装された AbstractInteraction の具象拡張を指定する必要があります。execute() には 2 つのバージョンがあります。これらについては、以下の節で説明します。

execute() バージョン 1

コード リスト 6-23 で宣言されている execute() メソッドは、InteractionSpec で表される対話を示します。

public boolean execute(InteractionSpec ispec,
                       Record input,
                       Record output)
                throws ResourceException

このように呼び出した場合、execute() は入力 Record を取得して出力 Record を更新します。以下を返します。

以下の表に、execute() バージョン 1 のパラメータを示します。

execute() バージョン 2

コード リスト 6-24 で宣言されている execute() メソッドは、InteractionSpec で表される Interaction も実行します。

public Record execute(InteractionSpec ispec,
                      Record input)
               throws ResourceException

この形で呼び出されると、execute() は入力 Record を取り込んで、Interaction が正常に実行されると、出力 Record を返します。

このメソッドの動作は、以下のとおりです。

例外が発生した場合、このメソッドによって Connection に通知され、メソッドのクローズなどの適切なアクションが発生します。

以下の表に、execute() バージョン 2 のパラメータを示します。

XCCI を使用した CCI の実装

XCCI (XML-CCI) は、XML ベースのレコード フォーマットを使用してデータを表現する Client Connector Interface の固有言語です。これらのフォーマットは、フレームワークおよびツールによってサポートされています。通常、XML-CCI は XCCI という略称で呼ばれます。

XCCI には、サービスおよび DocumentRecords という 2 つのコンポーネントがあります。

サービス

サービスは、EIS で使用できる機能を表し、次の 4 つのコンポーネントで構成されます。

サービスが要求または応答データを必要としないことを示すには、DesignTimeRequestHandler で、要求または応答に対して空または NULL の IDocumentDefinition を作成します。また、サービスの IServiceDescriptor の要求または応答の IDocumentDescriptor に、空または NULL の IDocumentDescriptor インスタンスを設定することもできます。空または NULL の IDocumentDefinition インスタンスは静的 DocumentFactory.createNullDocumentDefinition() メソッドを使用して作成します。空または NULL の IDocumentDescriptor インスタンスは静的 DescriptorFactory.createNullDocumentDescriptor() メソッドを使用して作成します。

生成された IServiceDescriptor または設計時にアダプタにより生成された IApplicationViewDescriptor で空または NULL のドキュメント定義または記述子を使用する場合、これらのサービスの NULL 要求または応答ドキュメントは、必ず実行時に処理する必要があります。つまり、空または NULL のドキュメント記述子を使用するアダプタが、実行時に要求または応答ドキュメントが NULL であると認識する必要があります。

アプリケーション ビューの実行時エンジンは、要求または応答を必要とするサービスが NULL 以外の要求または応答ドキュメントを受け取ることや、要求または応答を必要としないサービスが NULL の要求または応答ドキュメントを受け取ることを保証します。

DocumentRecord

com.bea.connector.DocumentRecord

実行時に、XCCI レイヤは DocumentRecord オブジェクトをサービスの入力として受け取り、DocumentRecord オブジェクトをサービスからの出力として返します。DocumentRecord は、javax.resource.cci.Record および com.bea.document.IDocument の両インタフェースを実装しています。Record インタフェースについては、「Record」を参照してください。

IDocument は、アダプタ内の CCI レイヤからの XML 入力および出力を支援するインタフェースで、以下の節で説明します。

IDocument

com.bea.document.IDocument

IDocument は、W3C DOM (Document Object Model) に準拠する高次元のラッパーです。IDocument インタフェースの最も重要な付加価値は、XML ドキュメントの要素に XPath インタフェースを提供する点です。つまり、XPath 文字列を使用して、IDocument オブジェクトのクエリや更新を実行できます。たとえば、コード リスト 6-25 の XML ドキュメントは、Bob という名前の人物に関する詳細を記録するための XML の使用方法を示します。

<Person name="Bob">
    <Home squareFeet="2000"/>
    <Family>
       <Child name="Jimmy">
          <Stats sex="male" hair="brown" eyes="blue"/>
       </Child>
       <Child name="Susie">
          <Stats sex="female" hair="blonde" eyes="brown"/>
        </Child>
    </Family>
</Person>

IDocument を使用して、コード リスト 6-26 に示す XPath コードで Jimmy の髪の色を検索できます。

System.out.println("Jimmy's hair color: " +
   person.getStringFrom("//Person[@name=\"Bob\"]/Family/Child
   [@name=\"Jimmy\"]/Stats/@hair");

一方、DOM を使用する場合、コード リスト 6-27 に示すコードを使用してクエリを発行する必要があります。

String strJimmysHairColor = null;
org.w3c.dom.Element root = doc.getDocumentElement();
if (root.getTagName().equals("Person") &&
    root.getAttribute("name").equals("Bob") {
     org.w3c.dom.NodeList list = root.
        getElementsByTagName("Family");
   if (list.getLength() > 0) {
     org.w3c.dom.Element family = (org.w3c.dom.
        Element)list.item(0);

    org.w3c.dom.NodeList childList = family.getElementsByTagName("Child");
    for (int i=0; i < childList.getLength(); i++) {
    org.w3c.dom.Element child = childList.item(i);
       if (child.getAttribute("name").equals("Jimmy")) {
    org.w3c.dom.NodeList statsList =
       child.getElementsByTagName("Stats");
       if (statsList.getLength() > 0) {
    org.w3c.dom.Element stats = statsList.item(0);
           strJimmysHairColor = stats.getAttribute("hair");

        }
      }
    }
  }
}

このように、IDocument によりコードを簡素化できます。

IDocument インスタンスでのネームスペースの適切な使い方

IDocument インスタンス内の XML インスタンス ドキュメントを渡す場合、IDocument インスタンスのアダプタまたはコンシューマが修飾された XPath 文を明示的に使用してデータのクエリを実行する場合以外は、インスタンス ドキュメントのテキスト内ではネームスペースやプレフィックスを使用しないでください。

この規則に違反すると、IDocument を使用するコードで実行時に障害が発生します。

また、IDocument を使用するサンプル アダプタおよび大部分のクライアントは XPath 式のステップを修飾する際にネームスペース プレフィックスを使用しないため、IDocument インスタンスとして表現された XML ドキュメントで XML ネームスペース宣言を使用しないでください。

たとえば、アプリケーション ビュー サービスの XML インスタンス ドキュメントで XML ネームスペース宣言を記述します。DBMS サンプル アダプタは、IDocument インタフェースを使用して要求データ フィールドを検索します。この場合、使用するプロセッサの問題で、IDocument は、ステップが修飾されていない XPath を使用して、デフォルトの XML ネームスペースを使用する XML インスタンス ドキュメントのデータ フィールドを検索できません。

その結果、DBMS サンプル アダプタ (または、IDocument または Xalan XPath を使用して XML インスタンスからデータ フィールドを取得するコード) は、要求ドキュメントから適切なフィールド データを取得できません。

以下のドキュメントを考えます。

<Input>
   <FirstName>Joe</FirstName>
</Input> 

呼び出し IDocument.getDocumentData("/Input/FirstName") は Joe を返します。

デフォルト ネームスペースを使用する以下のドキュメントを考えます。

<Input xmlns="my URI">
<FirstName>Joe</FirstName>
</Input>

呼び出し IDocument.getDocumentData("/Input/FirstName") は空の文字列を返します。XPath プロセッサは、my URI ネームスペースからデータを選択するための XPath のステップを検出せず、空のネームスペースだけを検出します。

ADK に付属の XCCI クラス

ADK には、アダプタ用の XCCI の実装に役立つ以下のクラスおよびインタフェースが用意されています。

この節では、これらのクラスおよびインタフェースを説明します。

AbstractDocumentRecordInteraction

com.bea.adapter.cci.AbstractDocumentRecordInteraction

このクラスは、ADK の抽象基本 Interaction である、com.bea.adapter.cci.AbstractInteraction を拡張します。このクラスにより、DocumentRecords の操作に便利なメソッドが提供され、実装する必要があるエラー処理が軽減されます。具体的には、このクラスは以下のように宣言します。

protected abstract boolean execute(
  InteractionSpec ixSpec,
  DocumentRecord inputDoc, 
  DocumentRecord outputDoc 
) throws ResourceException

および

protected abstract DocumentRecord execute(
  InteractionSpec ixSpec, 
  DocumentRecord inputDoc
) throws ResourceException

これらのメソッドは、出力レコードが DocumentRecord オブジェクトであることが確認されてから、具象実装で呼び出されます。

DocumentDefinitionRecord

com.bea.adapter.cci.DocumentDefinitionRecord

このクラスを使用すると、アダプタが DocumentRecordInteraction 実装から IDocumentDefinition を返すことができるようになります。このクラスは、サービスの要求ドキュメント定義または応答ドキュメント定義を作成する設計時要求に対応する場合に役立ちます。

DocumentInteractionSpecImpl

com.bea.adapter.cci.DocumentInteractionSpecImpl

このクラスを使用することで、実行時に execute メソッドに渡される InteractionSpec に、サービスの要求ドキュメント定義と応答ドキュメント定義を保存できます。この機能は、アダプタの Interaction が実行時にサービスの XML スキーマにアクセスする必要がある場合に役立ちます。

XCCI の設計パターン

XCCI でよく使用される設計パターンは、Interaction 実装でのサービス定義のサポートです。この設計パターンを使用すると、アダプタの javax.resource.cci.Interaction 実装により、クライアント プログラムは WebLogic Integration サービスを定義するために、基底の EIS からメタデータを検索できます。これにより、この対話にはサービスの要求と応答の XML スキーマおよびその他のメタデータを生成する機能が必要です。Interaction により、クライアント プログラムは EIS で提供される関数のカタログを参照することもできます。この方法により、アダプタの軽量クライアント アーキテクチャを活用できます。

ADK には、この設計パターンの実装に役立つ com.bea.adapter.cci.DesignTimeInteraction- SpecImpl クラスが用意されています。sample.cci.InteractionImpl クラスは、DesignTimeInteractionSpecImpl クラスを使用してこの設計パターンを実装する方法を例示します。

非 XML J2EE 準拠アダプタの使用

ADK には、WebLogic Integration で非 XML アダプタを使用するためのプラグイン メカニズムが用意されています。あらかじめ構築されたすべてのアダプタが、その javax.resource.cci.Record データ型として XML を使用するわけではありません。たとえば、以下のような場合、XML は使用できません。

ADK には、このようなタイプのアダプタを実装する際に役立つ com.bea.connector.IRecordTranslator インタフェースが用意されています。実行時に、Application Integration エンジンは、アダプタの IRecordTranslator 実装を使用して要求および応答レコードを変換し、アダプタのサービスを実行します。

Application Integration エンジンでは、com.bea.connector.DocumentRecord タイプの javax.resource.cci.Record のみをサポートするため、この独自のフォーマットを要求および応答レコード用のドキュメント レコードに変換する必要があります。この場合、アダプタの CCI 対話レイヤを書き直す必要はありません。IRecordTranslator インタフェースを実装するアダプタの EAR ファイルにクラスをインクルードすることにより、Application Integration エンジンは要求および応答の各レコードに対して、トランスレータ クラスの変換メソッドを実行できます。

InteractionSpec 実装クラスと IRecordTranslator 実装クラスの間には、1 対 1 の相関関係があります。複数のタイプの InteractionSpec 実装を持つアダプタは、それぞれの実装に対して IRecordTranslator 実装クラスを必要とします。プラグイン アーキテクチャは、アダプタの InteractionSpec の完全クラス名およびフレーズ RecordTranslator を使用してトランスレータ クラスを名前でロードします。たとえば、アダプタの InteractionSpec クラスの名前が com.bea.adapter.dbms.cci.InteractionSpecImpl である場合、エンジンは com.bea.adapter.dbms.cci.InteractionSpecImplRecordTranslator クラスをロードします (後者のクラスが有効な場合)。

実装する必要のあるメソッドについては、以下の URL の com.bea.connector.IRecordTranslator の Javadoc を参照してください。

http://edocs.bea.com/wli/docs92/wli.javadoc/

ConnectionFactory

javax.resource.cci.ConnectionFactory

ConnectionFactory は、EIS インスタンスへの接続を取得するためのインタフェースを提供します。ConnectionFactory インタフェースの実装は、アダプタによって提供されます。

アプリケーションは、JNDI ネームスペースから ConnectionFactory インスタンスをルックアップし、このインスタンスを使用して EIS 接続を取得します。

JNDI 登録をサポートするには、java.io.Serializable および javax.resource.Referenceableinterfaces を実装する必要があります。そのためには、ConnectionFactory の実装クラスが必要です。

ADK の実装

ADK には、javax.resource.cci.ConnectionFactory インタフェースの具象実装である ConnectionFactoryImpl が用意されており、以下の機能があります。

通常、このクラスは拡張せずにそのまま使用できます。

ConnectionMetaData

javax.resource.cci.ConnectionMetaData

ConnectionMetaData は、Connection インスタンスによって接続された EIS インスタンスに関する情報を提供します。コンポーネントは、Connection.getMetaData メソッドを呼び出して ConnectionMetaData インスタンスを取得します。

ADK の実装

デフォルトでは、ADK には com.bea.adapter.spi.AbstractConnectionMetaData クラスを介したこのクラスの実装が用意されています。この抽象クラスを拡張して、その 4 つの抽象メソッドをアダプタに実装する必要があります。

ConnectionSpec

javax.resource.cci.ConnectionSpec

ConnectionSpec は、アプリケーション コンポーネントが接続要求固有のプロパティを ConnectionFactory.getConnection() メソッドに渡すときに使用されます。

この ConnectionSpec インタフェースを JavaBean として実装し、ツールをサポートできるようにすることをお勧めします。ConnectionSpec 実装クラスのプロパティは、ゲッター メソッドおよびセッター メソッドのパターンによって定義します。

CCI 仕様により、ConnectionSpec の標準プロパティ セットが定義されます。プロパティは、派生インタフェース、または空の ConnectionSpec インタフェースの実装クラスで定義されます。また、アダプタに基底の EIS に固有のプロパティを定義できます。

ADK の実装

ConnectionSpec 実装は JavaBean でなければならないため、ADK にはこのクラスの実装は用意されていません。

InteractionSpec

javax.resource.cci.InteractionSpec

InteractionSpec には、EIS インスタンスとの対話を行うためのプロパティが格納されています。特に、これは対話で基底の EIS で指定された関数を実行するときに使用されます。

CCI 仕様により、InteractionSpec の標準プロパティ セットが定義されます。標準プロパティを基底の EIS に適用しない場合、InteractionSpec 実装で標準プロパティをサポートする必要はありません。

InteractionSpec 実装クラスは、サポートする各プロパティに対してゲッター メソッドとセッター メソッドを提供する必要があります。このゲッター メソッドとセッター メソッドの規約は、JavaBean 設計パターンに基づく必要があります。

InteractionSpec インタフェースは、ツールをサポートするために JavaBean として実装する必要があります。InteractionSpec インタフェースの実装クラスは、java.io.Serializable インタフェースを実装する必要があります。

InteractionSpec には、Record にはないが、呼び出す EIS 関数を決定するときに役立つ情報が格納されます。

以下の表では、標準プロパティについて説明します。

以下の標準プロパティは、Interaction インスタンスの ResultSet 要件に関する判断基準として使用されます。

CCI 実装では、InteractionSpec インタフェースに記述されたプロパティ以外の追加プロパティを指定できます。

ADK の実装

ADK には、javax.resource.cci.InteractionSpec の具象実装である InteractionSpecImpl が用意されています。このインタフェースは、表 6-5 で説明されている標準対話プロパティのゲッター メソッドおよびセッター メソッドを使用して拡張できる、基本実装を提供します。

LocalTransaction

javax.resource.cci.LocalTransaction

LocalTransaction インタフェースは、アプリケーションレベルのローカル トランザクションの境界設定に使用されます。このインタフェースは、リソース マネージャのローカル トランザクションに対するトランザクションの境界設定インタフェースを定義します。システム規約レベルの LocalTransaction インタフェース (javax.resource.spi パッケージで定義) は、コンテナのローカル トランザクション管理に使用されます。

ローカル トランザクションは、リソース マネージャ内で管理されます。ローカル トランザクションの調整には、外部トランザクション マネージャは関与しません。

CCI 実装は、LocalTransaction インタフェースを実装できます (省略可能)。LocalTransaction インタフェースが CCI 実装でサポートされている場合、Connection.getLocalTransaction() メソッドは、LocalTransaction インスタンスを返します。コンポーネントは、返された LocalTransaction を使用して、基底の EIS インスタンスで (Connection インスタンスに関連付けられた) リソース マネージャのローカル トランザクションの境界設定を行うことができます。

com.bea.adapter.spi.AbstractLocalTransaction クラスでもこのインタフェースを実装します。

ローカル トランザクションの詳細については、「トランザクションの境界設定」を参照してください。

Record

javax.resource.cci.Record

javax.resource.cci.Record インタフェースは、Interaction で定義される execute() メソッドへの入力またはメソッドからの出力を表現するための基本インタフェースです。execute() メソッドの詳細については、「execute() バージョン 1」および「execute() バージョン 2」を参照してください。

MappedRecord または IndexedRecord に、Record を追加できます。これは、MappedRecord および IndexedRecord を使用して任意の深さの階層構造を作成できることを意味します。MappedRecord または IndexedRecord で表される階層構造のリーフ要素として、基本 Java タイプが使用されます。

Record インタフェースを拡張して、以下の表のいずれかの表現を生成できます。

アダプタが CCI インタフェースを実装する場合、サービスに対してどのレコード フォーマットを使用するかを次に検討する必要があります。各サービスに対し、要求レコード (サービスへの入力) および応答レコード (EIS からの応答) のフォーマットを指定する必要があります。

ADK の実装

ADK では、CCI レイヤにおける XML ベースのレコード フォーマットの実装を支援することに重点を置いています。そのため、ADK には DocumentRecord クラスが用意されています。また、BEA のスキーマ ツールキットを使用して、サービスの要求および応答ドキュメントを記述するスキーマを開発できます。

ADK には、レコード名およびレコード記述に対するゲッター メソッドおよびセッター メソッドを提供する javax.resource.cci.Record インタフェースの具象実装である RecordImpl が用意されています。

また、XML ベースのレコード フォーマットを使用する (特に推奨) アダプタ プロバイダ向けに、ADK には com.bea.adapter.cci.Abstract DocumentRecordInteraction クラスが用意されています。クライアントはこのクラスを使用して、DocumentRecord オブジェクトを渡すことができます。また、このクラスは DocumentRecord の内容にアクセスする便利なメソッドを提供します。

ResourceAdapterMetaData

javax.resource.cci.ResourceAdapterMetaData

インタフェース javax.resource.cci.ResourceAdapterMetaData は、アダプタ実装の機能に関する情報を提供します。CCI クライアントは、ConnectionFactory.getMetaData を使用してアダプタのメタデータ情報を取得します。getMetaData() メソッドは、EIS インスタンスに対するアクティブな接続を必要としません。ResourceAdapterMetaData インタフェースを拡張すると、アダプタ実装に固有の情報をより細かく提供できます。

ADK の実装

ADK には、アダプタ メタデータをカプセル化し、すべてのプロパティに対してゲッターおよびセッターを提供するインタフェースである ResourceAdapterMetaDataImpl が用意されています。

手順 5 : 環境変数のサポートの有効化 (省略可能)

この手順は省略可能で、サービス定義で環境変数の使用を許可する場合に必要になります。環境変数の定義方法やアダプタに与える影響の詳細については、「設計時 GUI の開発」を参照してください。

実行時に、アダプタは環境変数セットを使って、対象の環境で使用するためにシステム管理者またはアプリケーション デプロイヤがコンフィグレーションした値を取得します。通常、変数を使用すると、サービスの 1 つまたは複数のプロパティの値での変数の参照が、実行時の変数の値で置き換えられます。どのプロパティか、プロパティの値のどの部分か、またどのような変数の参照が行われるかは、すべてアダプタ固有です。

環境変数を使用するには、現在実行中のサービスで使用する環境変数セットをアダプタが取得する必要があります。このような変数セットをアダプタが取得するには、以下の 2 つのいずれかの方法で行います。

ClientDataInteractionSpec の実装

このインタフェースは、setClientData(IClientData) メソッドの IClientData インスタンスを提供します。変数セットを取得するには、client_data_object.getVariableSet() メソッドを呼び出します。

DocumentInteractionSpecImpl の拡張

この場合は、独自に実装した java.beans.VetoableChangeListener.vetoableChange メソッドで java.beans.PropertyChange イベントをリスンします。PropertyChangeEvent.getPropertyName() メソッドが clientData を返すときに、そのイベントに対して getOldValue() を呼び出すことによって、IClientData を取得します。返された IClientData インスタンスを使用して、client_data_object.getVariableSet() メソッドを呼び出すことによって、変数セット (IVariableSet インスタンス) を取得できます。

IVariableSet インスタンスを取得したら、getVariable() を呼び出してその変数セットから変数を取得し、変数の値を使用して (元のプロパティ値の変数の参照を置換して) 実行時のプロパティ値を生成できます。

必要に応じて、com.bea.connector.VariableChangeListener インタフェースを実装し、IVariableSet.addListener(VariableChangeListener) メソッドを呼び出して変数セットのリスナ リストに実装クラスのインスタンスを追加することにより、この変数セットに対する変更をリスンできます。変数セットの変数またはその値が変更されるたびに、リスナの variableChange() への呼び出しによる通知が発生します。

実行時の環境変数の使用例については、WLI_HOME/adapters/dbms/src にある DBMS サンプル アダプタのソース コードを参照してください。

手順 6 : アダプタのテスト

ADK には、アダプタのテストに役立つ、ユニット テスト用のオープンソース ツール JUnit を強化するテスト ハーネス com.bea.adapter.test.TestHarness が用意されています。com.bea.adapter.test.TestHarness は、以下の処理を行います。

JUnit の詳細については、以下のサイトを参照してください。

http://www.junit.org

テスト ハーネスの使い方

ADK のテスト ハーネスを使用するには

ADK に付属のテスト ケース拡張

サンプル アダプタには、次の 2 つの基本 TestCase の拡張が付属しています。

sample.spi.NonManagedScenarioTestCase

NonManagedScenarioTestCase を使用すると、非管理対象シナリオの SPI および CCI クラスをテストできます。具体的には、以下の 4 つをテストします。

sample.event.OfflineEventGeneratorTestCase

sample.event.OfflineEventGeneratorTestCase を使用すると、Weblogic Server 外のイベント ジェネレータの内部機能をテストできます。具体的には、このクラスはイベント ジェネレータに対して以下のテストを行います。

sample.client.ApplicationViewClient

sample.client.ApplicationViewClient クラスは、アダプタをテストする別の方法を提供します。このクラスは、サービスを呼び出し、アプリケーション ビューのイベントをリスンする方法を示す Java プログラムです。Ant build.xml ファイルは、クライアント対象を提供し、ApplicationViewClient プログラムを使用できるようにします。ant client を実行する場合のデフォルトのコンフィグレーションは、プログラムの使用方法を表示することです。build.xml ファイルを編集すると、クライアント プログラムの入力パラメータを変更できます。

sample.client.ApplicationViewClient.java の例は、WLI_HOME/adapters/sample/src/sample/client を参照してください。

手順 7 : アダプタのデプロイ

SPI および CCI インタフェースを実装してアダプタをテストしたら、手動または WebLogic Server Administration Console を使用してアダプタを WebLogic Integration 環境にデプロイできます。詳細については、「アダプタのデプロイ」を参照してください。