JP2007149081A - メッセージ順序を保存するためのシステム - Google Patents

Abstract

【課題】 メッセージ順序を保存するためのシステムを提供すること。
【解決手段】 メッセージがそれに関連付けられた順序識別子を備え、受信機構が第１の順序識別子に関連付けられた第１のメッセージを受信するように動作可能であり、選択要素が第１のメッセージを処理するために第１のエンティティを選択するように動作可能である環境で使用するための、メッセージに関連付けられた順序を保存するためのシステムである。このシステムは、第１のメッセージの処理の完了に関連付けられた通知が受信機構によって受信されたか否かを判断するための判断要素と、通知の受信と通知の受信に続く受信機構による第１の識別子に関連付けられた第２のメッセージの受信との組み合わせに応答して、第２のメッセージを処理するために第２のエンティティを選択するように選択要素を制御するコントローラと、を備える。
【選択図】 図３

Description

本発明は、メッセージ順序を保存するためのシステムに関する。

図１を参照すると、ＷｅｂＳｐｈｅｒｅ ＭＱ（ＷｅｂＳｐｈｅｒｅはＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎの登録商標である）のような非同期式メッセージング・システム（１００）においては、送信側アプリケーション（ここでは「プロデューサ」（１０５）という用語で呼ばれる）は、処理のために受信側アプリケーション（ここでは「コンシューマ」（１１０）という用語で呼ばれる）のキュー（１１５）にメッセージを送信する。

非同期式メッセージング・システムを用いるときには、しばしば、プロデューサからのメッセージが順序通りに処理される必要性がある。通常、プロデューサは順序が保存されると想定し、その想定を踏まえて設計される。例えば、一組のメッセージが、データベースからの挿入、更新、削除などを表す場合に、そのメッセージが順序を無視して処理されると、結果は悲惨なことになりかねない。例えば、列の挿入動作に後続する列の削除動作が誤った順序で処理された（即ち削除動作が挿入動作の前に処理された）場合には、結果として、削除されるはずだった列が挿入されたまま残ることになる。即ち、ある数の非同期メッセージがコンシューマによって到着順に処理されねばならない場合に、メッセージｍ１及びメッセージｍ２が順次的な順序で到着するときには、コンシューマは、メッセージｍ１を先に処理しなければならず、ｍ１の処理が完了して初めてｍ２の処理を行うことができる。

プロデューサはメッセージを作成された順に順序付けるのが必然的であり、この順序を保存するための最も一般的なソリューションは、プロデューサがそのメッセージの全てを、単一のコンシューマに関連付けられたキューに送信するように設定することである。単一のコンシューマは、キューからの全てのメッセージを、そのメッセージがそのキューに入れられた順序で処理する。

残念ながら、そうしたメッセージ・コンシューマは、シングル・ポイント障害となる。さらに、たった１つのコンシューマが用いられるのであるから、システムは規模拡大が可能にはならない。さらにまた、たった１つのコンシューマが用いられるのであるから、このソリューションはまた、異なる数のコンシューマをサポートできる動的で柔軟なメッセージング・アーキテクチャを構築する可能性を制限する。複数のコンシューマは、ロード・バランシング要件に役立つことができ、故障したコンシューマを迂回するのに利用することができるといった利点をもつ。

よって、幾つかの非同期式メッセージング・システムにおいては、スケーラビリティのために、複数のコンシューマが共有キューからのメッセージを処理することが可能である。非同期式メッセージング・システムに関連する１つの問題は、共有キューからのメッセージを巡って複数のコンシューマが競合した場合に、メッセージの処理順序を保証しないということである。図２の非同期式メッセージング・システム（２００）を参照すると、２つのコンシューマ（２１０、２２０）が単一のキューでリスンする場合、一方のコンシューマが他方のコンシューマより速くメッセージを処理することがある。

例えば、コンシューマ１（２１０）がコンシューマ２（２２０）の半分の速度で実行する場合には、コンシューマ１（２１０）は、幾つかのメッセージを処理するのにコンシューマ２（２２０）の２倍の時間を取りかねない。さらにまた、コンシューマ１はコンシューマ２の存在を全く知らないことが通例である。従って、コンシューマ２（２２０）がメッセージｍ１を取り寄せて処理し、コンシューマ１（２１０）がｍ２を取り寄せ、コンシューマ１（２１０）がｍ２の処理を完了する前にコンシューマ２（２２０）がメッセージｍ３を取り寄せて処理した場合には、シーケンスｍ１、ｍ２、ｍ３は、実際には、ｍ１、ｍ３、ｍ２という順序で処理される。

従来技術のソリューションである、非特許文献１においては、複数のコンシューマが共有キューからのメッセージを処理する時に用いることが可能なシステムが開示される。従来技術においては、特定の種類のメッセージが、（例えばプロデューサ、フィルタリング・アプリケーションなどにより）グローバル・ユニーク・シーケンス番号（ＧＵＳ）を用いてマーク付けされる。複数のコンシューマは、最後に処理されたメッセージに関連付けられたデータ（例えばＧＵＳ、メッセージ・ペイロードなど）を格納する第１のリレーショナル・データベース、及び、シーケンスから外れたメッセージに関連付けられたデータ（例えばＧＵＳ）を格納する第２のリレーショナル・データベースへのアクセス手段を持たなければならない。よって、メッセージｍ１、ｍ２、ｍ３が、ｍ１、ｍ３、ｍ２という順序で到着した場合には、ｍ１が最初に処理されて第１のリレーショナル・データベースに挿入される。ｍ３が受信されたときには、第１のリレーショナル・データベースに対する照会が、ｍ３の順序は誤っており、従って、ｍ２が受信されるまで第２のリレーショナル・データベースに挿入されると判断する。ｍ２が受信されたときには、第１のリレーショナル・データベースに対する照会が行われて、ｍ１が処理済みであると判断する。よって、その後にｍ２及びｍ３を処理することができる。次いで、第１のリレーショナル・データベースは、ｍ２及びｍ３が処理済みであることを反映するために更新される。

従来技術のソリューションは、メッセージが転送中に誤った順序となることを許し、ＧＵＳ及びリレーショナル・データベースを用いて順序を立て直せるようにする。しかしながら、メッセージ・ペイロードが格納される必要があり、これはオーバーヘッドを引き起こす。そしてまた、コンシューマがリレーショナル・データベースへのアクセス手段を共有する必要があり、このことは、リレーショナル・データベースへのアクセス手段を共有できるコンシューマの数が限られているため、オーバーヘッドを引き起こしてスケーラビリティを減少させかねない。

「Ａ Ｍｅｔｈｏｄ ｆｏｒ Ｓｃａｌｅａｂｌｅ， Ｏｒｄｅｒｅｄ Ｍｅｓｓａｇｅ Ｐｒｏｃｅｓｓｉｎｇ」、ＩＢＭによるＩＰＣＯＭ００００２０２３３Ｄ（２００３年１１月４日付でＩＰ．ｃｏｍにロード済み）

幾つかの非同期式メッセージング・システムにおいては、複数のコンシューマが「クラスター化」され、各々のコンシューマは関連付けされたキューをもつ。メッセージの順序付けを保存するために、幾つかのシステムは、通常、メッセージを送信する相手である単一のコンシューマ・インスタンスをプロデューサが選択することができるという特徴を提供する。しかしながら、メッセージが、異なるクラスター化されたコンシューマのチェーンを経由して送信される場合には、メッセージ順序付け要件が犠牲にされなければならない（即ち、後から来たメッセージが先に来たメッセージを追い越すことを許し、チェーンにおける各コンシューマが各メッセージに対し動的に選択されるようにする）か、又は、動的で柔軟なメッセージング・アーキテクチャを構築する能力が犠牲になる（即ち、各要素が、メッセージが送信されるべき相手である次の要素を明示的に指定する）。

第１の態様によれば、メッセージがそれに関連付けられた順序識別子を備え、受信機構が第１の順序識別子に関連付けられた第１のメッセージを受信するように動作可能であり、選択要素が第１のメッセージを処理するために第１のエンティティを選択するように動作可能である環境で使用するための、メッセージに関連付けられた順序を保存するためのシステムであって、第１のメッセージの処理の完了に関連付けられた通知が受信機構によって受信されたか否かを判断するための判断要素と、通知の受信と通知の受信に続く受信機構による第１の識別子に関連付けられた第２のメッセージの受信との組み合わせに応答して、第２のメッセージを処理するために第２のエンティティを選択するように選択要素を制御するコントローラと、を備えるシステムが提供される。

