ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JAX-RPC Webサービスの開発
12c (12.1.1)
E48037-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

8 Webサービスの信頼性のあるメッセージングの使用

この章では、WebLogic Java API for XML-based RPC (JAX-RPC) WebサービスにおけるWebサービスの信頼性のあるメッセージングについて説明します。

この章では、以下のトピックについて説明します。


注意:

Webサービスの信頼性のあるメッセージングでは、WebLogic Webサービスの非同期リクエスト-レスポンス機能を使用する必要があります。先に進む前に、第7章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」で説明する概念を理解してください。

Webサービスの信頼性のあるメッセージングの概要

Webサービスの信頼性のあるメッセージングとは、ある1つのアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを確実に呼び出せるフレームワークです。ここでは、双方のサーバーでWS-ReliableMessaging仕様が実装されていることが前提となっています。「信頼性がある」とは、ソフトウェア・コンポーネント、システム、またはネットワークに障害があっても、2つのWebサービス間でメッセージ配信を保証できる状態として定義されます。


注意:

Webサービスの信頼性のあるメッセージングは、WS-ReliableMessaging仕様(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf)が実装された任意の2つのアプリケーション・サーバー間で機能します。ただし、このドキュメントでは、この2つのアプリケーション・サーバーがWebLogic Serverインスタンスであると想定しています。

Webサービスの信頼性のあるメッセージングは、JMSトランスポート機能ではサポートされません。

WebLogic Webサービスは、http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfにあるWS-ReliableMessaging仕様(2007年6月)に準拠しています。この仕様では、別々のアプリケーション・サーバーで実行されている2つのWebサービスが確実に通信できる方法について記述されています。具体的には、この仕様では送信元エンドポイント(つまりクライアントWebサービス)から宛先エンドポイント(つまり操作を確実に呼び出せるWebサービス)へ送信されるメッセージが、1つ以上の配信保証に基づいて確実に配信されるか、そうでなければ必ずエラーが発生する、相互運用性を備えたプロトコルについて説明されています。

信頼性のあるWebLogic Webサービスには、次の配信保証が備わっています。

表8-1 信頼性のあるメッセージングの配信保証

配信保証 説明

At Most Once

メッセージは最大で1回、重複なしに配信されます。メッセージによっては、一度も配信されない可能性もあります。

At Least Once

すべてのメッセージが、少なくとも1回、配信されます。メッセージによっては、1回よりも多く配信される可能性があります。

Exactly Once

すべてのメッセージが、必ず1回重複なしに配信されます。

In Order

メッセージは、送信された順序で配信されます。この配信保証は、上記の3つの保証と組み合せることも可能です。


注意:

Webサービスの信頼性のあるメッセージングでは、非同期メッセージを使用する必要があります。クライアントが信頼性のあるサービスを同期的に呼び出すことはできません。信頼性のあるスタブ・メソッドを呼び出す際には、xyz()ではなくxyzAsync()のような非同期署名を必ず使用してください。SOAPメッセージを直接作成するクライアントのために、非匿名のReplyToアドレスを使用してリクエスト・メッセージを作成します。

ReplyToを匿名URIに設定することはできません。JAX-RPCベースの信頼性のあるサービス操作を呼び出そうとすると(同期スタブ署名を呼び出すか、匿名のReplyToを使用してリクエストを送信することにより)、実行時例外がスローされます。

ここでは、信頼性のあるクライアントWebサービスを作成し、そのWebサービスがデプロイされる2つのWebLogic Serverインスタンスを構成する方法について説明します。Webサービスの信頼性のあるメッセージングのアーキテクチャの詳細は、WS-ReliableMessaging仕様を参照してください(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfを参照)。

WS-Policyを使用した信頼性のあるメッセージング・ポリシーのアサーションの指定

