非同期Webサービスの開発に関する概要

4.1 非同期Webサービスの理解

クライアントは、非同期的なWebサービス呼出しによって中断されることなく、処理を続行できます。

Webサービスを同期的に呼び出す場合、呼出し側のクライアント・アプリケーションは、レスポンスが戻るまで待機してから、処理を続行します。レスポンスが即座に戻る場合であれば、このWebサービス呼出しの方法は適切であると考えられます。しかし、リクエストの処理が遅延する可能性があるため、クライアント・アプリケーションによる処理を続行しレスポンスへの対処は後で行うようにすると便利なことがよくあります。Webサービスを非同期的にコールすれば、クライアントはその処理を間断なく続行でき、非同期レスポンスが戻されたときに通知を受けることができます。

次の各項で、非同期メッセージ・フローのダイアグラムをいくつか示し、クライアント側から見た全体像を示します。また、非同期メッセージが互いにどのように関連しているかを説明します。

4.1.1 単一のリクエスト・キューを使用した非同期Webサービスのフローの理解

1つのリクエスト・キューを使用する非同期Webサービスでは、リクエストとレスポンスの両方を処理するリクエスト・キューに、メッセージドリブンBean(MDB)が1つだけ関連付けられます。

注意:

単一のリクエスト・キューを使用した場合、パフォーマンスは高くなる可能性はありますが、リクエスト・キューとレスポンス・キューを使用した場合よりも信頼性が低くなります。単一のリクエスト・キューを使用するのではなく、「リクエストおよびレスポンス・キューを使用した非同期Webサービスのフローの理解」で説明されているように、リクエスト・キューとレスポンス・キューを使用することをお薦めします。

次のダイアグラムは、単一のリクエスト・キューを使用した非同期Webサービスのフローを示しています。このシナリオでは、リクエストとレスポンスの両方の処理を実行する単一のメッセージドリブンBean (MDB)がリクエスト・キューに関連付けられています。

図4-1 単一のリクエスト・キューを使用した同期Webサービス

「図4-1 単一のリクエスト・キューを使用した非同期Webサービス」の説明

次のステップでは、前の図に示したフローを説明しています。

クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。
非同期Webサービスは受信確認をクライアントに送信します。
リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。
リクエストMDBは、Webサービス実装の必須メソッドをコールします。
Webサービス実装がレスポンスを返します。
リクエストMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは受信確認メッセージを返します。
リクエストMDBは確認メッセージをリクエスト・キューに返して、プロセスを終了します。

このシナリオでは、コールバック・サービスへの接続(ステップ7)に問題がある場合、レスポンスは送信されません。後でリクエストが再試行される場合は、ステップ4からフローが再開し、再びWebサービス実装がコールされます(ステップ5)。このような動作は、アプリケーション・ロジックやトランザクション制御処理によっては望ましくないことがあります。次のシナリオでは、レスポンスが別のレスポンス・キューに格納されるため、最初にコールバック・サービスが使用可能になっていなくても、Webサービス実装を再びコールする必要がありません。

4.1.2 リクエストおよびレスポンス・キューを使用した非同期Webサービスのフローの理解

MDBを2つ使用すると、1つのキュー・モデルでエラーからの回復力が向上します。

次のダイアグラムは、単一のリクエスト・キューを使用した非同期メソッド・コールのフローを示しています。このシナリオでは、2つのMDBを使用し、それぞれがリクエスト処理とレスポンス処理を行います。このシナリオでは、ビジネス・ロジックの実行をレスポンスの返却と分離することにより、「単一のリクエスト・キューを使用した非同期Webサービスのフローの理解」で説明されている単一キューのモデルよりもエラー・リカバリを向上させています

図4-2 リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス

「図4-2 リクエスト・キューおよびレスポンス・キューを使用した非同期Webサービス」の説明

次のステップでは、前の図に示したフローを説明しています。

クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信して、それをリクエスト・キューに格納します。
非同期Webサービスは受信確認をクライアントに送信します。
リクエスト・キューのMDBリスナーがメッセージを受信し、リクエストの処理を開始します。
リクエストMDBは、Webサービス実装の必須メソッドをコールします。
Webサービス実装がレスポンスを返します。
リクエストMDBがレスポンスをレスポンス・キューに保存します。
リクエストMDBはリクエスト・キューに確認を送信して、プロセスを終了します。
レスポンス・キューのonMessageリスナーがレスポンスの処理を開始します。
レスポンスMDBがコールバック・クライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは受信確認メッセージを返します。
レスポンスMDBは確認メッセージをレスポンス・キューに返して、シーケンスを終了します。

