JP2004295895A - ２点間の保証および機能の構成が可能なメッセージ配信 - Google Patents

Abstract

【課題】 複数の別個のメッセージ伝送機構にアクセスすると共に、２つのエンドポイント間のメッセージ配信のための１つまたは複数のアプリケーションを開発するための単一のプログラミングモデルを提供すること。
【解決手段】 このプログラミングモデルにより、メッセージを移送するための、独立に構成が可能な保証／機能が可能となる。構成が可能な保証は、少なくとも１回配信、高々１回メッセージ配信、順序ごとメッセージ配信、およびメッセージ生存期間から選択することができる。独立に選ばれる機能は、セッション状態ストレージ、生存期間の延長、処理済みメッセージバッファリングを含むことができる。
【選択図】 図２

Description

本発明は、一般に高信頼性メッセージ交換システムに関する。より詳細には、本発明は、アプリケーションに特有の、またはそのアプリケーションのインストールに特有の要件に合わせて、高信頼性保証および機能の構成および調整が可能な単一のプログラミングモデルに関する。

メッセージ交換システムはますます、通信のための一般的な方法となってきている。こうした通信システムは、Ｅメールシステムからセキュリティで保護された取引まで、あるいはチャットルームからインターネットショッピングなどの様々なウェブサービスまで多岐に渡る。こうした通信システムはそれぞれ、必要とするセキュリティ、信頼性、拡張性（ｓｃａｌａｂｉｌｉｔｙ）、および可用性（ａｖａｉｌａｂｉｌｉｔｙ）の程度が異なる。こうした要件は、単純な信頼性のない応答不要なデータグラム機構や処理済の永続メッセージの交換を実現するキューイングシステムなどの疎結合モデルから、セッション指向の通信を行う伝送制御プロトコル（ＴＣＰ）やリモート手続き呼出し（ＲＰＣ）などのプロトコルを用いる密結合モデルまで多岐に渡る。

上述の具体的な通信機構に対する要件は様々であるので、プログラムモデルはこうした各機構間で異なり、さらには異なるベンダの類似のシステム間でも異なることとなる。さらに、各プログラムモデルで柔軟に構成できるか否かは、その機構および形態による。プログラマおよびシステム設計者は、通常は各機構を理解しなければならない、すなわちプログラマおよびシステム設計者の要件に最も適しているものを決定し、およびその機構によって定義された特定のインターフェースに合わせてコードを書かなければならない。

しかし、製品または配置の要件が変わり、および異なる通信機構が必要となる場合、得られたコードを通常は再設計して再実装する必要がある。これは、ほとんどの信頼性のある通信機構において、その信頼性のある通信機構を使用するアプリケーションに提供する信頼性の保証および機能の選択に関して十分な柔軟性が提供されず、またはその選択が制御されないためである。例えば、そのような機構が提供するのは、一般に順序だて（ｉｎ−ｏｒｄｅｒ）確実に１回（ｅｘａｃｔｌｙ−ｏｎｃｅ）の配信だけである。しかし、実際にこのレベルをアプリケーションが必要とする状況は多くない。

また、確実に１回や順序ごとの配信など、より多くの、またはより高い保証を提供することによるコストの発生もある。例えば、メッセージの受信を確認するために、受信側から送信側に確認メッセージを送り返さなければならない。この肯定応答がない場合、送信側は、メッセージが受信されたか否かを知ることができず、したがって確実に１回レベルの保証を提供することができない。時々メッセージが紛失しても存続することができるアプリケーションにおいては、少なくとも１回（ａｔ−ｌｅａｓｔ−ｏｎｃｅ）レベルの肯定応答プロトコルのため負担を負うことが望ましくないことがあり、単一の低優先順位メッセージを配信することができない場合セッション障害の危険をあえて冒すことが望ましくないことがある。そのような場合に肯定応答を要求することにより、不必要に通信コストが増大し、アプリケーション可用性が低下する可能性がある。

したがって、アプリケーションに提供すべきメッセージ配信の保証および機能の構成が可能な、高信頼性メッセージ交換の下部構造（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を提供する単一のプログラミングモデルが求められている。さらに、様々な伝送機構の形態、および様々な保証および機能に対する、広範なセッション状態およびメッセージ交換ストレージ機構をサポートする単一の高信頼性メッセージ交換プログラミングモデルが求められている。

本発明の例示される実施形態によれば、現在のメッセージ交換システムの前述の不完全な点および欠点が解決される。例えば、例示される実施形態は、１つまたは複数のメッセージ伝送機構（ｍｅｓｓａｇｅ ｔｒａｎｓｐｏｒｔ）をサポートするメッセージ交換システムを提供する。さらに、本発明は、開発時に特定のメッセージ伝送機構を指定するのではなく、実行時に特定のメッセージ伝送機構を選択するために１つまたは複数のエンドツーエンド配信保証レベルの指定を可能にする単一のプログラムモデルを提供することによってアプリケーション開発を簡略化する高信頼性メッセージ交換のアブストラクションを提供する。

本発明の高信頼性メッセージ交換のアブストラクションは、メッセージを実際に転送する際に基礎となる伝送機構とは無関係のアプリケーション指定のメッセージの配信の保証を提供する。したがって、このアブストラクションにより、アプリケーション開発者は伝送機構レベルの細部から離されることとなる。同様に、このアブストラクションにより、ネットワークトポロジおよびシステム接続性の細部からも開発者は分離されることが可能となる。

本システムにおいては、まず、複数の別個のメッセージ伝送機構を介してメッセージを交換するために送信演算（ｓｅｎｄｉｎｇ ｏｐｅｒａｔｉｏｎ）および受信演算（ｒｅｃｅｉｖｉｎｇ ｏｐｅｒａｔｉｏｎ）を抽象化するメッセージチャネルインターフェースが定義される。従来のプログラムモデルとは異なり、基礎となる伝送機構の定義とは無関係の複数のエンドツーエンドメッセージの配信の保証が定義され、および単一のプログラミングモデルと共に使用するため各エンドツーエンドメッセージの配信の保証を選択することができる。さらに、メッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回（ａｔ−ｍｏｓｔ−ｏｎｃｅ）メッセージ配信、順序ごと送信メッセージ配信，およびセッション生存期間から選ぶことができる。最後に、複数のローカルの高信頼性メッセージ交換機能が定義される。単一のプログラムモデル内で使用するために各ローカルの高信頼性メッセージ交換を選択することができる。加えて、ローカルの高信頼性メッセージ交換機能は、状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのいずれでもよい。

本発明の別に例示される実施形態によれば、別個のメッセージ伝送機構にアクセスするための単一のプログラムモデルを提供することによってアプリケーション開発を簡略化する方法が提供され、その別個のメッセージ伝送機構を介してメッセージを交換するためのメッセージチャネルインターフェースを抽象化し、アプリケーション開発者が１つまたは複数のエンドツーエンドメッセージの配信の保証を指定するのを可能にする。単一のプログラムモデルと共に使用するためにメッセージの配信の保証を選択することができ、メッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序ごと送信メッセージ配信、およびセッション生存期間から選ぶことができる。さらに、この方法により、アプリケーション開発者が１つまたは複数のローカルの高信頼性メッセージ交換機能を指定することが可能となる。単一のプログラムモデル内で使用するために各ローカルの高信頼性メッセージ交換機能を選択することができ、各ローカルの高信頼性メッセージ交換機能は、セッション状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのうち少なくとも１つを含む。

本発明のさらなる特徴および利点を以下で説明するが、その一部は以下の説明から明らかとなり、あるいは本発明を実施することによって知ることができる。本発明の特徴および利点は、特許請求の範囲に具体的に指摘される手段およびその組合せによって実現され、得られる。本発明の上記およびその他の特徴は、以下の説明および特許請求の範囲から完全に明らかとなり、あるいは本発明の上記およびその他の特徴は、以下に説明する本発明を実施することによって知ることができる。

本発明の上記およびその他の利点および特徴を得る方法を説明するために、添付の図面に示される本発明の特定の実施形態を参照することによって上記で簡潔に説明した本発明をより具体的に説明する。これらの図面は本発明の典型的な実施形態を示すに過ぎず、したがって本発明の範囲を限定するとみなすべきでないことを理解し、添付の図面を使用することにより、さらに具体的におよび詳細に本発明の説明を行う。

本発明は、１つまたは複数のアプリケーションを開発すると共に、複数の別個のメッセージ伝送機構にアクセスし、それを使用するための単一のプログラミングモデルを提供することによって高信頼性メッセージ交換アプリケーション開発を簡略化するための方法、システム、およびコンピュータプログラム製品まで含む。本発明の実施形態は、以下でより詳細に議論するように、様々なコンピュータハードウェアを含む専用コンピュータまたは汎用コンピュータを備えることができる。

図１に、高信頼性メッセージ交換スタック１００ａおよび１００ｂの高レベル表現を示す。メッセージ交換スタックでは、高信頼性メッセージ交換プロトコル１２５を用いない場合、アプリケーション１０５がメッセージを、例えば別のアプリケーション層１８５に送りたいとき、アプリケーション１０５は、データグラムメッセージ交換層１４０にメッセージまたは一連のメッセージ１１５を直接転送する（アプリケーション１０５は、例えばサービスなどのどんなタイプのアプリケーションでもよいことに留意されたい。また一般に、アプリケーション１０５がアプリケーションフレームワークを適宜包含することを理解されたい。）。データグラムは信頼性が低いので、メッセージ１１５が複製され、遅延し、および／または失われる可能性がある。例えば、信頼性のない応答不要なデータグラムプロトコルでは、メッセージ１１５が、伝送機構１６０と１６５の間の中継点１３５におけるものを含むいくつかの理由で失われる可能性がある。したがって、パートナのエンドポイントのアプリケーション１８５は、メッセージ１１５を決して受信せず、送信側アプリケーション１０５は、そのメッセージ１１５が受信されなかったことに気付かない。

