特許 7183384 分散コンピューティングシステムにおける共有リソースの管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-25

(45)【発行日】2022-12-05

(54)【発明の名称】分散コンピューティングシステムにおける共有リソースの管理

(51)【国際特許分類】

   G06F 9/52 20060101AFI20221128BHJP

【ＦＩ】

G06F9/52 150C

【請求項の数】 17

(21)【出願番号】P 2021504583

(86)(22)【出願日】2018-07-06

(65)【公表番号】

(43)【公表日】2021-08-26

(86)【国際出願番号】 IB2018055020

(87)【国際公開番号】W WO2019197887

(87)【国際公開日】2019-10-17

【審査請求日】2021-07-01

(31)【優先権主張番号】15/950,031

(32)【優先日】2018-04-10

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520393886

【氏名又は名称】オーエスアイソフト リミテッド ライアビリティ カンパニー

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】ザッカリー クリスチャン ムーア

(72)【発明者】

【氏名】ライアン マイケル ギルバート

(72)【発明者】

【氏名】アハヌフ タハミド ホサイン

(72)【発明者】

【氏名】トーマス フォス セイモア

【審査官】漆原 孝治

(56)【参考文献】

【文献】特開２０１５－１９１４５１（ＪＰ，Ａ）

【文献】Ｏｒａｃｌｅ８ｉ レプリケーション・ガイド リリース８．１ ，初版，ＯＲＡＣＬＥ，2000年02月28日，pp.2-1～2-21

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５２

(57)【特許請求の範囲】

【請求項1】

分散コンピュータシステムを使用してデッドロックを防止するための方法であって、
トランザクションマネージャーによって、共有リソース上でトランザクションを実行する要求を受信する工程であって、前記共有リソースは複数のコピーを有し、前記複数のコピーのそれぞれのコピーは１つまたは複数のパーティションに配置されている工程と、
前記トランザクションマネージャーによって、前記要求されたトランザクションに基づいて前記共有リソースの状態を変更する工程であって、前記変更する工程は、前記共有リソースの前記状態を第１の状態から第２の状態に変更する工程であり、
状態マネージャーによって、１つまたは複数のリソースハンドルを生成する工程であって、前記１つまたは複数のリソースハンドルは前記共有リソースを表現する工程と、
前記トランザクションマネージャーによって、１つまたは複数の動作ハンドルを生成する工程であって、前記１つまたは複数の動作ハンドルのそれぞれは動作を記述し、前記動作は共有リソースの状態を第１の状態から第２の状態に変更する工程と、
前記トランザクションマネージャーによって、前記１つまたは複数の動作ハンドルを１つまたは複数の動作スタックに加える工程であって、前記１つまたは複数の動作スタックは前記１つまたは複数のリソースハンドル内に配置される工程と、
を備える工程と、
前記トランザクションマネージャーによって、成功したトランザクションまたは失敗したトランザクションを指示する工程であって、前記指示することは、前記共有リソースの前記状態に基づいている工程と、
前記成功したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションを前記複数のコピーに適用する工程と、
前記トランザクションマネージャーによって、前記共有リソースおよび前記複数のコピーをコミットする工程と、
前記トランザクションマネージャーによって、前記変更された共有リソースに関連付けられた結果を返す工程と、
前記失敗したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションが前記複数のコピーを変更することを防止する工程と、
ロールバックモジュールによって、前記変更された共有リソースへのロールバックを適用する工程であって、前記ロールバックは前記共有リソースの前記状態を前記第２の状態から前記第１の状態に戻す工程と、
前記ロールバックモジュールによって、前記コピーに前記ロールバックを適用する工程と、
前記ロールバックモジュールによって、成功したロールバックまたは失敗したロールバックを指示する工程と、
を備える、方法。

【請求項2】

請求項１に記載の方法であって、前記パーティションは複数のトランザクションが各コピーに対して並行して実行されることを可能にする、方法。

【請求項3】

請求項１に記載の方法であって、前記共有リソースは、スクリプトリソース、テンプレートリソース、またはスケジュールリソースのうちの少なくとも１つである、方法。

【請求項4】

請求項１に記載の方法であって、前記動作は、処理サイクルにおいて１つの共有リソースを変更する、方法。

【請求項5】

請求項１に記載の方法であって、前記トランザクションは、処理サイクルにおいて複数の共有リソースを変更する、方法。

【請求項6】

請求項１に記載の方法であって、前記失敗したトランザクションを指示することは、
前記トランザクションマネージャーによって、前記複数のコピーに対する変更を防止する工程と、
前記トランザクションマネージャーによって、前記共有リソースに関連付けられた結果を先行して阻止する工程と、
をさらに備える、方法。

【請求項7】

請求項１に記載の方法であって、
前記トランザクションマネージャーによって、前記動作スタックから１つまたは複数の動作ハンドルをクリッピングする工程であって、前記１つまたは複数の動作ハンドルは無効化を有し、前記無効化は最新の動作ハンドルに基づく
工程をさらに備える、方法。

【請求項8】

請求項１に記載の方法であって、前記動作スタックは、ＬＩＦＯデータ構造である、方法。

【請求項9】

非一時的なコンピューター可読記憶媒体であって、プロセッサーによって実行されると、
トランザクションマネージャーによって、共有リソース上でトランザクションを実行する要求を受信する工程であって、前記共有リソースは複数のコピーを有し、前記複数のコピーのそれぞれのコピーは１つまたは複数のパーティションに配置されている工程と、
前記トランザクションマネージャーによって、前記要求されたトランザクションに基づいて前記共有リソースの状態を変更する工程であって、前記変更する工程は、前記共有リソースの前記状態を第１の状態から第２の状態に変更する工程であり、
状態マネージャーによって、１つまたは複数のリソースハンドルを生成する工程であって、前記１つまたは複数のリソースハンドルは前記共有リソースを表現する工程と、
前記トランザクションマネージャーによって、１つまたは複数の動作ハンドルを生成する工程であって、前記１つまたは複数の動作ハンドルのそれぞれは動作を記述し、前記動作は共有リソースの状態を第１の状態から第２の状態に変更する工程と、
前記トランザクションマネージャーによって、前記１つまたは複数の動作ハンドルを１つまたは複数の動作スタックに加える工程であって、前記１つまたは複数の動作スタックは前記１つまたは複数のリソースハンドル内に配置される工程と、
を備える工程と、
前記トランザクションマネージャーによって、成功したトランザクションまたは失敗したトランザクションを指示する工程であって、前記指示することは、前記共有リソースの前記状態に基づいている工程と、
前記成功したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションを前記複数のコピーに適用する工程と、
前記トランザクションマネージャーによって、前記共有リソースおよび前記複数のコピーをコミットする工程と、
前記トランザクションマネージャーによって、前記変更された共有リソースに関連付けられた結果を返す工程と、
前記失敗したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションが前記複数のコピーを変更することを防止する工程と、
ロールバックモジュールによって、前記変更された共有リソースへのロールバックを適用する工程であって、前記ロールバックは前記共有リソースの前記状態を前記第２の状態から前記第１の状態に戻す工程と、
前記ロールバックモジュールによって、前記コピーに前記ロールバックを適用する工程と、
前記ロールバックモジュールによって、成功したロールバックまたは失敗したロールバックを指示する工程と、
を前記プロセッサーに実行させる符号化された命令を有する、非一時的なコンピューター可読記憶媒体。

