(57)【特許請求の範囲】
【請求項１】
プラットフォーム非依存のプロトコルを介してクライアントコンピュータにＷｅｂサービスを提供するコンピュータシステムにおいて、
前記クライアントコンピュータから、特定のＷｅｂサービスに対する要求を受け取り、前記コンピュータシステムのコンピュータ読み取り可能な記憶媒体にキャッシングされた複数のＷｅｂサービスのデータのうち、前記要求と適合するＷｅｂサービスのデータを含む第１のリストを生成するリスト生成手段と、
前記第１のリストの各Ｗｅｂサービスの評判データを、各Ｗｅｂサービスのプロバイダのサーバから収集する監査手段であって、前記評判データは、各Ｗｅｂサービスの人気と無関係な技術的なパフォーマンスを表す技術的属性データを含むものである監査手段と、
前記第１のリストを、前記監査手段が提供する前記評判データに基づいてフィルタリングして、少なくとも１つのＷｅｂサービスを特定する第２のリストに絞り込む選択手段と
を備え、
前記監査手段は、前記第１のリストの各Ｗｅｂサービスのプロバイダのサーバと通信して実際のパフォーマンスを測定することにより、前記技術的属性データを含む前記評判データを収集し、
前記技術的属性データは、前記第１のリストの各Ｗｅｂサービスの待ち時間情報またはアップタイム情報を含み、
前記第２のリストが前記クライアントコンピュータに受け取られることを特徴とするコンピュータシステム。
【請求項２】
前記第２のリストは、選択された単一のＷｅｂサービスを特定することを特徴とする請求項１に記載のコンピュータシステム。
【請求項３】
前記評判データは、前記第１のリストの各Ｗｅｂサービスのコスト情報を含むことを特徴とする請求項１に記載のコンピュータシステム。
【請求項４】
前記評判データは、前記第１のリストの各Ｗｅｂサービスのプロバイダの支払い能力のレベルを表す情報を含むことを特徴とする請求項１に記載のコンピュータシステム。
【請求項５】
前記評判データは、前記第１のリストの各Ｗｅｂサービスのプロバイダのプライバシー・ポリシーを表す情報を含むことを特徴とする請求項１に記載のコンピュータシステム。
【請求項６】
前記評判データは、前記第１のリストの各Ｗｅｂサービスのプロバイダの証明書データを表す情報を含むことを特徴とする請求項１に記載のコンピュータシステム。
【請求項７】
処理装置およびコンピュータ読み取り可能な記憶媒体を有するコンピュータシステムが、プラットフォーム非依存のプロトコルを介してクライアントコンピュータにＷｅｂサービスを提供する方法において、
前記処理装置が、前記クライアントコンピュータから、特定のＷｅｂサービスに対する要求を受け取り、前記コンピュータ読み取り可能な記憶媒体にキャッシングされた複数のＷｅｂサービスのデータのうち、前記要求と適合するＷｅｂサービスのデータを含む第１のリストを生成するステップと、
前記処理装置が、前記第１のリストの各Ｗｅｂサービスの評判データを、各Ｗｅｂサービスのプロバイダのサーバから取得するステップであって、前記評判データは、各Ｗｅｂサービスの人気と無関係な技術的なパフォーマンスを表す技術的属性データを含むものであるステップと、
前記処理装置が、前記第１のリストを前記評判データに基づいてフィルタリングして、少なくとも１つのＷｅｂサービスを含む第２のリストを選択するステップと
を備え、
前記評判データを取得するステップは、前記第１のリストの各Ｗｅｂサービスのプロバイダのサーバと通信して実際のパフォーマンスを測定することにより、前記技術的属性データを含む前記評判データを取得するステップを備え、
前記技術的属性データは、前記第１のリストの各Ｗｅｂサービスの待ち時間情報またはアップタイム情報を含み、
前記第２のリストが前記クライアントコンピュータに受け取られることを特徴とする方法。
【請求項８】
コンピュータシステムに、請求項７に記載の方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータ・システムおよびネットワークに関し、より詳細にはＷｅｂサービスに関する。
【背景技術】
【０００２】
ローカルに保持されるサービスやデータ、および企業ネットワーク上あるいはそれ以外のイントラネットおよびインターネットを含むリモート・アクセス可能なサイトで保持されるデータなど、コンピュータ・ユーザーおよびアプリケーションが管理したり、およびそうでなければアクセスしたりする必要があるさまざまなコンピューティング・サービス、リソース、およびデータが存在する。Ｗｅｂサービスの概念は、概して、本質的にクロス・プラットフォームであるプロトコルおよび標準（standards）を介してクライアントにコンピューティング・サービスを提供することを目的とする。たとえば、Ｗｅｂサービスは、要求側のクライアントが動作するプラットフォームの種類にかかわらず、分散アプリケーションのノード間を接続するための基本的なツールを提供する。
【０００３】
さまざまなコンピューティング・プラットフォームが存在するので、ＨＴＴＰ（HyperText Transfer Protocol）、ＸＭＬ（eXtensible Markup Language）、ＸＭＬ  Ｓｃｈｅｍａ、ＳＯＡＰ（Simple Object Access Protocol）  ＸＭＬなど、ネットワーク情報を交換できる、プラットフォーム非依存のさまざまなメカニズムやプロトコルが普及している。ビジネス、組織、およびその他のプロバイダがユーザーまたはアプリケーションにサービスを提供するＷｅｂサービスの概念は、今やこうした標準（standards）に基づいている。
【０００４】
Ｗｅｂサービスが有用であるためには、ユーザーやアプリケーションがＷｅｂサービスを突きとめることを可能とし、Ｗｅｂサービスの実行に必要な情報を交換することを可能にすることが必要である。このために、ＵＤＤＩ（Universal Description Discovery and Integration）は、ユーザーやアプリケーションがこうしたビジネス、組織、およびその他のＷｅｂサービス・プロバイダを検出するのを支援する一連の定義されたサービス（たとえば、ＵＢＲ（universal business registry））を、それぞれの使用可能なＷｅｂサービスの説明と、こうしたサービスへのアクセスに必要な技術的インターフェースと共に、提供する。
【０００５】
現在のところ、使用可能なＷｅｂサービスの数は比較的少ないので、Ｗｅｂサービスごとにコンシューマ（consumer）とＷｅｂサービスのプロバイダとの間の手動の接続が可能である。順序付け、タイミング、リソース利用など、必要なインターフェースに関する属性のリストに詳述される契約条件などの、コンシューマからの要求に適合するＷｅｂサービスのタイプを突きとめるためのさまざまなメカニズムが存在し、あるいは、開発されている。ＵＤＤＩベースの技術や最新の改良により、Ｗｅｂサービスについての狭義の自動検索が可能になっている。
【０００６】
【特許文献１】米国特許出願第１０／２６２，５５１号明細書
【特許文献２】米国特許仮出願６０／３７９，８６４号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、Ｗｅｂサービスの数が数百万に拡大し、この可能性が存在する場合、クライアントの基準に適合する数百あるいは数千のＷｅｂサービスが、こうした検索の結果として得られる可能性がある。クライアントが、こうした数千件の適合する、より小さな規模のサブセットからＷｅｂサービスを選択することを可能にする自動化された方法が必要である。
【０００８】
検出されたＷｅｂサービスの人気によるランク付けは、可能ではあるが、厳しく管理されたネットワークの外部では不十分なモデルであり、したがってインターネット上で利用可能なＷｅｂサービスをランク付けするためにはどちらかと言えば不適切である。第１に、そこにおけるＷｅｂが容易には消えない、公共性の高い、リンクの痕跡を残す、単純なＷｅｂサイト・アクセスとは異なり、Ｗｅｂサービスでは、その本質的な性質によって、こうした痕跡は残さない。さらに、Ｗｅｂサービス利用の痕跡を記録するメカニズムを導入しても、こうした痕跡から個人または企業の業務上の手法を特定できるので、プライバシーに対する懸念が問題になる。さらに、個々のＷｅｂサービスのオペレータは、新しい顧客を引き付けるために彼らの実際の人気をつり上げ、人気に基づく検索結果のリストにおいて彼ら自身に上位のランキングを基本的に与えようとする。また、検索エンジンのオペレータは、結果の順位を変更し、サービスがコンシューマのニーズに最もよく適合しなくても、高位に対して喜んで代価を支払うＷｅｂサービス・プロバイダに対して、実質的に上位のランクを売り付ける。さらに、Ｗｅｂサービスのコンシューマは、特定のＷｅｂサービスの人気に関して他を欺き、より応答性の高いＷｅｂサービスを競争相手に知られないようにし、恐らく競争相手がより信頼性の低いＷｅｂサービスを使用するように仕向ける可能性がある。
【０００９】
要するに、必要とされているのは、コンシューマにとって有益であり、コンシューマのニーズに最もよく適合するＷｅｂサービスをランク付けする自動化されたシステムである。人気ベースのモデル（popularity- based model）とは異なり、こうしたシステムには、実際のランク付けを大きく操作できないように、不正な手法に大きく左右されないことが要求されている。
【課題を解決するための手段】
【００１０】
簡単に言えば、本発明は、Ｗｅｂサービスまたはその他のリソースの評判情報（reputation information）に基づく選択を自動化するためのシステムおよび方法を提供する。評判情報は、技術指向とビジネス指向の属性を含む振る舞い属性（behavioral attributes）として体系化される。技術的な結果には、Ｗｅｂサービスの応答性（web service responsiveness）、Ｗｅｂサービスの待ち時間（web service latency）、Ｗｅｂサービスのアップタイム（web service uptime）など、サード・パーティーが経験的データとして観測できるサービス・レベルに関する合意（service-level agreement）の項目が含むことができる。ビジネス指向の振る舞い属性は、Ｗｅｂサービスを提供する企業のビジネス・モデルと信頼性とを示すものである。こうした属性には、コスト・データ、支払い能力（solvency）データ、企業を監査するエンティティ（entity）の識別情報、企業および／またはオーディタ（auditor）のデジタル証明書、プライバシー・ポリシー、企業のプライバシー・ポリシーを検証するエンティティの識別情報、およびその他の関連情報を含めてもよい。
【００１１】
１つの実装形態において、クライアントは検索エンジンに問い合わせ、検索エンジンはＷｅｂサービスごとに計算された評判のスコアに基づくランキングを使用して順位を付けたＷｅｂサービスのリストを返す。この目的のために、オーディタは評判データを収集し、これを検索エンジンに提供する。検索エンジンは契約データと評判データをキャッシングし、クライアントは契約要件と評判要件を、たとえばクエリーとして、提供する。検索エンジンは、契約データを巡回（crawl）してどのＷｅｂサービスがクライアントの基本的な操作要件に合致するかを判断し、評判データを巡回してこうした契約条件に合致するＷｅｂサービスのどれが最も評判が高いかを判断する。検索エンジンは、ランク付けのメカニズムを使用して、オーディタが提供する評判スコアに基づき、Ｗｅｂサービスごとのスコアを計算することができる。計算された評判スコアは、たとえば上位にランク付けされたＷｅｂサービス（top-ranked web services）のサブセットについて、オーディタやＷｅｂサービス・プロバイダが検証してもよい。
【００１２】
各Ｗｅｂサービスの評判スコアは、たとえばさまざまな振る舞い属性に即してカテゴリ化してもよい。また、クライアントは、属性を個別に重み付けするための計算データを提供してもよい。クライアントは、特定のカテゴリについて評判要件にどの程度一致するか、たとえば、正確に一致するか、許容範囲内であるか、を指定してもよい。クライアントは個々の評判要件を指定する必要はなく、これにより、デフォルトで省略されたカテゴリはランク付けの要因にはならない。
【００１３】
別の実装において、企業インターネットは、Ｗｅｂサービスの評判データを保持することが可能であり、それによって自社の独自のオーディタとして機能することができる。企業インターネットの実装は、単独でも、または上で一般的に説明した検索エンジン・ベース、独立したオーディタ・ベースのコンピューティング環境と連携して動作することによっても、Ｗｅｂサービスを選択できる。Ｗｅｂサービス・サーバもオーディタとして動作する信頼できるコード（trusted code）を実行でき、別の実装においても、前述の実装においても、動作できる。
【００１４】
その他の利点は、以下の発明を実施するための最良の形態と添付の図面を関連付けることで明らかになるであろう。
【発明を実施するための最良の形態】
【００１５】
例示的な動作環境
図１は、本発明を実装できる適切なコンピューティング・システム環境１００の例を示している。コンピューティング・システム環境１００は、適切なコンピューティング環境の１つの例にすぎず、本発明の使い方または機能の範囲に関するいかなる制限を示すものでもない。また、コンピューティング環境１００は、例示的なオペレーティング環境１００に示すコンポーネントの１つまたは組み合わせに関して、依存性も要件もないものとする。
【００１６】
本発明は、他のさまざまな汎用または専用のコンピューティング・システム環境または構成にも適用できる。本発明の使用に適した周知のコンピューティング・システム、環境、および／または構成の例には、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルドまたはラップトップ・デバイス、タブレット・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラム可能な家庭用電子機器、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、前述の任意のシステムまたはデバイスを含む分散コンピューティング環境などが含まれるが、これらに限定はされない。
【００１７】
本発明は、コンピュータで実行される、プログラム・モジュールのような、コンピュータ実行可能命令の一般的なコンテクストで説明することができる。一般に、プログラム・モジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがあり、特定のタスクを実行するものや、特定の抽象データ型を実装するものがある。本発明は、通信ネットワークを介してリンクするリモート処理装置でタスクを実行する分散コンピューティング環境でも実施できる。分散コンピューティング環境では、メモリ記憶装置を含むローカルおよび／またはリモートのコンピュータ記憶媒体にプログラム・モジュールを格納できる。
【００１８】
図１を参照すると、本発明を実施する例示的なシステムに、コンピュータ１１０の形で汎用のコンピューティング・デバイスが配置されている。コンピュータ１１０のコンポーネントには、処理装置１２０、システム・メモリ１３０、さまざまなシステム・コンポーネント（システム・メモリや処理装置１２０など）を接続するシステム・バス１２１が含まれるが、それらに限定はされない。システム・バス１２１は、さまざまなバス・アーキテクチャの任意の１つを使用したメモリ・バスまたはメモリ・コントローラ、周辺バス、ローカル・バスを含む各種バス構造のいずれでもよい。こうしたアーキテクチャには、例として、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカル・バス、ＰＣＩ（Peripheral Component Interconnect）バス（メザニン（Mezzanine）バスとも呼ばれる）が含まれるが、これらに限定はされない。
【００１９】
コンピュータ１１０は、通常はさまざまなコンピュータ可読媒体を備えている。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる任意の使用可能な媒体でよい。揮発性と不揮発性の両方、および取り外し可能と不可能の両方の媒体が含まれる。例として、コンピュータ可読媒体にはコンピュータ記憶媒体および通信媒体を含めてもよいが、これらに限定はされない。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータなどの情報を記憶する任意の方法または技術で組み込まれた、揮発性と不揮発性、および取り外し可能と不可能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリなどのメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ：digital versatile disk）などの光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスクなどの磁気記憶装置、または必要な情報を格納でき、コンピュータ１１０からアクセスできる他の任意の媒体が含まれるが、これらに限定はされない。通信媒体は、搬送波やその他の搬送メカニズムのような変調データ信号に、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータなどを具体化したものであり、任意の情報伝達媒体を含む。「変調データ信号」という用語は、信号内に情報を符号化するように設定または変更された１つまたは複数の特性を有する信号を意味する。例として、通信媒体には、有線ネットワーク、直接ワイヤ接続などの有線媒体と、音、ＲＦ、赤外線などの無線媒体が含まれるが、これらに限定はされない。上記の任意の組み合わせも、コンピュータ可読媒体の範囲内に含まれるものとする。
【００２０】
システム・メモリ１３０には、読み取り専用メモリ（ＲＯＭ：read only memory）１３１やランダム・アクセス・メモリ（ＲＡＭ：random access memory）１３２のように揮発性および／または不揮発性メモリという形をとるコンピュータ記憶媒体が含まれる。起動時などにコンピュータ１１０内のエレメント間の情報転送を支援する基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ：basic input/output system）は、通常はＲＯＭ  １３１に格納される。ＲＡＭ  １３２には、通常は処理装置１２０からダイレクトにアクセスできる、かつ／または処理装置１２０で現在操作しているデータおよび／またはプログラム・モジュールが格納される。例として、限定はしないが、図１にはオペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７が示されている。
【００２１】
コンピュータ１１０には、その他の取り外し可能／不可能、揮発性／不揮発性のコンピュータ記憶媒体を含めてもよい。単に例として、図１に取り外し不可能な不揮発性の磁気媒体の読み出しまたは書き込みを行うハードディスク・ドライブ１４１、取り外し可能な不揮発性の磁気ディスク１５２の読み出しまたは書き込みを行う磁気ディスク・ドライブ１５１、ＣＤ  ＲＯＭや他の光媒体のような取り外し可能な不揮発性の光ディスク１５６の読み出しまたは書き込みを行う光ディスク・ドライブ１５５を示す。例示的なオペレーティング環境で使用できる上記以外の取り外し可能／不可能、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュ・メモリ・カード、デジタル多用途ディスク、デジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭなどが含まれるが、それらに限定はされない。ハードディスク・ドライブ１４１は、通常はインターフェース１４０などの取り外し不可能なメモリ・インターフェースを介してシステム・バス１２１に接続し、磁気ディスク・ドライブ１５１と光ディスク・ドライブ１５５は、通常はインターフェース１５０などの取り外し可能なメモリ・インターフェースを介してシステム・バス１２１に接続する。
【００２２】
図１に示す前述のドライブとこれに対応するコンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュールなど、コンピュータ１１０のデータを格納できる。たとえば、図１を参照すると、ハードディスク・ドライブ１４１にオペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７が格納されている。ただし、こうしたコンポーネントは、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じでもよいし、異なっていてもよい。ここでは、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７には異なる番号を付けて、少なくとも別のコピーであることを示している。ユーザーは、タブレットまたは電子デジタイザ１６４、マイクロフォン１６３、キーボード１６２やポインティング・デバイス１６１（一般に、マウス、トラック・ボール、またはタッチ・パッドと呼ばれる）を使用してコンピュータ１１０にコマンドや情報を入力できる。他の入力装置（図示せず）には、ジョイスティック、ゲーム・パッド、サテライト・ディッシュ、スキャナなどを含めてもよい。これらの入力装置および他の入力装置は、多くの場合にシステム・バスに接続されたユーザー入力インターフェース１６０を介して処理装置１２０に接続するが、パラレル・ポート、ゲームポート、ＵＳＢ（universal serial bus）のような他のインターフェースやバス構造によって接続してもよい。モニタ１９１または他のタイプの表示装置も、ビデオ・インターフェース１９０のようなインターフェースを介してシステム・バス１２１に接続される。モニタ１９１は、タッチ・パネルまたは同様のものに組み込まれていてもよい。モニタおよび／またはタッチ・パネルは、タブレット・タイプのパーソナル・コンピュータなど、コンピューティング・デバイス１１０が組み込まれているハウジングに物理的に接続できることに留意されたい。さらに、コンピューティング・デバイス１１０などのコンピュータには、周辺出力インターフェース１９４または同様の機能を介して、スピーカー１９５やプリンタ１９６など、モニタ以外の出力周辺装置を接続してもよい。
【００２３】
コンピュータ１１０は、リモート・コンピュータ１８０のような１台または複数台のリモート・コンピュータへの論理接続を使用してネットワーク環境で動作できる。リモート・コンピュータ１８０は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、または他の一般のネットワーク・ノードでよい。通常は、コンピュータ１１０に関連して上で説明したエレメントの多くまたはすべてが含まれるが、図１にはメモリ記憶装置１８１のみを示す。図１に示す論理接続には、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）１７１とワイド・エリア・ネットワーク（ＷＡＮ：wide area network）１７３が含まれるが、他のネットワークを含めてもよい。このようなネットワーキング環境は、職場、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットではごく一般的である。たとえば、本発明において、コンピュータ・システム１１０はデータの移動元であるソース・マシンと、移動先であるリモート・コンピュータ１８０を備えていてもよい。ただし、移動元と移動先のマシンはネットワークまたはその他の方法で接続されている必要はないが、代わりに移動元のプラットフォームでデータを書き出すことができ、移動先のプラットフォームでデータを読み込むことができる任意の媒体を介してデータを移動してもよい。
【００２４】
ＬＡＮネットワーキング環境で使用した場合、コンピュータ１１０はＬＡＮ  １７１にネットワーク・インターフェースまたはアダプタ１７０を介して接続する。ＷＡＮネットワーキング環境で使用した場合、コンピュータ１１０は一般にインターネットなどのＷＡＮ  １７３を介して通信を確立するためのモデム１７２またはその他の手段を備えている。モデム１７２（内蔵でも外付けでもよい）は、ユーザー入力インターフェース１６０または他の適切なメカニズムを使用してシステム・バス１２１に接続できる。ネットワーク環境では、コンピュータ１１０またはその一部に関連して説明したプログラム・モジュールをリモート・メモリ記憶装置に格納できる。例として、図１にメモリ・デバイス１８１に格納されたリモート・アプリケーション・プログラム１８５を示すが、これには限定されない。図示されたネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは言うまでもない。
【００２５】
Ｗｅｂサービスの評判
本発明は、１つには、クライアントすなわちコンシューマがサーバすなわちプロバイダに、クライアント向けの特定のサービスを実行して、適切な応答をクライアントに返すように要求する場合に、Ｗｅｂサービスを突きとめることを目的とする。こうした要求と応答は、プラットフォーム非依存の１つまたは複数のプロトコルを介して行われる。こうしたプロトコルを介して、事実上任意のクライアントは、事実上任意のサーバと、それぞれのプラットフォームには依存せずに、通信することができる
ただし、理解されるように、プラットフォーム非依存のプロトコルに基づく一般的なＷｅｂサービス・モデルは、クライアント向けのソフトウェアを実行するサーバに限定されず、クライアントがアクセスを希望する任意のリソースに適用される。たとえば、近い将来、ハードウェアはある程度コンポーネント化され、ユーザーが一連のハードウェア・コンポーネントを選択し、プラットフォーム非依存の通信プロトコルを介してそうしたコンポーネントを相互接続し、コンピューティング・タスクを実行するという点で、実質的にソフトウェア指向のＷｅｂサービスとさまざまな点で区別できなくなることが見込まれる。たとえば、ユーザーはポケット・サイズのパーソナル・コンピュータを使用して物理的に別々の記憶装置やスピーカー（それぞれ増幅器を伴う）のセットに動的に接続し、記憶装置の音楽を取り出し、さらにこの音楽を適切な信号に変換し、スピーカーに送信して音楽を再生できる。各デバイスがこの通信プロトコルに従う限り（かつ、適切な帯域幅が使用可能な限り）、実質的に任意の認証済みデバイスが別の装置とデータをやりとりしてそのリソースを利用できる。
【００２６】
図２は、クライアント・コンピュータ・システム２０２（たとえば、図１のコンピュータ・システム１１０でもよい）は、プラットフォーム非依存のプロトコル、たとえばＸＭＬ形式のメッセージ２０８または同様のものを介して、選択された外部リソース２０６と通信するオペレーティング・システム２０４を備えている。
【００２７】
さらに、通常、単一のコンピュータ・システムの要素と見なされるハードウェアおよびソフトウェア・コンポーネント、たとえば、モニタ、マウス、キーボード、ディスク・ドライブ、および／またはハードウェア・デバイスをソフトウェアにインターフェースする従来のデバイス・ドライバを備える実質的に任意のデバイスなど、は同様にしてプラットフォーム非依存のプロトコルを介してデータを伝達できると考えられる。したがって、たとえば図２に一般的に示すように、ハードディスク・ドライブ・メーカーはコンピュータ・プラットフォームごとに異なるデバイス・ドライバを必要とせず、適切なプラットフォーム非依存のプロトコルに準拠する特定のハードディスク２１２用の唯一のデバイス・ドライバ２１０（たとえば、ＸＭＬ形式のメッセージ２１２）を記述できる。同様に、アプリケーション・プログラム２２０はプログラムするのにプラットフォームの関数呼び出しに関する知識は不要であり、プラットフォーム非依存のメッセージ２２２をオペレーティング・システム２０４に渡すように記述でき、したがって任意のプラットフォーム用にコンパイルできる。
【００２８】
したがって、本発明の１つの態様について基本的に従来Ｗｅｂサービスと見なされているものに関して説明するが、本発明は一般に任意のリソース（ソフトウェア・ベースのＷｅｂサービス、リモート・デバイス、内蔵のソフトウェアまたはハードウェアのいずれでもよい）を突きとめることを目的としている。したがって、本明細書で使用する限り、用語「リソース」と「Ｗｅｂサービス」は同義である。たとえば、外付けのハードウェア・デバイスとソフトウェア、内蔵のソフトウェアまたはハードウェア・コンポーネントもＷｅｂサービスと見なすことができる。
【００２９】
図３に一般的に示すように、本発明の１つの視点は、リソースの評判に基づくリソースの選択に向けられる（評判以外の点でクライアントのニーズに適合する複数の使用可能なリソースの中から）。このために、選択メカニズム３０２によってリスト３０４（または他の適切に編成されたデータ）からリソースを選択し、評判データ３０８に基づいてリストを選択されたリソース３０６に絞り込む。リストは、選択を要求するコンピュータに内蔵または外付けのリスト・メカニズム３１０と、内部または外部のオーディタ３１２が提供する評判データによって保持できる。ただし、図３に示すコンポーネントの一部またはすべては、選択メカニズム３０２を含めて、図２に示すコンピュータ・システム２０２の内部で実行しても外部で実行してもよく、内部と外部のコンポーネントに分散してもよいこと、また、選択されたリソース３０６は、図２に示すリソースのいずれか、たとえばディスク・ドライバ／ディスク２１０、２１２、外部のハードウェアまたはソフトウェア・リソース２０６、アプリケーション２００、またはその他のリソースでもよいことに留意されたい。たとえば、以下で説明するように、一連のＷｅｂサービスの一部は検索エンジンの選択メカニズム・コンポーネントによってＷｅｂサービスのサブセットに絞り込まれ、さらにこうしたサブセットはクライアントの選択メカニズムによって１つのＷｅｂサービスに絞り込まれる。
【００３０】
評判データ３０８は、評判以外の点で適合するリソース（Ｗｅｂサービス）がクライアントで実行しようとする特定のコンピューティング・タスクに関してどれくらい優れており、かつ／またはどれくらい適切であるかを本質的に特定する。言うまでもないが、本発明は特定のタイプのＷｅｂサービスに関するクライアントの基本的な動作要件に適合する（おそらく多くの）Ｗｅｂサービスのセットを検出するための基礎である契約の概念を補うものである。つまり、Ｗｅｂサービスがクライアントに役に立つかどうかを契約によって判断する。こうした要件には、呼び出すインターフェース、タイミングの関係、終了時のリソース解放に関する仕様を含めてもよい。契約については、本発明の譲受人に譲渡され、参考のためにここに組み込まれている特許文献１で一般的に説明されている。
【００３１】
本発明の１つの態様により、以下に説明するとおり、クライアントは、Ｗｅｂサービスの契約オファー（offering）に関するクライアントの契約要件に適合することによって特定されたセットから、評判データに基づいて最終的に１つのＷｅｂサービスを選択する。換言すれば、特定のＷｅｂサービス・インターフェース定義に関する非常に詳細な契約の適合により、Ｗｅｂサービス・プロバイダのグローバル検索が可能になる。指定した契約要件に適合するリソースが検索によって複数得られた場合は、クライアントが検索結果の１つを選択する必要がある。本発明は、評判データを使用して検索結果をフィルタおよび／またはランク付けすることでリソースを選択するためのシステムおよび方法を提供する。
【００３２】
この目的のために、評判データを体系化し、経験的に決定してもよい。また、評判データに、技術指向とビジネス指向の両方の振る舞い属性を含む振る舞い属性を含めてもよい。たとえば、技術的な属性データには、Ｗｅｂサービスが特定のポートから読み出す頻度によって設定できる応答性、特定の操作の結果として超えないことが保証される待ち時間によって確立される待ち時間、およびサイトまたはデバイスが使用可能（または使用不可能）として参照された回数、および１日のうちの時間によって特定することができるアップタイムなど、サード・パーティーが経験的なデータとして観測できるサービス・レベルの契約項目を含めることができる。
【００３３】
ビジネス指向の振る舞い属性の例は、要求側クライアントがＷｅｂサービスを提供する企業のビジネス・モデルと信頼性を特定するための基準を示すものである。こうした属性には、Ｗｅｂサービスを利用する金銭的なコストがかかるか、あるいは無料で提供されるかを含めてもよい（たとえば、発注書を送付するためのＷｅｂサービスなど、他のビジネスをサポートする上で）。コストがかかる場合は、一般にサービスの対象となるトランザクションあたり、ポートあたりのコストとしてコード化してもよい。その他のビジネス指向の情報には、該当するＷｅｂサービスを提供する企業の支払い能力のレベルを示す何らかの指標、こうした企業を監査するエンティティの識別情報、こうした企業および／またはオーディタのデジタル証明書、企業が設定するプライバシー・ポリシー、こうしたポリシーを検証するエンティティの識別情報（たとえば、企業のプライバシー・ポリシー証明書の監査を担当したエンティティを特定する）を含めてもよい。さらに、他のビジネス指向の情報には、たとえばそれぞれ信頼性確認のために照会される独自の評判スコアを有する他の顧客のデジタル証明書などの参照情報を含めてもよい。
【００３４】
本発明は、こうしたデータを使用してＷｅｂサービスの評判情報に基づく選択を自動化するためのシステムおよび方法を提供する。より詳細には、以下で説明するように、１つの実装において、初めはコンシューマの契約要件への一致によって取得された検索結果のリストを、要求側のＷｅｂサービス・コンシューマは評判データを使用してフィルタおよび／またはランク付けできる。ランク付けする場合は、各振る舞い属性カテゴリのさまざまなスコアにさまざまな重みを割り当てることができる。たとえば、特定の要求側コンシューマがコストを最も重視する場合に、このコンシューマはコストのカテゴリに他のカテゴリより大きな重みを割り当てることができる。したがって、検索結果のランク付けは待ち時間が短いことをより重視する別のコンシューマとは異なる。ただし、以下で説明するように、フィルタおよび／またはランク付けは実際にクライアントで実行する必要はなく、クライアントの代わりにサーバで実行してもよい。
【００３５】
図４は、本発明の１つの態様に従って編成された分散型評判システムの別の実装例を示している。図４において、Ｗｅｂクライアント・コード４０２は特定のＷｅｂサービス契約要件とＷｅｂサービスの評判要件をクエリー４０４としてＷｅｂサービス検索エンジン４０６（たとえばＵＤＤＩ検索エンジン）に渡す。この目的のために、１つの実装例において、ｘＳｐｒｅｓｓｏと呼ばれる機能豊富なクエリー言語が、ＵＤＤＩ検索サービス（たとえば検索エンジン４０６）にマッチングまたはソートを行わせるため、特定の契約と評判のクエリー条件内に渡すべきクライアント・コード４０２に構造を提供する。さらに、ｘＳｐｒｅｓｓｏクエリーは、各評判カテゴリに、個別に重みを割り当てることができる。一般に、ｘＳｐｒｅｓｓｏ（参考のために本明細書に援用する２００２年５月１０日に出願された特許文献２および２００２年１１月２２日に出願された特許本出願のシリアル番号［まだ取得していない］に説明されている）は、ブローカー（brokers）が制御するプログラミング言語と実行時間、および非同期システム・コンポーネント間のデータ・フローに対処する。中でも、ｘＳｐｒｅｓｓｏは、順序付けやタイミングなど、プログラム的に検証できるプログラムまたはサービスの共通の次元を表現する。この言語は、ＸＭＬのようにカスタマイズ可能なタグ・ベースの言語から構成された組織的なスキーマのパスをプログラム的に表現できる。
【００３６】
以下に示すｘＳｐｒｅｓｓｏのサンプル・コードにおいて、クエリーはＵＤＤＩサーバ（たとえば検索エンジン４０６）に渡され、ＦｉｎｄＳｅｒｖｉｃｅクエリーによって返される順序付きの検索結果を要求する。この例で、クエリーは、評判データに加えて、特に個々の詳細な契約への適合に、関係されられる。評判データは、９９．９９５％以上のアップタイム要件、ポートあたり、トランザクションあたり＄０．０００５を超えないコスト、を有するＷｅｂサービス・プロバイダで、さらにＷＸＹＺ財務レビュー（review）企業でレビューされている企業を指定する。
【００３７】
【表１】
0004549867.tif 000002
【００３８】
以下は、配線を経由して送信するために、上述のｘＳｐｒｅｓｓｏのクエリーをＸＭＬにコンパイルした結果の生のＸＭＬ（実際に配線を経由して送信され、ＵＤＤＩサーバ上でクエリー形式には戻されない）を表す。こうした結果には、実際のＦｉｎｄＳｅｒｖｉｃｅクエリーに関連付けられた＜ｃｌａｕｓｅ＞文のみが含まれることに留意されたい。
【００３９】
【表２−１】
0004549867.tif 000003
【００４０】
【表２−２】
0004549867.tif 000004
【００４１】
図４に戻り、Ｗｅｂサービス検索エンジン４０６は、Ｗｅｂサービス契約オファー４１０1〜４１０nを提供する多くのＷｅｂサービス・サーバ４０８1〜４０８nの契約データと評判データにアクセスし、クエリーが実行されると、契約データを巡回してクライアントの契約要件に適合するサーバを検出する。契約データと、場合によっては一部またはすべてのサーバの評判データは、Ｗｅｂサービス検索エンジン４０６にバック・グラウンドでロードされ、キャッシングされ、その結果として、キャッシングされたＷｅｂサービスと評判のビューからクエリーを迅速に処理できることが好ましい。
【００４２】
本発明の１つの態様により、さらにＷｅｂサービス検索エンジン４０６は、キャッシングされた評判データを巡回し、クライアントの評判要件に適合するサービスを検出する。ただし、契約および／または評判の巡回（crawling）が完了して適合するものがない場合に、Ｗｅｂサービス検索エンジン４０６は、たとえば結果を得るにはクライアント４０２が要件を緩和する必要があることを示すメッセージをクライアント・コード４０２に返すことができる。
【００４３】
前述のように、評判は多くの要因に基づいており、評判データは多くの情報源から取得できる。たとえば、Ｗｅｂサービス・サーバ４０８1〜４０８nは、オーディタ４１４にデータ４１２1〜４１２nを提供することで自らを宣伝できる。クライアント４０２が、実際に観測される応答性などの評判データ４１６をオーディタ４１４に提供してもよい。他のクライアント、独立した評価サービス（批評（critics）および評論（reviewers））、およびその他の関連エンティティなどの他のパーティも、評判データ４１８をオーディタ４１４に提供できる。オーディタは、さまざまな情報源から取得した評判データを相互に関連付け、相関データ４２０をＷｅｂサービス検索エンジン４０６に提供する。検索エンジンは、必要に応じてこのデータをキャッシングして巡回し、クライアントの評判要件に適合するサービスを検出する。
【００４４】
例として、Ｗｅｂサービスは、自分自身の保証情報を宣伝してもよい。この情報は、たとえば、すでに企業をランク付けし、信用のスコアを提供し、デジタル・トラスト・サービス・シグネチャ（digital trust services signatures）を提供し、かつ／またはレビュー製品を提供している企業など、任意の数の独立したさまざまなサービス・オーディタによって巡回され、キャッシングすることができる。オーディタは、宣伝されているサービスの技術的な成果と、数千あるいは数百万のサービス・コンシューマによって観測された実際の技術的な成果とを比較することもできる。その他の利点として、独立した信頼できるオーディタを備えることで、データを提供する企業または個人は、匿名を使用できる。
【００４５】
各評判データの情報源は、それ自身、評判を有し、これは、オーディタが提供する各情報源の評判データの値に要素として組み入れられる。たとえば、信頼できる独立したサード・パーティー・レビューア（reviewer）から取得されたと決定することができるスコアからの１つの評判値のセットには、疑わしい情報源から取得した数千のスコアより大きな重みを割り当てることができる。複数の競合する独立したオーディタが存在することで、各オーディタは信頼できることを強制され、実際に、Ｗｅｂサービスや検索エンジン・プロバイダのコンシューマは、それ自身の経験に基づいて、さまざまなオーディタの評判スコアを採用でき、どのオーディタがコンシューマに最適であるかを判断できることに留意されたい。
【００４６】
図４に戻り、契約と評判の巡回が完了すると、（一時的な）ランク付けされたリスト４２２がＷｅｂサービス検索エンジン４０６で構成され、これによって一般にＷｅｂサービス・サーバの管理可能なサブセットが提供される。理解されるように、実質的に任意のランク付けアルゴリズム４２４を、次に示すようにオーディタから返されるカテゴリごとの評判スコアとカテゴリごとに提供されるクライアントの重みとの積の和（下記）をとる直接的なアルゴリズムを含めて、使用することができる（たとえば、応答性は１つの評判カテゴリのスコアであり、アップタイムは別のカテゴリ、コストはさらに別のカテゴリ、以下同様と言える）。
【００４７】
サービスのスコア＝（カテゴリ１のスコア＊クライアントが割り当てるカテゴリ１の重み）＋（カテゴリ２のスコア＊クライアントが割り当てるカテゴリ２の重み）＋．．．（カテゴリのスコア＊クライアントが割り当てるカテゴリＸの重み）
Ｗｅｂサービス検索エンジン４０６がランク付けされたリスト４２２を作成すると、Ｗｅｂサービス検索エンジン４０６は多くのタスクを実行して、このリストをさらに処理することができる。たとえば、上位にランク付けされたＷｅｂサービス・サーバと通信して要求したサービスを依然として提供できることを確認し、かつ／またはオーディタと通信して、上位にランク付けされた各Ｗｅｂサービス・サーバの評判データが依然として正しいことを確認することができる。たとえば、Ｗｅｂサービスの評判は該当するサーバの現在の負荷に基づいて変動する。つまり、混雑していない場合はサービスが上位にランクされ、混雑している場合はサービスのランクが低くなる。負荷は急速に変動するので、オーディタは上位にランク付けされた候補に対してほとんどリアルタイムで接続して最新の評判データを取得し、必要に応じてリストの上位を占めるＷｅｂサービスの一部またはすべてを追加、削除、順序変更するなどの調整を行ってもよい。
【００４８】
最終的に、少なくとも１つのＷｅｂサービス・サーバが契約と評判の要件に適合する場合に、Ｗｅｂサービス検索エンジン４０６は、特定のＷｅｂサービスを実装するプロバイダ（たとえばそれぞれへのリンクなど）のランク付けされたリスト４２６を、クエリー４０４への応答としてクライアント４０２に返す。ただし、検索エンジン４０６はトップにランク付けされたプロバイダのみを返すこともできるが、いくつかの上位プロバイダのリストからクライアントがいずれかを選択するのが好ましい。たとえば、クライアントは必ずしも評判スキーマに含まれていない、クライアントの独自の経験や好みに基づく別の基準を適用することができる。つまり、特定のサーバのＷｅｂサービスを、そのランクにかかわらず絶対に使用しない場合や、ランクにかかわらず１つのサーバを別のサーバより優先する場合がある。
【００４９】
一般に、Ｗｅｂサービス検索エンジン４０６は、ランク付きのリスト４２６としてクライアント４０２に返すデータの量（リストのサイズ）をフィルタリングするために、巡回を実行する。ただし、クライアント４０２は、リストから選択するだけでなく、少なくとも何らかのフィルタリングを適用できることに留意されたい。たとえば、匿名であることが必ずしも問題でないと仮定すると、Ｗｅｂサービス検索エンジン４０６は、各プロバイダにスコアのセット、すなわち応答性、待ち時間、アップタイム、コスト、財務データ、監査データ、プライバシー、および／または参照データなど、スコアを設定するときに使用できるいくつかの可能な要因に対応するものを提供できる。こうした個々のスコアは、クライアントが最終的に選択する上で有益であろう。たとえば、ソートされたリスト４２２にはランクの近い多くのサーバが含まれ、かつ／またはクライアントの好みに合わせて十分に絞り込むクエリーを提供できず、代わりとして検索後に、いくつかのクライアントの独自のフィルタリングを望む場合に、有益である。
【００５０】
図５は、図４に示すものと同様の実装が動作する一般的なタイミングを示している。一般に、クライアント５０２は、Ｗｅｂサービス・プロバイダのランク付きのリストを要求するＷｅｂサービス・クエリーをＷｅｂサービス検索エンジン５０６に送信することにより、プロセスを開始する。これは、図５の矢印（１）で示されている。前述のように、このクエリーには契約要件と評判要件が含まれる。
【００５１】
また、前述のように、Ｗｅｂサービス検索エンジン５０６は、キャッシングされたデータ５３０を巡回し、契約要件および評判要件とプロバイダとの適合を探す。これは、図５の矢印（２）で示されている。この結果、通常、ランク付けされて、検証されている、より管理しやすい、サブセットが得られる。たとえば、上位にランクされたプロバイダは、数１０００プロバイダの中の数１００件でなく、数１０件である可能性がある。この上位にランク付けされたプロバイダのサブセットは、後続の検証プロセスで順位が変わる場合は、クライアント５０２に返されることになるリストより若干大きい可能性がある。たとえば、クライアントが上位１０プロバイダのリストを要求する場合に、後続の処理によって１０プロバイダに絞るために、このサブセットは２０プロバイダ程度あることが可能である。
【００５２】
リストの上位にランク付けされたプロバイダのそれぞれについて、Ｗｅｂサービス検索エンジン５０６は、（たとえばキャッシュのタイム・スタンプに基づいて）プロバイダの対応するサーバ（たとえば５０８1）と通信し、参照情報、確認情報などを要求すること、一般的にサーバ５０８1〜５０８rが、少なくともサーバの観点からは、機能しており、要求したサービスに関して依然として宣伝のとおりに動作すること、を確認するように選択することもできる。こうした通信は、図５の矢印（３）と（４）で一般的に示されている。
【００５３】
また、Ｗｅｂサービス検索エンジン５０６は、（たとえばキャッシュのタイム・スタンプに基づいて）オーディタ５１４と通信し、各プロバイダの宣伝データが、おそらくさまざまな情報源（たとえば、他のクライアント、独立した測定機関、その他のレビューアなど、上で一般的に説明した）からのデータを編成したオーディタの最新のデータに対応するかどうかを、オーディタの観点から確認するように選択することもできる。こうした通信は、図５の矢印（５）と（６）で一般的に示されている。
【００５４】
何百万ものＷｅｂサービスがあり、特定のＷｅｂサービスのキャッシュした評判データはサーバの現在の負荷によって変動する応答性データのような目まぐるしく変化するデータに関して陳腐化している可能性があるので、サーバが接続されているかどうかにかかわらず、こうしたオーディタ５１４との通信により、クライアントは最新の評判データに基づくリストを受け取ることができる。検索エンジン５０６は、サーバおよび／またはオーディタから受け取られた評判データに対する各Ｗｅｂサービスについて、検索エンジンにキャッシングされた評判データを更新する。
【００５５】
サーバとオーディタ５１４からデータ５３２を受け取ると、Ｗｅｂサービス検索エンジン５０６は受け取ったデータ５３２を処理して、それをリストに関連付ける。これは、図５の矢印（７）で一般的に示されている。この結果、リストの順序の入れ替え、リストからの１つまたは複数のプロバイダの削除などを含めて、最初のランキングの順位が変更される場合がある。ただし、検索エンジン５０６がリストを埋めるためにさらにプロバイダが必要な場合、および／または結果が不十分な場合に、検索エンジンは最初にランキングに入っていたが、個々の参照確認（図５の矢印（３）から（６））では選択されていない他のプロバイダのデータを取得できる。たとえば、前述のように、Ｗｅｂサービス検索エンジン５０６は、サーバおよび／またはオーディタと通信してから、評判スコアの一部またはすべてが個々には確認されていない他のプロバイダの最初の評判スコアより下がったことを観測した場合は、こうした他のプロバイダの現在のデータを取得してクライアントにより適切なリストを提供するように決定することもできる。
【００５６】
この処理に続いて最終的なリストが作成されると、このリストがクライアントに返される。この様子は、図５の矢印（８）で一般的に示されている。次に、クライアント５０２はリストからプロバイダを選択し、これに対応するサーバ（たとえば図５のサーバ５０８1）に接続し、サービスが実行される。こうした通信は、図５の矢印（９）と（１０）で一般的に示されている。サービスの実行に続き、クライアント５０２は対応する評判データ（たとえば観測されたパフォーマンスのデータ）をオーディタ５１４に報告する。これは、図５の矢印（１１）で示されている。オーディタ５１４は、たとえばクライアントの評判に基づいて重みを割り当て、重み付けした値をこの特定のプロバイダに関する他の入力と数学的に組み合わせることで、結果のデータを集計する。
【００５７】
図６は、本発明の１つの態様によって編成された分散型評判システムのもう１つの（たとえばエンタープライズ環境向けの）実装例６００を示している。図６で、企業イントラネット６４４には多くのコンシューマ（たとえばＷｅｂクライアント・コード６０２1〜６０２mなど）が含まれている。企業のプロキシ／ファイアウォール６４６は、Ｗｅｂサービス・プロバイダ６０８から受け取った宣伝された技術的な（評判の）データ６１２と実際に測定された技術的なデータ６５０との違いを観測するパフォーマンス測定メカニズム６４８を備えるようにコード化されている。
【００５８】
この実装において、各企業はＷｅｂサービス・プロバイダの宣伝された評判についての小規模な独自のオーディタになってもよい。ただし、企業の従業員は企業内ネットワーク上で観測される（ログに記録された）振る舞いのプライバシーについて期待はしない。特定のビジネス・ライン・アプリケーションのシステム管理者は、こうしたメカニズムを使用して外部の企業がサービス契約を果たさない場合に警告し、必要に応じて内部クライアント・コードを競合するＷｅｂサービスに変更する（あるいは、フェイル・セーフとして自動的に変更される場合もある）。さらに、一部またはすべてのＷｅｂサービス・プロバイダは企業イントラネット６４４の内部に存在してもよい。この場合は、どの内部プロバイダが他より適切であるかを管理者が迅速に認識できる。
【００５９】
当然のことながら、図６に示す別の実装を図４に示す別の実装と組み合わせてもよい。たとえば、検索エンジン４０６から返されるランク付けされたリスト４２６（図４）から、測定された評判データ６５０（図６）を使用して１つのサービスを選択してもよい。また、企業は、他のＷｅｂサービスに関する今後のクエリーについて割り引く代わりに、あるいはグローバルなデータを取得するための要件として、全体として集計するために、その外部Ｗｅｂサービスの測定された観測データ６５０を、独立した外部のサービス・オーディタ５１４に（および場合によってはその他のオーディタにも）送信する。
【００６０】
本発明に沿って、Ｗｅｂ全体（または非常に大規模なネットワーク）にわたって評判データを集計すると、大規模な統計サンプルによって極端な情報が打ち消されるので、要求者あるいはプロバイダによる欺瞞的な、あるいは誤解を招くようなデータが抑制される。集計データによって、コンシューマ（たとえば企業）は観測された振る舞いがＷｅｂサービスで制御できないいくつかのアクティビティによる例外的な状況であったかどうかの判断について通知を受け取ることができる。たとえば、通信リンクの局所的な破損は局所的に観測される待ち時間には影響するが、全体的に観測される待ち時間には影響しない。
【００６１】
図７に、Ｗｅｂサービス・サーバ７０８が、信頼できるオーディタ７５０を内部的に実行する別の実装形態７００を示す。クエリー７５２（これは、中間的な検索エンジン（図示せず）に送信してもよい）に応答して、Ｗｅｂサービス・サーバ７０８は、契約オファー７５６に加えて、信頼できるオーディタが評価した実際の評判データ７５４を返す。代わりに（またはさらに）、信頼できるオーディタは、図４と５に示すように、独立したより大規模なオーディタに報告してもよい。
【００６２】
言うまでもないが、図７に示す実装において、Ｗｅｂサービス・サーバ７０８は本質的にそれ自身のオーディタとして動作する。こうしたモデルの信頼性はさまざまな方法で確認できる。たとえば、信頼できるＷｅｂサービス・プロバイダは、独立した、または絶対的に信頼できる変更されないオーディタ・コード７５０を実行し、データをそのまま報告することを断言できる。外部の監査機関（audits）、クライアントの測定結果などがこれを検証することができ、評判のよい大企業は、そのコードまたは実際の結果を改ざんすることで評判を落とすことのないようになる。
【００６３】
公正な内部の監査を実施する別の例として、信頼できる領域で監査コード（auditing code）を実行する方法がある。より詳細には、オペレーティング・システムとハードウェアは、改ざんできない信頼できる領域で、コードを実行し、データを格納できる。内部オーディタ７５０をサービスのシステム管理者が操作できない場所に置くことで、オペレーティング・システムはＷｅｂサービスの実際のパフォーマンスに関する公平な見解（view）を提供できる。
【００６４】
信頼できるオーディタのさらに別の例は、企業ネットワーク、ホームネットワークのようにハードウェアまたはソフトウェア・リソースを相互接続した環境など、クライアントとプロバイダが本質的に同一のエンティティによって所有される場合である。こうした環境では、両者が同一のエンティティに属するため、プロバイダはクライアントを誤解させようとする動機はない。
【００６５】
例として、１つまたは複数の使用可能なコンピューティング・デバイス上でアプリケーションを実行しようとするクライアントについて考察する。クライアントのＩＤに関連付けられたさまざまなデバイス間にオペレーティング・システムのサービスを分散することで、信頼性、パフォーマンス、その他のハードウェアの評判に関する経験的なデータを収集できる。本質的に同等であるその他の選択要因、つまり使用可能なさまざまなマシンが十分な容量と十分な処理速度を有する場合を想定する、このユーザーは、信頼性に関する評判の高いマシン上で、アプリケーションまたはＷｅｂサービスの分散された要素を実行することを望むことになる。
【００６６】
さらに、本発明は前述のように膨大な数のサービスを処理するように拡張できるが、個々のハードウェアまたはソフトウェア・コンポーネント・レベルに縮小することもできる。このレベルの評判にはさまざまな基準の組合せがあることに留意されたい。たとえば、クリーンで明確なインターフェース、契約に関する十分な説明、適切なドキュメンテーション、外部コミュニティの支援などを備えたソフトウェアは、こうしたカテゴリのスコアが低いソフトウェアより評判がよい。同様に、デバイスを選択できる場合に、通常、ユーザーは信頼性の低いハードウェア・デバイスを別のハードウェア・デバイスとの相互接続の対象として初めから選択しない。このデータは、ユーザーがデバイスを相互接続するための中央のデバイス（たとえばパーソナル・コンピュータ）に評判データとしてキャッシングすることもできるが、他の場所から取得することもできる。
【００６７】
以上の実施形態に関する説明からわかるように、こうしたデータを使用してＷｅｂサービスの評判データに基づく選択を自動化するためのシステムおよび方法が提供される。本システムおよび方法は、評判のスコアに基づいてＷｅｂサービスをランク付けすることができ、多くのＷｅｂサービスがクライアントとのその他の要件に一致する場合に、Ｗｅｂサービスの選択を容易にする。本発明は、内部のソフトウェア・コンポーネントやハードウェア・デバイスおよびコンポーネントを処理する場合など、少数のＷｅｂサービスから選択を容易にするために縮小することもできる。このように、本方法およびシステムは、最新のコンピューティングに求められる重要な利点と効果を提供する。
【００６８】
本発明は、さまざまな変更や別の構成が可能であるが、例として示すその特定の実施形態を図示し、以上に詳述してきた。ただし、本発明を開示された特定の形態へ限定することを意図するものでないこと、逆に、すべての変更、代替の構成、および均等物は、本発明の精神と範囲を逸脱しないことを理解されたい。
【図面の簡単な説明】
【００６９】
【図１】本発明を組み込むことができるコンピュータ・システムを一般的に示すブロック図である。
【図２】本発明の１つの態様により、プラットフォーム非依存の方式でリソースと通信するように編成されたコンピュータ・システムを一般的に示すブロック図である。
【図３】本発明の１つの態様による、評判データに基づくリソースの選択を一般的に示すブロック図である。
【図４】本発明の１つの態様により、評判データに基づいてＷｅｂサービスを自動的に検出する分散システムのコンポーネントを一般的に示すブロック図である。
【図５】本発明の１つの態様により、評判データに基づいてＷｅｂサービスを自動的に検出するタイミングのシナリオを一般的に示すブロック図である。
【図６】本発明の１つの態様により、評判データを自動的に収集するコンポーネントを伴う企業イントラネットを含むＷｅｂサービス環境を一般的に示すブロック図である。
【図７】本発明の１つの態様により、評判データを要求側クライアントに提供するＷｅｂサービス・サーバを一般的に示すブロック図である。
【図１】
0004549867.tif 000005
【図２】
0004549867.tif 000006
【図３】
0004549867.tif 000007
【図４】
0004549867.tif 000008
【図５】
0004549867.tif 000009
【図６】
0004549867.tif 000010
【図７】
0004549867.tif 000011