しかし、本発明の例示される実施形態によれば、高信頼性メッセージ交換スタック１００ａおよび１００ｂは、高信頼性メッセージ交換プロトコル１２５を備える。したがって、例えば、高信頼性メッセージ交換フレームワーク１２０（あるいは１８０）により、アプリケーション１０５から送信されたメッセージ１１５がその宛先エンドポイントに適切に到着するよう保証することができる。例えば、アプリケーション１０５がそのセッションの相手方アプリケーション１８５にメッセージ１１５を転送したい場合、アプリケーション１０５は、メッセージ１１５を高信頼性メッセージ交換フレームワーク１２０に送ることができ、そこでメッセージ１１５がセッションに割り当てられ、メッセージ１１５にメッセージのシーケンス番号が与えられる。セッション識別子が、アプリケーション１０５とアプリケーション１８５の間のセッション通信に対応する。言い換えれば、セッションとは、２つのアプリケーション１０５と１８５との間の２重会話を指す。シーケンス番号付けは、セッション通信中の所定のメッセージに対し行われる。例えば、２つのアプリケーション１０５と１８５との間で通信される単一のセッション内にいくつかのメッセージが存在する可能性があり、各メッセージは、アプリケーションによって送信された順に順次番号付けされる。加えて、アプリケーション１０５、１８５、および場合によっては他のアプリケーション間で確立された複数のセッションが存在する可能性がある（確立された各セッションは、同一のまたは異なる配信保証を有する可能性がある）。したがって、各メッセージには、所定のセッション順序およびそのセッション内のメッセージのシーケンス順序を識別するセッション番号およびシーケンス番号が一意に割り当てられる。

メッセージ１９１上にセッションおよびシーケンスヘッダが書き込まれ、その他の必要なチャネル処理が実行された後、メッセージ１９１は、送信バッファ内のセッション状態１９０に格納される。その後で、メッセージ１９１のコピーがデータグラムメッセージ交換１４０を介して移送される。データグラムメッセージ交換１４０は、例えばルーティングヘッダを提供することにより、メッセージ１９１のエンドツーエンド伝送を実施する。次いでメッセージ１９１が、場合によってはメッセージ１９１のエンドツーエンド伝送を一連のポイントツーポイント伝送としてそれぞれ実施する１つまたは複数の中継点、例えば中継点１３５を介して転送される。拡張された傍受機構（ｉｎｔｅｒｃｅｐｔｉｏｎ ｍｅｃｈａｎｉｓｍ）を使用して、ルーティング、フィルタリング、ポリシー管理、セキュリティなどの動作（ｂｅｈａｖｉｏｒｓ）を実施することができる。伝送機構１４５、１７０、１５５、および各メッセージ交換エンドポイント中のエンドポイントで使用可能な動作、および中継点１４０、１７５、１５０を、プログラムすることによって、またはシステムを構成することによって確立することができる。

少なくとも１回配信（以下でより詳細に説明する）に対する保証が、アプリケーション１０５に対して指定される場合、高信頼性メッセージ交換フレームワーク１２０は、高信頼性メッセージ交換フレームワーク１８０から、どのメッセージが適切に受信されたかを示す肯定応答の受信を待ち受ける。メッセージ１９２は、メッセージ１９１（例えばシーケンス中のメッセージ５）が受信されたという肯定応答を搬送する。周期的に、高信頼性メッセージ交換フレームワーク１８０がコピーを適切に受信しなかったため、または１２０が１８０から肯定応答を受信しなかったために高信頼性メッセージ交換フレームワーク１２０が肯定応答メッセージ１９２を受信しなかった場合、メッセージ１９１が再送信される。したがって、例えば中継点１３５で、メッセージ１９１が失われ、遅延し、または誤ってルーティングされた場合、高信頼性メッセージ交換フレームワーク１２０は、高信頼性メッセージ交換フレームワーク１８０がメッセージ１９１の少なくとも１つのコピーを適切に受信するように保証しようと試みて、メッセージ１９１を（後述のタイムアウト期間内で）周期的に送信し続ける。しかし、メッセージ１９１に関して上述したのと同様の理由で、肯定応答１９２が失われ、遅延し、または誤ってルーティングされる可能性がある。したがって、本発明は、以下で説明するように肯定応答メッセージ１９２の高信頼性メッセージ配信を提供する。

高信頼性メッセージ交換フレームワーク１８０が首尾よくメッセージ１９１のコピーを受信すると、高信頼性メッセージ交換フレームワーク１８０は肯定応答メッセージ１９２を高信頼性メッセージ交換フレームワーク１２０に送信する。肯定応答メッセージ１９２を受信すると、高信頼性メッセージ交換フレームワーク１２０は、そのセッション状態（送信）バッファ１９０からメッセージ１９１のコピーを削除し、メッセージ１９１の追加の送信を停止する。同様に、高信頼性メッセージ交換フレームワーク１８０は、そのセッション状態１９５中に、メッセージ１９１のコピーを受信したことを記録し、その結果、メッセージがアプリケーション１８５に既に配信されたか否かにかかわらず、高信頼性メッセージフレームワーク１８０が受信した任意の複製メッセージを廃棄することができる。その後で、アプリケーション１８５は、セッション状態（受信）バッファ１９５から、そのＲｅｃｅｉｖｅ（）コマンドを介して、受信されたメッセージを取り出すことができる。肯定応答１９２が失われ、遅延し、または誤ってルーティングされたために高信頼性メッセージ交換フレームワーク１２０が肯定応答１９２を受信しなかった場合、メッセージ１９１の再送信が続行され、それによって高信頼性メッセージ交換フレームワーク１８０が肯定応答１９２の別のコピーを送信するようトリガがかけられる。このプロセスは、高信頼性メッセージ交換フレームワーク１２０が少なくとも１つの肯定応答１９２を受信するまで、または高信頼性メッセージ交換フレームワーク１２０が再試行を諦め障害表示をアプリケーション１０５に送るまで続行することができる。

高信頼性メッセージ交換フレームワーク１２０および／または１８０は、本発明によるダイアログ２００（図２）としてそれぞれ構成することができる。ダイアログ２００は、図２を参照してより詳細に説明する。ダイアログ２００は、メッセージフレームワークアブストラクションであり、この場合サービス（またはアプリケーションインスタンス）は、他のサービスとの高信頼性のセッション指向の通信のためにダイアログ２００を使用する。プログラマは、ダイアログチャネル２２０を使用してダイアログにアクセスすることができる。さらに、ダイアログ２００は、アプリケーションに対するメッセージの配信の保証を構成することが可能な高信頼性メッセージ交換下部構造および単一のプログラミングモデルを提供する。こうした信頼性保証レベルは満たされなければならず、そうでなければセッション障害が発生する。ダイアログ２００を設計することにより、対応するランタイムの実装が柔軟になって、アプリケーションの実装に対して主張される保証（正確さの制約）を維持する限りは追加の機能を提供することができる。具体的には、アプリケーションは、アプリケーションの実装にトランスペアレントな様々な度合いの可用性および拡張性を備えることができる。さらに、アプリケーション１０５と１８５との間のこうしたセッションの通信は、様々な伝送機構の種類（例えば、ＴＣＰ／ＩＰ１６０およびＨＴＴＰ１６５）、伝送機構接続インスタンス、ネットワークトポロジを介して実現することができる。

ダイアログ２００によって提供される信頼性保証は、少なくとも１回（ＡＬＯ）配信、高々１回（ＡＭＯ）配信、および順序ごと（ＩＯ）配信を含む。追加のセッション生存期間（ＴＴＬ）保証も提供される。ＡＭＯ保証により、送信側アプリケーションによって送信される任意の所与のメッセージについて、メッセージが受信側アプリケーションに最大１回配信される。ダイアログ２００はアブストラクションであるので、アプリケーションは、複製メッセージがアプリケーションセマンティクスを破る場合に、複製メッセージを検出および廃棄する必要から解放される。同様に、ＡＬＯ保証は、送信側アプリケーションによって送信されるメッセージすべてを受信側エンドポイントが受信することを可能にし、それによってアプリケーションが、紛失したメッセージまたは誤って送られたメッセージを検出し、その再送信を調整する必要から解放される。ＩＯ保証は、送信側アプリケーションで送信された順番でメッセージを受信側アプリケーションに配信することを可能にする。これにより、アプリケーションは、メッセージの順序違い（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）受信を処理する必要から解放される。

ダイアログ２００はまた、セッションＴＴＬ保証も提供するが、これには、セッションＴＴＬが満了する前にパートナのエンドポイントのパートナ間におけるダイアログセッションを完了することが必要となる。ダイアログセッションが完了する前にセッションＴＴＬが満了した場合、ダイアログチャネルは障害状態に置かれ、障害の通知がアプリケーションに提供される。アプリケーションは、再度ＴＴＬのネゴシエーションを行うことによってセッションＴＴＬを延長することができる。

ダイアログによって、所与のアプリケーションおよび配置（ｄｅｐｌｏｙｍｅｎｔ）の所定の要件を満たすため、こうしたメッセージ配信の保証を個々に、または任意の組合せで使用することが可能となる。例えば、ＡＭＯ、ＡＬＯ、およびＩＯの３つの保証の組合せにより、ＴＣＰ／ＩＰなどのほとんどの信頼性の高い通信機構に典型的な、確実に１回、順序ごと配信が提供される。しかし、典型的な通信機構、およびそれに対応するプログラミングモデルとは異なり、アプリケーションが使用するプログラミングモデルを変更することなく、こうした保証をカスタマイズすることができる。

ダイアログ２００により、構成することができる保証が可能となるだけでなく、互いに独立に、かつ上記で選んだ保証とは無関係にローカルの高信頼性メッセージ交換の機能を選び、構成することも可能となる。こうしたローカルの高信頼性メッセージ交換の機能は、プログラミングモデルに一体化されたものと、アプリケーションプログラムとは無関係のカスタマイズに関するものとの２つの別個のカテゴリに分けられる。例えば、一体化されたローカルの機能には、アプリケーションに対して整合性、独立性、および原子性（ａｔｏｍｉｃｉｔｙ）のセマンティクスを有する処理済みバッファリング機能、またはプロファイルをセッションと関連付けて独立なカスタマイズを可能にするプロファイル参照が含まれる。カスタマイズが可能なローカルの機能には、以下で説明するように、セッション状態記憶の構成、バッファ割当（ｑｕｏｔａ）、送信タイムアウト、構成が可能なメッセージＴＴＬ、セッション優先順位メッセージ、またはポイズンメッセージを検出するしきい値を含めることができる。

