13 Oracle Service Busを含めるドメインの拡張

この章で説明する手順では、Oracle Service Bus (OSB)を追加してエンタープライズ・デプロイメント・トポロジを拡張するプロセスを示します。

Oracle Service Busの独自のドメインでの構成について

Oracle Service Bus (OSB)をエンタープライズ・トポロジに追加する際、既存のSOAドメインに追加することも、Oracle SOA Suiteドメインとは別にOSB用の新たなドメインを作成することもできます。

OSBトポロジの詳細は、「Oracle Service Busのトポロジ・オプションについて」を参照してください。

Oracle Service Busを別個のドメイン内に構成すると決定した場合、トポロジにOracle Service Busを追加する手順を使用する際に、次の点に留意してください。

  • SOA管理対象サーバーまたはSOAクラスタへの参照はすべて無視してください。ドメインのこれらの要素が存在するのは、Oracle SOA Suiteを含めることですでに拡張されたドメインを拡張する場合のみです。

  • RCUを実行して、Oracle Service BusドメインのSOAINFRAスキーマを作成する必要があります。このスキーマは、Oracle Service Busで必要とされます。Oracle Service Busドメインには、一意のSOAINFRAスキーマとスキーマ接頭辞を使用する必要があります。

  • 「Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート」での説明に従って、構成ウィザードを実行すると、「高可用性のオプション」画面が開きます。

    この画面は、自動サービス移行またはJDBCストア、あるいはその両方を使用するクラスタを作成するときに初めて表示されます。クラスタのHAオプションを選択すると、構成ウィザードを使用してドメインに追加される以降のクラスタはすべて、自動的にHAオプションが適用されます(つまり、構成ウィザードによってJDBCストアが作成され、それにASMが構成される)。

    次のオプションを選択することをお薦めします:
    • 「データベース・リース」で「自動サービス移行の有効化」を選択します。

    • 「JTAトランザクション・ログ永続性」「JDBC TLogストア」に設定します。

    • 「JMSサーバー永続性」「JMS JDBCストア」に設定します。

Oracle Service Busの構成時に使用される変数

この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。

いくつかのディレクトリ変数の値については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • JAVA_HOME

  • WEB_DOMAIN_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている、仮想ホスト名アドレスADMINVHNを参照します

この項のアクションは、次のホスト・コンピュータで実行します。

  • SOAHOST1

  • SOAHOST2

  • WEBHOST1

  • WEBHOST2

トポロジへのOSBの追加の概要

OSBをトポロジに追加する前に、初期Infrastructureドメインの作成に必要なステップをすでに実行し、ドメインを拡張してOracle SOA Suiteを追加していることを確認する必要があります。

表13-1では、Oracle Service Busのために既存のSOAドメインまたは既存のInfrastructureドメインを拡張する、大まかなステップをリストして説明します。

表13-1 Oracle Service Busを追加するためのSOAドメインの拡張ステップ

ステップ 説明 詳細情報

Oracle Service Busソフトウェアのインストール

ターゲット・システムへのOSBソフトウェアのインストール

Oracle Service Busソフトウェアのインストール

オプションで、サポートされているデータベースにSOAINFRAスキーマをインストールします。

OSBでは、wlsbjmsrpDataSourceデータ・ソースにSOAINFRAスキーマが必要です。OSBを独自のドメインで実行する場合は、サポートされているデータベースでOSB用に別個のSOAINFRAスキーマがインストールされていることを確認する必要があります。

OSBドメインで使用されるSOAINFRAスキーマには、一意のスキーマを使用してください。

Oracle SOA Suiteデータベース・スキーマの作成

オプションで、新しいInfrastructureドメインを作成します。

OSBを独自のドメインで実行する場合は、まずInfrastuctureドメインを作成して、OSBを含めることでこのドメインを拡張できるようにする必要があります。

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

ドメイン拡張のための構成ウィザードの実行

Oracle Service Busコンポーネントを追加するためにSOAまたはInfrastructureドメインを拡張します

Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

SOAHOST1の管理対象サーバー・ディレクトリ、さらにはSOAHOST2へのドメイン構成の伝播

Oracle Service Busでは、WebLogic Serverの起動スクリプトに多少の更新が必要です。これらの変更は、packコマンドとunpackコマンドを使用して伝播させます。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle Service Busサーバーの起動

Oracle Service Busサーバーは既存のドメインを拡張します。そのため、管理サーバーおよびそれぞれのノード・マネージャはSOAHOST1およびSOAHOST2で稼働しています。

WLS_OSB1管理対象サーバーの起動と検証

WLS_OSB管理対象サーバーの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認し、URLにアクセスしてサーバーのステータスを確認します。

WLS_OSB2管理対象サーバーの起動と検証

WLS_OSBn管理対象サーバーについてのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

Oracle Service Bus用のOracle HTTP Serverの構成

