JP4223004B2 - ウエブ・サービス・アーキテクチャにおいてサービスをランク付けするための方法およびシステム - Google Patents

Description

本発明は、ウエブ・サービス・アーキテクチャにおいてサービスをランク付けするための方法およびシステムに関する。特に、本発明は、トップ・レベルの呼び出し元によってランク付けを指定するサービス・プロバイダ階層を有するウエブ・サービス・アーキテクチャに関する。

ウエブ・サービスは、２００１年５月のＩＢＭソフトウエア・グループによる文書「Web Services Conceptual Architecture（ＷＳＣＡ１．０）」に記載されている。ウエブ・サービスは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、拡張マークアップ言語（ＸＭＬ：Extensible markup Language）、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：Simple Object Access Protocol）、ウエブ・サービス記述言語（ＷＤＳＬ：Web Services Description Language）、およびユニバーサル・ディスクリプション、ディスカバリ・アンド・インテグレーション（ＵＤＤＩ：Universal Description, Discovery and Integration）等、既存および新生の規格で構築されたプログラム間通信モデルを提供する。

ウエブ・サービスは、標準化されたＸＭＬメッセージングを介してネットワーク・アクセス可能な機能集合を記述するインタフェースによって記述される。ウエブ・サービスは、サービス記述と呼ばれる、標準的で公式のＸＭＬ表記を用いて記述される。サービス記述は、メッセージ・フォーマット、転送プロトコル、およびロケーションを含む、サービスとインタラクトするために必要な全ての詳細を包含する。インタフェースは、サービスの実施の詳細を隠し、これが実施されるハードウエアまたはソフトウエア・プラットフォームから独立し、また、これが書かれるプログラミング言語からも独立した使用を可能とする。また、これは、呼び出し側のハードウエアおよびソフトウエア環境からも独立している。これによって、ウエブ・サービスに基づくアプリケーションは、緩く結合され、コンポーネント指向で、技術をまたいだ実施が可能となり、ネットワークを通じて公開し、位置付けし、呼び出すことができる。

ウエブ・サービスは、ネットワークにおいて実施される。ネットワークは、インターネット、イントラネット、または他のいずれかの形態のネットワーク等、公的にアクセス可能なネットワークとすることができる。インターネット利用可能なウエブ・サービスは、一般的に配置されたネットワーク・プロトコルを用いる。かかるプロトコルは、ＨＴＴＰまたはＳＭＴＰもしくはＦＴＰ等の他のインターネット・プロトコルであり得る。他のネットワーク（例えばイントラネット）は、ＭＱＳｅｒｉｅｓ、ＣＯＢＲＡ等の信頼性の高いメッセージング・コール・インフラストラクチャを用いることができる。

ここに記載する方法およびシステムは、ＵＤＤＩ／ＷＳＤＬプロトコルおよびＸＭＬ／ＳＯＡＰ構文の拡張に関し、ウエブ・サービス・アーキテクチャ内で現在利用可能でない機能を提供する。

www.uddi.orgを通じて入手可能な以下の文書を参照する。
UDDI 2.0 Data Structure Reference
UDDI 2.0 API Specification
UDDI 2.0 Operators Specification
Web Services Description Language (WSDL) 1.1
２００１年５月のＩＢＭソフトウエア・グループによる文書「Web Services Conceptual Architecture（ＷＳＣＡ１．０） UDDI 2.0 Data Structure Reference UDDI 2.0 API Specification UDDI 2.0 Operators Specification Web Services Description Language (WSDL) 1.1

ウエブ・サービスにおけるＵＤＤＩの目的は、ディレクトリまたはレジストリ・ルックアップに基づいて機能に対するオープンなアクセスを提供することである。これらのサービスは、ＷＳＤＬ部分によって記述され、ＸＭＬ／ＳＯＡＰ機能によって呼び出される。呼び出し元のサービスへの結合は、動的であり、固定されていない。これは、ディレクトリが自由に利用可能であり、どのようにルックアップまたは選択が行われるかが制約されないという点で、オープンである。ＵＤＤＩは、見事にこの目的を満足させる。しかしながら、これに欠けている点は、サービスの質のような概念である。

ここに記載する方法およびシステムは、サービスの質の問題および他の選択に影響を与えるファクタをＵＳＳＩ／ＷＳＤＬの領域に取り入れることができる手段を提供する。

ウエブ・サービスでは、ディレクトリまたはレジストリを用いて、ソフトウエアを、コンポーネント化するようにアセンブルする。ＵＤＤＩの考えは、ＷＳＤＬフォーマットの要求をディレクトリまたはレジストリ・サーバに送ってサービスを選択するというものである。このサービス選択は、これを提供している会社およびそれが実行する機能等、一般に適用可能なある規準で指定することができる。この選択情報は、極めて一般的なものである。これは、全てのユーザに対して同一であり、言及されるサービスに対する要求の発信側に固有のものは何もない。

ここに記載する方法およびシステムは、発信側に固有の基準をルックアップに反映させることができる手段を提供する。既知の従来技術のウエブ・サービスとは異なり、サービスの選択は、サービス選択の発信側または要求側によって左右される。

以下は、１つの実例である。ユーザのソフトウエアが、本を買おうとする。ユーザは、「本屋」のカテゴリのディレクトリを参照し、そのサービスを提供する会社のリストが返信される。しかしながら、ユーザは、例えば２つの供給業者と優先レートを取り決めており、そのため、この購入要求を、第１の場合はこれらの２つのいずれかに、第３の選択として別の誰かに送ることを望む。