本発明の例示される実施形態によれば、ダイアログ２００は、ダイアログストア２６０と呼ばれる置換えが可能なコンポーネントとしてセッション状態およびメッセージのストレージを提供する。ダイアログストア２６０は置換えが可能であるので、第３者がダイアログストア２６０を独自に実装して配布することができる。管理者は、所与のインストールにおいて実際に使用するダイアログストアを選ぶことができる。したがって、この機構により、非常に高い柔軟性を得ることができ、永続性、性能、自律性（ａｕｔｏｎｏｍｙ）、および管理目標が満たされ得ることとなる。ダイアログストア２６０は、メモリ内ストレージ、ディスク上の永続ストレージ、デーモンプロセスのストレージ、不揮発性メモリ内ストア、光ストレージ、磁気テープ、ネットワーク装着ストレージ、または取外し可能ストレージのうち少なくとも１つを有するプラグ接続が可能な（ｐｌｕｇｇａｂｌｅ）ストアとすることができる。さらに、ダイアログストアはリモートまたはオフノードとすることができる。

本発明の例示される実施形態によれば、すべての状態をアプリケーションメモリ内に保つメモリ内ダイアログストア（例えばダイアログストア２６０）が実装される。このストアは、その状態への非常に高速なアクセスを提供する。しかし、この代償としてアプリケーションプロセスの状態が失われた場合（例えばアプリケーションに、またはアプリケーションの実行に障害が発生したシステムのために、例えばユーザがアプリケーションを終了したり、オペレーティングシステムがアプリケーションを終了したりする場合）、すべての状態が失われる。

他の例示される実施形態によれば、高速ダイアログストア（例えばダイアログストア２６０）が実装されて、別々の専用デーモンプロセスのメモリ内に状態が維持される。このダイアログストアにより、その状態がアプリケーションプロセス障害にかかわらず維持されることが保証される。しかし代償として、状態を維持するためにプロセスの切換えが行われる。デーモンプロセスに障害が発生し、あるいはオペレーティングシステムまたはコンピュータノードに障害が発生した場合、担当するセッションについての全状態が失われる。

ダイアログストア実装の別の実施形態によれば（例えばダイアログストア２６０）、セッション状態情報が、構造化照会言語（ＳＱＬ）サーバなどのデータベース内に永続的に維持される。この永続的に維持される状態は、コンピュータノードまたはオペレーティングシステムの障害を超えて残ることができるが、代償として、その状態を維持するためにディスク書込みが行われる。状態の保守のためにＳＱＬサーバなどのデータベースシステムを使用する利点の１つは、重要なアプリケーション状態の定期的なバックアップおよび回復を行う代わりに、インストールすること自体で、ツール、技法、およびプロセスを既に適切に用意することができることである。

また、本発明においては、ローカルコンピュータノードまたは別のノード上で動作するように構成できるようなダイアログストアがあるようにすることができる。例えば、ＳＱＬサーバなどの永続ダイアログストアを、ローカルのサーバデータベースまたは別のノード上のデータベースを使用するように構成することができる。他のノードはクラスタ化システムの一部でよく、したがって非常に高い可用性を有する。

本発明はまた、アプリケーションによって使用される特定の配置特性を満たすように複数のストア（またはストア構成）が同時に存在できるようにする。さらに、負荷または容量要件の増大などの変化に対処し、新しいストレージの選択肢を利用し、または他の配置環境の考慮すべき点に対処するために、異なるストア（またはストア構成）を使用するようにアプリケーション構成を変更することができる。さらに、同一のアプリケーション内の異なる通信セッションが異なる構成要件を有することができる。ダイアログにより、各セッションを個々に構成することが可能となる。例えば、アプリケーション内のあるセッションは、永続状態ストレージにおいて最もうまく働く可能性があるが、他のセッションは、揮発性状態ストレージにおいて最もうまく働くかもしれない。ダイアログストアは、プロファイル（以下で説明する）を介して構成し、またはアプリケーションコードで記述することができる。

ダイアログ２００で提供される別の構成が可能な機能には、バッファ割当がある。ダイアログ２００は、送信側アプリケーションおよび受信側アプリケーションでメッセージをバッファリングする。このバッファリングにより、２つのアプリケーションの自律性が向上し、一方の側が、動作中ではない場合、または例えばネットワークパーティションのために到達できない場合であっても、他方の側が、そのローカルバッファにメッセージを送信し、またはそのローカルバッファからメッセージを受信することが可能となる。例えば、アプリケーション２０５は、他方が一時的に使用不能、すなわち動作中ではなく、または到達不能であっても引き続きメッセージを送信することができる。これは、メッセージを首尾よく転送することができるまでローカル送信バッファ２５０内にメッセージを蓄積することによって実施される。同様に、アプリケーション２０５は、メッセージを送信したアプリケーションが現在は動作することができない場合であっても、受信バッファ２４５内に先にバッファリングされたメッセージを受信することができる。ダイアログ２００は、システムでバッファリングする最大メッセージ数（メッセージサイズに左右される）を定義する構成が可能なバッファ割当を提供する。したがって、これにより、ダイアログ状態２３５において消費するスペースの量が制限され、他のエンドポイントによって消費することができるローカル資源が制限される。これにより、アプリケーションが指定のメッセージ数をローカルにバッファリングするのに十分なスペースをメッセージ交換システムが確保することも可能となる。ダイアログ２００はまた、メッセージ交換下部構造によってバッファリングされる最小メッセージ数を定義する最小バッファ割当を提供する。最小バッファ割当と最大メッセージサイズの組合せにより、メッセージ交換下部構造によってバッファリングされる最小バイト数が定義される。バッファ割当は、プロファイル（以下で説明する）を介して構成することができ、またはアプリケーションコードで記述することができる。

ダイアログ２００はまた、構成が可能な送信タイムアウトの機能も提供する。メッセージが送信されたとき、メッセージはダイアログストア２６０／送信バッファ２５０内に配置される。バッファが満杯である場合、すなわちバッファ割当に達した場合、送信タイムアウトが満了し、またはメッセージを保持するためにバッファ中のスペースが使用可能となるまで、Ｓｅｎｄ（）２１０に対する呼出しがブロックされる。メッセージが首尾よく受信側エンドポイントに転送され、受信側エンドポイントによって確認され、もはやローカルのエンドポイントで再試行する必要がないときに、バッファ内のスペースが使用可能となる。送信タイムアウトが満了する前にスペースが使用可能となった場合、Ｓｅｎｄ（）２１０呼出しは正常終了する。スペースが使用できるようになる前に送信タイムアウトが満了した場合、メッセージを首尾よくバッファリング（キャプチャ）することができなかったという通知をアプリケーションに提供するという例外が発生する。したがって、アプリケーションは後で再試行することができる。構成が可能なタイムアウトにより、アプリケーションは、ブロッキングの簡潔性に優先して応答性の程度を選ぶことができる。送信タイムアウトは、プロファイル（以下で説明する）を介して構成し、またはアプリケーションコードで記述することができる。

前述のように、ダイアログ２００は、エンドツーエンドのセッションＴＴＬ保証をサポートする。ダイアログ２００はまた、ローカルの機能として構成が可能な任意選択メッセージ生存期間も提供する。メッセージＴＴＬは、送信されたメッセージが、ＴＴＬで指定された時間内に受信側エンドポイントで首尾よく受信されなければならないことを要求し、そうでない場合、アプリケーション２０５に対してエラーが生成される。ダイアログ２００はまた、メッセージＴＴＬについての構成が可能な延長も提供する。したがって、ＴＴＬが満了したとき、通知が送信側アプリケーション２０５に提供される。次いでアプリケーション２０５は、ダイアログを終了するか、またはメッセージのＴＴＬを延長するかの選択肢を有する。送信タイムアウトと同様に、ＴＴＬは、アプリケーションコードで設定することができ、またはプロファイルを使用して間接的に構成することができる。

ダイアログ２００によって提供される別の機能は、割り当てられる任意選択の優先順位である。ダイアログ２００内のすべてのメッセージは同一の優先順位を有する。しかし、複数のダイアログからのメッセージを送信のために使用可能であるとき、メッセージの送信の際に、高い優先順位を有するダイアログが、低い優先順位を有するダイアログよりも優先される。同様に、受信側アプリケーションに「配信」するためにメッセージが使用可能であるとき、高い優先順位を有するメッセージが、低い優先順位を有するメッセージの前に受信される。優先順位は、アプリケーションコードで設定することができ、または以下で説明するプロファイルを使用して間接的に設定することができる。

ダイアログ２００はまた、任意選択でメッセージをトランザクション処理させるバッファリングも提供する。ダイアログがトランザクションと共に使用されるとき、ローカル送信／受信バッファは、トランザクション資源マネージャとして動作する。この場合、トランザクション結果に応じて、トランザクション下で受信されたメッセージは、一時的に配信された（受信バッファから削除された）とみなされる。同様に、トランザクションの結果に応じて、トランザクション下で送信されたメッセージは、一時的にキャプチャされる（送信バッファに加えられる）。そのトランザクションが約束される場合、こうした一時的なメッセージキャプチャおよび配信は永続的なものとなる。トランザクションが打ち切られる場合、こうした一時的演算は、それが決して発生しなかったかのように破棄される。他のトランザクション資源マネージャと同様に、ダイアログストアは、一時的なバッファ演算のためのトランザクション分離（例えば、キャプチャされるメッセージは、トランザクションの外部では不可視である）と、トランザクションマネージャの制御下でトランザクションが完了するトランザクション原子性とを提供しなければならない。

トランザクションのバッファリングにより、（障害または並行する活動に面しても正確な状態遷移を行う）正確なメッセージ交換アプリケーションの開発が単純になる。アプリケーションは、この機能を使用してメッセージ交換およびローカルのメッセージ処理を調整することができる。例えば、アプリケーションは、トランザクションの範囲内でメッセージを受信し、処理することがある。このメッセージ処理は、１つまたは複数のトランザクションデータベースの読取りおよび更新、ならびにトランザクション内に含まれるダイアログに対する１つまたは複数のメッセージの送出を含む可能性がある。トランザクションが打ち切られる場合、作業のすべては行われない。具体的には、一時的に送信されたメッセージが破棄され（すなわち、セッションパートナはこうした一時的結果を見ない）、受信したメッセージは依然として配信のために使用可能である。後者により、新しいトランザクションの範囲内でメッセージを処理することが可能となる。トランザクションが約束されるとき、受信したメッセージの削除や送信したメッセージのバッファリングを含むこの活動のすべてが永続的となる。正味の影響は、確実に１回メッセージ処理である。トランザクションバッファリングは、アプリケーションがこの機能を使用するか否かがそのセッションパートナのアプリケーションにとって完全に透過的であるという意味で、ローカルのダイアログ機能である。

