Oracle® Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの開発 12c (12.2.1.3.0) E90362-03 |
|
前へ |
次 |
この章の内容は次のとおりです:
注意:
クラスタでのWebサービス永続性の使用に関する考慮事項は、「クラスタでのWebサービス永続性の使用」を参照してください
ステートレスWebサービス(それまでの起動における状態情報を認識している必要のないサービス)のクラスタリングは単純であり、サード・パーティのHTTPロード・バランサに対して既存のWebLogic HTTPルーティング機能と連携して動作します。
状態情報のメンテナンスが必要なWebサービスのクラスタリングには課題がいくつかあります。そのようなWebサービスの各インスタンスは状態情報に関連付けられており、この状態情報を管理し、保持する必要があります。クラスタでのルーティングの決定は、メッセージがクラスタ内の特定のサーバーにバインドされているかどうかに基づいて行われます。たとえば、メッセージの処理に必要な状態情報が特定のサーバーに格納されいる場合、その状態情報はそのサーバーでローカルに使用することしかできません。
注意:
セッション状態レプリケーションを使用して状態を管理するサービスは、Reliable Secure ProfileのようなWebサービスの高度な機能を利用するサービスとは問題の種類が異なります。後者では、ローカル・サーバーのみで利用できる状態の格納を備えるなど、永続性に関してより堅牢なアプローチが必要です。詳細は、「永続性に関する注意」を参照してください
Webサービス・リクエストが適切なサーバーにルーティングされるようにするだけでなく、クラスタリングに関する次の一般的な要件を満たす必要があります。
クラスタの内部トポロジは、クライアントに対して透過的にする必要があります。クライアントは、フロントエンド・ホストのみを介してクラスタと相互通信するため、クラスタ内の特定のサーバーを認識する必要はありません。これによって、クラスタは時間をかけて拡張し、需要を満たすことができます。
クラスタの移行がクライアントに対して透過的に行われることが必要です。クラスタ内のリソース(永続ストアなど、WebサービスまたはWebサービス・クライアントに必要なリソース)は、クラスタの拡大や障害対応などの理由で、あるサーバーから別のサーバーへ移行できます。
クラスタ内のWebサービスのルーティングについては、前述の要件に合せて、次の方式が用意されています。
インプレースSOAPルーター: リクエスト・メッセージが正しいサーバーに届き、そうでない場合は正しいサーバーに転送されることを前提としています(追加ホップは最大1回)。ルーティングの決定は、メッセージを受信するWebサービスが行います。このルーティング戦略は実装が最も簡単であり、構成も必要ありません。ただし、次の方式に比べると堅牢性に劣ります。
フロントエンドSOAPルーター (HTTPクラスタ・サーブレットのみ): メッセージ・ルーティングは、クラスタのかわりにメッセージを受け入れるフロントエンド・ホストによって管理され、クラスタの選択メンバー・サーバーに転送します。Webサービスの場合、フロントエンドSOAPルーターは、SOAPメッセージ内の情報を検査し、メッセージをルーティングする先の正しいサーバーを決定します。
このルーティング戦略は構成が複雑ですが、メッセージが適切なサーバーに直接ルーティングされるため効率的です(追加ホップは発生しません)。
注意:
「ファイアウォールの内側からの非同期Webサービス・クライアントの使用(接続作成)」の説明に従って接続作成を使用するとき、所定の接続作成匿名URIに関連するすべてのメッセージの適切なルーティングを保証できるのはフロントエンドSOAPルーティングのみです。
この章では、クラスタ内のWebサービスのルーティングが最適化されるように環境を構成する方法について説明します。フロントエンドSOAPルーターとしてのHTTPクラスタ・サーブレットの使用についても説明します。また、インプレースSOAPルーターを有効化し、HTTPクラスタ・サーブレットが使用できない場合や初期化されていない場合に使用します。
永続性に関する注意
「HTTPセッションを使用したステートフルJAX-WS Webサービスのプログラミング」で説明されているように、一部のケースではHttpSessionを使用してWebサービスの状態を維持できますが、この単純な永続性には十分な堅牢性がありません。Webサービスの高度な機能(信頼性のあるメッセージング、接続作成、Secure Conversationなど)では堅牢な永続性が要件となっており、HttpSessionのみを使用して満たすことはできません。Webサービスの高度な機能は、論理ストアという概念に基づいた専用の永続性実装を使用します。詳細は、「Webサービス永続性の管理」を参照してください
現時点では、Webサービス状態の永続性に関するこの2つのアプローチには互換性がありません。HttpSession永続性を使用するクラスタ化ステートフルWebサービスの作成を選択してから、(クライアントまたはサービスとして)そのサービスでWebサービスの高度な機能を使用すると、クラスタにおけるサービスの正常な動作が保証されません。これは、HttpSessionレプリケーションが、Webサービスの高度な機能の永続性をホストするのではなく、様々なサーバー・セットでHttpSessionを使用可能にできるためです。
次の項では、クラスタ環境内でWebサービスのリクエスト・メッセージとレスポンス・メッセージをルーティングする際のシナリオについて、図を使用して説明します。
このシナリオでは、受信したリクエストがサーバーに対してロード・バランシングされます。そのリクエストへのレスポンスをすべて、その同じサーバーにルーティングすることによって、元のリクエストにかわって状態情報を保持する必要があります。
前の図に示すように、次のような処理が行われます。
このシナリオでは、受信したリクエストがサーバーに対してロード・バランシングされます。レスポンスには、後続のリクエストに関する元のサーバーを宛先とするルーティング情報が含まれています。
前の図に示すように、次のような処理が行われます。
このシナリオでは、受信したSOAPリクエストにIDが含まれていますが、ルーティング情報は含まれていません。同じIDを持つ後続のリクエストはすべて、同じサーバーに送られる必要があります。
前の図に示すように、次のような処理が行われます。
次の項では、Webサービス・クラスタでのルーティングの仕組みについて説明します。
Webサービス・ランタイムは、次のような場合でもメッセージのルーティングが適切に行われるよう、送信するすべてのメッセージのSOAPヘッダーにルーティング情報を追加します。
リクエストの送信元のWebサービス・クライアントが、クラスタに属するすべてのサーバーからはアクセスできないストアを使用している場合。
リクエストが、レスポンスの処理に使用されるメモリー内の状態情報を必要とする場合。
送信するメッセージを処理する際、Webサービス・ランタイムは次のことを実行します。
送信するリクエストにメッセージIDが割り当てられていない場合はメッセージIDを作成し、RelatesTo
/MessageID
SOAPヘッダーに次の形式で格納します。
uuid:WLS
format_version
:
store_name
:
uniqueID
説明:
format_version
には、WebLogic Server形式のバージョン(WLS1
など)を指定します。
store_name
には、永続ストア(メッセージを送信する現在のWebサービスまたはWebサービス・クライアントによって使用されるストア)の名前を指定します。たとえば、Server1Store
です。この値は、システムで生成される名前(デフォルトの永続ストアを使用する場合)または空の文字列(永続ストアが構成されていない場合)です。
unique_ID
には、一意のメッセージIDを指定します。例:68d6fc6f85a3c1cb:-2d3b89ab8:12068ad2e60:-7feb
です。
他のWebサービス・コンポーネントが、メッセージにルーティング情報を組み込んでからメッセージを送信できるようにします。
SOAPルーター(インプレースまたはフロントエンド)は、受信したリクエストにルーティング情報がないかチェックします。特に、SOAPルーターはRelatesTo
/MessageID
SOAPヘッダーを探して永続ストアの名前を特定し、その永続ストアをホストするサーバーにメッセージを戻します。
フロントエンドSOAPルーティングを使用して正しいサーバーを判別する際にエラーが発生した場合、メッセージはクラスタ内のいずれかのサーバーに送信され、インプレースSOAPルーターが使用されます。インプレースSOAPルーターでフォルトが発生した場合、メッセージの送信元はプロトコル固有のバック・チャネルでフォルトを受信します。
注意:
ルーティング情報を含むSOAPメッセージ・ヘッダーは、平文で表す必要があります。暗号化することはできません。
ルーティングの決定を助けるため、SOAPルーター(インプレースまたはフロントエンド)はストアとサーバーの名前の関連付けを表す動的マッピングを使用します。この動的マップはクラスタ内の管理対象サーバーで作成されたもので、インプレースSOAPルーターはメモリー内でアクセスし、フロントエンドSOAPルーターはHTTPレスポンス・ヘッダーを介してアクセスします。HTTPレスポンス・ヘッダーは、クラスタ内のWebサービスから送信されたすべてのHTTPレスポンスに自動的に組み込まれます。
注意:
HTTPレスポンス・ヘッダーの詳細は、「フロントエンドSOAPルーターでのルーティング・マップの保持」を参照してください。
当初、動的マップは空です。初期化されるのは、クラスタ内の管理対象サーバーから最初のレスポンスを受信した後です。HTTPレスポンス・ヘッダーを含む最初のレスポンスを受信するまで、フロントエンドSOAPルーターは単にリクエストのロード・バランシングを行い、インプレースSOAPルーターはリクエストを適切なサーバーにルーティングします。
SOAPベースのルーティング情報がない場合、単純なロード・バランシング(ラウンドロビンなど)が行われている、HTTPセッション・ベースのルーティングを含むベース・ルーティングに従います。
「クラスタ内でのリクエストのルーティング」で述べたように、ルーティングの決定を助けるため、SOAPルーター(インプレースまたはフロントエンド)はストアとサーバーの名前の関連付けを表す動的マッピングを使用します。
この動的マップを生成するために、2つの新しいHTTPレスポンス・ヘッダーが用意されています(この後の項を参照)。これらのヘッダーは、クラスタ内のWebサービスから送信されたすべてのHTTPレスポンスに自動的に組み込まれます。
注意:
サード・パーティのフロントエンドを実装する際は、この後説明するHTTPレスポンス・ヘッダーを組み込むために、変数X-weblogic-wsee-request-storetoserver-list
を任意の値に設定したHTTPリクエスト・ヘッダーを、クライアントから送信する必要があります。
ストアとサーバーのマッピングの一覧は、X-weblogic-wsee-storetoserver-list
HTTPレスポンス・ヘッダーに保持されます。フロントエンドSOAPルーターは、このヘッダーを使用して、実行時に参照可能なマッピングにデータを移入し、メッセージのルーティングを行います。
X-weblogic-wsee-storetoserver-list
HTTPレスポンス・ヘッダーは次の形式を取ります。
storename
1:
host_server_spec
|
storename
2:
host_server_spec
|
storename
3:
host_server_spec
各値の説明は次のとおりです。
storename
には、永続ストアの名前を指定します。
host_server_spec
には、servername:host:port:sslport
という形式で指定します。不明な場合、sslport
は-1に設定されます。
ストアとサーバーのリストのハッシュ・マッピングは、X-weblogic-wsee-storetoserver-hash
HTTPレスポンス・ヘッダーに指定されます。このヘッダーを使用すると、新しいマッピング・リストをリフレッシュする必要があるかどうかを判断できます。
X-weblogic-wsee-storetoserver-hash
HTTPレスポンス・ヘッダーには、X-weblogic-wsee-storetoserver-list
HTTPレスポンス・ヘッダーに含まれるリストのハッシュ値を表す文字列値が組み込まれます。リストの最後のエントリを追跡することで、リストのリフレッシュが必要かどうかを判断できます。
次の表に、クラスタ内のWebサービスを構成する手順をまとめます。
表23-1 クラスタ内のWebサービスを管理する手順
# | 手順 | 説明 |
---|---|---|
1 |
WebLogicクラスタを設定します。 |
「WebLogicクラスタの設定」を参照してください。 |
2 |
Webサービスの高度な機能に必要なクラスタ・ドメイン・リソースを構成します。 |
クラスタ拡張テンプレート・スクリプトを使用すると、必要なクラスタ・ドメイン・リソースを自動的に構成できます。もう1つの方法として、Oracle WebLogic Server管理コンソールまたはWLSTを使用し、リソースを構成することも可能です。「クラスタ環境におけるWebサービスの高度な機能に必要なドメイン・リソースの構成」を参照してください。 |
3 |
フロントエンドSOAPルーターを拡張してWebサービスをサポートします。 |
注意: この手順は、フロントエンドSOAPルーターを使用する場合のみ必要です。 Webサービス・ルーティング・サーブレットは、WebLogic HTTPクラスタ・サーブレットの機能を拡張して、クラスタ内のWebサービスのルーティングをサポートします。「フロントエンドSOAPルーターの拡張によるWebサービスのサポート」を参照してください。 |
4 |
Webサービス原子性トランザクション・メッセージのルーティングを有効にします。 |
|
5 |
Webサービスの接続作成メッセージのルーティングを有効にします。 |
「Webサービスの接続作成メッセージのルーティングの有効化」を参照してください |
6 |
フロントエンドSOAPルーターのIDを構成します。 |
クラスタ内の各WebLogic ServerインスタンスをフロントエンドSOAPルーターのアドレスおよびポートで構成する必要があります。「フロントエンドSOAPルーターのIDの構成」を参照してください。 |
Oracle WebLogic Serverクラスタの管理のWebLogicクラスタの設定の説明に従って、WebLogicクラスタを設定します。次の点に注意してください。
クラスタ・ドメインを構成するには、「クラスタ環境におけるWebサービスの高度な機能に必要なドメイン・リソースの構成」を参照してください
SOAPベースのフロントエンドSOAPルーティングを有効にするには、Oracle WebLogic Serverクラスタの管理のHttpClusterServletの設定の説明に従って、HTTPクラスタ・サーブレットを構成します。
構成ウィザードを使用してドメインの作成または拡張を行う際には、WebLogic Advanced Web Services for JAX-WS拡張テンプレート(wls_webservice_jaxws.jar
)を適用すると、クラスタ環境でWebサービスの高度な機能をサポートするのに必要なリソースを自動的に構成できます。この拡張テンプレートの使用は必須ではありませんが、使用すると必要なリソースの構成が格段に容易になります。あるいは、Oracle WebLogic Server管理コンソールまたはWLSTを使用して、これらの高度な機能に必要なリソースを構成できます。
また、テンプレートによって、ドメインの変化(サーバーの追加や削除など)に合せて、高度なWebサービスで必要なリソースを管理するために使用できるスクリプトがドメイン・ディレクトリにインストールされます。
ドメインを構成して、リソースを管理するスクリプトを実行する方法の詳細は、「高度なWebサービス機能のためのドメインの構成」を参照してください
注意:
フロントエンドSOAPルーターを使用しない場合、この手順は不要です。
フロントエンドSOAPルーターを拡張してWebサービスをサポートするには、次の例(太字
の部分)に示すRoutingHandlerClassNameパラメータを、WebLogic HTTPクラスタ・サーブレット定義の一部として指定します。
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <servlet> <servlet-name>HttpClusterServlet</servlet-name> <servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class> <init-param> <param-name>WebLogicCluster</param-name> <param-value>Server1:7001|Server2:7001</param-value> </init-param> <init-param> <param-name>RoutingHandlerClassName</param-name> <param-value> weblogic.wsee.jaxws.cluster.proxy.SOAPRoutingHandler </param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>HttpClusterServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> . . . </web-app>
Webサービス原子性トランザクション・メッセージの高可用性およびルーティングは、Webサービスのクラスタ環境では自動的に有効になります。ただし、WebLogic HTTPクラスタ・サーブレットがフロントエンド・サーバーとして使用されている場合は、WebLogic HTTPクラスタ・サーブレットをホストするサーバーで、次のシステム・プロパティをfalse
に設定する必要があります。
weblogic.wsee.wstx.wsat.deployed=false
また、WebLogic Serverプラグインを使用するときは、WLIOTimeoutSecs
パラメータ値を適切に構成する必要があります。このパラメータは、WebLogic Serverからのリクエストに対するレスポンスをプラグインが待機する時間を定義します。サーブレットの処理時間より短くした場合は、予期しない結果が発生する場合があります。WLIOTimeoutSecs
パラメータの詳細は、Oracle WebLogic Serverプロキシ・プラグインの使用のWebサーバー・プラグインの一般的なパラメータに関する項を参照してください。
Webサービスの接続作成をサポートするには、「ファイアウォールの内側からの非同期Webサービス・クライアントの使用(接続作成)」に記載されているように、WebLogic HTTPクラスタ・サーブレットをホストしているWebLogic Server上にデフォルトの論理ストアを構成する必要があります。デフォルトの論理ストアの構成の詳細は、「論理ストアの構成」を参照してください
クラスタ内の各WebLogic ServerインスタンスをフロントエンドSOAPルーターのアドレスおよびポートで構成する必要があります。
次の方法(優先度の高い順にリストされています)のいずれかを使用して、フロントエンドSOAPルーターのIDを構成できます。
「ネットワーク・チャネルを使用したフロントエンドSOAPルーターのIDの構成」の説明に従って、ネットワーク・チャネルを作成します。このオプションをお薦めします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ用のHTTP設定の構成の説明に従って、クラスタのフロントエンド・ホストとポートを構成します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPプロトコルの構成の説明に従って、ローカル・サーバーのフロントエンド・ホストとポートを構成します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成の説明に従って、クラスタのCluster Address
を定義します。Cluster Address
は、他の値が設定されていない場合に必要となります。
次のクラスタ・ルーティング統計をモニターすると、アプリケーションのパフォーマンスを評価できます。
リクエストおよびレスポンスの総数。
サーバーにルーティングされたリクエストおよびレスポンスの総数。
ルーティングの失敗に関する情報(総数と最後の失敗を含む)。
WebLogic Server管理コンソールまたはWLSTを使用して、クラスタのルーティング・パフォーマンスをモニターできます。WebLogic Server管理コンソールを使用してクラスタのルーティング・パフォーマンスをモニターする方法については、Oracle WebLogic Server Administration Consoleオンライン・ヘルプのSOAP WebサービスのモニターおよびSOAP Webサービス・クライアントのモニターを参照してください。WLSTを使用してクラスタのルーティング・パフォーマンスをモニターする方法については、WebLogicスクリプティング・ツールの理解の既存のドメインの構成を参照してください。