ユーザは、検索から戻った会社のリストをフィルタリングすることによって、これを行うことができる。なぜなら、検索は直接ユーザに情報を戻し、ユーザが次に起こることを制御するからである。

本の購入要求が、他の誰かによって提供されているサービスの機能の一部として実行されている場合は、違いが生じる。例えば、ユーザがスタートレック本のライブラリを構築している場合があり得る。ユーザは、「ライブラリを構築」選択を用い、適切な販売業者のリストの返信を得る。ユーザは、スタートレックのライブラリ取得要求を、このジョブを実行する供給業者に課す。しかしながら、ユーザは、もはや、気に入っている本屋リストを用いる立場にはない、なぜなら、この時点で、本購入機能は誰か他の人によって処理されているからである。実際には、彼等がユーザの代わりに好みの供給業者を用いる。

ここに記載する本発明の１つの結果は、仲介者ではなくユーザの好む販売業者を用いて、本（または他のアイテム）を購入する方法を提供する。

ここに記載する方法およびシステムは、発信側のプリファレンス（優先的選択）に従ってどのようにＷＳＤＬ／ＵＤＤＩ要求にバイアスをかけるかに関する。ユーザのプリファレンスにどの条件が影響を与えるかは考察せず、ユーザに任される。ユーザのプリファレンスに影響を与え得る条件の例は、コスト、効率、速度、および信頼性の標準を含む。

本発明の第１の態様によれば、ルート発信サービス・リクエスタを有するサービス階層を有するウエブ・サービス・アーキテクチャにおいてサービスにランク付けするための方法であって、階層における第１のレベルのサービスがもっと低いレベルのサービスを呼び出す方法が提供される。この方法は、発信サービス・リクエスタが１つ以上のサービスに関するプリファレンスを示し、ランク付け機械がプリファレンスに基づいた選択アルゴリズムを有する、ステップと、発信サービス・リクエスタが、階層の１つ以上のレベルのサービスを呼び出すステップと、階層の各レベルにおいて、サービスがディレクトリを用いて１組の可能な低レベル・サービスを検出するステップと、ランク付け機械が、１組の可能な低レベル・サービスに選択アルゴリズムを適用するステップと、を有する。

低レベル・サービスは、サービス・リクエスタまたはサービス・プロバイダとすることができる。

１つの実施形態では、１組の可能な低レベル・サービスを、ディレクトリからランク付け機械に委託し、ランク付け機械によってディレクトリに好適なシーケンスを戻すことができる。ランク付け機械に委託されるステップは、ディレクトリを用いるサービスには見えないようにすることができる。

別の実施形態では、１組の可能な低レベル・サービスを、ディレクトリを用いるサービスによってランク付け機械に送信し、ランク付け機械によってサービスに好適なシーケンスを戻すことができる。

ディレクトリを用いるサービスに、単一の結果または結果のシーケンスを戻すことができる。

好ましくは、階層におけるサービスの低レベル呼び出しは、高レベル・サービスには見えない。

発信サービス・リクエスタのプリファレンスによって、発信サービス・リクエスタがサービスを利用したい順序にサービスをランク付けし、サービスを用いないよう除外し、もしくは他の選択に影響を与える規準を提供するか、またはそれら全てを行うことができる。

発信サービス・リクエスタのプリファレンスは、コスト、効率、速度、および信頼性を含むサービス基準品質に基づくことができる。

発信サービス・リクエスタのプリファレンスがある場合、プリファレンスは、ディレクトリを用いるサービスによる選択よりも優先される。好みのサービスが利用可能でない場合、発信サービス・リクエスタのプリファレンスを参照して以降のサービスを得ることができる。

発信サービス・リクエスタのプリファレンスが保存されていない場合、ディレクトリを用いるサービスが選択を行うことができる。

本発明の第２の態様によれば、ウエブ・サービス・アーキテクチャが提供される。これは、ルート発信サービス・リクエスタと、第１のレベルのサービスがもっと低いレベルのサービスを呼び出すサービス階層と、階層においてサービスを検出するためのディレクトリと、１つ以上のサービスに関する発信サービス・リクエスタのプリファレンスに基づいて、サービスのための選択アルゴリズムを適用するための手段を有するランク付け機械と、を有し、階層の各レベルにおいて、ディレクトリが１組の可能なサービスを提供し、ランク付け機械が選択アルゴリズムを適用して好適なサービスのシーケンスを提供する。

低レベル・サービスは、サービス・リクエスタまたはサービス・プロバイダとすることができる。

ランク付け機械は、好ましくは、ポートによってディレクトリに接続され、１組の可能なサービスが、ディレクトリによってランク付け機械に委託され、好適なサービスのシーケンスが、ランク付け機械によってディレクトリに戻される。

第１のレベルのサービスは、ＵＤＤＩディレクトリによって、もっと低いレベルのサービスを検出することができる。ランク付け機械は、ＵＤＤＩディレクトリ上にポートを有し、ＴＭｏｄｅｌバッグを１組の選択したＴＭｏｄｅｌに変換するフローを処理することができる。

各ＵＤＤＩ動作を、ランク付け機械に委託し、サービス・リクエスタのプリファレンスに一致するシーケンスとして戻すことができる。

基礎にあるＵＤＤＩアプリケーション・コードが参照を実行し、ランク付け機械の位置を以降のＸＭＬフローに追加することができる。