例示される実施形態によれば、図２を参照して以下で説明するように、Ｓｅｎｄ（）２１０が呼び出されたとき、送信側エンドポイントで、メッセージがダイアログストア２６０内に一時的に配置される。トランザクションが約束される場合、メッセージがストア２６０にコミットされ、パートナのエンドポイントに送信するために使用可能となる。トランザクションが打ち切られた場合、メッセージは廃棄される。受信側では、Ｒｅｃｅｉｖｅ（）２１５（またはＤｅｌｅｔｅ）が呼び出されたとき、メッセージはダイアログストア２６０から一時的に削除される。トランザクションが約束される場合、メッセージはストア２６０から永久に削除される。トランザクションが打ち切られる場合、メッセージはストア２６０内にとどまり、再配信のために使用可能である。処理済み受信により、メッセージの確実に１回処理が可能となる。

トランザクション処理させるバッファリングはキューイングシステムの一般的な機能であるが、こうしたシステムは一般に永続ストアを必要とすることに留意されたい。ダイアログ２００は、ダイアログストア２６０の永続性の如何にかかわらず、こうした同一のトランザクションセマンティクスを提供し、すべての場合に同一のプログラムモデルを提供する。例えば、メモリ内ストアは、トランザクション資源マネージャとして参加することによってトランザクションセマンティクスを提供する。しかしダイアログ２００により、伝送機構および接続性特性、メッセージルーティング、並びにエンドポイント状態管理に関連する詳細を含む配置の詳細と、アプリケーションの実装とを分けて考えることが可能となる。

ダイアログ２００によって提供される別の機能は、任意選択のポイズンメッセージ機能である。前述のように、メッセージがトランザクション下で受信および処理され、トランザクションが打ち切られるとき、メッセージはダイアログストア２６０内にとどまり、アプリケーションに再配信するために使用することができる。場合によっては、トランザクションのアボートを引き起こす問題は、一時的なもの、例えばデッドロックによるタイムアウトであり、次の試行時に配信およびメッセージ処理が続く。所与のメッセージに対する配信の試行が繰り返しアボートを引き起こす場合、そのメッセージは「ポイズン」とみなされる。ダイアログ２００は、何回メッセージ配信がアボートするとメッセージがポイズンとみなされるかということを構成する方法を提供する。ポイズンメッセージが検出されたとき、アプリケーションに対してエラーが発生し、アプリケーションが正しい動作を行うまで、メッセージを処理する際の試行がそれ以上行われないように停止される。これにより、決して成功しない作業、または何らかの介入をしなければ成功しない作業をあえて試み、処理資源を浪費しないよう保証する。ポイズンメッセージ検出は、プロファイル（以下で説明する）を介して構成することができ、またはアプリケーションコードで記述することができる。

任意選択のプロファイルの機能は、名前付きの１組のダイアログを構成する選択肢を提供する。前述のように、バッファ割当、タイムアウト、ストアなどの、ダイアログの多数の構成が可能な機能が存在する。さらに、ダイアログ２００は、構成が可能なメッセージの配信の保証、例えばＡＬＯ、ＡＭＯ、およびＩＯを提供し、アプリケーションコードが、望むなら構成を通じて増加させることができる望ましい配信保証の最小レベルを独立に指定することができる。プロファイルは、共通ダイアログ設定をグループ化し、その設定を名前で参照する方法を提供する。さらに、ダイアログ２００実装により、管理者が各設定にわたって配置時間制御を有するように、アプリケーション構成ファイルを通じたプロファイルの選択が可能となる。ダイアログを作成または受諾するとき、アプリケーションは、名前によってプロファイルを参照し、プロファイル中で指定されるすべての設定を使用して、ダイアログ２００を作成する。設定は、アプリケーションプログラムの一部、コード、または他のプログラミングの構築として直接確立することができる。コードまたは他のプログラミング構成内の参照によって間接的にプロファイルをプログラムと関連付けることができ、それによってプロファイルの値を、アプリケーションプログラムとは無関係に設定することができる。直接的に確立されたプロファイルの値は、プロファイル参照によって間接的に設定されたプロファイルの値より優先される。

ダイアログ２００は、こうした機能および保証の組合せを互いに独立に提供するので、伝送制御プロトコル（ＴＣＰ）およびリモート手続き呼出し（ＲＰＣ）と類似の密結合プログラミングモデルから、データグラムおよびキューに類似の疎結合プログラミングモデルまでの任意の結合構成を満たすようにダイアログ２００を構成することができる。加えて、ダイアログ２００は、片方向対話、半２重（単一の要求／応答からより複雑なパターンまで）対話、最も複雑な全２重対話などの様々な２者メッセージ交換パターン（ＭＥＰ）を効率的にサポートする。したがって、ダイアログ２００により２者通信プログラミングモデルの統一が可能となる。

図２に、本発明の例示される実施形態によるダイアログ２００の動作の特徴を示す。ダイアログチャネルアプリケーションプログラミングインターフェース（ＡＰＩ）２２０が、アプリケーション２０５に対するアブストラクションとして提供される。前述のように、ダイアログ２００は、一続きのメッセージを定義するウェブサービス、例えば高信頼性メッセージ交換（ＷＳ−ＲＭ）などのメッセージ交換プロトコルを使用する。シーケンスは、セッション内の単一の方向の１組のメッセージを定義する。このような２つのシーケンスが組み合わされて、シーケンスが２つの通信者間の各方向となる１つのダイアログが形成される。チャネル２２０メソッドＳｅｎｄ（）２１０が呼び出されるとき、Ｓｅｎｄメソッド２１０に対するパラメータとして渡されるメッセージが、送信状態２５０に格納され、メッセージが送信された順番に従って、単調増加のメッセージシーケンス番号で一意的にスタンプされる。

メッセージ２５５は送信状態２５０にバッファリングされ、シーケンス中の個々のメッセージに関する状態が維持される。この時点で、これらのメッセージは状態２５０に「キャプチャ」されていると呼ばれ、Ｓｅｎｄ（）２１０はアプリケーションに返される。より具体的には、送信メソッド２１０は、パラメータとして１つのメッセージを受諾する。このメッセージが、シーケンス番号でスタンプされる送信バッファ２５０に渡され、その後で、または同時にストア２６０内に格納される。この時点で、メッセージが「キャプチャ」されているとみなされ、送信メソッド２１０は戻る。この呼出しを他のメッセージで反復することにより、メッセージ２５５のシーケンスまたは部分シーケンスが得られる。

ダイアログ状態２３５は、送信バッファ２５０および受信バッファ２４０を含む。ダイアログ状態２３５は、ダイアログ識別子、アプリケーションにより指定される保証、およびパートナのエンドポイントアドレスなどの不変の情報を管理および格納する。ダイアログ状態２３５はまた、次の発信送信シーケンス番号や肯定応答状態などのセッション情報も管理する。さらに、ダイアログＴＴＬ、タイムアウト、ストアの位置などの構成データがダイアログセッション状態２３５内に保持される。

メッセージがキャプチャされると、プロトコル部２７０は、キャプチャされたメッセージ、例えばメッセージ２７５の処理および送信、したがってポート２８５を通じて処理および送信が可能となる。ダイアログ２００に関するプログラミングモデルおよびランタイムの構造により、柔軟で効率的なエンドポイントの解決（ｒｅｓｏｌｕｔｉｏｎ）モデルが提供される。

このモデルは少なくとも、２つのエンドポイントを効率的に解決して高信頼性のメッセージ交換の実現を保証する。具体的には、プロトコル部２７０は、ダイアログ内の初期メッセージを配信して処理を行う前に、両方のエンドポイントがエンドポイント一意性を保証するのに十分な基準と、ダイアログ２００を介するメッセージの正確な相関と、その対応するセッションとを保持することを保証することができる。これは例えば、高々１回配信を保証するようにメッセージが単一のセッションパートナに高い信頼性をもって配信されることを保証するのに必要である。このエンドポイントの解決は、ダイアログ２００の作成者によって使用されるパートナアプリケーションを識別する識別子（例えば汎用資源識別子（ＵＲＩ））、ローカル構成、メッセージヘッダ中のルーティングデータ、中継点構成、およびターゲットアプリケーション構成を含む複数の因子に基づくことができる。

アプリケーションの実装２０５がダイアログエンドポイントの解決の詳細にかかわる必要はないことに留意されたい。ダイアログ２００に関する下部構造は、解決プロセスを実施して、開始側エンドポイントと協調し、開始側エンドポイントがセッションに対して一意的に選択されたピアエンドポイントであることを保証する。これは、必要に応じて行われ、アプリケーション実装２０５にとって透過的である。
メッセージ配信目標を達成することを確実にするためにダイアログに関する実行時のエンドポイント解決が提供される一方、広範なネットワーク構成において正しい実行を達成するために柔軟性が提供される。この機能は、拡張性、可用性、セキュリティ（ファイアウォールなど）、および性能の要件に対処するために、様々な構成でのアプリケーションの柔軟な配置をサポートする。サービス配置の構成は、例えばアプリケーションファーム（例えばスケールアウトレプリカ）やアプリケーションパーティション（例えば顧客番号または地理的領域による区分処理）を含む。アプリケーションファームおよびパーティションは、別々に使用することができ、または一緒に使用することができる。例えば、アプリケーションパーティションへのデータ依存ルーティングを使用するようにアプリケーションを配置することができる。アプリケーションパーティションは、アプリケーションサーバのファームからなる。