【請求項10】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記パーティションは複数のトランザクションが各コピーに対して並行して実行されることを可能にする、非一時的なコンピューター可読記憶媒体。

【請求項11】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記共有リソースは、スクリプトリソース、テンプレートリソース、またはスケジュールリソースのうちの少なくとも１つである、非一時的なコンピューター可読記憶媒体。

【請求項12】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記動作は、処理サイクルにおいて１つの共有リソースを変更する、非一時的なコンピューター可読記憶媒体。

【請求項13】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記トランザクションは、処理サイクルにおいて複数の共有リソースを変更する、非一時的なコンピューター可読記憶媒体。

【請求項14】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記失敗したトランザクションを指示することは、
前記トランザクションマネージャーによって、前記複数のコピーに対する変更を防止する工程と、
前記トランザクションマネージャーによって、前記共有リソースに関連付けられた結果を先行して阻止する工程と、
をさらに備える、非一時的なコンピューター可読記憶媒体。

【請求項15】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、
前記トランザクションマネージャーによって、前記動作スタックから１つまたは複数の動作ハンドルをクリッピングする工程であって、前記１つまたは複数の動作ハンドルは無効化を有し、前記無効化は最新の動作ハンドルに基づく
工程をさらに備える、非一時的なコンピューター可読記憶媒体。

【請求項16】

請求項９に記載の非一時的なコンピューター可読記憶媒体であって、前記動作スタックは、ＬＩＦＯデータ構造である、非一時的なコンピューター可読記憶媒体。

【請求項17】

システムであって、
コンピュータープロセッサーと、
前記コンピュータープロセッサーに結合されたコンピューター可読記憶媒体と、
を備え、
前記コンピューター可読記憶媒体は実行可能コードを格納し、前記コードは、前記コンピュータープロセッサーによって実行されると、
トランザクションマネージャーによって、共有リソース上でトランザクションを実行する要求を受信する工程であって、前記共有リソースは複数のコピーを有し、前記複数のコピーのそれぞれのコピーは１つまたは複数のパーティションに配置されている工程と、
前記トランザクションマネージャーによって、前記要求されたトランザクションに基づいて前記共有リソースの状態を変更する工程であって、前記変更する工程は、前記共有リソースの前記状態を第１の状態から第２の状態に変更する工程であり、
状態マネージャーによって、１つまたは複数のリソースハンドルを生成する工程であって、前記１つまたは複数のリソースハンドルは前記共有リソースを表現する工程と、
前記トランザクションマネージャーによって、１つまたは複数の動作ハンドルを生成する工程であって、前記１つまたは複数の動作ハンドルのそれぞれは動作を記述し、前記動作は共有リソースの状態を第１の状態から第２の状態に変更する工程と、
前記トランザクションマネージャーによって、前記１つまたは複数の動作ハンドルを１つまたは複数の動作スタックに加える工程であって、前記１つまたは複数の動作スタックは前記１つまたは複数のリソースハンドル内に配置される工程と、
を備える工程と、
前記トランザクションマネージャーによって、成功したトランザクションまたは失敗したトランザクションを指示する工程であって、前記指示することは、前記共有リソースの前記状態に基づいている工程と、
前記成功したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションを前記複数のコピーに適用する工程と、
前記トランザクションマネージャーによって、前記共有リソースおよび前記複数のコピーをコミットする工程と、
前記トランザクションマネージャーによって、前記変更された共有リソースに関連付けられた結果を返す工程と、
前記失敗したトランザクションを指示することに応答して、
前記トランザクションマネージャーによって、前記トランザクションが前記複数のコピーを変更することを防止する工程と、
ロールバックモジュールによって、前記変更された共有リソースへのロールバックを適用する工程であって、前記ロールバックは前記共有リソースの前記状態を前記第２の状態から前記第１の状態に戻す工程と、
前記ロールバックモジュールによって、前記コピーに前記ロールバックを適用する工程と、
前記ロールバックモジュールによって、成功したロールバックまたは失敗したロールバックを指示する工程と、
を実行する、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、分散コンピューティングシステムの分割されたパーティションにわたって共有リソースを管理する方法に関する。

【背景技術】

【0002】

並列コンピューティングはプロセスをコンピューティングシステム内の別々のプロセッサー上で同時に実行する部分に分割することにより、そのパフォーマンスを効率化することができる。通常、並列コンピューティング環境におけるサブタスクは、多様なスレッド間で共有される変数を頻繁に使用または更新する必要があるスレッドによって実行される。これらの変数はサブタスクを実行する全てのスレッド間で共有されるため、ロックを使用することで、競合するスレッドが各サブタスクに必要な共通データを上書きしたり変更したりしないようにすることが確保される。しかし、ロックを使用すると、デッドロックや競合状態など各サブタスクの実行に関するいくつかの課題が発生する可能性が高い。多くの場合、デッドロックが発生すると競合するサブタスクが中止されるため、結果として作業が失われるとともに、サブタスクを再度やり直す必要性があるため、非効率になる。

【発明の概要】

【0003】

説明される実施形態は分散コンピューティングシステムにおいて、共有リソースを管理するためのトランザクションマネージャーを含む。分散コンピューティングシステムには、ユーザーが指定した動作やトランザクションを介して変更を受信する可能性のある共有リソースの個別のコピーをそれぞれ含む複数のパーティションが含まれている。各動作は、一度に１つの共有リソースを変更でき、どのリソースを変更すべきかを指示するリソースＩＤが含まれる。トランザクションマネージャーは、各パーティションの共有リソースの各コピーに対して、要求された動作またはトランザクションを並行して実行し、パーティション間で一貫した状態を維持する。さらに、動作とトランザクションによって変更される共有リソースを指定するリソースＩＤの使用は、分散コンピューティングシステムは、同じ共有リソースに対して動作が競合しないよう各リソースの変更を並行して振り分け、デッドロックや競合状態を回避する。