4.1.3 クライアントから見た非同期Webサービス・コールの全体像の理解

クライアントは非同期コールを開始する前に、非同期Webサービスからのレスポンスをリスニングするためのコールバック・サービスをデプロイする必要があります。

次のダイアグラムは、クライアントから見た2つの一方向メッセージ交換で構成されている非同期メソッド・コールの全体像のフローを示しています。

図4-3 非同期Webサービス・クライアントのフロー

「図4-3 非同期Webサービス・クライアントのフロー」の説明

前出の図に示したように、クライアントは非同期コールを開始する前に、非同期Webサービスからのレスポンスをリスニングするためのコールバック・サービスをデプロイする必要があります。

次のステップでは、前の図に示したメッセージを説明しています。

クライアントが非同期メソッドをコールします。
非同期Webサービスがリクエストを受信し、開始クライアントに確認メッセージを送信して、リクエストの処理を開始します。
リクエストの処理が完了すると、非同期Webサービスがクライアントとなり、コールバック・サービスにレスポンスを返します。
コールバック・サービスは確認メッセージを非同期Webサービスに送信します。

4.1.4 非同期メッセージの相関処理の理解

コールバック・サービスはレスポンスの受信時に、レスポンスと元のリクエストを相互に関連付ける必要があります。これは、ランタイムによってWS-Addressingを介して自動的に行われます。

注意:

メッセージ相関はランタイムによって自動的に処理されます。この項の説明は参考情報です。

クライアントは、SOAPヘッダーのWS-Addressing部分に次の2つのフィールドを設定します。

ReplyToアドレス: コールバック・サービスのアドレス。
MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。

コールバック・クライアントは、WS-AddressingヘッダーのrelatesToIdフィールド内の初期リクエストに対応するMessageIdを送信します。コールバック・サービスでレスポンス処理に追加データが必要となる場合、クライアントは次のタスクのいずれかを実行できます。

クライアントは、データをReplyToフィールド内の参照パラメータとして送信できます。非同期Webサービスでは、レスポンスで参照パラメータがすべて返されるため、コールバック・サービスで情報へのアクセスが可能となります。
データを非同期リクエスト・メッセージの一部として送信することが実行可能でない場合、クライアントは、ローカル・データ・ストアに必要なMessageIDとデータを保存できます。

4.2 JDeveloperを使用した非同期Webサービスの開発とデプロイについて

JDeveloperを使用すると、ADF Business Componentの非同期Webサービス・メソッドの開発とデプロイは、短時間で簡単に行うことができます。

非同期Webサービス・メソッドの開発およびデプロイの詳細は、Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイドで、非同期Webサービス・メソッドの生成方法を参照してください。

次の各項で、非同期Webサービスの実装方法を詳しく説明します。一部は参考情報です。

4.3 非同期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サービスに関連付けられた操作はすべて非同期となります。特定のメソッドを同期としてマークするには、コールバック・サービスを構成するための注釈で説明されているように、@CalbackMethod注釈を使用します。メソッドを同期的にも非同期的にもコールできるようにする場合は、メソッドを2つ作成して、それぞれに応じた注釈を付ける必要があります。

@AsyncWebServiceおよび@PortableWebService注釈の詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

非同期Webサービスで使用されるリクエスト・キューとレスポンス・キューの保護の詳細は、リクエスト・キューおよびレスポンス・キューの保護を参照してください。

4.4 リクエスト・キューおよびレスポンス・キューの作成

非同期Webサービスをデプロイする前に、リクエストおよびレスポンスの格納に使用するキューを作成し、保護する必要があります。

キューを作成して保護する手順は、次の各項で説明しています。

4.4.1 デフォルトのWebLogic JMSキューの使用

デフォルトのWebLogic JMSキューを使用するプロセスは、クラスタ・ドメインまたは非クラスタ・ドメインを使用しているかに応じて異なります。

この項には次のトピックが含まれます:

4.4.1.1 非クラスタ・ドメインのデフォルトのWebLogic JMSキュー