WebLogic Webサービスでは、宛先エンドポイントがWebサービスの信頼性のあるメッセージングの機能と要件を記述および公開できるように、WS-Policyファイルを使用します。WS-Policyファイルは、サポートされているWS-ReliableMessaging仕様のバージョンやサービス品質の要件などが記述されたXMLファイルです。WS-Policy仕様(http://www.w3.org/TR/ws-policy/)では、Webサービスのポリシーを記述して通信するための、汎用的なモデルと構文が提供されています。

WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むあらかじめパッケージ化されているWS-Policyファイルがあります(付録A「信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル」を参照)。あらかじめパッケージ化されているWS-Policyファイルがニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。信頼性のあるメッセージングのポリシー・アサーションに関するリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

信頼性のあるメッセージ・シーケンスのライフサイクルの管理

次の図に、信頼性のあるメッセージの一方向の交換を示します。

図8-1 Webサービスの信頼性のあるメッセージの交換

図8-1の説明が続きます
「図8-1 Webサービスの信頼性のあるメッセージの交換」の説明

信頼性のあるメッセージ・シーケンスは、RM送信元とRM宛先の間で確実に交換されるメッセージ・セットの進捗状況を追跡する際に使用されます。シーケンスは、0個以上のメッセージの送信に使用でき、文字列識別子で識別されます。この識別子は、信頼性のあるメッセージングを使用する際に、そのシーケンスを参照するために使用されます。

Webサービス・クライアント・アプリケーションは、RM送信元がRM宛先へ送信する信頼性のある配信のメッセージを送信します。RM宛先は、信頼性のあるメッセージを受信したことを確認応答し、そのメッセージをWebサービス・アプリケーションに配信します。RM送信元は、確認応答を受け取るまでメッセージを再送信できます。

Webサービス・クライアントは、JAX-RPCスタブに対するメソッドの呼出しを行い、ターゲットWebサービスへメッセージを送信します。スタブは、信頼性のあるWebサービスのポート・タイプに関連付けられており、そのWebサービスのプログラム的なインタフェースを表します。WebLogicでは、このスタブ内に、信頼性のあるメッセージ・シーケンスの識別子が格納されます。これによって、信頼性のあるメッセージ・シーケンスが単一のJAX-RPCスタブに接続されます。特定のスタブを使用して送信されるすべてのメッセージは、そのメッセージの数に関係なく、同じ信頼性のあるメッセージ・シーケンスを使用します。JAX-RPCスタブは、jwsc Antタスクの子要素<clientgenによって作成されます。

WebLogic Serverは信頼性のあるシーケンスと関連付けられたリソースを保持するので、適切なタイミングでこれらのリソースを解放することをお薦めします。WebLogic Serverには、Webサービスの信頼性のあるメッセージングで使用できるユーティリティ・クラスweblogic.wsee.reliability.WsrmUtilsがあります。このクラスを使用すると、構成オプションの設定、シーケンスIDの取得、信頼性のあるシーケンスの終了といった一般的なタスクを実行できます。

通常の状況では、すべてのメッセージが送信され、RM宛先によって確認応答されるまで、信頼性のあるシーケンスを保持する必要があります。シーケンスの適切な終了を容易にするため、信頼性のあるメッセージ・シーケンスの最後のメッセージを識別することをお薦めします。これにより、RM宛先へのメッセージの送信が完了したことがわかり、WebLogic Serverは信頼性のあるシーケンスを自動的に終了する前に最後の確認応答の検索を開始できます。最終メッセージは、weblogic.wsee.reliability.WsrmUtils.setFinalMessage()メソッドを使用し、メッセージの送信に使用されているJAX-RPCスタブをRM宛先に渡して示します。

最後のメッセージを識別すると、最後のメッセージまでのすべてのメッセージが確認応答され、信頼性のあるメッセージ・シーケンスが終了し、すべてのリソースが開放されます。そうでない場合、シーケンスは、構成したシーケンスの有効期限に達した後で自動的に終了します。

これは推奨されませんが、terminateSequence()メソッドを使用すると、すべてのメッセージが確認応答されているかどうかに関係なく、信頼性のあるメッセージ・シーケンスを終了できます。このメソッドを発行すると、このスタブ上で信頼性のあるメッセージをそれ以降送信することはできません。


注意:

JAX-RPCスタブは、最初のメソッドが信頼性のあるWebサービスに対して呼び出された直後まで完全に初期化されません。最初のメソッドが呼び出されると、RM送信元はCreateSequenceメッセージをRM宛先へ送信し、信頼性のあるシーケンスを作成および登録するようRM宛先にリクエストします。その後、RM宛先は新たに作成されたシーケンスについて、そのIDで応答します。RM送信元は、このレスポンスIDを受信するまでRM宛先と通信できず、RM宛先のターゲット・サービスを表すJAX-RPCスタブは使用できません。

信頼性のあるメッセージ・シーケンスに対しては、そのシーケンスが完全に初期化されるまで操作を行うことはできません。信頼性のあるメッセージ・シーケンスが初期化されているかどうかをモニターするには、weblogic.wsee.reliability.WsrmUtils.waitForSequenceInitialization()メソッドを使用します。このメソッドは、信頼性のあるシーケンスが初期化されると、そのシーケンスのIDを返します。

WsrmUtilsユーティリティ・クラスの詳細は、Oracle WebLogic Server Java APIリファレンスのweblogic.wsee.reliability.WsrmUtilsに関する項を参照してください。

Webサービスの信頼性のあるメッセージングの使用: 主な手順

WebLogic Webサービスの信頼性のあるメッセージングを構成するには、JMSサーバーやストア・アンド・フォワード(SAF)・エージェントの作成など標準的なJMSタスクとともに、JWSファイルへのJWSアノテーションの追加などWebサービス固有のタスクを実行する必要があります。また、あらかじめパッケージ化されているファイルを使用しない場合は、必要に応じて、信頼性のあるWebサービスの信頼性のあるメッセージング機能を記述したWS-Policyファイルをユーザー側で作成します。

信頼性のあるWebサービスの呼出しにWebLogicクライアントAPIを使用している場合、クライアント・アプリケーションはWebLogic Server上で実行される必要があります。したがって構成タスクは、信頼性のあるWebサービスを確実に呼び出すクライアント・コードを含むWebサービスがデプロイされたソースWebLogic Serverインスタンスと、信頼性のあるWebサービスそのものがデプロイされた宛先WebLogic Serverインスタンスの双方で実行される必要があります。

次の表では、信頼性のあるWebサービスと、その操作を呼び出すクライアントWebサービスを作成する手順を説明しています。この手順では、2つのWebサービスを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。またこの手順では、ソースWebLogic Serverインスタンスと宛先WebLogic Serverインスタンスの構成方法も示しています。

表8-2 信頼性のあるWebサービスの作成および呼出しの手順

#
 手順 説明

1

宛先WebLogic ServerインスタンスとソースWebLogic Serverインスタンスを構成します。

信頼性のあるWebサービスを宛先WebLogic Serverインスタンスにデプロイします。宛先WebLogic Serverインスタンスの構成については、「宛先WebLogic Serverインスタンスの構成」を参照してください。

信頼性のあるWebサービスを呼び出すクライアントWebサービスを、ソースWebLogic Serverインスタンスにデプロイします。ソースWebLogic Serverインスタンスの構成については、「ソースWebLogic Serverインスタンスの構成」を参照してください。

2

WS-Policyファイルを作成する(オプション)

任意のXMLまたはプレーン・テキスト・エディタを使用し、必要に応じて宛先WebLogic Server上で実行されているWebサービスの信頼性のあるメッセージング機能が記述されたWS-Policyファイルを作成します。独自のWS-Policyファイルを作成する方法の詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。

WebLogic Serverに付属しているいずれかのWS-Policyファイルを使用する場合、この手順は不要です。詳細については、付録A「信頼性のあるメッセージングためのあらかじめパッケージ化されているWS-Policyファイル」を参照してください。

3

信頼性のあるWebサービスを実装するJWSファイルを作成および更新します。

このWebサービスは、宛先WebLogic Serverインスタンスにデプロイされます。「信頼性のあるJWSファイルに関するプログラミングのガイドライン」を参照してください。

4

信頼性のあるWebサービスのコンパイルに使用されるbuild.xmlファイルを更新します。

build.xmlファイルを更新して、信頼性のあるJWSファイルをWebサービスにコンパイルするjwsc Antタスクの呼出しを含めます。

jwscタスクの使用についての一般情報は、「jwsc WebLogic WebサービスAntタスクの実行」を参照してください。

5

信頼性のあるJWSファイルをコンパイルおよびデプロイします。

適切なターゲットを呼び出して信頼性のあるJWSファイルをコンパイルし、宛先WebLogic Serverにデプロイします。例:

prompt> ant build-mainService deploy-mainService

6

信頼性のあるWebサービスを構成します。

管理コンソールを使用して、信頼性のあるWebサービスの信頼性のあるメッセージング・オプションを構成します。「信頼性のあるWebサービスの信頼性のあるメッセージングの構成」を参照してください。

7

クライアントWebサービスを実装するJWSファイルを作成および更新します。

このサービスは、信頼性のあるWebサービスを呼び出し、ソースWebLogic Serverにデプロイされます。「信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」を参照してください。

8

クライアントWebサービスのコンパイルに使用されるbuild.xmlファイルを更新します。

「信頼性のあるWebサービスのクライアント用build.xmlファイルの更新」を参照してください。

9

クライアントJWSファイルをコンパイルおよびデプロイします。

適切なターゲットを呼び出してクライアントJWSファイルをコンパイルし、ソースWebLogic Serverにデプロイします。例:

prompt> ant build-clientService deploy-clientService

以降の項では、これらの各手順について詳細に説明します。

また、以下の高度なトピックについて説明します。

前提条件

以下の作業を完了している必要があります。

  • 宛先と送信元のWebLogic Serverインスタンスを作成しておきます。

  • 各環境でのAntベースの開発環境の設定

  • 編集(jwsc Antタスクを実行して信頼性のある生成済Webサービスをデプロイするためのターゲットの追加など)が可能な作業用のbuild.xmlファイルの用意。

詳細は、『JAX-RPC Webサービスの開発』を参照してください。

宛先WebLogic Serverインスタンスの構成

信頼性のあるWebサービスがデプロイされるWebLogic Serverインスタンスを構成するには、JMSおよびストア・アンド・フォワード(SAF)・リソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡素化できます。詳細は、「Webサービス機能用のドメイン構成」を参照してください。


注意:

または、WLSTを使用してリソースを構成できます。WLSTを使用したドメインの拡張の詳細は、『WebLogic Scripting Toolの理解』の既存ドメインの構成に関する項を参照してください。

Webサービスのリソースを含まないドメインは、Webサービス以外のシナリオおよび非同期のリクエスト/レスポンスが含まれないWebサービス・シナリオにおいて、適切に起動および実行されます。ただし、サーバー・ログに、非同期リソースが構成されていないこと、およびWebサービスの非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表8-3 宛先WebLogic Serverインスタンスを手作業で構成する手順

#
 手順 説明

1

宛先WebLogic Serverが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

各要素の説明は次のとおりです。

  • hostは、管理サーバーが動作しているコンピュータを指します。

  • portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server WebLogic Webサービスの理解』の管理コンソールの起動に関する項を参照してください。

2

永続ファイル・ストアを作成する(オプション)

必要に応じて、宛先WebLogic ServerがWebサービスの信頼性のあるメッセージングの内部情報を格納するために使用する永続ストア(ファイルまたはJDBC)を作成します。新規作成しない場合は、既存のものを使用するか、常に存在するデフォルトのストアを使用できます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのファイル・ストアの作成に関する項を参照してください。

3

JMSサーバーを作成します。

JMSサーバーを作成します。JMSサーバーがすでに存在する場合は、新しいJMSサーバーを作成せずにそれを使用できます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの作成に関する項を参照してください。

4

JMSモジュールを作成し、キューを定義します。

JMSモジュールを作成し、その中にJMSキューを定義します。JMSモジュールがすでに存在する場合は、新しいJMSモジュールを作成せずにそれを使用することもできます。JMSキューを、1つ前の手順で作成したJMSサーバーにターゲット指定します。このJMSキューがローカルであることを必ず指定してください(通常は、ローカルJNDI名の設定により指定できます)。

後で信頼性のあるWebサービスを実装するJWSファイルをプログラムする際に使用するため、JMSキュー用に定義したJNDI名は覚えておく必要があります。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの作成に関する項とシステム・モジュールのキューの作成に関する項を参照してください。

クラスタ化の考慮事項:

クラスタ内でWebサービスの信頼性のあるメッセージング機能を使用する場合は、次の作業を行う必要があります。

  • JMSキューの作成時に、分散キューではなくローカルJMSキューを作成します。

  • このJMSキューをクラスタ内の各サーバーに明示的にターゲット指定します。

5

ストア・アンド・フォワード(SAF)エージェントを作成します。

新規作成しない場合は、既存のものを使用できます。

SAFエージェントを作成する場合は、次の作業を行います。

  • 「エージェントの種類」フィールドを「両方」に設定して、送信エージェントと受信エージェントの双方を有効化します。

  • 最初のアシスタント・ページで、「終了」ではなく「次へ」をクリックして「ターゲットの選択」ページを表示し、必ずSAFエージェントをターゲット指定します。

クラスタ化の考慮事項:

  • クラスタ内で信頼性のあるメッセージングを使用している場合、SAFエージェントをそのクラスタにターゲット指定する必要があります。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェントの作成に関する項を参照してください。

6

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『Oracle WebLogic Serverのパフォーマンスのチューニング』の負荷が高いシステムのチューニングによるWebサービスのパフォーマンス向上に関する項を参照してください。

7

サーバーを再起動します。

構成の変更を有効にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項の説明に従って、サーバーを再起動する必要があります。

ソースWebLogic Serverインスタンスの構成

クライアントWebサービスがデプロイされるWebLogic Serverインスタンスを構成する際には、JMSおよびストア・アンド・フォワード(SAF)・リソースを構成します。

これらのリソースは手作業でも構成できますが、構成ウィザードで、Webサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することもできます。構成ウィザードを使用すると、必要な構成手順を大幅に簡素化できます。詳細は、「Webサービス機能用のドメイン構成」を参照してください。


注意:

または、WLSTを使用してリソースを構成できます。WLSTを使用したドメインの拡張の詳細は、『WebLogic Scripting Toolの理解』の既存ドメインの構成に関する項を参照してください。

Webサービスのリソースを含まないドメインは、Webサービス以外のシナリオおよび非同期のリクエスト/レスポンスが含まれないWebサービス・シナリオにおいて、適切に起動および実行されます。ただし、サーバー・ログに、非同期リソースが構成されていないこと、およびWebサービスの非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージが表示されます。

リソースを手作業で構成する場合、以下の手順を実行します。

表8-4 ソースWebLogic Serverインスタンスの構成手順

#
 手順 説明

1

ソースWebLogic Serverが格納されたドメインの管理コンソールを起動します。

ブラウザで管理コンソールを起動するには、次のURLを入力します。

http://host:port/console

各要素の説明は次のとおりです。

  • hostは、管理サーバーが動作しているコンピュータを指します。

  • portは、管理サーバーが接続リクエストをリスニングしているポート番号を指します。管理サーバーのデフォルトのポート番号は7001です。

『Oracle WebLogic Server WebLogic Webサービスの理解』の管理コンソールの起動に関する項を参照してください。

2

永続ファイル・ストアを作成する(オプション)

必要に応じて、ソースWebLogic ServerがWebサービスの信頼性のあるメッセージングの内部情報を格納するために使用する永続ストア(ファイルまたはJDBC)を作成します。新規作成しない場合は、既存のものを使用するか、常に存在するデフォルトのストアを使用できます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのファイル・ストアの作成に関する項を参照してください。

3

ストア・アンド・フォワード(SAF)エージェントを作成します。

新規作成しない場合は、既存のものを使用できます。

SAFエージェントを作成する場合は、「エージェントの種類」フィールドを「両方」に設定して、送信エージェントと受信エージェントの双方を有効化します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェントの作成に関する項を参照してください。

6

必要に応じて、現在のドメイン環境をチューニングする(オプション)

『Oracle WebLogic Serverのパフォーマンスのチューニング』の負荷が高いシステムのチューニングによるWebサービスのパフォーマンス向上に関する項を参照してください。

7

サーバーを再起動します。

構成の変更を有効にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項の説明に従って、サーバーを再起動する必要があります。

Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成

WS-Policyファイルは、WS-Policy仕様に準拠するポリシー・アサーションを含むXMLファイルです。この場合、WS-PolicyファイルにはWebサービスの信頼性のあるメッセージングのポリシー・アサーションが含まれています。

WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むWS-Policyファイルがあらかじめパッケージ化されています。独自のWS-Policyファイルを作成しない場合は、これらのファイルを使用できます。次の表に、あらかじめパッケージ化されているWS-Policyファイルを示します。


注意:

このリリースでは、DefaultReliability.xmlファイルとLongRunningReliability.xmlファイルは非推奨となっています。DefaultReliability1.1.xml、Reliability1.1_SequenceTransportSecurity、またはReliability1.0_1.1.xmlファイルを使用することをお薦めし、http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfであるWS-ReliableMessaging仕様の1.1バージョンに準拠する必要があります。

表8-5 あらかじめパッケージ化されているWS-Policyファイル

あらかじめパッケージ化されているWS-Policyファイル 説明 
DefaultReliability1.1.xml

サービス品質に関するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。「DefaultReliability1.1.xml (WS-Policyファイル)」を参照してください。

 
Reliability1.1_SequenceTransportSecurity

トランスポート・レベルのセキュリティとサービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいています。「Reliability1.1_SequenceTransportSecurity.xml (WS-Policyファイル)」を参照してください。

 
Reliability1.0_1.1.xml

1.1と1.0のWS Reliable Messagingポリシー・アサーションを結合します。このサンプルは、適切なポリシーの選択に基づいて実行時に適用されるポリシー・アサーションを決定します。「Reliability1.0_1.1.xml (WS-Policy.xmlファイル)」を参照してください

 
DefaultRelibility.xml

非推奨です。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/WS-RMPolicy.pdf)に基づいています。このリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

