JP6238898B2 - ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを提供および管理するためのシステムおよび方法 - Google Patents

Description

著作権表示：
この特許文書の開示の一部は、著作権の保護下にある内容を含む。著作権所有者は、特許商標庁の特許ファイルまたは記録に現れるので、誰でも当該特許文書または特許開示を複製することについて異議を唱えないが、そうでなければ如何なる場合でもすべての著作権を留保する。

発明の分野：
この発明は、概して、ミドルウェアなどのコンピュータシステムおよびソフトウェアに関し、特に、トランザクションミドルウェアマシン環境をサポートすることに関する。

背景：
トランザクションミドルウェアシステムまたはトランザクション指向のミドルウェアは、構成内におけるさまざまなトランザクションを処理することのできるエンタープライズアプリケーションサーバを含む。高性能ネットワークおよびマルチプロセッサコンピュータなどの新技術の開発に伴い、トランザクションミドルウェアの性能をさらに向上させる必要がある。これらは、概して、本発明の実施形態が対処するよう意図された分野である。

概要：
ミドルウェアマシン環境においてメッセージキューを設けるためのシステムおよび方法をこの明細書中に記載する。トランザクションミドルウェアマシン環境は、メッセージ受信側にメッセージ制御データ構造と、共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含む。メッセージ送信側は、メッセージをヒープデータ構造にダイレクトに書込み、メッセージ制御データ構造においてメッセージに関連付けられるメタデータを維持するよう動作する。さらに、ミドルウェアマシン環境は、メッセージ受信側に共有メモリを含む。共有メモリは、ミドルウェアマシン環境のための１つ以上のメッセージキューを維持する。加えて、ミドルウェアマシン環境はデーモンプロセスを含む。このデーモンプロセスは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合、共有メモリにおいて少なくとも１つのメッセージキューを作成することができる。

本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを提供する例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境において正確なロードバランスをサポートするための例示的なフローチャートを示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのリモートメモリリングを提供する例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境において複数のメッセージ送信側によって同時にアクセスすることのできるメッセージキューの例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのＳｙｓｔｅｍ Ｖメッセージキューを用いる例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのリモートダイレクトメモリアクセス（remote direct memory access：ＲＤＭＡ）メッセージキューの例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを作成および管理することのできるデーモンプロセスの例を示す図である。 本発明の実施形態に従った、トランザクションミドルウェアマシン環境において正確なロードバランスをサポートするための例示的なフローチャートを示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するのに用いることができるセキュリティモデルの例を示す図である。 本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するための例示的なフローチャートを示す図である。

詳細な説明：
トランザクションミドルウェアマシン環境において複数のプロセッサを備えた高速マシンおよび高性能ネットワーク接続を活用することのできるトランザクションミドルウェアシステムを、サポートするためのシステムおよび方法をこの明細書中に記載する。当該システムは、リングバッファ（円形のキュー）に基づいたデータ構造を用いてマルチノードアプリケーションのためのメッセージキューを設けることができる。当該システムは、リーダ上に第１のリング構造とライタ上に第２のリング構造とを備えたリモートリング構造を含む。第１のリング構造および第２のリング構造の各々は、ヘッドポインタおよびテールポインタを有する。ライタは、リモートリングにメッセージを書込むよう動作すると、第１のリング構造および第２のリング構造の両方のためにヘッドポインタと、リモートリング構造におけるデータとを更新し得る。リーダは、リモートリングからメッセージを読取るよう動作すると、第１のリング構造および第２のリング構造の両方のためにテールポインタを更新し得る。加えて、メッセージをヒープデータ構造に記憶させることができ、メッセージに関連付けられるメタデータをリモートリング構造に記憶させることができる。

本発明の実施形態に従うと、当該システムは、高性能ハードウェア（たとえば６４ビットプロセッサ技術、高性能の大規模メモリ、ならびに冗長なＩｎｆｉｎｉＢａｎｄおよびイーサネット（登録商標）ネットワーキング）と、ＷｅｂＬｏｇｉｃ Ｓｕｉｔｅなどのアプリケーションサーバまたはミドルウェア環境との組合せを含み、これにより、迅速に設けられ得るとともにオンデマンドでスケール変更可能な大規模並列メモリグリッドを含む完全なＪａｖａ（登録商標）ＥＥアプリケーションサーバコンプレックスを提供する。一実施形態に従うと、当該システムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびＩｎｆｉｎｉＢａｎｄ（ＩＢ）ネットワークを提供するフルラック、ハーフラック、もしくはクォーターラック、または他の構成として展開され得る。ミドルウェアマシンソフトウェアは、たとえばＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ、ＪＲｏｃｋｉｔまたはＨｏｔｓｐｏｔ ＪＶＭ、Ｏｒａｃｌｅ Ｌｉｎｕｘ（登録商標）またはＳｏｌａｒｉｓ、およびＯｒａｃｌｅ ＶＭといった、アプリケーションサーバと、ミドルウェアと、他の機能性とを提供し得る。当該システムは、ＩＢネットワークを介して互いに通信する複数の計算ノードと、ＩＢスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。ラック構成として実現される場合、当該ラックの未使用部分は空のままとされ得るかまたはフィラー（filler）によって占有され得る。

