クラスタベースのBPELデプロイメントのベスト・プラクティス
単独のアダプタに対するOracle Enterprise Service Busの構成
一般的な管理操作を表5-1に示します。コンソールまたはコマンドライン・ツールを使用して、システムを監視および管理できます。
表5-1 システム管理タスク、ツールおよび関連ドキュメント
障害時リカバリを有効化する手順と推奨事項の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
BPELクラスタにアプリケーションをデプロイするときは、次の各手順を遵守する必要があります。
すべてのコンピュータを1台ずつ起動します。1つのコンピュータが完全に起動されてから、次のコンピュータを起動します。
EJBバインディング用のクライアント・インタフェースを、各コンピュータのsystem/classesディレクトリにコピーします。次にBPEL Process Managerを再起動して、それらのクラスをロードします。
ビルドおよびデプロイ対象のアプリケーションで、bpel.xml
ファイルのwsdlLocation
がローカル・ファイル・システム上のwsdlファイルを指すように定義し、wsdlRuntimeLocationが実行時にwsdlファイルを指すようにします。定義例は、ORACLE_HOME/bpel/samples/demos/LoanFlow/LoanDemo/bpel/bpel.xml
を参照してください。
ORACLE_HOME/bpel/samples/demos/LoanDemo
ディレクトリにあるサンプル・アプリケーションのLoanFlowを使用して、デプロイ後にBPELプロセスが動作することを検証します。
BPELのセキュア化およびセキュアなBPELプロセスの起動の詳細は、リリース10g(10.1.3.1)の『Oracle BPEL Process Manager管理者ガイド』の第1章「Oracle BPEL Process Managerのセキュリティ」を参照してください。
BPELコンソールでタスクを実行中に、次のエラーが発生することがあります。
500 Internal Server Error
java.lang.OutOfMemoryError: PermGen space
このエラーを解決するには、MaxPermSizeパラメータを使用して、PermGen領域(静的クラスのロードに使用される)に割り当てられているメモリーを増やします。次の手順に従って、APPHOST1およびAPPHOST2のOracle Application Serverインスタンスで、MaxPermSize
パラメータを設定します。
ORACLE_HOME/opmn/conf/opmn.xml
ファイルを開き、MaxPermSize
パラメータ(例5-1では太字で表示)があるかどうかを調べます。パラメータをopmn.xml
に追加する必要がある場合があります。パラメータをOC4J_SOA
コンテナの起動用に追加する必要があります。
例5-1 opmn.xmlのMaxPermSizeパラメータ
...
<category id="start-parameters">
<data id="java-options" value="-Xrs -server
-XX:MaxPermSize=128M -ms512M -mx1024M -XX:AppendRatio=3
-Djava.security.policy=$ORACLE_HOME/j2ee/Admin/config/java2.policy
-Djava.awt.headless=true -Dhttp.webdir.enable=false"/>
</category>
<category id="stop-parameters">
<data id="java-options"
value="-Djava.security.policy=$ORACLE_HOME/j2ee/Admin/config/java2.policy
-Djava.awt.headless=true -Dhttp.webdir.enable=false"/>
...
次の例に示すように、この値を大きくするか、またはすべてのOC4Jコンテナに対してMaxPermSize
パラメータを追加します。
-XX:MaxPermSize=
256
M
ファイルを保存して閉じ、次のコマンドを使用してOC4Jインスタンスを再起動します。
opmnctl reload
opmnctl stopproc process-type=OC4J_SOA
opmnctl startproc process-type=OC4J_SOA
Oracle Enterprise Service Busがクラスタ全体に対してデプロイされている場合、ESBフローが単独のアダプタ(ファイル・アダプタなど)によってトリガーされると、クラスタ化されたESBの1つのインスタンスのみがファイルを使用して1つのプロセスを起動します。クラスタ化された環境でのアダプタによる単独の動作は、ESBのインバウンド・エンドポイント・プロパティclusterGroupId
によって施行されます。この機能はファイル・システムなどのエンドポイント用に設計されており、SQLデータベースのようにソリッドなロック・メカニズムをネイティブにサポートしていません。
このアダプタによる単独の制御では、ESBおよびBPELのインスタンスが、第3.12項「APPHOST1およびAPPHOST2のBPELインスタンスのクラスタの構成」で説明しているように、ORACLE_HOME
/bpel/system/config/jgroup-protocol.xml
ファイルのmcast-addr
およびmcast-port
値から取得される同じJGroup構成に属している必要があります。
この動作を構成するには、特定のクラスタ・グループにJ2EE Connector Architecture(JCA)エンドポイントのアクティブ化(通常は、同じディレクトリなど、同じ非トランザクション・エンドポイントに対するアクティブ化)の組合せを割り当てます。常にアクティブにできるアクティブ化は1つのみです。次に例を示します。
クラスタ1、インスタンス1:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
クラスタ1、インスタンス2:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
クラスタ1、インスタンス3:
<service name="InboundServiceX" ...>
...
<endpointProperties>
<property name="clusterGroupId" value="cluster1"/>
</endpointProperties>
</service>
[...]
この構成では、同じクラスタ・グループ(この例ではクラスタ1)に属するすべてのJCAアダプタ・エンドポイントのアクティブ化において、常に1つのアクティブ化対象のみがアクティブになり(プライマリのアクティブ化)、積極的にエンドポイント(ファイル・システム)に対してポーリングを実行します。他のアクティブ化対象はホット・スタンバイ状態、つまりセカンダリなアクティブ化対象となります。たとえば、プライマリのアクティブ化対象であるインスタンス2が停止すると、インスタンス1およびインスタンス3がただちにこれを検出し、インスタンス1またはインスタンス3がアクティブ化を再開します(つまりプライマリのアクティブ化対象となります)。インスタンス2の操作が回復した後にインスタンス1またはインスタンス3が停止すると、インスタンス2が再度プライマリのアクティブ化対象となる可能性があります。
詳細は、『Oracle SOA Suite開発者ガイド』の「エンドポイント・プロパティの追加方法」を参照してください。