JP2002324056A - 分散型ネットワーク環境においてソフトウェアコンポーネントにアクセスするためのシステム及び方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】指定された属性に基づき、コンホ゜ーネントの
アト゛レス又は場所に関する事前の知識を必要とせずに
分散型ネットワーク環境にわたり分散されたリモートソ
フトウェアコンホ゜ーネントの位置を特定し、関連付け
を行うためのシステム及び方法を提供する。 【解決手段】分散型ネットワークシステムにおけるソフ
トウェアコンホ゜ーネント、インタフェイス、又はリソ
ースにアクセスするためのシステム及び方法であって、
少なくとも１つの指定された属性を有するコンホ゜ーネ
ントに関するリクエスト２２０を生成し、該リクエスト
２２０をネットワークを介してフ゛ロート゛キャスト
し、該リクエスト２２０をサーヒ゛スフ゜ロハ゛イタ゛
において受信し、該受信したリクエストの少なくとも１
つの指定された属性をサーヒ゛スフ゜ロハ゛イタ゛のコ
ンホ゜ーネントの属性と比較し、要求を出したサーヒ゛
スコンシューマ２１４へ応答を送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク化さ
れたコンピュータシステムに関し、特に、分散型ネット
ワーク環境にわたって配置されたソフトウェアコンポー
ネントに（密接した実行(cohesive execution)のため
に）アクセスするための新規のシステム及び方法に関す
る。

【０００２】

【従来の技術】一般に、分散された（ネットワーク化さ
れた）環境におけるソフトウェアアプリケーションは、
サービスプロバイダ、サービスコンシューマ、又はその
両者と考えることができる。その名前が示唆するよう
に、サービスプロバイダは、インタフェイス、コンポー
ネント、又はリソースを他のプログラムに提供して、該
他のプログラムがそれらのインタフェイス、コンポーネ
ント、又はリソースを利用してタスクを達成することが
できるようにするプログラムである。サービスコンシュ
ーマは、該サービスプロバイダにより提供されるインタ
フェイス、コンポーネント、又はリソースを利用するプ
ログラムである。

【０００３】一般に知られているように、多くのソフト
ウェアアプリケーションは、ネットワーク全体にわたっ
て分散され、これにより、該ソフトウェアアプリケーシ
ョンが、ネットワーク全体にわたり分散されているソフ
トウェアコンポーネントを利用することで目的を達成で
きるようになる。本書で使用する用語「コンポーネン
ト」は、インタフェイス、リソース、コードセグメント
等を含む、極めて広範な解釈を含むことを意図したもの
である。かかる分散されたアプリケーションの一例がネ
ットワークプリンタの使用である。具体的には、ネット
ワークプリンタは、該プリンタの動作を制御するよう構
成されたサーバによる直接的な制御下で動作することが
可能なものである。それにもかかわらず、分散されたア
プリケーション（クライアント）は、「プリント」用途
のために該プリンタにアクセスし利用することが可能で
ある。かかる分散されたアプリケーションの別の一例と
して、データベースに対するGUI（グラフィカルユーザ
インタフェイス）フロントエンドが挙げられる（すなわ
ち、GUIフロントエンドは該データベースを担うコンピ
ュータに関連するアプリケーション又はコンポーネント
である）。一般に知られているように、かかるGUIフロ
ントエンドは、データベースの内容に特定のグラフィカ
ルな及び／又は視覚的な「外観」を与えるために提供す
ることが可能である。データベースにアクセスしようと
するリモートソフトウェアアプリケーションは、GUIフ
ロントエンドを利用することが可能である。

【０００４】一般に知られているように、上記のような
アプリケーションでは、サービスコンシューマ（すなわ
ちプリンタ又はGUIフロントエンドを使用しようとする
ソフトウェアアプリケーション）は、提供されることに
なるコンポーネントのネットワークアドレス又は場所を
知る必要がある。すなわち、プリントしようとするワー
クステーションアプリケーションは、プリンタのネット
ワークアドレスを知る必要がある。同様に、GUIフロン
トエンドを使用しようとするプログラムは、データベー
スを担うコンピュータの場所を知るように構成される必
要がある。

【０００５】多くの場合、かかるコンポーネントは、サ
ービスコンシューマにより指定される「属性」に基づい
て探索される。例えば、企業のＬＡＮ環境において、ワ
ークステーションのユーザが、ビルディング「Ｇ」の
「２」階に配置された「カラー」プリンタでドキュメン
トをプリントすることを望む場合がある。それら括弧内
のアイテム（すなわち、カラー、２、及びＧ）は、所望
するプリンタリソースを指定するために用いることがで
きる属性である。それ故、システムがこのような属性を
取得して、指定された属性と一致する（又は少なくとも
指定された属性に最も近い）ネットワーク上の対応する
コンポーネントの位置を特定することができるようにす
ることが望ましい。

【０００６】かかる広範な機能を実施するための様々な
システム及び方法が知られている。これらの様々なシス
テム及び方法は一般に、サービスプロバイダにより必要
とされるコンポーネントのアドレス又は場所に関する事
前の知識を利用することにより動作するものである。CO
RBA（共通オブジェクトリクエストブローカアーキテク
チャ）として知られる方法では、オブジェクトリクエス
トブローカ（ORB）を利用して、サービスコンシューマ
（例えばクライアント）とサービスプロバイダ（例えば
サーバ）との間のオブジェクトコールを処理する。動作
時に、サービスコンシューマは、ORBにリクエスト（コ
ンポーネントに関する要求）を送信する。これとは別個
に、サービスプロバイダが、ORBを使用して「登録」を
行って、該サービスプロバイダが提供することができる
コンポーネントに関する指示をORBに与える。次いで、O
RBが「ブローカ」タスクを実行し、該タスクが、サービ
スコンシューマによるリクエストと登録されているサー
ビスプロバイダの能力との突き合わせを行う。該突き合
わせにおいて一致が見出されない場合には、ORBはその
旨をサービスコンシューマに通知することができる。し
かし、一致が見出された場合には、ORBは、その旨をサ
ービスコンシューマ（及び／又はサービスプロバイダ）
に通知して、リクエストされたコンポーネントをサービ
スコンシューマに提供できるようにする。このブローカ
処理が具体的に如何に実施されるかに関する詳細は、シ
ステムによって異なり得るものであるが、一般に当業者
には既知であり理解されているものである。それ故、こ
こで更に説明する必要はない。

