JPH10500509A - オペレーティングシステムにおけるイベント分配装置及び方法 - Google Patents

Abstract

(57)【要約】 オペレーティングシステム、イベントを生成するとともにイベントがコンピュータ内で発生したことを検出するイベントプロデューサと、イベントがコンピュータ内で発生した場合にその通知を必要とするイベントコンシューマを含むコンピュータにおいて、イベントを分配するシステムが提供される。このシステムは、少なくとも一つのイベントコンシューマが通知を受けるべき特定のイベントセットを格納する格納部と、イベントプロデューサからイベントを受信し、受信したイベントと格納されたイベントセットとを比較し、適切なイベントコンシューマに適切なイベントを分配するイベントマネージャ制御ユニットと、制御ユニットからイベントを受信し、制御ユニットに適切なイベントを適切なイベントコンシューマに分配させるディストリビュータとを有する。

Description

【発明の詳細な説明】 発明の名称 オペレーティングシステムにおけるイベント分配装置及び方法 発明の背景 本発明は、コンピュータ内で発生したイベントに関する情報を分配する装置及 び方法に関する。特に、コンピュータ内の適切なエンティティ（実体データや実 体プログラム等）へそれらイベントを分配すべく管理するイベントマネージャに 関する。 本説明において、イベントはコンピュータにおけるあらゆる発生を総称するも のであり、そのコンピュータもしくは接続されたコンピュータ上で実行されるプ ログラムは、そのイベントを通知される必要がある可能性がある。イベントは、 例えば以下のような処理の発生を含むものである。すなわち、キーストローク、 マウスクリック、ディスクの挿入及び排出、ネットワークへの接続及び切断、コ ンピュータのスリープモードシャットダウンへの移行、ウィンドウの出現（例え ば、ウインドウの内容が再表示される必要が生じた場合）、新しいファイルの生 成、ディレクトリの名称変更、ファイルの内容変更、ボリュームの空きスペース の変化等である。 割り込みやエラー状態も、不定形なイベントの例として扱われる。特に、割り 込みはプログラムによって処理されることが必要である。そこで、イベントマネ ージャは不適切な解決となる。割り込みを扱うコードは割り込みの割り込み処理 に基づいてイベントを発生することができる。例えば、コンピュータは、ユーザ がフロッピーディスクを挿入したときに、割り込みを発生することができる。割 り込み自身は、イベントマネージャによって伝播されることはまずないが、割り 込みハンドラが“ディスク挿入”イベントを発生することは道理にかなっている 。エラー状態は類似している。大部分の時間において、システム上のコンピュー タプログラムの一つが、エラーを扱うことは必要なことであり、それゆえ、より 直接的なポイントツーポイント（point to point）機構が適切である。しかしな がら、 その性質上より忠告的であるエラーが存在し、これらのエラーはイベントを介し て送られることが好ましい。例えば、幾つかのポータブルコンピュータは、バッ テリーが低下した場合に電力消費を低減するための種々の処理が実行される。全 てのソフトウエアプログラムにその状態を知らせるために、“バッテリー低下” と呼ばれるイベントを発行し、電力消費を低減可能な全てのソフトウエアに当該 イベントによる処理を実行させることは好ましいことである。 最近のあらゆる周知のオペレーティングシステムは、コンピュータ内で発生し たイベントを管理するための幾つかの種類のメカニズムを有する。しかしながら 、これらのメカニズムは、イベントを管理するのにポイントツーポイント方式を 用いている。すなわち、イベントを生成あるいは検出するエンティティが該イベ ントを使用するエンティティにイベントを分配する。これを達成するために、イ ベントを生成あるいは検出する全てのエンティティが、コンピュータ内において イベントが発生した場合にどのエンティティにそのイベントを通知しなければな らないかを把握していなければならない。この構成は、非常に負荷が大きく、非 効率的である。その上、イベントを生成或いは検出する各エンティティが、それ が生成或いは検出可能な全てのイベントに関する情報を持たなければならないと ともに、これらのイベントに関連する全てのエンティティに関する情報を持たな ければならないので、これは資源集中的（resource intensive）である。この情 報は、広範であり、かつ定常的に変化するものである。そして、このため、改造 を困難なものとしている。 更に、ポイントツーポイント方式は柔軟性に欠ける。ポイントツーポイントに おいては、もし新たなイベントのコンシューマが存在した場合、その新たなコン シューマを知っている新たなバージョンのプロデューサがリリースされなければ ならない。或いは、新たな種類のイベントが必要となった場合、その新たな種類 のイベントをどのように分配するかを知っている新たなバージョンのイベントマ ネージャがリリースされなければならない。 従って、オペレーティングシステムにおける全ての種類のイベントを効率的に 扱えて、特定の種類のイベントに関する情報を、そのような情報を必要としてい るプログラムに分配するための装置を提供することが望まれている。このために 、 システムパフォーマンスを向上すること、そのような情報を分配するために必要 とされる資源を低減することもまた望まれている。これらの目的を達成するため に、各イベントプロデューサが全てのイベントコンシューマを知ることを不要と し、イベントプロデューサとイベントコンシューマとの間のコミュニケーション を容易とすることが可能な、イベントを管理するための装置を提供することが望 まれている。 発明の要約 本発明によれば、上記目的及びその他の課題は、イベント管理の集中化によっ て達成される。特に、コンピュータ内のイベントの分配を扱うイベントマネージ ャを提供することによって達成される。 一つの実施形態によれば、コンピュータにおいてイベントが発生したことを検 出するとともにイベントを生成するイベントプロデューサと、コンピュータにお いてイベントが発生したときにその通知を必要とするイベントコンシューマとを 少なくとも１つずつ含むコンピュータに、イベントに関する情報を分配するため のシステムが導入される。このシステムは、イベントコンシューマが通知を受け るべき特定のイベントセットを格納する格納手段と、イベントプロデューサから イベントを受信し、格納されたイベンドセットと比較し、適切なイベントコンシ ューマに適切なイベントを分配するイベント管理制御手段と、制御手段からのイ ベントを受信し、適切なイベントコンシューマに適切なイベントを分配するため に制御手段を管理するディストリビュータとを備える。 また、別の実施形態によれば、コンピュータ内で発生したイベントを分配する ためのシステムが提供される。このシステムは、イベントがコンピュータ内で発 生したことを検出してイベントを生成するイベントプロデューサと、コンピュー タ内においてイベントが発生したときにその旨の通知を必要とするイベントコン シューマとを備える。このイベントコンシューマは第１及び第２のコンシューマ のクラスを備えている。本システムは、更に、イベントコンシューマが通知され るべき特定のイベントセットを格納する格納手段と、イベントプロデューサから イベントを受信し、格納されたイベントセットと比較し、適切なイベントコンシ ューマに適切なイベントを分配するイベント管理制御手段と、イベント制御手段 に応答して、イベントコンシューマへイベントを渡すべきか否かを決定する分配 手段とを備える。また、イベント管理制御手段は、格納されたイベントセットに 基づいて第１のタイプの適切なイベントコンシューマにイベントを送る第１の手 段と、上記分配手段に応答する第２のタイプの適切なイベントコンシューマに該 イベントを送る第２の手段とを備える。 また、他の実施形態によれば、コンピュータにおいて発生するイベントを分配 するための方法が提供される。この方法は、コンピュータ内のイベントプロデュ ーサによってイベントが検出されたことを決定するステップと、格納手段にイベ ントコンシューマが通知されるべき特定のイベントセットを格納するステップと 、イベント制御手段において上記イベントプロデューサからのイベントを受信す るステップと、受信したイベントを格納されたイベントセットと比較するステッ プとを備える。本方法は、更に、分配手段において制御手段からのイベントを受 信するステップと、該制御手段に適切なイベントを適切なイベントコンシューマ に分配させるステップと、制御手段を介して適切なイベントを適切なイベントコ ンシューマに分配するステップとを備える。 本発明の更に他の目的、特徴及び付随する利点は、本発明に基づいて構成され た実施形態に関して添付の図面を参照してなされる以下の詳細な説明を読むこと により当業者に明らかとなるであろう。 図面の簡単な説明 以下、方法及び装置に関する一例としての好適な実施形態を参照し、また添付 の図面を参照して本発明のより詳細な説明を行う。添付図面は以下の通りである 。 図１は、本発明を実行可能な典型的なコンピュータのブロック図である。 図２は、本発明の一実施形態に関るイベントマネージャの構成を示すブロック 図である。 図３は、本発明に係るイベントキューのデータ構造の典型的な実施形態を示す 図である。 図４は、本発明に係るサブスクリプションマトリクスの典型的な実施形態を示 す図である。 図５ａは、本発明に係る加入データ構造の典型的な実施形態を示す図である。 図５ｂは、本発明に係るシーケンシャルコンシューマのエントリ構造の典型的 な実施形態を示す図である。 図６は、本発明に係るイベント種別ヘッダのデータ構造の典型的な実施形態を 示す図である。 図７は、本発明に係るイベントネームのデータ構造の典型的な実施形態を示す 図である。 図８は、本発明に係るイベントデータ構造の典型的な実施形態を示す図である 。 図９Ａ、９Ｂ、９Ｃ、９Ｄは、本発明の一実施形態に係る、イベントプロデュ ーサの観点及びイベントディストリビュータの観点からのイベントハンドリング 処理を示すフローチャートである。 図１０は、本発明の一実施形態に係るシーケンシャルコンシューマの観点から のイベントハンドリング処理を示すフローチャートである。 図１１は、本発明の一実施形態に係るブロードキャストコンシューマの観点か らのイベントハンドリング処理を示すフローチャートである。 発明の実施の形態 総括的に言って、本発明は、コンピュータ内で発生したイベントに関るコンピ ュータ内の異なるエンティティ間の効率的なコミュニケーションの必要性を認識 するものである。特に、コミュニケーションにおいては、コンピュータ内のエン ティティに他のエンティティで生成されたイベントについて通知することを要求 される。これらのコミュニケーションを扱うために要求される方法は、関与する エンティティが他のエンティティを識別できないという理由によって複雑なもの となっている。また、この方法は、イベントを知る必要のあるエンティティの識 別情報や、発生し得るイベントのリストが定常的に変化してしまうという理由で 、更に複雑化されている。 本発明のイベントマネージャの一つの到達目標は、これらの種類のコミュニケ ーションの大部分をサポートする共通のサービスを提供することである。コミュ ニケーションされるべき情報はイベントとして参照される。一つの実施形態によ れば、イベントは３つの部分によって記述される。イベントの種類を示すイベン ト識別子、イベントが発生するエンティティを特定するイベントサブジェクト、 及び当該イベントがどのように発生したかを記述するインベント情報である。コ ンピュータ内の、その情報のソースとなるエンティティは、イベントのプロデュ ーサとして参照される。ここで、イベントプロデューサは、イベントを生成する 、もしくはコンピュータハードウエアがイベントを発生したことを検出する、コ ンピュータ上のあらゆるソフトウエアである。そして、イベントプロデューサは 、生成もしくは検出した各イベントの記述を生成する。一方、そのような情報を 受信することを必要とするコンピュータ内のエンティティはイベントコンシュー マとして参照される。特に、イベントコンシューマは、イベントが発生したとき に通知されることを必要とするとともに、そのイベントの記述を通知されること を必要とするあらゆるプログラムである。イベントのプロデューサとコンシュー マの間の接続を調整する仲介サービスは、イベントのディストリビュータとして 参照される。 本発明の一実施形態によれば、２つのクラスのイベントコンシューマがある。 これらは、ブロードキャストコンシューマ及びシーケンシャルコンシューマであ り、イベントに関る他のコンシューマとの関係において相違する。ブロードキャ ストコンシューマは他のコンシューマとは無関係である。それらは、それら自身 が最終的にはイベントを通知される限りにおいて、他のコンシューマが存在する か否か、どのような順序でコンシューマがイベントの通知を受けたかについて知 る必要がない。一方、シーケンシャルコンシューマは、他のコンシューマとの間 に非常に明確な関係を有する。これらは、これら自身がイベントを処理している 間、そのイベントに関して他のいかなるコンシューマも通知を受けないことを要 求する。また、それらがイベントを受信した順序によって影響を与える機能を要 求する。加えて、多くのシーケンシャルコンシューマはイベント自身を改造する 機能や、イベントが他のコンシューマによって受信されるの阻止する機能をも要 求する。コンシューマは、失敗すること無しにイベントに反応しなければならな いかどうかに基づいて、シーケンシャルかブロードキャストとして定義される。 特に、シーケンシャルコンシューマは、それが関連するイベントの種類に反応し なければならない。そこで、ディストリビュータは、シーケンシャルコンシュー マからそれらのイベントを引き止めるべきではない。例えば、通信プログラムは 、接続のドロップを通知するイベントのシーケンシャルコンシューマとなる。通 信プログラムはそのようなイベントに応答する必要があるからである。 ブロードキャストコンシューマは、典型的には、それが関与する特定のイベン トセットを有し、可能な限り簡単にこのセットから次のイベントを通知されるこ とを要求する。多くのブロードキャストコンシューマは、限定されたサブジェク トのセットのみに対して発生するイベントに関与する。そこで、本発明の一実施 形態は、イベントを、それらが「何に」よって発生されたかに基づいてフィルタ リングする方法を提供する。加えて、ブロードキャストコンシューマが関与する イベントセットは、関与の即時性がそうであるように、常時変化する。こうして 、本発明の一実施形態は、コンシューマに、当該コンシューマに配布されるイベ ントセットを変更することを可能とする方法を提供する。最後に、ブロードキャ ストコンシューマがイベントを修正するためにイベントマネージャ制御ユニット にポーリングを行うかどうかに関して、或いはそれらが同期して通知を受けるべ きか否かに関して明瞭なパターンは存在しない。それゆえ、一つの実施形態によ れば、これらの両方のオプションがサポートされる。 図１は本発明に基づくソフトウエアが実行される典型的なコンピュータを示す ブロック図である。コンピュータ１０は、プロセッサ（ＣＰＵ）１２、外部記憶 装置１４、ディスク格納装置１６、入出力（Ｉ／Ｏ）コントローラ１８、入力デ バイス２０、出力デバイス２２、メモリ２４、上記エレメントを接続する共用シ ステムバス２６を含む。図１には、読み易さの目的のために、ただ一つの入力デ バイス及び出力デバイスが示されている。しかしながら、コンピュータ１０が、 １つより多くのそのようなデバイスを含み得ることは好ましいことである。プロ セッサ１２、外部記憶装置１４、ディスク格納装置１６及びメモリ２４は、バス ２６及びＩ／Ｏコントローラ１８を介して入力、出力デバイス２０、２２に接続 される。加えて、コンピュータ１０はネットワーク２７と通信可能に適用され得 る。 コンピュータ１０のメモリ２４内に格納されるのは、プロセッサ１２によって 実行され得る複数のソフトウエアである。これらのソフトウエアの一つはオペレ ーティングシステム２８である。一つの実施形態において、オペレーティングシ ステム２８は、複数のアドレス空間を維持することのできるマイクロカーネルオ ペレーティングシステムである。イベントマネージャ３０はオペレーティングシ ステム内に駐在する。典型的な実施形態において、本発明のコンピュータシステ ム１０は、カリフォルニア州クペルチノのアップルコンピュータ社によるアップ ルマッキントッシュ（商標）コンピュータシステムであり、これはマイクロプロ セッサと、イベントマネージャ３０を含むマイクロカーネルオペレーティングシ ステム２８を格納するメモリを有する。コンピュータシステムのコンポーネント は、本開示に基づいて当業者がなしうる範囲において変化され得るものである。 なお、本発明はマッキントッシュ（商標）環境において説明されるが、本発明を ＤＯＳ、Ｕｎｉｘ、或いは他のコンピュータ環境において実現することは、本発 明の範疇であり、また当業者の技術の範疇である。 本発明は、オペレーティングシステムにおいて発生するイベントを管理するイ ベントマネージャのアーキテクチャに関する。イベントマネージャのクライアン トはイベントコンシューマとイベントプロデューサを含む。すなわち、アプリケ ーションプログラムや、ファイルマネージャのようなオペレーティングシステム の種々の部分が含まれる。 一実施形態によれば、本発明はマイクロカーネルアーキテクチャのオペレーテ ィングシステムと協動する。ここで、カーネルはセマフォ同期メカニズムとメッ セージングシステムを提供する。メッセージングシステムは、メッセージオブジ ェクト及び、一つもしくはそれ以上のポートオブジェクトのセットを生成、維持 しする。メッセージングシステムは複数の特徴を有する。それは、各オブジェク トと協動されるべきクリエータ定義値（creator-defined value）を許可する。 メッセージングシステムは複数のオブジェクトが同じポートにマップされること 、メッセージがポートから受信されるかまたはそのポートに適切なタイプのメッ セージが送られたときにファンクションがコールされることを許可する。更に、 メッセージングシステムはメッセージの受信部に、メッセージが最初に送られる 先 のオブジェクトを決定し、そのオブジェクトのためのクリエータ定義値を導き出 すことを可能とする。そのようなマイクロカーネルアーキテクチャの一例は、Ｎ ｕＫＥＲＮＥＬ（商標）によって提供される。これはアップルマッキントッシュ （商標）コンピュータに用いられている。ＮｕＫＥＲＮＥＬ（商標）システムは 、出願継続中の米国特許出願０８／１２８，７０６（１９９３年９月３０日出願 ）の「コンピュータにおける仮想メモリの分散バッキングストアのためのシステ ム」、米国特許出願０８／２２０，０４３（１９９４年３月３０日出願）の「オ ブジェクト指向メッセージパッシングシステム及び方法」、そして本願の出願に 前後して、Ｔhomas Ｅ.Ｓaulpaugh及びＳteven Ｊ.Ｓzymanskiによって出願され る「オブジェクト指向メッセージフィルタリングのシステム及び方法」と題した 特許出願において説明されている。これら３つの特許出願は本願に参照として組 み込まれるものである． メッセージングシステムによれば，サービスがサーバによって提供され、その サービスを用いることを要求するソフトウエアはそのサーバのクライアントと呼 ばれる。メッセージはクライアントによって目標に送られ、サーバによって受信 される。メッセージはクライアントの代わりに機能を遂行するためにサーバに向 けられる。メッセージオブジェクトは、メッセージングシステムクライアントへ の種々の資源を表すアブストラクトエンティティである。これらのオブジェクト は、たとえば，サーバによって管理されるデバイス、ファイルもしくはウインド ウを表してもよい。クライアントはオブジェクトにメッセージを送り、これらオ ブジェクトはＯbjectＩＤにラベル付けされた識別子によって識別される。 メッセージポートはサービスを表すアブストラクトエンティティである。これ らのポートは、たとえば，デバイスドライバ，ファイルシステム、ウインドウマ ネージャを表すことができる。サーバはポートからのメッセージを受信し、これ らのポートはラベルＰortＩＤによって識別される。オブジェクトはポートに割 り当てられる。オブジェクトに送られたメッセージはそのオブジェクトのポート において受信される。ポート及びオブジェクトはサーバの代わりにメッセージン グシステムによって生成される。オブジェクトの生成は、オブジェクトに送られ たメッセージがリトリーブされるポートを指定することを要求する。 一実施形態によれば、メッセージングシステムはイベントマネージャによって 使用される。このイベントマネージャにおいて、イベントディストリビュータは 協動するポート及びオブジェクトを有し、また、シーケンシャルコンシューマは 協動するポートおよびオブジェクトを有する。そして、そのイベントマネージャ はポートおよび、各ブロードキャストコンシューマについてこのポートに割り当 てられたオブジェクトを維持する。イベントはイベントプロデューサによってメ ッセージとしてディストリビュータの協動オブジェクトに受け渡される。シーケ ンシャルコンシューマは関連するポートからメッセージを受信し、ブロードキャ ストコンシューマはイベントを要求するために、そのブロードキャストコンシュ ーマのために維持されるオブジェクトを介して、メッセージをイベントマネージ ャに送る。加えて、一つの実施形態によれば、イベントマネージャは、シーケン シャルコンシューマを実施するためにメッセージングシステムにおいて提供され るメッセージフィルタメカニズムを使用する。各シーケンシャルコンシューマの ために、メッセージフィルタはディストリビュータのＯbjectＩＤ上に生成され る。フィルタを介して受信されたコードは、整合性をチェックし（何が提供され 、何によって提供されたかに関する）、シーケンシャルコンシューマに適切なメ ッセージを送る。そのようなメッセージフィルタリングメカニズムの一例は、上 述の、Ｔhomas Ｅ.Ｓaulpaugh及びＳteven Ｊ.Ｓzymanskiによる特許出願に記載 されている。 図２は図１に示されたイベントマネージャ３０のアーキテクチャを示すブロッ ク図である。イベントマネージャ３０（図２において破線で示される）は複数の イベントディストリビュータ３４０、複数のイベントコンシューマ及び複数のイ ベントプロデューサ３００と機能上において接続され、これらと通信を行う。イ ベントディストリビュータの数は、システム内において可能な、異なるイベント の種類の数に対応する。 一つの実施形態によれば、複数のイベントコンシューマはブロードキャストコ ンシューマ３１０およびシーケンシャルコンシューマ３６０を含むことができる 。与えられたシステムが一つ或いは複数のブロードキャストコンシューマ、もし くは一つ或いは複数のシーケンシャルコンシューマのいずれかを含むこと、もし く はその双方を含むことは好ましいことである。 本発明によれば、イベントは”種別”によってグループ分けされ、たとえば、 全てのキーストロークは一つの種類のイベントであり、全てのマウスクリックは 別の種類のイベントであり、全ての新規ファイル作成は更に他の種類のイベント である。また、イベントを上記例とは異なるようにグループ分けすることもでき る。たとえば、特定キーの全ての押下は一つの種類のイベントである。これは、 少なくとも部分的に好ましい実施方法ではない。数種類のイベントがすぐに管理 不能となるからである。しかしながら、イベントをどのようにグループ分けする かの選定は、本開示により当業者がなし得る範囲で可変である。 イベントマネージャ３０は、イベントマネージャ制御ユニット３０５及びデー タ構造を有する。データ構造はサブスクリプションマトリクス３３０、シーケン シャルコンシューマデータベース３５０、ブロードキャストコンシューマ３１０ と１対１対応で提供される複数のイベントキュー３２０、イベントディストリビ ュータ３４０と１対１対応で提供される複数のイベント種別ヘッダ３３１を含む 。イベントマネージャ制御ユニット３０５は、イベントマネージャデータ構造を 管理する少なくとも一つのソフトウエアルーチンからなる。 イベントプロデューサ３００は、イベントを生成する、或いは他のエンティテ ィがイベントを生成したことを検出する、コンピュータ上のあらゆるソフトウエ アを表す。イベントプロデューサは、自身が生成もしくは検出した各イベントの 記述を生成する。各種のイベントは、複数のイベントプロデューサを有すること ができ、与えられたイベントプロデューサは複数種類のイベントを生成もしくは 検出することができる。イベントコンシューマは、ブロードキャストコンシュー マ３１０とシーケンシャルコンシューマ３６０を含み、イベントが発生したとき を通知されることを必要とするとともに、そのイベントの記述の通知を必要とす るあらゆるプログラムを表すものである。各種のイベントは、複数のイベントコ ンシューマを有することができ、与えられたイベントコンシューマは、複数種類 のイベントを通知されることを必要とする。 イベントコンシューマがイベントプロデューサとなること、或いはイベントプ ロデューサがイベントコンシューマとなることも有り得ることである。特に、あ る一つのソフトウエアがある一つのイベントを処理し、その応答として別の種類 のイベントを生成するというケースが多く存在する。たとえば、ファイルマネー ジャは“ディスク挿入”イベントを処理し、その挿入されたメディアにそのボリ ュームをマウントし、“新規容量”イベントを結果として生成する。与えられた プログラムが異なる種類のイベントに異なる加入を行うことも可能である。特に 、プログラムは幾つかの種類のイベントに対してはシーケンシャルコンシューマ として加入し、他の種類のイベントに対してブロードキャストコンシューマとし て加入することができる。 イベントキュー３２０はイベントマネージャ制御ユニット３０５によって保持 されるイベントのリストであり、各ブロードキャストコンシューマ３１０に対し 、ブロードキャストコンシューマが関与するイベントについての情報を保持する 。一つの実施形態によれば、イベントキュー３２０はファーストインファースト アウトリストとして構成される。また、たとえば、ディスク挿入イベントはマウ スクリックよりも常に高い優先度を有するとか、ディスクイベントプロデューサ はマウスイベントプロデューサよりも高い優先度を有するというような、イベン ト優先度やプロデューサ優先度によって並べられるリストのような他の適したス トレージ構造も使用可能である。図２において、イベントキュー＃１はブロード キャストコンシューマ＃１に関与するイベントのリストであり、イベントキュー ＃２はブロードキャストコンシューマ＃２に関与するイベントのリストである。 他も同様である。図２には４つのブロードキャストコンシューマ／キューのペア が示されているが、所定の時刻において何組のブロードキャストコンシューマ／ キューのペアが定義されていてもよい。 一つの実施形態によれば、イベントキュー３２０は図３に示されるようなフォ ーマットで格納される。すなわち、先頭サブスクリプション、最終サブスクリプ ション、最大イベント、イベント配列である。先頭及び最終サブスクリプション のフィールドは、対応するブロードキャストコンシューマ３１０の先頭及び最終 サブスクリプションへのポインタである。イベントサブスクリプションは、特定 のブロードキャストコンシューマが通知を必要とする特定のイベントセットの記 述である。最大イベントのフィールドは、そのコンシューマに対するキューにお いて維持されるイベントの最大数である。一つの実施形態によれば、イベント配 列のサイズは、クッションを提供するために、示された最大数よりも若干大きく してある。イベント配列は、エレメントの配列の形態で、発生したイベントのリ ストを格納する。ここで各エレメントは、対応するブロードキャストコンシュー マが加入したイベントとなる。シングル及びダブルのリンクされたリストやダイ ナミックスタックのような他の適した格納構造を用いることができるが、一つの 実施形態において、キューはサーキュラバッファに格納される。 サブスクリプションマトリクス３３０は全ての存在するイベントサブスクリプ ションについて情報を保持する構成である。特に、サブスクリプションマトリク ス３３０は、ブロードキャストコンシューマが関与するイベントのサブスクリプ ションのトラックを保つのに用いられる。 一方、複数のシーケンシャルコンシューマ３６０が定義され得る。図２におい ては、３つのシーケンシャルコンシューマ＃１、＃２、＃３が示されているが、 いくつのシーケンシャルコンシューマが定義されてもよい。シーケンシャルコン シューマデータベース３５０は複数のシーケンシャルコンシューマエントリから なる。これらシーケンシャルコンシューマエントリは、各シーケンシャルコンシ ューマ３６０が関与するイベントをならべたものである。 一つの実施形態において、サブスクリプションマトリクス３３０は図４に示さ れるような構成を有する。ここで、各サブスクリプションに対して格納される一 つのサブスクリプションストラクチャ３３００が存在する。イベントキューやイ ベント種構造に関するサブスクリプションのsparse arrayやダイナミックリスト のような他の適切な形態が使用されてもよい。サブスクリプションマトリクスに 格納されたサブスクリプションストラクチャ３３００はイベントキュー３２０及 びイベント種別ヘッダ３３１に接続される。特に、システムに知られた各イベン トの種類に対して一つのイベント種別ヘッダ３３１が存在し、こうしてイベント 種別ヘッダの数はイベントディストリビュータの数と等しくなる。イベント種別 ヘッダ３３１は、イベントマネージャ制御ユニット３０５が、どのディストリビ ュータが現在処理されているその種類のイベントを扱うかを決定するのに用いる 情報を格納する。レジスタディストリビュータ（後述）コールはイベント種別 ヘッダを生成する。 一つの実施形態によれば、サブスクリプション３３００はサブスクリプション マトリクス３３０に図５ａに示す形態で格納され、以下のフィールドを有する。 すなわち、イベントキューポインタ、イベント種別ヘッダポインタ、次サブスク リプション及び同一イベント、前サブスクリプション及び同一イベント、次サブ スクリプション及び同一キュー、前サブスクリプション及び同一キュー、イベン トサブジェクトである。イベントキューポインタは、サブスクリプションが属す るイベントキューへのポインタである。イベント種別ヘッダポインタは、サブス クリプションのサブジェクトであるイベントの種類に対するイベント種別ヘッダ へのポインタである。イベントサブジェクトはそのイベントが発生したストラク チャを識別する。残りのフィールドは他のサブスクリプションへのポインタであ る。 シーケンシャルコンシューマエントリの典型的なフォーマットは図５ｂに示さ れている。一つの実施形態によれば、エントリは以下のフィールドを含む。すな わち、イベント識別子、イベントサブジェクト、シーケンシャルコンシューマオ ブジェクトＩＤである。イベント識別子は、シーケンシャルコンシューマが関与 するイベントの種類を識別する。イベントサブジェクトはそのシーケンシャルコ ンシューマが関与するイベントのサブジェクトを識別する。シーケンシャルコン シューマオブジェクトＩＤは、シーケンシャルコンシューマデータベースにおい てエントリを生成したシーケンシャルコンシューマのＯbjectＩＤを識別する。 一つの実施形態によれば、シーケンシャルコンシューマデータベース３５０は、 サブスクリプションマトリクス３３０の一部であり、各シーケンシャルコンシュ ーマに対するサブスクリプションストラクチャへのポインタがある。図２に示さ れるもう一つの実施形態によれば、シーケンシャルコンシューマデータベース３ ５０は、上述のようにサブスクリプションマトリクス３３０とは別々に提供され る。イベントマネージャ制御ユニット３０５はデータ構造と検出されたイベント の比較を実行し、当該イベントがそのシーケンシャルコンシューマへ送られるべ きか否かを決定する。 一つの実施形態によれば、メッセージフィルタリングメカニズムが、イベント の発生時にそのイベントを適切なシーケンシャルコンシューマに提供するために 要求される情報を保持するのに用いられる。そのメカニズムは、上述のSaulpaug hとSzymanskiによる特許出願に記載されている。 一つの実施形態によれば、イベント種別ヘッダ３３１は図６に示されるフォー マットによって格納される。イベント種別ヘッダ３３１は以下のフィールドを有 する。すなわち、次ヘッダ、ディストリビュータオブジェクトＩＤ、イベント識 別子、先頭サブスクリプション、最終サブスクリプションである。次ヘッダフィ ールドは、イベント種別ヘッダの単一にリンクされたリストにおける次のヘッダ へのポインタである。ディストリビュータオブジェクトＩＤは対応するイベント ディストリビュータに対するディストリビュータのＯbjectＩＤである。イベン ト識別子は関連するディストリビュータが扱うイベントの種類を識別する。先頭 及び最終サブスクリプションフィールドは、当該イベントの種類のために定義さ れた先頭及び最終のサブスクリプションへのポインタである。 イベントディストリビュータ３４０は、適切なイベントを適切なブロードキャ ストコンシューマに分配するためにイベントサブスクリプションを解釈するプロ グラムである。一つの実施形態によれば、各種のイベントに対してイベントディ ストリビュータが存在する。特に、あらゆるイベントプロデューサによって検出 された全てのキーストロークを扱うイベントディストリビュータや、全てのマウ スクリックを扱うイベントディストリビュータを扱う別のイベントディストリビ ュータ等が存在する。 一つの実施形態によれば、どのブロードキャストコンシューマにイベントが通 知されるかはディストリビュータによって決定される。ディストリビュータがど のコンシューマに実際に通知するかに関して最終的な報告を行う間、イベントマ ネージャ制御ユニット３０５は、サブスクリプションマトリクス３３０を用いて 、イベントを要求するコンシューマのトラックをキープする。与えられたディス トリビュータは常に全ての関連するコンシューマに結果を与えるかもしれないし 、常に一つを選択するかもしれないし、各コンシューマをみていくつかを選択し 、他を排除するかもしれない。これは非常に柔軟なアーキテクチャを可能とする 。例えば、全てのアプリケーションがマウスクリックに関与する場合（それゆえ 全 てのアプリケーションがその種のイベントに加入しており）、唯一の（最前の、 或いはクリックされたウインドウに対するアプリケーションのいずれか）ものが 実際にそのイベントを受け取る。マウスクリックイベントディストリビュータは どの加入者が最前のアプリケーションであるかを決定し、そのイベントをそのア プリケーションのみに送る。他の例としては、いつ新規ファイルが生成されたか を知る必要のある数本のコードがあるような場合、全てのコードが通知されるべ きである。それゆえ、新規ファイルイベントディストリビュータは常に全ての加 入者にイベントを送る。 図２に示されるように、各ブロードキャストコンシューマ３１０は、イベント マネージャ制御ユニット３０５を介してそれぞれのイベントキュー３２０に機能 上接続されており、通信可能となっている。各ブロードキャストコンシューマ３ １０はまた、イベントマネージャ制御ユニット３０５を介してサブスクリプショ ンマトリクスにも機能上接続されており、通信可能となっている。イベントキュ ー３２０の各々もイベントマネージャ制御ユニット３０５を介してサブスクリプ ションマトリクス３３０に機能上接続されており、通信可能となっている。シー ケンシャルコンシューマデータベース３５０はイベントマネージャ制御ユニット ３０５と機能上接続され通信可能であり、シーケンシャルコンシューマ３６０は イベントマネージャ制御ユニット３０５を介してシーケンシャルコンシューマデ ータベース３５０と機能上接続され、通信可能となっている。複数のイベント種 別ヘッダ３３１は複数のイベントディストリビュータ３４０と機能上接続され、 これら複数のイベントディストリビュータ３４０は複数のイベントプロデューサ ３００と機能上接続されている。 各ブロードキャストコンシューマ３１０はイベントマネージャ制御ユニット３ ０５を用いてイベントキュー３２０を生成し、イベントが報告された時点からブ ロードキャストコンシューマがそのイベントを消費するまでの間、関与するイベ ントを保持する。各ブロードキャストコンシューマ３１０はイベントマネージャ 制御ユニット３０５へ通知を必要とする全てのイベントを記述した加入イベント のセットを通信する。この加入イベントのセットは、常時変更が可能である。イ ベントマネージャ制御ユニット３０５は、その情報を、イベントディストリビュ ータ３４０によって使用されるように、サブスクリプションマトリクス内に格納 する。 要約すると、本発明の一実施形態によれば、イベントプロデューサ３００はイ ベントを検出し、イベント記述を生成する。そして、イベントマネージャ制御ユ ニット３０５をコールすることで、これらの記述をイベントマネージャ３０に送 る。イベントマネージャ制御ユニット３０５はそのイベント記述を、シーケンシ ャルコンシューマデータベース３５０内のエントリに基づいて、各シーケンシャ ルコンシューマ３６０に順番に送る。イベントマネージャ制御ユニット３０５は 、その後、イベント記述を、そのイベントの種類に応答するイベントディストリ ビュータ３４０に送信する。イベントディストリビュータ３４０はイベントマネ ージャ管理部３０５をコールし、サブスクリプションマトリクス３３０内の情報 に基づいて適切と判断されたブロードキャストコンシューマ３１０にイベント記 述を送る。イベントマネージャ制御ユニット３０５は、最初にこれらの記述をイ ベントキュー３２０に格納することにより、適切なブロードキャストコンシュー マ３１０にイベント記述を与える。ブロードキャストコンシューマ３１０は、レ ディ状態である場合、対応するイベントキュー３２０内に格納された次のイベン ト記述をリトリーブするために、イベントマネージャ制御ユニット３０５をコー ルする。 アプリケーションプログラマインターフェース 本発明によれば、イベントコンシューマ、イベントプロデューサ及びイベント ディストリビュータは、イベントマネージャの製造者以外のサードパーティによ って記述されてよい。それゆえ、アプリケーションプログラマインターフェース （ＡＰＩ）は、これらサードパーティがイベントマネージャとコミュニケーショ ンできるように仕様を提供するべく定義されている。以下は、本発明に係るイベ ントマネージャとのコミュニケーションを可能とするＡＰＩの一実施形態である 。 イベント構造 一つの実施形態によれば、イベントは３つのパートから成る。すなわち、どの イベントが発生したか（イベント識別子）、何がイベントを発生したか（イベン トサブジェクト）、どのようにしてイベントが発生したか（イベント情報）であ る。処理可能なイベントセットが（オペレーティングシステムの他の部分の開発 者によって、或いはアプリケーションプログラマによって）拡張可能であること は望ましいので、“どの”の部分はイベントネームとして参照されるユニークな 識別子を定義する。一つの実施形態において、イベントネーム識別子は、ＯＳＴ ｙｐｅとして知られている４キャラクタコードとして実施される。本開示に基づ いて当業者によって置き換えられ得る他の適切な識別子が用いられてもよい。ま た、一つの実施形態によれば、識別子のペアであってもよい。特に、本開示にお いて記述された実施の形態は２つのＯＳＴｙｐｅを用いる。図７に示されたイベ ントネーム識別子の構造４５は典型的なものである。イベントサービス識別子は 、例えば文書処理プログラムといった、イベントを定義したサービスの“サイン ”もしくは名前として機能する。そして、イベント種別識別子は、例えば新規フ ァイル生成といったような、イベント自身を識別するものである。こうして、全 てのイベントの名前の集合が、名前空間として参照されるものであるが、サイン を制御することによって管理される。 イベント構造の“何が”のフィールドは、一実施形態においてイベントサブジ ェクトとして定義されるものであるが、これは定義することが難しい。イベント マネージャの全ての可能な使用が予期できず、それゆえ、“何が”として記述さ れるかもしれないハードウエアとソフトウエアエレメントの全ての形態も予期し 得なくなるからである。幸運なことに、イベントのこの部分のためにサポートさ れる必要のある共通のオペレーションは等価判定のためのテストである。すなわ ち、ここで等価とは、ブロードキャストコンシューマによって加入のために提供 された“何が”に対する等価性である。そして、イベントマネージャ制御ユニッ ト３０５は加入者の構造を知る必要はなく、未解釈のバイト配列として定義され 得る。本開示に基づいて当業者に明らかな範囲で、固定長、もしくは可変長フィ ールドのような、“何が”のフィールドの適切な形態が用いられ得る。 構造の“詳細”部分は、図８における情報フィールドであり、全体としてオー プンエンドとなっており、各イベントに関してのみならず、イベントの各瞬間に おいて潜在的に変化する。こうして、この構成の一つの実施形態はオープンエン ドのバイト配列となる。 図８は、本発明の一実施形態に係るイベント構造のブロック図である。イベン ト４０は、イベントネーム、イベントサブジェクト、バイトカウント、イベント 情報フィールドから構成される。イベントネームフィールドは“どの”を特定し 、イベントサブジェクトフィールドは“何が”を特定し、バイトカウント及びイ ベント情報フィールドは“どのように”を特定する。イベント情報は実データで あり、バイト数はそのデータ長を表す。 システムコール イベントプロデューサは、イベントマネージャ制御ユニット３０５にイベント を委ねるためのシングルコールとともに供給される。特に、そのシングルコール はイベントメッセージをイベントマネージャ制御ユニット３０５に送信する。本 実施形態によれば、イベントプロデューサは、そのイベントに対する応答を必要 としているすべてのコンシューマがそのシングルコールの処理を行う機会がある ことの確認を受信する。特に、そのコールが返答されると、ディストリビュータ は、すべてのシーケンシャルコンシューマがそのシングルコールを確認したこと を認知し、すべてのブロードキャストコンシューマに対してそのイベントがキュ ーされる（enqueue）。他の実施形態によれば、この確認は必要とされず省略す ることができる。本実施形態によれば、このシングルコールは、二つのコール（ ファインドディストリビュータ（ＦindＤistributer）とプロデュースイベント （ＰroduceＥvent））に分割し、この分割によって、その種類のイベントをどの ように分配するかを知るもの識別を知ることを効率的に行える。このＡＰＩをテ ーブル１に示す。 テーブル１とそれに続くテーブルはＣ言語で記述された構造定義を示している 。ここでＣ言語の記述例を示しているが、本発明は、当業者によって他の適合し たプログラミング言語によっても実行される。加えて、テーブル１に参照される コードは本実施形態に従う本発明の一つの実行例である。本開示に基づいて、当 業者によって他の実行方法も可能であることが理解されるであろう。 テーブル１において、ＯSStatusは、通常、シングルコールが完了したか否か を示すために用いられるリータン値として用いられる様式である。ＯptionＢits は、通常、シングルコールがどのように処理されるかにおける微小変化を特定す るためにユーザに許可するコールの入力パラメータとして用いられる。 コンシューマ 本発明の実施形態に従う上述の説明によれば、ブロードキャストコンシューマ とシーケンシャルコンシューマは、それらの関係において他のイベントのコンシ ューマと異なる。ブロードキャストコンシューマは、自身がイベントの通知を受 ける限りにおいて、他のコンシューマが存在するか否かを知る必要がないばかり か、どの順番でコンシューマがイベントを通知されるかを知る必要がない。シー ケンシャルコンシューマは、自身がイベントを処理する間は、イベントについて 通知される他のコンシューマが一つもないことを必要とし、一連のシーケンスの 中でイベントを受信する場合の影響に対する能力を必要とする。加えて、多くの シーケンシャルコンシューマは、他のコンシューマによってイベントが受信され ることを阻止したり、イベント自身を変更する能力を必要とする。 本実施形態によれば、ＡＰＩは“何が”に基づいてイベントをフィルタリング する方法を提供する。これは、イベントを通知されるサブジェクトの設定を制限 するブロードキャストコンシューマの許可を誰が必要とするかに基づく方法であ る。加えて、ＡＰＩは、ブロードキャストコンシューマが、常時、関与するイベ ントの設定を変更することを可能とする方法を供給する。このように、ＡＰＩは 、ブロードキャストコンシューマがイベントを収集するためにイベントマネージ ャ制御ユニット３０５をポーリングすることをサポートし、あるいは非同期通知 機能を供給するメッセージングシステムの使用によってブロードキャストコンシ ューマが非同期に通知され得ることをサポートする。 本実施形態に従うインタフェースにおいて、コンシューマは、関連するイベン トのリストを表現するコンシューマ構造を生成するためにイベントマネージャ制 御ユニット３０５をコールする。これらのコンシューマ構造は、呼び出し側にと っては不明瞭である（即ち、その詳細はイベントマネージャ制御ユニット３０５ だけが知らされるものである）。 本実施形態に従えば、このコンシューマ構造はイベントキュー３２０である。 ＡＰＩは、ブロードキャストコンシューマがイベントキューを生成するイベント マネージャ制御ユニット３０５をコールすることを許可する。特に、イベントキ ュー３２０は、ＣreateＢroadcastＣonsumerのコールの結果としてイベントマネ ージャ制御ユニット３０５によって生成され、ＤisposeＢroadcastＣonsumerの コールの結果として消去される。本実施形態のキューの詳細は図３に示される。 イベントキューは、コンシューマ名（特定のコンシューマを識別するためにディ ストリビュータによって使用される）、コンシューマのためにイベントキューに 格納することによってイベントマネージャ制御ユニット３０５がバッファする最 大イベント数を含んでいる。コンシューマは、無限量のバッファリングをイベン トマネージャ制御ユニット３０５には委ねられないので、この後者の値を供給す ることに応答する。この値が越えるべきとされた場合は、付加的なイベントが廃 棄される。そして、コンシューマが獲得する次のイベントは、イベントマネージ ャ制御ユニット３０５自身からのＯverrunイベントである。テーブル２のコード 例 においてこの特徴を示す。 ブロードキャストコンシューマがＥventＣonsumerＩＤを持つと、関連するイ ベントの種類に加入することになる。加入処理の一部において、ブロードキャス トコンシューマは、イベントの通知をコンシューマが必要とする場合を決定する ために照合されるべきイベントネーム（ＥventＮame）とイベントサブジェクト （ＥventＳubject）の両方を特定できる。イベントディストリビュータ３４０に よるイベントサブジェクト（ＥventＳubject）の照合の方法は、処理されるイベ ントの種類に依存する。本実施形態によれば、この照合は、バイト毎の比較によ って実行することができる。また、他の適応可能な実行方法を用いてもよい、例 えば、３つの種類が異なる加入目的が同一なイベントがある場合は、即ち、同一 のコンシューマにそれらのイベントが通知される場合は、それゆえ、これらのイ ベントは、たとえビットが実際に異なっていても同一のものとして比較される。 ＥventＣonsumerＩＤに関連するイベントのリストは、加入ブロードキャストコ ンシューマ関数（ＳubscribeＢroadcastＣonsumer）の使用によっていつでも拡 張することができる。また、イベントの種別は、非加入ブロードキャストコンシ ューマ関数（ＵnsubscribeＢroadcastＣonsumer）によってリストからいつでも 取り除くことができる。特定のイベントの種類が非加入である場合、既にそのコ ンシューマに収集された種類のイベントの手続は破棄される。これをテーブル３ に示す。 イベント処理 ホールドイベント（ＨoldＥvents）／アンホールドイベント（ＵnholdＥvents ）コールは、イベント処理において、ある特殊なケースを平易にするために供給 される。イベントの種類が保持されると、ブロードキャストコンシューマのため にこれらのイベントの依頼が収集される。しかしながら、それらのイベントが保 持されなくなるまで、それらのイベントはＣonsumeコールによるユーザへの返答 はなされない。この方法においては、イベントマネージャが特定の種類のイベン トがまだブロードキャストコンシューマと関連する状況を取り扱うが、これらの イベントの処理は一時的に不可能となるか、あるいは優先されない。他の実施形 態によれば、同様の機能が２つに分割されたブロードキャストコンシューマＩＤ を生成することによって提供され得る。これらの一方は非保持のイベントであり 他方は保持可能なイベントである。ブロードキャストコンシューマは、第２のＥ ventＣonsumerＩＤから消費する場合を選択することができる。しかしながら、 本実施形態では完全には実用的ではない、なぜなら、何がどのカテゴリに属する かを常に予想することはできないからであり、また、保持のための決定処理が、 しばしばイベントの処理サイクルから完全に取り除かれてしまうからである。本 実施形態に従うホールドイベント（ＨoldＥvents）／アンホールドイベント（Ｕ nholdＥvents）コールは、その決定処理を分割するための平易なインタフェ ースを供給する。これらのコールをテーブル４に示す。 最終的に、イベントに関係するリストが構築されると、ブロードキャストコン シューマは同期コールと非同期コールの二つのコールの一つを用いて収集された イベントを消費する。両方のコールは、キューを特定するためのコンシューマの objectＩＤを特定し、イベントがコピーされるバッファを提供する。更に、Ａsy ncコールが、新しいイベントでバッファが満たされた場合に実行される動作を記 述するＥventＮotifucation構造を要求する。一つの実施形態によれば、Ｅvent Ｎotifucation構造とＥventＩnformationＰtrはオペレーティングシステムのカ ーネルによって定義される型である。供給されたバッファがイベント記述を保持 するのに十分な大きさでない場合、記述の主要な部分がバッファへとコピーされ る。そして、残りの記述は捨てられる。これらのコールをテーブル５に示す。 ＦlushＥventsは、ブロードキャストコンシューマのために収集されたイベン トで、まだ消費されていないイベントを取り除くために用いられる。ブロードキ ャストコンシューマは、イベントネーム（ＥventＮame）（ワイルドカードを用 いることができる）とイベントサブジェクト（ＥventＳubject）を特定する。イ ベントマネージャ制御ユニット３０５は、記述が照合されたイベントと未処理の 収集されたイベントを処分するが、処理はしない。このコールをテーブル６に示 す。 シーケンシャルコンシューマはＡＰＩに対してかなり異なる要求を有している 。それらはイベントの伝達のボトルネックとなるように機能するので、それらの ＡＰＩは、最大スループットを得るように設計されるべきであり、イベントマネ ージャ制御ユニット３０５が次のシーケンシャルコンシューマあるいはブロード キャストコンシューマにイベントを渡すことができるときを提示するために、各 イベントの応答を要求するように構成すべきである。これに基づき、本発明の一 実施形態のＡＰＩでは、イベントは適切なコミュニケーション機能を用いて、メ ッセージとしてシーケンシャルコンシュームに渡されるものとし、これは、例え ば、上述で説明したマイクロカーネルオペレーティングシステムによって供給さ れるメッセージングシステムのようなものである。本実施形態によれば、シーケ ンシャルコンシューマは、次のイベントの要求をイベントマネージャ制御ユニッ ト３０５に送信し、応答のメッセージでイベント自身が返送される。本開示に基 づいて、当業者が採用し得る他の実行方法でも実現可能である。一実施形態によ れば、 シーケンシャルコンシューマは、迅速な応答時間を保証するために受信動作とプ ログラムの実行が重複することを許容する受任機能を介してあるいは非同期受信 によってメッセージを受信する。そのようなメッセージングシステムの一例は、 ＮｕＫＥＲＮＥＫ（登録商標）によって提供される。 一実施形態によれば、メッセージングシステムがファンネリングメカニズム（ funneling mechanism）を提供し、シングルポートと協動する複数のオブジェク トを有しているので、加入コールがシーケンシャルコンシューマに対しは必要と されない。その代わり、シーケンシャルコンシューマは、関連する各イベントの 種類に対するオブジェクトを生成することが要求され、また、これらのオブジェ クトはコンシューマが所望するあらゆる方法でポートと関連付けられ得る。これ らのオブジェクトは、後述するＡＰＩを用いてイベントの種類に関連付けられる 。上記構成の他の適切な実施形態も本開示に基づいて当業者が適用し得る範囲で ある。 一実施形態に従えば、コンシューマの実際のシーケンスは、メッセージフィル タリングメカニズムの使用によって、リストメッセージ、スクリーンメッセージ 、変更メッセージ、或いは再発送メッセージに明瞭に提供される。メッセージフ ィルタは、他の処理に優先してあるフィルターの使用を許可するために所定の優 先順位で順序付けすることができる、合成されたメッセージインターセプション デバイス上のソフトウェアである。このメカニズムの詳細は、上記のＳaulpaugh とＳzymansk1の名で出願された出願に記載されている。 ＩnstallＳequentialＣonsumerコールは、与えられた名前とサブジェクトのイ ベントが与えられたオブジェクトに渡されるべきであることをイベントマネージ ャ制御ユニット３０５に報告するために用いられる。名前、順序、オプションパ ラメータは、これらのイベントと関係のあるシーケンシャルコンシューマにイベ ントを与える実行の順番を決定するために用いられる。ＲemoveＳequentialＣon sumerコールはインストールされたシーケンシャルコンシューマを取り除くため に用いられる。インスタレーションコールとリムーバルコールをテーブル７に示 す。 一度シーケンシャルコンシューマがインストールされ、イベントを受信し或い は消費すると、イベントマネージャ制御ユニット３０５が次のシーケンシャルコ ンシューマ（シーケンシャルコンシューマがそれ以上ない場合にはブロードキャ ストコンシューマ）にイベントを渡すことができるように、シーケンシャルコン シューマは、そのイベントの処理を終えたときを提示することが必要である。特 に、シーケンシャルコンシューマは、イベント処理を完了したことを示すＮext Ｃonsumerコールを、イベントマネージャ制御ユニット３０５に対して作成する 。イベントマネージャ制御ユニット３０５は、次のシーケンシャルコンシューマ 、あるいは適切なブロードキャストコンシューマにイベントを渡す。そのイベン トを渡す代わりに、シーケンシャルコンシューマは、あらゆる様式のあらゆるコ ンシューマに対し分配されないようにイベントのハンドリングを宣言する能力を 有する。特に、シーケンシャルコンシューマは、上記のイベントの分配を禁止す るためのＥventＨandledコールを生成することができる。これらの二つのコール をテーブル８に示す。ＮextＣonsumerは、メッセージングシステムコールである ＣontinueＭessageを用いる。このＣontinueＭessageは、メッセージングシ ステムにおいてフィルタチェーンにおける次のオブジェクトに継続する自動フォ ワードコマンドとして実行される。また、ＥventＨandledは、メッセージングシ ステムコールであるＲeplyＴoＭessageを用いるこれは、チェーンにおけるすべ てのオブジェクトがそのメッセージを処理したことを特定する。このメカニズム の詳細は、上記のＳaulpaughとＳzymanskiの名で出願された出願に記載されてい る。 ディストリビュータ 上述したように、各ディストリビュータは異なる種類のイベントを処理するも のである。各ディストリビュータはそれゆえ、処理すべきイベントを知っている 必要がある。 一つの実施形態によれば、大部分のイベントが適切なシーケンシャルコンシュ ーマを介して発送され、このイベントに関連することを提示した全てのブロード キャストコンシューマにそのコピーが与えられる。デフォルト時の実施によれば 、イベントディストリビュータによるあらゆるイベントサブジェクトの整合チェ ックが全ての値に渡る直接的なバイト比較によってなされ、どのコンシューマが そのイベントを通知されなければないかを決定する。本開示に基づいて当業者に 明らかな範囲で、他の適切な実施の形態が採用され得る。 一つの実施形態によれば、デフォルトディストリビュータは、ある種のイベン トを全てのブロードキャストコンシューマに渡すべく提供される。例えば、バッ テリー低下イベントのようなイベントは、常に全ての関与するコンシューマに分 配される。デフォルトディストリビュータによって分配され得る各イベントはテ ーブル９において示されるＲegisterＥventＷithＤefaultＤistributorコールに よって、デフォルトディストリビュータに登録されなければならない。このコー ルは、システムの稼働中に、イベントの種別毎に１回ずつ行なわれ、それらのイ ベント を担当するデフォルトディストリビュータに通知される。 カスタムディストリビュータは、イベントマネージャ制御ユニット３０５に登 録され、デフォルトディストリビュータで扱われない種類のイベントを扱う。一 つの実施形態によれば、カスタムディストリビュータをイベントマネージャ制御 ユニット３０５に登録することは、イベントをオブジェクトに連携させるコール によって遂行される。ここで、そのコールは、関連するイベントが発生した場合 にイベントマネージャ制御ユニット３０５がどのディストリビュータでそのイベ ントの分配を扱うかを知ることができるように、イベントをオブジェクトに連携 させるものである。カスタムディストリビュータは独立的にロードされたサービ スであり、プロデューサとディストリビュータ間の全てのコミュニケーションが メッセージの送出及び受信によって達成される。処理及び分配を行うべくイベン トを受信するために、各ディストリビュータはＯbjectＩＤを提供しなければな らない。イベントは、そのＯbjectＩＤに対してプロデューサから送られること になる。カスタムディストリビュータの登録及び抹消のためのコールをテーブル １０に示す。 どのブロードキャストコンシューマがプロデューサによって報告されたイベン トの通知を受け取るべきかを決定する処理には、ディストリビュータがより複雑 な試行錯誤を適用する必要のある幾つかのケースがある。サブスクリプションマ トリクスにおける情報は、ディストリビュータがどのブロードキャストコンシュ ーマに通知するかを決定するのを補佐するものであり、ディストリビュータにと って有効である。一実施形態によれば、ディストリビュータは、それを要求して いないブロードキャストコンシューマにイベントを与えることはできない。そし て、ディストリビュータはサブスクリプションマトリクスを調べ、そのイベント を要求しているコンシューマを見つける。しかしながら、ディストリビュータは 、それを要求したブロードキャストコンシューマのサブセットのみにイベントを 与えることができる。ディストリビュータがイベントの分配に影響する必要があ るであろうこの種の方法は以下のものを含む。 １． イベントサブジェクトのマッチングをとる方法は、直接的なバイ ト比較よりも複雑である。考慮される必要のあるサブジェクト識別におけるサブ ストラクチャがあるか、もしくは、扱われる必要のあるワイルドカード処理の幾 つかのフォームがある。 ２． 特定のイベントは、おそらく一つであろうが、関連を提示してい るブロードキャストコンシューマのサブセットに送られることを必要としてよい 。例えば、マウスイベントは、それに関与するアプリケーションのうちの一つの 適切なアプリケーションに送られる必要がある。 ３． 関連付けられたイベント結合されることを必要としてもよい。例 えば、同じウインドウに対する複数の領域更新イベントは、アプリケーションが そのイベントを実際に処理するまで結合されるべきである。 なお、これらの可能な形態は、シーケンシャルコンシューマには何の影響も及 ぼさない。シーケンシャルコンシューマが必要とされる理由の一つが分配のプロ セスに影響を与えるものだからである。言い換えれば、シーケンシャルコンシュ ーマは、それらが関与するイベントの種類に対して反応しなければならないので 、そのようにラベル付けされる。こうして、ディストリビュータが特定のシーケ ンシャルコンシューマにイベントを送らないように選択するという状況はなくな る。 それゆえ、イベントマネージャ制御ユニット３０５は全ての生成されたイベント を、ディストリビュータに手渡す前に、シーケンシャルコンシューマのガントレ ット（gauntlet）を介して送る。 図９Ａ、９Ｂ、９Ｃは、本発明の実施形態にかかるイベントプロデューサの観 点、及びイベントディストリビュータの観点からのイベントハンドリング処理を 示すフローチャートである。 図９Ａに示されるように、イベントプロデューサは最初にイベントを検出、も しくは生成する（ステップ６００）。イベントプロデューサはイベント記述を生 成する（ステップＳ６０２）。そして、ブロードキャスト及びシーケンシャルコ ンシューマの双方の、適切なイベントコンシューマにイベントを送るために、イ ベントマネージャ制御ユニット３０５をコールする（ステップ６０４）。 図９Ｂは、本発明の一実施形態にかかるイベントマネージャ制御ユニット３０ ５によるイベントの処理を示す。以下では、コンピュータのエレメント間にイベ ントを送信するためにメッセージングシステムを使用した場合を説明するが、本 開示によって当業者には明らかとなる他の適切な形態によって実施されてもよい 。 ステップ６０６において、イベントプロデューサが、そのイベントがハンドリ ングされた時点を知ることを必要としているか否かを判断する。すなわち、その 要求を、同期或いは非同期のいずれで処理するかを判断する。もし、イベントプ ロデューサがいつそのイベントがハンドリングされたかを知る必要がなければ（ そのコールの入力パラメータによって示される）、プロデューサに戻され（ステ ップ６０８）、そして、この図における残りのステップを非同期にて処理する（ ステップＳ６１０）。イベントプロデューサが知ることを必要とする場合は、同 期による処理が行なわれる（ステップ６１２）。 テストは、ステップ６０６で送られたメッセージを非同期メッセージとするこ とによって実施される。さもなければ、それは同期メッセージである。特に、イ ベントプロデューサは、検出されたイベントに関るメッセージを送るためにイベ ントマネージャ制御ユニット３０５をコールする。プロデューサは応答を待つか 否かを示す値を有する入力パラメータを提供する。このケースにおいて、メッセ ージは同期して送られる。さもなければ、メッセージは非同期で送られる。取り 決めに従って、メッセージが同期として送られると、イベントマネージャ制御ユ ニット３０５は、そのメッセージが全てのシーケンシャルコンシューマによって 処理されるまで、コールから戻らない。もし、メッセージが非同期で送られるな ら、メッセージが送られるや否や、イベントプロデューサがメッセージが処理さ れたかどうかを知り得ないうちに、イベントマネージャ制御ユニット３０５は、 イベントプロデューサに戻る。 ステップ６１４において、イベントマネージャ制御ユニット３０５は、シーケ ンシャルコンシューマデータベース３５０内のイベント記述にマッチするエント リを有する各シーケンシャルコンシューマにイベントを送る。これは一度に一回 行なわれ、各シーケンシャルコンシューマは、イベントマネージャ制御ユニット ３０５をコールすることにより、次のシーケンシャルコンシューマへ送られるメ ッセージを有することができるか、あるいはイベントが処理されたことを宣言す ることができる。こうして、シーケンシャルコンシューマがそのイベントの処理 を完了した後、シーケンシャルコンシューマはそのイベントの処理を継続するべ きかどうか、もしくはそのイベントが処理されたのでそのイベント処理をストッ プするかどうかを示す（ステップ６１６）。そして、シーケンシャルコンシュー マがイベントをハンドリングしているかどうかの判断がイベントマネージャ制御 ユニット３０５によってなされる（ステップ６１８）。もしハンドリングされて いるならば、他のコンシューマへのイベントの分配が禁止され、処理はプロデュ ーサをコールする処理へ戻る。シーケンシャルコンシューマがイベントのハンド リングを行っていないことを示すと、シーケンシャルコンシューマが最後のもの かどうかを判断する（ステップ６２２）。もし最後でなければ、ディストリビュ ータはステップ６１６へ戻り、次のシーケンシャルコンシューマへイベントを分 配する。 次に図９Ｃを参照する。全てのシーケンシャルコンシューマへイベントが分配 されると（ステップ６２２）、イベントマネージャ制御ユニット３０５は、ブロ ードキャストコンシューマに分配するために、そのイベントの種類に応答するイ ベントディストリビュータにイベントを送る（ステップ６２４）。イベントはデ ィストリビュータへメッセージとして送られる。全てのフィルタがそれを処理し 、 何れもが応答しなくなった場合に（それによって、イベントがハンドルされたこ とを宣言する）、メッセージングシステムはそのイベントをディストリビュータ へ自動的に通過させる。例えば、この時点でイベントマネージャ制御ユニット３ ０５にイベントディストリビュータをコールさせるというような、本開示に基づ いて当業者が想到し得る他の適切な実施が可能である。 プロセス６２４を図９Ｄに示す。ディストリビュータはこのプロセスにおいて どのようにイベントを分配するかを決定する。一つの実施形態によれば、これは 、加入したコンシューマのどれがイベントを得るべきであるかを見極めるために 、その種類のイベントに対する全加入者を順番にならべるために、イベントマネ ージャ制御ユニット３０５をコールすることによってなされる。一つの状態は、 ディストリビュータが全てのもしくはいくつかのコンシューマにイベントを送る 必要がある場合であり、しかしながら、コンシューマが受信し処理するまでに、 イベントデータ自身を修正することを可能とする必要がある場合である（ステッ プ６２４０）。例えば、ウインドウ環境において、ウインドウが露出した場合（ 例えば、一番上のウインドウが終了した場合）、ウインドウ露出イベントが生成 される。露出されたウインドウの別の部分がさらに露出され得るかもしれないの で、ウインドウ露出イベントディストリビュータは、そのイベントが処理されて しまうまでに、このイベントを修正することを可能とすることを要求する。この 場合、ディストリビュータは、実際のメッセージのためにプレイスホルダ構造を 提出し、これを適切なコンシューマに与える。 プレイスホルダ構造は、イベントを識別するためにディストリビュータによっ て用いられるレファレンスコンスタントフィールド、ＲefＣonと、ディストリビ ュータから実データを得るために用いられるＯbjectＩＤを含む。ディストリビ ュータは、プレイスホルダを生成する際にＲefＣonフィールドの値を提供する。 そして、その値を取得し、実際のイベント記述を再度提供することを可能とする 。こうして、コンシューマが実際にプレイスホルダを消費しようとするとき、イ ベントマネージャ制御ユニット３０５はメッセージをＲefＣonを含む与えられた ＯbjectＩＤに送る。ディストリビュータは、バッファに、現在の実際のイベン ト記述を入れ、コンシューマのバッファはＣonsumeへ渡される。この機能は選択 さ れた或いは全てのコンシューマの双方に提供されるので、テーブル１１に示すよ うに２つのコールが提供される。全てのコンシューマがプレイスホルダを用いて イベントを通知されるならば（ステップ６２４８）、ＧiveＰlaxeholderＴoＡll Ｃonsumersコールが使用される（ステップ６２５０）。もし、選択されたコンシ ューマのみがプレイスホルダを用いてイベントの通知を受けるのであれば（ステ ップ６２４８）、ＧiveＰlaxeholderＴoＳelectＣonsumersコールが使用される （ステップ６２５２）。 もしディストリビュータがイベントデータを修正する必要がないなら、ステッ プ６２４０における判断の結果は「否」となる。そして、ステップ６２４２にお いて、全てのブロードキャストコンシューマがイベントを受信すべきかどうかを 判断する。なお、このような場合が常であるなら、自動的に全てのコンシューマ に通知するデフォルトディストリビュータを用いることは好ましいことである。 他方、特殊な処理がイベントのサブセットのみに要求され、そのサブセット内に 存在しないあらゆるイベントに要求されると、分配メカニズムを起動するために ＧiveＥventＴoAllＣonsumersコールが使用され得る（ステップ６２４４）。こ のコールをテーブル１２に示す。 メッセージを受信するためにディストリビュータがコンシューマのサブセット を選択することを必要とする状況は次のいずれかの理由で発生する。すなわち、 ディストリビュータが整合するいかなるサブジェクトをも処理する必要があるた め、あるいは、イベントの性質がステップ６２４０におけるテストへの応答がな いことによって検出された分配を制限することを要求するために発生する。特に 、サブジェクトフィールドのバイト毎の比較が要求されない場合、サブジェクト が整合するかどうかをディストリビュータが判断することになる。これを達成す るために、ＧiveＥventＴoＳelectＣonsumersコールが用いられる(ステップ６２ ４６)。そして、フイルタ関数、ＣonsumerＦilterＦunction、が、その種のイベ ントに加入している各コンシューマについてコールされる（それらが記述するサ ブジェクトにかかわらず）。もし、イベントがそのコンシューマに与えられるべ きものであれば、その関数は「真」を返す。そう出なければ、「偽」を返す。こ のコールをテーブル１３に示す。 ステップ６２４４、６２４６、６２５０、６２５２における各コールの後に、 ルーチンはイベントマネージャ制御ユニット３０５に戻る（ステップ６２５４） 。 再び、図９Ｃを参照する。ステップ６２５において、イベントマネージャ制御 ユニット３０５は図９Ｄにおいてどのコールが使用されたかに従ってイベントを エンキューする（enqueue）。一つの実施形態によれば、ファーストイン、ファ ーストアウト（ＦＩＦＯ）の順序でイベントはエンキュー、デキューされる。イ ベントコンシューマがイベントに関して動作レディ状態となると、イベントキュ ーにおける最上位のイベントをデキューして、そのイベントの要求に従った処理 がなされる。 もし、図９Ｂの各ステップが同期して処理される（ステップ６２６）と、ルー チンはステップ６２８にてプロデューサに戻る。さもなければ、ルーチンはプロ デューサのメッセージに応答する（ステップ６３０）。 図１０は、本発明の一実施形態にかかるシーケンシャルコンシューマの観点に よるイベントハンドリングプロセスを示すフローチャートである。まず、シーケ ンシャルコンシューマはイベントマネージャ制御ユニット３０５をコールし、イ ンストールする（ステップ７００）。本発明の一つの実施形態によれば、コンシ ューマはＯbjectＩＤを提供する。ＯbjectＩＤは、イベントがメッセージとして 送信される先を示す。例えば、イベント記述へのポインタとともにコールされる ファンクションポインタをコンシューマが提供可能とするというような、他の適 切な形態を採用することも可能である。また、このような適切な実施は、本開示 に基づいて当業者がなし得る範囲のものである。 シーケンシャルコンシューマは、イベントが発生するのを待つ間は、独自に処 理を行う（ステップ７０２）。一つの実施形態によれば、イベントがメッセージ として送られるので、与えられたオブジェクトを通してメッセージを受理、受信 するためにシーケンシャルコンシューマがメッセージングシステムをコールする 。プロセスが同期かあるいは非同期かによって、別のことがシーケンシャルコン シューマによってなされてもよい。 イベントが受信されたとき（ステップ７０４）、シーケンシャルコンシューマ は適切な方法でイベントに関して動作する（ステップ７０６）。そして、シーケ ンシャルコンシューマは、それが他のコンシューマ（シーケンシャルもしくはブ ロードキャスト）にこのイベントを報告するかどうかを、或いはそのイベントを 十分にハンドルしたので他のコンシューマはそれを見るべきではないのかどうか を判断する（ステップ７０７）。もしそのイベントが完了しており、他のものが それを見るべきでないと判断されたなら、イベントマネージャ制御ユニット３０ ５をコールすことによって、イベントハンドラメッセージが送られる（ステップ ７１１）。さもなければ、シーケンシャルコンシューマはイベントマネージャ制 御ユニット３０５をコールし、イベントが次のコンシューマに受け渡されるべき であることを通知する（ステップ７０９）。シーケンシャルコンシューマは、ス テップ７０２の待ち状態へ戻り、ループを形成する。 図１１は、本発明の一実施形態に係るブロードキャストコンシューマの観点か らのイベントハンドリングプロセスを示すフローチャートである。ブロードキャ ストコンシューマはまず、イベントマネージャ制御ユニット３０５をコールし、 ＣreateＣonsumerコールを用いてそれ自身を登録する。登録が行われると、ディ ストリビュータは、与えられたＯbjectＩＤによって参照されるオブジェクトを 介してメッセージの受信を開始する。これらのメッセージの内容は、それらイベ ントを検出する或いは生成するプロデューサによって生成された記述である。デ ィストリビュータはイベントマネージャ制御ユニット３０５に、現在存在するコ ンシューマのどれがイベントを受信すべきかを提示しなければならない。一つの 実施形態において、メッセージングシステムはイベントをプロデューサより送り 出し、シーケンシャルコンシューマを経てディストリビュータに届ける。ディス トリビュータはイベントマネージャ制御ユニット３０５を用いて適切なキューに イベントを置く。 イベントマネージャ制御ユニット３０５はコンシューマのためにイベントキュ ーを生成し、戻る（ステップ８０２）。そして、ブロードキャストコンシューマ は、イベントマネージャ制御ユニット３０５をコールし、それが関連する特定の イベントの種類に加入する（ステップ８０４）。イベントマネージャ制御ユニッ ト３０５は、コンシューマのトラックをキープするためにサブスクリプションマ トリクスにエントリを追加する（ステップ８０６）。 コンシューマはイベントマネージャ制御ユニット３０５をコールし、次のイベ ントを獲得する（ステップ８０８）。一実施形態によれば、これは、イベントマ ネージャ制御ユニット３０５へのメッセージの送信をコンシューマに行わせるこ とによって実施される。このメッセージに対する応答は、そのコンシューマに対 する次のイベントとなる。コンシューマは、これを同期もしくは非同期でおこな うオプションを有する。そして、コンシューマはメッセージを同期或いは非同期 のいずれかで送る。なお、本開示に基づいて当業者が行える範囲で他の適切な形 態を適用してもよい。コンシューマは、イベントに対応する動作を行い（ステッ プ８１０）、処理はステップ８０８に戻りループを形成する。 前述の詳細な実施形態は本発明の全体の性質を十分に開示するので、当業者は 、現在の知識を適用することにより、総括的な概念から逸脱することなく、直ち に修正したり、種々のアプリケーションに適応させたりすることができる。それ ゆえ、そのような適応化、改造は、開示された実施形態の手段及び等価の範囲に 含まれるべきものである。用語の表現は説明の目的で採用されたものであり、本 発明を限定するものではないことは理解されるべきである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者 ソルポー， トーマス， ユージーン アメリカ合衆国 カリフォルニア州 95120 サン ホセ， ブレト ハルト ドライブ 6938 (72)発明者 キーナン， ウィリアム， ジョン アメリカ合衆国 カリフォルニア州 94061 レッドウッド シティ ウエスト ウッド ストリート 1287

