(57)【要約】  処理プラットフォーム、例えばJavaエンタプライズエディション(JEE)プラットフォームは、複数のプロセッサ３を有するJEEクラスタ１を備える。複数のプロセッサ３は、１つ以上のアプリケーションセッションＳ１からＳｎに関連付けられた複数のイベントを取り扱うためのリソースアダプタ１１を含んでいる。各アプリケーションセッションＳ１からＳｎは、セッション状態１５及びイベントキュー１７を有している。イベントキュー１７は、セッションＳ１からＳｎの特定の１つのために実行されるべき複数のイベントのリストを格納している。スレッドプール１９は、プロセッサ３が複数のタスクを並列に処理できるよう、１つ以上の処理スレッドｔ１〜ｔＮを有している。スレッドプール１９は、処理スレッドｔ１〜ｔＮによって実行されるべき複数のタスクを格納するタスクキュー２１を有する。リソースアダプタ１１は、スレッドプールからの複数のスレッドｔ１からｔＮが、複数のアプリケーションセッションＳ１からＳｎにおける複数のイベントをどのように取り扱うかを制御するための同期部２３を有する。具体的には、同期部２３は、イベントキュー１７内で待たされているイベントの１つだけが、自身にスケジュールされたタスクをタスクキュー２１に有するように構成され、それによって、あるアプリケーションセッションのある特定のイベントキューからの２つ以上のイベントが並列に実行されることを回避する。【選択図】図３
2013500526.tif 000002
【特許請求の範囲】
【請求項１】
電気通信処理プラットフォーム内で複数のアプリケーションセッションに関連付けられた複数のイベントの処理を同期させるための方法であって、前記電気通信処理プラットフォームは複数のタスクを並列に処理するための複数の処理スレッドを有し、前記複数のタスクはタスクキューに格納され、前記方法が、
特定のアプリケーションセッションに関連付けられたイベントキューに１つ以上のイベントを格納するステップと、
特定のアプリケーションセッションの前記イベントキュー内の１つのイベントだけに、前記タスクキュー内のタスクを割り当てるステップと、を有することを特徴とする方法。
【請求項２】
イベントを前記イベントキューに格納する前記ステップが、
前記イベントが前記イベントキュー内の最初のイベントかどうかを判別し、最初のイベントであれば、該イベントに前記タスクキュー内のタスクを割り当てるステップを有することを特徴とする請求項１記載の方法。
【請求項３】
前記イベントキューから処理済みのイベントを除去するステップをさらに有し、該除去するステップが、
前記イベントキューが空かどうかを判別し、空で無ければ、前記イベントキュー内の別のイベントに前記タスクキュー内のタスクを割り当てるステップを有することを特徴とする請求項１または請求項２記載の方法。
【請求項４】
タスクを割り当てる前記ステップが、前記イベントキュー内の次のイベントにタスクを割り当てるステップを有することを特徴とする請求項３記載の方法。
【請求項５】
格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項２記載の方法。
【請求項６】
格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項３または請求項４記載の方法。
【請求項７】
前記不可分の動作を実行するためにロックを用いるステップをさらに有することを特徴とする請求項５または請求項６に記載の方法。
【請求項８】
前記不可分の動作を実行するためにアトミックカウンタを用いるステップをさらに有することを特徴とする請求項５または請求項６に記載の方法。
【請求項９】
前記アトミックカウンタは、格納するステップまたは除去するステップのそれぞれの間に増加または減少されるカウント値を有し、前記カウント値が、前記キューが空か否か、または、あるイベントが前記イベントキュー内の最初のイベントかどうかを示すことを特徴とする請求項８記載の方法。
【請求項１０】
前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１乃至請求項９のいずれか１項に記載の方法。
【請求項１１】
タスクキューに格納されている複数のタスクを並列に処理するための複数の処理スレッドを有する電気通信処理プラットフォームで用いるためのリソースアダプタであって、
それぞれがあるアプリケーションセッションに関連付けられ、対応するアプリケーションセッションに関連付けられた１つ以上のイベントを格納するように構成された１つ以上のイベントキューと、
あるイベントキュー内の複数のイベントの処理を同期させるための同期手段であって、あるイベントキュー内の１つのイベントにのみ前記タスクキュー内のタスクを割り当てる同期手段と、を有することを特徴とするリソースアダプタ。
【請求項１２】
前記同期手段は、イベントをイベントキューに格納する際に、イベントがイベントキューに挿入されるべき最初のイベントか否かを判別し、イベントがイベントキューに挿入されるべき最初のイベントであれば、該イベントに対して前記タスクキュー内のタスクを割り当てるように構成されることを特徴とする請求項１１記載のリソースアダプタ。
【請求項１３】
前記同期手段は、イベントを前記イベントキューから除去する際に、前記イベントキューが空か否かを判別し、前記イベントキューが空でなければ、前記イベントキュー内の別のイベントに前記タスクキュー内のタスクを割り当てるように構成されることを特徴とする請求項１１または請求項１２記載のリソースアダプタ。
【請求項１４】
前記同期手段が、前記イベントキュー内の前記次のイベントにタスクを割り当てるように構成されることを特徴とする請求項１３記載のリソースアダプタ。
【請求項１５】
アトミックカウンタをさらに有し、前記アトミックカウンタは、対応するイベントキューが空か否かを示すカウント値を有することを特徴とする請求項１１乃至請求項１４のいずれか１項に記載のリソースアダプタ。
【請求項１６】
前記同期手段が、前記イベントキューにイベントを格納する際に前記アトミックカウンタの前記カウント値を増加させるように構成されることを特徴とする請求項１５記載のリソースアダプタ。
【請求項１７】
前記同期手段が、前記イベントキューからイベントを除去する際に前記アトミックカウンタの前記カウント値を減少させるように構成されることを特徴とする請求項１５または請求項１６記載のリソースアダプタ。
【請求項１８】
イベントキューがファーストインファーストアウトキューを有することを特徴とする請求項１１乃至請求項１７のいずれか１項に記載のリソースアダプタ。
【請求項１９】
前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１１乃至請求項１８のいずれか１項に記載のリソースアダプタ。
【請求項２０】
請求項１１乃至請求項１９のいずれか１項に記載のリソースアダプタを有するか、請求項１乃至請求項１０のいずれか１項に記載の方法を実行するように構成されたJEEクラスタ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電気通信ネットワーク内のイベントを処理するための装置および方法に関し、特に、電気通信処理プラットフォーム、例えばJava（登録商標）エンタプライズエディション(Java Enterprise Edition: JEE)におけるアプリケーションセッションと関連付けられたイベントの処理を同期させるための方法および装置に関する。
【背景技術】
【０００２】
電気通信ネットワークには、通常の呼に追加機能を提供するための多くのアプリケーションおよびサービスが存在している。これらアプリケーションおよびサービスは、電気通信ネットワークに接続される別個のサーバで稼動するのが一般的である。これらサーバは通常、通信ネットワーク自体とは異なるプラットフォーム上で稼働する。
【０００３】
そのようなプラットフォームの１つはＪＥＥ(Java Enterprise Edition)プラットフォームであり、スタンダードJavaプラットフォームの拡張(development)である。ＪＥＥはJavaプログラム言語でサーバプログラムを作成するために広く用いられているプラットフォームである。ＪＥＥプラットフォームは、アプリケーションサーバ上で稼働するモジュラコンポーネントに主に基づいて、耐障害性があり、分散型で、多階層(multi-tier)のJavaソフトウェアを展開する機能を提供するライブラリを追加している点でスタンダードJavaプラットフォームと異なる。ＪＥＥプラットフォームの機能の１つは、並行して稼動する複数の処理スレッドを可能とすることであり、それによってタスク実行スループットが向上する。
【０００４】
ＪＥＥプラットフォームは多くのアプリケーションに向いているが、以下に説明するように一部の電気通信サービスには非実用的となりうる。
【０００５】
電気通信プロトコルの処理は、アプリケーションセッションに関連付けられた状態機械の使用を必要とするのが一般的である。これら状態機械に対しては、状態が壊れないよう、一度に１つのメッセージのみを受信する必要がある。ＪＥＥプラットフォームそれ自体は、ある特定のアプリケーションセッション上で一度に複数のメッセージを処理するための手段を提供しない。その一方で、ＪＥＥプラットフォームは通常、処理すべきメッセージと同じ数の並列スレッドを開始するであろう。
【０００６】
図１は、複数のプロセッサ３を有する典型的なＪＥＥクラスタ１を示している。プロセッサ３は同一かつＪＥＥクラスタ１の負荷を分担することができる。電気通信処理プラットフォームとして用いられる場合、個々のプロセッサ３は通常、いくつかのコンテナ、例えばＥＪＢ(Enterprise Java Beans)５、ＨＴＴＰサーブレット７、セッション開始プロトコル(SIP)サーブレット９または、レガシシステムと通信するための他のリソースアダプタのような他の実行ユニット１３を有するであろう。
【０００７】
図１に示すアーキテクチャは、スレッドプール１９を有する。スレッドプール１９は、プロセッサ３が複数のタスクを並列処理することを可能にするための１つ以上の処理スレッドｔ１からｔＮを有している。スレッドプール１９はまた、スレッドｔ１からｔＮによって実行すべき一群のタスクを格納したタスクキュー２１を有している。個々の処理スレッドｔ１からｔＮは、一度に１つのタスクを取り扱う。
【０００８】
上述の通り、ＪＥＥプラットフォームは、システム内に定義されたスレッドと同数のタスクを並列に処理しようとするように構成されている。これは、図１に示すようなＪＥＥプラットフォームが電気通信アプリケーションおよびサービスを取り扱うために用いられている際に問題となり得る。それにより、複数のスレッドｔ１からｔＮが複数のアプリケーションセッションに関連付けられた複数のイベントを並列に処理する場合、セッション状態が無効となりうる。換言すれば、あるアプリケーションセッションにおける複数のイベントが、同一のセッション状態を同時に更新している。
【０００９】
イベント同期を確実にする１つの方法は、あるアプリケーションにおける複数のイベントが同一のセッション状態を同時に更新できなくするためのロックまたはセマフォを用いることである。そのため、１つのスレッドｔ１からｔＮがある特定のアプリケーションセッションに関連付けられたイベントを処理している際、他の全てのスレッドはその１つのスレッドが完了するまで待機しなければならない。これは、多くのスレッドｔ１からｔＮが待機させられ、システムリソースを最適に利用していないという点で不利であり、また通常はＪＥＥプラットフォームの原則と相容れないものである。
【００１０】
イベント同期を確実にする別の方法は、複数のスレッドｔ１からｔＮの１つだけを各アプリケーションセッションに割り当てることである。そのようにすることで、各アプリケーションセッションはそのイベントを取り扱うための専用のスレッドを持つ。しかし、そのような解決方法は上述したスレッドプール機構の問題を有し、そのため、（スレッドを含む）全てのリソースが管理されねばならないという重要なＪＥＥプラットフォームの原則に違反する。この解決方法はまた、必要数よりもずっと多くのスレッドｔ１からｔＮを用いるという問題を有しており、リソース効率が良くない。
【００１１】
以上のことから、リソース効率を妥協せずにイベント同期を実施することが困難であることが理解されるであろう。
【発明の開示】
【００１２】
本発明の目的は、電気通信ネットワークで用いるための処理プラットフォーム内のイベントの処理を、リソース効率の良い方法で同期させるための方法および装置を提供することである。
【００１３】
本発明の第１の見地によれば、電気通信処理プラットフォーム内で複数のアプリケーションセッションに関連付けられた複数のイベントの処理を同期させるための方法であって、前記電気通信処理プラットフォームは複数のタスクを並列に取り扱うための複数の処理スレッドを有し、前記複数のタスクはタスクキューに格納される。前記方法は、１つ以上のイベントをある特定のアプリケーションセッションに関連付けられたイベントキューに格納するステップと、前記タスクキュー内のあるタスクを、特定のアプリケーションセッションの前記イベントキュー内のただ１つのイベントに割り当てるステップとを有する。
【００１４】
本発明は、ある特定のアプリケーションセッションのあるイベントキュー内のただ１つのイベントが、割り当てられたタスクを有するので、複数のイベントが同時に取り扱われることを回避できるという利点を有する。本発明はまた、既存のスレッドプール自体がタスクキューからの複数のタスクを取り扱う方法を変更する必要が無いという利点も有する。
【００１５】
あるイベントを前記イベントキューに格納するステップは、前記イベントが前記イベントキューの最初のイベントかどうかを判定するステップと、もしそうであれば、前記タスクキュー内のあるタスクに、その特定のイベントを割り当てるステップとを有してよい。
【００１６】
前記イベントキューから処理済みのイベントを除去するステップは、前記イベントキューが空かどうかを判定するステップと、もしそうでなければ、前記タスクキュー内のあるタスクを、前記イベントキュー内の別のイベントに割り当てるステップを有してよい。タスクを割り当てる前記ステップは、タスクを前記イベントキュー内の次のイベントに割り当てるステップを有してよい。
【００１７】
イベントキューにイベントを格納するステップおよび前記イベントが前記イベントキュー内の最初のイベントかどうかを判定するステップは、分割できない１つの動作として実行されてよい。これは、競合状態を回避するという利点がある。
【００１８】
イベントキューからイベントを除去するステップおよび前記イベントキューが空かどうかを判定するステップは、分割できない１つの動作として実行されてよい。これもまた、競合状態を回避するという利点がある。
【００１９】
本発明の一見地によれば、不可分の動作を実行するためのロックが提供されてもよい。あるいは、不可分の動作を実行するためにアトミックカウンタが用いられてもよい。アトミックカウンタは、格納するステップまたは除去するステップのそれぞれにおいて増加または減少される計数値を有し、前記計数値は前記イベントキューが空かどうか、またはあるイベントが前記イベントキューの最初のイベントかどうかを示す。
【００２０】
前記方法は、ＪＥＥ(Java Enterprise Edition)処理プラットフォームを有する電気通信処理プラットフォームで実行されてよい。
【００２１】
本発明の別の見地によれば、タスクキューに格納されている複数のタスクを並列に処理するための複数の処理スレッドを有する電気通信処理プラットフォームで用いるためのリソースアダプタが提供される。リソースアダプタは１つ以上のイベントキューを有する。各イベントキューはあるアプリケーションセッションに関連付けられるとともに、対応するアプリケーションセッションに関連付けられた１つ以上のイベントを格納するように構成される。前記リソースアダプタは、あるイベントキュー内の複数のイベントの処理を同期させるための同期手段を有し、前記同期手段は前記タスクキュー内のあるタスクをあるイベントキュー内のただ１つのイベントに割り当てるように構成される。
【００２２】
本発明の別の見地によれば、本発明に係るリソースアダプタを有するＪＥＥクラスタまたは、本発明に係る方法を実行するように構成されたＪＥＥクラスタが提供される。
【００２３】
本発明は、不必要にスレットをブロックすることなく、また、可能な限り多くの（異なるアプリケーションセッションからの）イベントを同時に処理することにより、複数のキューからの複数のイベントを取り扱うためにスレッドプールを効率的に用いることができるという利点を有する。本発明では、デッドロックおよびライブロックも生じない。
【図面の簡単な説明】
【００２４】
【図１】既知のＪＥＥクラスタの典型的なアーキテクチャを示す図である。
【図２】複数のアプリケーションセッションを取り扱うためのリソースアダプタを有するＪＥＥアーキテクチャを示す図である。
【図３】本発明の実施形態に係るリソースアダプタを示す図である。
【図４】本発明の実施形態に係る方法で実行されるステップを示す図である。
【図５】本発明の一見地に係る方法で実行されるステップを示す図である。
【図６】本発明の別の見地に係る方法で実行されるステップを示す図である。
【図７】本発明の別の見地に係る方法で実行されるステップを示す図である。
【図８】本発明の別の見地に係る方法で実行されるステップを示す図である。
【図９】複数のイベントがどのようにして本発明に従って取り扱われうるかの一例を提供する図である。
【図１０】複数のイベントがどのようにして本発明に従って取り扱われうるかの一例を提供する図である。
【図１１】複数のイベントがどのようにして本発明に従って取り扱われうるかの一例を提供する図である。
【図１２】複数のイベントがどのようにして本発明に従って取り扱われうるかの一例を提供する図である。
【発明を実施するための形態】
【００２５】
本発明のより良い理解のため、また本発明がどのようにして実行されうるかをより明確に示すため、以下では例証として添付図面を参照する。
【００２６】
以下において、本発明はＪＥＥプラットフォームに関して説明される。しかしながら、スレッドプールとの組み合わせにより、すなわち、イベント処理を用いる任意のセッションフレームワークにより、複数のイベントおよびセッションの処理を取り扱う、他の型式のプラットフォームに対しても、本発明は適用可能であることが理解されよう。さらに、本発明を電気通信環境に関して説明するが、本発明は同様の問題を有する他のアプリケーションに対しても適用可能である。
【００２７】
本発明によれば、イベント同期は、複数のアプリケーションセッションを取り扱うように特に構成されたリソースアダプタを設けるとともに、ある特定のアプリケーションセッションに関連付けられたあるイベントキューにイベントを待ち行列化させ、そのイベントキューからのあるイベントを取り扱うために、一度にただ１つのタスクだけをスケジュールすることによって達成される。例えば複数のイベントはFIFOキュー内で待ち行列化されてよく、またそのイベントキュー内の最初のイベントを取り扱うために一度にただ１つだけのタスクをスケジュールする。
【００２８】
図２は、複数のプロセッサ３を有する典型的なＪＥＥクラスタ１を示している。個々のプロセッサ３は通常、いくつかのコンテナ、例えばＥＪＢ(Enterprise Java Beans)５、ＨＴＴＰサーブレット７、セッション開始プロトコル(SIP)サーブレット９または、レガシシステムと通信するための他のリソースアダプタのような他の実行ユニット１３を有する。図２のアーキテクチャはまた、複数のアプリケーションセッションを取り扱うために設けられたセッションリソースアダプタ１１を有するものとして図示されている。
【００２９】
リソースアダプタ１１は、１つ以上のアプリケーションセッションＳ１からＳｎを有している。アプリケーションセッションＳ１からＳｎはおのおの、セッション状態１５およびイベントキュー１７を有しており、イベントキュー１７は、アプリケーションセッションＳ１からＳｎの特定の１つのために実行されるべき複数のイベントのリストを格納している。一例として、”アプリケーションセッション”は、電気通信システムにおいて新たな呼が開始されている際に生成されうる。そのため、アプリケーションセッションは開始されている呼に関連付けられたサービスの形式であってよく、例えば発呼者へのお知らせを再生するためのサービスの形式であってよい。また、あくまで例示として、”イベント”は、呼の最中に発生する複数のイベントに関連付けられた用語であり、例えば被呼者による呼への応答、被呼者による自身の電話機への情報入力などである。なお、これらは何をセッションやイベントと見なすことができるかの単なる例示であり、本発明は処理可能なアプリケーションセッションまたはイベントのいかなる形式も包含し、電気通信、ＳＩＰまたはウェブベースのセッションおよびイベントを含むことを意図しているることに留意されたい。
【００３０】
リソースアダプタ１１は、スレッドプール１９を用いる。スレッドプール１９はリソースアダプタ１１内に設けられてもよいし、システム内の他の複数の構成要素と共用されてもよい。スレッドプール１９は、複数のプロセッサ３が複数のタスクを並列に実行可能なように、１つ以上のスレッドｔ１からｔＮを有している。スレッドプール１９はまた、スレッドｔ１からｔＮによって実行すべき一連のタスクを格納したタスクキュー２１を有している。処理スレッドｔ１からｔＮのおのおのは、一度に１つのタスクを取り扱う。典型的な電気通信アプリケーションにおいて、スレッドｔ１からｔＮの数は、アプリケーションセッションＳ１からＳｎの数よりもずっと少ないのが一般的であることに留意されたい。
【００３１】
上述の通り、ＪＥＥプラットフォームは、システム内に定義されたスレッドと同数のタスクを並列に実行しようとするように構成されている。これは、図２に示すようなＪＥＥプラットフォームが電気通信アプリケーションおよびサービスを取り扱うために用いられている際に問題となり得る。なぜなら、複数のスレッドｔ１からｔＮがある特定のアプリケーションセッションＳ１からＳｎからの複数のイベントを並列に処理する場合、セッション状態が無効となりうるからである。換言すれば、あるアプリケーションセッションにおける複数のイベントが、同一のセッション状態を同時に更新している。
【００３２】
図１に関して上述したように、イベント同期を確実にするための１つの方法は、ある特定のアプリケーションセッションＳ１からＳｎのイベントキュー１７上の相互排除を生成するためのロックまたはセマフォを用いることかもしれない。そうすると、１つのスレッドｔ１からｔＮがある特定のアプリケーションセッションＳｘのイベントキュー１７（すなわち、次のイベントを取り扱うイベントキュー）にアクセスしている際、他の全てのスレッドはその１つのスレッドが完了するまで待機しなければならない。これは、多くのスレッドｔ１からｔＮが待機させられ、システムリソースを最適に利用していないという点で不利であり、またＪＥＥプラットフォームの原則と相容れないものである。
【００３３】
これも上述したように、イベント同期を確実にする別の方法は、複数のスレッドｔ１からｔＮの１つだけを各アプリケーションセッションＳ１からＳｎに割り当てることかもしれない。そうすると、各アプリケーションセッションＳ１からＳｎは自身のイベントキューからの複数のイベントを取り扱う専用のスレッドを持つ。しかし、そのような解決方法は上述したスレッドプール機構の問題を有し、そのため、（スレッドを含む）全てのリソースが管理されねばならないという重要なＪＥＥプラットフォームの原則に違反する。この解決方法はまた、必要数よりもずっと多くのスレッドｔ１からｔＮを用いるという問題を有しており、リソース効率が良くない。
【００３４】
図３は、本発明の実施形態とともに用いるためのアーキテクチャを示している。図２示したように、ＪＥＥプラットフォームは複数のプロセッサ３を有するＪＥＥクラスタ１を備えている。必須ではないが、複数のプロセッサ３は同一であって良く、また複数のプロセッサ３はＪＥＥクラスタ１の負荷を分担することができる。あるプロセッサ３は１つ以上のコンテナ、例えばＥＪＢ(Enterprise Java Beans)５、ＨＴＴＰサーブレット７、セッション開始プロトコル(SIP)サーブレット９または、レガシシステムと通信するための他のリソースアダプタのような他の実行ユニット１３を有してよい。図２に示すように、プロセッサはセッションリソースアダプタ１１をさらに有してよい。
【００３５】
図３に示すアーキテクチャにおいて、アプリケーションセッションを取り扱うためのリソースアダプタ１１は、１つ以上のアプリケーションセッションＳ１からＳｎを有している。アプリケーションセッションＳ１からＳｎはおのおの、セッション状態１５およびイベントキュー１７を有しており、イベントキュー１７は、アプリケーションセッションＳ１からＳｎの特定の１つのために実行されるべき一群のイベントを格納している。
【００３６】
セッション状態１５およびイベントキュー１７はメモリ内に格納される。一実施形態によればセッション状態は、そのアプリケーションセッションが開始された（また、通常は関連付けられた通信セッションが存在する）プロセッサ上のメモリ内に保持されてよい。この形式のプロセッサアフィニティを用いることにより、（ローカルネットワークを通じて）プロセッサ間でイベントを不必要にルーティングする必要が無いという利点がある。さらに、セッション状態をクラスタ内で分散する必要が無く、セッション状態が存在するプロセッサがクラッシュすれば自動的に存在しなくなるであろう。本発明において、セッション状態およびイベントキューの保存場所に制限はない。
【００３７】
図３に示す実施形態において、リソースアダプタ１１はさらに、スレッドプール１９を有している。スレッドプール１９は、プロセッサ３が複数のタスクを並列に実行することを可能にするための１つ以上の処理スレッドｔ１からｔＮを有している。スレッドプール１９はまた、スレッドｔ１からｔＮによって実行すべき複数のタスクを格納するタスクキュー２１を有している。個々の処理スレッドｔ１からｔＮは、一度に１つのタスクを取り扱う。プロセッサは任意の数のアプリケーションセッションＳ１からＳｎと、任意の数のスレッドｔ１からｔＮを有してよい。スレッドプール１９はリソースアダプタ１１に専用であっても、プロセッサ３上の他の構成要素と共用されてもよいことに留意されたい。また、図３においてスレッドプール１９はリソースアダプタ１１の一部として示しているが、スレッドプール１９はシステム内のいかなる場所に存在してもよく、その場合リソースアダプタ１１はどこかに存在するスレッドプール１９の利用を共用することに留意されたい。
【００３８】
本発明によれば、リソースアダプタ１１はスレッドプールからの複数のスレッドｔ１からｔＮが複数のアプリケーションセッションＳ１からＳｎにおける複数のイベントをどのように取り扱うかを制御するための同期部２３を有する。別の実施形態において、各アプリケーションセッションは、図７および図８に関して後述するように、競合状態を回避するための手段２５を有するか、例えばアトミックカウンタのようなカウンタ２５を用いて、所定の複数のステップが不可分な方法で実行されることを可能にするための手段を有してよい。
【００３９】
図２に関して上述したように、図３の同期部２３が無いと、ＪＥＥプラットフォームはスレッドプール１９内の処理スレッドｔ１からｔＮを制御することができず、スレッドプール１９が、スレッドｔ１からｔＮのうち利用できるものを最大限使用してアプリケーションセッションＳ１からＳｎの複数のイベントキューを空にしようとするかもしれず、その結果、ある特定のアプリケーションセッションのイベントキュー１７から複数のイベントを取り扱う危険を冒すかもしれない。
【００４０】
しかし、本発明による同期部２３は、関連付けられたアプリケーションセッションのイベントキュー１７内の各イベントについてタスクがスケジュールされないように構成されている。その代わりに、同期部２３はあるアプリケーションセッションＳ１からＳｎのイベントキュー１７からのただ１つのイベントだけが、割り当てられたタスクを有するように構成されている。例えば、あるイベントキュー１７に複数のイベントがファスートインファストアウト(FIFO)キュー形式で格納されている場合、同期部２３は、イベントキュー１７内の最初のイベントだけが、スレッドプール１９に関連付けられたタスクキュー２１内にスケジュールされたタスクを有するようにリソースアダプタ１１の動作を制御するように構成される。
【００４１】
図４は、本発明の実施形態によって実行されるステップを示している。ステップ４０１において、あるアプリケーションセッションに関連付けられているあるイベントキューに、１つ以上のイベントが格納される。ステップ４０２に示すように、タスクキュー内のタスクは、ある特定のアプリケーションセッションのイベントキュー内のただ１つのイベントに割り当てられている。これをどのようにして実行しうるかについての例を以下に説明する。
【００４２】
あるイベントキューから１つのイベントだけが割り当てられたタスクを有することを同期部２３が保証するのは主に２通りの場合がある。その１つの場合は、あるイベントがイベントキューに追加されている場合、すなわち、イベントキューに格納もしくは挿入されている場合に関する。もう一つの場合は、あるイベントがイベントキューから除去されている場合、すなわち、イベントキューからのあるイベントがスレッドによって処理された場合に関する。
【００４３】
図５は、あるイベントをイベントキューに挿入する際に実行されるステップを示している。ステップ５０１で、ある特定のアプリケーションセッションのイベントキュー内に新たなイベントを挿入すべきであることが決定される。同期部２３は、ステップ５０３でまずそのイベントをイベントキューに格納するように構成される。続いて同期部２３はステップ５０５で、挿入されたイベントが、イベントキュー内の最初のイベントかどうかを判別するように構成される。もしそうでなければ、同期部２３はその特定のイベントに対してタスクキュー内のタスクをスケジュールしない。しかし、ステップ５０５で、そのイベントがキュー内の最初のイベントであると判別された場合、同期部２３はステップ５０７で、タスクキュー内のタスクをそのイベントに割り当てる。このように、あるイベントキュー内の最初のイベントだけが、タスクキュー内に割り当てられたタスクを有することが理解されるであろう。
【００４４】
後述するように、イベントをキューに挿入または格納するステップ（ステップ５０３）および、そのイベントがキュー内の最初のイベントかどうかを判別するステップ（ステップ５０５）は、不可分の動作であることが好ましい。換言すれば、これらステップは、その実行についてシステム内のいかなる他の処理スレッドにも影響を受けないような方法で実行される。
【００４５】
図６は、あるイベントキューからのあるイベントが取り扱われる際に実行されるステップおよび、引き続くステップを示している。図５に関して上述したように、イベントキュー内には１つ以上のイベントが挿入されている。ステップ６０１で、タスクキュー内に割り当てられているタスクを有するイベント、すなわちイベントキュー内の最初のイベントが、スレッドによって処理される。そのイベントは、処理された後にイベントキューから取り除かれる（ステップ６０３）。そして、同期部２３はステップ６０５で、イベントキューが空かどうか判別する。ステップ６０５でイベントキューが空でないと判別されれば、同期部２３はステップ６０７でそのイベントキュー内の別のイベント、例えば次のイベントに対して新たなタスクをスケジュールするように構成される。図６に示したプロセスは、ステップ６０５においてイベントキュー内にイベントが存在しないと判別され、（タスクをスケジュールするイベントがイベントキューに残っていないため）新たなタスクをスケジュールすることなく処理が終了するまで、ステップ６０１においてイベントキュー内の最初のイベントを処理するスレッドと別のスレッド（または同一のスレッド）によって継続される。
【００４６】
ここまでの説明から、特定のイベントキューからの２番目のイベントは、最初のイベントが完全に処理された後にだけ処理されうることが理解される。特に、２番目のイベントは、最初のイベントがそのキューから除去された後（２番目のイベントが最初にイベントになってから）にだけ取り扱うことができる。所望の機能を実現できるよう、あるイベントは処理された後でイベントキューから除去される。
【００４７】
後述するように、イベントをイベントキューから除去するステップ（ステップ６０３）および、そのイベントが空かどうかを判別するステップ（ステップ６０５）は、不可分の動作であることが好ましい。換言すれば、これらステップは、システム内のいかなる他の処理スレッドにも影響を受けないような方法で実行される。
【００４８】
同期部２３が構成される方法は、通常は同一である、スレッドによって実行されるタスクと、イベントを取り扱うルーチンとが区別されていることを暗に示している。
【００４９】
図６から、タスクが３つの違ったステップによってスケジュールされることが理解されるであろう。１つめは、イベント取扱いルーチンが、キュー内の最初のイベントにたいしてのみ実行されることである。そして、このイベントはそのキューから除去され、そのキューにまだイベントがあるかどうかの判定がなされ、もしあれば、そのイベントキューに対して新たなタスクが生成され、そのタスクがスレッドプールに提供される。
【００５０】
従って、スレッドプールのタスクキューにタスクがスケジュールされる２つの異なる場所が存在することが理解されよう。イベントキュー内の”最初のイベント”に対するタスクは、イベントを挿入したスレッドによって常にスレッドプールに提供される。”次のイベント”に対するタスクは、”最初のイベント”を取り扱ったスレッドによって常にスレッドプールに提供される。これは、キューが空になったときを両方のスレッドが判断しなくてはならないという競合状況の存在につながりうる。つまり、挿入するスレッドは、イベントを挿入する前にキューが空かどうかを判断しなければならない（キューが空であればタスクをスケジュールする必要があるため）。そして、除去するスレッドは、イベントを除去した後にキューが空かどうかを判断しなければならない（キューが空でなければ新たなタスクをスケジュールする必要があるため）。
【００５１】
挿入前にイベントキューが１つのイベント（処理中の１つ）を有しており、それが、挿入するスレッドがイベントを挿入できるようになる前に処理スレッドによって除去されることが起こりうる。挿入するスレッドは空のキューを見ていないので、タスクをスケジュールせず、それ以降イベントは処理されなくなるであろう。
【００５２】
また、２つ（以上）の挿入するスレッドのいずれもが、イベントを挿入する前にキューが空であると判別することも起こりうる。いずれのスレッドも空のキューを見ているため、両方でタスクをスケジュールし、同時に２つのイベントが処理されるであろう。
【００５３】
上述した競合状況は、不可分動作として、イベントキューにイベントを挿入または格納するステップと、イベントがイベントキュー内の最初のイベントかどうかを判別するステップとを実行することによって解決することができる。同様に、上述した競合状況は、不可分動作として、イベントキューからイベントを除去するステップと、イベントキューが空かどうかを判別するステップとを実行することによって解決することができる。これらの不可分動作は、図５および図６においてステップ５０９および６０９としてそれぞれ示されている。
【００５４】
図７および図８は、上述したような競合状況を回避するためのアトミックカウンタを有する、本発明の別の実施形態の動作を示している。
【００５５】
別の実施形態において、不可分動作はイベントキューに対するアトミックカウンタによって実現されてよい。処理するスレッドはアトミックカウンタを減少させ、全ての挿入するスレッドはアトミックカウンタを増加させる。増加および減少は、以前の値に戻すアトミックまたは不可分な動作であるため、スレッドはキューが空であるかどうか、またはキューが空であったかどうかを、安全に判定することができる。
【００５６】
図７は、あるイベントをイベントキューに挿入する際に実行されるステップを示している。ステップ７０１で、ある特定のアプリケーションセッションのイベントキュー内に新たなイベントを挿入すべきであることが決定される。ステップ７０３でまず同期部２３は、そのイベントをイベントキューに格納するように構成される。同期部２３はステップ７０４でカウンタを増加させるように構成され、それによって新たなイベントがイベントキューに追加されたことを示す。同期部２３はさらに、ステップ７０６において、そのイベントがイベントキュー内の最初のイベントかどうかを、カウント値が、増加させる以前にゼロであったかどうかをチェックすることにより、すなわち、イベントキューが空だったかどうかをチェックすることにより判別するように構成される。以前のカウント値がゼロでは無く、そのイベントがイベントキュー内の最初のイベントではないと判別された場合、同期部２３は、その特定のイベントについて、タスクキュー内のタスクをスケジュールしない。以前のカウンタ値がゼロであったことにより、ステップ７０６において、そのイベントが最初のイベントであると判別された場合、同期部２３はステップ７０７において、そのイベントに対してタスクキュー内のタスクをスケジュールする。このように、新たなイベントをイベントキューに挿入する際にカウンタを増加させることが、そのイベントキューが空かどうかに関する明確な指標を提供することが理解されるであろう。
【００５７】
図８は、あるイベントキューからのあるイベントが取り扱われる際に実行されるステップおよび、引き続くステップを示している。図７に関して上述したように、１つ以上のイベントがイベントキューに挿入されており、従ってカウンタの値はゼロでない。ステップ８０１において、割り当てられているタスクを有するイベント、すなわちイベントキューの最初のイベントが処理される。処理の後、ステップ８０３でそのイベントはイベントキューから除去される。
【００５８】
本発明の本実施形態によれば、同期部２３はステップ８０４において、カウンタ２５を減少させ、それによってイベントキューが空かどうかを示すように構成される。そして同期部２３は、ステップ８０６において、イベントキューが空かどうかを、カウンタ２５のカウント値がゼロかどうかをチェックすることによって判別する。ステップ８０６でイベントキューが空でないと判別されれば、同期部２３はステップ８０７でそのイベントキュー内の別のイベント、例えば次のイベントに対して、新たなタスクをスケジュールするように構成される。順番が来ると、その新たなタスクは、図８に示されるものと同じステップを、スレッドプールからの新たなスレッドにおいて実行する。
【００５９】
この処理は、ステップ８０６において、イベントキューにイベントが存在しない、すなわちカウント値がゼロであると判別され、処理が終了するまで継続される。このように、イベントキューからイベントを除去する際にカウンタを減少させることが、イベントキューが空かどうかに関する明確な指標を提供することが理解されるであろう。
【００６０】
なお、カウンタを、イベントキューが空かどうかを示すための手段、すなわち図５〜８に示した複数のステップの不可分性の実現を提供するための手段として説明してきたが、この指標を提供するため、従って競合状況を回避するために、他の手段を用いてもよいこと、例えばセマフォのようなロックを用いてもよいことが理解されよう。
【００６１】
上述した本発明は、不必要にスレットをブロックすることなく、また、可能な限り多くの（異なるアプリケーションセッションからの）イベントを同時に処理することにより、複数のキューからの複数のイベントを処理するためにスレッドプールを効率的に用いることができるという利点を有することが理解されよう。ここで説明したシステムはまた、デッドロックおよびライブロックが生じない。
【００６２】
図９から図１２は、本発明によって複数のイベントの処理がどのように同期されるかを説明するために提供されている。この例において、４つのアプリケーションセッションＳ１〜Ｓ４と、２つの処理スレッドｔ１，ｔ２を有するスレッドプールが図示されている。図９を参照すると、アプリケーションセッションＳ１が３つのイベント（ｅ１ａ，ｅ１ｂ，ｅ１ｃ）を有し、Ｓ２が２つのイベント（ｅ２ａ，ｅ２ｂ）を有し、Ｓ３が１つのイベント（ｅ３ａ）を有し、Ｓ４がイベントを有していないものとして図示されている。スレッドｔ１およびｔ２はいずれもアイドル状態であり、タスクはアプリケーションセッションＳ１，Ｓ２，およびＳ３にスケジュールされているものとして図示されている。
【００６３】
図１０はこの時点で何が起こりうるかを示している。スレッドｔ１がアプリケーションセッションＳ１のためのタスクを実行しており、従って、アプリケーションセッションＳ１のイベントキューからのイベントｅ１ａについてのイベント取扱いルーチンを実行している。並行して、スレッドｔ２は、アプリケーションセッションＳ２のためのタスクを実行しており、従って、アプリケーションセッションＳ２のイベントキューからのイベントｅ２ａについてのイベント取扱いルーチンを実行している。これらタスクはタスクキューから直ちに除去され、タスクキューにはアプリケーションセッションＳ３のためのタスクだけが残る。２つのスレッドｔ１，ｔ２しか存在しないため、アプリケーションセッションＳ３のためのタスクはスレッドｔ１，ｔ２の一方がアイドルになるまで待機しなければならない。
【００６４】
図１１は、他のスレッドが、アプリケーションセッションＳ４のためのイベントキューにイベントｅ４ａを挿入したと仮定した状態を示している。アプリケーションセッションＳ４のためのイベントキューは空であるため、同期部は、スレッドプールのタスクキューに、アプリケーションセッションＳ４のための新たなタスクをスケジュールする。その後、スレッドｔ２がイベントｅ２ａの処理を終えたものとする。すると、スレッドｔ２は、アプリケーションセッションＳ２のイベントキューからイベントｅ２ａを除去する。アプリケーションセッションＳ２のイベントキューは空でないため、同期部は、タスクキュー内に、アプリケーションセッションＳ２のための新たなタスクをスケジュールする。具体的には、同期部は、タスクキューに、アプリケーションセッションＳ２のイベントキューから次のイベントｅ２ｂのためのタスクをスケジュールする。さらに、スレッドｔ２はアイドルになっているため、（図９に関して上述したように）処理をタスクキュー内で待機していたアプリケーションセッションＳ３のためのタスクの実行を開始し、イベントｅ３ａを処理するであろう。
【００６５】
図１２では、スレッドｔ１がイベントｅ１ａの処理を完了したものとする。従って、スレッドｔ１は、アプリケーションセッションＳ１のイベントキューからイベントｅ１ａを除去する。アプリケーションセッションＳ１のイベントキューは空でないため、同期部は、タスクキューに、アプリケーションセッションＳ１からのイベントｅ１ｂのための新たなタスクをスケジュールする。スレッドｔ１はアイドルであるため、図１１においてタスクキューで実行を待っていたアプリケーションセッションＳ４のためのタスクの実行を開始するであろう。従って、スレッドｔ１はイベントｅ４ａを処理する。直後に、スレッドｔ２がアプリケーションセッションＳ３からのイベントｅ３ａの処理を完了したものとする。スレッドｔ２はイベントｅ３ａをアプリケーションセッションＳ３のイベントキューから除去する。アプリケーションセッションＳ３のイベントキューは空であるため、同期部はアプリケーションセッションＳ３のために新たなタスクを提供しない。スレッドｔ２はアイドルであるため、スレッドｔ２はアプリケーションセッションＳ２のためのタスクの実行を開始し、それによってアプリケーションセッションＳ２からのイベントｅ２ｂを処理する。
【００６６】
図９〜図１２において説明した手順は継続し、それによって同期部は、いかなる瞬間においても、タスクキュー内のタスクとして、イベントキューあたりイベントが１つだけスケジュールされることを保証する。
【００６７】
従って、上述した本発明は、各アプリケーションセッションについて同時に１つのイベントだけが処理されることを保証することにより、イベント同期の実現を可能にしている。
【００６８】
上述した方法は、ＪＥＥプラットフォーム上における電気通信サービスの記述を非常に簡潔にする。この方法は、リソースの非効率を招くことなく、かつ全てのリソースを管理することを可能としながら、イベント同期に関する問題を解決するという利点を有する。
【００６９】
上述の実施形態では、自身のスレッドプール１９を用いるリソースアダプタ１１について説明したが、リソースアダプタ１１はプラットフォームのスレッドプールも用いてよい。これにより、これらのシステムリソースも管理することが可能になる。
【００７０】
さらに、フレームワークはいかなる技術にも依存しないため、例えばＥＪＢ、サーブレット、および他のリソースアダプタのような、さまざまな技術と組み合わせて用いることができる。
【００７１】
上述した方法は、ＪＥＥコネクタアーキテクチャ(JCA)を用いるリソースアダプタ１１として好適に実施されることに留意されたい。ＪＣＡはレガシーシステムと通信するために提供されているが、ＪＥＥプラットフォームの全体において本発明のイベント同期を実現するために好適である。
【００７２】
本発明はいかなる方法においても、スレッドプールに関する制御ソフトウェアを変更しないという利点を有する。従って、スレッドプールは依然として、通常通り、タスクキューからのタスクをできる限り早く実行するように努めるであろう。しかし、イベントキューとスレッドプールとの間に設けられた、本発明のセッションリソースアダプタ内の同期部は、イベントキューあたり最大でも１つのタスクが存在するように管理する。従前のシステムにおいてはそのような仕組みは存在せず、各イベントはタスクと同等であった。
【００７３】
カウント値がゼロの場合にカウンタが空であるものとして説明したが、カウンタが空であることを示すための基準として任意の値を選択可能であることは理解されよう。
【００７４】
また、フローチャートは特定の順序で実行される所定のステップを示したが、これらステップのいくつかは、特許請求の範囲に規定された本発明の範囲内で別の順序で実行されてもよいことに留意されたい。
【００７５】
上述の実施形態は例示であり、本発明を限定しないこと、また本技術分野に属する当業者は、特許請求の範囲の範囲内で多数の代替実施形態を想起することが可能であることに留意されたい。「有する」という単語は、請求項に記述されたもの以外の構成要素や手順以外の存在を排除せず、「１つの」または「ある」という単語は、複数を排除せず、また、請求項における複数の手段の機能は、１つのプロセッサや別の手段によって実現されてもよい。請求項における参照数字等の記載は、その範囲を限定するものと解すべきではない。
【図１】
2013500526.tif 000003
【図２】
2013500526.tif 000004
【図３】
2013500526.tif 000005
【図４】
2013500526.tif 000006
【図５】
2013500526.tif 000007
【図６】
2013500526.tif 000008
【図７】
2013500526.tif 000009
【図８】
2013500526.tif 000010
【図９】
2013500526.tif 000011
【図１０】
2013500526.tif 000012
【図１１】
2013500526.tif 000013
【図１２】
2013500526.tif 000014
【手続補正書】
【提出日】平成23年5月23日(2011.5.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
電気通信処理プラットフォーム内で複数のアプリケーションセッションに関連付けられた複数のイベントの処理を同期させるための方法であって、前記電気通信処理プラットフォームは複数のタスクを並列に処理するための複数の処理スレッドを有し、前記複数のタスクはタスクキューに格納され、前記方法が、
特定のアプリケーションセッションに関連付けられたイベントキューにイベントを格納するステップと、
挿入されたイベントが前記イベントキュー内の最初のイベントであることを判別した後に、前記イベントキュー内の１つのイベントだけにタスクを割り当てるステップと、
前記タスクを前記タスクキューに格納することにより前記タスクをスケジュールするステップと、を有することを特徴とする方法。
【請求項２】
特定のアプリケーションセッションに関連付けられた前記イベントキューから処理済みのイベントを除去するステップと、
前記イベントキューが空かどうかを判別し、空で無ければ、前記イベントキュー内の別の１つのイベントにタスクを割り当てるステップと、をさらに有することを特徴とする請求項１記載の方法。
【請求項３】
タスクを割り当てられる前記イベントが、前記イベントキュー内の最初のイベントであることを特徴とする請求項２記載の方法。
【請求項４】
格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項１記載の方法。
【請求項５】
格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項２記載の方法。
【請求項６】
前記不可分の動作を実行するためにロックを用いるステップをさらに有することを特徴とする請求項４または請求項５に記載の方法。
【請求項７】
前記不可分の動作を実行するためにアトミックカウンタを用いるステップをさらに有することを特徴とする請求項４または請求項５に記載の方法。
【請求項８】
前記アトミックカウンタは、格納するステップまたは除去するステップのそれぞれの間に増加または減少されるカウント値を有し、前記カウント値が、前記キューが空か否か、または、あるイベントが前記イベントキュー内の最初のイベントかどうかを示すことを特徴とする請求項７記載の方法。
【請求項９】
前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
タスクキューに格納されている複数のタスクを並列に処理するための複数の処理スレッドを有する電気通信処理プラットフォームで用いるためのリソースアダプタであって、
それぞれがあるアプリケーションセッションに関連付けられ、対応するアプリケーションセッションに関連付けられたイベントを格納するように構成された１つ以上のイベントキューと、
あるイベントキュー内の複数のイベントの処理を同期させるための同期手段であって、イベントキュー内の１つのイベントだけにタスクを割り当て、前記タスクを前記タスクキューに格納することにより前記タスクをスケジュールする同期手段と、を有することを特徴とするリソースアダプタ。
【請求項１１】
前記同期手段は、特定のアプリケーションセッションに関連付けられた前記イベントキューから前記イベントを除去するとともに、前記イベントキューが空か否かを判別し、前記イベントキューが空でなければ、前記イベントキュー内の別の１つのイベントにタスクを割り当てるように構成されることを特徴とする請求項１１または請求項１２記載のリソースアダプタ。
【請求項１２】
タスクを割り当てられるイベントが、前記イベントキュー内の最初のイベントであることを特徴とする請求項１１記載のリソースアダプタ。
【請求項１３】
アトミックカウンタをさらに有し、前記アトミックカウンタは、対応するイベントキューが空か否かを示すカウント値を有することを特徴とする請求項１０乃至請求項１２のいずれか１項に記載のリソースアダプタ。
【請求項１４】
前記同期手段が、前記イベントキューにイベントを格納する際に前記アトミックカウンタの前記カウント値を増加させるように構成されることを特徴とする請求項１３記載のリソースアダプタ。
【請求項１５】
前記同期手段が、前記イベントキューからイベントを除去する際に前記アトミックカウンタの前記カウント値を減少させるように構成されることを特徴とする請求項１３または請求項１４記載のリソースアダプタ。
【請求項１６】
イベントキューがファーストインファーストアウトキューを有することを特徴とする請求項１０乃至請求項１５のいずれか１項に記載のリソースアダプタ。
【請求項１７】
前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１０乃至請求項１６のいずれか１項に記載のリソースアダプタ。
【請求項１８】
請求項１０乃至請求項１７のいずれか１項に記載のリソースアダプタを有するか、請求項１乃至請求項９のいずれか１項に記載の方法を実行するように構成されたJEEクラスタ。
【手続補正書】
【提出日】平成24年6月28日(2012.6.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１１
【補正方法】変更
【補正の内容】
【請求項１１】
前記同期手段は、特定のアプリケーションセッションに関連付けられた前記イベントキューから前記イベントを除去するとともに、前記イベントキューが空か否かを判別し、前記イベントキューが空でなければ、前記イベントキュー内の別の１つのイベントにタスクを割り当てるように構成されることを特徴とする請求項１０記載のリソースアダプタ。
【国際調査報告】
2013500526.tif 000015
2013500526.tif 000016