【０００７】この機能を実施するための既知の別の方法
としてディレクトリサービスの使用が挙げられる。実際
に、電子(electronic)ディレクトリは、ネットワークリ
ソースを管理するためのツールとして急速に普及しつつ
ある。プリント式(printed)ディレクトリは、サービス
コンシューマがコンポーネントを見つけ出して容易にア
クセスすることを可能にする情報を識別するリストから
構成することが可能である。様々な情報の中でも特に、
これらのディレクトリは通常は、そこに列挙されたコン
ポーネントに関するネットワークアドレス又は場所を含
むものとなる。

【０００８】初期の電子ディレクトリは典型的には、特
定のアプリケーション及びコンピュータシステムのため
に開発されたものであり、それ故、他のアプリケーショ
ン及びシステムとは互換性がない場合が多かった。しか
し、事実上あらゆるコンピュータシステム上で実行され
るほぼ全てのアプリケーションがディレクトリ情報を取
得することを可能にするプロトコルが現れた。例えば、
X.500ディレクトリアクセスプロトコル（DAP）は、ディ
レクトリを担うサーバのタイプにかかわらずユーザによ
るディレクトリのブラウズ又はサーチを支援する標準化
された機能を提供するものである。ディレクトリプロト
コルの別の例として、ライトウエイトディレクトリアク
セスプロトコル(LDAP)、TCP/IPベースのX.500 DAPがあ
る。

【０００９】ここで図１を簡単に参照する。同図は、か
かるタイプの従来のシステムの顕著な特徴を概略的に示
したものである。図１は、サービスコンシューマ10、サ
ービスプロバイダ12、及びルックアップサービス14を概
略的に示している。該ルックアップサービスは、電子デ
ィレクトリとすることが可能であり、またCORBAシステ
ム内のORBとすることが可能である。いすれのシステム
においても、ルックアップサービス14は既知の場所に設
けられ、サービスプロバイダ12が該サービスプロバイダ
12のコンポーネントの識別情報をルックアップサービス
14に提供することができるようになっている。サービス
コンシューマ10は、かかるコンポーネントを必要とし又
は所望する場合に、かかるコンポーネントがネットワー
ク上で利用可能であるか否かを判定するようルックアッ
プサービス14にリクエストする。該コンポーネントが利
用可能である場合には、ルックアップサービス14は一般
に、かかるコンポーネントを有するサービスプロバイダ
12のネットワークアドレス又は場所を識別することで該
リクエストに応答し、これにより、サービスコンシュー
マ10が、該サービスプロバイダ12とのインタフェイスを
直接形成することができるようにする。

【００１０】かかるシステムは、サービスコンシューマ
が、サービスプロバイダのネットワークアドレス又は場
所に関する事前の知識を必要とすることなく、指定され
たコンポーネントをサービスプロバイダから取得するこ
とを効果的に可能とするものではあるが、かかるシステ
ムには多数の明らかな欠点が存在する。最も重大なの
は、ルックアップサービス14がシステム内の唯一の障害
部位となった場合である。サービスプロバイダ12及びサ
ービスコンシューマ10が何れも適切に機能している場合
であっても、サービスコンシューマ10は、ルックアップ
サービス14に障害がある場合には、そのタスクを完遂す
ることができない可能性がある。

【００１１】更に、かかるシステムにおけるルックアッ
プサービス14は、性能上のボトルネックを呈するもので
もあり、サービスプロバイダ12により提供されるコンポ
ーネントへのアクセス速度を低下させるものとなる。多
数のサービスがルックアップサービスに登録される可能
性があるため、サービスに関するリクエストは一般に、
登録されているサービスのリスト全体に対して突き合わ
せが行われなければならない。かかる比較が行われてい
る間には、サービスコンシューマ及びサービスプロバイ
ダの両者がアイドル状態のままとなって、有用な作業を
全く行うことができなくなる場合が多い。

【００１２】更に、ルックアップサービス14はセキュリ
ティ上のリスクを呈するものとなる。これは、ルックア
ップサービス14が、それ自体に登録されている全サービ
スを世界中に公開するからである。ルックアップサービ
ス14は本来は公告的なサービスである。しかし、「世界
中」に一般に公告することは望まず、選ばれた少数のコ
ンシューマにのみサービスを提供することを所望するサ
ービスも存在する。サービスプロバイダは、選ばれたグ
ループ以外のコンシューマへのサービスを拒否するよう
構成することができるが、これは、サービスプロバイダ
に更なる複雑さを要求するものとなる。更に、サービス
が単に存在するだけでも、不要なアタックを招く可能性
がある。

【００１３】

【発明が解決しようとする課題】したがって、本発明の
目的は、指定された属性に基づき、及びコンポーネント
のアドレス又は場所に関する事前の知識を必要とするこ
となく、分散型ネットワーク環境にわたり分散されたリ
モートソフトウェアコンポーネントの位置を特定し関連
付けを行うための、改善されたシステム及び方法を提供
することにある。

【００１４】

【課題を解決するための手段】本発明のある特定の目
的、利点、及び新規の特徴については、以下の説明で部
分的に示すが、当業者であれば以下の内容を検討するこ
とにより更に部分的に自明となり、また本発明を実施す
ることにより習得されよう。本発明の目的及び利点は、
特許請求の範囲に規定する手段及びその組み合わせによ
り理解し獲得することが可能である。