Claims (1)

1. 【特許請求の範囲】 １． コンピュータ内で発生したイベントを検出し、イベントを発生する少な くとも１つのイベント生成部と、コンピュータ内でイベントが発生したときにそ の通知を必要とする少なくとも１つのイベントコンシューマとを含み、イベント を分配するコンピュータにおいて、 前記少なくとも１つのイベントコンシューマが通知を受けるべき特定のイベン ドセットを格納する格納手段と、 前記イベント生成部からのイベントを受信し、受信したイベントと格納された イベンドセットとを比較し、適当なイベントコンシューマに適切なイベントを分 配するイベント管理制御手段と、 上記制御手段からのイベントを受信し、前記制御手段を指揮して、適当なイベ ントコンシューマに適切なイベントを分配させる分配手段と を備えることを特徴とするイベント分配システム。 ２． 前記分配手段はコンピュータ内で発生し得る各イベントの種類毎に分配 モジュールを備える ことを特徴とする請求の範囲第１項に記載の装置。 ３． 複数のイベントコンシューマがコンピュータ内に含まれ、複数のコンシ ューマは、 互いのコンシューマ間について関連性を有しないブロードキャストコンシュー マと、ここで、ブロードキャストコンシューマは、他のコンシューマに対して独 立に、且つ、コンシューマがイベントの通知を受けた順には無関係に動作し、 互いに関連付けられたシーケンシャルコンシューマと、ここでシーケンシャル コンシューマは、それぞれが自身の処理を行なっている間は、イベントが他のコ ンシューマには通知されないことを要求し、他のコンシューマに関連するイベン トを受信したときには影響を及ぼす機能を要求する ことを特徴とする請求の範囲第１項に記載の装置。 ４． 前記分配手段は、 ブロードキャストコンシューマがイベントを受信するまで、後続するイベント に基づいてそのイベントをモディファイする権利と共にブロードキャストコンシ ューマにイベントを送信するかを判定する手段と、 前記判定する手段による肯定判定に応じて、適当なブロードキャストコンシュ ーマに対してモディファイする権利と共にイベントを分配する手段とを備える ことを特徴とする請求項の範囲第３項に記載の装置。 ５． 前記分配手段は、 イベントをブロードキャストコンシューマに、そのイベントのモディファイ権 利と共に送信するかを判定する第１の手段と、 前記判定する第１の手段による肯定判定に応じて、そのイベントが全てのブロ ードキャストコンシューマに渡されるものかを判定する第２の手段と、 前記判定する第２の手段による肯定判定に応じて、全てのブロードキャストコ ンシューマにプレイスホルダとともにイベントを分配する手段と、 前記判定する第２の手段による否定判定に応じて、選択されたブロードキャス トにイベントをプレイスホルダとともに分配する手段と、 前記判定する第１の手段の否定判定に応じて、そのイベントが全ブロードキャ ストコンシューマに対して送信するものかを判定する第３の手段と、 前記判定する第３の手段による肯定判定に応じて、そのイベントを全てのブロ ードキャストコンシューマに分配する手段と、 前記判定する第３の手段による否定判定に応じて、選択されたブロードキャス トコンシューマにイベントを分配する手段とを備える ことを特徴とする請求の範囲第３項に記載の装置。 ６． 前記格納手段は、 ブロードキャストコンシューマが関連付けられているイベントの加入状態を格 納しているサブスクリプションマトリクスと、 シーケンシャルコンシューマが関連付けられたイベントのエントリを格納して いるシーケンシャルコンシューマデータベースとを備える ことを特徴とする請求の範囲第３項に記載の装置。 ７． 前記格納手段は、 前記分配手段から分配されたイベントを受信する各ブロードキャストコンシュ ーマ毎のイベントキューを備え、当該キューは、対応するブロードキャストコン シューマによってイベントが消費されるまでは分配されたそのイベントを記憶し ている、 ことを特徴とする請求の範囲第３項に記載の装置。 ８． 前記制御手段は、シーケンシャルコンシューマデータベースにおけるエ ントリに従って、イベントを連続してシーケンシャルコンシューマに渡す手段を 備えることを特徴とする請求の範囲第３項に記載の装置。 ９． 前記制御手段は、シーケンシャルコンシューマからのイベントハンドラ メッセージの受信に応じて、イベントの渡しを禁止する手段を備える ことを特徴とする請求の範囲第８項に記載の装置。 １０． コンピュータ内で発生したイベントを検出し、イベントを発生し、イベ ントの記述を発生するイベント生成部と、 コンピュータ内で発生したイベントの通知を必要とするイベントコンシューマ と、ここでイベントコンシューマは、コンシューマの第１及び第２のクラスを備 え、 イベントコンシューマに通知される特定のイベントセットを格納する格納手段 と、 イベント生成部からのイベントを受信し、受信したイベントと記憶されたイベ ントセットとを比較するイベント管理制御手段と、 前記イベント管理手段に応答して、そのイベントがイベントコンシューマに渡 すものかを決定する分配手段とを備え、 前記イベント管理制御手段は、 記憶されたイベンドセットに基づいて、適切な第１のクラスのイベントコンシ ューマにイベントを送信する第１の手段と、 前記分配手段に応じて、適切な第２のクラスのイベントコンシューマにイベン トを送信する第２の手段と を備えることを特徴とするコンピュータシステム。 １１． 前記分配手段はコンピュータ内で発生し得る各イベントの種類毎に分配 モジュールを備える ことを特徴とする請求の範囲第１０項に記載の装置。 １２． 前記第１のクラスのコンシューマは、互いに関連性を有するシーケンシ ャルコンシューマを備え、ここで、シーケンシャルコンシューマは、それぞれが 自身の処理を行なっている間は、イベントが他のコンシューマには通知されない ことを要求し、他のコンシューマに関連するイベントを受信したときには影響を 及ぼし、 前記第２のクラスのコンシューマは、互いのコンシューマ間について関連性を 有しないブロードキャストコンシューマを備え、ここで、ブロードキャストコン シューマは、他のコンシューマに対して独立に、且つ、イベントを確認した順と は無関係に動作する ことを特徴とする請求の範囲第１０項に記載の装置。 １３． 前記分配手段は、 ブロードキャストコンシューマがイベントを受信するまで、イベントを、後続 のイベントに基づいてそのイベントをモディファイする権利と共にブロードキャ ストコンシューマに送信するかを判定する手段と、 前記判定する手段による肯定判定に応じて適切なブロードキャストコンシュー マに対してモディファイする権利と共にそのイベントを分配する手段とを備える ことを特徴とする請求の範囲第１２項に記載の装置。 １４． 前記格納手段は、 ブロードキャストコンシューマが関連付けられているイベントの加入状態を格 納しているサブスクリプションマトリクスと、 シーケンシャルコンシューマが関連付けられたイベントのエントリを格納して いるシーケンシャルコンシューマデータベースとを備える ことを特徴とする請求の範囲第１２項に記載の装置。 １５． 前記格納手段は、 前記分配手段から分配されたイベントを受信する各ブロードキャストコンシュ ーマ毎のイベントキューを備え、当該キューは、対応するブロードキャストコン シューマによってイベントが消費されるまで分配されたイベントを記憶する ことを特徴とする請求の範囲第１２項に記載の装置。 １６． 前記制御手段は、シーケンシャルコンシューマデータベースにおけるエ ントリに従って、イベントを、連続してシーケンシャルコンシューマに渡す手段 を備える ことを特徴とする請求の範囲第１２項に記載の装置。 １７． 前記制御手段は、シーケンシャルコンシューマからのイベントハンドラ メッセージの受信に応じて、イベントの渡しを禁止する手段を備える ことを特徴とする請求の範囲第１６項に記載の装置。 １８． コンピュータ内で発生したイベントを分配する方法であって、 コンピュータ内のイベント生成部によって検出されたイベントを判定し、 通知すべきイベントコンシューマの特定のイベントセットを記憶手段に格納し 、 イベント生成部からのイベントをイベント制御手段で受信し、 受信したイベントと格納されたイベンドセットとを比較し、 制御手段からのイベントをコンシューマ手段で受信し、 前記制御手段を制御して、適切なイベントコンシューマに対して適切なイベン トを分配させ、 前記制御手段を介して、適切なイベントコンシューマに適切なイベントを分配 する 各工程を備えることを特徴とする方法。 １９． 前記イベントコンシューマは、ブロードキャストコンシューマ及びシー ケンシャルコンシューマを含む複数のコンシューマを備え、 前記ブロードキャストコンシューマは、他のコンシューマに対して独立に、且 つ、イベントを確認した順とは無関係に動作し、 前記シーケンシャルコンシューマは、それぞれが自身の処理を行なっている間 は、イベントが他のコンシューマには通知されないことを要求し、他のコンシュ ーマに関連するイベントを受信したときには影響を及ぼす ことを特徴とする請求の範囲第１３項に記載の方法。 ２０． 前記分配工程は、 ブロードキャストコンシューマがイベントを受信するまで、そのイベントを、 後続するイベントに基づいてそのイベントをモディファイする権利と共に、ブロ ードキャストコンシューマに送信するかを判定し、 該判定工程による肯定判定に応じて、適切なブロードキャストコンシューマに 対してモディファイする権利と共にイベントを分配する工程を備える ことを特徴とする請求の範囲第１９項に記載の方法。 ２１． 前記格納工程は、 ブロードキャストコンシューマが関連付けられているイベントの加入状態をサ ブスクリプションマトリクスに格納し、 シーケンシャルコンシューマが関連付けられたイベントのエントリをシーケン シャルコンシューマデータベースに格納する工程を備える ことを特徴とする請求の範囲第１９項に記載の方法。 ２２． 更に、 ブロードキャストコンシューマに対応するイベントキュー内の分配されたイベ ントを受信し、 対応するブロードキャストコンシューマで前記イベントが消費されるまでは、 前記イベントキューに分配されたイベントを格納する工程を備える ことを特徴とする請求の範囲第１９項に記載の方法。 ２３． 前記分配工程は、シーケンシャルコンシューマから、イベントの処理が 完了したことを示す継続メッセージの受信に応じて、シーケンシャルコンシュー マに連続してイベントを渡す工程を備える ことを特徴とする請求の範囲第１９項に記載の方法。 ２４． 前記分配工程は、シーケンシャルコンシューマからのイベントハンドラ メッセージの受信に応じて、イベントの渡しを禁止する工程を備える ことを特徴とする請求の範囲第２３項に記載の方法。