【0004】

共有リソースのコピーを変更している間に動作またはトランザクションが失敗した場合、トランザクションマネージャーは、動作またはトランザクションが残りのコピーを変更することを防止し、失敗した動作またはトランザクションの結果を先行して阻止する。さらに、トランザクションマネージャーは、失敗した動作またはトランザクションをロールバックすることにより、共有リソース全体で一貫した状態に復旧させ、これによって、共有リソースの各コピーを動作またはトランザクションを実行する前の状態に戻すことができる。

【0005】

この概要および以下の詳細な説明で述べられる機能および利点は、すべてを網羅しているわけではない。多くの付加的な特徴および利点は、ここに記載される図面、明細書、および特許請求の範囲を見ることによって当業者に明らかとなり得る。

【図面の簡単な説明】

【0006】

【図1】本実施形態による分散コンピューティングシステムを示すブロック図である。

【図2】本実施形態によるトランザクションマネージャーを示すブロック図である。

【図3A】本実施形態によるトランザクションを管理するための例示的なプロセスを示す。

【図3B】本実施形態によるトランザクションを管理するための例示的なプロセスを示す。

【図4A】本実施形態によるユーザー要求、トランザクションマネージャー、および状態マネージャーの間の相互作用を示す関係図である。

【図4B】本実施形態によるユーザー要求、トランザクションマネージャー、および状態マネージャーの間の相互作用を示す関係図である。

【図5A】本実施形態による、動作ハンドルをコミットするためのプロセスを示す図である。

【図5B】本実施形態による、動作スタックをクリッピングするためのプロセスを示す図である。

【図6】本実施形態によるロールバック動作を示す図である。

【図7】本実施形態による、分散コンピューティングシステム上でトランザクションを管理するためのプロセスを示すフローチャートである。

【図8】本実施形態による管理コンピューターを示すブロック図である。

【0007】

図および以下の説明は、例示のみを目的として特定の実施形態を説明している。以下の説明から、当業者は本明細書に記載する原理から逸脱することなく、本明細書に示す構造および方法の代替の実施形態を使用できることを容易に認識するであろう。ここでは、いくつかの実施形態を詳細に参照し、その例を添付の図に示す。実行可能な場合はいつでも類似の参照番号を図で使用することができ、同様の機能を示すことができることに留意されたい。

【発明を実施するための形態】

【0008】

本明細書で説明する方法は分散コンピューティングシステム内の共有リソースで操作を実行するという技術的な課題（要求）に対応している。共有リソースを使用して操作を実行すると、分散コンピューティングシステムの複数のコンポーネントが同じリソースをめぐって競合するため、誤ったデータが導入され、リソースが変更されて一貫性のない状態になる可能性がある。リソースが共有されているため、これらの一貫性のない状態は、後続のプロセスで使用される分散コンピューティングシステム全体に誤ったデータを伝播する可能性がある。さらに、共有リソースをめぐって競合する多様なコンポーネントは、システム全体の進行を妨げるデッドロックシナリオを頻繁に引き起こす。ここで明示される方法は、ユーザーが一貫した状態を維持しながら、多様なパーティションに分散された共有リソースの個別のコピーを変更できるようにするトランザクションマネージャーフレームワークを提供する。さらに、同じ共有リソースのコピーを含む複数のパーティションの使用が、デッドロックを回避しながらパーティション間で同時に実行することができる、複雑なトランザクションを提供する。

【0009】

分散コンピューティングシステム
図１は分散コンピューティングシステム１００の一実施形態を示すブロック図である。分散コンピューティングシステム１００は、いくつかのパーティション１０２Ａ～Ｃ（ここでは「パーティション１０２」と個別に呼ばれる）、管理コンピューター１２８、およびネットワーク１２６を含む。各パーティション１０２は分割された一連の計算１０４Ａ～Ｃおよびディスパッチエンジン１０６Ａ～Ｃ（ここでは「計算１０４」および「ディスパッチエンジン１０６」と個別に呼ばれる）に加え、パーティション１０２Ａ～Ｃの各々にわたって分布する共有リソース１０８Ａ～Ｃ（ここでは「共有リソース１０８」と個別に呼ばれる）の複数のコピーを含む。管理コンピューター１２８は、分散コンピューティングシステム１００のユーザーによって生成された１つまたは複数のユーザー要求１３２を受信するトランザクションマネージャー１３０を含む。

【0010】

一実施形態では、パーティション１０２Ａ～Ｃは分散される負荷の一部を備える個別の計算１０４Ａ～Ｃをそれぞれ実行するサーバーである。分散コンピューティングシステム１００の各パーティション１０２は、共有リソース１０８Ａ～Ｃのそれ自身のコピーを含む。パーティション１０２Ａ～Ｃは、計算１０４Ａ～Ｃを実行するために共有リソース１０８Ａ～Ｃを使用する。例えば、ユーザーが１０００台のトラック集団のメンテナンススケジュールを決定するための計算を実行したい場合、各パーティション１０２Ａ～Ｃは、共有リソース１０８Ａ～Ｃを使用して各トラックのインスタンスを参照し、それに応じて計算１０２Ａ～Ｃを分割することができる。各パーティションには同一の共有リソース１０８Ａ～Ｃのコピーが含まれるため、新たなリソースのインスタンスの作成、リソースの読み取り、既存リソースの更新および／または削除といった、ユーザーが要求するあらゆる操作（ここでは「ＣＲＵＤ操作」と呼ばれる）は、他のパーティション１０２Ａ～Ｃ全てにわたって共有リソースの各コピーが追加で作成される必要がある。パーティション１０２Ａ～Ｃは、パーティション１０２で実行されるあらゆるＣＲＵＤ操作が、共有リソース１０８Ａ～Ｃのすべてのコピーの間で一貫性のある状態を維持するために残っているパーティション１０２Ａ～Ｃ上で、共有リソース１０８Ａ～Ｃのコピーに対して同様に適用されることを確実にするために、トランザクションマネージャー１３０によって管理される。

【0011】

共有リソース１０８Ａ～Ｃはユーザー要求１３２を介してユーザーによって要求されるＣＲＵＤ操作を通じて変更を受信できるオブジェクトであるか、あるいは、ディスパッチエンジン１０６によって引き起こされた所与のパーティション１０２に特化した個々の計算１０４Ａ～Ｃに用いられる。図１に示される実施形態では、共有リソース１０８Ａ～Ｃはリソース１～３を含み、リソース１はスクリプト、リソース２はテンプレート、リソース３はスケジュールである。他の実施形態では、付加的またはより少ない共有リソースおよび／またはここで示されたものとは異なるリソースを含み得る。