信頼性のあるメッセージングのポリシー・アサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。「DefaultReliability.xml (WS-Policyファイル) [非推奨]」を参照してください。

 
LongRunningReliability.xml

非推奨です。長期実行プロセスに関して、Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0に基づいています。このリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

1つ前に示した、信頼性のあるメッセージングのデフォルトWS-Policyファイルとほぼ同じですが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定する点が異なります。「LongRunningReliability.xml (WS-Policyファイル) [非推奨]」を参照してください。

WebLogic Serverに含まれる、あらかじめパッケージ化されている信頼性のあるメッセージングWS-Policyファイルの1つを使用できます。これらのファイルは、ほとんどの場合に適合しています。あらかじめパッケージ化されているファイルは変更できません。値がニーズを満たさない場合は、カスタムのWS-Policyファイルを作成する必要があります。以下の節で、カスタムWS-Policyファイルの作成方法を説明します。

WS-ReliableMessagingポリシー・アサーション・バージョン1.1を使用したカスタムWS-Policyファイルの作成

この項では、WS Reliable Messaging Policy Assertion Version 1.1(http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf)に基づいたWebサービスの信頼性のあるメッセージングのアサーションを含むカスタムWS-Policyファイルを作成する方法について説明します。現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

WS-Policyファイルのルート要素は<Policy>であり、次のネームスペース宣言が含まれている必要があります。