非クラスタ・ドメインの場合、oracle.jrf.ws.async_template.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サービスの非同期サービス」を選択します。詳細は、構成ウィザードによるWebLogicドメインの作成のグラフィック・モードでのWebLogicドメインの作成を参照してください。

注意:

このドメイン拡張テンプレートを使用する場合は、必ずJMSモジュール(JRFWSAsyncJmsModule)に、ドメイン内の非クラスタ・サーバーを必要に応じて1つ以上ターゲットとして明示的に指定します。

4.4.1.2 デフォルトのJMS配信失敗パラメータのチューニング

次のデフォルト値は、JMS配信失敗パラメータ用に構成されています。設定を見直して、使用環境に応じてそれらを変更することをお薦めします。JMS配信失敗パラメータに関連する構成は、WebLogic Server管理コンソールを使用して変更できます。Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理で、基本JMSシステム・リソースを構成する主なステップを参照してください。

「再配信遅延のオーバーライド」の値を900000ミリ秒に設定します。つまり、メッセージ・コンシューマまたは接続ファクトリで指定されている再配信遅延に関係なく、15分間待機した後にロールバックまたはリカバリされたメッセージが再配信されます。
「再配信の制限」の値を100に設定します。この値は、キューに定義されているエラー宛先にメッセージが移されるまでに許可される再配信試行回数を示します。
「有効期限ポリシー」の値を「リダイレクト」に設定します。これにより、期限切れのメッセージは現在の場所からキューに定義されているエラー宛先に移されます。これが有効になっている場合は、対応するエラー宛先が構成されていることを確認してください。

4.4.2 カスタムのリクエスト・キューおよびレスポンス・キューの作成

デフォルトのWebLogic JMSキューが要件を満たさない場合は、リクエスト・キューとレスポンス・キューをカスタマイズする必要があります。次のステップに従って、リクエスト・キューとレスポンス・キューをカスタマイズしてください。

JMSキューまたはトピックの作成に関する項の説明に従って、リクエスト・キューとレスポンス・キューを手動で作成します。
次の注釈を使用して、これらのキューをアプリケーション・コードに追加します。
- リクエスト・キュー: oracle.webservices.annotations.async.AsyncWebServiceQueue
  
  次に例を示します。
```
@AsyncWebServiceQueue (
    connectionFactory = "weblogic.jms.XAConnectionFactory",
    queue = "oracle.j2ee.ws.server.async.NonDefaultRequestQueue",
    enableTransaction = true
    transactionTimeout=3600
)
```
  @AsyncWebServiceQueueの詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。
- レスポンス・キュー: oracle.webservices.annotations.async.AsycnWebServiceResponseQueue
  
  次に例を示します。
```
@AsyncWebServiceResponseQueue (
    connectionFactory = "weblogic.jms.XAConnectionFactory",
    queue = "oracle.j2ee.ws.server.async.NonDefaultResponseQueue",
    enableTransaction = true
)
```
  @AsyncWebServiceResponseQueueの詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

4.4.3 カスタムのリクエスト・キューおよびレスポンス・キューについて

デフォルトのWebLogic JMSキューが要件を満たさない場合は、リクエスト・キューとレスポンス・キューをカスタマイズする必要があります。

非同期リクエストは、最初に、非同期の実行のためにリクエストJMSキューに保存されます。メッセージドリブンBean (MDB)は、キューのリクエストにアクセスして、ビジネス・ロジックを実行します。

同時に多数のリクエストを処理する場合、アプリケーション・サーバーはMDBインスタンスのプールを作成します(このプールは、アプリケーションの要件に基づいて構成できます)。プール内のMDBインスタンスが多いほど、スループットは向上します。ただし、使用されるリソース(スレッドやデータベース接続など)は多くなります。厳密なリソース要件は、非同期リクエスト・メッセージの保存に使用される永続ストアのタイプによって異なります。

デフォルトでは、WebLogic Serverは、1つのMDBインスタンスのみでプールを初期化し、実行のためにキューに投入されるリクエストが増えると、プール・サイズを(最大16まで)増やし続けます。最大プール・サイズに達すると、それ以上MDBインスタンスは追加されずに、サーバーは既存のMDBインスタンスが現在実行中のリクエストを完了するまで待機します。

