Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング 11g リリース1 (10.3.4) B60996-02 |
|
![]() 前 |
![]() 次 |
次の項では、リソース・アダプタをパッケージ化およびデプロイする方法について説明します。
WebLogic Serverアプリケーションのデプロイメントについては、『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
本番および開発目的では、アセンブル済みのリソース・アダプタ(RAR)をエンタープライズ・アプリケーション(EAR)の一部としてパッケージ化することをお勧めします。
リソース・アダプタは、applications/
ディレクトリ内のリソース・アダプタ・アーカイブ(RAR)に含まれるWebLogic Serverコンポーネントです。デプロイメント・プロセスは、リソース・アダプタ・プロバイダによって作成されたコンパイル済みリソース・アダプタ・インタフェースと実装クラスを格納するRARまたはデプロイメント・ディレクトリで開始されます。RARとデプロイメント・ディレクトリは、どちらがコンパイル済みクラスを格納している場合でも、Javaパッケージ構造と一致するサブディレクトリに入っている必要があります。
リソース・アダプタでは、展開ディレクトリ形式またはRARのどちらにパッケージ化される場合でも、同じディレクトリ形式を使用します。リソース・アダプタの一般的なディレクトリ構造を例9-1に示します。
リソース・アダプタに関するパッケージ化の要件は以下のとおりです。
デプロイメント記述子(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仕様(http://java.sun.com/j2ee/connector/
)の制限によるものです。
1つまたは複数のリソース・アダプタをディレクトリにステージングしたら、.rar
ファイル拡張子の付いたJavaアーカイブ(JAR)にパッケージ化します。
注意: リソース・アダプタをアセンブルした後は、エンタープライズ・アプリケーションの一部としてパッケージ化することをお勧めします。これにより、従来の単一ディレクトリ構造に比べていくつかの利点がある分割開発ディレクトリ構造を利用できるようになります。『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリ環境の作成」を参照してください。 |
リソース・アダプタをステージングおよびパッケージ化するには、次の手順に従います。
一時ステージング・ディレクトリをハード・ディスクの任意の場所に作成します。
対象となるリソース・アダプタの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
デプロイメント記述子を作成して、そのリソース・アダプタのエントリを追加します。
リソース・アダプタ・クラスとデプロイメント記述子をステージング・ディレクトリに配置すると、次のような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.Deployer
ツール
wldeploy
Antタスク
WebLogic Scripting Tool (WLST)
これらのアプリケーションのデプロイメント方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「weblogic.deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。
デプロイメント・プランを使用してリソース・アダプタ・デプロイメントをデプロイできます。リソース・アダプタの場合、WebLogic Serverデプロイメント・プランは、RARの外部にあるオプションのXMLドキュメントであり、特定のWebLogic Server環境のデプロイメントとしてリソース・アダプタが構成されます。デプロイメント・プランでは、リソース・アダプタのデプロイメント記述子で通常定義するようなデプロイメント・プロパティ値を設定したり、デプロイメント記述子ですでに定義されているプロパティ値をオーバーライドしたりします。デプロイメント・プランの詳細は、Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番デプロイメントのためのアプリケーションの構成に関する項を参照してください。
自動デプロイメントを使用してリソース・アダプタをデプロイすることもできます。この方法は開発時や初期テスト時に便利です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「開発ドメインへのアプリケーションの自動デプロイ」を参照してください。
リソース・アダプタ・アーカイブ(RAR)またはデプロイメント・ディレクトリをデプロイする場合は、myResourceAdapter
のように、デプロイメント・ユニットの名前を指定する必要があります。この名前を使用すると、後でリソース・アダプタをアンデプロイしたり更新したりする場合に、リソース・アダプタのデプロイメントを簡単に参照できます。
リソース・アダプタをデプロイする場合は、WebLogic Serverが、RARまたはデプロイメント・ディレクトリのパスおよびファイル名と一致するデプロイメント名を暗黙的に割り当てます。この名前を使用すると、サーバーが起動した後にリソース・アダプタをアンデプロイまたは更新できます。
リソース・アダプタのデプロイメント名は、サーバーが再起動されるまで、WebLogic Server内でアクティブなままです。リソース・アダプタをアンデプロイしても、関連付けられたデプロイメント名は削除されません。したがって、後でその名前を使用してリソース・アダプタを再デプロイできます。
WebLogic Serverの本番再デプロイメント機能を使用すると、同じアプリケーションの古いバージョンと一緒に、WebLogic Serverアプリケーションの新しいバージョンを再デプロイできます。デフォルトでは、WebLogic Serverは直ちに新しいクライアントリクエストを新しいバージョンのアプリケーションにルーティングする一方で、既存のクライアント接続は古いバージョンにルーティングします。古いバージョンのアプリケーションを使用するすべてのクライアントが作業を完了したら、WebLogic Serverは、新しいバージョンだけがアクティブになるように、古いバージョンを廃止します。
一般に、リソース・アダプタ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」
)の両方のリソース・アダプタが、「本番再デプロイメントの要件」で述べた要件をすべて満たしており、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「本番環境でのアプリケーションの再デプロイメント」で示されたアプリケーションの要件も満たしていることとします。
本番再デプロイメント時に、リソース・アダプタに以下のような呼出しが行われます。
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()
の呼出しによって、新旧のリソース・アダプタは、着信または発信の通信を古いリソース・アダプタから新しいリソース・アダプタに移行することができます。この処理方法は個々のリソース・アダプタ開発者の裁量に任されています。