【００１５】本発明は広範には、分散型ネットワーク環
境においてソフトウェアコンポーネント、インタフェイ
ス、又はリソースにアクセスするためのシステム及び方
法に関するものである。本発明の固有の特徴は、かかる
コンポーネント、インタフェイス、又はリソースの位置
を、特定の指定された属性に基づき、及び該コンポーネ
ント、インタフェイス、又はリソースのアドレス又は場
所に関する事前の知識を必要とすることなく、特定する
能力にある。

【００１６】一実施形態によれば、本発明の方法は、少
なくとも１つの指定された属性を有するコンポーネント
に関するリクエストを生成し、該リクエストをネットワ
ーク上にブロードキャストし、該リクエストをサービス
プロバイダで受信し、該受信されたリクエストの前記少
なくとも１つの指定された属性とサービスプロバイダの
コンポーネント属性とを比較し、リクエストを出したサ
ービスコンシューマに応答を送信する、という各ステッ
プを含むものとなる。

【００１７】

【発明の実施の形態】本明細書に含まれてその一部を形
成する図面は、本発明の幾つかの態様を示し、本発明の
詳細な説明と共に本発明の原理を説明する役割を果たす
ものである。

【００１８】ここで、図示の本発明に関する説明を詳細
に参照する。同図に関して本発明を説明するが、該開示
の実施形態に本発明を限定する意図はない。逆に、特許
請求の範囲により規定する本発明の思想及び範囲内に含
まれる全ての代替形態、変更形態、及び等価形態を網羅
することを意図している。図面は、グラフィクス処理シ
ステムについて示したものである。当業者であれば、本
明細書を参照することにより、本発明がグラフィクスシ
ステムに限定されるものではなく、他のタイプの処理シ
ステムに拡張可能なものであることが理解されよう。 [定義]本発明の好ましい実施形態について説明する前
に、幾つの定義について以下で説明する。本明細書又は
請求の範囲において、用語にせよ技術にせよ、これらの
用語が、以下に述べられる定義とは異なる特定の意味を
有する場合があるので、特定の場所又は特定のアプリケ
ーションにおいて、ある用語に異なる意味又は更に限定
された意味を特に割り当てない限り、以下の定義が、本
明細書及びその請求の範囲内で用いられるような用語の
解釈及び意味を定めるものとする。

【００１９】本明細書で用いられる「サービスプロバイ
ダ」は、リクエストを出しているデバイス又はプロセス
に、プログラム、インタフェイス、サービス、又は他の
コンポーネントを供給する、コンピュータネットワーク
上のエンティティを指す。

【００２０】本明細書で用いられる「サービスコンシュ
ーマ」は、サービスプロバイダから供給されたプログラ
ム、インタフェイス、サービス、又は同様のコンポーネ
ントを使用してタスクを実行し又は何らかの作業を完遂
する、コンピュータネットワーク上のエンティティを指
す。

【００２１】本明細書で用いられる「サービス記述子」
は、１つ又は２つ以上の属性を使用することにより１つ
のサービスを記述し又は定義する、オブジェクト、テー
ブル、又は他のデバイスを指す。

【００２２】本明細書で用いられる「サービスファイン
ダ」は、ネットワーク上の１つのサービスプロバイダの
１つ又は２つ以上のコンポーネント（サービス記述子に
より定義されるもの）の発見を制御するためにサービス
コンシューマにより生成され又は使用されるオブジェク
トのインスタンス、すなわち別個のプロセスを指す。サ
ービスファインダはまた、サービスコンシューマに対す
る発見されたコンポーネントの報告を制御することも可
能である。

【００２３】本発明は、図面を参照する前に上述のよう
にその概要を説明してきたが、本発明の進歩性の例証に
資するように、以下にその実施形態を提示する。この場
合、ネットワークプリンタ及びプリントアプリケーショ
ンを実施形態として選択したのは、単に本発明の特定の
思想を例示するためである。本発明は、極めて広範な応
用形態を有するものであって、本書で説明するプリンタ
又はプリントアプリケーションに限定されるものでは決
してない、ということが理解されよう。

【００２４】ネットワークプリンタ及びプリントアプリ
ケーションの使用は、周知のものである。ネットワーク
環境では、１つのネットワーク上で幾つかのプリンタが
使用可能であることが多い。ユーザの視点から見れば、
ユーザは、所与のアプリケーション（例えばWindows
（商標）アプリケーション）において、該アプリケーシ
ョンがプリントすることが可能な複数の利用可能なプリ
ンタのうちの１台を選択することが一般に可能である。
しかし、その前に、ユーザが使用しているコンピュータ
システムが「構成」されることになる。該コンピュータ
システムの構成時に、利用可能なプリンタとネットワー
ク上における該プリンタの各々の場所とに関する情報が
該コンピュータに指示される。更に、利用可能な各プリ
ンタのためのドライバが該コンピュータ上にインストー
ルされる。特定のプリンタが選択されて、該選択された
プリンタでプリントするためのコマンドが発行される
と、ユーザのコンピュータ上にインストールされたプリ
ンタドライバは、プリントサーバ（例えばネットワーク
プリンタを制御するコンピュータ又はプロセス）上で実
行されているドライバと協動して、プリントするよう選
択されたジョブ又は資料をプリントする。

【００２５】しかし、本発明は、プリント処理（本明細
書の場合）に対する全く新しいアプローチだけでなく無
数の他の応用形態を提供するものである。したがって、
本発明に従って構成されるシステムは、プリンタドライ
バ又は識別情報を用いてコンピュータワークステーショ
ンを予め構成する必要のないものである。代替的に、ネ
ットワークプリンタをリアルタイムで「発見」し、コン
ピュータワークステーション上にドライバをプリインス
ールすることを必要とせずに同プリンタを使用すること
が可能である。本発明のシステムは、ユーザ又はワーク
ステーションにより指定された属性に基づいてリクエス
トされたコンポーネント（例えばプリンタ）を識別する
ことにより動作するものである。プリンタの例で説明を
続けると、ユーザが資料をプリントすることを望み、及
びシステムが本発明に従って構成された場合、ユーザ
は、所望のプリンタの特定の属性を定義するだけで良
い。

