| Oracle® Fusion Middleware Oracle Infrastructure Webサービス開発者ガイド 11g リリース1(11.1.1) B61390-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Infrastructure Webサービス開発者ガイド 11g リリース1(11.1.1) B61390-05 |
|
前 |
次 |
この章では、非同期Webサービスの概念の概要を示し、非同期Webサービスを開発および構成する方法について説明します。
この章の内容は次のとおりです。
Webサービスを同期的に起動した場合、起動側のクライアント・アプリケーションは、レスポンスが戻るのを待機してから処理を続行する必要があります。このようなWebサービスの起動方法は、レスポンスが即時に戻るような場合には適しています。しかし、リクエスト処理が遅延する場合もあるため、クライアント・アプリケーションは先に処理を続行し、後でレスポンスを処理するほうが効率的なことも少なくありません。Webサービスを非同期的にコールすれば、クライアントはその処理を間断なく続行でき、非同期レスポンスが戻されたときに通知を受けることができます。
次の各項で、非同期メッセージ・フローのダイアグラムをいくつか示し、クライアント側から見た全体像を示します。また、非同期メッセージが互いにどのように関連しているかを説明します。
|
注意: 単一のリクエスト・キューを使用した場合、パフォーマンスは高くなる可能性はありますが、リクエスト・キューとレスポンス・キューを使用した場合よりも信頼性が低くなります。単一のリクエスト・キューを使用するのではなく、「リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス」で説明されているように、リクエスト・キューとレスポンス・キューを使用することをお薦めします。 |
このシナリオでは、リクエストとレスポンスの両方の処理を実行する単一のメッセージドリブンBean(MDB)がリクエスト・キューに関連付けられています。
次の図は、単一のリクエスト・キューを使用した非同期メソッド・コールのフローを示しています。
前出の図に示されたフローについて次に説明します。
クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。
非同期Webサービスは受信確認をクライアントに送信します。
リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。
リクエストMDBは、Webサービス実装の必須メソッドをコールします。
Webサービス実装がレスポンスを返します。
リクエストMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは受信確認メッセージを返します。
リクエストMDBは確認メッセージをリクエスト・キューに返して、プロセスを終了します。
このシナリオでは、コールバック・サービスへの接続(ステップ7)に問題がある場合、レスポンスは送信されません。後でリクエストが再試行される場合は、ステップ4からフローが再開し、再びWebサービス実装がコールされます(ステップ5)。このような動作は、アプリケーション・ロジックやトランザクション制御処理によっては望ましくないことがあります。次のシナリオでは、レスポンスが別のレスポンス・キューに格納されるため、最初にコールバック・サービスが使用可能になっていなくても、Webサービス実装を再びコールする必要がありません。
このシナリオでは、2つのMDBを使用し、それぞれがリクエスト処理とレスポンス処理を行います。このシナリオでは、ビジネス・ロジックの実行をレスポンスの返却と分離することにより、「単一のリクエスト・キューを使用した非同期Webサービス」で説明されている単一キューのモデルよりもエラー・リカバリを向上させています。
次の図は、単一のリクエスト・キューを使用した非同期メソッド・コールのフローを示しています。
前出の図に示されたフローについて次に説明します。
クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。
非同期Webサービスは受信確認をクライアントに送信します。
リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。
リクエストMDBは、Webサービス実装の必須メソッドをコールします。
Webサービス実装がレスポンスを返します。
リクエストMDBがレスポンスをレスポンス・キューに保存します。
リクエストMDBはリクエスト・キューに確認を送信して、プロセスを終了します。
レスポンス・キューのonMessageリスナーがレスポンスの処理を開始します。
レスポンスMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは受信確認メッセージを返します。
レスポンスMDBは確認メッセージをレスポンス・キューに返して、シーケンスを終了します。
クライアントから見ると、非同期メソッド・コールは次の図のように2つの一方向メッセージ交換で構成されています。
前出の図に示したように、クライアントは非同期コールを開始する前に、非同期Webサービスからのレスポンスをリスニングするためのコールバック・サービスをデプロイする必要があります。
メッセージのフローは次のとおりです。
クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信し、開始クライアントに確認メッセージを送信して、リクエストの処理を開始します。
リクエストの処理が完了すると、非同期Webサービスがクライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは確認メッセージを非同期Webサービスに送信します。
|
注意: メッセージ相関はSOAランタイムによって自動的に処理されます。この項の説明は参考情報です。 |
コールバック・サービスはレスポンスの受信時に、レスポンスと元のリクエストを相互に関連付ける必要があります。これは、SOAランタイムによってWS-Addressingを介して自動的に行われます。
クライアントは、SOAPヘッダーのWS-Addressing部分に次の2つのフィールドを設定します。
ReplyToアドレス: コールバック・サービスのアドレス。
MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。
コールバック・クライアントは、WS-AddressingヘッダーのrelatesToIdフィールド内の初期リクエストに対応するMessageIdを送信します。コールバック・サービスでレスポンス処理に追加データが必要となる場合、クライアントは次のタスクのいずれかを実行できます。
クライアントは、データをReplyToフィールド内の参照パラメータとして送信できます。非同期Webサービスでは、レスポンスで参照パラメータがすべて返されるため、コールバック・サービスで情報へのアクセスが可能となります。
データを非同期リクエスト・メッセージの一部として送信することが実行可能でない場合、クライアントは、ローカル・データ・ストアに必要なMessageIDとデータを保存できます。
ADF Business Componentの非同期Webサービス・メソッドの開発とデプロイは、短時間で簡単に行うことができます。詳細は、Oracle Application Development Frameworkの開発者ガイドの非同期Webサービス・メソッドの生成方法に関する項を参照してください。
次の各項で、非同期Webサービスの実装方法を詳しく説明します。一部は参考情報です。
oracle.webservices.annotations.async.AsyncWebService注釈を使用して、JAX-WS Webサービスを非同期Webサービスとして宣言できます。
次の例は、非同期Webサービスのごく単純なPOJOを示しています。
import oracle.webservices.annotations.PortableWebService import oracle.webservices.annotations.async.AsyncWebService @PortableWebService @AsyncWebService public class HelloService { public String hello(String name) { return "Hi " + name; } }
非同期Webサービスに対して生成されたWSDLには、2つのportTypeとして定義された2つの一方向操作が含まれています(非同期操作用とコールバック操作用)。
例:
<wsdl:portType name="HelloService"> <wsdl:operation name="hello"> <wsdl:input message="tns:helloInput" xmlns:ns1="http://www.w3.org/2006/05/addressing/wsdl" ns1:Action=""/> </wsdl:operation> </wsdl:portType> <wsdl:portType name="HelloServiceResponse"> <wsdl:operation name="helloResponse"> <wsdl:input message="tns:helloOutput" xmlns:ns1="http://www.w3.org/2006/05/addressing/wsdl" ns1:Action=""/> </wsdl:operation> </wsdl:portType>
オプションとして、systemUser引数を使用して、非同期Webサービスへのアクセスのセキュリティを確保するためにシステム・ユーザーも定義できます。指定しない場合、この値はOracleSystemUserにデフォルト設定されます。
例:
@AsyncWebService(systemUser="ABCIncSystemUser')
非同期Webサービスで使用されるリクエスト・キューとレスポンス・キューの保護に関する詳細は、リクエスト・キューおよびレスポンス・キューの保護に関する項を参照してください。
作成した非同期Webサービスをデプロイする前に、まずは次項の説明に従って、リクエストおよびレスポンスを格納するために使用されるキューを作成し、そのセキュリティを確保する必要があります。
次の各項で説明するように、このプロセスは、クラスタ・ドメインか非クラスタ・ドメインのどちらを使用しているかによって異なります。
クラスタ・ドメインの場合は、クラスタごとに2つのJMS共通分散宛先(UDD)を作成する必要があります。デフォルト・キューをクラスタ環境に追加する際は、オフラインWLSTスクリプトを使用できます。
このスクリプトは次の場所にあります。
<MW_HOME>/oracle_common/webservices/bin/jrfws-async-createUDDs.py
このスクリプトの実行例を次に示します。
java -classpath <some_path>/weblogic.jar weblogic.WLST ./jrfws-async-createUDDs.py --domain_home <domain> --cluster <cluster>
非クラスタ・ドメインの場合、oracle.jrf.ws.async_template_11.1.1.jarというWebLogicドメイン拡張テンプレートの一部として、1組のデフォルトのWebLogic JMSキューが用意されています。この拡張テンプレートに含まれているデフォルトのJMSキューは、次のとおりです。
リクエスト・キュー: oracle.j2ee.ws.server.async.DefaultRequestQueue
レスポンス・キュー: oracle.j2ee.ws.server.async.DefaultResponseQueue
基本ドメインの一部として用意されているデフォルトのJMS接続ファクトリであるweblogic.jms.XAConnectionFactoryが、デフォルトで使用されます。
必要なデフォルトのキューを作成するには、Fusion Middleware構成ウィザードを使用してドメインを作成または拡張するときに、「Oracle JRF Webサービスの非同期サービス」を選択します。詳細は、『構成ウィザードによるドメインの作成』を参照してください。
|
注意: このドメイン拡張テンプレートを使用する場合は、必ずJMSモジュール(JRFWSAsyncJmsModule)に、ドメイン内の非クラスタ・サーバーを必要に応じて1つ以上ターゲットとして明示的に指定します。 |
次のデフォルト値は、デフォルトではJMS配信失敗パラメータ用に構成されています。設定を見直して、使用環境に応じてそれらを変更することをお薦めします。JMS配信失敗パラメータ関連の構成は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の説明に従ってWebLogic Server管理コンソールを使用して変更できます。
「再配信遅延のオーバーライド」の値を900000ミリ秒に設定します。つまり、メッセージ・コンシューマまたは接続ファクトリで指定されている再配信遅延に関係なく、15分間待機した後にロールバックまたはリカバリされたメッセージが再配信されます。
「再配信の制限」の値を100に設定します。この値は、キューに定義されているエラー宛先にメッセージが移されるまでに許可される再配信試行回数を示します。
「有効期限ポリシー」の値を「リダイレクト」に設定します。これにより、期限切れのメッセージは現在の場所からキューに定義されているエラー宛先に移されます。これが有効になっている場合は、対応するエラー宛先が構成されていることを確認してください。
デフォルトのWebLogic JMSキューが要件を満たしていない場合は、次の手順を実行できます。
Oracle WebLogic ServerのJMSのプログラミングに関する項の説明に従って、リクエスト・キューとレスポンス・キューを手動で作成します。
次の注釈を使用して、これらのキューをアプリケーション・コードに追加します。
リクエスト・キュー: oracle.webservices.annotations.async.AsyncWebServiceQueue
詳細は、「@AsyncWebServiceQueue注釈」を参照してください。
レスポンス・キュー: oracle.webservices.annotations.async.ResponseQueue
詳細は、「@AsyncWebServiceResponseQueue注釈」を参照してください。
非同期リクエストは、最初に、非同期の実行のためにリクエストJMSキューに保存されます。メッセージドリブンBean (MDB)は、キューのリクエストにアクセスして、ビジネス・ロジックを実行します。
同時に多数のリクエストを処理する場合、アプリケーション・サーバーはMDBインスタンスのプールを作成します(このプールは、アプリケーションの要件に基づいて構成できます)。プール内のMDBインスタンスが多いほど、スループットは向上します。ただし、使用されるリソース(スレッドやデータベース接続など)は多くなります。厳密なリソース要件は、非同期リクエスト・メッセージの保存に使用される永続ストアのタイプによって異なります。
デフォルトでは、WebLogic Serverは、1つのMDBインスタンスのみでプールを初期化し、実行のためにキューに投入されるリクエストが増えると、プール・サイズを(最大16まで)増やし続けます。最大プール・サイズに達すると、それ以上MDBインスタンスは追加されずに、サーバーは既存のMDBインスタンスが現在実行中のリクエストを完了するまで待機します。
ユーザーは、アプリケーション要件に基づいて、初期プール・サイズおよび最大プール・サイズを構成できます。デフォルト値を使用し、検出したリソースの負荷に基づいて値を調節することをお薦めします。プールで使用されているリソースが多すぎる場合は、最大プール・サイズを小さくできます。システムのリソースに余裕があり、キューで待機中のリクエストが多すぎる場合は、最大プール・サイズを増やすことができます。
リクエスト・キューとレスポンス・キューを作成する(ステップ1)ためのベスト・プラクティスを次に挙げます。
クラスタ内のキューを高可用性およびフェイルオーバーのために構成します。
WebLogic Serverごとに単一のJMSサーバーとWebLogic永続ストアを構成し、ターゲットとしてサーバーのデフォルトの移行可能ターゲットを指定します。
JMSサーバーに対して必要な割当て制限を構成します。
メモリー不足によるエラーを回避するため、各JMSサーバーに対してメッセージの最大割当て制限を構成することをお薦めします。目安として、各メッセージ・ヘッダーでは約512バイトが使用されます。したがって、500,000メッセージの最大割当て制限では、約250MBのメモリーが必要になります。環境で使用可能なメモリー・リソースを考慮して、それに応じた割当て制限を設定してください。
単一のJMSシステム・モジュールを構成し、ターゲットとしてクラスタを指定します。
JMSシステム・モジュールに対して、次の手順を実行します。
単一のサブデプロイメントを構成し、各JMSサーバーを割り当てます。
必要な共通分散宛先を構成し、(前述の)拡張的なサブデプロイメントのターゲット指定を使用してターゲットを定義します。
カスタムの接続ファクトリを構成します。トランザクションが有効になっている場合、接続ファクトリが有効であればトランザクションをサポートする必要があります。WebLogic JMSには、トランザクションをサポートするためのweblogic.jms.XAConnectionFactory接続ファクトリがデフォルトで用意されています。
リクエスト・キューとレスポンス・キューは、Oracle Enterprise Managerを使用すると実行時に変更できます。更新内容を有効にするには、サーバーをいったん停止してから再起動する必要があります。詳細は、Web Servicesのセキュリティおよび管理者ガイドの非同期Webサービスの構成に関する項を参照してください。
|
注意: この項は、ADF Webサービスのみに適用されるものです。SOA Webサービスには適用されません。 |
JMSのリクエスト・キューおよびレスポンス・キューをユーザーベースまたはロールベースのセキュリティ・ポリシーで保護して、これらのリソースへのアクセスを保護することをお薦めします。JMSのリクエスト・キューおよびレスポンス・キューを保護する手順は、次のとおりです。
JMSシステム・ユーザーの構成(オプション)に関する項の説明に従って、任意にJMSシステム・ユーザーを構成することもできます。
JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。通常はデフォルト・ユーザーで十分です。
リクエストとレスポンスのすべてのキューのセキュリティを確保するために、リクエスト・キューとレスポンス・キューの保護を目的としたWLSTスクリプトの実行に関する項の説明に従ってWLSTスクリプトを実行します。
JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。ほとんどの場合、このデフォルト値で十分です。ただし、この値をセキュリティ・レルム内のカスタム・ユーザーに変更する必要がある場合は、@AsyncWebService注釈のsystemUser属性を使用してカスタム・システム・ユーザーを指定できます。例:
@AsyncWebService(systemUser = "ABCIncSystemUser")
この変更を有効にするには、JDeveloperまたはojdeployコマンド・ライン・ユーティリティを使用してアプリケーションEARファイルを再生成する必要があります。@AsyncWebService注釈の詳細は、@AsyncWebService注釈に関する項を参照してください。
アプリケーションのデプロイメントが済んだら、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の非同期 Webサービスに適したJMSシステム・ユーザーの変更に関する項の説明に従って、Oracle Enterprise Manager Fusion Middleware ControlおよびWebLogic Server Administration ConsoleのJMSシステム・ユーザーを変更できます。
リクエスト・キューとレスポンス・キューのセキュリティを確保する際は、オンラインWLSTスクリプトを使用できます。Administration Server接続に関する詳細(URL、ユーザー名およびパスワード)の他に、セキュリティをかけるJMSシステム・モジュール名と割り当てるセキュリティ・ロールを渡してください。
このスクリプトは次の場所にあります。
<MW_HOME>/oracle_common/webservices/bin/secure_jms_system_resource.py
このスクリプトの実行例を次に示します。
java -classpath <some_path>/weblogic.jar weblogic.WLST ./secure_jms_system_resource.py --username <AdminUserName> --password <AdminPassword> --url <AdminServer_t3_url> --jmsSystemResource <JMSSystemResourceName> --role <SecurityRoleToUse>
リクエスト・キューとレスポンス・キューが必要に応じて構成されていることを確認するには、次のタスクのいずれかを実行します。
『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のAdministration Consoleの起動に関する説明に従って、Administration Consoleを起動します。
次のJMSリソースが定義されており、「サービス」→「メッセージング」の順に選択して利用できることを確認します。
JRFWSAsyncJmsServerという名前のJMSサーバー。
必要に応じて、JMSモジュールが、非クラスタ・ドメイン(標準的なキュー)については1つ以上のサーバーをターゲットとして指定していること、またはクラスタ・ドメイン(UDD)についてはそのクラスタをターゲットとして指定していることを確認します。構成ウィザードまたはWLSTを使用してドメインを構成している場合、JMSサーバーは適切にターゲット指定されています。詳細は、デフォルトのWebLogic JMSキューの使用に関する項を参照してください。
JRFWSAsyncJmsModuleという名前のJMSモジュール。
JDNI名がoracle.j2ee.ws.server.async.DefaultRequestQueueのリクエスト・キューとこれに対応するエラー・キュー。
JDNI名がoracle.j2ee.ws.server.async.DefaultResponseQueueのレスポンス・キューとこれに対応するエラー・キュー。
非同期Webサービスがデプロイされていることを確認し、必要があればシステムのメッセージドリブンBean(MDB)がJMS接続先に接続されていることを次のように検証します。
「デプロイ」をクリックします。
「デプロイ」表のアプリケーションを開きます。
EJB直下に、非同期WebサービスのランタイムをサポートするためにWebサービス1件につき2つのシステムMDBが存在していることを確認します。例: <asyncwebservicename>_AsyncRequestProcessorMDBおよび<asyncwebservicename>_AsyncResponseProcessorMDB
表示されている各MDBがJMS接続先に接続されていることを確認します。
「EJB」を選択し、「監視」タブをクリックし、「実行中」タブをクリックします。
「接続ステータス」フィールドが「接続」になっていることを確認します。
キューが正しく作成されなかった場合は、次の手順のいずれかを実行します。
必要なJMSキューを手動で作成して構成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverインフォメーション・ロードマップ』の「メッセージング」を参照してください。
JMSサーバー、JMSモジュールおよび非同期Webサーバー用に作成されたデフォルト・キューを削除し、「デフォルトのWebLogic JMSキューの使用」の説明に従って、クラスタ・ドメインおよび非クラスタ・ドメイン用に指定された手順でもう一度これらを作成します。
|
注意: JMSリソースは、そのドメインの |
次の表に定義されている注釈を使用して、コールバック・サービス(portType)の特性をカスタマイズできます。これらの注釈は、oracle.webservices.annotations.asyncパッケージに含まれています。
表4-1 コールバック・サービスの構成に使用される注釈
| 注釈 | 説明 |
|---|---|
|
|
コールバックportType内の対応する操作のWSDLエンティティの名前をカスタマイズし、メソッドが同期か非同期かを設定します。 |
|
|
コールバック・サービスをコールするときにメッセージ・コンテキスト内で必須となるプロパティを指定します。詳細は、「@CallbackProperties注釈」を参照してください。 |
|
|
レスポンスWebサービス・ポート情報をカスタマイズします。詳細は、「@ResponseWebService注釈」を参照してください。 |
|
|
システム障害などによって実行が異常終了した場合、この非同期メソッドを多重呼出し不変とするか再試行可能とするか指定します。詳細は、@Retry注釈に関する項を参照してください。 |
非同期Webサービス用にSSLを構成するには、次のタスクを実行する必要があります。
keytoolを使用してIDキーストアおよび信頼キーストアを作成します。
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のプライベート キー、デジタル証明書、信頼性のある認証局の取得に関する項を参照してください。
Oracle WebLogic Server Administration Consoleを使用して、キーストア、キーストア・タイプおよびIDキーストアと信頼キーストアのパスワードを構成します。
Oracle WebLogic Server管理コンソールのヘルプのキーストアの構成に関する項を参照してください。
Fusion Middleware Control Enterprise Managerを使用して、Oracle WSM資格証明ストア・プロバイダでのIDキーストアと信頼キーストアのパスワードを構成します。
Web Servicesのセキュリティおよび管理者ガイドの資格証明ストアの構成に関する項を参照してください。
oracle.ws.async.ssl.securityという名前のマップが存在することを確認します。ない場合は、Web Servicesのセキュリティおよび管理者ガイドの資格証明ストアの構成に関する項の説明に従って作成する必要があります。
続いて、次の表で定義されている3つのキー・エントリを作成します。
次の2種類のクライアントが非同期Webサービスをコールできます。
SOA/BPELクライアント: このプロセスは、他の非同期BPELクライアントをコールするプロセスと同じです。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のBPELプロセスからの非同期Webサービスの起動に関する項を参照してください。
WebLogic Java EE JAX-WSクライアント: JDeveloperのWebサービス・プロキシの作成ウィザードを使用して、「非同期として生成」オプションを選択すると、非同期プロキシが生成されます。このウィザードを使用してWebサービス・クライアントを作成する方法の詳細は、JDeveloperのオンライン・ヘルプのWebサービス・プロキシの作成に関する項を参照してください。
次の各項で、非同期クライアントおよび生成されるコールバック・サービスの例を示し、実施する必要のある更新について説明します。
|
注意: 次の各項で説明する手順は、WebLogic JEE JAX-WSクライアントに適用されるものです。SOA/BPELクライアントには適用されません。 |
次の例は、非同期Webサービスをサポートするために生成されるクライアント・コードを示しています。太字で示されているように、クライアント・コードではアウトバウンド・ヘッダー内に2つのフィールドを設定する必要があります。
ReplyToアドレス: コールバック・サービスのアドレス。
MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。
ほとんどの場合は生成されたクライアント・コードに含まれるメッセージIDのUUIDで間に合いますが、このUUIDを更新することもできます。コールバック・サービスを指し示すようにReplyToアドレスを更新する必要があります。
例4-1 非同期クライアント・コードの更新
package async.jrf;
import com.sun.xml.ws.api.addressing.AddressingVersion;
import com.sun.xml.ws.api.addressing.WSEndpointReference;
import com.sun.xml.ws.developer.WSBindingProvider;
import com.sun.xml.ws.message.StringHeader;
import java.util.UUID;
import javax.xml.ws.WebServiceRef;
// !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
// This source file is generated by Oracle tools
// Contents may be subject to change
// For reporting problems, use the following
// Version = Oracle WebServices (11.1.1.0.0, build 090303.0200.48673)
public class HelloServicePortClient
{
@WebServiceRef
private static HelloServiceService helloServiceService;
private static final AddressingVersion WS_ADDR_VER = AddressingVersion.W3C;
public static void main(String [] args)
{
helloServiceService = new HelloServiceService();
HelloService helloService = helloServiceService.getHelloServicePort();
// Get the request context to set the outgoing addressing properties
WSBindingProvider wsbp = (WSBindingProvider)helloService;
WSEndpointReference repl
new WSEndpointReference(
"http://<replace with the URL of the callback service>",
WS_ADDR_VER);
String uuid = "uuid:" + UUID.randomUUID();
wsbp.setOutboundHeaders(
new StringHeader(WS_ADDR_VER.messageIDTag, uuid),
replyTo.createHeader(WS_ADDR_VER.replyToTag));
// Add your code to call the desired methods.
}
}
次の例は、コールバック・サービス・コードを示しています。太字で示されたコードは、クライアントからMessageIDとして送信されたメッセージ・ヘッダーからrelatesToIDを抽出する方法を示しています。
レスポンスを処理してコールバック・サービスをWebサービスとしてデプロイするためのコードを実装する必要があります。デプロイした後は、コールバック・サービスのURLをreplyToフィールドとしてクライアント・コードに追加します。
package async.jrf;
import com.sun.xml.ws.api.addressing.AddressingVersion;
import com.sun.xml.ws.api.message.Header;
import com.sun.xml.ws.api.message.HeaderList;
import com.sun.xml.ws.developer.JAXWSProperties;
import javax.annotation.Resource;
import javax.jws.Oneway;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.xml.bind.annotation.XmlSeeAlso;
import javax.xml.ws.Action;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.soap.Addressing;
// !THE CHANGES MADE TO THIS FILE WILL BE DESTROYED IF REGENERATED!
// This source file is generated by Oracle tools
// Contents may be subject to change
// For reporting problems, use the following
// Version = Oracle WebServices (11.1.1.0.0, build 090303.0200.48673)
@WebService(targetNamespace="http://jrf.async/", name="HelloServiceResponse")
@XmlSeeAlso(
{ async.jrf.ObjectFactory.class })
@SOAPBinding(style=Style.DOCUMENT)
@Addressing(enabled=true, required=true)
public class HelloServiceResponseImpl
{
@Resource
private WebServiceContext wsContext;
private static final AddressingVersion WS_ADDR_VER = AddressingVersion.W3C;
@WebMethod
@Action(input="")
@RequestWrapper(localName="helloResponse",targetNamespace="http://jrf.async/",
className="async.jrf.HelloResponse")
@Oneway
public void helloResponse(@WebParam(targetNamespace="", name="return")
String _return)
{
// Use the sample code to extract the relatesTo id for correlation and then add your rest of the logic
System.out.println("Received the asynchronous reply");
// get the messageId to correlate this reply with the original request
HeaderList headerList = (HeaderList)wsContext.getMessageContext().get(JAXWSProperties.INBOUND_HEADER_LIST_PROPERTY);
Header realtesToheader = headerList.get(WS_ADDR_VER.relatesToTag, true);
String relatesToMessageId = realtesToheader.getStringContent();
System.out.println("RelatesTo message id: " + relatesToMessageId);
// Add your implementation here.
}
}
ポリシーは次の非同期コンポーネントにアタッチできます。
非同期Webサービスをコールするクライアント(「非同期Webサービス・クライアントへのポリシーのアタッチ」を参照)。
非同期Webサービス(「非同期Webサービスおよびコールバック・サービスへのポリシーのアタッチ」を参照)。
非同期コールバック・クライアント(「コールバック・クライアントへのポリシーのアタッチ」を参照)。
非同期コールバック・サービス(「非同期Webサービスおよびコールバック・サービスへのポリシーのアタッチ」を参照)。
非同期Webサービスとクライアント・ポリシーは互いに適合している必要があります。同様に、非同期コールバック・クライアントとコールバック・サービス・ポリシーも互いに適合している必要があります。
ポリシーをコンポーネントにアタッチするには、次のいずれかの方法を使用できます。
設計時に注釈を使用。
実行時にEnterprise Managerを使用。
次の各項で、それぞれの方法について詳しく説明します。
|
注意:
|
設計時には、次の方法を使用してポリシーをアタッチできます。
SOA/BPELクライアントの場合、SOAコンポジット・エディタを使用してポリシーをアタッチできます(『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のポリシーの管理に関する項を参照)。
WebLogic Java EE JAX-WSクライアントの場合、JDeveloperでWebサービス・プロキシの作成ウィザードを使用してポリシーをアタッチできます。このウィザードを使用してWebサービス・クライアントを作成する方法の詳細は、JDeveloperのオンライン・ヘルプのWebサービス・プロキシの作成に関する項を参照してください。
実行時には、Enterprise Managerを使用してポリシーを各クライアント・タイプにアタッチできます(Web Servicesのセキュリティおよび管理者ガイドのWebサービス・クライアントへのポリシーのアタッチに関する項を参照)。
設計時には、ポリシーを非同期Webサービスおよびコールバック・サービスにアタッチするために、表4-3に定義されているいずれかの注釈を使用できます。これらの注釈は、oracle.webservices.annotationsパッケージに含まれています。
表4-3 ポリシーをWebサービスにアタッチするための注釈
| 注釈 | 説明 |
|---|---|
|
@AddressingPolicy |
WS-AddressingポリシーをWebサービスにアタッチします。詳細は、「@AddressingPolicy注釈」を参照してください。 |
|
@ManagementPolicy |
管理ポリシーをWebサービスにアタッチします。詳細は、「@ManagementPolicy注釈」を参照してください。 |
|
@MtomPolicy |
MTOMポリシーをWebサービスにアタッチします。詳細は、「@MtomPolicy注釈」を参照してください。 |
|
@SecurityPolicies |
@SecurityPolicy注釈の配列を指定します。複数のWS-Policyファイルをクラスにアタッチする場合は、この注釈を使用します。詳細は、「@SecurityPolicies注釈」を参照してください。 |
|
@SecurityPolicy |
セキュリティ・ポリシーをWebサービスにアタッチします。詳細は、「@SecurityPolicy注釈」を参照してください。 |
実行時には、Enterprise Managerを使用してポリシーを非同期Webサービスおよびコールバック・サービスにアタッチできます(Web Servicesのセキュリティおよび管理者ガイドのWebサービス・クライアントへのポリシーのアタッチに関する項を参照)。
メッセージ保護ポリシーを非同期Webサービスおよびコールバック・サービスにアタッチする際には、次のガイドラインを使用してください。
コールバック・サービスにメッセージ保護ポリシーを適用する場合は、非同期リクエストにもそのメッセージ保護ポリシーを適用する必要があります。そうしない場合、非同期クライアントの公開暗号化証明書が見つからないことを示すエラーが実行時に返されます。
非同期リクエストにメッセージ保護ポリシーを適用する場合は、コールバック・サービスに同じポリシーを適用する必要はありません。
非同期Webサービスにメッセージ保護ポリシーを適用する場合は、クライアント・キーストア内のクライアント公開暗号化証明書を構成する必要があります。
|
注意: コールバック・クライアントにアタッチしたポリシーは、非同期WebサービスWSDLで通知されます。 |
設計時には、ポリシーを非同期コールバック・クライアントにアタッチするために、表4-4に定義されている注釈のいずれかを使用できます。これらの注釈は、oracle.webservices.annotations.asyncパッケージに含まれています。
表4-4 ポリシーをコールバック・クライアントにアタッチするための注釈
| 注釈 | 説明 |
|---|---|
|
@CallbackManagementPolicy |
管理ポリシーを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントにアタッチします。デフォルトではいずれの管理ポリシーもアタッチされません。詳細は、「@CallbackManagementPolicy注釈」を参照してください。 |
|
@CallbackMtomPolicy |
MTOMポリシーを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントにアタッチします。デフォルトではいずれのMTOMポリシーもアタッチされません。詳細は、「@CallbackMtomPolicy注釈」を参照してください。 |
|
@CallbackSecurityPolicy |
1つ以上のセキュリティ・ポリシーを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントにアタッチします。デフォルトではいずれのセキュリティ・ポリシーもアタッチされません。詳細は、「@CallbackSecurityPolicy注釈」を参照してください。 |
実行時には、Enterprise Managerを使用してポリシーを非同期コールバック・クライアントにアタッチできます(Web Servicesのセキュリティおよび管理者ガイドのWebサービス・クライアントへのポリシーのアタッチに関する項を参照)。
