| Oracle® Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング 11g リリース1(10.3.5) B61633-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング 11g リリース1(10.3.5) B61633-03 |
|
前 |
次 |
次の項では、Webサービスの信頼性のあるメッセージングの使用方法について説明します。
Webサービスの信頼性のあるメッセージングとは、ある1つのアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを確実に呼び出せるフレームワークです。ここでは、双方のサーバーでWS-ReliableMessaging仕様が実装されていることが前提となっています。信頼性が高いとは、ソフトウェア・コンポーネント、システム、またはネットワークの障害があっても、2つのエンドポイント(Webサービスとクライアント)間でメッセージ配信を保証することができる状態として定義されます。
WebLogic Webサービスは、WS-ReliableMessaging 1.2仕様(2009年2月)(http://docs.oasis-open.org/ws-rx/wsrm/200702)に準拠しています(また、バージョン1.1をサポートしています)。この仕様では、異なるアプリケーション・サーバー上の2つのエンドポイント(Webサービスとクライアント)が確実に通信できる方法について記述されています。具体的には、この仕様では送信元エンドポイント(つまりクライアントWebサービス)から宛先エンドポイント(つまり操作を確実に呼び出せるWebサービス)へ送信されるメッセージが、1つ以上の配信保証に基づいて確実に配信されるか、そうでなければ必ずエラーが発生する、相互運用性を備えたプロトコルについて説明されています。
信頼性のあるWebLogic Webサービスには、次の配信保証が備わっています。
表5-1 信頼性のあるメッセージングの配信保証
| 配信保証 | 説明 |
|---|---|
|
At Most Once |
メッセージは最大で1回、重複なしに配信されます。メッセージによっては、一度も配信されない可能性もあります。 |
|
At Least Once |
すべてのメッセージが、少なくとも1回配信されます。メッセージによっては、1回よりも多く配信される可能性があります。 |
|
Exactly Once |
すべてのメッセージが、必ず1回重複なしに配信されます。 |
|
In Order |
メッセージは、送信された順序で配信されます。この配信保証は、上記の3つの保証と組み合わせることもできます。 |
このドキュメントでは、信頼性のあるWebサービスとクライアントの作成方法、およびWebサービスをデプロイするWebLogic Serverインスタンスの構成方法について説明します。
WebLogic Webサービスでは、宛先エンドポイントがWebサービスの信頼性のあるメッセージングの機能と要件を記述および公開できるように、WS-Policyファイルを使用します。WS-Policyファイルは、サポートされているWS-ReliableMessaging仕様のバージョンやサービス品質の要件などが記述されたXMLファイルです。WS-Policy仕様(http://www.w3.org/TR/ws-policy/)では、Webサービスのポリシーを記述して通信するための、汎用的なモデルと構文が提供されています。
WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むあらかじめパッケージ化されているWS-Policyファイルがあります。「Webサービスの信頼性のあるメッセージングとMakeConnectionのためのあらかじめパッケージ化されたWS-Policyファイル」を参照してください。あらかじめパッケージ化されているWS-Policyファイルがニーズに合わない場合は、独自のWS-Policyファイルを作成する必要があります。詳細は、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。信頼性のあるメッセージングのポリシー・アサーションに関するリファレンス情報は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWebサービスの信頼性のあるメッセージングのポリシー・アサーションに関するリファレンスの項を参照してください。
Webサービスの信頼性のあるメッセージングは、非同期的または同期的に使用できます。メッセージを非同期に配信するときは、必要に応じて、メッセージ配信の自動再試行をサポートするようにバッファリングを構成できます。
次の表では、Webサービスの信頼性のあるメッセージングに対するトランスポート・タイプのサポートを示します。Webサービス・クライアントのトランスポート・タイプのサポートの詳細は、「Webサービス・クライアントからの信頼性のあるWebサービスの呼出し」を参照してください。障害リカバリの詳細は、「信頼性のあるメッセージングの障害リカバリのシナリオ」を参照してください。
|
注意: メッセージ・バッファリングは、Webサービスに対して構成できます。詳細は、第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。Webサービス・クライアントの場合、メッセージ・バッファリングはデフォルトで有効化されています。 |
表5-2 Webサービスの信頼性のあるメッセージングのトランスポート・タイプ
| トランスポート・タイプ | 特長 |
|---|---|
|
非同期トランスポート |
バッファ付きWebサービスの場合:
非バッファWebサービスの場合:
|
|
同期トランスポート |
|
次の図に、信頼性のあるメッセージの一方向の交換を示します。
「信頼性のあるメッセージ・シーケンス」は、RM送信元とRM宛先の間で確実に交換されるメッセージ・セットの進捗状況を追跡する際に使用されます。シーケンスは、0個以上のメッセージの送信に使用でき、文字列識別子で識別されます。この識別子は、信頼性のあるメッセージングを使用する際に、そのシーケンスを参照するために使用されます。
Webサービス・クライアント・アプリケーションは、RM送信元がRM宛先へ送信する信頼性のある配信のメッセージを送信します。RM宛先は、信頼性のあるメッセージを受信したことを確認応答し、そのメッセージをWebサービス・アプリケーションに配信します。RM送信元は、確認応答を受け取るまでメッセージを再送信できます。RM宛先は、リクエストをバッファリングするように構成されている場合は、Webサービスがリクエストの処理に失敗すると、Webサービスにリクエストを再配信できます。
Webサービス・クライアントは、クライアント・インスタンス(ポート・インスタンスまたはディスパッチ・インスタンス)でメソッドを呼び出して、ターゲットWebサービスにメッセージを送信します。ポートは、ポート・タイプの信頼性のあるWebサービスと関連付けられていて、そのサービスに対するプログラム・インタフェースを表します。ポートは、jwsc Antタスクの<clientgen>子要素で作成されます。ディスパッチ・インスタンスはクライアントからWebサービスにメッセージ全体を配信するための、緩やかに型指定された汎用インタフェースです。ディスパッチ・クライアントの詳細は、「Webサービス・ディスパッチ・クライアントの開発」を参照してください。
WebLogicでは、このクライアント・インスタンス内に、信頼性のあるメッセージ・シーケンスの識別子が格納されます。これによって、信頼性のあるメッセージ・シーケンスが単一のクライアント・インスタンスに接続されます。特定のクライアント・インスタンスを使用して送信されるすべてのメッセージは、その送信メッセージ数に関係なく、同じ信頼性のあるメッセージ・シーケンスを使用します。(バッチ化を使用しない場合は、「ビジネス作業単位へのメッセージのグループ化(バッチ化)」を参照してください。)
WebLogic Serverには、信頼性のあるシーケンスに関連付けられたリソースが保持されるため、タイミングよくリソースを解放する手順を踏むことをお薦めします。この手順は、クライアント・インスタンス自体のライフサイクルを管理するか、またはweblogic.wsee.reliability2.api.WsrmClient APIを使用して実行できます。WsrmClient APIを使用すると、構成オプションの設定、シーケンスIDの取得、信頼性のあるシーケンスの終了といった一般的なタスクを実行できます。詳細は、「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」を参照してください。
次の項では、さまざまなシナリオでの信頼性のあるメッセージングの障害リカバリの概要について説明します。
最初の3つのシナリオでは、Webサービスとクライアントの両方でバッファリングが有効であるものとします。最後のシナリオでは、バッファなしのWebサービスでの信頼性のあるメッセージングの障害リカバリについて説明します。バッファリングは、Webサービス・クライアントではデフォルトで有効になります。Webサービスでのバッファリングの構成の詳細は、第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。
表5-3では、RM送信元からのリクエストが到着する前にRM宛先が使用できなくなったときの、信頼性のあるメッセージングの障害リカバリ・シナリオについて説明します。
Webサービスとクライアントの両方でWebサービス・バッファリングが有効であるものとします。バッファリングは、Webサービス・クライアントではデフォルトで有効になります。Webサービスでのバッファリングの構成の詳細は、第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。
表5-3 信頼性のあるメッセージングの障害リカバリのシナリオ: リクエストが到着する前にRM宛先がダウンする
| トランスポート・タイプ | シナリオの説明 |
|---|---|
|
非同期トランスポート |
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 |
|
同期トランスポート |
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 注意: 同期トランスポートで真の信頼性を実現するには、MakeConnectionを使用することをお薦めします。詳細は、「ファイアウォールの内側からの非同期Webサービス・クライアントの使用(MakeConnection)」を参照してください。 |
表5-4では、リクエストを行った後でRM送信元がダウンするときの、信頼性のあるメッセージングの障害リカバリ・シナリオについて説明します。
Webサービスとクライアントの両方でWebサービス・バッファリングが有効であるものとします。バッファリングは、Webサービス・クライアントではデフォルトで有効になります。Webサービスでのバッファリングの構成の詳細は、第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。
表5-4 信頼性のあるメッセージングの障害リカバリのシナリオ: リクエストを行った後でRM送信元がダウンする
| トランスポート・タイプ | シナリオの説明 |
|---|---|
|
非同期トランスポート |
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 |
|
同期トランスポート |
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 注意: 同期トランスポートで真の信頼性を実現するには、MakeConnectionを使用することをお薦めします。詳細は、「ファイアウォールの内側からの非同期Webサービス・クライアントの使用(MakeConnection)」を参照してください。 |
表5-5では、RM送信元からのリクエストを受け付けた後でRM宛先が使用できなくなったときの、信頼性のあるメッセージングの障害リカバリ・シナリオについて説明します。
Webサービスとクライアントの両方でWebサービス・バッファリングが有効であるものとします。バッファリングは、Webサービス・クライアントではデフォルトで有効になります。Webサービスでのバッファリングの構成の詳細は、第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。
表5-5 信頼性のあるメッセージングの障害リカバリのシナリオ: リクエストが到着した後でRM宛先がダウンする
| トランスポート・タイプ | シナリオの説明 |
|---|---|
|
非同期トランスポート |
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 |
|
同期トランスポート |
注意: 同期トランスポートを使用してバッファ付きWebサービスを呼び出そうとした場合、結果は次のいずれかになります。
次にこのシナリオのシーケンスを説明します。
注意: 「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」で説明されているように、クライアントはいつでも、確認応答のステータスを確認したり、メッセージについての情報にアクセスしたりできます。 |
バッファなしWebサービスの動作はバッファ付きWebサービスとは異なり、リクエストの確認応答と処理を行う前に、強化されたストレージに要求をバッファリングしません。バッファなしWebサービスはサービス・ロジックが失敗した場合でもリクエストを再処理しませんが、バッファ付きWebサービスはリクエストを再処理します。どちらの場合も、Webサービスによって生成されるすべてのレスポンスは、クライアントに返送される前にバッファリングされます。
バッファなしWebサービスは、次の場合に有効である場合があります。
Webサービスが非トランザクション・リソースに対して動作しており、リクエストを2回以上処理する必要がない場合(バッファリングされたリクエストをデキューしたトランザクションのロールバックでは、非トランザクション・サービスの二次的影響をロールバックできないため)。
Webサービスが比較的軽量であり、リクエストの処理に時間がかからない場合。
Webサービスではパフォーマンスが最も重要であり、リクエストまたはレスポンスを失ってもかまわない場合。バッファなしWebサービスではリクエストをストアにバッファリングするオーバーヘッドがないため、バッファ付きWebサービスよりスループットがよくなります。パフォーマンスの向上は、リクエストをバッファリングするために必要な時間とリソースによって異なります(たとえば、非常に大きいリクエスト・メッセージでは、バッファリングに多くの時間とリソースが必要な場合があります)。
ほとんどの障害シナリオでは、バッファなしWebサービスの動作はバッファ付きWebサービスとほぼ同じです。例外は、サービス(RM宛先)自体で障害が発生した場合です。たとえば、説明したすべてのRM送信元障害シナリオでは、動作はバッファ付きWebサービスでもバッファなしWebサービス(RM宛先)でも同じです。バッファなしWebサービスでは、次の2つのポイントの間で障害ウィンドウが開きます。
リクエストが処理のために受け付けられます。
Webサービスからのレスポンスがクライアント(RMリソース)への配信のために登録されます。
これら2つのポイントの間でWebサービス(RM宛先)に障害が起きると、RM送信元はリクエストが正常に処理されたものと判断しますが(確認応答を受け取ったため)、レスポンスを受け取ることはなく、リクエストが処理されない可能性があります。
Webサービスをバッファなしとして実行するように構成する前に、この障害ウィンドウをよく検討してください。
WebLogic Webサービスの信頼性のあるメッセージングを構成するには、JMSサーバーやストア・アンド・フォワード(SAF)・エージェントの作成など標準的なJMSタスクとともに、JWSファイルへのJWSアノテーションの追加などWebサービス固有のタスクを実行する必要があります。また、あらかじめパッケージ化されているファイルを使用しない場合は、必要に応じて、信頼性のあるWebサービスの信頼性のあるメッセージング機能を記述したカスタムWS-Policyファイルをユーザー側で作成します。
信頼性のあるWebサービスの呼出しにWebLogicクライアントAPIを使用している場合、クライアント・アプリケーションはWebLogic Server上で実行される必要があります。したがって構成タスクを、Webサービス・クライアントのコードがデプロイされる送信元WebLogic Serverインスタンスと、信頼性のあるWebサービスそのものがデプロイされる宛先WebLogic Serverインスタンスの双方で実行する必要があります。
表5-6は、信頼性のあるWebサービスと、その操作を呼び出すクライアントを作成する手順を説明しています。この手順では、Webサービスとクライアントを実装するJWSファイルをゼロから作成する方法を示しています。既存のJWSファイルを更新する場合は、この手順をガイドとして利用してください。またこの手順では、ソースWebLogic Serverインスタンスと宛先WebLogic Serverインスタンスの構成方法も示しています。
以下の作業を完了している必要があります。
宛先と送信元のWebLogic Serverインスタンスを作成しておきます。信頼性のあるWebサービスを宛先WebLogic Serverインスタンスにデプロイし、信頼性のあるWebサービスを呼び出すクライアントを送信元WebLogic Serverインスタンスにデプロイします。
Antベースの開発環境を設定しておきます。
編集(jwsc Antタスクを実行して信頼性のある生成済Webサービスをデプロイするためのターゲットの追加など)が可能な作業用のbuild.xmlファイルの用意。
詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebLogic Webサービスの開発に関する項を参照してください。非同期の信頼性のあるWebサービスとクライアントの開発のベスト・プラクティスは、「信頼性のあるWebサービスとクライアントを開発する手順」を参照してください。
表5-6 信頼性のあるWebサービスの作成および呼出し手順
| # |
手順 | 説明 |
|---|---|---|
|
1 |
宛先WebLogic ServerインスタンスとソースのWebLogic Serverインスタンスを構成します。 |
信頼性のあるWebサービスを宛先WebLogic Serverインスタンスにデプロイし、信頼性のある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「Webサービスの信頼性のあるメッセージングとMakeConnectionのためのあらかじめパッケージ化されたWS-Policyファイル」を参照を参照してください。 |
|
3 |
信頼性のあるWebサービスを実装するJWSファイルを作成および更新します。 |
このWebサービスは、宛先WebLogic Serverインスタンスにデプロイされます。「信頼性のあるJWSファイルに関するプログラミングのガイドライン」を参照してください。 たとえばベスト・プラクティスについては、「信頼性のあるWebサービスとクライアントを開発する手順」を参照してください。 |
|
4 |
信頼性のあるWebサービスのコンパイルに使用される |
|
|
5 |
信頼性のあるJWSファイルをコンパイルおよびデプロイします。 |
適切なターゲットを呼び出して信頼性のあるJWSファイルをコンパイルし、宛先WebLogic Serverにデプロイします。例: prompt> ant build-reliableService deploy-reliableService |
|
6 |
Webサービス・クライアントを作成または更新します。 |
Webサービス・クライアントは、信頼性のあるWebサービスを呼び出し、送信元WebLogic Serverにデプロイされます。「Webサービス・クライアントからの信頼性のあるWebサービスの呼出し」を参照してください。 |
|
7 |
信頼性のあるメッセージングを構成します。(オプション) |
管理コンソールを使用して信頼性のあるWebサービスに対する信頼性のあるメッセージングを構成します。信頼性のあるWebサービスにアタッチされているWS-Policyファイルが、初期構成の設定を提供します。「信頼性のあるメッセージングの構成」を参照してください。 |
|
8 |
信頼性エラー・リスナーを実装します。(オプション) |
信頼性のある配信が失敗した場合に通知を受け取る信頼性エラー・リスナーを実装します。「信頼性エラー・リスナーの実装」を参照してください。 |
|
9 |
信頼性のあるメッセージ・シーケンスのライフサイクルを管理します。(オプション) |
WebLogic Serverでは、Webサービスの信頼性のあるメッセージングで使用するためのクライアントAPI |
|
10 |
クライアントWebサービスのコンパイルに使用される |
|
|
11 |
Webサービス・クライアント・ファイルをコンパイルしてデプロイします。 |
適切なターゲットを呼び出してクライアント・ファイルをコンパイルし、ソースWebLogic Serverにデプロイします。例: prompt> ant build-clientService deploy-clientService |
|
12 |
Webサービスの信頼性のあるメッセージングを監視します。 |
管理コンソールを使用して、Webサービスの信頼性のあるメッセージングを監視します。「Webサービスの信頼性のあるメッセージングの監視」を参照してください。 |
以降の項では、これらの各手順について詳細に説明します。さらに、次のトピックについて説明します。
ビジネス作業単位へのメッセージのグループ化(バッチ化): メッセージをビジネス作業単位にグループ化し(バッチ化とも呼ばれます)、信頼性のあるメッセージングを使用するときのパフォーマンスを向上させます。
信頼性のあるWebサービスを再デプロイする際にクライアント側で考慮すべき事項: 信頼性のある更新済WebLogic Webサービスの新しいバージョンを、同じWebサービスの古いバージョンと一緒にデプロイする際に、クライアント側で考慮すべき事項について説明します。
WebLogic Webサービスの信頼性のあるメッセージングとの相互運用性: WebLogic Webサービスの信頼性のあるメッセージングと相互運用するための推奨事項を示します。
送信元と宛先のWebLogic Serverインスタンスに、Webサービスの永続性を構成する必要があります。信頼性のあるWebサービスを宛先WebLogic Serverインスタンスにデプロイし、信頼性のあるWebサービスを呼び出すクライアントを送信元WebLogic Serverインスタンスにデプロイします。
Webサービスの信頼性のあるメッセージングを使用するときは、状態が変化するたびに、Webサービスの信頼性のあるメッセージング・シーケンスがWebサービスの永続ストアに保存されます。状態変化の例を次に示します。
信頼性のあるメッセージングの状態が更新された(作成中、作成済み、終了中、終了済みなど)。
セキュリティ・プロパティが更新された(セキュリティ・コンテキスト・トークンなど)。
信頼性のあるメッセージング・シーケンスでメッセージが送信された(メッセージ・バッファリングが有効の場合)。
メッセージが到着したときに確認応答。
構成ウィザードでWebサービス固有の拡張テンプレートを使用してWebLogic Serverドメインを拡張することにより、Webサービスの永続性を構成できます。あるいは、Oracle WebLogic管理コンソールまたはWLSTを使用して、これらの高度な機能に必要なリソースを構成できます。Webサービス永続性の構成の詳細は、「Webサービス永続性の構成」を参照してください。
Webサービスにバッファリングを構成することもできます。メッセージ・バッファリングの構成に関する考慮事項と手順は、「第7章「Webサービスのためのメッセージ・バッファリングの構成」を参照してください。
WS-Policyファイルは、WS-Policy仕様に準拠するポリシー・アサーションを含むXMLファイルです。この場合、WS-PolicyファイルにはWebサービスの信頼性のあるメッセージングのポリシー・アサーションが含まれています。
WebLogic Serverには、標準的な信頼性のあるメッセージング・アサーションを含むWS-Policyファイルがあらかじめパッケージ化されています。独自のWS-Policyファイルを作成しない場合は、これらのファイルを使用できます。
次の表に、あらかじめパッケージ化されているWS-Policyファイルを示します。この表は、WS-Policyファイルをメソッド・レベルでアタッチできるかどうかも指定します。この列の値が「No」の場合、WS-Policyファイルをクラス・レベルでのみアタッチできます。詳細は、付録A「Webサービスの信頼性のあるメッセージングとMakeConnectionのためのあらかじめパッケージ化されたWS-Policyファイル」を参照してください。
|
注意: このリリースでは、DefaultReliability.xmlファイルとLongRunningReliability.xmlファイルは非推奨となっています。DefaultReliability1.2.xml、Reliability1.2_SequenceTransportSecurity、またはReliability1.0_1.2.xmlファイルを使用することをお薦めし、http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.2-spec-os.pdfであるWS-ReliableMessaging仕様の1.2バージョンに準拠する必要があります。 |
表5-7 信頼性のあるメッセージングをサポートする、あらかじめパッケージ化されているWS-Policyファイル
| あらかじめパッケージ化されているWS-Policyファイル | 説明 | メソッド・レベルのアタッチ |
|---|---|---|
DefaultReliability1.2.xml |
配信保証に関するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージング・アサーションは、 |
はい |
DefaultReliability1.1.xml |
サービス品質に関するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージング・アサーションは、 |
はい |
|
|
サービス品質に関するポリシー・アサーションを指定します。WebサービスでのMakeConnectionのサポートを有効にし、オプションとしてWebサービス・クライアントでの使用方法を指定します。「Reliability1.2_ExactlyOnce_WithMC1.1.xml(WS-Policyファイル)」を参照してください。 |
いいえ |
Reliability1.2_SequenceSTRSecurity |
信頼性のあるシーケンスでメッセージを保護するために、 |
いいえ |
Reliability1.1_SequenceSTRSecurity |
Webサービスの信頼性のあるメッセージング・アサーションは、 |
はい |
Reliability1.2_SequenceTransportSecurity |
トランスポート・レベルのセキュリティとサービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージング・アサーションは、 |
はい |
Reliability1.1_SequenceTransportSecurity |
トランスポート・レベルのセキュリティとサービス品質に関連するポリシー・アサーションを指定します。Webサービスの信頼性のあるメッセージング・アサーションは、 |
はい |
Reliability1.0_1.2.xml |
1.2と1.0のWS-Reliableメッセージング・ポリシー・アサーションを結合します。1.2バージョンのポリシー・アサーションはWebサービスでのMakeConnectionのサポートを有効にし、オプションとしてWebサービス・クライアントでの使用方法を指定します。このサンプルは、適切なポリシーの選択に基づいて実行時に適用されるポリシー・アサーションを決定します。「Reliability1.0_1.2.xml(WS-Policyファイル)」を参照してください。 |
いいえ |
Reliability1.0_1.1.xml |
1.1と1.0のWS Reliable Messagingポリシー・アサーションを結合します。「Reliability1.0_1.1.xml(WS-Policy.xmlファイル)」を参照してください。 |
はい |
DefaultReliability.xml |
非推奨。Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0( 信頼性のあるメッセージングのポリシー・アサーションに一般的な値(非アクティブ・タイムアウト10分、確認応答の間隔200ミリ秒、基本的な再送信間隔3秒など)を指定します。「DefaultReliability.xml WS-Policyファイル(WS-Policy)[非推奨]」を参照してください。 |
はい |
LongRunningReliability.xml |
非推奨。長期実行プロセスに関して、Webサービスの信頼性のあるメッセージングのアサーションは、WS Reliable Messaging Policy Assertion Version 1.0に基づいています。このリリースでは、信頼性のあるメッセージングのポリシー・アサーションの多くが、JWSアノテーションまたは構成を通じて管理されます。 1つ前に示した、信頼性のあるメッセージングのデフォルトWS-Policyファイルとほぼ同じですが、アクティビティのタイムアウト間隔に、より大きな値(24時間)を指定する点が異なります。「LongRunningReliability.xml WS-Policyファイル(WS-Policy)[非推奨]」を参照してください。 |
はい |
WebLogic Serverに含まれる、あらかじめパッケージ化されている信頼性のあるメッセージングWS-Policyファイルの1つを使用できます。これらのファイルは、ほとんどの場合に適合しています。あらかじめパッケージ化されているファイルは変更できません。値がニーズを満たさない場合は、カスタムのWS-Policyファイルを作成する必要があります。以下の節で、カスタムWS-Policyファイルの作成方法を説明します。
WS-ReliableMessagingポリシー・アサーション・バージョン1.2と1.1を使用したカスタムWS-Policyファイルの作成
WS-ReliableMessagingポリシー・アサーション・バージョン1.0を使用したカスタムWS-Policyファイルの作成(非推奨)
この項では、次の仕様に基づいたWebサービスの信頼性のあるメッセージングのアサーションを含むカスタムWS-Policyファイルを作成する方法について説明します。
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.2-spec-os.htmlのWS Reliable Messaging Policy Assertion Version 1.2
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.htmlのWS Reliable Messaging Policy Assertion Version 1.1
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ファイルでは次の一覧の順序どおりに指定する必要があります。
表5-8 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.2および1.1)
| アサーション | 説明 |
|---|---|
<wsrmp:SequenceSTR> |
信頼性のあるシーケンスでメッセージを保護するため、ランタイムでは |
<wsrmp:SequenceTransportSecurity> |
信頼性のあるシーケンスでメッセージを保護するため、ランタイムでは |
<wsrm:DeliveryAssurance> |
Webサービスの配信保証レベル(配信品質)。有効な値は、 |
次の例では、簡単な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 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ファイルでは次の一覧の順序どおりに指定する必要があります。
表5-9 Webサービスの信頼性のあるメッセージング・アサーション(バージョン1.0)
| アサーション | 説明 |
|---|---|
<wsrm:InactivityTimeout> |
非アクティブ間隔を定義する、 |
<wsrm:BaseRetransmissionInterval> |
ソース・エンドポイントがメッセージを送信してから、そのメッセージの確認応答を受け取っていない場合に再送信を行うまでの間隔(ミリ秒単位)。デフォルト値は、ソース・エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。 |
<wsrm:ExponentialBackoff> |
再送信の間隔が、指数関数的なバックオフ・アルゴリズムを使用して調整されることを指定します。この要素に属性はありません。 |
<wsrm:AcknowledgmentInterval> |
宛先エンドポイントがスタンドアロンの確認応答を送信しなければならない最大間隔(ミリ秒単位)。デフォルト値は、宛先エンドポイントのWebLogic Serverインスタンス上のSAFエージェントによって設定されます。 |
<beapolicy:Expires> |
信頼性のあるWebサービスの有効期限が切れ、これ以上の新しいシーケンス・メッセージを受け付けなくなるまでの時間の長さ。デフォルト値では、有効期限が切れることはありません。この要素には、 |
<beapolicy:QOS> |
表5-1で説明されている、配信保証レベル。この要素には |
次の例では、簡単な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.2と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サービスの保護』の適切なポリシーの選択に関する項を参照してください。
信頼性のあるメッセージングのアサーションが含まれるWS-PolicyファイルをWebサービスに追加するよう指定するには、JWSファイルで@Policyアノテーションを使用します。WebLogic Serverでは、あらかじめパッケージ化されているWS-Policyファイルのセットが提供されます。付録A「Webサービスの信頼性のあるメッセージングとMakeConnectionのためのあらかじめパッケージ化された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サービスで操作が確実に呼び出され、そのレスポンスが確実に配信されるよう要求するかどうかを指定できます。
以下の点に注意してください。
クライアントが同期トランスポートを使用してWebサービスを呼び出し、操作のインバウンド方向で信頼性が必要な場合は(optional属性がfalse)、クライアントは信頼性のあるレスポンスを送信する時使用できるようにofferシーケンスを提供する必要があります(http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdfにあるWS-ReliableMessaging仕様で説明されている<wsrm: Offer...>)。
クライアントが非同期トランスポートを使用する場合は、クライアントはofferシーケンスを送信する必要はありません。リクエストが信頼性を持って行われて、アウトバウンド方向にRMポリシーがある場合(オプションかどうか)信頼性のあるメッセージングのランタイムは、レスポンスを送信するために新しいRMシーケンスのハンドシェイクを強制します。この新しいシーケンスはリクエスト・シーケンスと関連付けられ、それ以降のすべてのレスポンスは新しいレスポンス・シーケンスで送信されます。レスポンス・シーケンスは、リクエストのReplyToアドレスで示されているエンドポイントとネゴシエーションされます。
@PolicyアノテーションのattachToWsdl属性を設定して、ポリシー・ファイルをWebサービスのパブリック規約が記述されたWSDLファイルに付加するかどうかを指定できます。通常は、クライアント・アプリケーションでWebサービスの信頼性のあるメッセージング機能が認識されるよう、パブリックなものとしてポリシーを公開します。そのため、この属性のデフォルト値はtrueです。
@Policyアノテーションの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のweblogic.jws.Policyに関する項を参照してください。
例5-1では、信頼性のあるWebサービスを実装する簡単なJWSファイルを示します。
例5-1 信頼性のあるWebサービスの例
import javax.jws.WebService;
import weblogic.jws.Policies;
import weblogic.jws.Policy;
/**
* Example Web service for reliable client best practice examples
*/
@WebService
// Enable RM on this service.
@Policies( { @Policy(uri = "policy:DefaultReliability1.2.xml") })
public class BackendReliableService {
public String doSomething(String what) {
System.out.println("BackendReliableService doing: " + what);
return "Did (Reliably) '" + what + "' at: " + System.currentTimeMillis();
}
}
この例では、事前に定義されたDefaultReliability1.2.xmlポリシー・ファイルがクラス・レベルでWebサービスにアタッチされています。つまり、ポリシー・ファイルはWebサービスのすべてのパブリック操作(doSomething())に適用されます。ポリシー・ファイルは、デフォルトでリクエストとレスポンスの両方に適用されます。あらかじめパッケージ化されている利用可能なポリシーおよびカスタム・ポリシーの作成の詳細につぃては、「Webサービスの信頼性のあるメッセージングのWS-Policyファイルの作成」を参照してください。
次の表では、使用するトランスポート・タイプに基づいてWebサービス・クライアントから信頼性のあるWebサービスを呼び出す方法を示します。トランスポート・タイプの詳細は、表5-2を参照してください。
表5-10 トランスポート・タイプに基づく信頼性のあるWebサービスの呼出し
| トランスポート・タイプ | 説明 |
|---|---|
|
非同期トランスポート |
非同期トランスポートを使用するには、次の手順を実行します。
|
|
同期トランスポート |
同期トランスポートを使用するには、標準のJAX-WS参照実装を使用して、信頼性のあるメッセージング・サービスのポート・インスタンスで非同期メソッドまたは同期メソッドを呼び出します(「JAX-WS参照実装の使用」を参照)。 注意: 同期トランスポートを使用してバッファ付きWebサービスを呼び出そうとした場合、結果は次のいずれかになります。
|
クライアント側での追加の制御として、次のタスクを実行できます。
クライアント側で信頼性のあるメッセージングを構成します(「信頼性のあるメッセージングの構成」を参照)。
信頼性のある配信が失敗した場合に通知を受け取る信頼性エラー・リスナーを実装します(「信頼性エラー・リスナーの実装」を参照)。ベスト・プラクティスとして信頼性エラー・リスナーを常に実装することをお薦めします。
構成オプションの設定、信頼性のあるシーケンスIDの取得、信頼性のあるシーケンスの終了など、信頼性のあるメッセージング・シーケンスに対する一般的なライフサイクル・タスクを実行します(「信頼性のあるメッセージ・シーケンスのライフサイクルの管理」を参照)。
WebLogic Server、Webサービス・エンドポイント、Webサービス・クライアントのレベルで、信頼性のあるWebサービスとクライアントのプロパティを構成できます。
WebLogic Serverレベルで定義したプロパティは、そのサーバーのすべての信頼性のあるWebサービスとクライアントに適用されます。WebLogic Serverレベルでの信頼性のあるメッセージングの構成の詳細は、「WebLogic Serverでの信頼性のあるメッセージングの構成」を参照してください。
必要がある場合は、次のようにして、サーバー・レベルで定義されている信頼性のあるメッセージングの構成オプションをオーバーライドできます。
Webサービス・エンドポイント・レベルで、アプリケーション・デプロイメント・プランを更新します。デプロイメント・プランは、新しい値をアプリケーションの記述子内の特定の場所に関連付け、weblogic-webservices.xml記述子に保存されます。デプロイメント時に、デプロイメント・プランは変数割当ての値を、その変数のリンク先アプリケーション記述子内の場所に適用することによって、そのアプリケーション内の記述子に結合されます。詳細は、「Webサービス・エンドポイントでの信頼性のあるメッセージングの構成」を参照してください。
Webサービスのクライアント・レベル。詳細は、「Webサービス・クライアントでの信頼性のあるメッセージングの構成」を参照してください。
次の項では、WebLogic Server、Webサービス・エンドポイント、Webサービス・クライアントの各レベルで信頼性のあるメッセージングを構成する方法を説明します。
WebLogic Serverでの信頼性のあるメッセージングは、管理コンソールまたはWLSTを使用して構成できます。以降の項を参照してください。
管理コンソールを使用してWebLogic Serverに対して信頼性のあるメッセージングを構成するには、次の手順に従います。
『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebLogic Server管理コンソールの使用に関する項の説明に従って、管理コンソールを起動します。
左側のナビゲーション・ペインで、「環境」、「サーバー」の順に選択します。
「構成」タブを選択し、「サーバー」表で、信頼性のあるメッセージングの構成の対象となるサーバーの名前をクリックします。
「構成」タブ、「Webサービス」タブ、「信頼できるメッセージ」タブの順にクリックします。
次の項の説明に従って、信頼性のあるメッセージングのプロパティを編集します。
「保存」をクリックします。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービスの信頼性のあるメッセージングに関する項を参照してください。
または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。
既定では、Webサービス・エンドポイントは、サーバーに対して定義されている信頼性のあるメッセージングの構成を使用します。次のようにすると、Webサービス・エンドポイントで使用される信頼性のあるメッセージングの構成を、管理コンソールを使用してオーバーライドできます。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』の管理コンソールの起動に関する項の説明に従って、管理コンソールを起動します。
左側のナビゲーション・ペインで、「デプロイメント」を選択します。
「デプロイメント」表でWebサービスの名前をクリックします。
「構成」タブ、「ポート・コンポーネント」タブの順に選択します。
「ポート」表でWebサービスのエンドポイントの名前をクリックします。
「信頼できるメッセージ」タブを選択します。
「信頼性のあるメッセージ構成のカスタマイズ」をクリックし、必要に応じて、指示に従ってデプロイメント・プランを保存します。
次の項の説明に従って、信頼性のあるメッセージングのプロパティを編集します。
「保存」をクリックします。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebサービスの信頼性のあるメッセージングの構成に関する項を参照してください。
Webサービス・クライアントでの信頼性のあるメッセージングの構成の一般情報は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービス・クライアントの構成に関する項を参照してください。
Webサービスの信頼性のあるメッセージングのクライアントを作成するときのweblogic.wsee.reliability2.api.WsrmClientInitFeatureの使用の詳細は、次の項を参照してください。
ソース・エンドポイントが、指定された基本の再送信間隔内で所定のメッセージの確認応答を受信しなかった場合、ソース・エンドポイントはメッセージを再送信します。ソース・エンドポイントは、メッセージのシーケンスの存続期間内の任意の時点で、この再送信間隔を変更することがあります。
この間隔を再送信間隔の指数関数的バックオフ(「再送信間隔の指数関数的バックオフの構成」を参照)と組み合せて使用すると、再送信間隔を調整するアルゴリズムを指定できます。
指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT5S (5秒)。
次の項では、基本の再送信間隔を構成する方法について説明します。
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで再送信間隔の指数関数的バックオフを構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「基本の再送信間隔」の値を設定します。
|
注意: Webサービス・クライアントの構成の詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービス・クライアントの構成に関する項を参照してください。 |
表5-11では、メッセージをRM宛先に再送信する前に経過する必要のある時間を構成するためのweblogic.wsee.reliability2.api.WsrmClientInitFeatureメソッドについて説明します。
表5-11 基本の再送信間隔を構成するためのメソッド
| メソッド | 説明 |
|---|---|
|
|
基本の再送信間隔を取得します。 |
|
|
基本の再送信間隔を設定します。 |
次の例では、基本の再送信間隔を3時間に設定しています。
import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import wsrm_jaxws.example.client_service.*; import wsrm_jaxws.example.client_service.EchoResponse; import weblogic.wsee.reliability2.api.WsrmClientInitFeature; ... @WebService public class ClientServiceImpl { ... @WebServiceRef(name="ReliableEchoService") private ReliableEchoService service; private ReliableEchoPortType port = null; WsrmClientInitFeature initFeature = new WsrmClientInitFeature(true); initFeature.setBaseRetransmissionInterval("P0DT3H"); port = service.getMyReliableServicePort(initFeature); ...
基本の再送信間隔の構成は、weblogic.xmlファイルでは次のように記述されます。
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.BaseRetransmissionInterval</name>
<value>PT30S</value>
</stub-property>
...
</port-info>
</service-reference-description>
再送信間隔の指数関数的バックオフは、基本の再送信間隔(「基本の再送信間隔の構成」を参照)と組み合せて使用します。宛先エンドポイントが、基本の再送信間隔で指定した時間内にメッセージのシーケンスを確認応答しなかった場合、メッセージが引き続き確認されなければ、連続する再送信のタイミングに対して、送信元エンドポイントでは指数関数的バックオフ・アルゴリズムを使用します。
指数関数的なバックオフ・アルゴリズムは、連続再送信の間隔が、基本の再送信間隔を基に指数的に増えるように指定します。たとえば、基本の再送信間隔が2秒で、指数関数的なバックオフ要素が設定されている場合、連続再送信の間隔は、メッセージが確認されなければ、2、4、8、16、32秒というように増えていきます。
デフォルトではこのフラグは無効(false)であり、連続再送信の間隔は指数的に増えず、同じ値が維持されます。
次の項では、再送信間隔の指数関数的バックオフを構成する方法について説明します。
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで再送信間隔の指数関数的バックオフを構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「再送信間隔の指数関数的バックオフの有効化」フラグを設定します。
|
注意: Webサービス・クライアントの構成の詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービス・クライアントの構成に関する項を参照してください。 |
表5-12では、メッセージの再送信間隔を再送信間隔の指数関数的バックオフ・アルゴリズムを使用して調整するかどうかを構成するためのweblogic.wsee.reliability2.api.WsrmClientInitFeatureメソッドについて説明します。
表5-12 再送信間隔の指数関数的バックオフを構成するためのメソッド
| メソッド | 説明 |
|---|---|
|
|
再送信間隔の指数関数的バックオフが有効かどうかを示します。 |
|
|
再送信間隔の指数関数的バックオフが有効かどうかを指定します。有効な値は |
次の例では、再送信間隔の指数関数的バックオフを有効にしています。
import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import wsrm_jaxws.example.client_service.*; import wsrm_jaxws.example.client_service.EchoResponse; import weblogic.wsee.reliability2.api.WsrmClientInitFeature; ... @WebService public class ClientServiceImpl { ... @WebServiceRef(name="ReliableEchoService") private ReliableEchoService service; private ReliableEchoPortType port = null; WsrmClientInitFeature initFeature = new WsrmClientInitFeature(true); initFeature.setBaseRetransmissionInterval("P0DT3H"); initFeature.setBaseRetransmissionExponentialBackoff(true); port = service.getMyReliableServicePort(initFeature); ...
再送信間隔の指数関数的バックオフの構成は、weblogic.xmlファイルでは次のように記述されます。
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.RetransmissionExponentialBackoff</name>
<value>true</value>
</stub-property>
...
</port-info>
</service-reference-description>
順序の有効期限は、アクティビティにかかわらず、シーケンスが期限切れになるまでの時間を指定します。
指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP1D (1日)。
次の項では、順序の有効期限を構成する方法について説明します。
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで順序の有効期限を構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「順序の有効期限」の値を設定します。
|
注意: Webサービス・クライアントの構成の詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービス・クライアントの構成に関する項を参照してください。 |
表5-13では、アクティビティにかかわらず順序が期限切れになるまでの時間に対するweblogic.wsee.reliability2.api.WsrmClientInitFeatureメソッドについて説明します。
表5-13 順序の有効期限を構成するためのメソッド
| メソッド | 説明 |
|---|---|
|
|
現在構成されている順序の有効期限を返します。 |
|
|
アクティビティにかかわらず、シーケンスが期限切れになるまでの時間。 |
次の例では、順序の有効期限を36時間に設定しています。
import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import wsrm_jaxws.example.client_service.*; import wsrm_jaxws.example.client_service.EchoResponse; import weblogic.wsee.reliability2.api.WsrmClientInitFeature; ... @WebService public class ClientServiceImpl { ... @WebServiceRef(name="ReliableEchoService") private ReliableEchoService service; private ReliableEchoPortType port = null; WsrmClientInitFeature initFeature = new WsrmClientInitFeature(true); initFeature.setSequenceExpiration("P0DT36H"); port = service.getMyReliableServicePort(initFeature); ...
順序の有効期限の構成は、weblogic.xmlファイルでは次のように記述されます。
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.SequenceExpiration</name>
<value>PT10M</value>
</stub-property>
...
</port-info>
</service-reference-description>
非アクティブ・タイムアウト間隔内に、エンドポイント(RM送信元とRM宛先)がアプリケーションのメッセージまたはプロトコル・メッセージを受け取らなければ、エンドポイントはRMシーケンスが非アクティブなため終了したものと見なします。
指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT600S (600秒)。
次の項では、非アクティブ・タイムアウトを構成する方法について説明します。
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで非アクティブ・タイムアウトを構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「非アクティブ・タイムアウト」の値を設定します。
|
注意: Webサービス・クライアントの構成の詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービス・クライアントの構成に関する項を参照してください。 |
表5-14では、非アクティブ・タイムアウトを構成するためのweblogic.wsee.reliability2.api.WsrmClientInitFeatureメソッドについて説明します。
表5-14 非アクティブ・タイムアウトを構成するためのメソッド
| メソッド | 説明 |
|---|---|
|
|
現在構成されている非アクティブ・タイムアウトを返します。 |
|
|
非アクティブ・タイムアウトを設定します。 |
次の例では、非アクティブ・タイムアウトを1時間に設定しています。
import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import wsrm_jaxws.example.client_service.*; import wsrm_jaxws.example.client_service.EchoResponse; import weblogic.wsee.reliability2.api.WsrmClientInitFeature; ... @WebService public class ClientServiceImpl { ... @WebServiceRef(name="ReliableEchoService") private ReliableEchoService service; private ReliableEchoPortType port = null; WsrmClientInitFeature initFeature = new WsrmClientInitFeature(true); initFeature.setInactivityTimeout("P0DT1H"); port = service.getMyReliableServicePort(initFeature); ...
非アクティブ・タイムアウトの構成は、weblogic.xmlファイルでは次のように記述されます。
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.InactivityTimeout</name>
<value>PT5M</value>
</stub-property>
...
</port-info>
</service-reference-description>
特定の宛先サーバーでメッセージ・バッファリングを無効にするかどうかを指定し、メッセージを受信するときにバッファリングを使用するかどうかを制御できます。宛先サーバーでバッファなしを構成できるのは、WebLogic ServerまたはWebサービス・エンドポイントのレベルのみであり、Webサービス・クライアントのレベルでは構成できません(Webサービス・クライアントではバッファリングがデフォルトで有効になります)。
|
注意: バッファなし宛先を構成した場合、@WebServiceRefを使用して構成の参照を定義しているすべてのWebサービス・クライアントは、レスポンスをバッファリングなしで受け取ります。
バッファなし宛先の構成は、
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.NonBufferedDestination</name>
<value>true</value>
</stub-property>
...
</port-info>
</service-reference-description>
|
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで、メッセージのバッファリングを無効にするように宛先サーバーを構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「非バッファ宛先」の値を設定し、宛先サーバーを構成します。
|
注意: 送信元サーバーでは、メッセージのバッファリングは常に有効にする必要があります。つまり、「非バッファ送信元」の値は常に無効にしておく必要があります。 |
確認応答の間隔では、宛先エンドポイントがスタンドアロンの確認応答を送信する必要のある最大間隔を指定します。確認応答の間隔を構成できるのはWebLogic ServerまたはWebサービス・エンドポイントのレベルのみであり、Webサービス・クライアントのレベルでは構成できません。
|
注意: @WebServiceRefを使用してWebサービスへの参照を定義しているWebサービス・クライアントは、確認応答の間隔の値を使用して、クライアントのレスポンス処理が確認応答の受信を待機する時間を制御します。つまり、クライアントは、レスポンス・メッセージを受信するときにRM宛先と同じように動作します。
バッファなし宛先の構成は、
<service-reference-description>
...
<port-info>
<stub-property>
<name>weblogic.wsee.wsrm.AcknowledgementInterval</name>
<value>PT5S</value>
</stub-property>
...
</port-info>
</service-reference-description>
|
宛先エンドポイントは、ソース・エンドポイントからメッセージを受信した直後に、返されたメッセージに対する確認応答を送信できます。また、スタンドアロンの確認応答として個別に確認応答を送信することもできます。返されたメッセージに対して確認応答を送信できない場合、宛先エンドポイントは、スタンドアロンの確認応答を送信するまで、確認応答の間隔に設定した時間範囲内で待機することがあります。未確認のメッセージがない場合、宛先エンドポイントは確認応答を送信しない可能性があります。
指定する値はXMLスキーマの期間を表す字句形式(PnYnMnDTnHnMnS)に従った正の値でなければなりません。ここで、nYは年数、nMは月数、nDは日数を表し、Tは日付/時刻のセパレータ、nHは時間数、nMは分数、nSは秒数を表します。この値のデフォルトはP0DT0.2S (0.2秒)です。
管理コンソールを使用して、WebLogic ServerまたはWebサービス・エンドポイントのレベルで確認応答の間隔を構成するには、次の手順を実行します。
|
注意: または、WLSTを使用して、信頼性のあるメッセージングを構成することもできます。WLSTを使用したドメインの拡張の詳細は、『Oracle WebLogic Scripting Tool』の既存ドメインの構成に関する項を参照してください。 |
管理コンソールを起動し、次の項の説明に従って、サーバー・レベルまたはWebサービス・エンドポイント・レベルで、Webサービスの信頼性のあるメッセージングのページにアクセスします。
必要に応じて、「確認応答の間隔」の値を設定します。
リクエストを配信できない場合に信頼性のある配信の障害に関する通知を受け取るには、次のweblogic.wsee.reliability2.api.ReliabilityErrorListenerインタフェースを実装します。
public interface ReliablityErrorListener {
public void onReliabilityError(ReliabilityErrorContext context);
}
表5-15では、信頼性エラー・リスナーを構成するためのweblogic.wsee.reliability2.api.WsrmClientInitFeatureメソッドについて説明します。
表5-15 信頼性エラー・リスナーを構成するためのメソッド
| メソッド | 説明 |
|---|---|
|
|
現在構成されている信頼性リスナーを取得します。 |
|
|
信頼性エラー・リスナーを設定します。 |
次の例では、Webサービス・クライアントに信頼性エラー・リスナーを実装して使用する方法を示します。この例は、例4-1「信頼性のあるWebサービス・クライアントのベスト・プラクティスの例」からの抜粋です。
import weblogic.wsee.reliability2.api.ReliabilityErrorListener;
import weblogic.wsee.reliability2.api.WsrmClientInitFeature;
...
@WebService
public class ClientServiceImpl {
...
WsrmClientInitFeature rmFeature = new WsrmClientInitFeature();
features.add(rmFeature);
ReliabilityErrorListener listener = new ReliabilityErrorListener() {
public void onReliabilityError(ReliabilityErrorContext context) {
// At a *minimum* do this
System.out.println("RM sequence failure: " +
context.getFaultSummaryMessage());
_lastResponse = context.getFaultSummaryMessage();
// And optionally do this...
// The context parameter tells you whether a request or the entire
// sequence has failed. If a sequence fails, you'll get a notification
// for each undelivered request (if any) on the sequence.
if (context.isRequestSpecific()) {
// We have a single request failure (possibly as part of a larger
// sequence failure).
// We can get the original request back like this:
String operationName = context.getOperationName();
System.out.println("Failed to deliver request for operation '" +
operationName + "'. Fault summary: " +
context.getFaultSummaryMessage());
if ("DoSomething".equals(operationName)) {
try {
String request = context.getRequest(JAXBContext.newInstance(),
String.class);
System.out.println("Failed to deliver request for operation '" +
operationName + "' with content: " +
request);
Map<String, Serializable> requestProps =
context.getUserRequestContextProperties();
if (requestProps != null) {
// Fetch back any property you sent in
// JAXWSProperties.PERSISTENT_CONTEXT when you sent the
// request.
String myProperty = (String)requestProps.get(MY_PROPERTY);
System.out.println(myProperty + " failed!");
}
} catch (Exception e) {
e.printStackTrace();
}
}
} else {
// The entire sequence has encountered an error.
System.out.println("Entire sequence failed: " +
context.getFaultSummaryMessage());
}
}
};
rmFeature.setReliabilityErrorListener(listener);
_features = features.toArray(new WebServiceFeature[features.size()]);
BackendReliableService anotherPort =
_service.getBackendReliableServicePort(_features);
...
WebLogic Serverでは、Webサービスの信頼性のあるメッセージングで使用するためのクライアントAPI weblogic.wsee.reliability2.api.WsrmClientが提供されています。このAPIを使用して、構成オプションの設定、信頼性のあるシーケンスIDの取得、信頼性のあるシーケンスの終了などの一般的なライフサイクル・タスクを実行します。
次に示すように、WsrmClient APIのインスタンスには、weblogic.wsee.reliability2.api.WsrmClientFactoryメソッドを使用して信頼性のあるWebサービス・ポートからアクセスできます。
package wsrm_jaxws.example; import java.xml.ws.WebService; import java.xml.ws.WebServiceRef; import wsrm_jaxws.example.client_service.*; import wsrm_jaxws.example.client_service.EchoResponse; import weblogic.wsee.reliability2.api.WsrmClientInitFeature; ... @WebService public class ClientServiceImpl { ... @WebServiceRef(name="ReliableEchoService") private ReliableEchoService service; private ReliableEchoPortType port = null; port = service.getReliableEchoPort(); WsrmClient wsrmClient = WsrmClientFactory.getWsrmClientFromPort(port); ...
次の項では、WsrmClientを使用して信頼性のあるメッセージ・シーケンスのライフサイクルを管理する方法を説明します。
Webサービス・信頼性のあるメッセージング・クライアントAPIの詳細は、Oracle WebLogic Server APIリファレンスのweblogic.wsee.reliability2.api.WsrmClientを参照してください。
信頼性のあるシーケンスを管理するには、次のタスクを実行します。
信頼性のあるシーケンスIDを取得および設定します(「信頼性のあるシーケンスIDの取得および設定」を参照)。
信頼性のあるシーケンスの状態にアクセスし、たとえばアクティブかどうかや、終了されているかどうかなどを判定します(「信頼性のあるシーケンスの状態へのアクセス」を参照)。
シーケンスIDは、特定の信頼性のあるシーケンスを識別するために使用されます。シーケンスIDの取得および設定は、それぞれ、weblogic.wsee.reliability2.api.WsrmClient.getSequenceID()メソッドおよびweblogic.wsee.reliability2.api.WsrmClient.setSequenceID()メソッドを使用します。getSequenceID()メソッドを発行した時点でメッセージが送信されていない場合、返される値はnullです。
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory; import weblogic.wsee.reliability2.api.WsrmClient; ... _service = new BackendReliableServiceService(); ... features.add(... some features ...); _features = features.toArray(new WebServiceFeature[features.size()]); ... BackendReliableService anotherPort = _service.getBackendReliableServicePort(_features); ... WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort); ... // Will be null String sequenceId = rmClient.getSequenceId(); // Send first message anotherPort.doSomething("Bake a cake"); // Will be non-null sequenceId = rmClient.getSequenceId();
サーバー障害からのリカバリ時には、新規作成したWebサービス上で信頼性のあるシーケンスを設定したり、クライアントまたはサーバーの再起動後にインスタンスをディスパッチしたりできます。クライアント・インスタンスのシーケンスIDの設定は高度な機能です。高度なクライアントは、setSequenceIdを使用してクライアント・インスタンスを既知のRMシーケンスに接続できます。
シーケンスの状態にアクセスするには、weblogic.wsee.reliability2.api.WsrmClient.getSequenceState()を使用します。このメソッドは、weblogic.wsee.reliability2.api.SequenceState型の定数java.lang.Enumを返します。
次の表では、シーケンスの状態に対して返される可能性のある有効な値を示します。
表5-16 シーケンスの状態の値
| シーケンスの状態 | 説明 |
|---|---|
|
|
信頼性のあるシーケンスは閉じられています。 注意: シーケンスを閉じるのは、最後の手段と考える必要があり、すべてのリクエストを受信することがないと予想される信頼性のあるメッセージング・シーケンスを閉じる準備をするだけです。詳細は、「信頼性のあるシーケンスを閉じる」を参照してください。 |
|
|
信頼性のあるシーケンスは閉じられている途中です。 注意: シーケンスを閉じるのは、最後の手段と考える必要があり、すべてのリクエストを受信することがないと予想される信頼性のあるメッセージング・シーケンスを閉じる準備をするだけです。詳細は、「信頼性のあるシーケンスを閉じる」を参照してください。 |
|
|
信頼性のあるシーケンスは作成されており、初期ハンドシェイクが完了しています。 |
|
|
信頼性のあるシーケンスは作成されている途中であり、初期ハンドシェイクは進行中です。 |
|
|
非推奨。WS-ReliableMessaging 1.0のみ。シーケンスの最後のメッセージを受信しました。 |
|
|
非推奨。WS-ReliableMessaging 1.0のみ。シーケンスの最後のメッセージは保留中です。 |
|
|
信頼性のあるシーケンスは初期状態です。初期ハンドシェイクは開始していません。 |
|
|
信頼性のあるシーケンスは終了されました。 通常の処理では、最終メッセージまでのすべてのメッセージが確認応答された後は、信頼性のあるメッセージ・シーケンスは終了されます。お薦めはできませんが、信頼性のあるシーケンスを強制的に終了できます(「信頼性のあるシーケンスの終了」を参照)。 |
|
|
信頼性のあるシーケンスは終了されている途中です。 通常の処理では、最終メッセージまでのすべてのメッセージが確認応答された後は、信頼性のあるメッセージ・シーケンスは終了されます。お薦めはできませんが、信頼性のあるシーケンスを強制的に終了できます(「信頼性のあるシーケンスの終了」を参照)。 |
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory;
import weblogic.wsee.reliability2.api.WsrmClient;
import weblogic.wsee.reliability2.api.SequenceState;
...
_service = new BackendReliableServiceService();
...
features.add(... some features ...);
_features = features.toArray(new WebServiceFeature[features.size()]);
...
BackendReliableService anotherPort =
_service.getBackendReliableServicePort(_features);
...
WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort);
...
SequenceState rmState = rmClient.getSequenceState();
if (rmState == SequenceState.TERMINATED) {
... Do some work or log a message ...
}
...
クライアントIDは、Webサービス・クライアントを示します。各クライアントは固有のIDを持っています。クライアントIDを使用して、クライアントまたはサーバーが再起動した後で信頼性のあるシーケンスに対して存在している可能性のある保存されたリクエストにアクセスできます。
クライアントIDは、WebLogic Serverによって自動的に構成されます。ポートを作成するときにweblogic.wsee.jaxws.persistence.ClientIdentityFeatureを使用して、クライアントIDをカスタム値に設定できます。詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のクライアントIDの管理に関する項を参照してください。
信頼性のあるメッセージングはクライアントIDを使用して、VMが再起動する前に送信されて、VMが終了する前に送信されなかったリクエストを発見します。以前のクライアントIDを使用して最初のクライアント・インスタンスを確立するとき、信頼性のあるメッセージングはそのポートと関連付けられているリソースを使用して、復元されたクライアントIDの代わりにリクエストの送信を開始します。
クライアントIDは、weblogic.wsee.reliability2.api.WsrmClient.getID()メソッドを使用して取得できます。
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory;
import weblogic.wsee.reliability2.api.WsrmClient;
...
_service = new BackendReliableServiceService();
...
features.add(... some features ...);
_features = features.toArray(new WebServiceFeature[features.size()]);
...
BackendReliableService anotherPort =
_service.getBackendReliableServicePort(_features);
...
WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort);
...
String clientId = rmClient.getId();
...
信頼性のあるメッセージ・シーケンスのライフサイクルの間に確認応答されたリクエストを表示するには、weblogic.wsee.reliability2.api.WsrmClient.ackRanges()メソッドを使用します。ackRanges()メソッドは、一連のweblogic.wsee.reliability.MessageRangeオブジェクトを返します。
確認応答が済んでいるリクエストの範囲を確認した後、クライアントは次を選択できます。
weblogic.wsee.reliability2.api.WsrmClient.requestAcknowledgement()メソッドを使用して、RM宛先に確認応答リクエストを送信します。
シーケンスを閉じ(「信頼性のあるシーケンスを閉じる」を参照)、特定の時間の後で確認応答されていないメッセージのアカウントに対してエラー処理を実行します。
注意: クライアントはgetAckRanges()を繰り返し呼び出して、信頼性のあるメッセージ・シーケンスを追跡できます。ただし、各呼出しにはある程度の追加オーバーヘッドが伴うことを考慮する必要があります。
weblogic.wsee.reliability2.api.WsrmClient.getMessageInfo()メソッドを使用すると、メッセージ番号に基づいて、クライアントから送信された信頼性のあるメッセージについての情報を取得できます。このメソッドは、クライアント・インスタンスから送信されたリクエスト・メッセージのシーケンシャル・メッセージ番号を表す長い値を受け取り、weblogic.wsee.reliability2.sequence.SourceMessageInfo型のメッセージに関する情報を返します。WsrmClient.getMostRecentMessageNumber()メソッドを使用すると、getMessageInfo()に渡すメッセージ番号の最大の値を特定できます。
返されるSourceMessageInfoオブジェクトは変更不可として扱う必要があり、getメソッドのみを使用する必要があります。
次の表では、送信元メッセージに関する特定の詳細にアクセスするために使用できるSourceMessageInfoメソッドの一覧を示します。
表5-17 SourceMessageInfo()のメソッド
| メソッド | 説明 |
|---|---|
|
|
メッセージIDをString値として取得します。 |
|
|
メッセージの番号をlong値として取得します。 |
|
|
現在の |
|
|
メッセージが確認応答されているかどうかを示します。 |
次の表では、宛先メッセージに関する特定の詳細にアクセスするために使用できるDestinationMessageInfoメソッドの一覧を示します。
表5-18 DestinationMessageInfo()のメソッド
| メソッド | 説明 |
|---|---|
|
|
メッセージIDをString値として取得します。 |
|
|
メッセージの番号をlong値として取得します。 |
getMessageInfo()メソッドをweblogic.wsee.reliability2.api.WsrmClient.getMostRecentMessageNumber()と組み合わせて使用すると、最後に送信された信頼性のあるメッセージについての情報を取得できます。このメソッドは、1から始まり単調に増加するlong値を返します。次の状況では、このメソッドは-1を返します。
信頼性のあるシーケンスIDが設定されていない場合(getSequenceID()はnullを返します)。
最初の信頼性のあるメッセージがまだ送信されていません。
信頼性のあるシーケンスが終了されました。
WebLogic Serverは信頼性のあるシーケンスと関連付けられたリソースを保持するので、適切なタイミングでこれらのリソースを解放することをお薦めします。通常の状況では、すべてのメッセージが送信され、RM宛先によって確認応答されるまで、信頼性のあるシーケンスを保持する必要があります。シーケンスの適切な終了を容易にするため、信頼性のあるメッセージ・シーケンスの最後のメッセージを識別することをお薦めします。これにより、RM宛先へのメッセージの送信が完了したことがわかり、WebLogic Serverは信頼性のあるシーケンスを自動的に終了する前に最後の確認応答の検索を開始できます。最後のメッセージを示すには、weblogic.wsee.reliability2.api.WsrmClient.setFinalMessage()メソッドを使用します。
最終メッセージを識別すると、最終メッセージまでの最終メッセージを含むすべてのメッセージが確認応答され、信頼性のあるメッセージ・シーケンスが終了し、すべてのリソースが開放されます。識別しない場合、シーケンスは、構成したシーケンスの有効期限に達した後で自動的に終了します。
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory;
import weblogic.wsee.reliability2.api.WsrmClient;
...
_service = new BackendReliableServiceService();
...
features.add(... some features ...);
_features = features.toArray(new WebServiceFeature[features.size()]);
...
BackendReliableService anotherPort =
_service.getBackendReliableServicePort(_features);
...
WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort);
...
anotherPort.doSomething("One potato");
anotherPort.doSomething("Two potato");
anotherPort.doSomething("Three potato");
// Indicate this next invoke marks the 'final' message for the sequence
rmClient.setFinalMessage();
anotherPort.doSomething("Four");
...
信頼性のあるメッセージング・シーケンスを閉じるには、weblogic.wsee.reliability2.api.WsrmClient.closeMessage()を使用します。
|
注意: このメソッドはWS-ReliableMessaging 1.1に対してのみ有効です。WS-ReliableMessaging 1.0ではサポートされていません。 |
信頼性のあるメッセージング・シーケンスを閉じると、新しいメッセージはRM宛先で受け付けられなくなり、RM送信元で送信されなくなります。閉じられたシーケンスは、まだ、RM宛先によって追跡され、確認応答リクエストに対応します。RM送信元は、シーケンスを終了する前に、信頼性のあるメッセージ・シーケンスの完全な会計情報を取得できます。
注意: シーケンスを閉じるのは、最後の手段と考える必要があり、すべてのリクエストを受信することがないと予想される信頼性のあるメッセージング・シーケンスを閉じる準備をするだけです。たとえば、確認応答が済んでいるリクエストの範囲を確認した後(「確認応答済みリクエストの管理」を参照)、クライアントはシーケンスを閉じる必要があると判断し、特定の時間の後で確認応答されていないメッセージのアカウントに対してエラー処理を実行できます。
信頼性のあるメッセージング・シーケンスが閉じられると、シーケンスの終了はクライアントに委ねられます。構成したタイムアウトに到達した後は、サーバーによって自動的に終了されなくなります。「信頼性のあるシーケンスの終了」を参照してください。
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory; import weblogic.wsee.reliability2.api.WsrmClient; ... _service = new BackendReliableServiceService(); ... features.add(... some features ...); _features = features.toArray(new WebServiceFeature[features.size()]); ... BackendReliableService anotherPort = _service.getBackendReliableServicePort(_features); ... WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort); ... anotherPort.doSomething("One potato"); anotherPort.doSomething("Two potato"); // ... Wait some amount of time, and check for acks // ... using WsrmClient.getAckRanges() ... // ... If we don't find all of our acks ... rmClient.closeSequence(); // ... Do some error recovery like telling our // ... client we couldn't deliver all requests ... rmClient.terminateSequence(); ...
これはお薦めできませんが、weblogic.wsee.reliability2.api.WsrmClient.terminateSequence()メソッドを使用すると、すべてのメッセージが確認応答されているかどうかに関係なく、信頼性のあるメッセージ・シーケンスを終了できます。
|
注意: 代わりに、setFinalMessage()メソッドを使用して、信頼性のあるシーケンスの最後のメッセージを識別することをお薦めします。最後のメッセージを識別すると、最後のメッセージまでのすべてのメッセージが確認応答され、信頼性のあるメッセージ・シーケンスが終了し、すべてのリソースが開放されます。詳細は、「信頼性のあるシーケンスでの最後のメッセージの識別」を参照してください。 |
シーケンスを終了すると、RM送信元とRM宛先は、そのシーケンスに関連付けられているすべての状態を削除します。クライアントは、終了されたシーケンスに対してはいかなるアクションも実行できなくなります。シーケンスが終了されると、サーバー側の再試行(SAFエージェント)によってシーケンスに対して配信された保留中のリクエストは破棄され、ReliablityErrorListenerで通知として送信されます。
例:
import weblogic.wsee.reliability2.api.WsrmClientFactory; import weblogic.wsee.reliability2.api.WsrmClient; ... _service = new BackendReliableServiceService(); ... features.add(... some features ...); _features = features.toArray(new WebServiceFeature[features.size()]); ... BackendReliableService anotherPort = _service.getBackendReliableServicePort(_features); ... WsrmClient rmClient = WsrmClientFactory.getWsrmClientFromPort(anotherPort); ... anotherPort.doSomething("One potato"); anotherPort.doSomething("Two potato"); // ... Wait some amount of time, and check for acks // ... using WsrmClient.getAckRanges() ... // ... If we don't find all of our acks ... rmClient.closeSequence(); // ... Do some error recovery like telling our // ... client we couldn't deliver all requests ... rmClient.terminateSequence(); ...
信頼性のあるシーケンスが閉じられて、保持する必要のなくなった信頼性のあるメッセージングに関係のあるすべてのRequestContextプロパティをクリアするには、weblogic.wsee.reliability2.api.WsrmClient.reset()メソッドを使用します。通常、このメソッドは、同じクライアントから信頼性のあるメッセージの別のシーケンスを開始するときに呼び出します。
reset()の使用例については、例B-1「信頼性のあるメッセージングのバッチ化のためのクライアント・ラッパー・クラスの例」を参照してください。
管理コンソールを使用して、Webサービスまたはクライアントの信頼性のあるメッセージング・シーケンスを監視できます。信頼性のあるメッセージング・シーケンスごとに、シーケンスの状態や送信元サーバーと宛先サーバーなどの、実行時監視情報が表示されます。「この表のカスタマイズ」をクリックすることで、表に表示される情報をカスタマイズできます。
具体的には、監視ページを使用して次のことを特定できます。
適切なタイミングでシーケンスをクリーンアップしているかどうか。監視タブに多数のシーケンスが表示される場合、クライアントのコードを調べて原因を特定します。
個別のシーケンスに確認応答されていないリクエストがあるか、または予想されるレスポンスを受信していないか。
Webサービスの信頼性のあるメッセージング・シーケンスを監視するには、左ペインの「デプロイメント」ノードをクリックし、右ペインに表示される「デプロイメント」表でWebサービスがパッケージ化されているエンタープライズ・アプリケーションを探します。「+」ノードをクリックしてアプリケーションを展開すると、「Webサービス」カテゴリにアプリケーション内のWebサービスのリストが表示されます。Webサービス名をクリックし、「監視」→「ポート」→「信頼性のあるメッセージング」を選択します。
Webサービス・クライアントの信頼性のあるメッセージング・シーケンスを監視するには、左ペインの「デプロイメント」ノードをクリックし、右ペインに表示される「デプロイメント」テーブルでWebサービス・クライアントがパッケージ化されているエンタープライズ・アプリケーションを探します。「+」ノードをクリックしてアプリケーションを展開し、Webサービス・クライアントが存在するアプリケーション・モジュールをクリックします。「監視」タブをクリックし、「Webサービス・クライアント」タブをクリックします。次に、「監視」→「サーバー」→「信頼性のあるメッセージング」をクリックします。
多くの場合、Webサービス・クライアントとサービスの間を流れるメッセージは、単一のビジネス・トランザクションつまり作業単位の一部です。たとえば、旅行代理店、航空会社、ホテル、レンタカー会社の間でメッセージを必要とする旅行代理店の予約処理などです。2つのエンドポイントの間を流れるすべてのメッセージはビジネス作業単位と考えることができます。
メッセージをRMシーケンスにグループ化することで、作業単位に関連のあるメッセージを処理するように信頼性のあるメッセージングを調整します。作業単位(つまりシーケンス)の全体がまとめて処理され、エラー・リカバリなどをシーケンス全体に適用できます(http://docs.oasis-open.org/ws-rx/wsrm/200702にあるWS-ReliableMessaging 1.2の仕様(2009年2月)でIncompleteSequenceBehavior要素の説明を参照)。たとえば、シーケンスのギャップの後で発生したリクエストを破棄したり、シーケンスから欠落したリクエストがある場合はリクエストのシーケンス全体を破棄したりするように、RMシーケンスを構成できます。
単位の最初のメッセージを送信する前に新しいクライアント・インスタンスを作成し、単位の最後のメッセージの後でクライアント・インスタンスを破棄することで、メッセージがビジネス作業単位の一部であることを示すことができます。または、WsrmClient API(クライアント・インスタンスをWsrmClientFactory.getWsrmClientFromPort()メソッドに渡すことで取得します)を使用して、シーケンス内の最後のリクエストが送信されようとしていることを示すことができます。これは、クライアント・インスタンスで呼出しを実行する直前にWsrmClient.setFinalMessage()を呼び出すことで行います(「信頼性のあるシーケンスでの最後のメッセージの識別」を参照)。
RMプロトコルには大きなオーバーヘッドが伴います。具体的には、シーケンスの作成と終了では、サービス(RM宛先)との間で往復メッセージが交換されます。つまり、RMシーケンスを確立して終了するには、4つのメッセージをやり取りする必要があります。このため、単一のRMシーケンス上の単一のビジネス作業単位内でリクエストを送信することには利点があります。これにより、RMプロトコルのオーバーヘッドのコストを複数のビジネス・メッセージに分割できます。
場合によっては、信頼性のあるサービスへの通信に使用されているクライアント・インスタンスは、メッセージの所属先のビジネス作業単位の固有概念がない環境で実行されます。その一例は、メッセージ・ブローカなどの仲介者です。この場合、ブローカは、メッセージ自体のみを認識し、メッセージが送信されているコンテキストを認識しないことがしばしばあります。ブローカは、ビジネス作業単位(またはシーケンス)の開始と終了の境界を定めるために何も実行しない場合があります。その結果、リクエストの送信に信頼性のあるメッセージングを使用するとき、ブローカは、送信するすべてのメッセージのRMシーケンス作成および終了プロトコルのオーバーヘッドを負担します。これは、パフォーマンスに重大な負の影響を及ぼす可能性があります。
組込みのビジネス作業単位がメッセージに対して不明の場合は、任意のグループ(バッチ)・メッセージを選択して、恣意的に作成した作業単位(バッチと呼ばれます)に含めることができます。信頼性のあるメッセージをバッチ化すると、前記のパフォーマンスに対する影響を回避でき、信頼性のあるメッセージングのクライアントとサービスの間のネットワーク使用とスループットを調整して最適化できます。関連のないリクエストを小さい単位(約10個のリクエスト)でバッチ化すると、クライアントとサービスの間のスループットが、信頼性のあるメッセージングを使用する(小さいメッセージを送信する)ときの3倍になる場合があることがテストにより示されました。
|
注意: すでにビジネス作業単位と関連付けられているリクエストをバッチ化することはお薦めしません。これは、RMシーケンスの境界と作業単位の境界が一致しない場合、エラー・リカバリが複雑になる可能性があるためです。たとえば、ReliabilityErrorListenerを(WsrmClientInitFeatureを使用して)クライアント・インスタンスに追加すると(「信頼性エラー・リスナーの実装」を参照)、このリスナーを使用してシーケンス内の単一のリクエストまたはシーケンス全体の障害に対するエラー・リカバリを実行できます。リクエストをバッチ化する場合、リクエストの障害を適切に処理するために、各リクエストに関する何らかの情報を、このエラー・リカバリ・ロジックで格納する必要があります。バッチ化を行わないクライアントのほうが、それが属しているビジネス作業単位に基づいて、リクエストに関するコンテキストをより多く保持する可能性があります。 |
次のコード例では、RMリクエストのバッチ化を簡単かつ効率的にするために使用できるBatchingRmClientWrapperという名前のクラスの例を示します。このクラスは、リクエストを指定した数のリクエストのグループにバッチ化します。通常のクライアント・インスタンスに代わる動的なプロキシを作成できます。クライアント・インスタンスで呼び出すと、バッチ・ラッパーが発信リクエストをバッチにシームレスにグループ化し、各バッチに専用のRMシーケンスを割り当てます。バッチ・ラッパーは、特定のバッチの最大存続期間を示す期間指定も取得します。これにより、バッチを完全に満たすのに十分な発信リクエストがない場合でも、完了していないバッチを適切なタイミングで完了させることができます。バッチが指定されている最大存続期間のあいだ存在している場合、バッチの最後のメッセージが送信された場合と同じように閉じられます。
信頼性のあるメッセージングをバッチ化するために使用できるクライアント・ラッパー・クラスの例は、付録B「Example Client Wrapper Class for Batching Reliable Messages」を参照してください。必要であれば、このクラスを独自のアプリケーション・コードとして使用できます。
例5-2 作業単位へのメッセージのグループ化の例(バッチ化)
import java.io.IOException;
import java.util.*;
import java.util.*;
import javax.servlet.*;
import javax.xml.ws.*;
import weblogic.jws.jaxws.client.ClientIdentityFeature;
import weblogic.jws.jaxws.client.async.AsyncClientHandlerFeature;
import weblogic.jws.jaxws.client.async.AsyncClientTransportFeature;
import weblogic.wsee.reliability2.api.ReliabilityErrorContext;
import weblogic.wsee.reliability2.api.ReliabilityErrorListener;
import weblogic.wsee.reliability2.api.WsrmClientInitFeature;
/**
* Example client for invoking a reliable Web service and 'batching' requests
* artificially into a sequence. A wrapper class called
* BatchingRmClientWrapper is called to begin and end RM sequences for each batch of
* requests. This avoids per-message RM sequence handshaking
* and termination overhead (delivering better performance).
*/
public class BestPracticeAsyncRmBatchingClient
extends GenericServlet {
private BackendReliableServiceService _service;
private BackendReliableService _singletonPort;
private BackendReliableService _batchingPort;
private static int _requestCount;
private static String _lastResponse;
@Override
public void init()
throws ServletException {
_requestCount = 0;
_lastResponse = null;
// Only create the Web service object once as it is expensive to create repeatedly.
if (_service == null) {
_service = new BackendReliableServiceService();
}
// Best Practice: Use a stored list of features, per client ID, to create client instances.
// Define all features for the Web service port, per client ID, so that they are
// consistent each time the port is called. For example:
// _service.getBackendServicePort(_features);
List<WebServiceFeature> features = new ArrayList<WebServiceFeature>();
// Best Practice: Explicitly define the client ID.
ClientIdentityFeature clientIdFeature =
new ClientIdentityFeature("MyBackendServiceAsyncRmBatchingClient");
features.add(clientIdFeature);
// Best Practice: Always implement a reliability error listener.
// Include this feature in your reusable feature list. This enables you to determine
// a reason for failure, for example, RM cannot deliver a request or the RM sequence fails in
// some way (for example, client credentials refused at service).
WsrmClientInitFeature rmFeature = new WsrmClientInitFeature();
features.add(rmFeature);
rmFeature.setErrorListener(new ReliabilityErrorListener() {
public void onReliabilityError(ReliabilityErrorContext context) {
// At a *minimum* do this
System.out.println("RM sequence failure: " +
context.getFaultSummaryMessage());
_lastResponse = context.getFaultSummaryMessage();
}
});
// Asynchronous endpoint
AsyncClientTransportFeature asyncFeature =
new AsyncClientTransportFeature(getServletContext());
features.add(asyncFeature);
// Best Practice: Define a port-based asynchronous callback handler,
// AsyncClientHandlerFeature, for asynchronous and dispatch callback handling.
BackendReliableServiceAsyncHandler handler =
new BackendReliableServiceAsyncHandler() {
public void onDoSomethingResponse(Response<DoSomethingResponse> res) {
// ... Handle Response ...
try {
DoSomethingResponse response = res.get();
_lastResponse = response.getReturn();
System.out.println("Got reliable/async/batched response: " + _lastResponse);
} catch (Exception e) {
_lastResponse = e.toString();
e.printStackTrace();
}
}
};
AsyncClientHandlerFeature handlerFeature =
new AsyncClientHandlerFeature(handler);
features.add(handlerFeature);
// Set the features used when creating clients with
// this client ID "MyBackendServiceAsyncRmBatchingClient"
WebServiceFeature[] featuresArray =
features.toArray(new WebServiceFeature[features.size()]);
// Best Practice: Define a singleton port instance and initialize it when
// the client container initializes (upon deployment).
// The singleton port will be available for the life of the servlet.
// Creation of the singleton port triggers the asynchronous response endpoint to be published
// and it will remain published until our container (Web application) is undeployed.
// Note, we will get a call to destroy() before this.
_singletonPort = _service.getBackendReliableServicePort(featuresArray);
// Create a wrapper class to 'batch' messages onto RM sequences so
// a client with no concept of which messages are related as a unit can still achieve
// good performance from RM. The class will send a given number of requests on
// the same sequence, and then terminate that sequence before starting
// another to carry further requests. A batch has both a max size and
// lifetime so no sequence is left open for too long.
// The example batches 10 messages or executes for 20 seconds, whichever comes
// first. Assuming there were 15 total requests to send, the class would start and complete
// one full batch of 10 requests, then send the next batch of five requests.
// Once the batch of five requests has been open for 20 seconds, it will be closed and the
// associated sequence terminated (even though 10 requests were not sent to fill the batch).
BackendReliableService batchingPort =
_service.getBackendReliableServicePort(featuresArray);
BatchingRmClientWrapper<BackendReliableService> batchingSeq
= new BatchingRmClientWrapper<BackendReliableService>(batchingPort,
BackendReliableService.class,
10, "PT20S",
System.out);
_batchingPort = batchingSeq.createProxy();
}
@Override
public void service(ServletRequest req, ServletResponse res)
throws ServletException, IOException {
// TODO: ... Read the servlet request ...
// For this simple example, echo the _lastResponse captured from
// an asynchronous DoSomethingResponse response message.
if (_lastResponse != null) {
res.getWriter().write(_lastResponse);
System.out.println("Servlet returning _lastResponse value: " + _lastResponse);
_lastResponse = null; // Clear the response so we can get another
return;
}
// Synchronize on _batchingPort since it is a class-level variable and it might
// be in this method on multiple threads from the servlet engine.
synchronized(_batchingPort) {
// Use the 'batching' port to send the requests instead of creating a
// new request each time.
BackendReliableService port = _batchingPort;
// Set the endpoint address for BackendService.
((BindingProvider)port).getRequestContext().
put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://localhost:7001/BestPracticeReliableService/BackendReliableService");
// Make the invocation. Our asynchronous handler implementation (set
// into the AsyncClientHandlerFeature above) receives the response.
String request = "Protected and serve " + (++_requestCount);
System.out.println("Invoking DoSomething reliably/async/batched with request: " +
request);
port.doSomethingAsync(request);
}
// Return a canned string indicating the response was not received
// synchronously. Client needs to invoke the servlet again to get
// the response.
res.getWriter().write("Waiting for response...");
}
@Override
public void destroy() {
try {
// Best Practice: Explicitly close client instances when processing is complete.
// Close the singleton port created during initialization. Note, the asynchronous
// response endpoint generated by creating _singletonPort *remains*
// published until our container (Web application) is undeployed.
((java.io.Closeable)_singletonPort).close();
// Best Practice: Explicitly close client instances when processing is complete.
// Close the batching port created during initialization. Note, this will close
// the underlying client instance used to create the batching port.
((java.io.Closeable)_batchingPort).close();
// Upon return, the Web application is undeployed, and the asynchronous
// response endpoint is stopped (unpublished). At this point,
// the client ID used for _singletonPort will be unregistered and will no longer be
// visible from the Administration Console and WLST.
} catch (Exception e) {
e.printStackTrace();
}
}
}
WebLogic Serverでは、本番用の再デプロイメントがサポートされています。つまり、信頼性のあるWebLogic Webサービスの更新後の新しいバージョンを、同じWebサービスの古いバージョンと並行してデプロイできます。
WebLogic Serverでは、新しいクライアントのリクエストのみが新しいバージョンに転送されるように、クライアント接続が自動的に管理されます。再デプロイメント時にすでにWebサービスに接続していたクライアントは、作業が完了するまで古いバージョンのサービスを使用し続け、作業が完了した時点で古いWebサービスが自動的に廃止されます。クライアントが信頼性のあるWebサービスに接続されている場合は、既存の信頼性のあるメッセージ・シーケンスがクライアントによって明示的に終了されるか、またはタイムアウトになったときに、そのクライアントの作業が完了したと見なされます。
本番用の再デプロイメントとWebサービス・クライアントの詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebサービスを再デプロイする際にクライアントで考慮すべき事項に関する項を参照してください。
WebLogic Webサービスの信頼性のあるメッセージングの実装は、IBMおよびMicrosoft .NETの各サードパーティ・ベンダーのWebサービスで提供されるWebサービスの信頼性のあるメッセージングの実装と相互運用できます。Microsoft .NETと相互運用するときのベスト・プラクティスは、『Oracle WebLogic Server WebLogic Webサービスの紹介』のMicrosoft WCF/.NETとの相互運用性に関する項を参照してください。
Webサービスの信頼性のあるメッセージングを使用するOracle SOAサービスとの相互運用性を拡張するには、相互運用性に関する次のガイドラインを考慮してください。
非同期トランスポートにはMakeConnectionを使用しないでください(「ファイアウォールの内側からの非同期Webサービス・クライアントの使用(MakeConnection)」を参照)。信頼性のあるSOAサービスはMakeConnectionをサポートしません。
WS-SecureConversationを使用して信頼性のあるWebサービスを保護しないでください。SOAサービスは、Webサービスの信頼性のあるメッセージングとWS-SecureConversationの併用をサポートしません。
信頼性のあるSOAサービスにアクセスする信頼性のあるWebLogic Webサービス・クライアントの場合:
同期(匿名WS-Addressing ReplyTo EPR)リクエスト応答または一方向MEP(メッセージ交換パターン)を使用します。
非同期(非匿名WS-Addressing ReplyTo EPR)リクエスト応答MEP(メッセージ交換パターン)は使用しないでください。
信頼性のあるWebLogic Webサービスにアクセスする信頼性のあるSOAクライアントの場合、次のいずれかを使用します。
同期(匿名WS-Addressing ReplyTo EPR)リクエスト応答または一方向MEP(メッセージ交換パターン)。
非同期(非匿名WS-Addressing ReplyTo EPR)リクエスト応答MEP(メッセージ交換パターン)。
