| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、Service Busで使用するためにカスタム・トランスポート・プロバイダをパッケージ化してデプロイする方法について説明します。
この章の内容は次のとおりです。
カスタム・トランスポート・プロバイダには、それぞれEARファイルとJARファイルの2つのファイルが必要です。3番目のファイルであるトランスポート・プラグインは、JDeveloperでカスタム・トランスポート・プロバイダを使用するために必要です。カスタム・トランスポート・プロバイダを、トランスポートを定義する自己完結型のJARファイルおよびWebLogic ServerにデプロイできるEARファイルとしてパッケージ化する必要があります。EARファイルは、JARファイルを含むことができ、また、JARファイルをEARファイルが依存するライブラリにすることもできます。後者の方法を使用すると、JARファイルの1つのコピーを維持することのみが必要になります。
Service Busでトランスポートを使用可能にするには、/MW_HOME/osb/lib/transportsにEARファイルをインストールし、オプションでJARファイルをインストールします。通常、EARファイルとJARファイルは両方とも、Service Busトランスポート用にこのディレクトリに配置されますが、JARファイルをここに配置する必要はありません。オフライン・ツールでカスタム・トランスポート・プロバイダを使用可能にするために作成するプラグイン・ファイルはJARファイルを指します。
Oracle Service Busコンソールおよびランタイムでトランスポートを使用できるようにするには、EARファイルをService Bus Kernel EARファイルおよびその他のService Bus関連アプリケーションとともにサーバーにデプロイします。サンプル・ソケット・トランスポート・プロバイダの例では、トランスポート・プロバイダを構成およびデプロイする方法を示しています。詳細は、「サンプル・ソケット・トランスポート・プロバイダの作成」を参照してください。
各トランスポート・プロバイダは、次の2つの異なるコンポーネントで構成されます。
構成: トランスポート・プロバイダの構成部分は、エンドポイントをトランスポート・プロバイダに登録するために、Oracle Service Busコンソールによって使用されます。この構成動作は、ユーザー・インタフェースの実装によって実行されます。詳細は、「ユーザー・インタフェースの構成」を参照してください。
ランタイム: トランスポート・プロバイダの実行時部分は、メッセージを送受信するビジネス・ロジックを実装します。
構成部分と実行時部分が別のデプロイメント・ユニットに配置されるようにトランスポート・プロバイダをパッケージ化することをお薦めします。これにより、クラスタ・デプロイメントが容易になります。詳細は、「クラスタへのデプロイ」および「トランスポート・プロバイダのコンポーネント」を参照してください。
トランスポートJARファイルには、次のリソースを含める必要があります。
トランスポート・プラグインに関する重要な情報を含むMANIFEST.MFファイル。参考として、サンプル・ソケット・トランスポートのMANIFEST.MFを使用してください。
トランスポート・プロバイダを構成するTransportConfig.xmlファイル。参考として、サンプル・ソケット・トランスポートのプラグインを使用してください。「ステップ5. TransportProviderConfiguration XMLBeanの定義」を参照してください。
使用するトランスポート実装を含むコンパイル済Javaクラス。
コンパイル済XML Beanが生成したクラス。
(オプション)オンライン・ヘルプを提供するためのリソース。
ここでは、カスタム・トランスポート・プロバイダのJARファイルおよびEARファイルの構造を説明します。この項でリストするいずれかのファイルの例を表示するには、「サンプルのビルドとデプロイ」の説明に従ってサンプル・ソケット・トランスポート・プロバイダをビルドします。すべてのパッケージ化されたアーティファクトが表示できるようになります。サンプルのbuild.xmlファイルを確認して、カスタム・トランスポート・プロバイダのコンパイルおよびデプロイの方法の例を表示することも可能です。
トランスポート・プロバイダをJARファイルにパッケージ化して、トランスポートをポータブルにします。トランスポート・プロバイダをパッケージ化するには、次のガイドラインに従います。
プラグインJARを構築するには、カスタム・トランスポートの名前に「transport」を付加してJARファイル名を作成します。たとえば、サンプル・ソケット・トランスポートJARファイルの名前はsock_transport.jarになります。
図42-1に示すように、次のディレクトリ構造でファイルをパッケージ化します。
/com (トランスポート・クラスおよびリソース)
/help
トランスポートのヘルプを提供する場合、「カスタム・トランスポートのヘルプの作成」の説明に従って、ヘルプ・リソースの/helpディレクトリを含めてください。
/META-INF/MANIFEST.MF
/schemaorg_apache_xmlbeans (XML Beanクラスおよびリソース)
TransportConfig.xml (XMLBeanトランスポート・プロバイダ構成。詳細は「ステップ5. TransportProviderConfiguration XMLBeanの定義」を参照)
次の図は、サンプル・ソケット・トランスポート・プロバイダのJARディレクトリを示します。
プラグインのパッケージ化の例を参照するには、「サンプル・ソケット・トランスポート・プロバイダの作成」の説明に従ってサンプル・ソケット・トランスポートをビルドします。生成されたsock_transport.jarおよびsock_transport.earを参照してください。
EARファイルでカスタム・トランスポート・プロバイダの実行時コンポーネントをパッケージ化します。これは、WebLogic Serverにデプロイできます。このファイルは、JARファイルを含むかまたはライブラリとしてJARファイルに依存できます。EARファイルの典型的なパッケージ化構造は次のものを含みます。
APP-INF/lib/name-transport.jar
META-INF/MANIFEST.FMおよび追加のスキーマ・ファイル。
パッケージ化済ヘルプ・ファイルなど、追加のWebアプリケーション・ファイル
JDeveloperが新しいトランスポートを取得するためには、トランスポート・プロバイダの実装、トランスポートID、ヘルプID (ある場合)およびトランスポートに必要な追加のライブラリを記述しているプラグイン・ファイルを作成する必要があります。JDeveloperでトランスポートを使用する計画がない場合、このファイルを作成する必要はありません。プラグイン・ファイルの命名規則は、transport-transport_name.xmlです。
次の形式を使用して、プラグイン登録ファイルを作成します。
<plugin xmlns="http://www.bea.com/alsb/offline/extensions">
<transport
class="transport_provider_class"
id="transport_id"
helpId="ID_to_access_help"/>
<libraries>
<library name='name_and_path_for_transport_jar'/>
</libraries>
</plugin>
次の例では、Service Busでインストールされたサンプル・ソケット・トランスポート・プロバイダに付属しているサンプル・プラグイン・ファイルを示します。
例 - サンプル・ソケット・トランスポート・プロバイダのプラグイン・ファイル
<plugin xmlns="http://www.bea.com/alsb/offline/extensions">
<transport
class="com.bea.alsb.transports.sock.SocketTransportProviderFactory"
id="socket"
helpId="contexts_socketTransport"/>
<libraries>
<library name='lib/transports/sock_transport.jar'/>
</libraries><
</plugin>
トランスポート・プロバイダのEARファイル、JARファイル(およびオプションでJDeveloperのプラグイン)を作成したら、これらのファイルをJDeveloperのインストールに追加してJDeveloperで取得できるようにする必要があります。
生成されたEARファイルおよびJARファイルを/MW_HOME/osb/lib/transportsにコピーします。
プラグイン登録ファイルを/MW_HOME/osb/config/pluginsにコピーします。
トランスポート・プロバイダのデプロイ可能なEARファイルを作成したら、Service Busドメインにデプロイする必要があります。次の方法のどれでもお好みの方法でEARファイルをデプロイできます。
プログラムを実行します(WebLogic Deployment Manager JSR-88 APIを使用)。
Oracle WebLogic Server管理コンソールを使用します。
Service Busドメインconfig.xmlファイルに次の例のようなエントリを追加します
例 - アプリケーション・デプロイメント・エントリ
<app-deployment>
<name>My Transport Provider</name>
<target>AdminServer, myCluster</target>
<module-type>ear</module-type>
<source-path>$MW_HOME$/osb/lib/transports/mytransport.ear</source-path>
<deployment-order>6</deployment-order>
</app-deployment>
注意:
トランスポート・プロバイダのEARファイルのデプロイ順序は、トランスポート・プロバイダの前にすべてのService Bus Kernel EARがデプロイされるようにする必要があります。
サーバーの再起動時に、デプロイしたトランスポートがすぐにサービス・リクエストの処理を開始できるようにする必要があります。トランスポートをすぐに使用できるようにするには、weblogic.application.ApplicationLifecycleListenerクラスを拡張し、preStart()メソッドを使用して、TransportManager.registerProvider()によってトランスポートを登録します。
実装例は、OSB_ORACLE_HOME/samples/servicebus/sample-transport/src/com/bea/alsb/transports/sockにあるサンプル・ソケット・トランスポートに付属しているApplicationListenerクラスを参照してください。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>
トランスポート・プロバイダは、Service Busがデプロイされているすべてのサーバーとクラスタにデプロイする必要があります。つまり、Service Busが(常にデプロイ先である)管理サーバーにのみデプロイされる場合、トランスポート・プロバイダを管理サーバーにデプロイする必要があります。Service Busが管理サーバーのトポロジおよび管理対象サーバーのトポロジにデプロイされる場合、トランスポート・プロバイダを管理サーバーおよびその該当の管理対象サーバーにデプロイする必要があります。Service Busがクラスタにデプロイされる場合、トランスポート・プロバイダを管理サーバーおよびクラスタにデプロイする必要があります。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()が管理サーバーと管理対象サーバーのどちらで呼び出されたかを確認して適切な動作を決定する必要があります。