【0012】

本例の目的のため、スクリプトが、どのように計算１０４Ａ～Ｃを実行すべきか、および／またはＣＲＵＤ操作を通じて共有リソースをどのように変更すべきかを各パーティション１０２に指示する、ユーザーによって定義されたコード（例えば、ＪａｖａＳｃｒｉｐｔ）のブロックであると仮定する。例えば、スクリプトの新しいインスタンスは、トランザクションマネージャー１３０に対してスクリプトを「作成する」ように指示するユーザー要求１３２を介し、ユーザーによって作成され得る。同様に、スクリプトを「更新」するためのユーザー要求１３２をトランザクションマネージャー１３０に提供することに応答し、スクリプトを新しい状態に更新することができる。さらに、スクリプトは「削除」するためのユーザー要求１３２を介して削除することができる。ただし、スクリプトのいずれかのコピーが変更完了に失敗すると、トランザクションマネージャーは、すべてのパーティション１０２Ａ～Ｃにわたる各スクリプトの状態を、失敗したＣＲＵＤの指示を受信する前のスクリプトの状態に戻す。

【0013】

テンプレートは、スクリプトによって使用されるエイリアスに加えて、ユーザーが計算１０４ごとに新しいスクリプトを生成するのではなく、一般的なアプリケーションスクリプトを定義できるようにするスクリプトを含むメタデータオブジェクトである。例えば、ユーザーがトラックの一団から特定のトラックのマイレージを決定したい場合、ユーザーは「ｍｉｌｅａｇｅ」などのエイリアスを使用し、各トラックのテンプレート（例えば、計算）のインスタンスを生成して単一のトラックのマイレージを計算するテンプレートを定義することができる。テンプレートはアクティブ状態または非アクティブ状態のいずれかに属し得る。テンプレートにはスクリプトで使用されるエイリアスが含まれているため、ＣＲＵＤ操作を実行する前に、テンプレートを非アクティブ状態にする必要がある。

【0014】

スケジュールは計算１０４Ａ～Ｃがパーティション１０２Ａ～Ｃによっていつ実行されるかを指示する（例えば、日次ベース、時間ベース、週次ベースなど）。各パーティション１０２は、指定されたスケジュールに基づいて、独自の一連の計算１０４Ａ～Ｃを実行する。ユーザーがスケジュールに従ってＣＲＵＤ操作を実行するにためには、変更操作もテンプレートに適用する必要がある。

【0015】

共有リソース１０８Ａ～Ｃは「動作」と呼ばれるＣＲＵＤ操作によって任意に変更することができる。動作とは、例えば、スクリプトの更新やテンプレートの削除など、ユーザーが１つの共有リソースを使用して実行しようとする作業の単位である。各動作は、一度に１つの共有リソース１０８Ａ～Ｃのみを変更し、変更するリソースを示すリソースＩＤを含む。さらに、各動作にはトランザクションマネージャー１３０によって受信されたそれぞれの動作特有の識別子として機能する動作ＩＤが割り当てられる。共有リソース１０８Ａ～Ｃは変更を受信する前に、その前の状態に戻ることができるため、動作は「ｄｏアクション」および「ｕｎｄｏアクション」もサポートする。このｄｏアクションは、スクリプトの作成、テンプレートの更新、スケジュールの削除など、動作が実行するＣＲＵＤ操作を示す。ｕｎｄｏアクションは、共有リソース１０８Ａ～Ｃの状態を、作成操作に続く削除操作など、ｄｏアクションの実行前の状態に戻す。このように、共有リソース１０８Ａ～Ｃを正常に変更することに失敗した場合、与えられる動作をロールバックすることができる。

【0016】

一度に複数の共有リソース１０８Ａ～Ｃに適用され得るＣＲＵＤ操作は「トランザクション」と呼ばれる。トランザクションは、論理的な作業単位を表す動作の集合である。あるトランザクションの動作が共有リソース１０８を正常に変更することに失敗した場合、トランザクションマネージャー１３０は、トランザクションの残りの動作が実行されるのを防ぐ。例えば、「テンプレートの更新」および「スクリプトの削除」といった指示を含むトランザクションが、最初にテンプレートの更新に失敗した場合、トランザクションマネージャー１３０は失敗したトランザクションがスクリプトを削除するのを先行して阻止する。この場合、失敗したトランザクションですでに実行された動作はすべてロールバックされ、共有リソース１０８をトランザクション実行以前の状態に戻す。

【0017】

パーティション１０２Ａ～Ｃおよび管理コンピューター１２８は、図１に示されるネットワーク１２６を介して通信するように構成される。図１は、有線および／または無線通信システムの両方を使用して、ローカルエリアおよび／またはワイドエリアネットワークの任意の組み合わせを含み得る。本実施形態では、ネットワーク１２６は、標準的な通信技術および／またはプロトコルを使用する。例えば、ネットワーク１２６は、イーサネット、８０２．１１、Worldwide Interoperability For Microwave Access（ＷｉＭＡＸ）、３Ｇ、４Ｇ、符号分割多元接続（ＣＤＭＡ）、デジタル加入者線（ＤＳＬ）などの技術を使用する通信リンクを含む。ネットワーク１２６を介した通信に使用されるネットワークプロトコルの例には、Multi-Protocol Label Switching（ＭＰＬＳ）、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）、Hyper Text Transfer Protocol（ＨＴＴＰ）、Simple Mail Transfer Protocol（ＳＭＴＰ）、およびFile Transfer Protocol（ＦＴＰ）が含まれる。ネットワーク１２６を介して交換されるデータは、Hyper Text Markup Language（ＨＴＭＬ）Extensible Markup Language（ＸＭＬ）などの任意の適切なフォーマットを使用して表現することができる。いくつかの実施形態では、ネットワーク１２６の通信リンクのすべて、またはいくつかは適切な技術を用いて暗号化することができる。

【0018】

ユーザー要求１３２は、共有リソース１０８Ａ～Ｃ上で動作、トランザクション、または計算１０４を実行するようにトランザクションマネージャーに指示する管理コンピューター１２８のユーザーによって生成された要求である。トランザクションマネージャー１３０は、受信したユーザー要求１３２ごとに動作、トランザクション、または計算１０４の新しいインスタンスを作成する。例えば、トランザクションマネージャー１３０がスクリプトを更新するための２つの連続するユーザー要求１３２を受信した場合、トランザクションマネージャー１３０は、各要求に個別の動作ＩＤを割り当て、各動作のライフサイクルを、それに応じて監視できるようにする。