ユーザーは、アプリケーション要件に基づいて、初期プール・サイズおよび最大プール・サイズを構成できます。デフォルト値を使用し、検出したリソースの負荷に基づいて値を調節することをお薦めします。プールで使用されているリソースが多すぎる場合は、最大プール・サイズを小さくできます。システムのリソースに余裕があり、キューで待機中のリクエストが多すぎる場合は、最大プール・サイズを増やすことができます。

4.4.4 カスタムのリクエスト・キューおよびレスポンス・キューの作成のベスト・プラクティス

メッセージドリブンBean (MDB)は、JMSキューのリクエストにアクセスして、非同期リクエストを実行します。

次のリストは、カスタムのリクエスト・キューおよびレスポンス・キューを作成する場合のベスト・プラクティスを示しています(カスタムのリクエスト・キューおよびレスポンス・キューの作成のステップ1)。

クラスタ内のキューを高可用性およびフェイルオーバーのために構成します。
WebLogic Serverごとに単一のJMSサーバーとWebLogic永続ストアを構成し、ターゲットとしてサーバーのデフォルトの移行可能ターゲットを指定します。
JMSサーバーに対して必要な割当て制限を構成します。

メモリー不足によるエラーを回避するため、各JMSサーバーに対してメッセージの最大割当て制限を構成することをお薦めします。目安として、各メッセージ・ヘッダーでは約512バイトが使用されます。したがって、500,000メッセージの最大割当て制限では、約250MBのメモリーが必要になります。環境で使用可能なメモリー・リソースを考慮して、それに応じた割当て制限を設定してください。
単一のJMSシステム・モジュールを構成し、ターゲットとしてクラスタを指定します。
JMSシステム・モジュールに対して、次の手順を実行します。
- 単一のサブデプロイメントを構成し、各JMSサーバーを割り当てます。
- 必要な共通分散宛先を構成し、(前述の)拡張的なサブデプロイメントのターゲット指定を使用してターゲットを定義します。
- カスタムの接続ファクトリを構成します。トランザクションが有効になっている場合、接続ファクトリが有効であればトランザクションをサポートする必要があります。WebLogic JMSには、トランザクションをサポートするためのweblogic.jms.XAConnectionFactory接続ファクトリがデフォルトで用意されています。

4.4.5 実行時のリクエスト・キューおよびレスポンス・キューの変更

リクエスト・キューとレスポンス・キューは、Fusion Middleware Controlを使用して実行時に変更できます。

詳細は、『Webサービスの管理』の非同期Webサービスの構成に関する説明を参照してください。

4.4.6 リクエスト・キューおよびレスポンス・キューの保護

JMSのリクエスト・キューおよびレスポンス・キューをユーザーベースまたはロールベースのセキュリティ・ポリシーで保護して、これらのリソースへのアクセスを保護することをお薦めします。

注意:

この項は、ADF Webサービスのみに適用されるものです。SOA Webサービスには適用されません。

JMSのリクエスト・キューおよびレスポンス・キューを保護するステップは、次のとおりです。

「カスタムのJMSシステム・ユーザーの構成について(オプション)」の説明に従って、任意にJMSシステム・ユーザーを構成することもできます。

JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。通常はデフォルト・ユーザーで十分です。
リクエストとレスポンスのすべてのキューのセキュリティを確保するために、「リクエスト・キューとレスポンス・キューの保護を目的としたWLSTスクリプトについて」の説明に従ってWLSTスクリプトを実行します。

4.4.6.1 カスタムのJMSシステム・ユーザーの構成について(オプション)

JMSキューへのアクセス権限を持つJMSシステム・ユーザーは、デフォルトではOracleSystemUserとして設定されています。ほとんどの場合、このデフォルト値で十分です。ただし、この値をセキュリティ・レルム内のカスタム・ユーザーに変更する必要がある場合は、@AsyncWebService注釈のsystemUser属性を使用してカスタム・システム・ユーザーを指定できます。

次に例を示します。

@AsyncWebService(systemUser = "ABCIncSystemUser")

この変更を有効にするには、JDeveloperまたはojdeployコマンド・ライン・ユーティリティを使用してアプリケーションEARファイルを再生成する必要があります。@AsyncWebService注釈の詳細は、Oracle Infrastructure WebサービスJava APIリファレンスを参照してください。

アプリケーションのデプロイメントが済んだら、『Webサービスの管理』の非同期Webサービスに適したJMSシステム・ユーザーの変更に関する説明に従って、Fusion Middleware ControlおよびWebLogic Server Administration ConsoleのJMSシステム・ユーザーを変更できます。