メッセージ順序は保存され、さらにまた、メッセージは転送される際に誤った順序にはならないという利点がある。順序に関連付けられたメッセージを処理するために異なるコンシューマを選択することが可能である（単一のコンシューマに送信された全ての未処理のメッセージに関連する確認応答が受信済みである場合）という利点がある。このことは、（例えば故障したコンシューマを迂回するなどの目的で）柔軟なアーキテクチャが構築されることを可能にする。

システムは、メッセージに関連付けられたデータとエンティティに関連付けられたデータをストレージ要素にロギングするためのロギング要素を備えることが好ましい。ストレージ要素は永続的であることがより好ましい。或いは又、ストレージ要素は非永続的である。ストレージ要素内のデータは、通知の受信に応答してパージされることが更により好ましい。

１つの好ましい実施形態においては、第１のエンティティは、処理のために第１のメッセージを第３のエンティティに転送するように動作可能であり、且つ、第１のメッセージに関連付けられたデータと第３のエンティティに関連付けられたデータをロギングするように動作可能である。第１のエンティティは、第３のエンティティから第１のメッセージの処理の完了に関連付けられた別の通知を受信することに応答して通知を生成するように動作可能であることが好ましい。システムは、順序識別子を生成するための生成機構を更に備えることがより好ましい。

通知は、複数のメッセージの処理の完了に関連付けられることが好ましい。通知は、システムに関連付けられたパラメータに従って送信されることがより好ましい。通知は非永続的であることが更により好ましい。

１つの好ましい実施形態においては、コントローラは、通知の受信に先立ち、受信機構による第１の識別子の受信に関連付けられた第３のメッセージに応答し、第３のメッセージを処理するために第１のエンティティを選択する選択要素を制御するように動作可能である。

第２の態様によれば、メッセージがそれに関連付けられた順序識別子を備え、受信機構が第１の順序識別子に関連付けられた第１のメッセージを受信するように動作可能であり、選択要素が第１のメッセージを処理するために第１のエンティティを選択するように動作可能である環境で使用するための、メッセージに関連付けられた順序を保存する方法であって、第１のメッセージの処理の完了に関連付けられた通知が受信機構によって受信されたか否かを判断するステップと、通知の受信と、通知の受信に続いて受信機構による第１の識別子に関連付けられた第２のメッセージの受信との組み合わせに応答して、第２のメッセージを処理するために第２のエンティティを選択するように選択要素を制御するステップと、を含む方法が提供される。

第３の態様によれば、コンピュータ上で動作するときに上述された方法のステップの全てを実行するように適合されたプログラム・コード手段を備えている、コンピュータ・プログラムが提供される。

これより本発明は、一例として、添付の図面に図示された好ましい実施形態を参照して説明される。

これより、図３及び図４を参照して、第１の実施形態が説明される。図４の第１の実施例においては、ステップ４００からステップ４５０は、ここでは「プロデューサ（３０５）」と呼ばれるプロデューサ（３０５）に関連付けられるメイン・スレッドによって実行されることが好ましい。ステップ４５５からステップ４８０は、プロデューサ（３０５）と並列に処理を行う並列プロデューサ・スレッドによって実行されることが好ましい。図３においては、少なくとも１つのメッセージを（例えばイベントに応答して）生成する（ステップ４００）プロデューサ（３０５）を含む非同期式メッセージング・システム（３００）が示される。第１の実施例においては、メッセージは、データベース列に対するデータベース動作（例えば、「挿入」「更新」「削除」など）と関連付けられる。メッセージ順序は、単一のプロデューサ・インスタンスによって生成されたメッセージに関して保存されることが好ましい。

システム（３００）はまた、対応する複数のシステムの間でクラスター化された複数のコンシューマ、即ち、関連付けられたキュー（３１５）を伴うコンシューマ１（３１０）及び、関連付けられたキュー（３２５）を伴うコンシューマ２（３２０）を含む。コンシューマの個々のインストールは、インスタンスとして知られる（即ち、コンシューマ１は１つのインスタンスであり、コンシューマ２は１つのインスタンスである）。第１の実施形態においては、各々のコンシューマ・インスタンスは、別のコンシューマなどに転送することなしに、メッセージを処理する。

非同期式メッセージング・アプリケーションは、プロデューサ及びコンシューマ・インスタンスの各々と同一のシステム上で実行することが通例である。

第１の実施形態においては、プロデューサ（３０５）は、メッセージの各々に、シーケンス識別子及びシーケンス番号（ここではシーケンス番号は、シーケンス識別子によって識別されたシーケンス内において一意であり、シーケンス番号の値は時間と共に増加する）をタグ付けする（ステップ４０５）。１つの例においては、シーケンス識別子は、プロデューサに対して一意（例えば、シーケンス識別子がタスクに対して一意である場合）であり、そのことにより、同じシーケンス識別子を有するメッセージを１つ以上のプロデューサが生成しないようにする。別の例においては、シーケンス識別子は、プロデューサに対して一意とすると共にコンシューマに対して一意としてもよく、そのことにより、同じシーケンス識別子を有するメッセージを１つ以上のコンシューマが受信しないようにする。

第１の実施例においては、データベース列は、各々、関連付けられたシーケンス識別子を有し、プロデューサ（３０５）は２つのメッセージを生成する。順序要件は、従って、第１のメッセージに対してはｓ１ｍ１（ここで「ｓ１」はシーケンス識別子であり、「ｍ１」はシーケンス番号であり、「列１を挿入する」がメッセージ・ペイロードである）、第２のメッセージに対してはｓ１ｍ２（ここで「ｓ１」はシーケンス識別子であり、「ｍ２」はシーケンス番号であり、「列１を更新する」がメッセージ・ペイロードである）のように記述でき、ｓ１ｍ１はｓ１ｍ２のシーケンス番号より小さいシーケンス番号をもつことから、ｓ１ｍ２の前に処理されねばならない。

適切なシーケンス識別子及びシーケンス番号を生成するタスクは、代替的に、メッセージング・アプリケーションか、又はプロデューサとメッセージング・アプリケーションの組み合わせによって実行されてもよい。後者の実施形態においては、プロデューサは、一意でないシーケンス識別子（例えば顧客ｉｄであり、１つ以上のプロデューサがその顧客ｉｄを用いる）を指定でき、その後メッセージング・アプリケーションがシーケンス識別子を修飾して、そのシーケンス識別子がプロデューサに対して一意となるようにすることができる。更に別の実施形態においては、複数のプロデューサが協働して、各々のプロデューサに一意であるようなシーケンス識別子を決めてもよい。

プロデューサ（３０５）は、第１のメッセージｓ１ｍ１を送信して処理するためにコンシューマ・インスタンスを選択する選択要素を備える。或いは又、ロード・バランシング技術、可用性要件などに基づき、メッセージング・アプリケーションがコンシューマ・インスタンスを選択してもよい。

第１の実施例においては、プロデューサ（３０５）が、コンシューマ１（３１０）を選択し、コンシューマ１（３１０）に関連付けられたキュー（３１５）にｓ１ｍ１を送信する（ステップ４１０）。プロデューサ（３０５）は、ｓ１ｍ１に関連付けられたメッセージ・データをロギングする（ステップ４１５）。

第１の実施例においては、シーケンス識別子（即ちｓ１）と、送信された最新のメッセージのシーケンス番号（即ちｍ１）がロギングされる。或いは又、付加的に、メッセージ・ペイロードもロギングすることができる。プロデューサ（３０５）はまた、コンシューマ１（３１０）に関連付けられたコンシューマ・データ（即ち、コンシューマ１に関連付けられた識別子であり、第１の実施例においては、識別子は「Ｃ１」である）をロギングする（ステップ４１５）。ログの図は、図７の表１に示される。

異なるプロデューサ・インスタンスの間でメッセージ順序を保存する必要性がないことから、プロデューサに関連付けられたログは、永続的（即ちディスクに書き込まれるもの）でないことが好ましい。例えば、シーケンス識別子は、プロデューサ・インスタンスに固有のものとなる。プロデューサの１つのインスタンスが終了した（例えばクラッシュしたか又は正常に終了した）場合には、再スタートに当たって、プロデューサの新規のインスタンスが実行される。異なるプロデューサ・インスタンスの間でメッセージ順序を保存する必要性はないことから、新規のプロデューサ・インスタンスは、先行するプロデューサ・インスタンスが用いたシーケンス識別子に対し新しいシーケンス識別子を使用し、プロデューサ・インスタンスは、プロデューサ・インスタンスにわたっていかなるデータも持続させる必要がない。先行するプロデューサ・インスタンスに関連付けられたメッセージは、依然として処理される。

或いはまた、プロデューサが故障の後で復旧できるようにするために、プロデューサに関連付けられたログは、永続的なもの（即ちディスクに書き込まれるもの）であってもよい。このことは、プロデューサが順序付けを失うことなしに続行することを可能にする。プロデューサは、外部イベントに応答してメッセージを生成する場合に、この技術を用いることができる。

