JP2000507724A - 分散形オブジェクトシステム内部での事象の収集 - Google Patents

Abstract

(57)【要約】 分散形オブジェクトシステムには事象収集機構（１４）があり、ここではシステム内部でのオブジェクトの創生、削除、及び作動についての情報を受領する。事象収集機構は集めた事象を事象発送機構（１６）に送り、それと一緒にユーザ応用が登録される。事象発送機構は、ユーザにより選定された基準に従って、ユーザ応用に向けて事象の詳細を送る。報告された事象のすべてを終局的にそれらの創生を担務することとなるオブジェクトに対してリンクするようにする方法が用意されている。

Description

【発明の詳細な説明】 分散形オブジェクトシステム内部での事象の収集 この発明は、分散形オブジェクトシステム（Distributed Object System）内 部での事象（イベント）の収集に関する。 分散形コンピューテングは、計算または計算機の分野で個々のソフトウェアモ ジュールが物理的に分けられている計算または計算機のノード上で運行されてい るものが互に通信でき、課題（タスク）を実行するために他に要求ができるもの である。オブジェクト指向技術の発達が近年分散形コンピューテングにとくには ずみを与え、２つの技術の収斂（集輻）が分散形オブジェク技術（Distributed Object Technology）で生れている。 これらオブジェクトの数と複雑さとが増して行くのにつれて、このようなシス テム内で何が起っているのかを正しく確認する上での問題も増えている。ソフト ウェア支援ツールが沢山システム設計者や保守者にとって使用可能となっている けれども、現状はやや不満足である。各種のツールで現在で使用可能とされてい るものに、例えば通常の“単一プロセス”ソフトウェアをデバグ（虫取り）する ものがあり、開発者にとってソフトウェア内のコードに踏み込んで、プログラム の状態を調べることができるようにしている。また、オブジェクト指向プログラ ミングに応用可能な一二のものもあり、これはオブジェクトの創生と削除とを示 すことによって通常のソフトウェア内でオブジェクトをプログラマに“目視可能 ”としている。 しかし、困難なことが発生するのであって、その理由は、このような通常のツ ールが大きな分散形オブジェクトシステムの設計者と保守者の需要に対して実際 には十分な力があるわけでなく、また融通性のあるものでもないことにある。 この発明を第１の視点でとらえると、複数のオブジェクトを有する分散形オブ ジェクトシステムが用意されており、各オブジェクトには関連のフィルタがあり 、このフィルタは対応するオブジェクトによって送受されたメッセージを傍受で きるようにされており、前記メッセージを表わす情報を事象収集器（イベントコ レクタ）へ前方送りするようにされている。 この発明はまた対応する方法にまで展開しており、とくにこの発明の第２の視 点に立つと、分散形オブジェクトシステムが複数のオブジェクトを有しているこ とに特徴があるシステムに展開しており、この方法の構成は各オブジェクトに関 連するフィルタを用意して、対応するオブジェクトによって送受されたメッセー ジを傍受し、またイベントコレクタへ向けて前記メッセージを表わす情報を前方 送りするようにされており、分散形オブジェクトシステムはイベントコレクタに よって受領されたメッセージに従って特徴づけされることが特徴となっている。 イベントコレクタによって集められたメッセージは事象についての予め定義さ れたクラス、例えばオブジェクトとオブジェクトの削除及び創成との間の相互作 用のクラスを表わすものであってよい。好ましいのは、イベントコレクタが集め た事象をイベントディスパッチメカニズム（事象発送機構）に送り、そこが事象 を処理してそれらを１又は複数のユーザ応用（アプリケーション）に送ることで ある。これらのユーザ応用はいろいろな異なる形態をとってよく、目視化応用、 欠陥検出応用、制御応用、及び課金応用などが含まれる。好ましい実施例では、 いくつかの違ったユーザ応用（オブジェクト）が同時に運行され、その各々が独 立して構成可能であるようにする。特定の要件に依存して、構成は自動的であっ てもまたはユーザが定義するものでもよい。 １形態では、この発明は事象の流れを創生するための機構または方法を提供し てよく、この場合、各事象は１つのオブジェクトから他へメッセージを送るか、 あるいはオブジェクトの創生もしくは削除のいずれかで成る。このシステムはオ ブジェクト自体のコードに対して侵襲的な変化を与えずにインストールできる。 さらにまた、一人ならず複数の個人がいつでもこのシステムで対話することを目 視可能とし、各個人がその者に関係する動作だけを見るようにする。 代って、別な実施例では、このシステムは欠陥報告とともに、あるいはこれと は別に欠陥回復サービスを分散形オブジェクトシステム内部で用意してもよい。 したがってこのシステムは、単一又他は一連のツールを用意し、それがよく定 義されたやり方で、分散形オブジェクトシステム内部で各種のオブジェクトから 情報を収集できる。したがってこの情報は次にシステムの分析に使用することが できて、例えばシステム故障とか他の予期しない事象の際に発生した何事かを見 出すようにする。同じように大切なことは、集めた情報が、開発に直接関与して いない別の人々に対してこのシステムを説明することを試みるシステム設計者を 助けるのに使用できる。便利なことは分散形オブジェクトシステムは極めて説明 することがむづかしく、この発明は少くとも何らかの形で、“情報転送”プロセ スであって開発者及び設計者から技術協力者及び顧客に向けたものを改善するこ とになろう。 この発明は、いろいろなやり方を実用に供することができ、１つの特定の分散 形オブジェクトシステムでこの発明を実施するものを例を挙げて、次の添付の図 面を参照して記述して行く。 図１は分散形処理環境内での遠隔プロセス呼を示す。 図２はこの発明の好ましい実施態様に従ったシステムの全体図である。 図３は送受されているメッセージを傍受するためにフィルタが使用されるやり 方を示す。 図４はフィルタの動作を示す。 図５はオブジェクト間を対話がどのように伝搬するかを示す。 図６はオブジェクト間でキーを伴うメッセージがどのように送られるかを示す 。 図７は追加のオブジェクトを伴う対話を示す図６に対応するものを示す。 図８は好ましい目視化応用が事象発送機構とどのように登録されるかを示す。 図９は目視化応用に向けて情報を前送りする事象発送機構を示す。 図１０は好ましい目視化応用からの例としてのスクリーンショットを示す。 図１１は分散形処理環境（ＤＰＥ）でこの発明と関係して使用してもよいもの に対する例としての構造を示す。 図１２はこの発明の実施例と使用されるプラットホームのハードウェアの図を 示す。 この発明の好ましい実施態様を記述する前に、分散形処理環境（ＤＰＥ）につ いての若干の背景にある情報を一般的に記述しておくのが有用であろう。 多数のＤＰＥはＣＯＲＢＡ（コモン・オブシェクト・リクエスト・ブローカ・ アーキテクチャ）と呼ばれれる事実上の規格に適ったものとなっている。ＣＯＲ ＢＡ規格はＯＭＧ（オブジェクト・マネージメント・グループ）によって創られ たもので、ＯＭＧは多数のコンピュータ会社、ソフトウェアベンダ及び他の関心 のある当事者で成る国際的な組合である。 大部分のＤＰＥは図１に概略示したリモート・プロシージャ・コール（ＲＰＣ ）と呼ばれる相互作用（対話）の型式を用いる。ＲＰＣモデルでは、クライアン トオブジェクト１０はメッセージ１１を遠隔サーバオブジェクトに送って、特定 の動作を要求する。サーバオブジェクト１２はこの動作に対応するコードを実行 する。一般に、外へ向うメッセージ１１は呼出（インボーク）されることになる 動作名称を動作のアーギュメント（項目）と一緒に含んでおり、また応答メッセ ージは動作の結果とともに呼出された動作の名称を含んでいる。 他の対話型式もあるが、大部分は通常のＲＰＣモデルから得られるものとして 考えてよい。例えば、ＣＯＲＢＡで使用される別の対話型式は“一方通行（ワン ・ウェイ）”型式である。このモデルでは動作を呼出すためのメッセージはサー バオブジェクトに送られるが、その間にクライアントオブジェクトはそれ自体の コードを実行し続ける。サーバオブジェクトが関係する動作の実行を完了すると きは、何もメッセージを送り戻さない。これは単に通常のＲＰＣとして眺められ 、そこでは結果はなく、また確認（コンファメーション）はサーバオブジェクト からクライアントオブジェクトへ送り戻されない。 ここで図２を見ると、この発明の好ましい実施態様の全体図が示されている。 この例示のシステムは３つの主たるサブシステムという手段で実現されている。 第１のサブシステムはイベント収集機構であり、オブジェクトの創生と削除から 生ずる事象の収集と、その間の相互作用とに関係している。この図から分るよう に、事象収集機構は複数の分散されたオブジェクト２，４から情報を受け、オブ ジェクトは計算用環境内で広く散らばっている。例えば、１つのオブジェクトは １つの物理的コンピュータ上で運行され、他のものは他の物理的コンピュータで あって、通常のローカルエリア網又はさらに広域の網によって第１のものに接続 されたものの上で運行される。第２のサブシステム１８は目視化応用の形をとっ ていて、システムの使用者にとって相互作用を眺めることができるようにし、相 互作用を眺めるやり方を構成して、眺めるべき相互作用（対話）を決められるよ うにする。特別の目視化応用１８ａ，１８ｂ，１８ｃは一時に動作状態であって もよい。第３のすなわち最終のサブシステムは事象発送機構１６を含み、これが 収集機構１６からの事象の流れをとりあげて、それを個々の目視化応用１８ａ， １８ｂ，１８ｃの各々に発送する。無論、事象収集機構１４、事象発送機構１６ 及び目視化応用１８はすべてがその権利についてはオブジェクトとして考慮され てよい。 図３はもっと詳細に個々のオブジェクトと事象収集器機構１４との間の相互作 用を示す。参照を容易にするためにＲＰＣモデルと対応している素子にっいて使 用される参照番号は図１で使用した番号と対応させている。図示のように、事象 収集器１４は事象２６，２８を集め、それらがフィルタ２０，２２によって送ら れ、フィルタはそれぞれクライアントオブジェクト１０とサーバオブジェクト１ ２とに関係している。フィルタ自体はＣＯＲＢＡ適合（コンプライアント）製品 Ｏｒｂｉｘで表わされるフィルタを含んでいてもよい。Orbixは市販のソフトウ ェア製品でIona Technologiesから入手できる。これがソフトウェアを挿入でき るものとし、メッセージの到着、発送、応答、戻り（オブジェクト相互作用）の 際に運行されるようにする。したがって、事象収集器１４は１つのオブジェクト から他へのメッセージの伝送（すなわち他による１つのオブジェクトについての 呼出し）か、オブジェクトの創生又は削除に関連する情報を集める。このフィル タは送受されているメッセージを傍受するやり方でオブジェクトと関連している が、オブジェクト自体に何らの変更も求めない。 図４は実際のシステム動作を示す。図中４ａはオブジェクトＡがオブジェクト Ｂ上で要求を呼び出す前の状態を示す。４ｂは要求が呼出されるときの状態を示 す。送り出されるメッセージ１１はフィルタＡによって傍受され、また報告用メ ッセージ３０は事象収集機構に送られる。無論、オブジェクトが創生されるか削 除されるときには、対応するフィルタもまた創生されるか削除されることになり 、それによって、このための事象も同様に生成されることになる。事象収集機構 はシステム内部の活性状態にあるオブジェクシ全部から事象を集める。 事象収集機構１４によって集められた事象のすべては、そこで連続した流れと なって事象発送機構１６（ＦＩＧ２）に送られる。無論、オブジェクト間で送ら れる全部のメッセージについて、また全部のオブジェクトについての創生と削除 とについて情報を集めることは情報の超過負荷をもたらすことになりそうである 。 一般には、ユーザは特定のオブジェクトもしくはオブジェクトの特定のクラスに 対して何が発生しているかだけに関心があり、そこでどの事象が関心があるかを 確定する何らかの方法を用意することが有用となろう。これを達成するやり方を これから記述する。 先ずは、分散形オブジェクトシステムでは、システム内であるオブジェクトが 他のものと相互作用とするときには、さらに“ノックオン（前へ投げる）”相互 作用が続いて起るかも知れないことに注意したい。これが図５に示されていて、 ここではオブジェクト３２，３４間の相互作用が“ノックオン”相互作用を別な オブジェクト３６，３８と創生している。好ましい実施例では、機構が用意され て、後続の“ノックオン”相互作用がトリガを発したもともとの相互作用に戻る ようにリンクされていてよい。 これが達成されるやり方は、図６を参照すると分ると思う。システム内の各オ ブジェクトは独特なキーすなわち識別子を与えられており、このキーはそれぞれ のフィルタと関連づけて記憶されている。そこで、もしあるオブジェクト（例え ばオブジェクトＡ）が他のオブジェクト（オブジェクトＢ）のサービスを呼ぶと 、オブジェクトＡのキーはオブジェクトＢへ伝わり、そこでこのキーを採用して オブジェクトＡの要求に対するサービスを終るまで使う。その後、オブジェクト Ａのキーを無視して、再び自分のキーに戻る。 図６ａはオブジェクトＡがオブジェクトＢ上の要求を呼出す前の状態を示す。 図示のように、オブジェクトＡと関係しているフィルタ２０は独特のキーＡを含 んでおり、またオブジェクトＢと関係しているフィルタ２２は独特のキーＢを含 んでいる。 図６ｂはオブジェクトＡがオブジェクトＢ上の要求を呼出すときの状態を示す 。送出されるメッセージ１１はオブジェクトＡとオブジェクトＢとの間を通り、 このメッセージは前述のようにフィルタ２０によって傍受され、そこが報告用メ ッセージ３０を生成する。フィルタ２０はメッセージ１１にそれ自体のキーであ るキーＡを付着させ、それが受信用フィルタ２２に向けて送られるが、ここには 現在はキーＢが含まれている。キーＡを含むメッセージが到着すると、フィルタ ２２はそれのもともとのキーに代ってキーＡを採用して、オブジェクトＢに向け て メッセージの残りの部分を送る。 図６ｃはこの状態を示し、そこでは要求がオブジェクトＢによってサービスを 受けている。後で分ると思うが、オブジェクトＢのフィルタ２２は今ではキーＡ を採用している。 図６ｄはオブジェクトＢが要求を完結し、応答メッセージをオブジェクトＡに 送り戻している場合に何が起るかを示している。このメッセージが送られると、 オブジェクトＢのフィルタ２２はもとのキーに戻ってキーＢを採用する。応答メ ッセージはフィルタ２０によって受領されて、オブジェクトＡに向けて送られる 。同時に、フィルタ２０は別の報告用メッセージ３０’を発生し、それが事象収 集機構１４（図２）へ向けて送られる。 このようにして、オブジェクトＡからオブジェクトＢへ送られた最初の相互作 用の結果として発生する事象の全部が、オブジェクトＡとキーＡを経由して関連 づけができる。事象収集機構は、報告用メッセージ３０，３０’の両方ともがそ の中にキーＡを含んでいるので、報告された事象のすべてがオブジェクトＡから 派生していることを理解する。 もう少し複雑なシナリオを図７で見ることができ、ここではオブジェクトＢが 今度は第３のオブジェクトであるオブジェクトＣのサービスを呼ぶ。 図７ａはオブジェクトＡがオブジェクトＢ上で要求を呼出す前の状態を示して いる。 図７ｂはこの要求の呼出し中の状態を示す。報告用メッセージ４４は、キーＡ を含み、それは事象収集機構に送られて、そこに呼出されている要求を知らせる 。 図７ｃはオブジェクトＢがオブジェクトＡの要求にサービスしている時間での 状態を示す。オブジェクトＢのフィルタ２２はキーＡを採用していることに留意 したい。 図７ｄは、制御がオブジェクトＡに戻る前に、オブジェクトＢが他のオブジェ クト４０（オブジェクトＣ）上での要求を呼出す必要があるときに何が起るかを 示している。オブジェクトＣはそれ自体のフィルタと関係しており、この点では キーＣを含んでいる。フィルタ２２はメッセージを傍受し、現在はキーＡとなっ ているそれ自体のキーに付属させ、またさらに報告用メッセージ４６を事象収集 機構に対して用意し、それ自体にはオブジェクトＡから最初の相互作用が派生し たことを示すキーＡを含んでいる。 図７ｅはオブジェクトＣがオブジェクトＢからの要求に対してサービスしてい る時間での状態を示す。オブジェクトＢのフィルタ２２はキーＡを含んでおり、 現状のオブジェクトＣのフィルタ４２と同様である。 図７ｆはオブジェクトＣからオブジェクトＢへ応答を送り戻すことを示してい る。一度応答が送られると、フィルタ４２はキーＡをもう使わず、もとのキーで あるキーＣに戻る。フィルタ２２は応答メッセージを傍受して事象収集機構に向 けて別の報告用メッセージ４８を送る。再び、これにはキーＡが含まれており、 それは現在その特定のキーを含んでいるフィルタ２２から派生していることによ る。 最後に、図７ｇはオブジェクトＢがその要求を完了し、オブジェクトＡに制御 を戻すときに何が起るかを示している。応答メッセージがオブジェクトＢからオ ブジェクトＡへ送り戻され、またオブジェクトＢのフィルタ２２は再びもとのキ ーであるキーＢを採用する。応答メッセージを受領すると、オブジェクトＡのフ ィルタ２０はさらにまた別なメッセージ５０を事象収集機構に送る。ここでもま た、このメッセージはキーＡを含むことになるが、それはキーが現在フィルタ２ ０と関係していることによる。 それ故に、キーは１つのオブジェクトから次のものへと伝搬して行き、送り用 フィルタでメッセージにそれを加え、受け用フィルタではメッセージからそれを 除去しているように見える。 この機構を用いると、別な解析のために特定の事象もしくは事象の組を選択す ることが可能である。例えば、システムのユーザがオブジェクトＡから発した相 互作用の結果として生じている事象の全体のシーケンスを目視できるようにした いとするときには、その者がなすべきことは関連するキーであるキーＡと関係し ている事象だけを選ぶことである。 ここでもっと詳細を、図８と９とを参照して、事象発送機構とその目視化器応 用との関連について述べる。 事象収集機構によって事象が集められると、それらは事象発送機構１６に送ら れる。この事象発送機構は事象収集機構１４によって集められたすべての事象に ついての詳細を受領して、ユーザが関心をもっている特定の事象を目視化（器） 応用１８に送るようにされている。 図８から分るように、事象発送機構１６はその内部で事象発送（器）工場５２ として知られているオブジェクトと共働していて、ここでは事象発送工場５２と して知られているオブジェクトと共働していて、ここでは事象発送（器）として 知られている別のオブジェクト５４を創生することを担務している。各事象発送 （器）は特定の目視化（器）応用に向けて事象を送ることを担務する。事象の特 定のサブセットを眺めたいとするユーザは目視化応用オブジェクト１８を運行し 、それが参照番号５６で示されているように事象発送機構１６で登録される。 図９に示すように、目視化応用１８のいくつかの個々の例（オブジェクト）は 実際には一時に運行されてよく、その各々は事象発送機構１６にすでに登録され ているものとする。各登録にあたって、事象発送工場５２は新しい事象発送オブ ジェクト５４を創り、それが５８で示したように情報を対応する目視化応用に送 る。各目視化応用１８は違った構成であってよく、事象収集機構１４によって集 められてしまった（あるいは集められつつある）事象の違ったサブセット上の情 報を要求してもよい。必要とされるフィルタ作用はそれぞれの事象発送器５４に よって実行され、そこは個々の目視化応用によって要求された情報だけを送る。 目視化応用１８はいろいろな形態をとってよく、各種のフロントエンドを備え 、好ましい姿が図１０に模式的に示してある。目視化応用のユーザは大きなウィ ンドウ６０内に図式的に表示された情報を見る。この窓の作業空間６２内部には 目視化応用が示すために構成した各種オブジェクトを表示している。一般に、こ の表示は複数のオブジェクトアイコン６４を示し、それらが矢印６６で接続され ている。各アイコン６４は特定のオブジェクトを表わしており、一緒にある矢印 はオブジェクト間の相互作用を表わしている。矢印６７とオブジェクトアイコン ６８とのあるものは違った色彩で表示されてよく、活性状態の（現在の）相互作 用とかオブジェクトとかを示すようにする。好ましい表示では、最新の表示した 相互作用を赤色で示し、別な事象が到達し、それが活性相互作用となると、前の 相互作用が灰色となる。 ウィンドウ６０はさらにツールバー７０を含み、そこには状態表示７２と複数 のボタン７４とがあり、それによってユーザは自分の要求に対する表示を構成で きるようにしている。 目視化応用のもつ好ましい能力を以下に列挙する。構成可能なモード： （ａ）ステップモード−このモードでは、事象は応用で待ち行列内に記憶され 、応用上のカウンタはいくつの数の事象が現在待ち行列にあるかを示す。ステッ プボタンはユーザが継続して記憶された事象中を移動できるようにして、ステッ プボタンの各クリックで１つが表示されるようにする。 （ｂ）運行（ラン）モード−このモードでは、応用は到着する相互作用を行列 としないが、直ちにそれを表示しようと試みる。制御手段があって、ユーザが事 象の表示に間を置くようにでき、この場合にはプレイ（動作）ボタンが押される まで待ち行列内に一時的に記憶されることになる。この応用はユーザが構成でき る事象表示間の最小時間を強要できる。生の（ライブ）または記録した事象の流れ： （ａ）生のモードでは、事象は上述した事象収集と発送とのシステムから受領 される。 （ｂ）ファイルからのプレイでは、一連の事象が記憶されたファイルから供給 される。 （ｃ）ファイルへの記録では、事象の生のシーケンスが表示され、それと同時 に後日の表示用にファイル内に記録される。表示の構成 目視化応用次の情報を含んでいる構成ファイル内にロードすることらよって構 成が可能となる。 （ａ）オブジェクト−構成ファイルによると、ユーザは、どのオブジェクトが 表示されることになるか、どの位置にそれらが表示されることになるか、オブジ ェクトに対してどの色を使うことにするか、及び表示性質のどのカテゴリィと適 合するかを構成できるようになる。 （ｂ）事象−構成ファイルによると、また、ユーザはどの到来する事象が表示 されることになり、またどのユーザに親しみ易い名称が各事象によって表示され るべきかを構成できるようになる。キーの構成： これによると、ユーザはある種のキーで構成されているオブジェクト（又はオ ブジェクトの組）によってとられれた動作の結果として発生する事象を受領でき るようになる。 相互作用は次の４つの基準のすべてを満すときだけスクリーン上に表示される ： （ａ）（キーがいずれも構成されていない場合を除き）目視化応用に構成され ていたものと同じキーを相互作用がもつべきこと。 （ｂ）関心のあるものとして構成されたオブジェクトから相互作用が生じてお るべきこと。 （ｃ）関心のあるものとして構成されたオブジェクトで相互作用が終結してお るべきこと。 （ｄ）関心のあるものとして構成されたメッセージ名称を相互作用が持つべき こと。 上述したように、オブジェクトはある性質に適うように構成されてよい。以下 に挙げる性質の類型は例であり、追加の類型がいつでも目視化応用を修正するこ とによって加えられてよい： 類型１オブジェクト−このオブジェクト類型は目視化応用のスクリーン上でい つでも見ることができる。 類型２オブジェクト−この類型のオブジェクトが見ることができるようになる のは、事象が受領されて、それが目視化応用は創られて しまっていることを知らせ、またオブジェクトの消去に 対応する事象が到達する場合には隠れてしまうことを知 らせる場合である。 類型３オブジェクト−この類型のオブジェクトが見ることができるようになる のは、相互作用が表示されて、それがオブジェクトに向 うが、消去事象の到達によって隠れる場合である。 別の実施例（図せず）では、目視応用１８は事象収集機構によって集められた 情報の使用ができるようにする別のオブジェクトによって置き換えられてもよい 。例えば、欠陥（故障）報告用応用は分散形オブジェクトシステムの欠陥監視の ために用意できる。この応用は予期しない事象が発生した場合にシステム警報の 生産を含んでおり、警報という事象でのシステムの動作を変更するように設計さ れた誤り回復オブジェクトを備えたものとなる。このシステムは、例えば、適当 な環境下で完全に自動的に機能停止となりうるし、他の欠陥回復オブジェクトを 運行できるものとする。この発明のシステムは、そこで、システム設計者と保守 者とにとって有用であるだけでなく、オペレーショナル（操作的）分散形オブジ ェクトシステムを監視するための手段としても有用である。 さらに別な実施例（図示せず）では、目視化応用は課金応用で置き換えてもよ い。事象収集機構で集めた事象はそこでオブジェクト又はサービスの使用に対し ての課金用とすることができる。 ここで図１１を参照するとして、好ましい分散形処理環境（ＤＰＥ）を定義し ている技術モデルのインフラストラクチャの特徴を示している。ＤＰＥはそれ自 体が知られている類型のインフラストラクチャであり、これが前に論じた各種の オブジェクトの相互作用を支持している。ＤＰＥの目的は、とりわけ、応用プロ グラムを基礎環境がもつ異種混合の分散された性質から遮蔽し、また動作してい る特定の計算用ノードについての詳細に知識をもたなくてもオブジェクトが対話 （相互作用）できるような機構を用意することである。ＤＰＥは４つの類型のエ ンティティを定義する：ＤＰＥカーネル８１１、カーネル移送網９０１、ＤＰＥ スタブ、ＤＰＥサーバ８０９である。カーネル移送網９０１は図示のように複数 のインターリンクしている計算用ノード８１０とリンクしている。 ＤＰＥカーネルは通信、記憶及び処理能力（例えばプロトコルスタック）のコ アの組を定義し、これが各ノードに送られるものと仮定している。 カーネル移送網９０１は、通信網であり、これに対しては全部のＤＰＥカーネ ルがオブジェクト相互作用に機能するためにメッセージを交換する目的で取付け られており、また音声とビデオの伝送のために使用してもよい移送網から計算用 網を論理的に分離するために定義付けられている。論理的な分離は２つの網がサ ービス品質（ＱｏＳ）について異なった要求をもってもよいことを認識させる。 ＤＰＥサーバ８０９はインフラストラクチャ支援を用意するが、例えばそれは トレーダ（商人）とか通知サーバとかいう形態である。トレーダは運行時間機構 としてオブジェクトが他のオブジェクトのインターフェースを位置決めできるよ うにするものを用意する。通知サーバはオブジェクトして他のオブジェクトに向 けて通知を発することができるるようにするものである（例えば、オブジェクト の寿命時間内に発生した重要な事象について）。通知を受けることを望むオブジ ェクトは通知サーバで運行時間を登録する。 ここで図１２を参照すると、この発明の実施例が動作することになるシステム のハードウェアを示す図が示されている。このハードウェアは移送網１１００の 周りに展開されており、この網はサービスプロバイダによってシステムの個々の ユーザに供されるデータサービスを運んでいる。網１１００を介して送られたデ ータは例えば音声とビデオとのいずれか一方もしくは両方の情報を含んでいるこ とになろう。個々のユーザは顧客の施設装置（ＣＰＥ）１１０１，１１０２の違 った部品によって網に接続される。各種の当事者で網サービスを提供したり実行 したりすることに関与している者は、例えばサービス小売人、サービスプロバイ ダ、及び網プロバイダなどであるが、この者が計算ノード８１０で移送網に接続 されている。各計算ノード８１０は各種のハードウェアとソフトウェアの特徴を 含んでおり、一般的に８１２として示してある。これらの中にはＤＰＥカーネル ８１１、ＤＰＥ原理による使用のためのプロトコルスタック、記憶機能１１２１ 、計算ノードで運行される応用１１２０が含まれている。 このシステムは各種のデータメモリ１１０５，１１０６を含み、図示のように 移送網に接続されている。データメモリ１１０５の１つは管理情報データメモリ を含み、網により提供されるサービスについての全体的な管理情報を送出するよ うにしている。 図１２に示したハードウェアと一緒に、目視化応用１８（図２）の例は個々の 計算用ノード８１０のいずれにおいても運用できることは理解できよう。この応 用は網を介して分散されたオブジェクトから情報を集め個々のオペレータの自分 の端末で図１０に示した情報スクリーンを使って報告できるようにしてもよい。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ， ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，Ｎ Ｏ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ， ＵＳ，ＵＺ，ＶＮ，ＹＵ