4.4.6.2 リクエスト・キューとレスポンス・キューの保護を目的としたWLSTスクリプトについて

リクエスト・キューとレスポンス・キューのセキュリティを確保する際は、オンライン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>

4.4.7 リクエストおよびレスポンスのキュー構成の確認

要件を満たすように、リクエスト・キューとレスポンス・キューを構成する必要があります。

リクエスト・キューとレスポンス・キューが必要に応じて構成されていることを確認するには、次のタスクのいずれかを実行します。

『Oracle WebLogic Server WebLogic Webサービスの理解』の管理コンソールの呼出しに関する項の説明に従って、管理コンソールを呼び出します。
次の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接続先に接続されていることを次のように検証します。
1. 「デプロイメント」をクリックします。
2. 「デプロイ」表のアプリケーションを開きます。
3. EJB直下に、非同期WebサービスのランタイムをサポートするためにWebサービス1件につき2つのシステムMDBが存在していることを確認します。例: <asyncwebservicename>_AsyncRequestProcessorMDBおよび<asyncwebservicename>_AsyncResponseProcessorMDB
4. 表示されている各MDBがJMS接続先に接続されていることを確認します。
5. 「EJB」を選択し、「監視」タブをクリックし、「実行中」タブをクリックします。
6. 「接続ステータス」フィールドが「接続」になっていることを確認します。
7. キューが正しく作成されなかった場合は、次のいずれかを実行します。
  
  必要なJMSキューを手動で作成して構成します。詳細は、『Oracle WebLogic Serverインフォメーション・ロードマップ』の「メッセージング」を参照してください。
  
  または
  
  JMSサーバー、JMSモジュールおよび非同期Webサーバー用に作成されたデフォルト・キューを削除し、「デフォルトのWebLogic JMSキューの使用」の説明に従って、クラスタ・ドメインおよび非クラスタ・ドメイン用に指定されたステップでもう一度これらを作成します
  
  注意:
  
  JMSリソースは、そのドメインのconfig.xmlファイルに格納されます。

4.5 コールバック・サービスを構成するための注釈

次の表に定義されている注釈を使用して、コールバック・サービス(portType)の特性をカスタマイズできます。これらの注釈は、oracle.webservices.annotations.asyncパッケージに含まれています。

表4-1 コールバック・サービスの構成に使用される注釈

注釈	説明
`@CallbackMethod`	コールバックportType内の対応する操作のWSDLエンティティの名前をカスタマイズし、メソッドが同期か非同期かを設定します。次に例を示します。 @CallbackMethod(exclude=true)
`@CallbackProperties`	コールバック・サービスをコールするときにメッセージ・コンテキスト内で必須となるプロパティを指定します。次に例を示します。 @CallbackProperties( { @Property( key = SecurityConstants.ClientConstants.WSS_CSF_KEY, value = "basic.credentials") } )
`@Property`	コールバック・サービスをコールするときにメッセージ・コンテキスト内で必須となるプロパティを指定します。次に例を示します。 @CallbackProperties( { @Property( key = SecurityConstants.ClientConstants.WSS_CSF_KEY, value = "basic.credentials") } )
`@ResponseWebService`	レスポンスWebサービス・ポート情報をカスタマイズします。
`@Retry`	システム障害などによって実行が異常終了した場合、この非同期メソッドを多重呼出し不変とするか再試行可能とするか指定します。デフォルトでは、すべての非同期メソッドは多重呼出し不変で、これは非同期メソッドを2回以上コールしても副次的な影響がないことを意味します。非同期メソッドが多重呼出し不変でない場合は、明示的にこの注釈の`enable`属性に`false`を設定する必要があります。

4.6 非同期WebサービスのためのSSL構成

非同期WebサービスにSSLを構成するために実行する必要があるタスクがいくつかあります。

実行に必要なタスクは、次のとおりです。

keytoolを使用してIDキーストアおよび信頼キーストアを作成します。

『Oracle WebLogic Serverセキュリティの管理』の秘密キー、デジタル証明書、信頼性のある認証局の取得に関する項を参照してください。
Oracle WebLogic Server Administration Consoleを使用して、キーストア、キーストア・タイプおよびIDキーストアと信頼キーストアのパスワードを構成します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する説明を参照してください。
Fusion Middleware Controlを使用して、OWSM資格証明ストア・プロバイダでのIDキーストアと信頼キーストアのパスワードを構成します。
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の資格証明ストアの構成に関する説明を参照してください。