次に、プロデューサ（３０５）に関連付けられた並列プロデューサ・スレッドは、ｓ１ｍ１が処理されたというコンシューマ１（３１０）からの確認応答を待つ（ステップ４５５）。第１の実施例においては、特定のシーケンス番号ｙをもつメッセージに関する確認応答はまた、シーケンス番号ｙ又はそれ以下の番号をもつ全てのメッセージに関しても確認応答する役割を果たす。

並列プロデューサ・スレッドは、並列に継続的に実行してもよく、又は確認応答が受信された時に呼び出されてもよいと理解されるべきである。

第１の実施例においては、並列プロデューサ・スレッドが、ｓ１ｍ１が処理されたというコンシューマ１（３１０）からの確認応答を待っている間に、プロデューサ（３０５）は、第１のメッセージと合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかのメッセージが存在するかどうかを判断する（ステップ４２５）。処理のために送信されるべきそれ以上のメッセージが存在しないとの判断に応答して、並列プロデューサ・スレッドは、ｓ１ｍ１が処理されたというコンシューマ１（３１０）からの確認応答を待ち続ける。

第１の実施例においては、プロデューサ（３０５）は、処理のために送信されるべき更なるメッセージ（即ち第２のメッセージｓ１ｍ２）が存在すると判断する。よって、処理のために送信されるべき更なるメッセージが存在するという判断に応答して、プロデューサ（３０５）は、更なるメッセージに関連付けられたシーケンス識別子（即ちｓ１）を判断する。プロデューサ（３０５）はこのシーケンス識別子を用いて、ログをチェックし（ステップ４３０）、合致するシーケンス識別子をもった記録があるか否かを判断する（ステップ４３５）。合致するシーケンス識別子をもった記録が存在しないという判断に応答して、プロデューサは、更なるメッセージをコンシューマに送信する（ステップ４１０）。

第１の実施例においては、プロデューサ（３０５）は、合致するシーケンス識別子をもった記録（即ち表１においてシーケンス識別子「ｓ１」をもつ記録）が存在すると判断し、従って、合致するシーケンス識別子をもった記録が存在するという判断に応答して、プロデューサ（３０５）は、関連付けられたコンシューマ・データ（即ち「Ｃ１」）を判断する（ステップ４４０）。並列プロデューサ・スレッドはｓ１ｍ１が処理されたというコンシューマ１（３１０）からの肯定通知を待っているのであるから、ログ記録はまだパージされておらず、故に、プロデューサ（３０５）は、合致するシーケンス識別子をもったログ記録がログの中に存在すると判断することに注意されたい。

プロデューサ（３０５）は、次いで、ｓ１ｍ２を、判断されたコンシューマ・データに関連付けられたコンシューマのキュー（即ちコンシューマ１（３１０）に関連付けられたキュー（３１５））に送信する（ステップ４４５）。ここでｓ１ｍ１は、第２のメッセージｓ１ｍ２と同じシーケンス識別子をもっており、コンシューマ１（３１０）は、第１のメッセージｓ１ｍ１を処理したのと同じコンシューマ・インスタンスであると理解されるべきである。プロデューサ（３０５）は、ｓ１ｍ２に関連付けられたメッセージ・データをロギングする（ステップ４５０）。第１の実施例においては、表１に表されたシーケンス識別子フィールド中のデータ（即ちｓ１）は変わらないが、ｍ２は送信された最新のメッセージのシーケンス番号であることから、シーケンス番号フィールド中のデータは上書きされ（即ち、ｍ１はｍ２で上書きされ）、表１に表されたコンシューマ識別子フィールド中のデータ（即ちＣ１）は変わらない。

更新されたプロデューサ・ログの図は図７の表２に示される。

データのロギング（ステップ４５０）に応答して、プロデューサ（３０５）は、第１のメッセージと合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかのメッセージが存在するかどうかを判断する（ステップ４２５）。第１の実施例においては、プロデューサ（３０５）は、処理のために送信されるべきそれ以上のメッセージが存在しないと判断し、並列プロデューサ・スレッドは、ｓ１ｍ１及びｓ１ｍ２が処理されたというコンシューマ１（３１０）からの確認応答を待ち続ける。

第１の実施例においては、コンシューマ１（３１０）は、ｓ１ｍ１を処理し、次いで、ｓ１ｍ２を処理する（ここで処理する順序は、メッセージがキュー（３１５）に到着した順序によって指定される）。ｓ１ｍ２が処理された後で、コンシューマ１（３１０）は、確認応答を生成して並列プロデューサ・スレッドに送信し、ｓ１ｍ２が処理されたことを確認応答する。第１の実施例においては、特定のシーケンス番号をもつメッセージに関する確認応答は、より小さいシーケンス番号をもつ全てのメッセージに関して確認応答する役目も果たすことから、この確認応答は、ｓ１ｍ１が処理されたことの確認応答でもある。

代替的に、コンシューマ・インスタンスに代わり、メッセージング・アプリケーションが、確認応答を生成し送信してもよいことが理解されるべきである。

並列プロデューサ・スレッドは、いずれかの確認応答が受信されたか否かの判断を行う（ステップ４６０）。いかなる確認応答も受信されない場合には、例えば、生成機構がアラートを生成し（ステップ４７０）、そのことにより、システム管理者が分析を実行できるようにする（例えば、システム管理者は、シーケンス識別子に関連付けられた未処理のメッセージに関連するログ記録のパージを強制することができる）。

第１の実施例においては、並列プロデューサ・スレッドは、確認応答が受信されたという判断を行う（例えば、並列プロデューサ・スレッドは、予め定められた時間の間、確認応答を待つことができる）（ステップ４６０）。

確認応答の受信に応答して、並列プロデューサ・スレッドは、ログをチェックし（ステップ４６５）、プロデューサ（３０５）は、シーケンス識別子に関連付けられた未処理のメッセージに関連するログ記録を「忘却」して良いか否かを判断する（ステップ４７５）。即ち、並列プロデューサ・スレッドは、確認応答内のシーケンス識別子及び関連付けられたシーケンス番号を、ログ記録内のシーケンス識別子データ及び関連付けられたシーケンス番号データと比較する。

送信された特定のシーケンス識別子に関連付けられた未処理のメッセージの各々について、確認応答が受信されなかった場合には、生成機構がアラートを生成する（ステップ４７０）。

送信された特定のシーケンス識別子に関連付けられた未処理のメッセージの各々について、確認応答が受信された場合には、並列プロデューサ・スレッドは、処理済みのメッセージのシーケンス識別子に関連付けられたログ記録（即ち、ｓ１ｍ２に関連付けられた（従ってｓ１ｍ１に関連付けられた）表２のログ記録）をパージする（ステップ４８０）。

第１の実施例においては、ｓ１ｍ２に関する（従ってｓ１ｍ１に関する）確認応答は、（表２に表された）ログに対して比較される。確認応答のシーケンス識別子は、ログ記録内のシーケンス識別子データに合致する。確認応答のシーケンス番号は、ログ記録内の最新のシーケンス番号データに合致し、よって、確認応答がｍ２の２より小さいシーケンス番号をもった全てのメッセージの処理も確認応答することから、確認応答はまた、ｍ１の処理も確認応答する（即ち、ｍ１が２より小さい数であるシーケンス番号１をもつ場合である）。

よって、並列プロデューサ・スレッドは、処理済みのメッセージのシーケンス識別子に関連付けられたログ記録（即ち、ｓ１ｍ２に関連付けられた（従ってｓ１ｍ１に関連付けられた）表２のログ記録）をパージする（ステップ４８０）。

メッセージにシーケンス識別子及びシーケンス番号を割当てることは、そのメッセージに関連付けられた確認応答が識別されることを可能にする（即ち、メッセージ内のシーケンス識別子及びシーケンス番号を、確認応答内のシーケンス識別子及びシーケンス番号と比較することによって）ことが理解されるべきである。単一のコンシューマは、その単一のコンシューマのキューに受信された順序でメッセージを処理することから、コンシューマがメッセージの処理に際して順序を保証すると理解されるべきである。