Oracle HTTP Serverを介したアクセスの検証

サーバーのステータスが「実行中」であることを確認します。

ロード・バランサを使用したOracle Service Bus URLの検証

OracleファイルとFTPアダプタの高可用性化

OracleファイルとFTPアダプタのアウトバウンド操作に対する高可用性を、データベースのmutexロック操作を使用して実現します。

Oracle DB、ファイルおよびFTPのアダプタの高可用性化

Oracle Service Bus構成のバックアップ

この後の手順でエラーが発生した場合の即座のリストアを目的として、ドメイン構成をバックアップします。

構成のバックアップ

Oracle Service Busを追加するためのドメインの拡張の前提条件

現在のドメインを拡張する前に、既存のデプロイメントが必要な前提条件を満たしていることを確認します。

  • インストールをバックアップすること。既存のFusion Middlewareホームとドメインをバックアップしていない場合は、今すぐバックアップすることをお薦めします。

    既存のFusion Middlewareホームとドメインをバックアップするには、「SOAエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」を参照してください。

  • 共有記憶域のOracleホームにInfrastructureおよびSOAソフトウェア・バイナリがインストールされ、SOAHOST1とSOAHOST2から使用できることを確認します。

  • Oracle Service BusがSOAと同じドメイン内に構成されている場合は、適切なSOAINFRAスキーマ(wlsbjmsrpDataSourceによって使用されるもの)がすでに使用可能になっていること。OSBが独自のドメイン内に構成されている場合、RCUを実行し、SOAドメインで使用されているSOAINFRAスキーマとは異なるスキーマ接頭辞を使用して、サポートされているデータベースにSOAINFRAスキーマをインストールする必要があります。

  • 前の章の説明どおりに、ノード・マネージャ、管理サーバー、(任意でSOAサーバー)、およびWSMサーバーをすでに構成していること。必要に応じて、サーバー移行、トランザクション・ログ、一貫性など、SOAシステムのその他のすべての構成ステップが完了していること。

  • 各ホスト・コンピュータのシステム・クロックが同期していることを確認します(まだ、確認していない場合)。これを行うには、各クラスタ内のホストでdateコマンドを同時に実行します。

    また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

Oracle Service Busソフトウェアのインストール

OSBインストーラを使用して、エンタープライズ・デプロイメントにOracle Service Busをインストールできます。

Oracle Service Busインストーラの起動

インストール・プログラムを起動するには、次のステップを実行します。

  1. ターゲット・システムSOAHOST1にログインします。
  2. インストール・プログラムをダウンロードしたディレクトリに移動します。
  3. 次のように、Java実行可能ファイルへのパス を入力します。
    export JAVA_HOME=JAVA_HOME
    export PATH=$JAVA_HOME/bin:$PATH
    

    この例では、このガイドで使用するファイル・システムとディレクトリ変数に記載され、エンタープライズ・デプロイメント・ワークブックに入力されている変数の値で、JAVA_HOMEを置き換えます。

  4. 次のコマンドを入力して、インストール・プログラムを起動します。
    java -jar fmw_14.1.2.0.0_osb.jar

    インストール・プログラムが表示されると、インストールを開始する準備ができています。

OSBインストール画面のナビゲート

表13-2は、インストール・プログラムの各画面の説明です。

表13-2 OSBのインストール画面

画面 説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

既存のSOAドメインを拡張する場合は、OSBソフトウェアをSOAソフトウェアがすでにインストールされている既存のOracleホームにインストールします。

OSBを別のドメイン内に構成する場合は、OSBソフトウェアをInfrastructureのOracleホームにインストールします。

インストール・タイプ

この画面を使用して、インストールのタイプを選択し、インストールする製品および機能セットを選択します。

このトポロジの場合は、「Service Bus」を選択します。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合、『Oracle Fusion Middleware Infrastructureのインストールと構成』システム環境の確認ロードマップに関する項で、次のドキュメントのいずれかを参照できます。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを検証できます。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』「サイレント・モードでのOracle Universal Installerの使用」を参照してください。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

他のホスト・コンピュータへのソフトウェアのインストール

SOAHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、SOAHOST2にもソフトウェアをインストールする必要があります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

Oracleホーム(ソフトウェア・バイナリが含まれている)をインストールする場所は、ホストによって異なることに注意してください。ご使用のOracleホーム・ディレクトリの正しい場所を特定するには、「このガイドで使用するファイル・システムとディレクトリ変数」のガイドラインを参照してください。

OSBインストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』インストール・ログ・ファイルの理解に関する項を参照してください。

ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle Service Busを追加すると、次のディレクトリおよびサブディレクトリが追加されます。ls --format=single-columnコマンドを使用して、ディレクトリ構造を確認します。

ls --format=single-colum $ORACLE_HOME/osb/
bin
common
config
doc
financial
L10N
lib
modules
osb
plugins
tools

