JP2011511976A - メッセージング・ネットワークにおけるメッセージ配布の方法、システム、装置およびコンピュータ・プログラム - Google Patents

Abstract

【課題】メッセージング・ネットワークにおけるメッセージ配布の方法およびシステムを提供する。
【解決手段】本発明のシステムは消費される前にアプリケーションにより識別可能なメッセージのための複製キュー４５１を提供する。複製キュー４５１は複数のメッセージ管理システム４１１ないし４１３上に定義される。複数のメッセージ管理システム４１１ないし４１３のうちの任意の一つを介してアクセス可能な複数の複製キュー４５１の各々にメッセージが送られる。本発明の方法は一意的な識別子を含むメッセージを生成し、複数の複製キュー４５１の各々に前記メッセージを書き込む。なお、前記メッセージはメッセージを読む前にその一意的な識別子により識別可能である。
【選択図】図６

Description

本発明はメッセージング・ネットワークにおけるメッセージ配布の技術分野に関し、特にコンシューマー(consumer)により消費される(consumed)前に一意的に識別され得るメッセージの配布に関する。

消費される前に一意的に識別され得るメッセージの例はリクエスト／応答システムにおける応答メッセージである。メッセージング・ネットワークの中では、リクエスト・システムがリクエストを送り、応答を受ける。そして応答システムがリクエストを受け、応答を送る。

リクエスト・システムが接続する複数のメッセージ管理システムを提供することにより、かつリクエスト・システム接続を利用することが可能なメッセージ管理システムにルート付けするワークロード・バランシング機構を用いることによって、或るレベルの高い可用性がメッセージング・ネットワークのフロントエンドで達成されることができる。応答システムが接続することができる複数のメッセージ管理システムを提供することにより、かつリクエスト・メッセージを、利用可能なバックエンド・メッセージ管理システムにルート付けするフロントエンド上のワークロード・バランシング機構を用いることによってバックエンドももっと利用されやすくなる。リクエストは、フロントエンドもしくはバックエンドのメッセージング管理システムが利用できない場合でさえ処理され続けることができる。

全般的な問題は、親和性（affinities）が存在するときの応答のルート付けに関連する可用性の課題である。応答はバックエンド・メッセージング管理システムによって特定のフロントエンド・メッセージング管理システムに典型的にはルート付けされ、ワークロードはバランスされない。ここで使用されるフロントエンド・メッセージング管理システムは、ここを介して対応するリクエスト・メッセージが送られるものである。これはリクエスト・システムがリクエストを典型的には送り、その同じメッセージング管理システムに、リクエスト・システムがその対応する応答を受け取るまで接続され続けるからである。その応答とフロントエンド・メッセージング管理システムとの間に親和性が生まれる。これは、リクエスト・システムのワーク（リクエストを送り、応答を受け取る）を完遂することがそのリクエストを送ったメッセージング管理システムの連続する可用性に依存するが故に、フロントエンドでの応答の可用性に対する問題を生じる。もしメッセージング管理システムが、リクエストがバックエンドにルート付けされた後その応答がフロントエンドにルート付けされる前に障害が起こるなら、その応答はそのフロントエンドのメッセージング管理システムが利用可能になるまでバックエンドで保持される。

もしリクエスト・システムがフロントエンド・メッセージング管理システムからそれがリクエストを送った後で応答を受け取る前に接続を切ったり接続を切られたりしたら問題がある。リクエスト・システムの接続はワークロード的にバランスされる。従って、リクエスト・システムが（応答を受け取るために）再接続するとき、その接続はそれが元々接続されていたのとは別のフロントエンド・メッセージング管理システムに接続されてワークロードのバランスをとることがあり得る。この結果、正しいフロントエンド・メッセージング管理システムに再接続されるまで、その応答がリクエスト・システムには利用できない状況が生じる。

この問題に対する既知の解決策の一つはリクエスト・システムのためにそれらの状態次第で別個の接続論理を使用することである。リクエストを送る前に、その接続はワークロードのバランスをとり、リクエストを送った後その応答を受け取る前はワークロードのバランスをとらないが、リクエスト・システムが親和性を有するメッセージング管理システムにその接続がなされる。

本発明の第１の側面によれば、メッセージング・ネットワークにおけるメッセージ配布方法であって、一意的な識別子を含むメッセージを生成するステップと、複数個の複製キューの各々に前記メッセージを送るステップとを含み、前記メッセージは消費される前に前記一意的な識別子により識別可能である、メッセージ配布方法が提供される。

本発明の第２の側面によれば、メッセージング・ネットワークにおけるメッセージ配布システムであって、１個または複数個のプロセッサ上に提供される複数個のメッセージ管理システムを含むメッセージング・ネットワークと、前記メッセージが読み出される前にアプリケーションにより識別されるように動作可能なメッセージのための複製キューであって、複数個のメッセージ管理システム上で定義可能な前記複製キューとを含み、複数個のメッセージ管理システムのうちのいずれか一つを用いてアクセス可能である複数個の複製キューの各々にメッセージが送られるところのメッセージ配布システムが提供される。

本発明の第３の側面によれば、メッセージング・ネットワークにおけるメッセージ配布のためにコンピュータ読取り可能なストレージ媒体上にストアされたコンピュータ・プログラムであって、一意的な識別子を含むメッセージを生成するステップと、前記メッセージを複数個の複製キューの各々に送るステップとを実行するコンピュータ読取り可能なプログラム・コード手段を含み、応答メッセージは消費される前に前記一意的な識別子により識別可能にされているような、コンピュータ・プログラムが提供される。