次に、プロデューサ（３０５）は、第３のメッセージを生成し（ステップ４００）、そのメッセージにシーケンス識別子及びシーケンス番号を（第１の実施例においては−ｓ１ｍ３）タグ付けする（ステップ４０５）。プロデューサ（３０５）は、処理のために第３のメッセージｓ１ｍ３を送信するべくコンシューマ・インスタンスを選択する。第１の実施例においては、プロデューサ（３０５）は、コンシューマ２（３２０）を選択し、コンシューマ２（３２０）に関連付けられたキュー（３２５）にｓ１ｍ３を送信する（ステップ４１０）。プロデューサ（３０５）は、ｓ１ｍ３に関連付けられたメッセージ・データをロギングし（ステップ４１５）、第１の実施例においては、シーケンス識別子（即ちｓ１）と送信された最新のメッセージのシーケンス番号（即ちｍ３）がロギングされる。プロデューサ（３０５）はまた、コンシューマ２（３２０）に関連付けられたコンシューマ・データ（即ち、コンシューマ２に関連付けられた識別子であり、第１の実施例においては、識別子は「Ｃ２」である）をロギングする（ステップ４１５）。プロデューサ・ログの図は、図７の表３に示される。

次に、並列プロデューサ・スレッドは、ｓ１ｍ３が処理されたというコンシューマ２（３２０）からの確認応答を待つ（ステップ４５５）。第１の実施例においては、並列プロデューサ・スレッドが、ｓ１ｍ３が処理されたというコンシューマ２（３２０）からの確認応答待ちをしている間に、プロデューサ（３０５）は、第３のメッセージと合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかのメッセージが存在するかどうかを判断する。第１の実施例においては、処理のために送信されるべきそれ以上のメッセージが存在しないので、並列プロデューサ・スレッドは、ｓ１ｍ３が上記のように処理されたというコンシューマ２（３２０）からの確認応答を待ち続ける（ステップ４５５）。

第１の実施例においては、コンシューマ２（３２０）は、ｓ１ｍ３を処理し、確認応答を生成して並列プロデューサ・スレッドに送信し、ｓ１ｍ３が処理されたことを確認応答する。

並列プロデューサ・スレッドは、いずれかの確認応答が受信されたか否かの判断を行う（ステップ４６０）。いかなる確認応答も受信されない場合には、生成機構がアラートを生成する（ステップ４７０）。

第１の実施例においては、並列プロデューサ・スレッドは、確認応答が受信されたという判断を行う（ステップ４６０）。確認応答を受信することに応答して、並列プロデューサ・スレッドは、ログをチェックし（ステップ４６５）、プロデューサ（３０５）が、上記のように、シーケンス識別子に関連付けられた未処理のメッセージに関連するログ記録を「忘却」して良いか否かを判断する（ステップ４７５）。

第１の実施例においては、ｓ１ｍ３に関する確認応答は、（表３に表された）ログに対して比較される。確認応答のシーケンス識別子は、ログ記録内のシーケンス識別子データに合致する。確認応答のシーケンス番号は、ログ記録の最新のシーケンス番号データに合致する。よって、並列プロデューサ・スレッドは、処理済みのメッセージのシーケンス識別子に関連付けられたログ記録（即ち、ｓ１ｍ３に関連付けられた表３のログ記録）をパージする（ステップ４８０）。

よって、プロデューサは、システム内の同じシーケンス識別子をもつ未処理のすべてのメッセージを、同じコンシューマ・インスタンスに送信するように設定可能である。単一のコンシューマが、該コンシューマに関連付けられたキューに到着する順序でメッセージを処理するのであるから、このことは、シーケンス内の順序が保存されることを可能にする。

さらにまた、同じコンシューマ・インスタンス（即ちＣ１）に送信された、同じシーケンス識別子（即ちｓ１）をもつ未処理のメッセージの各々（即ちｍ１、ｍ２）に関する確認応答が受信された時にのみ、プロデューサ（３０５）は、該プロデューサがいずれかの与えられたシーケンスに関するコンシューマを既に選択済みであることを「忘却」することができる。その後、プロデューサ（３０５）は、次にそのシーケンス（即ちｓ１）内のメッセージ（即ちｍ３）を見た時に、新規のコンシューマ・インスタンス（即ちＣ２）を選択することができる。未処理のメッセージの各々に関する確認応答を全て受信する前にプロデューサ・インスタンスが故障した場合には、その未処理のメッセージは、それでも処理されるが、プロデューサ・インスタンスに確認応答が返信されることはないと理解されるべきである（なぜならば、再スタートの際のプロデューサ・インスタンスは新規のプロデューサ・インスタンスであるからである）。

よって、システム内で未処理のメッセージをもつシーケンス識別子の各々について、プロデューサからコンシューマへのルートが構築され、該ルートは、メッセージがシステム内で未処理であるあいだ再利用されるが、そのシーケンス内のメッセージがもはや処理されなくなると破壊される（そして後に再構築される可能性がある）。

よって、特定のシーケンスが未処理のメッセージをもたないときに、好ましい実施形態は、新規のルートが構築されることを可能にする。好ましい実施形態は、システム内のいずれかの故障したコンシューマを迂回し、高い可用性の維持を助けるという利点がある。さらにまた、コンシューマの１つが故障した場合には、その故障したコンシューマが故障時に処理していたシーケンス識別子に関連するメッセージのみが、引き続き、故障したコンシューマに送られることになる（但し、例えばシステム管理者が介入して、シーケンス識別子に関連付けられた未処理のメッセージに関連するログ記録のパージを強制した場合を除く）。別のシーケンス識別子に関連付けられたメッセージは、メッセージ順序要件を損なうことなしに、安全に故障ポイントを迂回することができる。

現行のコンシューマ・インスタンスがそれまでに受信したメッセージを処理した後にシーケンスを忘却する特徴は、プロデューサ（３０５）が、増え続けるシーケンス識別子及びそれに関連付けられたコンシューマ識別子のログを蓄積しないという利点がある。

好ましい実施形態においては、特定のシーケンス識別子に関連付けられたメッセージの全てが同じコンシューマ・インスタンスによって処理される必要はないが、特定の順序で処理されねばならないことが理解されるべきである。即ち、メッセージは、１つのシーケンス識別子に関連付けられた先行するメッセージがコンシューマ・インスタンスに送信されてはいるが、該コンシューマ・インスタンスによってまだ処理されていないときにだけ、同じコンシューマ・インスタンスに送信される。

確認応答は、処理された全てのメッセージに関して生成できることが理解されるべきである。しかしながら、確認応答の生成及び受信は、最適化することが可能である。上述されたように、１つの実施例においては、ｓ（ｘ）に関する単一の確認応答、ｍ（ｙ）は、シーケンス識別子ｘ及びシーケンス番号ｙ又はそれ以下の番号をもつ全てのメッセージに関して確認応答する役目を果たす。別の実施例においては、確認応答の生成を省略し、処理されたメッセージに関して一つおきに確認応答が生成されるようにしてもよい。更に別の実施例においては、確認応答の生成は遅らせることができる（例えば、より広い帯域幅が利用可能になるまで）。更に別の実施例においては、確認応答は、バッチにおける第１のメッセージを受信してからのタイムアウトにより、メッセージのバッチに関して送信してもよい。更に別の実施例においては、シーケンス識別子に関連付けられた更なるメッセージがコンシューマ・インスタンスに送られたがまだ処理されていない状態にあるか否かを判断するように、メッセージング・アプリケーションを設定してもよい。メッセージング・アプリケーションは、その後、最後の未処理メッセージに関する確認応答が生成されるまでコンシューマ・インスタンスを待ち続ける、未処理のメッセージをもったシーケンス識別子に関して生成される確認応答を、廃棄するように設定可能である。或いは又、メッセージング・アプリケーションは、全ての未処理のメッセージが処理された時にのみ、コンシューマ・インスタンスを起動して（１つ又はそれ以上の）確認応答を生成するようにしてもよい。

処理されたメッセージ毎に確認応答を生成しないようにすることによって、シーケンス識別子に関連付けられた更なるメッセージは、全ての適切な確認応答が受信されるまで別のコンシューマ・インスタンスに送信できなくなったり（また、それにより、更なるメッセージが故障したコンシューマ・インスタンスを迂回することができなくなる）、確認応答が生成されなければならない時にコンシューマ・インスタンスが利用可能でなくなる場合もあるが、この特徴は、性能を向上させ、確認応答の生成及び送信に関連するオーバーヘッドを最小化するという利点がある。

別の最適化の実施例においては、確認応答は、非永続的メッセージとすることができる。永続的メッセージ（メッセージング・システムが消失させないことが保証されている）は、ディスクに書き込まれなければならず、従って、オーバーヘッドとなる。さらにまた、永続的メッセージを処理する時には、余剰のネットワーク使用が必要になる（例えば、永続的メッセージを受信した受信者からその永続的メッセージの送信者へ確認応答を送信する必要があるかも知れない）。よって、特定のシーケンス識別子に関連付けられたメッセージに関する確認応答が消失した場合であっても、その特定のシーケンスに関連付けられた更なる（未処理ではない）メッセージは、適切な確認応答が受信されるまで、同じコンシューマ・インスタンスに送信され、以下同様である。この最適化特徴は、メッセージが散発的に生成されるようなシーケンスにおいては、更なる（未処理でない）メッセージが生成されて適切な確認応答が受信されるまで時間がかかる場合があり、従って、そのシーケンス識別子に関連するログ記録のパージを遅らせることから、好適ではないかもしれない。