インストール・プロセスの後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解Oracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

Oracleホームの内容の表示

viewInventoryスクリプトを使用して、Oracleホームの内容を表示することもできます。『Oracle Universal Installerによるソフトウェアのインストール』Oracleホームの内容の表示に関する項を参照してください。

Oracle Service Busを追加するためのSOAまたはInfrastructureドメインの拡張

構成ウィザードでは、Oracle Service Busを追加して、既存のエンタープライズ・デプロイメントのSOAドメインを拡張することができます。拡張を完了するには、一連の追加タスクを実行する必要があります。

ドメインの拡張には、次のタスクが含まれます。

構成ウィザードの起動

ノート:

ドメインの作成の章で、SSLストアのカスタマイズがsetUserOverridesLate.shに追加されました。このファイルに追加されたカスタマイズはドメインの拡張時に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

ただし、ドメイン内のsetDomainEnv.shスクリプトに別のカスタマイズ(カスタム・ライブラリ、サーバー起動用のJAVAコマンドライン・オプション、環境変数など)を追加した場合、それらはドメインの拡張時に構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用されるすべての起動パラメータをsetUserOverridesLate.shファイルに追加します。これにより、拡張全体でそれらが保持されます。

ドメインの構成を開始するには:

  1. ドメインの構成中に、構成のロック、保存、アクティブ化が行われないように、管理サーバーを停止します。
  2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。
    cd $ORACLE_HOME/oracle_common/common/bin
    ./config.sh

Oracle Service Busを含めるドメイン拡張を行うための構成ウィザード画面への移動

このステップでは、「Oracle SOA Suiteを含めるドメインの拡張」で作成したドメインを拡張して、Oracle Service Busソフトウェア・コンポーネントと管理対象サーバーを追加します。

Oracle Service Busを追加して管理サーバーとWSM-PMクラスタのみを含むドメインを拡張する場合のステップは、この項で説明するステップとほぼ同じになりますが、画面に表示される一部のオプション、ライブラリ、コンポーネントは異なる場合があります。

この項の手順に従って、Oracle Service Bus用にドメインを拡張します。

ノート:

この手順では、既存のドメインを拡張することを想定しています。手順に示された内容と要件が合わないときは、適切な内容を選択していることを確認し、その他の詳細について説明されているドキュメントを参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

  • Oracle Service Bus参照構成[osb]

    初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

    • Oracle SOA Suite参照構成[soa] (SOAドメインを拡張する場合)

    • Oracle Enterprise Manager [em]

    • Oracle WSMポリシー・マネージャ[oracle_common]

    • Oracle JRF - [oracle_common]

    • WebLogic Coherenceクラスタ拡張[wlserver]

    Oracle Service Busテンプレートを選択すると、ODSI XQuery 2004コンポーネント[oracle_common]テンプレートも自動的に選択されます。

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』テンプレートに関する項を参照してください。

ノート:

ドメインを拡張してBPMやBAMなど、参照構成をサポートしないコンポーネントを追加する場合(参照構成はSOA、OSB、B2BおよびESSでのみサポートされます)、またはOSBでクラシックSOAドメインを拡張する場合、OSBクラシック・ドメイン・テンプレートを使用する必要があります。

参照構成に含まれる最適化を実装しないクラシックOSBテンプレートは、次のとおりです:

Oracle Service Bus - 14.1.2.0.0 [osb]

B2BまたはSOAのクラシック・ドメインでの後続の拡張は、参照構成テンプレートではなくクラシック拡張テンプレートで行う必要があります。

タスク3   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

  • 「ベンダー」Oracle「ドライバ」*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

  • すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』サービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』データ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、コンポーネント・スキーマとしてOSB JMSレポート・プロバイダを選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」「次へ」の順にクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

表13-3 GridLink Oracle RACデータベース接続の詳細情報の指定

要素 説明と推奨値

サービス名

Oracle RACデータベースのサービス名が適切であることを確認します。たとえば、soaedg.example.comです。

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

ONSリストはデータベースからドライバに自動的に提供されるため、Oracle 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータ・ソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』コンポーネント・スキーマのテスト関する項を参照してください。

タスク7   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で「トポロジ」を選択します。

ノート:

推奨はJDBCストアで、タスク3「高可用性オプションの選択」でも選択されるので、「ファイル・ストア」を構成する必要はありません。

タスク3「高可用性オプションの選択」で「ファイル・ストア」を選択した場合は、ここで「ファイル・ストア」オプションを選択し、ORACLE_RUNTIME/domain_name/OSB_Cluster/jmsの共有場所でそれを構成する必要があります。フェイルオーバー・シナリオでJMSおよびJTAを再開するには、共有の場所が必要です。

タスク8   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle Service Bus用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle Service Bus構成テンプレートによって自動的に作成されました。

