|
|
この章では、カスタム転送プロバイダをパッケージ化しデプロイする方法について説明します。内容は以下のとおりです。
カスタム転送プロバイダを、完全に独立した EAR ファイルとしてパッケージ化する必要があります。そうすることにより、Oracle Service Bus Kernel EAR およびその他の Oracle Service Bus 関連のアプリケーションと共にデプロイできます。
| ヒント : | サンプル ソケット転送プロバイダの例では、転送プロバイダを構成およびデプロイする方法を示しています。詳細については、「サンプル ソケット転送プロバイダ」を参照してください。 |
各転送プロバイダは、次の 2 つの異なる部分で構成されます。
| ヒント : | コンフィグレーション部分と実行時部分が別のデプロイメント ユニットに配置されるように転送プロバイダをパッケージ化することをお勧めします。これにより、クラスタ デプロイメントが容易になります。詳細については、「クラスタへのデプロイ」を参照してください。「転送プロバイダのコンポーネント」も参照してください。 |
この節では、転送プロバイダをデプロイする方法について説明します。
| ヒント : | Oracle Service Bus にアプリケーションをデプロイする方法の詳細については、Oracle Service Bus の『デプロイメント ガイド』を参照してください。 |
転送プロバイダのデプロイ可能な EAR ファイルを作成したら、Oracle Service Bus ドメインにデプロイする必要があります。EAR は、以下のいずれかの方法でデプロイすることができます。
config.xml ファイルに追加する。 <app-deployment>
<name>My Transport Provider</name>
<target>AdminServer, myCluster</target>
<module-type>ear</module-type>
<source-path>$USER_INSTALL_DIR$/servicebus/lib/mytransport.ear</source-path>
<deployment-order>1234</deployment-order>
</app-deployment>
| 注意 : | 転送プロバイダの EAR ファイルのデプロイ順序は、転送プロバイダの前にすべての Oracle Service Bus Kernel EAR がデプロイされるようにする必要があります。 |
サーバの再起動時に、デプロイした転送がすぐにサービス要求の処理を開始できるようにすることが可能です。転送をすぐに使用できるようにするには、weblogic.application.ApplicationLifecycleListener クラスを拡張し、preStart() メソッドを使用して、TransportManager.registerProvider() によって転送を登録します。
サンプル ソケット転送には、参考として使用できる ApplicationListener クラスが含まれています。これは、ALSB_HOME/samples/servicebus/socket-transport/src/com/bea/alsb/transports/sock にあります。
ApplicationLifecycleListener を拡張する際は、必ず拡張クラスを META-INF/weblogic-application.xml に登録してください。サンプル ソケット転送は、ALSB_HOME/samples/servicebus/sample-transport/META-INF/weblogic-application.xml で、以下の ApplicationListener クラスのエントリを提供しています。
<weblogic-application>
<listener>
<!-- このクラスは、デプロイメント ライフサイクルのコールバックを提供します。
ソケット転送は、アプリケーションが起動されるたびに ALSB に登録されます。
-->
<listener-class>com.bea.alsb.transports.sock.ApplicationListener
</listener-class>
</listener>
</weblogic-application>
Oracle Service Bus に登録された転送プロバイダのアンデプロイメントまたは登録取り消しはサポートされません。
クラスタ環境では、Oracle Service Bus ドメイン管理サーバにデプロイする必要があるのは、転送プロバイダのコンフィグレーション部分のみです。実行時部分は、ロードバランシングおよびフェイルオーバ用の管理対象サーバにのみデプロイする必要があります。
転送プロバイダの実行時部分とコンフィグレーション部分を単一のデプロイメント ユニットにデプロイする場合、結果の EAR ファイルは、それがデプロイされる場所 (管理サーバまたは管理対象サーバ) を認識し、管理サーバではコンフィグレーション動作のみを、また管理対象サーバでは実行時動作のみを行う必要があります。
たとえば、以下のように、some_transport.ear 内の初期化疑似コードで、このロジックを使用し、プロバイダのコンフィグレーション部分または実行時部分をアクティブにするかどうかを決定できます。
protected SomeTransportProvider() throws TransportException {
… some other initialization code …
if (!isAdminServer || !clusterExists)
_engine = new RuntimeEngine(…);
}
この場合、RuntimeEngine クラスのインスタンスの作成は実行時動作であり、シングル サーバ ドメインの管理対象ノードまたは管理ノードでのみ実行される必要があります。
さらに、すでに説明したように、クラスタ環境では、TransportProvider.createEndPoint() および deleteEndPoint() は、クラスタ内の管理対象サーバだけでなく管理サーバ上でも呼び出されます (WLS HTTP ルータ/フロントエンド ホストを除く)。一部の転送プロバイダでは、指定したコンフィグレーション (HTTP など) を持つエンドポイントが存在するという事実の登録以外を行わないように選択できます。通常、転送プロバイダは、createEndPoint() または deleteEndPoint() が管理サーバと管理対象サーバのどちらで呼び出されたを確認し、適切な動作を決定する必要があります。
|