本願明細書において「Ｓｕｎ Ｏｒａｃｌｅ Ｅｘａｌｏｇｉｃ」または「Ｅｘａｌｏｇｉｃ」と称される本発明の実施形態に従うと、当該システムは、Ｏｒａｃｌｅ Ｍｉｄｄｌｅｗａｒｅ ＳＷ ｓｕｉｔｅまたはＷｅｂｌｏｇｉｃといったミドルウェアまたはアプリケーションサーバソフトウェアをホストするための、展開が容易なソリューションである。本願明細書に記載されるように、当該システムは、１つ以上のサーバと、ストレージユニットと、ストレージネットワーキングのためのＩＢファブリックと、ミドルウェアアプリケーションをホストするのに必要な他のすべてのコンポーネントとを含む「グリッド・イン・ア・ボックス（grid in a box）」である。たとえばＲｅａｌ Ａｐｐｌｉｃａｔｉｏｎ ＣｌｕｓｔｅｒｓおよびＥｘａｌｏｇｉｃ ｏｐｅｎ ｓｔｏｒａｇｅを用いて大規模並列グリッドアーキテクチャを活用することにより、すべてのタイプのミドルウェアアプリケーションのために有意な性能が与えられ得る。このシステムは、線形のＩ／Ｏスケーラビリティとともに向上した性能を与え、使用および管理が簡潔であり、ミッションクリティカルな可用性および信頼性を与える。

本発明の実施形態に従うと、Ｔｕｘｅｄｏは１セットのソフトウェアモジュールであって、高性能の分散型ビジネスアプリケーションの構築、実行および管理を可能にし、複数の多層アプリケーション開発ツールによってトランザクションミドルウェアとして用いられてきた。Ｔｕｘｅｄｏは、分散型コンピューティング環境における分散型トランザクション処理を管理するのに用いることができるミドルウェアプラットフォームであり、無限のスケーラビリティおよび規格ベースの相互運用性を提供しつつ、エンタープライズレガシーアプリケーションをアンロックし、サービス指向のアーキテクチャーへと拡張するための検証済みのプラットフォームである。

本発明の一実施形態に従うと、ミドルウェアマシン環境は、マルチノードアプリケーションのためのメッセージキューを与えることができる。トランザクションミドルウェアマシン環境は、メッセージ受信側にメッセージ制御データ構造と、共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含む。メッセージ送信側は、ヒープデータ構造にダイレクトにメッセージを書込み、メッセージ制御データ構造においてメッセージに関連付けられるメタデータを維持するよう動作する。さらに、メッセージ制御データ構造は、ヘッドポインタおよびテールポインタを備えたリング構造であってもよい。加えて、メッセージ受信側は複数のクライアントに接続されるサーバ上に存在し、上記クライアントの各々は、メッセージ制御データ構造の専用コピーを保持する。また、メッセージ受信側は、メッセージ受信側に関連付けられたメッセージ制御データ構造への同時アクセスをサポートすることができる。

本発明の別の実施形態に従うと、ミドルウェアマシン環境は、マルチモードアプリケーションのためのメッセージキューを管理することができる。ミドルウェアマシン環境は、メッセージ受信側に共有メモリを含む。共有メモリは、ミドルウェアマシン環境のために１つ以上のメッセージキューを維持する。ミドルウェアマシン環境はさらにデーモンプロセスを含む。デーモンプロセスは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合に、共有メモリにおいて少なくとも１つのメッセージキューを作成することができる。加えて、クライアント上のさまざまなプロセスは、少なくとも１つのプロキシを用いてメッセージサーバと通信するよう動作する。さらに、ミドルウェアマシン環境は、デーモンプロセスによって作成されたセキュリティトークンを用いて、マルチモードアプリケーションのためのメッセージキューを保護することができる。

マルチノードアプリケーションのためのメッセージキュー
本発明の実施形態に従うと、メッセージ通信キューなどのメッセージ通信ソフトウェアは、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコルを用いてＩＢネットワークなどの高性能ネットワークを活用し得る。ＲＤＭＡプロトコルは、メッセージ送信側が、リモートマシン上のプロセスを起動させる必要なしに、ＯＳカーネルをバイパスしてメモリにダイレクトアクセスすることを可能にする。

図１は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを与える例を示す。図１に図示のとおり、ミドルウェアマシン環境１００は、マシンＡ １０１およびマシンＢ １０２などの複数のサーバマシンを含み得る。ローカルマシンたとえばマシンＡ １０１上のメッセージ送信側１０３は、リモートマシンたとえばマシンＢ １０２上のメッセージ受信側１０４にメッセージ１０７を送信することができる。リモートマシンＢ １０２上のメッセージ受信側１０４は、メッセージキューまたはメッセージ制御データ構造１０８およびヒープデータ構造１１０を含む共有メモリ１０６を用いることができる。

本発明の実施形態に従うと、メッセージキューは、メッセージに関連付けられたメタデータ情報だけを含み得る一方で、ヒープデータ構造は物理的なメッセージを含む。このため、可変サイズのメッセージに容易に対処することができ、この可変サイズのメッセージを共有メモリに記憶することができる。図１に図示のとおり、メッセージ送信側１０３はヒープデータ構造１１０にダイレクトにメッセージを書込み、かつメッセージ制御データ構造１０８においてメッセージに関連付けられたメタデータを維持するよう動作する。

また、図１に図示のとおり、メッセージ送信側１０３は、ローカルマシン、すなわちマシンＡ １０１、上にメッセージ制御データ構造１０５を含む。メッセージ制御データ構造１０５は、メッセージ送信側１０３のためのメッセージキュー１０８のコピーであり得る。ローカルマシンＡ １０１上のメッセージ送信側はさらに、ローカルマシンＡ １０１上のメッセージ制御データ構造１０５においてメッセージに関連付けられたメタデータを維持することができる。