次のタスクを実行して、デフォルトのOracle Service Bus管理対象サーバーを変更して2つ目のOracle Service Bus管理対象サーバーを作成します:

  1. デフォルトのOSB管理対象サーバーの名前をWLS_OSB1に変更します。

  2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_OSB2と名前を付けます。

    ヒント:

    ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。
  3. 表13-4の情報を使用して、各管理対象サーバーの残りの列を入力します。

  4. OSBサーバーのサーバー・グループとして「OSB-MGD-SVRS-ONLY」を選択します。デフォルトで選択されているOSB-MGD-SVRS-COMBINEDの選択を解除します。

  5. 「次」をクリックします。

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』管理対象サーバーに関する項を参照してください。

表13-4 構成ウィザードでのOracle Service Bus管理対象サーバーの構成

名前 リスニング・アドレス リスニングの有効化 リスニング・ポート SSLリスニング・ポート SSLポートの有効化 管理ポート サーバー・グループ

WLS_SOA1

SOAHOST1

選択解除

無効

7004

チェック・ボックスを選択

9004

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

選択解除

無効

7004

チェック・ボックスを選択

9004

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

選択解除

無効

7010

チェック・ボックスを選択

9003

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_WSM2

SOAHOST2

選択解除

無効

7010

チェック・ボックスを選択

9003

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_OSB1

SOAHOST1

選択解除

無効

8003

チェック・ボックスを選択

9007

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2

選択解除

無効

8003

チェック・ボックスを選択

9007

OSB-MGD-SVRS-ONLY

WLS_SOA管理対象サーバーは、Oracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合に表示されます。

タスク9   クラスタの構成

このタスクでは、Oracle Service Busソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のosb.example.comにリダイレクトするようになります。

osb.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

  1. 「追加」ボタンをクリックします。

  2. 「クラスタ名」フィールドで、OSB_Clusterを指定します。

  3. 「フロントエンド・ホスト」フィールドでosb.example.comを指定します。

  4. 「フロントエンドHTTPポート」0を指定し、「フロントエンドHTTPSポート」443を指定します。

ノート:

デフォルトでは、クラスタのサーバー・インスタンスはユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』ユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』クラスタに関する項を参照してください。

タスク10   サーバー・テンプレートの割当て

「次へ」をクリックして続行します。

タスク11 動的サーバーの構成

「次へ」をクリックして続行します。

タスク12   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

WLS_SOA管理対象サーバーはOracle Service Busを含めて既存のOracle SOA Suiteドメインを拡張する場合のみ表示されるということに注意してください。

  • SOA_Cluster (SOAドメインを拡張する場合):

    • WLS_SOA1

    • WLS_SOA2

  • WSM-PM_Cluster:

    • WLS_WSM1

    • WLS_WSM2

  • OSB_Cluster:

    • WLS_OSB1

    • WLS_OSB2

「次」をクリックします。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』サーバーのクラスタへの割当てに関する項を参照してください。

タスク13   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルOracle Coherence製品に関する項を参照してください。

タスク14 既存のマシンの検証

次のエントリが表示されることを確認します。

名前 ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

その他のすべてのフィールドはデフォルト値のままにします。

「次」をクリックします。

タスク15   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

  • ADMINHOST:

    • AdminServer

  • SOAHOST1

    • WLS_SOA1 (SOAドメインを拡張する場合)

    • WLS_WSM1

    • WLS_OSB1

  • SOAHOST2:

    • WLS_SOA2 (SOAドメインを拡張する場合)

    • WLS_WSM2

    • WLS_OSB2

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』サーバーのマシンへの割当てに関する項を参照してください。

タスク16   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから拡張するドメインの構成情報の詳細が含まれています。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』構成のサマリーに関する項を参照してください。

タスク17   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるためノートにとってください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogicリモート・コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク18   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

ドメインの拡張を完了したら、「ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播」に進みます。

新しいフロントエンド・アドレスの証明書の更新

この項では、新しいフロントエンド・アドレスの証明書について説明します。

ノート:

ドメイン拡張の証明書について。

OSBおよびWSMサーバーでは同じリスニング・アドレス(異なるポート)が使用されるため、新しい証明書を作成してストアを更新する必要はありません。ただし、OSBクラスタでは、「拡張したドメイン用のWeb層の構成」で信頼できるエンドポイントとして追加される、異なるフロントエンド・アドレスが使用されます。

WebLogic Serverのセキュリティ設定の更新

この項では、WebLogic Serverのセキュリティ設定について説明します。

「WebLogic Serverのセキュリティ設定の更新」で説明されているステップに従って、WLS_OSB1およびWLS_OSB2サーバーのSSL設定を更新します。

ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

OSBインスタンスを含めることでドメインを拡張し、SOAHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびシステムに伝播する必要があります。

更新済ドメインをWEBHOST1およびWEBHOST2システムに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

詳細は、次の項を参照してください。

変更を他のドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

