JP2007317199A

JP2007317199A - ウエブ・サービス・インスタンスがホストする適切なサーバに送られていることを検証する方法、装置、およびコンピュータ・プログラム

Info

Publication number: JP2007317199A
Application number: JP2007137251A
Authority: JP
Inventors: Daniel James Matthews; ダニエル、ジェームス、マシューズ; Ian Robinson; イアン、ロビンソン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2006-05-24
Filing date: 2007-05-23
Publication date: 2007-12-06
Anticipated expiration: 2027-05-23
Also published as: US20080060082A1; CN101079901B; CN101079901A; JP5043509B2; US7937436B2; GB0610302D0

Abstract

【課題】クライアントの要求が、複数のステートフルなウエブ・サービス・インスタンスを有するシステムの、特定のステートフルなウエブ・サービス・インスタンスをホストする適切なサーバに送られていることを検証する方法、装置、およびコンピュータ・プログラムを提供する。
【解決手段】特定のステートフルなウエブ・サービス・インスタンスとは、クライアントの要求を処理するのに必要な状態データを有するものである。ウエブ・サービス・インスタンスが処理する要求を受け取る。その要求から何らかの識別データを抽出する。識別データは、必要な状態データおよびその状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する。さらに、ターゲット・サーバのアイデンティティがクライアントの要求を受け取ったサーバのものと一致するかどうかを判別し、否定の判別結果に応答して、ルーティング障害を報告する。
【選択図】図１

Description

本発明は、ウエブ・サービスに関係し、より具体的にはウエブ・サービス要求が正しいターゲット・サーバに到着していることを検証することに関係する。

ウエブ・サービスは典型的にはステートレス（stateless＝状態を保持しない）で、そのためウエブ・サービス要求がその要求を処理できるターゲットに届けられる場合、要求は正しく届けられたとみなされる。ターゲットが見つからない場合または要求を処理できない場合、エラーが発生して、要求者に返される。このような場合、要求が正しく送られたことの検証は、存在しかつ要求を処理できるターゲットならどれも有効と考えられるため単純である。

しかし、すべてのウエブ・サービスがステートレスとは限らない。ステートフル（stateful = 履歴を保持する）なウエブ・サービスに対して要求するにはアドレス指定メカニズムを要する。ステートフルなウエブ・サービスにアドレス指定されるウエブ・サービス要求は単にその要求を処理できるウエブ・サービス・インスタンスだけでなく、要求がアドレス指定された特定のウエブ・サービス・インスタンスにも届けられなければならない。ステートフルなウエブ・サービスをアドレス指定する最も単純な方法は、ステートフルなウエブ・サービス自体の固有アドレスを含む直接アドレス指定システムである。当該直接アドレス指定は一般に信頼性があるが、高可用性などの一定の能力が限られる。

要求の経路選択に中間ノード（または複数のノード）が関与する場合にはかならず間接アドレス指定が必要となるのが通例である。本論において中間ノードとは、要求の送り先を変更するまたは経路を変更するエンティティである。例えば、ノードはウエブ・サーバなどの個別プロセス、またはさらに言えば、例えば要求者内で実行するロジックの経路選択をするコンポーネントとなろう。作業負荷の管理および高可用性機能に通常ルーティング・コードが使われる。セキュリティを提供するファイヤウォールの使用を含め、実世界のシステム・トポロジをサポートするために通常ウエブ・サーバおよびプロキシ・サーバが使われ、それによってターゲット・ウエブ・サービスのアドレスはクライアントが直接アドレス指定できなくてもよい。

間接アドレス指定を使用する場合は常に、ステートフルなウエブ・サービスにアドレス指定されるウエブ・サービス要求が間違ったサーバに誤って送られる可能性が高い。これは、ステートフルなウエブ・サービス・インスタンスのフェイルオーバーまたは作業負荷管理上の再配置、ルーティング・データの不正確な管理およびデータの伝播遅延を含むが、それだけに限定されない多数の理由が考えられる。このような場合、受け取られた要求がステートフルなウエブ・サービス・インスタンスをホストしないサーバに間違って送られた場合と、受け取られた要求が適切なサーバに正しく送られたがステートフルなウエブ・サービス・インスタンスがもはや存在していないアクセス場合とを、ユーザ・コードが区別することは単純なタスクではない。

