| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11g リリース1(11.1.1.4.0) B61435-02 |
|
 前 |
 次 |
Oracle Service Busは、EJBトランスポートを使用して、サポート対象プラットフォームにデプロイされたEJB 2.1またはEJB 3.0ステートレス・セッションBeanのネイティブRMI呼出しをサポートします。これにより、トランザクション対応のセキュアな通信が可能になります。また、EJBトランスポートを利用し、Oracle Service Busを介してEJBをWebサービスとして公開することもできます。
ここででは次のトピックについて説明します。
Oracle Service Busでは、ビジネス・サービスを構成して、EJBトランスポートを使用できます。EJBトランスポートは、Oracle Service Bus構成、管理、モニター、およびテスト・コンソールと完全に統合されています。EJBトランスポートが構成されたビジネス・サービスは、パブリッシュ、サービス・コールアウトおよびサービスの呼出しに使用できます。EJBトランスポートを使用するプロキシ・サービスは作成できません。
EJBトランスポートには以下の機能があります。
トランザクション整合性 – EJBビジネス・サービスをグローバル・トランザクションのコンテキスト内で呼び出せます。また、EJBトランスポートは、EJBを呼び出す前にグローバル・トランザクションをサスペンドまたは開始できます。
セキュリティ伝播 – メッセージ・フローの最初に確立されたセキュリティ・コンテキストは、Oracle Service Busクライアントからその他のシステムに伝播されます。たとえば、受信した、認証を必要とするOracle Service BusへのSOAP over HTTPリクエストは、Oracle Service Busによって認証され、認証されたサブジェクトはその後EJBサーバーに伝播されます。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のドメイン間セキュリティ・サポートに関する重要事項に関する項を参照してください。
HTTPトンネリングおよび暗号化通信 – HTTPトンネリングを使用して、ファイアウォール内のEJBにアクセスできます。セキュリティの強化のために、SSLを使用してEJBサーバーとのすべての通信を暗号化できます。
JNDIプロバイダ – EJBトランスポートは、Oracle Service BusリソースであるJNDIプロバイダを使用します。JNDIプロバイダは、リモート・サーバーにアクセスするための通信プロトコルやセキュリティ資格証明を定義します。JNDIプロバイダは、複数のEJBビジネス・サービスで再利用できます。これにより、管理者によるリモートEJBサーバー構成の一元的な管理が実現します。
JNDIプロバイダ・リソースの詳細は、2.1.8項「JNDIプロバイダ・リソースの作成および編集」を参照してください。
高パフォーマンス・キャッシング – EJBトランスポートはパフォーマンスの高いキャッシュ上に構築されており、確立された接続を再使用して、EJBスタブのルックアップを最小限に抑えることができます。
フェイルオーバーとロード・バランシング – EJBトランスポートでは、ロード・バランシングまたはフェイルオーバー、もしくは両方のために、同じEJBが複数のドメインまたは1つのクラスタにデプロイされているシナリオを利用できます。
XMLとJavaの拡張バインディング機能 – EJBトランスポートは、Oracle WebLogic Server JAX-RPCスタックを使用して、JavaとXMLのバインディングを実行します。JAX-RPCスタックは、XML Beanなどの高度なJavaオブジェクトをサポートする高性能のエンジンです。Java型がスタックによって認識されない場合、これらのJava型をサポートできるようにするための拡張メカニズムが提供されます。(コンバータ・クラスを使用した)拡張メカニズムについては、28.4.2項「サポートされる型およびコンバータ・クラス」を参照してください。
インテリジェントな再試行 – EJBトランスポートでは、EJBの呼出し中に発生する可能性のある障害の性質に基づいて再試行が決定されます。
Oracle Service Busにビジネス・サービスを構成する前に、JNDIプロバイダ・リソースおよびクライアントJARリソースを登録する必要があります。この項ではOracle Service BusでのEJBトランスポート・ビジネス・サービスの設計と構成の方法について説明します。
JNDIプロバイダ・リソースでは、リモートOracle WebLogicドメインのJNDIツリーにバインドされているEJBスタブを取得するために使用される通信プロトコルおよびセキュリティ資格証明を指定できます。JNDIツリーの設定方法の詳細は、Oracle Fusion MiddlewareのOracle WebLogic Server JNDIプログラミング・ガイドを参照してください。
通常、ターゲットEJBはOracle Service Busと同じドメイン内にはありません。この場合、JNDIプロバイダ・リソースを登録する必要があります。EJBが同じドメイン内にある場合、プロバイダを定義して資格証明を指定し、スタブ・キャッシングを利用できます。ただし、この場合、省略可能です。
JNDIプロバイダには、リモート接続とEJBスタブのための高性能なキャッシング・メカニズムがあります。Oracle Service BusからOracle WebLogic Serverドメインへの推奨される通信プロトコルは、t3またはt3sです。メッセージがファイアウォールを通過する必要がある場合は、HTTPトンネリングを使用できます。
|
注意: Oracle WebLogic Serverの外部JNDIプロバイダを使用することは可能ですが、使用しないことをお薦めします。このトランスポートでは、双方向SSLまたはクライアント証明書によるJNDIツリーのルックアップまたはEJBのメソッドへのアクセスをサポートしません。 |
Oracle Service BusでのJNDIプロバイダの登録と構成の詳細は、4.8項「JNDIプロバイダ」を参照してください。
クライアントJARを、リソースとしてOracle Service Busに登録する必要があります。その結果、Oracle Service Bus構成の一部となり、プロジェクトからエクスポートすることもプロジェクトにインポートすることもできます。
EJBクライアントJARファイルには、Oracle Service BusがEJBにアクセスするために必要なインタフェースとクラスが含まれている必要があります。これには、リモート・インタフェースとホーム・インタフェース(EJB 2.1)またはビジネス・インタフェース(EJB 3.0)、およびメソッドのパラメータ型またはアプリケーションの例外など、クライアントが公開される依存型が含まれます。
ビジネス・サービスにコンバータ・クラスが必要な場合は、コンバータ・クラスを含むJARファイルをOracle Service Busリソースとして登録すると、これらのクラスを使用してXMLにマップ可能なJavaクラスにパラメータと戻り値の型をマップできます。または、これらのコンバータ・クラスをEJBクライアントJARにパッケージ化できます。コンバータ・クラスについては、28.4.2.1項「コンバータ・クラス」を参照してください。
EJBクライアントJARを使用するときは、以下のガイドラインを考慮してください。
システム・クラスパスでのホーム・インタフェースおよびリモート・インタフェースの追加は推奨されません。また、Oracle Service Busではサポートされません。
クライアントJARのサイズを小さくすること、JARあたり1つのホーム・インタフェースを含めること、ejb-jarファイル全体を登録しないことを推奨します。
Eclipseを使用して、Oracle WebLogic ServerにデプロイされているEJBのクライアントJARを取得できます。
Oracle Service Busは、JDK 1.4以上でコンパイルされたclient-jarをサポートします。
Oracle Service BusでJARリソースを登録および構成する方法の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJARの追加に関する項を参照してください。
EJBメソッドが保護されている場合、呼出しに使用する資格証明を指定できます。多くの場合、これらの資格証明はJNDIプロバイダで使用される資格証明とは異なります。サービス・アカウントの追加と使用の詳細は、2.1.15項「サービス・アカウント・リソースの追加」を参照してください。
EJBのJNDI名がわからない場合は、EJBサーバーのJNDIツリーを参照できます。Oracle WebLogic Server管理コンソールを使用したJNDIツリーの参照の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。
EJBビジネス・サービスはトランスポート型付きのサービスです。つまり、トランスポートのタイプはサービスの構成によって決まります。
EJBビジネス・サービスのタイプはSOAP XMLサービスと同等です。つまり、EJBビジネス・サービスを他のすべてのSOAP XMLビジネス・サービスと同様に使用できます。EJBトランスポート構成を保存すると、WSDLが生成されます。
WSDLは、EJBのインタフェースに基づいて生成されます。EJBトランスポートの構成ページは、サービスのインタフェースと生成されるWSDLを制御するための構成オプションを提供します。
ここでは、EJBトランスポートのエンドポイントURLの形式と構成オプションを説明します。
EJBトランスポートのURIパターンは次のとおりです。
ejb:jndi_provider_name:ejb_jndi_name
ここで、jndi_provider_nameはOracle Service Bus JNDIプロバイダ・リソースの名前です。
EJBがローカルにデプロイされている場合、JNDIプロバイダの名前を提供する必要はありません。この場合、URIの形式は以下のようになります。
ejb::ejb_jndi_name
Oracle WebLogic Server上のEJB 3.0ビジネス・サービスの場合、ejb_jndi_nameはmappedName#BusinessInterfaceという形式になります。
|
注意: EJBがIBM WebSphere上で実行中の場合は、ejb_jndi_nameを次の形式にしてください。
または
詳細は次の場所にあるIBM WebSphereのドキュメントに記述されています。 |
表28-1に、EJBトランスポートのトランスポート固有の構成オプションを示します。
表28-1 ビジネス・サービスのためのEJBトランスポート構成オプション
| オプション | 説明 |
|---|---|
|
呼出し元のサブジェクトを渡す |
EJBの呼出し時にサービス・アカウントが構成されていない場合、このチェックボックスを選択して、Oracle Service Busがプロキシ・サービスから認証されたサブジェクトを渡すようにします。このオプションを選択すると、「サービス・アカウント」フィールドが無効になります。 |
|
サービス・アカウント |
「参照」をクリックし、表示されるリストでサービス・アカウントを選択します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。「呼出し元のサブジェクトを渡す」オプションを使用する場合、このオプションは使用できません。 |
|
トランザクションをサポートする |
トランザクションを指定する場合は、このチェック・ボックスを選択します。 |
|
クライアントJar |
「参照」をクリックし、表示されたリストからEJBクライアントJARリソースを選択します。 |
|
コンバータJar |
「参照」をクリックし、表示されたリストからEJBコンバータ・クラスJARリソースを選択します。 詳細は、28.2.2.1項「クライアントJARまたはコンバータJARの追加」および28.4.2.1項「コンバータ・クラス」を参照してください。 |
|
ホーム・インタフェース |
EJB 2.1専用 – JARが埋め込むオプションから必要なEJBHomeインタフェースを選択します。このURIサンプルのJNDI名はここで選択するEJBHomeインタフェースに関連付ける必要があります。EJBが必要なタイプのものではない、またはEJBHomeインタフェースがclient-jarで指定されていない場合は、警告が表示されます。 |
|
リモート・インタフェース |
EJB 2.1専用 – このフィールドは、Homeインタフェースの構成に基づいて、自動的に情報が表示されます。 |
|
ビジネス・インタフェース |
EJB 3.0専用 – 呼び出すクライアントJARでビジネス・インタフェースを選択します。 |
|
対象ネームスペース |
このフィールドにはJARからのピックアップされた情報が表示されます。 |
|
スタイル |
要件に応じて、「ドキュメントをラップ」または「RPC」を選択します。ステートレス・セッションEJBの2つ以上のメソッドに、同じ数の同じデータ・タイプのパラメータがあり、操作をドキュメント指向にする場合はドキュメントのラップを指定する必要があります。 EJBへのルーティングまたはパブリッシュの場合、 |
|
エンコーディング |
「エンコード形式」または「リテラル形式」を選択します。 |
|
メソッド |
必要なメソッドを選択します。「+」をクリックしてメソッドを展開すると、デフォルトのパラメータ値を編集して、提供されている場合(または必要な場合)はコンバータを選択できます。 JAX-RPCスタックでサポートされないパラメータまたは戻り値の型を持つメソッドを除外するか、それらの引数をコンバータ・クラスに関連付ける必要があります。 任意のメソッドのデフォルトの操作名を変更できます。デフォルトでは、操作名はメソッド名です。EJBに同じ名前のメソッドが含まれている場合、一意になるように操作名を変更する必要があります。WSDLでは一意の操作名が必要です。 注意: 任意のEJBのメソッド間で資格証明またはトランザクション設定が異なる場合、任意のビジネス・サービスのメソッドをカスタマイズして、メソッドごとのビジネス・サービスを作成できます。これにより、トランザクションと資格証明の詳細な制御が可能になります。 |
|
例外 |
このフィールドは、メソッドがビジネス例外を送出した場合に表示されます。EJBメソッドが、ArrayListなどのJava Web Services (JWS)でサポートされないデータ型を持つ例外を送出した場合は、「例外」フィールドを使用して、例外をJWSでサポートされる型に変換するコンバータ・クラスを選択します。 コンバータ・クラスは、com.bea.wli.sb.transports.ejb.ITypeConverterを実装する必要があります。コンバータ・クラスは、実行時例外ではなくチェック済の例外用にのみ構成できます。 コンバータ・クラスおよび変換された例外クラスをクライアントまたはコンバータJARでパッケージ化します。 |
EJBビジネス・サービスは、SOAP XMLビジネス・サービスとして使用できます。EJBビジネス・サービスへのパブリッシュ、ルーティング、コールアウトが可能です。トランザクション・サポートが必要な場合は、サービス品質を「必ず1回」に設定します28.4.1項「トランザクション処理、再試行、およびエラー処理」を参照してください。
テスト・コンソールを使用してコンフィグレーションを検証したり、XML要求の形式を決定したりすることもできます。
EJBトランスポートを使用して、EJBをWebサービスとして簡単に公開できます。
|
注意: 既存のEJBビジネス・サービスからプロキシ・サービスを作成することはできません。最初にEJBビジネス・サービスから生成されたWSDLを取得し、そのWSDLに基づいてプロキシ・サービスを作成する必要があります。これを行うには、次の手順を実行します。 |
28.2.3項「トランスポート構成のリファレンス」の説明に従って、公開するEJBを指すEJBビジネス・サービスを作成します。
「サービスの詳細。」ページで、EJBビジネス・サービスのWSDLを取得します。
WSDLはJARファイルに含まれています。保留中のセッションがない場合にのみWSDLを取得できます。
JARからWSDLを抽出し、WSDLリソースとして登録します。
ビジネス・サービスの構成が変更されると、新しいWSDLが生成されます。この場合、新しいWSDLを取得し、WSDLリソースとして再登録する必要があります。
WSDLに基づいてSOAP XMLプロキシ・サービスを作成します。
プロキシ・サービス・パイプラインを編集し、EJBビジネス・サービスにルーティングします。
これで、高価なWebサービス・ツール・キットを購入したり、EJBサーバーで煩雑な動作を実行せずに、EJBをWebサービスとして呼び出せます。
この項では、EJBビジネス・サービスが、設計時の構成の方法に応じて、実行時にどのように動作するかを理解するために、EJBトランスポートについて説明します。
ここでは、EJBトランスポートのトランザクション処理、再試行とフェイルオーバー、エラー処理について説明します。
EJBトランスポートは、トランザクションを作成、サスペンド、および伝播できます。Oracle Service BusおよびEJBサーバー間のトランザクションはXAトランザクションです。HTTPトンネリングを使用してトランザクションを使用する場合、または専用の通信チャネルがある場合は、トランザクション・マネージャのセキュリティの相互運用を「パフォーマンス」に設定する必要があります。セキュリティの相互運用モードの設定とその他のトランザクション構成の詳細は、Oracle Fusion MiddlewareのOracle WebLogic Server JTAプログラミング・ガイドのトランザクションの構成に関する項を参照してください。
デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。
EJBビジネス・サービスの動作を決定する場合、プロキシ・サービス・パイプラインにトランザクション・コンテキストが含まれているかどうか、およびサービスを呼び出すときにパイプラインでどのサービスの品質(QoS)設定が指定されているかを考慮する必要があります。
「ベスト・エフォート」QoS - パイプラインでQoSに「ベスト・エフォート」が指定されている場合、トランザクションはEJBに伝播されません。継続中のトランザクションは呼出しの前にサスペンドされ、呼出し後に再開されます。
「必ず1回」QoS - パイプラインでQoSとして「必ず1回」が指定され、EJBがトランザクションをサポートしない場合(つまり、EJBトランスポートの構成ページの「トランザクションをサポートする」オプションのチェックが選択されていない場合)、トランザクションはEJBに伝播されません。「ベスト・エフォート」の場合と同様に、継続中のトランザクションは呼出しの前にサスペンドされ、呼出し後に再開されます。
または
EJBがトランザクションをサポートする場合(つまり、「EJBトランスポート構成」ページの「トランザクションをサポートする」オプションがチェックされている場合)、EJBはトランザクションのコンテキスト内で呼び出され、すべての継続中のトランザクションはEJBに伝播されます。トランザクションが存在しない場合、トランザクションは、呼出しの前に作成され、後でコミットされます。
Oracle Service BusサービスでのQoSの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のサービス品質に関する項を参照してください。
EJBビジネス・サービスで再試行またはフェイルオーバーが構成されている場合、EJBトランスポートは以下のタイプの例外を区別します。
実行時例外またはリモート例外 - 通常、致命的なエラーまたは通信例外
JAX-RPCエンジンによる例外 - XMLからJavaへの変換中に発生する例外
EJBチェック済み例外 - EJB実装固有のEJBメソッド・シグネチャで宣言される例外(ビジネス例外とも呼ばれます)
再試行とフェイルオーバーは、エラーのタイプおよびQoSに基づきます。
「ベスト・エフォート」QoS - 実行時例外またはリモート例外がスローされた場合、EJBトランスポートは再試行またはフェイルオーバーを試みます。
JAX-RPCエンジンで例外が発生した場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
「必ず1回」QoS - 実行時例外またはリモート例外がスローされ、継続中のトランザクションが(一般的にEJBコンテナによって)ロールバックのみに設定されている場合、EJBコンテナが影響を受け、EJBコンテナまたはEJBのいずれかで致命的なエラーが発生したことを意味します。この場合、再試行またはフェイルオーバーの試みは行われず、エラーはパイプラインで発生します。
実行時例外またはリモート例外がスローされても、継続中のトランザクションがロールバックのみに設定されていない場合は、EJBコンテナの呼出し前にエラーが発生したことを意味し、EJBトランスポートは再試行またはフェイルオーバーを試みます。この場合、EJBトランスポートでは「必ず1回」のセマンティックが引続き適用されることに注意してください。
JAX-RPCエンジンで例外が発生し、EJBトランスポートによって継続中トランザクションがロールバックのみに設定される場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBビジネス・サービスへのQoS仕様のその他の影響については、28.4.1.1項「トランザクション」を参照してください。
チェック済例外をスローするときに、EJB仕様に応じて、継続中のトランザクションをロールバックのみに指定できます。
EJB開発者によって継続中のトランザクションがロールバックのみに設定されている場合、トランザクションは、最終的にその作成者(多くの場合、プロキシ・サービス)によってロール・バックされます。
継続中のトランザクションがロールバックのみに設定されておらず、チェック済例外が発生した場合、エラー・ハンドラによってパイプラインのEJBチェック済例外を捕捉することが重要です。それらの例外が捕捉されない場合、パイプライン・エラーがプロキシ・サービスに逆に伝播されます。次に、一般的にプロキシ・サービスは、継続中のトランザクションを(トランスポートの実装に応じて)ロールバックします。これは意図された結果ではない場合があります。
たとえば、以下のメソッドを持つEJBがあると仮定します。
public void withdrawFunds(float amount) throws RemoteException, InsufficientFundsException {…}
また、InsufficientFundsException例外がスローされたときに、EJBが現在のトランザクションをロールバックのみに設定しないと仮定します。ほとんどのシナリオにおいて、プロキシ・サービスがトランザクションをロール・バックするのは不適切です。場合によっては、パイプラインにエラー・ハンドラを構成して、エラーを捕捉し、このシナリオを回避する必要があります。
EJBトランスポートは、XMLとJava間の変換を行います。変換は、Oracle WebLogic Server JAX-RPCエンジンによって実行されます。
EJBトランスポートは、以下の型をネイティブにサポートしています。
プリミティブ型
XmlObject (ApacheおよびOracleバージョンの両方)
スキーマで生成されるXMLBean (ApacheおよびOracleバージョンの両方)
JavaBeanクラス
ネイティブでサポートされる型の一覧は、『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のJAXBデータ・バインディングの使用に関する項を参照してください。
EJBメソッドは、JAX-RPCエンジンでサポートされない(設計時にエラーが報告される)、また、XMLに直接マップしない(実行時にエラーが発生する)パラメータ/戻り値の型を使用できます。頻繁に使用されるが、サポートされていない型は次のとおりです。
Object、Object[]
強く型付けされていないJavaコレクション(List、Setなど)
JavaBeanパターンに従わないJavaクラス(Mapなど)
これらの型をXMLとJava間の変換に適した型に変換しなくても、カスタム・コンバータ・クラスを記述できます。EJBトランスポートはカスタム・コンバータ・クラスをサポートします。
コンバータ・クラスは、Oracle Service BusパブリックAPIのcom.bea.wli.sb.transports.ejb.ITypeConverter Javaインタフェースで定義されるコントラクトを実装して準拠するJavaクラスです。
EJBビジネス・サービスでコンバータ・クラスを使用するには、以下を行う必要があります。
インタフェースを実装およびコンパイルして、コンバータ・クラスを作成します。
コンバータ・クラスをクライアントJARまたはコンバータ・クラスのJARファイルに追加します(28.2.2.1項「クライアントJARまたはコンバータJARの追加」を参照)。
EJBビジネス・サービスの作成時にメソッド構成をカスタマイズする場合、パラメータ/戻り値の型のいずれか1つに移動し、目的のコンバータを選択します。 28.2.3項「トランスポート構成のリファレンス」を参照してください。サービス構成のユーザー・インタフェースに、特定のパラメータ/戻り値の型に適用可能なコンバータのリストが表示されます。
この項では、EJBビジネス・サービスの設計または実行時の問題のトラブルシューティングについて説明します。
EJBトランスポートは、その他のOracle Service Busトランスポートと同じロガーを使用します。デバッグ・モードを有効にするには、サーバーを起動する前に、ドメイン・ディレクトリにあるalsbdebug.xmlファイルを編集し、カテゴリalsb-transports-debugをtrueに設定します。alsbdebug.xmlファイルとデバッグ・フラグの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busのデバッグに関する項を参照してください。
EJBトランスポートは設計時に、tempディレクトリのサブフォルダにファイルを生成します。それらのフォルダとファイルを削除すると安全です。また、アクティブ化の際の問題を判断するためにそれらを確認すると役に立つ場合があります。
EJBビジネス・サービスが作成されると、Oracle Service Bus Serverにアプリケーションがデプロイされます。このアプリケーションのモニターと調整はOracle WebLogic Server管理コンソールを使用して行うことができます。
EJBビジネス・サービスに関する問題のトラブルシューティングが必要な場合に、以下の項目が役立つことがあります。
ビジネス・サービス作成時の以下のエラーは、255を超える文字を含むパスをサポートしないという、Windowsオペレーティング・システムの制限が原因です。
The system cannot find the path specified):Probably the string length of the path of the file being extracted was too long
Oracle Service Busドメインへの短いパスを作成することで、パスの長さを短くすることができます。また、サーバーの起動時に、次のオプションを使用してOracle WebLogic Serverのtempディレクトリをオーバーライドすることもできます。
-Dweblogic.j2ee.application.tmpDir=$desired_short_dir
EJBビジネス・サービスの呼出し時にXMLマーシャリング・エラーを受け取り、リクエストがサービスのWSDLに対し有効であるという確信がある場合は、コンバータ・クラスを記述することが必要になる可能性があります。詳細は、28.4.2.1項「コンバータ・クラス」を参照してください。
リモート・サーバーで、EJBインタフェースおよびスタブが変更された場合、新しいEJBの初回の呼出し時にエラーが送出されます。リモート・サーバーでのEJBインタフェースおよびスタブの変更は、Oracle Service Busに表示されません。Oracle Service Busは、有効ではなくなった、キャッシュされているEJBを呼び出そうとします。ただし、呼出しエラーが発生した場合、トランスポートはそれらのスタブが無効であると見なし、それらをキャッシュから削除します。この方法により、EJBを呼び出す次の試みでのエラーが防止されます。この初回時のエラーを回避するために、Oracle Service BusコンソールでJNDIプロバイダをリセットできます。