表13-5は、変更をすべてのドメイン・ディレクトリとシステムに伝播するために必要なステップをまとめたものです。

表13-5 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク 説明 詳細情報

SOAHOST1での拡張済ドメインの圧縮

packコマンドを使用して、新しいOSBサーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する場合は、soadomaintemplateExtOSB.jarというテンプレートJARファイルを作成します。

SOAHOST1での拡張済ドメインの圧縮

SOAHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

SOAHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

SOAHOST2でのドメインの解凍

SOAHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

SOAHOST2でのドメインの解凍

WLS_OSB1管理対象サーバーの起動と検証

ドメインの拡張、管理サーバーの再起動、および他のホストへのドメインの伝播を完了したら、次の手順を使用して、WLS_OSB1サーバーを起動し、そのサーバーが正常に構成されているかどうかを検証します。

WLS_OSB1管理対象サーバーの起動
  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    https://ADMINVHN:9002/em

    ノート:

    Web層がすでに構成されている場合は、https://admin.example.com:445/emを使用します。
  2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  4. WLS_OSB1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

    ノート:

    OSBサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、OSBサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。
  5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB1管理対象サーバーが稼働中であることを確認します。
エンタープライズ・デプロイメント管理グループへのMiddlewareAdministratorsロールの追加

WLS_OSB1管理対象サーバーのOracle Service Bus構成を検証する前に、Oracle Service BusのMiddlewareAdministrators管理ロールをエンタープライズ・デプロイメント管理グループ(SOA Administrators)に追加して、外部LDAPディレクトリにIntegrationAdministratorsグループを追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

管理対象サーバーの検証

MiddlewareAdministratorロールをSOA Administratorsグループに追加した後、次のようにWLS_OSB1管理対象サーバー上のOracle Service Busソフトウェアの構成を検証できます。

  1. Webブラウザを使用して次のURLに移動します。
    https://SOAHOST1:8003/sbinspection.wsil

    SOAHOST1を、Enterprise Deployment Workbookに入力されているこの変数の値に置き換えます。管理サーバーと各管理対象サーバーに必要な物理IP (IP)と仮想IP (VIP)アドレスの詳細は、「エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス」を参照してください。

  2. エンタープライズ・デプロイメント管理ユーザー(SOA Administrators)を使用してログインします。

    デフォルトのインストールでは、これにより、Webサービス・コールに対して次のHTTPレスポンスが返されます。

    <ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/"/>
    

WLS_OSB2管理対象サーバーの起動と検証

WLS_OSB2でも、前の項と同様のステップを実行します。

  1. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。
  2. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。
  3. WLS_OSB2管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。
  4. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_OSB2管理対象サーバーが稼働中であることを確認します。WLS_OSB2用の同等のURLにアクセスします。
    https://SOAHOST2:8003/sbinspection.wsil
  5. 次のURLにアクセスし、管理サーバーへのOracle Service Busコンソールのデプロイメントが適切であることを確認します。
    https://ADMINVHN:9002/servicebus/

OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認

Oracle Service Busは、OSB_Cluster内のいずれか1つのWLSサーバー上でのみ稼働するシングルトン・サービスをいくつか使用します。シングルトン・サービスは次のとおりです。
  • アグリゲータ

  • SLAアラート・マネージャ

  • ポーラー・トランスポート(メール、ファイル、FTPおよびSFTPポーラー)

これは、「Service Bus」構成の「グローバル設定」オプションにある「OSBシングルトン・コンポーネント自動移行」というグローバル・プロパティで制御し、Enterprise Managerで公開されます。アクティブ化すると、WebLogic Singleton Frameworkを使用して、OSBシングルトン・サービスのシングルトン動作と自動移行が保証されます。

サーバーまたはサービスの移行と同じように、データベース・リースも「OSBシングルトン・コンポーネント自動移行」が正しく動作するための要件です。「OSBシングルトン・コンポーネント自動移行」チェックボックスで、リース・データソースが自動的に定義されるわけではありません。アプリケーションをシングルトンとしてマークするだけです。

このガイドで推奨されているように、構成ウィザードで「自動サービス移行の有効化」が選択されているかぎり、このOSBグローバル・プロパティとデータベース・リースは、SOAエンタープライズ・デプロイメント・トポロジでデフォルトで選択されます。

構成ウィザードを使用して自動サービス移行が有効化されておらず、後で手動で定義する場合は、「OSBシングルトン・コンポーネント自動移行」も手動で選択する必要があります。

OSBで適切なシングルトン動作を保証するには:

「OSBシングルトン・コンポーネント自動移行」オプションが選択されていることを確認します。

  1. Oracle Fusion Middleware Enterprise Managerにログインします。ブラウザで、次のURLにアクセスします。
    https://ADMINVHN:9002/em
  2. 「SOA」「service-bus (AdminServer)」「グローバル設定」に移動します。

    SOA EDGトポロジの場合は、「OSBシングルトン・コンポーネント自動移行」のプロパティがデフォルトで選択されている必要があります。