従って、本発明は、クライアントの要求が複数のステートフル（stateful＝状態を保持する）なウエブ・サービス・インスタンスを有するシステム内の、クライアントの要求を処理するのに必要な状態データを有する特定のステートフルなウエブ・サービス・インスタンスをホストする適切なサーバに送られていることを検証する方法を提供し、前記方法は、ウエブ・サービス・インスタンスによって処理する要求を受け取るステップと、その要求から、要求される状態データおよび状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する識別データを抽出するステップと、ターゲット・サーバのアイデンティティがクライアントの要求を受け取ったサーバのものと一致するかどうかを判別するステップと、否定の判別結果に応答して、ルーティング障害を報告するステップとを有する。

識別データはサーバのクラスタのＩＤを参照でき、その各々が要求される状態データにアクセス権を有する。識別データは要求される状態データがどこに配置されるかのトラックを維持する高可用性サービスを参照することができる。

一実施例において、要求が識別データをまったく含まないとの判別に応答して、要求はウエブ・サービス・インスタンスに回される。

一実施例において、特定のサーバまたはクラスタにステートフルなウエブ・サービス・インスタンスへの参照を作る要求を受け取る。こうして、クライアントの要求に応答して識別子をカプセル化した参照が提供される。

一実施例において、ターゲット・サーバのアイデンティティがクライアントの要求を受け取ったサーバのものとは一致しないと判別される場合、その要求は必要な状態データをホストするサーバに送りなおされる。ただし他の選択肢も可能で、例えば要求するクライアントにエラー・メッセージを返してもよい。

実施例において、要求が正しく送られたことが検証されたが、必要な状態データが要求を受け取ったサーバに存在しないと判別されたら、状態データが実際にはシステム内に存在しないことを認識することが可能である。さらに、特定用途に合わせてこれに対応することが可能である。このことは、例えば、ステートフルなウエブ・サービス・インスタンスが存在しないという標示をクライアントに提供することを意味するであろう。

別の側面によると、本発明はクライアントの要求が複数のステートフルなウエブ・サービス・インスタンスを有するシステム内の、クライアントの要求を処理するのに必要な状態データを有する特定のステートフルなウエブ・サービス・インスタンスをホストする適切なサーバに送られたことを検証する装置を提供し、前記装置は、ウエブ・サービス・インスタンスによって処理する要求を受け取る手段と、要求から、要求される状態データおよびその状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する識別データを抽出する手段と、ターゲット・サーバのアイデンティティがクライアントの要求を受け取ったサーバのものと一致するかどうかを判別する手段と、否定の判別結果に応答して、ルーティング障害を報告する手段とを有する。

別の側面によると、本発明はクライアントの要求が複数のステートフルなウエブ・サービス・インスタンスを有するシステム内の、クライアントの要求を処理するのに必要な状態データを有する特定のステートフルなウエブ・サービス・インスタンスをホストする適切なサーバに送られていることを検証するコンピュータ・プログラムを提供し、前記コンピュータ・プログラムは、前記プログラムをコンピュータで実行する場合に次の方法ステップを実行するようになされたプログラム・コード手段を有する。すなわち、ウエブ・サービス・インスタンスによって処理する要求を受け取るステップと、要求から、要求される状態データおよびその状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する識別データを抽出するステップと、ターゲット・サーバのアイデンティティがクライアントの要求を受け取ったサーバのものと一致するかどうかを判別するステップと、否定の判別結果に応答して、ルーティング障害を報告するステップ。

ここで、本発明の好適な実施例を、単に例として図面を参照しながら説明する。

アドレス指定（ａｄｄｒｅｓｓｉｎｇ）コンポーネントが、ウエブ・サービス要求が正しいターゲット・サーバに到着したことを検証し、誤って送られた要求を、もはや存在しないウエブ・サービス・インスタンスに向けられる要求とは区別して処理できるソリューションを説明する。