<wsp:Policy
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

Webサービスの信頼性のあるメッセージングのポリシー・アサーションはすべて、<wsrmp:RMAssertion>要素の内部でラップします。この要素には、Webサービスの信頼性のあるメッセージングのポリシー・アサーションを使用するため、次のネームスペース宣言が含まれている必要があります。

<wsrmp:RMAssertion
   xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">

次の表に、WS-Policyファイルで指定可能なWebサービスの信頼性のあるメッセージングのアサーションを示します。アサーションの指定順序は重要です。次のアサーションを指定できますが、WS-Policyファイルでは次の一覧の順序どおりに指定する必要があります。

表8-6 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.1)

アサーション 説明 
<wsrmp:SequenceSTR>

信頼性のあるシーケンスでメッセージを保護するため、ランタイムではCreateSequenceメッセージで参照されるwsse:SecurityTokenReferenceが使用されます。指定できるセキュリティ・アサーションは1つのみとなります。つまり、wsrmp:SequenceSTRまたはwsrmp:SequenceTransportSecurityのいずれか1つは指定できますが、両方は指定できません。

 
<wsrmp:SequenceTransportSecurity>

信頼性のあるシーケンスでメッセージを保護するため、ランタイムではCreateSequenceメッセージの送信に使用されるSSLトランスポート・セッションが使用されます。このアサーションは、特定のトランスポート・レベル・セキュリティ・メカニズム(sp:HttpsTokenなど)の使用を要求するsp:TransportBindingアサーションとともに使用する必要があります。指定できるセキュリティ・アサーションは1つのみとなります。つまり、wsrmp:SequenceSTRまたはwsrmp:SequenceTransportSecurityのいずれか1つは指定できますが、両方は指定できません。

 
<wsrm:DeliveryAssurance>

Webサービスの配信保証レベル(配信品質)。有効な値は、AtMostOnce、AtLeastOnce、ExactlyOnceおよびInOrder。次の表に定義されている配信保証のいずれか1つを設定できます。設定しない場合、配信保証にはデフォルトのExactlyOnceが使用されます。

次の例では、簡単なWebサービスの信頼性のあるメッセージングのWS-Policyファイルを示します。

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <wsrmp:RMAssertion
         xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
    <wsrmp:SequenceTransportSecurity/>
    <wsrmp:DeliveryAssurance>
      <wsp:Policy>
        <wsrmp:ExactlyOnce/>
      </wsp:Policy>
    </wsrmp:DeliveryAssurance>
  </wsrmp:RMAssertion>
</wsp:Policy>

WS-Policyファイルにおける信頼性のあるメッセージングのポリシー・アサーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

WS-ReliableMessagingポリシー・アサーション・バージョン1.0を使用したカスタムWS-Policyファイルの作成(非推奨)

この項では、WS Reliable Messaging Policy Assertion Version 1.0(http://schemas.xmlsoap.org/ws/2005/02/rm/WS-RMPolicy.pdf)に基づいたWebサービスの信頼性のあるメッセージングのアサーションを含むカスタムWS-Policyファイルを作成する方法について説明します。


注意:

現在のリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。

WS-Policyファイルのルート要素は<Policy>です。Webサービスの信頼性のあるメッセージングのポリシー・アサーションを使用するには、これに次のネームスペース宣言が含まれていることが必要です。

<wsp:Policy
   xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:beapolicy="http://www.bea.com/wsrm/policy">

Webサービスの信頼性のあるメッセージングのポリシー・アサーションはすべて、<wsrm:RMAssertion要素の内部でラップします。wsrm:ネームスペースを使用するアサーションは、WS-ReliableMessaging仕様(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf)で定義される標準的なアサーションです。beapolicy:ネームスペースを使用するアサーションは、WebLogic固有のものです。詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

次の表に、WS-Policyファイルで指定可能なWebサービスの信頼性のあるメッセージングのアサーションを示します。Webサービスの信頼性のあるメッセージングのアサーションは、すべてオプションなので、デフォルト値が不適切なものだけを設定します。アサーションの指定順序は重要です。次のアサーションを指定できますが、WS-Policyファイルでは次の一覧の順序どおりに指定する必要があります。

表8-7 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.0)

アサーション 説明 
<wsrm:InactivityTimeout>

非アクティブ間隔を定義する、Milliseconds属性で指定されるミリ秒数。この時間が経過した時点で、宛先エンドポイントがソース・エンドポイントからのメッセージを受け取っていなければ、宛先エンドポイントは、処理が行われずシーケンスは終了したものと見なす場合があります。これは、ソース・エンドポイントについても同様のことが言えます。デフォルトでは、シーケンスがタイムアウトすることはありません。

 
<wsrm:BaseRetransmissionInterval>

ソース・エンドポイントがメッセージを送信してから、そのメッセージの確認応答を受け取っていない場合に再送信を行うまでの間隔(ミリ秒単位)。デフォルト値は、ソース・エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。

 
<wsrm:ExponentialBackoff>

再送信の間隔が、指数関数的なバックオフ・アルゴリズムを使用して調整されることを指定します。この要素には属性はありません。

 
<wsrm:AcknowledgmentInterval>

宛先エンドポイントがスタンドアロンの確認応答を送信しなければならない最大間隔(ミリ秒単位)。デフォルト値は、宛先エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。

 
<beapolicy:Expires>