次のステップに従って、適切なターゲットが存在していることを確認します。

  1. WebLogicリモート・コンソールにログインします。

  2. 「ツリーの編集」で、「アプリケーション・デプロイメント」をクリックします。

  3. アグリゲータ・シングルトン・マーカー・アプリケーションを探します。表の「ターゲット」列の値がOSB_Clusterであることを確認します。

リース・データソースがOSB_Clusterに定義されていることを確認します。

  1. WebLogicリモート・コンソールにログインします。

  2. 「ツリーの編集」で、「環境」を開き、「クラスタ」をクリックします。

  3. 「OSB_Cluster」をクリックします。

  4. 「移行」タブをクリックします。

  5. 「移行基盤」ドロップダウン・メニューで「データベース」が選択されており、リース・データソース「自動移行に使用するデータ・ソース」が定義されていることを確認します。

    データベース・リースが定義されていない場合は、構成する手順は「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」を参照してください。

ノート:

構成ウィザードで、ドメインを構成する時点では、「高可用性のオプション」画面で「自動サービス移行の有効化」オプションが選択されていると想定しています。このオプションが選択されていない場合、Service Bus Domain Singleton Marker Applicationは直接、クラスタWLS_OSB1の最初のサーバーにターゲット指定され、このサーバーでシングルトン・サービスがホストされます。障害が発生した場合にOSBシングルトン・サービスの自動移行が実行されないため、この方法を推奨されません。

uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

拡張したドメイン用のWeb層の構成

拡張したドメイン内の適切なクラスタにパブリックURLと内部URLの両方に対するリクエストをルーティングするように、Web層のWebサーバー・インスタンスを構成する方法を理解することが重要です。

OHS SSLリスナーに必要な証明書の生成

「Oracle HTTP Serverインスタンスの起動」「OHS SSLリスナーに必要な証明書の生成」で説明されているステップに従って、新しいフロント・アドレスを証明書ストアに追加し、OHSリスナー証明書のSANを更新します。

既存のOHS仮想ホスト証明書を置き換えるかどうか尋ねられたら、「はい」と回答して、OSBクラスタの新しいフロントエンド・アドレスでSANとして更新されるようにします。

Oracle Service Bus用のOracle HTTP Serverの構成

Oracle Service Busは、管理サーバーとOracle Service Busクラスタの両方にデプロイされたアプリケーションを公開します。管理サーバーのOracle Service Busで必要なOracle HTTP Serverマウント・ポイントが、ドメインの作成の章で作成したadmin_vh.confファイルに追加されます。Oracle Service Busクラスタでのアプリケーション・マウントの場合、SOAフロントエンド仮想ホスト名(soa.example.com)を再利用するか、Oracle Service Busの特定の仮想ホスト名(トポロジ・ダイアグラムに反映されたosb.example.comなど)を使用できます。

最初のケースでは、OSBで必要なマウント・ポイントを追加して、既存のOHS仮想ホストのsoa_vh.conf構成ファイルで関連するアプリケーションを公開する必要があります。2番目のケースでは、次のステップを実行します:
  1. osb.example.comの別の仮想ホスト名/仮想サーバーを追加するようにロード・バランサを構成します。詳細は、ロード・バランサ・ベンダーの正式なドキュメントを参照してください。

  2. 新しい仮想ホスト名(osb.example.com)を提供するようにOHSインスタンスを構成します。