【0019】

トランザクションマネージャー１３０は、分散コンピューティングシステム１００のパーティション１０２Ａ～Ｃに格納された共有リソースを変更する要求を受信し、受信した要求に基づいて共有リソース１０８の独自のコピーを変更するように、各パーティション１０２に指示する。各パーティション１０２は、共有リソース１０８Ａ～Ｃ上で並行して動作する。変更を受信する共有リソース１０８Ａ～Ｃは、動作および／またはトランザクションが実行される前に識別されるため、トランザクションマネージャー１３０は、動作および／またはトランザクションが競合しないよう、パーティション１０２Ａ～Ｃにわたって各リソースの変更を割り付けることが可能である。この方法で動作とトランザクションを調整すると、デッドロックや競合状態を回避しながら並列で実行することができる。与えられた共有リソース１０８を使用して動作またはトランザクションが適切に実行されない場合、トランザクションマネージャー１３０は、動作またはトランザクションを実行する前に、リソースの状態を元に戻す。

【0020】

トランザクションマネージャーフレームワーク
図２は本実施形態によるトランザクションマネージャー１３０を示すブロック図である。図２に示される実施形態では、トランザクションマネージャー１３０は状態マネージャー２００、状態ストア２０２、リソースハンドルストア２０４、動作ハンドルストア２０６、ロールバックモジュール２０８、および復旧モジュール２１０を含む。他の実施形態では、トランザクションマネージャー１３０は、様々なアプリケーションのための付加的、より少ない、または異なるコンポーネントを含み得る。システムアーキテクチャの詳細を不明確にしないため、ネットワークインターフェース、セキュリティ機能、ロードバランサ、フェイルオーバーサーバー、管理およびネットワーク操作コンソールなどの従来のコンポーネントは示されていない。

【0021】

状態マネージャー２００はそれらがトランザクションと動作を通じて変更することができるよう、共有リソース１０８Ａ～Ｃへのアクセスをトランザクションマネージャー１３０に供給する。状態マネージャー２００はリソースハンドルを生成することにより、アクセスを提供する。各リソースハンドルは分散コンピューティングシステム１００のパーティション１０２Ａ～Ｃに格納された共有リソース１０８の表現として機能し、共有リソース１０８を変更するために使用される動作スタックを含む。各リソースハンドルは独自のリソースロックを有する。共有リソースに関連付けられた動作スタックにアクセスする前に、トランザクションマネージャー１３０は、リソースが変更されている間に他の動作が動作スタックに入るのを防ぐため、リソースロックを入力しなければならない。本実施形態では、動作スタックは、ＬＩＦＯ順序で追加、実行、またはロールバックされる後入れ先出し（ＬＩＦＯ）スタックとして動作する。共有リソース１０８ごとに１つの動作スタックが確実に存在する。ただし、トランザクションは、動作の集合的なトランザクションを調整するために、特定の時間に様々な動作スタックで動作する場合がある。トランザクションマネージャー１３０が与えられた動作スタックと関連付けられた各トランザクションまたは動作を完了するときは、有効にトランザクションを終了するために、トランザクションマネージャー１３０はリソースロックを解放、状態マネージャー２００は、メモリーからリソースハンドルを解放する。リソースハンドルが使用されているとき、状態マネージャー２００はそれらをリソースハンドルストア２０４に格納する。

【0022】

トランザクションマネージャー１３０は所与のトランザクションを通じて共有リソース１０８Ａ～Ｃの様々な状態の在庫を維持するために、状態ストア２０２を使用する。状態ストア２０２は、トランザクションマネージャー１３０が動作によって変更された共有リソース１０８Ａ～Ｃの安定性を決めるために使用することができる動作の実行を説明する情報を保持する。例えば、ロールバック操作に失敗した後に動作が復旧のために設定されている場合、トランザクションマネージャー１３０はその動作を不安定としてマークし、状態ストア２０２は動作の不安定性の記録を維持する。本実施形態では、状態ストア２０２は、ユーザーによって定義および実装される。他の実施形態では、状態ストア２０２は、トランザクションマネージャー１３０によって維持および実装される。

【0023】

動作ハンドルストア２０６は、トランザクションマネージャー１３０によって生成された動作ハンドルを格納するために使用される。動作ハンドルストア２０６内の各動作ハンドルは、ユーザー要求１３２においてトランザクションマネージャー１３０によって受信された動作の表現として機能する。動作ハンドルはパーティション１０２Ａ～Ｃに格納された共有リソース１０８Ａ～Ｃを変更するためにリソースハンドルと共に使用される。トランザクションマネージャー１３０は、変更するリソースハンドルの動作スタックに対応する動作ハンドルを追加することにより、共有リソース１０８Ａ～Ｃで動作を実行する。実行されると、リソースハンドルに対応するパーティション１０２Ａ～Ｃに格納された共有リソース１０８が変更され、動作ハンドルは、ＬＩＦＯ順序で動作スタックから削除される。動作ハンドルは動作ハンドルがユーザーによってコミットされたとき、動作ハンドルが無効にされたとき、または動作ハンドルがロールバックモジュール２０８によってロールバックされたときにのみ、スタックから削除することができる。

【0024】

トランザクションマネージャー１３０は、それらの動作ハンドルに基づいて動作の状態に関する詳細を識別することが可能である。例えば、動作ハンドルは、動作がロールバックを要求されたかどうか、ロールバックが試行されたかどうか、ロールバックまたは復旧操作が正常に完了したかどうか、動作がコミットされたかどうか、動作が無効にされたかどうか、動作が失敗したロールバックから復旧されているかどうか、動作のライフサイクルが完了したかどうか、および動作が安定しているかどうか、を示すことが可能である。本実施形態では、失敗したロールバックを実行しなかった場合、または動作が失敗したロールバックから復旧した場合にのみ、動作が安定していると見なすことができる。動作のロールバックと復旧については、次のセクションで詳しく説明される。

【0025】