この解決策には２つのキーとなる部分がある。

１）特定のフロントエンド・メッセージング管理システムに一つの応答が送られる代わりに、全てのフロントエンド・メッセージング管理システムに応答が送られるように応答が複製される。

２）リクエスト・システムが応答メッセージを受け取るために任意のフロントエンド管理システムに接続することができる。他のフロントエンド・メッセージング管理システム上の応答メッセージは自動的に削除される。

本発明の目的は、リクエスト・システムがリクエストを送った同じメッセージング管理システムからの応答を受け取る必要性を無くすことによってリクエスト・システムへの応答の可用性を増すことにある。本発明はまたリクエスト・システムにおける別個の接続論理の必要性を無くして、それらがそのリクエスト・システムの状態に拘わらず、利用可能なメッセージ管理システムに対しワークロードのバランスをとることを、そして任意のフロントエンド・メッセージング管理システムで応答を受け取ることを許容する。

本発明とみなされる主題が詳しく指摘され、特許請求の範囲として明示されている。本発明は構成、動作方法の両方についてその目的、特徴および効果もともに、以下の詳細な記述を添付図面とともに参照して読むときもっともよく理解され得る。

従来技術で知られたようなメッセージング・システムの概略図である。 本発明が実施され得るコンピュータ・システムのブロック図である。 本発明のいろいろな側面による処理のフローチャートである。 本発明のいろいろな側面による処理のフローチャートである。 本発明のいろいろな側面による処理のフローチャートである。 本発明によるシステムのブロック図である。 本発明によるメッセージ・フローを示すシステムの実施例のブロック図である。

説明の簡潔さおよび明瞭さのため、図に示す要素は必ずしも縮尺比が正確ではないことを理解されたい。例えば、幾つかの要素の寸法は明瞭さのために他の要素に対し誇張されているかもしれない。更に、適切と考えられる場合は、対応する特徴または類似の特徴を示すために図相互間で参照番号が反復されることもある。

以下の詳細な説明では、本発明の完全な理解を提供するために幾多の特定の詳細が開示されている。しかし、本発明がこれらの詳細がなくても実施され得ることが当業者には理解できよう。他の例では、周知の方法、手順およびコンポーネントが、本発明を不明瞭にしないために詳細には説明されていない。

図１には、メッセージング・ネットワーク・システム１００が従来技術で知られたものとして示されている。メッセージング・ネットワーク・システム１００の中では、リクエスト・システム１０１ないし１０３（リクエストを送り、応答を受ける）および応答システム１０４ないし１０６（リクエストを受け、応答を送る）が、別のメッセージ管理システム１１１ないし１１３、１２１ないし１２３に接続されていてもよい。メッセージング・ネットワーク・システム１００はフロントエンドのメッセージ管理システム１１１ないし１１３をリクエスト・システム１０１ないし１０３の接続のために用い、バックエンドのメッセージ管理システム１２１ないし１２３を応答システム１０４ないし１０６のために用いる。メッセージ管理システム１１１ないし１１３，１２１ないし１２３は、例えばキュー・マネジャであってもよい。

或るレベルの高い可用性がメッセージング・ネットワークのフロントエンドで達成されることができる。これはリクエスト・システム１０１ないし１０３が接続することができる幾つかのフロントエンドのメッセージ管理システム１１１ないし１１３を提供し、かつリクエスト・システムの接続を利用可能なメッセージ管理システム１１１ないし１１３にルート付けするワークロード・バランシング機構１３１（例えば、ＩＰロード・バランサまたはメッセージング管理システム機能）を用いることにより達成されることができる。例えば、図１ではチャネル１３２がリクエスト・システム１０２から（ワークロード・バランシングにより選択された）メッセージング管理システム１１２にでき、そこを通じてメッセージが流れるように示されている。

応答システム１０４ないし１０６が接続することができる幾つかのメッセージ管理システム１２１ないし１２３を提供することによってバックエンドがもっと利用することができるようになる。フロントエンド・メッセージ管理システム１１１ないし１１３上のワークロード・バランシング機構１３３がリクエストを、利用可能なバックエンド・メッセージング管理システム１２１ないし１２３にルート付けする。例えば、図１はバックエンド１２３に参照番号１３４で示すようにルート付けられたリクエストと、フロントエンド１１２に参照番号１３５で示すようにルート付けされた応答を示す。

メッセージング・ネットワーク・システム１００は、リクエスト・システム１０１から応答システム１２３にフロントエンドないしバックエンドのメッセージ管理システムの１１１ないし１１３、１２１ないし１２３を介して、その１個もしくは複数個のフロントエンドもしくはバックエンドのメッセージング管理システムが利用できないとしても、リクエストを送ることによって、リクエストを処理し続けることができる。

図２を参照すると、メッセージング管理システムが実装されていてもよい実施例のシステムは、バス・システム２０３を介してメモリ・エレメントに直接的にまたは間接的に結合された少なくとも１個のプロセッサ２０１を含むプログラム・コードをストアしおよび／もしくは実行するのに適するデータ処理システム２００を含む。そのメモリ・エレメントは、そのプログラム・コードの実際の実行中に用いられるローカル・メモリ、大容量記憶装置およびキャッシュ・メモリを含むことができる。そのキャッシュ・メモリは実行中に大容量記憶装置からプログラム・コードが取出されなければならない回数を少なくするために少なくとも幾つかのプログラム・コードの一時的なストレージを提供する。