新しい仮想ホスト名を提供するようにOHSインスタンスを構成するには、次のステップを実行します:
  1. 「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」「OHS SSLリスナーに必要な証明書の生成」で説明されているステップを繰り返し、新しい仮想サーバー(osb.example.com)で証明書ストアを更新します。
  2. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します:
    cd $WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf
  3. 既存のadmin_vh.confファイルをosb_vh.confファイルにコピーします。これにより、必要なほとんどのSSL構成が転送されます:
    cp admin_vh.conf osb_vh.conf
  4. ファイルを編集し、ListenServerNameVirtualHostSSLWalletおよびLocationディレクティブに必要な値を使用してカスタマイズします(AllowEncodedSlashesはここでは必要ありません):

    ノート:

    リスニング・アドレスの場合は、前の仮想ホスト(admin_vh.confsoainternal_vh.confまたはsoa_vh.conf)で使用されているポートとは異なるポートを指定する必要があります。そうしないと、リスナーが競合します。
    
    ###################################################################
    # Oracle HTTP Server mod_ossl configuration file: ssl.conf        #
     
    ###################################################################
    
    # The Listen directive below has a comment preceding it that is used
    # by tooling which updates the configuration.  Do not delete the comment.
    #[Listen] OHS_SSL_PORT
    Listen WEBHOST1:4446
    ##
    ## SSL Virtual Host Context
    ##
    #[VirtualHost] OHS_SSL_VH
    <VirtualHost WEBHOST1:4446> 
    ServerName osb.example.com:443
    
      <IfModule ossl_module>
    
       #  SSL Engine Switch:
       #  Enable/Disable SSL for this virtual host.
       SSLEngine on
    
       #  Client Authentication (Type):
       #  Client certificate verification type and depth.  Types are
       #  none, optional and require.
       SSLVerifyClient None
    
       #  SSL Protocol Support:
       #  Configure usable SSL/TLS protocol versions.
       SSLProtocol TLSv1.2 TLSv1.3
       
       # Option to prefer the server's cipher preference order 
       SSLHonorCipherOrder on
    
       #  SSL Cipher Suite:
       #  List the ciphers that the client is permitted to negotiate.
       SSLCipherSuite TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
       
       #Path to the wallet
       #SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
       SSLWallet "/u02/oracle/config/keystores/orapki/orapki-vh-WEBHOST1
            
       <FilesMatch "\.(cgi|shtml|phtml|php)$">
          SSLOptions +StdEnvVars
       </FilesMatch>
    
       <Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin">
          SSLOptions +StdEnvVars
       </Directory>
    
       BrowserMatch "MSIE [2-5]" \
             nokeepalive ssl-unclean-shutdown \
             downgrade-1.0 force-response-1.0
    
       # Add the following directive to add HSTS
       <IfModule mod_headers.c>
       Header always set Strict-Transport-Security "max-age=63072000; preload; includeSubDomains"
       </IfModule>
    
    
       <Location /sbinspection.wsil>
           WLSRequest ON
           WebLogicCluster SOAHOST1:8003,SOAHOST2:8003  
       </Location>
    
       <Location /sbresource>
           WLSRequest ON
           WebLogicCluster SOAHOST1:8003,SOAHOST2:8003
       </Location>
    
       <Location /osb>
           WLSRequest ON
           WebLogicCluster SOAHOST1:8003,SOAHOST2:8003
       </Location>
    
       <Location /alsb>
           WLSRequest ON
           WebLogicCluster SOAHOST1:8003,SOAHOST2:8003
       </Location>
    
       <Location /default>
           WLSRequest ON
           WebLogicCluster SOAHOST1:8003,SOAHOST2:8003
       </Location>
    
       </IfModule>
    </VirtualHost>
  5. 次のエントリをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。
    
    <Location /servicebus>
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 9002
    </Location>
    
    <Location /testconsole >
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 9002
    </Location>
  6. WEBHOST2にログインして、osb_vh.confファイルとadmin_vh.confファイルを、2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします:
    $WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf
  7. osb_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。
  8. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

ロード・バランサを使用したOracle Service Bus URLの検証

Oracle Service Bus URLを検証して、ハードウェア・ロード・バランサからHTTP Serverインスタンスを経由してOracle Service Busコンポーネントに至るルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証するには:

  1. WLS_OSB1が稼働している状態で、Oracle WebLogicリモート・コンソールを使用してWLS_OSB2を停止します。
  2. 次のURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。
    https://osb.example.com/sbinspection.wsil
  3. Oracle WebLogicリモート・コンソールでWLS_OSB2を起動します。
  4. Oracle WebLogicリモート・コンソールでWLS_OSB1を停止します。
  5. 同じURLにアクセスし、HTTPレスポンスが「WLS_OSB2管理対象サーバーの起動と検証」のとおりであることを確認します。

    ノート:

    OSB_ClusterにフロントエンドURLが設定されているため、URLへのリクエストはLBRへの再ルーティングになりますが、どのようなケースでも、Oracle HTTP Server内のマウント・ポイントおよびフェイルオーバーの検証には十分です。

  6. ロード・バランサのアドレスを使用してこのURLを検証します。
    https://osb.example.com:443/sbinspection.wsil
    

    https://admin.example.com:445/servicebusも検証できます。

Oracle Service Busの構成後タスク

ドメインにOracle Service Busをインストールして構成した後、次のような構成後タスクを検討します。

Oracle DB、ファイルおよびFTPのアダプタの高可用性化

Oracle SOA SuiteとOracle Service Busは、同じデータベース、ファイルおよびFTP JCAアダプタを使用します。

Oracle SOA Suiteを構成する前に、Oracleリポジトリ作成ユーティリティを使用するときに、これらのアダプタに必要なデータベース・スキーマを作成します。データベース・アダプタの構成は、WebLogic Serverのリソース・レベルでは必要ありません。

その他のアダプタに必要な構成は、「OracleファイルとFTPアダプタの高可用性化」に記載されています。

SOAドメインの拡張としてOracle Service Busを構成する場合は、アダプタに対する構成はすでに行われているため構成に加える必要はありません。

