この章では、カスタム・トランスポート・プロバイダをパッケージ化しデプロイする方法について説明します。内容は以下のとおりです。
カスタム・トランスポート・プロバイダを、完全に独立したEARファイルとしてパッケージ化する必要があります。そうすることにより、Oracle Service Bus Kernel EARおよびその他のOracle Service Bus関連のアプリケーションと共にデプロイできます。
ヒント: サンプル・ソケット・トランスポート・プロバイダの例では、トランスポート・プロバイダを構成およびデプロイする方法を示しています。詳細は、第42章「サンプル・ソケット・トランスポート・プロバイダ」を参照してください。 |
各トランスポート・プロバイダは、次の2つの異なる部分で構成されます。
構成 - トランスポート・プロバイダの構成部分は、エンドポイントをトランスポート・プロバイダに登録するために、Oracle Service Busコンソールによって使用されます。この構成動作は、UIインタフェースの実装によって実行されます。41.6項「ユーザー・インタフェースの構成」を参照してください。
ランタイム - トランスポート・プロバイダのランタイム部分は、メッセージを送受信するビジネス・ロジックを実装します。
ヒント: 構成部分とランタイム部分が別のデプロイメント・ユニットに配置されるようにトランスポート・プロバイダをパッケージ化することをお薦めします。これにより、クラスタ・デプロイメントが容易になります。詳細は、43.4項「クラスタへのデプロイ」を参照してください。38.4項「トランスポート・プロバイダのコンポーネント」も参照してください。 |
この項では、トランスポート・プロバイダをデプロイする方法について説明します。
ヒント: Oracle Service Busへのアプリケーションのデプロイの詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。 |
トランスポート・プロバイダのデプロイ可能なEARファイルを作成したら、Oracle Service Busドメインにデプロイする必要があります。EARは、以下のいずれかの方法でデプロイすることができます。
プログラムを実行します(WebLogic Deployment Manager JSR-88 APIを使用)。
Oracle WebLogic Server管理コンソールを使用します。
例43-1のようなエントリをOracle Service Busドメインのconfig.xml
ファイルに追加します。
例43-1 アプリケーション・デプロイメント・エントリ
<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
クラスが含まれています。これは、OSB_ORACLE_HOME/samples/servicebus/socket-transport/src/com/bea/alsb/transports/sockにあります。
ApplicationLifecycleListener
を拡張する際は、必ず拡張クラスをMETA-INF/weblogic-application.xmlに登録してください。サンプル・ソケット・トランスポートは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/META-INF/weblogic-application.xmlで、次のApplicationListener
クラスのエントリを提供しています。
<weblogic-application> <listener> <!-- This class gives callbacks for the deployment lifecycle and socket transport is registered with ALSB whenever the application is started. --> <listener-class>com.bea.alsb.transports.sock.ApplicationListener </listener-class> </listener> </weblogic-application>
Oracle Service Busに登録されたトランスポート・プロバイダのアンデプロイメントまたは登録取消しはサポートされません。
トランスポート・プロバイダは、Oracle Service Busがデプロイされているすべてのサーバーとクラスタにデプロイする必要があります。つまり、Oracle Service Busが管理サーバーのみにデプロイされている場合(管理サーバーには常にデプロイされる)、トランスポート・プロバイダを管理サーバーにデプロイする必要があります。Oracle Service Busが管理サーバーと管理対象サーバーのトポロジにデプロイされている場合は、トランスポート・プロバイダを管理サーバーと特定の管理対象サーバーにデプロイする必要があります。さらに、Oracle Service Busがクラスタにデプロイされている場合は、トランスポート・プロバイダを管理サーバーとクラスタにデプロイする必要があります。Oracle Service Busは、ドメインのトポロジに関係なく必ず管理サーバーにデプロイされることに注意してください。
トランスポート・プロバイダのEARファイルにあるアプリケーション・コードは、トランスポートがどこにデプロイされているか(管理サーバーまたは管理対象サーバー)を動的に認識して、管理サーバーでは構成動作、管理対象サーバーではランタイム動作のみを行う必要があります。
たとえば、some_transport.ear
内の初期化疑似コードで、次のロジックを使用し、プロバイダの構成部分またはランタイム部分をアクティブにするかどうかを決定できます。
protected SomeTransportProvider() throws TransportException { . . . some other initialization code . . . if (!isRuntimeEnabled) _engine = new RuntimeEngine(. . .); }
この場合、RuntimeEngineクラスのインスタンスの作成はランタイム動作であるため、マルチサーバー・ドメインでは管理対象ノードのみ、シングル・サーバー・ドメインでは管理ノードでのみ実行される必要があります。
さらに、すでに説明したように、クラスタ環境では、TransportProvider.createEndPoint()
およびdeleteEndPoint()
は、クラスタ内の管理対象サーバーだけでなく管理サーバー上でも呼び出されます(WLS HTTPルーター/フロントエンド・ホストを除く)。一部のトランスポート・プロバイダ(HTTPなど)では、指定した構成を持つエンドポイントが存在するという事実の登録以外を行わないように選択できます。通常、トランスポート・プロバイダは、createEndPoint()
またはdeleteEndPoint()
が管理サーバーと管理対象サーバーのどちらで呼び出されたを確認し、適切な動作を決定する必要があります。