このメモリ・エレメントはシステム・メモリ２０２を読取専用メモリ（ＲＯＭ）２０４およびランダム・アクセス・メモリ（ＲＡＭ）２０５の形態で含むことができる。基本入出力システム（ＢＩＯＳ）２０６がＲＯＭ２０４にストアされていてもよい。システム・ソフトウエア２０７がＲＡＭ２０５にストアされ、オペレーティング・システム（ＯＳ）ソフトウエア２０８を含んでいてもよい。ＲＡＭ２０５にはソフトウエア・アプリケーション２１０もまた含まれていてもよい。

システム２００はまた磁気ハードディスク・ドライブのような１次ストレージ手段２１１および磁気ディスク・ドライブおよび光ディスク・ドライブのような２次ストレージ手段２１２を含んでもよい。これらのドライブおよびその関連するコンピュータ読取り可能な媒体がシステム２００のためにコンピュータ実行可能な命令、データ構造、プログラム・モジュールおよび他のデータの不揮発性ストレージを提供する。ソフトウエア・アプリケーションはまた１次ストレージ手段２１１、２次ストレージ手段２１２およびシステム・メモリ２０２にストアされていてもよい。

コンピューティング・システム２００は、１個もしくは複数個の遠隔コンピュータへのネットワーク・アダプタ２１６を介しての論理接続を用いて、ネットワーク環境で動作してもよい。

入出力装置２１３は、直接的にまたは介在するＩ／Ｏコントローラを介してそのシステムに結合され得る。ユーザーはコマンドおよび情報をキーボード、ポインティング装置または他の入力装置（例えば、マイクロフォン、ジョイスティック、ゲーム・パッド、サテライト・ディッシュ（パラボラ・アンテナ）、スキャナー等）などの入力装置を介してシステム２００に入力してもよい。出力装置がスピーカー、プリンタ等を含んでもよい。ディスプレイ装置２１４もシステム・バス２０３にビデオ・アダプタ２１５などのインターフェースを介して接続されてもよい。

メッセージング管理システムはまたレジストリを定義するプログラム、メッセージング管理システム定義、およびローカル・デフォールト・キュー定義を含む。

ここに記述された方法およびシステムでは、特別のタイプのキューが提供され、これがメッセージを保持するのに使用される。このキューは、複製されたキューすなわち複製キュー（replicated queue、ＲＱ）と呼ばれる。ＲＱはコンシューマーがメッセージ（例えば、特有の識別子を備えた応答メッセージ）を受取ってしまう前にコンシューマーによって一意的に識別され得るメッセージ用に設計される。

ＲＱは複数のメッセージ管理システム上で各メッセージング管理システム上の手動の定義、または一つの手動の定義および他の管理システム上で定義を複製するための自動定義メカニズムのいずれかを用いて定義される。自動定義メカニズムを用いると、ＲＱの動的生成（例えば、アプリケーションの挙動に応答して定義されるもの）をよりよくサポートする。メッセージング・ネットワークにおけるメッセージング管理システムはメッセージング・ネットワークにおけるＲＱを自動的に気付くようにさせられる。

メッセージがＲＱに送られるとき（例えば応答メッセージ）、それは一意的な識別子を持たねばならない。この一意的な識別子はアプリケーションまたはメッセージング管理システムによって特定され得る。メッセージング管理システムまたはアプリケーションのいずれかがメッセージを複製し、その結果、ＲＱをホストするメッセージング・ネットワークにおける全てのメッセージング管理システムがコピーを受け取る。この複製されたメッセージが任意のメッセージング技法を用いて送られる。

ＲＱをホストする各メッセージング管理システムは複製されたメッセージのコピーを受け取る。アプリケーションは、一意的な識別子によって識別され、ＲＱをホストするいずれかのメッセージング管理システムに接続することができる。

アプリケーションが複製されたメッセージのうちの一つを一旦消費してしまうと、そのワークを完遂するが、そのＲＱをホストする他のメッセージング管理システムがそのメッセージのコピーをなおも保持している。これらの残りのメッセージはシステム・リソースを用い、従って削除されるべきである。この削除が自動的に実行されることが有利である。

メッセージがアプリケーションにより消費されるとき、そのメッセージ管理システムはＲＱをホストする全ての他のメッセージ管理システムに通知メッセージを送る。その通知メッセージは任意のメッセージング技法を用いて送られる。

この通知メッセージは応答が送られたＲＱの名称および消費されたメッセージの一意的な識別子の両方を含む。この通知メッセージはメッセージ削除コンポーネントに配布される。このコンポーネントは外部プログラムか、またはそのメッセージング・システムの一部であり得る。

そのメッセージ削除コンポーネントが通知メッセージを受け取ると、それはその一意的に特定されたメッセージをその特定のＲＱから削除する。他のＲＱ上の応答メッセージはアプリケーションがそのメッセージを受け取った後幾らかの時間存在していてもよい。これらのメッセージがＲＱに留まるのは受け入れ可能である。なぜならそれらの存在が他のアプリケーションに悪影響を与えないからである。これは、アプリケーションが、一意的な識別子を用いて、メッセージを消費するからであり、またこれらのメッセージの識別子が他のアプリケーションにより消費されるものと一致しないからである。

メッセージ削除コンポーネントが、その対応する複製されたメッセージがＲＱ上に到達する前に通知メッセージを受け取ることがあり得る。従って、その対応する複製されたメッセージが利用可能でないような通知メッセージが保持される。その対応する複製されたメッセージが到達するとき、それとその保持された通知メッセージの両方が削除される。

通知メッセージまたは複製メッセージのいずれかが特定のメッセージ管理システムに到達しないことがあり得る。例えば、メッセージ管理システム相互間の通信リンクがダウンしている場合、またはメッセージが時間切れの場合である。通知がその複製されたメッセージと同じ時間満了を有する。

