WebLogic リソースアダプタプログラマーズガイド

リソースアダプタのパッケージ化とデプロイ

以下の節では、リソースアダプタをパッケージ化およびデプロイする方法について説明します。

WebLogic Server へのアプリケーションのデプロイについては、『WebLogic Server アプリケーションの開発』の「Deploying and Packaging from a Split Development Directory」で詳細に説明されています。

リソースアダプタのパッケージ化

プロダクションおよび開発目的では、アセンブル済みのリソースアダプタ (RAR) をエンタープライズアプリケーション (EAR) の一部としてパッケージ化することをお勧めします。

ディレクトリ構造のパッケージ化

リソースアダプタは、applications/ ディレクトリ内のリソースアダプタアーカイブ (RAR) に含まれる WebLogic Server コンポーネントです。デプロイメントプロセスは、リソースアダプタプロバイダによって作成されたコンパイル済みリソースアダプタインタフェースと実装クラスを格納する RAR またはデプロイメントディレクトリで開始されます。RAR とデプロイメントディレクトリは、どちらがコンパイル済みクラスを格納している場合でも、Java パッケージ構造と一致するサブディレクトリに入っている必要があります。

リソースアダプタでは、展開ディレクトリ形式または RAR のどちらにパッケージ化される場合でも、同じディレクトリ形式を使用します。リソースアダプタの一般的なディレクトリ構造をコードリスト 9-1 に示します。

コードリスト 9-1 リソースアダプタのディレクトリ構造

/META-INF/ra.xml

/META-INF/weblogic-ra.xml

/META-INF/MANIFEST.MF (省略可能)

/images/ra.jpg

/readme.html

/eis.jar

/utilities.jar

/windows.dll

/unix.so

パッケージ化の考慮事項

リソースアダプタに関するパッケージ化の要件は以下のとおりです。

デプロイメント記述子 (ra.xml と weblogic-ra.xml) は、META-INF というディレクトリに入っていなければなりません。
省略可能な MANIFEST.MF も META-INF サブディレクトリに入っています。マニフェストファイルは JAR ツールによって自動的に生成され、常に JAR ファイルの最初のエントリとなります。マニフェストファイルのデフォルトファイル名は META-INF/MANIFEST.MF です。マニフェストファイルには、そのアーカイブのメタ情報が格納されます。
WebLogic Server にデプロイされたリソースアダプタは、クラスまたはリソースをプロパティとして参照する MANIFEST.MF 内の class-path エントリをサポートします。
リソースアダプタには、リソースアダプタが使用する Java クラスおよびインタフェースを格納する複数の JAR (たとえば eis.jar や utilities.jar) を含めることができます。プラットフォーム固有のネイティブライブラリについて、リソースアダプタの依存関係がすべて解決されることを確認してください。
リソースアダプタには、EIS との対話用にリソースアダプタが必要とするネイティブライブラリ (たとえば windows.dll や unix.so) を含めることができます。
リソースアダプタには、マニュアルやリソースアダプタが直接には使用しない関連ファイル (たとえば readme.html や \images\ra.jpg) を含めることができます。
スタンドアロンのリソースアダプタ RAR をデプロイする場合、リソースアダプタはアプリケーションサーバ内のすべての J2EE アプリケーションで使用できなければなりません。
J2EE アプリケーションの EAR 内にリソースアダプタの RAR をパッケージ化してデプロイする場合、リソースアダプタはそのパッケージ化されている J2EE アプリケーションでのみ使用可能でなければなりません (この仕様に準拠した動作は必要に応じてオーバーライドできます)。

パッケージ化の制限

スタンドアロンのリソースアダプタを再ロードするときに、そのリソースアダプタを使用するクライアントを再ロードしない場合、クライアントは正常に機能しなくなる可能性があります (この制限事項は、リモート可用性のあるインタフェースを許可しないという J2CA 1.5 仕様の制限によるものです)。

リソースアダプタアーカイブ (RAR) のパッケージ化

1 つまたは複数のリソースアダプタをディレクトリにステージングしたら、.rar ファイル拡張子の付いた Java アーカイブ (JAR) にパッケージ化します。

注意 : リソースアダプタをアセンブルした後は、エンタープライズアプリケーションの一部としてパッケージ化することをお勧めします。これにより、従来の単一ディレクトリ構造に比べていくつかの利点がある分割開発ディレクトリ構造を利用できるようになります。『WebLogic Server アプリケーションの開発』の「Creating a Split Development Directory Environment 」を参照してください。