図１は、本発明がある好適な実施例に従い動作する環境を図示する。複数のサーバ１０、３０、５０（ファイヤウォール９５内に置いてもよい）は各々、同じウエブ・サービス（例、銀行用アプリケーション）のインスタンス２５、４０、６０をホストする。例えば、ビジー状態のシステムの作業負荷を分散するために、マルチサーバを使用してもよい。ステートフルなウエブ・サービスでは、各ウエブ・サービス・インスタンスはいくつかの状態データ２０、３５、５５にアクセス権を有し、当該状態データを各インスタンスがクライアント・アプリケーション９０からの要求を処理するために使う。クライアント・アプリケーション９０の要求はひとつまたは複数の中間ルーティング・サーバ７０、８０を介してサーバ・クラスタ５に到着する。各要求は同じ中間ルーティング・サーバを経由して進めない。当該サーバは、各ウエブ・サービス・インスタンスが受けている現在の作業負荷に基づいて、要求をウエブ・サービス・インスタンスに送る作業負荷ルーティング・コンポーネントを含んでもよい。クライアントがステートフルなウエブ・サービス・インスタンスの参照を有してしまえば、そのステートフルなインスタンスに関連する状態データがクラスタ内のすべてのサーバで複製されない場合、作業負荷のバランシングが制約を受けて、その後の要求をステートフルなウエブ・サービス・インスタンスをホストする同じサーバに送ることがある。作業負荷の均等な分散を維持するために、作業負荷管理システムがステートフルなウエブ・サービス・インスタンスをあるサーバから別のサーバに「移動」する必要がある場合もある。どうしてもある程度の待ち時間が生じる分散環境においては、作業負荷ルーターはステートフルなウエブ・サービス・インスタンスの実際の場所とはずれてしまうことがある。その結果、クライアント・アプリケーションの最初の要求はサーバ１０に送られて、そこでステートフルなウエブ・サービス・インスタンスを作るが、ウエブ・サービス・インスタンスはその後サーバ３０に移動することがある。このことは、クライアントからのその後の要求が、状態データがサーバ間で複製されない場合には状態データがもはや存在しないサーバ１０に向けられたままになれば問題になることは明らかであろう。その後の要求をサーバ１０で受け取る場合、ターゲットウエブ・サービス・インスタンスはそのサーバに存在しない、すなわち、ターゲットウエブ・サービス・インスタンスに関連する状態データはサービス１０には存在しない。ウエブ・サービス・インスタンスが存在しないことを示すクライアントへの応答は不正確となり、クライアントの誤った行動を招くであろう。

ウエブ・サービス・インスタンスが、その寿命の間ずっと単一のサーバに残るが、ルーティング・サーバがステートフルなウエブ・サービス・インスタンスをホストするサーバを好んでその作業負荷分散をさせない場合（図１に示す）にも、同じ問題が生じるであろう。

一般に、この問題は、ルーティング・コンポーネントがあるステートフルなウエブ・サービス・インスタンス向けの要求を間違ったサーバに向けると起こりうる。

前述した問題のソリューションを図２、図３、図４、および図５を参照して説明する。図２および図３は好適な実施例の構成要素を示し、図４および図５は好適な実施例に従う本発明の処理を示す。これらの図は互いに関連付けて解釈するべきである。

図２および図４をまず参照して、これらの図は正しいサーバ（これは必要なステートフルなウエブ・サービスを有しているはずである）が要求を受け取ったことを確認するクライアントのウエブ・サービス要求の検証を扱うものである。クライアント・アプリケーション９０がウエブ・サービスを要求する。クライアント・アプリケーションの要求は中間ルーティング・サーバ（図示せず）によってサーバ３０に、その結果ウエブ・サービス・インスタンス４０に送られる。ステップ３００でウエブ・サービス・エンジン４５が要求を受け取る。ウエブ・サービス・エンジン４５は当該要求を必ずアドレス指定コンポーネント１００に渡すのが好ましい。ステップ３１０で、アドレス指定コンポーネント内のインスペクタ・コンポーネント２１０が、クライアント・アプリケーションの要求がアドレス・データを含むかどうかを判別する。アドレス・データを使って、その後正しいサーバがターゲットとされたことを確認して、そのサーバ上のそのウエブ・サービス・インスタンスを選択する。