プロトコル部２７０はまた、上述のエンドポイント解決を実施するための方法とは無関係に、アプリケーション２０５によってどの種類のエンドツーエンド保証およびローカルの機能が指定されたかを判定する。アプリケーション２０５がＡＬＯ保証を指定した場合、プロトコル部２７０は、メッセージ２７５が適切に受信されたという肯定確認応答を受信側（図示せず）から受信するまで、ダイアログの送信バッファ２５０内にメッセージ２７５のコピーを保持する。プロトコル部２７０が受信側から肯定確認応答を受信したとき、プロトコル部２７０は、そのことをセッション状態２３５内に記録し、送信バッファ２５０からメッセージを削除する。プロトコル部２７０が指定の再試行タイムアウト内に肯定確認応答を受信しなかった場合、プロトコル部は、同一のメッセージシーケンス番号を有する同一のメッセージ２７５のコピーを再送信する。ダイアログ２００は、何回かこのプロセスを反復することができ、ネットワーク上でさらに輻輳が発生するのを回避するために再試行タイマバックオフ法を使用することができる。肯定応答がメッセージＴＴＬによって指定される時間枠内に受信されない場合、エラーが発生し、保証を満たすことができないことが送信側アプリケーション２０５に通知される。

ダイアログメッセージ２８０を受信したとき、プロトコル部２７０は、メッセージを受信バッファ状態２４０内にコピーする。プロトコル部２７０はまた、次の予想されるメッセージシーケンス番号を記録する。メッセージ２８０を受信した場合、ダイアログ２００の保証がＡＭＯを含むとき、到着メッセージ２８０のメッセージシーケンス番号は、受信バッファ状態２４０内に前述のように格納される先に到着したメッセージシーケンス番号の組と比較される。この組が合致するシーケンス番号を既に含む場合、メッセージ２８０は複製とみなされて廃棄される。そうでない場合、後の参照のためにメッセージ２８０がローカルの受信バッファ２４０内に配置される。

保証がＡＬＯを含む場合、プロトコル部２７０は、メッセージ２８０の受信時に順序付けられていない完全に選択的な肯定確認応答をダイアログに関するパートナのエンドポイントに送信する。この確認応答は、セッションでそれまでに受信したすべてのメッセージのシーケンス番号を含まなければならない。１組のシーケンス範囲を含む略記法を使用して、メッセージ空間を節約することができる。

指定された保証がＩＯを含まない場合、メッセージ２８０は、受信チャネル２２０を介して受信側アプリケーション２０５に「配信」するために即座に使用可能にされる。具体的には、メッセージが受信のために使用可能であるという通知がアプリケーション２０５に送信される。次いでアプリケーション２０５は受信側２１５を呼び出し、その結果、配信のために使用可能な次のメッセージがアプリケーション２０５に渡され、これは「配信」が行われたと呼ばれる。

保証としてＩＯが指定された場合、到着メッセージ２８０のシーケンス番号が、次の予想されるシーケンス番号と比較される。シーケンス番号が次の予想されるシーケンス番号より小さい場合、到着メッセージ２８０が廃棄される。それらが合致する場合、到着メッセージ２８０は即座に、受信側アプリケーション２０５に配信することができるようにされ、次の予想されるシーケンス番号が、次の欠落メッセージの番号に設定される。シーケンス番号が次の予想されるシーケンス番号よりも大きい場合、動作は、保証としてＡＬＯ指定されるか否かに左右される。ＡＬＯの保証が指定されない場合、メッセージ２８０は即座に、受信側アプリケーション２０５に配信することを可能にされ、次の予想されるシーケンス番号が、到着メッセージ２８０のシーケンス番号よりも１つ大きい番号に設定される。ＡＬＯの保証が指定される場合、メッセージ２８０は受信側アプリケーション２０５に配信することが可能とはならないものの、受信バッファ２４０内にとどまる。したがって、それらが合致しない場合、小さいシーケンス番号の少なくとも１つの他のメッセージを受信していないと推定される。そのような欠落した小さい番号のメッセージすべてが到着したとき、メッセージの連続的範囲が、適切なシーケンスとして受信側アプリケーションに配信するのに使用可能となり、次の予想されるシーケンス番号が、次の欠落メッセージの番号に設定される。

前述のように、メッセージが受信側アプリケーション２０５に配信することが可能なとき、受信側アプリケーション２０５に対して通知が発行される。次いで受信側アプリケーションは、ダイアログチャネル２２０上でＲｅｃｅｉｖｅ（）メソッド２１５を呼び出し、使用可能な次のメッセージの配信を受諾する。Ｒｅｃｅｉｖｅ（）は、使用可能な各メッセージを受信するために複数回呼び出すことができる。順序を確実にするために、イベント通知が逐次配信される。したがって、メッセージがアプリケーション２０５に配信することが可能なとき、ダイアログ２００イベントと共に先に登録されたアプリケーションコードを呼び出すことにより、単一のイベント通知がアプリケーション２０５に配信される。アプリケーションコードに対するその呼出しが返るまでは、他のメッセージが配信することが可能な場合であっても、そのアプリケーションコードへの他の呼出しは行われない。そのアプリケーションコード内で、アプリケーション２０５は通常、Ｄｉａｌｏｇ Ｒｅｃｅｉｖｅ（）２１５を呼び出して、次の使用可能なメッセージを受信する。

やはり前述のように、Ｓｅｎｄ（）２１０が呼び出されたとき、現在送信バッファ２５０中にあるメッセージ数が、指定のバッファ割当と比較される。現在送信バッファ２５０中にあるメッセージ数がその割当を超過する場合、空間が使用可能となるまで、または送信タイムアウトとなるまで、イベントに対して呼出し元Ｓｅｎｄ（）２１０がブロックされる。送信バッファ２５０内の空間が利用可能となったとき、バッファは、メッセージの送信を待機する何らかの呼出し元が存在するか否かをチェックされる。そうである場合、呼出し元Ｓｅｎｄ（）２１０がブロック解除され、再びメッセージを送信することができる。

メッセージバッファ２５０および２４０、チャネル２２０、ならびにプロトコル部２７０内を含むダイアログ２００に関するすべての状態を、ダイアログストア２６０内に同時に保持することができる。ダイアログストア２６０は、最新の情報を含むべきである。これにより、ダイアログ状態２３５がダイアログストア２６０の永続性プロパティを確実に有することとなり、すべての機能が、使用中のストア２６０にかかわりなく機能することが可能となる。例えば、メッセージ２８０を受信バッファ２４０内に配置することには、ストア２６０へのディスク書込みが関係する可能性がある。保証を実現するために、確認応答は、メッセージがストア２６０内に記録された後でないと送信されない。これにより、例えば、送信側または受信側がメッセージのコピーを常に確実に有するようにされる。同様に、送信側では、Ｓｅｎｄ（）２１０は、メッセージがストア２６０内に記録された後でなければ完了しない。

前述のように、ダイアログストア２６０はプラグが可能なストアであり、これは非常に高い柔軟性によって、永続性、性能、自律性、および管理の目標に合致させることを可能となる。例えば、アプリケーションメモリ内のすべての状態を保持するメモリダイアログストアの実装、別々の専用デーモンプロセスのメモリ内の状態を保持する高速ダイアログストアの実装、または構造化照会言語（ＳＱＬ）サーバなどの永続データベースストアの実装を含む単一のフレームワーク内の複数のストアのうちの１つからストア２６０を選択することができる。同一のアプリケーション２０５内の異なるダイアログが、異なるストアを使用することができる。さらに、本発明により、いくつかのダイアログストア２６０をローカルのコンピュータノードまたは別のノード上で動作するように構成することも可能となる。

ダイアログ２００はアプリケーション２０５の代わりにエージェントとして動作するので、アプリケーション２０５は、接続性が変化することとは別におかれる。これにより、例えば、アプリケーションが実行され、いくつかのメッセージを送受信し、次いで他のエンドポイントが応答し、さらには待機して利用可能とする必要ない状態で終了するようなバッチスタイルの処理が可能となる。さらに、様々な配信の保証およびローカルの機能、例えばメッセージまたはセッションＴＴＬに合致することだけに依存する非常に柔軟にメッセージ配信をスケジューリングすることができる。例えば、配信の保証に応じて、ダイアログ２００はピークメッセージの負荷をある期間に分散することができ（負荷平衡）、あるいは、アプリケーション２０５とは独立に、メッセージ配信をよりコスト効率の良い時間にシフトし、資源が使用可能となるまで待機し、メッセージまたはダイアログの優先順位を調節することなどを行う。加えて、ストア２６０は、アプリケーション２０５に対してシャットダウンの機能および再始動の機能を提供する。バッチ処理、スケジューリング、ならびにアプリケーションのシャットダウンの機能および再始動の機能により、システムの可用性および拡張性が向上する。

加えて、前述のように、アプリケーション２０５は、Ｓｅｎｄ（）２１０およびＲｅｃｅｉｖｅ（）２１５演算をダイアログバッファ２５０および２４０に関して処理することを指定することができる。これにより、アプリケーションは、例えばメッセージを受信し、１つまたは複数のダイアログに関するいくつかのメッセージを送信し、すべて単一のトランザクション内にあるアプリケーションテーブルを更新することが可能となる。このようなトランザクションの使用法においては、これは単にローカルの概念であって他のエンドポイントに搬送したりされない。

ダイアログはまた、実行中の障害回復も提供するが、これは、アプリケーションの実装を使用せずに、多くの障害２６５を自動的に回復（マスク）させることができる。アプリケーションは、ダイアログ２００の寿命の間にアサートされた特性（すなわち、アサートされた保証および機能）を受信することができる。ダイアログ２００またはプロトコル部２７０についての下部構造により、アサートされる特性がもはや満たされないと判定された場合、主要なアプリケーションコードと、またはアプリケーション２０５とさえ無関係に動作する帯域外の訂正を考慮して、ダイアログは障害状態に配置され、障害イベントが生成される。障害２６５を訂正（修復）することができる場合、ダイアログをサービスに戻すことができる。回復不能な障害、すなわち修復することができない障害は、ダイアログ２００およびアプリケーション通知が終了する結果となる可能性がある。このような設計は、高信頼性のアプリケーションの開発の基礎となる「フェイルファースト（ｆａｉｌ−ｆａｓｔ）」モデルに準拠する。