これより、第２の実施形態が、図４、図５、及び図６を参照しながら説明される。図６の第２の実施例においては、ステップ６００からステップ６６０は、ここでは「媒介体１（５１０）」と呼ばれる媒介体１（５１０）に関連付けられたメイン・スレッドによって実行されることが好ましい。ステップ６６５からステップ６９５は、媒介体１（５１０）と並列に処理を行う並列媒介体スレッドによって実行されることが好ましい。

図５においては、少なくとも１つのインバウンド・メッセージを（例えばイベントに応答して）生成するプロデューサ（５０５）を含む、非同期式メッセージング・システム（５００）が示される。ここで用いる「インバウンド」という用語は、媒介体に対してインバウンドであることをいう。システム（５００）はまた、対応する複数のシステムの間でクラスター化された複数の媒介体、即ち、関連付けられたキュー（５１５）を伴う媒介体１（５１０）と、関連付けられたキュー（５２５）を伴う媒介体２（５２０）とを備える。システム（５００）は、また、対応する複数のシステムの間でクラスター化された複数のコンシューマ、即ち、関連付けられたキュー（５３５）を伴うコンシューマ１（５３０）及び、関連付けられたキュー（５４５）を伴うコンシューマ２（５４０）を含む。媒介体又はコンシューマの個々のインストールは、インスタンスとして知られる。

１つのタイプの媒介体は、通常、インバウンド・メッセージに応答して、１つ又はそれ以上のアウトバウンド・メッセージを生成することができ、ここでは「アウトバウンド」という用語は、コンシューマに対してアウトバウンドであることをいう。別のタイプの媒介体は、プロデューサからのインバウンド・メッセージを変換し、変換されたメッセージをコンシューマに送信することができる。例えば、メッセージ中の時刻データが英国夏時間（ＢＳＴ）からグリニッジ標準時（ＧＭＴ）に変換される。別のタイプの媒介体は、異なるコンシューマの間でインバウンド・メッセージを送ることができる。特に複雑な媒介体は、これらの動作の全てを実行することができる。

第２の実施例においては、媒介体インスタンスは、インバウンド・メッセージを処理し、これに応答して、メッセージング・ネットワークに複数のアウトバウンド・メッセージを導入し、またこれらのアウトバウンド・メッセージをコンシューマに送ることができる。第２の実施例においては、コンシューマ・インスタンスの各々は、いかなるアウトバウンド・メッセージも別のコンシューマに転送することなく、１つ又はそれ以上のアウトバウンド・メッセージを処理する。

非同期式メッセージング・アプリケーションは、プロデューサ、媒介体、及びコンシューマのインスタンスの各々と同一のシステム上で実行動作することが通例である。

第２の実施例においては、プロデューサ（５０５）は２つのインバウンド・メッセージを生成し（ステップ４００）、ここではインバウンド・メッセージは、データベース列に対するデータベース動作（例えば、「挿入」、「更新」、「削除」など）と関連付けられる。

プロデューサ（５０５）は、インバウンド・メッセージの各々に、シーケンス識別子及びシーケンス番号（ここではシーケンス番号は、シーケンス識別子によって識別されたシーケンス内において一意であり、シーケンス番号の値は時間と共に増加する）をタグ付けする（ステップ４０５）。

第２の実施例においては、データベース列は、各々、関連付けられたシーケンス識別子を有する。順序要件は、従って、第１のインバウンド・メッセージに対してはｓ１ｍ１（ここで「ｓ１」はシーケンス識別子であり、「ｍ１」はシーケンス番号であり、「列１を挿入する」がメッセージ・ペイロードである）、第２のインバウンド・メッセージに対してはｓ１ｍ２（ここで「ｓ１」はシーケンス識別子であり、「ｍ２」はシーケンス番号であり、「列１を更新する」がメッセージ・ペイロードである）のように記述でき、ｓ１ｍ１はｓ１ｍ２のシーケンス番号より小さいシーケンス番号をもつことから、ｓ１ｍ２の前に処理されねばならない。

プロデューサ（５０５）は、処理のために第１のインバウンド・メッセージｓ１ｍ１を送信するべく媒介体インスタンスを選択するための選択要素を備える。或いは又、ロード・バランシング技術、可用性要件などに基づき、メッセージング・アプリケーションが媒介体インスタンスを選択してもよい。

第２の実施例においては、プロデューサ（５０５）は、媒介体１（５１０）を選択し、媒介体１（５１０）に関連付けられたキュー（５１５）にｓ１ｍ１を送信する（ステップ４１０）。プロデューサ（５０５）は、ｓ１ｍ１に関連付けられたメッセージ・データをロギングし（ステップ４１５）、第２の実施例においては、シーケンス識別子（即ちｓ１）と送信された最新のインバウンド・メッセージのシーケンス番号（即ちｍ１）がロギングされる。プロデューサ（５０５）はまた、媒介体１（５１０）に関連付けられた媒介体データ（即ち、媒介体１に関連付けられた識別子であり、第２の実施例においては、識別子は「Ｉ１」である）をロギングする（ステップ４１５）。ログの図は、図８の表４に示される。

プロデューサに関連付けられたログは、永続的（即ちディスクに書き込まれるもの）ではないことが好ましい。或いは又、プロデューサに関連付けられたログは永続的（即ちディスクに書き込まれるもの）であってもよい。

プロデューサ（５０５）に関連付けられた並列プロデューサ・スレッドは、ｓ１ｍ１が処理されたという媒介体１（５１０）からの確認応答を待つ（ステップ４５５）。

図６を参照すると、インバウンド・メッセージｓ１ｍ１の受信（ステップ６００）に応答して、媒介体１（５１０）は、２つのアウトバウンド・メッセージを生成する（ステップ６０５）。媒介体１（５１０）は、インバウンド・シーケンス識別子及びそれに関連するインバウンド・シーケンス番号を、アウトバウンド・シーケンス識別子及び少なくとも１つの関連するアウトバウンド・シーケンス番号とマッピングする。

第２の実施例においては、媒介体１（５１０）は、アウトバウンド・メッセージの各々に、インバウンド・シーケンス識別子に関連付けられたアウトバウンド・シーケンス識別子をタグ付けする（ステップ６１０）。或いは又、アウトバウンド・シーケンス識別子は、インバウンド・シーケンス識別子と同一であってもよい。媒介体１（５１０）は、アウトバウンド・メッセージの各々に、インバウンド・シーケンス番号に関連付けられたアウトバウンド・シーケンス番号をタグ付けする（ステップ６１０）。アウトバウンド・シーケンス番号は、アウトバウンド・シーケンス識別子によって識別されたシーケンス内において一意であり、アウトバウンド・シーケンス番号の値は時間と共に増加する。

第２の実施例においては、第１のインバウンド・メッセージｓ１ｍ１に対して、第１のアウトバウンド・メッセージｓ１０ｍ１が生成され（ここで「ｓ１０」はアウトバウンド・シーケンス識別子であり、「ｍ１」はアウトバウンド・シーケンス番号であり、「データベースＡに行く」がメッセージ・ペイロードである）、第２のアウトバウンド・メッセージｓ１０ｍ２が生成される（ここで「ｓ１０」はアウトバウンド・シーケンス識別子であり、「ｍ２」はアウトバウンド・シーケンス番号であり、「列１００を挿入する」がメッセージ・ペイロードである）。ｓ１０ｍ１はｓ１０ｍ２のアウトバウンド・シーケンス番号より小さいアウトバウンド・シーケンス番号をもつことから、ｓ１０ｍ２の前に処理されねばならない。

媒介体１（５１０）は、処理のために第１及び第２のアウトバウンド・メッセージを送信するためのコンシューマ・インスタンスを選択する選択要素を備える。或いは又、ロード・バランシング技術、可用性要件などに基づき、メッセージング・アプリケーションがコンシューマ・インスタンスを選択してもよい。

第２の実施例においては、媒介体１（５１０）は、アウトバウンド・メッセージ（即ちｓ１０ｍ１及びｓ１０ｍ２）を処理するためにコンシューマ１（５３０）を選択し、コンシューマ１（５３０）に関連付けられたキュー（５３５）にｓ１０ｍ１及びｓ１０ｍ２を送信する（ステップ６１５）。