本発明の第３の態様によれば、ルート発信サービス・リクエスタを有するサービス階層を有するウエブ・サービス・アーキテクチャのためのコンピュータ読み取り可能保存媒体上に保存されたコンピュータ・プログラム・プロダクトが提供され、第１のレベルのサービスがもっと低いレベルのサービスを呼び出す。これは、発信サービス・リクエスタが１つ以上のサービスに関するプリファレンスを示し、ランク付け機械がプリファレンスに基づいた選択アルゴリズムを有する、ステップと、発信サービス・リクエスタが、階層の１つ以上のレベルのサービスを呼び出すステップと、階層の各レベルにおいて、サービスがディレクトリを用いて１組の可能な低レベル・サービスを検出するステップと、ランク付け機械が、１組の可能な低レベル・サービスに選択アルゴリズムを適用するステップと、を実行するためのコンピュータ読み取り可能プログラム・コード手段を有する。

これより、添付図面を参照して、本発明の実施形態を、例示としてのみ説明する。

この説明において、ウエブ・サービスという言葉を用いる。これは、ウエブを介して（例えばブラウザから）ウエブ・サービスを呼び出さなければならないことを意味するものと解釈すべきではない。ウエブ・サービスは、インターネット、イントラネット、ＬＡＮ、ＷＡＮ等を含むいかなる形態のネットワークにおいても実施することができる。先に定義したように、ウエブ・サービスは、プログラム間の通信モデルを提供し、ウエブ・サービスの機能を記述するインタフェースによって記述される。

図１は、サービス・プロバイダ１０１、サービス・レジストリ１０２、およびサービス・リクエスタ１０３の３つの役割を示すウエブ・サービス・モデル１００を示す。インタラクションには、公開１０４、検出１０５、および結合１０６の動作が伴う。結合動作１０６は、緩く結合された環境におけるエンティティ間のアクセス・フローである。同時に、これらの役割および動作は、ウエブ・サービス・ソフトウエア・モジュール１０７およびその記述１０８であるウエブ・サービス・アーチファクトに作用する。

典型的な状況では、サービス・プロバイダ１０１が、ウエブ・サービスを実施したものであるネットワーク・アクセス可能ソフトウエア・モジュール１０７をホストする。サービス・プロバイダ１０１は、ウエブ・サービス１０７のためのサービス記述１０８を定義し、これをサービス・レジストリ１０２に公開する。また、サービス・リクエスタ１０３は、サービス・プロバイダ１０１から直接、プッシュ動作ではなくプル動作として、サービス記述１０８またはその一部を取得することができる。サービス・リクエスタ１０３は、検出動作１０５を用いて、サービス・レジストリ１０２からサービス記述１０８を検索し、サービス記述１０８を用いてサービス・プロバイダ１０１と結合し（１０６）、ウエブ・サービス実施１０７を呼び出すか、またはこれとインタラクトする。サービス・プロバイダ１０１およびサービス・リクエスタ１０３は、役割であり、１つのサービスが双方の特徴を発揮することができる。

サービス・プロバイダ１０１は、少なくともサービスのフロンド・エンドに対するアクセスをホストするプラットフォームである。サービス・リクエスタ１０３は、サービスとのインタラクションを探し、呼び出すかまたは開始しているアプリケーションである。例えば別のウエブ・サービスのようなユーザ・インタフェースを用いずに、人またはプログラムによって駆動されるブラウザによって、サービス・リクエスタの役割を果たすことができる。サービス・レジストリ１０２は、サービス記述１０８の検索可能レジストリであり、サービス・プロバイダ１０１はサービス記述１０８をこれに公開する。サービス・リクエスタ１０３は、サービスを検出し、サービス記述１０８から結合情報を取得して、サービスのために通信および実行を確立する。

アクセス可能とするため、サービス記述１０８を公開して（１０４）、サービス・リクエスタ１０３がこれを検出できるようにする必要がある。検出動作１０５では、サービス・リクエスタ１０３は、直接サービス記述１０８を検索するか、または、サービス発見プロセスを用いて必要なサービス・タイプについてサービス・レジストリ１０２に問合せを行う。結合動作１０６では、サービス・リクエスタ１０３は、サービスに接触しこれを呼び出すため、サービス記述１０８における結合詳細を用いて実行時にサービスとのインタラクションを呼び出すかまたは開始する。

サービス記述１０８は、サービスを実施するためのインタフェースの詳細を含む。これには、そのデータ・タイプ、動作、結合情報、およびネットワーク・ロケーションが含まれる。また、これは、サービス・リクエスタ１０３による発見および利用を容易にするためのカテゴリ化も含むことができる。

図２を参照すると、公開、検出、および結合の３つの動作を相互利用可能な方法で実行するため、各レベルで規格を包含するウエブ・サービス・スタック２００がなければならない。

ウエブ・サービス・スタック２００の基礎は、ネットワーク・レベル２０１である。これは、ウエブ・サービスは、ネットワーク・アクセス可能であり、サービス・リクエスタによって呼び出されなければならないからである。スタック２００のネットワーク・レベル２０１に適用される標準的な技術には、ＨＴＴＰ、ＦＴＰ、ｅメール、ＭＱＳｅｒｉｅｓ、ＩＩＯＰ等が含まれる。