要約すると、以下の手順を取る。
・メッセージがＲＱに送られると、その送り手の側にあるメッセージ管理システムがそのＲＱのインスタンスごとにメッセージを複製する。
・複製されたメッセージがアプリケーションにより受け取られると、ＲＱ上に保持された他のレプリカが自動的に削除される。

以下の例は応答を送るためにＲＱがどのように使用され得るかを説明する。

図３では、フローチャート３１０がリクエスト・システムにより実行されるプロセスのステップが示される。リクエスト・システムはメッセージング・ネットワークに接続し（ステップ３１１）、特定のフロントエンド・メッセージング管理システムに対しワークロードがバランスされている。リクエスト・システムはＲＱとして応答の宛先付きのリクエストを生成し、そのリクエストの識別子を保存する（ステップ３１２）。リクエスト・システムはそのリクエストを送る（ステップ３１３）。リクエスト・システムは接続を遮断することができるか、または接続が失敗する可能性がある（ステップ３１４）。

メッセージ・ネットワークのワークロード・バランス機構が、そのリクエストが送られるバックエンドのメッセージング管理システムを実行し、選択する。

図４では、リクエストが送られるバックエンドのメッセージング管理システムに接続された応答システムにより実行されるプロセス・ステップをフローチャート３２０が示す。応答システムがリクエストを消費する（ステップ３２１）。応答システムが応答を生成し、その応答の中にリクエストからの識別子をコピーする（ステップ３２２）。応答システムはリクエスト中に特定された宛先にその応答を送る（ステップ３２３）。メッセージング管理システムは特定された宛先がＲＱであることに気付き、そのＲＱをホストする全てのメッセージ管理システムにその応答を送る（ステップ３２５）。

図５では、リクエスト・システムが再接続するときそれによって実行されるプロセスをフローチャート３３０が示す。リクエスト・システムが再接続し、複数のフロントエンドのメッセージ管理システムのうちの任意の一つへのワークロードがバランスされる（ステップ３３１）。リクエスト・システムはそのリクエストからその保存された識別子を、その応答を選択的に受け取るために特定し（ステップ３３２）、そして接続を遮断する（ステップ３３３）。メッセージング管理システムがその応答をリクエスト・システムに配布するとき、それはそのＲＱの名称および消費されてきた応答の識別子を含む通知メッセージを生成する（ステップ３３４）。メッセージング管理システムがその通知メッセージをその特定されたＲＱの他のホストに送る（ステップ３３５）。削除通知コンポーネントがその特定された応答を削除する。

システム・ダイアグラムが図６に示されるが、そこにはフロントエンド・メッセージ管理システム４１１ないし４１３およびバックエンド・メッセージ管理システム４２１ないし４２３を含むメッセージング・ネットワーク４１０を備えたメッセージング・システム４００が示される。リクエスト・システム接続４２１ないし４２３がフロントエンドのメッセージ管理システム４１１ないし４１３の一つにロード・バランスされる（第１のロード・バランシング機構４４０）。第２のロード・バランシング機構４４１がフロントエンドのメッセージ管理システム４１１ないし４１３からバックエンドのメッセージ管理システム４１４ないし４１６にリクエストをロード・バランスする。応答システム４３１ないし４３３がバックエンドのメッセージ管理システム４１４ないし４１６に接続される。

バックエンドのメッセージ管理システム４１４ないし４１６は各々がリクエストの宛先４５０をホストし、フロントエンドのメッセージ管理システム４１１ないし４１３の各々がＲＱ４５１をホストする。

一実施例では、ＲＱが特別のタイプのクラスタ・キューとして実装され得る。ある実装例は、ＷｅｂＳｐｈｅｒｅ ＭＱクラスタ（ＷｅｂＳｐｈｅｒｅ ＭＱはインターナショナル・ビジネス・マシーンズ・コーポレーションの商標）のコンテキスト(context)に記述されている。メッセージング・ネットワークはＷｅｂＳｐｈｅｒｅ ＭＱクラスタにおけるキュー・マネジャの形式で提供されることができる。その際そのクラスタ中のキュー・マネジャはそのクラスタにおけるＲＱに自動的に気付かされる。メッセージ消費システムが応答メッセージを生成するとき、それはメッセージの生成システムがリクエストおよび応答を相互に関連付けるのを許容するように、ＭＱＭＤ．ＭｓｇｌｄをＭＱＭＤ．ＣｏｒｒｅｌＩｄにコピーすることにより、リクエスト・メッセージから応答メッセージへ情報をコピーする。リクエストを最初に書き込んだメッセージ消費システムはフロントエンドのキュー・マネジャのいずれかに接続もしくは再接続したままであり、そのキュー・マネジャ上のＲＱ上に保持される応答メッセージを受け取る。そのアプリケーションはＭＱＭＤ．ＣｏｒｒｅｌＩｄのその相互関連情報を、それが関連する特定の応答メッセージを受け取るために用いる。

