JP2015143998A - 電気通信ネットワークにおけるイベントを処理するための装置および方法 - Google Patents

Abstract

【課題】処理プラットフォーム内のイベントの処理を、リソース効率の良い方法で同期させるための方法および装置を提供する。【解決手段】アプリケーションセッションを取り扱うためのリソースアダプタ１１は、１つ以上のアプリケーションセッションＳ１からＳｎを有している。イベントキュー１７は、アプリケーションセッションＳ１からＳｎの特定の１つのために実行されるべき一群のイベントを格納している。スレッドプール１９は、プロセッサ３が複数のタスクを並列に実行することを可能にするための１つ以上の処理スレッドｔ１からｔＮを有している。スレッドプール１９はまた、スレッドｔ１からｔＮによって実行すべき複数のタスクを格納するタスクキュー２１を有している。同期部２３は、イベントキュー１７内で待たされているイベントの１つだけが、自身にスケジュールされたタスクをタスクキュー２１に有するように構成する。【選択図】図３

Description

本発明は電気通信ネットワーク内のイベントを処理するための装置および方法に関し、特に、電気通信処理プラットフォーム、例えば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)を用いるリソースアダプタ１１として好適に実施されることに留意されたい。ＪＣＡはレガシーシステムと通信するために提供されているが、ＪＥＥプラットフォームの全体において本発明のイベント同期を実現するために好適である。

本発明はいかなる方法においても、スレッドプールに関する制御ソフトウェアを変更しないという利点を有する。従って、スレッドプールは依然として、通常通り、タスクキューからのタスクをできる限り早く実行するように努めるであろう。しかし、イベントキューとスレッドプールとの間に設けられた、本発明のセッションリソースアダプタ内の同期部は、イベントキューあたり最大でも１つのタスクが存在するように管理する。従前のシステムにおいてはそのような仕組みは存在せず、各イベントはタスクと同等であった。

カウント値がゼロの場合にカウンタが空であるものとして説明したが、カウンタが空であることを示すための基準として任意の値を選択可能であることは理解されよう。

また、フローチャートは特定の順序で実行される所定のステップを示したが、これらステップのいくつかは、特許請求の範囲に規定された本発明の範囲内で別の順序で実行されてもよいことに留意されたい。

上述の実施形態は例示であり、本発明を限定しないこと、また本技術分野に属する当業者は、特許請求の範囲の範囲内で多数の代替実施形態を想起することが可能であることに留意されたい。「有する」という単語は、請求項に記述されたもの以外の構成要素や手順以外の存在を排除せず、「１つの」または「ある」という単語は、複数を排除せず、また、請求項における複数の手段の機能は、１つのプロセッサや別の手段によって実現されてもよい。請求項における参照数字等の記載は、その範囲を限定するものと解すべきではない。

Claims (20)

1. 電気通信処理プラットフォーム内で複数のアプリケーションセッションに関連付けられた複数のイベントの処理を同期させるための方法であって、前記電気通信処理プラットフォームは複数のタスクを並列に処理するための複数の処理スレッドを有し、前記複数のタスクはタスクキューに格納され、前記方法が、
   特定のアプリケーションセッションに関連付けられたイベントキューに１つ以上のイベントを格納するステップと、
   特定のアプリケーションセッションの前記イベントキュー内の１つのイベントだけに、前記タスクキュー内のタスクを割り当てるステップと、を有することを特徴とする方法。
2. イベントを前記イベントキューに格納する前記ステップが、
   前記イベントが前記イベントキュー内の最初のイベントかどうかを判別し、最初のイベントであれば、該イベントに前記タスクキュー内のタスクを割り当てるステップを有することを特徴とする請求項１記載の方法。
3. 前記イベントキューから処理済みのイベントを除去するステップをさらに有し、該除去するステップが、
   前記イベントキューが空かどうかを判別し、空で無ければ、前記イベントキュー内の別のイベントに前記タスクキュー内のタスクを割り当てるステップを有することを特徴とする請求項１または請求項２記載の方法。
4. タスクを割り当てる前記ステップが、前記イベントキュー内の次のイベントにタスクを割り当てるステップを有することを特徴とする請求項３記載の方法。
5. 格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項２記載の方法。
6. 格納する前記ステップおよび判別する前記ステップは、不可分の動作として実行されることを特徴とする請求項３または請求項４記載の方法。
7. 前記不可分の動作を実行するためにロックを用いるステップをさらに有することを特徴とする請求項５または請求項６に記載の方法。
8. 前記不可分の動作を実行するためにアトミックカウンタを用いるステップをさらに有することを特徴とする請求項５または請求項６に記載の方法。
9. 前記アトミックカウンタは、格納するステップまたは除去するステップのそれぞれの間に増加または減少されるカウント値を有し、前記カウント値が、前記キューが空か否か、または、あるイベントが前記イベントキュー内の最初のイベントかどうかを示すことを特徴とする請求項８記載の方法。
10. 前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１乃至請求項９のいずれか１項に記載の方法。
11. タスクキューに格納されている複数のタスクを並列に処理するための複数の処理スレッドを有する電気通信処理プラットフォームで用いるためのリソースアダプタであって、
    それぞれがあるアプリケーションセッションに関連付けられ、対応するアプリケーションセッションに関連付けられた１つ以上のイベントを格納するように構成された１つ以上のイベントキューと、
    あるイベントキュー内の複数のイベントの処理を同期させるための同期手段であって、あるイベントキュー内の１つのイベントにのみ前記タスクキュー内のタスクを割り当てる同期手段と、を有することを特徴とするリソースアダプタ。
12. 前記同期手段は、イベントをイベントキューに格納する際に、イベントがイベントキューに挿入されるべき最初のイベントか否かを判別し、イベントがイベントキューに挿入されるべき最初のイベントであれば、該イベントに対して前記タスクキュー内のタスクを割り当てるように構成されることを特徴とする請求項１１記載のリソースアダプタ。
13. 前記同期手段は、イベントを前記イベントキューから除去する際に、前記イベントキューが空か否かを判別し、前記イベントキューが空でなければ、前記イベントキュー内の別のイベントに前記タスクキュー内のタスクを割り当てるように構成されることを特徴とする請求項１１または請求項１２記載のリソースアダプタ。
14. 前記同期手段が、前記イベントキュー内の前記次のイベントにタスクを割り当てるように構成されることを特徴とする請求項１３記載のリソースアダプタ。
15. アトミックカウンタをさらに有し、前記アトミックカウンタは、対応するイベントキューが空か否かを示すカウント値を有することを特徴とする請求項１１乃至請求項１４のいずれか１項に記載のリソースアダプタ。
16. 前記同期手段が、前記イベントキューにイベントを格納する際に前記アトミックカウンタの前記カウント値を増加させるように構成されることを特徴とする請求項１５記載のリソースアダプタ。
17. 前記同期手段が、前記イベントキューからイベントを除去する際に前記アトミックカウンタの前記カウント値を減少させるように構成されることを特徴とする請求項１５または請求項１６記載のリソースアダプタ。
18. イベントキューがファーストインファーストアウトキューを有することを特徴とする請求項１１乃至請求項１７のいずれか１項に記載のリソースアダプタ。
19. 前記電気通信処理プラットフォームが、Javaエンタプライズエディション(JEE)処理プラットフォームであることを特徴とする請求項１１乃至請求項１８のいずれか１項に記載のリソースアダプタ。
20. 請求項１１乃至請求項１９のいずれか１項に記載のリソースアダプタを有するか、請求項１乃至請求項１０のいずれか１項に記載の方法を実行するように構成されたJEEクラスタ。

Images