非同期通信およびスコープを使用した、トランスペアレントなモジュール分散および分離
【課題】非同期通信およびスコープを使用してモジュールをトランスペアレントに分散させ分離すること。
【解決手段】本発明によるシステムおよび方法は、非同期通信およびスコープを使用してトランスペアレントにモジュールを分離し負荷を分散させることを含むことができる。非同期通信は、メッセージキューの使用またはメッセージトピックの使用によって達成することができる。スコープは、分離されたモジュールに関連するリソースに構造を与えるため、およびメッセージの処理に必要なそのようなリソースをモジュール間で分散させる能力を向上させるための手段として導入される。さらに、非同期通信およびスコープの使用は、自動的に、かつユーザおよび/またはアプリケーション開発者に対してトランスペアレントに、行うことができる。
【解決手段】本発明によるシステムおよび方法は、非同期通信およびスコープを使用してトランスペアレントにモジュールを分離し負荷を分散させることを含むことができる。非同期通信は、メッセージキューの使用またはメッセージトピックの使用によって達成することができる。スコープは、分離されたモジュールに関連するリソースに構造を与えるため、およびメッセージの処理に必要なそのようなリソースをモジュール間で分散させる能力を向上させるための手段として導入される。さらに、非同期通信およびスコープの使用は、自動的に、かつユーザおよび/またはアプリケーション開発者に対してトランスペアレントに、行うことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明によるシステムおよび方法は、一般に、非同期通信およびスコープを使用してモジュールを分離することに関する。
【背景技術】
【０００２】
ビジネスおよび他の組織は、その運営の間に、様々なデータアイテムおよび電子情報(以下では広く「ビジネスデータ」として言及する)を生成および/または受信する。例えば、クラウドコンピューティングのコンテキストでは、ビジネスデータは、種々の領域および/または国に位置する様々なエンティティのコンピュータから生成および/または受信されることがある。したがって、コンピュータのネットワークにわたって、ビジネスロジックおよび一時的なビジネスデータ、ならびにこのデータを処理するためのロジックを、分散させることを改善することが必要とされている。
【０００３】
クラウドコンピューティングのコンテキストでは、サーバが、クライアントおよび他のサーバから要求を受け取って処理することができる。クライアントおよび他のサーバは、例えば、種々の領域および/または国に位置する様々なエンティティのコンピュータである場合がある。サーバは、複数のソフトウェアモジュールを使用して要求を扱うことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
これらのモジュールを実行するには、サーバは、サーバリソース(例えばメモリや処理時間など)の一部をモジュールに割り振る必要がある。加えて、サーバのモジュールは通常、「結合」される。すなわち、例えばモジュールは、他のモジュールのパブリッシュされた機能に依拠したり、同じグローバルデータまたは変数にアクセスすることによって状態を共有したりすること等が可能である。 さらに、クラウド環境では、単一のまたは種々のコンピュータシステム上に位置する結合されたモジュールを更新することは、問題を孕む可能性がある。同様に、結合されたモジュールをオペレータが自発的にスケーリングしたいときにもまた、困難が生じる。加えて、一般にサーバリソースは非常に非構造的な方式で割り振られ使用されるので、クラウド環境にわたるリソースの伝送は困難であることがある。したがって、より構造化されたサーバリソース管理手法を使用して、モジュールの分離を可能にすることが必要とされている。
【課題を解決するための手段】
【０００５】
本発明の一実施形態によれば、コンピュータシステム中でモジュールを分離する方法、および、この方法を実行するための命令を記憶したコンピュータ可読媒体が開示される。この方法は、例えば、非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信すること、メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持すること、コンテキストのコピーを第2のホストに送信すること、第1のモジュールを一時停止すること、メッセージが第2のモジュールによって処理されたことを示す応答を受信すること、コンテキストのコピーの更新を第2のホストから受信すること、更新をスコープ階層中のコンテキストに組み込むこと、および、第1のホスト上の第1のモジュールを再開することを含むことができる。
【０００６】
本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、例えば、ネットワークを介してメッセージを送信するように構成された通信ユニットと、メッセージの送信を抑制するためのキューを記憶したメモリと、リソースマネージャとを備えることができる。リソースマネージャは、コンテキストをスコープ階層中で維持し、メッセージに関連するスコープを生み出し、コンテキストのうちの1つまたは複数を受信コンテキストとマージするためのものとすることができる。
【０００７】
本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、ネットワークを介してモジュールに対するメッセージを受信するための受信機と、モジュールを実行してメッセージを処理するためのプロセッサと、メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備えることができ、コンテキストは、メッセージに関連するスコープのリソースを含む。
【０００８】
以上の一般的な記述と、以下の詳細な記述とは両方とも、例示的および説明的なものに過ぎず、記述され特許請求される本発明の範囲を限定するものと考えるべきではないことを理解されたい。さらに、本明細書に述べるものに加えて特徴および/または変形を提供することもできる。例えば、本発明の実施形態は、詳細な記述で述べる特徴の様々な組合せおよびサブコンビネーションを対象とすることもできる。
【０００９】
本開示に組み込まれ本開示の一部をなす添付の図面に、本発明の様々な実施形態および態様を示す。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明による、モジュールをトランスペアレントに分離するための例示的なシステムを示す図である。
【図１Ｂ】本発明による、モジュールをトランスペアレントに分離するための別の例示的なシステムを示す図である。
【図２】本発明による、モジュールをトランスペアレントに分離するための例示的なプロセスを示す図である。
【図３】本発明による、キューを使用した例示的な非同期通信を示す図である。
【図４】本発明による、トピックを使用した例示的な非同期通信を示す図である。
【図５】本発明による例示的なスコープ階層を示す図である。
【図６Ａ】本発明による例示的な要求メッセージを示す図である。
【図６Ｂ】例示的な応答メッセージを示す図である。
【図７】本発明による、スコープコンテキストを複製するための例示的なシステムを示す図である。
【図８】本発明による、負荷平衡のための例示的なプロセスを示す図である。
【図９】本発明による、負荷平衡のための追加の例示的なプロセスを示す図である。
【図１０】本発明による、モジュールを更新するための例示的なプロセスを示す図である。
【発明を実施するための形態】
【００１１】
以下の詳細な記述では、添付の図面を参照する。可能な場合には、図面および以下の記述において、同じまたは類似の部分を指すのには、同じ参照番号を使用する。本発明のいくつかの例示的な実施形態および特徴について本明細書に述べるが、本発明の趣旨および範囲を逸脱することなく、修正、適応、および他の実施形態も可能である。例えば、図面に示すコンポーネントに対して代用、追加、または修正を行うこともでき、また、開示する方法に対してステップを代用、並べ替え、または追加することによって、本明細書に述べる例示的な方法を修正することもできる。したがって、以下の詳細な記述は本発明を限定しない。そうではなく、本発明の正しい範囲は、添付の特許請求の範囲によって定義される。
【００１２】
発明の概観
本発明によるシステムおよび方法は、一般に、モジュール分離およびトランスペアレントな分散を提供することに関する。本発明によるシステムおよび方法は、クラウドコンピューティング環境で利用することができる。トランスペアレントな分散およびモジュール分離は、非同期通信およびスコープを使用して達成することができる。
【００１３】
図1Aに、本発明によるシステム100を示す。システム100は、メッセージ作成側110および120が通信ネットワーク130によってメッセージ消費側140に接続されているのを示す。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、ビジネスコンピュータシステムとすることができる。メッセージ作成側110および120ならびにメッセージ消費側140はまた、種々の抽象化レベルで見ることができる。例えばこれらは、システムのリソース全体をカバーするノードレベルから、スレッドのリソースをカバーするスレッドレベルまでで見ることができる。加えて、メッセージ作成側110および120ならびにメッセージ消費側140のユーザおよびクライアントは、メッセージ作成側110、120ならびにメッセージ消費側140の特定の「セキュリティ領域」に制限することができる。すなわち、セキュリティの目的で、ユーザおよびクライアントからメッセージ作成側110および120ならびにメッセージ消費側140のいくつかのリソースへのアクセスを制限することができる。通信ネットワーク130は、メッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。図1Aに示すコンポーネント110、120、および140の数が例示的であることは、当業者なら理解するであろう。したがって、本発明によるシステム100は、任意の数のメッセージ作成側110もしくは120、または任意の数のメッセージ消費側140を含むことができる。図1Bに別の可能なシステムを示すが、このシステムは、メッセージ消費側とメッセージ作成側とがちょうど対称であってもよいことを強調するもので、メッセージ消費側とメッセージ作成側とがそれぞれの役割を実行時に切り替えることができる。
【００１４】
通信ネットワーク130は、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、またはインターネットなど、1つまたは複数のネットワークタイプを含むことができる。通信ネットワーク130は、ワイヤラインおよび/またはワイヤレス技術によって動作することができ、伝送制御プロトコル/インターネットプロトコル(TCP/IP)またはいずれか他の適切なプロトコルを使用して、システム100のメッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。ネットワーク130内のネットワーク接続は、イーサネット（登録商標）、電話回線、セルラーチャネル、または他の伝送媒体を介して確立することができる。ネットワーク130を介したデータ通信は、メッセージ作成側110および120ならびにメッセージ消費側140などのデバイス間でデータパケットを伝送することによって容易にすることができる。本明細書に述べるデータ伝送は、例えば、単一のデータパケット中で送信されてもよく、あるいはいくつかのデータパケットにわたって分割されてもよい。さらに、メッセージ作成側110および120は、ネットワーク130を介してメッセージ消費側140と非同期通信することができる。
【００１５】
システム100のメッセージ作成側110および120ならびにメッセージ消費側140は、1つまたは複数のアプリケーションプログラムおよび1つまたは複数のハードウェアコンポーネントの組合せなど、多くのインフラストラクチャを含むことができる。例えば、アプリケーションプログラムは、本発明の開示される動作を実行する、ソフトウェアモジュール、命令のシーケンス、ルーチン、データ構造、表示インタフェース、および他のタイプの構造を含むことができる。メッセージ作成側110および120ならびにメッセージ消費側140のハードウェアコンポーネントは、中央処理装置(CPU)、バス、メモリデバイス、記憶ユニット、データプロセッサ、入力デバイス、出力デバイス、ネットワークインタフェースデバイス、および、当業者には明らかであろう他のタイプのコンピュータシステムコンポーネントの組合せを含むことができる。したがって、メッセージ作成側110および120ならびにメッセージ消費側140は、ハンドヘルドデバイス、パーソナルコンピュータ、またはメインフレームコンピュータなど、任意のタイプのコンピュータデバイスによって実現することができる。
【００１６】
メッセージ作成側110および120ならびにメッセージ消費側140は、それぞれプロセッサ110-1、120-1、および140-1を備えることができる。プロセッサ110-1、120-1、および140-1はプロセスを実行することができ、プロセスは、スレッド110-2、120-2、および140-2などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はさらに、メモリ110-3、120-3、および140-3を備えることができる。メモリ110-3、120-3、および140-3は、不揮発性または揮発性メモリなど任意の形のコンピュータ可読記憶媒体を含むことができ、例としてこれらには、EPROM、RAM、ROM、DRAM、EEPROM、フラッシュメモリデバイスなどの半導体メモリデバイス;内蔵ハードディスクや取外し可能ディスクなどの磁気ディスク;光磁気ディスク;およびCD-ROM、DVD、またはブルーレイディスクが含まれる。
【００１７】
スコープおよびコンテキスト
メモリ110-3、120-3、および140-3はそれぞれ、モジュール110-4、120-4、および140-4などのソフトウェアモジュールを含むことができる。モジュール110-4、120-4、および140-4は、それぞれプロセッサ110-1、120-1、および140-1によって実行される命令を含むことができる。上に論じたように、命令はさらに、スレッド110-2、120-2、および140-2などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はそれぞれさらに、「スコープ」を使用してリソースを管理するために、リソース管理モジュール110-5、120-5、および140-5などのリソース管理モジュールを備えることができる。「リソース」は、例えばメモリデータ構造、データベース接続、またはセキュリティ許可において、特定のプロセスを実行するのに必要なものなら何でも含むことができる。「スコープ」は、定義された期間にわたってコンピュータ上でグループ化される複数のリソースを含むことができる。スコープタイプの例は、要求スコープ、ユーザスコープ、プロセススコープなどである。スコープタイプの追加の例については、以下でさらに詳細に論じる。メッセージ作成側110および120ならびにメッセージ消費側140は、スコープタイプを実行時にインスタンス化して、スコープインスタンスを生み出すことができる。スコープインスタンスは、実行時にこのインスタンスを識別するための論理IDを含むことができる。このIDは、大域的に一意とすることができる(すなわち、スコープタイプを同じくするかまたは異にする、異なるスコープインスタンスは、異なるIDを有さなければならない)。
【００１８】
リソース管理モジュール110-5、120-5、および140-5は、リソースをスコープインスタンスに関連付けて、システム100内部で割り振られる任意のリソースの寿命を明確に線引きすることができる。いくつかの実施形態では、システム100中には、スコープインスタンスに関連付けられないリソースがないことがある。しかし、本発明のいくつかの実施形態では、所有主であるスコープインスタンスは非常に粗粒であることがある。すなわち、スコープインスタンスは、システム100の大きなコンポーネントをカバーし、より小さいスコープインスタンスに細分できないことがある。例えば、この設定は、スコープインスタンスをバッチジョブよりも低い細粒度にさらに分割することから何の利益も得られそうにない場合の、ローカルバッチ処理のみに向けられたシステム中で適切であることがある。リソース管理モジュール110-5、120-5、および140-5は、リソースをスコープインスタンス中で割り振ったりスコープインスタンスから解放したりすることによって、リソースを管理することができる。リソース管理モジュール110-5、120-5、および140-5は、リソースが生み出されるとき、リソースをちょうど1つのスコープインスタンスに割り振ることができ、リソースが個別に削除されるとき、このスコープインスタンスからリソースを解放することができる。リソース管理モジュール110-5、120-5、および140-5は、リソースを所有するスコープインスタンスが例えばタイムアウトのせいで解放されるとき、リソースを解放することができる。リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを暗黙的に定義することができ、それにより、メモリ領域、すなわちオブジェクトを割り振る構造をプログラマが明示的に宣言しなくて済むようにすることができる。さらに、リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを使用して、ローカルに割り振られたオブジェクトをメッセージ作成側110および120ならびにメッセージ消費側140などの協働ノードのネットワーク中で分散させて、リモート通信の透過性を高めることができる。
【００１９】
リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを、その「コンテキスト」と呼ばれる定義された記憶エリアに関連付けることができる。コンテキストは、一時的(メモリ中)とすることもでき、あるいは永続的(ディスク上)とすることもできる。コンテキストはシステム100中で冗長的に存在できるが、スコープインスタンスは通常、いずれか所与の時点で単一のメッセージ作成側110もしくは120またはメッセージ消費側140上でのみアクティブであるという点で、コンテキストは、それに関連するスコープインスタンスとは異なるものとすることができる。例えば図1Aでは、メッセージ作成側110のメモリ110-3は、第1のスコープインスタンスのコンテキスト110-6を含む。同様に、メッセージ作成側120のメモリ120-3は、第2のスコープインスタンスのコンテキスト120-6を含む。リソース管理モジュール110-5は、スコープインスタンスの寿命の間にスコープインスタンスに関連付けられる任意のリソースを割り振ることができる。例えば、第1のスコープインスタンスのコンテキスト110-6は、割り振られたリソース110-7および110-8を含む。同様に、第2のスコープインスタンスのコンテキスト120-6は、割り振られたリソース120-7および120-8を含む。
【００２０】
スコープインスタンスは、メッセージ作成側110および120ならびにメッセージ消費側140のそれぞれにおいて1つのコンテキストを有することによって、メッセージ作成側110および120ならびにメッセージ消費側140の間を移行することができる。リソース管理モジュール110-5、120-5、および140-5などのリソース管理モジュールは、これらのコンテキストのうちの1つを好ましいインスタンスとして割り当てて、種々のマシン間で過剰なデータ移動がないようにすることができる。スコープ中の好ましいインスタンスは、このスコープインスタンスに関係する全てのタスクをデフォルトで扱うインスタンスとすることができる。他のマシン上の他のコンテキストインスタンスは、コンテキストのこの好ましいインスタンスと同期して、所与のスコープインスタンス内でのデータ不整合を回避することができる。
【００２１】
非同期通信
図1Aに示すように、メモリ110-3および120-3は、それぞれアウトバウンドキュー110-9および120-9を含む。アウトバウンドキュー110-9および120-9は、それぞれアウトバウンドメッセージ110-10および120-10を含むことができる。コンテキスト110-6は、リソース110-7および110-8など、メッセージ110-10を処理するのに必要なリソースを含むことができる。すなわち、メッセージ110-10は、第1のスコープインスタンスであるスコープ1に関連することができる。コンテキスト120-6は、リソース120-7および120-8など、メッセージ120-10を処理するのに必要なリソースを含むことができる。すなわち、メッセージ120-10は、第2のスコープインスタンスであるスコープ2に関連することができる。メッセージ消費側140のメモリ140-3は、インバウンドキュー140-6を含むことができる。インバウンドキュー140-6は、アウトバウンドキュー110-9から受け取ったメッセージ110-10、およびアウトバウンドキュー120-9から受け取ったメッセージ120-10を含むことができる。
【００２２】
同様に、図1Bに示すように、メッセージ消費側140はまた、他のモジュール140-9を備えることができ、リソースマネージャ140-5は、リソース140-11および140-12を含むコンテキスト140-10など、スコープインスタンスについてのコンテキストを割り振ることができる。メッセージ消費側140はまた、メッセージ作成側110などのメッセージ作成側または他のメッセージ消費側にメッセージ140-14を送信するためのアウトバウンドキュー140-13を備えることができる。メッセージ作成側110もまた、他のメッセージ作成側またはメッセージ消費側140からメッセージ140-14を受信するためのインバウンドキュー110-13を備えることができる。メッセージ作成側110は、モジュール110-4または別のモジュール110-11を使用して、メッセージ140-14を処理することができる。加えて、メッセージ作成側110はまた、メッセージ140-14についてのコンテキストのコピー、すなわちコンテキストコピー110-12を受信することができる。
【００２３】
例えば、図1B中のモジュール110-4が、ネットワーク130によってメッセージ作成側110から分離されているメッセージ消費側140上にモジュール140-4があることを知らずに、モジュール140-4の機能にアクセスしたいと仮定する。モジュール110-4は、モジュール140-4を表すメモリ110-3中のリソースに対して、メソッド呼出しを開始することができる。このメソッド呼出しは、スレッド110-2上で実施することができる。次いで、呼び出されたリソースは、メソッド呼出しをメッセージ110-10に変換することができ、スレッド110-2は、メッセージ110-10をアウトバウンドキュー110-9上に配置することができる。その後、メッセージ140-14などの応答メッセージまたは肯定応答がメッセージ作成側110に返されるまで、スレッド110-2を保留するかまたはメッセージ作成側110中の他のタスクに利用することができる。メッセージ作成側110のスレッドスケジューリングアルゴリズムに応じて、同じまたは異なるスレッド110-2が、メッセージ作成側110のインバウンドキュー110-13からメッセージ140-14などの応答メッセージを得て、元のメソッド呼出しのすぐ後に続く命令ステップでモジュール110-4の処理を再開する。
【００２４】
図1A中のメッセージ110-10および120-10を処理するために、メッセージ消費側140は、メッセージ110-10および120-10に関連するスコープインスタンスのリソースへのアクセスを必要とすることがある。これが起こるのを可能にするために、本発明によるシステム100は、メッセージ110-10および120-10に関連するスコープインスタンスのコンテキストを、メッセージ消費側140にコピーする。このプロセス中で、システム100は、データがコンテキストの様々なコピー間で同期するようにして、データ破損を防止する。コピープロセスがいくらかの時間を要する場合は、システム100は、コピープロセスが完了するまで、メッセージ消費側140へのメッセージ110-10および120-10の配信を遅延させることを選択することができる。したがって、メッセージ110-10および120-10がメッセージ消費側140中で処理されると、メモリ140-3は、第1のスコープインスタンスのコンテキストの現コピー140-7、ならびに第2のスコープインスタンスのコンテキストの現コピー140-8を含む。
【００２５】
前の2つの段落で述べた手法は、図1Aのモジュール110-4および120-4に同期するように見える呼出しをシステム100が非同期に実行するのを可能にすることができる。さらに、この手法はまた、システム100が参照渡し(call-by-reference)セマンティクスによってリモート呼出しを実施するのを可能にすることができる。というのは、呼出し中に使用されるどんな参照の現在の値も、メッセージ消費側140に利用可能にされるからである。この2つの能力の組合せにより、本発明の使用は確実に、モジュール110-4および120-4に対して完全にトランスペアレントのままとなる。すなわち、分散環境で実行されるにもかかわらず、モジュール110-4および120-4は、モジュール140-4がモジュール110-4および120-4と同じメモリ110-3中にあるかのように動作し続けることができる。
【００２６】
特定の方式で構成された特定のコンポーネントを有するものとしてシステム100の例示的な実施形態について述べているが、システム100が、異なるように構成できる追加のまたはより少ないコンポーネントを含んでもよいことは、当業者なら理解するであろう。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、追加のプロセッサおよび/またはメモリデバイスを備えてもよい。さらに、コンポーネント110-4、110-5、110-6、および110-9に例えば含まれるプロセス命令は、複数のメモリデバイスにわたって分散させてもよい。また前述のように、システム100は、図1Aまたは1Bに示すよりも少ないかまたは多いメッセージ作成側110および120ならびにメッセージ消費側140を使用して実現してもよい。
【００２７】
図2に、本発明による、スコープを使用してモジュールをトランスペアレントに分離するための例示的なシステムを示す。ステップS201で、メッセージ作成側110および120のうちの一方に位置することのできるモジュールAが、メッセージ消費側140上に位置することのできるモジュールBのオブジェクトインスタンス上のメソッドを呼び出す。モジュールAから見ると、これは、モジュールBのオブジェクトインスタンスを表すモジュールAのローカルアドレス空間中のオブジェクトインスタンスに対する、ローカルメソッド呼出しである。次いでメッセージ作成側110または120は、要求メッセージをキューに入れ、対応するスレッド(例えばスレッド110-2および120-2)を、モジュールA中のメソッド呼出しを実行するタスクから分離することができる(S202)。次いでこのスレッドは、モジュールAのローカルアドレス空間中での他の処理に使用することができる。この分離により、モジュールAの実行は、メソッド呼出しの継続時間にわたって一時停止される(S203)。次いでメッセージプロバイダ110または120は、要求メッセージをモジュールBに転送することができる(S204)。システム100はまた、関連するどんなスコープコンテキストもモジュールBのローカルアドレス空間に暗黙的にコピーすることができる(S205)。これを行うには3つの方法がある。すなわち、メッセージ添付、および事前対応または事後対応(すなわちオンデマンド)の帯域外複製(後で「コンテキスト複製」の章で論じる)である。ステップS204とS205は、並行して行われてよい。次いでシステム100は、要求メッセージをモジュールBのローカルアドレス空間中のメソッド呼出しのターゲットオブジェクトインスタンスに配信する(S206)。メッセージ消費側140は、複製されたスコープコンテキストを必要に応じて参照して、メソッドを実行する(S207)。例えば、メソッド呼出しがパラメータを利用した場合は、複製されたスコープコンテキストからこれらのパラメータにアクセスすることができる。次いでメッセージ消費側140は、メソッド実行の結果を応答メッセージに変換し、これをモジュールBのローカルアドレス空間でキューに入れることができる(S208)。次いでシステム100は、応答メッセージをモジュールAのロ
ーカルアドレス空間に転送することができる(S209)。システム100は、モジュールB中でのメソッド実行中に関連スコープコンテキストに対して加えられたどんな変更も、後で詳述する3つの複製メカニズムのうちの1つを使用してモジュールAのローカルアドレス空間に暗黙的に複製し返すことができる(S210)。やはりステップS209とS210は並行して行われてよい。次いでメッセージ作成側110または120は、モジュールAのアドレス空間中のスレッド(例えばスレッド110-2および120-2)によって応答メッセージをキューから取り出すことができ、モジュールAの実行が再開される(S211)。メッセージをキューから取り出すスレッドは、メソッド呼出しを開始したスレッドと同じスレッドでないことがあるが、元のスレッドと同じスレッドコンテキストを有する必要があることがある。モジュールAをさらに実行する間、どんな関連スコープコンテキストにも、モジュールAによってアクセスすることができる。このようなコンテキストに割り振られたリソースに対してモジュールB上でのメソッド呼出し中に加えられたどんな変更も、モジュールAから見える。
【００２８】
システム100は、インバウンドキュー140-6などのキューを使用して非同期通信することができる。図3に、キューを使用した例示的な非同期通信300を示す。図3に示すように、モジュール301が、メッセージ302をキュー303に送ることができる。次いでモジュール304が、メッセージ302を消費することができる。メッセージ302を消費した後、モジュール304は、メッセージ302の消費をモジュール301に肯定応答することができる。メッセージ302は、ポイントツーポイントメッセージとすることができる。すなわち、メッセージ302は、ちょうど1つの消費側を有することができる。さらに、モジュール301とモジュール304とは、ネットワーク(図示せず)を介して接続された異なるコンピュータ(図示せず)上に位置することができる。メッセージングインフラストラクチャは、最低1回保証の配信、または順番にちょうど1回保証の配信など、メッセージ配信についての様々なサービス品質をサポートすることができる。このようなサービス品質は、トランスポート層におけるいくつかのネットワーク伝送エラーを隔離し、それにより、モジュール層からみたリモート通信の透過性を高める。
【００２９】
システム100は、「トピック」を使用して非同期通信することができる。トピックは、ある基準を満たすメッセージをそれにパブリッシュすることのできる構造である。図4に、トピックを使用した例示的な非同期通信400を示す。図4に示すように、モジュール401は、メッセージ402をトピック403にパブリッシュすることができる。モジュール404および405は、トピック403に申し込むことができる。すなわち、モジュール404および405は、トピック403にパブリッシュされたメッセージを受け取りたいことを示すことができる。次いでトピック403は、メッセージ402をモジュール404および405に配信することができる。非同期通信400によるいくつかの実施形態では、モジュール404および405は、メッセージ402の消費を肯定応答しない。
【００３０】
本発明による実施形態は、非同期通信をデフォルトのメカニズムとして使用して、システム100中で実行される種々のモジュールを分離することができる。このような全ての実施形態では、非同期通信の使用が参加モジュールに対してトランスペアレントのままであるように、非同期通信をシステム100に組み込むことができる。非同期通信は、図示の粗粒モジュール間、またはシステム100の内容を定義する種々のモジュール間における任意のメッセージについて行うことができるが、そうする必要があるわけではない。同期通信をモジュール間通信に使用すると、モジュール間の結合度が増すことがあり、本発明で述べる様々な技法の適用可能性が低下することがある。しかし、同期通信の使用は、本発明のコンテキストでは、例えばモジュール間の高頻度の対話に対する性能を改善するための、一時的な最適化に過ぎないと考えられる。特に、これはいつでもデフォルトの非同期通信で置換することができ、それにより、再びモジュール間の結合を低減し、本発明で述べる様々な技法の使用を可能にすることができる。
【００３１】
メソッドを非同期で呼び出す決定は、厳密に、モジュール開発者によってではなくシステム管理者によって行われる管理上の決定とすることができる。その場合、この決定は、メッセージ作成側110および120またはメッセージ消費側140を再起動せずに、実行時に行うことができ、また覆すこともできる。
【００３２】
スコープ階層およびスコープタイプ
スコープインスタンスは、しばしば階層に編成される。図5に、例示的なスコープインスタンスの階層500を示す。子スコープインスタンスがその親スコープインスタンスよりも長生きしないという制約を階層が満たす限り、階層の正確な形は、本発明の一実施形態において構成可能とすることができる。階層500中で、スコープインスタンス510は、スコープインスタンス510に割り振られたリソース512および513を含むコンテキスト511を有することができる。スコープインスタンス510は、子スコープインスタンス520および530に対する親としての働きをすることができる。子スコープインスタンス520は、子スコープインスタンス520に割り振られたリソース522および523を含むコンテキスト521を有することができる。同様に、子スコープインスタンス530は、子スコープインスタンス530に割り振られたリソース532および533を含むコンテキスト531を有することができる。子スコープインスタンス530はまた、それ自体のコンテキスト541ならびに割り振られたリソース542および543を有する親スコープインスタンス540の子とすることができる。子スコープインスタンス530はまた、それ自体のコンテキスト551ならびに割り振られたリソース552および553を有する子スコープインスタンス550の親としての働きをすることができる。階層は、参加スコープインスタンスのそれぞれの識別に依拠して、親から子へ、および子から親へナビゲート可能とすることができる。
【００３３】
本明細書で論じるスコープは、いくつかのタイプのスコープのいずれかとすることができる。以下のTable 1(表1)に、本発明による例示的なスコープタイプを列挙する。Table 1(表1)は、網羅的でも必須でもない。本発明による一実施形態は、所与のビジネス問題を解決するために適切と見なされる場合には、追加のスコープタイプを定義することができ、あるいはTable 1(表1)からいくつかのスコープタイプを省くことを選択することができる。例えば、バッチ処理システムがバッチスコープタイプを定義することができ、また、バッチシステムは通常はクライアントからのどんな要求にもサービスしないので、要求スコープタイプの使用を控えることができる。
【００３４】
【表１Ａ】
【００３５】
【表１Ｂ】
【００３６】
Table 1(表1)中のいくつかのスコープタイプは、いずれか所与の個別ノードの寿命を超えることがあることに留意されたい。例えば、ユーザスコープまたはクラスタスコープは、それらが最初に生み出された場であるノードが消滅したとしても、存続することができる。このような長生きするスコープタイプは、特定のノードに固定されないことを示すために「仮想」スコープタイプと呼ぶことができる。仮想スコープタイプは、メッセージ作成側110および120ならびにメッセージ消費側140などの複数のノードを包含する単一のスコープインスタンスによって表すことができる。他のスコープインスタンスと同様、仮想インスタンスは、大域的に一意である単一のIDを有することができる。しかし、非仮想スコープインスタンスとは対照的に、仮想スコープインスタンスは、全て並行してアクセス可能なメッセージ作成側110および120ならびにメッセージ消費側140などの種々のノード上の複数のコンテキストインスタンスによって表すことができる。システム100は、種々のノード上で仮想スコープの複数のコンテキストインスタンスを同期的に維持して、どんなデータ破損も回避することを担うことができる。これは例えば、競合のない方式で仮想スコープインスタンスのコンテキストインスタンスを更新するために依拠することのできる中央ロックサービスを提供することによって、達成することができる。
【００３７】
Table 1(表1)の様々なスコープタイプのインスタンスは、階層に編成することができる。スコープインスタンスの階層は、実行時に動的に変化することがある(例えば、新しいユーザがシステムにログオンしたとき、新しいユーザスコープインスタンスが階層に挿入され、以後、このユーザスコープインスタンスを使用してこのユーザのためにリソースを割り振ることができる)。要求が完了したとき、対応する要求スコープインスタンスは、その全ての子と共に階層から除去される。この動的なスコープインスタンス階層はそれでもなお、展開時に構成することのできる明確に定義された安定したタイプ構造に依拠することができる。このタイプ構造が定義された場合は、このタイプ構造により、所与のタイプのスコープインスタンスは常に、階層の自由裁量レベルで挿入されるのではなく、階層中のいくつかの固定スコープタイプの親と子との間に挿入されるようになる。したがって、タイプ構造は、実行時の動的な階層全体のよりよい構造およびよりよい管理可能性に大きく貢献する。
【００３８】
スコープおよびリソースのライフサイクル
階層500のスコープインスタンスは、様々なタイプのスコープを表すことができる。例えば、リソースマネージャ110-5、120-5、および140-5(図1A)は、所与のユーザについての、かつ、このユーザのセキュリティ領域内の全てのコンピュータインフラストラクチャインスタンスにわたる、全てのクライアントスコープインスタンスの親であるユーザスコープインスタンスを共同で維持することができる。同時に、リソースマネージャ110-5、120-5、および140-5のうちの1つは、単一のコンピュータインフラストラクチャインスタンス上で、このユーザのクライアントスコープインスタンスの親としてのアプリケーションスコープインスタンスを維持することができ、したがって、アプリケーションセッションが通常はユーザとアプリケーションとの組合せによって所有されることを反映することができる。リソースマネージャ110-5、120-5、および140-5のうちの1つが親スコープインスタンスのうちの1つを明示的または暗黙的に解放したときは、この親の全ての子スコープインスタンス(したがって子スコープインスタンスに関連する全てのリソース)もまた解放することができる。例えば、ユーザがサインアウトしたとき、ユーザのセキュリティ領域中の全てのリソースマネージャは、関連するユーザスコープインスタンスを解放することができ、リソースマネージャ110-5、120-5、および140-5はそれぞれ、各々システム110、120、および140上のこのユーザの全てのクライアントスコープを解放することができる。メッセージ作成側110上でアプリケーションを閉じると、この作成側上で生きているこのアプリケーションについての全てのクライアントセッションの解放をトリガすることができるが、メッセージ作成側110上の他のアプリケーションのどんなクライアントセッションも、またメッセージ作成側120またはメッセージ消費側140上で実行されているどんなアプリケーションのどんなクライアントセッションも、そのままにされる。メッセージ作成側110は、後でより詳細に論じるように、クリーンアップの前にクライアントスコープインスタンスのコンテキストを異なるメッセージ作成側に複製することによって、ユーザが異なるノード上で(例えばメッセージ作成側120上の異なるアプリケーショ
ンスコープインスタンス中で)アプリケーションについてのクライアントセッションをトランスペアレントに再開するのを可能にすることができる。
【００３９】
システム100は、リソース管理モジュール110-5、120-5、および140-5のうちの1つまたは複数を使用して、1つまたは複数のスコープインスタンス510、520、530、540、および550に対して、定義された寿命を強いることができる。例えばタイムアウトのせいでまたは親がその寿命の終わりにあるせいで、スコープインスタンスがその寿命の終わりにあるとシステム100が決定したとき、システム100は、スコープインスタンスの寿命の間にこのコンテキスト中で割り振られていたどんなリソースも共に、スコープインスタンスを解放することができる。仮想スコープインスタンスの場合、スコープインスタンスのクリーンアップをトリガしたメッセージ作成側110および120ならびにメッセージ消費側140のうちの1つはまた、任意の関連するコンピュータインフラストラクチャインスタンスに、このスコープインスタンスのどんなコンテキストもクリーンアップするよう通知することができる。
【００４０】
開発者は、例えば既存のクライアントスコープインスタンスを削除することによって、任意の時点でいくつかのスコープインスタンスを手動で解放するオプションを有することができる。加えて、開発者は、後述するようにリソース昇格を実施することによって、リソースがその最初のスコープインスタンスの寿命を超えて利用可能のままであるようにすることができる。いくつかの実施形態では、開発者はまた、所与のスコープのタイムアウト値をリセットすることによって、所与のスコープインスタンスのライフサイクルが延長されるよう要求することができる。しかし、このような要求がメッセージ作成側110もしくは120またはメッセージ消費側140によって許可された場合、この要求は、開発者がメッセージ作成側110もしくは120またはメッセージ消費側140のインフラストラクチャを通したスコープインスタンスのライフサイクル管理を迂回しないようにするために、定義された期間のみにわたって有効とすることができる。
【００４１】
リソース管理モジュール110-5、120-5、または140-5は、既存のリソースを新しいまたはより広いスコープインスタンスに昇格させることができ、これによりリソースは、その前のスコープインスタンスから除去されてよい。例えば、最初に要求スコープインスタンス中で割り振られたオブジェクトを、クライアントスコープインスタンスに昇格させて、このオブジェクトがクライアントからの次の要求に対して引き続き利用可能であるようにすることができる。別の例は、それ自体のメソッドスコープインスタンス中で実行されるメソッド呼出しの外部で戻り値または例外を公開することである。この戻り値または例外を使用して、最初にメソッドのスコープインスタンスの内部で割り振られていた任意の関連する結果をメソッドの呼出し元に渡すことができる。これにより、これらの結果は、メソッドのスコープインスタンスの終わりを生き延びることができ、メソッドスコープインスタンスの親に移動することができる。
【００４２】
リソース昇格は、スコープ階層500の内部でのみ可能とすることができ(すなわち、開発者はリソースを所与のスコープインスタンスからその直接の親のうちの1つに昇格させることができる)、リソースの可視性を高めることができる。
【００４３】
リソース管理モジュール110-5、120-5、および140-5は、短命のスコープインスタンスを、それらの寿命が終わったときに解体することができ、それにより、そのスコープ中で割り振られた全てのリソースを解放することができる。いくつかの長命のスコープインスタンスの場合、メッセージ作成側110または120あるいはメッセージ消費側140は、このスコープインスタンスの寿命が終わる前に明示的なリソース割振り解除を開発者が要求できるようにしてよい。これは、対応するスコープタイプ上、例えばクライアントまたはアプリケーションスコープタイプ上で公開される専用APIによって達成することができる。一実施形態では、スコープインスタンス(これは最初は論理概念でしかない)を、実行時のオブジェクトインスタンス(これはコンピュータメモリ中の論理概念の物理表現である)によって表すことができる。例えば、セッションスコープインスタンスを、Java（登録商標）エンタープライズエディションサーブレットスタンダード(Java（登録商標） Enterprise Edition Servlet Standard)の場合のように、セッションスコープオブジェクトインスタンスによって表すことができる。多くの並列セッションスコープインスタンスがある可能性があるので、実行時に多くの並列セッションスコープオブジェクトインスタンス(すなわちユーザおよびアプリケーションごとに1つ)がある可能性もまたある。
【００４４】
このスコープオブジェクトは、このスコープオブジェクトインスタンスの寿命を終わらせる(関連するスコープインスタンスの寿命の終わりを含意する)ためのメソッドなど、任意の当事者が使用するためのいくつかのAPIを公開する。特に、スコープオブジェクトはまた、このスコープインスタンス中で現在生きておりしたがってスコープオブジェクトインスタンスの内部コンテキストの一部として記憶されているリソースを割振り解除するためのメソッドを公開することができる。開発者がこのメソッドをオブジェクトインスタンス上で呼び出して、割振り解除するリソースへの参照を渡した場合は、リソースはスコープオブジェクトインスタンスから明示的に除去される。
【００４５】
データを除去するための明示的なAPIを公開しない長命のスコープタイプの場合、対応するスコープインスタンスのコンテキストは、リソース管理モジュール110-5、120-5、および140-5によって必要に応じてクリーンアップすることができる。特に、いくつかの長命のスコープは、参照カウンティングに基づく通常の「トラディショナル」ガベージコレクションの恩恵を受けて、使用されない記憶域を解放することができる。
【００４６】
コンテキスト複製
リソース管理モジュール110-5、120-5、および140-5は、それぞれのインフラストラクチャの所与のインスタンス内部のリソースを管理することを超えて、スコープコンテキストを使用してメッセージ作成側110および120とメッセージ消費側140との間で関連データグループをトランスペアレントに共有することができる。図6Aに、メッセージ作成側110および120とメッセージ消費側140との間でコンテキストデータをトランスペアレントに共有するための例示的なメッセージ600を示す。メッセージ600は、メッセージヘッダ610およびメッセージペイロード620を含むことができる。メッセージヘッダ610は、例えば相関ID611および他のヘッダ612を含むことができる。メッセージペイロード620は、例えばターゲットオブジェクトID621、ターゲットメソッド名622、および/または1組のメソッド呼出しパラメータ623を含むことができる。一実施形態では、メッセージに関連するスコープについてのコンテキスト630が、メッセージ600に添付されるかまたは含まれてよい。コンテキストは、メッセージに関連するスコープに割り振られたリソース631および632を含むことができる。これにより、メッセージ作成側110および120とメッセージ消費側140とが、関係するデータグループをそれらの間でトランスペアレントに共有するのを可能にすることができる。したがって、本発明のこの実施形態は、ソースシステムとターゲットシステムとの間の進行中の要求に依拠して全ての当事者間でコンテキストデータをトランスペアレントに共有し、この実施形態は、コンテキストインスタンスが少量のデータしか含まない場合に適切とすることができる。
【００４７】
図6Bに、それぞれのメッセージヘッダ610および650中の相関ID611および651によって要求メッセージ600と論理的に関連付けることのできる、対応する応答メッセージ601を示す。メッセージヘッダ650は、他のヘッダ652も含むことができる。応答メッセージは、メソッド呼出しの結果を発信側システムに搬送し返す。すなわち、メッセージペイロード640は、メソッド呼出し結果641を含むことができる。一実施形態では、スコープについてのコンテキスト630がメッセージ601に添付されるかまたは含まれてよい。このコンテキストは、メッセージ600に添付されたコンテキスト630と同じ論理識別を有するが、ターゲットシステム上でのメソッド呼出しの処理中に割り振られた修正済みのまたは新しいリソースを含んでもよい。すなわち、コンテキスト630は、修正済みリソース631、未修正リソース632、および/または新しいリソース633を含むことができる。
【００４８】
図7に、スコープ複製のいくつかの代替実施形態を示す。これらの実施形態は、帯域外コンテキスト複製(すなわち、ターゲットシステムへのどんな進行中の要求からも独立した複製)に依拠する点で共通し、コンテキストインスタンスが多量のデータを含む場合には前述のメッセージベースの手法よりも適切とすることができる。例えば、リソース管理モジュール110-5は、クライアントスコープインスタンスのコンテキストを、予備のメッセージ作成側710、メッセージ消費側140、またはデータベース720に、事前対応的に複製することができる。最初のコピーの後は、後続の複製の手間は、最新の変更をコンテキストの様々なコピーに同期させることに限定することができ、したがって、転送されるデータの量を低減することができる。メッセージ作成側110は、通信ネットワーク130を介して、データベース720、メッセージ消費側140、および予備のメッセージ作成側710と通信することができる。メッセージ作成側710は、メッセージ作成側110と同様の構造とすることができ、例えばプロセッサ710-1と、スレッド710-2と、コンテキスト110-6の複製710-6をモジュール110-4のコピー710-4と共に記憶するためのメモリ710-3とを備え、複製710-6とコピー710-4は両方ともリソース管理710-5によって管理される。複製710-6は、リソース110-7の複製710-7、およびリソース110-8の複製710-8を含むことができる。同様に、データベース720は、リソース複製720-2とリソース複製720-3とを含むコンテキスト複製720-1を記憶することができる。
【００４９】
スコープインスタンス中の個別の要素を、オンデマンドでメッセージ消費側140に複製することもできる。この手法は、スコープインスタンス全体よりも少ない何らかがメッセージ消費側140上で必要な場合に、使用することができる。例えば、子スコープインスタンスがメッセージ作成側110からメッセージ消費側140に複製済みであって、階層500中のその親のうちの1つの個別の要素を参照するときは、これらの要素もまたメッセージ消費側140上で利用可能にする必要がある。これらの参照は、親スコープインスタンスの個別のノードをターゲットとするだけなので、親スコープインスタンスのコンテキスト全体の複製は、性能の理由で得策ではない場合がある。このような場合、メッセージ消費側140は、親スコープの個別の要素をメッセージ作成側110にオンデマンドで要求することを選択することができる。
【００５０】
スコープコンテキストを複製しても、元のスコープインスタンスの寿命は延長されないものとすることができる。そうではなく、ただ元のスコープコンテキストのリソースのコピーを含む、それ自体の独立したライフサイクルを有する2次スコープコンテキストを生み出すことができる。これは、スコープ階層500の全体構造および所有権関係を維持するのに必要であることがある。上の例では、予備のメッセージ作成側710上の複製されたクライアントスコープコンテキストは、それ自体のライフサイクルを有することができる。特に、予備のメッセージ作成側710が管理上の理由でシャットダウンされた場合、複製されたクライアントスコープコンテキストもまた閉じられる必要があることがある。これは、どんな形でも起源スコープインスタンスに影響を及ぼさないものとすることができるが、例外として、起源スコープインスタンスをホストするコンピュータは、新しい予備のノード上に別の複製クライアントスコープインスタンスを生み出す必要があることがある。
【００５１】
トランスペアレントな分散およびモジュール更新
メッセージ作成側110が突然死んだ場合、クライアントは、フェイルオーバ処理中にメッセージ作成側710上で生み出された新しいクライアントスコープインスタンスから、複製されたコンテキスト710-6にアクセスすることによって、予備のメッセージ作成側710上でその作業を継続することができる。新しいクライアントスコープインスタンスはまた、データベース720の複製されたコンテキスト720-1にアクセスすることによって、メッセージ作成側110上の失敗したコンテキストの内容をロードすることができる。
【００５２】
トランスペアレントな分散のために、メッセージ作成側110は同様に、コンテキスト110-6に関連するスコープインスタンスを有するメッセージをメッセージ消費側140が処理できるように、コンテキスト110-6を帯域外複製によってメッセージ消費側140に複製することができる。
【００５３】
図8に、本発明による、クライアント要求の終端間処理のために負荷を分散させるプロセスを示す。クライアント要求は、例えばHTTP要求を含むことができる。要求処理負荷を分散させるために、ロードバランサが、クライアントから要求を受信し(S801)、入来要求の発送先としての適切なメッセージ作成側110または710を決定する(S802)ことができる。ロードバランサは、この決定を行うために、ロードバランサの以前のルーティング決定に関する知識、ルーティングポリシ、利用可能な各メッセージ作成側の現在の負荷、ならびに利用可能なメッセージ作成側のスケジュールされたダウンタイムなど、その現在の構成および内部アルゴリズムに依拠することができる。選択されたメッセージ作成側110または710は、ロードバランサから要求を受信し、要求の処理を開始する(S803)。この処理中、メッセージ作成側110または710は、ローカルまたはリモートモジュール中のオブジェクト上の様々なメソッドを呼び出すことを選択することができる(S804)。これらのメソッド呼出しの実施の詳細は、図2に概説したステップに従い、それにより、リモートモジュールを呼び出すときであっても、高い程度のネットワーク透過性を保証する。例えば、メッセージ作成側110または710は、この能力を利用して、それ自体では現在扱うことのできないいくらかの負荷を他のシステムに移すことができ、あるいは、メッセージ作成側110または710以外のネットワーク中の専用システムインスタンスにクリティカルプロセスを限定する何らかのセキュリティ制約を施行することができる。要求処理の間、メッセージ作成側110または710はまた、以下および図10に概説するステップに続いて、モジュール110-4または710-4の実行をリフレッシュする(S805)ことを選択することができる。要求の処理を完了した後、応答が、ロードバランサに返され(S806)、そこからクライアントに返される(S807)。
【００５４】
実際の要求処理とは独立に、メッセージ作成側110および710、メッセージ消費側140、またはデータベース720は、バックグラウンドでアクティブであることができ、それにより、図7で述べた帯域外コンテキスト複製メカニズムに続いて全てのスコープコンテキストインスタンスがこれらの異なるシステム間で同期されたままであるようにすることができる。特にこれは、要求処理中に修正されたコンテキストインスタンスに適用されてよく、それにより、これらのシステムのうちの1つの、起こり得る突然の停止の影響が最小限に抑えられるようにすることができる。やはり実際の要求処理とは独立に、これらの各システムは、各システムの現在利用可能な容量に応じて、新しい入来クライアント要求からより多くのまたはより少ない負荷が割り当てられるように、ロードバランサに要求することができる。
【００５５】
図9に、本発明による、メッセージ処理の負荷を分散させるための別のプロセスを示す。メッセージ作成側110は、すでにクライアントからの所与の要求を処理している間でも、メッセージ作成側110が過負荷かどうか判定することができる(S901)。メッセージ作成側110が過負荷でないと判定した場合は、メッセージを処理し応答を送信することによって、メッセージ作成側110上で通常通り処理を継続することができる(S902およびS903)。メッセージ作成側110が過負荷であると判定した場合は、メッセージ作成側110は、メッセージ110-10(S904)、およびメッセージに関連するスコープについてのコンテキスト110-6(S905)を、別のメッセージ作成側710に転送することができる。次いでメッセージ作成側710は、コンテキスト110-6のコピー710-4を使用してメッセージ110-10を処理することができ(S906)、その後、要求に対する応答をロードバランサに直接返すことができる(S907)。同様のメカニズムにより、すでに所与の要求を処理しているメッセージ消費側140は、負荷を別のメッセージ消費側(図示せず)に動的に移すことができる。
【００５６】
図10に、本発明による、システム100がオンラインのままである間にモジュールを更新するための例示的なプロセスを示す。モジュール140-4などのモジュールを更新する必要があると判定されたとき、メッセージ消費側140は、モジュール140-4によるキュー140-6からのメッセージ消費を一時停止することができる(S1001)。次いで、キュー140-6は、メッセージ消費側140がモジュール140-4を更新する間に、入来メッセージをキューイングし続けることができる(S1002)。モジュール140-4が更新された後、モジュール140-4は、キュー140-6からのメッセージの処理を再開することができる(S1003)。キュー140-6がメッセージでオーバーフローしない限り、モジュール140-4の更新は、メッセージ作成側110および120に対してトランスペアレントのままとすることができる。加えて、モジュール140-4によるメッセージの処理が再開できる前に、メッセージ消費側140は、キュー140-6に記憶されたメッセージが、またはコンテキスト140-7および140-8に記憶されたリソースのコピーが、更新されたモジュール140-4中のタイプ宣言と互換するようにする必要がある。これは、メッセージ処理を再開した後のタイプ互換性エラーを防止するために必要であることがある。
【００５７】
実行の変形
本明細書に開示するシステムおよび方法は、様々な形に組み入れることができ、例えば、 データベースも備えたコンピュータなどのデータプロセッサの形、または、個別ではデータを永続させるどんな能力も持たないかもしれない組込みデバイスのネットワークの形が含まれる。さらに、本発明に関する上記の特徴ならびに他の態様および原理は、様々な環境で実現することができる。そのような環境および関係する適用例は、本発明による様々なプロセスおよび動作を実施するために特別に構築されたものであってもよく、あるいは、コードによって選択的にアクティブ化されるかまたは再構成されて必要な機能を提供する汎用コンピュータまたはコンピューティングプラットフォームを含むものであってもよい。本明細書に開示するプロセスは、どんな特定のコンピュータまたは他の装置にも本質的に関係せず、ハードウェア、ソフトウェア、および/またはファームウェアの適切な組合せによって実現することができる。例えば、様々な汎用マシンを、本発明の教示に従って書かれたプログラムと共に使用することができ、あるいは、必要とされる方法および技法を実施するための特殊化された装置またはシステムを構築する方がより好都合であることもある。
【００５８】
本発明によるシステムおよび方法はまた、本発明の方法およびプロセスに基づく様々なコンピュータ実行可能な動作を実施するためのプログラム命令またはコードを含むコンピュータ可読記憶媒体を含む。媒体およびプログラム命令は、本発明の目的のために特別に設計および構築されたものであってもよく、あるいは、コンピュータソフトウェア技術の当業者に周知かつ利用可能な種類のものであってもよい。プログラム命令の例としては、例えば、コンパイラによって作成されるものなどのマシンコード、および、インタープリタを使用してコンピュータによって実行できる高レベルコードを含むファイルが含まれる。
【００５９】
特に明記しない限り、開示した方法における様々なステップは、本明細書に列挙した厳密な順序で実施する必要はない。そうではなく、これらのステップは、当業者に周知のように種々の順序で実施することができる。
【００６０】
本発明による可能な実施形態に関する以上の記述は、述べた実施形態の全てのそのような実施形態または全ての変形の包括的なリストを表すものではない。いくつかの実施形態のみに関する記述を、他の実施形態を排除する意図として解釈すべきではない。以下の特許請求の範囲から逸脱しない均等物および代替を使用して、どのように添付の特許請求の範囲における本発明を多くの他の方法で実施するかについては、当業者なら理解するであろう。
【符号の説明】
【００６１】
100 システム
110 メッセージ作成側
110-1 プロセッサ
110-2 スレッド
110-3 メモリ
110-4 モジュール
110-5 リソース管理モジュール、リソースマネージャ
110-6 第1のスコープインスタンスのコンテキスト
110-7 リソース
110-8 リソース
110-9 アウトバウンドキュー
110-10 アウトバウンドメッセージ
110-11 モジュール
110-12 コンテキストコピー
110-13 インバウンドキュー
120 メッセージ作成側
120-1 プロセッサ
120-2 スレッド
120-3 メモリ
120-4 モジュール
120-5 リソース管理モジュール、リソースマネージャ
120-6 第2のスコープインスタンスのコンテキスト
120-7 リソース
120-8 リソース
120-9 アウトバウンドキュー
120-10 アウトバウンドメッセージ
130 通信ネットワーク
140 メッセージ消費側
140-1 プロセッサ
140-2 スレッド
140-3 メモリ
140-4 モジュール
140-5 リソース管理モジュール、リソースマネージャ
140-6 インバウンドキュー
140-7 第1のスコープインスタンスのコンテキストの現コピー
140-8 第2のスコープインスタンスのコンテキストの現コピー
140-9 モジュール
140-10 コンテキスト
140-11 リソース
140-12 リソース
140-13 アウトバウンドキュー
140-14 メッセージ
300 非同期通信
301 モジュール
302 メッセージ
303 キュー
304 モジュール
400 非同期通信
401 モジュール
402 メッセージ
403 トピック
404 モジュール
405 モジュール
500 階層
510 親スコープ
511 コンテキスト
512 リソース
513 リソース
520 子スコープ
521 コンテキスト
522 リソース
523 リソース
530 子スコープ
531 コンテキスト
532 リソース
533 リソース
540 親スコープ
541 コンテキスト
542 リソース
543 リソース
550 子スコープ
551 コンテキスト
552 リソース
553 リソース
600 メッセージ
601 応答メッセージ
610 メッセージヘッダ
611 相関ID
612 他のヘッダ
620 メッセージペイロード
621 ターゲットオブジェクトID
622 ターゲットメソッド名
623 メソッド呼出しパラメータ
630 コンテキスト
631 リソース、修正済みリソース
632 リソース、未修正リソース
633 新しいリソース
640 メッセージペイロード
641 メソッド呼出し結果
650 メッセージヘッダ
651 相関ID
652 他のヘッダ
710 メッセージ作成側
710-1 プロセッサ
710-2 スレッド
710-3 メモリ
710-4 モジュール110-4のコピー
710-5 リソース管理
710-6 コンテキスト110-6の複製
710-7 リソース110-7の複製
710-8 リソース110-8の複製
720 データベース
720-1 コンテキスト複製
720-2 リソース複製
720-3 リソース複製
【技術分野】
【０００１】
本発明によるシステムおよび方法は、一般に、非同期通信およびスコープを使用してモジュールを分離することに関する。
【背景技術】
【０００２】
ビジネスおよび他の組織は、その運営の間に、様々なデータアイテムおよび電子情報(以下では広く「ビジネスデータ」として言及する)を生成および/または受信する。例えば、クラウドコンピューティングのコンテキストでは、ビジネスデータは、種々の領域および/または国に位置する様々なエンティティのコンピュータから生成および/または受信されることがある。したがって、コンピュータのネットワークにわたって、ビジネスロジックおよび一時的なビジネスデータ、ならびにこのデータを処理するためのロジックを、分散させることを改善することが必要とされている。
【０００３】
クラウドコンピューティングのコンテキストでは、サーバが、クライアントおよび他のサーバから要求を受け取って処理することができる。クライアントおよび他のサーバは、例えば、種々の領域および/または国に位置する様々なエンティティのコンピュータである場合がある。サーバは、複数のソフトウェアモジュールを使用して要求を扱うことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
これらのモジュールを実行するには、サーバは、サーバリソース(例えばメモリや処理時間など)の一部をモジュールに割り振る必要がある。加えて、サーバのモジュールは通常、「結合」される。すなわち、例えばモジュールは、他のモジュールのパブリッシュされた機能に依拠したり、同じグローバルデータまたは変数にアクセスすることによって状態を共有したりすること等が可能である。 さらに、クラウド環境では、単一のまたは種々のコンピュータシステム上に位置する結合されたモジュールを更新することは、問題を孕む可能性がある。同様に、結合されたモジュールをオペレータが自発的にスケーリングしたいときにもまた、困難が生じる。加えて、一般にサーバリソースは非常に非構造的な方式で割り振られ使用されるので、クラウド環境にわたるリソースの伝送は困難であることがある。したがって、より構造化されたサーバリソース管理手法を使用して、モジュールの分離を可能にすることが必要とされている。
【課題を解決するための手段】
【０００５】
本発明の一実施形態によれば、コンピュータシステム中でモジュールを分離する方法、および、この方法を実行するための命令を記憶したコンピュータ可読媒体が開示される。この方法は、例えば、非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信すること、メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持すること、コンテキストのコピーを第2のホストに送信すること、第1のモジュールを一時停止すること、メッセージが第2のモジュールによって処理されたことを示す応答を受信すること、コンテキストのコピーの更新を第2のホストから受信すること、更新をスコープ階層中のコンテキストに組み込むこと、および、第1のホスト上の第1のモジュールを再開することを含むことができる。
【０００６】
本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、例えば、ネットワークを介してメッセージを送信するように構成された通信ユニットと、メッセージの送信を抑制するためのキューを記憶したメモリと、リソースマネージャとを備えることができる。リソースマネージャは、コンテキストをスコープ階層中で維持し、メッセージに関連するスコープを生み出し、コンテキストのうちの1つまたは複数を受信コンテキストとマージするためのものとすることができる。
【０００７】
本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、ネットワークを介してモジュールに対するメッセージを受信するための受信機と、モジュールを実行してメッセージを処理するためのプロセッサと、メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備えることができ、コンテキストは、メッセージに関連するスコープのリソースを含む。
【０００８】
以上の一般的な記述と、以下の詳細な記述とは両方とも、例示的および説明的なものに過ぎず、記述され特許請求される本発明の範囲を限定するものと考えるべきではないことを理解されたい。さらに、本明細書に述べるものに加えて特徴および/または変形を提供することもできる。例えば、本発明の実施形態は、詳細な記述で述べる特徴の様々な組合せおよびサブコンビネーションを対象とすることもできる。
【０００９】
本開示に組み込まれ本開示の一部をなす添付の図面に、本発明の様々な実施形態および態様を示す。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明による、モジュールをトランスペアレントに分離するための例示的なシステムを示す図である。
【図１Ｂ】本発明による、モジュールをトランスペアレントに分離するための別の例示的なシステムを示す図である。
【図２】本発明による、モジュールをトランスペアレントに分離するための例示的なプロセスを示す図である。
【図３】本発明による、キューを使用した例示的な非同期通信を示す図である。
【図４】本発明による、トピックを使用した例示的な非同期通信を示す図である。
【図５】本発明による例示的なスコープ階層を示す図である。
【図６Ａ】本発明による例示的な要求メッセージを示す図である。
【図６Ｂ】例示的な応答メッセージを示す図である。
【図７】本発明による、スコープコンテキストを複製するための例示的なシステムを示す図である。
【図８】本発明による、負荷平衡のための例示的なプロセスを示す図である。
【図９】本発明による、負荷平衡のための追加の例示的なプロセスを示す図である。
【図１０】本発明による、モジュールを更新するための例示的なプロセスを示す図である。
【発明を実施するための形態】
【００１１】
以下の詳細な記述では、添付の図面を参照する。可能な場合には、図面および以下の記述において、同じまたは類似の部分を指すのには、同じ参照番号を使用する。本発明のいくつかの例示的な実施形態および特徴について本明細書に述べるが、本発明の趣旨および範囲を逸脱することなく、修正、適応、および他の実施形態も可能である。例えば、図面に示すコンポーネントに対して代用、追加、または修正を行うこともでき、また、開示する方法に対してステップを代用、並べ替え、または追加することによって、本明細書に述べる例示的な方法を修正することもできる。したがって、以下の詳細な記述は本発明を限定しない。そうではなく、本発明の正しい範囲は、添付の特許請求の範囲によって定義される。
【００１２】
発明の概観
本発明によるシステムおよび方法は、一般に、モジュール分離およびトランスペアレントな分散を提供することに関する。本発明によるシステムおよび方法は、クラウドコンピューティング環境で利用することができる。トランスペアレントな分散およびモジュール分離は、非同期通信およびスコープを使用して達成することができる。
【００１３】
図1Aに、本発明によるシステム100を示す。システム100は、メッセージ作成側110および120が通信ネットワーク130によってメッセージ消費側140に接続されているのを示す。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、ビジネスコンピュータシステムとすることができる。メッセージ作成側110および120ならびにメッセージ消費側140はまた、種々の抽象化レベルで見ることができる。例えばこれらは、システムのリソース全体をカバーするノードレベルから、スレッドのリソースをカバーするスレッドレベルまでで見ることができる。加えて、メッセージ作成側110および120ならびにメッセージ消費側140のユーザおよびクライアントは、メッセージ作成側110、120ならびにメッセージ消費側140の特定の「セキュリティ領域」に制限することができる。すなわち、セキュリティの目的で、ユーザおよびクライアントからメッセージ作成側110および120ならびにメッセージ消費側140のいくつかのリソースへのアクセスを制限することができる。通信ネットワーク130は、メッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。図1Aに示すコンポーネント110、120、および140の数が例示的であることは、当業者なら理解するであろう。したがって、本発明によるシステム100は、任意の数のメッセージ作成側110もしくは120、または任意の数のメッセージ消費側140を含むことができる。図1Bに別の可能なシステムを示すが、このシステムは、メッセージ消費側とメッセージ作成側とがちょうど対称であってもよいことを強調するもので、メッセージ消費側とメッセージ作成側とがそれぞれの役割を実行時に切り替えることができる。
【００１４】
通信ネットワーク130は、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、またはインターネットなど、1つまたは複数のネットワークタイプを含むことができる。通信ネットワーク130は、ワイヤラインおよび/またはワイヤレス技術によって動作することができ、伝送制御プロトコル/インターネットプロトコル(TCP/IP)またはいずれか他の適切なプロトコルを使用して、システム100のメッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。ネットワーク130内のネットワーク接続は、イーサネット（登録商標）、電話回線、セルラーチャネル、または他の伝送媒体を介して確立することができる。ネットワーク130を介したデータ通信は、メッセージ作成側110および120ならびにメッセージ消費側140などのデバイス間でデータパケットを伝送することによって容易にすることができる。本明細書に述べるデータ伝送は、例えば、単一のデータパケット中で送信されてもよく、あるいはいくつかのデータパケットにわたって分割されてもよい。さらに、メッセージ作成側110および120は、ネットワーク130を介してメッセージ消費側140と非同期通信することができる。
【００１５】
システム100のメッセージ作成側110および120ならびにメッセージ消費側140は、1つまたは複数のアプリケーションプログラムおよび1つまたは複数のハードウェアコンポーネントの組合せなど、多くのインフラストラクチャを含むことができる。例えば、アプリケーションプログラムは、本発明の開示される動作を実行する、ソフトウェアモジュール、命令のシーケンス、ルーチン、データ構造、表示インタフェース、および他のタイプの構造を含むことができる。メッセージ作成側110および120ならびにメッセージ消費側140のハードウェアコンポーネントは、中央処理装置(CPU)、バス、メモリデバイス、記憶ユニット、データプロセッサ、入力デバイス、出力デバイス、ネットワークインタフェースデバイス、および、当業者には明らかであろう他のタイプのコンピュータシステムコンポーネントの組合せを含むことができる。したがって、メッセージ作成側110および120ならびにメッセージ消費側140は、ハンドヘルドデバイス、パーソナルコンピュータ、またはメインフレームコンピュータなど、任意のタイプのコンピュータデバイスによって実現することができる。
【００１６】
メッセージ作成側110および120ならびにメッセージ消費側140は、それぞれプロセッサ110-1、120-1、および140-1を備えることができる。プロセッサ110-1、120-1、および140-1はプロセスを実行することができ、プロセスは、スレッド110-2、120-2、および140-2などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はさらに、メモリ110-3、120-3、および140-3を備えることができる。メモリ110-3、120-3、および140-3は、不揮発性または揮発性メモリなど任意の形のコンピュータ可読記憶媒体を含むことができ、例としてこれらには、EPROM、RAM、ROM、DRAM、EEPROM、フラッシュメモリデバイスなどの半導体メモリデバイス;内蔵ハードディスクや取外し可能ディスクなどの磁気ディスク;光磁気ディスク;およびCD-ROM、DVD、またはブルーレイディスクが含まれる。
【００１７】
スコープおよびコンテキスト
メモリ110-3、120-3、および140-3はそれぞれ、モジュール110-4、120-4、および140-4などのソフトウェアモジュールを含むことができる。モジュール110-4、120-4、および140-4は、それぞれプロセッサ110-1、120-1、および140-1によって実行される命令を含むことができる。上に論じたように、命令はさらに、スレッド110-2、120-2、および140-2などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はそれぞれさらに、「スコープ」を使用してリソースを管理するために、リソース管理モジュール110-5、120-5、および140-5などのリソース管理モジュールを備えることができる。「リソース」は、例えばメモリデータ構造、データベース接続、またはセキュリティ許可において、特定のプロセスを実行するのに必要なものなら何でも含むことができる。「スコープ」は、定義された期間にわたってコンピュータ上でグループ化される複数のリソースを含むことができる。スコープタイプの例は、要求スコープ、ユーザスコープ、プロセススコープなどである。スコープタイプの追加の例については、以下でさらに詳細に論じる。メッセージ作成側110および120ならびにメッセージ消費側140は、スコープタイプを実行時にインスタンス化して、スコープインスタンスを生み出すことができる。スコープインスタンスは、実行時にこのインスタンスを識別するための論理IDを含むことができる。このIDは、大域的に一意とすることができる(すなわち、スコープタイプを同じくするかまたは異にする、異なるスコープインスタンスは、異なるIDを有さなければならない)。
【００１８】
リソース管理モジュール110-5、120-5、および140-5は、リソースをスコープインスタンスに関連付けて、システム100内部で割り振られる任意のリソースの寿命を明確に線引きすることができる。いくつかの実施形態では、システム100中には、スコープインスタンスに関連付けられないリソースがないことがある。しかし、本発明のいくつかの実施形態では、所有主であるスコープインスタンスは非常に粗粒であることがある。すなわち、スコープインスタンスは、システム100の大きなコンポーネントをカバーし、より小さいスコープインスタンスに細分できないことがある。例えば、この設定は、スコープインスタンスをバッチジョブよりも低い細粒度にさらに分割することから何の利益も得られそうにない場合の、ローカルバッチ処理のみに向けられたシステム中で適切であることがある。リソース管理モジュール110-5、120-5、および140-5は、リソースをスコープインスタンス中で割り振ったりスコープインスタンスから解放したりすることによって、リソースを管理することができる。リソース管理モジュール110-5、120-5、および140-5は、リソースが生み出されるとき、リソースをちょうど1つのスコープインスタンスに割り振ることができ、リソースが個別に削除されるとき、このスコープインスタンスからリソースを解放することができる。リソース管理モジュール110-5、120-5、および140-5は、リソースを所有するスコープインスタンスが例えばタイムアウトのせいで解放されるとき、リソースを解放することができる。リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを暗黙的に定義することができ、それにより、メモリ領域、すなわちオブジェクトを割り振る構造をプログラマが明示的に宣言しなくて済むようにすることができる。さらに、リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを使用して、ローカルに割り振られたオブジェクトをメッセージ作成側110および120ならびにメッセージ消費側140などの協働ノードのネットワーク中で分散させて、リモート通信の透過性を高めることができる。
【００１９】
リソース管理モジュール110-5、120-5、および140-5は、スコープインスタンスを、その「コンテキスト」と呼ばれる定義された記憶エリアに関連付けることができる。コンテキストは、一時的(メモリ中)とすることもでき、あるいは永続的(ディスク上)とすることもできる。コンテキストはシステム100中で冗長的に存在できるが、スコープインスタンスは通常、いずれか所与の時点で単一のメッセージ作成側110もしくは120またはメッセージ消費側140上でのみアクティブであるという点で、コンテキストは、それに関連するスコープインスタンスとは異なるものとすることができる。例えば図1Aでは、メッセージ作成側110のメモリ110-3は、第1のスコープインスタンスのコンテキスト110-6を含む。同様に、メッセージ作成側120のメモリ120-3は、第2のスコープインスタンスのコンテキスト120-6を含む。リソース管理モジュール110-5は、スコープインスタンスの寿命の間にスコープインスタンスに関連付けられる任意のリソースを割り振ることができる。例えば、第1のスコープインスタンスのコンテキスト110-6は、割り振られたリソース110-7および110-8を含む。同様に、第2のスコープインスタンスのコンテキスト120-6は、割り振られたリソース120-7および120-8を含む。
【００２０】
スコープインスタンスは、メッセージ作成側110および120ならびにメッセージ消費側140のそれぞれにおいて1つのコンテキストを有することによって、メッセージ作成側110および120ならびにメッセージ消費側140の間を移行することができる。リソース管理モジュール110-5、120-5、および140-5などのリソース管理モジュールは、これらのコンテキストのうちの1つを好ましいインスタンスとして割り当てて、種々のマシン間で過剰なデータ移動がないようにすることができる。スコープ中の好ましいインスタンスは、このスコープインスタンスに関係する全てのタスクをデフォルトで扱うインスタンスとすることができる。他のマシン上の他のコンテキストインスタンスは、コンテキストのこの好ましいインスタンスと同期して、所与のスコープインスタンス内でのデータ不整合を回避することができる。
【００２１】
非同期通信
図1Aに示すように、メモリ110-3および120-3は、それぞれアウトバウンドキュー110-9および120-9を含む。アウトバウンドキュー110-9および120-9は、それぞれアウトバウンドメッセージ110-10および120-10を含むことができる。コンテキスト110-6は、リソース110-7および110-8など、メッセージ110-10を処理するのに必要なリソースを含むことができる。すなわち、メッセージ110-10は、第1のスコープインスタンスであるスコープ1に関連することができる。コンテキスト120-6は、リソース120-7および120-8など、メッセージ120-10を処理するのに必要なリソースを含むことができる。すなわち、メッセージ120-10は、第2のスコープインスタンスであるスコープ2に関連することができる。メッセージ消費側140のメモリ140-3は、インバウンドキュー140-6を含むことができる。インバウンドキュー140-6は、アウトバウンドキュー110-9から受け取ったメッセージ110-10、およびアウトバウンドキュー120-9から受け取ったメッセージ120-10を含むことができる。
【００２２】
同様に、図1Bに示すように、メッセージ消費側140はまた、他のモジュール140-9を備えることができ、リソースマネージャ140-5は、リソース140-11および140-12を含むコンテキスト140-10など、スコープインスタンスについてのコンテキストを割り振ることができる。メッセージ消費側140はまた、メッセージ作成側110などのメッセージ作成側または他のメッセージ消費側にメッセージ140-14を送信するためのアウトバウンドキュー140-13を備えることができる。メッセージ作成側110もまた、他のメッセージ作成側またはメッセージ消費側140からメッセージ140-14を受信するためのインバウンドキュー110-13を備えることができる。メッセージ作成側110は、モジュール110-4または別のモジュール110-11を使用して、メッセージ140-14を処理することができる。加えて、メッセージ作成側110はまた、メッセージ140-14についてのコンテキストのコピー、すなわちコンテキストコピー110-12を受信することができる。
【００２３】
例えば、図1B中のモジュール110-4が、ネットワーク130によってメッセージ作成側110から分離されているメッセージ消費側140上にモジュール140-4があることを知らずに、モジュール140-4の機能にアクセスしたいと仮定する。モジュール110-4は、モジュール140-4を表すメモリ110-3中のリソースに対して、メソッド呼出しを開始することができる。このメソッド呼出しは、スレッド110-2上で実施することができる。次いで、呼び出されたリソースは、メソッド呼出しをメッセージ110-10に変換することができ、スレッド110-2は、メッセージ110-10をアウトバウンドキュー110-9上に配置することができる。その後、メッセージ140-14などの応答メッセージまたは肯定応答がメッセージ作成側110に返されるまで、スレッド110-2を保留するかまたはメッセージ作成側110中の他のタスクに利用することができる。メッセージ作成側110のスレッドスケジューリングアルゴリズムに応じて、同じまたは異なるスレッド110-2が、メッセージ作成側110のインバウンドキュー110-13からメッセージ140-14などの応答メッセージを得て、元のメソッド呼出しのすぐ後に続く命令ステップでモジュール110-4の処理を再開する。
【００２４】
図1A中のメッセージ110-10および120-10を処理するために、メッセージ消費側140は、メッセージ110-10および120-10に関連するスコープインスタンスのリソースへのアクセスを必要とすることがある。これが起こるのを可能にするために、本発明によるシステム100は、メッセージ110-10および120-10に関連するスコープインスタンスのコンテキストを、メッセージ消費側140にコピーする。このプロセス中で、システム100は、データがコンテキストの様々なコピー間で同期するようにして、データ破損を防止する。コピープロセスがいくらかの時間を要する場合は、システム100は、コピープロセスが完了するまで、メッセージ消費側140へのメッセージ110-10および120-10の配信を遅延させることを選択することができる。したがって、メッセージ110-10および120-10がメッセージ消費側140中で処理されると、メモリ140-3は、第1のスコープインスタンスのコンテキストの現コピー140-7、ならびに第2のスコープインスタンスのコンテキストの現コピー140-8を含む。
【００２５】
前の2つの段落で述べた手法は、図1Aのモジュール110-4および120-4に同期するように見える呼出しをシステム100が非同期に実行するのを可能にすることができる。さらに、この手法はまた、システム100が参照渡し(call-by-reference)セマンティクスによってリモート呼出しを実施するのを可能にすることができる。というのは、呼出し中に使用されるどんな参照の現在の値も、メッセージ消費側140に利用可能にされるからである。この2つの能力の組合せにより、本発明の使用は確実に、モジュール110-4および120-4に対して完全にトランスペアレントのままとなる。すなわち、分散環境で実行されるにもかかわらず、モジュール110-4および120-4は、モジュール140-4がモジュール110-4および120-4と同じメモリ110-3中にあるかのように動作し続けることができる。
【００２６】
特定の方式で構成された特定のコンポーネントを有するものとしてシステム100の例示的な実施形態について述べているが、システム100が、異なるように構成できる追加のまたはより少ないコンポーネントを含んでもよいことは、当業者なら理解するであろう。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、追加のプロセッサおよび/またはメモリデバイスを備えてもよい。さらに、コンポーネント110-4、110-5、110-6、および110-9に例えば含まれるプロセス命令は、複数のメモリデバイスにわたって分散させてもよい。また前述のように、システム100は、図1Aまたは1Bに示すよりも少ないかまたは多いメッセージ作成側110および120ならびにメッセージ消費側140を使用して実現してもよい。
【００２７】
図2に、本発明による、スコープを使用してモジュールをトランスペアレントに分離するための例示的なシステムを示す。ステップS201で、メッセージ作成側110および120のうちの一方に位置することのできるモジュールAが、メッセージ消費側140上に位置することのできるモジュールBのオブジェクトインスタンス上のメソッドを呼び出す。モジュールAから見ると、これは、モジュールBのオブジェクトインスタンスを表すモジュールAのローカルアドレス空間中のオブジェクトインスタンスに対する、ローカルメソッド呼出しである。次いでメッセージ作成側110または120は、要求メッセージをキューに入れ、対応するスレッド(例えばスレッド110-2および120-2)を、モジュールA中のメソッド呼出しを実行するタスクから分離することができる(S202)。次いでこのスレッドは、モジュールAのローカルアドレス空間中での他の処理に使用することができる。この分離により、モジュールAの実行は、メソッド呼出しの継続時間にわたって一時停止される(S203)。次いでメッセージプロバイダ110または120は、要求メッセージをモジュールBに転送することができる(S204)。システム100はまた、関連するどんなスコープコンテキストもモジュールBのローカルアドレス空間に暗黙的にコピーすることができる(S205)。これを行うには3つの方法がある。すなわち、メッセージ添付、および事前対応または事後対応(すなわちオンデマンド)の帯域外複製(後で「コンテキスト複製」の章で論じる)である。ステップS204とS205は、並行して行われてよい。次いでシステム100は、要求メッセージをモジュールBのローカルアドレス空間中のメソッド呼出しのターゲットオブジェクトインスタンスに配信する(S206)。メッセージ消費側140は、複製されたスコープコンテキストを必要に応じて参照して、メソッドを実行する(S207)。例えば、メソッド呼出しがパラメータを利用した場合は、複製されたスコープコンテキストからこれらのパラメータにアクセスすることができる。次いでメッセージ消費側140は、メソッド実行の結果を応答メッセージに変換し、これをモジュールBのローカルアドレス空間でキューに入れることができる(S208)。次いでシステム100は、応答メッセージをモジュールAのロ
ーカルアドレス空間に転送することができる(S209)。システム100は、モジュールB中でのメソッド実行中に関連スコープコンテキストに対して加えられたどんな変更も、後で詳述する3つの複製メカニズムのうちの1つを使用してモジュールAのローカルアドレス空間に暗黙的に複製し返すことができる(S210)。やはりステップS209とS210は並行して行われてよい。次いでメッセージ作成側110または120は、モジュールAのアドレス空間中のスレッド(例えばスレッド110-2および120-2)によって応答メッセージをキューから取り出すことができ、モジュールAの実行が再開される(S211)。メッセージをキューから取り出すスレッドは、メソッド呼出しを開始したスレッドと同じスレッドでないことがあるが、元のスレッドと同じスレッドコンテキストを有する必要があることがある。モジュールAをさらに実行する間、どんな関連スコープコンテキストにも、モジュールAによってアクセスすることができる。このようなコンテキストに割り振られたリソースに対してモジュールB上でのメソッド呼出し中に加えられたどんな変更も、モジュールAから見える。
【００２８】
システム100は、インバウンドキュー140-6などのキューを使用して非同期通信することができる。図3に、キューを使用した例示的な非同期通信300を示す。図3に示すように、モジュール301が、メッセージ302をキュー303に送ることができる。次いでモジュール304が、メッセージ302を消費することができる。メッセージ302を消費した後、モジュール304は、メッセージ302の消費をモジュール301に肯定応答することができる。メッセージ302は、ポイントツーポイントメッセージとすることができる。すなわち、メッセージ302は、ちょうど1つの消費側を有することができる。さらに、モジュール301とモジュール304とは、ネットワーク(図示せず)を介して接続された異なるコンピュータ(図示せず)上に位置することができる。メッセージングインフラストラクチャは、最低1回保証の配信、または順番にちょうど1回保証の配信など、メッセージ配信についての様々なサービス品質をサポートすることができる。このようなサービス品質は、トランスポート層におけるいくつかのネットワーク伝送エラーを隔離し、それにより、モジュール層からみたリモート通信の透過性を高める。
【００２９】
システム100は、「トピック」を使用して非同期通信することができる。トピックは、ある基準を満たすメッセージをそれにパブリッシュすることのできる構造である。図4に、トピックを使用した例示的な非同期通信400を示す。図4に示すように、モジュール401は、メッセージ402をトピック403にパブリッシュすることができる。モジュール404および405は、トピック403に申し込むことができる。すなわち、モジュール404および405は、トピック403にパブリッシュされたメッセージを受け取りたいことを示すことができる。次いでトピック403は、メッセージ402をモジュール404および405に配信することができる。非同期通信400によるいくつかの実施形態では、モジュール404および405は、メッセージ402の消費を肯定応答しない。
【００３０】
本発明による実施形態は、非同期通信をデフォルトのメカニズムとして使用して、システム100中で実行される種々のモジュールを分離することができる。このような全ての実施形態では、非同期通信の使用が参加モジュールに対してトランスペアレントのままであるように、非同期通信をシステム100に組み込むことができる。非同期通信は、図示の粗粒モジュール間、またはシステム100の内容を定義する種々のモジュール間における任意のメッセージについて行うことができるが、そうする必要があるわけではない。同期通信をモジュール間通信に使用すると、モジュール間の結合度が増すことがあり、本発明で述べる様々な技法の適用可能性が低下することがある。しかし、同期通信の使用は、本発明のコンテキストでは、例えばモジュール間の高頻度の対話に対する性能を改善するための、一時的な最適化に過ぎないと考えられる。特に、これはいつでもデフォルトの非同期通信で置換することができ、それにより、再びモジュール間の結合を低減し、本発明で述べる様々な技法の使用を可能にすることができる。
【００３１】
メソッドを非同期で呼び出す決定は、厳密に、モジュール開発者によってではなくシステム管理者によって行われる管理上の決定とすることができる。その場合、この決定は、メッセージ作成側110および120またはメッセージ消費側140を再起動せずに、実行時に行うことができ、また覆すこともできる。
【００３２】
スコープ階層およびスコープタイプ
スコープインスタンスは、しばしば階層に編成される。図5に、例示的なスコープインスタンスの階層500を示す。子スコープインスタンスがその親スコープインスタンスよりも長生きしないという制約を階層が満たす限り、階層の正確な形は、本発明の一実施形態において構成可能とすることができる。階層500中で、スコープインスタンス510は、スコープインスタンス510に割り振られたリソース512および513を含むコンテキスト511を有することができる。スコープインスタンス510は、子スコープインスタンス520および530に対する親としての働きをすることができる。子スコープインスタンス520は、子スコープインスタンス520に割り振られたリソース522および523を含むコンテキスト521を有することができる。同様に、子スコープインスタンス530は、子スコープインスタンス530に割り振られたリソース532および533を含むコンテキスト531を有することができる。子スコープインスタンス530はまた、それ自体のコンテキスト541ならびに割り振られたリソース542および543を有する親スコープインスタンス540の子とすることができる。子スコープインスタンス530はまた、それ自体のコンテキスト551ならびに割り振られたリソース552および553を有する子スコープインスタンス550の親としての働きをすることができる。階層は、参加スコープインスタンスのそれぞれの識別に依拠して、親から子へ、および子から親へナビゲート可能とすることができる。
【００３３】
本明細書で論じるスコープは、いくつかのタイプのスコープのいずれかとすることができる。以下のTable 1(表1)に、本発明による例示的なスコープタイプを列挙する。Table 1(表1)は、網羅的でも必須でもない。本発明による一実施形態は、所与のビジネス問題を解決するために適切と見なされる場合には、追加のスコープタイプを定義することができ、あるいはTable 1(表1)からいくつかのスコープタイプを省くことを選択することができる。例えば、バッチ処理システムがバッチスコープタイプを定義することができ、また、バッチシステムは通常はクライアントからのどんな要求にもサービスしないので、要求スコープタイプの使用を控えることができる。
【００３４】
【表１Ａ】
【００３５】
【表１Ｂ】
【００３６】
Table 1(表1)中のいくつかのスコープタイプは、いずれか所与の個別ノードの寿命を超えることがあることに留意されたい。例えば、ユーザスコープまたはクラスタスコープは、それらが最初に生み出された場であるノードが消滅したとしても、存続することができる。このような長生きするスコープタイプは、特定のノードに固定されないことを示すために「仮想」スコープタイプと呼ぶことができる。仮想スコープタイプは、メッセージ作成側110および120ならびにメッセージ消費側140などの複数のノードを包含する単一のスコープインスタンスによって表すことができる。他のスコープインスタンスと同様、仮想インスタンスは、大域的に一意である単一のIDを有することができる。しかし、非仮想スコープインスタンスとは対照的に、仮想スコープインスタンスは、全て並行してアクセス可能なメッセージ作成側110および120ならびにメッセージ消費側140などの種々のノード上の複数のコンテキストインスタンスによって表すことができる。システム100は、種々のノード上で仮想スコープの複数のコンテキストインスタンスを同期的に維持して、どんなデータ破損も回避することを担うことができる。これは例えば、競合のない方式で仮想スコープインスタンスのコンテキストインスタンスを更新するために依拠することのできる中央ロックサービスを提供することによって、達成することができる。
【００３７】
Table 1(表1)の様々なスコープタイプのインスタンスは、階層に編成することができる。スコープインスタンスの階層は、実行時に動的に変化することがある(例えば、新しいユーザがシステムにログオンしたとき、新しいユーザスコープインスタンスが階層に挿入され、以後、このユーザスコープインスタンスを使用してこのユーザのためにリソースを割り振ることができる)。要求が完了したとき、対応する要求スコープインスタンスは、その全ての子と共に階層から除去される。この動的なスコープインスタンス階層はそれでもなお、展開時に構成することのできる明確に定義された安定したタイプ構造に依拠することができる。このタイプ構造が定義された場合は、このタイプ構造により、所与のタイプのスコープインスタンスは常に、階層の自由裁量レベルで挿入されるのではなく、階層中のいくつかの固定スコープタイプの親と子との間に挿入されるようになる。したがって、タイプ構造は、実行時の動的な階層全体のよりよい構造およびよりよい管理可能性に大きく貢献する。
【００３８】
スコープおよびリソースのライフサイクル
階層500のスコープインスタンスは、様々なタイプのスコープを表すことができる。例えば、リソースマネージャ110-5、120-5、および140-5(図1A)は、所与のユーザについての、かつ、このユーザのセキュリティ領域内の全てのコンピュータインフラストラクチャインスタンスにわたる、全てのクライアントスコープインスタンスの親であるユーザスコープインスタンスを共同で維持することができる。同時に、リソースマネージャ110-5、120-5、および140-5のうちの1つは、単一のコンピュータインフラストラクチャインスタンス上で、このユーザのクライアントスコープインスタンスの親としてのアプリケーションスコープインスタンスを維持することができ、したがって、アプリケーションセッションが通常はユーザとアプリケーションとの組合せによって所有されることを反映することができる。リソースマネージャ110-5、120-5、および140-5のうちの1つが親スコープインスタンスのうちの1つを明示的または暗黙的に解放したときは、この親の全ての子スコープインスタンス(したがって子スコープインスタンスに関連する全てのリソース)もまた解放することができる。例えば、ユーザがサインアウトしたとき、ユーザのセキュリティ領域中の全てのリソースマネージャは、関連するユーザスコープインスタンスを解放することができ、リソースマネージャ110-5、120-5、および140-5はそれぞれ、各々システム110、120、および140上のこのユーザの全てのクライアントスコープを解放することができる。メッセージ作成側110上でアプリケーションを閉じると、この作成側上で生きているこのアプリケーションについての全てのクライアントセッションの解放をトリガすることができるが、メッセージ作成側110上の他のアプリケーションのどんなクライアントセッションも、またメッセージ作成側120またはメッセージ消費側140上で実行されているどんなアプリケーションのどんなクライアントセッションも、そのままにされる。メッセージ作成側110は、後でより詳細に論じるように、クリーンアップの前にクライアントスコープインスタンスのコンテキストを異なるメッセージ作成側に複製することによって、ユーザが異なるノード上で(例えばメッセージ作成側120上の異なるアプリケーショ
ンスコープインスタンス中で)アプリケーションについてのクライアントセッションをトランスペアレントに再開するのを可能にすることができる。
【００３９】
システム100は、リソース管理モジュール110-5、120-5、および140-5のうちの1つまたは複数を使用して、1つまたは複数のスコープインスタンス510、520、530、540、および550に対して、定義された寿命を強いることができる。例えばタイムアウトのせいでまたは親がその寿命の終わりにあるせいで、スコープインスタンスがその寿命の終わりにあるとシステム100が決定したとき、システム100は、スコープインスタンスの寿命の間にこのコンテキスト中で割り振られていたどんなリソースも共に、スコープインスタンスを解放することができる。仮想スコープインスタンスの場合、スコープインスタンスのクリーンアップをトリガしたメッセージ作成側110および120ならびにメッセージ消費側140のうちの1つはまた、任意の関連するコンピュータインフラストラクチャインスタンスに、このスコープインスタンスのどんなコンテキストもクリーンアップするよう通知することができる。
【００４０】
開発者は、例えば既存のクライアントスコープインスタンスを削除することによって、任意の時点でいくつかのスコープインスタンスを手動で解放するオプションを有することができる。加えて、開発者は、後述するようにリソース昇格を実施することによって、リソースがその最初のスコープインスタンスの寿命を超えて利用可能のままであるようにすることができる。いくつかの実施形態では、開発者はまた、所与のスコープのタイムアウト値をリセットすることによって、所与のスコープインスタンスのライフサイクルが延長されるよう要求することができる。しかし、このような要求がメッセージ作成側110もしくは120またはメッセージ消費側140によって許可された場合、この要求は、開発者がメッセージ作成側110もしくは120またはメッセージ消費側140のインフラストラクチャを通したスコープインスタンスのライフサイクル管理を迂回しないようにするために、定義された期間のみにわたって有効とすることができる。
【００４１】
リソース管理モジュール110-5、120-5、または140-5は、既存のリソースを新しいまたはより広いスコープインスタンスに昇格させることができ、これによりリソースは、その前のスコープインスタンスから除去されてよい。例えば、最初に要求スコープインスタンス中で割り振られたオブジェクトを、クライアントスコープインスタンスに昇格させて、このオブジェクトがクライアントからの次の要求に対して引き続き利用可能であるようにすることができる。別の例は、それ自体のメソッドスコープインスタンス中で実行されるメソッド呼出しの外部で戻り値または例外を公開することである。この戻り値または例外を使用して、最初にメソッドのスコープインスタンスの内部で割り振られていた任意の関連する結果をメソッドの呼出し元に渡すことができる。これにより、これらの結果は、メソッドのスコープインスタンスの終わりを生き延びることができ、メソッドスコープインスタンスの親に移動することができる。
【００４２】
リソース昇格は、スコープ階層500の内部でのみ可能とすることができ(すなわち、開発者はリソースを所与のスコープインスタンスからその直接の親のうちの1つに昇格させることができる)、リソースの可視性を高めることができる。
【００４３】
リソース管理モジュール110-5、120-5、および140-5は、短命のスコープインスタンスを、それらの寿命が終わったときに解体することができ、それにより、そのスコープ中で割り振られた全てのリソースを解放することができる。いくつかの長命のスコープインスタンスの場合、メッセージ作成側110または120あるいはメッセージ消費側140は、このスコープインスタンスの寿命が終わる前に明示的なリソース割振り解除を開発者が要求できるようにしてよい。これは、対応するスコープタイプ上、例えばクライアントまたはアプリケーションスコープタイプ上で公開される専用APIによって達成することができる。一実施形態では、スコープインスタンス(これは最初は論理概念でしかない)を、実行時のオブジェクトインスタンス(これはコンピュータメモリ中の論理概念の物理表現である)によって表すことができる。例えば、セッションスコープインスタンスを、Java（登録商標）エンタープライズエディションサーブレットスタンダード(Java（登録商標） Enterprise Edition Servlet Standard)の場合のように、セッションスコープオブジェクトインスタンスによって表すことができる。多くの並列セッションスコープインスタンスがある可能性があるので、実行時に多くの並列セッションスコープオブジェクトインスタンス(すなわちユーザおよびアプリケーションごとに1つ)がある可能性もまたある。
【００４４】
このスコープオブジェクトは、このスコープオブジェクトインスタンスの寿命を終わらせる(関連するスコープインスタンスの寿命の終わりを含意する)ためのメソッドなど、任意の当事者が使用するためのいくつかのAPIを公開する。特に、スコープオブジェクトはまた、このスコープインスタンス中で現在生きておりしたがってスコープオブジェクトインスタンスの内部コンテキストの一部として記憶されているリソースを割振り解除するためのメソッドを公開することができる。開発者がこのメソッドをオブジェクトインスタンス上で呼び出して、割振り解除するリソースへの参照を渡した場合は、リソースはスコープオブジェクトインスタンスから明示的に除去される。
【００４５】
データを除去するための明示的なAPIを公開しない長命のスコープタイプの場合、対応するスコープインスタンスのコンテキストは、リソース管理モジュール110-5、120-5、および140-5によって必要に応じてクリーンアップすることができる。特に、いくつかの長命のスコープは、参照カウンティングに基づく通常の「トラディショナル」ガベージコレクションの恩恵を受けて、使用されない記憶域を解放することができる。
【００４６】
コンテキスト複製
リソース管理モジュール110-5、120-5、および140-5は、それぞれのインフラストラクチャの所与のインスタンス内部のリソースを管理することを超えて、スコープコンテキストを使用してメッセージ作成側110および120とメッセージ消費側140との間で関連データグループをトランスペアレントに共有することができる。図6Aに、メッセージ作成側110および120とメッセージ消費側140との間でコンテキストデータをトランスペアレントに共有するための例示的なメッセージ600を示す。メッセージ600は、メッセージヘッダ610およびメッセージペイロード620を含むことができる。メッセージヘッダ610は、例えば相関ID611および他のヘッダ612を含むことができる。メッセージペイロード620は、例えばターゲットオブジェクトID621、ターゲットメソッド名622、および/または1組のメソッド呼出しパラメータ623を含むことができる。一実施形態では、メッセージに関連するスコープについてのコンテキスト630が、メッセージ600に添付されるかまたは含まれてよい。コンテキストは、メッセージに関連するスコープに割り振られたリソース631および632を含むことができる。これにより、メッセージ作成側110および120とメッセージ消費側140とが、関係するデータグループをそれらの間でトランスペアレントに共有するのを可能にすることができる。したがって、本発明のこの実施形態は、ソースシステムとターゲットシステムとの間の進行中の要求に依拠して全ての当事者間でコンテキストデータをトランスペアレントに共有し、この実施形態は、コンテキストインスタンスが少量のデータしか含まない場合に適切とすることができる。
【００４７】
図6Bに、それぞれのメッセージヘッダ610および650中の相関ID611および651によって要求メッセージ600と論理的に関連付けることのできる、対応する応答メッセージ601を示す。メッセージヘッダ650は、他のヘッダ652も含むことができる。応答メッセージは、メソッド呼出しの結果を発信側システムに搬送し返す。すなわち、メッセージペイロード640は、メソッド呼出し結果641を含むことができる。一実施形態では、スコープについてのコンテキスト630がメッセージ601に添付されるかまたは含まれてよい。このコンテキストは、メッセージ600に添付されたコンテキスト630と同じ論理識別を有するが、ターゲットシステム上でのメソッド呼出しの処理中に割り振られた修正済みのまたは新しいリソースを含んでもよい。すなわち、コンテキスト630は、修正済みリソース631、未修正リソース632、および/または新しいリソース633を含むことができる。
【００４８】
図7に、スコープ複製のいくつかの代替実施形態を示す。これらの実施形態は、帯域外コンテキスト複製(すなわち、ターゲットシステムへのどんな進行中の要求からも独立した複製)に依拠する点で共通し、コンテキストインスタンスが多量のデータを含む場合には前述のメッセージベースの手法よりも適切とすることができる。例えば、リソース管理モジュール110-5は、クライアントスコープインスタンスのコンテキストを、予備のメッセージ作成側710、メッセージ消費側140、またはデータベース720に、事前対応的に複製することができる。最初のコピーの後は、後続の複製の手間は、最新の変更をコンテキストの様々なコピーに同期させることに限定することができ、したがって、転送されるデータの量を低減することができる。メッセージ作成側110は、通信ネットワーク130を介して、データベース720、メッセージ消費側140、および予備のメッセージ作成側710と通信することができる。メッセージ作成側710は、メッセージ作成側110と同様の構造とすることができ、例えばプロセッサ710-1と、スレッド710-2と、コンテキスト110-6の複製710-6をモジュール110-4のコピー710-4と共に記憶するためのメモリ710-3とを備え、複製710-6とコピー710-4は両方ともリソース管理710-5によって管理される。複製710-6は、リソース110-7の複製710-7、およびリソース110-8の複製710-8を含むことができる。同様に、データベース720は、リソース複製720-2とリソース複製720-3とを含むコンテキスト複製720-1を記憶することができる。
【００４９】
スコープインスタンス中の個別の要素を、オンデマンドでメッセージ消費側140に複製することもできる。この手法は、スコープインスタンス全体よりも少ない何らかがメッセージ消費側140上で必要な場合に、使用することができる。例えば、子スコープインスタンスがメッセージ作成側110からメッセージ消費側140に複製済みであって、階層500中のその親のうちの1つの個別の要素を参照するときは、これらの要素もまたメッセージ消費側140上で利用可能にする必要がある。これらの参照は、親スコープインスタンスの個別のノードをターゲットとするだけなので、親スコープインスタンスのコンテキスト全体の複製は、性能の理由で得策ではない場合がある。このような場合、メッセージ消費側140は、親スコープの個別の要素をメッセージ作成側110にオンデマンドで要求することを選択することができる。
【００５０】
スコープコンテキストを複製しても、元のスコープインスタンスの寿命は延長されないものとすることができる。そうではなく、ただ元のスコープコンテキストのリソースのコピーを含む、それ自体の独立したライフサイクルを有する2次スコープコンテキストを生み出すことができる。これは、スコープ階層500の全体構造および所有権関係を維持するのに必要であることがある。上の例では、予備のメッセージ作成側710上の複製されたクライアントスコープコンテキストは、それ自体のライフサイクルを有することができる。特に、予備のメッセージ作成側710が管理上の理由でシャットダウンされた場合、複製されたクライアントスコープコンテキストもまた閉じられる必要があることがある。これは、どんな形でも起源スコープインスタンスに影響を及ぼさないものとすることができるが、例外として、起源スコープインスタンスをホストするコンピュータは、新しい予備のノード上に別の複製クライアントスコープインスタンスを生み出す必要があることがある。
【００５１】
トランスペアレントな分散およびモジュール更新
メッセージ作成側110が突然死んだ場合、クライアントは、フェイルオーバ処理中にメッセージ作成側710上で生み出された新しいクライアントスコープインスタンスから、複製されたコンテキスト710-6にアクセスすることによって、予備のメッセージ作成側710上でその作業を継続することができる。新しいクライアントスコープインスタンスはまた、データベース720の複製されたコンテキスト720-1にアクセスすることによって、メッセージ作成側110上の失敗したコンテキストの内容をロードすることができる。
【００５２】
トランスペアレントな分散のために、メッセージ作成側110は同様に、コンテキスト110-6に関連するスコープインスタンスを有するメッセージをメッセージ消費側140が処理できるように、コンテキスト110-6を帯域外複製によってメッセージ消費側140に複製することができる。
【００５３】
図8に、本発明による、クライアント要求の終端間処理のために負荷を分散させるプロセスを示す。クライアント要求は、例えばHTTP要求を含むことができる。要求処理負荷を分散させるために、ロードバランサが、クライアントから要求を受信し(S801)、入来要求の発送先としての適切なメッセージ作成側110または710を決定する(S802)ことができる。ロードバランサは、この決定を行うために、ロードバランサの以前のルーティング決定に関する知識、ルーティングポリシ、利用可能な各メッセージ作成側の現在の負荷、ならびに利用可能なメッセージ作成側のスケジュールされたダウンタイムなど、その現在の構成および内部アルゴリズムに依拠することができる。選択されたメッセージ作成側110または710は、ロードバランサから要求を受信し、要求の処理を開始する(S803)。この処理中、メッセージ作成側110または710は、ローカルまたはリモートモジュール中のオブジェクト上の様々なメソッドを呼び出すことを選択することができる(S804)。これらのメソッド呼出しの実施の詳細は、図2に概説したステップに従い、それにより、リモートモジュールを呼び出すときであっても、高い程度のネットワーク透過性を保証する。例えば、メッセージ作成側110または710は、この能力を利用して、それ自体では現在扱うことのできないいくらかの負荷を他のシステムに移すことができ、あるいは、メッセージ作成側110または710以外のネットワーク中の専用システムインスタンスにクリティカルプロセスを限定する何らかのセキュリティ制約を施行することができる。要求処理の間、メッセージ作成側110または710はまた、以下および図10に概説するステップに続いて、モジュール110-4または710-4の実行をリフレッシュする(S805)ことを選択することができる。要求の処理を完了した後、応答が、ロードバランサに返され(S806)、そこからクライアントに返される(S807)。
【００５４】
実際の要求処理とは独立に、メッセージ作成側110および710、メッセージ消費側140、またはデータベース720は、バックグラウンドでアクティブであることができ、それにより、図7で述べた帯域外コンテキスト複製メカニズムに続いて全てのスコープコンテキストインスタンスがこれらの異なるシステム間で同期されたままであるようにすることができる。特にこれは、要求処理中に修正されたコンテキストインスタンスに適用されてよく、それにより、これらのシステムのうちの1つの、起こり得る突然の停止の影響が最小限に抑えられるようにすることができる。やはり実際の要求処理とは独立に、これらの各システムは、各システムの現在利用可能な容量に応じて、新しい入来クライアント要求からより多くのまたはより少ない負荷が割り当てられるように、ロードバランサに要求することができる。
【００５５】
図9に、本発明による、メッセージ処理の負荷を分散させるための別のプロセスを示す。メッセージ作成側110は、すでにクライアントからの所与の要求を処理している間でも、メッセージ作成側110が過負荷かどうか判定することができる(S901)。メッセージ作成側110が過負荷でないと判定した場合は、メッセージを処理し応答を送信することによって、メッセージ作成側110上で通常通り処理を継続することができる(S902およびS903)。メッセージ作成側110が過負荷であると判定した場合は、メッセージ作成側110は、メッセージ110-10(S904)、およびメッセージに関連するスコープについてのコンテキスト110-6(S905)を、別のメッセージ作成側710に転送することができる。次いでメッセージ作成側710は、コンテキスト110-6のコピー710-4を使用してメッセージ110-10を処理することができ(S906)、その後、要求に対する応答をロードバランサに直接返すことができる(S907)。同様のメカニズムにより、すでに所与の要求を処理しているメッセージ消費側140は、負荷を別のメッセージ消費側(図示せず)に動的に移すことができる。
【００５６】
図10に、本発明による、システム100がオンラインのままである間にモジュールを更新するための例示的なプロセスを示す。モジュール140-4などのモジュールを更新する必要があると判定されたとき、メッセージ消費側140は、モジュール140-4によるキュー140-6からのメッセージ消費を一時停止することができる(S1001)。次いで、キュー140-6は、メッセージ消費側140がモジュール140-4を更新する間に、入来メッセージをキューイングし続けることができる(S1002)。モジュール140-4が更新された後、モジュール140-4は、キュー140-6からのメッセージの処理を再開することができる(S1003)。キュー140-6がメッセージでオーバーフローしない限り、モジュール140-4の更新は、メッセージ作成側110および120に対してトランスペアレントのままとすることができる。加えて、モジュール140-4によるメッセージの処理が再開できる前に、メッセージ消費側140は、キュー140-6に記憶されたメッセージが、またはコンテキスト140-7および140-8に記憶されたリソースのコピーが、更新されたモジュール140-4中のタイプ宣言と互換するようにする必要がある。これは、メッセージ処理を再開した後のタイプ互換性エラーを防止するために必要であることがある。
【００５７】
実行の変形
本明細書に開示するシステムおよび方法は、様々な形に組み入れることができ、例えば、 データベースも備えたコンピュータなどのデータプロセッサの形、または、個別ではデータを永続させるどんな能力も持たないかもしれない組込みデバイスのネットワークの形が含まれる。さらに、本発明に関する上記の特徴ならびに他の態様および原理は、様々な環境で実現することができる。そのような環境および関係する適用例は、本発明による様々なプロセスおよび動作を実施するために特別に構築されたものであってもよく、あるいは、コードによって選択的にアクティブ化されるかまたは再構成されて必要な機能を提供する汎用コンピュータまたはコンピューティングプラットフォームを含むものであってもよい。本明細書に開示するプロセスは、どんな特定のコンピュータまたは他の装置にも本質的に関係せず、ハードウェア、ソフトウェア、および/またはファームウェアの適切な組合せによって実現することができる。例えば、様々な汎用マシンを、本発明の教示に従って書かれたプログラムと共に使用することができ、あるいは、必要とされる方法および技法を実施するための特殊化された装置またはシステムを構築する方がより好都合であることもある。
【００５８】
本発明によるシステムおよび方法はまた、本発明の方法およびプロセスに基づく様々なコンピュータ実行可能な動作を実施するためのプログラム命令またはコードを含むコンピュータ可読記憶媒体を含む。媒体およびプログラム命令は、本発明の目的のために特別に設計および構築されたものであってもよく、あるいは、コンピュータソフトウェア技術の当業者に周知かつ利用可能な種類のものであってもよい。プログラム命令の例としては、例えば、コンパイラによって作成されるものなどのマシンコード、および、インタープリタを使用してコンピュータによって実行できる高レベルコードを含むファイルが含まれる。
【００５９】
特に明記しない限り、開示した方法における様々なステップは、本明細書に列挙した厳密な順序で実施する必要はない。そうではなく、これらのステップは、当業者に周知のように種々の順序で実施することができる。
【００６０】
本発明による可能な実施形態に関する以上の記述は、述べた実施形態の全てのそのような実施形態または全ての変形の包括的なリストを表すものではない。いくつかの実施形態のみに関する記述を、他の実施形態を排除する意図として解釈すべきではない。以下の特許請求の範囲から逸脱しない均等物および代替を使用して、どのように添付の特許請求の範囲における本発明を多くの他の方法で実施するかについては、当業者なら理解するであろう。
【符号の説明】
【００６１】
100 システム
110 メッセージ作成側
110-1 プロセッサ
110-2 スレッド
110-3 メモリ
110-4 モジュール
110-5 リソース管理モジュール、リソースマネージャ
110-6 第1のスコープインスタンスのコンテキスト
110-7 リソース
110-8 リソース
110-9 アウトバウンドキュー
110-10 アウトバウンドメッセージ
110-11 モジュール
110-12 コンテキストコピー
110-13 インバウンドキュー
120 メッセージ作成側
120-1 プロセッサ
120-2 スレッド
120-3 メモリ
120-4 モジュール
120-5 リソース管理モジュール、リソースマネージャ
120-6 第2のスコープインスタンスのコンテキスト
120-7 リソース
120-8 リソース
120-9 アウトバウンドキュー
120-10 アウトバウンドメッセージ
130 通信ネットワーク
140 メッセージ消費側
140-1 プロセッサ
140-2 スレッド
140-3 メモリ
140-4 モジュール
140-5 リソース管理モジュール、リソースマネージャ
140-6 インバウンドキュー
140-7 第1のスコープインスタンスのコンテキストの現コピー
140-8 第2のスコープインスタンスのコンテキストの現コピー
140-9 モジュール
140-10 コンテキスト
140-11 リソース
140-12 リソース
140-13 アウトバウンドキュー
140-14 メッセージ
300 非同期通信
301 モジュール
302 メッセージ
303 キュー
304 モジュール
400 非同期通信
401 モジュール
402 メッセージ
403 トピック
404 モジュール
405 モジュール
500 階層
510 親スコープ
511 コンテキスト
512 リソース
513 リソース
520 子スコープ
521 コンテキスト
522 リソース
523 リソース
530 子スコープ
531 コンテキスト
532 リソース
533 リソース
540 親スコープ
541 コンテキスト
542 リソース
543 リソース
550 子スコープ
551 コンテキスト
552 リソース
553 リソース
600 メッセージ
601 応答メッセージ
610 メッセージヘッダ
611 相関ID
612 他のヘッダ
620 メッセージペイロード
621 ターゲットオブジェクトID
622 ターゲットメソッド名
623 メソッド呼出しパラメータ
630 コンテキスト
631 リソース、修正済みリソース
632 リソース、未修正リソース
633 新しいリソース
640 メッセージペイロード
641 メソッド呼出し結果
650 メッセージヘッダ
651 相関ID
652 他のヘッダ
710 メッセージ作成側
710-1 プロセッサ
710-2 スレッド
710-3 メモリ
710-4 モジュール110-4のコピー
710-5 リソース管理
710-6 コンテキスト110-6の複製
710-7 リソース110-7の複製
710-8 リソース110-8の複製
720 データベース
720-1 コンテキスト複製
720-2 リソース複製
720-3 リソース複製
【特許請求の範囲】
【請求項１】
コンピュータシステム中でモジュールを分離する方法であって、
非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、
前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、
前記コンテキストのコピーを前記第2のホストに送信する段階と、
前記第1のモジュールを一時停止する段階と、
前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、
前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、
前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、
前記第1のホスト上の前記第1のモジュールを再開する段階とを含む方法。
【請求項２】
前記メッセージを送信する段階および前記コンテキストの前記コピーを送信する段階が前記第1のモジュールおよび前記第2のモジュールに対してトランスペアレントである、請求項1に記載の方法。
【請求項３】
応答を受信する段階が、前記第1のホストにおいて前記第2のホストから返信メッセージを受信する段階を含む、請求項1に記載の方法。
【請求項４】
前記コンテキストの前記コピーが帯域内コピーとして前記メッセージに添付される、請求項1に記載の方法。
【請求項５】
前記コンテキストの前記コピーを帯域外コピーとして前記メッセージとは別に前記第2のホストに送信する段階をさらに含む、請求項1に記載の方法。
【請求項６】
前記コンテキストを前記第2のホストに送信する段階が、前記第1のホストの代わりとして前記コンテキストを事前対応的にコピーする段階を含む、請求項5に記載の方法。
【請求項７】
前記コンテキストの前記コピーを送信する段階が、前記第2のホストの需要があり次第、前記メッセージを処理するのに必要な前記コンテキストをコピーする段階を含む、請求項5に記載の方法。
【請求項８】
前記メッセージを処理するのに必要な前記コンテキストが前記スコープ階層中で識別可能である、請求項1に記載の方法。
【請求項９】
前記メッセージをメッセージキュー中に配置する段階をさらに含む、請求項1に記載の方法。
【請求項１０】
前記キューを一時停止する段階と、
前記第2のモジュールを更新する段階と、
前記第2のモジュールが更新された後で前記キューから前記要求メッセージを処理する段階とをさらに含む、請求項9に記載の方法。
【請求項１１】
前記コンテキストの前記コピーに基づいて前記メッセージを処理するように構成された一連の第2のホストを提供する段階と、
ロードバランサを使用して前記メッセージを前記一連の第2のホストのうちの複数にルーティングする段階とをさらに含む、請求項9に記載の方法。
【請求項１２】
モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、
ネットワークを介してメッセージを送信するように構成された通信ユニットと、
前記メッセージの送信を抑制するためのキューを記憶したメモリと、
コンテキストをスコープ階層中で維持し、
前記メッセージに関連するスコープを生み出し、
前記コンテキストのうちの1つまたは複数を受信コンテキストとマージするための、リソースマネージャとを備えるコンピュータシステム。
【請求項１３】
前記通信ユニットがさらに、前記メッセージに関連する前記スコープについてのコンテキストのコピーを送信するように構成された、請求項12に記載のコンピュータシステム。
【請求項１４】
前記コンテキストの前記コピーが前記メッセージに添付される、請求項13に記載のコンピュータシステム。
【請求項１５】
前記第2のホストへの前記コンテキストの前記コピーが前記メッセージとは別に送信される、請求項13に記載のコンピュータシステム。
【請求項１６】
前記受信コンテキストが前記メッセージに応答して受信される、請求項12に記載のコンピュータシステム。
【請求項１７】
モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、
ネットワークを介して前記モジュールに対するメッセージを受信するための受信機と、
前記モジュールを実行して前記メッセージを処理するためのプロセッサと、
前記メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、
コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備え、前記コンテキストが、前記メッセージに関連する前記スコープのリソースを含む、コンピュータシステム。
【請求項１８】
前記メッセージをキュー中に配置するためのキューマネージャをさらに備える、請求項17に記載のコンピュータシステム。
【請求項１９】
前記キューマネージャが、
前記キューを一時停止し、
前記モジュールを更新し、
前記モジュールが更新された後で前記キューから前記要求メッセージを処理する、請求項16に記載のコンピュータシステム。
【請求項２０】
コンピュータシステム中でモジュールを分離する方法を実行するための命令を記憶した非一時的なコンピュータ可読媒体であって、前記方法が、
非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、
前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、
前記コンテキストのコピーを前記第2のホストに送信する段階と、
前記第1のモジュールを一時停止する段階と、
前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、
前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、
前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、
前記第1のホスト上の前記第1のモジュールを再開する段階とを含む、非一時的なコンピュータ可読媒体。
【請求項１】
コンピュータシステム中でモジュールを分離する方法であって、
非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、
前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、
前記コンテキストのコピーを前記第2のホストに送信する段階と、
前記第1のモジュールを一時停止する段階と、
前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、
前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、
前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、
前記第1のホスト上の前記第1のモジュールを再開する段階とを含む方法。
【請求項２】
前記メッセージを送信する段階および前記コンテキストの前記コピーを送信する段階が前記第1のモジュールおよび前記第2のモジュールに対してトランスペアレントである、請求項1に記載の方法。
【請求項３】
応答を受信する段階が、前記第1のホストにおいて前記第2のホストから返信メッセージを受信する段階を含む、請求項1に記載の方法。
【請求項４】
前記コンテキストの前記コピーが帯域内コピーとして前記メッセージに添付される、請求項1に記載の方法。
【請求項５】
前記コンテキストの前記コピーを帯域外コピーとして前記メッセージとは別に前記第2のホストに送信する段階をさらに含む、請求項1に記載の方法。
【請求項６】
前記コンテキストを前記第2のホストに送信する段階が、前記第1のホストの代わりとして前記コンテキストを事前対応的にコピーする段階を含む、請求項5に記載の方法。
【請求項７】
前記コンテキストの前記コピーを送信する段階が、前記第2のホストの需要があり次第、前記メッセージを処理するのに必要な前記コンテキストをコピーする段階を含む、請求項5に記載の方法。
【請求項８】
前記メッセージを処理するのに必要な前記コンテキストが前記スコープ階層中で識別可能である、請求項1に記載の方法。
【請求項９】
前記メッセージをメッセージキュー中に配置する段階をさらに含む、請求項1に記載の方法。
【請求項１０】
前記キューを一時停止する段階と、
前記第2のモジュールを更新する段階と、
前記第2のモジュールが更新された後で前記キューから前記要求メッセージを処理する段階とをさらに含む、請求項9に記載の方法。
【請求項１１】
前記コンテキストの前記コピーに基づいて前記メッセージを処理するように構成された一連の第2のホストを提供する段階と、
ロードバランサを使用して前記メッセージを前記一連の第2のホストのうちの複数にルーティングする段階とをさらに含む、請求項9に記載の方法。
【請求項１２】
モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、
ネットワークを介してメッセージを送信するように構成された通信ユニットと、
前記メッセージの送信を抑制するためのキューを記憶したメモリと、
コンテキストをスコープ階層中で維持し、
前記メッセージに関連するスコープを生み出し、
前記コンテキストのうちの1つまたは複数を受信コンテキストとマージするための、リソースマネージャとを備えるコンピュータシステム。
【請求項１３】
前記通信ユニットがさらに、前記メッセージに関連する前記スコープについてのコンテキストのコピーを送信するように構成された、請求項12に記載のコンピュータシステム。
【請求項１４】
前記コンテキストの前記コピーが前記メッセージに添付される、請求項13に記載のコンピュータシステム。
【請求項１５】
前記第2のホストへの前記コンテキストの前記コピーが前記メッセージとは別に送信される、請求項13に記載のコンピュータシステム。
【請求項１６】
前記受信コンテキストが前記メッセージに応答して受信される、請求項12に記載のコンピュータシステム。
【請求項１７】
モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、
ネットワークを介して前記モジュールに対するメッセージを受信するための受信機と、
前記モジュールを実行して前記メッセージを処理するためのプロセッサと、
前記メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、
コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備え、前記コンテキストが、前記メッセージに関連する前記スコープのリソースを含む、コンピュータシステム。
【請求項１８】
前記メッセージをキュー中に配置するためのキューマネージャをさらに備える、請求項17に記載のコンピュータシステム。
【請求項１９】
前記キューマネージャが、
前記キューを一時停止し、
前記モジュールを更新し、
前記モジュールが更新された後で前記キューから前記要求メッセージを処理する、請求項16に記載のコンピュータシステム。
【請求項２０】
コンピュータシステム中でモジュールを分離する方法を実行するための命令を記憶した非一時的なコンピュータ可読媒体であって、前記方法が、
非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、
前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、
前記コンテキストのコピーを前記第2のホストに送信する段階と、
前記第1のモジュールを一時停止する段階と、
前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、
前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、
前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、
前記第1のホスト上の前記第1のモジュールを再開する段階とを含む、非一時的なコンピュータ可読媒体。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−８９１３４（Ｐ２０１２−８９１３４Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−２２８７２６（Ｐ２０１１−２２８７２６）
【出願日】平成２３年１０月１８日（２０１１．１０．１８）
【出願人】（３０００１５４４７）エスアーペー アーゲー (146)
【氏名又は名称原語表記】ＳＡＰ ＡＧ
【住所又は居所原語表記】Ｄｉｅｔｍａｒ−Ｈｏｐｐ−Ａｌｌｅｅ １６， ６９１９０ Ｗａｌｌｄｏｒｆ， Ｇｅｒｍａｎｙ
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１１−２２８７２６（Ｐ２０１１−２２８７２６）
【出願日】平成２３年１０月１８日（２０１１．１０．１８）
【出願人】（３０００１５４４７）エスアーペー アーゲー (146)
【氏名又は名称原語表記】ＳＡＰ ＡＧ
【住所又は居所原語表記】Ｄｉｅｔｍａｒ−Ｈｏｐｐ−Ａｌｌｅｅ １６， ６９１９０ Ｗａｌｌｄｏｒｆ， Ｇｅｒｍａｎｙ
[ Back to top ]