本発明の実施形態に従うと、ローカルマシンＡ １０１上のメッセージ送信側は、リモートマシンＢ １０２上の共有メモリ１０６内のヒープデータ構造１１０にダイレクトにメッセージを書込むことができる。図１に図示のとおり、メッセージ送信側１０３は、メッセージ受信側１０４によって提供されるアドレス指定情報を用いてリモートマシンＢ １０２上のＯＳカーネルをバイパスすることができる。さらに、ローカルマシンＡ １０１上のメッセージ送信側１０３は、ローカルマシンＡ １０１上の制御構造を介してリモートマシンＢ １０２内のキューにおいて入力シーケンス番号などのメッセージの状況情報を更新することができる。

さらに、ローカルマシンＡ １０１上のメッセージ送信側１０３は、メッセージのサイズに関わらず、メッセージ受信側１０４にメッセージを送信することができる。したがって、このメッセージ通信メカニズムは、コスト効率が良く効率的なものであり得、大量のデータのためのオーバーヘッドをさほど必要としない。

加えて、メッセージ送信側１０３は、予め構成された手順に従って、メッセージ受信側１０４に関連付けられたリモートマシンＢ １０２上のプロセス１１２を起動させることができる。たとえば、メッセージ送信側は、プロセスによって処理することのできるサービス要求メッセージが配信された場合にプロセスを起動させることができる。別の例においては、キューがフルである場合、メッセージ送信側は、リモートマシンＢ １０２上のデーモンプロセスを起動させることができる。

本発明の実施形態に従うと、メッセージ受信側のプロセス、たとえばプロセス１１２がスリープに入る前に、当該プロセスは、クライアント側のメッセージ制御構造１０５を認識することができる、および／または、それ自体を如何に起動させるかについての手順をメッセージ制御構造１０５に提供することができる。次いで、受信側のプロセスはメッセージの配信を待つことができる。たとえば、メッセージが来ることを予想しているプロセスは、メッセージ送信側によって起動されるまでスリープ状態であってもよい。

また、図１に図示のとおり、メッセージ受信側１０４がメッセージを使い果たした後、メッセージ受信側はキューからメッセージを取出すことでき、この場合、メッセージ受信側は、ＲＤＭＡ書込み動作を実行することによってメッセージキュー１０８と送信側の制御構造１０５とを更新することができる。このようなＲＤＭＡ書込み動作は、リモートマシンＢ １０２上のクライアントから干渉のない態様で実行することができる。

本発明の実施形態に従うと、ミドルウェアマシン環境において２つのサーバ間で双方向通信をサポートするために、ミドルウェアマシン上の各サーバは受信側および送信側を備え得る。このため、これら２つのサーバ間の通信は、ＲＤＭＡ書込み動作などのＲＤＭＡプロトコルを用いて、さまざまなマシンにおいてさまざまなメッセージ送信側によって実行することができる。

図２は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを与えるための例示的なフローチャートを示す。図２に図示のとおり、ステップ２０１において、システムはメッセージ受信側に第１のメッセージ制御データ構造を設けることができる。ステップ２０２において、システムは、共有メモリ内のヒープデータ構造をメッセージ受信側に関連付けることができる。次いで、２０３において、システムは、メッセージ送信側がヒープデータ構造にメッセージをダイレクトに書込み、第１のメッセージ制御データ構造においてメッセージに関連付けられたメタデータを維持することを可能にする。

リモートメモリリング
本発明の実施形態に従うと、リングバッファ（円形のキュー）に基づいたデータ構造は、このシステムのバックボーンになり得る。簡素化された場合には、このリング構造は先入れ先出し（first-in first-out：ＦＩＦＯ）キューとして機能し得る。

図３は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのリモートメモリリングを設ける例を示す。図３に図示のとおり、メッセージ送信側３０１およびメッセージ受信側３０２はともに、メッセージ制御データ構造としてリング構造を用いることができ、各々のリング構造はヘッドポインタおよびテールポインタを備えることができる。メッセージ送信側３０１がメッセージリーダ３０２上のメッセージキュー、たとえば共有メモリ内のヒープデータ構造、にメッセージを書込むよう動作すると、メッセージ送信側３０１は両方のリング構造のためにヘッドポインタ３０３および３０４を更新することができる。他方で、メッセージ受信側３０２またはリーダが共有メモリ内のヒープデータ構造からメッセージを読取るよう動作すると、リーダは両方のリング構造のためにテールポインタ３０５および３０６を更新する。

本発明の実施形態に従うと、リング構造内のヘッドポインタは、メッセージキューに加えられた最新のメッセージを指し、リング構造内のテールポインタはメッセージキューにおける最も古いメッセージを指す。アクティブなメッセージがヘッドポインタとテールポインタとの間に記憶される。メッセージ送信側またはライタは、キューのヘッドポインタとテールポインタとの間の自由空間（図３におけるリング構造の白い部分）を参照して、新しいメッセージを書込むのに応じてヘッドポインタを前方に移動させることができる。他方で、メッセージリーダは、キューのヘッドポインタとテールポインタとの間（図３におけるリング構造の影付き部分）を参照して、新しいメッセージを得て、これらリーダがメッセージを読取るのに応じてテールポインタを前方に移動させることができる。これにより、ヘッドポインタおよびテールポインタをともに確実に一方向のみに移動させる。