【００２６】例えば、企業環境のローカルエリアネット
ワークについて考察する。ジョブ又は資料をプリントす
ることを選択するユーザは、プリンタが、カラーレーザ
高速プリンタであり、用紙の両面にプリントすることが
可能なものであり、ビルディング100の４階に配置され
たものである、といった所望のプリンタの特定の属性を
指定することが可能である。次いで、本発明に従って構
成されたシステムは、そのリクエストを満たす全てのプ
リンタを識別し、該プリンタのリストをユーザ（又はリ
クエストを出しているアプリケーション）に返し、ユー
ザは、その返されたリストに基づいて１台のプリンタを
選択することが可能となる。勿論、適当な例外処理を該
システムに組み込むのが好ましいであろう。このため、
例えば、指定された各属性に一致するプリンタが見つか
らなかった場合であっても、最も近く一致するプリンタ
を識別して該プリンタをユーザに返してその中から選択
できるようにするようシステムを構成することが可能で
ある。この例外処理及び一般的なシステム設計の一部と
して、最も重要な属性を選択するようユーザに促すこと
が可能であり、該選択された属性に従って識別及び発見
プロセスを形成することが可能である。更に、好ましい
実施形態では、属性を指定するために、共通の「用語」
が選択されるのが好ましいであろう。しかし、かかる細
部は、本発明の範囲及び思想に矛盾することなく、アプ
リケーションプログラマに委ねることが可能なものであ
り、またアプリケーションによって異なり得るものであ
る。

【００２７】しかし、上記の広範な教示にしたがって構
成されたシステムは、従来の技術によるシステムよりも
遙かに優れた進歩を提供するものとなる。例えば、専門
技術者が個々のワークステーションに足を運んで新しい
プリンタ用の適当なドライバをインストールしたりプリ
ンタの選択を更新したりすることを必要とすることな
く、新しいプリンタをネットワークに追加することが可
能である。更に、プリンタに障害が発生し、若しくはプ
リンタが一定期間にわたりネットワークから取り外され
る場合には、かかる障害又は取り外しがユーザに対して
明らかとなる。これは、該プリンタが、プリントサービ
スをリクエストした所与のワークステーションからのリ
クエストブロードキャストに対して単に応答しないこと
になるからである。他の多くの利益及び利点が、本書で
提供する開示から当業者に明らかとなろう。

【００２８】ここで図２を参照する。同図は、本発明に
従って構成されたシステム100が動作することが可能な
例示的なネットワーク環境を示している。この場合、シ
ステム100は、ネットワーク116を介して通信を行う多数
のサービスコンシューマ（例えば符号112,118）及び多
数のサービスプロバイダ（例えば符号114,126,136）を
有するものとして示されている。ここで説明する特定の
実施形態は、ローカルエリアネットワークとしてネット
ワーク116を示している。しかし、本発明の思想及び教
示は、インターネットを含むワイドエリアネットワーク
に容易に拡張することができる、ということが当業者に
は理解されよう。更に、ＬＡＮ境界を超えるマルチキャ
スト・ブロードキャストを遮断するようIPルータが構成
されることが多いことが当業者には理解されよう。それ
故、ＬＡＮ境界を超えて本発明を利用することが可能と
なるようにIPルータの構成を適当に変更する必要がある
場合がある。かかる細部は、本発明の要旨を形成するも
のではなく、本発明の理解の中心となるものでもないの
で、本書で説明する必要はない。

【００２９】サーバ120,130といった特定のハードウェ
アコンポーネントも示されている。サーバ120はデータ
ベースサーバとして示されている。該サーバ120は、デ
ータベース又は記憶装置124と通信するコンピュータ122
を含む。勿論、記憶装置124は、コンピュータ122の内部
に配置されたハードディスクとすることが可能である
が、純粋に例示を目的として、図２では別個の装置とし
て描いてある。ネットワーク116上の他のエンティティ
により要求され得るリソースを有しているため、サーバ
120は該リソースのコンポーネントを管理するサービス
プロバイダ126を含む。同様に、サーバ130はプリントサ
ーバとして示されている。該サーバ130は、プリンタ134
と通信するコンピュータ132を含む。ネットワーク116上
の他のエンティティにより要求され得るリソース（すな
わちプリンタ134）を有しているため、サーバ130はサー
ビスプロバイダ136を含む。更に別の多くのタイプのサ
ービスプロバイダが、本発明の範囲及び思想内に含まれ
るが、本書ではこれ以上具体的に示さないこととする。
上記で簡単に説明したように、サービスプロバイダは単
に、リソース、サービス、インタフェイス、プログラム
セグメント、又は他のコンポーネントを、かかるコンポ
ーネントの使用をリクエストするサービスコンシューマ
に提供する、エンティティである。

【００３０】これに関して、図２は単なる例示を目的と
して提供したものであり、本発明の範囲を制限するもの
と見なされるべきではない。

【００３１】ここで図３Ａ及び図３Ｂを参照する。同図
は、本発明の好ましい実施形態に従って構成されたシス
テム200の主な構成要素を示したものである。図の単純
化のために、１つのサービスプロバイダ212及び１つの
サービスコンシューマ214しか示していない。好ましい
システム200の該主な構成要素に加え、図３Ａ及び図３
Ｂは、本発明の好ましい実施形態の方法を示す際にも有
用なものである。このため、以下の説明は、好ましい実
施形態の主な方法を説明したものである。そのシステム
の様々な構成要素については、該方法の文脈及び流れに
沿って説明するものとする。

