(57)【要約】【課題】イベント通知システムに関し、複数のイベントを組み合わせたサブスクライブ情報に対して予め記憶したロジックでパブリッシュ情報を集約して通知するシステムとその方法を提供することを目的とする。【解決手段】本発明の複合イベント通知システムは、予めパブリッシュ情報の集約ロジックを記憶するモジュール格納手段と、サブスクライバ・アプリケーションから要求された複合サブスクライブ情報を取得する複合ブスクライブ情報取得手段と、取得した複合サブスクライブ情報を分解し登録するサブスクライブ情報登録手段と、パブリッシュ情報を受け付けたとき登録したサブスクライブ情報と集約ロジックに基づいてパブリッシュ情報を取得するパブリッシュ情報取得手段と、取得した情報を通知するパブリッシュ情報通知手段とで構成する。【選択図】    図１
2004348680.tif 000002
【特許請求の範囲】
【請求項１】
パブリッシュ情報の集約ロジックを記述したイベント処理モジュールを格納するモジュール格納手段と、
サブスクライバ・アプリケーションからの要求により、複数のイベントの組み合わせを含む複合サブスクライブ情報を取得する複合サブスクライブ情報取得手段と、
前記イベント処理モジュールに基づいて、前記複合サブスクライブ情報を個々のイベントのサブスクライブ情報に分解して登録するサブスクライブ情報登録手段と、
パブリッシャ・アプリケーションのイベント発生によるパブリッシュ情報を受け取ったとき、前記登録されたサブスクライブ情報と前記イベント処理モジュールとに基づいて前記パブリッシュ情報を取得するパブリッシュ情報取得手段と、
前記取得したパブリッシュ情報を前記複合サブスクライブ情報に基づいて通知するパブリッシュ情報通知手段と
を有することを特徴とする複合イベント通知システム。
【請求項２】
パブリッシュ情報の集約ロジックを記述した複数のイベント処理モジュールを格納するモジュール格納手段と、
サブスクライバ・アプリケーションからの要求により、イベント処理の種類と複数のイベントの組み合わせとを含む複合サブスクライブ情報を取得する複合サブスクライブ情報取得手段と、
前記イベント処理の種類により選択した前記イベント処理モジュールに基づいて、前記複合サブスクライブ情報を個々のイベントのサブスクライブ情報に分解して登録するサブスクライブ情報登録手段と、
パブリッシャ・アプリケーションのイベント発生によるパブリッシュ情報を受け取ったとき、前記登録されたサブスクライブ情報と前記選択されたイベント処理モジュールとに基づいて前記パブリッシュ情報を取得するパブリッシュ情報取得手段と、
前記取得したパブリッシュ情報を前記複合サブスクライブ情報に基づいて通知するパブリッシュ情報通知手段と
を有することを特徴とする複合イベント通知システム。
【請求項３】
パブリッシュ情報の集約ロジックを記述した複数のイベント処理モジュールを格納するモジュール格納手段と、
複合イベント名に対応して複合サブスクライブ情報を作成する定義体を記述をした複数の複合イベント定義体を格納する複合イベント定義体格納手段と、
サブスクライバ・アプリケーションから指定された複合イベント名とパラメータとに基づいて、前記複合イベント定義体を選択して複合サブスクライブ情報を作成する複合サブスクライブ情報作成手段と、
前記複合サブスクライブ情報により選択した前記イベント処理モジュールに基づいて、前記複合サブスクライブ情報を個々のイベントのサブスクライブ情報に分解して登録するサブスクライブ情報登録手段と、
パブリッシャ・アプリケーションのイベント発生によるパブリッシュ情報を受け取ったとき、前記登録されたサブスクライブ情報と前記選択されたイベント処理モジュールとに基づいて前記パブリッシュ情報を取得するパブリッシュ情報取得手段と、
前記取得したパブリッシュ情報を前記複合サブスクライブ情報に基づいて通知するパブリッシュ情報通知手段と
を有することを特徴とする複合イベント通知システム。
【請求項４】
請求項１乃至請求項３のいずれかに記載の複合イベント通知システムは、前記サブスクライブ情報登録手段において取得したサブスクライブ情報を他の複合イベント通知システムにイベント通知の処理を依頼すること
を特徴とする複合イベント通知システム。
【請求項５】
パブリッシュ情報の集約ロジックを記述したイベント処理モジュールを格納するモジュール格納手順と、
サブスクライバ・アプリケーションからの要求により、複数のイベントの組み合わせを含む複合サブスクライブ情報を取得する複合サブスクライブ情報取得手順と、
前記イベント処理モジュールに基づいて、前記複合サブスクライブ情報を個々のイベントのサブスクライブ情報に分解して登録するサブスクライブ情報登録手順と、
パブリッシャ・アプリケーションのイベント発生によるパブリッシュ情報を受け取ったとき、前記登録されたサブスクライブ情報と前記イベント処理モジュールとに基づいて前記パブリッシュ情報を取得するパブリッシュ情報取得手順と、
前記取得したパブリッシュ情報を前記複合サブスクライブ情報に基づいて通知するパブリッシュ情報通知手順と
をコンピュータに実行させることを特徴とする複合イベント通知プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、サブスクライバ・アプリケーションの要求に基づいてパブリッシャ・アプリケーションから送信されたパブリッシュ情報を通知するイベント通知システムに関し、特にサブスクライバ・アプリケーションが複数のイベントを組み合わせた要求に対して指定されたロジックでパブリッシュ情報を取得して集約し、通知するイベント通知システムに関する。
【０００２】
【従来の技術】
インターネット上では様々なサービスが提供され、多くのユーザはそれらのサービスを亨受できるようになってきている。しかし、個々のサービスは各サービスプロバイダによって独自の方式で提供されており、一つのサービスの用途は限定的である。
【０００３】
一方でユーザの要求は複雑であり、その要求を叶えるには時として複数のサービスを順序よく効率的に利用し、互いの実行結果を利用する必要がある。しかし、ユーザがどのサービスをどの順番で利用すればいいのかを気にしなければならないのでは、ユーザにとって負担になる上に誤りを起しやすい。さらに、サービスの処理に時間が掛る場合には、いつ処理が終わるのかを意識していないと速やかに次の処理を開始できず、時間を無駄にする恐れがある。
【０００４】
このため、サービス同士がある程度自律的に連携し、協調的に動作することが望まれている。しかし、サービスはサービスプロバイダによって随時作成され、独自に管理されているので、あらかじめ連携可能なサービスを知っておき、それに合せて個々のサービスを実行し、結果を集約するようなシステムを設計しておくのは困難である。また、連携可能なサービスの組み合わせが増えると、それに合せてシステムを設計・開発しなおさなければならない、と言う問題もある。
【０００５】
このため、あるイベントが発生した時点で、特定のサービスにイベントが起きたことを通知するイベント通知サービスが利用されている。図３はイベント通知サービスの仕組みを示すもので、サービスＸおよびサービスＹは予め知らせ欲しいイベントの情報を登録（サブスクライブ）しておく（図３の▲１▼）。また、サービスＡ〜Ｃは、イベントという形式で自律的に情報をイベント通知サービスに送信（パブリッシュ）する（図３の▲２▼）。イベント通知サービスはサービスＸ及びサービスＹによって登録されたイベントがサービスＡ〜Ｃに発生したときその情報をサービスＸまたはサービスＹに通知（ノーティファイ）する（図３の▲３▼）ものである。ここでイベント通知サービスと言う表現はサービスから見た言葉で、他の言葉でイベント通知サービスをイベント通知システム、サービスＸおよびＹはサブスクライバ・アプリケーションＸおよびＹ、サービスＡ〜Ｃはパブリッシャ・アプリケーションＡ〜Ｃとも表現するが、実体は同一であっても構わない。
【０００６】
このようなイベント通知サービスの規格として、ＣＯＲＢＡのノーティフィケーションサービス（例えば、非特許文献１、２）やＪａｖａ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅのパブ・サブ（Ｐｕｂ／ｓｕｂ）  メッセージングモデル（例えば、非特許文献３）、あるいはＭｉｃｒｏｓｏｆｔ．  ＮＥＴ  Ａｌｅｒｔｓ  （例えば、非特許文献４）などがある。
【０００７】
【非特許文献１】
Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ、［ｏｎｌｉｎｅ］、Ａｎ  Ａｄｏｐｔｅｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  ｔｈｅ  Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ，Ｉｎｃ  、［平成１  ５  年４  月７  日検索］、インターネット＜  ｈｔｔｐ：／／ｗｗｗ．ｏｍｇ．ｏｒｇ／ｄｏｃｓ／ｆｏｒｍａｌ／０２−０８−０４．ｐｄｆ＞
【０００８】
【非特許文献２】
ＣＯＲＢＡ通知サービス、［ｏｎｌｉｎｅ］、Ｄａｖｅ  Ｂａｒｔｌｅｔｔ  、［平成１５年  ４月  ７日検索］、インターネット＜  ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｄｅｖｅｌｏｐｅｒｗｏｒｋｓ／ｃｏｍｐｏｎｅｎｔｓ／０１０７２０／ｊ＿ｃｏ−ｃｊｃｔ７−ｉｎｄｅｘ．ｈｔｍｌ＞
【０００９】
【非特許文献３】
Ｊａｖａ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  −  ｖｅｒｓｉｏｎ  １．１、［ｏｎｌｉｎｅ］、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，  Ｉｎｃ．［平成１５年  ４月  ７日検索］、インターネット＜  ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊｍｓ／ｄｏｃｓ．ｈｔｍｌ＞
【００１０】
【非特許文献４】
Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴ  Ａｌｅｒｔｓ  、［ｏｎｌｉｎｅ］、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ  、［平成１５年  ４月  ７日検索］、インターネット＜  ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｎｅｔ／ｓｅｒｖｉｃｅｓ／ａｌｅｒｔｓ／ｄｅｆａｕｌｔ．ａｓｐ＞
【００１１】
【発明が解決しようとする課題】
上記に述べたように、サービス同士がある程度自律的に連携し、協調的に動作することが望まれているが、実際に必要とするサービスの連携は単なる順次起動ばかりでなく、特定の時刻に自動的に起動したり、複数のサービスの実行回数をトリガにしたり、複数のサービスの終了を待ってから起動したり、あるいは限定的に特定の手順が決まっている場合もあり、イベント通知サービスには、そのような集約的なイベントの通知機能が必要となってきている。
【００１２】
例えば、開発プロジェクトにおいて、毎週決まった曜日に、プロジェクトメンバに進捗報告を提出するように催促するメッセージを送付し（イベントの定時発生）、すべてのメンバからの進捗が出揃った時点で、各進捗情報をまとめてプロジェクトリーダに通知する（イベントの待合わせ）  、ことなどである。また、期日までに提出していないメンバがいる場合に督促を何回か行い、ある一定回数になった時点で出揃っている進捗情報をまとめて通知することも考えられる（イベントのカウンタ）  。また、メンバ間での合意形成のために多数決を行う際にイベントサービスを利用することも可能である。
【００１３】
しかし、従来のイベント通知サービスの多くは複合的なイベントを取り扱っていなかった。したがって、複数のイベントの発生を待合わせて、あるサービスが起動されるようにするには、イベント通知の受け手となるサービス自身が個々のイベントをすべて受け付け、必要なイベントがすべて揃った時点で、処理を始めるようにサービスを設計するか、イベントを待合わせて揃った時点で目的のサービスにイベントを通知するだけのサービスを別個に構築する必要がある。
【００１４】
ところが前者の場合、新たに連携可能なサービスが追加されたり、イベントの集約の仕方を変えようとすると、その度ごとにサービス自体に変更を加えなければならず、柔軟に対処するのが困難である。また、場合によってはサービスを再起動する必要が生ずる場合もある。後者の場合、イベントの集約に応じて連携のためだけにサービスを構築する必要があり、開発やその後の管理コストの増大を招くため手軽に連携を実現することが困難である。
【００１５】
従って、サービス間の連携を集約的なイベントに対応させることが困難になり、複雑なサービス連携を実現する障害になっていた。本発明は、複数のイベントで発生するパブリッシュ情報を取得し集約する動作ロジックをモジュール化して内部に持ち、複合したサブスクライブ情報に基づいて対応するモジュールを選択し、内部でプリミティブなイベント毎の要求に分解してそれぞれパブリッシュされた情報を動作ロジックによって集約した上でサブスクライバ・アプリケーションに通知するものである。しかもモジュールを追加可能とすることで汎用性を高め、複雑なサービス連携の実現を容易にすることを目的とする。
【００１６】
【課題を解決するための手段】
上記課題を解決するため、本発明の複合イベント通知システムは以下のように構成される。
（１）第１の発明
第１の発明は、複数のイベントの組み合わせで構成された複合サブスクライブ情報を個別のプリミティブなサブスクライブ情報に分解し、予め記憶されているパブリッシュ情報の集約ロジックによりパブリッシュ情報を取得し、指定された通知先に通知するものである。  その原理を図１を用いて説明する。本発明は、図１に示すようにモジュール格納手段１、複合サブスクライブ情報取得手段２、サブスクライブ情報登録手段３、パブリッシュ情報取得手段４およびパブリッシュ情報通知手段５から成る。
【００１７】
モジュール格納手段１は、パブリッシュ情報を集約するロジックを記述したイベント処理モジュールを予め適切な記憶部に格納しておく（記憶しておく）ものである。イベント処理モジュールは、例えば待ち合わせロジックである場合、イベントＡ〜Ｃの三つのイベントの発生を待ち合わせ、それらのパブリッシュ情報を取得し、総ての情報が揃ったところで纏めて（集約して）通知する、といったロジックを記述したものである。ロジックの記述は、処理するイベント名やイベントの数を固定的に決めておくものではなく汎用的に処理できるように記述されている。
【００１８】
複合サブスクライブ情報取得手段２は、サブスクライバ・アプリケーションからの要求により、複合サブスクライブ情報を取得する。複合サブスクライブ情報は、通知して欲しいイベント名が複数組み合わされた情報や取得した情報の通知先などから成る。
サブスクライブ情報登録手段３は、取得した複合サブスクライブ情報をイベント処理モジュールに基づいて個別のイベントのサブスクライブ情報に分解し、適切な記憶部に登録するものである。例えば、５つのプリミティブなイベントの組み合わせから成り立っている複合サブスクライブ情報に対しては５つのサブスクライブ情報に分解される。
【００１９】
パブリッシュ情報取得手段４は、パブリッシャ・アプリケーションでのイベント発生によりパブリッシュされた情報（パブリッシュ情報）を、登録してあるサブスクライブ情報とイベント処理モジュールとを用いてパブリッシュ情報を取得し集約するものである。即ち、パブリッシュされた情報はサブスクライブ情報で求めている情報であって、且つイベント処理モジュールにおけるロジックに合致するときそのパブリッシュ情報を取得し集約する。例えば、イベントＸとイベントＹの情報を得てその後イベントＺの情報を取得したい、と言う複合サブスクライブ情報であったとき、サブスクライブ情報登録手段２において、プリミティブなイベントであるイベントＸ、イベントＹ、イベントＺが登録されるが、イベントＺがイベントＸまたはイベントＹに先立ってイベントの発生があっても、その時点ではイベントＺの情報は取得されないことになる。
【００２０】
パブリッシュ情報通知手段５は、取得したパブリッシュ情報を複合サブスクライブ情報で指定された通知先に通知するものである。
第１の発明によれば、イベント処理ロジックに複雑な関係を持たせてパブリッシュ情報を集約するロジックを記述しておくことにより、容易に複合した情報を通知できる複合イベント通知システムを提供できる。また、サブスクライバ・アプリケーションと複合イベント通知システムの間は、集約された通知メッセージのみが送信され、個々のイベントは通知されないので通信量の削減を図ることができる。更に、異なるロジックによりイベントを集約通知したい場合は、イベント処理モジュールのみを変更するだけで済む。
（２）第２の発明
第２の発明は、パブリッシュ情報の集約ロジックを記述したイベント処理モジュールを複数備え、複合サブスクライブ情報に基づいてイベント処理モジュールを選択できるようにしたものである。
【００２１】
第１の発明と異なる部分について説明する。
まず、モジュール格納手段１は、パブリッシュ情報の集約ロジックが複数のイベント処理モジュールを備えることである。例えば、「待ち合わせ」、「多数決」、「カウンタ」等のイベント処理モジュールをカートリッジのように備えておくものである。
【００２２】
また、複合サブスクライブ情報取得手段２で取得する複合サブスクライブ情報は第１の発明の複数のイベントの組み合わせの情報に加えてイベント処理の種類の情報を含むものである。イベント処理の種類は、モジュール格納手段１で述べた「待ち合わせ」や「多数決」等のイベント処理方法を指定するもので、イベント処理モジュールの選択の識別に用いる情報である。
【００２３】
サブスクライブ情報登録手段３は、イベント処理の種類の情報に基づいてイベント処理モジュールを選択し、選択したイベント処理モジュールを用いて複合サブスクライブ情報を個別のイベントのサブスクライブ情報に分解し、登録する。パブリッシュ情報集約手段４は、選択されたイベント処理モジュールを用いてパブリッシュ情報の取得を行うものである。
【００２４】
第２の発明によれば、複数のイベント処理モジュールを格納しておくことにより、種々のパブリッシュ情報の取得ロジックに対応できる複合イベント通知システムの提供が可能となる。また、全体のシステムを停止することなく、必要に応じてこのイベント処理モジュールを追加できるメリットも有する。
（３）第３の発明
第３の発明は、複合イベント名を指定するだけで、予め複合イベント名に対応して予め格納されている複合イベント定義体に基づいて複合サブスクライブ情報を作成し、複合イベントに対するパブリッシュ情報の取得を行うものである。
【００２５】
図２は、第３の発明の原理を示すもので、モジュール格納手段１、複合イベント定義体格納手段６、複合サブスクライブ情報作成手段７、サブスクライブ情報登録手段３、パブリッシュ情報集約手段４およびパブリッシュ情報通知手段５から構成する。これらの内、複合イベント定義体格納手段６と複合サブスクライブ情報作成手段７が第２の発明と異なり、他の構成要素は第２の発明と同一であるのでこれらの構成要素について説明する。
【００２６】
複合イベント定義体格納手段６は、予め複合サブスクライブ情報を作成する定義体を複合イベント名に対応して格納しておくものである。
複合サブスクライブ情報作成手段７は、サブスクライバ・アプリケーションから複合イベント名とそのパラメータを取得すると、その複合イベント名から格納されている複合イベント定義体を呼び出し、パラメータを組み入れて複合サブスクライブ情報を作成する。
【００２７】
複合サブスクライブ情報が作成された以降は第２の発明と同様である。
第３の発明によれば、サブスクライバ・アプリケーションは複合サブスクライブ情報を作成することなく、複合イベント名とパラメータを指定するだけでよい。複合イベントの定義は、例えばイベントサービスの管理者あるいは利用者が行えるようにすることで定義変更も容易に行え、複合イベント通知システムはより使い易いものとなる効果がある。
（４）第４の発明
第４の発明は、第１の発明乃至第３の発明におけるサブスクライブ情報登録手段において、取得した複合サブスクライブ情報を他の複合イベント通知システムに回送し、処理の依頼を行うものである。
【００２８】
第４の発明によれば、他の複合イベント通知システムに依頼できることによって、自身の複合イベント通知システムが負荷が高い場合に負荷の平準化を図ることができ、また、自身のシステムにイベント処理モジュールを実装していない場合でも処理を可能とする効果がある。
（５）第５の発明
第５の発明は、第１の発明における複合イベント通知プログラムである。
【００２９】
第５の発明によれば、複数のイベント処理モジュールを備えることにより、複合サブスクライブ情報から種々のパブリッシュ情報を連携して容易に取得できる複合イベント通知プログラムの提供が可能となる。
【００３０】
【発明の実施の形態】
次に、本発明について図４から図２１を参照して実施形態を説明する。
（実施形態その１）
実施形態その１は、第１の発明を具現化する例で図４に全体構成を示す。本発明の複合イベント通知システム１００は、サブスクライブ情報受付部１０１、サブスクライブディスパッチャ１０２、イベント処理モジュール１０３、サブスクライブ情報管理部１０４、イベント受付部１０５、クロック１０６、ノーティフィケーションディスパッチャ１０７、イベントノーティファイア１０８、複合サブスクライブ情報管理テーブル１２０、サブイベント処理用作業テーブル１３０およびサブスクライブ情報テーブル１４０から構成する。ここで、複合イベント通知システム１００のハードウェアはコンピュータであり、複合サブスクライブ情報管理テーブル１２０、サブイベント処理用作業テーブル１３０およびサブスクライブ情報テーブル１４０は、外部記憶またはメモリ上の記憶部に置かれたデータテーブルである。また、クロック１０６はコンピュータに内蔵の時計機能であり、以上に示した以外のものは、メモリ上に展開されたプログラムである。
【００３１】
サブスクライブ情報受付部１０１は、サブスクライバ・アプリケーションから要求されたサブスクライブ情報を受け付ける機能である。ここでは、受け付けたサブスクライブ情報の形式チェックを行い、妥当なものであればＩＤを付与してサブスクライブディスパッチャ１０２に渡す。もし、形式等が合っていない場合はエラーとして要求元であるサブスクライバ・アプリケーションに通知する。サブスクライブ情報のデータ例を図５に示す。図５（ａ）は従来のプリミティブなイベントのサブスクライブ情報の例で、図５（ｂ）は複合イベントのサブスクライブ情報の例であり、ＸＭＬを用いて記述している。それぞれのタグについて説明する。まず図５（ａ）の「ｓｕｂｓｃｒｉｂｅ」タグはサブスクライブ情報であることを示している。「ｅｖｅｎｔ」タグは通知して欲しいイベントの内容を示すもので、そのタグ内に示される「ｔｙｐｅ」はイベント処理の種類を示す属性で、ここでは単一なイベント処理であることを示す「ｐｒｉｍｉｔｉｖｅ」、更に「ｎａｍｅ」はイベント名を示している。続いて、「ｄｅｓｔｉｎａｔｉｏｎ」タグは取得したパブリッシュ情報の通知先を、「ｃｏｎｔｅｎｔｓ」タグは通知して欲しい内容、「ｅｘｐｉｒｅ」タグはパブリッシュ情報取得の有効期限を示している。図５（ｂ）の複合イベントのサブスクライブ情報の例では、「ｅｖｅｎｔ」の属性が「ｗａｉｔ」で、次行に示されるイベントを待ち合わせて、それらが揃ったところ通知する処理を行うことを示すものである。「ｅｖｅｎｔ」タグの下位にある［ｓｕｂｅｖｅｎｔ］は複数のイベントの組み合わせを示している。ここでは、Ｅｖｅｎｔ−Ａ、Ｅｖｅｎｔ−ＢおよびＥｖｅｎｔ−Ｃの三つのプリミティブなサブイベントを組み合わせている。
【００３２】
サブスクライブディパッチャ１０２は、サブスクライブ情報受付部１０１で受け付けたサブスクライブ情報の内容を見て、プリミティブなイベントの場合はサブスクライブ情報管理部１０４に、複合イベントの場合はイベント処理モジュール１０３を呼び出し、サブスクライブ情報を渡す。即ち、単一（プリミティブ）なイベントか、複合イベントかをここで振り分ける。
【００３３】
イベント処理モジュール１０３は、パブリッシュ情報の集約ロジックを記述したもので、基本的に二つの機能を有している。一つはサブスクライブ時の機能で、サブスクライブディパッチャ１０２から渡されたサブスクライブ情報（複合イベントのサブスクライブ情報）を複合サブスクライブ情報テーブル１２０に登録し、集約ロジックに基づいてプリミティブなサブイベントに分解する。そして、分解された複数のサブイベントの情報に対して先に付与されたＩＤに追番を付けたＩＤをサブイベント用作業テーブル１３０にエントリー（登録）しておく。また、新しく付与されたＩＤとともに分解されたサブイベントの情報をサブスクライブ情報管理部１０４に渡し、サブスクライブ情報テーブル１４０に登録することを依頼する。イベント処理モジュール１０３のもう一つの機能はパブリッシュ情報を取得し集約する機能で、後述するサブスクライブ情報管理部１０４から渡されたパブリッシュ情報を集約ロジックに基づいて取得するかどうかを判断し、取得するようであればそのパブリッシュ情報をサブイベント処理用テーブル１３０に書き込むことを行う機能である。さらに、サブイベント処理用テーブル１３０において関連するＩＤのサブスクライブ情報が総てパブリッシュ情報を取得済であるかどうか調べ、取得済であれば通知メッセージを作成してノーティフィケーションディスパッチャ１０７に対して通知の依頼を行う。
【００３４】
ここで、複合サブスクライブ情報管理テーブル１２０およびサブイベント用作業テーブル１３０のデータ構造例を説明する。図６は複合サブスクライブ情報管理テーブル１２０の例を示すもので、「ＩＤ」、「通知先」、「通知内容」および「有効期限」のフィールドから構成している。「ＩＤ」はサブスクライブ情報受付部１０１で付与したもの、「通知先」は集約したパブリッシュ情報を通知する通知先、「通知内容」はサブスクライブ情報で指定されたイベントが発生した時に通知される内容、「有効期限」はそのサブスクライブ情報の有効期限であり、これを過ぎると対象となっているイベントが発生しても通知されなくなる。図６のＩＤ「ｓｕｂｉｄ＃１２３」は図５（ｂ）に示した複合イベントのサブスクライブ情報のデータである。
【００３５】
図７はサブイベント用作業テーブル１３０の例を示すもので、「ＩＤ」、「コンテンツタイプ」および「コンテンツ」のフィールドから構成している。「ＩＤ」はサブイベントに付けられたＩＤで、サブスクライブ情報受付部１０１で付与されたＩＤに追番を付けたものである。図７に示すＩＤのデータは、サブスクライブ情報受付部１０１で受け付けられ複合イベントのサブスクライブ情報にまず「ｓｕｂｉｄ＃１２３」のＩＤが付与され、三つに分解されたプリミティブなサブイベントに対して追番を付けてＩＤとしたものである。「コンテンツタイプ」および「コンテンツ」は、パブリッシュ情報を取得した段階で書き込まれるもので、サブスクライブ時にエントリした時点では何も書かれていない。図７の例では、「ｓｕｂｉｄ＃１２３−１」と「ｓｕｂｉｄ＃１２３−２」のサブイベントに対してパブリッシュ情報を取得した状態となっていることを示している。
【００３６】
サブスクライブ情報管理部１０４は、複合イベントに対してはイベント処理モジュール１０３で分解したサブイベントの情報を、単一イベントに対してはサブスクライブ情報受付部１０１で受け付けたサブスクライブ情報をサブスクライブ情報テーブル１４０に登録する。また、イベント受付部１０５から渡されたパブリッシュ情報がサブスクライブ情報で要求している情報かを確認して、プリミティブなイベントであればノーティフィケーションディスパッチャ１０７に取得したパブリッシュ情報の通知を依頼する。複合イベントであればイベント処理モジュール１０３に通知する。
【００３７】
ここで、サブスクライブ情報テーブル１４０のデータ例を説明する。図８は、サブスクライブ情報テーブル１４０のデータ例を示すもので、「ＩＤ」、「イベント名」および「サブイベント通知先」の各フィールドから構成する。「ＩＤ」は、単一イベントのサブスクライブ情報はサブスクライブ情報受付部１０１で付与したＩＤであり、複合イベントで分解されたサブイベントのサブスクライブ情報はイベント処理モジュール１０３で追番を付けたＩＤである。「イベント名」はサブスクライブ情報で指示された名称、「サブイベント通知先」はイベントが発生した時の通知先である。例えば、単一イベントの場合はＵＲＬ、複合イベントで分解されたサブイベントの場合ではイベント処理モジュール１０３を特定する名前である（Ｊａｖａクラス名の先頭に「＃」を付けて、実装しているイベント処理モジュールであることの区別している）。より具体的には、個々のサブイベントをイベント処理モジュール１０３がサブスクライブ情報管理部１０４に対してサブスクライブし、そのサブイベントの発生をサブスクライブ情報管理部１０４がイベント処理モジュール１０３に通知する。こためのイベント処理モジュール１０３の通知先である。
【００３８】
イベント受付部１０５は、パブリッシャ・アプリケーションでのイベントの発生によりパブリッシュ情報を受け付けるものである。ここではパブリッシュされた情報の形式チェックを行い、サブスクライブ情報管理部１０４に渡す。パブリッシュ情報のデータ例を図９に示す。これは、Ｅｖｅｎｔ−Ａの情報をパブリッシュする場合の例である。
【００３９】
クロック１０６は、サブスクライブ情報の有効期限内であるかどうかを判断する場合に用いられる。例えば、必要とするイベントの発生が何時までも行われないと待ち続けることになるので、クロック１０６により指定された期限を過ぎた場合は取得情報が欠落していても取得した情報のみを通知するような場合に用いる。図６の複合サブスクライブ情報管理テーブル１２０の「有効期限」フィールドの値と比較して判断する。
【００４０】
ノーティフィケーションディスパッチャ１０７は、イベント処理モジュール１０３およびサブスクライブ情報管理部１０４からの通知依頼を受けて、通知先に応じてイベント処理モジュール１０３またはイベントノーティファイア１０８に対して通知の指示を出すものである。通知先が通常のＵＲＬであれば、イベントノーティファイア１０８へ、イベント処理モジュール名の場合にはイベント処理モジュール１０３に通知を依頼する。
【００４１】
イベントノーティファイア１０８は、ノーティフィケーションディスパッチャ１０７の指示を受けて取得したパブリッシュ情報を通知先に通知を行う。通知データの例を図１０に示す。図１０はイベント処理モジュール１０３が図５（ｂ）の複合サブスクライブ情報の要求に基づいてパブリッシュ情報を取得、集約して作成した通知情報の例である。
【００４２】
次に、図４に示した複合イベント通知システム１００の処理フローを説明する。本説明は、サブスクライブ時のイベント名を登録しておく処理と、イベントの発生時にパブリッシュ情報を取得して通知するまでの処理の二つの処理について説明する。
まず、前者のサブスクライブ時の処理について図１１および図１２を用いて説明する。図１１において複合イベント通知システム１００は、サブスクライバ・アプリケーションからサブスクライブ情報を受け取り、サブスクライブ情報の形式チェックを行う。形式に問題があればエラーとしてサブスクライバ・アプリケーションに通知するが、問題なければサブスクライブ情報に一意のＩＤを付与する。（Ｓ１０１〜Ｓ１０５）。
【００４３】
続いてサブスクライブ情報の内容を調べてイベントの種類をチェックする。即ち、サブスクライブ情報が単一イベントであるか複合イベントであるかをチェックする。複合イベントであれば、イベント処理モジュール１０３を呼び出す。このとき、イベント処理モジュール１０３にはＩＤとサブスクライブ情報（即ち、複合サブスクライブ情報）とを渡す。イベント処理モジュール１０３内部の処理は次に説明するが、処理を終えたイベント処理モジュール１０３から複合イベントを分解してそれぞれにＩＤを付与されたサブイベントの情報を受取り、サブスクライブ情報テーブル１４０に登録する。一方、サブスクライブ情報が単一イベントであった場合、イベント処理モジュール１０３を通さずに付与されたＩＤとともにサブスクライブ情報テーブル１４０に登録する。（Ｓ１０６〜Ｓ１０９）。
【００４４】
次に、ステップＳ１０８で呼び出されたイベント処理モジュール１０３の処理フローについて、図１２を用いて説明する。イベント処理モジュール１０３は待ち合わせロジックのモジュールを例とし、サブスクライブ情報のデータは図５（ｂ）の情報であるものとして説明する。まず、付与されたＩＤとともに、サブスクライブ情報から通知先、通知内容および有効期限を複合サブスクライブ情報管理テーブル１２０に書き込む。続いて、サブスクライブ情報の「ｅｖｅｎｔ」タグの下位階層にある「ｓｕｂｅｖｅｎｔ」タグによりプリミティブなサブイベントに分解する。図５（ｂ）のサブスクライブ情報では三つのサブイベントに分解できるので、それぞれに対して「ＩＤ＋追番」をサブイベントのＩＤとして付ける。このＩＤをサブイベント処理用作業テーブルに書き込む（即ち、エントリする）。（Ｓ２０１〜Ｓ２０４）。
【００４５】
ここまで、単一イベントおよび複合イベントのサブスクライブ情報を受け付けてから登録するまでの処理を説明した。次に、この登録情報に基づいてパブリッシャ・アプリケーションからパブリッシュ情報を取得する処理フローを図１３と図１４により説明する。
図１３において、パブリッシャ・アプリケーションのイベント発生に基づいてパブリッシュ情報を受け取る。この情報の形式チェックを行い、問題がなければサブスクライブ情報テーブル１４０を参照してパブリッシュされたイベント名が登録されているかどうかを照合して調べる（即ち、サブスクライブ情報がそのパブリッシュ情報を必要としているかどうかを調べる）。イベント名に等しいサブスクライブ情報がサブスクライブ情報テーブル１４０にが存在していれば、次に通知先が待ち合わせイベント処理モジュール名かどうかをサブスクライブ情報テーブル１４０で調べ、そうであれば待ち合わせイベント処理モジュール１０３を呼び出す。（Ｓ３０１〜Ｓ３０８）。
【００４６】
イベント処理モジュール１０３では詳細を後述するが、集約ロジックによりパブリッシュ情報の取捨選択を行う。そしてサブスクライブ情報が要求しているパブリッシュ情報が総て揃ったと判断した場合は通知依頼を行う。この通知依頼を受けて、指定された通知先に、イベント処理モジュール１０３で集約したパブリッシュ情報を通知する。一方、ステップＳ３０７で要求しているサブスクライブ情報が単一イベントであったとき、サブスクライブ情報テーブル１４０から通知先を取得してパブリッシュ情報を通知する。（Ｓ３０９〜Ｓ３１１）。
【００４７】
次に、概要の説明に終わったイベント処理モジュール１０３におけるパブリッシュ情報の取得処理を図１４を用いて、待ち合わせイベントの例で説明する。このモジュールが呼び出しを受けたとき、パブリッシュ情報とＩＤが渡されるので、まず複合サブスクライブ情報管理テーブル１２０を参照して取得したパブリッシュ情報が有効期限内かどうかをチェックする。有効期限を過ぎていれはサブスクライブ情報を削除して終了する。パブリッシュ情報が有効期限内であれば、それを基にサブイベント処理用作業テーブル１３０の「コンテンツタイプ」と「コンテンツ」フィールドにパブリッシュ情報を書き込む。続いて、サブイベント処理用作業テーブル１３０を参照して同じ複合イベントのサブスクライブ情報が総てパブリッシュ情報を取得済かどうかを調べる（「コンテンツタイプ」または「コンテンツ」フィールドがＮＵＬＬがあるかどうかで判断する）。総て取得済みの状態であれば、サブイベント処理用作業テーブル１３０の「コンテンツタイプ」と「コンテンツ」フィールドの情報を集約して通知用のメッセージを作成し、複合サブスクライブ情報管理テーブル１２０を参照して通知先を取得してノーティフィケーションディスパッチャ１０７に対し通知依頼を行う。続いて、サブイベント処理用作業テーブル１３０の内容をクリアにして終了する。未だ、取得の終わってないサブイベントの情報があれば通知依頼を行わず終了する。（Ｓ４０１〜Ｓ４０９）。
【００４８】
以上複合イベント通知システムの処理を説明した。処理フローで説明した他に、複合サブスクライブ情報管理テーブル１２０を一定時間間隔でチェックして期限切れのサブスクライブ情報に対しては、それまで揃っているコンテンツを集めて通知するようにしてもよい。
（実施形態その２）
実施形態その２は、第２の発明を具現化する例で図１５に全体構成を示す。実施形態その１の全体構成を示す図４に、イベント処理モジュール１０３が複数個を備え、それらを管理するモジュール管理テーブル１５０が加わったもので、他の構成は同一である。異なる部分について説明する。
【００４９】
イベント処理モジュール１０３は、例えば「待ち合わせ（Ｗａｉｔ）」や「順次取得（Ｓｅｑｕｅｎｃｅ）」などの集約ロジック毎のモジュールで構成する。これらのモジュールの実装は、追加や削除など容易に行えるものである。
モジュール管理テーブル１５０は、例えば図１６に示すものでイベントタイプとモジュール名との対応テーブルである。サブスクライブディスパッチャ１０２でイベント処理モジュール１０３を選択する場合に、このモジュール管理テーブル１５０を用いて選択する。
【００５０】
複合サブスクライブ情報管理テーブル１２０およびサブイベント処理用作業テーブル１３０はイベント処理モジュール１０３毎に持たせてある。このようにすることにより、モジュールの実装取り外しが容易になる。
それ以外の機能およびフローは実施形態その１で示した内容と同一である。
（実施形態その３）
実施形態その３は、複合イベント名を指定するだけで、複合サブスクライブ情報を作成し複合イベントの処理を可能とする複合イベント通知システムで図１７にその構成を示す。
【００５１】
図１７は、図１５の構成に複合イベント定義体受付部１０９と複合イベント定義体テーブル１６０とを付加したものである。複合イベント定義体受付部１０９は、利用者等が作成した複合イベント定義体を複合イベント定義体テーブル１６０に格納したり、サブスクライブ情報受付部１０１が受け付けた複合イベント名とパラメータとを貰って複合イベントのサブスクライブ情報を作成し、サブスクライバ情報受付部１０１に返すことを行う。サブスクライブ情報が作成された以降は、実施形態その１で説明した通りであるので省略する。
【００５２】
複合イベント定義体は、例えば図１８に示される記述である。この例では、複合イベント名が「ＭｏｎｔｈｌｙＲｅｐｏｒｔ」で、通知先（ｄｅｓｔｉｎａｔｉｏｎ）や取得するコンテンツ（ｃｏｎｔｅｎｔｓ）、有効期限（ｅｘｐｉｒｅ）をそれぞれのタグで指定している。
サブスクライバ・アプリケーションから指定される複合イベント名とパラメータは、例えば図１９に示すものである。ここでは、複合イベント名が「ＭｏｎｔｈｌｙＲｅｐｏｒｔ」で、パラメータとしてイベントタイプが「Ｗａｉｔ（待ち合わせイベント）」であり、通知して欲しいイベントは「ＭｅｍｂｅｒＡ〜Ｃ」であることを示している。これに対して作成される複合サブスクライブ情報は図２０に示すものであり、図１８および図１９で示された情報が組み合わされて作成されている。図１８〜図２０は、プロジェクトメンバーＡ〜Ｃが作成する月例報告書を期日を設定して収集する応用例であるが、メンバーの変更があっても複合イベント名のパラメータを変えるだけで月例報告書の収集が行える。このように定常的な業務において僅かな変更があるような場合に特に効果が大きい。
【００５３】
また、この定義体を用いて複数の種類の複合イベントの処理を組み合わせることも可能である。例えば、イベントＡとイベントＢを待ち合わせてからイベントＣの情報を取得する、と言った「待ち合わせ」の処理と「順次取得」の処理を組み合わせるようなことである。
（実施形態その４）
実施形態その４は、複数の複合イベント通知システムがお互いの拡張モジュールを利用してイベント通知を行うことを可能とするもので、図２１はその構成を示すものである。
【００５４】
図２１の複合イベント通知システムＡ２００は、モジュール管理テーブル２０３に自身が処理可能なイベント処理モジュールの他に複合イベント通知システムＢ３００が利用可能なイベント処理モジュールの情報（接続先の情報を含む）も持っているものとする。
サブスクライバ・アプリケーションから複合イベント通知システムＡ２００が複合サブスクライブ情報をサブスクライブ情報受付部２０１で受け付けると、サブスクライブディスパッチャ２０２はモジュール管理テーブル２０３を参照して複合イベント通知システムＢ３００のサブスクライブ情報受付部３０１に対してサブスクライブを行う。それを受理した複合イベント通知システムＢ３００は、内部のイベント処理モジュールを利用して通常のサブスクライブの処理を行い、イベント受付部３０２で受け付けたパブリッシャ・アプリケーションからのパブリッシュ情報をイベント処理モジュールのロジックにより取得し、それらをイベントノーティファイア３０３を介して複合イベント通知システムＡ２００のイベントノーティファイア２０４に通知する。複合イベント通知システムＡ２００は、要求を受けたサブスクライバ・アプリケーションにパブリッシュ情報を通知する。あるいは、複合イベント通知システムＢ３００のイベントノーティファイア３０３から直接サブスクライバ・アプリケーションに通知してもよい。
【００５５】
また、複合イベント処理モジュール通知システムＡ２００は、更に他の複数の複合イベント通知システムに回送できるようにモジュール管理テーブル２０３を持つようにしてもよい。
また、複数の複合イベント通知システムがイベント処理モジュールを共通に持つようにしてもよい。その場合は、複合イベント通知システム同士がモジュール管理テーブルを常に最新のものにしておく必要がある。
【００５６】
このように構成することにより、複合イベント通知システムの負荷を１ケ所のシステムに集中することを防ぐことが可能である。
以上四つの実施形態を示したが、本発明をデータベースに組み込むことも可能である。複合サブスクライブ情報として、データベースに格納されている特定のデータに対する操作や変化、処理の過程で発生した障害などをイベントとして捉え、これらを集約する複合イベントが発生した場合に通知を行うような設定が考えられる。また、データベースからのイベントだけでなく、外部サービスからのイベントとも組み合わせて複合イベントの検知を行い通知するようにしてもよい。
【００５７】
【発明の効果】
本発明によれば、イベント間の複雑な連携を図りながらパブリッシュ情報を取得できる。また、パブリッシュ情報の取得ロジックの追加、変更が容易なシステムを構築できる。
【図面の簡単な説明】
【図１】第１の発明の原理図である。
【図２】第３の発明の原理図である。
【図３】イベント通知サービスの説明図である。
【図４】実施形態その１の全体構成図である
【図５】サブスクライブ情報のデータ例である。
【図６】複合サブスクライブ情報管理テーブル１２０のデータ例である。
【図７】サブイベント処理用作業テーブル１３０のデータ例である。
【図８】サブスクライブ情報テーブル１４０のデータ例である。
【図９】パブリッシュ情報のデータ例である。
【図１０】通知情報のデータ例である。
【図１１】サブスクライブ情報登録処理のフロー例
【図１２】待ち合わせイベント処理モジュールによる複合サブスクライブ情報分解処理のフロー例である。
【図１３】パブリッシュ情報取得処理のフロー例である。
【図１４】待ち合わせモジュールのパブリッシュ情報取得処理のフロー例である。
【図１５】実施形態その２の全体構成図である。
【図１６】モジュール管理テーブル１５０のデータ例である。
【図１７】実施形態その３の全体構成図である。
【図１８】複合イベント定義体のデータ例である。
【図１９】複合イベント名とパラメータのデータ例である。
【図２０】複合イベント名から作成されたサブスクライブ情報のデータ例である。
【図２１】実施形態その４の全体構成図である。
【符号の説明】
１：モジュール格納手段
２：複合サブスクライブ情報取得手段
３：サブスクライブ情報登録手段
４：パブリッシュ情報取得手段
５：パブリッシュ情報通知手段
６：複合イベント定義体格納手段
７：複合サブスクライブ情報作成手段
１００：複合イベント通知システム
１０１：サブスクライブ情報受付部
１０２：サブスクライブディスパッチャ
１０３：イベント処理モジュール
１０４：サブスクライブ情報管理部
１０５：イベント受付部
１０６：クロック
１０７：ノーティフィケーションディスパッチャ
１０８：イベントノーティファイア
１０９：複合イベント定義体受付部
１２０：複合サブスクライブ情報管理テーブル
１３０：サブイベント処理用作業テーブル
１４０：サブスクライブ情報テーブル
１５０：モジュール管理テーブル
１６０：複合イベント定義体テーブル
２００：複合イベント通知システムＡ
２０１：サブスクライブ情報受付部
２０２：サブスクライブディスパッチャ
２０３：モジュール管理テーブル
２０４：イベントノーティフィア
３００：複合イベント通知システムＢ
３０１：サブスクライブ情報受付部
３０２：イベント受付部
３０３：イベントノーティファイア
【図１】
2004348680.tif 000003
【図２】
2004348680.tif 000004
【図３】
2004348680.tif 000005
【図４】
2004348680.tif 000006
【図５】
2004348680.tif 000007
【図６】
2004348680.tif 000008
【図７】
2004348680.tif 000009
【図８】
2004348680.tif 000010
【図９】
2004348680.tif 000011
【図１０】
2004348680.tif 000012
【図１１】
2004348680.tif 000013
【図１２】
2004348680.tif 000014
【図１３】
2004348680.tif 000015
【図１４】
2004348680.tif 000016
【図１５】
2004348680.tif 000017
【図１６】
2004348680.tif 000018
【図１７】
2004348680.tif 000019
【図１８】
2004348680.tif 000020
【図１９】
2004348680.tif 000021
【図２０】
2004348680.tif 000022
【図２１】
2004348680.tif 000023