oracle.ws.async.ssl.securityという名前のマップが存在することを確認します。存在しない場合は、これを作成する必要があります。

次に示されている3つのキー・エントリを作成します。
- ユーザー名asyncおよびパスワード<trust_store_password>を持つtrust-keystore-password
- ユーザー名asyncおよびパスワード<identity_store_password>を持つidentity-keystore-password
- ユーザー名asyncおよびパスワード<key_password>を持つkey-password

4.7 非同期Webサービス・クライアントの定義

非同期Webサービスを呼び出せるクライアントは、SOA/BPELクライアントとWebLogic Java EE JAX-WSクライアントの2種類です。

SOA/BPELクライアント: このプロセスは、他の非同期BPELクライアントをコールするプロセスと同じです。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のBPELプロセスからの非同期Webサービスの起動に関する項を参照してください。
WebLogic Java EE JAX-WSクライアント: JDeveloperのWebサービス・プロキシの作成ウィザードを使用して、「非同期として生成」オプションを選択すると、非同期プロキシが生成されます。ウィザードを使用したWebサービス・クライアントの作成の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のWebサービス・クライアントの作成に関する項を参照してください。

次の各項で、非同期クライアントおよび生成されるコールバック・サービスの例を示し、実施する必要のある更新について説明します。

注意:

次の各項で説明するステップは、WebLogic Java EE JAX-WSクライアントに適用されるものです。SOA/BPELクライアントには適用されません。

4.7.1 非同期クライアント・コード

クライアント・コードを使用して、非同期Webサービスをサポートできます。

次の例は、非同期Webサービスをサポートするために生成されるクライアント・コードを示しています。太字で示されているように、クライアント・コードではアウトバウンド・ヘッダー内に2つのフィールドを設定する必要があります。

ReplyToアドレス: コールバック・サービスのアドレス。
MessageID: リクエストを識別する一意のID。たとえば、UUIDなどです。

ほとんどの場合は生成されたクライアント・コードに含まれるメッセージIDのUUIDで間に合いますが、このUUIDを更新することもできます。コールバック・サービスを指し示すようにReplyToアドレスを更新する必要があります。

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;
 
// !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 (12.x.x.x.x, build 090303.0200.48673)
 
public class HelloServicePortClient
{
  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.
  }
}

4.7.2 コールバック・サービス・コード

コールバック・サービス・コードを使用すれば、コールバック・サービスをWebサービスとして使用できます。

次の例は、コールバック・サービス・コードを示しています。太字で示されたコードは、クライアントから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 (12.x.x.x.x, 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.
  }
}

4.8 非同期Webサービスおよびクライアントへのポリシーのアタッチ

非同期Webサービスとクライアント・ポリシーは互いに適合している必要があります。同様に、非同期コールバック・クライアントとコールバック・サービス・ポリシーも互いに適合している必要があります。

注意:

Webサービスの信頼性のあるメッセージング(WS-ReliableMessaging)は、Oracle Infrastructureの非同期Webサービスではサポートされていません。つまり、設計時に@ReliabilityPolicy注釈を使用して、また実行時にFusion Middleware ControlまたはWLSTを使用して、信頼性のあるメッセージング・ポリシーを非同期Webサービスまたはコールバック・クライアントにアタッチできません。

ポリシーをコンポーネントにアタッチするには、次のいずれかの方法を使用できます。

設計時に注釈を使用。
実行時にFusion Middleware ControlまたはWLSTを使用。

次の各項で、それぞれの方法について詳しく説明します。

注意:

oracle/wsaddr_policyは、再度、非同期のWebサービスまたはクライアントにアタッチする必要はありません。oracle/wsaddr_policyポリシーはデフォルトですべての非同期Webサービスおよびクライアントにアタッチされ、WSDLで通知されます。これは、非同期Webサービスの処理で必要となるためです。しかし、Fusion Middleware Controlにはポリシーがアタッチされていることは反映されないため、ポリシーをアタッチする際の使用可能なポリシーリストではこのポリシーが選択可能になっています(『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する説明を参照)。

ポリシーは次の非同期コンポーネントにアタッチできます。

4.8.1 非同期Webサービス・クライアントへのポリシーのアタッチについて