本発明の実施形態に従うと、各々のリング動作のために以下の限定事項が維持され得る：リーダだけがテールポインタを更新する；ライタだけがヘッドポインタを更新する；リング構造におけるテールポインタからヘッドポインタまでの区域は有効な未読メッセージを含む；リング構造におけるヘッドポインタからテールポインタまでの区域は常に空いている。このため、ライタがリングに書込みを行う場合であってもリーダはメッセージを読取ることができ、リーダとライタとの間に同期は必要ない。

並列実行されるリーダおよびライタ
本発明の実施形態に従うと、ミドルウェアマシン環境におけるさまざまなクライアント上の複数のメッセージ送信側はミドルウェアマシン環境におけるサーバマシン上のメッセージキューに同時にアクセスすることができる。

図４は、本発明の実施形態に従った、ミドルウェアマシン環境において複数のメッセージ送信側によって同時にアクセスすることができるメッセージキューの例を示す。図４に図示のとおり、サーバ４０１は、メッセージキュー４０３を用いて、複数のクライアントたとえばクライアントＡ ４１１〜クライアントＤ ４１４からのサービス要求を同時に処理することができる。メッセージキュー４０３はサーバマシン上の共有メモリ４０２に維持することができる。各クライアントは、メッセージキュー４０３の専用コピーであり得る別個のメッセージキュー４２１〜４２４を維持することができる。さらに、各メッセージキュー４２１〜４２４がタイムリーに更新されることを確実にするために、メッセージキュー４０３のさまざまな専用コピー（すなわちメッセージキュー４２１〜４２４）をメッセージキュー４０３とたとえば周期的に同期させることができる。

本発明の実施形態に従うと、キューまたはキューにおける特定のエントリがそのときクライアントによって更新されている場合、メッセージキュー上でロックを起動させることができる。キューがサーバマシン上の共有メモリにあるので、他のすべてのクライアントは、キューがロックされていることを認識することができ、メモリのうちキュー内の特定のエントリに関連付けられる対応部分に書込みを行わないようにすることができる。さらに、メッセージの送信は、送信側でＲＤＭＡ書込み動作を実行することによって実現することができる。したがって、共有メモリにおけるキューおよびその関連付けられたヒープデータ構造についての書込みおよびアクセスの際にコンフリクションが生じないことを保証するために、受信側でラッチまたは直列化メカニズムを実現してロックする必要はない。

本発明の実施形態に従うと、クライアント同士は、キューにアクセスするために競合し得る。クライアントがキュー上でロックを獲得するかまたはキューにおける特定のエントリを獲得すれば、他のクライアントは、たとえば単一ノード環境におけるＯＳによって提供されるセマフォメカニズムを用いて、または、マルチノード環境内のＲＤＭＡアトミックスおよびラッチレスメカニズムを用いて、ロックの解放を待つことができる。

Ｓｙｓｔｅｍ Ｖメッセージキュー
本発明の実施形態に従うと、分散型トランザクションシステムは、クライアントが利用可能なサーバに作業を委託することを可能にするサーバ−クライアントモデルを用いることができる。クライアントは、作業が終わると結果を得ることができる。作業の委託およびその完了はメッセージキューを用いて伝えることができる。Ｓｙｓｔｅｍ Ｖメッセージキューは、オラクルＴｕｘｅｄｏ環境などの分散型トランザクション環境において単独のマシン上で作業の委託および完了を処理する効率的な方法を提供する。さらに、Ｓｙｓｔｅｍ Ｖメッセージキューは、複数のマシン間での作業を共有するために拡張させることができる。

図５は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのＳｙｓｔｅｍ Ｖメッセージキューを用いる例を示す。図５に図示のとおり、シャドウキュー作成モデルは、ミドルウェアマシン環境５００においてＳｙｓｔｅｍ Ｖメッセージキューに対して適用することができる。メッセージキューＱ ５１１がノードＡ ５０１上で作成されると、そのノード上のブローカ、すなわちブローカＡ ５０４に対し、メッセージキューＱ ５１１が存在していることを通知することができる。次いで、ブローカＡ ５０４は、他のノード５０２〜５０３上の同様のブローカと通信し、これらに、クラスタ内の各ノード上に同じ名前「Ｑ」を有するキューを作成させることができる。

本発明の実施形態に従うと、ノードＢ ５０２上のプロセス５０７はローカルメッセージキューＱ ５１２に書込みを行うことができる。ノードＢはメッセージキューＱ ５１１が最初に作成されたノードではないので、ノードＢ上のブローカプロセスでは、メッセージキュー５１２からメッセージを読取り、ＴＣＰ接続を用いてネットワークを介してノードＡ上のブローカＡ ５０４にメッセージを送信することができる。次いで、ブローカＡ ５０４は、ノードＡ上のメッセージキューＱ ５１１にメッセージを書込むことができる。このようにして、如何なるノード上のプロセスでも、キューがローカルであるかまたはリモートであるかどうかを実際に識別することなく、いずれのノードから作成されたキューにも書込みを行うことができる。加えて、ノードＡ上のブローカＡ ５０４はすべてのシャドウキューを絶えず監視することができ、シャドウキューのいずれかに書込まれたメッセージを、元のキューが作成されたノードＡへと伝搬させることができる。

上述のプログラミングモデルに付随する限定事項がある。たとえば、１）リモートノードからキューに書込まれたメッセージは、いくつか（たとえば５個）のメモリコピーが宛先キューに達することを必要とし得る。このため、このモデルは、ＣＰＵバスに対して多くのストレスを与える；２）多数のキューが存在する場合、環境全体がブローカの処理量に左右され、これがボトルネックになる可能性がある。および、３）このモデルは、メッセージの転送をスケーリングすることのできる利用可能なＲＤＭＡネットワークを活用しない。