媒介体１（５１０）は、ｓ１ｍ１に関連付けられたメッセージ・データを強制的にロギングする（ステップ６２０）。第２の実施例においては、媒介体１（５１０）は、第１のインバウンド・メッセージのシーケンス識別子（即ちｓ１）と、第１及び第２のアウトバウンド・メッセージのシーケンス識別子（即ちｓ１０）と、送信された最新のインバウンド・メッセージのインバウンド・シーケンス番号（即ちｍ１）と、第１のインバウンド・メッセージを生成したプロデューサに関連するプロデューサデータ（例えば、プロデューサ（５０５に関連付けられた識別子であり、第２の実施例においては、識別子は「Ｐ１」である）と、送信された最新のアウトバウンド・メッセージのアウトバウンド・シーケンス番号（即ちｍ２）と、アウトバウンド・メッセージを処理しているコンシューマに関連付けられたコンシューマ・データ（例えば、コンシューマ１（５３０）に関連付けられた識別子であり、第２の実施例においては、識別子は「Ｃ１」である）をロギングする。ログの図は、図９の表５に示される。

媒介体に関連付けられたログは、媒介体のインスタンスにわたっても永続的である（即ち、ディスクに書込まれる）。このことは、故障の際には、媒介体は、メッセージが処理されること、及びメッセージが正しい順序で処理されることを保証する必要があるからである。

例えば、媒介体が、特定のシーケンス識別子に関連付けられた第１のメッセージを選択されたコンシューマに転送し、その後クラッシュする。コンシューマは、まだ第１のメッセージを処理していない（従って、コンシューマはまだ確認応答を送信していない）。媒介体が回復し、次いで特定のシーケンス識別子に関連付けられた第２のメッセージを受信する。コンシューマはまだ第１のメッセージの処理を確認応答していないので、媒介体は、第２のメッセージを同じ選択されたコンシューマに転送しなければならない（その選択は、媒介体の先行するインスタンスの間に成されたものではあるが）。ログは、媒介体のインスタンスにわたって、選択動作に関連付けられたデータを格納するために用いられる。

媒介体は、再実行した時に、（上述されたように再実行に際して新規のシーケンス識別子を使用できるプロデューサとは異なり）新規のシーケンス識別子を使用しない。

並列媒介体スレッドは、ｓ１０ｍ１及びｓ１０ｍ２が処理されたというコンシューマ１（５３０）からの確認応答を待つ（ステップ６６５）。

図４を参照すると、第２の実施例においては、並列プロデューサ・スレッドが、ｓ１ｍ１が処理されたという媒介体１（５１０）からの確認応答待ちをしている間に、プロデューサ（５０５）は、第１のインバウンド・メッセージと合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかのインバウンド・メッセージが存在するかどうかを判断する（ステップ４２５）。処理のために送信されるべきそれ以上のインバウンド・メッセージが存在しないとの判断に応答して、並列プロデューサ・スレッドは、ｓ１ｍ１が処理されたという媒介体１（５１０）からの確認応答待ちを続行する（４５５）。

第２の実施例においては、プロデューサ（５０５）は、処理のために送信されるべき更なるインバウンド・メッセージ（即ち第２のインバウンド・メッセージｓ１ｍ２）が存在すると判断し、よって、処理のために送信されるべき更なるインバウンド・メッセージが存在するという判断に応答して、プロデューサ（５０５）は、第２のインバウンド・メッセージに関連付けられたシーケンス識別子（即ちｓ１）を判断する。プロデューサ（５０５）はシーケンス識別子を用いて、ログをチェックし（ステップ４３０）、合致するシーケンス識別子をもった記録があるか否かを判断する（ステップ４３５）。合致するシーケンス識別子をもった記録が存在しないという判断に応答して、プロデューサ（５０５）は、更なるメッセージをコンシューマに送信する（ステップ４１０）。

第２の実施例においては、プロデューサ（５０５）は、合致するシーケンス識別子をもった記録（即ち表４においてシーケンス識別子「ｓ１」をもつ記録）が存在すると判断し、従って、合致するシーケンス識別子をもった記録が存在するという判断に応答して、プロデューサ（５０５）は関連付けられた媒介体データ（即ち「Ｉ１」）を判断する（ステップ４４０）。並列プロデューサ・スレッドはｓ１ｍ１が処理されたという媒介体１（５１０）からの確認応答を待っているのであるから、ログ記録はまだパージされておらず、故に、プロデューサ（５０５）は、合致するシーケンス識別子をもったログ記録がログの中に存在すると判断していることに注意されたい。

プロデューサ（５０５）は、次いで、ｓ１ｍ２を、判断された媒介体データに関連付けられた媒介体のキュー（即ち媒介体１（５１０）に関連付けられたキュー（５１５））に送信する（ステップ４４５）。ここでｓ１ｍ１は、第２のインバウンド・メッセージｓ１ｍ２と同じシーケンス識別子をもっており、媒介体１（５１０）は、第１のインバウンド・メッセージｓ１ｍ１を処理したのと同じ媒介体インスタンスであると理解されるべきである。

プロデューサ（５０５）は、ｓ１ｍ２に関連付けられたメッセージ・データをロギングする（ステップ４５０）。第２の実施例においては、表４に表されたシーケンス識別子フィールド中のデータ（即ちｓ１）は同じままであり、ｍ２は送信された最新のインバウンド・メッセージのシーケンス番号であることから、シーケンス番号フィールド中のデータは上書きされ（即ち、ｍ１はｍ２で上書きされる）、表４に表された媒介体識別子フィールド中のデータ（即ちＩ１）は同じままである。更新されたプロデューサ・ログの図は図８の表６に示される。

データのロギング（ステップ４５０）に応答して、プロデューサ（５０５）は、第１のインバウンド・メッセージと合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかのインバウンド・メッセージが存在するかどうかを判断する（ステップ４２５）。第２の実施例においては、プロデューサ（５０５）は、処理のために送信されるべきそれ以上のインバウンド・メッセージが存在しないと判断し、並列プロデューサ・スレッドは、ｓ１ｍ１及びｓ１ｍ２が処理されたという媒介体１（５１０）からの確認応答待ちを続行する（ステップ４５５）。

図６を参照すると、並列媒介体スレッドが、ｓ１０ｍ１及びｓ１０ｍ２が処理されたというコンシューマ１（５３０）からの確認応答待ちをしている間に、媒介体１（５１０）は、第１のインバウンド・メッセージと合致するシーケンス識別子（即ちｓ１ｍ１）をもつ、処理のために送信されるべきそれ以上のいずれかのインバウンド・メッセージが存在するかどうかを判断する（ステップ６２５）。処理のために送信されるべきそれ以上のインバウンド・メッセージが存在しないとの判断に応答して、並列媒介体スレッドは、ｓ１０ｍ１及びｓ１０ｍ２が処理されたというコンシューマ１（５３０）からの確認応答待ちを続行する（ステップ６３０）。

第２の実施例においては、媒介体１（５１０）は、処理のために送信されるべき更なるインバウンド・メッセージ（即ち第２のインバウンド・メッセージｓ１ｍ２）がキュー（５１５）に存在すると判断する。よって、処理のために送信されるべき更なるインバウンド・メッセージが存在するという判断に応答して、媒介体１（５１０）は、第２のインバウンド・メッセージに関連付けられたシーケンス識別子（即ちｓ１）を判断する。媒介体１（５１０）は、このシーケンス識別子を用いてログをチェックし（ステップ６３０）、合致するシーケンス識別子をもった記録があるか否かを判断する（ステップ６３５）。合致するシーケンス識別子をもった記録が存在しないという判断に応答して、媒介体１（５１０）は、更なるインバウンド・メッセージをコンシューマに送信する（ステップ６１５）。

第２の実施例においては、媒介体１（５１０）は、合致するシーケンス識別子をもった記録（即ち表５においてシーケンス識別子「ｓ１」をもった記録）が存在すると判断し、従って、合致するシーケンス識別子をもった記録が存在するという判断に応答して、媒介体１（５１０）は、関連付けられたコンシューマ・データ（即ち「Ｃ１」）を判断する（ステップ６４０）。

並列媒介体スレッドはｓ１０ｍ１及びｓ１０ｍ２が処理されたというコンシューマ１（５３０）からの確認応答を待っているのであるから、ログ記録はまだパージされておらず、故に、媒介体１（５１０）は、合致するシーケンス識別子をもったログ記録がログの中に存在すると判断することに注意されたい。

ｓ１ｍ２の受信に応答して、媒介体１（５１０）は、２つのアウトバウンド・メッセージを生成する（ステップ６４５）。媒介体１（５１０）は、インバウンド・シーケンス識別子及びそれに関連付けられたインバウンド・シーケンス番号を、アウトバウンド・シーケンス識別子及び少なくとも１つの関連付けられたアウトバウンド・シーケンス番号とマッピングする。

