| Oracle Application Serverエンタープライズ・デプロイメント・ガイド 10gリリース3（10.1.3.5.0） B57230-01 |
|
 戻る |
 次へ |
クラスタベースの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=256M
ファイルを保存して閉じ、次のコマンドを使用して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開発者ガイド』の「エンドポイント・プロパティの追加方法」を参照してください。