致命的でない障害には、メッセージの破壊、紛失、重複、または遅延、伝送機構およびネットワークの障害、プロセス障害、中継点障害、ならびにシステム障害を含めることができる。前述のように、ダイアログ２００がアプリケーションにアブストラクションを提供し、それ自体のバッファおよびストアを維持するので、ダイアログ２００は、断続的に接続されるアプリケーションおよび環境もサポートする。ダイアログはまた、ネットワークトポロジに対する変化、再ネゴシエーションされたセキュリティコンテキスト、またはエンドポイントの再配置などの環境の変化に適合することもできる。

ダイアログ２００はそれ自体で、例えばメッセージを再送信することよってこうした障害を自動的に修復するよう企図することができる。これに代えて、またはこれとともに、ダイアログ２００は、第３者、例えばシステムオペレータまたは診断用のコードに要求を送信して、障害を修復する際の助けを求めることができる。この助けは例えば、ネットワーク内の断線を修復する単純な人間による介入とすることができ、または場合によっては自動修復プロセスとすることができる。いずれの場合も、障害を修復した後は、ダイアログ２００はメッセージの送信を続行することができる。これらを他の可用性の機能と組み合わせることにより、長寿命のダイアログが可能となる。しかし、ダイアログ２００または何らかの他の第３者の介入によって障害を解決することができない場合、ダイアログを開始したアプリケーション２０５に対してエラーメッセージを生成すべきである。

アプリケーションプロセス障害および再始動にわたってダイアログを維持することを可能にするダイアログストア２６０を使用するようにアプリケーションを構成することができる。加えて、何らかのストア２６０により、システム障害および再始動を許容することができる。

ドメイン固有の障害ハンドラと前述の基本メッセージ再送信サポートとの組合せにより、他の伝送障害を自動的に処理することができる。その例には、セキュリティ証明書（ｃｒｅｄｅｎｔｉａｌ）またはポリシー満了の結果として生じる障害が含まれる。保護セッション上で送信されたメッセージに、証明書満了のために障害が発生した場合、ダイアログ２００は、セキュリティ証明書を再ネゴシエーションし、ダイアログの障害をクリアすることができる。ダイアログの処理が再開したとき、バッファリングされたメッセージは、標準の再試行プロセスによって更新された証明書と共に再送信される。

やはり前述のように、ダイアログ２００に関する設計および対応する下部構造により、ランタイムが実行環境の変化にダイアログ２００を動的に適合させることが可能となる。これは、アプリケーション実装にとって透過的に実現することができ、長寿命のダイアログおよび高いレベルで使用可能なアプリケーションを可能とする。

障害ハンドラ（プラグすることが可能）と、送信および配信の再試行と、障害および修復モデルとの上述の組合せにより、ダイアログは多くの環境変化に適合することが可能となる。こうした変化には、限定はしないが、ポリシーの変化（例えばメッセージプライバシー）、プロトコルの変化（例えば新しいセキュリティプロトコルのサポート）、ネットワークトポロジの変化（例えばルータまたはファイアウォールの追加または取外し）、負荷の増大に対処するための配置アプリケーションの変更（例えば、アプリケーションファームおよび／またはパーティションの導入）、およびダイアログのエンドポイントと関連する状態の再配置（例えば、災害回復）が含まれる。これにより、非常に小規模から非常に大規模までをサポートするスケーラブルな配置の選択が可能となる。例えば、ダイアログ２００は、やはりアプリケーションの実装にとって透過的なスケールアップ、スケールアウト、アプリケーション複製、または区分化をサポートする。

図３に、ダイアログ２００のライフサイクルおよび状態を示す。ダイアログ２００は、アクティブ３２０または非アクティブ３６０の２つの主状態の一方とすることができる。ダイアログ２００がアクティブ３２０である場合、ダイアログチャネルオブジェクト２２０がメモリ内にあり、そうでない場合、ダイアログ２００が非アクティブ３６０であり、ダイアログ２００はダイアログストア２６０内にのみ存在する。管理システム資源は、手動または自動で行うことのできる非アクティブ化３５０および再アクティブ化３４０プロセスによって行われる。例えば、非アクティブ化３５０は、アプリケーションがＤｉｓｐｏｓｅを呼び出す場合に手動で行うことができ、またはメッセージがダイアログチャネル上で交換されない場合に一定期間が非活動で経過する非活動時間のために自動的に行うことができる。このようなチャネルを非アクティブ化することが可能となり（対応するオブジェクトがメモリから解放され）、したがって他の事柄のためにメモリ資源が解放される。

再アクティブ化３４０は、アプリケーションがダイアログマネージャ（図示せず）にチャネルを要求する場合に手動で行うことができ、または新しいメッセージがセッションに到着した場合に自動的に行うことができる。ダイアログ作成３１０の間に、ダイアログマネージャによって各ダイアログに固有のＩＤが割り当てられる。このＩＤは、再アクティブ化３４０要求時にアプリケーション２０５によってダイアログマネージャに渡され、ダイアログマネージャはＩＤを使用してダイアログ状態の位置を突き止め、チャネルを再開する。非アクティブ化３５０および再アクティブ化３４０のインターフェースにより、システムが、発信メッセージの送信または着信メッセージの処理のためにアクティブに使用されていないダイアログに関連する処理資源を制限することが可能となる。これにより、下部構造が、ダイアログストア２６０に関連する資源以外の関係する資源を再利用することが可能となる。さらに、この設計により、優先順位または資源可用性に基づくメッセージ送信のスケジューリング、より効率的な送信のためのメッセージのバッチ処理、優先順位または資源可用性に基づくメッセージ配信のスケジューリング、およびより効率的な処理のためのメッセージ配信のバッチ処理を含む資源スケジューリングが可能となる。

ダイアログの作成３１０は、ダイアログマネージャによって制御され、作成３１０機能を呼び出すアプリケーションによって開始することができる。あるいは、メッセージ交換システムは、新しいダイアログが必要であることを示す別のエンドポイントからのメッセージを受信した後に、ダイアログ作成３１０を開始することができる。この場合、システムは、ダイアログが要求されたことをアプリケーション２０５に通知する。次いでアプリケーション２０５は、ダイアログマネージャ上のＡｃｃｅｐｔメソッドを呼び出して、ダイアログ要求を受諾し、ダイアログ作成３１０を引き起こすことができ、またはダイアログマネージャ上のＲｅｊｅｃｔメソッドを呼び出して、ダイアログ要求を拒絶することができる。ダイアログマネージャはまた、ティアダウン（Ｔｅａｒｄｏｗｎ）３３０も制御し、いくつかの理由でそれを開始することができる。１つの理由は、セッションが首尾よく完了し、すなわち両側が送信を終了し、メッセージがもう残っていないということであろう。ティアダウン３３０を制御する別の理由は、ダイアログ２００が終了し、例えばアプリケーションがＴｅｒｍｉｎａｔｅ（）関数を呼び出し、またはパートナのエンドポイントから終了を求める指示を受信したことかもしれない。一方の側がダイアログを終了したとき、これを示すためにメッセージが他方の側に送信される。このメッセージに対する信頼性はなく、単に、ダイアログが終了したことを他方の側に伝えるための試行である。終了は、ダイアログのセッションを介してそれ以上のメッセージが交換されることがないことを示唆する。

本発明の説明では、ダイアログを両方のセッションエンドポイントのパートナでアプリケーションのメッセージを送信および受信することができる二重通信機構と定義するが、別の例示される実施形態には、単信モデルが含まれる。実施形態によれば、一方のセッションエンドポイントは、アプリケーションのメッセージ送信のみを行い、そのパートナのエンドポイントからアプリケーションのメッセージを受信せず、セッションエンドポイントのパートナは、アプリケーションのメッセージの受信のみを行い、アプリケーションのメッセージを送信しない。ダイアログにおいては、同一の構成が可能な保証、および構成が可能なローカルのエンドポイントの機能が適用される。実装は、送信側エンドポイントで受信バッファ２４０が不要であり、受信側エンドポイントで送信バッファ２５０が不要である点で異なる。

本発明の範囲内の実施形態はまた、コンピュータ実行可能命令またはデータ構造を搬送し、または格納するためのコンピュータ読取可能な媒体も含む。このようなコンピュータ読取可能な媒体は、汎用コンピュータまたは専用コンピュータでアクセスすることができる入手可能などんな媒体でもよい。例えば限定はしないが、そのようなコンピュータ読取可能な媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク記憶媒体、磁気ディスク記憶媒体または他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形態の所望のプログラムコード手段を搬送または記憶するのに使用することができ、かつ汎用コンピュータまたは専用コンピュータでアクセスすることができる他のどんな媒体も含めることができる。情報がネットワークまたは他の通信接続（ハードワイヤード、無線、あるいはハードワイヤードと無線の組合せ）を介してコンピュータに転送または供給されるとき、コンピュータはその接続をコンピュータ読取可能な媒体として適切に認識する。したがって、任意のそのような接続が、コンピュータ読取可能な媒体と呼ぶのは適切である。上記の組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。例えばコンピュータ実行可能命令は、ある機能または機能の集まりを汎用コンピュータ、専用コンピュータ、または専用処理装置に実行させる命令およびデータを含む。

図４および以下の議論は、本発明を実施することができる適切なコンピューティング環境の簡潔で一般的な説明を与えるものである。必須ではないが、ネットワーク環境内のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況の下で本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールが、本明細書で開示される方法のステップを実行するプログラムコード手段の例を表す。このような実行可能命令の特定のシーケンス、または関連するデータ構造が、このようなステップで記述される機能を実施する対応する行為の例を表す。

パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で本発明を実施できることを当業者は理解されよう。本発明は、通信ネットワークを介して（ハードワイヤードリンク、無線リンク、あるいはハードワイヤードリンクと無線リンクの組合せによって）リンクされるローカル処理装置およびリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置のどちらにも置くことができる。

図４を参照すると、本発明を実装するための例示のシステムは、従来型コンピュータ４２０の形態の汎用コンピューティング装置を含む。従来型コンピュータ４２０は、処理装置４２１と、システムメモリ４２２と、システムメモリ４２２を含む様々なシステム構成要素を処理装置４２１に結合するシステムバス４２３とを含む。システムバス４２３は、メモリバスまたはメモリコントローラと、周辺バスと、様々なバスアーキテクチャのいずれかを用いるローカルバスとを含むいくつかのタイプのバス構造のいずれでもよい。システムメモリは、読取り専用メモリ（ＲＯＭ）４２４およびランダムアクセスメモリ（ＲＡＭ）４２５を含む。始動中などにコンピュータ４２０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４２６を、ＲＯＭ４２４内に格納することができる。