ＲＤＭＡメッセージキュー
本発明の実施形態に従うと、Ｔｕｘｅｄｏシステムなどのトランザクションミドルウェアシステムは、Ｅｘａｌｏｇｉｃミドルウェアマシンなどの複数のプロセッサを備えた高速マシンおよび高性能ネットワーク接続を利用することができる。

当該システムは、Ｅｘａｌｏｇｉｃミドルウェアマシンを備えた利用可能なＲＤＭＡ対応のＩＢネットワークを用いる能力をトランザクションミドルウェアシステム、たとえばＯｒａｃｌｅ Ｔｕｘｅｄｏに与えることができる。ＲＤＭＡは、ホストチャネルアダプタ（host channel adapter：ＨＣＡ）および／またはネットワークインターフェイスカード（network interface card：ＮＩＣ）に対するメッセージ転送に付随するほとんどのＣＰＵ作業の負担を軽減することができる。当該システムは、Ｅｘａｌｏｇｉｃマシンと同様の態様で、ＴｕｘｅｄｏがＲＤＭＡ対応システム上でそのトランザクション処理容量をスケーリングするのを支援することができる。当該システムは、ユーザがＲＤＭＡを用いてＩＢネットワーク上でメッセージキューを実行させることができるように、既存のメッセージ通信インフラストラクチャ実現例にＲＤＭＡ能力を追加することができる。

図６は、本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのＲＤＭＡメッセージキューの例を示す。図６に図示のとおり、２ノードのメッセージキューは、リモートリング構造を用いてメッセージキューを表わすことができる。リモートリング構造は、リーダ側で維持される１つのリング構造６０８とライタ側で維持される別のリング構造６０５とを含む２つの標準的なリング構造上にある。ローカルマシンすなわちマシンＡ ６０１上のメッセージ送信側６０３は、たとえばＲＤＭＡプロトコル６２０を用いて、リモートマシンすなわちマシンＢ ６０２上のメッセージ受信側６０４にメッセージを送信することができる。

本発明の実施形態に従うと、メッセージ受信側は、まず、リモートマシン内の共有メモリにおいてキューを作成し、ネットワークインターフェイスカードに共有メモリ内のキューのアドレスを通知することができる。メッセージキューは、ヘッドポインタおよびテールポインタを含むリングバッファデータ構造を用いて実現することができる。加えて、メッセージ受信側は、受信メッセージを含めるよう共有メモリにおいてヒープデータ構造を実現することができる。次いで、メッセージ受信側は、共有メモリにおいてヒープデータ構造のアドレス情報とともにメッセージキューの作成についてもメッセージ送信側に通知することができる。

加えて、ライタがメッセージキューに新しいメッセージを書込む場合、システムは両方のリング構造上のリングデータおよびヘッドポインタを更新する。当該システムは、リーダがリモートノード上にある場合、ＲＤＭＡを用いてリーダ側の構造を更新することができる。同様に、リーダは、これらリーダがメッセージを読取るのに応じて両方のリングを更新させ続けることができる。

本発明の実施形態に従うと、メッセージは、リング構造へダイレクトに記憶されない。実際のメッセージをどこで検索できるかについてのメタデータだけがリング構造内に維持される。メッセージは、リーダノードにおいて維持されるヒープデータ構造６１０に記憶される。実際のメッセージは、ＲＤＭＡ書込み動作６２０を用いて、ライタプロセスからリーダノード上の割当てられたメモリにまで転送させることができる。リモートヒープ６１０の実現例は可変サイズのメッセージをサポートすることができる。このリモートヒープ６１０においては、たとえ実際のヒープメモリがリーダノード上で維持されたとしても、割当て動作および解放動作はライタノード上で遂行される。一例においては、ヒープメモリ６１０はリーダノード上にあり、ヒープメタデータ全体はライタノード上に記憶される。したがって、如何なるネットワーク通信も行わずにライタ側からヒープ割当てを行うことができる。さらに、ヒープ管理は、競合をさらに最小限にするために／リモートキューの回復を簡略化にするために、スロット割当てミューテックス／ステップから切離すことができる。

以下のリスト１は、メッセージを優先させることなくロックの助けを借りてキューが作成された場合のキュー書込みおよび読取り動作を示す擬似コードを含む。

本発明の実施形態に従うと、キュー動作全体は、さまざまなクライアントプロセスによってユーザモードで起こり得る。プロセスは、共有リング構造またはヒープメタデータを更新している間、たとえば、get_next_slot/allocate ring slotを実行しているときに、例外的に終了させることができる。回復メカニズムを用いてプロセスの終了（death）を検出し、メタデータを一定の状態にして、他のプロセスが依然として同じキュー上で動作できるようにする。

本発明の実施形態に従うと、起動メカニズムを提供することができる。リスト１中の上述の擬似コードは、単一の優先事項のために作成されるキューの場合に実行することのできるステップの概要を示す。当該システムは、また、各メッセージが優先事項を有することを可能にし、優先事項に基づいた検索を可能にする。しばしば、クライアントは、特定の何らかの特性（「ｎ」未満の優先事項または「ｎ」と等しい優先事項または「ｎ」のない優先事項など）を有するメッセージを要求する可能性がある。この要求を満たすことのできるメッセージがそのときキューに存在しない場合、クライアントプロセスをスリープモードにすることができる。このクライアントプロセスは、いずれかのノードからのプロセスが、要求を満たし得るメッセージを書込む際に、起動させることができる。特定の要求を待機するプロセスを起動させるためのメカニズムがＲＤＭＡに基づいて実現され得る。