ロールバックモジュール２０８は、与えられたリソースハンドルの動作スタック上における正常な実行に失敗した動作ハンドルを識別し、リソースハンドルを失敗した実行前の状態に復元しようと試行する。ロールバック用に指定された動作ハンドルは、ロールバックが正常に処理されるか、あるいは動作ハンドルが無効になるまではロールバックモジュール２０８によって削除されない（図５Ｂを参照してさらに説明する）。ロールバックモジュール２０８は動作スタックの最上部に位置する安定した動作ハンドルに対してのみロールバック操作を実行することができる。トランザクションマネージャー１３０はリソースに変更を加える前にリソースロックに入るので、ロールバックモジュール２０８は同一の共有リソース１０８Ａ～Ｃ上で操作している他の動作がデッドロック、競合状態または、分散コンピューティングシステムの予期される状態との干渉に入ることを保証するために、動作スタック上のロールバックを処理する。ロールバックモジュール２０８は、ロールバックが成功したか失敗したかを示す信号をトランザクションマネージャー１３０に送信する。ロールバックモジュール２０８が失敗した動作ハンドルを適切にロールバックできない場合、必ずトランザクションマネージャー１３０が復旧操作を試行する。

【0026】

復旧モジュール２１０は適切にロールバックに失敗し、動作スタック上で一貫性のない状態のままにされた動作ハンドルの復旧を管理する。復旧モジュール２１０は復旧タスクが正常に完了したかどうかを監視し、それに従って動作ハンドルを一貫性のある状態に戻し、成功した復旧または失敗した復旧のいずれかを示す信号を返す。復旧が成功した場合、一貫性のない動作ハンドルのライフサイクルは、動作スタックから削除されることによって終了する。復旧に失敗すると、ユーザーからの手動の介入が必要になる可能性がある。

【0027】

トランザクションを実行するためのプロセス
図３Ａは、本実施形態による分散コンピューティングシステム１００においてトランザクションを管理するための例示的なプロセスを示す。共有リソース１０８Ａ～Ｃを変更するトランザクションは、通常、トランザクションによって変更される共有リソース１０８の各コピーにおいて一貫した状態を達成すべく、各パーティション１０２Ａ～Ｃ上で実行される。ただし、図３Ａに示される例では、明確にするために１つのパーティションのみが示されている。この例では、トランザクションマネージャーは、スクリプトを削除するためのユーザー要求１３２を受信する。テンプレートリソースにはスクリプトとスクリプトで使用されるエイリアスが含まれているとすると、トランザクションマネージャーはスクリプトを削除する前に、テンプレートリソースを非アクティブ状態に設定する必要もある。これは、テンプレートが変更されているときに、他のスクリプトリソースがテンプレートを使用していないことを保証するために行われる。トランザクションマネージャーはテンプレート動作スタック３００およびスクリプト動作スタック３０２を含む、テンプレートリソースおよびスクリプトリソースのリソースハンドルをそれぞれ取得する。テンプレート動作スタック３００およびスクリプト動作スタック３０２は、トランザクションマネージャー１３０がテンプレートリソースおよびスクリプトリソースにアクセスし、要求されたトランザクションに従って両方のリソースを変更することができる。

【0028】

トランザクションマネージャー１３０は、非アクティブにするためのテンプレートを変更する第１の動作ハンドル（例えば、更新操作）と、スクリプトを削除するための第２の動作ハンドルの２つのハンドルを生成する。これらの動作ハンドルは図３Ａ中で動作ハンドル「更新_A1」および動作ハンドル「削除_A1」として示され、下付き文字はトランザクションＡの範囲内で実行される順序を示している。トランザクションマネージャー１３０はトランザクションが失敗した場合に現在の状態にロールバックするために、トランザクションＡを実行する前に各リソースの状態を記録する。例えば、テンプレートの効果的の非アクティブ化によって更新_A1動作ハンドルは正常に実行されたが、削除_A2動作ハンドルは失敗した場合、トランザクションＡは集合トランザクションとして失敗となる。この例では、ロールバックモジュール２０８は、トランザクションＡの実行が失敗する前に記録された状態情報を使用して、テンプレートリソースおよびスクリプトリソースを以前の状態に復元することが可能である。

【0029】

図３Ｂは、本実施形態による図３Ａに示されるトランザクションを実行するための例示的な実行順序を示すフローチャートである。図３Ｂ中で示される本実施形態において、トランザクションＡとＣはそれぞれの動作スタックの最下部に位置するため、最初に実行を開始する。一般に、動作スタックの最下部に位置する動作ハンドルは、同じトランザクション内で相互に依存関係がない場合、同時に実行される可能性がある。さらに、同じ動作スタック上の動作ハンドルは、必ず動作スタックの最下部に位置する動作ハンドルから開始し、その後、動作スタックの最上位に到達するまで動作ハンドルを上に処理する。これが図３Ｂ中に示されており、トランザクションは更新_A1および削除_C1を実行することによって開始３０６をする。動作ハンドル更新_A1と削除_A2はそれぞれの動作スタックの一番下に位置するが、動作ハンドル削除_A2は動作アハンドル更新_A1に依存しており、実行する前にその完了を待つ必要がある。しかし、スケジュール動作スタック３０４の動作ハンドル削除_C1は、スクリプト動作スタック３０２の削除_C2に依存せず、実行を開始することが可能である。ただし、仮にスケジュール動作スタック３０４上の削除_C1が、トランザクションＡおよびＢがそれぞれの実行を完了する前にその実行を正常に完了したとしても、削除_A2が更新_A1を、削除_B2は更新Ｂ１を待たなければならないとすると、スクリプト動作スタック３０２上の削除_C2はトランザクションＡおよびＢが正常に完了するまで実行を待たなければならない。

【0030】

動作を実行するためのプロセス
図４Ａは、本実施形態による共有リソース１０８を変更するためのプロセスを示す関係図である。図４Ａに示される実施形態において、トランザクションマネージャーはユーザー要求から動作４００を実行するための指示を受信し、リソースハンドル要求４０２を状態マネージャーに送信して、変更される共有リソース１０８へのアクセスを取得する。状態マネージャーは要求された共有リソースに対するリソースハンドルを作成３００し、リソースハンドルをトランザクションマネージャーに送信４０６する。トランザクションマネージャーはリソースハンドルの動作ロックを入力４０８し、要求された動作を表す動作ハンドルを作成４１０する。トランザクションマネージャーは変更する共有リソースに対応する動作スタック上に動作ハンドルを配置４１２する。トランザクションマネージャーは動作を実行４１４する。動作が成功４１６に実行された場合、トランザクションマネージャーは結果４１８を、ユーザー要求を生成したユーザーに送信し、状態マネージャーにリソースハンドルがもはや不要になったことを通知４２０する。状態マネージャーは、ユーザーが動作ハンドルをコミットするのを待ってから４２８、リソースハンドルをメモリーから解放する。ただし、実行された動作が成功しなかった場合４１６、ロールバックモジュールは動作のロールバック４２２を試行する。ロールバックが成功した場合、トランザクションマネージャーが実行され、失敗した動作ハンドルが動作スタックから削除され、共有リソースは動作ハンドルの実行前に保持していた状態を再開する。ロールバックが失敗した場合、復旧モジュールは要求された動作が実行される前に、共有リソースの前の状態への復旧４２６を必ず試行する。

