Liberty でのリモート・インターフェースによる Enterprise JavaBeans の使用
別の Java 仮想マシン (JVM) または同じ JVM 内の別のアプリケーションによって Enterprise Java™ Bean (EJB) がホストされている場合に、リモート・インターフェースを使用して EJB メソッドにリモートからアクセスできます。WebSphere® Application Server は、RMI-IIOP テクノロジーを使用して、リモート EJB インターフェースを実装します。ejbRemote-3.2 フィーチャーを使用してリモート EJB サポートを有効にすることができます。
このタスクについて
リモート EJB サポートを有効にしてアプリケーションを実行するように Liberty サーバーを構成するには、 ejbRemote-3.2 フィーチャーを設定する必要があります。
リモート EJB インターフェースを使用する場合は、以下の考慮事項を検討してください。
- ネーミング
java: 名前空間を使用する
EJB 仕様では、リモート・インターフェースは java: 名前空間にバインドされている必要があります。以下に例を示します。java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:app/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface java:module/ExampleBean!com.ibm.example.ExampleRemoteInterface
EJB コンポーネントは、WebSphere® Application Server traditionalのようにデフォルトの Java Naming and Directory Interface (JNDI) 名前空間にはバインドされません。そのため、ibm-*-bnd.xml ファイル内の @EJB 検索とバインディングでは、この名前空間を使用してはなりません。このような検索では、java: の名前 (同じサーバー内にホストされている EJB コンポーネントの場合) および corbaname: の URL (別のサーバー内にホストされている EJB コンポーネントの場合) を使用する必要があります。
- corbaname: URL を使用するインターフェースは、java:global 名前空間で使用されるインターフェースに似たコンテキストで、 ORB CosNaming ネーム・サービスにもバインドされます。これらのインターフェースには、corbaname: URL を使用して、JNDI を通してアクセスできます。 以下に例を示します。
corbaname::test.ibm.com:2809#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleHomeBean!com.ibm.example.ExampleEJBHome
サーバーでは、rir: 形式の URL はローカル・ネーム・サービスを使用します。クライアントでは、デフォルトまたは構成されたリモート・ネーム・サービスが使用されます。
- corbaname: URL をエスケープする
オブジェクト管理グループ (OMG) ネーミング・サービス仕様に従うと、 corbaname: URL 内の文字にはエスケープが必要なものがあります。Liberty は、 java:global 名前空間から得られた corbaname: URL がエスケープを必要とするかどうかの判定を試み、自動的にエスケープします。 すべてのケースでエスケープが可能であるとは限りません。例えば、名前に 1 つのドット (.) が含まれていて、 無効文字は含まれていない場合、自動的にエスケープすることはできません。特定の方法で名前が解釈されるように強制するには、 OMG ネーミング・サービス仕様に記述されているように、URL を手動でエスケープする必要があります。
以下のようなエンタープライズ Bean の java:global 名があるとします。
単純な形式の corbaname: URL は、異なるロケーションだが、有効なロケーションを表しているため、 自動的にエスケープすることはできません。したがって、以下の URL は期待した通りには機能しません。java:global/TestApp/TestModule/TestBean!test.TestRemoteInterface
代わりに、 この URL を手動で次のようにエスケープする必要があります。corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test.TestRemoteInterface
corbaname:rir:#ejb/global/TestApp/TestModule/TestBean!test%5c.TestRemoteInterface
corbaname: URL のエスケープの構文は、OMG ネーミング・サービス仕様にすべて記述されています。
- JNDI 名をプログラマチックに使用するこれらの例にあるすべての URL および JNDI 名は、 InitialContext からプログラマチックにルックアップすることができます。java: 名をルックアップするときには、 結果のオブジェクトを期待されるタイプに直接キャストできます。以下に例を示します。
ただし、 corbaname: URL を使用してオブジェクトを取得するときには、 narrowing と呼ばれる、RMI スタイルのキャストを使用する必要があります。以下に例を示します。Object found = new InitialContext().lookup("java:global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface) found;
Object found = new InitialContext().lookup("corbaname:rir:#ejb/global/ExampleApp/ExampleModule/ExampleBean!com.ibm.example.ExampleRemoteInterface"); ExampleRemoteInterface bean = (ExampleRemoteInterface)PortableRemoteObject.narrow(found, ExampleRemoteInterface.class);
- インターオペラビリティー
- IIOP プロトコルをサポートするどの製品でも、バージョン 2.0 デプロイメント記述子で EJB JAR モジュール内にパッケージされていれば、 EJBHome および EJBObject とともに EJB 2.x リモート・プログラミング・モデルを使用するエンタープライズ Bean を呼び出すことができます。リモート・クライアントのクラスパスに WLP_INSTALL_DIR/clients/ejbRemotePortable.jar ファイルが含まれている必要があります。このファイルには、Liberty サーバーとの通信に必要なシステム値クラスが含まれています。WebSphere Application Server Liberty または WebSphere Application Server traditional から EJB コンポーネントにリモートからアクセスする場合には、このファイルは不要です。Liberty で EJB 3 リモート・プログラミング・モデルを使用する EJB コンポーネントには、WebSphere Application Server プロセスによってリモートからアクセスできます。Liberty は、スタンドアロン Java プロセスから EJB コンポーネントを開始するためのシン・クライアントを備えていません。Liberty は、WebSphere Application Server traditional からホストされている EJB コンポーネントを開始する場合も含め、リモート EJB コンポーネント用のワークロード管理やフェイルオーバーの機能を提供しません。
- スタブ・クラス
- WebSphere Application Server でホストされているリモート EJB を開始する場合には、クライアントにスタブ・クラスが含まれている必要があります。クライアントが WebSphere Application Server の場合、以下のような一部のケースでは、製品によって正しいスタブ・クラスが自動的に生成されます。
- クライアント・アプリケーションが同じアプリケーション内に含まれているリモート EJB を開始した場合、Liberty により、スタブ・クラスが自動的に生成されます。
- ターゲット EJB が別個のアプリケーションで実行されていて、EJBHome および EJBObject とともに EJB 2.x リモート・プログラミング・モデルを使用している場合、クライアントのクラスパスにスタブ・クラスが含まれている必要があります。EJB が WebSphere Application Server traditionalでホストされている場合、EJB クライアント JAR を、ejbdeploy コマンドで処理された後に、EAR からアプリケーションでコピーできます。EJB が Liberty 上でホストされている場合、Java SDK に付属の rmic プログラムを使用して、ターゲット EJB 用のスタブ・クラスを生成する必要があり、その後クライアントにそのスタブ・クラスを組み込む必要があります。
- ターゲット EJB が別個のアプリケーションで実行されていて、EJB 3 リモート・プログラミング・モデルを使用している場合、クライアント Liberty または WebSphere Application Server traditionalのプロセスにより、スタブ・クラスが自動的に生成されます。Liberty 上で EJB 3 リモート・プログラミング・モデルを使用する EJB 3 コンポーネントには、 WebSphere Application Server プロセスまたは WebSphere Application Client プロセスによってのみリモートでアクセスできます。
- トランザクションの伝搬
- Liberty では、アウトバウンドおよびインバウンドのトランザクションの伝搬はサポートされません。さらに、 EJB 仕様では、製品がアウトバウンドのトランザクションの伝搬をサポートしている場合でも、 ヌル・トランザクション・コンテキストの送信が必要であるとされています。このコンテキストは、 Required (デフォルト)、Mandatory、または Supports トランザクション属性を使用する EJB コンポーネントによって拒否されなければなりません。アクティブなグローバル・トランザクションがあるクライアントは、クライアントまたはサーバーが Liberty にある場合、デフォルト・トランザクション属性で EJB を開始できません。クライアントは、 EJB が RequiresNew または NotSupported トランザクション属性を使用するように変更された場合は、EJB を開始できます。ただし、 EJB によって行われるトランザクション処理は、クライアントのトランザクションの一部としてコミットされません。
- 非同期メソッド
- EJB リモート・インターフェースでは、Future タイプの戻り値を持つ非同期メソッドを使用できます。サーバーは、Future オブジェクトをクライアントに返し、このオブジェクトが値の取得に使用されます。リモート非同期メソッドはお勧めできません。要求されない結果が累積して、メモリーが枯渇する可能性があるためです。この問題を緩和するには、クライアントが結果を 24 時間以内に取得しなかった場合または要求されない結果の最大数が 1000 を超えた場合に、サーバーの結果の有効期限が切れるようにします。以下の例のように、これらの値は server.xml ファイル内で調整できます。
<ejbContainer> <async maxUnclaimedRemoteResults="10"unclaimedRemoteResultTimeout="10m"/> </ejbContainer>