Claims (1)

1. 【特許請求の範囲】 １．複数のオブジェクトを有し、各オブジェクトには関連するフィルタがあっ て、このフィルタはそれと対応するオブジェクトによって送受されるメッセージ を傍受するようにされかつ該メッセージの表わす情報を事象収集器に送るように されている、分散形オブジェクトシステム。 ２．前記フィルタはさらに対応するオブジェクトの創生又は削除で事象収集器 に向けて情報を送るようにされている請求項１記載の分散形オブジェクトシステ ム。 ３．各クライアントオブジェクトが関連するクライアントフィルタを有し、こ のクライアントフィルタは該クライアントオブジェクトを表わしているクライア ントキーを有している、請求項１又は２記載の分散形オブジェクトシステム。 ４．前記クライアントオブェクトがサーバオブジェクト向けメッセージでその サーバオブジェクトを呼出しているものを送るときは、クライアントフィルタが 事象収集器に対してクライアントキーを表わす情報を送る請求項３記載の分散形 オブジェクトシステム。 ５．前記クライアントオブジェクトがサーバオブジェクト向けメッセージでそ のサーバオブジェクトを呼出しているものを送るときは、クライアントフィルタ がクライアントキーを表わす情報を送り出すメッセージに加える請求項３記載の 分散形オブジェクトシステム。 ６．前記送り出されるメッセージがサーバオブジェクトと関連するサーバフィ ルタによって受領され、このサーバフィルタはこの送り出されるメッセージの受 領でサーバキーをクライアントキーで置き換えるようにされている請求項５記載 の分散形オブジェクトシステム。 ７．前記サーバオブシェクトがクライアントオブジェクト向け応答メッセージ でそのクライアントオブジェクトに制御を戻すとするものを送るときは、サーバ フィルタがクライアントキーをサーバキーで置き換える請求項６記載の分散形オ ブジェクトシステム。 ８．前記応答メッセージがクライアントフィルタにより受領され、このクライ アントフィルタがクライアントキーを表わす別の情報を事象収集器に送るように されている請求項７記載の分散形オブジェクトシステム。 ９．複数のオブジェクトはそれ自体が分散形オブジェクトシステムとしてフィ ルタとは独立して相互作用をするようにされており、このフィルタはオブジェク トと関係はしているが、オブジェクトのいずれのコードも変更はしない前記請求 項１ないし８のいずれか１項記載の分散形オブジェクトシステム。 10．事象収集器に送られた情報は基本オブジェクトを識別する情報を含んでお り、この基本オブジェクトは外へ向けられたサーバが呼出しているメッセージで あって最終的には前記傍受したメッセージを生じさせているものの第１インステ ィゲータである請求項１記載の分散形オブジェクトシステム。 11．前記フィルタがＣＯＲＢＡコンプライアントである請求項１記載の分散形 オブジェクトシステム。 12．前記事象収集器によって集められた事象が事象発送機構によって処理され て、ユーザ応用に送られる前記請求項１ないし１１のいずれか１項記載の分散形 オブジェクトシステム。 13．前記ユーザ応用が構成可能であり、前記事象発送機構がこのユーザ応用に 対して関心のある事象だけをユーザ応用に送るようにされている請求項１２記載 の分散形オブジェクトシステム。 14．前記事象収集器は処理した事象を複数の個々のユーザ応用に送るようにさ れている請求項１２又は１３記載の分散形オブジェクトシステム。 15．前記個々のユーザ応用は同時に運行されているオブジェクトである請求項 １４記載の分散形オブジェクトシステム。 16．前記ユーザ応用はユーザに対して選ばれた事象を表示するようにされた目 視化応用である請求項１２ないし１５のいずれか１項記載の分散形オブジェクト システム。 17．ユーザ応用が欠陥検出応用であって、受領した事象に基づいて前記分散形 オブジェクトシステムの動作における欠陥を検出するようにされている請求項１ ２ないし１５のいずれか１項記載の分散形オブジェクトシステム。 18．前記ユーザ応用が制御応用であって、受領した事象に基づいて前記分散形 オブジェクトシステムの応用を制御するようにされている請求項１２ないし１５ のいずれか１項記載の分散形オブジェクトシステム。 19．前記ユーザ応用は課金応用であって、受領した事象に基づいて前記分散形 オブジェクトシステムの個々のユーザに課金するようにされている請求項１２な いし１５のいずれか１項記載の分散形オブジェクトシステム。 20．ユーザ応用が事象発送機構を登録するようになっている請求項１２ないし １９のいずれか１項記載の分散形オブジェクトシステム。 21．前記事象発送機構の事象発送工場が、ユーザ応用がする事象発送機構の登 録のための事象発送器を創生するようにされており、事象発送器はそれぞれのユ ーザ応用に向けて前記ユーザ応用の構成に基づいて送るようにされている請求項 ２０記載の分散形オブジェクトシステム。 22．図２ないし９を参照して実質的に特記したような分散形オブジェクトシス テム。 23．複数のオブジェクトを有する分散形オブジェクトシステムを特徴づける方 法であって、その構成は、各オブジェクトに関連するフィルタを用意して、その フィルタが対応するオブジェクトにより送受されるメッセージを傍受して、かつ 事象収集器に向けて前記メッセージを表わす情報を送るようにされており、この 分散形オブジェクトシステムはこの事象収集器により受領したメッセージに従っ て特徴づけがされている方法。 24．図２ないし９を参照して実質的に特記したような分散形オブジェクトシス テムを特徴づける方法。