コンピュータ４２０はまた、磁気ハードディスク４３９を読み書きするための磁気ハードディスクドライブ４２７と、取外し可能磁気ディスク４２９を読み書きするための磁気ディスクドライブ４２８と、ＣＤ−ＲＯＭや他の光媒体などの取外し可能光ディスク４３１を読み書きするための光ディスクドライブ４３０とを含むことができる。磁気ハードディスクドライブ４２７、磁気ディスクドライブ４２８、および光ディスクドライブ４３０は、それぞれハードディスクドライブインターフェース４３２、磁気ディスクドライブインターフェース４３３、および光ドライブインターフェース４３４によってシステムバス４２３に接続される。ドライブと、それに関連するコンピュータ読取可能な媒体とにより、コンピュータ４２０に対して、コンピュータ実行可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性記憶が提供される。本明細書で説明する例示される環境では、磁気ハードディスク４３９、取外し可能磁気ディスク４２９、および取外し可能光ディスク４３１を使用するが、磁気カセット、フラッシュメモリカード、デジタルバーサタイルディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなど、他のタイプのデータ記憶用コンピュータ読取可能な媒体も使用することができる。

オペレーティングシステム４３５、１つまたは複数のアプリケーションプログラム４３６、他のプログラムモジュール４３７、およびプログラムデータ４３８を含む１つまたは複数のプログラムモジュールを有するプログラムコード手段を、ハードディスク４３９、磁気ディスク４２９、光ディスク４３１、ＲＯＭ４２４、またはＲＡＭ４２５上に格納することができる。ユーザは、キーボード４４０、ポインティングデバイス４４２、あるいはマイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどの他の入力装置（図示せず）を介してコンピュータ４２０にコマンドおよび情報を入力することができる。上記およびその他の入力装置はしばしば、システムバス４２３に結合されたシリアルポートインターフェース４４６を介して処理装置４２１に接続される。あるいは、入力装置は、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースによって接続することもできる。モニタ４４７または他のディスプレイ装置もまた、ビデオアダプタ４４８などのインターフェースを介してシステムバス４２３に接続される。モニタに加えて、パーソナルコンピュータは一般に、スピーカやプリンタなどの他の周辺出力装置（図示せず）を含む。

コンピュータ４２０は、リモートコンピュータ４４９ａおよび４４９ｂなどの１つまたは複数のリモートコンピュータに対する論理接続を用いて、ネットワーク環境で動作することができる。リモートコンピュータ４４９ａおよび４４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般にはコンピュータ４２０に関する前述の要素のうちの多くまたはすべてを含むが、図４にはメモリ記憶装置４５０ａおよび４５０ｂと、それに関連するアプリケーションプログラム４３６ａおよび４３６ｂだけを示してある。図４に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５１および広域ネットワーク（ＷＡＮ）４５２を含む。これらは限定的なものではなく、単に例としてここで示したに過ぎない。このようなネットワーキング環境は、オフィス全体または企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。

ＬＡＮネットワーキング環境で使用するとき、コンピュータ４２０は、ネットワークインターフェース／アダプタ４５３を介してローカルネットワーク４５１に接続される。ＷＡＮネットワーキング環境で使用するとき、コンピュータ４２０は、モデム４５４、無線リンク、あるいはインターネットなどの広域ネットワーク４５２を介して通信を確立するための他の手段を含むことができる。モデム４５４は内蔵でも外付けでもよく、シリアルポートインターフェース４４６を介してシステムバス４２３に接続される。ネットワーク環境では、コンピュータ４２０に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。ここで示したネットワーク接続は例示的なものであって、広域ネットワーク４５２を介して通信を確立する他の手段も使用できることを理解されよう。

本発明の精神または不可欠な特徴から逸脱することなく、本発明を他の特定の形態で実施することができる。記載の実施形態は、すべての点において例示的なものに過ぎず、限定的ではないとみなすべきである。したがって、本発明の範囲は、上記の説明によってではなく、特許請求の範囲によって示される。特許請求の範囲の等価の意味および範囲内にあるすべての変更は、その範囲内に包含されるべきである。

本発明の例示される実施形態に従ってメッセージを送信および受信するための高信頼性メッセージ交換スタックを示す図である。 本発明の例示される実施形態によるメッセージフレームワークを示す図である。 本発明の例示される実施形態によるアプリケーションと伝送機構間のリンクのライフサイクルを示す図である。 本発明に適した動作環境を与える例示されるシステムを示す図である。

符号の説明

１００ａ、１００ｂ 高信頼性メッセージ交換スタック
１０５、１８５ アプリケーション
１１５ メッセージ
１２０、１８０ 高信頼性メッセージ交換フレームワーク
１３５ 中継点
１４０ データグラムメッセージ交換層
１４５、１５５、１７０ 伝送機構
１６０、１６５ 伝送機構
１９０ セッション状態（送信）バッファ
１９１ メッセージ
１９２ 肯定応答メッセージ
１９５ セッション状態（受信）バッファ
２００ ダイアログ
２０５ アプリケーション
２２０ ダイアログチャネル
２３５ ダイアログ状態
２４０ 受信バッファ
２５０ 送信バッファ
２６０ ダイアログストア
２６５ 障害
２７０ プロトコル部
２７５ メッセージ
２８０ ダイアログメッセージ
２８５ ポート
３１０ ダイアログ作成
４２０ 従来型コンピュータ
４２１ 処理装置
４２２ システムメモリ
４２３ システムバス
４２４ 読取り専用メモリ（ＲＯＭ）
４２５ ランダムアクセスメモリ（ＲＡＭ）
４２６ 基本入出力システム（ＢＩＯＳ）
４２７ 磁気ハードディスクドライブ
４２８ 磁気ディスクドライブ
４２９ 取外し可能磁気ディスク
４３０ 光ディスクドライブ
４３１ 取外し可能光ディスク
４３２ ハードディスクドライブインターフェース
４３３ 磁気ディスクドライブインターフェース
４３４ 光ドライブインターフェース
４３５ オペレーティングシステム
４３６、４３６ａ、４３６ｂ アプリケーションプログラム
４３７ 他のプログラムモジュール
４３８ プログラムデータ
４３９ 磁気ハードディスク
４４０ キーボード
４４２ ポインティングデバイス
４４６ シリアルポートインターフェース
４４７ モニタ
４４８ ビデオアダプタ
４４９ａ、４４９ｂ リモートコンピュータ
４５０ａ、４５０ｂ メモリ記憶装置
４５１ ローカルエリアネットワーク（ＬＡＮ）
４５２ 広域ネットワーク（ＷＡＮ）
４５３ ネットワークインターフェース／アダプタ
４５４ モデム

Claims (47)

1. １つまたは複数のメッセージ伝送機構をサポートするメッセージ交換システムにおいて、所定のメッセージ伝送機構を開発時に指定せずに、実行時に使用される前記所定のメッセージ伝送機構とは無関係に、実行時に満たすべき１つまたは複数のエンドツーエンドメッセージの配信の保証を指定することを可能にする単一のプログラミングモデルを提供することによってアプリケーション開発を簡略化する方法であって、
   １つまたは複数のメッセージを送信および受信するのに使用可能な１つまたは複数のメッセージ伝送機構を介してメッセージを交換するための送信演算および受信演算を抽象化するメッセージチャネルインターフェースを定義する動作と、
   単一のプログラミングモデル内で使用するために、前記１つまたは複数の使用可能メッセージ伝送機構を開発時に指定することなく、前記１つまたは複数の使用可能なメッセージ伝送機構とは無関係に実行時に各々指定することができる複数のエンドツーエンドメッセージの配信の保証を定義する動作であって、前記複数のメッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序ごと送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含む動作と
   を備えたことを特徴とする方法。
2. 複数のローカルの高信頼性メッセージの機能を定義する動作であって、前記単一のプログラミングモデル内で使用するために前記複数のローカルの高信頼性メッセージの機能を選択することができ、前記複数のローカルの高信頼性メッセージの機能は、セッション状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのうち少なくとも１つを含む動作をさらに備えたことを特徴とする請求項１に記載の方法。
3. セッション状態ストレージの前記ローカルの高信頼性メッセージの機能は、プラグが可能なストアを含むことを特徴とする請求項２に記載の方法。
4. 前記ストアは、メモリ内ストレージ、ディスク上の永続ストレージ、またはデーモンプロセスストレージのうち少なくとも１つを含むことを特徴とする請求項３に記載の方法。
5. 前記ストアは、前記定義された複数のエンドツーエンドメッセージの配信の保証のうち１つまたは複数を指定するアプリケーションのローカルにあることを特徴とする請求項４に記載の方法。
6. 前記ストアは、前記定義された複数のエンドツーエンドメッセージの配信の保証のうち１つまたは複数を指定するアプリケーションのリモートにあることを特徴とする請求項４に記載の方法。
7. 前記ローカルの高信頼性メッセージの機能は、最大メッセージサイズと共に前記システムによってバッファリングされ、メッセージが消費することができる最大スペースを制限する最大メッセージ数を定義するバッファ割当をさらに含むことを特徴とする請求項２に記載の方法。
8. 前記ローカルの高信頼性メッセージの機能は、前記バッファ割当に従って必要なバッファ空間を使用できない場合、送信タイムアウトが満了した後にメッセージ送信機能のブロックを解除する送信タイムアウトをさらに含むことを特徴とする請求項７に記載の方法。
9. 前記ローカルの高信頼性メッセージの機能は、最大メッセージサイズと共に指定のメッセージ数に対して十分なバッファ空間を確保するバッファ割当をさらに含むことを特徴とする請求項２に記載の方法。
10. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージの送信が、低い優先順位のメッセージよりも優先されることを特徴とする請求項２に記載の方法。
11. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージの配信が、低い優先順位のメッセージよりも優先されることを特徴とする請求項２に記載の方法。
12. 処理済みメッセージバッファリングの前記ローカルの高信頼性メッセージの機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項２に記載の方法。
13. 前記ローカルの高信頼性メッセージの機能は、メッセージを配信不能とみなす前にメッセージ配信をアボートしなければならない回数であって構成が可能な数をさらに含むことを特徴とする請求項２に記載の方法。
14. 前記エンドツーエンドメッセージの配信の保証およびローカル機能によって定義されるメッセージの構成の選択肢を含む固有の１組を提供する１組のプロファイルによってメッセージ交換特性の定義が可能なことを特徴とする請求項２に記載の方法。
15. １つまたは複数のメッセージ伝送機構をサポートするメッセージ交換システムにおいて、所定のメッセージ伝送機構を開発時に指定せず、前記所定のメッセージ伝送機構を実行時に選択する際に使用するために１つまたは複数のエンドツーエンド配信保証を指定することを可能にする単一のプログラミングモデルを提供することによってアプリケーション開発を簡略化する方法であって、
    前記１つまたは複数のメッセージ伝送機構を介してメッセージを交換するためにメッセージチャネルインターフェースを抽象化するステップと、
    前記単一のプログラミングモデル内で使用するために複数のエンドツーエンドメッセージの配信の保証のうち１つまたは複数をアプリケーション開発者が指定することを可能にするステップであって、当該指定されるエンドツーエンド配信保証は、開発時にいずれのメッセージ伝送機構も指定することなく、実行時に適切なメッセージ伝送機構を選択する際に使用され、前記複数のメッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序ごと送信メッセージ配信、およびメッセージ生存期間のうち少なくとも１つを含むステップと
    を備えたことを特徴とする方法。
