![]() ![]() ![]() ![]() |
AquaLogic Service Bus は、EJB 転送を使用して、WebLogic Server 8.1、9.0、9.1 または 9.2 にデプロイされているステートレス セッション Bean のネイティブな RMI 呼び出しをサポートします。これにより、トランザクション対応の、安全な通信が可能になります。EJB 転送は、AquaLogic Service Bus から EJB を Web サービスとしてエクスポーズする際にも利用できます。
AquaLogic Service Bus でビジネス サービスを設計し、EJB 転送を使用できます。EJB 転送は、AquaLogic Service Bus コンフィグレーション、管理、モニタ、およびテスト コンソールと完全に統合されています。EJB 転送を使用して構築されたビジネス サービスは、パブリッシュ、サービス コールアウト、およびサービスの呼び出しに使用できます。EJB 転送を使用するプロキシ サービスは作成できません。
EJB は、ツールを使用したり、EJB をホストするアプリケーション サーバのレガシー コードを変更したりすることなく、Web サービスとしてエクスポーズできます。
AquaLogic Service Bus にビジネス サービスをコンフィグレーションする前に、JNDI プロバイダ リソースおよびクライアント JAR リソースを登録する必要があります。この節では、AquaLogic Service Bus での EJB 転送ビジネス サービスの設計とコンフィグレーションの方法について説明します。内容は以下のとおりです。
JNDI プロバイダ リソースにより、リモート WebLogic 8.1 または 9.x ドメインの JNDI ツリーにバインドされている EJB スタブを取得するために使用される通信プロトコルやセキュリティ資格を指定できます (JNDI ツリーの設定方法の詳細については、BEA WebLogic Server ドキュメントの『WebLogic JNDI プログラマーズ ガイド』を参照)。
通常、ターゲット EJB は AquaLogic Service Bus と同じドメイン内にはありません。この場合、JNDI プロバイダ リソースを登録する必要があります。EJB が同じドメイン内にある場合、プロバイダを定義して資格を指定し、スタブ キャッシングを利用できます。ただし、この場合、省略可能です。
JNDI プロバイダには、リモート接続と EJB スタブのための高性能なキャッシング メカニズムがあります。AquaLogic Service Bus から WebLogic Server ドメインへの推奨される通信プロトコルは、t3
または t3s
です。メッセージがファイア ウォールを通過する必要がある場合は、HTTP トンネリングを使用できます。HTTP トンネリングの詳細については、「HTTP トンネリングおよび暗号化された通信」を参照してください。
注意 : |
AquaLogic Service Bus への JNDI プロバイダ リソースの登録とコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「システムの管理」にある「JNDI プロバイダの追加」を参照してください。
クライアント JAR を、リソースとして AquaLogic Service Bus に登録する必要があります。その結果、AquaLogic Service Bus コンフィグレーションの一部となり、プロジェクトからエクスポートすることもプロジェクトにインポートすることもできます。
EJB クライアント JAR ファイルには、AquaLogic Service Bus が EJB にアクセスするために必要なインタフェースとクラスが含まれている必要があります。これには、リモート インタフェースとホーム インタフェース、およびメソッドのパラメータ型またはアプリケーションの例外など、クライアントがエクスポーズされる依存型が含まれます。ビジネス サービスにコンバータ クラスが必要な場合は、それらも JAR ファイルに含める必要があります。コンバータ クラスについては、「Converter クラス」を参照してください。
EJB クライアント JAR を使用するときは、以下のガイドラインを考慮してください。
AquaLogic Service Bus への JAR リソースの登録とコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「JAR」にある「JAR の追加」を参照してください。
EJB メソッドが保護されている場合、呼び出しに使用する資格を指定できます。多くの場合、これらの資格は JNDI プロバイダで使用される資格とは異なります。サービス アカウントの追加と使用については、『AquaLogic Service Bus Console の使い方』の「サービス アカウント」を参照してください。
EJB の JNDI 名がわからない場合は、EJB サーバの JNDI ツリーを参照できます。WebLogic Server Administration Console を使用した JNDI ツリーの参照方法については、以下を参照してください。
この節では、EJB 転送を使用するビジネス サービスの作成について説明します。内容は以下のとおりです。
EJB ビジネス サービスは「転送型付きのサービス」です。つまり、転送のタイプはサービスのコンフィグレーションによって決まります。現時点では、EJB 転送はこの転送のタイプのみとなります。AquaLogic Service Bus の転送 SDK を使用して、その他の転送を追加できます。
ejb:
provider
:
jndi_name
EJB がローカルにデプロイされている場合、JNDI プロバイダの名前を提供する必要はありません。この場合、URI の形式は以下のようになります。
ejb::
jndi_name
ビジネス サービスの全般的なコンフィグレーションが完了したら、ホーム インタフェースやリモート インタフェースなどの EJB 転送固有の情報を指定します。AquaLogic Service Bus Console の [EJB 転送コンフィグレーション] ページを次の図に示します。
EJB メソッドが保護されており、「サービス アカウントの作成 (省略可能)」の手順でサービス アカウントを定義している場合は、[参照] をクリックして適切なサービス アカウントを検索します。
EJB 転送でのトランザクション処理については、「トランザクション処理、再試行、およびエラー処理」を参照してください。
クライアント JAR を選択すると、ホーム インタフェースのリストがこのページに表示されます。
リモート インタフェースは、ホーム インタフェースから自動的に推測され、コンフィグレーション ページが更新されます。[リモート インタフェース] フィールドが入力され、その他のオプションが提供されます。これにより、サービスのインタフェースおよびこのビジネス サービスのコンフィグレーションの終了時に生成される WSDL を制御できます。
EJB ビジネス サービスは転送型付きのサービスです。つまり、転送のタイプはサービスのコンフィグレーションによって決まります。
EJB ビジネス サービスのタイプは SOAP XML サービスと同等です。つまり、EJB ビジネス サービスを他のすべての SOAP XML ビジネス サービスと同様に使用できます。EJB 転送コンフィグレーションを保存すると、WSDL が生成されます。
WSDL は、EJB のインタフェースに基づいて生成されます。[EJB 転送コンフィグレーション] ページは、サービスのインタフェースと生成される WSDL を制御するためのコンフィグレーション オプションを提供します。これを行うには、上の図に示すように [EJB 転送コンフィグレーション] ページのコンフィグレーションを完了します。
sayHello
と sort
の 2 つのメソッドを表示しています。
次の図は、カスタム メソッド コンフィグレーションの例を示します。
注意 : | 任意の EJB のメソッド間で資格またはトランザクション設定が異なる場合、任意のビジネス サービスのメソッドをカスタマイズする機能を使用して、メソッドごとのビジネス サービスを作成できます。これにより、トランザクションと資格の詳細な制御が可能になります。 |
EJB ビジネス サービスは、SOAP XML ビジネス サービスとして使用できます。EJB ビジネス サービスへのパブリッシュ、ルーティング、コールアウトが可能です。トランザクション サポートが必要な場合は、QoS を 「必ず 1 回」に設定します。「トランザクション処理、再試行、およびエラー処理」を参照してください。
テスト コンソールを使用してコンフィグレーションを検証したり、XML 要求の形式を決定したりすることもできます。
EJB 転送を使用して、EJB を Web サービスとして簡単にエクスポーズできます。
注意 : 既存の EJB ビジネス サービスからプロキシ サービスを作成することはできません。最初に EJB ビジネス サービスから生成された WSDL を取得し、その WSDL に基づいてプロキシ サービスを作成する必要があります。これを行うには、次の手順を実行します。
WSDL は JAR ファイルに含まれています。保留中のセッションがない場合にのみ WSDL を取得できます。
ビジネス サービスのコンフィグレーションが変更されると、新しい WSDL が生成されます。この場合、新しい WSDL を取得し、WSDL リソースとして再登録する必要があります。
これで、高価な Web サービス ツールキットを購入したり、EJB サーバで煩雑な動作を実行せずに、EJB を Web サービスとして呼び出せます。
この節では、EJB ビジネス サービスが、設計時のコンフィグレーションの方法に応じて、実行時にどのように動作するかを理解するために、EJB 転送について説明します。内容は以下のとおりです。
EJB 転送は、トランザクションを作成、サスペンド、および伝播できます。AquaLogic Service Bus および EJB サーバ間のトランザクションは XA トランザクションです。HTTP トンネリングを使用してトランザクションを使用する、または専用の通信チャネルがあり、EJB が 8.1 サーバにデプロイされている場合は、トランザクション マネージャの [セキュリティの相互運用モード] を [パフォーマンス
] に設定する必要があります。セキュリティの相互運用モードの設定とその他のトランザクション コンフィグレーションについては、『WebLogic JTA プログラマーズ ガイド』の「トランザクションのコンフィグレーション」を参照してください。
EJB ビジネス サービスの動作を決定する場合、プロキシ サービス パイプラインにトランザクション コンテキストが含まれているかどうか、およびサービスを呼び出すときにパイプラインでどのサービスの品質 (QoS) 設定が指定されているかを考慮する必要があります。
AquaLogic Service Bus services の QoS については、「サービスの品質」を参照してください。
EJB ビジネス サービスで再試行またはフェイルオーバがコンフィグレーションされている場合、EJB 転送は以下のタイプの例外を区別します。
再試行とフェイルオーバは、エラーのタイプおよび QoS に基づきます。
EJB ビジネス サービスへの QoS 仕様のその他の影響については、「トランザクション」を参照してください。
チェック済み例外を送出するときに、EJB 仕様に応じて、継続中のトランザクションを「ロールバックのみ」に指定できます。
EJB 開発者によって継続中のトランザクションが「ロールバックのみ」に設定されている場合、トランザクションは、最終的にその作成者 (多くの場合、プロキシ サービス) によってロール バックされます。
継続中のトランザクションが「ロールバックのみ」に設定されておらず、チェック済み例外が発生した場合、エラー ハンドラによってパイプラインの EJB チェック済み例外を捕捉することが重要です。それらの例外が捕捉されない場合、パイプライン エラーがプロキシ サービスに逆に伝播されます。次に、一般的にプロキシ サービスは、継続中のトランザクションを (転送の実装に応じて) ロールバックします。これは意図された結果ではない場合があります。
たとえば、以下のメソッドを持つ EJB があると仮定します。
public void withdrawFunds(float amount) throws RemoteException, InsufficientFundsException {...}
また、InsufficientFundsException
例外が送出されたときに、EJB が現在のトランザクションを「ロールバックのみ」に設定しないと仮定します。ほとんどのシナリオにおいて、プロキシ サービスがトランザクションをロール バックするのは不適切です。場合によっては、パイプラインにエラー ハンドラをコンフィグレーションして、エラーを捕捉し、このシナリオを回避する必要があります。
EJB 転送は、XML Java の変換を行います。変換は、WebLogic Server JAX-RPC エンジンによって実行されます。
ネイティブにサポートされる型の完全なリストについては、『WebLogic Web サービス プログラマーズ ガイド』の「データ型とデータ バインディング」を参照してください。
EJB メソッドは、JAX-RPC エンジンでサポートされない (設計時にエラーが報告される)、また、XML に直接マップしない (実行時にエラーが発生する) パラメータ/戻り値の型を使用できます。頻繁に使用されるが、サポートされていない型は以下のとおりです。
これらの型を XML Java の変換に適した型に変換しなくても、カスタム コンバータ クラスを記述できます。EJB 転送はカスタム コンバータ クラスをサポートします。
Converter クラスは、AquaLogic Service Bus パブリック API. の com.bea.wli.sb.transports.ejb.ITypeConverter
Java インタフェースによって定義されるコントラクトを実装し、準拠する Java クラスです。ITypeConverter
Java インタフェースとその他の AquaLogic Service Bus API については、AquaLogic Service Bus の Javadoc を参照してください。
EJB ビジネス サービスでコンバータ クラスを使用するには、以下を行う必要があります。
この節では、EJB ビジネス サービスの設計または実行時の問題のトラブルシューティングについて説明します。
EJB 転送は、その他の AquaLogic Service Bus 転送と同じロガーを使用します。デバッグ モードを有効にするには、サーバを起動する前に、ドメイン ディレクトリにある wlidebug.xml
ファイルを編集し、カテゴリ wli-sb-transports-debug を true
に設定します。wlidebug.xml
ファイルとデバッグ フラグの詳細については、「AquaLogic Service Bus でのデバッグ」を参照してください。
設計時に、EJB 転送は、サブフォルダ alsbejbtransport にファイルを生成し、temp
ディレクトリに appcgen_ というプレフィックスが付けられたサブフォルダを生成します。それらのフォルダとファイルを削除すると安全です。また、アクティブ化の際の問題を判断するためにそれらを確認すると役に立つ場合があります。
EJB ビジネス サービスが作成されると、AquaLogic Server にアプリケーションがデプロイされます。このアプリケーションのモニタと調整は WebLogic Server Administration Console を使用して行うことができます。EJB ビジネス サービス アプリケーションの名前には、ALSB EJB
が付加され、その後に WSDL 型と自動生成されたサフィックスが続きます。
EJB ビジネス サービスに関する問題のトラブルシューティングが必要な場合に、以下の項目が役立つことがあります。
システムは指定されたパスを見つけられません) : 抽出されているファイルのパスの文字列の長さが長すぎる可能性があります
AquaLogic Service Bus ドメインへの短いパスを作成することで、パスの長さを短くすることができます。また、サーバの起動時に、以下のオプションを使用して WebLogic Server の temp
ディレクトリをオーバーライドすることもできます。
-Dweblogic.j2ee.application.tmpDir=$desired_short_dir
config.xml
ファイルで、t3-server-abbrev-table-size
要素に 255
を設定する必要がある。 <server>
<name>AdminServer</name>
<ssl>
<name>AdminServer</name>
<enabled>true</enabled>
</ssl>
<t3-server-abbrev-table-size>255</t3-server-abbrev-table-size>
<listen-address></listen-address>
</server>
![]() ![]() ![]() |