| Oracle Application Serverエンタープライズ・デプロイメント・ガイド 10gリリース3（10.1.3.5.0） B57230-01 |
|
 戻る |
 次へ |
セキュリティ・インフラストラクチャのOracle Application Server Metadata Repositoryのインストール
データ層でのOracle Internet Directoryインスタンスのインストール
ロード・バランシング・ルーターを使用するための仮想サーバーの構成
Oracle Internet Directoryインスタンスのテスト
ORABPEL、ORAESBおよびORAWSMスキーマのインストール
グローバル・トランザクション用のOracle SOA Suiteの構成
コンポーネントをセキュリティDMZにインストールする前に、10g（10.1.4.0.1）のOracleAS Metadata RepositoryをReal Application Clustersデータベースにインストールする必要があります。Oracle Application Serverには、既存のデータベースにOracleAS Metadata Repositoryを作成するためのOracle Application Server Repository Creation Assistantが用意されています。
10g（10.1.4.0.1）のOracleAS RepCAは、OracleAS RepCA CD-ROMまたはOracle Application Server DVD-ROMからインストールできます。OracleAS RepCAは、別のOracleホームにインストールする必要があります。
OracleAS Metadata Repositoryをインストールして実行する手順は次のとおりです。
『Oracle Application Server Metadata Repository Creation Assistantユーザーズ・ガイド』の手順に従って、OracleAS RepCAをReal Application Clustersデータベースにインストールします。このマニュアルは、Oracle Application Serverドキュメント・ライブラリで参照できます（「Getting Started」タブ）。
データベースが『Oracle Application Server Metadata Repository Creation Assistantユーザーズ・ガイド』の「データベースの要件」の要件を満たしていることを確認してください。
また、OracleAS RepCAを実行するために、データベース・コンピュータに最低512MBのスワップ領域があることも確認してください。
OracleAS RepCAを実行します。
『Oracle Application Server Metadata Repository Creation Assistantユーザーズ・ガイド』に記載されたスキーマが、OracleAS RepCAによって作成されます。
次の第2.1.1項で説明されているインストール後の手順を実行します。
クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスを作成するには、Oracle Enterprise Manager Cluster Managed Services Pageを使用することをお薦めします。データベース・サービス作成の詳細な手順は、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイド』のワークロード管理に関する章を参照してください。
SQL*Plusを使用してサービスを構成することもできます。その場合の手順は次のとおりです。
CREATE_SERVICEサブプログラムを使用して、soaedg.mycompany.comデータベース・サービスを作成します。sysdbaユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'soaedg.mycompany.com', NETWORK_NAME => 'soaedg.mycompany.com', );
次のsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。
prompt> srvctl add service -d soadb -s soaedg -r soadb1,soadb2
次のsrvctlコマンドを使用して、サービスを開始します。
prompt> srvctl start service -d soadb -s soaedg
|
注意: srvctlコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
同じデータベースを共有する場合でも、その製品スイート用の特定のデータベース・サービスを使用することをお薦めします。また、デフォルトのデータベース・サービスとは別のデータベース・サービスを使用することもお薦めします。前の手順で説明した例では、データベースはsoadb.mycompany.comであり、デフォルトのサービスはこれと同じ名前のサービスです。 SOAインストールは、soaedg.mycompany.comというサービスを使用するように構成されます。 この場合、BAMにはbamedg.mycompany.comという名前のサービスを使用することをお薦めします。
Oracle RAC 10g Databaseを使用したデプロイメントでは、分散トランザクション処理（DTP）用にデータベースを構成する必要があります。DTP構成では、特定のデータベース・サービス用の優先RACインスタンスを指定できます。つまり、データベース・サービスは、一度に1つのホストで使用可能になります。その結果、サービスへのデータソース接続はすべて、そのホストにルーティングされます。優先インスタンスに障害が発生した場合、それらの接続は、指定したセカンダリ優先インスタンスにフェイルオーバーされます。
異なるデータソース接続によって、同じグローバル・トランザクションの一部として複数のトランザクション・ブランチが作成される場合、トランザクション一貫性を保持するためにDTPが必要です。これらのトランザクション・ブランチは、異なるRACノードでは認識されません。そのため、すべてのトランザクション・ブランチは、一貫性を確保するために、同じRACノード内に存在している必要があります。BPEL Process ManagerとEnterprise Service Bus（ESB）はそれぞれ、独自のデータソース接続を使用するため、これら2つのコンポーネントが同じグローバル・トランザクションの一部として相互に作用するときは常に、この構成を使用する必要があります。同様に、BPEL Process ManagerやESBからのインバウンドまたはアウトバウンドのアダプタ・エンドポイント用のデータソース接続では、別々のデータソース接続を使用でき、その場合もDTPが必要です。
Oracle RAC Database 11gでは、あるノード上のトランザクションはクラスタ全体で認識されるため、DTPは不要です。詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle Real Application Clustersに関する項に記載されている、サービスおよび分散トランザクション処理についての情報を参照してください。
RACデータベースをインストールすると使用可能になるコマンドラインsrvctlユーティリティを使用して、RACサービスを作成できます。次のコマンドを使用して、優先インスタンスとして使用可能なRACノードを1つ、セカンダリ優先インスタンスとしてRACノードを1つ以上指定できます。
> srvctl add service -d ORCL -s ORCLSVC -r ORCL1 -a ORCL2
コマンド例では、パラメータ値は次のとおりです。
ORCL Database name ORCLSVC DTP service name ORCL1 Preferred instance ORCL2 Secondary instance
サービスで分散トランザクションをサポートできるようにするには、SYSユーザーとして次のデータベース・コマンドを実行します。
SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCLSVC', dtp => true);
<Oracle RAC DatabaseでのDTPおよびXAの詳細は、『RACでXAを使用するためのベスト・プラクティス』を参照してください。>
RAC DTPサービス用の優先インスタンスおよびセカンダリ・インスタンスは、RACノード間でどのようにロード・バランシングが実現されるかということに影響します。SOA Suiteノードのクラスタがある環境では、優先インスタンスの異なる複数のRACサービスを使用してRACのロード・バランシングを実現できます。
次のコマンド例では、2つのサービスと、それぞれに1つの優先インスタンスが作成されます。
> srvctl add service -d ORCL -s ORCLSVC1 -r ORCL1 -a ORCL2 … > srvctl add service -d ORCL -s ORCLSVC2 -r ORCL2 -a ORCL1
この後、特定のノード用のSOA Suiteデータソース接続は、ORCLSVC1とORCLSVC2のいずれかのサービスを使用するように構成できます。これにより、2つのRACインスタンス間でデータ層のロード・バランシングが可能になります。2つのノードのあるSOA Suiteクラスタの単純なケースでは、ノード1のデータソースはORCLSVC1を指し、ノード2のデータソースはORCLSVC2を指します。このモデルは当然、より多くのOracle Application ServerインスタンスとRACインスタンスに拡張できます。使用可能なDTPサービス（それぞれ固有の優先インスタンスが構成されているサービス）の数が多ければ多いほど、独自のDTPサービスに接続できるOracle Application Serverの数も多くなり、データベース層に対するロード・バランシングが向上します。
MAX_COMMIT_PROPAGATION_DELAYデータベース・プロパティを使用して、RACインスタンス間で変更を伝播する速度を構成できます。
次のようなシナリオでは、このプロパティの値をゼロに設定する必要がある可能性があります。
BPELプロセスが、レスポンス・メッセージをただちに送信する外部サービスの非同期呼出しを開始する
BPELプロセスが一方向呼出しを開始し、ただちに受信される相関レスポンス・メッセージを処理するためにpickアクティビティを使用する
これらのシナリオでは、レスポンス・メッセージの受信が予想される時点で、BPELシステムが自動的にプロセス・インスタンス・データをデータベースにハイドレーションします。レスポンス・メッセージが届くと、BPELシステムはプロセス・インスタンスをリハイドレーションします。BPELプロセスのリハイドレーション元のRACインスタンスにインスタンス・データが伝播される前にレスポンス・メッセージが届いた場合、エラーが発生します。したがって、非同期のレスポンス・メッセージが迅速（1秒以内）に返ってくる可能性がある環境では、BPELシステムが正しく動作するようにするために、MAX_COMMIT_PROPAGATION_DELAYプロパティ値をゼロに設定する必要があります。
MAX_COMMIT_PROPAGATION_DELAYの詳細は、『Oracle Real Application Clusters管理者ガイド』を参照してください。
この項では、Oracle Internet Directoryコンポーネント（OIDHOST1およびOIDHOST2）を、Metadata Repositoryを含むデータ層にインストールする手順について説明します。2つのコンポーネントのインストール手順はほとんど同じですが、構成オプション画面での選択が異なります。
最初のOracle Internet Directoryインスタンスをインストールする前に、OracleAS Metadata Repositoryが稼動している必要があります。
10g（10.1.4.0.1）のOracle Internet DirectoryをOIDHOST1にインストールする手順は次のとおりです。
システム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。これらは、ご使用のプラットフォームおよびリリースのOracle Application Serverドキュメント・ライブラリで参照できるOracle Application Serverのクイック・インストレーション・ガイドに示されています。
使用しているオペレーティング・システムに対応する次のコマンドを発行して、コンピュータ上のサービスが、ポート389と636を使用していないことを確認します（ポートが使用されていない場合は、コマンドから出力は返されません）。
UNIX:
netstat -an | grep "389"
netstat -an | grep "636"
Microsoft Windows:
netstat -an | findstr :389
netstat -an | findstr:636
Disk1/stage/Responseディレクトリのstaticports.iniファイルを、Oracleホームのディレクトリにコピーします。
staticport.iniファイルを編集し、次のカスタム・ポートを割り当てます。
Oracle Internet Directory port = 389 Oracle Internet Directory (SSL) port = 636
次のように、Oracle Universal Installerを起動します。
UNIX:
> runInstaller
Microsoft Windows:
setup.exeをダブルクリックします。
「ようこそ」画面が表示されます。
「次へ」をクリックします。
UNIXシステムの場合、「インベントリ・ディレクトリと資格証明の指定」画面が表示されます。
oraInventoryディレクトリと、そのディレクトリへの書込み権限を持つオペレーティング・システム・グループを指定します。
「次へ」をクリックします。
UNIXシステムの場合、oraInstRoot.shスクリプトの実行を求めるダイアログが表示されます。
ウィンドウを開いてから、そのウィンドウのプロンプトに従ってスクリプトを実行します。
Oracle Universal Installerの画面に戻り、「次へ」をクリックします。
「ファイルの場所の指定」画面が表示され、次のもののデフォルトの場所が示されます。
インストールの製品ファイル（インストール元）
Oracleホームの名前とパス（インストール先）
デフォルトとは異なるインストール先を選択する場合は、「インストール先名」と「パス」を指定し、「次へ」をクリックします。
「インストールする製品の選択」画面が表示されます。
「OracleAS Infrastructure 10g」を選択し、「次へ」をクリックします。
「インストール・タイプの選択」画面が表示されます。
「Identity Management」を選択し、「次へ」をクリックします。
「既存のOracle Application Server (10.1.2) Infrastructureのアップグレード」画面が表示されます。
「Oracle Application Server Infrastructure 10g (10.1.4.0.1)の新規インストール」を選択し、「次へ」をクリックします。
「製品固有の前提条件のチェック」画面が表示されます。
「次へ」をクリックします。
「インストール前の要件の確認」画面が表示されます。
要件が満たされていることを確認してから、それぞれのボックスを選択し、「次へ」をクリックします。
「構成オプションの選択」画面が表示されます。
「Oracle Internet Directory」、「OracleAS Directory Integration and Provisioning」および「高可用性およびレプリケーション」を選択し、「次へ」をクリックします。
「ポート構成オプションの指定」画面が表示されます。
「手動」を選択し、「次へ」をクリックします。
「リポジトリの指定」画面が表示されます。
DBAログイン情報とコンピュータ情報を入力し、「次へ」をクリックします。
|
注意: RACデータベースのホスト名とポート・フィールドの構文は次のとおりです。infradbhost1-V.mycompany.com:1521^infradbhost2-V.mycompany.com:1521^ |
「高可用性またはレプリケーション・オプションの選択」画面が表示されます。
「OracleASクラスタ(ID管理)」を選択し、「次へ」をクリックします。
「Internet Directoryのネームスペースの指定」画面が表示されます。
「次へ」をクリックしてデフォルトの「推奨ネームスペース」を指定するか、「カスタム・ネームスペース」の値を入力して「次へ」をクリックします。
「インスタンス名とias_adminパスワードの指定」画面が表示されます。
インスタンス名とパスワードを指定し、「次へ」をクリックします。
「サマリー」画面が表示されます。
選択内容が正しいことを確認し（そうでない場合は、「戻る」をクリックして、それまでの画面の選択内容を変更する）、「インストール」をクリックします。
「インストール」画面がプログレス・バー付きで表示されます。UNIXシステムの場合、root.shスクリプトの実行を求めるダイアログが表示されます。
ウィンドウを開いてから、このスクリプトを実行します。
「コンフィギュレーション・アシスタント」画面が表示されます。複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。このプロセスの完了後、「インストールの終了」画面が表示されます。
「終了」をクリックしてから、その選択を確認します。
このタスクを実行する前に、OracleAS Metadata Repositoryと最初のOracle Internet Directoryインスタンスが稼動している必要があります。10gリリース2（10.1.2）のOracle Internet DirectoryをOIDHOST2にインストールする手順は次のとおりです。
システム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。これらは、ご使用のプラットフォームおよびリリースのOracle Application Serverドキュメント・ライブラリで参照できるOracle Application Serverのクイック・インストレーション・ガイドに示されています。
使用しているオペレーティング・システムに対応する次のコマンドを発行して、コンピュータ上のサービスが、ポート389と636を使用していないことを確認します（ポートが使用されていない場合は、コマンドから出力は返されません）。
UNIX:
netstat -an | grep "389"
netstat -an | grep "636"
Windows:
netstat -an | findstr :389
netstat -an | findstr:636
ポートが使用されている場合（ポートを識別する出力がコマンドから返される場合）、ポートを解放する必要があります。
UNIX:
/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。
Windows:
ポートを使用しているコンポーネントを停止します。
Disk1/stage/Responseディレクトリのstaticports.iniファイルを、Oracleホームのディレクトリにコピーします。
staticports.iniファイルを編集し、コメントを外して次のエントリを更新します。
Oracle Internet Directory port = 389 Oracle Internet Directory (SSL) port = 636
次のように、Oracle Universal Installerを起動します。
UNIXでは、runInstallerコマンドを発行します。
Windowsでは、setup.exeをダブルクリックします。
「ようこそ」画面が表示されます。
「次へ」をクリックします。
UNIXシステムの場合、「インベントリ・ディレクトリと資格証明の指定」画面が表示されます。
oraInventoryディレクトリと、そのディレクトリへの書込み権限を持つオペレーティング・システム・グループを指定します。
「次へ」をクリックします。
UNIXシステムの場合、oraInstRoot.shスクリプトの実行を求めるダイアログが表示されます。
ウィンドウを開いてから、そのウィンドウのプロンプトに従ってスクリプトを実行します。
Oracle Universal Installerの画面に戻り、「次へ」をクリックします。
「ファイルの場所の指定」画面が表示され、次のもののデフォルトの場所が示されます。
デフォルトとは異なるインストール先を選択する場合は、「インストール先名」と「パス」を指定し、「次へ」をクリックします。
「インストールする製品の選択」画面が表示されます。
「OracleAS Infrastructure 10g」を選択し、「次へ」をクリックします。
「インストール・タイプの選択」画面が表示されます。
「Identity Management」を選択し、「次へ」をクリックします。
「既存のOracle Application Server (10.1.2) Infrastructureのアップグレード」画面が表示されます。
「Oracle Application Server Infrastructure 10g (10.1.4.0.1)の新規インストール」を選択し、「次へ」をクリックします。
「製品固有の前提条件のチェック」画面が表示されます。
「次へ」をクリックします。
「インストール前の要件の確認」画面が表示されます。
要件が満たされていることを確認してから、それぞれのボックスを選択し、「次へ」をクリックします。
「構成オプションの選択」画面が表示されます。
「Oracle Internet Directory」、「OracleAS Directory Integration and Provisioning」および「高可用性およびレプリケーション」を選択し、「次へ」をクリックします。
「ポート構成オプションの指定」画面が表示されます。
「手動」を選択し、「次へ」をクリックします。
「リポジトリの指定」画面が表示されます。
DBAログイン情報とコンピュータ情報を入力し、「次へ」をクリックします。
|
注意: RACデータベースのホスト名とポート・フィールドの構文は次のとおりです。infradbhost1-V.mycompany.com:1521^infradbhost2-V.mycompany.com:1521^ |
ダイアログが開き、Oracle Internet Directoryの1次コンピュータのシステム時刻とインストール先のコンピュータのシステム時刻を同期化するよう求められます。
2台のコンピュータのシステム時刻を同期化し、「OK」をクリックします。
「ODSパスワードの指定」画面が表示されます。
ユーザー名とパスワードを指定し、「次へ」をクリックします。
「OIDログインの指定」画面が表示されます。
「インスタンス名とias_adminパスワードの指定」画面が表示されます。
インスタンス名とパスワードを指定し、「次へ」をクリックします。
「サマリー」画面が表示されます。
選択内容が正しいことを確認し（そうでない場合は、「戻る」をクリックして、それまでの画面の選択内容を変更する）、「インストール」をクリックします。
「インストール」画面がプログレス・バー付きで表示されます。UNIXシステムの場合、root.shスクリプトの実行を求めるダイアログが表示されます。
ウィンドウを開いてから、このスクリプトを実行します。
「コンフィギュレーション・アシスタント」画面が表示されます。複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。このプロセスの完了後、「インストールの終了」画面が表示されます。
「終了」をクリックしてから、その選択を確認します。
mySOAcompany.comのエンタープライズ・デプロイメント・アーキテクチャをJAZN-SSO/DASで使用する場合、次の機能を実行するようにロード・バランシング・ルーターを構成する必要があります。
ポート389および636で受信したoidhost1.mycompany.comへのリクエストと、ポート389および636で受信したoidhost2.mycompany.comへのリクエストのバランシング。
両方のコンピュータでのOracle Internet Directoryプロセスの監視。Oracle Internet Directoryプロセスがどちらかのコンピュータで停止した場合、ロード・バランシング・ルーターは稼動しているコンピュータにLDAPトラフィックをルーティングする必要があります。
次のコマンドを使用して、Oracle Internet Directoryの各インスタンスとロード・バランシング・ルーターに接続できることを確認します。
ldapbind -p 389 -h OIDHOST1
ldapbind -p 389 -h OIDHOST2
ldapbind -p 389 -h oid.mycompany.com
次のコマンドを使用して、ORACLE_HOME/binにあるOracle Internet Directoryの各インスタンスでoidadminツールを起動します。
oidadmin
データ層が、図2-1に示されている構成になります。
SOA Suiteのデータベースは、表2-1に示されているバージョンのいずれかである必要があります。
表2-1 SOA Suiteでサポートされるデータベースのバージョン
| データベース・シリーズ | バージョン |
|---|---|
|
Oracle9iリリース2（9.2.x） |
9.2.0.7以上 |
|
Oracle Database 10gリリース1（10.1.x） |
10.1.0.5以上 |
|
Oracle Database Express Edition 10gリリース2（10.2.x） |
10.2.0.1 |
|
Oracle Database 10gリリース2（10.2.x） |
10.2.0.2以上 |
次のコマンドを使用してデータベースのバージョンを調べます。
sqlplus "sys/password as sysdba" sql> select version from product_component_version where product like 'Oracle%9i%' or product like 'Oracle%Database%';
SOA Suiteをインストールする前に、次のデータベース要件に従って、ORABPEL、ORAESBおよびORAWSMスキーマをOracleデータベース（CUSTDBHOST1およびCUSTDBHOST2）にインストールする必要があります。
Oracle Application ServerのDisk1/install/soa_schemas/ircaディレクトリに移動します。
irca.batまたはirca.shスクリプトを実行します。
クラスタ設定内では、ESBは、内部の通信および外部エンドポイントとの非同期相互作用にAQメッセージング・トピックを使用します。これらのトピックは、SQLスクリプト$ORACLE_HOME/integration/esb/sql/oracle/create_esb_topics.sqlを使用して作成されます。データベースの互換性モード「10.0」を使用するようにこのスクリプトを変更し、ORAESBユーザーとしてスクリプトを実行してAQトピックを作成（または再作成）します。
dbms_aqadm.create_queue_table( Queue_table => qtablename, Queue_payload_type => 'SYS.AQ$_JMS_TEXT_MESSAGE', multiple_consumers => true, compatible => '10.0');
トランザクションに関与するユーザー定義AQトピック（たとえば、AQ-JMS用のAQアダプタやJMSアダプタに接続するトピック）についても同様に、正しい互換値を使用する必要があります。
次の問合せを使用して互換値を確認します。
SQL> SELECT QUEUE_TABLE, COMPATIBLE FROM USER_QUEUE_TABLES; QUEUE_TABLE COMPAT ------------------------------ ------ ESB_CONTROL 10.0.0 ESB_ERROR 10.0.0 ESB_ERROR_RETRY 10.0.0 ESB_JAVA_DEFERRED 10.0.0 ESB_MONITOR 10.0.0
ESBは、ESBエンドポイントへの非同期ルーティングに、内部のデータベース・ベースのOracle Streamsアドバンスト・キューイング（AQ）メッセージング・キューを利用します。前述の方法でDTPサービスを使用してデータソースのロード・バランシングを行っている場合、これにはパフォーマンスに関する考慮事項があります。RACマルチノード環境内のAQでは、特定のキュー表にインスタンス・アフィニティを設定し、すべてのクライアントが指定のインスタンス上でそのキュー表にアクセスするように制限することをお薦めします。キュー表にインスタンス・アフィニティを設定することで、メッセージの伝播やタイミング・プロパティ（遅延や有効期限など）の実装など、メッセージのバックグラウンド処理が、確実にそのキューのプライマリ・インスタンスまたはフェイルオーバー・インスタンスで実行されるようになります。AQのインスタンス・アフィニティとDTPサービスの優先インスタンスには一貫性がある必要があります。したがって、各SOA Suiteノードのデータソースは、単一のDTPサービス（たとえば、ORCLSVC1）を指している必要があります。SOA SuiteのデータソースとAQの処理を同じRACノードに結び付ける構成を実装するには、次の手順を実行します。
同じDTPサービス（たとえば、ORCLSVC1）を使用するように、すべてのSOA Suiteデータソースを構成します。
DTPサービスのプライマリ・ノードとセカンダリ・ノードに関係付けるプライマリ・インスタンスとセカンダリ・インスタンスの値について、該当するRACインスタンス番号を決定します。
SQL> SELECT INSTANCE_NUMBER,INSTANCE_NAME FROM V$INSTANCE;
ESB_HOME/sql/oracle/create_esb_topics.sqlファイルを編集します。
次の例を使用します。この例では、前の手順で決定されたプライマリ・インスタンス番号とセカンダリ・インスタンス番号が使用されています。
dbms_aqadm.create_queue_table( … ); dbms_aqadm.alter_queue_table( queue_table => qtablename, primary_instance => 1, secondary_instance => 2); dbms_aqadm.create_queue ( … );
ORAESBスキーマに接続し、SQLスクリプトを実行します。
これにより、ESBのAQトピックが再作成され、それらのトピックが特定のRACノードに対するアフィニティを処理するように構成されます。
オプションとして、alter_queue_tableを実行できます。この場合、スクリプトを実行してもトピックは再作成されません。それには、create_esb_topics.sqlスクリプトに一覧表示されているスクリプトごとに、SQLコマンドalter_queue_tableを直接実行します。
ここに記載されている手順を実行すると、パフォーマンスが向上する可能性がありますが、データベース処理はRACクラスタの1つのノードに限定されるため、データ層のスケーラビリティが制限されます。
デプロイメント・トポロジの設計時には、スケーラビリティとパフォーマンスの対比という側面を考慮に入れることをお薦めします。
この項では、操作中にグローバル・トランザクション（XA）の一貫性を保持するための、Oracle SOA Suiteコンポーネントの構成の要件について説明します。この構成は、Oracle RAC Database 10g上のデプロイメントにも対応します。また、この項では、RAC環境と非RAC環境の両方に対してXAを正しく構成するための手順についても説明します。どちらの環境でも必要なXA構成はほとんど同じですが、RACインスタンスに対するデータソースおよびデータベースの構成に関連して、ごくわずかな違いがあります。
この項の内容は、Oracle SOA SuiteとOracle Application Serverの相互作用に固有のものであり、Oracle SOA Suiteエンタープライズ・デプロイメントの他の領域は対象ではありません。エンタープライズ・デプロイメントの詳細は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』を参照してください。
Oracle SOA Suiteは、Oracle SOA Suite、Oracle Application ServerおよびJDBCの必須パッチの特定セットを使用して、XAで動作保証されています。Oracle RAC Database 10g上のXAデプロイメントの場合、Oracle SOA Suiteは、Oracle RAC Databaseのバージョン10.2.0.2.xおよび11.1.0.6.x（およびOracle Clusterwareでサポートされている構成）に対してサポートされています。
必須パッチのリストは、My Oracle Support（以前の名前はMetaLink）にあります。ここで、OracleMetaLink Note 38108.1「Required Patching for XA Deployments of SOA Suite Using RAC Databases」を取得してください。
My Oracle Supportは、次の場所にあります。
BPEL Process ManagerやESBなどのアダプタは、OC4Jコンテナによって管理されるデータソース接続プールを使用して、それぞれのデータベース・スキーマに接続します。Oracle Web Services Managerは、第2.11.3項「OWSMデータベース接続」で説明する独自の接続プーリング・メカニズムを使用します。
ここで説明するXA構成は、RAC固有のものではありません。RACデータベース接続文字列を除いて、RAC環境と非RAC環境のどちらでも必要です。
この構成は、次のコンポーネント接続プールに適用されます。
BPEL Process Manager（orabpel）
ESBランタイム（esb-rt）
ESBデザインタイム（esb-dt）
次のものに対するアダプタ
AQ
AQ-JMSでのJMSアダプタ
データベース
E-Business Suite
接続プールは、ORACLE_HOME/j2ee/<containername>/config/data-sources.xmlファイルで定義されます。BPEL Process ManagerおよびESBconnectionプールの名前は、BPELPM_CONNECTION_POOL、ESBPoolおよびESBAQJMSPoolです。アダプタ接続プールの名前は、作成時に付けられます。
OC4Jコンテナごとの接続プールそれぞれについて、次のXA構成が必要です。
分散トランザクションのサポートをデータソース接続に提供するため、接続プールは、XAコネクション・ファクトリ・クラスoracle.jdbc.xa.client.OracleXADataSourceを使用して構成する必要があります。次に例を示します。
<connection-factory factory-class="oracle.jdbc.xa.client.OracleXADataSource"
RAC上のデプロイメントの場合、データソースのデータベース接続文字列は、RACのTNSNAMES接続記述とともに、SERVICE_NAME（たとえば、ORCLSVC）を使用するように構成する必要があります。
接続文字列にSERVICE_NAMEを使用することが重要です。これはSIDと同じではありません。RAC構成の詳細は、第2.3項「Oracle RAC Database」を参照してください。
url="jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost1-V)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost2-V)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=ORCLSVC)))"
Oracle SOA Suiteは、トランザクション・コーディネータとしてOracle Application Server内のOC4Jトランザクション・マネージャを使用します。複数のデータソースにまたがるトランザクションで予期しないエラーが発生した場合、OC4Jトランザクション・マネージャが、完了しなかったトランザクションを正しくリカバリしようとします。OC4Jトランザクション・マネージャは、ファイルベースまたはデータベースの独自のトランザクション・ログを使用して、トランザクション情報を格納します。詳細は、第2.11.4項「OC4Jトランザクション・マネージャのロギング」を参照してください。
データベース・リソースに対するリカバリ・プロセスの一部として、リカバリ・マネージャは、データベース・トランザクションの状態情報にアクセスし、適切なコマンド（リソース・トランザクションのコミットやロールバックなど）を発行するための正しい権限が付与された、データベース・ユーザーの資格証明を要求します。
この機能を実行するデータベース・ユーザーを設定する手順は、次のとおりです。
次のコマンドを使用して、データベース・ユーザー（たとえば、xauser）を作成し、CONNECT権限およびRESOURCE権限を付与します。
SQL> CREATE USER xauser IDENTIFIED BY welcome1; … SQL> GRANT CONNECT, RESOURCE TO xauser; …
次のコマンドを使用して、DBA_PENDING_TRANSACTIONSに対する選択権限およびSYS.DBMS_SYSTEMパッケージに対する実行権限を付与します。
SQL> GRANT SELECT ON DBA_PENDING_TRANSACTIONS TO xauser; … SQL> GRANT EXECUTE ON SYS.DBMS_SYSTEM TO xauser;
接続プール定義のconnectionfactory要素内に<xa-recovery-config>要素を追加して、リカバリ・マネージャのデータベース・ユーザー名とパスワードを指定します。
次に例を示します。
<connection-factory …>
<xa-recovery-config>
<password-credential>
<username>xauser</username>
<password>welcome1</password>
</password-credential>
</xa-recovery-config>
…
</connection-factory>
リカバリ・マネージャでパスワードの不明瞭化を使用するには、データベース・ユーザーの資格証明と一致するユーザー名とパスワードを持つOC4J JAAS（Java Authentication and Authorization Service）ユーザーを作成します。
次の例では、ユーザーは、$ORACLE_HOME/j2ee/<container>/config/system-jazn-data.xmlファイルに格納されているユーザー名および暗号化されたパスワードを使用して、jazn.comレルムの一部として作成されます。
$OH/j2ee/oc4j_soa> java -jar ../home/jazn.jar -shell AbstractLoginModule username: oc4jadmin AbstractLoginModule password: JAZN:> adduser jazn.com xauser welcome1
jazn.jarユーティリティは、$ORACLE_HOME/j2ee/homeディレクトリ内にありますが、データソースが定義されているコンテナ・ディレクトリ（たとえば、$ORACLE_HOME/j2ee/oc4j_soa）から実行する必要があります。
ユーザーが作成されたら、パスワードのインダイレクションの表記法でデータソースのパスワード要素を更新します。これで、OC4Jは、暗号化されたパスワードを実行時に参照して利用するようになります。
次に例を示します。
<connection-factory …>
<xa-recovery-config>
<password-credential>
<username>xauser</username>
<password>->xauser</password>
</password-credential>
</xa-recovery-config>
…
</connection-factory>
新しい設定を有効にするため、コンテナを再起動します。次に、コンテナとdata-sources.xmlファイルごとに、これらの手順を繰り返します。パスワードの不明瞭化の詳細は、『OracleAS JAAS Provider Admintoolリファレンス』を参照してください。
OC4Jトランザクション・マネージャの構成の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
次のconnection-pool属性は、すべての接続プールに対してお薦めする設定です。
<connection-pool name="ESBPool" min-connections="50" initial-limit="0" max-connect-attempts="10" connection-retry-interval="5" max-connections="250">
接続プール属性の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
一部のアダプタは、ユーザー定義データソース接続を使用します。それらの接続は、第2.11.2.4項で説明されているものと同じXAリカバリと接続プール設定で構成されている必要があります。それらのアダプタは、次のとおりです。
AQ
AQ-JMSでのJMSアダプタ
データベース
E-Business Suite
これらのアダプタのエンドポイントおよび対応するデータソースは、アダプタを使用するBPEL Process ManagerとESBデプロイメントいずれかの一部としてOracle SOA Suiteをインストールするときに作成されます。そのため、これらの手順は、そのようなデプロイメントでのみ必要になります。
data-sources.xmlファイルでこれらのアダプタのデータソースを構成することをお薦めします。
データソースは、$ORACLE_HOME/j2ee/<containername>/application-deployments/default/<adapter>/oc4j-ra.xmlにあるアダプタ構成ファイル内で直接構成することもできます。
data-sources.xmlファイル内でデータソースを構成すると、OC4Jで使用可能なデータソース管理のフル実装を使用できます。
Oracle E-Business Integration Documentationにある『Oracle Application Server Adapters for Files、FTP、DatabasesおよびEnterprise Messagingユーザーズ・ガイド』には、アダプタがそのデータベース接続情報を導出する状況を示した図が記載されています。
カスタム・アプリケーション・データとAQメッセージング・トピックには、別々のスキーマとデータソースを使用することをお薦めします。BPEL Process ManagerまたはESBスキーマでカスタム・アプリケーション・データを格納するか、またはカスタムAQトピックを作成すると、パフォーマンスの問題さらにはデッドロックの問題が発生する可能性があります。
data-sources.xmlファイル内にデータソースを構成したら、データベース・アダプタまたはAQアダプタのoc4j-ra.xmlファイルを編集し、xADataSourceNameプロパティのコネクタ・ファクトリ構成プロパティをデータソースのJNDI名に設定します。さらに、非XA dataSourceNameプロパティに値が設定されていないことを確認します。
データベース・アダプタのoc4j-ra.xmlファイルの例を次に示します。
<connector-factory location="eis/DB/BPELSamples" connector-name="Database Adapter"> <config-property name="xADataSourceName" value="jdbc/BPELSamplesDataSource"/> <config-propertyname="dataSourceName" value=""/> … </connector-factory>
グローバル・トランザクションに関与するJMSアダプタでは、oc4j-ra.xmlファイル定義内でTransactedプロパティの値を「false」に設定する必要があります。これにより、このプロパティが「true」に設定されているときのデフォルトの動作（JMS操作当たり1つのトランザクション・セッションのみを許可）が変更されます。同じコネクタ・ファクトリ定義で、プロパティ値がXAQueueConnectionFactoriesとXATopicConnectionFactoriesのいずれかになっているXA connectionFactoryLocation構成プロパティを指定する必要があります。
次に例を示します。
<connector-factory location="eis/jms/myQueue" …/> … <config-property name="connectionFactoryLocation" value="java:comp/resource/ojmsdemo/XAQueueConnectionFactories/myQCF"/> <config-property name="isTransacted" value="false"/> … </connector-factory>
connectionFactoryLocationプロパティのojmsdemoは、$ORACLE_HOME/j2ee/<container-name>/config/application.xmlでJMSリソースに対して定義されているリソース・プロバイダ名と一致している必要があることに注意してください。
OJMSおよびOC4J JMSアダプタ構成の詳細は、『Oracle Application Server Adapters for Files、FTP、DatabasesおよびEnterprise Messagingユーザーズ・ガイド』の、OJMSの構成に関する項またはOC4J JMSの構成に関する項を参照してください。このガイドは、Oracle E-Business Integration Documentation内のOracle Application Server Adaptersシリーズにあります。
さらに、XAトランザクション内でAQ-JMS（別名OJMS）に対して動作するJMSアダプタには、次のように構成することをお薦めします。
同じスキーマへのインバウンドおよびアウトバウンドのメッセージング用に、oc4j-ra.xml内に別々のコネクタ・ファクトリを構成します。
これには、$ORACLE_HOME/j2ee/<containername>/config/application.xml内に2つの別々のリソース・プロバイダ（それぞれが固有のデータソースを指すもの）を作成する必要があります。
詳細は、Oracle Application Serverのリリース・ノートの、AQ-JMS（OJMS）に対するXAシナリオでのJMSアダプタに関する項を参照してください。
この要件はXA構成でのみ必要です。
AQ-JMSのデータソースの構成では、txlevelプロパティを「global」に、manage-local-transactionsプロパティを「false」に設定する必要があります。
明示的に設定されていない場合、tx-levelプロパティはデフォルトで「global」に設定されますが、manage-local-transactionsプロパティはデフォルトで「true」に設定されることに注意してください。
<managed-data-source name="AQSAMPLE_DS1" connection-pool-name="AQSAMPLE_POOL1" jndi-name="jdbc/aqSample1" tx-level="global" manage-local-transactions="false" login-timeout="0"/>
manage-local-transactionsのこの設定では、グローバル・トランザクションと競合することなく、AQ-JMSプロバイダは、非トランザクションDDL文を発行（永続サブスクライバを作成）できます。
これらのプロパティの詳細は、『Oracle Containers for J2EEサービス・ガイド』の、管理対象データソース設定に関する項を参照してください。
cacheConnectionsという新しいプロパティを「false」に設定して、JMSアダプタに対してBPELパートナ・リンクまたはESBエンドポイントを構成します。
Fast Connection Failover（FCF）は、暗黙的接続キャッシュ（ICC）によって提供される、よく知られたRAC固有のクライアント機能であり、Oracle 10g JDBCドライバの機能です。
Fast Connection Failoverは、10g XA JDBCドライバのJDBC ICCではサポートされていません。FCFは非XA 10g JDBCドライバでのみ動作するため、FCFの構成は設定に含まれません。
この項では、OWSMが独自のデータベース接続プーリング・メカニズムを使用できるようにする方法について説明します。このメカニズムは、BPEL Process ManagerおよびESBに対するOC4J管理対象データソースとは別個のものです。RACデータベースを使用するために必要な構成は、適切なTNSNAMESディスクリプタを使用してデータベース接続文字列を変更することのみです。
以降の手順では、OWSMがOracle Universal Installerを使用してすでにインストールされていることを想定しています。
$ORACLE_HOME/owsm/bin/coresv.propertiesファイルを編集し、RACデータベース接続文字列を使用するようにdataload.messagelog.db.urlプロパティを更新します。
次に例を示します。
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost1-V)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost2-V)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=ORCLSVC)))
ORACLE_HOME\owsm\bin\wsmadminディレクトリでOWSMのwsmadminコマンドライン・ユーティリティを使用して、OWSMモジュールをすべて更新および再デプロイします。
次に例を示します。
> wsmadmin copyDBConfig … > wsmadmin deploy all
Oracle Application Serverコンテナを再起動し、OWSMにログインします。
「ポリシー管理」に移動し、cfluent.messagelog.db.urlコンポーネント・プロパティを同じデータベース接続文字列で更新します。
wsmadminコマンドの詳細は、『Oracle Web Services Managerデプロイメント・ガイド』を参照してください。
OC4Jトランザクション・マネージャでは、トランザクションの状態に関する情報を保持するためにロギングが必要です。$ORACLE_HOME/j2ee/<containername>/config/transaction-manager.xmlファイルを使用して、データベースまたはファイルベースの永続性にロギング・タイプを構成できます。
次のロギング・タイプのいずれかを実行します。
トランザクション・ロギングをファイルベースの永続性に構成します。
この設定では、Oracle Application Serverノードに障害が発生した場合にトランザクション・ログの可用性を維持するために、ファイル・システムは共有ディスク・ストレージ上に存在している必要があります。デフォルトのファイルベースのログは、ローカル・ファイル・システム（$ORACLE_HOME/j2ee/home/persistence/txlogs）にあり、ロケーション属性を使用して、共有ディスク・ディレクトリの場所を指定します。
<commit-coordinator retry-count="4">
<middle-tier>
<log type="file" location="/net/server1/txlogs" />
<recovery retry-interval = "30"/>
</middle-tier>
</commit-coordinator>
トランザクション・マネージャによって、このディレクトリの場所で構成されているOC4Jコンテナごとに、固有のサブディレクトリが自動的に作成されます。
または、データベース永続性のトランザクション・ロギングを使用するために、BPEL Process ManagerまたはESBとともにインストールされているOC4Jコンテナごとに次の手順を実行します。
コンテナのdata-source.xmlファイル内にネイティブのデータソース接続を作成します。
<native-data-source name="xaLogging"jndi-name="jdbc/xaLogging" data-source-class="oracle.jdbc.pool.OracleDataSource" url="jdbc:oracle:thin:@host:1521:orcl" />
transaction-manager.xmlファイルを編集して、データベース永続性のトランザクション・ロギングを有効にします（簡単にするために、XAリカバリ・マネージャ用に構成されている同じデータベース・ユーザーの使用を検討してください）。
<commit-coordinator retry-count="4">
<middle-tier>
<log type="database" location="jdbc/xaLogging">
<identity user="xauser" password="welcome1"/>
<database-logging-performance …/>
</log>
</middle-tier>
</commit-coordinator>
データベースにログインし、$ORACLE_HOME/j2ee/home/database/j2ee/jta/oracle/2pc_jdbcstore.sqlでSQLスクリプトを実行してトランザクション・マネージャ・スキーマを作成します。
詳細は、「OC4Jトランザクション・サポート」の「データベース・ストアの属性」を参照してください。
パスワードを不明瞭化するには、この項で前に説明した手順に従い、パスワードのインダイレクションに同じ表記法を利用します。
<commit-coordinator retry-count="4">
<middle-tier>
<log type="database" location="jdbc/xaLogging">
<identity user="xauser" password="->xauser"/>
<database-logging-performance …/>
</log>
</middle-tier>
</commit-coordinator>
前述のとおりトランザクション・マネージャの永続性を構成し、コンテナを再起動すると、data-sources.xml内で定義されているデータソースに、新しい属性commit-record-table-nameが設定されます。デフォルトでは、この属性値は空の文字列です。
この属性は、OC4Jトランザクション・マネージャの別の機能であるリカバリ可能最終リソース・コミット（RLRC）を有効にするための、オプションの構成の一部です。この機能を使用しない場合は、この属性を削除するか、または値を空のままにしておくのが安全です。RLRCは、OC4Jトランザクション・マネージャの最終リソース・コミット（LRC）機能に関連しています。この機能により、1つの非XAデータベース・リソースでグローバル・トランザクションのパフォーマンスを最適化できます。LRCとRLRCの詳細は、『Oracle Containers for J2EEサービス・ガイド』の最終リソース・コミットに関する項、およびOracle Application Serverのリリース・ノートのリカバリ可能最終リソース・コミットのサポートに関する項を参照してください。
OC4Jトランザクション・マネージャの構成の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
このXA設定用のJDBC関連パッチはまず、Oracle Databaseに適用されます。
必須パッチのリストは、My Oracle Support（以前の名前はMetaLink）にあります。ここで、OracleMetaLink Note 38108.1を取得して、JDBCのパッチ情報を確認してください。
My Oracle Supportは、次の場所にあります。
パッチのREADMEの手順に従って適用します。次の手順は、更新されたJDBCファイルをアプリケーション・サーバーにコピーすることです。DatabaseのORACLE_HOME/jdbc/lib/*ファイルをApplication ServerのORACLE_HOME/jdbc/lib/ディレクトリにコピーします。Application Serverインスタンスごとにこれを実行します。
