(57)【要約】      （修正有）【課題】  パートナのエンドポイントとメッセージを交換するために送信演算および受信演算を抽象化する実行時メッセージ交換の下部構造を提供する。【解決手段】  メッセージアプリケーションが伝送機構を開発時に指定することなく、実行時にメッセージアプリケーションを任意の数のメッセージ伝送機構とリンクすることによって可用性および拡張性が向上する。このメッセージ下部構造は、エンドツーエンドの配信の保証を指定する命令をメッセージアプリケーションから受信する。この下部構造は、指定された配信の保証を実現するために伝送機構を使用し、メッセージを交換するのに使用するために、メッセージアプリケーションと、伝送機構との間にリンクを作成する。セッション状態ストレージをプラグが可能なストア内に保持することができ、プラグが可能なストアは、例えば永続的データベースストアまたはアプリケーションメモリストアでよい。【選択図】  図２
2004295896.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数の使用可能なメッセージ伝送機構を介してパートナのエンドポイントとメッセージを交換するために送信および受信演算を抽象化する実行時メッセージ交換の下部構造において、実行時にメッセージ交換アプリケーションとリンクするために前記１つまたは複数のメッセージ伝送機構のうち少なくとも１つを選択することによって前記メッセージ交換アプリケーションの可用性および拡張性を向上させる方法であって、
前記メッセージ交換アプリケーションが少なくとも１つの所望のメッセージ伝送機構を開発時に指定することなく、実行時に前記少なくとも１つの所望のメッセージ伝送機構を選択する際に使用すべき１つまたは複数のエンドツーエンドメッセージ配信の保証を指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作であって、前記１つまたは複数のエンドツーエンドメッセージ配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序だて送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含む動作と、
前記メッセージ交換アプリケーションから受信した前記１つまたは複数の命令で指定された前記１つまたは複数のエンドツーエンドメッセージ配信の保証を実現するために、前記１つまたは複数の使用可能なメッセージ伝送機構から前記少なくとも１つの所望のメッセージ伝送機構を選択する動作と、
前記メッセージ交換アプリケーションと、前記パートナのエンドポイントとの間でメッセージを交換するために、前記メッセージ交換の下部構造内でメッセージ交換アプリケーションと選択した前記少なくとも１つの適切なメッセージ伝送機構との間のリンクを作成する動作と
を備えたことを特徴とする方法。
【請求項２】
１つまたは複数のローカルの高信頼性メッセージ機能を指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作をさらに備え、前記１つまたは複数のローカルの高信頼性メッセージ機能は、セッション状態ストレージ、メッセージ生存期間、および処理済メッセージのバッファリングのうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記セッション状態ストレージは、プラグが可能なストアを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記プラグが可能なストアは、メモリ内ストレージ、ディスク上の永続ストレージ、デーモンプロセスストレージ内、不揮発性メモリストア内、光ストレージ上、磁気テープ、ネットワーク接続ストレージ、または取外し可能のうち少なくとも１つであることを特徴とする請求項３に記載の方法。
【請求項５】
前記プラグが可能なストアは、前記メッセージ交換の下部構造のリモートにあるストアを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記ローカルの高信頼性メッセージ機能は、前記メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義し、最大メッセージサイズを組み合わせることにより前記メッセージ交換の下部構造によってバッファリングされる最大バイト数を定義する最大バッファ割当と、前記メッセージ交換の下部構造によってバッファリングされる最小確保メッセージ数を定義し、最大メッセージサイズを組み合わせることにより前記メッセージ交換の下部構造によってバッファリングされる最小バイト数を定義する最小バッファ割当と、送信タイムアウト満了後に前記送信演算のブロックを解除する送信タイムアウトと、高い優先順位のメッセージの送信および配信が低い優先順位のメッセージよりも優先される優先順位選択肢と、前記メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能なポイズンメッセージ機能とをさらに含むことを特徴とする請求項２に記載の方法。
【請求項７】
処理済メッセージのバッファリングの前記ローカルの高信頼性メッセージ機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項２に記載の方法。
【請求項８】
前記作成したリンクは、チャネル、セッション状態バッファ、プロトコル部、およびプラグが可能なストアを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記１つまたは複数の指定されたエンドツーエンド配信の保証は、少なくとも１回メッセージ配信を含み、前記プロトコル部は、再試行間隔の後確認応答を受信するまで、以前に送信したメッセージのコピーを前記パートナのエンドポイントに周期的に送信することを特徴とする請求項８に記載の方法。
【請求項１０】
前記１つまたは複数の指定のエンドツーエンド配信の保証は、セッション生存期間をさらに含み、確認応答が指定されたセッション生存期間内に受信されない場合、次の再試行が行われず、エラー表示が前記メッセージ交換アプリケーションに付与されることを特徴とする請求項９に記載の方法。
【請求項１１】
メッセージ生存期間のローカルの高信頼性メッセージ機能を受信する動作をさらに備え、確認応答が指定されたメッセージ生存期間内に受信されない場合、次の再試行が行われず、エラー表示が前記メッセージ交換アプリケーションに付与されることを特徴とする請求項９に記載の方法。
【請求項１２】
前記再試行間隔は、連続する再試行間隔の後にバックオフ間隔によって調節されることを特徴とする請求項９に記載の方法。
【請求項１３】
前記チャネル、セッション状態バッファ、およびプロトコル部についての状態は、前記プラグが可能なストア内に保持されることを特徴とする請求項８に記載の方法。
【請求項１４】
前記少なくとも１つの所望のメッセージ伝送機構は、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰ、ＲＰＣ、およびＳＭＴＰの各伝送機構のうち少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記メッセージの交換は、片方向メッセージ交換、要求／応答メッセージ交換、および全二重メッセージ交換のうち少なくとも１つを含む複数のメッセージ交換パターンによって定義されることを特徴とする請求項１に記載の方法。
【請求項１６】
１つまたは複数の使用可能なメッセージ伝送機構を介してパートナのエンドポイントとメッセージを交換するために送信演算および受信演算を抽象化する実行時メッセージ交換の下部構造において、実行時にメッセージ交換アプリケーションとリンクするために前記１つまたは複数のメッセージ伝送機構のうち少なくとも１つを選択することによってメッセージ交換アプリケーションの可用性および拡張性を向上させる方法を実施するコンピュータ実行可能命令を格納する１つまたは複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
前記メッセージ交換アプリケーションが少なくとも１つの所望のメッセージ伝送機構を開発時に指定することなく、実行時に前記少なくとも１つの所望のメッセージ伝送機構を選択する際に使用すべき１つまたは複数のエンドツーエンドメッセージ配信の保証を指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作であって、前記１つまたは複数のエンドツーエンドメッセージ配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序だて送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含む動作と、
前記メッセージ交換アプリケーションから受信した前記１つまたは複数の命令で指定された前記１つまたは複数のエンドツーエンドメッセージ配信の保証を実現するために、前記１つまたは複数の使用可能なメッセージ伝送機構から前記少なくとも１つの所望のメッセージ伝送機構を選択する動作と、
前記メッセージ交換アプリケーションと前記パートナのエンドポイントとの間でメッセージを交換するために、前記メッセージ交換の下部構造内でメッセージ交換アプリケーションと選択した前記少なくとも１つの所望のメッセージ伝送機構との間のリンクを作成する動作と
を備えたことを特徴とするコンピュータプログラム製品。
【請求項１７】
１つまたは複数のローカルの高信頼性メッセージ機能を指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作をさらに備え、前記１つまたは複数のローカルの高信頼性メッセージ機能は、セッション状態ストレージ、メッセージ生存期間、および処理済メッセージのバッファリングのうち少なくとも１つを含むことを特徴とする請求項１６に記載のコンピュータプログラム製品。
【請求項１８】
前記セッション状態ストレージは、プラグが可能なストアを含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項１９】
前記ローカルの高信頼性メッセージ機能は、前記メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義し、最大メッセージサイズと組み合わせることにより前記メッセージ交換の下部構造によってバッファリングされる最大バイト数を定義する最大バッファ割当と、前記メッセージ交換の下部構造によってバッファリングされる最小確保メッセージ数を定義し、最大メッセージサイズと組み合わせることにより前記メッセージ交換の下部構造によってバッファリングされる最小バイト数を定義する最小バッファ割当と、送信タイムアウト満了後に前記送信演算をブロック解除する送信タイムアウトと、高い優先順位のメッセージの送信および配信が低い優先順位のメッセージよりも優先される優先順位の選択肢と、前記メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能なポイズンメッセージ機能とをさらに含むことを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２０】
前記送信演算は、前記送信タイムアウトにより、所定のタイムアウト期間が経過する前にスペースが利用可能であることを前記バッファ割当が示す場合にのみ使用可能となることを特徴とする請求項１９に記載のコンピュータプログラム製品。
【請求項２１】
処理済メッセージのバッファリングの前記ローカルの高信頼性メッセージ機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項１７に記載のコンピュータプログラム製品。
【請求項２２】
前記作成したリンクは、チャネル、セッション状態バッファ、プロトコル部、およびプラグが可能なストアを含むことを特徴とする請求項１６に記載のコンピュータプログラム製品。
【請求項２３】
前記プロトコル部は、受信したメッセージを受信バッファ内にコピーすることを特徴とする請求項２２に記載のコンピュータプログラム製品。
【請求項２４】
前記プロトコル部は、次に予想されるメッセージシーケンス番号を記録することを含むことを特徴とする請求項２３に記載のコンピュータプログラム製品。
【請求項２５】
受信したメッセージが、セッションエンドポイントによって維持される状態に基づいて以前に受信したメッセージの複製である場合、前記受信したメッセージは廃棄されることを特徴とする請求項２３に記載のコンピュータプログラム製品。
【請求項２６】
前記１つまたは複数の指定のエンドツーエンド配信の保証は、少なくとも１回メッセージ配信を含み、前記プロトコル部は、再試行間隔の後確認応答を受信するまで、以前に送信したメッセージのコピーを前記パートナのエンドポイントに周期的に送信することを特徴とする請求項２２に記載のコンピュータプログラム製品。
【請求項２７】
前記１つまたは複数の指定されたエンドツーエンド配信の保証は、セッション生存期間をさらに含み、確認応答が指定のセッション生存期間内に受信されない場合、次の再試行が行われず、エラー表示が前記メッセージ交換アプリケーションに付与されることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項２８】
メッセージ生存期間のローカルの高信頼性メッセージ機能を受信する動作であって、確認応答が指定されたセッション生存期間内に受信されない場合、次の再試行が行われず、エラー表示が前記メッセージ交換アプリケーションに付与される動作をさらに備えたことを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項２９】
前記パートナのエンドポイントへの一続きのメッセージのうち少なくとも１つのメッセージの送信または配信をスケジューリングする動作をさらに備えたことを特徴とする請求項１６に記載のコンピュータプログラム製品。
【請求項３０】
前記スケジューリングは、接続性、負荷平衡、メッセージ優先順位、および低コスト伝送機構の使用のうち少なくとも１つに基づいて行われることを特徴とする請求項２９に記載のコンピュータプログラム製品。
【請求項３１】
前記チャネル、セッション状態バッファ、およびプロトコル部についての状態は、前記プラグが可能なストア内に保持されることを特徴とする請求項２２に記載のコンピュータプログラム製品。
【請求項３２】
１つまたは複数のメッセージ伝送機構を介してパートナのエンドポイントとメッセージを交換するために送信演算および受信演算を抽象化する実行時メッセージ交換の下部構造において、実行時にメッセージ交換アプリケーションとリンクするために前記１つまたは複数のメッセージ伝送機構のうち少なくとも１つを選択することによって前記メッセージ交換アプリケーションの可用性および拡張性を向上させる方法であって、
前記メッセージ交換アプリケーションが、前記１つまたは複数の伝送機構の中から、前記メッセージ交換アプリケーションによって指定される１つまたは複数のエンドツーエンド配信の保証を満たす少なくとも１つの所望の伝送機構を開発時に指定することなく、前記少なくとも１つの所望の伝送機構を実行時に決定するステップであって、前記１つまたは複数のエンドツーエンド伝送機構の保証は、少なくとも１回配信、高々１回配信、順序だて送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含むステップと、
前記メッセージ交換アプリケーションと前記パートナのエンドポイントとの間でメッセージを交換するために、前記メッセージ交換アプリケーションと、前記決定した少なくとも１つの所望の伝送機構とをリンクするステップと
を備えたことを特徴とする方法。
【請求項３３】
セッション状態ストレージ、メッセージ生存期間、および処理済メッセージのバッファリングのうち少なくとも１つを含む１つまたは複数のローカルの高信頼性メッセージ機能を実装するステップをさらに備えたことを特徴とする請求項３２に記載の方法。
【請求項３４】
前記セッション状態ストレージは、デーモンプロセスストア、永続性のデータベースストア、およびアプリケーションストアのうち少なくとも１つを含むプラグが可能なストア内に保持されることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記ローカルの高信頼性メッセージ機能は、前記メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義するバッファ割当と、送信タイムアウト満了後に前記送信演算のブロックを解除する送信タイムアウトと、高い優先順位のメッセージが低い優先順位のメッセージよりも前に送信される優先順位の選択肢と、前記メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能なポイズンメッセージ機能とをさらに含むことを特徴とする請求項３３に記載の方法。
【請求項３６】
トランザクションサポートの前記ローカルの高信頼性メッセージ機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項３３に記載の方法。
【請求項３７】
前記メッセージ交換アプリケーションと、前記決定した少なくとも１つの所望の伝送機構とは、チャネル、セッション状態バッファ、プロトコル部、およびプラグが可能なストアによって前記メッセージ交換の下部構造内でリンクされることを特徴とする請求項３２に記載の方法。
【請求項３８】
前記チャネルは、メッセージを送信および受信するためのアブストラクションを提供するアプリケーションプログラミングインターフェースであることを特徴とする請求項３７に記載の方法。
【請求項３９】
前記セッション状態バッファは、送信バッファを含み、および単調増加のメッセージシーケンス番号でメッセージを一意的にスタンプすることを特徴とする請求項３８に記載の方法。
【請求項４０】
前記セッション状態バッファは、前記アプリケーションに配信するまでメッセージを保持する受信バッファを含むことを特徴とする請求項３８に記載の方法。
【請求項４１】
前記１つまたは複数の指定されたエンドツーエンド配信の保証は、少なくとも１回メッセージ配信およびセッション生存期間を含み、前記プロトコル部は、前記セッション生存期間中に、再試行間隔の後確認応答メッセージを受信するまで、以前に送信したメッセージのコピーを前記パートナのエンドポイントに周期的に送信することを特徴とする請求項３７に記載の方法。
【請求項４２】
前記メッセージ交換の下部構造は、セッション障害またはメッセージ障害の判定および処理のうち少なくとも１つを提供することを特徴とする請求項３７に記載の方法。
【請求項４３】
前記メッセージ障害処理は、オペレーティングコードへの障害の通知、メッセージ交換アプリケーションへの障害の通知、１つまたは複数のプラグが可能な障害ハンドラへの障害の通知、およびオペレータへの障害の通知のうち少なくとも１つを含むことを特徴とする請求項４２に記載の方法。
【請求項４４】
切り抜けることができる障害は、メッセージの破壊、メッセージの紛失、メッセージの重複、メッセージの遅延、メッセージの再順序付け、伝送機構障害、ネットワーク障害、プロセス障害、およびシステム障害を含まれることを特徴とする請求項４３に記載の方法。
【請求項４５】
前記メッセージ交換の下部構造は、前記障害が修復されたという通知を受け、障害のあった演算を再試行することを特徴とする請求項４２に記載の方法。
【請求項４６】
前記チャネル、セッション状態バッファ、およびプロトコル部についての状態は、前記プラグが可能なストア内に保持されることを特徴とする請求項３７に記載の方法。
【請求項４７】
１つまたは複数の伝送機構を介してパートナのエンドポイントとメッセージを交換するために送信演算および受信演算を抽象化する実行時メッセージ交換の下部構造において、実行時にメッセージ交換アプリケーションとリンクするために前記１つまたは複数のメッセージ伝送機構のうち少なくとも１つを選択することによってメッセージ交換アプリケーションの可用性および拡張性を向上させる方法を実施するコンピュータ実行可能命令を格納する１つまたは複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
前記メッセージ交換アプリケーションによって指定される１つまたは複数のエンドツーエンド配信の保証を満たす少なくとも１つの所望のメッセージ伝送機構を前記１つまたは複数の伝送機構の中から前記メッセージ交換アプリケーションが開発時に指定することなく、前記少なくとも１つの所望の伝送機構を実行時に決定するステップであって、前記１つまたは複数のエンドツーエンド伝送機構の保証は、少なくとも１回配信、高々１回配信、順序だて配信、およびセッション生存期間配信のうち少なくとも１つを含むステップと、
前記メッセージ交換アプリケーションと前記パートナのエンドポイントとの間でメッセージを交換するために、前記メッセージ交換アプリケーションと、前記決定した少なくとも１つの所望の伝送機構とをリンクするステップと
を備えたことを特徴とするコンピュータプログラム製品。
【請求項４８】
セッション状態ストレージ、メッセージ生存期間、および処理済メッセージのバッファリングのうち少なくとも１つを含む１つまたは複数のローカルの高信頼性メッセージ機能を実装するステップをさらに備えたことを特徴とする請求項４７に記載のコンピュータプログラム製品。
【請求項４９】
前記セッション状態ストレージは、デーモンプロセスストア、永続性のデータベースストア、およびアプリケーションストアのうち少なくとも１つを含むプラグが可能なストア内に保持されることを特徴とする請求項４８に記載のコンピュータプログラム製品。
【請求項５０】
前記ローカルの高信頼性メッセージ機能は、前記メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義するバッファ割当と、送信タイムアウト満了後に前記送信演算のブロックを解除する送信タイムアウトと、高い優先順位のメッセージが低い優先順位のメッセージよりも前に送信される優先順位の選択肢と、前記メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能なポイズンメッセージ機能とをさらに含むことを特徴とする請求項４８に記載のコンピュータプログラム製品。
【請求項５１】
処理済メッセージのバッファリングの前記ローカルの高信頼性メッセージ機能は、前記セッション状態ストレージの永続性の如何にかかわらず使用可能であることを特徴とする請求項４８に記載のコンピュータプログラム製品。
【請求項５２】
前記メッセージ交換アプリケーションと、前記決定した少なくとも１つの所望の伝送機構とは、チャネル、セッション状態バッファ、プロトコル部、およびプラグが可能なストアによって前記メッセージ交換の下部構造内でリンクされることを特徴とする請求項４７に記載のコンピュータプログラム製品。
【請求項５３】
前記セッション状態バッファは、前記メッセージ交換アプリケーションからメッセージをキャプチャし、前記メッセージ交換アプリケーションにメッセージを配信し、送信および受信したメッセージについての状態情報を保持することを特徴とする請求項５２に記載のコンピュータプログラム製品。
【請求項５４】
前記状態情報は、セッション識別子、前記１つまたは複数の指定されたエンドツーエンド伝送機構の保証、およびパートナのエンドポイントアドレスのうち少なくとも１つを含むことを特徴とする請求項５３に記載のコンピュータプログラム製品。
【請求項５５】
前記状態情報は、送信シーケンス番号および確認応答状態情報の少なくとも一方を含むことを特徴とする請求項５３に記載のコンピュータプログラム製品。
【請求項５６】
前記状態情報は、構成が可能な生存期間、送信タイムアウト情報、および情報が格納されている位置のうち少なくとも１つを含むことを特徴とする請求項５３に記載のコンピュータプログラム製品。
【請求項５７】
前記プロトコル部は、エンドポイント解決を実施して前記パートナのエンドポイントを識別することを特徴とする請求項５２に記載のコンピュータプログラム製品。
【請求項５８】
前記プロトコル部は、アプリケーションファームまたはアプリケーションファーム内のパーティションの少なくとも一方の中のノードに向けてメッセージを送るための中継点と共に、エンドポイント解決を開始することを特徴とする請求項５７に記載のコンピュータプログラム製品。
【請求項５９】
前記１つまたは複数の指定のエンドツーエンド配信の保証は、少なくとも１回メッセージ配信およびセッション生存期間を含み、前記プロトコル部は、前記セッション生存期間中に、再試行間隔の後確認応答メッセージを受信するまで、以前に送信したメッセージのコピーを前記パートナのエンドポイントに周期的に送信することを特徴とする請求項５２に記載のコンピュータプログラム製品。
【請求項６０】
前記チャネル、セッション状態バッファ、およびプロトコル部についての状態は、前記プラグが可能なストア内で保持されることを特徴とする請求項５２に記載のコンピュータプログラム製品。
【請求項６１】
１つまたは複数の使用可能なメッセージ伝送機構を介してパートナのエンドポイントとメッセージを交換するためにセッション状態ストレージならびに送信演算および受信演算を抽象化する実行時メッセージ交換の下部構造において、実行時にメッセージ交換アプリケーションとリンクするために前記１つまたは複数のメッセージ伝送機構のうち少なくとも１つを選択することによってメッセージ交換アプリケーションの可用性および拡張性を向上させる方法を実行するコンピュータ実行可能命令を格納する１つまたは複数のコンピュータ読取可能な媒体を含むコンピュータプログラム製品であって、前記方法は、
セッション状態ストレージを指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作であって、前記セッション状態が、デーモンプロセスストア、永続データベースストア、およびアプリケーションストアのうち少なくとも１つを含むプラグが可能なストア内に保持される動作と、
前記メッセージ交換アプリケーションが少なくとも１つの所望のメッセージ伝送機構を開発時に指定することなく、実行時に前記少なくとも１つの所望のメッセージ伝送機構を選択する際に使用すべき１つまたは複数のエンドツーエンドメッセージ配信の保証を指定する１つまたは複数の命令を前記メッセージ交換アプリケーションから受信する動作であって、前記１つまたは複数のエンドツーエンドメッセージ配信の保証は、少なくとも１回メッセージ配信、高々１回メッセージ配信、順序だて送信メッセージ配信、およびセッション生存期間のうち少なくとも１つを含む動作と、
前記メッセージ交換アプリケーションから受信した前記命令で指定された前記１つまたは複数のエンドツーエンドメッセージ配信の保証を実現するために、前記１つまたは複数の使用可能なメッセージ伝送機構から少なくとも１つの所望のメッセージ伝送機構を選択する動作と、
前記メッセージ交換アプリケーションと前記パートナのエンドポイントとの間でメッセージを交換する際に使用するために、前記メッセージ交換の下部構造内でメッセージ交換アプリケーションと選択した前記少なくとも１つの所望のメッセージ伝送機構との間のリンクを作成する動作と
を備えたことを特徴とするコンピュータプログラム製品。
【請求項６２】
前記方法は、メッセージ生存期間と、処理済メッセージのバッファリングと、前記メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義するバッファ割当と、送信タイムアウト満了後に前記送信演算のブロックを解除する送信タイムアウトと、高い優先順位のメッセージが低い優先順位のメッセージよりも前に送信される優先順位の選択肢と、前記メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能な構成可能ポイズンメッセージ機能のうち少なくとも１つを含む１つまたは複数のローカルの高信頼性メッセージ機能を受信する動作をさらに備えたことを特徴とする請求項６１に記載のコンピュータプログラム製品。
【請求項６３】
前記作成したリンクは、チャネル、セッション状態バッファ、プロトコル部、およびプラグが可能なストアを含むことを特徴とする請求項６１に記載のコンピュータプログラム製品。
【請求項６４】
前記１つまたは複数の指定されたエンドツーエンド配信の保証は、少なくとも１回メッセージ配信およびセッション生存期間を含み、前記プロトコル部は、前記セッション生存期間中に、再試行間隔の後確認応答メッセージを受信するまで、以前に送信したメッセージのコピーを前記パートナのエンドポイントに周期的に送信することを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６５】
前記再試行間隔は、連続する再試行間隔の後にバックオフ間隔によって調節されることを特徴とする請求項６４に記載のコンピュータプログラム製品。
【請求項６６】
前記パートナのエンドポイントへの一続きのメッセージのうち少なくとも１つのメッセージの転送をスケジューリングする動作をさらに備えたことを特徴とする請求項６１に記載のコンピュータプログラム製品。
【請求項６７】
前記スケジューリングは、断続的接続性、負荷平衡、メッセージ優先順位、および低コスト伝送機構の使用のうち少なくとも１つに基づくことを特徴とする請求項６６に記載のコンピュータプログラム製品。
【請求項６８】
前記チャネル、セッション状態バッファ、およびプロトコル部についての状態は、前記プラグが可能なストア内で維持されることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６９】
前記メッセージの交換は、片方向メッセージ交換、要求／応答メッセージ交換、および全二重メッセージ交換のうち少なくとも１つを含む複数のメッセージ交換パターンによって定義されることを特徴とする請求項６１に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に高信頼性のメッセージ交換システムに関する。より詳細には、本発明は、高信頼性の２者間メッセージ交換システムについての可用性および拡張性をアプリケーションにとって透過的な方法で向上させるためのシステム、方法、およびコンピュータプログラム製品を提供する。
【背景技術】
【０００２】
メッセージ交換システムはますます、通信のための一般的な方法となってきている。こうした通信システムは、Ｅメールシステムからセキュリティで保護された取引まで、あるいはチャットルームからインターネットショッピングなどの様々なウェブサービスまで多岐に渡る。こうしたシステムおよびアプリケーションは、メッセージ交換の信頼性、セキュリティ、性能、可用性（ａｖａｉｌａｂｉｌｉｔｙ）、および拡張性（ｓｃａｌａｂｉｌｉｔｙ）に関する要件として極めて多様なものを要求される。既存のシステムによっては、より一般的な要件の、特定の限定された組合せに対処する部分的な解決策しか提供されない。
【０００３】
伝統的な従来技術のメッセージ交換システムでは一般に、保証（ａｓｓｕｒａｎｃｅ：例えば、確実に１回（ｅｘａｃｔｌｙ−ｏｎｃｅ）配信）、メッセージ交換パターン（例えば、片方向、要求／応答、または全二重）、およびメッセージ交換インターフェースセマンティクス（例えばトランザクションメッセージバッファリング）に関して提供される柔軟性が限られる。こうした各メッセージ交換システムでは一般に、対処する１組の拡張性の要件と可用性の要件が限定され、全体の拡張性または可用性を向上させるようにシステムを拡張するための選択肢がほとんど提供されないか、または大規模なアプリケーションの介入が必要となる。
【０００４】
例えば、以下の２者間通信モデルを考慮する。データグラムシステムでは通常、信頼性のない応答不要な送信の片方向セッションレスのメッセージ交換が提供され、拡張性および可用性に対する直接的なサポートはほとんど提供されない。こうしたシステムにより、開発者は最高の自由度および柔軟性を与えられ、開発者自身がすべてを構築することとなる。
【０００５】
ＴＣＰは、全二重のセッション指向通信を提供する。ＴＣＰは、多様ではあるが、固定の１組の配信の保証（確実に１回、順序だて（ｉｎ−ｏｒｄｅｒ）バイト配信）を有する。接続状態は揮発性メモリ内データ構造内に保持され、可用性が限定されて接続はシステム／プロセス障害、および多くのネットワーク障害で維持されない。
【０００６】
ＲＣＰは半二重の交換パターンを提供するが、一部のシステムにおいて、これは単一要求／応答対話に限定され、一部においては会話型セッションが提供される。いずれの場合も、通常はエンドポイントの状態がメモリ内に保持され、したがってＴＣＰと同様に可用性が制限される。時には、セッションレスの要求／応答システムが高い拡張性を達成することが可能だが（ＨＴＴＰベースのウェブファームを考慮されたい）、こうしたシステムは通常、高々１回（ａｔ−ｍｏｓｔ−ｏｎｃｅ）要求処理を提供せず、したがってその使用は、べき等要求（ｉｄｅｍｐｏｔｅｎｔ  ｒｅｑｕｅｓｔ）に限定される。セッションに基づくＲＰＣシステムにおいては、高々１回処理を用いて要求を再試行することができ、可用性を多少向上させることが可能となる。ある場合には、拡張性が多少向上する多重化を考慮して、基礎となるトランスポート接続はランタイムによって管理される。
【０００７】
最後に、メッセージキューイングシステムは一般に、確実に１回配信のセマンティクスを提供する。データグラム、ＴＣＰ、およびＲＰＣモデルとは異なり、キューにより、通信する２者間でバッファリングが行われ、接続性およびスケジューリング柔軟性を追加することが可能となる。多くのメッセージキューイングシステムにより、プロセス／システム障害を許容することによって可用性を向上させる永続的な状態ストレージを提供する。一部のキューイングシステムは、トランザクションもサポートする。このモデルは、部分的作業を自動的にアンドゥし、自動的に再試行処理を可能にすることによって、信頼性および可用性を向上させることができる。こうしたシステムでは一般に、例えばプロプラエタリで永続的なストアの使用が要求されるなど、ストレージの選択肢が制限され、および伝送機構に依存してネットワークの構成を限定することとなる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、柔軟性を向上させて、アプリケーションに指定される保証が満たされる限り、特別なランタイム条件および要件にアプリケーションを適合させることを可能にするメッセージ交換システムが求められている。さらに、アプリケーションプログラムにとって透過的な方法で、特定の配置の必要に合わせてアプリケーションの可用性および拡張性を調整するのに使用することができる上述の柔軟性を有するメッセージ交換システムが求められている。
【課題を解決するための手段】
【０００９】
本発明の例示の実施形態によれば、現在のメッセージ交換システムの前述の不完全性および欠点が克服される。例えば、例示の実施形態は、いくつかのメッセージ伝送機構（ｔｒａｎｓｐｏｒｔ）を介してパートナのエンドポイントとメッセージを交換するために送信演算（ｓｅｎｄｉｎｇ  ｏｐｅｒａｔｉｏｎ）および受信演算（ｒｅｃｅｉｖｉｎｇ  ｏｐｅｒａｔｉｏｎ）を抽象化する実行時のメッセージ交換の下部構造（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を提供する。本発明は、基礎となるメッセージ伝送機構の可用性および拡張性を向上させることによってメッセージアプリケーションの可用性および拡張性を向上させる。例えば、多くのエラーをマスクし、永続状態の保持に対するサポートを提供し、アプリケーションにとってすべて不可視である、クラスタ、サービスの冗長度、構成の可能なタイムアウト、および構成の可能なバッファサイズに対するサポートを提供することによって可用性が向上する。構成の可能なバッファサイズ、およびサービスの複製、例えばサービスファームによって拡張性が達成される。
【００１０】
具体的には、実行時にメッセージアプリケーションとリンクするためにメッセージ伝送機構のうち１つを選択することによって可用性および拡張性が向上する。本発明によるメッセージ下部構造は、少なくとも１回（ａｔ−ｌｅａｓｔ−ｏｎｃｅ）メッセージ配信、高々１回メッセージ配信、順序だて送信メッセージ配信、セッション生存期間などのエンドツーエンドのメッセージ配信の保証を指定する命令をメッセージアプリケーションから受信する。選択された保証が、メッセージアプリケーションが適切な伝送機構を開発時に指定することなく、実行時に適切なメッセージ伝送機構を選択する際に使用される。この下部構造は、エンドツーエンドのメッセージ配信の保証を満たす少なくとも１つの伝送機構を選択し、メッセージアプリケーションとパートナのエンドポイントとの間でメッセージを交換する際に使用するために、メッセージアプリケーションと、選択した伝送機構との間のリンクを作成する。
【００１１】
本発明の他の例示の実施形態によれば、この下部構造は、セッション状態ストレージ、メッセージ生存期間、処理済みメッセージ交換バッファリングなどのローカルの高信頼性メッセージの機能を指定する命令をメッセージアプリケーションから受信することができる。セッション状態ストレージのローカルの高信頼性メッセージ交換の機能は、プラグが可能なストア内に保持することができ、プラグが可能なストアは、例えばデーモンプロセスストア、永続データベースストア、またはアプリケーションメモリストアとすることができる。ストアの選択により、セッション状態の永続性が定義され、より多くの種類の障害（例えば、アプリケーションクラッシュ、ノードクラッシュなど）からの回復が可能となって可用性が向上する。同様に、ディスクベースのストアは、メモリベースのストアよりも多くのメッセージを保持することができ、したがって拡張性と可用性が共に向上する。
【００１２】
ローカルの高信頼性メッセージ交換の機能はまた、とりわけ、メッセージ交換の下部構造によってバッファリングされる最大メッセージ数を定義するバッファ割当と、その満了後に送信演算のブロックを解除する送信タイムアウトと、高い優先順位メッセージが低い優先順位メッセージよりも前に送信される優先順位選択肢と、メッセージをいつポイズンとするかを判定するためにメッセージ配信をアボートする回数の構成が可能であるポイズンメッセージ機能も含むことができる。
【００１３】
本発明のさらなる特徴および利点を以下で説明するが、その一部は以下の説明から明らかとなり、あるいは本発明を実施することによって知ることができる。本発明の特徴および利点は、特許請求の範囲に具体的に指摘される手段およびその組合せによって実現され、得られる。本発明の上記およびその他の特徴は、以下の説明および特許請求の範囲から完全に明らかとなり、あるいは本発明の上記およびその他の特徴は、以下に説明する本発明を実施することによって知ることができる。
【００１４】
本発明の上記およびその他の利点および特徴を得る方法を説明するために、添付の図面に示される本発明の特定の実施形態を参照することによって上記で簡潔に説明した本発明をより具体的に説明する。これらの図面は本発明の典型的な実施形態を示すに過ぎず、したがって本発明の範囲を限定するとみなすべきでないことを理解し、添付の図面を使用することにより、さらに具体的におよび詳細に本発明の説明を行う。
【発明を実施するための最良の形態】
【００１５】
本発明は、１つまたは複数のアプリケーションを開発すると共に、複数の別個のメッセージ伝送機構にアクセスし、それを使用するための単一のプログラミングモデルを提供することによって高信頼性メッセージ交換アプリケーション開発を簡略化するための方法、システム、およびコンピュータプログラム製品まで含む。本発明の実施形態は、以下でより詳細に議論するように、様々なコンピュータハードウェアを含む専用コンピュータまたは汎用コンピュータを備えることができる。
【００１６】
図１に、高信頼性メッセージ交換スタック１００ａおよび１００ｂの高レベル表現を示す。メッセージ交換スタックでは、高信頼性のメッセージ交換のプロトコル部１２５を用いない場合、アプリケーション１０５がメッセージを、例えば別のアプリケーション層１８５に送りたいとき、アプリケーション１０５は、データグラムメッセージ交換層１４０にメッセージまたは一連のメッセージ１１５を直接転送する（アプリケーション１０５は、例えばサービスなどのどんなタイプのアプリケーションでもよいことに留意されたい。また一般に、アプリケーション１０５がアプリケーションフレームワークを適宜包含することを理解されたい。）。データグラムは信頼性が低いので、メッセージ１１５が複製され、遅延し、および／または失われる可能性がある。例えば、信頼性のない応答不要なデータグラムプロトコルでは、メッセージ１１５が、伝送機構１６０と１６５の間の中継点１３５におけるものを含むいくつかの理由で失われる可能性がある。したがって、パートナのエンドポイントのアプリケーション１８５は、メッセージ１１５を決して受信せず、送信側アプリケーション１０５は、そのメッセージ１１５が受信されなかったことに気付かない。
【００１７】
しかし、本発明の例示される実施形態によれば、高信頼性メッセージ交換スタック１００ａおよび１００ｂは、高信頼性のメッセージ交換のプロトコル部１２５を備える。したがって、例えば、高信頼性メッセージ交換フレームワーク１２０（あるいは１８０）により、アプリケーション１０５から送信されたメッセージ１１５がその宛先エンドポイントに適切に到着するよう保証することができる。例えば、アプリケーション１０５がそのセッションの相手方アプリケーション１８５にメッセージ１１５を転送したい場合、アプリケーション１０５は、メッセージ１１５を高信頼性メッセージ交換フレームワーク１２０に送ることができ、そこでメッセージ１１５がセッションに割り当てられ、メッセージ１１５にメッセージのシーケンス番号が与えられる。セッション識別子が、アプリケーション１０５とアプリケーション１８５の間のセッション通信に対応する。言い換えれば、セッションとは、２つのアプリケーション１０５と１８５との間の二重会話を指す。シーケンス番号付けは、セッション通信中の所定のメッセージに対し行われる。例えば、２つのアプリケーション１０５と１８５との間で通信される単一のセッション内にいくつかのメッセージが存在する可能性があり、各メッセージは、アプリケーションによって送信された順に順次番号付けされる。加えて、アプリケーション１０５、１８５、および場合によっては他のアプリケーション間で確立された複数のセッションが存在する可能性がある（確立された各セッションは、同一のまたは異なる配信保証を有する可能性がある）。したがって、各メッセージには、所定のセッション順序およびそのセッション内のメッセージのシーケンス順序を識別するセッション番号およびシーケンス番号が一意に割り当てられる。
【００１８】
メッセージ１９１上にセッションおよびシーケンスヘッダが書き込まれ、その他の必要なチャネル処理が実行された後、メッセージ１９１は、送信バッファ内のセッション状態１９０に格納される。その後で、メッセージ１９１のコピーがデータグラムメッセージ交換１４０を介して移送される。データグラムメッセージ交換１４０は、例えばルーティングヘッダを提供することにより、メッセージ１９１のエンドツーエンド伝送を実施する。次いでメッセージ１９１が、場合によってはメッセージ１９１のエンドツーエンド伝送を一連のポイントツーポイント伝送としてそれぞれ実施する１つまたは複数の中継点、例えば中継点１３５を介して転送される。拡張された傍受機構（ｉｎｔｅｒｃｅｐｔｉｏｎ  ｍｅｃｈａｎｉｓｍ）を使用して、ルーティング、フィルタリング、ポリシー管理、セキュリティなどの動作（ｂｅｈａｖｉｏｒｓ）を実施することができる。伝送機構１４５、１７０、１５５、および各メッセージ交換エンドポイント中のエンドポイントで使用可能な動作、および中継点１４０、１７５、１５０を、プログラムすることによって、またはシステムを構成することによって確立することができる。
【００１９】
少なくとも１回配信（以下でより詳細に説明する）に対する保証が、アプリケーション１０５に対して指定される場合、高信頼性メッセージ交換フレームワーク１２０は、高信頼性メッセージ交換フレームワーク１８０から、どのメッセージが適切に受信されたかを示す肯定応答の受信を待ち受ける。メッセージ１９２は、メッセージ１９１（例えばシーケンス中のメッセージ５）が受信されたという肯定応答を搬送する。周期的に、高信頼性メッセージ交換フレームワーク１８０がコピーを適切に受信しなかったため、または１２０が１８０から肯定応答を受信しなかったために高信頼性メッセージ交換フレームワーク１２０が肯定応答メッセージ１９２を受信しなかった場合、メッセージ１９１が再送信される。したがって、例えば中継点１３５で、メッセージ１９１が失われ、遅延し、または誤ってルーティングされた場合、高信頼性メッセージ交換フレームワーク１２０は、高信頼性メッセージ交換フレームワーク１８０がメッセージ１９１の少なくとも１つのコピーを適切に受信するように保証しようと試みて、メッセージ１９１を（後述のタイムアウト期間内で）周期的に送信し続ける。しかし、メッセージ１９１に関して上述したのと同様の理由で、肯定応答１９２が失われ、遅延し、または誤ってルーティングされる可能性がある。したがって、本発明は、以下で説明するように肯定応答メッセージ１９２の高信頼性メッセージ配信を提供する。
【００２０】
高信頼性メッセージ交換フレームワーク１８０が首尾よくメッセージ１９１のコピーを受信すると、高信頼性メッセージ交換フレームワーク１８０は肯定応答メッセージ１９２を高信頼性メッセージ交換フレームワーク１２０に送信する。肯定応答メッセージ１９２を受信すると、高信頼性メッセージ交換フレームワーク１２０は、そのセッション状態（送信）バッファ１９０からメッセージ１９１のコピーを削除し、メッセージ１９１の追加の送信を停止する。同様に、高信頼性メッセージ交換フレームワーク１８０は、そのセッション状態１９５中に、メッセージ１９１のコピーを受信したことを記録し、その結果、メッセージがアプリケーション１８５に既に配信されたか否かにかかわらず、高信頼性メッセージフレームワーク１８０が受信した任意の複製メッセージを廃棄することができる。その後で、アプリケーション１８５は、セッション状態（受信）バッファ１９５から、そのＲｅｃｅｉｖｅ（）コマンドを介して、受信されたメッセージを取り出すことができる。肯定応答１９２が失われ、遅延し、または誤ってルーティングされたために高信頼性メッセージ交換フレームワーク１２０が肯定応答１９２を受信しなかった場合、メッセージ１９１の再送信が続行され、それによって高信頼性メッセージ交換フレームワーク１８０が肯定応答１９２の別のコピーを送信するようトリガがかけられる。このプロセスは、高信頼性メッセージ交換フレームワーク１２０が少なくとも１つの肯定応答１９２を受信するまで、または高信頼性メッセージ交換フレームワーク１２０が再試行を諦め障害表示をアプリケーション１０５に送るまで続行することができる。
【００２１】
高信頼性メッセージ交換フレームワーク１２０および／または１８０は、本発明によるダイアログ２００（図２）としてそれぞれ構成することができる。ダイアログ２００は、図２を参照してより詳細に説明する。ダイアログ２００は、メッセージフレームワークアブストラクションであり、この場合サービス（またはアプリケーションインスタンス）は、他のサービスとの高信頼性のセッション指向の通信のためにダイアログ２００を使用する。プログラマは、ダイアログチャネル２２０を使用してダイアログにアクセスすることができる。さらに、ダイアログ２００は、アプリケーションに対するメッセージの配信の保証を構成することが可能な高信頼性メッセージ交換の下部構造および単一のプログラミングモデルを提供する。こうした信頼性保証レベルは満たされなければならず、そうでなければセッション障害が発生する。ダイアログ２００を設計することにより、対応するランタイムの実装が柔軟になって、アプリケーションの実装に対して主張される保証（正確さの制約）を維持する限りは追加の機能を提供することができる。具体的には、アプリケーションは、アプリケーションの実装にトランスペアレントな様々な度合いの可用性および拡張性を備えることができる。さらに、アプリケーション１０５と１８５との間のこうしたセッションの通信は、様々な伝送機構の種類（例えば、ＴＣＰ／ＩＰ１６０およびＨＴＴＰ１６５）、伝送機構接続インスタンス、ネットワークトポロジを介して実現することができる。
【００２２】
ダイアログ２００によって提供される信頼性保証は、少なくとも１回（ＡＬＯ）配信、高々１回（ＡＭＯ）配信、および順序ごと（ＩＯ）配信を含む。追加のセッション生存期間（ＴＴＬ）保証も提供される。ＡＭＯ保証により、送信側アプリケーションによって送信される任意の所与のメッセージについて、メッセージが受信側アプリケーションに最大１回配信される。ダイアログ２００はアブストラクションであるので、アプリケーションは、複製メッセージがアプリケーションセマンティクスを破る場合に、複製メッセージを検出および廃棄する必要から解放される。同様に、ＡＬＯ保証は、送信側アプリケーションによって送信されるメッセージすべてを受信側エンドポイントが受信することを可能にし、それによってアプリケーションが、紛失したメッセージまたは誤って送られたメッセージを検出し、その再送信を調整する必要から解放される。ＩＯ保証は、送信側アプリケーションで送信された順番でメッセージを受信側アプリケーションに配信することを可能にする。これにより、アプリケーションは、メッセージの順序違い（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）受信を処理する必要から解放される。
【００２３】
ダイアログ２００はまた、セッションＴＴＬ保証も提供するが、これには、セッションＴＴＬが満了する前にパートナのエンドポイントのパートナ間におけるダイアログセッションを完了することが必要となる。ダイアログセッションが完了する前にセッションＴＴＬが満了した場合、ダイアログチャネルは障害状態に置かれ、障害の通知がアプリケーションに提供される。アプリケーションは、再度ＴＴＬのネゴシエーションを行うことによってセッションＴＴＬを延長することができる。
【００２４】
ダイアログによって、所与のアプリケーションおよび配置（ｄｅｐｌｏｙｍｅｎｔ）の所定の要件を満たすため、こうしたメッセージ配信の保証を個々に、または任意の組合せで使用することが可能となる。例えば、ＡＭＯ、ＡＬＯ、およびＩＯの３つの保証の組合せにより、ＴＣＰ／ＩＰなどのほとんどの信頼性の高い通信機構に典型的な、確実に１回、順序ごと配信が提供される。しかし、典型的な通信機構、およびそれに対応するプログラミングモデルとは異なり、アプリケーションが使用するプログラミングモデルを変更することなく、こうした保証をカスタマイズすることができる。
【００２５】
ダイアログ２００により、構成することができる保証が可能となるだけでなく、互いに独立に、かつ上記で選んだ保証とは無関係にローカルの高信頼性メッセージ交換の機能を選び、構成することも可能となる。こうしたローカルの高信頼性メッセージ交換の機能は、プログラミングモデルに一体化されたものと、アプリケーションプログラムとは無関係のカスタマイズに関するものとの２つの別個のカテゴリに分けられる。例えば、一体化されたローカルの機能には、アプリケーションに対して整合性、独立性、および原子性（ａｔｏｍｉｃｉｔｙ）のセマンティクスを有する処理済みバッファリング機能、またはプロファイルをセッションと関連付けて独立なカスタマイズを可能にするプロファイル参照が含まれる。カスタマイズが可能なローカルの機能には、以下で説明するように、セッション状態記憶の構成、バッファ割当（ｑｕｏｔａ）、送信タイムアウト情報、構成が可能なメッセージＴＴＬ、セッション優先順位メッセージ、またはポイズンメッセージを検出するしきい値を含めることができる。
【００２６】
本発明の例示される実施形態によれば、ダイアログ２００は、ダイアログストア２６０と呼ばれる置換えが可能なコンポーネントとしてセッション状態およびメッセージのストレージを提供する。ダイアログストア２６０は置換えが可能であるので、第３者がダイアログストア２６０を独自に実装して配布することができる。管理者は、所与のインストールにおいて実際に使用するダイアログストアを選ぶことができる。したがって、この機構により、非常に高い柔軟性を得ることができ、永続性、性能、自律性（ａｕｔｏｎｏｍｙ）、および管理目標が満たされ得ることとなる。ダイアログストア２６０は、メモリ内ストレージ、ディスク上の永続ストレージ、デーモンプロセスのストレージ、不揮発性メモリ内ストア、光ストレージ、磁気テープ、ネットワーク装着ストレージ、または取外し可能ストレージのうち少なくとも１つを有するプラグ接続が可能な（ｐｌｕｇｇａｂｌｅ）ストアとすることができる。さらに、ダイアログストアはリモートまたはオフノードとすることができる。
【００２７】
本発明の例示される実施形態によれば、すべての状態をアプリケーションメモリ内に保つメモリ内ダイアログストア（例えばダイアログストア２６０）が実装される。このストアは、その状態への非常に高速なアクセスを提供する。しかし、この代償としてアプリケーションプロセスの状態が失われた場合（例えばアプリケーションに、またはアプリケーションの実行に障害が発生したシステムのために、例えばユーザがアプリケーションを終了したり、オペレーティングシステムがアプリケーションを終了したりする場合）、すべての状態が失われる。
【００２８】
他の例示される実施形態によれば、高速ダイアログストア（例えばダイアログストア２６０）が実装されて、別々の専用デーモンプロセスのメモリ内に状態が維持される。このダイアログストアにより、その状態がアプリケーションプロセス障害にかかわらず維持されることが保証される。しかし代償として、状態を維持するためにプロセスの切換えが行われる。デーモンプロセスに障害が発生し、あるいはオペレーティングシステムまたはコンピュータノードに障害が発生した場合、担当するセッションについての全状態が失われる。
【００２９】
ダイアログストア実装の別の実施形態によれば（例えばダイアログストア２６０）、セッション状態情報が、構造化照会言語（ＳＱＬ）サーバなどのデータベース内に永続的に維持される。この永続的に維持される状態は、コンピュータノードまたはオペレーティングシステムの障害を超えて残ることができるが、代償として、その状態を維持するためにディスク書込みが行われる。状態の保守のためにＳＱＬサーバなどのデータベースシステムを使用する利点の１つは、重要なアプリケーション状態の定期的なバックアップおよび回復を行う代わりに、インストールすること自体で、ツール、技法、およびプロセスを既に適切に用意することができることである。
【００３０】
また、本発明においては、ローカルコンピュータノードまたは別のノード上で動作するように構成できるようなダイアログストアがあるようにすることができる。例えば、ＳＱＬサーバなどの永続ダイアログストアを、ローカルのサーバデータベースまたは別のノード上のデータベースを使用するように構成することができる。他のノードはクラスタ化システムの一部でよく、したがって非常に高い可用性を有する。
【００３１】
本発明はまた、アプリケーションによって使用される特定の配置特性を満たすように複数のストア（またはストア構成）が同時に存在できるようにする。さらに、負荷または容量要件の増大などの変化に対処し、新しいストレージの選択肢を利用し、または他の配置環境の考慮すべき点に対処するために、異なるストア（またはストア構成）を使用するようにアプリケーション構成を変更することができる。さらに、同一のアプリケーション内の異なる通信セッションが異なる構成要件を有することができる。ダイアログにより、各セッションを個々に構成することが可能となる。例えば、アプリケーション内のあるセッションは、永続状態ストレージにおいて最もうまく働く可能性があるが、他のセッションは、揮発性状態ストレージにおいて最もうまく働くかもしれない。ダイアログストアは、プロファイル（以下で説明する）を介して構成し、またはアプリケーションコードで記述することができる。
【００３２】
ダイアログ２００で提供される別の構成が可能な機能には、バッファ割当がある。ダイアログ２００は、送信側アプリケーションおよび受信側アプリケーションでメッセージをバッファリングする。このバッファリングにより、２つのアプリケーションの自律性が向上し、一方の側が、動作中ではない場合、または例えばネットワークパーティションのために到達できない場合であっても、他方の側が、そのローカルバッファにメッセージを送信し、またはそのローカルバッファからメッセージを受信することが可能となる。例えば、アプリケーション２０５は、他方が一時的に使用不能、すなわち動作中ではなく、または到達不能であっても引き続きメッセージを送信することができる。これは、メッセージを首尾よく転送することができるまでローカル送信バッファ２５０内にメッセージを蓄積することによって実施される。同様に、アプリケーション２０５は、メッセージを送信したアプリケーションが現在は動作することができない場合であっても、受信バッファ２４５内に先にバッファリングされたメッセージを受信することができる。ダイアログ２００は、システムでバッファリングする最大メッセージ数（メッセージサイズに左右される）を定義する構成が可能なバッファ割当を提供する。したがって、これにより、ダイアログ状態２３５において消費するスペースの量が制限され、他のエンドポイントによって消費することができるローカル資源が制限される。これにより、アプリケーションが指定のメッセージ数をローカルにバッファリングするのに十分なスペースをメッセージ交換システムが確保することも可能となる。ダイアログ２００はまた、メッセージ交換の下部構造によってバッファリングされる最小メッセージ数を定義する最小バッファ割当を提供する。最小バッファ割当と最大メッセージサイズの組合せにより、メッセージ交換の下部構造によってバッファリングされる最小バイト数が定義される。バッファ割当は、プロファイル（以下で説明する）を介して構成することができ、またはアプリケーションコードで記述することができる。
【００３３】
ダイアログ２００はまた、構成が可能な送信タイムアウトの機能も提供する。メッセージが送信されたとき、メッセージはダイアログストア２６０／送信バッファ２５０内に配置される。バッファが満杯である場合、すなわちバッファ割当に達した場合、送信タイムアウトが満了し、またはメッセージを保持するためにバッファ中のスペースが使用可能となるまで、Ｓｅｎｄ（）２１０に対する呼出しがブロックされる。メッセージが首尾よく受信側エンドポイントに転送され、受信側エンドポイントによって確認され、もはやローカルのエンドポイントで再試行する必要がないときに、バッファ内のスペースが使用可能となる。送信タイムアウトが満了する前にスペースが使用可能となった場合、Ｓｅｎｄ（）２１０呼出しは正常終了する。スペースが使用できるようになる前に送信タイムアウトが満了した場合、メッセージを首尾よくバッファリング（キャプチャ）することができなかったという通知をアプリケーションに提供するという例外が発生する。したがって、アプリケーションは後で再試行することができる。構成が可能なタイムアウト情報により、アプリケーションは、ブロッキングの簡潔性に優先して応答性の程度を選ぶことができる。送信タイムアウト情報は、プロファイル（以下で説明する）を介して構成し、またはアプリケーションコードで記述することができる。
【００３４】
前述のように、ダイアログ２００は、エンドツーエンドのセッションＴＴＬ保証をサポートする。ダイアログ２００はまた、ローカルの機能として構成が可能な任意選択メッセージ生存期間も提供する。メッセージＴＴＬは、送信されたメッセージが、ＴＴＬで指定された時間内に受信側エンドポイントで首尾よく受信されなければならないことを要求し、そうでない場合、アプリケーション２０５に対してエラーが生成される。ダイアログ２００はまた、メッセージＴＴＬについての構成が可能な延長も提供する。したがって、ＴＴＬが満了したとき、通知が送信側アプリケーション２０５に提供される。次いでアプリケーション２０５は、ダイアログを終了するか、またはメッセージのＴＴＬを延長するかの選択肢を有する。送信タイムアウト情報と同様に、ＴＴＬは、アプリケーションコードで設定することができ、またはプロファイルを使用して間接的に構成することができる。
【００３５】
ダイアログ２００によって提供される別の機能は、割り当てられる任意選択の優先順位である。ダイアログ２００内のすべてのメッセージは同一の優先順位を有する。しかし、複数のダイアログからのメッセージを送信のために使用可能であるとき、メッセージの送信の際に、高い優先順位を有するダイアログが、低い優先順位を有するダイアログよりも優先される。同様に、受信側アプリケーションに「配信」するためにメッセージが使用可能であるとき、高い優先順位を有するメッセージが、低い優先順位を有するメッセージの前に受信される。優先順位は、アプリケーションコードで設定することができ、または以下で説明するプロファイルを使用して間接的に設定することができる。
【００３６】
ダイアログ２００はまた、任意選択でメッセージをトランザクション処理させるバッファリングも提供する。ダイアログがトランザクションと共に使用されるとき、ローカル送信／受信バッファは、トランザクション資源マネージャとして動作する。この場合、トランザクション結果に応じて、トランザクション下で受信されたメッセージは、一時的に配信された（受信バッファから削除された）とみなされる。同様に、トランザクションの結果に応じて、トランザクション下で送信されたメッセージは、一時的にキャプチャされる（送信バッファに加えられる）。そのトランザクションが約束される場合、こうした一時的なメッセージキャプチャおよび配信は永続的なものとなる。トランザクションが打ち切られる場合、こうした一時的演算は、それが決して発生しなかったかのように破棄される。他のトランザクション資源マネージャと同様に、ダイアログストアは、一時的なバッファ演算のためのトランザクション分離（例えば、キャプチャされるメッセージは、トランザクションの外部では不可視である）と、トランザクションマネージャの制御下でトランザクションが完了するトランザクション原子性とを提供しなければならない。
【００３７】
トランザクションのバッファリングにより、（障害または並行する活動に面しても正確な状態遷移を行う）正確なメッセージ交換アプリケーションの開発が単純になる。アプリケーションは、この機能を使用してメッセージ交換およびローカルのメッセージ処理を調整することができる。例えば、アプリケーションは、トランザクションの範囲内でメッセージを受信し、処理することがある。このメッセージ処理は、１つまたは複数のトランザクションデータベースの読取りおよび更新、ならびにトランザクション内に含まれるダイアログに対する１つまたは複数のメッセージの送出を含む可能性がある。トランザクションが打ち切られる場合、作業のすべては行われない。具体的には、一時的に送信されたメッセージが破棄され（すなわち、セッションパートナはこうした一時的結果を見ない）、受信したメッセージは依然として配信のために使用可能である。後者により、新しいトランザクションの範囲内でメッセージを処理することが可能となる。トランザクションが約束されるとき、受信したメッセージの削除や送信したメッセージのバッファリングを含むこの活動のすべてが永続的となる。正味の影響は、確実に１回メッセージ処理である。トランザクションバッファリングは、アプリケーションがこの機能を使用するか否かがそのセッションパートナのアプリケーションにとって完全に透過的であるという意味で、ローカルのダイアログ機能である。
【００３８】
例示される実施形態によれば、図２を参照して以下で説明するように、Ｓｅｎｄ（）２１０が呼び出されたとき、送信側エンドポイントで、メッセージがダイアログストア２６０内に一時的に配置される。トランザクションが約束される場合、メッセージがストア２６０にコミットされ、パートナのエンドポイントに送信するために使用可能となる。トランザクションが打ち切られた場合、メッセージは廃棄される。受信側では、Ｒｅｃｅｉｖｅ（）２１５（またはＤｅｌｅｔｅ）が呼び出されたとき、メッセージはダイアログストア２６０から一時的に削除される。トランザクションが約束される場合、メッセージはストア２６０から永久に削除される。トランザクションが打ち切られる場合、メッセージはストア２６０内にとどまり、再配信のために使用可能である。処理済み受信により、メッセージの確実に１回処理が可能となる。
【００３９】
トランザクション処理させるバッファリングはキューイングシステムの一般的な機能であるが、こうしたシステムは一般に永続ストアを必要とすることに留意されたい。ダイアログ２００は、ダイアログストア２６０の永続性の如何にかかわらず、こうした同一のトランザクションセマンティクスを提供し、すべての場合に同一のプログラムモデルを提供する。例えば、メモリ内ストアは、トランザクション資源マネージャとして参加することによってトランザクションセマンティクスを提供する。しかしダイアログ２００により、伝送機構および接続性特性、メッセージルーティング、並びにエンドポイント状態管理に関連する詳細を含む配置の詳細と、アプリケーションの実装とを分けて考えることが可能となる。
【００４０】
ダイアログ２００によって提供される別の機能は、任意選択のポイズンメッセージ機能である。前述のように、メッセージがトランザクション下で受信および処理され、トランザクションが打ち切られるとき、メッセージはダイアログストア２６０内にとどまり、アプリケーションに再配信するために使用することができる。場合によっては、トランザクションのアボートを引き起こす問題は、一時的なもの、例えばデッドロックによるタイムアウト情報であり、次の試行時に配信およびメッセージ処理が続く。所与のメッセージに対する配信の試行が繰り返しアボートを引き起こす場合、そのメッセージは「ポイズン」とみなされる。ダイアログ２００は、何回メッセージ配信がアボートするとメッセージがポイズンとみなされるかということを構成する方法を提供する。ポイズンメッセージが検出されたとき、アプリケーションに対してエラーが発生し、アプリケーションが正しい動作を行うまで、メッセージを処理する際の試行がそれ以上行われないように停止される。これにより、決して成功しない作業、または何らかの介入をしなければ成功しない作業をあえて試み、処理資源を浪費しないよう保証する。ポイズンメッセージ検出は、プロファイル（以下で説明する）を介して構成することができ、またはアプリケーションコードで記述することができる。
【００４１】
任意選択のプロファイルの機能は、名前付きの１組のダイアログを構成する選択肢を提供する。前述のように、バッファ割当、タイムアウト情報、ストアなどの、ダイアログの多数の構成が可能な機能が存在する。さらに、ダイアログ２００は、構成が可能なメッセージの配信の保証、例えばＡＬＯ、ＡＭＯ、およびＩＯを提供し、アプリケーションコードが、望むなら構成を通じて増加させることができる望ましい配信保証の最小レベルを独立に指定することができる。プロファイルは、共通ダイアログ設定をグループ化し、その設定を名前で参照する方法を提供する。さらに、ダイアログ２００実装により、管理者が各設定にわたって配置時間制御を有するように、アプリケーション構成ファイルを通じたプロファイルの選択が可能となる。ダイアログを作成または受諾するとき、アプリケーションは、名前によってプロファイルを参照し、プロファイル中で指定されるすべての設定を使用して、ダイアログ２００を作成する。設定は、アプリケーションプログラムの一部、コード、または他のプログラミングの構築として直接確立することができる。コードまたは他のプログラミング構成内の参照によって間接的にプロファイルをプログラムと関連付けることができ、それによってプロファイルの値を、アプリケーションプログラムとは無関係に設定することができる。直接的に確立されたプロファイルの値は、プロファイル参照によって間接的に設定されたプロファイルの値より優先される。
【００４２】
ダイアログ２００は、こうした機能および保証の組合せを互いに独立に提供するので、伝送制御プロトコル（ＴＣＰ）およびリモート手続き呼出し（ＲＰＣ）と類似の密結合プログラミングモデルから、データグラムおよびキューに類似の疎結合プログラミングモデルまでの任意の結合構成を満たすようにダイアログ２００を構成することができる。加えて、ダイアログ２００は、片方向対話、半二重（単一の要求／応答からより複雑なパターンまで）対話、最も複雑な全二重対話などの様々な２者間メッセージ交換パターン（ＭＥＰ）を効率的にサポートする。したがって、ダイアログ２００により２者間通信プログラミングモデルの統一が可能となる。
【００４３】
図２に、本発明の例示される実施形態によるダイアログ２００の動作の特徴を示す。ダイアログチャネルアプリケーションプログラミングインターフェース（ＡＰＩ）２２０が、アプリケーション２０５に対するアブストラクションとして提供される。前述のように、ダイアログ２００は、一続きのメッセージを定義するウェブサービス、例えば高信頼性メッセージ交換（ＷＳ−ＲＭ）などのメッセージ交換のプロトコルを使用する。シーケンスは、セッション内の単一の方向の１組のメッセージを定義する。このような２つのシーケンスが組み合わされて、シーケンスが２つの通信者間の各方向となる１つのダイアログが形成される。チャネル２２０メソッドＳｅｎｄ（）２１０が呼び出されるとき、Ｓｅｎｄメソッド２１０に対するパラメータとして渡されるメッセージが、送信状態２５０に格納され、メッセージが送信された順番に従って、単調増加のメッセージシーケンス番号で一意的にスタンプされる。
【００４４】
メッセージ２５５は送信状態２５０にバッファリングされ、シーケンス中の個々のメッセージに関する状態が維持される。この時点で、これらのメッセージは状態２５０に「キャプチャ」されていると呼ばれ、Ｓｅｎｄ（）２１０はアプリケーションに返される。より具体的には、送信メソッド２１０は、パラメータとして１つのメッセージを受諾する。このメッセージが、シーケンス番号でスタンプされる送信バッファ２５０に渡され、その後で、または同時にストア２６０内に格納される。この時点で、メッセージが「キャプチャ」されているとみなされ、送信メソッド２１０は戻る。この呼出しを他のメッセージで反復することにより、メッセージ２５５のシーケンスまたは部分シーケンスが得られる。
【００４５】
ダイアログ状態２３５は、送信バッファ２５０および受信バッファ２４０を含む。ダイアログ状態２３５は、ダイアログ識別子、アプリケーションにより指定される保証、およびパートナのエンドポイントアドレスなどの不変の情報を管理および格納する。ダイアログ状態２３５はまた、次の発信送信シーケンス番号や肯定応答状態などのセッション情報も管理する。さらに、ダイアログＴＴＬ、タイムアウト情報、ストアの位置などの構成データがダイアログセッション状態２３５内に保持される。
【００４６】
メッセージがキャプチャされると、プロトコル部２７０は、キャプチャされたメッセージ、例えばメッセージ２７５の処理および送信、したがってポート２８５を通じて処理および送信が可能となる。ダイアログ２００に関するプログラミングモデルおよびランタイムの構造により、柔軟で効率的なエンドポイントの解決（ｒｅｓｏｌｕｔｉｏｎ）モデルが提供される。
【００４７】
このモデルは少なくとも、２つのエンドポイントを効率的に解決して高信頼性のメッセージ交換の実現を保証する。具体的には、プロトコル部２７０は、ダイアログ内の初期メッセージを配信して処理を行う前に、両方のエンドポイントがエンドポイント一意性を保証するのに十分な基準と、ダイアログ２００を介するメッセージの正確な相関と、その対応するセッションとを保持することを保証することができる。これは例えば、高々１回配信を保証するようにメッセージが単一のセッションパートナに高い信頼性をもって配信されることを保証するのに必要である。このエンドポイントの解決は、ダイアログ２００の作成者によって使用されるパートナアプリケーションを識別する識別子（例えば汎用資源識別子（ＵＲＩ））、ローカル構成、メッセージヘッダ中のルーティングデータ、中継点構成、およびターゲットアプリケーション構成を含む複数の因子に基づくことができる。
【００４８】
アプリケーションの実装２０５がダイアログエンドポイントの解決の詳細にかかわる必要はないことに留意されたい。ダイアログ２００に関する下部構造は、解決プロセスを実施して、開始側エンドポイントと協調し、開始側エンドポイントがセッションに対して一意的に選択されたピアエンドポイントであることを保証する。これは、必要に応じて行われ、アプリケーション実装２０５にとって透過的である。
【００４９】
メッセージ配信目標を達成することを確実にするためにダイアログに関する実行時のエンドポイント解決が提供される一方、広範なネットワーク構成において正しい実行を達成するために柔軟性が提供される。この機能は、拡張性、可用性、セキュリティ（ファイアウォールなど）、および性能の要件に対処するために、様々な構成でのアプリケーションの柔軟な配置をサポートする。サービス配置の構成は、例えばアプリケーションファーム（例えばスケールアウトレプリカ）やアプリケーションパーティション（例えば顧客番号または地理的領域による区分処理）を含む。アプリケーションファームおよびパーティションは、別々に使用することができ、または一緒に使用することができる。例えば、アプリケーションパーティションへのデータ依存ルーティングを使用するようにアプリケーションを配置することができる。アプリケーションパーティションは、アプリケーションサーバのファームからなる。
【００５０】
プロトコル部２７０はまた、上述のエンドポイント解決を実施するための方法とは無関係に、アプリケーション２０５によってどの種類のエンドツーエンド保証およびローカルの機能が指定されたかを判定する。アプリケーション２０５がＡＬＯ保証を指定した場合、プロトコル部２７０は、メッセージ２７５が適切に受信されたという肯定確認応答を受信側（図示せず）から受信するまで、ダイアログの送信バッファ２５０内にメッセージ２７５のコピーを保持する。プロトコル部２７０が受信側から肯定確認応答を受信したとき、プロトコル部２７０は、そのことをセッション状態２３５内に記録し、送信バッファ２５０からメッセージを削除する。プロトコル部２７０が指定の再試行タイムアウト内に肯定確認応答を受信しなかった場合、プロトコル部は、同一のメッセージシーケンス番号を有する同一のメッセージ２７５のコピーを再送信する。ダイアログ２００は、何回かこのプロセスを反復することができ、ネットワーク上でさらに輻輳が発生するのを回避するために再試行タイマバックオフ法を使用することができる。肯定応答がメッセージＴＴＬによって指定される時間枠内に受信されない場合、エラーが発生し、保証を満たすことができないことが送信側アプリケーション２０５に通知される。
【００５１】
ダイアログメッセージ２８０を受信したとき、プロトコル部２７０は、メッセージを受信バッファ状態２４０内にコピーする。プロトコル部２７０はまた、次の予想されるメッセージシーケンス番号を記録する。メッセージ２８０を受信した場合、ダイアログ２００の保証がＡＭＯを含むとき、到着メッセージ２８０のメッセージシーケンス番号は、受信バッファ状態２４０内に前述のように格納される先に到着したメッセージシーケンス番号の組と比較される。この組が合致するシーケンス番号を既に含む場合、メッセージ２８０は複製とみなされて廃棄される。そうでない場合、後の参照のためにメッセージ２８０がローカルの受信バッファ２４０内に配置される。
【００５２】
保証がＡＬＯを含む場合、プロトコル部２７０は、メッセージ２８０の受信時に順序付けられていない完全に選択的な肯定確認応答をダイアログに関するパートナのエンドポイントに送信する。この確認応答は、セッションでそれまでに受信したすべてのメッセージのシーケンス番号を含まなければならない。１組のシーケンス範囲を含む略記法を使用して、メッセージ空間を節約することができる。
【００５３】
指定された保証がＩＯを含まない場合、メッセージ２８０は、受信チャネル２２０を介して受信側アプリケーション２０５に「配信」するために即座に使用可能にされる。具体的には、メッセージが受信のために使用可能であるという通知がアプリケーション２０５に送信される。次いでアプリケーション２０５は受信側２１５を呼び出し、その結果、配信のために使用可能な次のメッセージがアプリケーション２０５に渡され、これは「配信」が行われたと呼ばれる。
【００５４】
保証としてＩＯが指定された場合、到着メッセージ２８０のシーケンス番号が、次の予想されるシーケンス番号と比較される。シーケンス番号が次の予想されるシーケンス番号より小さい場合、到着メッセージ２８０が廃棄される。それらが合致する場合、到着メッセージ２８０は即座に、受信側アプリケーション２０５に配信することができるようにされ、次の予想されるシーケンス番号が、次の欠落メッセージの番号に設定される。シーケンス番号が次の予想されるシーケンス番号よりも大きい場合、動作は、保証としてＡＬＯ指定されるか否かに左右される。ＡＬＯの保証が指定されない場合、メッセージ２８０は即座に、受信側アプリケーション２０５に配信することを可能にされ、次の予想されるシーケンス番号が、到着メッセージ２８０のシーケンス番号よりも１つ大きい番号に設定される。ＡＬＯの保証が指定される場合、メッセージ２８０は受信側アプリケーション２０５に配信することが可能とはならないものの、受信バッファ２４０内にとどまる。したがって、それらが合致しない場合、小さいシーケンス番号の少なくとも１つの他のメッセージを受信していないと推定される。そのような欠落した小さい番号のメッセージすべてが到着したとき、メッセージの連続的範囲が、適切なシーケンスとして受信側アプリケーションに配信するのに使用可能となり、次の予想されるシーケンス番号が、次の欠落メッセージの番号に設定される。
【００５５】
前述のように、メッセージが受信側アプリケーション２０５に配信することが可能なとき、受信側アプリケーション２０５に対して通知が発行される。次いで受信側アプリケーションは、ダイアログチャネル２２０上でＲｅｃｅｉｖｅ（）メソッド２１５を呼び出し、使用可能な次のメッセージの配信を受諾する。Ｒｅｃｅｉｖｅ（）は、使用可能な各メッセージを受信するために複数回呼び出すことができる。順序を確実にするために、イベント通知が逐次配信される。したがって、メッセージがアプリケーション２０５に配信することが可能なとき、ダイアログ２００イベントと共に先に登録されたアプリケーションコードを呼び出すことにより、単一のイベント通知がアプリケーション２０５に配信される。アプリケーションコードに対するその呼出しが返るまでは、他のメッセージが配信することが可能な場合であっても、そのアプリケーションコードへの他の呼出しは行われない。そのアプリケーションコード内で、アプリケーション２０５は通常、Ｄｉａｌｏｇ  Ｒｅｃｅｉｖｅ（）２１５を呼び出して、次の使用可能なメッセージを受信する。
【００５６】
やはり前述のように、Ｓｅｎｄ（）２１０が呼び出されたとき、現在送信バッファ２５０中にあるメッセージ数が、指定のバッファ割当と比較される。現在送信バッファ２５０中にあるメッセージ数がその割当を超過する場合、空間が使用可能となるまで、または送信タイムアウトとなるまで、イベントに対して呼出し元Ｓｅｎｄ（）２１０がブロックされる。送信バッファ２５０内の空間が利用可能となったとき、バッファは、メッセージの送信を待機する何らかの呼出し元が存在するか否かをチェックされる。そうである場合、呼出し元Ｓｅｎｄ（）２１０がブロック解除され、再びメッセージを送信することができる。
【００５７】
メッセージバッファ２５０および２４０、チャネル２２０、ならびにプロトコル部２７０内を含むダイアログ２００に関するすべての状態を、ダイアログストア２６０内に同時に保持することができる。ダイアログストア２６０は、最新の情報を含むべきである。これにより、ダイアログ状態２３５がダイアログストア２６０の永続性プロパティを確実に有することとなり、すべての機能が、使用中のストア２６０にかかわりなく機能することが可能となる。例えば、メッセージ２８０を受信バッファ２４０内に配置することには、ストア２６０へのディスク書込みが関係する可能性がある。保証を実現するために、確認応答は、メッセージがストア２６０内に記録された後でないと送信されない。これにより、例えば、送信側または受信側がメッセージのコピーを常に確実に有するようにされる。同様に、送信側では、Ｓｅｎｄ（）２１０は、メッセージがストア２６０内に記録された後でなければ完了しない。
【００５８】
前述のように、ダイアログストア２６０はプラグが可能なストアであり、これは非常に高い柔軟性によって、永続性、性能、自律性、および管理の目標に合致させることを可能となる。例えば、アプリケーションメモリ内のすべての状態を保持するメモリダイアログストアの実装、別々の専用デーモンプロセスのメモリ内の状態を保持する高速ダイアログストアの実装、または構造化照会言語（ＳＱＬ）サーバなどの永続データベースストアの実装を含む単一のフレームワーク内の複数のストアのうちの１つからストア２６０を選択することができる。同一のアプリケーション２０５内の異なるダイアログが、異なるストアを使用することができる。さらに、本発明により、いくつかのダイアログストア２６０をローカルのコンピュータノードまたは別のノード上で動作するように構成することも可能となる。
【００５９】
ダイアログ２００はアプリケーション２０５の代わりにエージェントとして動作するので、アプリケーション２０５は、接続性が変化することとは別におかれる。これにより、例えば、アプリケーションが実行され、いくつかのメッセージを送受信し、次いで他のエンドポイントが応答し、さらには待機して利用可能とする必要ない状態で終了するようなバッチスタイルの処理が可能となる。さらに、様々な配信の保証およびローカルの機能、例えばメッセージまたはセッションＴＴＬに合致することだけに依存する非常に柔軟にメッセージ配信をスケジューリングすることができる。例えば、配信の保証に応じて、ダイアログ２００はピークメッセージの負荷をある期間に分散することができ（負荷平衡）、あるいは、アプリケーション２０５とは独立に、メッセージ配信をよりコスト効率の良い時間にシフトし、資源が使用可能となるまで待機し、メッセージまたはダイアログの優先順位を調節することなどを行う。加えて、ストア２６０は、アプリケーション２０５に対してシャットダウンの機能および再始動の機能を提供する。バッチ処理、スケジューリング、ならびにアプリケーションのシャットダウンの機能および再始動の機能により、システムの可用性および拡張性が向上する。
【００６０】
加えて、前述のように、アプリケーション２０５は、Ｓｅｎｄ（）２１０およびＲｅｃｅｉｖｅ（）２１５演算をダイアログバッファ２５０および２４０に関して処理することを指定することができる。これにより、アプリケーションは、例えばメッセージを受信し、１つまたは複数のダイアログに関するいくつかのメッセージを送信し、すべて単一のトランザクション内にあるアプリケーションテーブルを更新することが可能となる。このようなトランザクションの使用法においては、これは単にローカルの概念であって他のエンドポイントに搬送したりされない。
【００６１】
ダイアログはまた、実行中の障害回復も提供するが、これは、アプリケーションの実装を使用せずに、多くの障害２６５を自動的に回復（マスク）させることができる。アプリケーションは、ダイアログ２００の寿命の間にアサートされた特性（すなわち、アサートされた保証および機能）を受信することができる。ダイアログ２００またはプロトコル部２７０についての下部構造により、アサートされる特性がもはや満たされないと判定された場合、主要なアプリケーションコードと、またはアプリケーション２０５とさえ無関係に動作する帯域外の訂正を考慮して、ダイアログは障害状態に配置され、障害イベントが生成される。障害２６５を訂正（修復）することができる場合、ダイアログをサービスに戻すことができる。回復不能な障害、すなわち修復することができない障害は、ダイアログ２００およびアプリケーション通知が終了する結果となる可能性がある。このような設計は、高信頼性のアプリケーションの開発の基礎となる「フェイルファースト（ｆａｉｌ−ｆａｓｔ）」モデルに準拠する。
【００６２】
致命的でない障害には、メッセージの破壊、紛失、重複、または遅延、伝送機構およびネットワークの障害、プロセス障害、中継点障害、ならびにシステム障害を含めることができる。前述のように、ダイアログ２００がアプリケーションにアブストラクションを提供し、それ自体のバッファおよびストアを維持するので、ダイアログ２００は、断続的に接続されるアプリケーションおよび環境もサポートする。ダイアログはまた、ネットワークトポロジに対する変化、再ネゴシエーションされたセキュリティコンテキスト、またはエンドポイントの再配置などの環境の変化に適合することもできる。
【００６３】
ダイアログ２００はそれ自体で、例えばメッセージを再送信することよってこうした障害を自動的に修復するよう企図することができる。これに代えて、またはこれとともに、ダイアログ２００は、第３者、例えばシステムオペレータまたは診断用のコードに要求を送信して、障害を修復する際の助けを求めることができる。この助けは例えば、ネットワーク内の断線を修復する単純な人間による介入とすることができ、または場合によっては自動修復プロセスとすることができる。いずれの場合も、障害を修復した後は、ダイアログ２００はメッセージの送信を続行することができる。これらを他の可用性の機能と組み合わせることにより、長寿命のダイアログが可能となる。しかし、ダイアログ２００または何らかの他の第３者の介入によって障害を解決することができない場合、ダイアログを開始したアプリケーション２０５に対してエラーメッセージを生成すべきである。
【００６４】
アプリケーションプロセス障害および再始動にわたってダイアログを維持することを可能にするダイアログストア２６０を使用するようにアプリケーションを構成することができる。加えて、何らかのストア２６０により、システム障害および再始動を許容することができる。
【００６５】
ドメイン固有の障害ハンドラと前述の基本メッセージ再送信サポートとの組合せにより、他の伝送障害を自動的に処理することができる。その例には、セキュリティ証明書（ｃｒｅｄｅｎｔｉａｌ）またはポリシー満了の結果として生じる障害が含まれる。保護セッション上で送信されたメッセージに、証明書満了のために障害が発生した場合、ダイアログ２００は、セキュリティ証明書を再ネゴシエーションし、ダイアログの障害をクリアすることができる。ダイアログの処理が再開したとき、バッファリングされたメッセージは、標準の再試行プロセスによって更新された証明書と共に再送信される。
【００６６】
やはり前述のように、ダイアログ２００に関する設計および対応する下部構造により、ランタイムが実行環境の変化にダイアログ２００を動的に適合させることが可能となる。これは、アプリケーション実装にとって透過的に実現することができ、長寿命のダイアログおよび高いレベルで使用可能なアプリケーションを可能とする。
【００６７】
障害ハンドラ（プラグすることが可能）と、送信および配信の再試行と、障害および修復モデルとの上述の組合せにより、ダイアログは多くの環境変化に適合することが可能となる。こうした変化には、限定はしないが、ポリシーの変化（例えばメッセージプライバシー）、プロトコルの変化（例えば新しいセキュリティプロトコルのサポート）、ネットワークトポロジの変化（例えばルータまたはファイアウォールの追加または取外し）、負荷の増大に対処するための配置アプリケーションの変更（例えば、アプリケーションファームおよび／またはパーティションの導入）、およびダイアログのエンドポイントと関連する状態の再配置（例えば、災害回復）が含まれる。これにより、非常に小規模から非常に大規模までをサポートするスケーラブルな配置の選択が可能となる。例えば、ダイアログ２００は、やはりアプリケーションの実装にとって透過的なスケールアップ、スケールアウト、アプリケーション複製、または区分化をサポートする。
【００６８】
図３に、ダイアログ２００のライフサイクルおよび状態を示す。ダイアログ２００は、アクティブ３２０または非アクティブ３６０の２つの主状態の一方とすることができる。ダイアログ２００がアクティブ３２０である場合、ダイアログチャネルオブジェクト２２０がメモリ内にあり、そうでない場合、ダイアログ２００が非アクティブ３６０であり、ダイアログ２００はダイアログストア２６０内にのみ存在する。管理システム資源は、手動または自動で行うことのできる非アクティブ化３５０および再アクティブ化３４０プロセスによって行われる。例えば、非アクティブ化３５０は、アプリケーションがＤｉｓｐｏｓｅを呼び出す場合に手動で行うことができ、またはメッセージがダイアログチャネル上で交換されない場合に一定期間が非活動で経過する非活動時間のために自動的に行うことができる。このようなチャネルを非アクティブ化することが可能となり（対応するオブジェクトがメモリから解放され）、したがって他の事柄のためにメモリ資源が解放される。
【００６９】
再アクティブ化３４０は、アプリケーションがダイアログマネージャ（図示せず）にチャネルを要求する場合に手動で行うことができ、または新しいメッセージがセッションに到着した場合に自動的に行うことができる。ダイアログ作成３１０の間に、ダイアログマネージャによって各ダイアログに固有のＩＤが割り当てられる。このＩＤは、再アクティブ化３４０要求時にアプリケーション２０５によってダイアログマネージャに渡され、ダイアログマネージャはＩＤを使用してダイアログ状態の位置を突き止め、チャネルを再開する。非アクティブ化３５０および再アクティブ化３４０のインターフェースにより、システムが、発信メッセージの送信または着信メッセージの処理のためにアクティブに使用されていないダイアログに関連する処理資源を制限することが可能となる。これにより、下部構造が、ダイアログストア２６０に関連する資源以外の関係する資源を再利用することが可能となる。さらに、この設計により、優先順位または資源可用性に基づくメッセージ送信のスケジューリング、より効率的な送信のためのメッセージのバッチ処理、優先順位または資源可用性に基づくメッセージ配信のスケジューリング、およびより効率的な処理のためのメッセージ配信のバッチ処理を含む資源スケジューリングが可能となる。
【００７０】
ダイアログの作成３１０は、ダイアログマネージャによって制御され、作成３１０機能を呼び出すアプリケーションによって開始することができる。あるいは、メッセージ交換システムは、新しいダイアログが必要であることを示す別のエンドポイントからのメッセージを受信した後に、ダイアログ作成３１０を開始することができる。この場合、システムは、ダイアログが要求されたことをアプリケーション２０５に通知する。次いでアプリケーション２０５は、ダイアログマネージャ上のＡｃｃｅｐｔメソッドを呼び出して、ダイアログ要求を受諾し、ダイアログ作成３１０を引き起こすことができ、またはダイアログマネージャ上のＲｅｊｅｃｔメソッドを呼び出して、ダイアログ要求を拒絶することができる。ダイアログマネージャはまた、ティアダウン（Ｔｅａｒｄｏｗｎ）３３０も制御し、いくつかの理由でそれを開始することができる。１つの理由は、セッションが首尾よく完了し、すなわち両側が送信を終了し、メッセージがもう残っていないということであろう。ティアダウン３３０を制御する別の理由は、ダイアログ２００が終了し、例えばアプリケーションがＴｅｒｍｉｎａｔｅ（）関数を呼び出し、またはパートナのエンドポイントから終了を求める指示を受信したことかもしれない。一方の側がダイアログを終了したとき、これを示すためにメッセージが他方の側に送信される。このメッセージに対する信頼性はなく、単に、ダイアログが終了したことを他方の側に伝えるための試行である。終了は、ダイアログのセッションを介してそれ以上のメッセージが交換されることがないことを示唆する。
【００７１】
本発明の説明では、ダイアログを両方のセッションエンドポイントのパートナでアプリケーションのメッセージを送信および受信することができる二重通信機構と定義するが、別の例示される実施形態には、単信モデルが含まれる。実施形態によれば、一方のセッションエンドポイントは、アプリケーションのメッセージ送信のみを行い、そのパートナのエンドポイントからアプリケーションのメッセージを受信せず、セッションエンドポイントのパートナは、アプリケーションのメッセージの受信のみを行い、アプリケーションのメッセージを送信しない。ダイアログにおいては、同一の構成が可能な保証、および構成が可能なローカルのエンドポイントの機能が適用される。実装は、送信側エンドポイントで受信バッファ２４０が不要であり、受信側エンドポイントで送信バッファ２５０が不要である点で異なる。
【００７２】
本発明の範囲内の実施形態はまた、コンピュータ実行可能命令またはデータ構造を搬送し、または格納するためのコンピュータ読取可能な媒体も含む。このようなコンピュータ読取可能な媒体は、汎用コンピュータまたは専用コンピュータでアクセスすることができる入手可能などんな媒体でもよい。例えば限定はしないが、そのようなコンピュータ読取可能な媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク記憶媒体、磁気ディスク記憶媒体または他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形態の所望のプログラムコード手段を搬送または記憶するのに使用することができ、かつ汎用コンピュータまたは専用コンピュータでアクセスすることができる他のどんな媒体も含めることができる。情報がネットワークまたは他の通信接続（ハードワイヤード、無線、あるいはハードワイヤードと無線の組合せ）を介してコンピュータに転送または供給されるとき、コンピュータはその接続をコンピュータ読取可能な媒体として適切に認識する。したがって、任意のそのような接続が、コンピュータ読取可能な媒体と呼ぶのは適切である。上記の組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。例えばコンピュータ実行可能命令は、ある機能または機能の集まりを汎用コンピュータ、専用コンピュータ、または専用処理装置に実行させる命令およびデータを含む。
【００７３】
図４および以下の議論は、本発明を実施することができる適切なコンピューティング環境の簡潔で一般的な説明を与えるものである。必須ではないが、ネットワーク環境内のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況の下で本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールが、本明細書で開示される方法のステップを実行するプログラムコード手段の例を表す。このような実行可能命令の特定のシーケンス、または関連するデータ構造が、このようなステップで記述される機能を実施する対応する行為の例を表す。
【００７４】
パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で本発明を実施できることを当業者は理解されよう。本発明は、通信ネットワークを介して（ハードワイヤードリンク、無線リンク、あるいはハードワイヤードリンクと無線リンクの組合せによって）リンクされるローカル処理装置およびリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置のどちらにも置くことができる。
【００７５】
図４を参照すると、本発明を実装するための例示のシステムは、従来型コンピュータ４２０の形態の汎用コンピューティング装置を含む。従来型コンピュータ４２０は、処理装置４２１と、システムメモリ４２２と、システムメモリ４２２を含む様々なシステム構成要素を処理装置４２１に結合するシステムバス４２３とを含む。システムバス４２３は、メモリバスまたはメモリコントローラと、周辺バスと、様々なバスアーキテクチャのいずれかを用いるローカルバスとを含むいくつかのタイプのバス構造のいずれでもよい。システムメモリは、読取り専用メモリ（ＲＯＭ）４２４およびランダムアクセスメモリ（ＲＡＭ）４２５を含む。始動中などにコンピュータ４２０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４２６を、ＲＯＭ４２４内に格納することができる。
【００７６】
コンピュータ４２０はまた、磁気ハードディスク４３９を読み書きするための磁気ハードディスクドライブ４２７と、取外し可能磁気ディスク４２９を読み書きするための磁気ディスクドライブ４２８と、ＣＤ−ＲＯＭや他の光媒体などの取外し可能光ディスク４３１を読み書きするための光ディスクドライブ４３０とを含むことができる。磁気ハードディスクドライブ４２７、磁気ディスクドライブ４２８、および光ディスクドライブ４３０は、それぞれハードディスクドライブインターフェース４３２、磁気ディスクドライブインターフェース４３３、および光ドライブインターフェース４３４によってシステムバス４２３に接続される。ドライブと、それに関連するコンピュータ読取可能な媒体とにより、コンピュータ４２０に対して、コンピュータ実行可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性記憶が提供される。本明細書で説明する例示される環境では、磁気ハードディスク４３９、取外し可能磁気ディスク４２９、および取外し可能光ディスク４３１を使用するが、磁気カセット、フラッシュメモリカード、デジタルバーサタイルディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなど、他のタイプのデータ記憶用コンピュータ読取可能な媒体も使用することができる。
【００７７】
オペレーティングシステム４３５、１つまたは複数のアプリケーションプログラム４３６、他のプログラムモジュール４３７、およびプログラムデータ４３８を含む１つまたは複数のプログラムモジュールを有するプログラムコード手段を、ハードディスク４３９、磁気ディスク４２９、光ディスク４３１、ＲＯＭ４２４、またはＲＡＭ４２５上に格納することができる。ユーザは、キーボード４４０、ポインティングデバイス４４２、あるいはマイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどの他の入力装置（図示せず）を介してコンピュータ４２０にコマンドおよび情報を入力することができる。上記およびその他の入力装置はしばしば、システムバス４２３に結合されたシリアルポートインターフェース４４６を介して処理装置４２１に接続される。あるいは、入力装置は、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースによって接続することもできる。モニタ４４７または他のディスプレイ装置もまた、ビデオアダプタ４４８などのインターフェースを介してシステムバス４２３に接続される。モニタに加えて、パーソナルコンピュータは一般に、スピーカやプリンタなどの他の周辺出力装置（図示せず）を含む。
【００７８】
コンピュータ４２０は、リモートコンピュータ４４９ａおよび４４９ｂなどの１つまたは複数のリモートコンピュータに対する論理接続を用いて、ネットワーク環境で動作することができる。リモートコンピュータ４４９ａおよび４４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般にはコンピュータ４２０に関する前述の要素のうちの多くまたはすべてを含むが、図４にはメモリ記憶装置４５０ａおよび４５０ｂと、それに関連するアプリケーションプログラム４３６ａおよび４３６ｂだけを示してある。図４に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５１および広域ネットワーク（ＷＡＮ）４５２を含む。これらは限定的なものではなく、単に例としてここで示したに過ぎない。このようなネットワーキング環境は、オフィス全体または企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００７９】
ＬＡＮネットワーキング環境で使用するとき、コンピュータ４２０は、ネットワークインターフェース／アダプタ４５３を介してローカルネットワーク４５１に接続される。ＷＡＮネットワーキング環境で使用するとき、コンピュータ４２０は、モデム４５４、無線リンク、あるいはインターネットなどの広域ネットワーク４５２を介して通信を確立するための他の手段を含むことができる。モデム４５４は内蔵でも外付けでもよく、シリアルポートインターフェース４４６を介してシステムバス４２３に接続される。ネットワーク環境では、コンピュータ４２０に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。ここで示したネットワーク接続は例示的なものであって、広域ネットワーク４５２を介して通信を確立する他の手段も使用できることを理解されよう。
【００８０】
本発明の精神または不可欠な特徴から逸脱することなく、本発明を他の特定の形態で実施することができる。記載の実施形態は、すべての点において例示的なものに過ぎず、限定的ではないとみなすべきである。したがって、本発明の範囲は、上記の説明によってではなく、特許請求の範囲によって示される。特許請求の範囲の等価の意味および範囲内にあるすべての変更は、その範囲内に包含されるべきである。
【図面の簡単な説明】
【００８１】
【図１】本発明の例示される実施形態に従ってメッセージを送信および受信するための高信頼性メッセージ交換スタックを示す図である。
【図２】本発明の例示される実施形態によるメッセージフレームワークを示す図である。
【図３】本発明の例示される実施形態によるアプリケーションと伝送機構間のリンクのライフサイクルを示す図である。
【図４】本発明に適した動作環境を与える例示されるシステムを示す図である。
【符号の説明】
【００８２】
１００ａ、１００ｂ  高信頼性メッセージ交換スタック
１０５、１８５  アプリケーション
１１５  メッセージ
１２０、１８０  高信頼性メッセージ交換フレームワーク
１３５  中継点
１４０  データグラムメッセージ交換層
１４５、１５５、１７０  伝送機構
１６０、１６５  伝送機構
１９０  セッション状態（送信）バッファ
１９１  メッセージ
１９２  肯定応答メッセージ
１９５  セッション状態（受信）バッファ
２００  ダイアログ
２０５  アプリケーション
２２０  ダイアログチャネル
２３５  ダイアログ状態
２４０  受信バッファ
２５０  送信バッファ
２６０  ダイアログストア
２６５  障害
２７０  プロトコル部
２７５  メッセージ
２８０  ダイアログメッセージ
２８５  ポート
３１０  ダイアログ作成
４２０  従来型コンピュータ
４２１  処理装置
４２２  システムメモリ
４２３  システムバス
４２４  読取り専用メモリ（ＲＯＭ）
４２５  ランダムアクセスメモリ（ＲＡＭ）
４２６  基本入出力システム（ＢＩＯＳ）
４２７  磁気ハードディスクドライブ
４２８  磁気ディスクドライブ
４２９  取外し可能磁気ディスク
４３０  光ディスクドライブ
４３１  取外し可能光ディスク
４３２  ハードディスクドライブインターフェース
４３３  磁気ディスクドライブインターフェース
４３４  光ドライブインターフェース
４３５  オペレーティングシステム
４３６、４３６ａ、４３６ｂ  アプリケーションプログラム
４３７  他のプログラムモジュール
４３８  プログラムデータ
４３９  磁気ハードディスク
４４０  キーボード
４４２  ポインティングデバイス
４４６  シリアルポートインターフェース
４４７  モニタ
４４８  ビデオアダプタ
４４９ａ、４４９ｂ  リモートコンピュータ
４５０ａ、４５０ｂ  メモリ記憶装置
４５１  ローカルエリアネットワーク（ＬＡＮ）
４５２  広域ネットワーク（ＷＡＮ）
４５３  ネットワークインターフェース／アダプタ
４５４  モデム
【図１】
2004295896.tif 000003
【図２】
2004295896.tif 000004
【図３】
2004295896.tif 000005
【図４】
2004295896.tif 000006