図７を参照すると、図６のメッセージング・システム４００がキュー・マネジャ４１１ないし４１６の形式でメッセージ管理システムのＷｅｂＳｐｈｅｒｅ ＭＱクラスタ４１０（ＭＹＣＬＵＳ）のコンテキスト中に示される。３個のバックエンド・キュー・マネジャ４１４ないし４１６（ＱＭ４、ＱＭ５、ＱＭ６）および３個のフロントエンド・キュー・マネジャ４１１ないし４１３（ＱＭ１、ＱＭ２、ＱＭ３）が示される。メッセージ生成クライアント・アプリケーション４２１ないし４２３がロード共有機構４４０を介してフロントエンド・キュー・マネジャ４１１ないし４１３のうちの一つに接続し、リクエスト・メッセージを、全てのバックエンド・キュー・マネジャ４１４ないし４１６上でホストされるクラスタ・キュー４５０（ＲＥＱ．Ｑ）に書き込み、それから接続を遮断する。バックエンド・キュー・マネジャ４１４ないし４１６に接続されたメッセージ消費アプリケーション４３１ないし４３３はクラスタ・キュー４５０（ＲＥＱ．Ｑ）からリクエスト・メッセージを取り出しＲＱキュー４５１（ＲＥＰ．Ｑ）に応答メッセージを書き込む。少し経ってから、いずれかのフロントエンド・キュー・マネジャ４１１ないし４１３からその応答が取り出せる。

リクエスト・キューが以下の通り作成される。
！ＱＭ４ ＤＥＦ ＱＬ（ＲＥＱ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）
！ＱＭ５ ＤＥＦ ＱＬ（ＲＥＱ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）
！ＱＭ６ ＤＥＦ ＱＬ（ＲＥＱ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）

応答キューが以下の通り作成される。
！ＱＭ１ ＤＥＦ ＲＱ（ＲＥＰ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）
！ＱＭ２ ＤＥＦ ＲＱ（ＲＥＰ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）
！ＱＭ３ ＤＥＦ ＲＱ（ＲＥＰ．Ｑ） ＣＬＵＳＴＥＲ（ＭＹＣＬＵＳ）

ＲＱが一旦定義されると、その上でそれが定義されるキュー・マネジャは自動的にそのキューに関係する情報（例えば、通知メッセージ）を受領するよう登録される（subscribe）。

下記のステップ（図７参照）が、単一のリクエストおよび応答のための振る舞いを説明する。

１）メッセージ生成クライアント・アプリケーションが接続し、特定のフロントエンド・キュー・マネジャに対しワークロードがバランスされる（例えば、ＩＰロード・バランサもしくはＷｅｂＳｐｈｅｒｅ ＭＱクライアント・チャネル定義テーブルを用いて）。この場合、それがＱＭ３に対しワークロードがバランスされる。

２）メッセージ生成クライアント・アプリケーションがリクエスト・メッセージを生成し、ＲＥＰ．ＱのＭＱＭＤ．ＲｅｐｌｙＴｏＱの名称を記入し、ＭＱＭＤ．ＭｓｇＩｄを保存する。

３）このメッセージ生成クライアント・アプリケーションがＲＥＱ.Ｑにリクエスト・メッセージを書き込む。ＲＥＱ．Ｑがクラスタ・キューなので、ＱＭ３がそのことに気付き、それにメッセージをルート付けすることができる。

４）クラスタ・ワークロード・バランシング・アルゴリズムが実行され、そしてこの場合にＱＭ６にそのリクエスト・メッセージを送るように選択する。このメッセージはＱＭ６にクラスタ・チャンネルを介して送られ、ＲＥＱ．Ｑ上に書き込まれる。

５）メッセージ生成クライアント・アプリケーションが接続を遮断する（あるいは接続し損なう）。このことがステップ３およびステップ１０の間の任意の時点で起こり得ることに留意されたい。

６）ＱＭ６上のメッセージ消費アプリケーションはそのリクエスト・メッセージを取り出し、処理する（例えば、データベースを更新する）。

７）ＱＭ６上のメッセージ消費アプリケーションは応答メッセージを生成し、リクエスト・メッセージからのＭＱＭＤ．Ｍｓｇｌｄを応答メッセージ中のＭＱＭＤ．ＣｏｒｒｅｌＩｄにコピーする。

８）ＱＭ６上のメッセージ消費アプリケーションはこの応答メッセージをリクエスト・メッセージ（ＲＥＰ．Ｑ）のＭＱＭＤ．ＲｅｐｌｙＴｏＱの中に特定されている宛先に応答メッセージを書き込む。

９）ＱＭ６はＲＥＰ．ＱがＲＱであることに気付き、従って特定された任意のＭＱＯＤ．ＯｂｊｅｃｔＱＭｇｒＮａｍｅを無視し、その応答メッセージを、ＲＥＰ．Ｑをホストする全てのキュー・マネジャに発行する。その結果応答メッセージのコピーがＱＭ１、ＱＭ２、ＱＭ３上のＲＥＰ.Ｑ上に今や存在することになる。そのＯｂｊｅｃｔＱＭｇｒＮａｍｅを無視するというのが、存在するアプリケーションがＲＱの利点を生かすのを許容することに留意されたい。

１０）メッセージ生成クライアント・アプリケーションが接続し、特定のフロントエンド・キュー・マネジャに対し（例えば、ＩＰロード・バランサもしくはＷｅｂＳｐｈｅｒｅ ＭＱクライアント・チャネル定義テーブルのいずれかを用いて）ワークロードのバランスがとられている。この場合、ＱＭ１に対し、ワークロードのバランスがとられている。

１１）メッセージ生成クライアント・アプリケーションがその応答メッセージ、ＭＱＭＤ．ＣｏｒｒｅｌＩｄにおいて（そのリクエスト・メッセージからの）その保存されたメッセージＩＤを特定し、その応答メッセージを取り出し、そして接続を遮断する。