次のレベルは、ＸＭＬベースのメッセージング・レベル２０２であり、メッセージング・プロトコルのための基礎としてのＸＭＬのユーザを表す。ＸＭＬメッセージング・プロトコルを増強するものとして、ＳＯＡＰを用いることができる。

次のレベルは、記述文書の集合であるサービス記述レベル２０３である。記述は、３つのタイプのもの、すなわち、ロケーション、アクティビティ、およびインタフェースにグループ化される。ＷＳＤＬは、ＸＭＬベースのサービス記述のための標準である。ＷＳＤＬは、サービス・インタラクションのインタフェースおよび機構を定義する。ＷＳＤＬ文書は、他のサービス記述文書によって補足して、ウエブ・サービスのもっと高いレベルの態様を記述することができる。例えば、ビジネス・コンテクストは、ＷＳＤＬ文書に加えて、ＵＤＤＩデータ構造を用いて記述される。

ネットワーク・レベル２０１、ＸＭＬベースのメッセージング・レベル２０２、およびサービス記述レベル２０３という最初の３つのレベルは、いずれかのウエブ・サービスを提供または用いる必要がある。

図２に示すスタック２００の次の２つのレベルは、サービス公開およびサービス発見レベル２０４、２０５であり、多数のソリューションによって実施することができる。ＷＳＤＬ文書をサービス・リクエスタに利用可能とする全てのアクションが、サービス公開である。公的ＵＤＤＩレジストリは、サービス公開のコピーを保持する。

ウエブ・サービスは、これが公開されないならば発見することはできない。従って、サービス発見レベル２０５はサービス公開レベル２０４に依存する。発見機構の種類は、公開機構に対応する。サービス・リクエスタがサービス記述に対するアクセスを得ることを可能とし、それを実行時にアプリケーションに利用可能とする全ての機構が、サービス発見として適切である。

図２の最上レベル２０６は、サービス・フロー・レベル２０６であり、サービス間通信、協同、およびフローがどのように実行されるかを記述する。

完全なウエブ・サービス記述は、サービスの基本ＷＳＤＬ記述上に構築される。完全なウエブ・サービス記述は、以下をアドレシングする。すなわち、サービスをホストするビジネス、そのビジネスの種類、サービスに関連する製品、ビジネスまたはウエブ・サービスが関連するカテゴリ、サービス呼び出しの選択についてリクエスタに影響を与える態様、サービスを検出しやすくするように提供することができるキーワード等である。

ＵＤＤＩは、ウエブ・サービスの記述を保持するための機構を提供する。ＵＤＤＩは、ディレクトリ機構として考えられることが多いが、これは、ＸＭＬでサービス記述情報を表すためのデータ構造規格も定義する。図３は、４つの基本的なデータ構造を有するＵＤＤＩエントリ３００を示す。

ＵＤＤＩエントリは、ビジネス・エンティティ３０１で開始する。ビジネス・エンティティ３０１は、ビジネスに関する情報をモデル化する。ビジネス・エンティティ３０１は、ビジネスが公開を望む各ウエブ・サービスごとに１つずつ、ビジネス・サービス３０２の集合を含む。各ビジネス・サービス３０２は、ビジネス・エンティティのウエブ・サービスに関する技術的および記述的情報を含む。ビジネス・サービス３０２は、結合テンプレート３０３の集合を含む。

結合テンプレート３０３は、例えば終点アドレスのようなアクセス情報を記述し、どのようにビジネス・サービス３０２が様々な技術仕様を用いるかを記述する。技術仕様は、ｔＭｏｄｅｌ３０４としてモデル化される。ｔＭｏｄｅｌ３０４は、サービスのタイプ、ＨＴＴＰ等のプラットフォーム技術、または分類等、多くの異なる概念をモデル化することができる。ビジネス・エンティティ３０１、ビジネス・サービス３０２、および結合テンプレート３０３は、定義したタイプのｔＭｏｄｅｌを用いて実施される。１つのビジネス・サービス３０２に関連した結合テンプレート３０３の集合は、ビジネス・サービス３０２が用いる技術の明確な特徴を表す。

ｔＭｏｄｅｌ３０４は、発呼側インタフェースおよび結果を定義する。これは、高レベルではＸＭＬで、ユーザには見られない低レベルではＡＰＩによってレンダリングされる。ｔＭｏｄｅｌ３０４は、キーと称する一意の識別子を有する。ＵＤＤＩは、同一キーの指定によって２つ以上の場所における所与のｔＭｏｄｅｌ３０４の使用をサポートし、外見に関する限り、２つの場所での挙動が全く同一であり、プラットフォーム固有のリターン・コードは追加されないことを保証する。

ここに記載する方法およびシステムは、要求の発信側に対する全てのＵＤＤＩ動作に関する参照を含む。いったんディレクトリまたはレジストリが要求を処理すると、その結果は、フィルタリングのためにこの参照に委託される。

ここで図４を参照すると、ウエブ・サービス階層４００が示されている。３階層４００のルート・ノードは、ウエブ・サービスを呼び出したいと望むサービス・リクエスタ４０１である。

３階層４００は、中間サービスを表す多数のサービス・レベル４０２、４０３を有する。中間サービスは、サービス・リクエスタ４０１が呼び出したいと望むエンド・ウエブ・サービスを検出するため、サービス・リクエスタ４０１によって（直接的または間接的に）呼び出すことができる。エンド・ウエブ・サービス４０４は、３階層４００上のリーフ・ノードである。レベル４０２は、サービス・リクエスタ４０１によるサービスの選択とすることができ、レベル４０３および４０４は、サービス・リクエスタ４０１には見えない隠れたサブ・サービスの選択とすることができる。