【００３２】該方法の初期のステップは、サービスコン
シューマ214が、サービスプロバイダ212により供給され
ることになるコンポーネント（例えば、サービス、イン
タフェイス、リソース、コードセグメント等）のリクエ
ストを生成することである。サービスコンシューマ214
において実行されているアプリケーションに応じて、該
リクエストを自動的に（例えばプログラム制御下で）生
成することが可能であり、又はユーザによる制御及び命
令下で生成することが可能である。例えば、上記の例で
提示したように、ワードプロセッシングアプリケーショ
ンを使用しておりドキュメントをプリントすることを望
んでいるユーザは、所望のプリンタがカラーレーザ高速
プリンタであり、両面プリントを行うことが可能なもの
であり、特定のビルディングに配置されたものであるこ
とを指定することが可能である。かかる場合には、リク
エストは、部分的にユーザの直接的な制御下で作成され
ることになる。

【００３３】好ましい実施形態では、リクエストは、デ
ータパケット220という形で作成され、ネットワーク216
を介して該ネットワーク上の全ての装置へブロードキャ
ストされる。データパケット220の構造及び物理的な構
成は変更することが可能である。しかし、好ましいデー
タパケットは、パケットID221、パケットバージョン22
2、パケットタイプ223、ポート番号224、エントリイン
デックス225、及びサービス記述子226を含むものとな
る。好ましい実施形態では、パケットID221は、データ
パケットを一意に識別する短いストリングである。パケ
ットバージョン222は、システムの最新バージョンが開
発された場合に使用することが可能な整数である。パケ
ットタイプ223は、そのパケットが発見パケット（すな
わちリクエスト）であるか、応答パケットであるか、通
知パケットであるか、又はシステム200によりサポート
することが可能な他のタイプのパケットであるかを示す
整数であることが好ましい。ポート番号224は、応答を
送るべきポートを識別するものである。エントリインデ
ックス225は、応答を送るべきハンドラの識別子であ
る。最後に、サービス記述子226は、基本的には、サー
ビスコンシューマ214により探索されることになる様々
な属性を定義する名前／値の対のハッシュテーブルであ
る。サービス記述子226に関する付加情報について符号2
30に関連して以下で説明する。

【００３４】好ましい実施形態では、「応答時間」フィ
ールド227もまた、リクエストパケットの一部として含
まれる場合がある。このフィールドは、好ましくは、応
答のための最大時間を指定するものとなる。サービスプ
ロバイダは、リクエストパケットの受信時に、応答を遅
らせるためのランダムな遅延時間（応答時間フィールド
により設定される時間を最大とするもの）を生成するこ
とが好ましい。これにより、多数の応答が生成された場
合におけるネットワーク上での輻輳の低減に資するもの
となる。図示はしないが、将来の拡張をサポートするた
めの未使用フィールドを含む更に別のフィールドをリク
エストパケット中に含めることが可能である。

【００３５】図示のメッセージパケット220は単なる例
示であって本発明を制限するものではないことが理解さ
れよう。このため、本発明の教示に従って構成されたシ
ステムは、様々な異なる形式及び構造を有するリクエス
トパケットを生成し又は使用することが可能である。本
発明の好ましい実施形態の目的上重要なことは、リクエ
ストパケットが、サービスコンシューマ214によりリク
エストされているコンポーネントの１つ又は２つ以上の
属性を定義することである。

【００３６】上記のように、好ましい実施形態では、サ
ービスコンシューマ214は、ネットワーク216上の全ての
装置にリクエストパケット220をブロードキャストす
る。かかるメッセージのブロードキャストを実施するこ
とが可能な様々な態様が存在するが、好ましい実施形態
では、マルチキャストプロトコルが用いられる。好適に
は、リクエストパケット220は、IPネットワーク上でUDP
マルチキャストを用いてサービスコンシューマからブロ
ードキャストされる。

【００３７】これに関連して、一般に知られているよう
に、大規模ネットワークでは、比較的少数のパケットを
含む短いメッセージをネットワークへ迅速にブロードキ
ャストして、ネットワーク上の全ての装置が絶対確実に
又は極めて高い確率で該メッセージを受信することを確
実にすることが望ましい場合がある。送信側装置は、該
メッセージを多数の受信側装置に送信することができ
る。比較的短いメッセージを高い信頼性で送信すること
ができる限り、大規模で疎に結合されたネットワーク
は、メインフレームシステムの特徴と類似した集中制御
属性を有することができる。信頼性を確保するための１
つの方法は、IPネットワーク上でのTCPといったコネク
ションベースのプロトコルを用いて、全ての受信側シス
テムの各々と通信することである。コネクションベース
のプロトコルでは、１つの装置が、別の装置とのコネク
ションを形成し、該装置との全ての通信を処理し、次い
で該コネクションを終了する。多数の装置との通信が所
望される場合には、各システムとのコネクションが順次
に形成される。送信側システムと多数の受信側システム
との間のコネクションの形成及び管理に関するオーバー
ヘッドは、多数の受信側システムが存在する場合には法
外に非経済的なものとなる。

【００３８】コネクションベースのプロトコルに関連す
るオーバーヘッドを低減させるために、IPネットワーク
上でのUDPといったコネクションレスプロトコルが開発
された。コネクションレスプロトコルは典型的には、個
々のシステムとのコネクションを形成することなく多数
の受信側装置に１つのメッセージをブロードキャストす
るブロードキャスト又は「マルチキャスト」モデルに準
拠するものである。該アプローチは、各装置とのコネク
ションの形成に関連するオーバーヘッドをなくすが、全
ての装置に対するメッセージの受信を保証することがで
きないという欠点を一般に有するものとなる。IPネット
ワークの場合、多数の宛先にパケットを送信することに
関するオーバーヘッドを低減させるための設計により、
マルチキャストが信頼性に欠けるものとなる。