初めてクライアント・アプリケーション９０から要求を受け取る場合には、アドレス・データは一切含まれない。アドレス指定コンポーネント（リターナ２５０）がウエブ・サービス・エンジン４５に対して要求をウエブ・サービス４０に渡すよう指示する（ステップ３６０）。ウエブ・サービスは、同じウエブ・サービス・インスタンスへのクライアントの今後の要求で使用するためのアドレス・データを要求することを適切だとみなすことができる。アドレス・データの作成については図３および図５を参照して後で論じる。

ステップ３１０でインスペクタ・コンポーネント２１０が、要求がアドレス・データを含んでいると判別する場合、ステップ３２０でエクストラクタ・コンポーネント２２０が要求からアドレス・データを抽出し、さらにアドレス・データ内の識別データを使って、要求が正しいターゲット・サーバに送られたかどうかをステップ３３０で検証し、もし正しいターゲット・サーバに送られていれば、ターゲット・サーバのウエブ・サービス・インスタンスが要求を処理する（バリデータ２３０）。

当該識別データは、ターゲット・サーバのアイデンティティと、クライアントからの過去の関連のある要求の対象であったウエブ・サービス・インスタンスに関連する状態データ（情報）を一意的に識別する。当該状態データは当該過去の要求の結果として蓄積されていく。この識別子がとる形は、部分的にウエブ・サービスの種類に依存する。

ｉ）ウエブ・サービスは「脆弱」として知られるものであることがある。この場合、クライアントの最初の要求が送られたウエブ・サービス・インスタンスを保持する特定のサーバに存在する状態データの使用のみしか許容できない。そのため、識別データはサーバのＩＤを含むことが好ましい。

ｉｉ）ある場合には、状態データはクラスタのサーバ間で共有し、そのため関連クラスタ内のどのウエブ・サービス・インスタンスも同じ状態データにアクセス権を有する。その結果、識別データはクラスタのＩＤを含むことが好ましい。

ｉｉｉ）ウエブ・サービスは「高可用性」（ＨＡ）ウエブ・サービスとして分類されることがある。すなわち、ウエブ・サービス・インスタンスおよびそれに関連する状態データがどのサーバに存在するかのトラックを維持するＨＡサービスによって管理されるということである。サーバが障害を起こすと、ＨＡサービスはウエブ・サービス・インスタンスおよびその状態データを別のサーバに移して、その追跡データベースを更新する。ＨＡウエブ・サービスの場合、識別データは、ＨＡサービスが認識して、識別データを含む要求を受け取るサーバがＨＡのＩＤに対応したものであるかどうかを判別するのに使う形態のＩＤを含むことが好ましい。

ウエブ・サービス自体は、当該識別情報を含むアドレス・データを作るよう要求したときには、どのカテゴリーに分類するかをアドレス指定コンポーネントに知らせていることが好ましい（後述を参照）。

上記あげた例は単なる例示的なものであり、本発明の制限を意図しているわけではないことに留意する。

バリデータ・コンポーネント２３０は識別データがクラスタのＩＤを含むことを判別できる。このクラスタＩＤはさらにサーバ３０があるクラスタのクラスタＩＤと比較される。この２つが一致する場合、要求は正しく送られたと判別される。同様に、バリデータ・コンポーネント２３０は識別データがＨＡのＩＤと関連することを判別でき、その場合ＨＡのＩＤを使って関連するＨＡサービスは要求が正しく送られたかどうかを問われる。

さらにステップ３４０のテストは真または偽のいずれかに等しいと定義する。要求が正しく送られている場合、リターナ・コンポーネント２５０によってウエブ・サービス・エンジン４５に要求を処理するためにウエブ・サービス・インスタンスに渡すように回される（ステップ３６０）。正しく送られていない場合には、是正措置がとられる（ステップ３５０）。すなわち、アドレス指定コンポーネント１００からウエブ・サービス・エンジン４５を介してクライアント・アプリケーション９０にエラー・メッセージを返すか、またはアドレス指定コンポーネント１００がそれを引き受けて要求の経路を変更できるであろう。別の実施例では、アドレス指定コンポーネント１００からエラー・メッセージが返されるが、クライアント・アプリケーション９０はこれを受け取らない。代わりに、中間ノードがそれを引き受けて、要求の経路を変更してもよい。ただし、これは単なる例で、すべてを網羅しているわけではない。