第１の実施例においては、媒介体１（５１０）は、アウトバウンド・メッセージの各々に、インバウンド・シーケンス識別子に関連付けられたアウトバウンド・シーケンス識別子及びインバウンド・シーケンス番号に関連付けられたアウトバウンド・シーケンス番号をタグ付けする（ステップ６５０）。アウトバウンド・シーケンス番号は、アウトバウンド・シーケンス識別子によって識別されたシーケンス内において一意であり、アウトバウンド・シーケンス番号の値は時間と共に増加する。

第２の実施例においては、第２のインバウンド・メッセージｓ１ｍ２に対して、第３のアウトバウンド・メッセージｓ１０ｍ３が生成され（ここで「ｓ１０」はシーケンス識別子であり、「ｍ３」はシーケンス番号であり、「データベースＢに行く」がメッセージ・ペイロードである）、第４の更なるメッセージｓ１０ｍ４が生成される（ここで「ｓ１０」はシーケンス識別子であり、「ｍ４」はシーケンス番号であり、「列７５を更新する」がメッセージ・ペイロードである）。ｓ１０ｍ３はｓ１０ｍ４のシーケンス番号より小さいシーケンス番号をもつことから、ｓ１０ｍ４の前に処理されねばならない。さらにまた、順序を保存するために、第２のインバウンド・メッセージに関連付けられた第３のアウトバウンド・メッセージのシーケンス番号の値（即ちｓ１０ｍ３の３）は、第１のインバウンド・メッセージに関連付けられた第２のアウトバウンド・メッセージのシーケンス番号の値（即ちｓ１０ｍ２の２）より大きくなければならない。

次いで、媒介体１（５１０）は、ｓ１０ｍ３及びｓ１０ｍ４を、判断されたコンシューマ・データに関連付けられたコンシューマのキュー（即ち、コンシューマ１（５３０）に関連付けられたキュー（５３５））に送信する（ステップ６５５）。コンシューマ１（５３０）は、第１及び第２のアウトバウンド・メッセージ（即ちｓ１０ｍ１及びｓ１０ｍ２）を処理したのと同じコンシューマ・インスタンスであり、ここでｓ１０ｍ１及びｓ１０ｍ２は、第３のアウトバウンド・メッセージｓ１０ｍ３及び第４のアウトバウンド・メッセージｓ１０ｍ４と同じシーケンス識別子をもっていることが理解されるべきである。

媒介体１（５１０）は、ｓ１ｍ２に関連付けられたメッセージ・データを強制的にロギングする（ステップ６６０）。第２の実施例においては、媒介体１（５１０）は、第２のインバウンド・メッセージのシーケンス識別子（即ちｓ１）と、第３及び第４のアウトバウンド・メッセージのシーケンス識別子（即ちｓ１０）と、送信された最新のインバウンド・メッセージのインバウンド・シーケンス番号（即ちｍ２）と、第２のインバウンド・メッセージを生成したプロデューサに関連するプロデューサデータ（例えば、プロデューサ（５０５に関連付けられた識別子であり、第２の実施例においては、識別子は「Ｐ１」である）と、送信された最新のアウトバウンド・メッセージのアウトバウンド・シーケンス番号（即ちｍ４）と、アウトバウンド・メッセージを処理しているコンシューマに関連付けられたコンシューマ・データ（例えば、コンシューマ１（５３０）に関連付けられた識別子であり、第２の実施例においては、識別子は「Ｃ１」である）をロギングする。ログの図は、図９の表７に示される。

データのロギング（ステップ６６０）に応答して、媒介体１（５１０）は、第１のインバウンド・メッセージ（即ちｓ１ｍ１）と合致するシーケンス識別子をもつ、処理のために送信されるべきそれ以上のいずれかの更なるメッセージが存在するかどうかを判断する（ステップ６２５）。第２の実施例においては、媒介体１（５１０）は、処理のために送信されるべきそれ以上のメッセージが存在しないと判断し、並列媒介体スレッドは、ｓ１０ｍ１、ｓ１０ｍ２、ｓ１０ｍ３、及びｓ１０ｍ４が処理されたというコンシューマ１（５３０）からの確認応答待ちを続行する（ステップ６６５）。

第２の実施例においては、コンシューマ１（５３０）は、ｓ１０ｍ１、ｓ１０ｍ２、ｓ１０ｍ３、及びｓ１０ｍ４を処理する（ここで処理する順序は、メッセージがキュー（５３５）に到着した順序によって指定される）。ｓ１０ｍ４が処理された後で、コンシューマ１（５３０）は、確認応答を生成して並列媒介体スレッドに送信し、ｓ１０ｍ４が処理されたことを確認応答する。第２の実施例においては特定のシーケンス番号をもつメッセージに関する確認応答は、より小さいシーケンス番号をもつ全てのメッセージを確認応答する役目も果たすことから、この確認応答は、ｓ１０ｍ１、ｓ１０ｍ２、及びｓ１０ｍ３が処理されたことの確認応答でもある。代替的に、コンシューマ・インスタンスに代わり、メッセージング・アプリケーションが、確認応答を生成し送信してもよいと理解されるべきである。

並列媒介体スレッドは、いずれかの確認応答が受信されたか否かの判断を行う（ステップ６７０）。いかなる確認応答も受信されない場合には、生成機構がアラートを生成する（ステップ６９５）。

第２の実施例においては、並列媒介体スレッドは、確認応答が受信されたという判断を行う（例えば、並列媒介体スレッドは、予め定められた時間の間、確認応答を待つことができる）（ステップ６７０）。

確認応答の受信に応答して、並列媒介体スレッドは、ログをチェックし（ステップ６７５）、１つ又はそれ以上のインバウンド・メッセージが処理されたことを確認応答する確認応答が、プロデューサ（５０５）に送信されても良いか否かを判断する（ステップ６８０）。

即ち、並列媒介体スレッドは、確認応答内のシーケンス識別子及び関連付けられたシーケンス番号を、ログ記録内のシーケンス識別子データ及び関連付けられたシーケンス番号データと比較する。比較することに応答して、並列媒介体スレッドが、送信された特定のシーケンス識別子に関連付けられた未処理のアウトバウンド・メッセージの各々について、確認応答が受信されていないと判断した場合には、生成機構がアラートを生成する（ステップ６９５）。

第２の実施例においては、並列媒介体スレッドは、ｓ１０ｍ４に関する確認応答を、（表７に表された）ログに対して比較する。確認応答のシーケンス識別子は、ログ記録内のアウトバウンド・シーケンス識別子データに合致する。確認応答のシーケンス番号は、ログ記録内の最新のアウトバウンド・シーケンス番号データに合致し、よって、確認応答がｍ４の４より小さいシーケンス番号をもった全てのメッセージの処理も確認応答することから、確認応答はまた、ｓ１０ｍ１、ｓ１０ｍ２、及びｓ１０ｍ３の処理も確認応答する。

よって、比較することに応答して、並列媒介体スレッドは、送信された特定のシーケンス識別子に関連付けられた未処理のアウトバウンド・メッセージの各々に関する確認応答が受信されたと判断する。よって、並列媒介体スレッドは、プロデューサ（５０５）によって生成された関連する第１のインバウンド・メッセージ即ちｓ１ｍ１及び第２のインバウンド・メッセージ即ちｓ１ｍ２に関する確認応答を生成する（ステップ６８５）。具体的には、並列媒介体スレッドは、ｓ１ｍ２に関する確認応答（これは、ｍ２の２より小さいシーケンス番号をもった全てのメッセージの処理も確認応答する役目を果たし、従って、この確認応答はまた、ｓ１ｍ１の処理も確認応答する）を生成する（ステップ６８５）。

並列媒介体スレッドは、プロデューサ（５０５）に確認応答を送信する（ステップ６８５）。代替的に、媒介体インスタンスに代わり、メッセージング・アプリケーションが確認応答を生成し送信してもよいと理解されるべきである。

送信された特定のシーケンス識別子に関連付けられた未処理のアウトバウンド・メッセージの各々に関連する確認応答が受信されたのであるから、並列媒介体スレッドは、処理済みのアウトバウンド・メッセージのシーケンス識別子に関連するログ記録（即ちｓ１０ｍ４に関連付けられた（従ってｓ１０ｍ１、ｓ１０ｍ２、及びｓ１０ｍ３ｉに関連付けられた）表７のログ記録）をパージする（ステップ６９０）。よって、媒介体は、それがいずれかの与えられたシーケンスに関するコンシューマを選択済みであることを「忘却」することができる。その後、媒介体は、次にそのシーケンスの中にメッセージを見た時には、新規のコンシューマ・インスタンスを選択することができる。