１２）ＱＭ１は、応答メッセージがＲＱ（ＲＥＰ．Ｑ）から除去されたことを気づき、ＲＱ（ＲＥＰ．Ｑ）の名称および丁度除去されたばかりのその応答メッセージのＣｏｒｒｅｌＩＤ（即ち他のＲＱ上の他の応答メッセージ中にある同じＣｏｒｒｅｌＩＤ）を含む通知メッセージを自動的に生成する。そこでＱＭ１は、これらの通知を既に受領するよう登録されているＲＥＱ．Ｑの他のホストに通知を発行する。

１３）ＱＭ２およびＱＭ３はその発行を得て、その特定されたＲＱ（ＲＥＱ．Ｑ）からのその特定されたメッセージを削除するようにその通知メッセージにおける情報を使用する。ローカルの配布が効力を持たないので、ＱＭ１がその通知を受け取らないことに留意されたい。

全てのアプリケーション接続と同様、その接続がコミット中に失敗するならそのアプリケーションはそのコミットが完了したか否か確信できない時がある。以下のシナリオは、２つの問題のコミットを記述する。

１）そのアプリケーションがコミット・コールを発行し、そのコミットが失敗し、その接続が失敗し、そしてそのアプリケーションがそのコミット・コールから「接続切れ」戻しコードを受け取る。その応答はなおも利用可能である。

２）そのアプリケーションがコミット・コールを発行し、そのコミットが成功裏に完了し、その接続が失敗し、そしてそのアプリケーションがそのコミット・コールから「接続切れ」戻しコードを受け取る。その応答はもはや利用可能でない。

シナリオ１）および２）における問題は、そのコミットが実際に完了したか否かをそのアプリケーションが知らないことである。その同じ問題はコミットする全てのアプリケーションとともに存在する。この解決策は、（個々のメッセージの単一の消費者である）アプリケーションが、もしそのメッセージがそのメッセージング管理システムからもはや利用することができないならそのコミットが働いたと仮定することができることである。２つのかなり簡単な解決策がある。

ａ）もしそのアプリケーションがコミット・コールに応答して「接続切れ」を受け取るなら、そのアプリケーションはそのコミットを発行した同じメッセージング管理システムに再接続して応答があるかどうかチェックしなければならない。もしその応答が存在しないなら、それはそのコミットが成功したとみなされることができ、そしてそのアプリケーションが処理を続けることができる。もしその応答が存在するなら、それは再び消費され、そして再びコミットされなければならない。これが親和性（affinity）を生み出すけれども、その「親和性ウインドウ」はそのＲＱシステムを用いるときかなり引き下げられる。

ｂ）そのエラーを無視せよ、そしてそのコミットが成功したと仮定して続行せよ。もしそのコミットが成功したなら、その応答はそのＲＱから除去され、それ以上のアクションを取る必要はない。もしそのコミットが失敗したら、その応答はそのＲＱ上に留まる。応答を消費した全てのアプリケーションが一意的に識別可能な応答を選択しているので、他のアプリケーションはその留まっている応答を消費することができず、従って今や問題は、その残っている応答を如何にうまくクリアするかである。ＲＱの時間満了または手動でのクリアが使用されることができる。

この記述した方法およびシステムはリクエスト／応答のシナリオにおける可用性を増す。この解決策は可用性の改善をメッセージ往復時間に最小限の影響しか与えずに提供する。全ての応答が一単位の作業で送られやすいので、もしＲＱの非常に大きな数のホストがあるなら、複製される応答を送るのに時間の増加が関係したであろう。少なくとも可用性の観点からは、大きな数のＲＱが必要とされることがあまりないということに注意する価値がある。また、メッセージ往復時間に関連した任意の単位の作業の外での過剰な応答の削減がなされる。

この解決策はｎ個のＲＱを含むネットワークが、そのＲＱをホストするｎ−１個までのメッセージ管理システムの失敗のイベントにおいて応答を配布することができるように設計される。典型的には、２個または３個のＲＱが十分な冗長性を提供すると期待することができる。

ある（失敗の）シナリオでは、このモデルがタイムリな態様で削除されない複製応答を生じる。この解決策はその応答が（例えば、一意的な識別子により）選択的に処理されることを仮定している。一旦応答が消費されてしまうと、そのアプリケーションにより保持される選択基準はそのアプリケーションが他のＲＱからの任意の存在する複製応答を読み出そうと試みないようにクリアされる。もし選択的な応答が必要とされなければ、任意のスレッドまたはアプリケーションが応答を処理することができ、かくしてＲＱの必要性を完全に否定する（単純な宛先で十分である）。

本発明は完全にハードウエアの実施例、完全にソフトウエアの実施例、あるいはハードウエアおよびソフトウエアの要素を組み合わせた実施例といった形態をとることができる。好適な実施例では、本発明は、以下に限定されるものではないが、ファームウエア、常駐ソフトウエア、マイクロコードなどを含むソフトウエアで実施される。

また本発明は、コンピュータまたは任意の命令実行システムにより、またはそれに関連して使用されるプログラム・コードを提供する、コンピュータ可用媒体またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラムの形態をとることができる。この説明の目的上、コンピュータ可用媒体またはコンピュータ可読媒体は、命令実行システム、装置もしくはデバイスにより、またはそれに関連して使用されるプログラムを含み、ストアし、通信し、伝播し、あるいは移送することができる任意の装置であってよい。

この媒体は、電子的、磁気的、光学的、電磁的、赤外線の、もしくは半導体のシステム（または装置、デバイス）或いは伝送媒体であってよい。コンピュータ可読媒体の例は半導体もしくは固体素子のメモリ、磁気テープ、取り外し可能なフレキシブル・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、磁気ハードディスクおよび光ディスクを含む。今日の光ディスクの例は、ＣＤ−ＲＯＭ（コンパクト・ディスク読出し専用メモリ）、ＣＤ−Ｒ／Ｗ（コンパクト・ディスク読出し書込み）およびＤＶＤを含む。