16. アプリケーション開発者が、複数のローカルの高信頼性メッセージの機能のうち１つまたは複数を指定することを可能にするステップであって、前記複数のローカルの高信頼性メッセージの機能の各々は、前記単一のプログラミングモデル内で使用するために選択することができ、前記複数のローカルの高信頼性メッセージの機能は、セッション状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのうち少なくとも１つを含むステップをさらに備えたことを特徴とする請求項１５に記載の方法。
17. 前記セッション状態ストレージのローカルの高信頼性メッセージの機能は、プラグが可能なストアを含むことを特徴とする請求項１６に記載の方法。
18. 前記ストアは、メモリ内ストレージ、ディスク上の永続ストレージ、またはデーモンプロセスストレージのうち少なくとも１つを含むことを特徴とする請求項１７に記載の方法。
19. 前記ローカルの高信頼性メッセージの機能は、最大メッセージサイズと共に前記システムによってバッファリングされる最大メッセージ数を定義するバッファ割当をさらに含むことを特徴とする請求項１６に記載の方法。
20. 前記ローカルの高信頼性メッセージの機能は、前記バッファ割当が満たされた場合、前記送信タイムアウトが満了した後に前記送信機能のブロックを解除する送信タイムアウトをさらに含むことを特徴とする請求項１９に記載の方法。
21. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に送信されることを特徴とする請求項１６に記載の方法。
22. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に受信されることを特徴とする請求項１６に記載の方法。
23. 処理済みメッセージバッファリングの前記ローカルの高信頼性メッセージの機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項１６に記載の方法。
24. 前記ローカルの高信頼性メッセージの機能は、メッセージを配信不能とみなす前にメッセージ配信をアボートしなければならない回数を構成する手段をさらに含むことを特徴とする請求項１６に記載の方法。
25. 前記エンドツーエンドメッセージの配信の保証およびローカル機能によって定義されるメッセージ構成の選択肢を含む固有の１組を提供する１組のプロファイルによってメッセージ配信特性の定義が可能なことを特徴とする請求項１６に記載の方法。
26. １つまたは複数のメッセージ伝送機構をサポートするメッセージ交換システムにおいて、所定のメッセージ伝送機構を開発時に指定せずに、実行時に前記所定のメッセージ伝送機構を選択する際に使用するために１つまたは複数のエンドツーエンドメッセージの配信の保証を指定することを可能にする単一のプログラミングモデルを提供することによってアプリケーション開発を簡略化する方法を実施するコンピュータ実行可能命令を格納する１または複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
    １つまたは複数のメッセージ伝送機構を介してメッセージを交換するための送信演算および受信演算を抽象化するメッセージチャネルインターフェースを定義する動作と、
    単一のプログラミングモデル内で使用するために、適切なメッセージ伝送機構を開発時に指定せずに、前記適切なメッセージ伝送機構を実行時に選択する際に使用すべき複数のエンドツーエンドメッセージの配信の保証を定義する動作であって、前記複数のメッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序ごと送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含む動作と
    を備えたことを特徴とするコンピュータプログラム製品。
27. 複数のローカルの高信頼性メッセージの機能を定義する動作をさらに備え、前記複数のローカル高信頼性メッセージ交換機能の各々は、前記単一のプログラミングモデル内で使用するために選択することができ、前記複数のローカルの高信頼性メッセージの機能は、セッション状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのうち少なくとも１つを含むことを特徴とする請求項２６に記載のコンピュータプログラム製品。
28. 前記セッション状態ストレージのローカルの高信頼性メッセージの機能は、プラグが可能なストアを含むことを特徴とする請求項２７に記載のコンピュータプログラム製品。
29. 前記ストアは、メモリ内ストレージ、ディスク上の永続ストレージ、またはデーモンプロセスストレージのうち少なくとも１つを含むことを特徴とする請求項２８に記載のコンピュータプログラム製品。
30. 前記ローカルの高信頼性メッセージの機能は、最大メッセージサイズと共に前記システムによってバッファリングされる最大メッセージ数を定義するバッファ割当をさらに含むことを特徴とする請求項２７に記載のコンピュータプログラム製品。
31. 前記ローカルの高信頼性メッセージの機能は、前記バッファ割当が満たされた場合に前記送信タイムアウトが満了した後に前記送信機能のブロックを解除する送信タイムアウトをさらに含むことを特徴とする請求項３０に記載のコンピュータプログラム製品。
32. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に送信されることを特徴とする請求項２７に記載のコンピュータプログラム製品。
33. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に受信されることを特徴とする請求項２７に記載のコンピュータプログラム製品。
34. 処理済みメッセージバッファリングの前記ローカルの高信頼性メッセージの機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項２７に記載のコンピュータプログラム製品。
35. 前記ローカルの高信頼性メッセージの機能は、メッセージを配信不能とみなす前にメッセージ配信をアボートしなければならない回数を構成する手段をさらに含むことを特徴とする請求項２７に記載のコンピュータプログラム製品。
36. 前記エンドツーエンドメッセージの配信の保証およびローカル機能によって定義されるメッセージ構成の選択肢を含む固有の１組を提供する１組のプロファイルによってメッセージ配信特性を定義することができることを特徴とする請求項２７に記載のコンピュータプログラム製品。
37. 所定のメッセージ伝送機構を開発時に指定せずに、実行時に前記所定のメッセージ伝送機構を選択する際に使用するために１つまたは複数のエンドツーエンドメッセージの配信の保証を指定することを可能にする単一のプログラミングモデルを提供することによってアプリケーション開発を簡略化する方法を実施するコンピュータ実行可能命令を格納する１または複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
    １つまたは複数のメッセージ伝送機構を介してメッセージを交換するためのメッセージチャネルインターフェースを抽象化するステップと、
    前記単一のプログラミングモデル内で使用するために複数のエンドツーエンドメッセージの配信の保証のうち１つまたは複数をアプリケーション開発者が指定することを可能にするステップであって、当該指定されるエンドツーエンドの配信の保証は、開発時にいずれのメッセージ伝送機構も指定することなく、実行時に適切なメッセージ伝送機構を選択する際に使用され、前記複数のメッセージの配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序ごと送信メッセージ配信、およびメッセージ生存期間のうち少なくとも１つを含むステップと
    を備えたことを特徴とするコンピュータプログラム製品。
38. アプリケーション開発者が、複数のローカルの高信頼性メッセージの機能のうち１つまたは複数を指定することを可能にするステップであって、前記複数のローカルの高信頼性メッセージの機能の各々は、前記単一のプログラミングモデル内で使用するために選択することができ、前記複数のローカルの高信頼性メッセージの機能は、セッション状態ストレージ、メッセージ生存期間、および処理済みメッセージバッファリングのうち少なくとも１つを含むステップをさらに備えたことを特徴とする請求項３７に記載のコンピュータプログラム製品。
39. 前記セッション状態ストレージのローカルの高信頼性メッセージの機能は、プラグが可能なストアを含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
40. 前記ストアは、メモリ内ストレージ、ディスク上の永続ストレージ、またはデーモンプロセスストレージのうち少なくとも１つを含むことを特徴とする請求項３９に記載のコンピュータプログラム製品。
41. 前記ローカルの高信頼性メッセージの機能は、最大メッセージサイズと共に、前記システムによってバッファリングされる最大メッセージ数を定義するバッファ割当をさらに含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
42. 前記ローカルの高信頼性メッセージの機能は、前記バッファ割当が満たされた場合に前記送信タイムアウトが満了した後に前記送信機能のブロックを解除する送信タイムアウトをさらに含むことを特徴とする請求項４１に記載のコンピュータプログラム製品。
43. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に送信されることを特徴とする請求項３８に記載のコンピュータプログラム製品。
44. 前記ローカルの高信頼性メッセージの機能は、優先順位の選択肢をさらに含み、高い優先順位のメッセージが、低い優先順位のメッセージよりも前に受信されることを特徴とする請求項３８に記載のコンピュータプログラム製品。
45. 処理済みメッセージバッファリングの前記ローカルの高信頼性メッセージの機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項３８に記載のコンピュータプログラム製品。
46. 前記ローカルの高信頼性メッセージの機能は、メッセージを配信不能とみなす前にメッセージ配信をアボートしなければならない回数を構成する手段をさらに含むことを特徴とする請求項３８に記載のコンピュータプログラム製品。
47. 前記エンドツーエンドメッセージの配信の保証およびローカル機能によって定義されるメッセージ構成の選択肢を含む固有の１組を提供する１組のプロファイルによってメッセージ配信特性の定義が可能なことを特徴とする請求項３８に記載のコンピュータプログラム製品。

Images