| Oracle Containers for J2EEリソース・アダプタ管理者ガイド 10g（10.1.3.5.0） B56028-01 |
|
 戻る |
 次へ |
通常のエンタープライズ・アプリケーションは、何らかのバックエンド情報システムのデータにアクセスする必要があります。今日、業務における問題の1つは、アプリケーションをWebベース・テクノロジに適応させる場合、そのデータがWebからアクセスできるようには設計されていない旧式のレガシー・システム内にあることです。
エンタープライズ・アプリケーションの統合のために、アプリケーション・サーバーはWebベースのアプリケーションとレガシー・システムとを統合するための適切なポイントとなります。J2EE Connector Architecture（J2CA）は、Oracle Containers for J2EE（OC4J）などのJ2EE準拠のアプリケーション・サーバーを介して、これらのレガシー・システムにアクセスするための標準フレームワークを提供します。J2CAのOC4J 10.1.3実装であるOracle J2CAは、コネクタ・アーキテクチャのバージョン1.5をサポートします。
この章では、次の項でJ2CAの主な概念と問題について説明します。
|
注意: ここやこのドキュメントの他の箇所で説明されている項目の詳細は、J2EE Connector Architecture Specificationを参照してください。OC4J 10.1.3実装の現在のバージョンはバージョン1.5で、次のサイトから入手できます。
|
J2EE Connector Architectureは、J2EEプラットフォームと、エンタープライズ情報システムと呼ばれる異機種間レガシー・システムとの間の双方向接続性のための標準アーキテクチャを定義します。これはリソース・アダプタと呼ばれるコンポーネントを介して実行されます。これらの用語の定義については後述します。基本的なアーキテクチャは図1-1に示します。
このアーキテクチャは、エンタープライズ情報システム・ベンダー（またはサード・パーティ）に対しては情報システムへのアクセスの際にJ2EEアプリケーションで使用される標準リソース・アダプタを提供するためのメカニズムを、アプリケーション・サーバー・ベンダーに対しては、標準リソース・アダプタをアプリケーション・サーバーにプラグインできるようにするサポートを提供するためのメカニズムを提供します。
この項ではこの後、次の内容について説明します。
エンタープライズ情報システム（EIS）は、企業データ用の異機種間ストレージおよび検索システムです。たとえば、企業リソース計画（ERP）システム、カスタマ・リレーションシップ・マネージメント（CRM）システム、メインフレーム・トランザクション処理（TP）システム、その他のデータベース、およびJavaプログラム言語で書かれていないレガシー・アプリケーションなどがあります。
一般に、レガシーEISは膨大な時間と労力をかけて進化してきました。通常、これらのシステムを交換することはできないので、システムはそのままにして、可能であれば標準的な再利用可能な方法でシステムに接続するメカニズムが必要とされます。
リソース・アダプタは、アプリケーション・サーバーやアプリケーション・クライアントで特定のEISに接続するために使用されるソフトウェア・ドライバです。リソース・アダプタの一例に、リレーショナル・データベースに接続するJDBCドライバがあります。同様に、ERPシステムやCRMシステムにもリソース・アダプタを含める場合があります。
リソース・アダプタを必要とした場合の初期の解決策として、固有の互換性のない技術が使用されました。J2EE Connector Architectureがない場合、各タイプのアプリケーション・サーバーを各タイプのEISベンダーに接続するため、カスタム・リソース・アダプタが必要となる場合があります。
J2EE Connector Architectureが標準リソース・アダプタ・フレームワークとして機能すると、それぞれのアプリケーション・サーバーではコネクタ・アーキテクチャの仕様をサポートする1つの実装のみが必要となり、それぞれのEISでは仕様に準拠するあらゆるアプリケーション・サーバーにプラグインできる1つのリソース・アダプタのみが必要となります。
さらに、初期の固有の解決策は、必ずしも接続管理、プーリング、トランザクション管理およびセキュリティといったサービスをサポートしていませんでした。J2EE Connector Architectureは、標準的なメカニズムを使用してこれらのサービスだけでなくそれ以外のものもサポートします。
ここでもう少し詳細に述べると、リソース・アダプタとは特定のEISと仕様に準拠したJ2EEアプリケーション・サーバーとの通信に必要なクラスとメタデータの集約として定義します。リソース・アダプタはアプリケーション・サーバーにプラグインし、アプリケーション・サーバーのアドレス空間内で実行されます。
コネクタ・アーキテクチャの以前のOC4J実装を理解しているユーザーのために、この項ではバージョン1.5のアーキテクチャおよびOC4J実装での拡張機能について要約します。
J2EE Connector Architectureのバージョン1.5は、インバウンド通信機能の追加など、バージョン1.0から大幅にアップグレードしました。（アウトバウンド通信だけはバージョン1.0でサポートされていました。）具体的には、OC4J 10.1.3実装でサポートされている新機能には、次のものがあります。
ライフサイクル管理規約
ワーク管理規約
メッセージ・インフロー規約
トランザクション・インフロー規約
管理接続ファクトリ用の複数の実装クラスのサポート
これらの規約および他の規約は「J2EE Connector Architectureのシステム規約」にまとめています。
J2EE Connector Architectureバージョン1.5の新機能のサポートに加えて、OC4J 10.1.3実装は次のような拡張機能を提供します。
接続プーリングの拡張機能
新しい接続共有機能
サーバーを停止しないOC4J固有の構成ファイルへの更新のサポート
リソース・アダプタの実行時のパーミッションおよびコンテナ管理のサインオン用のJAASセキュリティ実装とのより密接な統合
リソース・アダプタ用の2フェーズ・コミット
接続およびワーク管理スレッド・プールの新しいメトリック
同じリソース・アダプタの複数バージョンのデプロイ。各バージョンは、共有ライブラリとしてすべてのアプリケーションで使用できます。特定のバージョンのリソース・アダプタをインポートし、そのリソース・アダプタプのすべてのクラスをロードするようアプリケーションを構成できます。
デフォルト・アプリケーションの再起動を必要としないリソース・アダプタのデプロイ、アンデプロイまたは再デプロイ
J2EE Connector Architectureにおいて、J2EEコンポーネントは、機能のいくつかの重要な領域における標準的なサポートを指定するシステム規約を使用してリソース・アダプタと通信します。これらの規約はそれぞれ、一部はアプリケーション・サーバーによって実装され、一部はリソース・アダプタによって実装されているので、標準的な方法で対話しコラボレートすることができます。（これらの規約は、サービス品質規約とも呼ばれます。）
次に規約の要約を示します。
接続管理によって、アプリケーション・コンポーネントはEISに接続できるようになり、アプリケーション・サーバーはこれらの接続用に接続プーリングを使用できるようになります。（これを別のメカニズムであるJDBCの接続プーリングと混同しないでください。）詳細は、第3章「接続管理」を参照してください。
トランザクション管理によって、アプリケーション・サーバーは、トランザクション・マネージャを使用して複数のEISまたはリソース・マネージャにわたるトランザクションを処理することができます。（リソース・マネージャは共有EISリソースを管理します。）詳細は、第4章「トランザクション管理」を参照してください。
セキュリティ管理によって、アプリケーション・サーバーとEISの間の認証、認可および安全な通信が提供されます。「J2EE Connector Architectureのセキュリティ機能」も参照してください。EIS接続のOC4Jセキュリティの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。
ライフサイクル管理によって、アプリケーション・サーバーは、リソース・アダプタがデプロイされたときまたはアプリケーション・サーバーが起動したときのリソース・アダプタのブートストラップのためのメカニズム、およびリソース・アダプタがアンデプロイされたときまたはアプリケーション・サーバーが停止したときのリソース・アダプタへの通知のためのメカニズムなど、リソース・アダプタの起動と停止を管理できます。関連情報は、「リソース・アダプタのライフサイクル: 起動と停止」を参照してください。
メッセージ・インフローによって、リソース・アダプタは、メッセージをアプリケーション・サーバー内のエンドポイント（メッセージドリブンBeanなど）に配信できます。メッセージの配信は非同期です。このサポートは特定のメッセージ・プロバイダによるものではなく、Java Message Service（JMS）やJava API for XML Messaging（JAXM）など、幅広い用途があります。「メッセージ・インフロー規約の概要」も参照してください。
トランザクション・インフローによって、インポートされたトランザクションをリソース・アダプタによってアプリケーション・サーバーに伝播できます。「インポート済のトランザクションおよびトランザクション・インフロー規約の概要」も参照してください。
ワーク管理によって、アプリケーション・サーバーに対して発行され、ワーク・マネージャによって実行される作業ユニットを使用してリソース・アダプタでタスクを実行できます。このようなタスクには、アプリケーション・コンポーネントのコールやネットワークのエンドポイントの監視などがあります。アプリケーション・サーバーは別々のスレッドを使用して異なる作業ユニットを実行するため、リソース・アダプタはスレッド自体を管理する必要はなくなります。詳細は、第5章「ワーク管理」を参照してください。
J2EE Connector Architectureでは、アプリケーション・コンポーネントとEISの間の通信はどちら側からでも開始することができ、リソース・アダプタは次のうちのどちらかまたは両方をサポートする場合があります。
アウトバウンド通信: アプリケーション・コンポーネントによって開始される通信
インバウンド通信: EISによって開始される通信
この項では、アウトバウンド通信とインバウンド通信を比較し、インバウンド通信に関連するメッセージ・システムを簡単に説明します。
アウトバウンド通信では、リソース・アダプタによってアプリケーションはEISに接続して、EIS固有のAPIやこの章で後述する標準のCommon Client Interface（CCI）のようなAPIを使用してEISと通信することが簡単にできます。この場合、リソース・アダプタは受動ライブラリであり、通信は同期でアプリケーションによって開始されます。アプリケーション・コンポーネントは、EISの機能を同期的に実行したり結果を取得するためにAPI（EIS固有またはCCI）を使用できます。（このことを可能にするために、リソース・アダプタ自身は背後で固有のメカニズムを使用する場合があります。）アプリケーション・サーバーは接続に関連するトランザクション・セマンティックスを実行します。
インバウンド通信では、リソース・アダプタによってアプリケーション・サーバーの外側のエンティティやイベントがアクティビティを開始できます。たとえば、EISはキューにメッセージを書き込むことでこれを行うことができます。通信は非同期で、EISによって開始されます。インバウンド通信をサポートするリソース・アダプタは、通常ワーク管理規約とメッセージ・インフロー規約を使用します。リソース・アダプタに関連する作業ユニットは、EISからの通信の受信、J2EEコンテナの適切な受信者（メッセージ・エンドポイント）への通信の配信、およびEISへの適切な応答結果の配信を調整します。アプリケーション・サーバーは作業ユニットに割り当てられたスレッドを作成して管理し、通信の配信を処理するためにメッセージ・エンドポイント・インスタンスを割り当て、配信に関連するトランザクション・セマンティックスを強制します。
ほとんどのEISはメッセージ・システムを使用して、OC4J内で実行されるアプリケーションなどのEISの外側にあるアプリケーションとの通信を開始します。このため、インバウンド・アダプタがEISによって開始された通信のリスニングのために単純なソケット接続のような固有のメカニズムを使用することが可能であっても、一般的にインバウンド・リソース・アダプタはメッセージ・システムと関連付けられています。
メッセージ・システムおよびメッセージ・エンドポイントの詳細は、次の「J2EE Connector Architectureを使用したメッセージ・プロバイダの接続性」を参照してください。
図1-2はアウトバウンド通信の流れおよび関連するシステム規約が規定する場所を表しています。
図1-3はインバウンド通信の流れおよび関連するシステム規約が規定する場所を表しています。
J2EE 1.4の仕様は、J2CAを介してJMSを含む様々なメッセージ・システムへの接続性をサポートしています。メッセージ機能とともに使用するためのリソース・アダプタは、数に制限はありませんが、一般的に1つのメッセージ・システムまたはメッセージ・プロバイダをサポートしています。
アウトバウンド・リソース・アダプタによって、アウトバウンド通信を使用して同期的にメッセージを送受信できます。インバウンド・リソース・アダプタによって、メッセージ・プロバイダから、アプリケーション・サーバー内のメッセージドリブンBean（MDB）コンポーネントであるメッセージ・エンドポイントへ非同期にメッセージを配信できます。双方向のリソース・アダプタは両方の機能を提供します。
インバウンド通信をサポートするほとんどのリソース・アダプタは、JMS実装などの標準的なメッセージ・システムに基づいているため、EISは標準的な方法で通信を開始できます。
Oracleによって提供される一般的なJMSリソース・アダプタの概略は、「OracleのJMSサポートおよび一般的なJMSリソース・アダプタの概要」を参照してください。
|
注意: 現在リソース・アダプタは、アプリケーション・サーバーにメッセージ・システムをプラグインするための望ましい手段です。 |
リソース・アダプタを使用するJ2EEアプリケーションにおけるセキュリティには、次の2つの異なった側面があります。
EISへのアクセスを制御するJ2CAのセキュリティ規約。
クラスローダー、スレッドおよびソケットなどのアプリケーション・サーバー・リソースへのアクセスを制御するセキュリティ・パーミッション。これらのパーミッションはOC4J内で実行しているアプリケーションの動作を適切に制限します。
後述の項では、次の内容を要約します。
J2EEアプリケーションとEISの間の安全な相互作用を保証するために、J2EE Connector Architectureによりアプリケーション・コンポーネントはEISに対して確立された接続にセキュリティ・コンテキストを関連付けることができます。これはアプリケーション・サーバーとリソース・アダプタの間のJ2CAセキュリティ規約を使用して行われます。この規約は、接続管理規約を拡張し、安全な接続に関連する機能を持たせます。また標準的なJava Authentication and Authorization Service（JAAS）と連動して動作し、標準的なJAASインタフェースをサポートします。
セキュリティ規約には、次の機能が含まれます。
J2EEコンポーネントからリソース・アダプタへのセキュリティ・コンテキストまたはサブジェクトの直接伝播（コンポーネント管理のサインオン用）
アプリケーション・サーバーからリソース・アダプタへのセキュリティ・コンテキストまたはサブジェクトの伝播（コンテナ管理のサインオン用）
セキュリティ規約は次の2つの特別な認証メカニズムをサポートしています。
一般的に使用される基本的なパスワードのメカニズムは、パスワード資格証明オブジェクトに含まれるユーザー名とパスワードのペアによるものです。アプリケーション・サーバーは、認証のためにこのオブジェクトをリソース・アダプタに渡します。
Kerberosバージョン5のメカニズム（略称Kerbv5）はマサチューセッツ工科大学によって配布された認証プロトコルです。このメカニズムはKerberosチケットのような資格証明情報をカプセル化する一般的な資格証明オブジェクトを使用します。アプリケーション・サーバーはこのオブジェクトを検証のためにリソース・アダプタに渡します。
J2EEアプリケーションからEISへのサインオンは、アプリケーションのコンポーネントまたはJ2EEコンテナ（OC4J）によって管理されます。コンポーネント管理のサインオンはプログラムで設定される必要があり、OC4J固有の構成を必要としません。コンテナ管理のサインオンは、プログラムミングの必要がないOC4J固有の構成によって宣言的に設定されるか、またはOC4J固有の構成とプログラムとの連携によってプログラム的に設定されるかのどちらかです。プログラム的でコンテナ管理のサインオンは、プリンシパル・マッピング・クラスか、JAASのログイン・モジュールかのどちらかを使用できます。
これらの機能の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。
OC4Jなどのアプリケーション・サーバーは、管理されたランタイム環境で実行しているリソース・アダプタで使用されるセキュリティ・パーミッションのセットを提供する必要があります。リソース・アダプタは、アプリケーション・サーバーが制御するリソースへのアクセスなどの注意が必要な操作（たとえば、クラスローダー）を行うために、適切で明示的な権限が必要となります。
リソース・アダプタが特定の権限を必要とする場合、それらはra.xmlファイルの<security-permission>要素を使用して示される必要があります。しかしこれらの権限は、OC4J環境においてoc4j-connectors.xmlファイルの<security-permission>要素を使用してオーバーライドされる場合があります。「<security-permission>」を参照してください。
その他の情報は、J2EE Connector Architecture Specificationのバージョン1.5を参照してください。
J2EE Connector Architectureには、次のインタフェース・ライブラリがあります。
Common Client Interface（CCI）
これは、J2EEコンポーネントから関連するEISにアクセスする際に使用される標準的なクライアントに対応するインタフェースを提供するため、リソース・アダプタによって任意に実装できるインタフェースのセットです。実装された場合、基本的にはJ2EEアプリケーションとリソース・アダプタの間の規約になります。使用はコネクタ・アーキテクチャの仕様で義務づけられてはいないので、ベンダー固有のAPIをかわりに実装することもできます（データベースにアクセスするためのJDBC APIなど）。ただし、J2EEコンポーネントの範囲からEISの範囲に簡単にアクセスするには、リソース・アダプタによるCCIのサポートをお薦めします。そのようなサポートによって、リソース・アダプタをあらゆるJ2EE準拠の開発ツールやエンタープライズ・アプリケーション統合フレームワークにプラグインできることが保証されます。
Service Provider Interface（SPI）
これは、一部はアプリケーション・サーバーによって実装され、一部はリソース・アダプタによって実装されるインタフェースのセットで、EISへの物理接続を管理し、J2CAのシステム規約をサポートするために、アプリケーション・サーバーとリソース・アダプタの間のインタフェースを提供します。SPIインタフェースは、このドキュメントで規約について説明する中で必要に応じて解説します。
CCIインタフェース・ライブラリとSPIインタフェース・ライブラリは、それぞれjavax.resource.cciとjavax.resource.spiパッケージの中にあります。
CCIを実装するリソース・アダプタは、J2EEコンポーネントが関連するEISにアクセスするための標準的な方法を提供します。これにより、1つのJ2EEコンポーネントから複数のEISにアクセスするタスクが簡略化されます。
CCIはEISにアクセスするためにクライアント・アプリケーションで直接使用できますが、ツール・ベンダーがCCIを（実行時用に）ソフトウェア開発者キットの形で公開したり、（設計時用に）ウィザードの形で公開したりすることがより一般的であり、またクライアント・アプリケーションがこのツールを使用してEISにアクセスすることがより一般的です。CCIをサポートするリソース・アダプタを、標準的方法でエンタープライズ・ツールおよび他のエンタープライズ・アプリケーション統合フレームワークにプラグインできます。
CCIを通した通信では、EISで機能を実行するための相互作用の作成と実行を必要とします。EISへの接続を取得し、相互作用を作成し、相互作用を実行するという手順になります。相互作用はリソース・アダプタを伴うクラスで表されており、そのクラスはCCIのInteractionインタフェースを実装します。このインタフェースは、EISへの操作を実行するためにオーバーロードされたexecute()メソッドを指定します。相互作用オブジェクトはEIS接続を通して取得され、その接続との関連付けを維持します。相互作用には次の3つの種類があります。
SYNC_SEND_RECEIVE: EISに対して同期リクエストを送信し、関連する同期レスポンスを受信します。これは標準的なリクエスト/レスポンスのメカニズムです。
SYNC_SEND: EISに対して同期リクエストを送信しますが、関連する同期レスポンスは存在しません。
SYNC_RECEIVE: EISから同期レスポンスを受信しますが、関連する同期リクエストは存在しません。1つのシナリオは、長いジョブを開始するためにSYNC_SEND相互作用を使用し、その後結果が準備されるときにSYNC_RECEIVE相互作用を使用するというものです。
CCIのInteractionSpecインタフェースは相互作用のためのプロパティを保持するメカニズムを提供します。（「例: 相互作用仕様について」も参照してください。）
|
注意:
|
リソース・アダプタを構成するクラス、インタフェース、ディスクリプタおよび他のリソースは、デプロイするために、.rar拡張子の付いたJavaアーカイブ・ファイルであるRARファイルの中にパッケージ化されています。RARファイルは少なくとも次のものを含んでいる必要があります。
リソース・アダプタ用のra.xml構成ファイル
リソース・アダプタの実装を含む1つ以上のJARファイル
次の2つの方法のどちらかでデプロイされます。
EARファイルの中でのデプロイ。この場合、EARファイルの中のアプリケーションだけがリソース・アダプタを利用できます。
それ自身でのデプロイ。この場合、リソース・アダプタはスタンドアロンと呼ばれ、OC4Jのデフォルト・アプリケーションと関連付けられます。またサーバー・インスタンス内のすべてのアプリケーションがリソース・アダプタを利用できます。
（OC4Jはグローバル・アプリケーションとも呼ばれるデフォルト・アプリケーションを含むデフォルトの構成でインストールされます。デフォルト・アプリケーションは、デフォルトで、Application Server Controlコンソールを除くOC4J内の他のすべてのJ2EEアプリケーションの親になります。）
スタンドアロンの各リソース・アダプタは共有ライブラリとして表され、デフォルトによりすべてのアプリケーションで使用可能です。スタンドアロンのリソース・アダプタのすべてのコード・ソースは専用の共有ローダーに追加され、（別の方法が明示的に構成されていないかぎり）これらのソースがすべてのアプリケーションによってインポートされます。スタンドアロン・リソース・アダプタの複数バージョンをデプロイする場合、特定のリソース・アダプタをインポートするようアプリケーションを構成して、すべてのリソース・アダプタ・クラスが同じアダプタからロードされるようにできます。
ra.xmlファイルに加えて、それぞれのデプロイ済のリソース・アダプタに対してoc4j-ra.xml構成ファイルが必要となります。これはRARファイルに含めることができるOC4J固有のファイルです。つまり、OC4Jはデプロイ中にそれを自動的に作成します。最後に、oc4j-connectors.xmlファイル（これもOC4J固有）はアプリケーションに関連するすべてのリソース・アダプタの一覧であり、またいくつかの追加の構成も含む場合があります。EARファイルにデプロイされたリソース・アダプタの場合、リソース・アダプタを列挙する1つのoc4j-connectors.xmlファイルがあり、EARファイルの中にそれがない場合はOC4Jが自動的に作成します。スタンドアロン・リソース・アダプタの場合、OC4J構成ディレクトリの中に1つのoc4j-connectors.xmlファイルがあり、スタンドアロン・リソース・アダプタを列挙するためにOC4Jのデフォルト・アプリケーションと関連付けられています。もし存在していない場合はOC4Jがこのファイルも作成します。（OC4J固有の構成ファイルの詳細は、付録A「OC4Jリソース・アダプタ構成ファイル」を参照してください。）
次にサンプルRARファイルの内容を示します。
META-INF/ra.xml META-INF/oc4j-ra.xml howto.html images/icon.jpg ra.jar cci.jar
この例では、次のことを前提としています。
ra.jarファイルはリソース・アダプタの実装を含んでいます。
リソース・アダプタはcci.jarに含まれているCCI APIをそのクライアント・インタフェース用に公開します。
アプリケーションは、RARファイルにバンドルされたアダプタ固有のクラスにアクセスする必要がある場合があります。スタンドアロン・リソース・アダプタの場合、OC4Jの中にデプロイされたすべてのアプリケーションがこれらのクラスを利用できます。EARファイルにデプロイされたリソース・アダプタの場合、同じEARファイルの中にデプロイされたモジュールだけがそのクラスを利用できます。
次にサンプルEARファイルの内容を示します。（oc4j-connectors.xmlとmyRar.rarだけがリソース・アダプタに関連付けられています。）
META-INF/application.xml META-INF/oc4j-connectors.xml myRar.rar myWar.war myEjb.jar
リソース・アダプタをデプロイするには、Application Server ControlなどのJSR-88準拠のツールを使用できます。（詳細は、「OC4J管理の概要」を参照してください。）OC4J固有のパラメータ設定を指定するためにApplication Server Controlコンソールのデプロイ・プラン・エディタを使用してください。
デプロイ中にOC4JはRARファイルを解凍し、OC4J固有のデプロイメント・ディスクリプタ・ファイルに関して次のアクションをします。
次に示すように、リソース・アダプタ用のデプロイ・ディレクトリを作成します。
j2ee/instance/application-deployments/app_name/ra_name
OC4Jインスタンスであるinstanceはスタンドアロン環境では常にhomeであり、Oracle Application Server環境ではデフォルトでhomeになります。スタンドアロン・リソース・アダプタの場合、アプリケーションの名前app_nameはdefaultで、リソース・アダプタの名前ra_nameをデプロイ中に指定します。EARファイルにデプロイされたリソース・アダプタの場合、アプリケーションの名前はデプロイ中に指定したもので、リソース・アダプタの名前は.rar拡張子のないRARファイルの名前となります。
OC4Jインスタンス内で、RAR名は一意である必要があります。OC4JインスタンスにすでにデプロイされているRARと同じファイル名のRARをデプロイしようとすると、NullPointerException例外が発生します。
RARファイルの中にoc4j-ra.xmlファイルが提供されていない場合、空のoc4j-ra.xmlファイルを作成してそれをリソース・アダプタ用のデプロイ・ディレクトリ（ra_name）に置いてください。
スタンドアロン・リソース・アダプタの場合、OC4Jのデフォルト・アプリケーションと関連付けられたoc4j-connectors.xmlファイルの中に<connector>エントリを追加します。もしファイルが存在しない場合は作成します。
EARファイルにデプロイされたリソース・アダプタの場合、EARファイルにoc4j-connectors.xmlファイルを提供していない場合は、アプリケーションのデプロイ・ディレクトリ（app_name）にoc4j-connectors.xmlを作成し、<connector>エントリを追加します。
次に示すように、それぞれのリソース・アダプタはデプロイされるときに一意の名前を持っている必要があります。
リソース・アダプタのデプロイ、アンデプロイまたは再デプロイの際に、デフォルト・アプリケーションの再起動は必要ありません。
アプリケーションのEARファイルの中のリソース・アダプタは、EARファイルがデプロイされるときにデプロイされます。oc4j-connectors.xmlファイルの中に名前が指定されていない場合、RARのアーカイブ名と同じ名前になります。
デプロイ中にそれぞれのスタンドアロン・リソース・アダプタに対して一意の名前が提供される必要があります。
詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
アプリケーションのデプロイの際、アプリケーションはデフォルトにより、以前にデプロイされたすべてのスタンドアロン・リソース・アダプタをインポートします。
スタンドアロン・リソース・アダプタのデプロイの際、以前にデプロイされた実行中のすべてのアプリケーション（デフォルト・アプリケーションを除く）は、リソース・アダプタをインポートするかどうか尋ねられます。そのため、まだデプロイされていないリソース・アダプタをアプリケーションが使用しようとしないかぎり、スタンドアロン・リソース・アダプタに依存するアプリケーションをデプロイした後に、リソース・アダプタをデプロイできます。依存するアプリケーションより後にスタンドアロン・リソース・アダプタをデプロイする場合、そのアプリケーションはすでにクラスをロードしている可能性があるため注意が必要です。スタンドアロン・リソース・アダプタをインポートすることで、前にロードされているクラスが、別のローダーによって後からロードされると、予期しない例外が発生します。
リソース・アダプタは、別のリソース・アダプタを参照および使用できます。各スタンドアロン・リソース・アダプタには独自のクラスローダーがあるため、スタンドアロン・リソース・アダプタでは、デプロイ済の別のスタンドアロン・リソース・アダプタおよび共有ライブラリのインポートが必要です。デフォルトでは、スタンドアロン・リソース・アダプタは、以前にデプロイされたすべてのスタンドアロン・リソース・アダプタとすべての共有ライブラリをインポートします。スタンドアロン・リソース・アダプタを先にデプロイした後で、それに依存するスタンドアロン・リソース・アダプタをデプロイする必要があります。
同じ名前のクラスを含む複数のスタンドアロン・リソース・アダプタをデプロイできます。デフォルトで、すべてのアプリケーションはすべてのスタンドアロン・リソース・アダプタを使用できるため、複数のバージョンがデプロイされるスタンドアロン・リソース・アダプタを使用するすべてのアプリケーションは、どのバージョンを使用するかを明示的に指定する必要があります。アプリケーションは、複数バージョンがあるリソース・アダプタの1つのバージョンのみを使用します。
アプリケーションでは、構成ファイルorion-application.xmlに、使用するスタンドアロン・リソース・アダプタが指定されます。たとえば、ある同じクラスを含む2つのスタンドアロン・リソース・アダプタを、adapterAとadapterBの名前でデプロイします。次のconnector要素が、J2EE_HOME/config/oc4j-connectors.xmlに記述されます。
<connector name="adapterA" path="adapterAFileName.rar" > <connector name="adapterB" path="adapterBFileName.rar" >
adapterAのみを使用するようアプリケーションを構成する場合、アプリケーションのorion-application.xmlファイルに次の要素を追加します。
<imported-shared-libraries> <remove-inherited name="adapterB"/> </imported-shared-libraries>
両方のスタンドアロン・リソース・アダプタがデフォルトでインポートされるため、adapterAを明示的にインポートする必要はありません。
もう1つの構成方法は次のようになります。
<imported-shared-libraries>
<import-shared-library name="adapterA">
<remove-inherited name="*"/>
</imported-shared-libraries>
|
注意: 共有ライブラリにはバージョン番号を使用したバージョン付けが可能ですが、現状、これをスタンドアロン・リソース・アダプタに対して行うことはできません。デプロイされる各リソース・アダプタは一意の名前を持つ必要があります。 |
リソース・アダプタをデフォルト・アプリケーションにデプロイすると、そのリソース・アダプタでは、共有ライブラリとしてデプロイされたスタンドアロン・リソース・アダプタを使用できません。共有ライブラリとしてデプロイされたリソースは、デフォルト・アプリケーションによってインポートされません。
Oracle Application Serverとともに提供されるリソース・アダプタには、Oracleの一般的なJMSアダプタとサード・パーティのアダプタがあります。
JMSは、J2EE環境での通信用にポータブルなメッセージベースのアプリケーションを使用できるようにするエンタープライズ・メッセージAPIを規定しています。信頼性とサービス品質に関して保証する様々なJMSのプロバイダがあります。最近OC4Jは、異なるJMSプロバイダにプラグインするための固有のリソース・プロバイダのメカニズムを含んでいます。
Oracle Application Server 10g（10.1.3.5.0）において、Oracleは2つのJMS実装を提供しています。1つはOracle JMS（OJMS）であり、Oracle Database Streams Advanced Queueing（AQ）機能へのJMSインタフェースです。もう1つはOracleAS JMSであり、ファイルベースの永続性を提供し、OC4Jと密接に統合されているネイティブJava実装です。
Oracleでは、J2CAのサポートのレベルがバージョン1.5かどうかに関係なく、OC4Jが管理するアプリケーションにあらゆるJMSプロバイダにアクセスする統合されたメカニズムを持たせることができるJ2CA 1.5準拠のJMSリソース・アダプタも提供されます。このOracleのJMSリソース・アダプタは、一般的なJMSリソース・アダプタと呼ばれており、Oracle固有のAPIは使用していません。サポートされるJMS実装には、たとえば、OJMS、OracleAS JMS、およびサード・パーティの製品であるIBM WebSphere MQ JMS、Tibco Enterprise for JMS、SonicMQ JMSなどがあります。
Oracleの一般的なJMSリソース・アダプタは、OC4J 10.1.3の実装におけるJMSの使用方法としてお薦めします。それはJ2CA 1.5、JMS 1.1および1.02bの標準に基づいており、OC4Jの最低限のカスタマイズを含んでいますが、個々のJMSプロバイダのカスタマイズは含んでいません。あらゆる標準のJMS実装をシームレスに統合することを目的としています。（多くのJMSプロバイダがカスタム拡張機能をサポートすることを考慮すると、一般的なJMSリソース・アダプタは、通常、個々のJMSプロバイダへの最適なアクセスを提供することはできません。）また次の分野において、多くの特徴的な機能を持っています。
JNDIマッピング
MDB統合（メッセージ・ロード変更の動的調整を含む）
グローバル・トランザクション・サポート（トランザクション・リカバリの標準ベースのサポートを含む）
一般的なJMS接続プーリング
デプロイ上の便宜（順序の独立性を含む）
JMS操作の遅延解決（起動順の独立性、JMSプロバイダの起動と停止などの動的管理の許容範囲、およびプロバイダ障害の際の接続の再試行を含む）
パフォーマンス
JSR-77の統計
通常、Oracleの一般的なJMSリソース・アダプタは、EISの接続先がJMSリソース・プロバイダである状況で使用されます。しかしEISがJ2EEアプリケーション・コンポーネントに通知する手段としてJMSメッセージ機能を使用する場合もそれが使用されます。この場合、EIS固有のリソース・アダプタのインバウンド通信機能があるときは、JMSリソース・アダプタを（JMSリソース・プロバイダとともに）そのかわりに使用することも可能です。この2つのアダプタによるソリューション、すなわち、EIS固有のアダプタがアウトバウンド通信に使用され、Oracleの一般的なJMSリソース・アダプタがインバウンド通信に使用されるというソリューションは、それ以外の方法では不可能であろうEISとJ2EEアプリケーションの間の双方向通信を可能にします。
Oracle JMS実装とJMSリソース・アダプタの詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
この項では、J2CA仕様で扱われているエンジニリアリングと技術者の役割、これらの役割の何がドキュメントの対象読者を示すか、および各対象読者に関係する内容について説明します。
J2CA仕様は次の役割に対応しています。
リソース・アダプタ・プロバイダ
特定のEISに関連するテクノロジを専門的に扱います。
J2EEアプリケーション・サーバー・プロバイダおよびコンテナ・プロバイダ
これらの役割はコネクタ・アーキテクチャの仕様の中で別々に扱われていますが、OracleはOC4Jコンテナおよび関連するサービスを含むOracle Application Serverで両方の機能を満たしています。
J2EEアプリケーション・コンポーネント・プロバイダ
1つ以上のEISにアクセスするJ2EEコンポーネントのためのものです。観念的には、コンポーネント・プロバイダはソフトウェア開発ツール・ベンダーによってCCIに基づいて作成された便利なJavaインタフェースに対するプログラミングです。
エンタープライズ・ツール・ベンダー
ツール・ベンダーからの製品は、EISのデータの範囲と構造を分析するためのデータマイニングおよびファンクションマイニングのツール、EISのデータとファンクションに基づいた設計のための分析および設計ツール、EISのデータとファンクションにアクセスするためのJavaクラスを作成するコード生成ツール、およびデプロイ・ツールを含んでいる場合があります。
アプリケーション・アセンブラ
アセンブラは、デプロイ可能なエンティティの中にアプリケーションのコンポーネントをパッケージ化します。
アプリケーション・デプロイヤ
デプロイヤは、OC4Jインスタンスなどのターゲット環境にデプロイ可能なエンティティをロードします。
システム管理者
管理者は、J2EEコンテナの環境、リソース・アダプタおよびEISを管理し、構成します。
前述の項で示した役割の中で、このドキュメントの主な対象読者はシステム管理者、すなわちリソース・アダプタの構成を含めてOC4J環境を管理するユーザーです。その他に、アプリケーション・コンポーネント・プロバイダおよびリソース・アダプタ・プロバイダが対象読者となります。
このドキュメントの各内容は、表1-1に示すそれぞれの読者に関係します。