Oracle Service BusをOracle Fusion Middleware Infrastructureドメインの拡張としてデプロイする(Oracle SOA Suiteを含まない)場合は、「OracleファイルとFTPアダプタの高可用性化」で説明されているステップを実行する必要があります。

ポーラー・トランスポートに関する考慮事項

OSBは、本質的にはトランザクションでないネイティブ・ポーラー・トランスポートを提供します。これらのトランスポートは、ソース・ディレクトリ、FTPサーバーまたは電子メール・サーバーで新しいメッセージをポーリングし、処理ペイロードを必要なJMS宛先にプッシュします。電子メール、ファイル、FTPおよびSFTPは、このカテゴリに含まれます。

ポーリングベースのトランスポートでは、管理対象サーバーに固定されたトランスポート・ポーラー・スレッドが使用されます。クラスタ内のすべての管理対象サーバーが関連ペイロードを処理できますが、メッセージをポーリングできるのは1つのサーバーのみです。システムを停止から保護するには、ポーラー・スレッドをアプリケーション・スコープのシングルトンとして構成し、関係するJMS宛先に高い可用性があることが必要です。

ポーラー・トランスポートのシングルトン動作は、他のOSBシングルトン・サービスと同じように、「OSBシングルトン・コンポーネント自動移行」のプロパティによって制御されます。

選択すると、ポーラー用のアプリケーション・スコープのシングルトンがクラスタにデプロイされます。サーバーまたはサービスの移行と同じように、リースも「OSBシングルトン・コンポーネント自動移行」が正しく動作するための要件です。

ノート:

このチェックボックスで、リース・データソースが自動的に定義されるわけではありません。アプリケーションをシングルトンとしてマークするだけです。

このガイドで推奨されているように、構成ウィザードで「自動サービス移行の有効化」が選択されている場合、SOAエンタープライズ・デプロイメント・トポロジのプロパティ「OSBシングルトン・コンポーネント自動移行」および「データベース・リース」がデフォルトで選択されます。

リース・データソースがまだ構成されていないときに、このチェックボックスを選択する場合は、必ずリース・データソースを構成してください。「OSBシングルトン・サービスのターゲット指定が適切であるかどうかの確認」を参照してください。

ポーラー・トランスポートが、「OSBシングルトン・コンポーネント自動移行」でアプリケーション・スコープのシングルトンとして構成されているかどうかは、次のステップで確認できます。

  1. WebLogicリモート・コンソールにログインします。

  2. 「ツリーの編集」で、「デプロイメント」をクリックします。

  3. 左側にある「ドメイン構造」ツリーで、「デプロイメント」をクリックします。

  4. トランスポート・ポーラーにシングルトン・アプリケーションがデプロイされていることを確認します。例: SB_FILE_Proxy_*

  5. 表の「ターゲット」列の値がOSB_Clusterであることを確認します。

このトランスポート・サービスを高可用性で利用するには、永続化するJMS宛先(ペイロード処理のために使用される)を障害が保護する必要があります。SOAエンタープライズ・デプロイメント・トポロジでは、この保護は自動サービス移行機能によって提供されます。

エンタープライズ・デプロイメント用の個別のOracle Service Busサービスの構成

IBM WebSphereのMQ接続リソースとMQトランスポートをOracle Service Bus内で使用するには、MQクライアント・ライブラリをクラスパスに追加する必要があります。

必要なMQライブラリをドメイン・ホーム・ディレクトリの次の場所にコピーするのも1つの方法です。

DOMAIN_HOME/lib

これは、カスタム・アサーションおよびJBoss統合サービスの場合にもあてはまります。

  • JBoss初期コンテキスト・ファクトリ・クラスを使用している場合は、クラスおよび依存クラスをDOMAIN_HOME/libディレクトリに含めてください。

  • 同様に、カスタム・アサーションの場合は、アサーションに必要なJARファイルを作成し、DOMAIN_HOME/libディレクトリにそのJARファイルを追加します。

さらに、エンタープライズ・デプロイメントでこれらのサービスを使用するには、必要なライブラリを管理サーバー・ドメイン・ホーム(ASERVER_HOME/lib)と管理対象サーバー・ドメイン・ホーム(MSERVER_HOME/lib)に追加する必要があります。

Oracle Service Busのサービスの構成およびデプロイの詳細は、『Oracle Fusion Middleware Oracle Service Busでのサービスの開発』Oracle Service Busコンソールのスタート・ガイドを参照してください。

接続文字列の適切なTNS別名への置換

Oracleでは、複数の接続プール間で長いJDBC文字列を繰り返すのではなく、FMWコンポーネントで使用される接続文字列でTNS別名を使用することをお薦めします。

データソースでTNS別名を使用する方法の詳細は、「エンタープライズ・デプロイメントの共通の構成および管理タスク」の章の「接続文字列でのTNS別名の使用」を参照してください。

構成のバックアップ

Oracleのベスト・プラクティスとしては、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。