図４を参照すると、並列プロデューサ・スレッドは、いずれかの確認応答が受信されたか否かの判断を行う（ステップ４６０）。いかなる確認応答も受信されない場合には、生成機構がアラートを生成する（ステップ４７０）。

第２の実施例においては、並列プロデューサ・スレッドは、確認応答が受信されたという判断を行う（ステップ４６０）。確認応答の受信に応答して、並列プロデューサ・スレッドは、上述されたように、ログをチェックし（ステップ４６５）、プロデューサ（３０５）が、シーケンス識別子に関連付けられた未処理のメッセージに関連するログ記録を「忘却」して良いか否かを判断する（ステップ４７５）。

第２の実施例においては、ｓ１ｍ２に関する（従ってｓ１ｍ１に関する）確認応答は、（表６に表された）ログに対して比較される。確認応答のシーケンス識別子は、ログ記録内のシーケンス識別子データに合致する。確認応答のシーケンス番号は、ログ記録内の最新のシーケンス番号データに合致し、よって、確認応答がｍ２の２より小さいシーケンス番号をもった全てのメッセージの処理も確認応答することから、確認応答はまた、ｍ１の処理も確認応答する（即ち、ｍ１が２より小さいシーケンス番号１）。

よって、並列プロデューサ・スレッドは、処理済みのメッセージのシーケンス識別子に関連付けられたログ記録（即ち、ｓ１ｍ２に関連付けられた（従ってｓ１ｍ１に関連付けられた）表６のログ記録）をパージする（ステップ４８０）。

よって、プロデューサは、システム内の同じシーケンス識別子をもつ未処理のメッセージを、全て、同じ媒介体インスタンスに送信するように設定可能である。単一の媒介体が、それに関連付けられたキューに到着する順序でメッセージを処理するのであるから、このことは、シーケンス内において順序が保存されることを可能にする。さらにまた、同じ媒介体インスタンス（即ちＩ１）に送信された、同じシーケンス識別子（即ちｓ１）をもつ未処理のメッセージの各々（即ちｍ１、ｍ２）に関する確認応答が受信された時にのみ、プロデューサは、それがいずれかの与えられたシーケンスのための媒介体を既に選択済みであることを「忘却」することができる。その後、プロデューサ（５０５）は、次にそのシーケンスの中にメッセージを見た時には、新規の媒介体インスタンスを選択することができる。

このことは媒介体にもあてはまり、媒介体は、システム内の同じシーケンス識別子をもつ未処理のアウトバウンド・メッセージを全て、同じコンシューマ・インスタンスに送信するように設定可能である。さらにまた、同じコンシューマ・インスタンス（即ちＣ１）に送信された、同じシーケンス識別子（即ちｓ１０）をもつ未処理のアウトバウンド・メッセージの各々（即ちｍ１、ｍ２、ｍ３、及びｍ４）に関する確認応答が受信された時にのみ、媒介体は、それがいずれかの与えられたシーケンスに関するコンシューマを既に選択済みであることを「忘却」することができる。その後、媒介体は、次にそのシーケンスの中にメッセージを見た時には、新規のコンシューマ・インスタンスを選択することができる。

コンシューマとの関連で上述された確認応答の生成及び受信の最適化は、媒介体についてもあてはまることが理解されるべきである。

本発明はまた、複数のコンシューマ・インスタンス又は複数の媒介体インスタンスが単一の物理コンピュータ・システム上に常駐するシステムにおいても、利用可能であることが理解されるべきである。このようなシステムは、処理がメモリ内で起こることから、通信がより高速であるという利点がある。この実施例においては、ディスパッチャが、シーケンス識別子に関連付けられたメッセージを送る相手であるメモリ内のコンシューマ・インスタンス又は媒介体インスタンスを選択することができ、メッセージ・データ及びコンシューマ・データ又は媒介体データをロギングすることができ、コンシューマ・インスタンス又は媒介体インスタンスからの確認応答を受信することができる。ディスパッチャは、コンシューマ・インスタンス又は媒介体インスタンスと同じ物理コンピュータ・システム上に常駐してもよく、又は異なる物理コンピュータ・システム上に常駐してもよいことが理解されるべきである。

本発明は、複数の媒介体（クラスター）に規模拡大が可能であることが理解されるべきである。例えば、第１の媒介体クラスターは、メッセージを変換し、そのメッセージを第２の媒介体クラスターに送信することができる。第２の媒介体クラスターは、そのメッセージに関連付けられたデータをロギングし、そのメッセージをコンシューマに伝送することができる。

プロデューサ及び単一のコンシューマ・インスタンスのブロック図である。 プロデューサ及び複数のコンシューマ・インスタンスのブロック図である。 プロデューサ及び複数のコンシューマ・インスタンスのより詳細なブロック図である。 プロデューサによって実行されるプロセスに関わる動作ステップを示すフローチャートである。 プロデューサ、複数の媒介体インスタンス、及び複数のコンシューマ・インスタンスのブロック図である。 媒介体によって実行されるプロセスに関わる動作ステップを示すフローチャートである。 プロデューサのログの図である。 プロデューサのログの図である。 媒介体のログの図である。

符号の説明

３０５：プロデューサ
３１５：キュー
３１０：コンシューマ１
３２５：キュー
３２０：コンシューマ２

Claims (14)

1. メッセージがそれに関連付けられた順序識別子を備え、受信機構が第１の順序識別子に関連付けられた第１のメッセージを受信するように動作可能であり、選択要素が前記第１のメッセージを処理するために第１のエンティティを選択するように動作可能である環境で使用するための、メッセージに関連付けられた順序を保存するためのシステムであって、
   前記第１のメッセージの処理の完了に関連付けられた通知が前記受信機構によって受信されたか否かを判断するための判断要素と、
   前記通知の受信と、前記通知の前記受信に続いて前記受信機構により受信された前記第１の識別子に関連付けられた第２のメッセージの受信との組み合わせに応答して、前記第２のメッセージを処理するために第２のエンティティを選択するように前記選択要素を制御するコントローラと、
   を備えるシステム。
2. メッセージに関連付けられたデータとエンティティに関連付けられたデータとをストレージ要素内でロギングするためのロギング要素を更に備えた、請求項１に記載のシステム。
3. 前記ストレージ要素が永続的である、請求項２に記載のシステム。
4. 前記ストレージ要素が非永続的である、請求項２に記載のシステム。
5. 前記通知の受信に応答して、前記ストレージ要素内のデータがパージされる、請求項２から請求項４のいずれか１項に記載のシステム。
6. 前記第１のエンティティが、処理のために前記第１のメッセージを第３のエンティティに転送するように動作可能であり、且つ、前記第１のメッセージに関連付けられたデータと前記第３のエンティティに関連付けられたデータとをロギングするように動作可能である、請求項１から請求項５のいずれか１項に記載のシステム。
7. 前記第１のエンティティが、前記第３のエンティティから前記第１のメッセージの処理の完了に関連付けられた別の通知を受信することに応答して前記通知を生成するように動作可能である、請求項６に記載のシステム。
8. 順序識別子を生成するための生成機構を更に備えた、請求項１から請求項７のいずれか１項に記載のシステム。
9. 前記通知が複数のメッセージの処理の完了に関連付けられる、請求項１から請求項８のいずれか１項に記載のシステム。
10. 前記通知が、前記システムに関連付けられたパラメータに従って送信される、請求項１から請求項９のいずれか１項に記載のシステム。
11. 前記通知が非永続的である、請求項１から請求項１０のいずれか１項に記載のシステム。
12. 前記コントローラが、前記通知の受信に先立ち前記受信機構により受信された前記第１の識別子に関連付けられた第３のメッセージに応答して、前記第３のメッセージを処理するために第１のエンティティを選択する前記選択要素を制御するように動作可能である、請求項１から請求項１１のいずれか１項に記載のシステム。
13. メッセージがそれに関連付けられた順序識別子を備え、受信機構が第１の順序識別子に関連付けられた第１のメッセージを受信するように動作可能であり、選択要素が前記第１のメッセージを処理するために第１のエンティティを選択するように動作可能である環境で使用するための、メッセージに関連付けられた順序を保存する方法であって、
    前記第１のメッセージの処理の完了に関連付けられた通知が前記受信機構によって受信されたか否かを判断するステップと、
    前記通知の受信と、前記通知の前記受信に続いて前記受信機構により受信された前記第１の識別子に関連付けられた第２のメッセージの受信との組み合わせに応答して、前記第２のメッセージを処理するために第２のエンティティを選択するように前記選択要素を制御するステップと、
    を含む方法。
14. コンピュータに請求項１３から請求項２４のいずれか１項に記載のステップを実行させるためのコンピュータ・プログラム。

Images