改良と修正が本発明の範囲から逸れることなく前述のことについて行われることができる。

Claims (40)

1. メッセージング・ネットワークにおけるメッセージ配布方法であって、一意的な識別子を含むメッセージを生成するステップ３２２と、
   複数個の複製キュー４５１の各々に前記メッセージを送るステップ３２４とを含み、前記メッセージは消費される前に前記一意的な識別子により識別可能である、メッセージ配布方法。
2. 複数個の複製キュー４５１の各々に前記メッセージを送るステップ３２４が、前記複製キュー４５１が定義されるメッセージ管理システム４１１ないし４１３の各々に前記メッセージを送ることを含む、請求項１に記載の方法。
3. 複製されたメッセージが応答メッセージを含む、請求項１または２に記載の方法。
4. 前記応答メッセージがリクエスト／応答メッセージング・システムに関連する、請求項３に記載の方法。
5. 前記リクエストにおいて特定されるメッセージング管理システム４１１ないし４１３が無視される、請求項１ないし４のいずれかに記載の方法。
6. 前記一意的な識別子を用いて前記複製キュー４５１のいずれかから前記メッセージを取り出すステップ３３３を含む、請求項１ないし５のいずれかに記載の方法。
7. 前記複製されたメッセージを削除するための通知メッセージ３３４を生成するステップであって、前記通知メッセージが前記複製キュー４５１の名称および前記一意的な識別子を含むものと、
   前記複製キューが定義されるメッセージング管理システムに前記通知メッセージを発行するステップ３３５とを含む、請求項１ないし６のいずれかに記載の方法。
8. 前記複製されたメッセージが前記複製されたキュー３５１の一つから除去されたのに応答して前記通知メッセージが発行される、請求項７に記載の方法。
9. メッセージング・ネットワークにおけるメッセージ配布システムであって、１個または複数個のプロセッサ上に提供される複数個のメッセージ管理システム４１１ないし４１５を含むメッセージング・ネットワーク４００と、
   前記メッセージが読み出される前にアプリケーションにより識別されるように動作可能なメッセージのための複製キュー４５１であって、複数個のメッセージ管理システム４１１ないし４１３上で定義可能な前記複製キューとを含み、
   複数個のメッセージ管理システム４１１ないし４１５のうちのいずれか一つを用いてアクセス可能である複数個の複製キュー４５１の各々にメッセージが送られるところのメッセージ配布システム。
10. メッセージング・ネットワーク４００が
    複数個のフロントエンド・メッセージ管理システム４１１ないし４１３および複数個のバックエンド・メッセージ管理システム４１４ないし４１６を含み、
    前記システムが
    前記フロントエンド・メッセージ管理システム４１１ないし４１３のうちの一つに接続可能なリクエスト・システム４２１ないし４２３と、
    前記バックエンド・メッセージ管理システム４１４ないし４１６のうちの一つに接続可能な応答システム４３１ないし４３３とを含む、請求項９に記載のシステム。
11. リクエスト・システム４２１ないし４２３およびフロントエンド・メッセージ管理システム４１１ないし４１３間の第１のロード・バランシング機構４４０と、
    フロントエンド・メッセージ管理システム４１１ないし４１３およびバックエンド・メッセージ管理システム４１４ないし４１６間の第２のロード・バランシング機構４４１とを含む、請求項１０に記載のシステム。
12. 前記複数個のフロントエンド・メッセージ管理システム４１１ないし４１３のうちのいずれか一つからリクエスト・システム４２１ないし４２３により消費されるため、メッセージのための複製キュー４５１が複数個の前記フロントエンド・メッセージ管理システム４１１ないし４１３上で定義可能である、請求項９ないし１１のいずれかに記載のシステム。
13. 一意的な識別子を用いて前記複製キュー４５１のうちのいずれか一つから前記応答を消費するためのリクエスト・システム４２１ないし４２３を含む、請求項１２に記載のシステム。
14. 前記複製されたメッセージが応答メッセージを含む、請求項９ないし１３のいずれかに記載のシステム。
15. 前記応答メッセージがリクエスト／応答メッセージング・システムに関連する、請求項１４に記載のシステム。
16. 前記複製キュー４５１が複数個のメッセージ管理システム４１１ないし４１３の各々の上で手動で定義可能である、請求項９ないし１５のいずれかに記載のシステム。
17. 前記キュー４５１を複製するために、前記複製キュー４５１が一つのメッセージ管理システム４１１ないし４１３上で手動で定義可能であり、かつ複数個のメッセージ管理システム４１１ないし４１３の残りの上で自動的に定義可能である、請求項９ないし１５のいずれかに記載のシステム。
18. メッセージ識別子を含むリクエストを受取るための手段と、
    リクエスト・メッセージ識別子に関連する関連情報を含む応答を生成する手段と、
    複数個の複製キュー４５１の各々に前記応答を書き込むところの、前記応答が消費前に一意的な識別子情報により識別可能である手段とを含む、請求項９ないし１７のいずれかに記載のシステム。