【0031】

図４Ｂは、本実施形態による動作スタック上で正常に実行された動作ハンドルをコミットするためのプロセスを示す関係図である。図４Ｂに示す実施形態では、トランザクションマネージャーはユーザー要求からコミット動作４２６指示を受信し、共有リソースにアクセスするために前もって使われていたリソースハンドルを再取得するために、リソースハンドル要求４３２を状態マネージャーに再送信する。状態マネージャーはリソースハンドルをトランザクションマネージャーに送信４３４し、トランザクションマネージャーはリソースハンドルに正常な動作ハンドルをコミットするような指示４３６を出す。コミットされると、状態マネージャーは動作スタックから動作ハンドルを削除４３８し、動作ハンドルがクリップインヴォーキング４４０かどうかを識別する。動作ハンドルがクリップインヴォーキングである場合、動作ハンドルの以前の状態は無効になり、動作スタックからクリップ４４２される。動作ハンドルがクリップインヴォーキングでない場合は、単純に動作スタックの最上部から削除される。トランザクションマネージャーは、リソースハンドルが不要になったことを状態マネージャーに再度通知４４４する。状態マネージャーは、動作スタックが空であるかどうかを判定４４６する。いくつかの動作ハンドルが動作スタック上に残っている場合、状態マネージャーは各動作ハンドルが正常に実行されるか、ロールバックされるか、動作スタックからクリップされるまで、リソースハンドルをメモリーから解放しない。動作スタックが空の場合は、状態マネージャーはリソースハンドルを解放４４８し、次の要求を待つ。

【0032】

動作スタックを管理するためのプロセス
図５Ａ、５Ｂ、および６は分散コンピューティングシステム１００の各パーティション１０２内の共有リソース１０８に対応するリソース動作スタックの管理に関連するいくつかのプロセスを示している。以下の例では簡便のため、リソース動作スタックが１つのパーティションにのみ示されている。しかし、以下の例で実行される動作は分散コンピューティングシステム１００内のすべてのパーティションにわたる共有リソースの各コピーに適用される。各例においては、リソース動作スタック５００はスクリプト動作スタック、テンプレート動作スタック、またはスケジュール動作スタックに対応し得る。

【0033】

動作ハンドルをコミットするプロセス
図５Ａは、本実施形態によるリソース動作スタック５００上で正常な動作ハンドルをコミットするためのプロセスを示している。図５に示されるように、ステップＡではリソース動作スタック５００は空（すなわち、対応する共有リソースを変更する動作ハンドルがない）であり、その初期状態はヌル（ｎｕｌｌ）である。ステップＢにおいて、リソース動作スタック５００はリソースのインスタンスの作成を要求する動作ハンドルを受信し、リソース動作スタック５００の状態を状態１に更新する。１つまたは複数の実施形態においては、この動作はスクリプト動作スタック内のスクリプト、テンプレート動作スタック内のテンプレート、またはスケジュール動作スタック内のスケジュールの作成に対応し得る。ステップＣにおいては、動作ハンドルは正常に実行され、ユーザーによってコミットされ、そして、リソース動作スタック５００から削除されるように設定される（点線で示されているように）。最終的に、ステップＤでは、正常な動作ハンドルがリソース動作スタック５００から削除され、現在の状態は状態１を維持する。

【0034】

動作スタックをクリッピングするプロセス
図５Ｂは、本実施形態によるリソース動作スタック５００をクリッピングするためのプロセスを示している。図５ＢのステップＡに示されるように、リソース動作スタック５００は動作スタックに対して状態３に更新するように指示する動作ハンドルを受信し、その結果、リソース動作スタックは現在の状態３を有するようになる。１つまたは複数の実施形態においては、この動作はスクリプト動作スタック内のスクリプトの更新、テンプレート動作スタック内のテンプレートの更新、またはスケジュール動作スタック内のスケジュールの更新に対応し得る。ただし、動作ハンドルがリソース動作スタック５００から削除される前に、別の動作ハンドルが到着して実行される。ステップＢでは、リソース動作スタック５００は、動作スタックに指示する第２の動作ハンドルを受信して、リソース動作スタック５００に対応する共有リソース上で、再び更新を実行する。ステップＣにおいて、第２の動作ハンドルは正常に実行され、リソース動作スタックを状態４に更新し、そして、リソース動作スタック５００から削除されるように設定される（点線で示されるように）。第２の更新動作ハンドルが成功であったため、それはコミットされ、リソース動作スタック５００から削除される。しかし、共有リソースは現在の状態が状態４であるため、あたかもリソース動作スタックを状態３に更新する動作ハンドルが全く実行されなかったように見える可能性がある。したがって、トランザクションマネージャー１３０は第１の更新動作ハンドルを無効にし、第２の動作ハンドルが削除されると動作スタックからクリップする。これは、ステップＤに示されており、ここで、リソース動作スタック５００は再び空となり、現在の状態は４を有することとなる。

【0035】

失敗した動作をロールバックするプロセス
図６は本実施形態による、失敗した動作ハンドルをロールバックするためのプロセスを示している。図６に示される本実施形態のステップＡにおいて、初期のリソース動作スタック５００は作成動作に対応する動作ハンドルを有しており、現在の状態は１である。ステップＢでは、初期の作成動作ハンドルが実行され、追加の作成動作ハンドルがリソース動作スタック５００に加えられる。このステップでは、作成動作ハンドルはコミットもロールバックもされておらず、第２の作成動作ハンドルはまだ実行を終了せずに、リソース動作スタック５００の現在の状態は２ではなくむしろ１のままである。ステップＣにおいては、リソース動作スタック５００によって参照される共有リソースが第１の作成動作ハンドルによって既に作成されているため、第２の作成動作ハンドルの実行は失敗することになる。第２の作成動作ハンドルはロールバック用にマークされ（点線で示されているように）、現在の状態は１を維持する。リソース動作スタック５００は、ロールバックモジュール２０８によって処理される。第２の作成動作ハンドルはリソース動作スタック５００の最上部にあり、ロールバックのマークが付けられているため、迅速にロールバックすることができる。ロールバックモジュール２０８は、第２の作成動作ハンドルに対してロールバック操作を実行し、それをリソース動作スタック５００から削除する。ステップＤでは、第１の作成動作ハンドルはコミットされ（点線で示されるように）、その後、現在の状態１を残してリソース動作スタック５００から削除される。

