(57)【要約】【課題】サーバー待ち行列システムおよび方法を提供する。【解決手段】１つのサブシステムが非同期的に１つまたは複数の順序付けされた動作を実行しようとする場合、待ち行列サーバーが信頼性の高いメッセージ転送のために使用される。メッセージは、１つまたは複数のメッセージを有するグループとして待ち行列に送り出される。特定のグループ内のメッセージは、所定の順序で処理される。メッセージグループは、特定の相関関係内のすべてのグループが所定の順序で処理されるように、相関関係にあるようマークされる。メッセージは、そのメッセージの処理が完了するまで、ＳＱＬデータベーステーブルに格納される。メッセージシステムの受信側は、複数のマシンにまたがって、かつ／または任意の所与のマシンの利用可能なリソースにまたがってスケーリングされる。システムは、送信側と、受信側の両方での災害シナリオを処理することができる。【選択図】図２
2006190265.tif 000002
【特許請求の範囲】
【請求項１】
メッセージを待ち行列に入れるために、コンピュータで実施される方法として、
待ち行列システムにおいて、送信側サブシステムから送り出されるメッセージグループを受け取るステップであって、前記メッセージグループの各々は少なくとも１つのメッセージを含むステップと、
前記待ち行列システムを使って所定の順序で前記受け取られたメッセージグループを格納するステップと、
前記待ち行列システムにおいて、各メッセージグループに対する相関識別子を受け取るステップであって、該相関識別子はメッセージグループを関連付けるために使用されるステップと、
前記待ち行列システムを使って前記受け取られた相関識別子を格納するステップと、
前記所定の順序に従って前記格納されたメッセージグループおよび前記相関識別子を送り出すステップと、
を具備したことを特徴とするコンピュータで実施される方法。
【請求項２】
前記受け取られたメッセージグループはＳＱＬテーブルに格納される、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項３】
前記格納されたメッセージグループは複数のマシンに送り出される、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項４】
受け取られた各メッセージグループに優先度値が関連付けられる、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項５】
前記メッセージグループは、前記関連付けられた優先度値に従って送り出される、ことを特徴とする請求項４に記載のコンピュータで実施される方法。
【請求項６】
前記相関識別子としてＧＵＩＤが使用される、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項７】
前記ＧＵＩＤはクライアントにより供給される、ことを特徴とする請求項６に記載のコンピュータで実施される方法。
【請求項８】
前記所定の順序は、前記メッセージグループが受け取られる順序である、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項９】
関連付けられたグループの最後のメッセージグループは、前記関連付けられたグループの任意の格納されたメッセージグループを送り出す前に受け取られる、ことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項１０】
前記相関識別子によって関連付けられている受け取られたメッセージグループを送り出すために、ロックするステップと、
前記相関識別子によって関連付けられている最後のメッセージグループが受け取られると、前記受け取られたメッセージグループを送り出すために、ロック解除するステップと、
をさらに含むことを特徴とする請求項１に記載のコンピュータで実施される方法。
【請求項１１】
メッセージを待ち行列に入れるシステムであって、
待ち行列システムにおいて、送信側サブシステムから送り出されるメッセージグループを送り出す手段であって、前記メッセージグループの各々は少なくとも１つのメッセージを含む手段と、
前記待ち行列システムを使って所定の順序で前記受け取られたメッセージグループを格納する手段と、
前記待ち行列システムにおいて、各メッセージグループに対する相関識別子を受け取る手段であって、該相関識別子はメッセージグループを関連付けるために使用される手段と、
前記待ち行列システムを使って前記受け取られた相関識別子を格納する手段と、
前記所定の順序に従って前記格納されたメッセージグループおよび前記相関識別子を送り出す手段と、
を具備したことを特徴とするシステム。
【請求項１２】
前記受け取られたメッセージグループはＳＱＬテーブルに格納される、ことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記格納されたメッセージグループは複数のマシンに送り出される、ことを特徴とする請求項１１に記載のシステム。
【請求項１４】
受け取られた各メッセージグループに優先度値が関連付けられる、ことを特徴とする請求項１１に記載のシステム。
【請求項１５】
前記メッセージグループは、前記関連付けられた優先度値に従って送り出される、ことを特徴とする請求項１４に記載のシステム。
【請求項１６】
メッセージの待ち行列システムを管理するためのコンピュータ実行可能命令を含んだコンピュータ可読媒体であって、
待ち行列システムにおいて、送信側サブシステムから送り出されるメッセージグループを受け取る命令であって、前記メッセージグループの各々は少なくとも１つのメッセージを含む命令と、
前記待ち行列システムを使って所定の順序で前記受け取られたメッセージグループを格納する命令と、
前記待ち行列システムにおいて、各メッセージグループに対する相関識別子を受け取る命令であって、該相関識別子はメッセージグループを関連付けるために使用される命令と、
前記待ち行列システムを使って前記受け取られた相関識別子を格納する命令と、
前記所定の順序に従って前記格納されたメッセージグループおよび前記相関識別子を送り出す命令と、
を有することを特徴とするコンピュータ可読媒体。
【請求項１７】
前記相関識別子としてＧＵＩＤが使用される、ことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記所定の順序は、前記メッセージグループが受け取られる順序である、ことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１９】
関連付けられたグループの最後のメッセージグループは、前記関連付けられたグループの任意の格納されたメッセージグループを送り出す前に受け取られる、ことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項２０】
前記相関識別子によって関連付けられている受け取られたメッセージグループを送り出すために、ロックする命令と、
前記相関識別子によって関連付けられている最後のメッセージグループが受け取られると、前記受け取られたメッセージグループを送り出すために、ロック解除する命令と、
をさらに含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー待ち行列(server queuing)システムおよび方法に関するものである。
【背景技術】
【０００２】
待ち行列システム(queuing system)は、数人の異なるユーザ（および／またはプロセス）が、受信側サブシステム(receiving subsystem)が後で使用するために待ち行列に格納されるデータおよび／または処理要求(processing request)を送り出す(send)ことを可能にする。例えば、プロジェクトサーバーサブシステムは、待ち行列システムに１つまたは複数のメッセージを送り出すことができる。待ち行列システムは、受信側サブシステムが格納された情報を取り出し、処理することができるようになるまで、その情報を格納する。しかしながら、サブシステムと待ち行列システムの間、およびシステムの間での機械故障および通信割り込みが処理に際してエラーを引き起こし、かつ／または格納された情報を処理するのを不可能にすることがある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
よって本発明の目的は、信頼性の高いメッセージ転送(message transport)のためのサーバー待ち行列(server queuing)システムおよび方法を提供することにある。
【課題を解決するための手段】
【０００４】
待ち行列サーバーは、例えば、１つのサブシステムが非同期的(asynchronously)に１つまたは複数の順序付けされた動作(ordered operation)を実行しようとする場合に使用される。メッセージは、１つまたは複数のメッセージを含むグループとして待ち行列に送り出される。特定のグループ内のメッセージは、所定の順序(predetermined order)で処理される。メッセージグループ(groups of messages)は、特定の相関関係(particular correlation)内のすべてのグループが所定の順序で処理され得るように、相関関係にあるようマークされる。メッセージは、そのメッセージの処理が完了するまで、ＳＱＬデータベーステーブルに格納される。メッセージシステムの受信側(receiving side)は、複数のマシンにまたがって、かつ／または任意の所与のマシンにおける利用可能なリソース(available resources of any given machine)にまたがってスケーリングされる。本システムは、送信側(sending side)と受信側(receiving side)の両方での「災害(disaster)」シナリオを処理することができる。具体的には、送信側では、送信側マシン(sending machine)があるグループを送り出している最中にクラッシュする場合であり、受信側では、電源障害が受信側マシンの少なくとも１つでリブートを引き起こす場合である。
【０００５】
本発明の一態様において、待ち行列システムは、送信側サブシステム(sender subsystem)から送り出されるメッセージグループ(message group)を受け取り、各メッセージグループは、少なくとも１つのメッセージを含む。受け取られたメッセージグループ(received message group)は、待ち行列システムを使って所定の順序で格納される。この待ち行列システムは、各メッセージグループに対する相関識別子(correlation identifier)を受け取る。受け取られた相関識別子は、待ち行列システムを使って格納される。格納されたメッセージグループおよび相関識別子は、所定の順序に従って送り出される。
【発明を実施するための最良の形態】
【０００６】
本発明は、信頼性の高いメッセージ転送のためのサーバー待ち行列方法およびシステムを対象とする。待ち行列サーバーは、例えば、１つのサブシステムが非同期的に１つまたは複数の順序付けされた動作を実行しようとする場合に使用される。メッセージは、１つまたは複数のメッセージを含むグループとして待ち行列に送り出される。特定のグループ内のメッセージは、所定の順序で処理される。メッセージグループは、特定の相関関係内のすべてのグループが所定の順序で処理されるように、相関関係にあるとしてマークされる。メッセージは、そのメッセージの処理が完了するまでＳＱＬデータベーステーブルに格納される。メッセージシステムの受信側は、複数のマシンにまたがって、かつ／または任意の所与のマシンの利用可能なリソースにまたがってスケーリングされる。システムは、送信側（すなわち、送信側マシンが１つのグループを送り出している最中にクラッシュする）と受信側（すなわち、電源障害が受信側マシンの少なくとも１つでリブートを引き起こす）両方での「災害」シナリオを処理することができる。
【０００７】
例示的動作環境
図１において、本発明を実施するための例示的システムは、コンピューティングデバイス１００などのコンピューティングデバイスを含む。コンピューティングデバイス１００は、クライアント、サーバー、モバイル機器、またはネットワークベースの協働システムにおいてデータと対話する他の任意のコンピューティングデバイスとして構成される。非常に基本的な構成において、コンピューティングデバイス１００は、通常、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を含む。コンピューティングデバイスの厳密な構成および種類に応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、または両者の何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のアプリケーション１０６を含み、プログラムデータ１０７を含む。以下で詳細に説明するサーバー待ち行列システム１０８は、通常、アプリケーション１０６内で実施される。
【０００８】
コンピューティングデバイス１００は、追加の機構または機能を備えることができる。例えば、コンピューティングデバイス１００は、例えば、磁気ディスク、光ディスク、またはテープなど、追加のデータ記憶装置（取り外し可能および／または取り外し不能）を含むこともできる。そのような追加の記憶は、図１に、取り外し可能ストレージ１０９および取り外し不能ストレージ１１０で示されている。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実施された揮発性および不揮発性、取り外し可能および取り外し不能媒体が含まれる。システムメモリ１０４、取り外し可能ストレージ１０９および取り外し不能ストレージ１１０は、すべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなどのメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）などの光記憶、磁気カセット、磁気テープ、磁気ディスク記憶などの磁気記憶装置、または所望の情報を格納するのに使用でき、コンピューティングデバイス１００によってアクセスされる他の任意の媒体が含まれる。したがって、そのようなコンピュータ記憶媒体は、装置１００の一部とすることができる。また、コンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス１１２も備えることができる。また、ディスプレイ、スピーカ、プリンタなどの出力デバイス１１４も含むことができる。
【０００９】
また、コンピューティングデバイス１００は、この装置が、ネットワークを介するなどして、他のコンピューティングデバイス１１８と通信を行えるようにする通信接続１１６も含む。ネットワークには、ローカルエリアネットワークおよび広域ネットワーク、ならびに、イントラネットおよびエクストラネットを含む他の大規模ネットワークが含まれる。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波や他の搬送機構などの変調データ信号においてコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータによって実施することができ、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、その特性の１つまたは複数が、その信号において情報を符号化するように設定または変更されている信号を意味する。例をあげると、それだけに限らないが、通信媒体には、有線ネットワークや直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体が含まれる。本明細書で使用されるコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００１０】
待ち行列システムサーバー
図２は、本発明の態様による信頼性の高いメッセージ転送のための待ち行列システムのブロック図を示す。例示したシステムは、待ち行列サーバー２００、送信側サブシステムクライアント２５０、２５２、２５４、および受信側サブシステムクライアント２６０、２６２、２６４を含む。（本発明による他のシステムは、１つまたは複数の送信側サブシステムクライアントおよび／または１つまたは複数の受信側サブシステムクライアントを含むことができる。）サーバー２００は、１つまたは複数の格納されたメッセージを含み、それらのメッセージはメッセージグループ２１０として編成される。メッセージグループ２１０は（ＳＱＬテーブルなどの）メッセージ待ち行列２３０に格納され、各メッセージグループは、（やはりＳＱＬテーブルなどとすることのできる）グループ待ち行列２４０中のエントリに関連付けられる。
【００１１】
メッセージの送り出し
送信側サブシステム(sending subsystem)クライアント２５０、２５２、２５４は、ＡＰＩ（アプリケーションプログラミングインターフェース）を使って以下で定義されるセンダー(sender)オブジェクトを呼び出すことができる。例えば、センダー(sender)オブジェクトは、以下のように定義される。
【００１２】
【表１】
2006190265.tif 000003
【００１３】
まず、送信側サブシステムクライアントは、センダー(sender)オブジェクトを作成する。コンストラクタのパラメータは、通常、（以下で説明する）ＩＱｕｅｕｅＡｃｃｅｓｓインターフェースを提供するクラスのＳｙｓｔｅｍ．Ｔｙｐｅである。代替のコンストラクタ(alternate constructor)はｓｅｒｖｅｒＩｄをとることができ、これはメッセージを送り出すサーバーインスタンス(server instance)を識別する任意のストリングとすることができる。これは、プロジェクトサーバー(project server)のただ１つのインスタンスが所与のマシン上で走っている場合、そのマシン名とすることもできる。ＳｅｒｖｅｒＩＤ値は、通常は、送信側サブシステムクライアントによっては使用されない。
【００１４】
センダー(sender)オブジェクトが構築されると、クライアントは、ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）を呼び出す。ｍｅｓｓａｇｅＴｙｐｅパラメータは、共通の待ち行列を共用する異なるタイプのメッセージを区別するのに使用されるクライアント定義の値である。例えば、メッセージタイプは、Ｓａｖｅタイプ、Ｐｕｂｌｉｓｈタイプ、およびＲｅｐｏｒｔタイプのメッセージなどとすることができる。クライアントは、これらのタイプのメッセージにある任意の定数を定義することができ、その値を使って受信側で適正なメッセージ処理コードに分岐することができる。
【００１５】
優先度(priority)パラメータは、メッセージグループの優先度値(priority value)を指定するのに使用される。例えば、「１」の値を最高の優先度とすることができ、それより大きい数をより低い優先度とすることができる。
【００１６】
ｃｏｒｒｅｌａｔｉｏｎＩｄパラメータは、通常、別々のメッセージグループを相関させるのに使用されるクライアントによって供給されるＧＵＩＤである。例えば、特定のユーザからの（タイムシート入力プログラムからのメッセージなどの）メッセージは、（それらが受け取られる順序など）所定の順序に従って処理される。各タイムシート処理依頼は、１つのメッセージグループとして送り出される。ｃｏｒｒｅｌａｔｉｏｎＩｄは、タイムシートメッセージを処理する複数のスレッドがある場合でさえもこれらのグループのそれぞれが（発生順など）所定の順序に従って処理されるようにするために、待ち行列サーバー２００によって使用される。タイムシートの例では、ｃｏｒｒｅｌａｔｉｏｎＩｄ値は、ＲｅｓｏｕｒｃｅＩＤとすることができる。
【００１７】
ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）の戻り値(turned value)は、そのグループのＵＩＤである。このＵＩＤは、メッセージグループの状況に関連する問い合わせに使用される。
【００１８】
ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐへの呼び出しの後、送信側サブシステムクライアントは、Ｓｅｎｄ（）を使って任意の数のメッセージを送り出すことができる。ｍｅｓｓａｇｅＢｏｄｙパラメータは、通常、送り出されるメッセージを表す任意のオブジェクトである。ｍｅｓｓａｇｅＢｏｄｙパラメータは、メッセージデータのみならず、受信側でそのデータを処理するメソッドさえも含むことができる。しかしながら、この任意のオブジェクトは、（直列化されることができるなど）所定の順序に従って編成することができる必要がある。待ち行列サーバー２００は、通常、待ち行列データベーステーブルに格納するためのオブジェクトの直列化および非直列化を処理する。待ち行列データベーステーブルは、メッセージがすでにバイナリ形式（バイト配列など）である場合、システムがそのデータをデータベースに「現状のまま(as is)」書き込むことができるように最適化され得る。
【００１９】
すべてのメッセージが送り出されると、クライアントは、ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐ（）を呼び出すことができる。ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐ（）は、グループを閉じ、そのグループに、（以下で説明する）受信側コードによる処理が可能であるとマークする。
【００２０】
何らかの理由で未完了のグループを廃棄することが求められる場合には、ＣａｎｃｅｌＭｅｓｓａｇｅＧｒｏｕｐ（）が呼び出される。ＣａｎｃｅｌＭｅｓｓａｇｅＧｒｏｕｐ（）は、待ち行列からＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）への呼び出し後に送り出されたすべてのメッセージを除去するのに使用される。ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐへの呼び出し後は、そのメッセージグループに追加のメッセージが加えられ得ないが、センダー(sender)オブジェクト自体は、単にＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐを再度呼び出すだけで再利用される。Ｂｅｇｉｎ／ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐ対の間に送り出されるすべてのメッセージによって定義されるメッセージグループは、通常、ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐが正常に呼び出されるまで処理されない。メッセージを送り出している間にシステムクラッシュが発生した場合、未完了のグループが待ち行列に残されることになる。この未完了のグループは、以下で説明するクリーンアッププロセスによって正常に除去される。
【００２１】
メッセージの受け取り(receiving messages)
受信側システムは、待ち行列からメッセージを取り出し、次いで適当な処理コードを呼び出すスレッドとして働くように設計される。このため、メッセージを処理するコードの開発者は、通常、以下のＡＰＩによって定義されるレシーバ(receiver)オブジェクトのいずれも使用する必要はない。このＡＰＩは、プロジェクトサーバーが始動され、または管理者によって手動で活動化されるとき、受信側サービスをセットアップするのに使用される。レシーバ(receiver)オブジェクトは以下のように定義される。
【００２２】
【表２】
2006190265.tif 000004
【００２３】
レシーバ(receiver)オブジェクトは、ｑｕｅｕｅＡｃｃｅｓｓＴｙｐｅ、ｐｒｏｃｅｓｓＭｅｓｓａｇｅＴｙｐｅ、およびｓｅｒｖｅｒＩＤというパラメータを使って構築される。ｑｕｅｕｅＡｃｃｅｓｓＴｙｐｅパラメータは、ＩＱｕｅｕｅＡｃｃｅｓｓインターフェースをサポートするオブジェクトのＳｙｓｔｅｍ．Ｔｙｐｅであり、ｐｒｏｃｅｓｓＭｅｓｓａｇｅＴｙｐｅパラメータは、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅインターフェースをサポートするオブジェクトのＳｙｓｔｅｍ．Ｔｙｐｅであり、ｓｅｒｖｅｒＩＤは、通常、そのレシーバ(receiver)が属するサーバーインスタンスを識別するのに使用される任意のストリングである。１つのマシンにつきただ１つのインスタンスが使用される場合、これは、マシン名とすることができる。（これらのコンストラクタパラメータの操作については以下でより詳細に説明する。）
【００２４】
レシーバ(receiver)オブジェクトが構築されると、それはＳｔａｒｔ（）を呼び出すことによって開始される。通常、レシーバは、おそらく、スレッドとして実行されるはずであり、したがって、その「非同期」パラメータは「真」であるはずであるが、それは、「偽」として渡すことによって同期しても実行することができる。代替の実施形態は、システムが常に非同期的に実行されるように実施することができる。
【００２５】
同期的に開始されたにせよ、非同期的に開始されたにせよ、受信側サービスは、Ｓｔｏｐ（）を呼び出すことによってシャットダウンされる。Ｓｔｏｐの呼び出しは、受信側サービスに、あらゆるアクティブワーカー(active worker)スレッドをシャットダウンし、次いで終了するよう命令する。レシーバ(receiver)スレッドおよびレシーバ(receiver)スレッドに関連付けられているワーカー(worker)スレッドすべてが実際に完了すると、Ｄｏｎｅプロパティが「真」に設定される。
【００２６】
ＳｅｒｖｉｃｅＬｉｍｉｔは、レシーバがいくつのワーカー(worker)スレッドを使用できるか指定するのに使用される読み取り／書き込みプロパティである。ＳｅｒｖｉｃｅＬｉｍｉｔはデフォルトで「１」の値になるように設定される。ＳｅｒｖｉｃｅＬｉｍｉｔは、通常、レシーバ(receiver)スレッドが走っている間に変更される。
【００２７】
ＴｈｒｅａｄＳｌｅｅｐＴｉｍｅは、レシーバ(receiver)スレッドが、待ち行列に新しいメッセージがあるかポーリングするたびにどれほどの時間（例えばミリ秒単位で）休止するか指定する読み取り／書き込みプロパティである。ＴｈｒｅａｄＳｌｅｅｐＴｉｍｅは、デフォルトで、ミリ秒の単位を使用すると１秒である１０００の値になるように設定される。
【００２８】
センダーおよびレシーバは、通常、スレッド化考慮事項のために、（オブジェクト自体のインスタンスではなく）ｑｕｅｕｅＡｃｃｅｓｓおよびｐｒｏｃｅｓｓＭｅｓｓａｇｅＴｙｐｅにＳｙｓｔｅｍ．Ｔｙｐｅ値を取る。センダーおよびレシーバが必要なオブジェクトのインスタンスを取り込んだ場合、センダーおよびレシーバは、これらのオブジェクトが完全にスレッドセーフでなければならないことを必要とし、それは、これらのオブジェクトが参照した他のどんなオブジェクトもまたスレッドセーフでなければならないことを意味するはずである。この問題を回避するためにセンダーおよびレシーバは、（渡されたＳｙｓｔｅｍ．Ｔｙｐｅオブジェクトを使って）作成された各スレッドごとに指定されたオブジェクトのコピーをインスタンス化する。したがって、ＩＱｕｅｕｅＡｃｃｅｓｓまたはＩＰｒｏｃｅｓｓＭｅｓｓａｇｅを提供するオブジェクトだけが、アパートメントスレッドセーフでなければならない（すなわち、それらは、静的クラスメンバへのアクセスを保護しなければならないが、インスタンスメンバへのアクセスを保護する必要はない）はずである。
【００２９】
メッセージの処理
受信側サービスが開始されるとき、それがとるパラメータの１つは、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅインターフェースをサポートするオブジェクトのＳｙｓｔｅｍ．Ｔｙｐｅであり、これは以下のように定義される。
【００３０】
【表３】
2006190265.tif 000005
【００３１】
レシーバ(receiver)オブジェクトのワーカー(worker)スレッドのそれぞれは、クライアントのオブジェクトのインスタンスをインスタンス化する。どんなメッセージが読み取られる前にも、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅ．ＳｔａｒｔＭｅｓｓａｇｅＧｒｏｕｐ（）が呼び出される。これは、クライアントに、メッセージグループを処理する前に必要とされる任意の初期設定またはその他の処理を行う機会を与える。次に、メッセージグループ内の各メッセージごとに、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅ．ＰｒｏｃｅｓｓＭｅｓｓａｇｅＣａｌｌｂａｃｋ（）が呼び出される。
【００３２】
ＰｒｏｃｅｓｓＭｅｓｓａｇｅＣａｌｌｂａｃｋの戻り値は、メッセージが正常に処理されたか否か指定する。「真」の値が戻される場合、そのメッセージは待ち行列からポップされる。「偽」の戻り値は、メッセージが失敗したことを示し、その場合、待ち行列システムは、同じメッセージを用いて再度ＰｒｏｃｅｓｓＭｅｓｓａｇｅＣａｌｌｂａｃｋを呼び出すことができる。
【００３３】
レシーバ(receiver)スレッドが（最後のメッセージを受け取り、または例外により打ち切ることによって）メッセージの読み取りを終了すると、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅ．ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐ（）が呼び出される。これは、クライアントに、求められ得る任意のクリーンアップまたは終了処理を行う機会を与える。
【００３４】
Ｍｅｓｓａｇｅパラメータは、通常、そのメッセージ自体である。このオブジェクトは、以下のプロパティを持つ。
【００３５】
【表４】
2006190265.tif 000006
【００３６】
ＭｅｓｓａｇｅＩｄはメッセージのＩＤを与え、このＩＤはグループ内で一意である。グループ中の第１のメッセージは、通常、メッセージのＩＤを持ち、グループ中の第２のメッセージもまたメッセージのＩＤを持ち、以下同様である。ＭｅｓｓａｇｅＢｏｄｙは、Ｓｅｎｄｅｒ．Ｓｅｎｄ（）メソッドにより最初に送り出されたオブジェクトである。
【００３７】
Ｇｒｏｕｐパラメータは、通常、メッセージが属するグループに関するメタデータを含むオブジェクトである。Ｇｒｏｕｐパラメータは、以下のプロパティを提供する。
【００３８】
【表５】
2006190265.tif 000007
【００３９】
ＧｒｏｕｐＩｄはそのグループの一意の識別子である。各メッセージグループは一意のＧｒｏｕｐＩｄを持つ。ＣｏｒｒｅｌａｔｉｏｎＩｄは、相関関係を持つメッセージグループの一意の識別子である。これは、Ｓｅｎｄｅｒ．ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）が呼び出されるときにＳｅｎｄｅｒ．ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）に渡されるパラメータに対応する。ＭｅｓｓａｇｅＴｙｐｅは、メッセージのタイプを指定するクライアント定義の列挙型タイプである。ＭｅｓｓａｇｅＴｙｐｅは、Ｓｅｎｄｅｒ．ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）に渡されるパラメータに対応する。Ｐｒｉｏｒｉｔｙはグループ優先度である。Ｐｒｉｏｒｉｔｙは、Ｓｅｎｄｅｒ．ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）に渡されるパラメータに対応する。ＬａｓｔＭｅｓｓａｇｅＩｄは、グループ中の最後のメッセージのＭｅｓｓａｇｅＩｄを与える。したがって、ｍｓｇ．ＭｅｓｓａｇｅＩｄは、グループ中の最後のメッセージに当たったときのｍｅｓｓａｇｅＧｒｏｕｐ．ＬａｓｔＭｅｓｓａｇｅＩｄと同じになるはずである。
【００４０】
ＭｅｓｓａｇｅＣｏｎｔｅｘｔパラメータは、メッセージの現在の処理状態に関する追加情報を含むことができる。ＭｅｓｓａｇｅＣｏｎｔｅｘｔパラメータは、以下のように定義される。
【００４１】
【表６】
2006190265.tif 000008
【００４２】
ＲｅｔｒｙＣｏｕｎｔは、特定のメッセージを用いてＰｒｏｃｅｓｓＭｅｓｓａｇｅＣａｌｌｂａｃｋが呼び出された回数である。第１の呼び出し時、その値は、通常、「１」になる。ＧｒｏｕｐＲｅｔｒｙＣｏｕｎｔは、特定のグループが処理を試みた回数である。何らかの理由でレシーバのワーカー(worker)スレッドがグループの処理を打ち切る場合、ＧｒｏｕｐＲｅｔｒｙＣｏｕｎｔは、通常は、最初の未処理のメッセージから開始して、そのグループを再試行する。ＳｌｅｅｐＢｅｆｏｒｅＲｅｔｒｙは、メッセージの処理に失敗した場合、ワーカー(worker)スレッドに、メッセージを再試行する前にどれほどの間休止すべきか知らせるクライアント設定パラメータである。
【００４３】
低レベル待ち行列アクセス(low level queue access)
待ち行列サーバー２００は、通常、待ち行列ストレージ(queue storage)「アグノスティク(agnostic」」である（すなわち、サーバーは、待ち行列ストレージの内部の仕組み(inner working)に依存しない）。待ち行列サーバー２００は、ＩＱｕｅｕｅＡｃｃｅｓｓをサポートするオブジェクトを介して読み取り／書込み／ポップアクセスを待ち行列に入れ、そのオブジェクトのＳｙｓｔｅｍ．Ｔｙｐｅがセンダーおよびレシーバオブジェクトのコンストラクタに渡される。ＩＱｕｅｕｅＡｃｃｅｓｓは以下のように定義される。
【００４４】
【表７】
2006190265.tif 000009
【００４５】
ＩＱｕｅｕｅＡｃｃｅｓｓのデフォルト実施形態は、２つのＳＱＬテーブル（例えば、メッセージ待ち行列２３０およびグループ待ち行列２４０など）を使って構築される。しかしながら、待ち行列サーバー２００の残りの部分からのこの待ち行列アクセスの分離のために、システム全体が、任意の適当な記憶システム（ＭＳＭＱやＹｕｋｏｎ  ＳＳＢなど）に加えて構築される。
【００４６】
待ち行列ストレージ(queue storage)
メッセージ待ち行列２３０は、送信側サブシステムクライアントから送り出されたメッセージの実際のメッセージ本文データを保持する表である。Ｓｅｎｄｅｒ．Ｓｅｎｄ（）呼び出しごとに、通常、１行がこのテーブルに追加される。図には、メッセージグループがまとめてクラスタ化されているように示されているが、実際には、複数のグループからのメッセージが交錯していることがある。メッセージ待ち行列２３０は、通常、データコンテナとして働く。通常、このテーブルで実行される動作は、新しいメッセージの挿入、処理されたメッセージの削除、および次のメッセージの選択（読み取り）である。このテーブル中のレコードは、前述のＭｅｓｓａｇｅオブジェクトに対応する。
【００４７】
図示の実施形態には、メッセージ待ち行列２３０として１つのテーブルが示されているが、代替の実施形態は、必要に応じて、このテーブルを複数のテーブルに分割することができる。代替の実施形態は、複数のテーブルを実施するために、ただＩＱｕｅｕｅＡｃｃｅｓｓ．ＲｅａｄＭｅｓｓａｇｅ、ＩＱｕｅｕｅＡｃｃｅｓｓ．ＰｏｐＭｅｓｓａｇｅ、およびＩＱｕｅｕｅＡｃｃｅｓｓ．ＳｅｎｄＭｅｓｓａｇｅの実施形態を拡張しさえすればよいはずである。第２のテーブル、グループ待ち行列（２４０）は、次のグループを選択し、グループおよび相関ロックを処理、管理し、追加のメタデータを保持するのに使用される。このテーブル中のレコードは、前述のＧｒｏｕｐオブジェクトに対応する。普通、メッセージ待ち行列２３０とグループ待ち行列（２４０）のレコードの間には、多対１の関係がある。メッセージ待ち行列２３０は、通常、送られた各個別メッセージごとに１つのレコードを持つ。グループ待ち行列（２４０）は、通常、送られた各メッセージグループごとに１つのレコードを持つ。
【００４８】
待ち行列への新グループの追加
送信側サブシステムクライアントがＳｅｎｄｅｒ．ＢｅｇｉｎＭｅｓｓａｇｅＧｒｏｕｐ（）を呼び出すと、グループ待ち行列に新しいレコードが追加される。このレコードは、そのグループが完了するまでどのレシーバもグループを処理し始めないようにするために、「送り出しのためにロックされている(locked for sending)」とマークされる。クライアントが任意の回数Ｓｅｎｄｅｒ．Ｓｅｎｄ（）を呼び出した後、送り出された最後のメッセージのＩＤを用いてグループレコードを更新し、そのグループにロック解除されているとマークするＳｅｎｄｅｒ．ＥｎｄＭｅｓｓａｇｅＧｒｏｕｐ（）が呼び出される。
【００４９】
次に利用可能なグループ(the next available group)の獲得
図３は、本発明の態様による次に利用可能なグループを獲得するプロセスを示す流れ図を示す。一般に、このプロセスは、その相関グループ（相関ＩＤを共用するグループ）が受け取りのためにロックされておらず、そのグループが送り出しのためにロックされておらず、その相関関係が、より高い優先度を持つ送り出しのためにロックされた待ち行列より前のグループを持たない、最高の優先度グループを探す。プロセスの論理は、待ち行列システムの用法に従って変更できる。
【００５０】
プロセスは、開始ブロック３００で開始し、ブロック３１０に進み、そこでその相関関係が受け取りのためにロックされていないすべてのグループのリストが獲得される。このリストは、待ち行列中の位置および特定のメッセージグループの優先度によって順序付けされる。
【００５１】
ブロック３２０において、リストが空でないかどうか判定され、リストにグループが存在する場合にはブロック３４０に進む。リストにグループが存在しない場合、プロセスは、ブロック３３０に進み、終了する。
【００５２】
ブロック３４０において、リスト中の第１のグループが獲得され、ブロック３５０で評価されて、そのグループが送り出しのためにロックされているかどうか判定される。グループが送り出しのためにロックされている場合、プロセスはブロック３６０に進み、そこでロックされているグループの相関ＩＤを共用するすべてのグループがリストから除去される。グループが送り出しのためにロックされていない場合、プロセスはブロック３７０に進み、そこでそのグループが受け取りのためにロックされ、呼び出し側プロセス(calling process)に戻される。
【００５３】
次の利用可能グループの取得（レシーバスレッドおよびワーカースレッド）
図４は、本発明の態様によるレシーバ(receiver)スレッドおよびワーカー(worker)スレッドを使用したプロセスを示す流れ図である。一般に、レシーバ(receiver)スレッドは、待ち行列に利用可能なグループが入れられるのをワッチする。レシーバ(receiver)スレッドは、待ち行列をポーリング(polling the queue)し始める前に、まず、コンストラクタのｓｅｒｖｅｒＩｄパラメータに渡(pass)されたサーバーインスタンス名(server instance name)によって送り出しのためにロックされて(locked for sending)いる任意のグループ(any groups)をロック解除する。これらのグループは、クリーンアップ／回復(cleanup/recovery)プロセスを可能にするためにロック解除される。レシーバ(receiver)スレッドが（マシンリブート(machine reboot)などに起因して）異常に停止した場合、現在処理しているグループは、そうではなく、送り出しのためにロックされたままになるはずである。したがって、これらのグループは、サーバーインスタンスが再始動(restart)するとすぐにロック解除(unlock)される。
【００５４】
この後、レシーバ(receiver)スレッドは、待ち行列に利用可能なグループがあるかポーリングする。グループが利用可能であり、ワーカー(worker)スレッドの数が許容される最大数より少ないとき、レシーバ(receiver)スレッドは、そのグループを処理するワーカー(worker)スレッドを作成することができる。ワーカー(worker)スレッドがグループを正常に処理した場合、そのグループ項目はグループ待ち行列から除去される。そうでない場合、ワーカー(worker)スレッドは、そのグループを用いて再始動される。
【００５５】
プロセスは、開始ブロック４００で開始し、ブロック４０５に進み、そこで、レシーバ(receiver)がそれに属し、ｓｅｒｖｅｒＩｄがそれに関連付けられているサーバーインスタンスによって、ロックされたスレッドが受け取りのためにロック解除される。
【００５６】
ブロック４１０において、いずれかのワーカー(worker)スレッドが利用可能であるかどうか判定される。いずれかのワーカー(worker)スレッドが利用可能である場合、プロセスはブロック４１５に進み、そこで次に利用可能なグループが獲得される。どのワーカー(worker)スレッドも利用可能でない場合、プロセスはブロック４３０に進み、ワーカー(worker)スレッドの状況をチェックする前に待機する。
【００５７】
ブロック４２０において、次に利用可能なグループ(next available group)が獲得(obtain)されたかどうか判定される。次に利用可能なグループが獲得された場合、プロセスはブロック４２５に進み、そこでワーカー(worker)スレッドが開始される。ワーカー(worker)スレッドが開始された後、プロセスはブロック４１０に戻る。次に利用可能なグループが獲得されなかった場合、プロセスはブロック４３０に進み、ワーカー(worker)スレッドの状況をチェックする前に待機する。
【００５８】
ブロック４３０で待機した後、プロセスはブロック４３５に進み、そこでワーカー(worker)スレッドの状況がチェックされる。ブロック４４０において、次に利用可能なグループ中のすべてのメッセージが処理されているかどうか判定される。次に利用可能なグループ中のすべてのメッセージが処理されていない場合、プロセスはブロック４４５に進み、そこでワーカー(worker)スレッドが再始動される。次に利用可能なグループ中のすべてのメッセージが処理されている場合、プロセスはブロック４５０に進み、そこでそのグループがグループ待ち行列から除去される。
【００５９】
ブロック４４５でワーカー(worker)スレッドを再始動し、またはブロック４５０でグループ待ち行列からグループを除去した後、プロセスはブロック４５５に進み、そこでチェックすべき次のワーカー(worker)スレッドがあるかどうか判定される。チェックすべき次のワーカー(worker)スレッドがある場合、プロセスはブロック４３５に戻り、そこでワーカー(worker)スレッドの状況がチェックされる。チェックすべき次のワーカー(worker)スレッドがない場合、プロセスはブロック４１０に戻り、そこでいずれかのワーカー(worker)スレッドが利用可能であるかどうか再度判定される。
【００６０】
メッセージ処理ワーカースレッド(message processing worker thread)
図５は、本発明の態様によるメッセージ処理ワーカースレッドを使用したプロセスを示す流れ図である。一般に、メッセージ処理ワーカースレッドはループとして動作する。メッセージがメッセージ待ち行列上にある間、メッセージ処理ワーカー(worker)スレッドは、メッセージを読み取り、ＩＰｒｏｃｅｓｓＭｅｓｓａｇｅ．ＰｒｏｃｅｓｓＭｅｓｓａｇｅＣａｌｌｂａｃｋ（）を呼び出す。この関数が（メッセージの正常な処理を示す）「真」を返す場合、そのメッセージは待ち行列から除去される。そうでない場合、そのメッセージが再試行される。
【００６１】
プロセスは開始ブロック５００で開始し、ブロック５０５に進み、そこでメッセージが読み取られる。ブロック５２０において、メッセージが正常に獲得されたかどうか判定される。メッセージが正常に獲得された場合、プロセスはブロック５３０に進む。メッセージが正常に獲得されなかった場合、プロセスはブロック５６０に進み、終了する。
【００６２】
ブロック５３０において、正常に獲得されたメッセージが処理され、プロセスはブロック５４０に進み、そこでメッセージが正常に処理されたかどうか判定される。メッセージが正常に処理されなかった場合、プロセスはブロック５３０に戻り、そこで獲得されたメッセージが再度処理される。（プロセス論理に、メッセージが適正に処理され得ない場合に処理を打ち切るためのチェックを入れることができる。）メッセージが正常に処理された場合、プロセスはブロック５５０に進み、そこでメッセージが待ち行列から「ポップ(pop)」される（すなわち、除去され、関連するポインタが調整される）。メッセージがポップされた後、プロセスはブロック５１０に戻り、そこで別のメッセージが読み取られる。プロセスは、次のメッセージが獲得されなくなるまで繰り返し、次のメッセージが獲得されない場合、処理は、終了ブロック５６０で終了する。
【００６３】
サブシステム誤動作からの回復(recovery from subsystem malfunctions)
サブシステム誤動作の２つの事例、すなわち、受信側マシンがリブートされ、オンラインに戻る状況、および受信側マシンがクラッシュし、相当な期間オンラインに戻らない状況が対処される。（相当な期間とは、別のマシンに、クラッシュしたマシンによって担われた処理負荷が割り当てられ得る時間の長さとすることができる。）
送信側サブシステムクラッシュ(sending subsystem crash)からの回復(recovery)は、受け取りのためにロックされるときに、グループ待ち行列２４０中のグループエントリにレシーバ(receiver)のインスタンス名（コンストラクタへのｓｅｒｖｅｒＩｄパラメータ）を用いてマークすることによって可能とされる。リブートシナリオにおいて、受信側サービスの再始動時の最初のアクションは、通常、このインスタンスによって受け取りのためにロックされたグループをロック解除することである。次いで、これらのグループは、任意の利用可能な受信側サービスによって取得され、処理される。
【００６４】
受信側サブシステムがクラッシュし、相当な時間戻らない場合、（センダークラッシュ(sender crash)の場合と同様に）普通は、受け取りのためにマークされた、失効している１つまたは複数のグループが生じることになる。この場合のクリーンアップは、グループをロック解除することによって達成される。グループがロック解除され次第、そのグループは、メッセージ処理スレッドによる継続処理のために取得される。
【００６５】
以上述べた説明、例およびデータは、本発明に係るシステムおよび方法を提供するものである。本発明の精神およ特許請求の範囲から逸脱することなく、本発明に関連した多くの実施形態を構成することができる。
【図面の簡単な説明】
【００６６】
【図１】本発明の例示的実施形態に従って使用されるコンピューティングデバイスを示す図である。
【図２】本発明の実施形態おいて、信頼性の高いメッセージ転送のための待ち行列システムを示すブロック図である。
【図３】本発明の実施形態において、次に利用可能なグループを獲得するプロセスを示す動作流れ図である。
【図４】本発明の実施形態において、レシーバスレッドおよびワーカースレッドを使用したプロセスを示す流れ図である。
【図５】本発明の実施形態において、メッセージ処理ワーカースレッドを使用したプロセスを示す流れ図である。
【符号の説明】
【００６７】
１００  コンピューティングデバイス
１０２  処理ユニット
１０４  システムメモリ
１０５  オペレーティングシステム
１０６  アプリケーション
１０８  サーバー待ち行列システム
１０７  プログラムデータ
１０９  取り外し可能ストレージ
１１０  取り外し不能ストレージ
１１２  入力デバイス
１１４  出力デバイス
１１６  通信接続
１１８  他のコンピューティングデバイス
２００  待ち行列サーバー
２３０  メッセージ待ち行列（ＳＱＬテーブル）
２４０  グループ待ち行列（ＳＱＬテーブル）
２５０  クライアント（送信側サブシステム）
２５２  クライアント（送信側サブシステム）
２５４  クライアント（送信側サブシステム）
２６０  クライアント（受信側サブシステム）
２６２  クライアント（受信側サブシステム）
２６４  クライアント（受信側サブシステム）
【図１】
2006190265.tif 000010
【図２】
2006190265.tif 000011
【図３】
2006190265.tif 000012
【図４】
2006190265.tif 000013
【図５】
2006190265.tif 000014