さまざまなクライアントプロセスが、同じキュー上で読取りおよび／または書込みを行うことができる。このようなシナリオでは、キューは共有メモリ（または共有ストレージ）上で作成することができる。大抵の共有メモリベースのアプリケーションにおいては、共有データを更新する場合、ミューテックスの利用が必要となる可能性がある。込み合った読取りおよび書込み経路におけるロックを回避するために、リング構造およびアトミックなコンペア・アンド・スワップ(compare and swap：ＣＡＳ)命令に基づいた方法を実現することができる。

本発明の実施形態に従うと、メッセージ転送のためにＲＤＭＡを用いることによりメモリバスの利用を削減することができる。これによりメッセージ転送全体からＣＰＵが解放され、これにより、ＣＰＵは、メッセージの転送中に他の作業を行うことができる。さらに、当該システムは、Ｓｙｓｔｅｍ Ｖメッセージキューのためのブローカなどのボトルネックが排除された状態ではよりスケーラブルになる。このため、ＲＤＭＡを用いることにより、ＣＰＵの使用、メッセージ転送処理量およびメッセージ転送レイテンシに関して実質的な利点が得られる。

本発明の実施形態に従うと、当該システムは、ノード間メッセージ転送にＲＤＭＡを用いてメッセージキューを活用することができる。当該システムは、リモートリング構造を用いて、さまざまなマシンから同時にメッセージの読取りおよび書込みを行うことができる。当該システムは、リモートヒープが割当てられた可変サイズのメッセージを処理することができる。回復モデルを用いることにより、ローカルノード上またはリモートノード上で異常なプロセスが終了する場合にキューを回復させることができる。キューは、共有データに対するローカルな動作またはＲＤＭＡ動作を行うために、考案されたメカニズムを用いて共有メモリ上で作成される。当該システムは、メッセージを待っているリモートプロセスのためにＲＤＭＡに基づいた起動メカニズムを用いることができ、並列実行される（concurrent）リーダおよびライタが、ユーザモードプロセスから、ラッチレス同期を用いて同じキュー上で動作することが可能となる。

本発明の実施形態に従うと、当該システムは、最新のネットワークインターフェイスカードにおいて利用可能なＲＤＭＡ機構を活用することによってさまざまなノード間でキュー動作を行うためのインターフェイスを提供することができる。インターフェイスによって提供されるプログラミングインターフェイスは、Ｓｙｓｔｅｍ Ｖ ＡＰＩのインターフェイスと同様であり得る。

メッセージキューの作成および管理
本発明の実施形態に従うと、ミドルウェアマシン環境におけるサーバノード上のデーモンプロセスは、共有メモリにおいてメッセージキューを作成および管理するのに用いることができる。

図７は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを作成および管理することのできるデーモンプロセスの例を示す。図７に図示のとおり、ミドルウェアマシン環境は、サーバノード７０１ならびにいくつかのクライアントノード７０２および７０３を含み得る。サーバノードはさまざまなクライアントからメッセージを受信するための共有メモリ７０４を含み得る。共有メモリは１つ以上のメッセージキュー７１１および７１２を維持する。

本発明の実施形態に従うと、サーバノード３０１は、さまざまなクライアントがメッセージを送信および受信するようメッセージキューを設定するようサーバに要求した場合にサーバ上の共有メモリにおける１つ以上のメッセージキューの作成を担うデーモンプロセス３０６を含み得る。たとえば、クライアントＢ ７０３がサーバ７０１との接続を開始すると、サーバ上のデーモンプロセス７０６は、メッセージ制御構造７２２を介してクライアントＢ ７０３と通信するためにキューＢ ７１２を動的に作成することができる。

本発明の実施形態に従うと、サーバと複数のクライアントとの間のこの通信方式はさらにプロキシを用いて拡張させることができる。たとえば、クライアントＡ ７０２上のキュー／制御構造Ａ ７２１は、１つ以上のプロキシ、たとえばプロキシＩ ７２３〜プロキシＩＩＩ ７２５を用いて拡張させることができる。これらのプロキシを用いると、クライアントＡ上のさまざまなプロキシに関連付けられたプロセスは、キュー／制御構造Ａを用いてサーバと通信することができる。

このため、ＲＤＭＡプロトコルを用いてさまざまなサーバとクライアントとの間の通信をサポートするためのミドルウェアマシンにおいて優れたスケーラビリティを達成することができる。というのも、プロセスがサーバ７０１上のヒープデータ構造７０５にメッセージをダイレクトに書込むことを可能にすることによって、サーバの干渉なしで、クライアントＡ ７０２上のプロセスから開始されたメッセージをサーバ７０１に送信することができるからである。

本発明の実施形態に従うと、サーバ７０１上のデーモンプロセス７０６はまた、ローカルなメッセージ通信を目的として、ローカルメッセージキュー、たとえばキューＣ ７０８を作成および保存することもできる。一例においては、ローカルサーバプロセス同士がローカルメッセージキューを用いて互いに通信することができ、Ｓｙｓｔｅｍ Ｖ ＩＰＣプロトコルをＲＤＭＡプロトコルの代わりに用いることができる。なぜなら、ローカルで用いられる場合にはＩＰＣプロトコルの方がＲＤＭＡプロトコルよりも高速であるからである。