非道Webサービス・クライアントには、様々なポリシーがアタッチされます。

設計時には、次の方法を使用してポリシーをアタッチできます。

SOA/BPELクライアントでは、『Oracle SOA SuiteでのSOAアプリケーションの開発』のポリシーの管理に関する項の説明に従って、SOA Composite Editorを使用してポリシーをアタッチできます。
WebLogic Java EE JAX-WSクライアントの場合、JDeveloperでWebサービス・プロキシの作成ウィザードを使用してポリシーをアタッチできます。ウィザードを使用したWebサービス・クライアントの作成の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のWebサービス・クライアントの作成に関する項を参照してください。

実行時には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のFusion Middleware Controlを使用したWebサービスおよびクライアントへのポリシーのアタッチに関する説明に従って、Fusion Middleware Controlを使用してクライアントの各タイプにポリシーをアタッチできます。

4.8.2 非同期コールバック・サービスにアタッチするためのポリシー

クライアントのコールバック・サービスに非同期レスポンスを送信するとき、特定の注釈を使用してポリシーにアタッチできます。

設計時には、クライアントのコールバック・サービスへの非同期レスポンスの送信中にポリシーをアタッチするために、表4-2に定義されているいずれかの注釈を使用できます。

表4-2 ポリシーをWebサービスおよびコールバック・サービスにアタッチするための注釈

注釈	説明
`@CallbackManagementPolicy`	`oracle.webservices.annotations.async.CallbackManagementPolicy`注釈は、管理ポリシーを、クライアントのコールバック・サービスに非同期レスポンスを送信するときにアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackManagementPolicyに関する説明を参照してください。注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明する`oracle.wsm.metadata.annotation.CallbackPolicySet`注釈を使用することをお薦めします。
`@CallbackMtomPolicy`	`oracle.webservices.annotations.async.CallbackMtomPolicy`注釈は、クライアント・コールバック・サービスに非同期レスポンスを送信するときにMTOMポリシーをアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackMtomPolicyに関する説明を参照してください。注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明する`oracle.wsm.metadata.annotation.CallbackPolicySet`注釈を使用することをお薦めします。
`@CallbackPolicySet`	`oracle.wsm.metadata.annotation.CallbackPolicySet`注釈は、1つ以上のポリシー・セットを、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントにアタッチします。デフォルトではいずれのポリシーもアタッチされません。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する説明を参照してください。
`@CallbackSecurityPolicy`	`oracle.webservices.annotations.async.CallbackSecurityPolicy`注釈は、セキュリティ・ポリシーをコールバックWebサービスにアタッチします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackSecurityPolicyに関する説明を参照してください。注意: この注釈は非推奨です。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@CallbackPolicySetに関する項で説明する`oracle.wsm.metadata.annotation.CallbackPolicySet`注釈を使用することをお薦めします。
`@FastInfosetCallbackClient`	`com.oracle.webservices.api.FastInfosetCallbackClient`注釈は、コールバック・サービスに接続される非同期Webサービスのコールバック・クライアントで、Fast Infosetを有効にして、構成します。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の@FastInfosetCallbackClientに関する説明を参照してください。

実行時には、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーのアタッチに関する説明に従って、Fusion Middleware Controlを使用して非同期コールバック・サービスにポリシーをアタッチできます。

メッセージ保護ポリシーを非同期コールバック・サービスにアタッチする際には、次のガイドラインを使用してください。

コールバック・サービスにメッセージ保護ポリシーを適用する場合は、非同期リクエストにもそのメッセージ保護ポリシーを適用する必要があります。そうしない場合、非同期クライアントの公開暗号化証明書が見つからないことを示すエラーが実行時に返されます。

非同期リクエストにメッセージ保護ポリシーを適用する場合は、コールバック・サービスに同じポリシーを適用する必要はありません。
非同期Webサービスにメッセージ保護ポリシーを適用する場合は、クライアント・キーストア内のクライアント公開暗号化証明書を構成する必要があります。

4.8.3 コールバック・クライアントへのポリシーのアタッチについて

Fusion Middleware Controlを使用して、非同期コールバック・クライアントにポリシーをアタッチできます。

詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の非同期Webサービス・コールバック・クライアントへのポリシーのアタッチに関する項を参照してください。

注意:

コールバック・クライアントにアタッチしたポリシーは、非同期WebサービスWSDLで通知されます。