ここで図５を参照すると、レベル４０２、４０３、４０４の各々における選択されたサービス４０６、４０８、４１０のみを示す。ディレクトリ４１１が設けられ、これは、サービスまたはサービス・プロバイダの形態の可能な結果のグループまたはバッグを検出するために用いられる。

ランク付け機械４０５が設けられ、これは、サービス・リクエスタ４１０のサービス選択のプリファレンスの詳細を保存する。これは、ランク付け機械４０５に対していずれかの適切な時間に提示されるオプション間の選択アルゴリズムの形態で設けられる。サービス・リクエスタ４０１は、ランク付け機械４０５に、そのサービス・プロバイダのプリファレンスを知らせ、サービス・プロバイダのプリファレンスをランク付けする選択アルゴリズムがセーブされる。

第１の実施形態では、ランク付け機械４０５は、ディレクトリ４１１上のポート４１２を聴取する。ディレクトリ４１１がルックアップを実行し結果のバッグを生成する時、ランク付け機械４０５は、ポート４１２を聴取しており、結果のバッグはランク付け機械４０５に送られる（４０７）。ランク付け機械４０５は、その選択アルゴリズムを結果のバッグに適用し、サービス・リクエスタ４０１の好みの順序で、結果シーケンスをディレクトリ４１１に戻す（４０９）。ディレクトリ４１１は、ランク付け機械４０５によって与えられた結果シーケンスによってルックアップに答える。

ディレクトリにおいてサービスを参照する全ての中間サービス・プロバイダ４０２、４０３は、ルックアップをランク付け機械４０５に委託し、ランク付け機械４０５は、サービス・リクエスタ４０１について示されたプリファレンスに従ってサーチ結果をフィルタリングする。ランク付け機械４０５にプリファレンスが保存されている場合、ランク付け機械４０５はそのプリファレンスに基づいて選択を行い、中間サービス・プロバイダ４０２、４０３は、次のレベルのサービス・プロバイダを呼び出す場合にプリファレンスに従う。

図４および５に示した例では、サービス・リクエスタ４０１は、もっと低いレベルのサービスの使用を伴う第１レベル４０２の中間サービス・プロバイダのサービスを用いることを望む。しかしながら、いずれかのもっと低いレベルのサービスを用いるという事実は、サービス・リクエスタ４０１には明らかにされない。サービス・リクエスタ４０１は、第１レベル４０２のサービス・プロバイダのためのディレクトリ４１１を用いて検索を実行し、可能なサービス・プロバイダ４０２のシーケンスを得る。可能なサービス・プロバイダ４０２のシーケンスは、ランク付け機械４０５によってフィルタリングされており、明らかな非競争者を除去するか、または特定の選択を強制する（すなわち１つのみの結果がバッグにある場合）。バッグに２つ以上の結果がある場合、サービス・リクエスタ４０１は、第１レベル４０２のサービス・プロバイダ４０６の１つを選択する。

ディレクトリ４１１によって与えられた各ルックアップ応答は、ランク付け機械４０５によってフィルタリングされた可能な候補のバッグを生成する。ディレクトリ４１１におけるソフトウエアは、ランク付け機械４０５に対する参照を行う。ディレクトリ４１１においてルックアップを要求したエンティティには、ランク付け機械４０５がそこに存在しないかに関する結果のリストが戻される。ルックアップを要求したエンティティは、ディレクトリ４１１によって戻された結果の自由選択を有するが、戻された結果は、ランク付け機械４０５によってすでに制限されている。

サービス・リクエスタ４０１は、第１レベル４０２のサービス・プロバイダ４０６とのみ通信を行う。しかしながら、その機能を実行するために、サービス・プロバイダ４０６は第２レベル４０３のサービス・プロバイダ４０８を用い、サービス・プロバイダ４０８はエンド・サービス４１０を用いる。サービス・リクエスタ４０１は、第２レベルのサービス・プロバイダ４０８またはエンド・サービス４１０について知らない。同様に、第１レベルのサービス・プロバイダ４０６は、第２レベルのサービス・プロバイダ４０８によって用いられるエンド・サービス４１０について知らない。

第１レベル４０２のサービス・プロバイダ４０６は、ディレクトリ４１１のルックアップを実行して第２レベル４０３のサービス・プロバイダ４０８を検出する。同様に、第２レベル４０３のサービス・プロバイダ４０８は、ディレクトリ４１１のルックアップを実行してエンド・サービス４１０を検出する。各ルックアップでは、ディレクトリ４１１が検出した結果のバッグは、発信側サービス・リクエスタ４０１のプリファレンスに従ってランク付け機械４０５によりランク付けされている。ランク付け機械４０５がその選択アルゴリズムで用いるプリファレンスは、階層内でグローバルであり、レベルに依存しない。

第２の実施形態では、ディレクトリは、ルックアップ要求の結果を、発信側サービス・リクエスタまたは中間サービス・プロバイダであり得るリクエスタに戻し、リクエスタは、結果のバグを、ランク付けのためにランク付け機械に送る。ランク付け機械は、結果のシーケンスをリクエスタに戻す。