図７に図示のとおり、ローカルサーバプロセス７０７は、キューＡ ７１１およびキューＢ ７１２などのリモートメッセージキューに加えて、ローカルメッセージキューＣ ７０８からメッセージを受信することができる。ローカルサーバプロセス７０７は、ローカルメッセージキューとリモートメッセージキューとの差に対処する必要なしに、さまざまなメッセージキューからのメッセージを処理することができる。

本発明の実施形態に従うと、クライアントは、クライアント上のキューまたは制御構造を共有メモリまたは専用メモリにおいて作成できるかどうかを判断することができる。クライアントが特定のプロセスに関連付けられたクライアントマシンの専用メモリにおいてキューまたは制御構造を作成すると決めた場合、システムは、クライアント上の制御構造にアクセスするためにクライアントマシンおよびリモートマシン上の他のプロセスを妨害することができる。このことは有益となり得る。なぜなら、いくつかのメッセージが顧客の財務情報などの機密に関わる情報を含む可能性があるからである。

本発明の実施形態に従うと、中断は、サーバプロセス上で起こり得るかまたはサーバにおけるデーモンプロセス上でも起こり得る。クライアントは、サーバプロセスまたはデーモンプロセスの回復を待つ必要なしに、サーバマシン上の共有メモリにおいてＲＤＭＡ書込み動作を実行し続けることができる。これにより、システムのための障害回復を堅調かつ簡単明瞭なものにする。加えて、クライアントは、キューがフルである場合に、サーバマシン上の共有メモリへの書込みを停止させることができる。

図８は、本発明の実施形態に従った、トランザクションミドルウェアマシン環境においてメッセージキューを作成および管理するための例示的なフローチャートを示す。図８に図示のとおり、ステップ８０１において、サーバは、ミドルウェアマシン環境において１つ以上のメッセージキューを維持する共有メモリをメッセージ受信側に設けることができる。次いで、ステップ８０２において、クライアントは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューをサーバ上で設定することを要求する。最後に、ステップ８０３において、サーバがクライアント要求を受信すると、サーバ上のデーモンプロセスは、共有メモリにおいて少なくとも１つのメッセージキューを動的に作成することができる。

メッセージキューを保護するためのセキュリティモデル
本発明の実施形態に従うと、ミドルウェアマシン環境においてメッセージキューを保護するのにセキュリティモデルを用いることができる。

図９は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するのに用いることのできるセキュリティモデルの例を示す。図９に図示のとおり、メッセージ受信側９０２はメッセージ送信側９０１と通信するよう構成することができる。メッセージ受信側９０２に関連付けられるサーバノード上のデーモンプロセス９１０は、デーモンプロセスが最初にメッセージ送信側９０１と通信するためにサーバマシン上の共有メモリ９０４においてメッセージキュー９０６を作成する場合に、キーまたはセキュリティトークン９１４を作成することができる。

本発明の実施形態に従うと、デーモンプロセス９１０はさらに、ＩＢネットワークにキーまたはセキュリティトークン９１４を登録し、セキュリティ保護されたネットワーク９２０を介してクライアントノード上でメッセージ送信側９１０にセキュリティトークン９１４を送信することができる。図９に図示のとおり、メッセージ送信側９０１をデーモンプロセス９０５に関連付けることもできる。メッセージ送信側９０１のデーモンプロセス９１０とメッセージ受信側９０２のデーモンプロセス９０５との間のセキュリティ保護されたネットワーク９２０において別個の通信リンク、たとえば専用のプロセス、が存在し得る。

本発明の実施形態に従うと、メッセージ送信側９０１がセキュリティトークン９１４を受信した後、メッセージ送信側９０１は受信側マシン内の共有メモリ９０４にダイレクトアクセスすることができる。図９に図示のとおり、クライアントノード上のメッセージ送信側９０１は、セキュリティトークン９１４を用いて、受信側の共有メモリ９０４内のヒープデータ構造９０８においてメッセージをダイレクトに書込むためのＲＤＭＡ書込み動作９２１を実行することができる。

図１０は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するための例示的なフローチャートを示す。図１０に図示のとおり、ステップ１００１において、メッセージ受信側のデーモンプロセスは、デーモンプロセスが最初にクライアントノードと通信するためにサーバノード上で共有メモリにおいてメッセージキューを作成すると、サーバノード上でセキュリティトークンを作成することができる。次いで、ステップ１００２において、メッセージ受信側のデーモンプロセスは、作成されたセキュリティトークンを、セキュリティ保護されたネットワークを介してサーバノードからクライアントノードに送信することができる。最後に、ステップ１００３において、クライアント側でセキュリティトークンを受信した後、メッセージ送信側は共有メモリ内のメッセージキューにダイレクトにメッセージを書込むことができる。

この発明は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取り可能な記憶媒体を含む１つ以上の従来の汎用のまたは特化されたデジタルコンピュータ、演算装置、マシンまたはマイクロプロセッサを用いて、好都合に実現され得る。ソフトウェア技術の当業者に明らかとなるように、適切なソフトウェアコーディングは、熟練したプログラマによって本開示の教示に基づき容易に準備され得る。

いくつかの実施形態においては、本発明は、本発明のプロセスのいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令を格納した記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気または光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／またはデータを格納するのに適した任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。

本発明の上述の記載は、例示および説明を目的として与えられており、網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正例および変形例が明確となるであろう。上記の実施形態は、本発明の原理およびその実際的な適用を最もよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に適したさまざまな修正例を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの同等例によって定義されるよう意図されている。

