(57)【要約】  ミドルウェアマシン環境は、マルチノードアプリケーションのためのメッセージキューを提供することができる。トランザクションミドルウェアマシン環境は、メッセージ受信側のメッセージ制御データ構造と、共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含む。メッセージ送信側は、メッセージをヒープデータ構造にダイレクトに書込み、かつメッセージ制御データ構造においてメッセージに関連付けられるメタデータを維持するよう動作する。さらに、ミドルウェアマシン環境は、メッセージ受信側に共有メモリを含む。共有メモリは、ミドルウェアマシン環境のための１つ以上のメッセージキューを維持する。加えて、ミドルウェアマシン環境は、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューを設定することをクライアントが要求する場合に共有メモリにおいて少なくとも１つのメッセージキューを作成することのできるデーモンプロセスを含む。
2014531687.tif 000002
【特許請求の範囲】
【請求項１】
ミドルウェアマシン環境においてメッセージキューを提供するためのシステムであって、
１つ以上のマイクロプロセッサと、
メッセージ受信側に第１のメッセージ制御データ構造と、
共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含み、
１つ以上のマイクロプロセッサ上で実行されるメッセージ送信側は、
ヒープデータ構造にダイレクトにメッセージを書込み、
第１のメッセージ制御データ構造において前記メッセージに関連付けられるメタデータを維持するよう動作する、システム。
【請求項２】
メッセージ送信側に第２のメッセージ制御データ構造をさらに含み、メッセージ送信側は、第２のメッセージ制御データ構造において前記メッセージに関連付けられたメタデータを維持するよう動作する、請求項１に記載のシステム。
【請求項３】
第１のメッセージ制御データ構造が第１のリング構造である、請求項２に記載のシステム。
【請求項４】
第２のメッセージ制御データ構造が第２のリング構造である、請求項３に記載のシステム。
【請求項５】
第１のリング構造および第２のリング構造の各々がヘッドポインタおよびテールポインタを有する、請求項４に記載のシステム。
【請求項６】
ライタは、ヒープデータ構造に対するメッセージを共有メモリに書込むよう動作するとき、第１のリング構造および第２のリング構造の両方のためにヘッドポインタを更新し、
リーダは、共有メモリ内のヒープデータ構造に対するメッセージを読取るよう動作するとき、第１のリング構造および第２のリング構造の両方のためにテールポインタを更新する、請求項５に記載のシステム。
【請求項７】
メッセージ受信側は、複数のクライアントに接続されたサーバ上にあり、各々の前記クライアントは、共有メモリにおいて維持される第１のメッセージ制御データ構造の専用コピーを保持する、請求項１に記載のシステム。
【請求項８】
第１のメッセージ制御データ構造におけるエントリがクライアントによって更新されているとき、第１のメッセージ制御データ構造上でロックが起動される、請求項７に記載のシステム。
【請求項９】
他のすべてのクライアントは、第１のメッセージ制御データ構造がロックされていることを認識することができ、かつ、共有メモリのうち、第１のメッセージ制御データ構造におけるエントリに関連付けられる対応部分にアクセスしないようにすることができる、請求項８に記載のシステム。
【請求項１０】
別のクライアントが、共有メモリのうち、メッセージキューにおけるエントリに関連付けられる別の部分にアクセスすることが可能となる、請求項９に記載のシステム。
【請求項１１】
ミドルウェアマシン環境においてメッセージキューを提供するための方法であって、
メッセージ受信側に第１のメッセージ制御データ構造を提供するステップと、
共有メモリ内のヒープデータ構造をメッセージ受信側に関連付けるステップと、
１つ以上のマイクロプロセッサ上で実行されるメッセージ送信側が、
ヒープデータ構造にダイレクトにメッセージを書込み、
第１のメッセージ制御データ構造においてメッセージに関連付けられたメタデータを維持することを可能にするステップとを含む、方法。
【請求項１２】
第２のメッセージ制御データ構造をメッセージ送信側に関連付けるステップをさらに含み、メッセージ送信側は、第２のメッセージ制御データ構造においてメッセージに関連付けられたメタデータを維持するよう動作する、請求項１１に記載の方法。
【請求項１３】
第１のメッセージ制御データ構造が第１のリング構造となることを可能にするステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
第２のメッセージ制御データ構造が第２のリング構造となることを可能にするステップをさらに含む、請求項１３に記載の方法。
【請求項１５】
第１のリング構造および第２のリング構造の各々がヘッドポインタおよびテールポインタを有することを可能にするステップをさらに含む、請求項１４に記載の方法。
【請求項１６】
ライタが、ヒープデータ構造に対するメッセージを共有メモリに書込むよう動作するとき、第１のリング構造および第２のリング構造の両方のためにヘッドポインタを更新することを可能にするステップと、
リーダが、共有メモリ内のヒープデータ構造に対するメッセージを読取るよう動作するとき、第１のリング構造および第２のリング構造の両方のためにテールポインタを更新することを可能にするステップとをさらに含む、請求項１５に記載の方法。
【請求項１７】
メッセージ受信側が複数のクライアントに接続されるサーバ上に存在することを可能にするステップをさらに含み、各々の前記クライアントは、共有メモリにおいて維持される第１のメッセージ制御データ構造の専用コピーを保持する、請求項１１に記載の方法。
【請求項１８】
第１のメッセージ制御データ構造におけるエントリがクライアントによって更新されているとき、第１のメッセージ制御データ構造上でロックを起動させるステップをさらに含む、請求項１７に記載の方法。
【請求項１９】
他のすべてのクライアントが第１のメッセージ制御データ構造がロックされていることを認識できること、および、共有メモリのうち、第１のメッセージ制御データ構造におけるエントリに関連付けられる対応部分にアクセスしないようにすることができることを可能にする、請求項１８に記載の方法。
【請求項２０】
別のクライアントが、共有メモリのうち、メッセージキューにおけるエントリに関連付けられる別の部分にアクセスすることを可能にするステップをさらに含む、請求項１９に記載の方法。
【請求項２１】
ミドルウェアマシン環境においてメッセージキューを管理するためのシステムであって、
１つ以上のマイクロプロセッサと、
メッセージ受信側に共有メモリとを含み、共有メモリはミドルウェアマシン環境において１つ以上のメッセージキューを維持し、前記システムはさらに、
１つ以上のマイクロプロセッサ上で実行されるデーモンプロセスを含み、前記デーモンプロセスは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合、共有メモリにおける少なくとも１つのメッセージキューを作成することができる、システム。
【請求項２２】
クライアント上のさまざまなプロセスが、少なくとも１つのプロキシを用いてメッセージサーバと通信するよう動作する、請求項２１に記載のシステム。
【請求項２３】
メッセージキューが第２のサーバノードと通信するために第１のサーバノード上の共有メモリにおいて作成されると、デーモンプロセスはさらに、第１のサーバノード上でセキュリティトークンを作成することができる、請求項２１に記載のシステム。
【請求項２４】
デーモンプロセスはさらに、第１のセキュリティ保護されたネットワークを介して第１のサーバノードから第２のサーバノードにセキュリティトークンを送信することができる、請求項２３に記載のシステム。
【請求項２５】
デーモンプロセスはさらに、第２のサーバノードがセキュリティトークンを用いて共有メモリ内のメッセージキューにメッセージを送信することを可能にすることができる、請求項２４に記載のシステム。
【請求項２６】
デーモンプロセスは、ローカルなメッセージ通信のためにローカルメッセージキューを作成および保存することができる、請求項２１に記載のシステム。
【請求項２７】
ローカルメッセージキューは共有メモリの外部にある、請求項２６に記載のシステム。
【請求項２８】
ローカルサーバプロセスは、ローカルメッセージキューおよび少なくとも１つのリモートメッセージキューの両方からメッセージを受信するよう動作する、請求項２６に記載のシステム。
【請求項２９】
クライアントは、キューが共有メモリまたは専用メモリ上で作成されるかどうかを判断することができる、請求項２１に記載のシステム。
【請求項３０】
サーバマシン上で中断が起こった場合、クライアントは、回復を待つことなく、サーバマシン上の共有メモリにおいて書込み動作を実行し続けることができる、請求項２１に記載のシステム。
【請求項３１】
ミドルウェアマシン環境においてメッセージキューを管理するための方法であって、
メッセージ受信側に共有メモリを提供するステップを含み、共有メモリはミドルウェアマシン環境において１つ以上のメッセージキューを維持し、前記方法はさらに、
メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合、１つ以上のマイクロプロセッサ上で実行されるデーモンプロセスを介して、共有メモリ内に少なくとも１つのメッセージキューを作成するステップを含む、方法。
【請求項３２】
クライアント上のさまざまなプロセスが少なくとも１つのプロキシを用いてメッセージサーバと通信することを可能にするステップをさらに含む、請求項３１に記載の方法。
【請求項３３】
第２のサーバノードと通信するために第１のサーバノード上の共有メモリにおいてメッセージキューが作成されるときに第１のサーバノード上でセキュリティトークンを作成するステップをさらに含む、請求項３１に記載の方法。
【請求項３４】
第１のセキュリティ保護されたネットワークを介して第１のサーバノードから第２のサーバノードにセキュリティトークンを送信するステップをさらに含む、請求項３３に記載の方法。
【請求項３５】
第２のサーバノードがセキュリティトークンを用いて、共有メモリ内のメッセージキューにメッセージを送信することを可能にするステップをさらに含む、請求項３４に記載の方法。
【請求項３６】
ローカルなメッセージ通信のためにローカルメッセージキューを作成および保存するステップをさらに含む、請求項３１に記載の方法。
【請求項３７】
ローカルメッセージキューが共有メモリの外部にあることを可能にするステップをさらに含む、請求項３６に記載の方法。
【請求項３８】
ローカルサーバプロセスがローカルメッセージキューおよび少なくとも１つのリモートメッセージキューの両方からメッセージを受信することを可能にするステップをさらに含む、請求項３６に記載の方法。
【請求項３９】
キューが共有メモリまたは専用メモリ上で作成されるかどうかをクライアントが判断することを可能にするステップをさらに含む、請求項３１に記載の方法。
【請求項４０】
サーバマシン上で中断が起こった場合、クライアントが、回復を待つことなく、サーバマシン上の共有メモリにおいて書込み動作を実行し続けることを可能にするステップをさらに含む、請求項３１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権表示：
この特許文書の開示の一部は、著作権の保護下にある内容を含む。著作権所有者は、特許商標庁の特許ファイルまたは記録に現れるので、誰でも当該特許文書または特許開示を複製することについて異議を唱えないが、そうでなければ如何なる場合でもすべての著作権を留保する。
【０００２】
発明の分野：
この発明は、概して、ミドルウェアなどのコンピュータシステムおよびソフトウェアに関し、特に、トランザクションミドルウェアマシン環境をサポートすることに関する。
【背景技術】
【０００３】
背景：
トランザクションミドルウェアシステムまたはトランザクション指向のミドルウェアは、構成内におけるさまざまなトランザクションを処理することのできるエンタープライズアプリケーションサーバを含む。高性能ネットワークおよびマルチプロセッサコンピュータなどの新技術の開発に伴い、トランザクションミドルウェアの性能をさらに向上させる必要がある。これらは、概して、本発明の実施形態が対処するよう意図された分野である。
【発明の概要】
【課題を解決するための手段】
【０００４】
概要：
ミドルウェアマシン環境においてメッセージキューを設けるためのシステムおよび方法をこの明細書中に記載する。トランザクションミドルウェアマシン環境は、メッセージ受信側にメッセージ制御データ構造と、共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含む。メッセージ送信側は、メッセージをヒープデータ構造にダイレクトに書込み、メッセージ制御データ構造においてメッセージに関連付けられるメタデータを維持するよう動作する。さらに、ミドルウェアマシン環境は、メッセージ受信側に共有メモリを含む。共有メモリは、ミドルウェアマシン環境のための１つ以上のメッセージキューを維持する。加えて、ミドルウェアマシン環境はデーモンプロセスを含む。このデーモンプロセスは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合、共有メモリにおいて少なくとも１つのメッセージキューを作成することができる。
【図面の簡単な説明】
【０００５】
【図１】本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを提供する例を示す図である。
【図２】本発明の実施形態に従った、ミドルウェアマシン環境において正確なロードバランスをサポートするための例示的なフローチャートを示す図である。
【図３】本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのリモートメモリリングを提供する例を示す図である。
【図４】本発明の実施形態に従った、ミドルウェアマシン環境において複数のメッセージ送信側によって同時にアクセスすることのできるメッセージキューの例を示す図である。
【図５】本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのＳｙｓｔｅｍ  Ｖメッセージキューを用いる例を示す図である。
【図６】本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのリモートダイレクトメモリアクセス（remote direct memory access：ＲＤＭＡ）メッセージキューの例を示す図である。
【図７】本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを作成および管理することのできるデーモンプロセスの例を示す図である。
【図８】本発明の実施形態に従った、トランザクションミドルウェアマシン環境において正確なロードバランスをサポートするための例示的なフローチャートを示す図である。
【図９】本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するのに用いることができるセキュリティモデルの例を示す図である。
【図１０】本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するための例示的なフローチャートを示す図である。
【発明を実施するための形態】
【０００６】
詳細な説明：
トランザクションミドルウェアマシン環境において複数のプロセッサを備えた高速マシンおよび高性能ネットワーク接続を活用することのできるトランザクションミドルウェアシステムを、サポートするためのシステムおよび方法をこの明細書中に記載する。当該システムは、リングバッファ（円形のキュー）に基づいたデータ構造を用いてマルチノードアプリケーションのためのメッセージキューを設けることができる。当該システムは、リーダ上に第１のリング構造とライタ上に第２のリング構造とを備えたリモートリング構造を含む。第１のリング構造および第２のリング構造の各々は、ヘッドポインタおよびテールポインタを有する。ライタは、リモートリングにメッセージを書込むよう動作すると、第１のリング構造および第２のリング構造の両方のためにヘッドポインタと、リモートリング構造におけるデータとを更新し得る。リーダは、リモートリングからメッセージを読取るよう動作すると、第１のリング構造および第２のリング構造の両方のためにテールポインタを更新し得る。加えて、メッセージをヒープデータ構造に記憶させることができ、メッセージに関連付けられるメタデータをリモートリング構造に記憶させることができる。
【０００７】
本発明の実施形態に従うと、当該システムは、高性能ハードウェア（たとえば６４ビットプロセッサ技術、高性能の大規模メモリ、ならびに冗長なＩｎｆｉｎｉＢａｎｄおよびイーサネット（登録商標）ネットワーキング）と、ＷｅｂＬｏｇｉｃ  Ｓｕｉｔｅなどのアプリケーションサーバまたはミドルウェア環境との組合せを含み、これにより、迅速に設けられ得るとともにオンデマンドでスケール変更可能な大規模並列メモリグリッドを含む完全なＪａｖａ（登録商標）ＥＥアプリケーションサーバコンプレックスを提供する。一実施形態に従うと、当該システムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびＩｎｆｉｎｉＢａｎｄ（ＩＢ）ネットワークを提供するフルラック、ハーフラック、もしくはクォーターラック、または他の構成として展開され得る。ミドルウェアマシンソフトウェアは、たとえばＷｅｂＬｏｇｉｃ  Ｓｅｒｖｅｒ、ＪＲｏｃｋｉｔまたはＨｏｔｓｐｏｔ  ＪＶＭ、Ｏｒａｃｌｅ  Ｌｉｎｕｘ（登録商標）またはＳｏｌａｒｉｓ、およびＯｒａｃｌｅ  ＶＭといった、アプリケーションサーバと、ミドルウェアと、他の機能性とを提供し得る。当該システムは、ＩＢネットワークを介して互いに通信する複数の計算ノードと、ＩＢスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。ラック構成として実現される場合、当該ラックの未使用部分は空のままとされ得るかまたはフィラー（filler）によって占有され得る。
【０００８】
本願明細書において「Ｓｕｎ  Ｏｒａｃｌｅ  Ｅｘａｌｏｇｉｃ」または「Ｅｘａｌｏｇｉｃ」と称される本発明の実施形態に従うと、当該システムは、Ｏｒａｃｌｅ  Ｍｉｄｄｌｅｗａｒｅ  ＳＷ  ｓｕｉｔｅまたはＷｅｂｌｏｇｉｃといったミドルウェアまたはアプリケーションサーバソフトウェアをホストするための、展開が容易なソリューションである。本願明細書に記載されるように、当該システムは、１つ以上のサーバと、ストレージユニットと、ストレージネットワーキングのためのＩＢファブリックと、ミドルウェアアプリケーションをホストするのに必要な他のすべてのコンポーネントとを含む「グリッド・イン・ア・ボックス（grid in a box）」である。たとえばＲｅａｌ  Ａｐｐｌｉｃａｔｉｏｎ  ＣｌｕｓｔｅｒｓおよびＥｘａｌｏｇｉｃ  ｏｐｅｎ  ｓｔｏｒａｇｅを用いて大規模並列グリッドアーキテクチャを活用することにより、すべてのタイプのミドルウェアアプリケーションのために有意な性能が与えられ得る。このシステムは、線形のＩ／Ｏスケーラビリティとともに向上した性能を与え、使用および管理が簡潔であり、ミッションクリティカルな可用性および信頼性を与える。
【０００９】
本発明の実施形態に従うと、Ｔｕｘｅｄｏは１セットのソフトウェアモジュールであって、高性能の分散型ビジネスアプリケーションの構築、実行および管理を可能にし、複数の多層アプリケーション開発ツールによってトランザクションミドルウェアとして用いられてきた。Ｔｕｘｅｄｏは、分散型コンピューティング環境における分散型トランザクション処理を管理するのに用いることができるミドルウェアプラットフォームであり、無限のスケーラビリティおよび規格ベースの相互運用性を提供しつつ、エンタープライズレガシーアプリケーションをアンロックし、サービス指向のアーキテクチャーへと拡張するための検証済みのプラットフォームである。
【００１０】
本発明の一実施形態に従うと、ミドルウェアマシン環境は、マルチノードアプリケーションのためのメッセージキューを与えることができる。トランザクションミドルウェアマシン環境は、メッセージ受信側にメッセージ制御データ構造と、共有メモリ内に、メッセージ受信側に関連付けられるヒープデータ構造とを含む。メッセージ送信側は、ヒープデータ構造にダイレクトにメッセージを書込み、メッセージ制御データ構造においてメッセージに関連付けられるメタデータを維持するよう動作する。さらに、メッセージ制御データ構造は、ヘッドポインタおよびテールポインタを備えたリング構造であってもよい。加えて、メッセージ受信側は複数のクライアントに接続されるサーバ上に存在し、上記クライアントの各々は、メッセージ制御データ構造の専用コピーを保持する。また、メッセージ受信側は、メッセージ受信側に関連付けられたメッセージ制御データ構造への同時アクセスをサポートすることができる。
【００１１】
本発明の別の実施形態に従うと、ミドルウェアマシン環境は、マルチモードアプリケーションのためのメッセージキューを管理することができる。ミドルウェアマシン環境は、メッセージ受信側に共有メモリを含む。共有メモリは、ミドルウェアマシン環境のために１つ以上のメッセージキューを維持する。ミドルウェアマシン環境はさらにデーモンプロセスを含む。デーモンプロセスは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューが設定されることをクライアントが要求する場合に、共有メモリにおいて少なくとも１つのメッセージキューを作成することができる。加えて、クライアント上のさまざまなプロセスは、少なくとも１つのプロキシを用いてメッセージサーバと通信するよう動作する。さらに、ミドルウェアマシン環境は、デーモンプロセスによって作成されたセキュリティトークンを用いて、マルチモードアプリケーションのためのメッセージキューを保護することができる。
【００１２】
マルチノードアプリケーションのためのメッセージキュー
本発明の実施形態に従うと、メッセージ通信キューなどのメッセージ通信ソフトウェアは、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコルを用いてＩＢネットワークなどの高性能ネットワークを活用し得る。ＲＤＭＡプロトコルは、メッセージ送信側が、リモートマシン上のプロセスを起動させる必要なしに、ＯＳカーネルをバイパスしてメモリにダイレクトアクセスすることを可能にする。
【００１３】
図１は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを与える例を示す。図１に図示のとおり、ミドルウェアマシン環境１００は、マシンＡ  １０１およびマシンＢ  １０２などの複数のサーバマシンを含み得る。ローカルマシンたとえばマシンＡ  １０１上のメッセージ送信側１０３は、リモートマシンたとえばマシンＢ  １０２上のメッセージ受信側１０４にメッセージ１０７を送信することができる。リモートマシンＢ  １０２上のメッセージ受信側１０４は、メッセージキューまたはメッセージ制御データ構造１０８およびヒープデータ構造１１０を含む共有メモリ１０６を用いることができる。
【００１４】
本発明の実施形態に従うと、メッセージキューは、メッセージに関連付けられたメタデータ情報だけを含み得る一方で、ヒープデータ構造は物理的なメッセージを含む。このため、可変サイズのメッセージに容易に対処することができ、この可変サイズのメッセージを共有メモリに記憶することができる。図１に図示のとおり、メッセージ送信側１０３はヒープデータ構造１１０にダイレクトにメッセージを書込み、かつメッセージ制御データ構造１０８においてメッセージに関連付けられたメタデータを維持するよう動作する。
【００１５】
また、図１に図示のとおり、メッセージ送信側１０３は、ローカルマシン、すなわちマシンＡ  １０１、上にメッセージ制御データ構造１０５を含む。メッセージ制御データ構造１０５は、メッセージ送信側１０３のためのメッセージキュー１０８のコピーであり得る。ローカルマシンＡ  １０１上のメッセージ送信側はさらに、ローカルマシンＡ  １０１上のメッセージ制御データ構造１０５においてメッセージに関連付けられたメタデータを維持することができる。
【００１６】
本発明の実施形態に従うと、ローカルマシンＡ  １０１上のメッセージ送信側は、リモートマシンＢ  １０２上の共有メモリ１０６内のヒープデータ構造１１０にダイレクトにメッセージを書込むことができる。図１に図示のとおり、メッセージ送信側１０３は、メッセージ受信側１０４によって提供されるアドレス指定情報を用いてリモートマシンＢ  １０２上のＯＳカーネルをバイパスすることができる。さらに、ローカルマシンＡ  １０１上のメッセージ送信側１０３は、ローカルマシンＡ  １０１上の制御構造を介してリモートマシンＢ  １０２内のキューにおいて入力シーケンス番号などのメッセージの状況情報を更新することができる。
【００１７】
さらに、ローカルマシンＡ  １０１上のメッセージ送信側１０３は、メッセージのサイズに関わらず、メッセージ受信側１０４にメッセージを送信することができる。したがって、このメッセージ通信メカニズムは、コスト効率が良く効率的なものであり得、大量のデータのためのオーバーヘッドをさほど必要としない。
【００１８】
加えて、メッセージ送信側１０３は、予め構成された手順に従って、メッセージ受信側１０４に関連付けられたリモートマシンＢ  １０２上のプロセス１１２を起動させることができる。たとえば、メッセージ送信側は、プロセスによって処理することのできるサービス要求メッセージが配信された場合にプロセスを起動させることができる。別の例においては、キューがフルである場合、メッセージ送信側は、リモートマシンＢ  １０２上のデーモンプロセスを起動させることができる。
【００１９】
本発明の実施形態に従うと、メッセージ受信側のプロセス、たとえばプロセス１１２がスリープに入る前に、当該プロセスは、クライアント側のメッセージ制御構造１０５を認識することができる、および／または、それ自体を如何に起動させるかについての手順をメッセージ制御構造１０５に提供することができる。次いで、受信側のプロセスはメッセージの配信を待つことができる。たとえば、メッセージが来ることを予想しているプロセスは、メッセージ送信側によって起動されるまでスリープ状態であってもよい。
【００２０】
また、図１に図示のとおり、メッセージ受信側１０４がメッセージを使い果たした後、メッセージ受信側はキューからメッセージを取出すことでき、この場合、メッセージ受信側は、ＲＤＭＡ書込み動作を実行することによってメッセージキュー１０８と送信側の制御構造１０５とを更新することができる。このようなＲＤＭＡ書込み動作は、リモートマシンＢ  １０２上のクライアントから干渉のない態様で実行することができる。
【００２１】
本発明の実施形態に従うと、ミドルウェアマシン環境において２つのサーバ間で双方向通信をサポートするために、ミドルウェアマシン上の各サーバは受信側および送信側を備え得る。このため、これら２つのサーバ間の通信は、ＲＤＭＡ書込み動作などのＲＤＭＡプロトコルを用いて、さまざまなマシンにおいてさまざまなメッセージ送信側によって実行することができる。
【００２２】
図２は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのメッセージキューを与えるための例示的なフローチャートを示す。図２に図示のとおり、ステップ２０１において、システムはメッセージ受信側に第１のメッセージ制御データ構造を設けることができる。ステップ２０２において、システムは、共有メモリ内のヒープデータ構造をメッセージ受信側に関連付けることができる。次いで、２０３において、システムは、メッセージ送信側がヒープデータ構造にメッセージをダイレクトに書込み、第１のメッセージ制御データ構造においてメッセージに関連付けられたメタデータを維持することを可能にする。
【００２３】
リモートメモリリング
本発明の実施形態に従うと、リングバッファ（円形のキュー）に基づいたデータ構造は、このシステムのバックボーンになり得る。簡素化された場合には、このリング構造は先入れ先出し（first-in first-out：ＦＩＦＯ）キューとして機能し得る。
【００２４】
図３は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのリモートメモリリングを設ける例を示す。図３に図示のとおり、メッセージ送信側３０１およびメッセージ受信側３０２はともに、メッセージ制御データ構造としてリング構造を用いることができ、各々のリング構造はヘッドポインタおよびテールポインタを備えることができる。メッセージ送信側３０１がメッセージリーダ３０２上のメッセージキュー、たとえば共有メモリ内のヒープデータ構造、にメッセージを書込むよう動作すると、メッセージ送信側３０１は両方のリング構造のためにヘッドポインタ３０３および３０４を更新することができる。他方で、メッセージ受信側３０２またはリーダが共有メモリ内のヒープデータ構造からメッセージを読取るよう動作すると、リーダは両方のリング構造のためにテールポインタ３０５および３０６を更新する。
【００２５】
本発明の実施形態に従うと、リング構造内のヘッドポインタは、メッセージキューに加えられた最新のメッセージを指し、リング構造内のテールポインタはメッセージキューにおける最も古いメッセージを指す。アクティブなメッセージがヘッドポインタとテールポインタとの間に記憶される。メッセージ送信側またはライタは、キューのヘッドポインタとテールポインタとの間の自由空間（図３におけるリング構造の白い部分）を参照して、新しいメッセージを書込むのに応じてヘッドポインタを前方に移動させることができる。他方で、メッセージリーダは、キューのヘッドポインタとテールポインタとの間（図３におけるリング構造の影付き部分）を参照して、新しいメッセージを得て、これらリーダがメッセージを読取るのに応じてテールポインタを前方に移動させることができる。これにより、ヘッドポインタおよびテールポインタをともに確実に一方向のみに移動させる。
【００２６】
本発明の実施形態に従うと、各々のリング動作のために以下の限定事項が維持され得る：リーダだけがテールポインタを更新する；ライタだけがヘッドポインタを更新する；リング構造におけるテールポインタからヘッドポインタまでの区域は有効な未読メッセージを含む；リング構造におけるヘッドポインタからテールポインタまでの区域は常に空いている。このため、ライタがリングに書込みを行う場合であってもリーダはメッセージを読取ることができ、リーダとライタとの間に同期は必要ない。
【００２７】
並列実行されるリーダおよびライタ
本発明の実施形態に従うと、ミドルウェアマシン環境におけるさまざまなクライアント上の複数のメッセージ送信側はミドルウェアマシン環境におけるサーバマシン上のメッセージキューに同時にアクセスすることができる。
【００２８】
図４は、本発明の実施形態に従った、ミドルウェアマシン環境において複数のメッセージ送信側によって同時にアクセスすることができるメッセージキューの例を示す。図４に図示のとおり、サーバ４０１は、メッセージキュー４０３を用いて、複数のクライアントたとえばクライアントＡ  ４１１〜クライアントＤ  ４１４からのサービス要求を同時に処理することができる。メッセージキュー４０３はサーバマシン上の共有メモリ４０２に維持することができる。各クライアントは、メッセージキュー４０３の専用コピーであり得る別個のメッセージキュー４２１〜４２４を維持することができる。さらに、各メッセージキュー４２１〜４２４がタイムリーに更新されることを確実にするために、メッセージキュー４０３のさまざまな専用コピー（すなわちメッセージキュー４２１〜４２４）をメッセージキュー４０３とたとえば周期的に同期させることができる。
【００２９】
本発明の実施形態に従うと、キューまたはキューにおける特定のエントリがそのときクライアントによって更新されている場合、メッセージキュー上でロックを起動させることができる。キューがサーバマシン上の共有メモリにあるので、他のすべてのクライアントは、キューがロックされていることを認識することができ、メモリのうちキュー内の特定のエントリに関連付けられる対応部分に書込みを行わないようにすることができる。さらに、メッセージの送信は、送信側でＲＤＭＡ書込み動作を実行することによって実現することができる。したがって、共有メモリにおけるキューおよびその関連付けられたヒープデータ構造についての書込みおよびアクセスの際にコンフリクションが生じないことを保証するために、受信側でラッチまたは直列化メカニズムを実現してロックする必要はない。
【００３０】
本発明の実施形態に従うと、クライアント同士は、キューにアクセスするために競合し得る。クライアントがキュー上でロックを獲得するかまたはキューにおける特定のエントリを獲得すれば、他のクライアントは、たとえば単一ノード環境におけるＯＳによって提供されるセマフォメカニズムを用いて、または、マルチノード環境内のＲＤＭＡアトミックスおよびラッチレスメカニズムを用いて、ロックの解放を待つことができる。
【００３１】
Ｓｙｓｔｅｍ  Ｖメッセージキュー
本発明の実施形態に従うと、分散型トランザクションシステムは、クライアントが利用可能なサーバに作業を委託することを可能にするサーバ−クライアントモデルを用いることができる。クライアントは、作業が終わると結果を得ることができる。作業の委託およびその完了はメッセージキューを用いて伝えることができる。Ｓｙｓｔｅｍ  Ｖメッセージキューは、オラクルＴｕｘｅｄｏ環境などの分散型トランザクション環境において単独のマシン上で作業の委託および完了を処理する効率的な方法を提供する。さらに、Ｓｙｓｔｅｍ  Ｖメッセージキューは、複数のマシン間での作業を共有するために拡張させることができる。
【００３２】
図５は、本発明の実施形態に従った、ミドルウェアマシン環境においてマルチノードアプリケーションのためのＳｙｓｔｅｍ  Ｖメッセージキューを用いる例を示す。図５に図示のとおり、シャドウキュー作成モデルは、ミドルウェアマシン環境５００においてＳｙｓｔｅｍ  Ｖメッセージキューに対して適用することができる。メッセージキューＱ  ５１１がノードＡ  ５０１上で作成されると、そのノード上のブローカ、すなわちブローカＡ  ５０４に対し、メッセージキューＱ  ５１１が存在していることを通知することができる。次いで、ブローカＡ  ５０４は、他のノード５０２〜５０３上の同様のブローカと通信し、これらに、クラスタ内の各ノード上に同じ名前「Ｑ」を有するキューを作成させることができる。
【００３３】
本発明の実施形態に従うと、ノードＢ  ５０２上のプロセス５０７はローカルメッセージキューＱ  ５１２に書込みを行うことができる。ノードＢはメッセージキューＱ  ５１１が最初に作成されたノードではないので、ノードＢ上のブローカプロセスでは、メッセージキュー５１２からメッセージを読取り、ＴＣＰ接続を用いてネットワークを介してノードＡ上のブローカＡ  ５０４にメッセージを送信することができる。次いで、ブローカＡ  ５０４は、ノードＡ上のメッセージキューＱ  ５１１にメッセージを書込むことができる。このようにして、如何なるノード上のプロセスでも、キューがローカルであるかまたはリモートであるかどうかを実際に識別することなく、いずれのノードから作成されたキューにも書込みを行うことができる。加えて、ノードＡ上のブローカＡ  ５０４はすべてのシャドウキューを絶えず監視することができ、シャドウキューのいずれかに書込まれたメッセージを、元のキューが作成されたノードＡへと伝搬させることができる。
【００３４】
上述のプログラミングモデルに付随する限定事項がある。たとえば、１）リモートノードからキューに書込まれたメッセージは、いくつか（たとえば５個）のメモリコピーが宛先キューに達することを必要とし得る。このため、このモデルは、ＣＰＵバスに対して多くのストレスを与える；２）多数のキューが存在する場合、環境全体がブローカの処理量に左右され、これがボトルネックになる可能性がある。および、３）このモデルは、メッセージの転送をスケーリングすることのできる利用可能なＲＤＭＡネットワークを活用しない。
【００３５】
ＲＤＭＡメッセージキュー
本発明の実施形態に従うと、Ｔｕｘｅｄｏシステムなどのトランザクションミドルウェアシステムは、Ｅｘａｌｏｇｉｃミドルウェアマシンなどの複数のプロセッサを備えた高速マシンおよび高性能ネットワーク接続を利用することができる。
【００３６】
当該システムは、Ｅｘａｌｏｇｉｃミドルウェアマシンを備えた利用可能なＲＤＭＡ対応のＩＢネットワークを用いる能力をトランザクションミドルウェアシステム、たとえばＯｒａｃｌｅ  Ｔｕｘｅｄｏに与えることができる。ＲＤＭＡは、ホストチャネルアダプタ（host channel adapter：ＨＣＡ）および／またはネットワークインターフェイスカード（network interface card：ＮＩＣ）に対するメッセージ転送に付随するほとんどのＣＰＵ作業の負担を軽減することができる。当該システムは、Ｅｘａｌｏｇｉｃマシンと同様の態様で、ＴｕｘｅｄｏがＲＤＭＡ対応システム上でそのトランザクション処理容量をスケーリングするのを支援することができる。当該システムは、ユーザがＲＤＭＡを用いてＩＢネットワーク上でメッセージキューを実行させることができるように、既存のメッセージ通信インフラストラクチャ実現例にＲＤＭＡ能力を追加することができる。
【００３７】
図６は、本発明の実施形態に従った、ミドルウェアマシン環境におけるマルチノードアプリケーションのためのＲＤＭＡメッセージキューの例を示す。図６に図示のとおり、２ノードのメッセージキューは、リモートリング構造を用いてメッセージキューを表わすことができる。リモートリング構造は、リーダ側で維持される１つのリング構造６０８とライタ側で維持される別のリング構造６０５とを含む２つの標準的なリング構造上にある。ローカルマシンすなわちマシンＡ  ６０１上のメッセージ送信側６０３は、たとえばＲＤＭＡプロトコル６２０を用いて、リモートマシンすなわちマシンＢ  ６０２上のメッセージ受信側６０４にメッセージを送信することができる。
【００３８】
本発明の実施形態に従うと、メッセージ受信側は、まず、リモートマシン内の共有メモリにおいてキューを作成し、ネットワークインターフェイスカードに共有メモリ内のキューのアドレスを通知することができる。メッセージキューは、ヘッドポインタおよびテールポインタを含むリングバッファデータ構造を用いて実現することができる。加えて、メッセージ受信側は、受信メッセージを含めるよう共有メモリにおいてヒープデータ構造を実現することができる。次いで、メッセージ受信側は、共有メモリにおいてヒープデータ構造のアドレス情報とともにメッセージキューの作成についてもメッセージ送信側に通知することができる。
【００３９】
加えて、ライタがメッセージキューに新しいメッセージを書込む場合、システムは両方のリング構造上のリングデータおよびヘッドポインタを更新する。当該システムは、リーダがリモートノード上にある場合、ＲＤＭＡを用いてリーダ側の構造を更新することができる。同様に、リーダは、これらリーダがメッセージを読取るのに応じて両方のリングを更新させ続けることができる。
【００４０】
本発明の実施形態に従うと、メッセージは、リング構造へダイレクトに記憶されない。実際のメッセージをどこで検索できるかについてのメタデータだけがリング構造内に維持される。メッセージは、リーダノードにおいて維持されるヒープデータ構造６１０に記憶される。実際のメッセージは、ＲＤＭＡ書込み動作６２０を用いて、ライタプロセスからリーダノード上の割当てられたメモリにまで転送させることができる。リモートヒープ６１０の実現例は可変サイズのメッセージをサポートすることができる。このリモートヒープ６１０においては、たとえ実際のヒープメモリがリーダノード上で維持されたとしても、割当て動作および解放動作はライタノード上で遂行される。一例においては、ヒープメモリ６１０はリーダノード上にあり、ヒープメタデータ全体はライタノード上に記憶される。したがって、如何なるネットワーク通信も行わずにライタ側からヒープ割当てを行うことができる。さらに、ヒープ管理は、競合をさらに最小限にするために／リモートキューの回復を簡略化にするために、スロット割当てミューテックス／ステップから切離すことができる。
【００４１】
以下のリスト１は、メッセージを優先させることなくロックの助けを借りてキューが作成された場合のキュー書込みおよび読取り動作を示す擬似コードを含む。
【数１】
2014531687.tif 000003
【００４２】
本発明の実施形態に従うと、キュー動作全体は、さまざまなクライアントプロセスによってユーザモードで起こり得る。プロセスは、共有リング構造またはヒープメタデータを更新している間、たとえば、get_next_slot/allocate ring slotを実行しているときに、例外的に終了させることができる。回復メカニズムを用いてプロセスの終了（death）を検出し、メタデータを一定の状態にして、他のプロセスが依然として同じキュー上で動作できるようにする。
【００４３】
本発明の実施形態に従うと、起動メカニズムを提供することができる。リスト１中の上述の擬似コードは、単一の優先事項のために作成されるキューの場合に実行することのできるステップの概要を示す。当該システムは、また、各メッセージが優先事項を有することを可能にし、優先事項に基づいた検索を可能にする。しばしば、クライアントは、特定の何らかの特性（「ｎ」未満の優先事項または「ｎ」と等しい優先事項または「ｎ」のない優先事項など）を有するメッセージを要求する可能性がある。この要求を満たすことのできるメッセージがそのときキューに存在しない場合、クライアントプロセスをスリープモードにすることができる。このクライアントプロセスは、いずれかのノードからのプロセスが、要求を満たし得るメッセージを書込む際に、起動させることができる。特定の要求を待機するプロセスを起動させるためのメカニズムがＲＤＭＡに基づいて実現され得る。
【００４４】
さまざまなクライアントプロセスが、同じキュー上で読取りおよび／または書込みを行うことができる。このようなシナリオでは、キューは共有メモリ（または共有ストレージ）上で作成することができる。大抵の共有メモリベースのアプリケーションにおいては、共有データを更新する場合、ミューテックスの利用が必要となる可能性がある。込み合った読取りおよび書込み経路におけるロックを回避するために、リング構造およびアトミックなコンペア・アンド・スワップ(compare and swap：ＣＡＳ)命令に基づいた方法を実現することができる。
【００４５】
本発明の実施形態に従うと、メッセージ転送のためにＲＤＭＡを用いることによりメモリバスの利用を削減することができる。これによりメッセージ転送全体からＣＰＵが解放され、これにより、ＣＰＵは、メッセージの転送中に他の作業を行うことができる。さらに、当該システムは、Ｓｙｓｔｅｍ  Ｖメッセージキューのためのブローカなどのボトルネックが排除された状態ではよりスケーラブルになる。このため、ＲＤＭＡを用いることにより、ＣＰＵの使用、メッセージ転送処理量およびメッセージ転送レイテンシに関して実質的な利点が得られる。
【００４６】
本発明の実施形態に従うと、当該システムは、ノード間メッセージ転送にＲＤＭＡを用いてメッセージキューを活用することができる。当該システムは、リモートリング構造を用いて、さまざまなマシンから同時にメッセージの読取りおよび書込みを行うことができる。当該システムは、リモートヒープが割当てられた可変サイズのメッセージを処理することができる。回復モデルを用いることにより、ローカルノード上またはリモートノード上で異常なプロセスが終了する場合にキューを回復させることができる。キューは、共有データに対するローカルな動作またはＲＤＭＡ動作を行うために、考案されたメカニズムを用いて共有メモリ上で作成される。当該システムは、メッセージを待っているリモートプロセスのためにＲＤＭＡに基づいた起動メカニズムを用いることができ、並列実行される（concurrent）リーダおよびライタが、ユーザモードプロセスから、ラッチレス同期を用いて同じキュー上で動作することが可能となる。
【００４７】
本発明の実施形態に従うと、当該システムは、最新のネットワークインターフェイスカードにおいて利用可能なＲＤＭＡ機構を活用することによってさまざまなノード間でキュー動作を行うためのインターフェイスを提供することができる。インターフェイスによって提供されるプログラミングインターフェイスは、Ｓｙｓｔｅｍ  Ｖ  ＡＰＩのインターフェイスと同様であり得る。
【００４８】
メッセージキューの作成および管理
本発明の実施形態に従うと、ミドルウェアマシン環境におけるサーバノード上のデーモンプロセスは、共有メモリにおいてメッセージキューを作成および管理するのに用いることができる。
【００４９】
図７は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを作成および管理することのできるデーモンプロセスの例を示す。図７に図示のとおり、ミドルウェアマシン環境は、サーバノード７０１ならびにいくつかのクライアントノード７０２および７０３を含み得る。サーバノードはさまざまなクライアントからメッセージを受信するための共有メモリ７０４を含み得る。共有メモリは１つ以上のメッセージキュー７１１および７１２を維持する。
【００５０】
本発明の実施形態に従うと、サーバノード３０１は、さまざまなクライアントがメッセージを送信および受信するようメッセージキューを設定するようサーバに要求した場合にサーバ上の共有メモリにおける１つ以上のメッセージキューの作成を担うデーモンプロセス３０６を含み得る。たとえば、クライアントＢ  ７０３がサーバ７０１との接続を開始すると、サーバ上のデーモンプロセス７０６は、メッセージ制御構造７２２を介してクライアントＢ  ７０３と通信するためにキューＢ  ７１２を動的に作成することができる。
【００５１】
本発明の実施形態に従うと、サーバと複数のクライアントとの間のこの通信方式はさらにプロキシを用いて拡張させることができる。たとえば、クライアントＡ  ７０２上のキュー／制御構造Ａ  ７２１は、１つ以上のプロキシ、たとえばプロキシＩ  ７２３〜プロキシＩＩＩ  ７２５を用いて拡張させることができる。これらのプロキシを用いると、クライアントＡ上のさまざまなプロキシに関連付けられたプロセスは、キュー／制御構造Ａを用いてサーバと通信することができる。
【００５２】
このため、ＲＤＭＡプロトコルを用いてさまざまなサーバとクライアントとの間の通信をサポートするためのミドルウェアマシンにおいて優れたスケーラビリティを達成することができる。というのも、プロセスがサーバ７０１上のヒープデータ構造７０５にメッセージをダイレクトに書込むことを可能にすることによって、サーバの干渉なしで、クライアントＡ  ７０２上のプロセスから開始されたメッセージをサーバ７０１に送信することができるからである。
【００５３】
本発明の実施形態に従うと、サーバ７０１上のデーモンプロセス７０６はまた、ローカルなメッセージ通信を目的として、ローカルメッセージキュー、たとえばキューＣ  ７０８を作成および保存することもできる。一例においては、ローカルサーバプロセス同士がローカルメッセージキューを用いて互いに通信することができ、Ｓｙｓｔｅｍ  Ｖ  ＩＰＣプロトコルをＲＤＭＡプロトコルの代わりに用いることができる。なぜなら、ローカルで用いられる場合にはＩＰＣプロトコルの方がＲＤＭＡプロトコルよりも高速であるからである。
【００５４】
図７に図示のとおり、ローカルサーバプロセス７０７は、キューＡ  ７１１およびキューＢ  ７１２などのリモートメッセージキューに加えて、ローカルメッセージキューＣ  ７０８からメッセージを受信することができる。ローカルサーバプロセス７０７は、ローカルメッセージキューとリモートメッセージキューとの差に対処する必要なしに、さまざまなメッセージキューからのメッセージを処理することができる。
【００５５】
本発明の実施形態に従うと、クライアントは、クライアント上のキューまたは制御構造を共有メモリまたは専用メモリにおいて作成できるかどうかを判断することができる。クライアントが特定のプロセスに関連付けられたクライアントマシンの専用メモリにおいてキューまたは制御構造を作成すると決めた場合、システムは、クライアント上の制御構造にアクセスするためにクライアントマシンおよびリモートマシン上の他のプロセスを妨害することができる。このことは有益となり得る。なぜなら、いくつかのメッセージが顧客の財務情報などの機密に関わる情報を含む可能性があるからである。
【００５６】
本発明の実施形態に従うと、中断は、サーバプロセス上で起こり得るかまたはサーバにおけるデーモンプロセス上でも起こり得る。クライアントは、サーバプロセスまたはデーモンプロセスの回復を待つ必要なしに、サーバマシン上の共有メモリにおいてＲＤＭＡ書込み動作を実行し続けることができる。これにより、システムのための障害回復を堅調かつ簡単明瞭なものにする。加えて、クライアントは、キューがフルである場合に、サーバマシン上の共有メモリへの書込みを停止させることができる。
【００５７】
図８は、本発明の実施形態に従った、トランザクションミドルウェアマシン環境においてメッセージキューを作成および管理するための例示的なフローチャートを示す。図８に図示のとおり、ステップ８０１において、サーバは、ミドルウェアマシン環境において１つ以上のメッセージキューを維持する共有メモリをメッセージ受信側に設けることができる。次いで、ステップ８０２において、クライアントは、メッセージの送信および受信をサポートするよう少なくとも１つのメッセージキューをサーバ上で設定することを要求する。最後に、ステップ８０３において、サーバがクライアント要求を受信すると、サーバ上のデーモンプロセスは、共有メモリにおいて少なくとも１つのメッセージキューを動的に作成することができる。
【００５８】
メッセージキューを保護するためのセキュリティモデル
本発明の実施形態に従うと、ミドルウェアマシン環境においてメッセージキューを保護するのにセキュリティモデルを用いることができる。
【００５９】
図９は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するのに用いることのできるセキュリティモデルの例を示す。図９に図示のとおり、メッセージ受信側９０２はメッセージ送信側９０１と通信するよう構成することができる。メッセージ受信側９０２に関連付けられるサーバノード上のデーモンプロセス９１０は、デーモンプロセスが最初にメッセージ送信側９０１と通信するためにサーバマシン上の共有メモリ９０４においてメッセージキュー９０６を作成する場合に、キーまたはセキュリティトークン９１４を作成することができる。
【００６０】
本発明の実施形態に従うと、デーモンプロセス９１０はさらに、ＩＢネットワークにキーまたはセキュリティトークン９１４を登録し、セキュリティ保護されたネットワーク９２０を介してクライアントノード上でメッセージ送信側９１０にセキュリティトークン９１４を送信することができる。図９に図示のとおり、メッセージ送信側９０１をデーモンプロセス９０５に関連付けることもできる。メッセージ送信側９０１のデーモンプロセス９１０とメッセージ受信側９０２のデーモンプロセス９０５との間のセキュリティ保護されたネットワーク９２０において別個の通信リンク、たとえば専用のプロセス、が存在し得る。
【００６１】
本発明の実施形態に従うと、メッセージ送信側９０１がセキュリティトークン９１４を受信した後、メッセージ送信側９０１は受信側マシン内の共有メモリ９０４にダイレクトアクセスすることができる。図９に図示のとおり、クライアントノード上のメッセージ送信側９０１は、セキュリティトークン９１４を用いて、受信側の共有メモリ９０４内のヒープデータ構造９０８においてメッセージをダイレクトに書込むためのＲＤＭＡ書込み動作９２１を実行することができる。
【００６２】
図１０は、本発明の実施形態に従った、ミドルウェアマシン環境においてメッセージキューを保護するための例示的なフローチャートを示す。図１０に図示のとおり、ステップ１００１において、メッセージ受信側のデーモンプロセスは、デーモンプロセスが最初にクライアントノードと通信するためにサーバノード上で共有メモリにおいてメッセージキューを作成すると、サーバノード上でセキュリティトークンを作成することができる。次いで、ステップ１００２において、メッセージ受信側のデーモンプロセスは、作成されたセキュリティトークンを、セキュリティ保護されたネットワークを介してサーバノードからクライアントノードに送信することができる。最後に、ステップ１００３において、クライアント側でセキュリティトークンを受信した後、メッセージ送信側は共有メモリ内のメッセージキューにダイレクトにメッセージを書込むことができる。
【００６３】
この発明は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取り可能な記憶媒体を含む１つ以上の従来の汎用のまたは特化されたデジタルコンピュータ、演算装置、マシンまたはマイクロプロセッサを用いて、好都合に実現され得る。ソフトウェア技術の当業者に明らかとなるように、適切なソフトウェアコーディングは、熟練したプログラマによって本開示の教示に基づき容易に準備され得る。
【００６４】
いくつかの実施形態においては、本発明は、本発明のプロセスのいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令を格納した記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気または光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／またはデータを格納するのに適した任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。
【００６５】
本発明の上述の記載は、例示および説明を目的として与えられており、網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正例および変形例が明確となるであろう。上記の実施形態は、本発明の原理およびその実際的な適用を最もよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に適したさまざまな修正例を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの同等例によって定義されるよう意図されている。
【図１】
2014531687.tif 000004
【図２】
2014531687.tif 000005
【図３】
2014531687.tif 000006
【図４】
2014531687.tif 000007
【図５】
2014531687.tif 000008
【図６】
2014531687.tif 000009
【図７】
2014531687.tif 000010
【図８】
2014531687.tif 000011
【図９】
2014531687.tif 000012
【図１０】
2014531687.tif 000013
【国際調査報告】
2014531687.tif 000014
2014531687.tif 000015