リソースアダプタをステージングおよびパッケージ化するには、次の手順に従います。

一時ステージングディレクトリをハードディスクの任意の場所に作成します。

対象となるリソースアダプタの Java クラスをステージングディレクトリにコンパイルまたはコピーします。

リソースアダプタの Java クラスを入れる JAR を作成します。この JAR をステージングディレクトリの最上位に追加します。

ステージングディレクトリに META-INF サブディレクトリを作成します。

META-INF サブディレクトリに ra.xml デプロイメント記述子を作成して、そのリソースアダプタのエントリを追加します。

注意 : ra.xml の文書型定義の詳細については、Sun Microsystems のドキュメント (http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd) を参照してください。

META-INF サブディレクトリに weblogic-ra.xml デプロイメント記述子を作成して、そのリソースアダプタのエントリを追加します。

注意 : weblogic-ra.xml ファイルの内容については、「weblogic-ra.xml スキーマ」を参照してください。

リソースアダプタクラスとデプロイメント記述子をステージングディレクトリに配置すると、次のような JAR コマンドを使用して RAR を作成できます。

jar cvf jar-file.rar -C staging-dir

このコマンドによって作成された RAR は、WebLogic Server にデプロイすることも、アプリケーションアーカイブ (EAR) にパッケージ化することもできます。
-C staging-dir オプションを指定すると、JAR コマンドはディレクトリを staging-dir に変更します。これにより、JAR に記録されるディレクトリパスがリソースアダプタのステージングディレクトリを基準にした相対パスとなります。

このトピックの詳細については、「リソースアダプタの作成とコンフィグレーション : 主な手順」を参照してください。

リソースアダプタのデプロイ

リソースアダプタのデプロイメントは、Web アプリケーション、EJB、およびエンタープライズアプリケーションのデプロイメントとほぼ同じです。これらのデプロイメントユニットと同様、リソースアダプタも展開ディレクトリ形式でデプロイしたり、アーカイブファイルとしてデプロイしたりすることができます。

デプロイメントオプション

Administration Console、weblogic.Deployer ツール、wldeploy Ant タスク、WebLogic Scripting Tool (WLST) のいずれかを使用して、スタンドアロンのリソースアダプタ (またはエンタープライズアプリケーションの一部としてパッケージ化されたリソースアダプタ) をデプロイできます。これらのアプリケーションのデプロイメント方法の詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Deploying Applications and Modules」を参照してください。

デプロイメントプランを使用してリソースアダプタデプロイメントをデプロイできます。リソースアダプタの場合、WebLogic Server デプロイメントプランは、RAR の外部にあるオプションの XML ドキュメントであり、特定の WebLogic Server 環境のデプロイメントとしてリソースアダプタがコンフィグレーションされます。デプロイメントプランでは、リソースアダプタのデプロイメント記述子で通常定義するようなデプロイメントプロパティ値を設定したり、デプロイメント記述子で既に定義されているプロパティ値をオーバーライドしたりします。デプロイメントプランの詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Configuring Applications for Production Deployment」を参照してください。

自動デプロイメントを使用してリソースアダプタをデプロイすることもできます。この方法は開発時や初期テスト時に便利です。詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Auto-Deploying Applications in Development Domains」を参照してください。

リソースアダプタのデプロイメント名

リソースアダプタアーカイブ (RAR) またはデプロイメントディレクトリをデプロイする場合は、myResourceAdapter のように、デプロイメントユニットの名前を指定する必要があります。この名前を使用すると、後でリソースアダプタをアンデプロイしたり更新したりする場合に、リソースアダプタのデプロイメントを簡単に参照できます。

リソースアダプタをデプロイする場合は、WebLogic Server が、RAR またはデプロイメントディレクトリのパスおよびファイル名と一致するデプロイメント名を暗黙的に割り当てます。この名前を使用すると、サーバが起動した後にリソースアダプタをアンデプロイまたは更新できます。

リソースアダプタのデプロイメント名は、サーバが再起動されるまで、WebLogic Server 内でアクティブなままです。リソースアダプタをアンデプロイしても、関連付けられたデプロイメント名は削除されません。したがって、後でその名前を使用してリソースアダプタを再デプロイできます。

プロダクションの再デプロイメント