以上述べたしたように、クライアントの要求はアドレス・データを一切含まないことがある。このためウエブ・サービス・インスタンスが当該アドレス・データの作成を要求してもよい。図３および図５はプロセスのこの部分に関する。

ウエブ・サービス・インスタンスは、アドレス指定コンポーネント１００でアドレス・データを作成するよう要求する。ステップ４００で、アドレスを要求するために、要求が受け取られて、アドレス・ファクトリー１２０に回される（ステップ４１０）。アドレス・ファクトリー１２０はウエブ・サービス・インスタンスをアドレス指定するためのアドレス・データを作成する（ステップ４２０）。さらにアドレス・ファクトリー１２０はアイデンティティ・ファクトリー１３０から、クライアントがめざすサーバを一意的に識別する識別データを要求する（ステップ４３０）。それからステップ４４０で、アドレス・ファクトリー１２０はアイデンティティ・ファクトリーから返された識別データをアドレス・データに挿入する。

次にステップ４５０でリターナ２５０からウエブ・サービスにアドレス・データが返される。さらにアドレス・データはアプリケーション９０に返される（ステップ３５５）。

今度クライアント・アプリケーション９０からウエブ・サービス４０が要求を受け取ると、ステップ３１０でインスペクタ・コンポーネント２１０が、要求がアドレス・データを含んでいることを判別して、当該アドレス・データ内の識別データを使って、要求が正しく送られたことを検証できる（図４）。

まとめると、本発明は、ウエブ・サービス要求がステートフルなウエブ・サービス・インスタンスをホストする正しいターゲット・サーバに送られたことを検証するメカニズムを提供する。このメカニズムにより、１）受け取る要求がステートフルなウエブ・サービス・インスタンスをホストしてないサーバに間違って送られた場合、および２）受け取る要求が適切なサーバに正しく送られたが、ステートフルなウエブ・サービス・インスタンスがもはや存在しない場合、の２つの場合の区別が可能である。

このソリューションは、アドレスの属性がそのアドレスに出される要求に含まれ、ターゲットで利用できるあらゆるアドレス指定システムに適用できる。ＷＳアドレス指定はその一例である。

ＷＳアドレス指定はウエブ・サービスのアドレスとしてエンドポイント・リファレンス（ＥＰＲ）を指定する。これは１つの必須アドレスＵＲＩとゼロもしくはそれ以上の参照パラメータからなる。エンドポイント・リファレンスをめざしたウエブ・サービス要求が出される場合、要求（ＳＯＡＰヘッダー）内でエンドポイント・リファレンスの参照パラメータが利用できる。これは例えばＳＯＡＰ／ＨＴＴＰまたはＳＯＡＰ／ＪＭＳなど使用されるトランスポートとは独立している。ＷＳアドレス指定がエンドポイント・リファレンスを作成する場合、システム内のトポロジー上のエンティティ、この場合識別データを表すよく知られた参照パラメータがＷＳアドレス指定のコンポーネントによって追加されることになる。このアイデンティティのタイプは、エンドポイント・リファレンスのタイプ、例えば脆弱性、作業負荷管理可能性または高可用性によって決定する。これらの場合の各々のアイデンティティはそれぞれ、特定の物理サーバへの不変の１対１のマッピング、サーバの論理グループへのマッピング、またはある物理サーバから別の物理サーバに再配置できる仮想の単一エンティティへの１対１のマッピングを表す。

ターゲット・システムが外部から入ってくるウエブ・サービス要求を受け取る場合、ターゲット・システムのＷＳアドレス指定のコンポーネントが要求のＳＯＡＰヘッダーのよく知られる参照パラメータ（ここでは識別データとして使われている）を検査し、その値を抽出する。それで、要求内の識別データがターゲットと矛盾がないかを検証する。

本発明を好適な実施例に従い動作する環境を図示する。好適な実施例に従う本発明の構成要素を示す。好適な実施例に従う本発明の構成要素を示す。好適な実施例に従う本発明の処理を図示する。好適な実施例に従う本発明の処理を図示する。

