1. Oracle WebLogic Server リソース・アダプタの開発
  2. リソース・アダプタのパッケージ化とデプロイ

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

WebLogicリソース・アダプタをデプロイするには、最初にそれをリソース・アダプタ・アーカイブ(RAR)ファイルにパッケージ化して、展開ディレクトリ形式でデプロイ、またはアーカイブ・ファイルとしてデプロイします。RARファイルの作成では、リソース・アダプタをスタンドアロンでデプロイするのか、Java EEアプリケーションのEARとともにデプロイするのか、またはそのデプロイ方法に関する考慮事項など、いくつかの要因に応じた要件があります。

WebLogic Serverへのアプリケーションのデプロイは、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイメントとパッケージ化に関する項で詳細に説明されています。

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

本番および開発目的では、アセンブル済みのリソース・アダプタ(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 (optional)
/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をデプロイする場合、リソース・アダプタはアプリケーション・サーバー内のすべてのJava EEアプリケーションで使用可能にする必要があります。

  • Java EEアプリケーションのEAR内にリソース・アダプタのRARをパッケージ化してデプロイする場合、リソース・アダプタはそのパッケージ化されているJava EEアプリケーションでのみ使用可能にする必要があります。この仕様に準拠した動作は必要に応じてオーバーライドできます。

パッケージ化の制限

スタンドアロンのリソース・アダプタを再ロードするときに、そのリソース・アダプタを使用するクライアントを再ロードしない場合、クライアントは正常に機能しなくなる可能性があります。この制限事項は、リモート可用性のあるインタフェースを許可しないという『JSR 322: Java EE Connector Architecture 1.6』の制限によるものです。

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

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

ノート:

リソース・アダプタをアセンブルした後は、エンタープライズ・アプリケーションの一部としてパッケージ化することをお薦めします。これにより、従来の単一ディレクトリ構造に比べていくつかの利点がある分割開発ディレクトリ構造を利用できるようになります。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の作成に関する項を参照してください。

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

  1. 一時ステージング・ディレクトリをハード・ディスクの任意の場所に作成します。
  2. リソース・アダプタのJavaクラスをステージング・ディレクトリにコンパイルまたはコピーします。
  3. リソース・アダプタのJavaクラスを入れるJARを作成します。このJARをステージング・ディレクトリの最上位に追加します。
  4. ステージング・ディレクトリにMETA-INFサブディレクトリを作成します。
  5. META-INFサブディレクトリにra.xmlデプロイメント記述子を作成して、そのリソース・アダプタのエントリを追加します。

    ノート:

    ra.xmlの文書型定義の詳細は、http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/connector_1_7.xsdを参照してください。

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

    ノート:

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

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

    このコマンドによって作成されたRARは、WebLogic Serverにデプロイすることも、エンタープライズ・アプリケーション・アーカイブ(EAR)にパッケージ化することもできます。

    -C staging-dirオプションを指定すると、JARコマンドはディレクトリをstaging-dirに変更します。これにより、JARに記録されるディレクトリ・パスがリソース・アダプタのステージング・ディレクトリを基準にした相対パスとなります。

このトピックの詳細は、「リソース・アダプタの作成と構成:主なステップ」を参照してください

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

リソース・アダプタのデプロイメントは、Webアプリケーション、EJBおよびエンタープライズ・アプリケーションのデプロイメントに似ています。これらのデプロイメント・ユニットと同様、リソース・アダプタも展開ディレクトリ形式でデプロイしたり、アーカイブ・ファイルとしてデプロイすることができます。WebLogic Serverでは、アプリケーションの古いバージョンと並行して同じアプリケーションの新しいバージョンを再デプロイすることによって、ダウンタイムを排除できる本番再デプロイメント機能を使用するかどうかなど、いくつかのデプロメント・オプションを提供しています。

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

次のツールのいずれかを使用して、スタンドアロンのリソース・アダプタ(またはエンタープライズ・アプリケーションの一部としてパッケージ化されたリソース・アダプタ)をデプロイできます。

  • WebLogic Server管理コンソール

  • weblogic.Deployerツール

  • wldeploy Antタスク

  • WebLogic Scripting Tool(WLST)

これらのアプリケーションのデプロイメント方法の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。

デプロイメント・プランを使用してリソース・アダプタ・デプロイメントをデプロイできます。リソース・アダプタの場合、WebLogic Serverデプロイメント・プランは、RARの外部にあるオプションのXMLドキュメントであり、特定のWebLogic Server環境のデプロイメントとしてリソース・アダプタが構成されます。デプロイメント・プランでは、リソース・アダプタのデプロイメント記述子で通常定義するようなデプロイメント・プロパティ値を設定したり、デプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。デプロイメント・プランの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番デプロイメントのためのアプリケーションの構成に関する項を参照してください。

自動デプロイメントを使用してリソース・アダプタをデプロイすることもできます。この方法は開発時や初期テスト時に便利です。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の開発ドメインでのアプリケーションの自動デプロイに関する項を参照してください。

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

リソース・アダプタ・アーカイブ(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インタフェースの実装の詳細は、「リソース・アダプタのアクティビティの中断と再開」を参照してください

本番再デプロイメントの要件

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

  • リソース・アダプタはコネクタ・アーキテクチャ1.7に対応する必要があります。(1.0リソース・アダプタでは本番再デプロイメントは利用できません。)

  • リソース・アダプタは、Suspendableインタフェースを実装する必要があります(例3-3を参照してください)。

  • リソース・アダプタはエンタープライズ・アプリケーション(EARファイル)の内部にパッケージ化されている必要があります。スタンドアロンのリソース・アダプタの本番再デプロイメントはサポートされていません。

  • WebLogic Serverに呼び出された場合、Suspendable.supportsVersioning()メソッドはtrueを戻す必要があります。

  • weblogic-ra.xml記述子のenable-access-outside-app要素をfalseに設定する必要があります。

本番再デプロイメントのプロセス

以下のプロセスでは、リソース・アダプタの古いバージョンがデプロイされて実行中であると仮定しています。また、古いバージョン(「old」)と新しいバージョン(「new」)の両方のリソース・アダプタが、「本番再デプロイメントの要件」で述べた要件をすべて満たしており、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番環境でのアプリケーションの再デプロイメントに関する項で示されたアプリケーションの要件も満たしていることとします。

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

  1. WebLogic Serverはnew.init(old, null)を呼び出して、新しいリソース・アダプタに古いリソース・アダプタと交代することを通知します。
  2. WebLogic Serverはold.startVersioning(new, null)を呼び出して、古いリソース・アダプタに、新しいリソース・アダプタと共に本番再デプロイメント処理を開始することを通知します。
  3. WebLogic Serverはnew.start(extendedBootstrapContext)を呼び出します。「拡張されたBootstrapContext」を参照してください。
  4. 古いリソース・アダプタは、終了すると(つまり、すべてのクライアントおよびインバウンド接続を新しいリソース・アダプタに正常に移行し終えると)、(ExtendedBootstrapContext)bsCtx.complete()を呼び出します。これは、WebLogic Serverに、古いリソース・アダプタをアンデプロイしてもよいことを通知するものです。
  5. アンデプロイメントが行われると、WebLogic Serverがold.stop()を呼び出して、本番再デプロイメントは完了します。

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

複数のアウトバウンド接続プールで構成されたリソース・アダプタのデプロイ

デフォルトでは、複数のアウトバウンド接続プールで構成されたリソース・アダプタをデプロイする際に、いずれかの接続プールにエラーが発生すると、アダプタのデプロイメントが失敗します。ただし、失敗した接続プールを正常なプールから分離することにより、デプロイメントの成功を可能にするオプションを使用できます。このオプションを使用すると、アダプタ全体を再デプロイすることなく、失敗した接続プールの分離、診断、修復、およびデプロイメントの動的更新を行えます。

アウトバウンド接続プールにエラーが発生した場合でもリソース・アダプタ・デプロイメントが成功するように構成するには、次のいずれかを実行します。

  • WebLogic Server管理コンソールを使用して、「全体としてデプロイ」フラグが選択されていないことを確認します。このオプションは、「リソース・アダプタ」→「構成」→「全般」ページから使用できます。『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のリソース・アダプタのプロパティの構成に関する項を参照してください。

  • weblogic-ra.xmlファイルのdeploy-as-a-whole要素をfalseに設定します。