双方の実施形態では、サービス・リクエスタのプリファレンスは、コスト、効率、速度、および信頼性等、サービスの質の問題に関連させるか、または、プリファレンスに影響を与える他のいずれかの選択に関連させることができる。プリファレンスによって、サービス・リクエスタがサービスを用いたい順序でサービスにランク付けしたり、具体的にあるサービスを使用から除外したり、または他のいずれかのプリファレンスの指示を与えることができる。

なぜプリファレンスを記録するかに関して、サービス・リクエスタには理由は必要でなく、プリファレンスは、中間サービス・プロバイダによって見たり、理解したりする必要はない。サブ・サービス選択の制御は、供給業者には与えられないか、または、元のサービス・リクエスタによって少なくとも影響を受ける。

実施例１
以下は、ユーザと称されるサービス・リクエスタによるウエブ・サービスの呼び出しの１例である。図６は、どのように従来技術のＵＤＤＩルックアップ要求が機能するかを示す。ＵＤＤＩディレクトリは、その結果としてバッグを戻し、これをここでは｛セット｝として示す。

ユーザ５０１は、ライブラリを構築したいと望むので、彼は、ＵＤＤＩディレクトリ５０２に、これを実行するサービス・プロバイダ５０３を検出するように頼む。ユーザ５０１は、ライブラリ・ビルダを検出するためのＵＤＤＩルックアップの要求５１１をディレクトリ５０２に送る。この場合、このカテゴリのサービス・プロバイダ５０３は１つのみなので、ディレクトリ５０２は、｛LibraryBuilder1｝のセットの結果を戻す（５１２）。

次いで、ユーザ５０１は、「ライブラリを構築」の要求５１３を、サーバLibraryBuilder1５０４に送る。次いで、LibraryBuilder1５０４は、ＵＤＤＩディレクトリ５０２において、本供給業者５０５のリストを参照する（５１４、５１５）。ディレクトリ５０２は、｛Seller1, UserPreferredSeller2｝のセットを戻す（５１６）。次いで、LibraryBuilder1５０４は、第１の供給業者を選ぶ（５１７）。これは、Seller1５０６であるか、または本を買うために用いる最も適切な供給業者と考えるものである。この結果、本はLibraryBuilder1に都合の良い場所から購入される（５１８）が、この場合はUserPreferredSeller2５０７であるユーザの好みの販売者ではない。

図７は、図６と同じであるが本発明の第１の実施形態に従ったＵＤＤＩルックアップを示す。ここに記載する方法およびシステムでは、戻されたバッグをユーザのプリファレンスに従った順序でランク付けすることができる場所に各ＵＤＤＩ要求を委託することが必要である。これは、このランク付けにおいてどの基準を用いるかには関連せず、それが実行されることにのみ関連する。

このため、｛bag｝は、＜sequence＞として戻され、リストの冒頭に好みのアイテムがある。シーケンスは、バグの全てのメンバ、サブセット、または完全に異なるものでさえ含むことができる。この参照を行うのは、基礎にあるＵＤＤＩルックアップ・コード（換言すれば基礎にあるＵＤＤＩ ＡＰＩ）である。余分なコード・ステップは、発呼側には必要でない。

図７は、ランク付け機械５０８の追加コンポーネントを有する。これは、本の供給業者５０９についてユーザ５０１が示すプリファレンスを反映する選択アルゴリズムを保持する。

ユーザは、ＵＤＤＩディレクトリ５０２に、ライブラリ・ビルダを検出するよう要求する（５２１）。ディレクトリ５０２は、｛LibraryBuilder1｝セットを検出する。しかしながら、これはユーザ５０１に知らされない。なぜなら、サービス・プロバイダの基礎にある層は、参照のないローカルな要求はランク付けする必要があることを知っており、これは構成オプションによって実行され、このためユーザには見えないからである。このため、ＵＤＤＩディレクトリ５０２からのリターン・フローは、次いで、分析のためにローカル・ランク付け機械５０８に委託される（５２２）。選択肢は１つだけで、許容可能な＜LibraryBuilder1＞である。このため、結果は不変であるので、ＵＤＤＩディレクトリ５０２に最初に戻され（５２３）、リターンをユーザ５０１に送り返す（５２４）。

次いで、ユーザ５０１は、第１の（この例では唯一の）供給業者５０４を選択し、ライブラリ構築動作を呼び出す（５２５）。基礎にある層は、これがサービスに対するＸＭＬ／ＳＯＡＰ要求であることを知っているので、必要なランク付け機械５０８の位置をＸＭＬフローに追加する。

次いで、供給業者すなわちLibraryBuilder1５０４は、ＵＤＤＩディレクトリ５０２が本販売者５０４のリストを検出することを要求し（５２６）、関連ランク付け機械５０８の位置をフローに追加する。このディレクトリ・ルックアップ５２７は、保持された本販売者のセット｛Seller1, UserPreferredSeller2｝を戻す。次いで、基礎にある層は、このセットを前のようにランク付け機械５０８に委託する（５２８）。この場合、ランク付け５０８は、ユーザの優先する本供給業者５０９の使用を強制したいので、ＵＤＤＩ結果をシーケンス＜UserPreferredSeller2＞に変更し、その後、結果をＵＤＤＩディレクトリ５０２に返送（５２９）し、そのルックアップ５２７の結果としてライブラリ・ビルダ５０４に結果を返送する（５３０）。この結果、本は、Selle1５０６でなくUserPreferredSeller2５０７から注文される（３２１、３２２）。