WebLogic Server のプロダクションの再デプロイメント機能を使用すると、同じアプリケーションの古いバージョンと一緒に、WebLogic Server アプリケーションの新しいバージョンを再デプロイできます。デフォルトでは、WebLogic Server は直ちに新しいクライアントリクエストを新しいバージョンのアプリケーションにルーティングする一方で、既存のクライアント接続は古いバージョンにルーティングします。古いバージョンのアプリケーションを使用するすべてのクライアントが作業を完了したら、WebLogic Server は、新しいバージョンだけがアクティブになるように、古いバージョンを廃止します。

Suspendable インタフェースとプロダクションの再デプロイメント

一般に、リソースアダプタ Bean は javax.resource.spi.ResourceAdapter インタフェースを実装します。このインタフェースでは start() および stop() メソッドを定義しています。このタイプのリソースアダプタではプロダクションの再デプロイメントを行うことはできません。リソースアダプタは着信/発信通信で 1 つまたは複数の EIS に接続します。すべての通信は、アプリケーションサーバの知識を使用せずに、リソースアダプタ独自の方法で実行されます。実行時にプロダクションの再デプロイメントが試行された場合、アプリケーションサーバは、既存のリソースアダプタから新しいインスタンスへの接続の移行を管理できるように、リソースアダプタに通知を提供するだけです。ただし、リソースアダプタは Suspendable インタフェースを実装できます。このインタフェースは、リソースアダプタがプロダクションの再デプロイメントに参加するための機能を提供します。Suspendable インタフェースの実装の詳細については、「リソースアダプタのアクティビティの中断と再開」を参照してください。

プロダクションの再デプロイメントの要件

プロダクションの再デプロイメントが機能するためには、リソースアダプタの古いバージョンと新しいバージョンの両方で、以下の要件をすべて満たしている必要があります。満たされていない場合、再デプロイメントは失敗します。

リソースアダプタは J2CA 1.5 仕様に基づいている必要があります (1.0 リソースアダプタではプロダクションの再デプロイメントは利用できません)。
リソースアダプタは Suspendable インタフェースを実装する必要があります (コードリスト 4-3 を参照)。
リソースアダプタはエンタープライズアプリケーション (EAR ファイル) の内部にパッケージ化されている必要があります。スタンドアロンのリソースアダプタのプロダクション再デプロイメントはサポートされていません。
WebLogic Server に呼び出された場合、Suspendable.supportsVersioning() メソッドは true を返す必要があります。
weblogic-ra.xml 記述子の enable-access-outside-app 要素を false に設定する必要があります。

プロダクションの再デプロイメントのプロセス

以下のプロセスでは、リソースアダプタの古いバージョンがデプロイされて実行中であると仮定しています。また、古いバージョン (「old」) と新しいバージョン (「new」) の両方のリソースアダプタが、「プロダクションの再デプロイメントの要件」で述べた要件をすべて満たしており、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Updating Applications in a Production Environment」で示されたアプリケーションの要件も満たしていることとします。

プロダクションの再デプロイメント時に、リソースアダプタに以下のような呼び出しが行われます。

WebLogic Server は new.init(old, null) を呼び出して、新しいリソースアダプタに古いリソースアダプタと交代することを通知します。

WebLogic Server は old.startVersioning(new, null) を呼び出して、古いリソースアダプタに、新しいリソースアダプタと共にプロダクションの再デプロイメント処理を開始することを通知します。

WebLogic Server は new.start(extendedBootstrapContext) を呼び出します。「拡張された BootstrapContext」を参照してください。

古いリソースアダプタは、「終了」すると (つまり、すべてのクライアントおよび着信接続を新しいリソースアダプタに正常に移行し終えると)、(ExtendedBootstrapContext)bsCtx.complete() を呼び出します。これは、WebLogic Server に、古いリソースアダプタをアンデプロイしてもよいことを通知するものです。

アンデプロイメントが行われると、WebLogic Server が old.stop() を呼び出して、プロダクションの再デプロイメントは完了します。

new.init() と old.startVersioning() の呼び出しによって、新旧のリソースアダプタは、着信または発信の通信を古いリソースアダプタから新しいリソースアダプタに移行することができます。この処理方法は個々のリソースアダプタ開発者の裁量に任されています。

リソース アダプタのパッケージ化とデプロイ

リソース アダプタのパッケージ化