Claims (10)

1. ミドルウェアマシン環境においてメッセージキューを提供するためのシステムであって、
   前記ミドルウェアマシン環境において提供される複数のサーバマシンを備え、
   前記複数のサーバマシンの１つであるメッセージ受信側のサーバマシンは、第１のリング構造を有する第１のメッセージ制御データ構造体と、当該メッセージ受信側に関連付けられるヒープデータ構造体とが形成された共有メモリを含んでおり、前記共有メモリは他のサーバマシンからアクセス可能であり、
   前記複数のサーバマシンの別の１つであるメッセージ送信側のサーバマシンは、第２のリング構造を有する第２のメッセージ制御データ構造体が形成されたメモリを含んでおり、前記第２のメッセージ制御データ構造体は、前記メッセージ受信側のサーバマシンからの通知に応じて前記第１のメッセージ制御データ構造体とともに更新され、
   前記第１のリング構造および前記第２のリング構造の各々は、最新のメッセージを指すヘッドポインタおよび最も古いメッセージを指すテールポインタを有しており、
   前記メッセージ送信側のサーバマシンは、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコルを用いて、前記共有メモリ内のヒープデータ構造体にメッセージを書込むと、前記ヒープデータ構造体に書込んだメッセージを特定するための、前記メッセージに関連付けられるメタデータを、前記第１のメッセージ制御データ構造体に維持するとともに、当該メタデータに応じて、前記第１のリング構造および前記第２のリング構造の両方についての前記ヘッドポインタを更新し、
   前記メッセージ受信側のサーバマシンは、前記共有メモリ内のヒープデータ構造体からメッセージを読取ると、前記第１のリング構造についての前記テールポインタを更新するとともに、前記第１のリング構造の更新を前記メッセージ送信側のサーバマシンへ通知する、システム。
2. 前記メッセージ受信側のサーバマシンには、前記メッセージ送信側として、複数のクライアントが接続されており、
   前記複数のクライアントの各々は、前記共有メモリにおいて維持される前記第１のメッセージ制御データ構造体の専用コピーを保持する、請求項１に記載のシステム。
3. 前記第１のメッセージ制御データ構造体におけるエントリがクライアントによって更新されているとき、前記第１のメッセージ制御データ構造体上でロックが起動される、請求項２に記載のシステム。
4. 他のすべてのクライアントは、前記第１のメッセージ制御データ構造体がロックされていることを認識することができ、かつ、前記共有メモリのうち、前記第１のメッセージ制御データ構造体におけるエントリに関連付けられる対応部分にアクセスしないようにすることができる、請求項３に記載のシステム。
5. 別のクライアントが、前記共有メモリのうち、メッセージキューにおけるエントリに関連付けられる別の部分にアクセスすることが可能となる、請求項４に記載のシステム。
6. 複数のサーバマシンが提供されるミドルウェアマシン環境においてメッセージキューを提供するための方法であって、
   前記複数のサーバマシンの１つであるメッセージ受信側のサーバマシンの共有メモリ内に、第１のリング構造を有する第１のメッセージ制御データ構造体を形成するステップを備え、前記共有メモリは他のマシンからアクセス可能であり、
   前記共有メモリ内に前記メッセージ受信側のサーバマシンに関連付けられるヒープデータ構造体を形成するステップと、
   前記複数のサーバマシンの別の１つであるメッセージ送信側のサーバマシンのメモリ内に、第２のリング構造を有する第２のメッセージ制御データ構造体を形成するステップを備え、前記第１のリング構造および前記第２のリング構造の各々は、最新のメッセージを指すヘッドポインタおよび最も古いメッセージを指すテールポインタを有しており、
   前記メッセージ送信側のサーバマシンが、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコルを用いて、前記共有メモリ内のヒープデータ構造体にメッセージを書込むステップと、
   前記メッセージ送信側のサーバマシンが、前記ヒープデータ構造体に書込んだメッセージの前記共有メモリのアドレスを特定するための、前記メッセージに関連付けられるメタデータを、前記第１のメッセージ制御データ構造体に維持するとともに、当該メタデータに応じて、前記第１のリング構造および前記第２のリング構造の両方についての前記ヘッドポインタを更新するステップと、
   前記メッセージ受信側のサーバマシンが、前記共有メモリ内のヒープデータ構造体からメッセージを読取ると、前記第１のリング構造についての前記テールポインタを更新するとともに、前記第１のリング構造の更新を前記メッセージ送信側のサーバマシンへ通知するステップとを含む、方法。
7. メッセージ受信側が複数のクライアントに接続されるサーバ上に存在することを可能にするステップをさらに含み、各々の前記クライアントは、共有メモリにおいて維持される第１のメッセージ制御データ構造の専用コピーを保持する、請求項６に記載の方法。
8. 第１のメッセージ制御データ構造におけるエントリがクライアントによって更新されているとき、第１のメッセージ制御データ構造上でロックを起動させるステップをさらに含む、請求項７に記載の方法。
9. 他のすべてのクライアントが第１のメッセージ制御データ構造がロックされていることを認識できること、および、共有メモリのうち、第１のメッセージ制御データ構造におけるエントリに関連付けられる対応部分にアクセスしないようにすることができることを可能にする、請求項８に記載の方法。
10. 別のクライアントが、共有メモリのうち、メッセージキューにおけるエントリに関連付けられる別の部分にアクセスすることを可能にするステップをさらに含む、請求項９に記載の方法。