図８は、図６および７と同一であるが本発明の第２の実施形態に従ったＵＤＤＩルックアップを示す。図７と同様、ここに記載する方法およびシステムでは、各ＵＤＤＩ要求を、戻されたバッグをユーザのプリファレンスに従った順序でランク付けすることができる場所に委託する必要がある。これは、このランク付けにおいてどの基準を用いるかには関連せず、それが実行されることにのみ関連する。

この場合も、{bag}は、＜sequence＞として戻され、リストの冒頭に好みのアイテムがある。第２の実施形態では、ＵＤＤＩディレクトリ５０２に対するルックアップのリクエスタは、結果の｛bag｝を受信し、バッグをランキングのためランク付け機械５０８に委託し、次いで、リクエスタは、ユーザ５０１のプリファレンスに従ってランク付け機械５０８から＜sequence＞を受信する。

実施形態
第１の実施形態では、ランク付け機械は、ＵＤＤＩ／ランク付け機械ポートを聴取し、上述のフローを処理して、１つのtModelバッグを、選択したtModelのバッグに変える。

ＵＤＤＩ ＡＰＩに関して、１０のfind_xx動詞を、ランク付け機械のURL:portを追加することによって拡張する。

例えば、数式２は、数式３に変換される。

サービスのＳＯＡＰ／ＸＭＬ実行に関して、これは、ランク付け機械ＵＲＬを含むように拡張される。これを以降のＵＤＤＩ関連呼び出しに渡さなければならないことは、ＵＤＤパラダイムの要件である。

このフローは、ＷＳＤＬ供給業者によって挿入または処理される。または、いずれにしても、この機能は、ＵＤＤＩサーバに（Ａアドレス：ポートがルックアップ要求に渡される際）、または、ＵＤＤＩ処理に用いられる発呼側のＤＬＬのいずれかに隠れる。いずれの場合にも、ＵＤＤＩルックアップ・プロセスは、発呼側の介入なしに、フィルタリングを実行する。

このランク付け機械アドレスを受信するサービスが、以降のＵＤＤＩ／ＸＭＬ／ＳＯＡＰ動作のためにそれをわざわざ渡さない場合は、これはプロトコル違反であり、サービスは、ルールに従って動作しない。この分野における他の全ての規格と同様、これは、自己管理であろう。

しかしながら、サービスがこれらのルールに従ったか否かを示すため、新たなエントリが結合テンプレートおよびビジネス・サービスｔＭｏｄｅｌに追加される。この要素は、＜RankingSupported/＞と考えることができる。＜RANKER＞要素が呼に供給され、＜RankingSupported/＞が存在しない場合、find_xxＡＰｌはｔＭｏｄｅｌを選択しない。

ＡＰＩ実行の点で、これは、基本的に、ＵＤＤＩディレクトリをホストするコンピュータ上で実行される。選択を行うコードを変更して、新しいＡＰＩおよびｔＭｏｄｅｌタグに対応する。

従って、この記載により、ＵＲＬ要求を処理するためのランク付け機械を用い、関連したＵＤＤＩ／ＷＳＤＬプロトコルを拡張させることで、どのように新しい発信者プリファレンス選択機能をＵＤＤＩパラダイムに導入することができるかが示された。

１つのサービス・プロバイダが利用可能でなく、別のものを選択する必要がある状況では、以下を適用する。実際のサービス自体は、特定の結合ｔＭｏｄｅｌによって、インタフェース（パラメータ呼び出し）・レベルで指定する。特定のサービスが望まれる場合、結合テンプレートと呼ばれる特定のｔＭｏｄｅｌを用いることができる（または、多くの異なるＸＭＬ呼び出しを符号化する）。特定のｔＭｏｄｅｌを用いる供給業者が望ましくない場合（速度が遅すぎる、費用が高すぎる、機能しない等）、コードを変更して、異なるインタフェースを用いる別の供給業者を利用することができる。

記録の問題を回避するため、別の供給業者は、全く同一のインタフェースを用いて選択しなければならない。これは、換言すると、同じ結合ｔＭｏｄｅｌを用いるものである。これは、ＵＤＤＩルックアップにより容易に実行される。

ＵＤＤＩが、公的（すなわち一般に利用可能な）ディレクトリおよび私的（すなわち発呼側に固有の）ディレクトリに対応することに留意すべきである。これは、要求されたサービス全体が私的ディレクトリの範囲内にある場合（同一の組織内で、同一または複製されたＵＤＤＩサーバを用いる）は問題なく、この私的ディレクトリ内で実際動作するものによってプリファレンスの問題に対処することができる。しかしながら、この手法は、要求が私的ディレクトリの範囲外で実行される場合は、うまくいかない。ここに記載する方法およびシステムは、この問題を克服する。

また、ＵＤＤＩがPublisherAssertionのためのｔＭｏｄｅｌに対応することにも留意すべきである。これは、供給業者を、ある種のもっと大きなエンティティにリンクしようとするものである。これは、ここに記載した方法およびシステムとは重複しない。なぜならPublisherAssertionは、公的で、静的なものであり、これが注目されるる保証はない。

本発明の範囲から逸脱することなく、前述のことに改善および変更を行うことができる。

ウエブ・サービス・モデルの概略図である。 ウエブ・サービス・スタックの概略図である。 ＵＤＤＩデータ構造のブロック図である。 本発明に従ったウエブ・サービス階層の概略ブロック図である。 本発明に従ったウエブ・サービス・アーキテクチャの概略ブロック図である。 従来技術からの既知のサービス選択のフロー・ライン図である。 本発明に従ったサービス選択の第１の実施形態のフロー・ライン図である。 本発明に従ったサービス選択の第２の実施形態のフロー・ライン図である。

