(57)【要約】【課題】インターネット等のデータ伝送ネットワークにおいてウェブ・サービスを求める要求をリダイレクトする方法を提供する。【解決の手段】この方法では、クライアントのホスト（１０）によりウェブ・サービス・プロバイダに転送された要求に応答して、これはＨＴＴＰ等のトランスポート・プロトコルでシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）等のメッセージ交換プロトコルに基づくウェブ・サービス定義言語（ＷＳＤＬ）ファイルを提供する。この方法は、第１要求を該クライアントから前記ウェブ・サービスの旧アドレス（１２）に転送するステップと、該旧アドレスに関連付けられている該ウェブ・サービス・ポイントから該クライアントに応答して、前記メッセージ交換プロトコルを用いるヘッダが要求されたウェブ・サービス（１４）の新アドレス・リダイレクションを含むようになっているメッセージを送り戻すステップと、第２要求を該クライアントから該ウェブ・サービスの新アドレスに転送するステップとを含む。【選択図】図１
2007514223.tif 000002
【特許請求の範囲】
【請求項１】
インターネット等のデータ伝送ネットワークにおいてウェブ・サービスを求める要求をリダイレクトする方法であって、ここで、クライアントのホスト（１０）によりウェブ・サービス・プロバイダ（２４）に転送された要求に応答して、これはＨＴＴＰ等のトランスポート・プロトコル上でシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）等のメッセージ交換プロトコルに基づくウェブ・サービス定義言語（ＷＳＤＬ）ファイルを提供し、前記方法は、
第１要求を前記クライアントから前記ウェブ・サービスの旧アドレス（１２）に転送するステップと、
前記旧アドレスに関連付けられている前記ウェブ・サービス・ポイントから前記クライアントに応答して、要求されたウェブ・サービスの新アドレス・リダイレクション（１４）を前記メッセージ交換プロトコルを用いるヘッダにおいて含むメッセージを送り戻すステップと、
第２要求を前記クライアントから前記ウェブ・サービスの新アドレスに転送するステップと
を含むことを特徴とする方法。
【請求項２】
前記要求されたウェブ・サービスの前記新アドレス（リダイレクション） （１４）は、将来の要求を正しいアドレスに向けるために、前記クライアント・アプリケーションにおけるコード変更を許すように前記ホスト（１０）によりログされる、請求項１に記載の方法。
【請求項３】
前記メッセージ交換プロトコルはＳＯＡＰであり、前記リダイレクションは、前記クライアント及びサービス・プロバイダにより使用される全てのランタイムがそれを理解することを保証するためにＳＯＡＰ規格に含まれる、ＳＯＡＰヘッダ・タグ「リダイレクト（Ｒｅｄｉｒｅｃｔ）」である、請求項２に記載の方法。
【請求項４】
インターネット等のデータ伝送ネットワークにおいてウェブ・サービスを求める要求をリダイレクトするためのシステムであって、ここで、クライアントのホスト（１０）によってウェブ・サービス・プロバイダ（２４）に転送された要求に応答して、これはＨＴＴＰ等のトランスポート・プロトコル上でシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）に基づくウェブ・サービス定義言語（ＷＳＤＬ）ファイルを提供し、前記システムは、
前記クライアントのＳＯＡＰランタイムから前記サービス・プロバイダに転送された要求が新しいポイント・アドレスにリダイレクトされなければならないか否かチェックし、前記要求が転送されなければならない新しいポイント・アドレスであって、旧ポイント・アドレスに存する前記サービス・プロバイダから前記クライアントの前記ＳＯＡＰランタイムに転送されるＳＯＡＰ応答メッセージ内において提供される前記新しいポイント・アドレスを提供する、前記サービス・プロバイダ（２４）の前記ＳＯＡＰランタイムに存するチェッカー（３０）と、
前記ＳＯＡＰ応答メッセージが前記新ポイント・アドレスを含むか否かチェックし、同じ要求を作り直してそれを前記新ポイント・アドレス（１４）に転送する、前記クライアントの前記ＳＯＡＰランタイムに存するチェッカーと
を含むことを特徴とするシステム。
【請求項５】
前記システムは旧式化したウェブ・サービスのリスト（３２）を更に含み、前記サービス・プロバイダの前記ＳＯＡＰランタイム（２８）に存する前記チェッカー（３０）は前記要求が新ポイント・アドレスへリダイレクトされなければならないか否かチェックするために前記リストへのアクセスを有する、請求項４に記載のシステム。
【請求項６】
前記新ポイント・アドレスは前記ＳＯＡＰ応答メッセージのヘッダにおいて提供される、請求項４又は５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット・ネットワークのクライアントに提供されるウェブ・サービスに関し、特にクライアント要求を、そのアドレスが変更されているときにウェブ・サービスにリダイレクトする方法に関する。
【背景技術】
【０００２】
インターネット・ネットワーク上のますます多くのサービスへのアクセスを持つことができるようになってきていることは広く知られている。そこで、インターネット・ユーザはインターネット上のオンライン・サービスと、それらのサービスを要求する方法とに関する情報を得ることに関心を持つ。オンライン・サービスは一般にアプリケーション・サービス・プロバイダにより提供されるが、生命科学に関する要求のようにドメイン指向のサービスもある。
【０００３】
今日、クライアントは、クライアント、会社又はプログラムにサービス使用方法を提供する目的で、普通はインターネット接続を通して会社が明らかにした特定のビジネス機能である“ウェブ・サービス”を用いることによって、必要とされる情報を得ることができる。ウェブ・サービスは、エレクトロニック・コマースや、アプリケーション・サービス・プロバイダとのやり取りのためのバックボーンになってきている。
【０００４】
インターネット・ネットワーク上で公開のウェブ・サービスを提供するサービス・プロバイダは、そのウェブ・サービスに関する情報の全体を記述しなければならない。そのために、それは、そのウェブ・サービスに関連付けられたウェブ・サービス定義言語（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ））ファイルを提供することができる。ＷＳＤＬは、インターフェース（方法、パラメーター、・・・）と、サービスのランタイム（バインディング、アドレス、・・・）とを記述するのに有益である。クライアントの観点からは、ＷＳＤＬファイルはクライアント構造を構築するために必要な全ての情報を含んでいる。通常、クライアントは、実行時にではなくて構築時にのみＷＳＤＬファイルを使用する。
【０００５】
普通の製造モデルでは、新しい機能要件又はランタイム要件のためにＷＳＤＬが進化することは確実である。サービス・プロバイダがウェブ・サービス及び関連するＷＳＤＬファイルを更新したいときの主な難点は、全てのウェブ・サービス・クライアントへの通知である。実際、公開ウェブ・サービスの場合、サービス・プロバイダはウェブ・サービス・クライアントを知らないので、彼らに変更について通知することができない。
【０００６】
ウェブ・サービスのインターフェースにおける変更に関する慣行が幾つか設けられている。すなわち、インターフェースにおける変更は常に前のバージョンと両立するべきである。例えば、ＷＳＤＬファイルにおいて新しい方法は許容されるけれども、これらの方法の除去は禁じられる。
【０００７】
しかし、その公開ウェブ・サービスのうちの１つのエンド・ポイント・アドレスが変わるときにサービス・プロバイダが全てのウェブ・サービス・クライアントに通知する方法は無い。なぜならば、サービス・プロバイダは、リバース・プロキシ或いはウェブ・サービス・ゲートウェイを使わずにウェブ・サービスを第１のホストから他のより強力なホストに移すことを希望し、或いは、ウェブ・サービスの前にロード・バランシング・ソリューションを付け加えることを希望し、或いはウェブ・サービス・ゲートウェイ、１つの安全なプロキシをその前に付け加えることを希望し、或いはドメイン名を変更しなければならないからである。
【０００８】
３ｘｘＨＴＴＰステータス・コードを用いるトランスポート・プロトコルとしてＨＴＴＰプロトコルのための既存のソリューションが既に存在する。３ｘｘＨＴＴＰ応答コードを受け取ったクライアント・ブラウザは、要求されている文書の記憶場所が変わったことを知り、ブラウザは、３ｘｘＨＴＴＰ応答コードにおいて示されている記憶場所への新しいＨＴＴＰ要求を自動的に作る。しかし、このソリューションは、メッセージ交換プロトコルとしてシングル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を用いるウェブ・サービスのためには２つの理由から使用され得ない。第１に、コード３ｘｘは、ＳＯＡＰとＨＴＴＰとの間のバインディングを提供するランタイムによって自動的に処理されない。第２に、ＳＯＡＰメッセージのための通信プロトコルはＨＴＴＰだけではない。なぜならば、ＳＯＡＰメッセージはＳＭＴＰ、ＪＭＳ、・・・のような他のトランスポート・プロトコルでも送られ、またリダイレクション用の３ｘｘＨＴＴＰステータス・コードはこれらのプロトコル上で使用され得ないからである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従って、本発明の目的は、ランタイム変更の場合にウェブ・サービスのクライアントを新しいエンド・ポイント・アドレスにリダイレクトする方法を達成することである。
【課題を解決するための手段】
【００１０】
従って、本発明は、インターネット等のデータ伝送ネットワークにおいてウェブ・サービスを求める要求をリダイレクトする方法に関する。ここで、クライアントのホストによりウェブ・サービス・プロバイダに転送された要求に応答して、これはＨＴＴＰ等のトランスポート・プロトコル上でシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）等のメッセージ交換プロトコルに基づくウェブ・サービス定義言語（ＷＳＤＬ）ファイルを提供する。この方法は、第１要求をクライアントからウェブ・サービスの旧アドレスに転送するステップと、旧アドレスに関連付けられているウェブ・サービス・ポイントからクライアントに応答して、要求されたウェブ・サービスの新しいアドレス・リダイレクションをメッセージ交換プロトコルを用いるヘッダにおいて含むメッセージを送り戻すステップと、第２要求をクライアントからウェブ・サービスの新しいアドレスに転送するステップとを含む。
【００１１】
他の側面では、本発明は１つのシステムに関する。そのシステムは、クライアントのＳＯＡＰランタイムからサービス・プロバイダに転送された要求が新しいポイント・アドレスにリダイレクトされなければならないか否かチェックし、またその要求が転送されなければならない新しいポイント・アドレスを提供する、サービス・プロバイダのＳＯＡＰランタイムに存するチェッカーを含む。この新しいポイント・アドレスは、旧ポイント・アドレスに存するサービス・プロバイダからクライアントのＳＯＡＰランタイムに転送されるＳＯＡＰ応答メッセージにおいて提供される。  またシステムは、ＳＯＡＰ応答メッセージが新しいポイント・アドレスを含むか否かチェックして、同じ要求を作り直してそれを新しいポイント・アドレスに転送するクライアントのＳＯＡＰランタイムに存するチェッカーを含む。
【００１２】
本発明の上記の及びその他の目的、特徴及び利点は、添付図面と関連させて本発明についての以下のより具体的な記述を読むことにより、より良く理解されるであろう。
【発明を実施するための最良の形態】
【００１３】
図１に関して、メッセージ交換プロトコルＳＯＡＰに基づくウェブ・サービス・クライアント１０がサービス・プロバイダにより提供されるウェブ・サービスへのアクセスを持つことを希望するということが仮定される。この様な場合、第１の要求はホスト１０から旧アドレス・ポイント１２である現在のウェブ・サービス・アドレスに転送される。なぜならば、ユーザはウェブ・サービスのアドレスが変更されていることを知らないからである。旧ポイント・アドレス１２は、後述されるように応答メッセージのヘッダにリダイレクションを与えることによってホスト１０に応答する。旧ポイント・アドレスから受信されたＳＯＡＰメッセージに含まれるリダイレクションを用いて、ホスト１０は、この要求への応答を得るために第２の要求を新しいウェブ・サービス・アドレス１４に送ることができる。ホストは、新しいポイント・アドレスに対して更なるＳＯＡＰ要求を直接行うためにリダイレクションをログするようにプログラミングされ得ることに注意しなければならない。
【００１４】
本発明の方法の実施態様が図２に示されている。ウェブ・サービス・クライアント・ステーション１０は、通常、２つの機能を含む。クライアント・アプリケーション１８とＳＯＡＰランタイムである。ＳＯＡＰランタイムは、受信されたＳＯＡＰメッセージがそのヘッダ中にリダイレクションを含むか否かチェックする役割を果たすコンポーネントであるチェッカー２２を含む。  もしリダイレクションを含むならば、チェッカー２２は、上述したようにヘッダに与えられている新しいポイント・アドレスへの同じＳＯＡＰ要求を作り直す。チェッカー２２はまた、随意的に、将来の要求を正しいアドレスに向けるためにクライアント・アプリケーションにおけるコード変更を許すようにリダイレクションをログする。チェッカー２２は、一般にランタイム内のルーチンであるが、クライアント・ランタイムがＳＯＡＰメッセージを受信するごとにクライアント・ランタイムによりアクセスされる独立のコンポーネントであってよいことに注意するべきである。
【００１５】
ウェブ・サービス・プロバイダ２４は、通常どおりの第１のＨＴＴＰ２６サーバと、クライアント・ランタイムのようなＳＯＡＰランタイム２８とを含む。ランタイム２８は、ウェブ・サービスＷＳ１、ＷＳ２及びＷＳ３等のウェブ・サービスへのアクセスを得るようになっている。クライアントに関して、サービス・プロバイダのＳＯＡＰランタイム２８は随意のチェッカー３０を有する。チェッカー３０は、ランタイム２８内のソフトウェア部分或いはＳＯＡＰ要求が受信されたときにアクセスされる独立のコンポーネントであり得る。ＨＴＴＰ以外の、ＳＭＴＰ等の他の任意のトランスポート・プロトコルを使用しうることに注意するべきである。後者の場合、サーバ２６はＳＭＴＰサーバでありえる。
【００１６】
クライアント１０からＳＯＡＰ要求が受信されるごとに、チェッカー３０は、要求されたウェブ・サービスのアドレスが正しいアドレスであるのか、それともそのウェブ・サービスが他のマシン或いはアドレスに移ったためにアドレスが旧アドレスになっているのかをチェックする。そのために、チェッカー３０は、どれが旧式化したウェブ・サービスであるか知っており、また要求されたサービスが旧式化している場合、新しいアドレスを知っているコンポーネント３２へのアクセスを有する。チェッカー３０は、クライアントに戻されるＳＯＡＰメッセージのヘッダに含ませるために新しいアドレスをランタイムに提供する。
【００１７】
新しいアドレスをＳＯＡＰメッセージのヘッダに含ませる方法は、ＳＯＡＰヘッダ・タグを作ることである。ここで、ＳＯＡＰヘッダ・タグは「リダイレクト（Ｒｅｄｉｒｅｃｔ）」という名前を持ち、クライアント及びサービス・プロバイダにより使用される全てのＳＯＡＰランタイムがそれを理解することを保証するためにＳＯＡＰ規格に含められる。にもかかわらず、そのＳＯＡＰヘッダ・タグをＳＯＡＰ規格に含めることは必須ではない。これらのランタイムを使ってクライアント及びサービス・プロバイダにより高いサービス品質を提供するのは、幾つかのランタイムによってのみサポートされるＳＯＡＰエクステンションであり得る。
【００１８】
ＳＯＡＰ応答メッセージ内のこの様なヘッダの例は下記のＸＭＬコードであり得る：
＜ｓｏａｐｅｎｖ：Ｈｅａｄｅｒ＞
＜ｓｏａｐｅｎｖ：Ｒｅｄｉｒｅｃｔ  ｓｏａｐｅｎｖ：ｍｕｓｔＵｎｄｅｒｓｔａｎｄ＝”１”＞
Ｈｔｔｐ：／／ｎｅｗｈｏｓｔ．ｄｏｍａｉｎ．ｃｏｍ／ｓｅｒｖｉｃｅｓ／ＰｕｂｌｉｃＷｅｂＳｅｒｖｉｃｅ＜／ｓｏａｐｅｎｖ：Ｒｅｄｉｒｅｃｔ＞
＜／ｓｏａｐｅｎｖ：Ｈｅａｄｅｒ＞
【００１９】
ウェブ・サービスを提供するサーバＳＯＡＰランタイム・サーバの動作が図３に示されている。始めに、ＳＯＡＰランタイムはＳＯＡＰ要求を待つ（ステップ４０）。上述したように、ＳＯＡＰランタイムは、旧式化したウェブ・サービスのリストを提供する一般的にＸＭＬで書かれた属性ファイルへのアクセスを有する。旧式化したウェブ・サービスの各々に新しいポイント・アドレスが関連付けられる。従って、ＳＯＡＰ要求を得た後に、チェッカーは、このリスト中の旧式化したウェブ・サービスを検索し（ステップ４２）、クライアントから要求されたウェブ・サービスが旧式化したウェブ・サービスであるか否かチェックする（ステップ４４）。もしそのウェブ・サービスが旧式化したウェブ・サービスのこのリストに載っていれば、ＳＯＡＰランタイムは、そのウェブ・サービスと連絡を取ろうと試みないで、リダイレクション・ヘッダを伴なうＳＯＡＰ応答を送り戻す（ステップ４６）。既述の様に、このヘッダは、属性ファイルにより提供される新しいポイント・アドレスを含む。ＳＯＡＰボディは、クライアントＳＯＡＰランタイムが同じＳＯＡＰ要求を新しいポイント・アドレスへ送り直せるように、クライアントから正に受信されたＳＯＡＰボディで満たされる。
【００２０】
もしウェブ・サービスが旧式化したウェブ・サービスのリストに載っていなければ、ＳＯＡＰランタイムは自分の通常の作業を続ける、すなわちＳＯＡＰ要求を適切なウェブ・サービスに転送する（ステップ４８）。いずれにせよ、プロセスは、ＳＯＡＰ要求を待つ出発ステップ（ステップ４０）に巡り戻る。
【００２１】
クライアントＳＯＡＰランタイムの動作が図４に示されている。始めに、ランタイムはＳＯＡＰ応答を待つ（ステップ５０）。次にランタイムのチェッカーは、この応答がリダイレクション・ヘッダを含むか否かチェックする（ステップ５２）。もし含んでいれば、ＳＯＡＰランタイムは、メッセージ・ヘッダに含まれている新しいポイント・アドレスへの新しいＳＯＡＰ要求を作り直す（ステップ５４）。ＳＯＡＰランタイムは、また、ＳＯＡＰ応答からＳＯＡＰボディを得て、それを新しいＳＯＡＰ要求に挿入する。随意に、ＳＯＡＰランタイムは、クライアント・コードにおける更なる変更を許すために、従ってリダイレクションを要求することを必要とせずに新しいアドレスへの直接アクセスを許すために、リダイレクションをログすることもできる（ステップ５６）。もしＳＯＡＰ応答メッセージ中にリダイレクション・ヘッダが無ければ、ＳＯＡＰランタイムは自分の通常の作業を続ける、すなわちＳＯＡＰ応答をクライアントへ転送する（ステップ５８）。いずれにせよ、プロセスは、ＳＯＡＰ応答を待つ出発ステップ（ステップ５０）に巡り戻る。
【００２２】
本発明の好ましい実施態様ではシングル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）が用いられているけれども、どんなトランスポート・プロトコルが使用されてもＳＯＡＰ以外の任意の他のメッセージ交換プロトコルを使えることに留意しなければならない。
【図面の簡単な説明】
【００２３】
【図１】本発明の方法を表す略図である。
【図２】本発明のシステムを表すブロック図である。
【図３】旧ウェブ・サービス・アドレスと関連付けられたＳＯＡＰランタイムにおいて実行される方法のステップを表すフローチャートである。
【図４】クライアントのＳＯＡＰランタイムにおいて実行される方法のステップを表すフローチャートである。
【図１】
2007514223.tif 000003
【図２】
2007514223.tif 000004
【図３】
2007514223.tif 000005
【図４】
2007514223.tif 000006
【国際調査報告】
2007514223.tif 000007
2007514223.tif 000008
2007514223.tif 000009