【0036】

トランザクションを管理するためのプロセス
図７は本実施形態によるトランザクションを管理するためのプロセスを示している。本実施形態では、図７に示されるように、トランザクションマネージャーはユーザー要求から共有リソース上でトランザクションを実行するための要求を受信７００し、共有リソース上でトランザクションを実行７１０する。トランザクションが成功である場合、トランザクションマネージャーにトランザクションの成功を示し７２０、トランザクションをコミット７３０し、分散コンピューティングシステムのユーザーに結果を返す７４０。逆に、トランザクションが失敗である場合は失敗したトランザクションを示し７２０、ロールバックモジュールは失敗したトランザクションをロールバック７５０する。

【0037】

管理コンピューターの例
図８は本実施形態による管理コンピューター８００の例を示す高水準のブロック図である。チップセット８０４に結合された少なくとも１つのプロセッサー８０２が示されている。チップセット８０４はメモリーコントローラハブ８２０および入力／出力（Ｉ ／ Ｏ）コントローラハブ８２２を含む。メモリー８０６およびグラフィックアダプタ８１２はメモリーコントローラハブ８２０に結合され、ディスプレイデバイス８１８はグラフィックアダプタ８１２に結合される。ストレージデバイス８０８、キーボード８１０、ポインティングデバイス８１４、およびネットワークアダプタ８１６はＩ ／ Ｏコントローラハブ８２２に結合される。管理コンピューター８００の他の実施形態は異なるアーキテクチャを有する。例えば、いくつかの実施形態では、メモリー８０６はプロセッサー８０２に直接結合される。

【0038】

ストレージデバイス８０８は、ハードドライブ、コンパクトディスクリードオンリーメモリー（ＣＤ－ＲＯＭ）、ＤＶＤ、またはソリッドステートメモリーデバイスなどの１つまたは複数の非一時的なコンピューター可読記憶媒体を含む。メモリー８０６は、プロセッサー８０２によって使用される指示およびデータを保持する。ポインティングデバイス８１４は管理コンピューター８００にデータを入力するために、キーボード８１０と組み合わせて使用される。グラフィックアダプタ８１２は、画像および他の情報をディスプレイデバイス８１８に表示する。いくつかの実施形態では、ディスプレイデバイス８１８はユーザー入力および選択を受信するためのタッチスクリーン機能を含む。ネットワークアダプタ８１６は管理コンピューター８００をネットワーク１２６に結合する。管理コンピューター８００のいくつかの実施形態は、図８に示されるものとは異なるおよび／または他の構成要素を有する。

【0039】

管理コンピューター８００は、本明細書で説明される機能を提供するためのコンピュータプログラムモジュールを実行するのに適したものである。「モジュール」という用語は、本明細書で使用されるときは、特定の機能を提供するために使用されるコンピュータープログラム指示および／または他の論理を指す。したがって、モジュールはハードウェア、ファームウェア、および/またはソフトウェアで実装することが可能である。本実施形態では、実行可能なコンピュータープログラム指示で形成されたプログラムモジュールは記憶装置８０８に格納され、メモリー８０６に導かれ、プロセッサー８０２によって実行される。

【0040】

追加の考慮事項
上述のいくつかの部分は、アルゴリズムのプロセスまたは操作の観点から実施形態を説明している。これらのアルゴリズムの説明および表現は、当業者達の業務内容を他の当業者に効果的に伝えるために、データ処理技術の当業者によって一般的に用いられている。これらの操作は、プロセッサーまたは同等の電気回路、マイクロコード等によって実装するための指示を備えるコンピュータープログラムによって実装されると理解される。さらに、一般性を欠くことなく、これらの機能操作の配置をモジュールと呼ぶことも便利な場合があることが認められている。説明された操作およびそれらに関連するモジュールは、ソフトウェア、ファームウェア、ハードウェア、またはそれらのあらゆる組み合わせで形態化することができる。

【0041】

本明細書のあらゆる言及で使用される「一実施形態」または「実施形態」は、実施形態に関連して説明される特定の要素、特徴、構造、または特性が少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な場所における「一実施形態において」という表現は、必ずしもすべてが同じ実施形態を指すとは限らない。

【0042】

いくつかの実施形態は、それらから派生したものと合わせて「結合された」および「接続された」という表現を使用して説明され得る。これらの用語は、相互の同義語として意図されたものではないことを理解する必要がある。例えば、いくつかの実施形態は、２つ以上の要素が互いに直接物理的または電気的に接触していることを示すために「接続された」という用語を使用して説明され得る。別の例では、いくつかの実施形態は、２つ以上の要素が直接の物理的または電気的接触にあることを示すために「結合された」という用語を使用して説明され得る。ただし、「結合された」という用語は、2つ以上の要素が互いに直接接触していないが、それでも互いに協力または相互作用していることを意味する場合もある。

【0043】

本明細書で使用される場合、「備える」、「備えている」、「含む」、「含んでいる」、「有する」、「有している」またはそれらの変形した用語は、非独占的な包含をカバーすることを意図している。例えば、要素のリストを含むプロセス、方法、物品、または装置は、必ずしもそれらの要素のみに限定されるわけではなく、そのようなプロセス、方法、物品、または装置に明確にリストに示されていないか、固有ではない他の要素を含み得る。さらに、明確に反対の記載がない限り、「または」は包括していることを指しており、排他的であることを指してはいない。例えば、条件ＡまたはＢは次のいずれかによって満たされる：Ａは真（あるいは、存在する）でありＢは偽（あるいは、存在しない）、Ａは偽（あるいは、存在しない）でありＢは真（あるいは、存在する）、ＡとＢの両方とも真（あるいは、存在する）である。さらに、「ａ」または「ａｎ」の使用は、本明細書の実施形態の要素およびコンポーネントを説明するために使用される。これは単に便宜のため、および開示の一般的な意味を与えるために行われる。この説明は、１つまたは少なくとも１つを含むように読む必要があり、別の意味であることが明確でない限り、単数形には複数形も含まれる。

【0044】

この開示を読むにあたり、当業者はメッセージングディレクトリおよびそれらのディレクトリのメッセージングメンバーを生成するためのシステムおよびプロセスに対する、追加の代替となる構造的および機能的設計を理解し得る。したがって、特定の実施形態および用途が例示、説明されているが、説明される内容は本明細書に開示される通りの構造および構成要素に限定されないこと、そして、当業者によって本明細書に開示される方法および装置の配置、操作および詳細の様々な変更、変化、バリエーションは明白となるとなることは理解されるべきである。

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5A】

【図5B】

【図6】

【図7】

【図8】