Claims

クライアントの要求が、複数の状態を保持するウエブ・サービス・インスタンスを有するシステム内の、クライアントの要求の処理に必要な状態データを有する特定の状態を保持するウエブ・サービス・インスタンスをホストする適切なサーバに送られたことを検証する方法であって、
ウエブ・サービス・インスタンスによって処理する要求を受け取るステップと、
前記要求から、要求される状態データおよび前記状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する識別データを抽出するステップと、
前記ターゲット・サーバのアイデンティティが前記クライアントの要求を受け取ったサーバのものと一致するかどうかを判別するステップと、
否定の判別結果に応答して、ルーティング障害を報告するステップとを有する方法。
前記識別データがサーバのクラスタのＩＤを参照し、その各々が前記要求される状態データにアクセス権を有する、請求項１の方法。
前記識別データが、前記要求される状態データがどこに位置するかのトラックを維持する高可用性サービスを参照する、請求項１の方法。
前記要求が識別データを含まないという判別に応答して、前記要求を前記ウエブ・サービス・インスタンスに回すステップを有する請求項１から３のいずれかの方法。
特定のサーバまたはクラスタに状態を保持するウエブ・サービス・インスタンスへの参照を作成する要求を受け取るステップと、
クライアントの要求に応答して前記識別子をカプセル化する前記参照を提供するステップとを有する請求項１から４のいずれかの方法。
否定の判別結果に応答して、前記要求を前記要求される状態データをホストするサーバに送りなおすステップを有する、請求項１から５のいずれかの方法。
要求が正しく送られていることを検証するステップと、
前記要求される状態データが前記要求を受け取ったサーバに存在しないことの判別に応答して、前記要求される状態データがシステム内に存在しないことを認識するステップとを有する、請求項１から６のいずれかの方法。
前記要求するクライアントに前記状態を保持するウエブ・サービス・インスタンスが存在しないという標示を提供するステップを有する、請求項７の方法。
クライアントの要求が、複数の状態を保持するウエブ・サービス・インスタンスを有するシステム内の、クライアントの要求の処理に必要な状態データを有する特定の状態を保持するウエブ・サービス・インスタンスをホストする適切なサーバに送られていることを検証する装置であって、
ウエブ・サービス・インスタンスによって処理する要求を受け取る手段と、
前記要求から、前記必要な状態データおよび前記状態データをホストするターゲット・サーバのアイデンティティを一意的に識別する識別データを抽出する手段と、
前記ターゲット・サーバのアイデンティティが前記クライアントの要求を受け取ったサーバのものと一致するかどうかを判別する手段と、
否定の判別結果に応答して、ルーティング障害を報告する手段とを有する装置。
前記識別データがサーバのクラスタのＩＤを参照し、その各々が前記必要な状態データにアクセス権を有する、請求項９の装置。
前記識別データが前記必要な状態データがどこに位置するかのトラックを維持する高可用性サービスを参照する、請求項９の装置。
前記要求が識別データを含まないという判別に応答して、前記要求を前記ウエブ・サービス・インスタンスに回す手段を有する、請求項９から１１のいずれかの装置。
特定のサーバまたはクラスタに状態を保持するウエブ・サービス・インスタンスへの参照を作成する要求を受け取る手段と、
前記クライアントの要求に応答して前記識別子をカプセル化する前記参照を提供する手段とを有する、請求項９から１２のいずれかの装置。
否定の判別結果に応答して、前記要求を前記必要な状態データをホストするサーバに送りなおす手段を有する、請求項９から１３のいずれかの請求項の装置。
要求が正しく送られたことを検証したが、前記必要な状態データが前記要求を受け取ったサーバに存在しないという判別に応答して、前記必要な状態データが前記システム内に存在しないことを認識する手段を有する、請求項９から１４のいずれかの装置。
前記要求するクライアントに、前記状態を保持するウエブ・サービス・インスタンスが存在しないという標示を提供する手段を有する、請求項１５の装置。
プログラムをコンポーネントで実行したときに、請求項１から９のいずれかの方法を実行するようになされたプログラム・コードを有するコンピュータ・プログラム。