(57)【特許請求の範囲】
【請求項１】
複数のイベントソースおよび複数のイベントコンシューマを含むコンピュータシステムにおいて、条件に従って、前記複数のイベントソースにより発火され、サブスクリプションに基づき前記複数のイベントコンシューマによって受け取られるイベントを処理する方法であって、
前記複数のイベントソースから、前記複数のイベントソースおよび前記複数のイベントコンシューマによって認識されるスキーマ定義に従って構成された、複数のイベントについてのイベント通知を受け取るステップと、
前記複数のイベントコンシューマに各々関係付けられた１つまたは複数のサブスクリプションを受け取るステップであって、イベント通知の受け取り側イベントコンシューマに送られるべき特定の特性を持つイベントの通知であるイベント通知についてのサブスクリプション要求を、当該イベント通知の受け取り側イベントコンシューマとは異なる要求側エンティティであって当該イベント通知の受け取り側イベントコンシューマの代わりに当該サブスクリプション要求を行う要求側エンティティから受け取る、ステップと、
前記複数のイベントコンシューマに関連付けられた前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップと、
前記１つまたは複数のサブスクリプションを受け取るステップに応答して、複数の相互接続されたフィルタを含むフィルタのツリーを構成するステップであって、前記フィルタのツリーが前記１つまたは複数のサブスクリプションを他のすでに受け取っているサブスクリプションとともに受け入れるようにフィルタのツリーを構成するステップと、
前記１つまたは複数のサブスクリプションを受け入れた前記フィルタのツリーに基づき前記イベント通知をフィルタ処理するステップと
を備えたことを特徴とするイベントを処理する方法。
【請求項２】
前記１つまたは複数のサブスクリプションのいずれも前記イベント通知と一致しないことを判定するステップをさらに備え、前記イベント通知をフィルタ処理するステップは、
前記イベント通知をいかなるイベントコンシューマにも受け渡すことなく前記イベント通知を除去するステップ
を備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項３】
前記１つまたは複数のサブスクリプションの少なくとも幾つかが前記イベント通知と一致することを判定するステップをさらに備え、前記イベント通知をフィルタ処理するステップは、
前記イベント通知と一致するサブスクリプションと関連付けられたイベントコンシューマに前記イベント通知を渡すステップと、
前記イベント通知を前記イベント通知と一致するサブスクリプションと関連付けられていないイベントコンシューマに受け渡すことなく前記イベント通知を除去するステップと
を備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項４】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップをさらに備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項５】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップは、
前記要求側エンティティが前記受け取り側イベントコンシューマに送るイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップ
を備えたことを特徴とする請求項４に記載のイベントを処理する方法。
【請求項６】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップは、
前記要求側エンティティが前記受け取り側イベントコンシューマに送る前記特定の特性を持つイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップ
を備えたことを特徴とする請求項４に記載のイベントを処理する方法。
【請求項７】
前記イベント通知があてはまるイベント通知の分類に基づいたスキーマ定義によるポジションを判定するステップをさらに備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項８】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のポジションを表す要求を受け取るステップ
を備えたことを特徴とする請求項７に記載のイベントを処理する方法。
【請求項９】
前記イベントは、１つまたは複数のノードを有して構成され、前記スキーマ定義はノード特性を定義し、前記サブスクリプション要求は前記ノード特性を表すステートメントを含み、
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が前記スキーマ定義に当てはまるポジションに対応するかどうかを判定するステップ
を備えたことを特徴とする請求項８に記載のイベントを処理する方法。
【請求項１０】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のノード特性を表すサブスクリプション要求を受け取るステップ
を備えたことを特徴とする請求項９に記載のイベントを処理する方法。
【請求項１１】
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が前記スキーマ定義に当てはまるポジションに対応するかどうかを判定するステップと、
前記サブスクリプション要求によって表されるノード特性が、前記通知が前記スキーマ定義に当てはまるポジションに対応するノード特性に対応するかどうかを判定するステップと
をさらに備えたことを特徴とする請求項１０に記載のイベントを処理する方法。
【請求項１２】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のノード特性を表すサブスクリプション要求を受け取るステップ
を備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項１３】
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が当てはまる前記スキーマ定義によるポジションに対応するかどうかを判定するステップと、
前記サブスクリプション要求によって表されるノード特性が、前記通知が前記スキーマ定義に当てはまるポジションに対応するノード特性に対応するかどうかを判定するステップと
をさらに備えたことを特徴とする請求項１２に記載のイベントを処理する方法。
【請求項１４】
第１の通知チャネルで第１のタイプのイベント通知のみを受け取るステップをさらに備え、第１のタイプのイベント通知のみを受け取るステップはイベントソースからイベント通知を受け取るステップを備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項１５】
第２の通知チャネルで第２のタイプのイベント通知のみを受け取るステップをさらに備えたことを特徴とする請求項１４に記載のイベントを処理する方法。
【請求項１６】
前記サブスクリプション要求を受け取るステップは、
特定の特性を持つイベントをログに記録するサブスクリプション要求を受け取るステップ
を備えたことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項１７】
前記サブスクリプション要求を受け取るステップは、
特定の特性を持つリアルタイムイベントを受け取るサブスクリプション要求を受け取るステップ
を含むことを特徴とする請求項１に記載のイベントを処理する方法。
【請求項１８】
前記複数のイベントソース、および前記複数のイベントコンシューマのうち少なくとも１つは単一のコンピュータシステム内に常駐することを特徴とする請求項１に記載のイベントを処理する方法。
【請求項１９】
前記複数のイベントソース、および前記複数のイベントコンシューマのうち少なくとも１つは異なるコンピュータシステム内に常駐することを特徴とする請求項１に記載のイベントを処理する方法。
【請求項２０】
１つまたは複数のイベントソースおよび１つまたは複数のイベントコンシューマを含むコンピュータシステムにおいて、条件に従って、１つまたは複数のイベントソースにより発火され、サブスクリプションに基づき前記１つまたは複数のイベントコンシューマによって受け取られるイベントを処理する方法であって、
イベントソースから、前記イベントソースおよび前記イベントコンシューマによって認識されるスキーマ定義に従って構成されたイベントについてのイベント通知を受け取るステップと、
１つまたは複数のイベントコンシューマに各々関係付けられた１つまたは複数のサブスクリプションを受け取るステップであって、イベント通知の受け取り側イベントコンシューマに送られるべき特定の特性を持つイベントの通知であるイベント通知についてのサブスクリプション要求を、当該イベント通知の受け取り側イベントコンシューマとは異なる要求側エンティティであって当該イベント通知の受け取り側イベントコンシューマの代わりに当該サブスクリプション要求を行う要求側エンティティから受け取る、ステップと、
１つまたは複数のイベントコンシューマに関連付けられた前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップと、
前記イベント通知と一致するサブスクリプションを提示したそれぞれのイベントコンシューマに前記イベント通知を渡すステップと、
前記１つまたは複数のサブスクリプションを受け取るステップに応答して、複数の相互接続されたフィルタを含むフィルタのツリーを構成するステップであって、前記フィルタのツリーが前記１つまたは複数のサブスクリプションを他のすでに受け取っているサブスクリプションとともに受け入れるようにフィルタのツリーを構成するステップと、
前記１つまたは複数のサブスクリプションを受け入れた前記フィルタのツリーに基づき前記イベント通知を前記イベント通知と一致するサブスクリプションを提示しなかったイベントコンシューマに受け渡すことなく前記イベント通知を除去するステップと
を備えたことを特徴とするイベントを処理する方法。
【請求項２１】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップをさらに備えたことを特徴とする請求項２０に記載のイベントを処理する方法。
【請求項２２】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップは、
前記要求側エンティティが前記受け取り側イベントコンシューマに送るイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップ
を備えたことを特徴とする請求項２１に記載のイベントを処理する方法。
【請求項２３】
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップは、
前記要求側エンティティが前記受け取り側イベントコンシューマに送る前記特定の特性をイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定するステップ
を備えたことを特徴とする請求項２１に記載のイベントを処理する方法。
【請求項２４】
前記イベント通知の分類に基づいたスキーマ定義による前記イベント通知があてはまるポジションを判定するステップをさらに備えたことを特徴とする請求項２０に記載のイベントを処理する方法。
【請求項２５】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のポジションを表す要求を受け取るステップ
を備えたことを特徴とする請求項２４に記載のイベントを処理する方法。
【請求項２６】
前記イベントは、１つまたは複数のノードを有して構成され、前記スキーマ定義はノード特性を定義し、前記サブスクリプション要求は前記ノード特性を表すステートメントを含み、
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が前記スキーマ定義に当てはまるポジションに対応するかどうかを判定するステップ
を備えたことを特徴とする請求項２５に記載のイベントを処理する方法。
【請求項２７】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のノード特性を表すサブスクリプション要求を受け取るステップ
を備えたことを特徴とする請求項２６に記載のイベントを処理する方法。
【請求項２８】
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が前記スキーマ定義に当てはまるポジションに対応するかどうかを判定するステップと、
前記サブスクリプション要求によって表されるノード特性が、前記通知が前記スキーマ定義に当てはまるポジションに対応するノード特性に対応するかどうかを判定するステップと
をさらに備えたことを特徴とする請求項２７に記載のイベントを処理する方法。
【請求項２９】
前記要求側エンティティからサブスクリプション要求を受け取るステップは、
前記スキーマ定義内のノード特性を表すサブスクリプション要求を受け取るステップ
を備えたことを特徴とする請求項２０に記載のイベントを処理する方法。
【請求項３０】
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合するステップは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が当てはまる前記スキーマ定義によるポジションに対応するかどうかを判定するステップと、
前記サブスクリプション要求によって表されるノード特性が、前記通知が前記スキーマ定義に当てはまるポジションに対応するノード特性に対応するかどうかを判定するステップと
をさらに備えたことを特徴とする請求項２９に記載のイベントを処理する方法。
【請求項３１】
第１の通知チャネルで第１のタイプのイベント通知のみを受け取るステップをさらに備え、第１のタイプのイベント通知のみを受け取るステップはイベントソースからイベント通知を受け取るステップを備えたことを特徴とする請求項２０に記載のイベントを処理する方法。
【請求項３２】
第２の通知チャネルで第２のタイプのイベント通知のみを受け取るステップをさらに備えたことを特徴とする請求項３１に記載のイベントを処理する方法。
【請求項３３】
前記イベントソース、および前記イベントコンシューマのうち少なくとも１つは単一のコンピュータシステム内に常駐することを特徴とする請求項２０に記載のイベントを処理する方法。
【請求項３４】
前記イベントソース、および前記イベントコンシューマのうち少なくとも１つは異なるコンピュータシステム内に常駐することを特徴とする請求項３３に記載のイベントを処理する方法。
【請求項３５】
コンピュータを、１つまたは複数のイベントソースおよび１つまたは複数のイベントコンシューマを含み、条件に従って、前記１つまたは複数のイベントソースにより発火され、サブスクリプションに基づき前記１つまたは複数のイベントコンシューマによって受け取られるイベントを処理するコンピュータシステムとして、動作させるためのコンピュータプログラムであって、前記コンピュータに、
１つまたは複数のイベントコンシューマに各々関係付けられた１つまたは複数のサブスクリプションの受信を検出し、当該１つまたは複数のイベントコンシューマに送られるべき特定の特性を持つイベントの通知であるイベント通知についてのサブスクリプション要求の受信であって、当該イベント通知の受け取り側イベントコンシューマとは異なる要求側エンティティであって当該イベント通知の受け取り側イベントコンシューマの代わりに当該サブスクリプション要求を行う要求側エンティティからのサブスクリプション要求の受信を検出することと、
イベントソースからのイベント通知であって、前記イベントソースおよび前記イベントコンシューマによって認識されるスキーマ定義に従って構成されたイベントについてのイベント通知の受信を検出することと、
１つまたは複数のイベントコンシューマに関連付けられた前記１つまたは複数のサブスクリプションと前記イベント通知とを照合することと、
前記イベント通知と一致するサブスクリプションを提示したそれぞれのイベントコンシューマに前記イベント通知を渡すことと、
前記１つまたは複数のサブスクリプションの受信を検出することに応答して、複数の相互接続されたフィルタを含むフィルタのツリーを構成するステップであって、前記フィルタのツリーが前記１つまたは複数のサブスクリプションを他のすでに受け取っているサブスクリプションとともに受け入れるようにフィルタのツリーを構成することと、
前記１つまたは複数のサブスクリプションを受け入れた前記フィルタのツリーに基づき前記イベント通知を前記イベント通知と一致するサブスクリプションを提示しなかったイベントコンシューマに受け渡すことなく前記イベント通知を除去することと
を実行させることを特徴とするコンピュータプログラム。
【請求項３６】
前記コンピュータプログラムは、前記コンピュータに、
前記要求側エンティティがイベント通知にサブスクライブするセキュリティ権限を持つかどうかを判定することを実行させることを特徴とする請求項３５に記載のコンピュータプログラム。
【請求項３７】
前記コンピュータプログラムは、前記コンピュータに、
前記イベント通知の分類に基づいたスキーマ定義による前記イベント通知があてはまるポジションを判定することを実行させることを特徴とする請求項３５に記載のコンピュータプログラム。
【請求項３８】
前記要求側エンティティからのサブスクリプション要求の受信を検出することは、
前記スキーマ定義内のポジションを表す要求の受信を検出することを特徴とする請求項３７に記載のコンピュータプログラム。
【請求項３９】
前記１つまたは複数のサブスクリプションと前記イベント通知とを照合することは、
前記サブスクリプション要求によって表されるスキーマ定義のポジションが、前記イベント通知が前記スキーマ定義に当てはまるポジションに対応するかどうかを判定することを特徴とする請求項３８に記載のコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、イベントを処理する方法及びシステムに関する。より具体的には、イベント通知技術に関連し、通知チャネルへのサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎｓ）に基づきイベント通知を実行する、イベントを処理する方法及びシステム並びにコンピュータプログラムプロダクトに関する。
【０００２】
【従来の技術】
理にかなった意思決定を下すためには適切なタイムリーな情報にアクセスできる必要があるということにほとんどが同意するであろう。コンピュータは、このような情報へのアクセス能力を大幅に高めており、それで現代は「情報時代」と称されることが多い。
【０００３】
情報のアクセス方法には、同期または「プル指向」と呼ばれる方法がある。つまり、情報の要求が提示される（submitted）ごとに情報のアクセスが行われる。情報に対し同期アクセスを実行するのでは不効率な場合もある。たとえば、関連はあるが予期していない情報もある。もちろん、ユーザやアプリケーションは通常であれば、予期されていない情報を要求することを知らない。そこで、対象のイベントが非同期に発生した場合、または言い換えるとイベントが発生したかどうかを問い合わせる対応する要求をすることなく、ユーザまたはアプリケーションに通知する技術が開発された。
【０００４】
対象のイベントとして、たとえば、コンピュータが不安定な状態になっていることを知っていればデータを保存したいので、コンピュータのエラーが発生したというイベントもある。また、特定のデータフィールドに特定の値が入っているかどうか、またはデータフィールドの組合せに特定の組合せのデータ値が含まれているかを知りたい場合もある。たとえば、投資家がその年の特定の日時に株価が特定の価格を下回ったかどうかを知りたい場合がある。また、たとえば特定の送信者から送られた電子メールを受信するなどの他の非同期イベントを知りたい場合もある。
【０００５】
イベントの発生の通知を受けることができる特定のアプリケーションにイベントログがある。従来のイベントログは、通常、アプリケーションまたはユーザが関心を持つイベントに関係なく、さまざまな主題に関する多数のイベントを記録する。ユーザが特定のイベントシーケンスを判定することに関心がある場合、ユーザは通常、ログ全体を表示して、注目するイベントを目でみて追跡し適切な結論を引き出すことになる。たとえば、コンピュータシステムがクラッシュしたとする。ネットワーク管理者はイベントログを表示し、すべての情報を取捨選択して無関係の情報の中から関係のある情報を選び、コンピュータシステムがクラッシュした理由について関連する情報に基づき結論を引き出すことができる。
【０００６】
人間の頭脳が驚異的な心理作用を実行できることはよく理解されている。たとえば、人間のユーザであれば、無関係の情報の中から関連する情報を容易に区別できることが多く、情報の表し方に一貫性のある構造がごくわずかしかなくてもその関連性のある情報に基づき判断を下すことができる。しかし、コンピュータシステムだと、予測できる構造を持たない情報を解釈する能力に大きな制限がある。
【０００７】
そこで、ログエントリに何らかの予測可能な構造を持たせ、コンピュータが情報をある程度解釈できるようにする。たとえば、従来のイベントログ技術では限られた数のフィールドをイベントエントリごとに割り当てる。このようなフィールドとしては、たとえば、イベントＩＤ、イベントソースＩＤ、イベントタイプ（たとえば、情報、警告、または重大度レベルを上げる際のエラー）、および記述などがある。イベントエントリを表すために使用されるフィールドの数とタイプには通常、拡張性がない。したがって記録できるイベント情報のタイプは極めて制約される。
【０００８】
このような制限を幾分緩和する従来の方法として、イベントエントリの記述フィールドに何らかのあらかじめ定められた構造を持つ記述のドラフトをアプリケーションに作成させる方法がある。そうしてから、その構造を理解するアプリケーションがそのあらかじめ定められた構造を使用して記述を取捨選択し意図した意味を抽出することができる。しかし、その記述を解釈するアプリケーションがそのあらかじめ定められている構造を認識している必要がある。従来、イベント記述（ｅｖｅｎｔ  ｄｅｓｃｒｉｐｔｉｏｎ）を作成する際にそれぞれのアプリケーションはそれ独自のあらかじめ定められた構造を使用している。そのため、記述フィールドを構造化する方法に関する標準化を欠いているので、イベントごとに対するイベント記述は解釈が困難な場合がある。
【０００９】
また、イベントログは、アプリケーションまたはユーザのイベントに対する関心に関係なく、すべてのイベントを記録するので、対象でないイベントエントリを作成するのに貴重なコンピュータ処理およびメモリ資源を無駄にすることも考えられる。
【００１０】
【発明が解決しようとする課題】
従来のシステムには上述したように、イベントの解釈に制約があり、イベントの処理が効率的でないという点において、未だ改善の余地があった。
【００１１】
本発明は、このような課題に鑑みてなされたもので、その目的とするところは、イベントを広範に解釈でき、あまり対象でないイベントを処理する際には処理およびメモリ資源を減縮するイベント通知技術を実現した、イベントを処理する方法及びシステムを提供することにある。
【００１２】
【課題を解決するための手段】
従来技術の上記の問題点は、たとえばスキーマの定義により定義されたあらかじめ定められている構造に従ってイベントが構造化されているサブスクリプションベースのイベント通知を実行する方法、システム、およびコンピュータプログラムプロダクトを対象とする本発明の原理により克服される。
【００１３】
本発明により、分散コンピュータネットワークまたは単一のコンピュータシステムであっても、多数のイベントソースおよび多数のイベントコンシューマ（ｅｖｅｎｔ  ｃｏｎｓｕｍｅｒｓ）を含むことができる。多数の通知「チャネル」が、イベントソースとイベントコンシューマの間に確立される。それぞれのチャネルは特定のスコープ（ｓｃｏｐｅ）に対応する。たとえば、１つのチャネルでエラーデバッグイベント（ｄｅｂｕｇｇｉｎｇ  ｅｒｒｏｒ  ｅｖｅｎｔｓ）を受け取り、他のチャネルで電子メール関連イベントを受け取り、さらに他のチャネルでカレンダー通知イベント（ｃａｌｅｎｄａｒ  ｒｅｍｉｎｄｅｒ  ｅｖｅｎｔｓ）を受け取ることができる。それぞれのチャネルは、特定の特性を持つイベント通知へのサブスクリプションを受け取ることができる。さらに、それぞれのチャネルは、チャネルに対するサブスクライバ（ｓｕｂｓｃｒｉｂｅｒｓ）およびパブリッシャ（ｐｕｂｌｉｓｈｅｒｓ）の権利を判定するための自身のセキュリティを保持することができる。通知サービス全体を複数のチャネルに分割することにより、各チャネルのセキュリティの制御性が向上する。
【００１４】
各通知チャネルはスキーマ定義を使用して通知を管理することができる。イベントコンシューマから受け取ったイベントサブスクリプションは目的のイベント通知がスキーマ定義内で取るポジションを識別するステートメントを使用する。イベントサブスクリプションではさらに、そのポジションにある対象のイベントと関連する特性または属性を識別することもできる。これは、スキーマ定義内のノードポジションおよび対象の子ノードの属性を識別する従来のＸＰＡＴＨステートメントを使用して実行できる。
【００１５】
その後、チャネルは１つまたは複数のイベントソースからイベント通知を受け取る。イベント通知はＸＭＬ（eXtensible [eXtended] Markup Language）フラグメント（fragment）の形をとることができる。さらにチャネルは、スキーマ定義により示されている通りに、受信されたＸＭＬフラグメントが取るポジションを判定する。サブスクリプションごとに、またイベント通知ごとに、チャネルはイベント通知をサブスクリプションと突き合わせて照合する。特に、チャネルはイベント通知のポジションおよび属性がイベントサブスクリプションのポジションおよび属性と一致するかどうかを判定する。一致が見つかれば、イベントがコピーされ、対応するサブスクリプションで指定されている受信者に転送される。一致が見つからない場合、そのイベントはコピーされない。
【００１６】
この照合操作を実行する１つの方法として、フィルタを各サブスクリプション要求に割り当てる方法がある。各フィルタは、イベント通知を受け取り、それらのイベント通知を特定のサブスクリプションと突き合わせて照合するように設計される。これは、サブスクリプションは少ない場合にうまく機能するが、サブスクリプションが多くなると不効率である。
【００１７】
フィルタ処理操作をより効率的なものにするために、サブスクリプション要求をフィルタの決定ツリー（ｄｅｃｉｓｉｏｎ  ｔｒｅｅ）に縮小することができる。たとえば、サブスクリプションがすべて、１つは識別子５を持ちもう１つは識別子６を持つ２つのプロセスから発火されたイベントに対応するとする。決定ツリー内のルートフィルタは、イベントサブスクリプションがプロセス５または６以外のプロセスによって発火されたかどうかを調べるテストを実行できる。もしそうであれば、イベント通知がルートフィルタで即座にフィルタ処理される。したがって、ツリー内の他のフィルタはそのイベント通知を処理するのにリソースを無駄にする必要がなかった。ツリーは、各サブスクリプション要求への応答として再構成され、各イベント通知に必要な平均的処理リソースを削減できる。この構造により、処理を効率的なものにし、リアルタイムのイベント通知処理をサポートすることができる。
【００１８】
このイベント通知システムを利用すると、イベントコンシューマはイベント通知のフィルタ処理を制御することができることに留意されたい。それに応じてイベント通知は除去され、イベントコンシューマの要求に合わせて処理を維持する。イベントコンシューマがロギングアプリケーション（ｌｏｇｇｉｎｇ  ａｐｐｌｉｃａｔｉｏｎ）であった場合、対象のイベント通知のみがログに記録される。これは、通常、イベントに関心のあるイベントコンシューマがあろうがあるまいが非常に多くのイベントを記録する従来のログ記録メカニズムとは、著しく対照的である。
【００１９】
また、イベント通知はスキーマ定義によって指示された特定のポジションを持つことにも注意されたい。それぞれの特定のイベントタイプはそのタイプのイベントに適した対応するスキーマを持つことができる。イベントコンシューマは、その対応するスキーマを使用して、イベント通知からデータを読み出すだけでなく、そのデータの意味を理解し、データに基づいてインテリジェントな決定を下すことができる。さらにスキーマ定義では、イベントタイプの数を拡大し、所定のイベントタイプに対応するフィールドの数を増やすことができる。そのため、ロギングは、特定の固定された数およびタイプのフィールドに制限される必要はなく、与えられたイベントタイプについてより適切なものとすることができる。
【００２０】
本発明の他の特徴および利点については以下で説明するが、ある程度その説明から明らかであろうし、また本発明を実施することにより学ぶこともできる。本発明の特徴と利点は、特許請求の範囲で特に指摘されている機器および組合せを使って実現し得ることができる。本発明のこの特徴および他の特徴については以下の説明を読むとより完全に明らかになるであろうし、あるいは以下で述べているように本発明を実施することにより学ぶこともできる。
【００２１】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。本発明の上記の利点および特徴およびその他の利点および特徴を得る方法を説明するために、上記で簡単に説明した本発明より具体的な説明を付属の図面に示されている特定の実施形態を参照しながら行う。これらの図面は本発明の代表的な実施形態を示しているだけであり、したがってその範囲を制限しているものとみなされないことを理解していることを前提として、付属の図面を使用して本発明を具体的内容および詳細とともに説明する。
【００２２】
本発明は特定のスコープにそれぞれ対応するイベントチャネルを使用してサブスクリプションベースの通知を実行する方法、システム、およびコンピュータプログラムプロダクトに拡大適用される。各チャネルはスキーマ定義を使用して通知を管理する。イベントコンシューマから受け取ったイベントサブスクリプションは目的のイベント通知がスキーマ定義に従って取るポジションを識別するステートメントを使用する。イベントサブスクリプションではさらに、そのポジションにある対象のイベントと関連する特性または属性を識別することもできる。
【００２３】
その後、チャネルは１つまたは複数のイベントソースからイベント通知を受け取る。イベント通知はＸＭＬフラグメントの形をとることができる。さらにチャネルは、ＸＭＬフラグメントがスキーマ定義内で取るポジションを判定する。チャネルはイベント通知とサブスクリプションとの照合を行う。特に、チャネルはイベント通知のポジションおよび属性がスキーマ定義内においてイベントサブスクリプションのポジションおよび属性と一致するかどうかを判定する。一致が見つかれば、イベント通知がコピーされ、対応するサブスクリプションで指定されている受信者に転送される。一致が見つからない場合、そのイベント通知はコピーされない。
【００２４】
本発明の実施形態は、後述のさまざまなコンピュータハードウェアコンポーネントを含む汎用または専用のコンピュータシステムを含むことができる。本発明の範囲内の実施形態はさらに、格納されているコンピュータ実行可能命令またはデータ構造体を搬送するまたは保持するためのコンピュータ読み取り可能な媒体も含む。このようなコンピュータ読み取り可能な媒体は、汎用または専用のコンピュータシステムからアクセス可能な、任意の入手可能な媒体でよい。例として、ただしこれに限るわけではないが、このようなコンピュータ読み取り可能な媒体は、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）、ＥＰＲＯＭ（electrically erasable PROM）、ＣＤ（compact disc [disk]）−ＲＯＭまたはその他の光ディスクストレージ、磁気ディスクストレージまたはその他の磁気ストレージデバイス、またはコンピュータ実行可能命令またはデータ構造体の形で目的のプログラムコード手段を搬送または格納するために使用でき、かつ汎用または特殊目的コンピュータシステムによってアクセスできるその他の媒体などの物理的ストレージ媒体を含むことができる。
【００２５】
情報をネットワークまたは他の通信接続（有線、無線、または有線と無線の組合せ）を介してコンピュータシステムまたはコンピュータデバイスに転送または供給するときに、その接続をコンピュータ読み取り可能な媒体としてみなしても適切である。したがって、このような接続はコンピュータ読み取り可能な媒体と呼んでも適切である。上記の組合せはコンピュータ読み取り可能な媒体の範囲に収まるであろう。コンピュータ実行可能命令は、たとえば、汎用コンピュータシステムまたは専用コンピュータシステムに何らかの機能または機能のグループを実行させる命令およびデータを含む。
【００２６】
当業者には、本発明が、パソコン、ラップトップコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ（Personal Digital Assistant）、ページャなど、さまざまな種類のコンピュータシステム構成のネットワークコンピューティング環境で実施できることは明白であろう。本発明はさらに、通信ネットワークを通じてリンクされている（有線リンク、無線リンク、または有線と無線リンクの組合せにより）ローカルおよびリモートコンピュータシステムが両方ともタスクを実行する分散コンピューティング環境で実施できる。分散コンピューティング環境では、プログラムモジュールをローカルとリモートの両方のメモリストレージデバイスに配置できる。
【００２７】
図１および以下の説明は、本発明を実施できる適当なコンピューティング環境について簡潔に述べた一般的な説明である。必要というわけではないが、本発明について、コンピュータシステムによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明する。一般に、プログラムモジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。コンピュータ実行可能命令、附随のデータ構造、およびプログラムモジュールは本発明で開示する方法のステップを実行するプログラムコード手段の例を表す。このような実行可能命令または附随のデータ構造の特定のシーケンスは、このようなステップで説明される機能を実行する対応する動作の例を表す。
【００２８】
図１を参照すると、本発明の原理に関する適当なオペレーティング環境は、プロセッサ１２１、システムメモリ１２２、およびシステムメモリ１２２を含むさまざまなシステムコンポーネントをプロセッサ１２１に結合するステムバス１２３を含む、従来のコンピューティングデバイス１２０の形態の一般的なコンピューティングデバイスを含む。システムバス１２３には、さまざまなバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種類のバス構造がある。システムメモリは、読み取り専用メモリ（ＲＯＭ）１２４およびランダムアクセスメモリ（ＲＡＭ）１２５を備える。起動時などにコンピュータ１２０内の要素間の情報伝送を助ける基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）１２６は通常、ＲＯＭ１２４に格納される。
【００２９】
コンピュータ１２０はさらに、磁気ハードディスク１３９への読み書きを行う磁気ハードディスクドライブ１２７、リムーバル磁気ディスク１２９への読み書きを行う磁気ディスクドライブ１２８、およびＣＤ−ＲＯＭまたはその他の光媒体などのリムーバル光ディスク１３１への読み書きを行う光ディスクドライブ１３０を備えることもできる。磁気ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０は、ハードディスクドライブインタフェース１３２、磁気ディスクドライブインタフェース１３３、および光ドライブインタフェース１３４によりそれぞれ、システムバス１２３に接続される。ドライブおよび附随のコンピュータ読み取り可能媒体は、コンピュータ１２０用のコンピュータ実行可能命令、データ構造、プログラムモジュール、およびその他のデータを格納する不揮発性ストレージを提供する。本発明で説明している例示的な環境では磁気ハードディスク１３９、リムーバル磁気ディスク１２９、およびリムーバル光ディスク１３１を採用しているが、磁気カセット、フラッシュメモリカード、ＤＶＤ（digital versatile disk）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどの、データを格納するための他の種類のコンピュータ読み取り可能な媒体を使用することもできる。
【００３０】
磁気ハードディスク１３９、リムーバル磁気ディスク１２９、リムーバル光ディスク１３１、ＲＯＭ１２４、またはＲＡＭ１２５には、オペレーティングシステム１３５ａ、１つまたは複数のアプリケーションプログラム１３６ｃ、その他のプログラムモジュール１３７ａ、およびプログラムデータ１３８ａなどの１つまたは複数のプログラムモジュールを含むプログラムコード手段を格納できる。
【００３１】
ユーザは、キーボード１４０、ポインティングデバイス１４２、またはマイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどその他の入力デバイス（図には示されていない）を介してコンピュータ１２０にコマンドおよび情報を入力できる。これらの入力デバイスやその他の入力デバイスは、システムバス１２３に結合されているシリアルポートインタフェース１４６を通じて、プロセッサ１２１に接続されることが多い。それとは別に、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などのその他のインタフェースにより入力デバイスを接続することもできる。モニタ１４７やその他の表示デバイスも、ビデオアダプタ１４８などのインタフェースを介してバス１２３に接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカやプリンタなどの他の周辺出力デバイス（図に示されていない）を備える。
【００３２】
コンピュータ１２０は、リモートコンピュータ１４９ａ、１４９ｂなどの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することもできる。リモートコンピュータ１４９ａ、１４９ｂは、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の一般のネットワークノードでもよく、通常は、コンピュータ１２０に関係する上述の要素の多くまたはすべてを含むが、メモリストレージデバイス１５０ａ、１５０ｂおよびその関連アプリケーションプログラム１３６ａ、１３６ｂのみが図１に示されている。図１に示されている論理接続は、ここでは例で示されているがそれに限らないローカルエリアネットワーク（ＬＡＮ）１５１とワイドエリアネットワーク（ＷＡＮ）１５２を含む。このようなネットワーキング環境は、オフィス規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットではよくある。
【００３３】
ＬＡＮネットワーキング環境で使用する場合は、コンピュータ１２０はネットワークインタフェースまたはアダプタ１５３を介してローカルネットワーク１５１に接続される。ＷＡＮネットワーキング環境で使用する場合は、コンピュータ１２０は、インターネットなどのワイドエリアネットワーク１５２上で通信を確立するためのモデム１５４、無線リンク、またはその他の手段を備える。モデム１５４は、内蔵でも外付けでもよいが、シリアルポートインタフェース１４６を介してシステムバス１２３に接続される。ネットワーク環境では、コンピュータ１２０またはその一部に関して述べたプログラムモジュールは、リモートメモリストレージデバイスに格納できる。図に示されているネットワーク接続は例であり、ワイドエリアネットワーク１５２を介して通信を確立するその他の手段を使用できることは理解されるであろう。
【００３４】
図１は本発明の適当なオペレーティング環境を表しているが、本発明の原理は必要ならば適当な修正を加えて本発明の原理を実装することができるシステムにおいて採用することができる。図１に示されている環境は、説明のためのみであり、決して、本発明の原理が実装されるさまざまな環境の小さな一部さえ表すものではない。
【００３５】
図２は、多数の通知チャネル２２０（チャネル２２１および２２２を含む）を介して多数のイベントコンシューマ２３０（コンシューマ２３１から２３６を含む）と通信している多数のイベントソース２１０（ソース２１１から２１５を含む）の概略を示している。それぞれのイベントソース２１０は、イベント通知を発生または転送するイベントソースでよい。各イベントコンシューマ２３０は、イベント通知を他のイベントコンシューマに転送するだけであってもイベント通知を処理することができるイベントコンシューマとしてよい。チャネルの意味は以下でさらに詳細に述べられる。５つのイベントソース、６つのイベントコンシューマ、および２つのチャネルが図２の例に示されているが、本発明は特定の数のイベントソース、イベントコンシューマ、およびチャネルに限られない。実際、本発明の原理の利点の１つは、任意の数のイベントソース、イベントコンシューマ、またはチャネルに合わせて拡大できるという点である。
【００３６】
イベントソース２１０およびイベントコンシューマ２３０は、図１を参照して説明したコンピュータ１２０などの単一のコンピュータシステム内に配置することができる。ただし、イベントソース２１０および／またはイベントコンシューマ２３０の少なくとも幾つかは分散環境内の他のコンピュータシステム上に配置することができる。
【００３７】
チャネル２２０は、ある種の相手をそれぞれ対象とするイベントのライブストリーム（ｌｉｖｅ  ｓｔｒｅａｍ）を表す。イベントソース２１０のどれかで、イベントをその相手をターゲットとするチャネルにパブリッシュ（publish）することができる（セキュリティチェックを条件とする）。チャネルは、よく知られる傾向のある一般的使用のチャネル、またはプライベートアプリケーションのチャネルである。図２の例では、ソース２１１、２１３、２１４は、チャネル２２１にパブリッシュするセキュリティ権限を持ち、一方、コンシューマ２３２、２３３、および２３４はチャネル２２１によって提供されるイベントにサブスクライブ（subscribe）するセキュリティ権限を持つ。ソース２１４および２１５は、チャネル２２２にパブリッシュするセキュリティ権限を持ち、一方、コンシューマ２３４および２３５はチャネル２２２によって提供されるイベントにサブスクライブするセキュリティ権限を持つ。
【００３８】
単一ソースで複数のチャネルにパブリッシュできる場合がある。たとえば、ソース２１４はイベントをチャネル２２１と２２２の両方にパブリッシュする。ソース（たとえば、ソース２１２）はまったくチャネルにパブリッシュできない場合がある。同様に、単一コンシューマで複数のチャネルにサブスクライブできる場合がある。たとえば、コンシューマ２３４はチャネル２２１と２２２の両方にサブスクライブしている。他方、コンシューマ（たとえば、コンシューマ２３１および２３６）はまったくどのチャネルにもサブスクライブできない場合がある。
【００３９】
チャネルは、特定の相手を対象とする任意のイベントストリームとすることができる。相手は「全員」とすることができ、その場合どんなイベントもそのチャネルにパブリッシュできる。しかし、相手がさらに特定の相手に絞られている場合、特有の利点が得られる。たとえば、あるチャネルが「ディスクアクセス」チャネルであれば、ディスクのアクセスに関係するイベントのみをパブリッシュできる。より固有のチャネルを「ディスク読み出しアクセス」チャネルとすれば、ディスクへの読み出し要求に関係するイベントのみをパブリッシュできる。他のチャネルは、割り込みに関係するイベントのみをパブリッシュできる「割り込みチャネル」とすることもできる。他のチャネルは、ネットワークを介して送受信することに関係するイベントに焦点を絞った「ネットワークチャネル」とすることができる。他のさらに固有のチャネルを電子メールに関係するイベントのみに的を絞った「電子メール受信」チャネルとすることができる。
【００４０】
さまざまなイベントコンシューマが特定のチャネルタイプに関与すると思われる。たとえば、デバッギングアプリケーションはディスクアクセス、ディスク読み出しアクセス、および割り込みチャネルからのイベントに関与する。電子メールとメッセージ送受信のアプリケーションは、ネットワークおよび電子メール受信チャネルに関与する。この説明を検討した後、当業者であれば本発明の原理を採用できるチャネルのタイプおよび範囲には無限の可能性のあることを理解するであろう。
【００４１】
特定のタイプのイベントコンシューマの１つにロギングアプリケーションがある。チャネルはそれぞれ、イベントログを関連付けられないか、あるいは１つまたは複数のイベントログを関連付けられる。イベントロギングはチャネル全体を通して関連している共通アプリケーションであるため、ロギングアプリケーションをチャネル自体に組み込むことができる。しかし、ロギングアプリケーションは概念上、単なるもう一つのイベントコンシューマにすぎない。したがって、この説明の大部分において、ロギングアプリケーションは他のイベントコンシューマと全く同じように取り扱うことができる。
【００４２】
図３は、チャネル３００の構造を詳しく説明している。たとえば、チャネル３００は、図２に示されているチャネル２２０の１つとすることができる。チャネルは、イベントコンシューマ２３０からサブスクリプション要求を受け取るサブスクリプションモジュール３０３などの複数のコンポーネントを含む。サブスクリプション要求は、要求を提示した同じエンティティに転送する特定の特性を有するイベント通知に対するものである。しかし、要求側エンティティおよびイベントコンシューマは異なるエンティティであってよい。つまり、他のイベントコンシューマの代わりに、サブスクリプション要求を行うことができるということである。
【００４３】
サブスクリプションモジュール３０３は、セキュリティモジュール３０２を使用して、そのサブスクリプション要求を受け入れられるべきかどうかを判定する。特に、セキュリティモジュール３０２は、複数の細分性レベル（ｌｅｖｅｌｓｏｆ  ｇｒａｎｕｌａｒｉｔｙ）に対するセキュリティクリアランス（ｓｅｃｕｒｉｔｙ  ｃｌｅａｒａｎｃｅｓ）の判定に使用できる。たとえば、セキュリティモジュール３０２を使用して、要求側エンティティがチャネル３００に対しパブリッシュされたイベントにサブスクライブするセキュリティ権限を持っているかどうか、要求側エンティティが要求された特性を持つイベントにサブスクライブするセキュリティ権限を持っているかどうか、または要求側エンティティが特定のイベントコンシューマに転送するイベントにサブスクライブするセキュリティ権限を持つかどうかを判定することができる。
【００４４】
さらにセキュリティをイベントソース２１０からのパブリッシュ要求に設定して、パブリッシュ要求に対応するイベントソースがチャネル３００にイベントをパブリッシュするセキュリティ権限を持つかどうか、イベントソースが特定の特性を持つイベントをチャネルにパブリッシュするセキュリティ権限を持つかどうかを判定することができる。セキュリティモジュール３０２を使用して、チャネルに届いたイベントのタイプを望みどおりに制約することができる。そこで、チャネルを特定のトピックに合わせて特殊化したり、一般化したりすることが望む通りにできる。チャネルは、一般に、実質的にどのようなイベントコンシューマまたはソースからでも公然とアクセスできる。他方、１つまたは少数のイベントソースおよびコンシューマのみによるプライベート使用にチャネルを制限することもできる。
【００４５】
チャネル３００はイベントを受け取り、その後、イベントをそのイベントにサブスクライブしているイベントコンシューマに渡す。それぞれのイベントとそれぞれのサブスクリプション要求とを比較してどのイベントコンシューマがイベントを転送されるべきかを判断する代わりに、チャネル３００がそれぞれの可能なイベントコンシューマへの論理パスを持つフィルタ３１０を使用する。図の例では、サブスクリプション要求は２つしかなく、結果としてそれぞれ、対応するクエリフィルタ３１１および３１２となる。しかし、サブスクリプション要求が多数ある場合は、フィルタ３１０は図４のフィルタツリー４００によって示されているようなフィルタのツリーを使用するとよい。フィルタツリー４００の説明とその目的については、この詳細な説明でさらに述べてから説明する。
【００４６】
チャネル３００はさらに、スキーマ定義３０１も含む。受け取ったイベントは自己記述的（self-describing）でも、またスキーマ定義３０１に従って特定のポジションにマッピングできる特定の構造を持つものであってもよい。同様に、スキーマ定義に従ってサブスクリプション要求を特定のポジションにマッピングすることができる。一例では、受け取ったイベント通知はＸＭＬフラグメントであり、スキーマ定義３０１はＸＳＤ（XML Schema Definition）文書である。この例では、サブスクリプション要求はＸＰＡＴＨステートメントを含み、スキーマ定義３０１により定義された特定のポジションを記述する。イベント通知をそれぞれのクエリフィルタに送ることができる。
【００４７】
イベント通知とクエリフィルタに対応するサブスクリプション要求との間で一致が見つかった場合、イベント通知はクエリフィルタをパスすることが許される。そうでなければ、一致が見つからない場合、クエリフィルタを使用してイベント通知を削除する。スキーマ定義に従ってイベント通知が取るポジションが、サブスクリプション要求によってサブスクライブされたイベントがスキーマ定義に従って取るポジションに対応する場合に、一致があると判定できる。一致に関する他の必要な条件は、サブスクリプション要求で指定された目的のイベントの属性がイベント通知に対応していることである。
【００４８】
サブスクリプション要求のすべてに対してこのフィルタ処理を実行する方法として、１つのフィルタ（たとえば、クエリフィルタ３１１および３１２）をそれぞれのサブスクリプション要求に割り当てる方法がある。サブスクリプション要求が少なければ、この方法で、一般にリアルタイムでイベント通知を発生させることができる。しかしこれは、サブスクリプション要求が多くなった場合は、リアルタイムイベント通知では問題になることがある。この場合、多数の処理要求がそれぞれ、イベント通知をフィルタ処理するために専用に割り当てられたメモリおよび処理リソースを必要とする。
【００４９】
図４は、図３のフィルタ３１０内で使用できるフィルタツリーの例４００を示している。フィルタツリー４００は、イベント通知を処理しなければならないフィルタの個数を減らすか、いっそ最小限にまで減らすように設計されている。たとえば、イベントサブスクリプションが識別子５または識別子６で識別されたプロセスにより発火されるイベントに対してのみであると仮定する。フィルタツリー４００のルートフィルタ４０１は、プロセス５または６によって発火されなかったイベント通知を除去する。図４に示されている例では、イベントはフィルタ４０１を通る。フィルタに届いたイベントは、フィルタの左側部分に達している矢印で表されている。フィルタを通るイベントは、フィルタの右側部分から出ている矢印で表されている。「Ｘ」が重ねて表示されている矢印は、イベントがまだ何らかの上流フィルタによって除去されていない場合にイベントフローになっていることを意味する。「Ｘ」が重ねて表示されていない矢印は、上流フィルタによってイベント通知が除去されていないことを意味する。
【００５０】
この例では、第２レベルのフィルタ４０８がイベント通知を除去する。したがって、フィルタ４０９から４１２では、イベント通知を処理する必要はない。しかし、第２レベルのイベントフィルタ４０２はイベント通知を通す。第３レベルフィルタ４０４は、第３レベルフィルタ４０３がイベント通知を通している間にイベント通知を除去した。第４レベルフィルタ４０６は、第４レベルフィルタ４０５および４０７がイベント通知を通している間にイベント通知を除去した。したがって、イベント通知は２つの頭に○が付いている矢印で表されているような、可能な７つのイベントコンシューマのうちの２つに渡される。
【００５１】
イベント通知の処理に必要な平均的な処理およびメモリリソースは、特に、イベントサブスクリプションがかなり多い場合に、このようなフィルタツリーを使用することで低減することができる。一例では、サブスクリプション要求を受け取るごとにこの決定ツリーを再構成する。或いは、フィルタツリーの定期的な再構築の時が来るまで、期限付きでサブスクリプション要求にそれ専用のルートレベルのフィルタを割り当てておいてもよい。このようなフィルタツリーを使用しても、所与のリソースによっては必ずしも処理およびメモリリソースが低減されないが、平均的なイベント別処理およびメモリリソースは著しく低減できる。
【００５２】
図５は、本発明によるサブスクリプションベースのイベント通知を実行する方法５００を示している。この方法は、１つまたは複数のイベントコンシューマから１つまたは複数のサブスクリプションを受け取るステップ（ステップ５０１）と、１つまたは複数のイベントソースから１つまたは複数のイベント通知を受け取るステップ（ステップ５０２）を含む。ステップ５０１および５０２は、逐次実行されるように示されているが、サブスクリプションおよびイベントはいつでも受け取ることができる。
【００５３】
方法５００は、次に、１つまたは複数のイベントコンシューマから受け取った１つまたは複数のサブスクリプションとイベント通知とを照合する（ステップ５０３）。この照合ステップは、図３のフィルタ３１０を使用して実行することができる。このフィルタは次に、１つまたは複数のサブスクリプションに基づいてイベント通知のフィルタ処理のステップを実行する（ステップ５０４）。この機能的結果指向のステップには、指定された結果を達成する対応するステップを含めてもよい。一例では、ステップ５０４は、イベント通知を、そのイベント通知と一致するサブスクリプションを提示した各イベントコンシューマに渡す対応するステップ（ステップ５０６）と、イベント通知をそのイベント通知と一致するサブスクリプションを提示しなかったイベントコンシューマに渡すことなくイベント通知を除去する対応するステップ（ステップ５０５）を含む。
【００５４】
図２を再び参照すると、チャネルは、ＡＰＩ（Application Programming Interface）を介してイベントソースおよびイベントコンシューマと通信することができる。正確なＡＰＩは、そのＡＰＩがチャネル、イベントソース、およびイベントコンシューマによって認識されている限り本発明にとっては重要なことではない。この説明を検討した後当業者にとって明白であろうが、ＡＰＩは広範な機能を使用できるように定義してよい。
【００５５】
たとえば、本発明の原理を使用することにより、フレキシブルなロギングを実行するとともに、同時実行のリアルタイムイベント通知も実行することができる。またたとえば、イベントコンシューマをそのサブスクリプション要求をチャネルに提示するロギングアプリケーションとすることもできる。その後、チャネルはサブスクリプション要求に対応するイベントのみをログに書き込む。そこで、チャネルを通過するすべてのイベントを記録する代わりに、サブスクライブされた最も関連するイベントのみをログに記録するようにする。ロギングアプリケーションをチャネル自体に組み込むこともできる。ネットワーク管理者はユーザインタフェースを使用して、ロギングアプリケーションに、対象のイベントに対応する特定のサブスクリプション要求をネットワーク管理者に提示させることができる。
【００５６】
さらに、他のイベントコンシューマは必ずしもイベントを記録しなくてよいが、別な方法でリアルタイムイベント通知を使用することができる。このようなリアルタイムイベント通知を制御するのに、ロギングに使用したのと同じメカニズムを用いる。つまり、リアルタイムイベントコンシューマは対象のイベントについてのサブスクリプション要求を提示するということである。その後、チャネルがイベントを受け取ったのと実質的に同時に、関連するイベントがチャネルからイベントコンシューマに渡される。
【００５７】
さらに、いくつかの実施形態では、本発明の原理において特定のスキーマに従うイベントが使用される。スキーマ定義は、特定のイベントに対応するさまざまな名前−値のペアに十分対応できる柔軟さを備える。さらに、スキーマ定義は拡張可能とすることができる。特定のイベントに対する名前−値のペアが必要になったときに、イベントコンシューマまたはソースは、特定の名前−値のペアを含むようにスキーマ定義を拡張する要求を提示することができる。たとえば、電子メールの受信に関するイベントを定義する特定のスキーマがあるとする。このスキーマは、受信時刻、送信者名、サイズ、カーボンコピーリスト、および件名の行を規定する。そこで、電子メールの本文中の最初の１０語を知る必要もあるとする。イベントソースまたはパブリッシャは電子メール本文先頭の１０語に対応するようスキーマ定義を拡張するＡＰＩを提示することができる。
【００５８】
イベントソース、チャネルおよびイベントコンシューマによって認識されるスキーマを使用することにより、そのイベントの背後にある意味をよりインテリジェントな形で解釈することができる。たとえば、株式アプリケーションは、値２０２５．５７を読み取れるだけでなく、それが特定のインデックスファンドの現在の終値であることも認識することができる。このアプリケーションはさらに、他の手段ではその値の背後にある意味を理解することなくては実行できないタスクをその値で実行することができる。したがって、本発明の原理を用いれば、イベントに関する意味のある情報を表す柔軟で拡張性のある方法を可能とする。
【００５９】
本発明の他の利点として、特定のチャネルに届くイベントソースおよびイベントタイプを制御することにより特定の相手を対象とするチャネルにイベントを通すことができる。そのため、イベントコンシューマは対象のイベントチャネルのみを処理することができる。したがって、イベントを管理し編成する有効な方法が得られる。
【００６０】
本発明は、その趣旨または本質的特性から逸脱することなく他の固有の形でも実現することができる。ここで説明した実施形態は、あらゆる点において説明を目的としており制限すること目的としていないものとみなすべきである。したがって、本発明の範囲は上記の説明によってではなく特許請求の範囲により示される。すべての変更は、特許請求の範囲の意味とその等価性の範囲内にある限り本発明の範囲内にあるものとする。
【００６１】
【発明の効果】
以上説明したように本発明によれば、イベントを広範に解釈でき、あまり対象でないイベントを処理する際には処理およびメモリ資源を減縮するイベント通知技術を実現できる。
【図面の簡単な説明】
【図１】本発明の原理を示す適当なオペレーティング環境を示す図である。
【図２】本発明の実施形態の多数のイベントソースが複数の通知チャネルを介して多数のイベントコンシューマと通信するのを示す概略図である。
【図３】本発明の実施形態の通知チャネルをさらに詳しく示す概略図である。
【図４】本発明の実施形態のイベント通知を効率的にフィルタ処理するために使用できるフィルタツリーの図である。
【図５】本発明の実施形態の条件付きでイベントを処理する方法の流れ図である。
【符号の説明】
１２０  コンピューティングデバイス
１２１  プロセッサ
１２２  システムメモリ
１２３  ステムバス
１２４  ＲＯＭ
１２５  ＲＡＭ
１２６  ＢＩＯＳ
１２７  磁気ハードディスクドライブ
１２８  磁気ディスクドライブ
１２９  リムーバル磁気ディスク
１３０  光ディスクドライブ
１３１  リムーバル光ディスク
１３２  ハードディスクドライブインタフェース
１３３  磁気ディスクドライブインタフェース
１３４  光ドライブインタフェース
１３５ａ、１３５ｂ  オペレーティングシステム
１３６ａ、１３６ｂ、１３６ｃ、１３６ｄ  アプリケーションプログラム
１３７ａ、１３７ｂ  プログラムモジュール
１３８ａ、１３８ｂ  プログラムデータ
１３９  磁気ハードディスク
１４０  キーボード
１４２  ポインティングデバイス
１４６  シリアルポートインタフェース
１４７  モニタ
１４８  ビデオアダプタ
１４９ａ、１４９ｂ  リモートコンピュータ
１５０ａ、１５０ｂ  メモリストレージデバイス
１５１  ＬＡＮ
１５２  ＷＡＮ
１５３  ネットワークインタフェースまたはアダプタ
１５４  モデム
２２０、２２１、２２２  チャネル
２１０  イベントソース
２１１、２１２、２１３、２１４、２１５  ソース
２３０  イベントコンシューマ
２３１、２３２、２３３、２３４、２３５、２３６  コンシューマ
３００  チャネル
３０１  スキーマ定義モジュール
３０２  セキュリティモジュール
３０３  サブスクリプションモジュール
３１０  フィルタ
３１１、３１２  クエリフィルタ
４００  フィルタツリー
４０１  ルートフィルタ
４０２〜４１２  フィルタ
５００  イベント通知を実行する方法
【図１】
0005122722.tif 000002
【図２】
0005122722.tif 000003
【図３】
0005122722.tif 000004
【図４】
0005122722.tif 000005
【図５】
0005122722.tif 000006