| 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サービス(それまでの起動における状態情報を認識している必要のないサービス)のクラスタリングは単純であり、サード・パーティのHTTPロード・バランサに対して既存のWebLogic HTTPルーティング機能と連携して動作します。
状態情報のメンテナンスが必要なWebサービスのクラスタリングには課題がいくつかあります。そのようなWebサービスの各インスタンスは状態情報に関連付けられており、この状態情報を管理し、保持する必要があります。クラスタでのルーティングの決定は、メッセージがクラスタ内の特定のサーバーにバインドされているかどうかに基づいて行われます。たとえば、メッセージの処理に必要な状態情報が特定のサーバーに格納されいる場合、その状態情報はそのサーバーでローカルに使用することしかできません。
|
注意: セッション状態レプリケーションを使用して状態を管理するサービスは、Reliable Secure ProfileのようなWebサービスの高度な機能を利用するサービスとは問題の種類が異なります。後者では、ローカル・サーバーのみで利用できる状態の格納を備えるなど、永続性に関してより堅牢なアプローチが必要です。詳細は、「永続性に関する注意」を参照してください。 |
Webサービス・リクエストが適切なサーバーにルーティングされるようにするだけでなく、クラスタリングに関する次の一般的な要件を満たす必要があります。
クラスタの内部トポロジは、クライアントに対して透過的にする必要があります。クライアントは、フロントエンド・ホストのみを介してクラスタと相互通信するため、クラスタ内の特定のサーバーを認識する必要はありません。これによって、クラスタは時間をかけて拡張し、需要を満たすことができます。
クラスタの移行がクライアントに対して透過的に行われることが必要です。クラスタ内のリソース(永続ストアなど、WebサービスまたはWebサービス・クライアントに必要なリソース)は、クラスタの拡大や障害対応などの理由で、あるサーバーから別のサーバーへ移行できます。
クラスタ内のWebサービスのルーティングについては、前述の要件に合せて、次の方式が用意されています。
インプレースSOAPルーター: リクエスト・メッセージが正しいサーバーに届き、そうでない場合は正しいサーバーに転送されることを前提としています(追加ホップは最大1回)。ルーティングの決定は、メッセージを受信するWebサービスが行います。このルーティング方式は実装が最も簡単であり、構成も必要ありません。ただし、次の方式に比べると堅牢性に劣ります。
フロントエンドSOAPルーター (HTTPクラスタ・サーブレットのみ): メッセージ・ルーティングは、クラスタのかわりにメッセージを受け入れるフロントエンド・ホストによって管理され、クラスタの選択メンバー・サーバーに転送します。Webサービスの場合、フロントエンドSOAPルーターは、SOAPメッセージ内の情報を検査し、メッセージをルーティングする先の正しいサーバーを決定します。
このルーティング方式は構成が複雑ですが、メッセージが適切なサーバーに直接ルーティングされるため効率的です(追加ホップは発生しません)。
|
注意: 「ファイアウォール内からの非同期Webサービス・クライアントの使用(MakeConnection)」の説明に従ってMakeConnectionを使用するとき、所定のMakeConnection匿名URIに関連するすべてのメッセージの適切なルーティングを保証できるのはフロントエンドSOAPルーティングのみです。 |
この章では、クラスタ内のWebサービスのルーティングが最適化されるように環境を構成する方法について説明します。フロントエンドSOAPルーターとしてのHTTPクラスタ・サーブレットの使用についても説明します。また、インプレースSOAPルーターを有効化し、HTTPクラスタ・サーブレットが使用できない場合や初期化されていない場合に使用します。
永続性に関する注意
「HTTPセッションを使用したステートフルJAX-WS Webサービスのプログラミング」で説明されているように、一部のケースではHttpSessionを使用してWebサービスの状態を維持できますが、この単純な永続性には十分な堅牢性がありません。Webサービスの高度な機能(信頼性のあるメッセージング、MakeConnection、Secure Conversationなど)では堅牢な永続性が要件となっており、HttpSessionのみを使用して満たすことはできません。Webサービスの高度な機能は、論理ストアという概念に基づいた専用の永続性実装を使用します。詳細は、「Webサービス永続性の管理」を参照してください。
現時点では、Webサービス状態の永続性に関するこの2つのアプローチには互換性がありません。HttpSession永続性を使用するクラスタ化ステートフルWebサービスの作成を選択してから、(クライアントまたはサービスとして)そのサービスでWebサービスの高度な機能を使用すると、クラスタにおけるサービスの正常な動作が保証されません。これは、HttpSessionレプリケーションが、Webサービスの高度な機能の永続性をホストするのではなく、様々なサーバー・セットでHttpSessionを使用可能にできるためです。
次の項では、クラスタ環境内でWebサービスのリクエスト・メッセージとレスポンス・メッセージをルーティングする際のシナリオについて、図を使用して説明します。
このシナリオでは、受信したリクエストがサーバーに対してロード・バランシングされます。そのリクエストへのレスポンスをすべて、その同じサーバーにルーティングすることによって、元のリクエストにかわって状態情報を保持する必要があります。
前の図に示すように、次のような処理が行われます。
フロントエンドSOAPルーターが、受信したHTTPリクエストをルーティングし、標準的なロード・バランシング手法でServer2に送信します。
Server2が、Webサービスのエンドポイント・アドレスにあるMyserviceを呼び出します。SOAPメッセージのReplyToヘッダーには、フロントエンドSOAPルーターへのポインタが含まれています。
MyServiceがフロントエンドSOAPルーターにレスポンスを戻します。
フロントエンドSOAPルーターは、レスポンスのルーティング先を決定する必要があります。Server2がレスポンスに関連する状態情報を保持しているため、フロントエンドSOAPルーターはレスポンスをServer2にルーティングします。
このシナリオでは、受信したリクエストがサーバーに対してロード・バランシングされます。レスポンスには、後続のリクエストに関する元のサーバーを宛先とするルーティング情報が含まれています。
前の図に示すように、次のような処理が行われます。
フロントエンドSOAPルーターが、受信したHTTPリクエスト(Request1)をルーティングし、標準的なロード・バランシング手法でServer2に送信します。リクエストにはルーティング情報は含まれていません。
Server2が、Webサービスのエンドポイント・アドレスにあるMyserviceを呼び出します。SOAPメッセージのReplyToヘッダーには、フロントエンドSOAPルーターへのポインタが含まれています。
MyServiceが呼出し元にレスポンスを戻します。レスポンスには、Server2を後続のすべてのリクエストのターゲットに指定するルーティング情報が含まれています。呼出し元は、レスポンスに含まれているルーティング情報を、後続のすべてのリクエスト(Request2など)に入れて渡します。
フロントエンドSOAPルーターが、Request2とともに渡されたルーティング情報を使用して、Request2をServer2にルーティングします。
このシナリオでは、受信したSOAPリクエストにIDが含まれていますが、ルーティング情報は含まれていません。同じIDを持つ後続のリクエストはすべて、同じサーバーに送られる必要があります。
前の図に示すように、次のような処理が行われます。
リクエストは、ID (MakeConnection匿名URI)を含むWebサービス・クライアントに由来し、このIDはRequest1に関連する将来のリクエストによって共有されます。このIDのフォームはプロトコル固有のものです。
フロントエンドSOAPルーターがRequest1のIDを検出し、アフィニティ・ストアをチェックして、そのIDがクラスタ内の特定のサーバーに関連付けられていないかを調べます。この場合、関連付けは定義されていません。
フロントエンドSOAPルーターがリクエストのロード・バランシングを行い、処理のためにリクエストをServer2に送信します。
Server2のMyService Webサービス・インスタンスがリクエストを処理します(必要に応じてレスポンスを生成します)。この場合、シナリオ2: ルーティング情報を使用した単一サーバーへのWebサービス・レスポンスのルーティングとは異なり、ルーティング情報は伝播できません。
Request1で使用したのと同じIDを使用して、Request2がフロントエンドSOAPルーターに到着します。
フロントエンドSOAPルーターがIDを検出し、アフィニティ・ストアをチェックして、そのIDが特定のサーバーに関連付けられていないかを調べます。この場合、IDがServer2にマップされていることが判明します。
アフィニティ情報に基づいて、フロントエンドSOAPルーターがRequest2をServer2にルーティングします。
次の項では、Webサービス・クラスタでのルーティングの仕組みについて説明します。
Webサービス・ランタイムは、次のような場合でもメッセージのルーティングが適切に行われるよう、送信するすべてのメッセージのSOAPヘッダーにルーティング情報を追加します。
リクエストの送信元のWebサービス・クライアントが、クラスタに属するすべてのサーバーからはアクセスできないストアを使用している場合。
リクエストが、レスポンスの処理に使用されるメモリー内の状態情報を必要とする場合。
送信するメッセージを処理する際、Webサービス・ランタイムは次のことを実行します。
送信するリクエストにメッセージIDが割り当てられていない場合はメッセージIDを作成し、RelatesTo/MessageID SOAPヘッダーに次の形式で格納します。
uuid:WLSformat_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ルーターは単にリクエストのロード・バランシングを行い、インプレース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レスポンス・ヘッダーは次の形式を取ります。
storename1:host_server_spec | storename2:host_server_spec | storename3: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サービスを構成する手順をまとめます。
表8-1 クラスタ内のWebサービスを管理する手順
| # |
手順 | 説明 |
|---|---|---|
|
1 |
WebLogicクラスタを設定します。 |
「WebLogicクラスタの設定」を参照してください。 |
|
2 |
Webサービスの高度な機能に必要なクラスタ・ドメイン・リソースを構成します。 |
クラスタ拡張テンプレート・スクリプトを使用すると、必要なクラスタ・ドメイン・リソースを自動的に構成できます。もう1つの方法として、Oracle WebLogic管理コンソールまたはWLSTを使用し、リソースを構成することも可能です。「クラスタ環境におけるWebサービスの高度な機能に必要なドメイン・リソースの構成」を参照してください。 |
|
3 |
フロントエンドSOAPルーターを拡張してWebサービスをサポートします。 |
注意: この手順は、フロントエンドSOAPルーターを使用する場合のみ必要です。 Webサービス・ルーティング・サーブレットは、WebLogic HTTPクラスタ・サーブレットの機能を拡張して、クラスタ内のWebサービスのルーティングをサポートします。「フロントエンドSOAPルーターの拡張によるWebサービスのサポート」を参照してください。 |
|
4 |
Webサービス原子性トランザクション・メッセージのルーティングを有効にします。 |
「Webサービス原子性トランザクション・メッセージのルーティングの有効化」を参照してください。 |
|
5 |
フロントエンド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_webservices_jaxws.jar)を適用すると、クラスタ環境でWebサービスの高度な機能をサポートするのに必要なリソースを自動的に構成できます。この拡張テンプレートの使用は必須ではありませんが、使用すると必要なリソースの構成が格段に容易になります。もう1つの方法として、Oracle WebLogic管理コンソールまたはWLSTを使用し、高度な機能に必要なリソースを構成することも可能です。
また、テンプレートによって、ドメインの変化(サーバーの追加や削除など)に合せて、高度なWebサービスで必要なリソースを管理するために使用できるスクリプトがドメイン・ディレクトリにインストールされます。
ドメインの構成方法やリソースを管理するためのスクリプトの実行方法の詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』の高度なWeb Services機能のためのドメインの構成に関する項を参照してください。
|
注意: フロントエンド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サーバー・プラグインの一般的なパラメータに関する項を参照してください。
クラスタ内の各WebLogic ServerインスタンスをフロントエンドSOAPルーターのアドレスおよびポートで構成する必要があります。ネットワーク・チャネルを使用すると、クラスタのフロントエンド・アドレスにアクセスするための一貫した方法を提供できます。ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・チャネルの理解に関する項を参照してください。
各サーバー・インスタンスについて、以下の手順を実行します。
Webサービスの呼出しに使用するプロトコル用のネットワーク・チャネルを作成します。ネットワーク・チャネルの名前は、weblogic-wsee-proxy-channel-XXXとする必要があります(XXXはプロトコルを表します)。たとえば、HTTPS用のネットワーク・チャネルを作成する場合、weblogic-wsee-proxy-channel-httpsという名前にします。
ネットワーク・チャネルの作成に関する一般情報は、Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。
「外部リスニング・アドレス」および「外部リスニング・ポート」フィールドを、それぞれプロキシ・サーバーのアドレスおよびポートで更新して、ネットワーク・チャネルを構成します。
次のクラスタ・ルーティング統計をモニターすると、アプリケーションのパフォーマンスを評価できます。
リクエストおよびレスポンスの総数。
サーバーにルーティングされたリクエストおよびレスポンスの総数。
ルーティングの失敗に関する情報(総数と最後の失敗を含む)。
WebLogic Server管理コンソールまたはWLSTを使用して、クラスタのルーティング・パフォーマンスをモニターできます。WebLogic Server管理コンソールを使用してクラスタのルーティング・パフォーマンスをモニターする方法については、Oracle WebLogic Server管理コンソール・ヘルプのWebサービスのモニターに関する項およびWebサービス・クライアントのモニターに関する項を参照してください。