19. 前記リクエストが応答の宛先を含み、複数個のメッセージ管理システム４１１ないし４１３上で定義可能な複製キュー４５１を含む、請求項１８に記載のシステム。
20. 複数個の複製キューの各々に前記応答を送るための前記手段が、複製キュー４５１が定義可能なメッセージ管理システム４１１ないし４１３の各々に応答を送るための手段を含む、請求項１８または１９に記載のシステム。
21. 前記リクエスト中に特定されるメッセージ管理システム４１１ないし４１３を無視するための手段を含む、請求項１８ないし２０のいずれかに記載のシステム。
22. 前記応答を削除するための通知メッセージであって、前記複製キュー４５１の名称および前記一意的な識別子を含む前記通知メッセージを生成する手段と、
    前記通知メッセージを、前記複製キュー４５１をホストするように動作可能なメッセージ管理システム４１１ないし４１３に送る手段とを含むメッセージ削除コンポーネントを含む、請求項１８ないし２１のいずれかに記載のシステム。
23. 前記複数個のメッセージ管理システム４１１ないし４１３がキュー・マネジャのクラスタを含む、請求項９ないし２２のいずれかに記載のシステム。
24. １個もしくは複数個のプロセッサ上に提供される複数個のメッセージ管理システム４１１ないし４１５を含むメッセージング・ネットワーク４００とともに動作可能なメッセージング・ネットワークにおけるメッセージ配布装置であって、
    一意的な識別子を含むメッセージを生成する手段と、
    複数個の複製キュー４５１の各々に前記メッセージであって、消費前に一意的な識別子により識別される前記メッセージを送る手段３２４とを含むメッセージ配布装置。
25. 複製キュー４５１が複数個のメッセージ管理システム４１１ないし４１３上で定義されることが可能なように動作し得ることと、
    メッセージが複数個の複製キュー４５１の各々に送られ、かつメッセージが複数個のメッセージ管理システム４１１ないし４１５のうちのいずれか一つを用いてアクセス可能であることよりなる、請求項２４に記載の装置。
26. 前記メッセージング・ネットワーク４００が複数個のフロントエンド・メッセージ管理システム４１１ないし４１３と、
    複数個のバックエンド・メッセージ管理システム４１４ないし４１６とを含み、
    前記装置が
    前記フロントエンド・メッセージ管理システム４１１ないし４１３のうちの一つに接続可能なリクエスト・システム４２１ないし４２３と、
    前記バックエンド・メッセージ管理システム４１４ないし４１６のうちの一つに接続可能な応答システム４３１ないし４３３とを含む、請求項２４に記載の装置。
27. リクエスト・システム４２１ないし４２３およびフロントエンド・メッセージ管理システム４１１ないし４１３間の第１のロード・バランシング機構４４０と、
    フロントエンド・メッセージ管理システム４１１ないし４１３およびバックエンド・メッセージ管理システム４１４ないし４１６間の第２のロード・バランシング機構４４１とを含む、請求項２６に記載の装置。
28. 前記複数個のフロントエンド・メッセージ管理システム４１１ないし４１３のうちのいずれか一つからリクエスト・システム４２１ないし４２３により消費されるため、メッセージのための複製キュー４５１が複数個の前記フロントエンド・メッセージ管理システム４１１ないし４１３上で定義可能である、請求項２４ないし２７のいずれかに記載の装置。
29. 一意的な識別子を用いて前記複製キュー４５１のうちのいずれか一つから前記応答を消費するためのリクエスト・システム４２１ないし４２３を含む、請求項２８に記載の装置。
30. 前記複製されたメッセージが応答メッセージを含む、請求項２４ないし２９のいずれかに記載の装置。
31. 前記応答メッセージがリクエスト／応答メッセージング・システムに関連する、請求項３０に記載の装置。
32. 前記複製キュー４５１が複数個のメッセージ管理システム４１１ないし４１３の各々の上で手動で定義可能である、請求項２４ないし３１のいずれかに記載の装置。
33. 前記キュー４５１を複製するために、前記複製キュー４５１が一つのメッセージ管理システム４１１ないし４１３上で手動で定義可能であり、かつ複数個のメッセージ管理システム４１１ないし４１３の残りの上で自動的に定義可能である、請求項２４ないし３１のいずれかに記載の装置。
34. メッセージ識別子を含むリクエストを受取るための手段と、
    リクエスト・メッセージ識別子に関連する関連情報を含む応答を生成する手段と、
    複数個の複製キュー４５１の各々に前記応答を書き込むところの、前記応答が消費前に一意的な識別子情報により識別可能である手段とを含む、請求項２４ないし３３のいずれかに記載の装置。
35. 前記リクエストが応答の宛先を含み、複数個のメッセージ管理システム４１１ないし４１３上で定義可能な複製キュー４５１を含む、請求項３４に記載の装置。
36. 複数個の複製キューの各々に前記応答を送るための前記手段が、複製キュー４５１が定義可能なメッセージ管理システム４１１ないし４１３の各々に応答を送るための手段を含む、請求項３４または３５に記載の装置。
37. 前記リクエスト中に特定されるメッセージ管理システム４１１ないし４１３を無視するための手段を含む、請求項３４ないし３６のいずれかに記載の装置。
38. 前記応答を削除するための通知メッセージであって、前記複製キュー４５１の名称および前記一意的な識別子を含む前記通知メッセージを生成する手段と、
    前記通知メッセージを、前記複製キュー４５１をホストするように動作可能なメッセージ管理システム４１１ないし４１３に送る手段とを含むメッセージ削除コンポーネントを含む、請求項３４ないし３７のいずれかに記載の装置。
39. 前記複数個のメッセージ管理システム４１１ないし４１３がキュー・マネジャのクラスタを含む、請求項２４ないし３８のいずれかに記載の装置。
40. 請求項１ないし８のいずれかに記載の全てのステップを実行するように適用されたプログラム・コード手段を含む、コンピュータ上で実行可能なコンピュータ・プログラム。

Images