Claims (14)

1. ルート発信サービス・リクエスタ（４０１）を伴ったサービス階層（４０１、４０６、４０８、４１０）を有するウエブ・サービス・アーキテクチャにおいてサービスにランク付けするための方法であって、前記階層における第１のレベルのサービスが、より低いレベルのサービスを呼び出し、
   前記発信サービス・リクエスタ（４０１）が１つ以上のサービスに関するプリファレンス（優先的選択）を示すステップであって、ランク付け機械（４０５）が前記プリファレンスに基づいた選択アルゴリズムを有するステップと、
   前記発信サービス・リクエスタ（４０１）が、階層の１つ以上のレベルのサービスを呼び出すステップと、
   前記階層の各レベルにおいて、サービスが、１組の可能な、より低いレベルのサービスを検出するためにディレクトリ（４１１）を用いるステップと、
   前記ランク付け機械（４０５）が、前記１組の可能な、より低いレベルのサービスに前記選択アルゴリズムを適用するステップと、を有する方法。
2. 前記もっと低いレベルのサービスがサービス・リクエスタまたはサービス・プロバイダによって提供される、請求項１に記載の方法。
3. 前記１組の可能な、より低いレベルのサービスが、前記ディレクトリ（４１１）から前記ランク付け機械（４０５）に委託され、前記ランク付け機械（４０５）によって前記ディレクトリに好適なシーケンスが戻される、請求項１または２に記載の方法。
4. 前記ランク付け機械（４０５）に委託されるステップが、前記ディレクトリ（４１１）を用いる前記サービスには不可視である、請求項３に記載の方法。
5. 前記１組の可能な、より低いレベルのサービスが、前記ディレクトリ（４１１）を用いる前記サービスによって前記ランク付け機械（４０５）に送信され、前記ランク付け機械（４０５）によって前記サービスに好適なシーケンスが戻される、請求項１または２に記載の方法。
6. 前記ディレクトリ（４１１）を用いる前記サービスに単一の結果または結果のシーケンスが戻される、請求項１から５のいずれか１項に記載の方法。
7. 前記階層における、より低いレベルのサービスの呼び出しが、より高いレベルのサービスには不可視である、請求項１から６のいずれか１項に記載の方法。
8. 前記発信サービス・リクエスタ（４０１）のプリファレンスによって、前記発信サービス・リクエスタ（４０１）がサービスを利用したい順序に前記サービスをランク付けし、サービスを用いないよう除外し、もしくは選択基準に影響を与える他の選択を提供し、またはそれら全てを行う、請求項１から７のいずれか１項に記載の方法。
9. 前記発信サービス・リクエスタ（４０１）のプリファレンスが、コスト、効率、速度、および信頼性を含むサービス基準の品質に基づいている、請求項１から８のいずれか１項に記載の方法。
10. 発信サービス・リクエスタのプリファレンスがある場合、前記プリファレンスは、前記ディレクトリ（４１１）を用いる前記サービスによる選択よりも優先される、請求項１から９のいずれか１項に記載の方法。
11. 前記優先的選択されたサービスが利用可能でない場合、以降のサービスが前記発信サービス・リクエスタのプリファレンスを参照して得られる、請求項１から１０のいずれか１項に記載の方法。
12. 発信サービス・リクエスタのプリファレンスが保存されていない場合、前記ディレクトリ（４１１）を用いる前記サービスが選択を行う、請求項１から９のいずれか１項に記載の方法。
13. ルート発信サービス・リクエスタ（４０１）と、
    第１のレベルのサービスが、より低いレベルのサービスを呼び出すサービス階層（４０１、４０６、４０８、４１０）と、
    前記階層においてサービスを検出するためのディレクトリ（４１１）と、
    １つ以上のサービスに関する前記発信サービス・リクエスタのプリファレンス（優先的選択）に基づいて、サービスのための選択アルゴリズムを適用するための手段を有するランク付け機械（４０５）とを有し、
    前記階層の各レベルにおいて、前記ディレクトリ（４１１）が１組の可能なサービスを提供し、前記ランク付け機械（４０５）が前記選択アルゴリズムを適用して好適なサービスのシーケンスを提供する、ウエブ・サービス・アーキテクチャ。
14. ルート発信サービス・リクエスタ（４０１）を伴ったサービス階層（４０１、４０６、４０８、４１０）を有するウエブ・サービス・アーキテクチャのためのコンピュータ・プログラムであって、第１のレベルのサービスはもっと低いレベルのサービスを呼び出すものであり、前記コンピュータに、
    前記発信サービス・リクエスタ（４０１）が１つ以上のサービスに関するプリファレンス（優先的選択）を示すステップであって、ランク付け機械（４０５）が前記プリファレンスに基づいた選択アルゴリズムを有するステップと、
    前記発信サービス・リクエスタ（４０１）が、階層の１つ以上高いレベルのサービスを呼び出すステップと、
    前記階層の各レベルにおいて、サービスがディレクトリ（４１１）を用いて１組の可能な、より低いレベルのサービスを検出するステップと、
    前記ランク付け機械（４０５）が、前記１組の可能な、より低いレベルのサービスに前記選択アルゴリズムを適用するステップと、
    を実行するための、コンピュータ・プログラム。

Images