【００３９】数十万又は数億というパケットからなる大
きなメッセージについて高信頼性に関する問題に対処す
るために、他のメッセージングプロトコルが開発された
が、比較的少数のパケットからなる短いメッセージにつ
いては、かかるプロトコルは開発されていない。かかる
プロトコルは、送信時のオーバーヘッドを低減させるIP
マルチキャストを使用して、IPネットワークに接続され
た送信側システムから多数の受信側装置へデータを送信
するものである。

【００４０】この場合もやはり、本発明に関して、これ
らの方法のうちの任意の方法を利用することが可能であ
る。しかし、所与の装置が応答しなければならないわけ
ではないので、全ての各装置に対する高い信頼性での送
信は、必要不可欠なものではない、ということが理解さ
れよう。好適には、リクエストパケット220は、IPネッ
トワーク上でUDPマルチキャストを用いてサービスコン
シューマからブロードキャストされる。

【００４１】図３Ａ及び図３Ｂに関する説明を続ける
と、所与のサービスプロバイダ212はリクエストパケッ
ト220を受信すると、該受信したパケット内で定義され
ている属性を、該サービスプロバイダ212が有する様々
なコンポーネントの属性と比較する。該コンポーネント
は、ネットワーク216上の他の装置に対して利用可能と
なるものである。この場合、サービスプロバイダ212
は、ネットワーク216上の他の装置に対して利用可能と
なる、該サービスプロバイダが有する全てのコンポーネ
ントの各々に関するサービス記述子を含むことが可能で
ある。符号230は１つのかかるサービス記述子を示した
ものである。既述のように、サービス記述子は基本的に
は、様々な属性を指定するために使用することが可能な
名前／値の対を含むハッシュテーブルである。図示のサ
ービス記述子では、サービス名、サーバホスト、サーバ
名、OS名、及びOSバージョンといったアイテムをサービ
ス記述子230に含むことが可能である。更に、複数の属
性をサービス記述子230内で定義し又は指定することが
可能である。この場合も、無数の数及び無数のタイプの
属性が存在し、かかる属性は各応用形態に応じて様々な
サービス記述子内で定義することが可能である。かかる
属性は、当業者であれば所与の応用形態に基づき理解さ
れよう。それ故、各属性を網羅するリストを本書で述べ
る必要はない。

【００４２】サービスプロバイダ212は、リクエストパ
ケット220を受信すると、該受信したパケットのサービ
ス記述子226で指定された属性と、該サービスプロバイ
ダ212の様々なコンポーネントのサービス記述子（例え
ば符号230）で指定された属性とを比較する。リクエス
トパケットのサービス記述子226内で指定された全ての
属性が、サービスプロバイダ212のコンポーネントのサ
ービス記述子230内に含まれる場合には、サービスプロ
バイダ212は、該指定されたコンポーネントをサービス
コンシューマ214に提供することができることを示す応
答を生成する。リクエストのサービス記述子226により
指定された全ての属性がサービスプロバイダ212の単一
のサービス記述子230内に含まれない場合であっても、
本発明と矛盾することなく、同様の応答を生成するよう
サービスプロバイダ212を構成することが可能である。
代替的には、例えばリクエストのサービス記述子226内
で指定された属性のうちの一定の割合の属性がサービス
プロバイダ212内の単一のサービス記述子230内で見い出
された場合に、応答メッセージを生成するように、サー
ビスプロバイダ212を構成することが可能である。サー
ビスプロバイダ212がサービスコンシューマ214に返送す
るための応答メッセージを生成することになるときを判
定する際に、本発明と矛盾することなく、他の様々なア
ルゴリズムを利用することが可能である。

【００４３】好ましい実施形態の説明を続ける。サービ
スプロバイダ212は、適当な「一致」が見い出された
（例えばリクエストのサービス記述子226内で指定され
た属性のうちの十分な数の属性がサービスプロバイダ21
2のサービス記述子230内で見い出された）と判定した場
合に、応答メッセージパケット240を生成する。メッセ
ージパケット220とは異なり、好ましい実施形態では、
応答パケット240は、ネットワーク216上の全ての装置に
はブロードキャストされず、リクエストを出しているサ
ービスコンシューマ214に対してのみ送信される。この
場合、該応答は、ユニキャストメッセージを介して送信
することが可能である。しかし、本発明と矛盾すること
なく、該応答は、TCPを用いた高信頼性の応答を用いる
ことを含めて様々な方法で送信することが可能である。

【００４４】本発明によれば、応答パケット240は、様
々な形式及び構造で実施することが可能である。しか
し、好ましい実施形態では、応答パケットは、パケット
ID241、パケットバージョン242、パケットタイプ243、
エントリインデックス244、サービス記述子245、及びサ
ービスインタフェイス246を含む。これら要素の大部分
は、リクエストパケット220に関連して記述され、再び
記述される必要のないものである。しかし、サービス記
述子245は、サービス記述子226と一致するものと見なさ
れたサービス記述子230の複製である可能性がある、と
いうことに留意することが重要である。応答パケット24
0の一部としてサービス記述子230を送信することによ
り、該サービス記述子230が該サービスコンシューマ214
によりリクエストされたコンポーネントに適当に一致す
るものであるであるか否かに関する最終的な判定をリク
エストを出したサービスコンシューマ214が行うことが
可能となる。この場合に、サービス記述子226が５つの
属性を指定しており、及びサービス記述子230が該属性
のうちの３つのみを含んでいる場合には、サービスプロ
バイダ212は「一致」が見い出されたものと見なすこと
が可能である。しかし、サービスコンシューマ214は、
それを「一致」と見なさずに応答240を破棄することが
可能である。

