| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1.2.0) E82661-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
Service Busでは、EJBトランスポートが構成されたビジネス・サービスを使用して、パブリッシュ、サービス・コールアウトおよびサービスの呼出しを実行できます。EJBトランスポートを使用するプロキシ・サービスは作成できません。
EJBトランスポートには次の機能があります。
トランザクション整合性 - EJBビジネス・サービスは、グローバル・トランザクションのコンテキスト内で呼び出すことができます。また、EJBトランスポートは、EJBを呼び出す前にグローバル・トランザクションを中断または開始できます。
セキュリティ伝播: Service Busクライアントから確立されたセキュリティ・コンテキストは、別の外部システムに伝播されます。たとえば、受信した、認証を必要とするService BusへのSOAP over HTTPリクエストは、Service Busによって認証され、認証されたサブジェクトはその後EJBサーバーに伝播されます。セキュリティ伝播の詳細は、『Oracle WebLogic Serverセキュリティの管理』のクロスドメイン・セキュリティのサポートに関する重要情報が記載された項を参照してください。
HTTPトンネリングおよび暗号化通信: HTTPトンネリングを使用して、ファイアウォール内のEJBにアクセスできます。セキュリティを強化するには、SSLを使用してEJBサーバーとのすべての通信を暗号化します。
JNDIプロバイダ: EJBトランスポートは、JNDIプロバイダ(Service Busリソース)を使用します。JNDIプロバイダは、リモート・サーバーにアクセスするための通信プロトコルやセキュリティ資格証明を定義します。JNDIプロバイダは、複数のEJBビジネス・サービスで再利用できます。これにより、管理者によるリモートEJBサーバー構成の一元的な管理が実現します。
JNDIプロバイダ・リソースの詳細は、「JNDIプロバイダ・子ソースの操作」を参照してください。
高性能キャッシュ: EJBトランスポートは高性能キャッシュに基づいて構築されています。そのため、確立された接続を再利用して、EJBスタブのルック・アップを最小限に抑えられます。
フェイルオーバーとロード・バランシング: EJBトランスポートでは、ロード・バランシングまたはフェイルオーバー、もしくは両方のために、同じEJBが複数のドメインまたは1つのクラスタにデプロイされているシナリオを利用できます。
XMLとJavaの拡張バインディング機能: EJBトランスポートは、Oracle WebLogic Server JAX-WSスタックを使用して、JavaとXMLのバインディングを実行します。JAX-WSスタックは、XML Beanなどの高度なJavaオブジェクトをサポートする高性能のエンジンです。Java型がスタックによって認識されない場合、これらのJava型をサポートできるようにするための拡張メカニズムが提供されます。(コンバータ・クラスを使用した)この拡張メカニズムについては、「サポートされる型およびコンバータ・クラス」を参照してください。
インテリジェントな再試行: EJBトランスポートでは、EJBの呼出し中に発生する可能性のある障害の性質に基づいて再試行が決定されます。
EJBトランスポートを使用するようにビジネス・サービスを構成するには、JNDIプロバイダ・リソースおよびクライアントJARリソースを作成する必要があります。この項では、Service Bus内のEJBトランスポート・ビジネス・サービスを設計および構成するために必要な手順について説明します。
JNDIプロバイダ・リソースでは、リモートOracle WebLogic ServerドメインのJNDIツリーにバインドされているEJBスタブを取得するために使用される通信プロトコルおよびセキュリティ資格証明を指定できます。通常、ターゲットEJBはService Busと同じドメイン内にはありません。この場合、JNDIプロバイダ・リソースを登録する必要があります。EJBが同じドメイン内にある場合、プロバイダを定義して資格証明を指定し、スタブ・キャッシングを利用できます。ただし、この場合、省略可能です。
JNDIプロバイダには、リモート接続とEJBスタブのための高性能なキャッシング・メカニズムがあります。Service BusからOracle WebLogic Serverドメインへの推奨される通信プロトコルは、t3またはt3sです。メッセージがファイアウォールを通過する必要がある場合は、HTTPトンネリングを使用できます。
注意:
Oracle WebLogic Serverの外部JNDIプロバイダを使用できますが、使用しないことをお薦めします。
このトランスポートでは、双方向SSLまたはクライアント証明書によるJNDIツリーのルックアップまたはEJBのメソッドへのアクセスをサポートしません。
Service BusへのJNDIプロバイダ・リソースの登録と構成の詳細は、「JNDIプロバイダ・リソースの操作」を参照してください。
クライアントJARファイルがService Busサービスによって使用されるようにするには、そのクライアントJARファイルをService Bus内のリソースとして登録する必要があります。その結果、Service Bus構成の一部となり、プロジェクトからエクスポートすることもプロジェクトにインポートすることもできます。EJBクライアントJARファイルには、Service BusがEJBにアクセスするために必要なインタフェースとクラスが含まれている必要があります。これには、リモート・インタフェースとホーム・インタフェース(EJB 2.1)またはビジネス・インタフェース(EJB 3.0)、およびメソッドのパラメータ型またはアプリケーションの例外など、クライアントが公開される依存型が含まれます。
Service Bus 12.2.1以降、EJBトランスポートはJAX-WSスタックを使用します。JAX-WSスタックでは、JavaクラスのXMLへのマッピング、および逆方向のほとんどのJavaタイプへのマッピングをサポートしています。ほとんどの場合、コンバータ・クラスは必要ありません。このリリースでサポートされているコンバータ・クラスは、大部分が前のバージョンのService Busで作成されたビジネス・サービスとの後方互換性をサポートしています。
ビジネス・サービスにコンバータ・クラスが必要な場合は、コンバータ・クラスを含むJARファイルをService Busリソースとして登録すると、これらのクラスを使用してXMLにマップ可能なJavaクラスにパラメータと戻り値の型をマップできます。または、これらのコンバータ・クラスをEJBクライアントJARにパッケージ化できます。コンバータ・クラスについては、「カスタム・コンバータ・クラス」を参照してください。
EJBクライアントJARを使用するときは、次のガイドラインを考慮してください。
システム・クラスパスでのホーム・インタフェースおよびリモート・インタフェースの追加は推奨されず、Service Busではサポートされません。
クライアントJARファイルのサイズを小さくすること、JARファイル当たり1つのホーム・インタフェースを含めること、ejb-jarファイル全体を登録しないことをお薦めします。
Service Busは、JDK 1.4以上でコンパイルされたclient-jarファイルをサポートします。
「サポートされる型およびコンバータ・クラス」で説明しているように、Service Bus EJB実装の拡張による複雑なタイプの継承を使用するには、コンバータ・クラスを作成して使用する必要があります。Service BusへのクライアントまたはコンバータJARリソースの登録と構成の詳細は、「JARファイルの操作」を参照してください。
EJBメソッドが保護されている場合、サービス・アカウントを使用した呼出しに使用する資格証明を指定できます。多くの場合、これらの資格証明はJNDIプロバイダで使用される資格証明とは異なります。サービス・アカウントの追加と使用の詳細は、「サービス・アカウントの操作」を参照してください。
EJBビジネス・サービスは、SOAP XMLビジネス・サービスとして使用できます。EJBビジネス・サービスへのパブリッシュ、ルーティング、コールアウトが可能です。
トランザクション・サポートが必要な場合は、サービス品質を「必ず1回」に設定します詳細は、「EJBトランスポートの詳細な説明」を参照してください。
テスト・コンソールを使用して構成を検証したり、XMLリクエストの形式を決定したりすることもできます。
EJBトランスポートを使用して、EJBをWebサービスとして簡単に公開できます。
プロキシ・サービスは既存のEJBビジネス・サービスから作成できません。EJBビジネス・サービスから生成されたWSDLファイルを最初に取得し、そのWSDLファイルに基づいてプロキシ・サービスを作成する必要があります。これを行うには、次の手順を実行します。
この項では、EJBビジネス・サービスが、設計時の構成に応じて、実行時にどのように動作するかを理解するために、EJBトランスポートについて説明します。
EJBトランスポートは、トランザクションを作成、中断、および伝播できます。Service BusおよびEJBサーバー間のトランザクションはXAトランザクションです。HTTPトンネリングを使用してトランザクションを使用する場合、または専用の通信チャネルがある場合は、トランザクション・マネージャのセキュリティの相互運用を「パフォーマンス」に設定する必要があります。セキュリティの相互運用モードの設定とその他のトランザクション構成の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションの構成に関する項を参照してください。
デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。
EJBビジネス・サービスの動作を決定する場合、パイプラインにトランザクション・コンテキストが含まれているかどうか、およびサービスを呼び出すときにパイプラインでどのサービスの品質(QoS)設定が指定されているかを考慮する必要があります。
「ベスト・エフォート」QoS: パイプラインで「ベスト・エフォート」QoSが指定されている場合、トランザクションはEJBに伝播されません。継続中のトランザクションは呼出しの前に中断され、呼出し後に再開されます。
「必ず1回」QoS: パイプラインでQoSとして「必ず1回」が指定され、EJBがトランザクションをサポートしない場合(つまり、EJBトランスポートの構成ページの「トランザクションをサポートする」オプションが選択されていない場合)、トランザクションはEJBに伝播されません。「ベスト・エフォート」の場合と同様に、継続中のトランザクションは呼出しの前に中断され、呼出し後に再開されます。
EJBがトランザクションをサポートする場合(つまり、EJBトランスポート構成ページの「トランザクションをサポートする」オプションが選択されている場合)、EJBはトランザクションのコンテキスト内で呼び出され、すべての継続中のトランザクションはEJBに伝播されます。トランザクションが存在しない場合、トランザクションは、呼出しの前に作成され、後でコミットされます。
Service BusサービスのQoSの詳細は、「サービスの品質」を参照してください。
EJBビジネス・サービスで再試行またはフェイルオーバーが構成されている場合、EJBトランスポートは次のタイプの例外を区別します。
実行時例外またはリモート例外: これらは通常、予期しない致命的なエラーまたは通信例外です。
JAX-WSエンジンによる例外: これらは、XMLからJavaへの変換中に発生する例外です。
EJBチェック済例外: これらは、EJB実装固有のEJBメソッド署名で宣言される例外です。ビジネス例外とも呼ばれます。
次で説明するように、試行とフェイルオーバーは、エラーのタイプおよびQoSに基づきます。
QoSに「ベスト・エフォート」が指定されている場合
実行時例外またはリモート例外がスローされた場合、EJBトランスポートは再試行またはフェイルオーバーを試みます。
JAX-WSエンジンで例外が発生した場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
QoSに「必ず1回」が指定されている場合
実行時例外またはリモート例外がスローされ、継続中のトランザクションが(一般的にEJBコンテナによって)「ロールバックのみ」に設定されている場合、EJBコンテナが影響を受け、EJBコンテナまたはEJBのいずれかで致命的なエラーが発生しています。この場合、再試行またはフェイルオーバーの試みは行われず、エラーはパイプラインで発生します。
実行時例外またはリモート例外がスローされても、継続中のトランザクションが「ロールバックのみ」に設定されていない場合は、EJBコンテナの呼出し前にエラーが発生しており、EJBトランスポートは再試行またはフェイルオーバーを試みます。この場合、EJBトランスポートでは「必ず1回」のセマンティックが引続き適用されることに注意してください。
JAX-WSエンジンで例外が発生し、EJBトランスポートによって継続中トランザクションが「ロールバックのみ」に設定される場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBチェック済例外がスローされた場合、パイプラインに対してエラーが生成され、再試行またはフェイルオーバー試行は行われません。
EJBビジネス・サービスへのQoS仕様のその他の影響については、「EJBトランスポートのトランザクション」を参照してください。
チェック済例外をスローするときに、EJB仕様に応じて、継続中のトランザクションをロールバックのみに指定できます。EJB開発者によって継続中のトランザクションがロールバックのみに設定されている場合、トランザクションは、最終的にその作成者(多くの場合、プロキシ・サービス)によってロール・バックされます。
継続中のトランザクションがロールバックのみに設定されておらず、チェック済例外が発生した場合、エラー・ハンドラによってパイプラインのEJBチェック済例外を捕捉することが重要です。それらの例外が捕捉されない場合、パイプライン・エラーがプロキシ・サービスに逆に伝播されます。次に、一般的にプロキシ・サービスは、継続中のトランザクションを(トランスポートの実装に応じて)ロールバックします。この結果は意図されたものではない場合があります。
たとえば、次のメソッドを持つEJBがあると仮定します。
public void withdrawFunds(float amount) throws RemoteException, InsufficientFundsException {…}
また、InsufficientFundsException例外がスローされたときに、EJBが現在のトランザクションをロールバックのみに設定しないと仮定します。ほとんどのシナリオにおいて、プロキシ・サービスがトランザクションをロール・バックするのは不適切です。場合によっては、パイプラインにエラー・ハンドラを構成して、エラーを捕捉し、このシナリオを回避する必要があります。
EJBトランスポートは、XMLとJava間の変換を行います。変換は、Oracle WebLogic Server JAX-WSエンジンによって実行されます。EJBトランスポートは、次の型をネイティブにサポートしています。
プリミティブ型
XmlObject (Apacheバージョンのみ)
スキーマで生成されるXMLBean (Apacheバージョンのみ、org.apache.xmlbeans.XmlObjectから拡張されたXMLBean)
JavaBeanクラス
ネイティブでサポートされる型の一覧は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAXBデータ・バインディングの使用に関する項を参照してください。
EJBメソッドは、JAX-WSエンジンでサポートされない(設計時にエラーが報告される)、また、XMLに直接マップしない(実行時にエラーが発生する)パラメータ/戻り値の型を使用できます。サポートされない型の中で最もよく使用される型は、次のとおりです。
Object、Object[]
強く型付けされていないJavaコレクション(List、Setなど)
JavaBeanパターンに従わないJavaクラス(Mapなど)
これらの型をXMLとJava間の変換に適した型に変換しなくても、カスタム・コンバータ・クラスを記述できます。
EJBトランスポートでは、XMLBeanタイプ(org.apache.xmlbeans.*)の入力引数または戻り型のセッションBeanがサポートされています。
12.2.1以降、EJBトランスポートでは、デフォルトのバインディング方式としてJAXBを使用するJAX-WSスタックを使用します。JAXBではXMLBeanタイプは解釈されません。EJBトランスポートでのXMLBeanタイプのサポートは、プラグイン・モジュールに依存します。
XMLBeanプラグインの制限事項は次のとおりです。
プラグイン・モジュールを使用して、org.apache.xmlbeans.XmlObjectから拡張されたXMLBeanがサポートされています。
com.bea.xml.*から拡張されたXMLBeanオブジェクトはサポートされていません。
ユーザー定義Javaオブジェクトを含むXMLBeanの使用はサポートされていません。EJBにJavaオブジェクトとXmlbeansが入力引数または戻り型として含まれている場合、EJBトランスポートはランタイム・エラーを返します。
JAX-WSでは、EJBメソッドで入力引数またはメソッド戻り型として使用されるユーザー定義Javaオブジェクトには、パラメータをとらないデフォルトのコンストラクタが必要です。
これは、前のバージョンのService Busで(デフォルト・コンストラクタがない場合でも)機能していたユーザー定義Javaタイプを、デフォルト・コンストラクタに含めるよう変更する必要があることを意味します。詳細は、「ユーザー定義のJavaデータ型のプログラミング」を参照してください。
Service Busは、EJB構造に正確に一致する中間Webサービスを生成します。すべてのEJBとそのデータ型をWebサービスのデータ型にマップできるとは限らないため、コンバータ・クラスを作成して中間Webサービスの形状を変更し、Service Bus側で必要なEJBタイプへのSOAPデータ型の内部変換を有効にすることができます。コンバータ・クラスは、Service BusパブリックAPIのcom.bea.wli.sb.transports.ejb.ITypeConverter Javaインタフェースで定義されるコントラクトを実装して準拠するJavaクラスです。
JAX-WS仕様では、EJBパラメータの特定の基準と、そのパラメータをWebサービス・レイヤーにラップするための戻り型が、データ型の特定の要件とともに必要になります。詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJWSファイルのプログラミングに関する項を参照してください。コンバータ・クラスを使用すると、Webサービス・レイヤーを通じてデータ型を公開する方法でService Bus EJBラッパーをカスタマイズでき、このデータ型は、EJBで必要なデータ型に変化します。ラッパー実装は付属のEJBクライアント・クラスに基づくもので、EJBインタフェースに正確に一致する必要があります。この実装には、(WebLogic ServerのJWSツールセットを使用して作成された)Webサービス・レイヤー経由でアクセスできます。
この項では、EJBビジネス・サービスの設計または実行時の問題のトラブルシューティングについて説明します。
また、「Oracle Service Busアプリケーションのデバッグ」の説明に従って、デバッグを有効化できます。
前のバージョンのService Busでは、EJBトランスポートはベースとなるスタックとしてJAX-RPCを使用していました。このバージョンではJAX-WSを使用しているため、WSDLとの互換性の問題が発生することがあります。JAX-RPCおよびJAX-WSは2つの別の実装であり、相互に互換していません。
JAX-RPCおよびJAX-WSによって生成されたWSDLは、配列をメソッド入力/戻り型として使用する点が異なります。JAX-RPCは配列値の表現にラッパーを使用しますが、JAX-WSは使用しません。
JAX-RPCおよびJAX-WSによって生成されたWSDLは次のとおりです。
JAX-WS生成のWSDL
<xs:complexType name="ArrayOfJavaLangstring_literal">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="JavaLangstring" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="ArrayOfJavaLangstring_literal" type="open:ArrayOfJavaLangstring_literal" xmlns:open="http://www.openuri.org/"/>
<xs:element name="returnNames">
<xs:complexType>
<xs:sequence>
<xs:element name="arg0" type="open:ArrayOfJavaLangstring_literal" xmlns:open="http://www.openuri.org/"/>
</xs:sequence>
</xs:complexType>
</xs:element>
JAX-WS生成のWSDL
<xsd:complexType name="returnNames">
<xsd:sequence>
<xsd:element form="qualified" maxOccurs="unbounded" name="arg0" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
JAX-RPCのWebLogic Server実装では、繰り返される要素をラッパー内にラップします。
<foo>
<param1>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
<JavaLangstring>arrayItemOfp1</JavaLangstring>
</param1>
</foo>
JAX-WSでは、配列にインライン反復要素を使用します。
<foo> <param1>arrayItemOfp1</param1> <param1>arrayItemOfp1</param1> <param1>arrayItemOfp1</param1> </foo>
ビジネス・メソッドString[] returnNames(String[] names)のあるステートレス・セッションBeanでは、JAX-RPC (前のバージョンのService Bus)およびJAX-WS (Service Bus 12.2.1)で生成されたWSDLによって次のリクエスト・ペイロードとレスポンス・ペイロードを想定しています。
JAX-RPCリクエスト
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
</soap:Header>
<soapenv:Body>
<open:returnNames xmlns:open="http://www.openuri.org/">
<open:arg0>
<open:JavaLangstring>John</open:JavaLangstring>
<open:JavaLangstring>Eric</open:JavaLangstring>
<open:JavaLangstring>Mark</open:JavaLangstring>
</open:arg0>
</open:returnNames>
</soapenv:Body>
</soapenv:Envelope>
JAX-RPCレスポンス
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<m:returnNamesResponse xmlns:m="http://www.openuri.org/">
<m:return>
<m:JavaLangstring>John</m:JavaLangstring>
<m:JavaLangstring>Eric</m:JavaLangstring>
<m:JavaLangstring>Mark</m:JavaLangstring>
</m:return>
</m:returnNamesResponse>
</env:Body>
</env:Envelope>
JAX-WSリクエスト
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
</soap:Header>
<soapenv:Body>
<open:returnNames xmlns:open="http://www.openuri.org/">
<open:arg0>John</open:arg0>
<open:arg0>Eric</open:arg0>
<open:arg0>Mark</open:arg0>
</open:returnNames>
</soapenv:Body>
</soapenv:Envelope>
JAX-WSレスポンス
<S:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns0:returnNamesResponse xmlns:ns0="http://www.openuri.org/">
<ns0:return>John</ns0:return>
<ns0:return>Eric</ns0:return>
<ns0:return>Mark</ns0:return>
</ns0:returnNamesResponse>
</S:Body>
</S:Envelope>
生成されたWSDLでの差異により、リクエスト・ペイロードに適用されるXPath関数は、動作が異なる場合があります。この差異に対応するよう、XPath関数を修正します。
EJBトランスポートは設計時に、tempディレクトリのサブフォルダにファイルを生成します。それらのフォルダとファイルを削除すると安全です。また、アクティブ化の際の問題を判断するためにそれらを確認すると役に立つ場合があります。
EJBビジネス・サービスが作成およびアクティブ化されると、Service Busサーバーにアプリケーションがデプロイされます。Oracle WebLogic Server管理コンソールとFusion Middleware Controlを使用して、このアプリケーションを監視およびチューニングできます。
EJBビジネス・サービスに関する問題のトラブルシューティングが必要な場合に、次の情報が役立つことがあります。
ビジネス・サービスの作成時に次のエラーが発生した場合、その原因はWindowsオペレーティング・システムの制限です。255文字を超える文字を含むパスはサポートされていません。
The system cannot find the path specified):Probably the string length of the path of the file being extracted was too long
Service Busドメインへの短いパスを作成することで、パスの長さを短くできます。また、サーバーの起動時に、次のオプションを使用してOracle WebLogic Serverのtempディレクトリをオーバーライドすることもできます。
-Dweblogic.j2ee.application.tmpDir=$desired_short_dir
EJBビジネス・サービスの呼出し時にXMLマーシャリング・エラーを受け取り、リクエストがサービスのWSDLドキュメントに対し有効であるという確信がある場合は、コンバータ・クラスを記述することが必要になる可能性があります。詳細は、「カスタム・コンバータ・クラス」を参照してください。
リモート・サーバーで、EJBインタフェースおよびスタブが変更された場合、新しいEJBの初回の呼出し時にエラーがスローされます。リモート・サーバーでのEJBインタフェースおよびスタブの変更はService Busに表示されないため、Service Busは、有効ではなくなった、キャッシュされているEJBを呼び出そうとします。ただし、呼出しエラーが発生すると、トランスポートはそれらのスタブが無効になったと見なし、それらをキャッシュから削除します。次回以降にEJBの呼出しを試行したときのエラーは、このような方法で回避されます。この初回時のエラーを回避するには、Oracle Service BusコンソールでJNDIプロバイダをリセットします。
EJBビジネス・サービスはトランスポート型付きのサービスです。つまり、トランスポートのタイプはサービスの構成によって決まります。EJBビジネス・サービスのタイプは、SOAP XMLサービスに相当します。
つまり、他のSOAP XMLビジネス・サービスと同様にEJBビジネス・サービスを使用できます。EJBトランスポート構成を保存すると、Service BusによってWSDLファイルが生成されます。生成されるWSDLファイルは、EJBのインタフェースに基づいています。EJBトランスポートの構成ページは、サービスのインタフェースと生成されるWSDLファイルを制御するための構成オプションを提供します。
ビジネス・サービス内では、次のURIパターンを、EJBトランスポートのエンドポイントURIに使用します。
ejb:jndi_provider_name:ejb_jndi_name
ここで、jndi_provider_nameは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を次のいずれかの形式にしてください。
cell/nodes/node_name/servers/server_name/ejb_jndi_name
または
cell/clusters/cluster_name/ejb_jndi_name
詳細は、IBM WebSphereのドキュメントを参照してください。
次の表に、ビジネス・サービス用のEJBトランスポートの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。
表28-1 ビジネス・サービス用のEJBトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
呼出し元のサブジェクトを渡す |
EJBの呼出し時にサービス・アカウントが構成されていない場合、このチェック・ボックスを選択して、Service Busがプロキシ・サービスから認証されたサブジェクトを渡すようにします。これはサービス・アカウントの使用にかわる方法であり、このオプションを選択すると、「サービス・アカウント」フィールドが無効になります。 |
サービス・アカウント |
サービスにアクセスするための認証に使用するサービス・アカウントを入力します。サービス・アカウントを指定しない場合は、匿名サブジェクトが使用されます。「呼出し元のサブジェクトを渡す」オプションを選択した場合、このオプションは使用できません。 詳細は、「サービス・アカウントの操作」を参照してください。 |
トランザクションをサポートする |
EJBがトランザクションをサポートすることを指定する場合、このチェック・ボックスを選択します。 |
EJB 3.0 |
インタフェースがEJBバージョン3.0を使用する場合、このチェック・ボックスを選択します。 |
クライアントJar |
「参照」をクリックし、使用可能なリソースのリストからEJBクライアントJARリソースを選択します。 |
コンバータJar |
「参照」をクリックし、使用可能なオプションのリストからEJBコンバータ・クラスJARリソースを選択します。このフィールドは、前述のクライアントJARファイルを選択した後に表示されます。 詳細は、「クライアントJARまたはコンバータJARの追加」および「カスタム・コンバータ・クラス」を参照してください。 |
ホーム・インタフェース |
JARファイルによって移入されたオプションから必要なEJBHomeインタフェースを選択します。このフィールドは、EJB 2.1でのみ使用可能です。 このURIサンプルのJNDI名はここで選択するEJBHomeインタフェースに関連付ける必要があります。EJBが必要なタイプのものではない場合またはEJBHomeインタフェースがクライアントJARファイルで指定されていない場合は、警告が表示されます。 |
リモート・インタフェース |
リモート・インタフェースが表示され、ホーム・インタフェースの構成に基づいて、情報が自動的に移入されます。EJB 2.1でのみ使用可能です。 |
ビジネス・インタフェース |
呼び出すクライアントJARでビジネス・インタフェースを選択します。このフィールドは、EJB 3.0でのみ使用可能です。 |
対象ネームスペース |
JARファイルから選択された情報に基づいて決定されたネームスペースを表示します。このフィールドは、EJB 3.0を選択し、クライアントJARファイルを指定した場合のみ表示されます。 |
スタイル |
要件に応じて、「ドキュメントをラップ」または「RPC」を選択します。ステートレス・セッションEJBの2つ以上のメソッドに、同じ数の同じデータ・タイプのパラメータがあり、操作をドキュメント指向にする場合はドキュメントのラップを指定します。 EJBへのルーティングまたはパブリッシュの場合、 RPCスタイルがJAX-WSでサポートされていますが、新しいEJBエンドポイントには「ドキュメントをラップ」することをお薦めします。既存のEJBビジネス・サービスでは、引き続きRPCスタイルを使用できます。 |
エンコーディング |
SOAPメッセージのエンコーディングとして、「エンコード形式」または「リテラル形式」を指定します。 |
メソッド |
選択したEJBリモートまたはビジネス・インタフェースのメソッドを構成します。必要なメソッドを選択します(複数のメソッドの選択も可能)。構成するメソッドを展開した後、デフォルトのパラメータ値を編集して、提供されている場合(または必要な場合)はコンバータを選択します。 各メソッドのデフォルトの操作名を変更できます。デフォルトでは、操作名はメソッド名です。EJBに同じ名前のメソッドが含まれている場合、一意になるように操作名を変更する必要があります。WSDLファイルは一意の操作名を必要とします。 追加または除外するメソッドを選択できます。JAX-WSスタックでサポートされないパラメータまたは戻り値の型を持つメソッドを除外するか、それらの引数をコンバータ・クラスに関連付ける必要があります。 注意: EJBのメソッド間で資格証明またはトランザクション設定が異なる場合、特定のビジネス・サービスのメソッドをカスタマイズして、メソッドごとのビジネス・サービスを作成できます。これにより、トランザクションと資格証明の詳細な制御が可能になります。 |
例外 |
メソッドによってスローされるすべてのビジネス例外を表示します。EJBメソッドが、ArrayListなどのJava Web Services (JWS)でサポートされないデータ型を持つ例外をスローした場合は、「例外」フィールドを使用して、例外をJWSでサポートされる型に変換するコンバータ・クラスを選択します。 コンバータ・クラスは、 |
