(57)【要約】ハードウェア・コンポーネント及びソフトウェア・コンポーネントについての情報を格納するための、改善されたディレクトリ・サービスを提供する方法、コンピュータ・プログラム、及びデータ処理システムが開示される。このディレクトリ・サービスは、他のハードウェア・コンポーネント及びソフトウェア・コンポーネントが、ディレクトリ内に列挙されたコンポーネントを見つけ、利用するために必要とする情報を格納するだけでなく、クライアントの機能要件を満たす「メタサービス」を動的に構成することも可能にする。
2006500650.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェア・コンポーネント及びソフトウェア・コンポーネントについての情報を格納するためのコンピュータ実装方法であって、
機能要件を含む要求を受信し（５０１）、
ディレクトリ（４０１）に問い合わせて、前記機能要件を満たす単一のコンポーネントが存在するかどうかを判断し（５０２）、
前記機能要件を満たす単一のコンポーネントが存在しないという判断に応答して、ある組合わせ方法に従って組み合わされた時に該機能要件を満たすであろう複数の機能を特定し（８１６）、
前記複数の機能を満たす複数のコンポーネントを特定する（８１８）、
段階を含む方法。
【請求項２】
前記機能要件がサービスの定義であり、前記ディレクトリが、利用可能なサービスのデータベースに問い合わせることによって、定義されたサービスが利用可能かどうかを判断する、請求項１に記載の方法。
【請求項３】
前記機能要件を達成するための前記組合わせ方法に従って前記複数のコンポーネントを組み合わせる命令を導き出す段階をさらに含む、請求項１又は請求項２に記載の方法。
【請求項４】
前記要求がクライアントによってなされる請求項３に記載の方法であって、該方法が、
前記命令を前記クライアントに戻す段階をさらに含み、
前記クライアントが前記複数のコンポーネントを利用して前記機能要件を達成できるようにする方法。
【請求項５】
前記要求がクライアントによってなされる請求項３に記載の方法であって、該方法が、
前記命令を遠隔メタサービス・プロバイダに提供し、前記遠隔メタサービス・プロバイダが、前記複数のコンポーネントを組み合わせてメタサービスにすることによって前記機能要件を満たす機能を前記クライアントに提供できるようにする段階をさらに含む方法。
【請求項６】
前記複数のコンポーネントを再特定することなく将来使用できるように、該複数のコンポーネントを登録する段階をさらに含む、前記請求項のいずれかに記載の方法。
【請求項７】
前記要求がクライアントによってなされる請求項１に記載の方法であって、該方法が、
前記クライアント以外のサービスに利用可能な前記複数のコンポーネントの特定を行う段階をさらに含む方法。
【請求項８】
前記要求がクライアントによってなされる請求項１に記載の方法であって、該方法が、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定し、
前記複数の組合わせのうちの一つの組合わせを選択することを前記クライアントに提案する、
段階をさらに含む方法。
【請求項９】
前記要求がクライアントによってなされる請求項１に記載の方法であって、該方法が、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定し、
付加的な好みを定めるために前記クライアントに質問し、
前記付加的な好みに基づいて、前記複数の組合わせのうちの少なくとも１つの組合わせを選択し、前記クライアントに提案する、
段階をさらに含む方法。
【請求項１０】
コンピュータ・プログラムであって、
機能要件を含む要求を受信し（５０１）、
ディレクトリ（４０１）に問い合わせて、前記機能要件を満たす単一のコンポーネントが存在するかどうかを判断し（５０２）、
前記機能要件を満たす単一のコンポーネントが存在しないという判断に応答して、ある組合わせ方法に従って組み合わされた時に該機能要件を満たすであろう複数の機能を特定し（８１６）、
前記複数の機能を満たす複数のコンポーネントを特定する（８１８）、
ことからなるコンピュータによって実行される方法を、前記コンピュータに実行させる命令を含む、コンピュータ・プログラム。
【請求項１１】
前記機能要件がサービスの定義であり、前記ディレクトリが、利用可能なサービスのデータベースに問い合わせることによって、定義されたサービスが利用可能かどうかを判断する、請求項１０に記載のコンピュータ・プログラム。
【請求項１２】
前記コンピュータによって実行される前記プロセスが、
前記機能要件を達成するための前記組合わせ方法に従って前記複数のコンポーネントを組み合わせるための命令を導き出す段階をさらに含む、請求項１０又は請求項１１に記載のコンピュータ・プログラム。
【請求項１３】
前記要求がクライアントによってなされる請求項１２に記載のコンピュータ・プログラムであって、コンピュータによって実行される前記方法が、
前記命令を前記クライアントに戻す段階を含み、
前記クライアントが前記複数のコンポーネントを利用して前記機能要件を達成できるようにする、コンピュータ・プログラム。
【請求項１４】
前記要求がクライアントによってなされる請求項１２に記載のコンピュータ・プログラムであって、コンピュータによって実行される前記方法が、
前記命令を遠隔メタサービス・プロバイダに提供し、前記遠隔メタサービス・プロバイダが、前記複数のコンポーネントを組み合わせてメタサービスにすることによって、前記機能要件を満たす機能を前記クライアントに提供できるようにする段階を含む、コンピュータ・プログラム。
【請求項１５】
コンピュータによって実行される前記方法が、
前記複数のコンポーネントを再特定することなく将来使用できるように、該複数のコンポーネントを登録する段階を含む、請求項１０乃至請求項１４のいずれかに記載のコンピュータ・プログラム。
【請求項１６】
前記要求がクライアントによってなされる請求項１０に記載のコンピュータ・プログラムであって、コンピュータによって実行される前記方法が、
前記クライアント以外のサービスに利用可能な前記複数のコンポーネントの特定を行う段階を含む、コンピュータ・プログラム。
【請求項１７】
前記要求がクライアントによってなされる請求項１０に記載のコンピュータ・プログラムであって、コンピュータによって実行される前記方法が、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定し、
前記複数の組合わせのうちの一つの組合わせを選択することを前記クライアントに提案する、
段階を含む、コンピュータ・プログラム。
【請求項１８】
前記要求がクライアントによってなされる請求項１０に記載のコンピュータ・プログラムであって、コンピュータによって実行される前記方法が、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定し、
付加的な好みを定めるために前記クライアントに質問し、
前記付加的な好みに基づいて、前記複数の組合わせのうちの少なくとも１つの組合わせを選択し、前記クライアントに提案する、
段階を含む、コンピュータ・プログラム。
【請求項１９】
データ処理システムであって、
機能要件を含む要求を受信するための手段（５０１）と、
ディレクトリ（４０１）に問い合わせて、前記機能要件を満たす単一のコンポーネントが存在するかどうかを判断するための手段（５０２）と、
前記機能要件を満たす単一のコンポーネントが存在しないという判断に応答して、ある組合わせ方法に従って組み合わされた時に該機能要件を満たすであろう複数の機能を特定するための手段（８１６）と、
前記複数の機能を満たす複数のコンポーネントを特定するための手段（８１８）と、
を含む、データ処理システム。
【請求項２０】
前記機能要件がサービスの定義であり、前記システムは、ディレクトリによって問い合わせ可能なサービスの定義のデータベースをさらに含む、請求項１９に記載のデータ処理システム。
【請求項２１】
前記機能要件を達成するために、前記組合わせ方法に従って前記複数のコンポーネントを組み合わせるための命令を導き出すための手段をさらに含む、請求項１９又は請求項２０のいずれかに記載のデータ処理システム。
【請求項２２】
前記要求がクライアントによってなされる請求項２１に記載のデータ処理システムであって、該データ処理システムが、
前記命令を前記クライアントに戻すための手段をさらに含み、
前記クライアントが前記複数のコンポーネントを利用して前記機能要件を達成できるようにする、データ処理システム。
【請求項２３】
前記要求がクライアントによってなされる請求項２１に記載のデータ処理システムであって、該データ処理システムが、
前記命令を遠隔メタサービス・プロバイダに提供し、前記遠隔メタサービス・プロバイダが、前記複数のコンポーネントを組み合わせてメタサービスにすることによって、前記機能要件を満たす機能を前記クライアントに提供できるようにするための手段をさらに含む、データ処理システム。
【請求項２４】
前記複数のコンポーネントを再特定することなく将来使用できるように、該複数のコンポーネントを登録するための手段をさらに含む、請求項１９乃至請求項２３のいずれか１項に記載のデータ処理システム。
【請求項２５】
前記要求がクライアントによってなされる請求項１９に記載のデータ処理システムであって、該データ処理システムが、
前記クライアント以外のサービスに利用可能な前記複数のコンポーネントの特定を行うための手段をさらに含む、データ処理システム。
【請求項２６】
前記要求がクライアントによってなされる請求項１９に記載のデータ処理システムであって、該データ処理システムが、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定するための手段と、
前記複数の組合わせのうちの一つの組合わせを選択することを前記クライアントに提案するための手段と、
をさらに含む、データ処理システム。
【請求項２７】
前記要求がクライアントによってなされる請求項１９に記載のデータ処理システムであって、該データ処理システムが、
前記複数の機能を満たすコンポーネントの複数の組合わせを特定するための手段と、
付加的な好みを定めるために前記クライアントに質問する手段と、
前記付加的な好みに基づいて、前記複数の組合わせのうちの少なくとも１つの組合わせを選択し、前記クライアントに提案するための手段と、
をさらに含む、データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、改善されたデータ処理システムに関し、具体的には、ハードウェア及びソフトウェア・コンポーネントを管理する方法及び装置に関する。さらにより具体的には、本発明は、機能要件を達成するために、コンポーネントを自動的に特定し、組み合わせる方法及び装置を提供する。
【背景技術】
【０００２】
近年のコンピュータ技術が、非常に複雑で絶え間なく変わり続ける環境をもたらした。こうした環境の１つは、「インターネットワーク」とも呼ばれるインターネットである。インターネットは、データ転送と、送信ネットワークのプロトコルから受信ネットワークによって用いられるプロトコルへのメッセージ変換とを処理するゲートウェイによって相互に結合された、異なるものであってよい、コンピュータ・ネットワークの組である。「インターネット」という用語を用いる場合、この用語は、ＴＣＰ／ＩＰプロトコル・スイートを用いるネットワーク及びゲートウェイの集合を指す。現在、インターネット上でデータを転送するのに利用される最も一般的な方法は、単に「ウェブ」とも呼ばれるワールド・ワイド・ウェブ環境を利用するものである。情報を転送するために、ファイル転送プロトコル（ＦＴＰ）及びＧｏｐｈｅｒなどの他のインターネット・リソースが存在するが、これらはウェブほど普及しなかった。ウェブ環境においては、サーバ及びクライアントが、様々なデータ・ファイル（例えば、テキスト、静止グラフィック画像、音声、動画ビデオなど）の転送を処理するための既知のプロトコルであるハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて、データ・トランザクションを行う。様々なデータ・ファイルの情報は、ユーザに提示するために、標準的なページ記述言語であるハイパーテキスト・マークアップ言語（ＨＴＭＬ）によって書式設定される。インターネットはまた、ブラウザを用いてアプリケーションをユーザに転送するのに広く用いられる。多くの場合、ソフトウェア・パッケージのユーザは、ソフトウェア・パッケージをインターネット経由で検索し、取得することができる。
【０００３】
他のタイプの複雑なネットワーク・データ処理システムとして、大企業の仕事を容易にするために作成されるシステムが挙げられる。多くの場合、こうしたネットワークは、世界の様々な場所において地域を越えて広がることになる。こうした複雑なネットワークも、事業を行うための仮想製品ネットワークの一部として、インターネットを用いることができる。ネットワーク内部で用いられるソフトウェアを管理し、更新する必要性により、こうしたネットワークがさらに複雑なものになる。
【０００４】
ソフトウェアが進化し、徐々に「自律型」になるにつれて、ソフトウェアをインストールし、設定するタスクは、管理者が行うのではなく、コンピュータ自身が行うことがさらに多くなる。現在のインストール及び設定機構は、「自律型」プロセスに向かっている。例えば、多くのオペレーティング・システム及びソフトウェア・パッケージは、ユーザ指定の要求に基づいて、特定のソフトウェア・コンポーネントを自動的に参照する。これらのインストール及び更新機構は、多くの場合、予め選択された場所でインターネットに接続し、更新又は必要なコンポーネントが存在するかどうかを確かめる。更新又は他のコンポーネントが存在する場合には、メッセージがユーザに示され、コンポーネントをダウンロードし、インストールするかどうかをユーザに尋ねる。こうしたシステムの例には、オープンソースのＤｅｂｉａｎ  ＧＮＵ／Ｌｉｎｕｘオペレーティング・システムの一部である、パッケージ管理プログラム「ｄｓｅｌｅｃｔ」が含まれる。
【０００５】
「自律型」計算に向かう次のブロックは、ユーザの介入を必要とせずに、必要なソフトウェア及びハードウェア・コンポーネントを特定し、インストール／ダウンロードする段階を含む。こうした次世代システムにおいては、自律型設定ユーティリティが、特定の機能の必要性の検出に応答してコンポーネントをインストールする。こうした状況では、必要な機能を提供する単一のハードウェア又はソフトウェア・コンポーネントがあるわけではない。したがって、単一のコンポーネントがない場合に必要な機能を獲得し、必要な機能を提供することができるスキームがあることが望ましい。
【０００６】
【非特許文献１】Ｅｌｍａｓｒｉ及びＮａｖａｔｈｅ、Ｆｕｎｄａｍｅｎｔａｌｓ  ｏｆ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍｓ、第３版、Ａｄｄｉｓｏｎ  Ｗｅｓｌｅｙ、２０００年、ｐｐ．４１−６６
【発明の開示】
【０００７】
したがって、本発明は、機能要件を含む要求を受信し、ディレクトリに問い合わせて該機能要件を満たす単一のコンポーネントが存在するかどうかを判断し、該機能要件を満たす単一のコンポーネントが存在しないという判断に応答して、ある組合わせ方法に従って組み合わされた時に該機能要件を満たすであろう複数の機能を特定し、該複数の機能を満たす複数のコンポーネントを特定する段階を含む、ハードウェア及びソフトウェア・コンポーネントについての情報を格納するための、コンピュータによって実施する方法を提供するものである。
【０００８】
この方法を実行するための命令を含むコンピュータ・プログラム、該プロセスを実施するためのデータ処理システムも提供される。
【０００９】
したがって、本発明は、他のハードウェア及びソフトウェア・コンポーネントが、ディレクトリ内に列挙されたコンポーネントを見つけ、利用するために必要とする情報を格納するだけでなく、クライアントの機能要件を満たす「メタサービス」を動的に構成することも可能にする、改善されたディレクトリを提供するものである。
【００１０】
特定の機能要件についてのクライアントからの要求に応答して、ディレクトリ・サービスは、１組のハードウェア・コンポーネント及び／又はソフトウェア・コンポーネントを決定し、必要とされる機能を提供する。次に、その組の中のコンポーネントを組み合わせ、ドメイン知識による論理演繹を介して必要な機能を達成するように構成する。履歴機構は、既に得られたハードウェア又はソフトウェア・コンポーネントを即座に再呼び出しすることを可能にする。
【００１１】
本発明の特質であると考えられる新規な特徴は、添付の特許請求の範囲に記述される。しかしながら、発明自体並びにその好ましい使用形態、さらなる目的、及び利点は、添付図面と共に読んだときに、以下の例示的な実施形態の詳細な説明を参照して、最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１２】
ここで図面を参照すると、図１は、本発明を実装することができるデータ処理システムのネットワークの図形表示を示す。ネットワーク・データ処理システム１００は、本発明を実装することができるコンピュータのネットワークである。ネットワーク・データ処理システム１００は、該ネットワーク・データ処理システム１００内で相互に接続される様々な装置及びコンピュータ間の通信リンクを提供するのに用いられる媒体であるネットワーク１０２を含む。ネットワーク１０２は、ワイヤ、ワイヤレス通信リンク、又は光ファイバ・ケーブルなどの接続を含むことができる。
【００１３】
図示された例においては、サーバ１０４が、ストレージ・ユニット１０６と共に、ネットワーク１０２に接続される。さらに、クライアント１０８、１１０、及び１１２が、ネットワーク１０２に接続される。これらのクライアント１０８、１１０、及び１１２は、例えばパーソナル・コンピュータ又はネットワーク・コンピュータとすることができる。図示された例においては、サーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、及びアプリケーションなどのデータをクライアント１０８、１１０、及び１１２に提供する。クライアント１０８、１１０、及び１１２は、サーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、付加的なサーバ、クライアント、及び図示されない他の装置を含んでもよい。図示された例においては、ネットワーク・データ処理システム１００は、Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）プロトコル・スイートを用いて相互に通信を行うネットワーク及びゲートウェイの世界的な集合を表すネットワーク１０２を持つインターネットである。インターネットの中心には、データ及びメッセージ送付する何千もの商用コンピュータ・システム、政府系コンピュータ・システム、教育用コンピュータ・システム、その他のコンピュータ・システムで構成されるメジャー・ノード又はホスト・コンピュータ間の高速データ通信線のバックボーンがある。当然のことながら、ネットワーク・データ処理システム１００は、例えばインターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、又は広域ネットワーク（ＷＡＮ）などの、多数の異なるタイプのネットワークとして実装することもできる。図１は、一例を表すものであり、本発明についてのアーキテクチャ面の制限として意図されるものではない。
【００１４】
図２を参照すると、本発明の好ましい実施形態に従って、図１のサーバ１０４などのサーバとして実装することができるデータ処理システムのブロック・ダイアグラムが示される。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２及び２０４を含む対称型マルチプロセッサ・システム（ＳＭＰ）とすることができる。代替的に、シングル・プロセッサ・システムを使用することもできる。システム・バス２０６には、ローカル・メモリ２０９とのインターフェースになるメモリ・コントローラ／キャッシュ２０８も接続される。Ｉ／Ｏバス・ブリッジ２１０が、システム・バス２０６に接続され、Ｉ／Ｏバス２１２とのインターフェースになる。メモリ・コントローラ／キャッシュ２０８及びＩ／Ｏバス・ブリッジ２１０は、図示されるように一体化することができる。
【００１５】
Ｉ／Ｏバス２１２に接続されたペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バス・ブリッジ２１４が、ＰＣＩローカル・バス２１６とのインターフェースになる。ＰＣＩローカル・バス２１６には、多数のモデムを接続することができる。典型的なＰＣＩバス実装は、４つのＰＣＩ拡張スロット又はアドイン・コネクタをサポートするものである。図１のクライアント１０８、１１０、及び１１２との通信リンクは、アドイン・ボードを介してＰＣＩローカル・バス２１６に接続されたモデム２１８及びネットワーク・アダプタ２２０によって構成することができる。
【００１６】
付加的なＰＣＩバス・ブリッジ２２２及び２２４が、付加的なモデム又はネットワーク・アダプタをサポートすることができる付加的なＰＣＩローカル・バス２２６及び２２８のためのインターフェースになる。このようにして、データ処理システム２００は、多数のネットワーク・コンピュータとの接続が可能になる。図示されるように、メモリ・マップ・グラフィクス・アダプタ２３０及びハード・ディスク２３２も、直接的に又は間接的に、Ｉ／Ｏバス２１２に接続することができる。
【００１７】
当業者であれば、図２に示されたハードウェアは変更できることを理解するであろう。例えば、図示されたハードウェアに加えて、又はそれらに代えて、光ディスク・ドライブなどといった他の周辺装置を用いることもできる。図示された例は、本発明についてのアーキテクチャ面での制限を意味することを意図するものではない。
【００１８】
図２に示されたデータ処理システムは、例えば、拡張対話式エグゼクティブ（ＡＩＸ）オペレーティング・システム又はＬＩＮＵＸオペレーティング・システムによって作動する、ニューヨーク州アーモンクのＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎの製品であるＩＢＭ  ｅＳｅｒｖｅｒ  ｐＳｅｒｉｅｓシステムとすることができる。
【００１９】
ここで図３を参照すると、本発明を実装することができるデータ処理システムを説明するブロック・ダイアグラムが示される。データ処理システム３００は、クライアント・コンピュータの例である。データ処理システム３００は、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）ローカル・バス・アーキテクチャを利用する。図示された例はＰＣＩバスを利用するものであるが、Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ（ＡＧＰ）及びＩｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）などの他のバス・アーキテクチャを用いることもできる。プロセッサ３０２及びメイン・メモリ３０４が、ＰＣＩブリッジ３０８を介してＰＣＩローカル・バス３０６に接続される。ＰＣＩブリッジ３０８は、プロセッサ３０２のための一体型のメモリ・コントローラ及びキャッシュ・メモリを含むこともできる。コンポーネントの直接相互接続によって、又はアドイン・ボードを介して、ＰＣＩローカル・バス３０６との付加的な接続が行われる。図示された例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホスト・バス・アダプタ３１２、及び拡張バス・インターフェース３１４が、コンポーネントの直接接続によってＰＣＩローカル・バス３０６に接続される。拡張バス・インターフェース３１４は、キーボード及びマウス・アダプタ３２０、モデム３２２、及び追加メモリ３２４の接続を提供する。小型コンピュータ・システム・インターフェース（ＳＣＳＩ）ホスト・バス・アダプタ３１２は、ハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、及びＣＤ−ＲＯＭドライブ３３０の接続を提供する。典型的なＰＣＩローカル・バス実装は、３つ又は４つのＰＣＩ拡張スロット又はアドイン・コネクタをサポートするものである。
【００２０】
オペレーティング・システムが、プロセッサ３０２上で作動し、図３のデータ処理システム３００内部の様々なコンポーネントの制御を調整及び提供するのに用いられる。オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ（Ｒ）ＸＰなどの市販のオペレーティング・システムとすることができる。Ｊａｖａのようなオブジェクト指向プログラミング・システムを、オペレーティング・システムと共に作動させて、データ処理システム３００上で実行しているＪａｖａプログラム又はアプリケーションからオペレーティング・システムを呼び出すことができる。「Ｊａｖａ」は、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の登録商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、及び、アプリケーション又はプログラムのための命令は、ハード・ディスク・ドライブ３２６のようなストレージ・デバイス上に置かれ、プロセッサ３０２による実行のためにメイン・メモリ３０４に読み込むことができる。
【００２１】
当業者であれば、図３のハードウェアは、実装形態に応じて変更できることを理解するであろう。図３に示されたハードウェアに加えて、又はそれらに代えて、フラッシュ読み取り専用メモリ（ＲＯＭ）、同様の不揮発性メモリ、及び光ディスク・ドライブなどといった他の内蔵ハードウェア又は周辺装置を用いることもできる。また、本発明のプロセスは、マルチプロセッサ・データ処理システムに応用することができる。
【００２２】
別の例として、データ処理システム３００は、何らかのタイプのネットワーク通信インターフェースに依存せずに、ブート可能になるように構成された独立型システムとすることができる。更に別の例として、データ処理システム３００は、オペレーティング・システム・ファイル及び／又はユーザ生成データを格納するための非揮発性メモリを備えるために、ＲＯＭ及び／又はフラッシュＲＯＭを有するように構成された携帯情報端末（ＰＤＡ）装置とすることができる。
【００２３】
図３に示された例及び上述の例は、アーキテクチャ面での制限を意味することを意図するものではない。例えば、データ処理システム３００は、ＰＤＡの形態をとることに加えて、ノートブック・コンピュータ又はハンドヘルド・コンピュータとすることもできる。データ処理システム３００は、キオスク又はＷｅｂアプライアンスとすることもできる。
【００２４】
本発明は、ハードウェア及びソフトウェア・コンポーネントについての情報を格納するための改善されたディレクトリ・サービスに向けられる。本文書全体を通して、「サービス」という用語は、ハードウェア・コンポーネント及びソフトウェア・コンポーネントの両方を説明するために用いられる。自律計算パラダイムにおいては、機能要件に従って、サービスを動的に入手し、組み合わせる（バインドする）ことができる。このように、自律計算において、現在の機能要件のためだけにシステム・コンポーネントを配置するという事実を強調するために、自律計算環境におけるハードウェア及びソフトウェア・コンポーネントを「サービス」と呼ぶ。したがって、自律計算システムは、一定かつ不変の組のコンポーネントから構築時に静的に構成されるものではなく、寧ろ、要求に応じて利用可能な「サービス」を動的に利用するというものである。
【００２５】
自律計算システムに必要とされる機能は、単一のサービスだけで提供することはできない。こうした場合には、多数のサービスを互いに組み合わせることによって、必要とされる機能を達成することができる。したがって、本発明によって提供されるディレクトリ・サービスは、他のコンポーネントが、ディレクトリ内に列挙されたサービスを見つけ、利用するために必要とする情報を格納するだけでなく、クライアントの要求を満たす「メタサービス」を動的に構成することもできる。
【００２６】
例えば、クライアントが、ディレクトリ内で利用できない特定のタイプのサービスについての詳細（これらに限られるものではないが、そのサービスの場所又は特定を含む）を提供することを該ディレクトリに求める場合、単純なディレクトリ・サービスであれば、そのようなサービスが利用可能でないことを応答するだけである。しかしながら、改善されたディレクトリ・サービスは、予めプログラムされた知識又はオン・ザ・フライ式演繹法のいずれかに基づいて、ディレクトリ内で利用可能なコンポーネントを組み合わせ得る機構を導き出し（或いは、別のソフトウェア・エンティティを導き出し）、要求中のクライアントが最初に求めたサービスと同様の機能を獲得する能力を有する。
【００２７】
例えば、要求中のサービス（例えば、ソフトウェア・コンポーネント）が、１ＰＢ（ペタバイト）の直接アクセス記憶空間を提供できる利用可能なサービスについての情報を、ディレクトリに求めるという状況を考える。ディレクトリがこうしたサービスについての情報を含まないものの、各々が１００ＴＢ（テラバイト）の直接アクセス記憶空間を提供できる１０個のサービスについての情報を含む場合には、ディレクトリ・サービスは、要求中のサービスが、該１０個のサービスを組み合わせれば、最初に要求されたサービスと同様のサービスを獲得できることを示す応答を、該要求中のサービスに戻すことができる。
【００２８】
図４は、本発明の好ましい実施形態によるディレクトリ及び構成サービスの全体図を示すダイアグラムである。要求中のサービス４００は、それ自体がサービス（ハードウェア又はソフトウェア・コンポーネント）であるディレクトリ・サービス４０１から、特定の機能要件に対処するサービスに要求する。ディレクトリ・サービス４０１は、利用可能なサービス・データベース４０６を調べて、必要な機能を提供するサービス（ハードウェア又はソフトウェア・コンポーネント）を見つける。こうした単一のサービスが利用可能でない場合には、ディレクトリ・サービス４０１は、構成サービス４０２（同じくハードウェア又はソフトウェア・コンポーネントである）を用いて、個々のサービスを組み合わせて「メタサービス」にし、必要な機能を提供することができる。
【００２９】
好ましい実施形態において、ディレクトリ・サービス４０１は、Ｗｅｂサービス記述言語（ＷＳＤＬ）のような標準化されたサービス・スキーム、及びＵｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，及びＩｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）のようなシステムを用いて、ディレクトリ・サービスを提供することができ、このことにより、プログラムが、特定のサービスを提供するエンティティを見つけ、これらのサービスを用いて、どのように通信し、トランザクションを行うかを自動的に定めることが可能になる。ＷＳＤＬは、Ｉｎｔｅｒｎａｔｉｏｎｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ，Ａｒｉｂａ，Ｉｎｃ．及びＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎのような企業の代表者によって作成されたワールドワイド・ウェブ・コンソーシアムにより作成された規格案である。ＵＤＤＩバージョン３が、Ｗｅｂサービス・アプリケーション及びサービスのために用いられる最新の仕様である。ＵＤＤＩについての将来の発展及び変更は、Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ａｄｖａｎｃｅｍｅｎｔ  ｏｆ  Ｓｔｒｕｃｔｕｒｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｔａｎｄａｒｄ（ＯＡＳＩＳ）によって取り扱われる。
【００３０】
構成サービス４０２は、最初に、前に得られたサービスの組合わせ結果を格納する履歴データベース４０５を介して、要求を満たそうとする。適用できる前に得られた組合わせが利用可能でない場合には、構成論理４０３を用いて、要求の機能要件を満たす利用可能なサービスの新しい組合わせを引き出す。好ましい実施形態においては、構成論理４０３は、組合わせヒント４０４からの、コンポーネントの組合わせ能力に関する利用可能なサービスのデータベース４０６内のコンポーネントについての情報を利用するソフトウェアであり、要求中のサービス４００の元の要求の機能要件を満たすコンポーネントの組合わせを導き出す。
【００３１】
図５は、本発明の好ましい実施形態による、サービスに対する要求を満たすためのプロセスのフローチャート図である。図５は、２つの部分に分けられる。ディレクトリ・サービス部分５００は、個々のサービスの特定及び配置（例えば、図４のディレクトリ・サービス４０１によって）を含むブロックを含み、構成サービス部分５１２は、個々のサービスを組み合わせてメタサービスを形成するブロックを含む。当業者であれば、このブロックの分割が、異なるソフトウェア・プロセスと一致してもよく（例えば、ディレクトリ・サービス部分５００内のブロックは、１つのソフトウェア・プロセスによって実行されるが、構成サービス５１２内のブロックは、異なるソフトウェア・プロセスによって実行される）、或いは一致しなくてもよい（例えば、１つのプロセスが全てのブロックを実行するか、又は多数のプロセスが異なるグループのブロックを実行する）ことを理解するであろう。図５では、（例えば、プロセス、スレッド、機能、サブルーチンのような）２つの別箇の組織単位のソフトウェア（すなわち、ディレクトリ・サービス４０１及び構成サービス４０２）が用いられるが、上述のように、実際にはこうした分割は必要でないと考えられる。
【００３２】
ここで図５によって示されるプロセスの流れを参照すると、このプロセスは、クライアントから受信した要求で始まる（すなわち、サービス又はコンポーネントが付加的な機能を要求する）（ブロック５０１）。次に、利用可能なサービス（すなわち、利用可能なサービス・データベース４０６）によって要求に対処できるかどうかに関して判断を行う（ブロック５０２）。要求に対処できる（ブロック５０２がイエスである）場合には、適切なサービスの使用法に関する命令を提供する適切な応答が、利用可能なサービス・データベース４０６から取り出される（ブロック５０３）。次に、この応答は、クライアントに戻され、該クライアントが選択されたサービスを利用することが可能になる（ブロック５０４）。
【００３３】
利用可能なサービスによって要求に対処できない（ブロック５０２がノーである）場合には、該要求は、構成サービス４０２に送信される（ブロック５０５）。構成サービス４０２は、要求を受信し（ブロック５０６）、履歴データベース４０５によって該要求を満たすことができるかどうかを判断する（ブロック５０７）。要求を満たすことができる（ブロック５０７がイエスである）場合には、履歴データベース４０５からの応答が戻される（ブロック５０９）。要求を満たすことができない（ブロック５０７がノーである）場合には、構成論理４０３を用いて、必要な機能を提供する組合わせを導き出す（ブロック５１０）。この新しい組合わせは、履歴データベース４０５に入力され（ブロック５０８）、応答が戻される（ブロック５０９）。次に、ディレクトリ・サービス４０１は、構成サービス４０２の応答を受信し（ブロック５１１）、該応答をクライアントに戻す（ブロック５０４）。
【００３４】
図４及び図５から分かるように、要求に応答してサービスを特定及び組み合わせる段階のタスクは、１つ又はそれ以上のデータベースからデータを取り出す段階と、該データに論理（例えば、構成論理４０３）を適用して適切な応答を導き出す段階とを含む。図６及び図７は、本発明の好ましい実施形態において、ディレクトリ、組合わせ、及び履歴情報を格納するために用い得る１つの可能なデータベース・スキーマについて説明する。当業者であれば、本発明の範囲及び精神から逸脱することなく、ここに説明されるスキーマの多くの変形物及び代替物を適用することもできることを理解するであろう。以下の図に示されるデータベース・スキーマは、例証のためだけに含まれるものである。
【００３５】
データベース・モデル化へのＥ・Ｒ（エンティティ・リレーションシップ）手法は、データベースの概念設計のためのセマンティクスを提供するものである。Ｅ・Ｒ手法を用いる場合、データベース情報は、エンティティ、エンティティの属性、及びエンティティ間のリレーションシップに関して示され、そこでは、以下の定義を適用する。各々の定義に対応するモデル化セマンティクスが、図６に示される。図６は、Ｅ・Ｒダイアグラムに関する付加的な材料を含み、引用によりここに組み入れられる、非特許文献１から採られたものである。
【００３６】
エンティティ：エンティティは、情報が収集される主オブジェクトである。例えば、会社の個人についての情報を含むデータベースにおいて、エンティティは、「従業員」である。Ｅ・Ｒモデル化において、エンティティは、ボックスで表される。エンティティは、別のエンティティへの依存性に関して、弱いエンティティ又は強いエンティティと呼ぶことができる。強いエンティティは、別のエンティティへの依存性を示さず、すなわち、その存在が別のエンティティの存在を必要としない。図６に示されるように、強いエンティティは、斜線が施されていない単一のボックスで表される。弱いエンティティは、その存在が別のエンティティに由来するものである。例えば、エンティティ「勤務時間予定」は、その存在がエンティティ「従業員」に由来しており、これが従業員に関連している場合にだけ存在することができる。図６に示されるように、弱いエンティティは、同心のボックスで表される。
【００３７】
属性：属性は、エンティティに記述的特性を与えるラベルである（例えば、名前、色など）。２つのタイプの属性がある。主要属性は、エンティティの出現を見分けるものである。例えば、米国において、社会保障番号は、個人を見分ける主要属性である。記述子属性は、エンティティの出現を説明するものに過ぎない（例えば、性別、体重など）。図６に示されるように、Ｅ・Ｒモデル化において、属性は、属するエンティティ（ボックス）につながれた楕円で表される。
【００３８】
場合によっては、属性は多数の値を持つことができる。例えば、企業を表すエンティティは、多値属性の「位置」を有することができる。企業が多数の位置を有する場合には、属性「場所」は、多数の値を有する。図６に示されるように、多値属性は、同心の楕円で表される。
【００３９】
リレーションシップ：リレーションシップは、エンティティの出現の間に示される接続性である。リレーションシップは、１対１、１対多数、及び多数対多数とすることができ、エンティティによるリレーションシップへ参加は、任意のものであっても、必須のものであってもよい。例えば、会社の個人についての情報を含むデータベースにおいて、従業員エンティティの出現の中のリレーションシップ「結婚している」は、（従業員がせいぜい１人の配偶者をもっていると示される場合には）１対１である。さらに、結婚していない従業員もいるので、リレーションシップへの参加は、任意のものである。第２の例として、会社の規則により、全ての従業員が厳密に１人の管理者を持つと規定される場合は、従業員エンティティ出現の中のリレーションシップ「管理される」は、多数対１であり（多くの従業員が同じ管理者を持つことができる）、必須のものである（あらゆる従業員が１人の管理者を持たねばならない）。
【００４０】
図６に示されるように、Ｅ・Ｒモデル化において、リレーションシップは、それが１つ又はそれ以上のエンティティにリレーションシップする場合にひし形で表され、２つより多いエンティティにリレーションシップする場合にはｎ辺の多角形で表される。図６に示されるように、リレーションシップ内のカーディナリティ比（１対１、１対多など）は、１：１又は１：Ｎのカーディナリティ比を示すのに文字「１」及び「Ｎ」を用いて、或いは明確な構造的制約を用いて示される。図６に示されるように、エンティティの全てのインスタンスがリレーションシップに参加する時には、エンティティ・ボックスは、二重線によってリレーションシップひし形に接続され、他の場合には、単一の線が、リレーションシップを有するエンティティに接続する。
【００４１】
図７は、本発明の好ましい実施形態に用いることができる例示的なデータベース・スキーマのエンティティ・リレーションシップ（Ｅ・Ｒ）ダイアグラムである。図７に示されるスキーマは、図４に示されるアーキテクチャに従った部分、すなわちディレクトリ・サービス部分７００、履歴データベース部分７０２、及び組合わせヒント部分７０４に分けられる。当業者であれば、こうした分割が単に概念的なものにすぎず、異なる部分における情報を互いから物理的に分離することを義務付けることを意図するものではないことを理解するであろう。
【００４２】
図７の「基本」エンティティは、基本的な「アトミック」サービスを表し、他のコンポーネント（サービス）の構成ではない個々のコンポーネント（サービス）を意味する、コンポーネント・エンティティ７０６である。各々のコンポーネントは、多値属性「要求」７０８で表される、特定の最小ハードウェア要求又は他のサービスへの依存といった多数の要求を有することができる。
【００４３】
３進リレーションシップ「ｐｒｏｖｉｄｅｓ１」７１０は、特定の使用法（７１２）のもとで、各々のコンポーネント（７０６）を１つ又はそれ以上の基本機能（７１４）と関連付けるものである。３進リレーションシップ「ｐｒｏｖｉｄｅｓ１」７１０は、特定の方法（７１２）で用いられた時に、特定のコンポーネント（７０６）が、１つ又はそれ以上の基本機能（７１４）を提供することを示す。
【００４４】
３進リレーションシップ「ｓｙｎｔｈｅｓｉｚｅ」７１６は、１つ又はそれ以上の基本機能（７１４）を、組合わせ方法（組合わせ方法エンティティ７１８）及び対応する派生機能（派生機能エンティティ７２０）と関連付けるものである。３進リレーションシップ「ｓｙｎｔｈｅｓｉｚｅ」７１６は、特定の方法（７１８）で１つ又はそれ以上の基本機能（７１４）を組み合わせて、派生機能（７２０）を達成できることを示す。例えば、グラフィック・ファイルを「ＢＭＰ」（ビットマップ）ファイルから「ＴＩＦＦ」（ｔａｇｇｅｄ  ｉｍａｇｅ  ｆｉｌｅ  ｆｏｒｍａｔ）ファイルに変換するのは、基本機能であり、ＴＩＦＦファイルを「ＧＩＦ」（ｇｒａｐｈｉｃｓ  ｉｎｔｅｒｃｈａｎｇｅ  ｆｏｒｍａｔ）に変換するのは、更に別の基本機能である。次に、ＢＭＰからＧＩＦ形式への変換は、ＢＭＰ・ＴＩＦＦ変換サービスからＴＩＦＦ・ＧＩＦ変換サービスに出力を与える組合わせ方法を適用することによって達成可能な派生機能である。図７において、３進リレーションシップ「ｓｙｎｔｈｅｓｉｚｅ」７１６が、コンポーネントではなく、機能を関連付ける点に注目すべきである。例えば、３進リレーションシップ「ｓｙｎｔｈｅｓｉｚｅ」７１６は、何らかのＢＭＰ・ＴＩＦＦ変換サービスを何らかのＴＩＦＦ・ＧＩＦ変換サービスと組み合わせて、ＢＭＰ・ＧＩＦ変換メタサービスを生成することを示しており、３進リレーションシップ「ｓｙｎｔｈｅｓｉｚｅ」７１６において、どの特定のＢＭＰ・ＴＩＦＦ変換サービスを用いるべきかについては示していない。
【００４５】
「組合わせ可能」リレーションシップ７２２は、組合わせ方法（７１８）を１つ又はそれ以上のコンポーネント（７０６）と関連付ける。「組合わせ可能」リレーションシップ７２２は、特定の組合わせ方法（７１８）に従って、特定のグループのコンポーネントを組み合わせできることを示す。したがって、前述のグラフィック・ファイル・フォーマット変換の場合には、「組合わせ可能」リレーションシップ７２２は、一方の出力を他方の入力に与えることによって、２つの特定の変換サービスを組み合わせできるという表示を格納する。したがって、特定の機能を基本機能から導き出さねばならない場合には、特定のグループのコンポーネントを必要な方法で組み合わせ、所望の派生機能を達成できることを保証するために、「組合わせ可能」リレーションシップ７２２に照会する。
【００４６】
１組の基本機能（７１４）を派生機能（７２０）に組み合わせるコンポーネント（７０６）の組合わせは、リレーションシップ７２２、７２８、及び７３０を介してエンティティ７０６、７１４、及び７２０に関連付けられた「組合わせ」エンティティ７２４によって表される組合わせである。「組合わせ」エンティティ７２４の「組合わせスキーム」属性７２６は、組合わせを形成又は使用するための情報を表す。組合わせエンティティ７２４は、既に得られた組合わせを格納するための履歴機構を提供する。「組合わせスキーム」属性７２６は、（例えば「組合わせ方法」エンティティ７１８からの）組合わせ方法情報、又は（個々のコンポーネント又は個々のコンポーネントからのコードを組み込む、組み合わされたソフトウェア・コンポーネントのコピーから組合わせを形成するための命令といった）組合わせを使用又は形成するための何らかの他の関連情報を含むことができる。
【００４７】
リレーショナル、オブジェクト指向、オブジェクト・リレーショナル、又は演繹的データベース管理システムのようなデータベース管理システムを用いて、図７に説明されたスキーマのようなデータベース・スキーマを実装することができる。当該技術分野において利用可能なような、他のデータ・ストレージ・パラダイムも、本発明の好ましい実施形態の範囲内で実行可能である。
【００４８】
本発明の好ましい実施形態によると、図７に示されるようなデータベース・スキーマが、（例えば、図４のディレクトリ・サービス４０１、構成サービス４０２、及び構成論理４０３によって提供されるような）制御論理と組み合わされ、機能要件を満たす際に利用可能なサービスを選択し、及び／又は組み合わせることが可能になる。図８は、本発明の実施形態に用いることができる制御論理の、フローチャート形態の１つの可能な実施形態である。図８に説明された制御論理は、図７のデータベース・スキーマに基づいており、図４に関して説明されたようなディレクトリ・サービス４０１、構成サービス４０２、及び構成論理４０３の機能を組み合わせる。図４と関連して述べられたように、本発明は、ディレクトリ・サービス４０１、構成サービス４０２、及び構成論理４０３の厳格な分離を要求していない。図７のデータベース・スキーマと同様に、図８に示されるプロセスは、制御論理がどのように機能するかの例となることを意図するに過ぎず、限定となることを意図するものではない。
【００４９】
図８に示されるプロセスは、特定の機能要件と関連したコンポーネント及び制約を見つけるために、サブルーチンを呼び出す段階で始まる（ブロック８００）。ブロック８００において呼び出されたサブルーチンは、特定された各々の機能要件を満たす際にコンポーネントを見つける及び／又は組み合わせるための再帰的サブルーチンである。コンポーネントが各々の機能要件のための解決方法に組み込まれているので、残りの要求を満たす際に付加的なコンポーネント及び／又は組合わせを組み込むように、サブルーチンが再帰的に呼び出される。サブルーチンが最初に呼び出された時には、これまでの解決方法におけるコンポーネント及び制約を表す、機能要件の完全なリスト及び２つの空のリストを、パラメータとしてサブルーチンに送信することができる。サブルーチンが繰返し再帰的に呼び出されるので、コンポーネント及び制約が、これまでの解決方法を表す２つのリストに加えられ、これまでの解決方法によって満たされた機能要件が機能要件のリストから取り除かれる。
【００５０】
サブルーチンが呼び出されるたびに、対処すべき何らかの機能要件が残っているかどうかについての判断が行われる（ブロック８０２）。付加的な機能要件が残っていない（ブロック８０２がノーである）場合には、これまでの解決方法を結果として戻すべきである（ブロック８０４）。
【００５１】
何らかの機能要件が残っている（ブロック８０２がイエスである）場合には、これまでの解決方法に含めるために、何らかのコンポーネントが選択されたかどうかについての判断が行われる（ブロック８０６）。何らかのコンポーネントが選択された（ブロック８０６がイエスである）場合には、次に、解決方法に含ませるために、既に選択されたコンポーネントによって残りの要求のいずれかに対処できるかどうかについての判断が行われる（ブロック８０８）。残りの要求のいずれにも対処できない（ブロック８０８がノーである）場合には、プロセスはブロック８１２に続く。
【００５２】
既に選択されたコンポーネントによって対処される要求がある（ブロック８０８がイエスである）場合には、次に、使用法情報（すなわち、所望の機能を達成するために当該コンポーネントをどのように用いるかについて、クライアントに指示する情報）が、これまでの解決方法の制約リストに加えられる（ブロック８１０）。次に、何らかの残りの機能要件に対処するために、再帰的呼び出しが行われる（ブロック８１１）。
【００５３】
ブロック８１２において、まだ選択され、これまでの解決方法に含ませていない単一のコンポーネントによって対処できる要求があるかどうかについての判断が行われる。単一のコンポーネントによって対処できる要求がある（ブロック８０２がイエスである）場合には、コンポーネントは、これまでの解決方法のコンポーネントのリストに加えられ（ブロック８１４）、そのコンポーネントについての使用法情報が、これまでの解決方法に加えられ（ブロック８１０）、何らかの残りの機能要件を処理するために、サブルーチンが再帰的に呼び出される（ブロック８１１）。
【００５４】
単一のコンポーネントによっていずれの機能要件も満たすことができない（ブロック８１２がノーである）場合には、機能の組合わせを用いて機能要件に対処できるかどうかについての判断が行われる（ブロック８１６）。機能の組合わせを用いて機能要件に対処できる（ブロック８１６がイエスである）場合には、サブルーチンが再帰的に呼び出され、必要な派生機能要件を達成するのに必要とされる機能要件に対処する１組のコンポーネントを見つける（ブロック８１８）。次に、サブルーチンによって戻されたコンポーネントを、必要な方法で組み合わせることができるかどうかを確かめるために、再帰的サブルーチンの呼び出しの結果を調べる（ブロック８１９）。組み合わせることができる（ブロック８１９がイエスである）場合には、コンポーネントがこれまでの解決方法に加えられ（ブロック８１４）、そのコンポーネントをどのように組み合わせ、使用するかを特定する使用法情報が、これまでの解決方法に加えられ（ブロック８１０）、残りの機能要件に対処するために、サブルーチンが再帰的に呼び出される（ブロック８１１）。
【００５５】
解決方法がサブルーチンによって戻されると、得られた組合わせは、履歴データベースに格納される（ブロック８２０）。当業者であれば、従来のデータベース記憶技術を用いて、又は表記入された論理プログラミング又はＰｒｏｌｏｇのような自己修飾コードをサポートする言語のプログラム論理を修正することによって、或いは他の適切な手段によって、単一のデータベース表示だけに制限されずに、履歴データベースを実装することができることを理解するであろう。
【００５６】
図４乃至図８に示される好ましい実施形態は、ディレクトリ・サービス又は組み合わされたディレクトリ及び構成サービスが、命令又は他の情報を含む応答を戻し、クライアントが、サービス（コンポーネント）を組み合わせて使用できるようにすることを想定するが、他の多数のアーキテクチャ構成も可能である。図９は、遠隔メタサービス・プロバイダ９１２を用いる本発明の実施形態を示す。遠隔メタサービス・プロバイダ９１２により、実際のサービスの組合わせがクライアント９００によって遠方から行われることが可能になる。具体的には、クライアント９００は、サービスの組合わせが、構成サービス９０８に対して必要な中継要求９０６であるかどうかについての要求９０２を、ディレクトリ・サービス９０４に出す。次に、構成サービス９０８は、組合わせ命令９１０を遠隔メタサービス・プロバイダ９１２に送信する。次に、ディレクトリ・サービス９０４は、クライアント９００に応答し（９１４、図示せず）、要求された機能を提供するのに遠隔メタサービス・プロバイダ９１２が今や利用可能であることを、クライアント９００に知らせる。次に、クライアント９００は、遠隔メタサービス・プロバイダ９１２が要求された機能を提供する個々のサービスであるかのように、該遠隔メタサービス・プロバイダ９１２を用いることができる。しかしながら、実際には、遠隔メタサービス・プロバイダ９１２は、組合わせ命令９１０に従って「メタサービス」を構成する、サービスの組合わせのインターフェースとして働く。
【００５７】
図１０は、遠隔メタサービス・プロバイダが、派生組合わせのために用いられる構成サービス内に組み込まれた、本発明の更に別のアーキテクチャ面での変形を示す。クライアント１０００は、サービスの組合わせが構成サービス１００８に対して必要な中継要求１００６であり、図９の遠隔メタサービス・プロバイダのように派生メタサービスをクライアント１０００に提供するかどうかの要求１００２をディレクトリ・サービス１００４に出す。次に、ディレクトリ・サービス１００４は、クライアント１０００に応答し（１０１０、図示せず）、要求された機能を提供するために構成サービス１００８が今や利用可能であることをクライアント１０００に知らせる。図１０のアーキテクチャ面での変形は、ディレクトリ・サービス１００４が、構成サービス１００８ではなく、派生メタサービスを提供するためのものである。
【００５８】
本発明の付加的な変形が可能である。例えば、組合わせを得るプロセスを、分散方法で行うことができ、多数の解決方法が、同時に作動する複数の構成サービスから戻され、戻された解決方法から最良の解決方法が選択される。別の変形は、２つ又はそれ以上の可能な組合わせを、場合によっては選択基準として用いられることになる付加的な情報と共に要求クライアントに与え、該クライアントが、呈示された可能な組合わせの１つを選択することを可能にする。多数の解決方法をサポートできる別の方法は、構成サービス（又はディレクトリ・サービス）が、複数の候補から導き出された組合わせを選択する助けになる好みをクライアントに質問し、該構成サービス（又はディレクトリ・サービス）が、該クライアントの好みに最も適合する１つ又はそれ以上の解決方法を提供できるようにすることである。例えば、速度又は信頼性のいずれに大きな関心があるかをクライアントに尋ね、クライアントのニーズに従って速度／信頼性のトレードオフを処理する解決方法を与えることができる。
【００５９】
本発明は完全に機能するデータ処理システムに即して説明されたが、当業者であれば、本発明の処理の命令を、コンピュータ読取可能媒体又は他の機能記述材料の形態で、及び様々な形態で配布することが可能であり、本発明は、実際に配布を行うのに用いられる信号支持媒体の具体的な種類にかかわらず等しく利用されると理解するであろうということに留意することが重要である。コンピュータ読取可能媒体の例として、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの書き込み可能タイプの媒体、並びに、例えば無線通信及び光通信などの通信形態を用いる、デジタル及びアナログ通信リンク、有線又は無線通信リンクといった通信タイプの媒体が挙げられる。コンピュータ読取可能媒体は、特定のデータ処理システムで実際に用いるためにデコードされるコード化フォーマットの形式をとることができる。機能記述材料は、機械に機能を与える情報である。機能記述材料には、これらに限られるものではないが、コンピュータ・プログラム、命令、ルール、事実、計算可能な機能の定義、オブジェクト、及びデータ構造が含まれる。
【００６０】
本発明の記述は、例示及び説明の目的で提示され、網羅的であること又は本発明を開示された形態に限定することを意図するものではない。当業者には、多くの修正又は変形が明らかであろう。実施形態は、本発明の原理及び実際の適用を最もよく説明するように、及び、考慮された特定の使用に適合するような種々の修正を伴う様々な実施形態について当業者以外でも本発明を理解できるように、選択し記述された。
【図面の簡単な説明】
【００６１】
【図１】本発明を実装することができるネットワーク化されたデータ処理システムのダイアグラムである。
【図２】図１のネットワーク化データ処理システム内のサーバ・システムのブロック・ダイアグラムである。
【図３】図１のネットワーク化データ処理システム内のクライアント・システムのブロック・ダイアグラムである。
【図４】本発明の好ましい実施形態による自律型構成ブローカー・システムの全体図を示すダイアグラムである。
【図５】本発明の好ましい実施形態におけるハードウェア又はソフトウェア・コンポーネントに対する要求を満たすプロセスのフローチャート図である。
【図６】本文書内に用いられるようなＥ・Ｒ（エンティティ・リレーションシップ・ダイアグラム）におけるシンボル凡例を提供するダイアグラムである。
【図７】本発明の好ましい実施形態に用いるためのデータベース・システムを表す例示的なＥ・Ｒダイアグラムである。
【図８】本発明の好ましい実施形態による、制御論理に従ったプロセスのフローチャート図である。
【図９】遠隔メタサービス・プロバイダが派生メタサービスを提供するために用いられる、本発明についてのアーキテクチャ面での変形を示すダイアグラムである。
【図１０】遠隔メタサービスの能力が構成サービス内に組み込まれた、本発明のアーキテクチャ面での変形を示すダイアグラムである。
【図１】
2006500650.tif 000003
【図２】
2006500650.tif 000004
【図３】
2006500650.tif 000005
【図４】
2006500650.tif 000006
【図５】
2006500650.tif 000007
【図６】
2006500650.tif 000008
【図７】
2006500650.tif 000009
【図８】
2006500650.tif 000010
【図９】
2006500650.tif 000011
【図１０】
2006500650.tif 000012
【国際調査報告】
2006500650.tif 000013
2006500650.tif 000014