【００４５】応答パケット240はまた、サービスインタ
フェイス（シリアル化されたスタブ(serialized stu
b)）246を含む。好ましい実施形態では、該サービスイ
ンタフェイス246は、１セグメントのJava（商標）コー
ドとして実施することが可能であり、これは、サービス
プロバイダ212のリクエストされたコンポーネントとの
インタフェイスに必要とされるコードを提供する。有利
なことに、これにより、リクエストされたコンポーネン
トのためのドライバを用いてサービスコンシューマ214
を予め構成する必要性がなくなる。更に、明らかには図
示しないが、該応答はまた、サービスプロバイダのネッ
トワークアドレス又は場所の識別情報を含むことが可能
である。しかし、本発明と矛盾することなく、該「スタ
ブ」を多数の態様のうちの任意の態様で提供することが
可能である。好ましい実施形態では、スタブに必要とさ
れるのは、サービスプロバイダとのコネクションを確立
し、及び該サービスプロバイダのサービスを利用するた
めに、コンシューマに十分な情報を提供することだけで
ある。場合によっては、該情報は、IPアドレス、ポート
番号、及び関連し得る方法しか含まないことが可能であ
る。

【００４６】サービスコンシューマ214により任意の所
与のリクエストがブロードキャストされる場合には複数
の応答が受信される可能性があることが理解されよう。
それ故、サービスコンシューマ214は、かかる複数の応
答を処理するための機能を含む。かかる機能は、過度の
応答を破棄し、応答の受信のための「タイムアウト」時
間を課し、及び他の問題を処理することを含むことが可
能である。

【００４７】応答を受信した後、サービスコンシューマ
214は、その後、サービスプロバイダ212と直接通信し
て、サービスプロバイダにより供給されるコンポーネン
トの協動使用を調整することが可能である。この場合に
も、この種の細部は、様々な態様で実施することが可能
なものであり、概ね、特定の応用形態でのプログラマの
自由裁量の範囲内のものとなる。

【００４８】図示の実施形態では、サービスコンシュー
マ214は、リクエストを生成し、応答の受信を待ち、応
答を整理し、応答をサービスコンシューマに報告する、
といった役割を果たすサービスファインダ250を含む。
一実施形態では、サービスファインダ250は、サービス
コンシューマの下で実行される別個のプロセスとするこ
とが可能である。しかし、好ましい実施形態では、サー
ビスファインダ250は、実行のための別個のスレッドを
有するインスタンスである。図示のように、サービスフ
ァインダ250は、リクエストパケットを生成するための
セグメント252を含む。該セグメント252は、少なくとも
１つの属性を指定し及びリクエストパケット内に含まれ
ることになるサービス記述子を指定する役割を果たすも
のである。サービスファインダ250はまた、リクエスト
パケットがネットワーク216上にブロードキャストされ
た後に、応答が「受信されるのを待つ(listening)」役
割を果たすセグメント254を含む。サービスファインダ2
50はまた、応答を受信し、受信された応答を整理するた
めのセグメント256も含む。該セグメント256は、「タイ
ムアウト」時間を課すことが可能なものであり、該タイ
ムアウト時間にわたり「応答が受信されるのを待つ」こ
とになる。次いで、該応答が整理されてベクトルにさ
れ、該ベクトルは、サービスコンシューマ214に渡すこ
とが可能なものである。サービスファインダ250は、応
答に寄与したものをサービスコンシューマ214に報告す
る更に別のセグメント258を含む。

【００４９】サービスコンシューマ214の場合と同様
に、サービスプロバイダ212は、リクエストの受信及び
応答の生成を処理するための機構を含むことが好まし
い。図示の実施形態では、これはサービスレスンポンダ
260によって処理される。サービスファインダ250の場合
と同様に、サービスレスポンダ260は別個のプロセスと
することが可能である。しかし、好ましい実施形態で
は、サービスレスポンダ260は、実行のための別個のス
レッドを有するインスタンスである。様々な機能の中で
も特に、サービスレスポンダ260は、マルチキャストリ
クエストを受信するためのセグメント262を含む。サー
ビスレスポンダ260はまた、受信したリクエストのサー
ビス記述子と、サービスプロバイダ212の各コンポーネ
ントのサービス記述子230とを比較するためのセグメン
ト264を含む。サービスレスポンダ260は、リクエストを
出したサービスコンシューマ214へ送信される応答パケ
ットを生成するための更に別のセグメント266を含む。

【００５０】本発明は、コンピュータネットワーク環境
においてリモートソフトウェアコンポーネントにアクセ
スするための新規のシステム及び方法を提供するもので
ある、ということが上記説明から理解されよう。好まし
い実施形態の方法は、少なくとも１つの指定された属性
を有するコンポーネントに関するリクエストを生成し、
該リクエストをネットワークにわたりブロードキャスト
し、該リクエストをサービスプロバイダで受信し、該受
信されたリクエストの少なくとも１つの指定された属性
とサービスプロバイダのコンポーネントの属性とを比較
し、及びリクエストを出したサービスコンシューマに応
答を送信する、という各ステップを含む。更に、好まし
い実施形態のシステム及び方法が従来技術のシステムの
様々な欠点及び問題点を解決するものであることが理解
されよう。最も注目すべきは、好ましい実施形態のシス
テムが、集中型のブローカ又は集中型のディレクトリサ
ービスの必要性を排除する点である。結果的に、かかる
集中型アイテムの排除は、かかる集中型のコンポーネン
トにより導入される単一ポイントでの障害を回避するこ
とにより、システムの障害に対する許容度を改善するも
のとなる。