信頼性のあるWebサービスの有効期限が切れ、これ以上の新しいシーケンス・メッセージを受け付けなくなるまでの時間の長さ。デフォルト値では、有効期限が切れることはありません。この要素には、Expiresという1つの属性があります。この属性のデータ型はXMLスキーマ期間型です。(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#durationを参照。)たとえば、有効期限までを1日と設定する場合は、<beapolicy:Expires Expires="P1D" />とします。

 
<beapolicy:QOS>

表8-9で説明されている、配信保証レベル。この要素にはQOSという1つの属性があり、この属性はAtMostOnce、AtLeastOnce、ExactlyOnceの各値のうちの1つに設定します。また、メッセージを順序通りにすることを指定するためにInOrder文字列を含めることもできます。デフォルト値はExactlyOnce InOrderです。この要素は通常、設定されません。

次の例では、簡単なWebサービスの信頼性のあるメッセージングのWS-Policyファイルを示します。

<?xml version="1.0"?>

<wsp:Policy
   xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:beapolicy="http://www.bea.com/wsrm/policy"
  >

 <wsrm:RMAssertion>

   <wsrm:InactivityTimeout
      Milliseconds="600000" />
   <wsrm:BaseRetransmissionInterval
      Milliseconds="500" />
   <wsrm:ExponentialBackoff />
   <wsrm:AcknowledgementInterval
      Milliseconds="2000" />

 </wsrm:RMAssertion>

</wsp:Policy>

WS-Policyファイルにおける信頼性のあるメッセージングのポリシー・アサーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。

複数のポリシー選択肢の使用

カスタム・ポリシー・ファイルを作成することによって、単一のWebサービスに対して複数のポリシー選択肢(適切なポリシー選択肢)を構成できます。実行時には、適用されるポリシーがそれらの中から自動的に選択されます。その際は、サポートされていないポリシーやアサーションが競合しているポリシーが除外され、構成されているプリファレンスに基づいて、受信メッセージの検証とレスポンス・メッセージの構築に適したポリシーが選択されます。

次の例では、1.1と1.0 WSの信頼性のあるメッセージングの両方をサポートするセキュリティ・ポリシーの例を示します。各ポリシー選択肢は、<wsp:All>要素で囲まれています。


注意:

1.0のWebサービスの信頼性のあるメッセージング・アサーションには、接頭辞としてwsrmp10が付加されます。

 

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
  <wsp:ExactlyOne>
    <wsp:All> 
      <wsrmp10:RMAssertion
       xmlns:wsrmp10="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
        <wsrmp10:InactivityTimeout Milliseconds="1200000"/>
        <wsrmp10:BaseRetransmissionInterval Milliseconds="60000"/>
        <wsrmp10:ExponentialBackoff/>
        <wsrmp10:AcknowledgementInterval Milliseconds="800"/>
      </wsrmp10:RMAssertion>
    </wsp:All>
    <wsp:All>
      <wsrmp:RMAssertion
           xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702">
        <wsrmp:SequenceSTR/>
        <wsrmp:DeliveryAssurance>
          <wsp:Policy>
            <wsrmp:AtMostOnce/>
          </wsp:Policy>
        </wsrmp:DeliveryAssurance>
      </wsrmp:RMAssertion>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

複数のポリシー選択肢の詳細は、『Oracle WebLogic Server WebLogic Webサービスの保護』の「メッセージ・レベルのセキュリティの構成」、適切なポリシーの選択に関する項を参照してください。

信頼性のあるJWSファイルに関するプログラミングのガイドライン

この項では、信頼性のあるWebサービスを実装するJWSファイルの作成方法を説明します。

信頼性のあるWebサービスを実装するJWSファイルでは、次のJWSアノテーションが使用されます。

表8-8 信頼性のあるメッセージングのJWSアノテーション

アノテーション 説明 
@weblogic.jws.Policy

必須項目。信頼性のあるメッセージングのアサーションが含まれるWS-PolicyファイルをWebサービスに追加するよう指定します。「@Policyアノテーションの使用」を参照してください。

 
@javax.jws.Oneway

信頼性のあるWebサービス操作を同期的に呼び出す(つまり、非同期リクエスト-レスポンスの機能は使用しない)場合にのみ必須です。「@Onewayアノテーションの使用」を参照してください。

 
@weblogic.jws.BufferQueue

オプション。WebLogic Serverが信頼性のあるメッセージを内部的に格納するために使用するJMSキューのJNDI名を指定します。「@BufferQueueアノテーションの使用」を参照してください。

 
@weblogic.jws.ReliabilityBuffer

オプション。WebLogic ServerによるJMSキューからWebサービス実装へのメッセージ配信試行回数、およびサーバーが待機すべき再試行間隔を指定します。「@ReliabilityBufferアノテーションの使用」を参照してください。

次のサンプルでは、信頼性のあるWebサービスを実装する簡単なJWSファイルを示します。太字で示されたJavaコードに対応するコーディングのガイドラインについては、サンプルの後の説明を参照してください。

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway; 

import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer; 
import weblogic.jws.BufferQueue; 
import weblogic.jws.Policy; 

/**
 * Simple reliable Web Service.
 */

@WebService(name="ReliableHelloWorldPortType",
              serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
      serviceUri="ReliableHelloWorld",
      portName="ReliableHelloWorldServicePort")

@Policy(uri="ReliableHelloWorldPolicy.xml", 
          direction=Policy.Direction.both, 
          attachToWsdl=true) 
@BufferQueue(name="webservices.reliable.queue") 

public class ReliableHelloWorldImpl {

  private static String onewaySavedInput = null;

/**
 * A one-way helloWorld method that saves the given string for later 
 * concatenation to the end of the message passed into helloWorldReturn.
 */
  @WebMethod()
  @Oneway() 
  @ReliabilityBuffer(retryCount=10, retryDelay="10 seconds") 

  public void helloWorld(String input) {
    System.out.println(" Hello World " + input);
    onewaySavedInput = input;
   }

/**
 * This echo method concatenates the saved message from helloWorld 
 * onto the end of the provided message, and returns it.
 */
  @WebMethod()
  @ReliabilityBuffer(retryCount=10, retryDelay="10 seconds") 

  public String echo(String input2) {
    System.out.println(" Hello World " + input2 + onewaySavedInput);
    return input + onewaySavedInput;
  }
}

この例では、カスタムReliableHelloWorldPolicy.xmlポリシー・ファイルがクラス・レベルでWebサービスに追加されています。つまり、ポリシー・ファイルはWebサービスのすべてのパブリック操作に適用されます。ポリシー・ファイルは、リクエストWebサービス・メッセージ(信頼性のあるメッセージング機能によって要求される)のみに適用され、WSDLファイルに追加されます。あらかじめパッケージ化されている利用可能なポリシーおよびカスタム・ポリシーの作成の詳細につぃては、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。

WebLogic Serverが、Webサービスの信頼性のあるメッセージングを有効化するために内部で使用するJMSキューのJNDI名は、@BufferQueueアノテーションで指定されているように、webservices.reliable.queueです。

helloWorld()メソッドは、@WebMethodと@Oneway、どちらのJWSアノテーションでもマークされています。これは、このメソッドがhelloWorldというパブリック操作であるということです。@Policyアノテーションがあるために、操作を確実に呼び出すことができます。@ReliabilityBufferアノテーションに記述されているとおり、Webサービスのランタイムでは、最大で10回、10秒間隔で、信頼性のあるメッセージをサービスに配信しようとします。たとえば、トランザクションがロールバックされる場合や、コミットしない場合などには、メッセージの再配信が必要となることがあります。

echo()メソッドは、@WebMethodとJWSアノテーションでもマークされています。これは、このメソッドがechoというパブリック操作であるということです。@Policyアノテーションがあるために、操作を確実に呼び出すことができます。helloWorld()メソッドと同じような信頼性バッファ構成を使用します。

@Policyアノテーションの使用

信頼性のあるメッセージングのアサーションが含まれるWS-PolicyファイルをWebサービスに追加するよう指定するには、JWSファイルで@Policyアノテーションを使用します。WebLogic Serverでは、あらかじめパッケージ化されているWS-Policyファイルのセットが提供されます。付録A「信頼性のあるメッセージング用にパッケージ化されているWS-Policyファイル」を参照してください。

Webサービスの信頼性のあるメッセージングで@Policyアノテーションを使用する場合は、次のガイドラインに従います。

  • uri属性を使用して、ポリシー・ファイルのビルド時の場所を以下のように指定します。

    • 独自のWS-Policyファイルを作成した場合は、JWSファイルを基準として相対的に場所を指定します。例:

      @Policy(uri="ReliableHelloWorldPolicy.xml",
          direction=Policy.Direction.both,
          attachToWsdl=true)

      この例では、ReliableHelloWorldPolicy.xmlファイルがJWSファイルと同じディレクトリに置かれています。

    • あらかじめパッケージ化されているWS-Policyファイルの1つか、共有Java EEライブラリにパッケージ化されているWS-Policyファイルを指定するには、そのポリシー・ファイルの名前とパスとともにpolicy:接頭辞を使用します。この構文ではビルド時のjwsc Antタスクに、ファイル・システムの実際のファイルを探させず、Webサービスが、サービスのデプロイ時にWebLogic ServerからWS-Policyファイルを取得することを通知しています。


      注意:

      共有Java EEライブラリは、様々なエンタープライズ・アプリケーション内にパッケージ化されている複数のWebサービスとWS-Policyファイルを共有する場合に有用です。WS-Policyファイルが共有Java EEライブラリのMETA-INF/policiesまたはWEB-INF/policiesディレクトリに置かれているかぎり、ポリシー・ファイルはWebサービスの同じアーカイブにパッケージ化されている場合と同様に指定できます。ライブラリの作成、およびWebサービスがポリシー・ファイルを見つけることができるようにするための環境設定については、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

    • ポリシー・ファイルをWeb上で公開するよう指定するには、次の例に示すとおり、URLと共にhttp:接頭辞を使用します。

      @Policy(uri="http://someSite.com/policies/mypolicy.xml"
        direction=Policy.Direction.both,
        attachToWsdl=true)

  • デフォルトでは、WS-Policyファイルはリクエスト(着信)とレスポンス(発信)の両方のSOAPメッセージに適用されます。このデフォルトの動作は、direction属性をPolicy.Direction.inboundまたはPolicy.Direction.outboundに設定すると変更できます。

  • uriで指定されるポリシー・ファイル内でwsp:optional属性を使用し、Webサービスで操作が確実に呼び出され、そのレスポンスが確実に配信されるよう要求するかどうかを指定できます。

    任意の操作での発信に対してoptional属性をfalseに設定する場合:

    • クライアントは、信頼性のあるレスポンスを送信する時使用できるようにofferシーケンスを提供する必要があります。(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfにあるWS-ReliableMessaging仕様で説明されている<wsrm: Offer...>)

    • レスポンスが必要なすべての操作に対してレスポンスが確実に送信されます。

    すべての操作での発信に対してoptional属性をtrueに設定する場合:

    • クライアントはofferシーケンスを提供する必要がありません。

    • クライアントがofferシーケンスを提供する場合、レスポンスは確実に送信され、提供しない場合、レスポンスの送信には信頼性がありません。

  • @PolicyアノテーションのattachToWsdl属性を設定して、ポリシー・ファイルをWebサービスのパブリック規約が記述されたWSDLファイルに付加するかどうかを指定できます。通常は、クライアント・アプリケーションでWebサービスの信頼性のあるメッセージング機能が認識されるよう、パブリックなものとしてポリシーを公開します。そのため、この属性のデフォルト値はtrueです。

@Policyアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.Policyに関する項を参照してください。

@Onewayアノテーションの使用

信頼性のあるWebサービス操作を同期的に呼び出す(すなわち、非同期リクエスト-レスポンス機能を使用しない)場合は、実装メソッドに@Onewayアノテーションを付けて、そのメソッドが一方向のものであることを指定する必要があります。つまり、メソッドは値を戻すことができず、明示的にvoidを戻すことになります。

反対に、メソッドに@Onewayアノテーションが付いていなければ、非同期リクエスト-レスポンス機能を使用して呼び出す必要があります。操作の呼出し方法がわからない場合は、同期と非同期の2種類の操作を作成することを検討してください。

第7章「非同期リクエスト-レスポンスを使用したWebサービスの呼出し」と第11章「非同期機能の併用」を参照してください。

@BufferQueueアノテーションの使用

信頼性のあるメッセージを内部に格納するためにWebLogic Serverが使用するJMSキューのJNDI名を指定するには、@BufferQueueアノテーションを使用します。JNDI名は、「宛先WebLogic Serverインスタンスの構成」のステップ4でのJMSキューの作成時に構成したものです。

@BufferQueueアノテーションは、省略可能です。これをJWSファイルで指定しなければ、WebLogic Serverはweblogic.wsee.DefaultQueueのJNDI名を持つキューを使用します。ただし、それでもこのJNDI名を持つJMSキューを管理コンソールで明示的に作成する必要はあります。

@BufferQueueアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.BufferQueueに関する項を参照してください。

@ReliabilityBufferアノテーションの使用

@ReliabilityBufferアノテーションは、WebLogic ServerによるJMSキューからWebサービス実装へのメッセージ配信試行回数、およびサーバーが待機すべき再試行間隔の指定に使用します。

再試行回数の指定にはretryCount属性を、待機時間の指定にはretryDelay属性を使用します。retryDelay属性の形式としては、数字の後に以下の文字列のうち1つを続けます。

  • seconds

  • minutes

  • hours

  • days

  • years

たとえば、再試行回数を20、再試行の遅延を2日と指定するには、次の構文を使用します。

@ReliabilityBuffer(retryCount=20, retryDelay="2 days")

再試行の回数と遅延のデフォルト値はそれぞれ、3と5です。

@ReliabilityBufferアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.ReliabilityBufferに関する項を参照してください。

信頼性のあるWebサービスの信頼性のあるメッセージングの構成

必要に応じて、アプリケーションのデプロイメント・プランを更新し、weblogic-webservices.xml記述子に格納される、信頼性のあるWebサービスの信頼性のあるメッセージ構成オプションを編集することができます。新しい値は、デプロイメント・プランにより、現在のアプリケーションの記述子における特定の場所に関連付けられます。デプロイメント時に、デプロイメント・プランは変数割当ての値を、その変数のリンク先アプリケーション記述子内の場所に適用することによって、そのアプリケーション内の記述子に結合されます。

次の表では、信頼性のあるWebサービス用に構成できる信頼性のあるメッセージングのオプションを説明しています。

表8-9 信頼性のあるメッセージングの構成オプション

構成オプション 説明

信頼性のあるメッセージ構成のカスタマイズ

Webサービス・エンドポイント・レベルにおけるWebサービス記述子またはデプロイメント・プランで定義された信頼性のあるメッセージ構成をカスタマイズするかどうかを指定するフラグ。このフラグは、Webサービス・エンドポイント・レベルで信頼性のあるメッセージングを構成する場合にのみ使用できます。チェックされない場合、WebLogic Serverに指定された信頼性のあるメッセージ構成が使用されます。

注意:このフラグは、直接WSDLに指定されるWS-RMポリシーなどの他の形式では、信頼性のあるメッセージングの構成を反映しません。

基本の再送信間隔

RM宛先にメッセージの再送信を行うまでの時間間隔。

ソース・エンドポイントが、指定した間隔内で所定のメッセージの確認応答を受信しなかった場合、ソース・エンドポイントはメッセージを再送信します。ソース・エンドポイントは、メッセージのシーケンスの存続期間内の任意の時点で、この再送信間隔を変更することがあります。

この要素を「再送信間隔の指数関数的バックオフ」要素と組み合せて使用すると、再送信間隔を調整するアルゴリズムを指定できます。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT3S (3秒)です。

再送信間隔の指数関数的バックオフの有効化

メッセージの再送信の間隔を、指数関数的なバックオフ・アルゴリズムを使用して調整するかどうかを示すフラグ。

この要素は「基本の再送信間隔」要素と組み合せて使用します。宛先エンドポイントが、「基本の再送信間隔」で指定した時間内でメッセージのシーケンスを確認応答しなかった場合、メッセージが引続き確認されなければ、連続再送信のタイミングに対して、ソース・エンドポイントは指数関数的なバックオフ・アルゴリズムを使用します。

指数関数的なバックオフ・アルゴリズムは、連続再送信の間隔が、基本の再送信間隔を基に指数的に増えるように指定します。たとえば、基本の再送信間隔が2秒で、指数関数的なバックオフ要素が設定されている場合、連続再送信の間隔は、メッセージが確認されなければ、2、4、8、16、32秒というように増えていきます。

デフォルト値はfalseであり、連続再送信の間隔は指数的に増えず、同じ値が維持されます。

確認応答の間隔

宛先エンドポイントがスタンドアロンの確認応答を送信しなければならない最大間隔。

宛先エンドポイントは、ソース・エンドポイントからメッセージを受信した直後に、返されたメッセージに対する確認応答を送信できます。また、スタンドアロンの確認応答として個別に確認応答を送信することもできます。返されたメッセージに対して確認応答を送信できない場合、宛先エンドポイントは、スタンドアロンの確認応答を送信するまで、確認応答の間隔に設定した時間範囲内で待機することがあります。未確認メッセージがない場合、宛先エンドポイントは確認応答を送信しない可能性があります。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT0.2S (200ミリ秒)。

非アクティブ・タイムアウト

非アクティブの間隔。非アクティブ・タイムアウト間隔で、エンドポイント(RM送信元とRM宛先)がアプリケーションのメッセージまたは制御メッセージを受け取らなければ、エンドポイントはRMシーケンスが非アクティブなため終了したものと見なす場合があります。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT600S(600秒)です。

順序の有効期限

アクティビティにかかわらず、シーケンスが期限切れになるまでの時間。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP1D(1日)です。

バッファの再試行回数

信頼性のあるリクエストを再試行する回数。この値のデフォルトは3。

バッファの再試行遅延

信頼性のあるリクエストを再試行するまでの待機時間。

再試行間隔は、JMSキューにあるクライアントのリクエスト・メッセージとWebサービスの実装へのメッセージ配信までの間隔。

指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT5S(5秒)です。

信頼性のあるメッセージング構成オプションは、管理コンソールやWLSTを使用して設定できます。以降の節を参照してください。

管理コンソールの使用

管理コンソールを使用してWebサービス・エンドポイント用の信頼性のあるメッセージングを構成するには:

  1. 『Oracle WebLogic Server WebLogic Webサービスの理解』の管理コンソールの起動に関する項の説明に従って、管理コンソールを起動します。

  2. 左側のナビゲーション・ペインで、「デプロイメント」を選択します。

  3. 「デプロイメント」表でWebサービスの名前をクリックします。

  4. 「構成」タブ、「ポート」タブの順に選択します。

  5. 「ポート」表でWebサービスのエンドポイントの名前をクリックします。

  6. 「信頼できるメッセージ」タブを選択します。

  7. 「信頼性のあるメッセージ構成のカスタマイズ」をクリックし、必要に応じて、指示に従ってデプロイメント・プランを保存します。

  8. 必要に応じて、信頼性のあるメッセージングのプロパティを設定します。

  9. 「保存」をクリックします。

WLSTの使用

WLSTを使用して、信頼性のあるメッセージングを構成するためにアプリケーションのデプロイメント・プランを更新する方法の説明と例は、『WebLogic Scripting Toolの理解』のデプロイメント・プランの更新に関する項を参照してください。

以下の表に、WS-RM構成オプションのXPath値を参考としてまとめます。

表8-10 WS_RM構成変数名とXPath値

構成オプション 変数名の例 XPath値

非アクティブ・タイムアウト

 
ReliabilityConfig_
InactivityTimeout

/weblogic-webservices/webservice-description/
[webservice-description-name="
service_name"]/port-component/
[port-component-name="port_name"]
/reliability-config/inactivity-timeout

基本の再送信間隔

 
ReliabilityConfig_
BaseRetransmission
Interval

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/base-retransmission-interval

再送信間隔の指数関数的バックオフ

 
ReliabilityConfig_
Retransmission
ExponentialBackoff

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]/reliability-
config/retransmission-exponential-backoff

確認応答の間隔

 
ReliabilityConfig_
AcknowledgementInterval

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/acknowledgement-interval

順序の有効期限

 
ReliabilityConfig_
SequenceExpiration

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/sequence-expiration

バッファの再試行回数

 
ReliabilityConfig_
BufferRetryCount

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/buffer-retry-count

バッファの再試行遅延

 
ReliabilityConfig_
BufferRetryDelay

/weblogic-webservices/webservice-description/
[webservice-description-name=
"service_name"]/port-component/
[port-component-name="port-name"]
/reliability-config/buffer-retry-delay

信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン

WebLogicクライアントAPIを使用している場合は、信頼性のあるWebサービスをWebサービス内から呼び出す必要があります。スタンドアロンのクライアント・アプリケーションからは呼び出せません。

次の例では、「信頼性のあるJWSファイルに関するプログラミングのガイドライン」で説明した、サービスから信頼性のある操作を呼び出すWebサービス用の簡単なJWSファイルを示します。

package examples.webservices.reliable;

import java.rmi.RemoteException;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.xml.rpc.Stub;
import weblogic.jws.WLHttpTransport;
import weblogic.jws.ServiceClient; 
import weblogic.jws.ReliabilityErrorHandler; 

import weblogic.jws.AsyncFailure;
import weblogic.jws.AsyncResponse;

import examples.webservices.reliable.ReliableHelloWorldPortType; 

import weblogic.wsee.reliability.ReliabilityErrorContext; 
import weblogic.wsee.reliability.ReliableDeliveryException; 
import weblogic.wsee.reliability.WsrmUtils; 

@WebService(name="ReliableClientPortType",
            serviceName="ReliableClientService")

@WLHttpTransport(contextPath="ReliableClient",
                 serviceUri="ReliableClient",
                 portName="ReliableClientServicePort")

public class ReliableClientImpl
{
  private static String responseMessage = null;

  @ServiceClient( 
     serviceName="ReliableHelloWorldService", 
     portName="ReliableHelloWorldServicePort") 

  private ReliableHelloWorldPortType port; 

  @WebMethod
  public void callHelloWorld(String input, String input2, String serviceUrl)
     throws RemoteException {

    ((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceUrl); 

    port.helloWorld(input); 

    System.out.println(" Invoked the ReliableHelloWorld.helloWorld operation reliably." );
    WsrmUtils.setFinalMessage((Stub)port);
    port.echo(input2);
    System.out.println(" Invoked the ReliableHelloWorld.echo operation reliably." );
  }

  @AsyncResponse(target = "port", operation = "echo")
  public void onEchoAsyncResponse(String msg) {
 
    System.out.println("ClientService: Got async response for request : " + msg);
    responseMessage = msg;
  }
 
  @AsyncFailure(target = "port", operation = "echo")
  public void onEchoAsyncFailure(Throwable t) {
    System.out.println("ClientService: Got async FAILURE for request : " + t);
    t.printStackTrace();
  }

  @ReliabilityErrorHandler(target="port") 
  public void onReliableMessageDeliveryError(ReliabilityErrorContext ctx) { 

    ReliableDeliveryException fault = ctx.getFault(); 
    String message = null; 
    if (fault != null) { 
      message = ctx.getFault().getMessage(); 
    } 
    String operation = ctx.getOperationName(); 
    System.out.println("Reliable operation " + operation + " may have not invoked. The error message is " + message); 
  }

}

信頼性のあるWebサービスを呼び出すJWSファイルをプログラミングする際は、次のガイドラインに従います。ガイドラインのサンプル・コードは、前述のサンプル内では太字で示されています。

クライアントWebサービスをプログラミングする際、次のガイドラインに従います。

信頼性のあるWebサービスのクライアント用build.xmlファイルの更新

build.xmlファイルを更新し、信頼性のあるWebサービス操作を呼び出すJWSファイルを生成するには、次のようなtaskdefおよびbuild-reliable-clientターゲットを追加します。

<taskdef name="jwsc"
    classname="weblogic.wsee.tools.anttasks.JwscTask" />

<target name="build-reliable-client">

    <jwsc
        enableAsyncService="true"
        srcdir="src"
        destdir="${client-ear-dir}" >

        <jws file="examples/webservices/reliable/ReliableClientImpl.java">

          <clientgen 
            wsdl="http://${wls.destination.host}:${wls.destination.port}/ReliableHelloWorld/ReliableHelloWorld?WSDL" 
            packageName="examples.webservices.reliable"/> 

        </jws>

    </jwsc>

</target>

jwsc Antタスクの完全なクラス名を定義するには、taskdef Antタスクを使用します。

クライアントWebサービスをコンパイルするjwsc Antタスクを更新して、<jws>要素の<clientgen>子要素を含めます。これにより、デプロイされたReliableHelloWorld WebサービスのJAX-RPCスタブが生成およびコンパイルされるようになります。jwsc Antタスクでは、これらのスタブが生成されたWARファイルに自動的にパッケージ化されるため、即座にクライアントWebサービスからアクセスできるようになります。このようにするのは、生成されたクラスの1つをReliableClientImpl JWSファイルでインポートして使用するためです。

信頼性のあるメッセージングとMTOMの使用

次に、信頼性のあるWebサービスを実装し、MTOM/XOPを使用してSOAPメッセージ内のxs:base64Binary型のXMLデータの転送を最適化する簡単なJWSファイルの例を示します。コーディング・ガイドラインとして、サンプル・コードの後の説明を参照してください。このガイドラインはJavaコード内の太字部分に対応しています。このサンプルは、「信頼性のあるWebサービスを呼び出すJWSファイルに関するプログラミングのガイドライン」のサンプルを元に作成しています。

package examples.webservices.reliable;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.Oneway; 
import weblogic.jws.WLHttpTransport;

import weblogic.jws.ReliabilityBuffer; 
import weblogic.jws.BufferQueue; 
import weblogic.jws.Policy; 
import weblogic.jws.Policies; 

/**
 * Simple reliable Web Service.
 */

@WebService(name="ReliableHelloWorldPortType",
              serviceName="ReliableHelloWorldService")

@WLHttpTransport(contextPath="ReliableHelloWorld",
      serviceUri="ReliableHelloWorld",
      portName="ReliableHelloWorldServicePort")

@Policies({@Policy(uri="ReliableHelloWorldPolicy.xml", 
           direction=Policy.Direction.both, 
           attachToWsdl=true), 
           @Policy(uri = "policy:Mtom.xml")}) 

@BufferQueue(name="webservices.reliable.queue") 

public class ReliableHelloWorldImpl {

  @WebMethod()
  @Oneway() 
  @ReliabilityBuffer(retryCount=10, retryDelay="10 seconds") 

  public void helloWorld(String input) {
    System.out.println(" Hello World " + input);

  }

  @WebMethod

  public byte[] echoBinary(byte[] bytes) { 
    return bytes; 
  } 
}

MTOMを使用して信頼性のあるWebサービスを呼び出すJWSファイルをプログラミングする際は、次のガイドラインに従います。ガイドラインのサンプル・コードは、前述のサンプル内では太字で示されています。

信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項

WebLogic Serverでは、本番用の再デプロイメントがサポートされています。つまり、信頼性のあるWebLogic Webサービスの更新後の新しいバージョンを、同じWebサービスの古いバージョンと並行してデプロイできます。

WebLogic Serverでは、新しいクライアントのリクエストのみが新しいバージョンに転送されるように、クライアント接続が自動的に管理されます。再デプロイメント時にすでにWebサービスに接続していたクライアントは、作業が完了するまで古いバージョンのサービスを使用し続け、それらの作業が完了した時点で、WebLogic Serverが古いWebサービスを自動的にリタイアします。クライアントが信頼性のあるWebサービスに接続されている場合は、既存の信頼性のあるメッセージ・シーケンスがクライアントによって明示的に終了されるか、またはタイムアウトになったときに、そのクライアントの作業が完了したと見なされます。

本番用の再デプロイメントおよびWebサービス・クライアントに関する追加情報は、Webサービスを再デプロイする際にクライアント側で考慮すべき事項に関する項を参照してください。

信頼性のあるメッセージングとプロキシ・サーバーの使用

信頼性のあるWebサービスを呼び出すクライアント・アプリケーションでは、直接操作を呼び出すのではなく、プロキシ・サーバーを使用することがあります。プロキシを使用する理由としては、ファイアウォールの存在や、呼び出されたWebサービスのクラスタへのデプロイメントなどがあります。

この場合、呼び出されたWebサービスをホストするWebLogic Serverインスタンスは、プロキシ・サーバーのアドレスとポートで構成する必要があります。Webサービスがクラスタにデプロイされている場合は、そのクラスタ内のすべてのサーバーを構成することが必要です。

この手順では、ネットワーク接続を管理するための構成可能なWebLogic Serverの主要リソースであるネットワーク・チャネルの作成方法について説明します。ネットワーク・チャネルにより、クラスタのフロントエンド・アドレスにアクセスするための一貫性のある方法を提供できます。ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

各サーバー・インスタンスについて、以下の手順を実行します。

  1. Webサービスの呼出しに使用するプロトコル用のネットワーク・チャネルを作成します。ネットワーク・チャネルの名前は、weblogic-wsee-proxy-channel-XXXとする必要があります(XXXはプロトコルを表します)。たとえば、HTTPS用のネットワーク・チャネルを作成する場合、weblogic-wsee-proxy-channel-httpsという名前にします。

    ネットワーク・チャネルの作成に関する一般情報は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

  2. 「外部リスニング・アドレス」および「外部リスニング・ポート」フィールドを、それぞれプロキシ・サーバーのアドレスおよびポートで更新して、ネットワーク・チャネルを構成します。

  3. -Dweblogic.wsee.skip.async.response=true Javaシステム・プロパティを使用してWebLogic Serverインスタンスを起動することによって、WebLogic Serverプロキシ・サーバー上の非同期レスポンス・サービスを無効にします。

    デフォルトでは、すべてのWebLogic Serverインスタンスに、非同期リクエスト-レスポンス機能を処理する内部非同期Webサービスがデプロイされます。このシステム・プロパティを指定しない場合、プロキシ・サーバー上の非同期サービスが非同期メッセージを消費するため、非同期メッセージは要求したとおりにクラスタに到着しません。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次