【００５１】上記の説明は、図示及び説明を目的として
提示したものである。本発明の網羅及び本発明の開示し
た厳密な形態への限定は意図していない。上記教示に鑑
み、明らかな変更形態及び変形形態を実施することが可
能である。上記で説明した実施形態は、本発明の原理及
びその実際上の応用形態の最もわかり易い例示を提供す
ることにより、当業者が様々な実施形態で本発明を利用
し、及び意図する特定用途に適するような様々な変更形
態で本発明を利用することができるようにするために選
択し説明したものである。全てのかかる変更形態及び変
形形態は、特許請求の範囲が公正にかつ法的に権利を与
えられた範囲に従って解釈される場合に該特許請求の範
囲により確定される本発明の範囲内に含まれるものであ
る。

【００５２】以下においては、本発明の様々な構成要件
の組み合わせからなる例示的な実施態様を示す。 １．少なくとも１つのサービスコンシューマ(214)と少
なくとも１つのサービスプロバイダ(212)とを有する分
散型ネットワークシステムにおいて、前記サービスコン
シューマによりリモートソフトウェアコンポーネント(1
24,134)にアクセスするための方法であって、少なくと
も１つの指定された属性を有するコンポーネントに関す
るリクエスト(220)を生成し(252)、該リクエスト(220)
を前記ネットワークを介してブロードキャストし、該リ
クエストを前記サービスプロバイダ(212)で受信し(26
2)、該受信したリクエストの前記少なくとも１つの指定
された属性と前記サービスプロバイダ(212)のコンポー
ネントの属性(230)とを比較し(264)、前記リクエストを
出したサービスコンシューマ(214)へ応答(240)を送信す
る(266)、という各ステップを含む方法。 ２．前記ソフトウェアコンポーネントが、サービス、リ
ソース、インタフェイス、及びプログラムセグメントか
らなるグループから選択される、前項１に記載の方法。 ３．前記リクエストを生成する前記ステップが、サービ
ス記述子(226)を作成するステップを含み、該サービス
記述子(226)が、前記少なくとも１つの指定された属性
を指定するオブジェクトである、前項１に記載の方法。 ４．前記リクエストをブロードキャストする前記ステッ
プが、マルチキャストプロトコルを使用して前記リクエ
ストを前記ネットワークを介してブロードキャストす
る、前項１に記載の方法。 ５．前記ネットワークが、ローカルエリアネットワーク
である、前項１に記載の方法。 ６．前記ネットワークが、ワイドエリアネットワークで
ある、前項１に記載の方法。 ７．前記応答(240)を送信する前記ステップ(266)が、ユ
ニキャストプロトコルを使用する、前項１に記載の方
法。 ８．前記サービスプロバイダにより応答を作成するステ
ップを更に含み、該応答が、前記サービスプロバイダの
ネットワーク上の場所の識別情報を含む、前項１に記載
の方法。 ９．リモートソフトウェアコンポーネントにアクセスす
るための分散型ネットワークシステムであって、少なく
とも１つのサービスコンシューマ(214)と、少なくとも
１つのサービスプロバイダ(212)と、少なくとも１つの
指定された属性を有するコンポーネントに関するリクエ
スト(220)を前記サービスコンシューマ(214)において生
成する手段(252)と、該リクエストを前記ネットワーク
を介してブロードキャストする手段と、該リクエストを
前記サービスプロバイダ(212)において受信する手段(26
2)と、該受信された前記リクエストの前記少なくとも１
つの指定された属性と前記サービスプロバイダ(212)の
コンポーネントの属性(230)とを比較する手段(264)と、
前記リクエストを出したサービスコンシューマ(214)へ
応答を送信する手段とを備えている、分散型ネットワー
クシステム。

【図面の簡単な説明】

【図１】従来技術によるシステムがコンピュータネット
ワーク内のソフトウェアコンポーネントの位置を動的に
特定する態様を示す高レベルの説明図である。

【図２】本発明に従って構成されたシステムが動作する
ことが可能な例示的なネットワーク環境を示す説明図で
ある。

【図３Ａ】本発明の好ましい実施形態に従って構成され
たシステムの主要なコンポーネントを示す説明図である
(1/2)。

【図３Ｂ】本発明の好ましい実施形態に従って構成され
たシステムの主要なコンポーネントを示す説明図である
(2/2)。

【符号の説明】

124 データベース又は記憶装置 134 プリンタ 212 サービスプロバイダ 214 サービスコンシューマ 220 データパケット 226 サービス記述子 230 サービス記述子に関する付加情報、サービス記述
子 240 応答パケット 252 リクエストパケットを生成するためのセグメント 262 マルチキャストリクエストを受信するためのセグ
メント 264 受信されたリクエストのサービス記述子と、サー
ビスプロバイダの各コンポーネントのサービス記述子と
を比較するためのセグメント 266 サービスコンシューマに送信される応答パケット
を生成するための更に別のセグメント

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダニエル・イー・フォード アメリカ合衆国カリフォルニア州95746, グラニテベイ，ルクソール・レーン・4141 (72)発明者 エリック・ハバード アメリカ合衆国カリフォルニア州95678, ローズビル，フォレスト・ノエル・ナンバ ー２・425 Ｆターム(参考） 5B045 BB28 BB42 GG11

Claims (1)

【特許請求の範囲】
1. 【請求項１】少なくとも１つのサービスコンシューマ(2
   14)と少なくとも１つのサービスプロバイダ(212)とを有
   する分散型ネットワークシステムにおいて、前記サービ
   スコンシューマによりリモートソフトウェアコンポーネ
   ント(124,134)にアクセスするための方法であって、 少なくとも１つの指定された属性を有するコンポーネン
   トに関するリクエスト(220)を生成し(252)、 該リクエスト(220)を前記ネットワークを介してブロー
   ドキャストし、 該リクエストを前記サービスプロバイダ(212)で受信し
   (262)、 該受信したリクエストの前記少なくとも１つの指定され
   た属性と前記サービスプロバイダ(212)のコンポーネン
   トの属性(230)とを比較し(264)、 前記リクエストを出したサービスコンシューマ(214)へ
   応答(240)を送信する(266)、という各ステップを含む方
   法。