(57)【要約】【課題】ＲＭ−ＷＳプロトコルを使用するシステムについての接続生存性を検証し、維持するやり方を提供すること。【解決手段】本発明は、ウェブサービス用の高信頼メッセージングプロトコル（ＲＭ−ＷＳプロトコル）による確立されたシーケンスセッション上の２つのエンドポイント間のメッセージ受信を監視する。受信されるメッセージは、アプリケーションメッセージまたは基盤メッセージ（ＲＭ−ＷＳプログラムによる肯定応答メッセージなど）である。さらに、本発明は、シーケンスセッション上でメッセージ（アプリケーションまたは基盤）を受信せずに経過し得る時間の上限である、非活動タイムアウトとして知られる期間を定義する。この非活動タイムアウト期間に基づいて、本発明は、接続生存性を検証し維持するためのＲＭ−ＷＳプロトコルによる冪等基盤メッセージを送信するための期間を計算する。【選択図】図１Ａ
2006164252.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービス（ＷＳ）環境内の開始側コンピュータシステムで、ＷＳ用の高信頼メッセージングプロトコル（ＲＭ−ＷＳプロトコル）を使用することによってエンドポイント間でシーケンスセッションの接続生存性を維持する方法であって、
ＲＭ−ＷＳプロトコルに従って２つのエンドポイントアプリケーション間のアプリケーション層で、一意のシーケンス識別子によって識別されるシーケンスセッションを確立するステップと、
前記シーケンスセッションの非活動タイムアウト期間を識別するステップであって、前記非活動タイムアウト期間は、前記シーケンスセッションについてのメッセージを受信せずに通過し得る時間の上限を表すステップと、
前記非活動タイムアウト期間に基づくアルゴリズムに従ってキープアライブ満了タイムアウトを計算するステップと、
計算された前記キープアライブ満了タイムアウトに基づいて、前記一意のシーケンス識別子を含むメッセージを送信するステップと、
前記接続生存性を維持する前記非活動タイムアウト期間の前に、前記一意のシーケンス識別子を含むメッセージを受信するステップと、
前記シーケンスセッションが存続され続けるように、受信される前記メッセージに基づいて前記非活動タイムアウト期間の非活動タイマを再設定するステップと
を備えることを特徴とする方法。
【請求項２】
前記一意のシーケンス識別子を含む受信される前記メッセージはアプリケーションレベルのメッセージであることを特徴とする請求項１に記載の方法。
【請求項３】
前記アプリケーションレベルのメッセージは、１つまたは複数のシーケンスセッションについての肯定応答を含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記一意のシーケンス識別子を含む送信される前記メッセージは、前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、受信される前記メッセージは、前記肯定応答要求メッセージに応答した基盤肯定応答メッセージであることを特徴とする請求項１に記載の方法。
【請求項５】
前記肯定応答要求メッセージは、前記受付け側から受信済みとして既に肯定応答されている１つまたは複数のメッセージに対応することを特徴とする請求項４に記載の方法。
【請求項６】
前記肯定応答要求メッセージは複数のシーケンスセッションについての肯定応答要求を含み、受信される前記メッセージは前記複数のシーケンスセッションについての複数の肯定応答を含むことを特徴とする請求項４に記載の方法。
【請求項７】
前記開始側はアドレス指定不可能であり、前記開始側は、ＨＴＴＰを介したＳＯＡＰによって前記受付け側と通信することを特徴とする請求項１に記載の方法。
【請求項８】
前記一意のシーケンス識別子を含む送信される前記メッセージは、前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、前記受付け側に送信されるアプリケーションメッセージはブロックされるが、前記肯定応答要求メッセージはいずれにせよ送信されることを特徴とする請求項１に記載の方法。
【請求項９】
前記キープアライブ満了タイムアウトを計算するための前記アルゴリズムは、前記非活動タイムアウト期間のうちの何らかの割合にさらに基づくことを特徴とする請求項１に記載の方法。
【請求項１０】
前記一意のシーケンス識別子を含む送信される前記メッセージは、前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、前記キープアライブ満了タイムアウトを計算するために使用される前記非活動タイムアウト期間のうちの前記割合は、前記非活動タイマが前記非活動タイムアウト期間の２分の１に達するときに前記肯定応答要求メッセージが送信されるように、前記非活動タイムアウト期間の２分の１であることを特徴とする請求項９に記載の方法。
【請求項１１】
アプリケーションおよび基盤メッセージが送信される最大の回数である最大再試行回数を識別するステップと、
前記最大再試行回数に基づいてキープアライブ間隔を計算するステップであって、前記キープアライブ間隔はメッセージを送信するための期間を表すステップと、
計算された前記キープアライブ間隔に基づいて、前記一意のシーケンス識別子を含む１つまたは複数のメッセージを送信するステップであって、送信される前記１つまたは複数のメッセージは、アプリケーションレベルメッセージまたは肯定応答要求メッセージのうちの少なくとも１つを含むステップと
をさらに備えることを特徴とする請求項９に記載の方法。
【請求項１２】
前記非活動タイムアウト期間は、前記通信媒体によって課される遅延を見込むように調整可能であることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ＲＭ−ＷＳプロトコルはＷＳ高信頼メッセージングであることを特徴とする請求項１１に記載の方法。
【請求項１４】
送信される前記メッセージはアプリケーションレベルメッセージであることを特徴とする請求項１に記載の方法。
【請求項１５】
肯定応答要求メッセージは前記アプリケーションレベルメッセージと共に送信され、前記肯定応答要求メッセージは、前記ＲＭ−ＷＳプロトコルによって定義されており、また前記受付け側からの肯定応答を早めるために使用される基盤冪等メッセージであることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記非活動タイムアウト期間の満了後にアプリケーションまたは基盤メッセージが受信されず、前記シーケンスセッションが放棄されることを特徴とする請求項１に記載の方法。
【請求項１７】
ウェブサービス（ＷＳ）環境内のコンピュータシステムで、ＷＳ用の高信頼メッセージングプロトコルＷＳ（ＲＭ−ＷＳプロトコル）を使用することによってエンドポイントアプリケーション間でシーケンスセッションの接続生存性を検証する方法であって、
ＲＭ−ＷＳプロトコルに従って２つのエンドポイントアプリケーション間のアプリケーション層で、一意のシーケンス識別子によって識別されるシーケンスセッションを確立するステップと、
非活動タイムアウト期間を識別するステップであって、前記非活動タイムアウト期間は、前記シーケンスセッションについて前記２つのエンドポイント間でメッセージを交換せずに通過し得る時間の上限を表すステップと、
前記非活動タイムアウト期間が終了する前に、前記接続生存性を検証するためのメッセージを受信するステップであって、前記メッセージは前記シーケンスセッションに対応する一意のシーケンス識別子を含むステップと、
前記シーケンスセッションが存続され続けるように、受信された前記メッセージに基づいて前記非活動タイムアウト期間のための非活動タイマを再設定するステップと
を備えることを特徴とする方法。
【請求項１８】
前記一意のシーケンス識別子を含む受信される前記メッセージはアプリケーションメッセージであることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記アプリケーションメッセージは、前記一意のシーケンス識別子に対応する前記シーケンスセッションを含む１つまたは複数のシーケンスセッションについての肯定応答を含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
受信される前記メッセージは前記シーケンスセッションの開始側によって受信され、受信される前記メッセージは、前記開始側によって前に送信された肯定応答要求メッセージに応答した基盤肯定応答メッセージであることを特徴とする請求項１７に記載の方法。
【請求項２１】
前記基盤肯定応答メッセージは、前記開始側と受付け側の間の複数のシーケンスセッションについての肯定応答を含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記開始側はアドレス指定不可能であり、前記開始側は、ＨＴＴＰを介したＳＯＡＰによって前記受付け側と通信することを特徴とする請求項２０に記載の方法。
【請求項２３】
受信される前記メッセージは前記シーケンスセッションの受付け側によって受信され、受信される前記メッセージはシーケンス肯定応答要求であることを特徴とする請求項１７に記載の方法。
【請求項２４】
前記非活動タイムアウト期間は、前記通信媒体によって課される遅延を見込むように調整可能であることを特徴とする請求項１７に記載の方法。
【請求項２５】
前記非活動タイマの再設定後、アプリケーションまたは基盤メッセージが前記非活動タイムアウト期間の満了後に受信されず、前記シーケンスセッションが放棄されることを特徴とする請求項１７に記載の方法。
【請求項２６】
ウェブサービス（ＷＳ）環境内の開始側コンピュータシステムで、ＷＳ用の高信頼メッセージングプロトコル（ＲＭ−ＷＳプロトコル）を使用することによってエンドポイント間のシーケンスセッションの接続生存性を維持する方法を実施するためのコンピュータプログラム製品であって、プロセッサによって実行される場合に前記メッセージングシステムに、
ＲＭ−ＷＳプロトコルに従って２つのエンドポイントアプリケーション間のアプリケーション層で、一意のシーケンス識別子によって識別されるシーケンスセッションを確立するステップと、
前記シーケンスセッションの非活動タイムアウト期間を識別するステップであって、前記非活動タイムアウト期間は、前記シーケンスセッションについてのメッセージを受信せずに通過し得る時間の上限を表すステップと、
前記非活動タイムアウト期間に基づくアルゴリズムに従ってキープアライブ満了タイムアウトを計算するステップと、
計算された前記キープアライブ満了タイムアウトに基づいて、前記一意のシーケンス識別子を含むメッセージを送信するステップと、
前記接続生存性を維持する前記非活動タイムアウト期間の前に、前記一意のシーケンス識別子を含むメッセージを受信するステップと、
前記シーケンスセッションが存続され続けるように、受信された前記メッセージに基づいて、前記非活動タイムアウト期間のための非活動タイマを再設定するステップと
を実行させることができるコンピュータ実行可能命令がそれ上に格納された１つまたは複数のコンピュータ読取り可能媒体を備えることを特徴とするコンピュータプログラム製品。
【請求項２７】
前記一意のシーケンス識別子を含む受信される前記メッセージはアプリケーションレベルメッセージであることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項２８】
前記一意のシーケンス識別子を含む送信される前記メッセージは、前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、受信される前記メッセージは、前記肯定応答要求メッセージに応答した基盤肯定応答メッセージであることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項２９】
前記肯定応答要求メッセージは、前記受付け側から受信済みとして既に肯定応答されている１つまたは複数のメッセージに対応することを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３０】
前記開始側はアドレス指定不可能であり、前記開始側は、ＨＴＴＰを介したＳＯＡＰによって前記受付け側と通信することを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３１】
前記一意のシーケンス識別子を含む送信される前記メッセージは、前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、前記受付け側に送信されるアプリケーションメッセージはブロックされるが、前記肯定応答要求メッセージはいずれにせよ送信されることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３２】
前記キープアライブ満了タイムアウトを計算するための前記アルゴリズムは前記非活動タイムアウト期間のうちの何らかの割合にさらに基づくことを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３３】
前記一意のシーケンス識別子を含む送信される前記メッセージは前記ＲＭ−ＷＳプロトコルによって定義された基盤冪等メッセージである肯定応答要求メッセージであり、前記キープアライブ満了タイムアウトを計算するために使用される前記非活動タイムアウト期間のうちの前記割合は、前記非活動タイマが前記非活動タイムアウト期間の２分の１に達するときに前記肯定応答要求メッセージが送信されるように、前記非活動タイムアウト期間の２分の１であることを特徴とする請求項３２に記載のコンピュータプログラム製品。
【請求項３４】
前記メッセージングシステムに、
アプリケーションおよび基盤メッセージが送信される最大の回数である最大再試行回数を識別するステップと、
前記最大再試行回数に基づいてキープアライブ間隔を計算するステップであって、前記キープアライブ間隔はメッセージを送信するための期間を表すステップと、
計算された前記キープアライブ間隔に基づいて、前記一意のシーケンス識別子を含む１つまたは複数のメッセージを送信するステップであって、送信される前記１つまたは複数のメッセージは、アプリケーションレベルメッセージまたは肯定応答要求メッセージのうちの少なくとも１つを含むステップと
を実行させることができるコンピュータ実行可能命令をさらに備えることを特徴とする請求項３２に記載のコンピュータプログラム製品。
【請求項３５】
前記非活動タイムアウト期間は、前記通信媒体によって課される遅延を見込むように調整可能であることを特徴とする請求項３４に記載のコンピュータプログラム製品。
【請求項３６】
前記ＲＭ−ＷＳプロトコルはＷＳ高信頼メッセージングであることを特徴とする請求項３４に記載のコンピュータプログラム製品。
【請求項３７】
前記非活動タイムアウト期間の満了後にアプリケーションまたは基盤メッセージが受信されず、前記シーケンスセッションが放棄されることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３８】
送信される前記メッセージはアプリケーションレベルメッセージであることを特徴とする請求項２６に記載のコンピュータプログラム製品。
【請求項３９】
肯定応答要求メッセージはアプリケーションレベルメッセージと共に送信され、前記肯定応答要求メッセージは、前記ＲＭ−ＷＳプロトコルによって定義されており、また前記受付け側からの肯定応答を早めるために使用される基盤冪等メッセージであることを特徴とする請求項３８に記載のコンピュータプログラム製品。
【請求項４０】
ウェブサービス（ＷＳ）環境内のコンピュータシステムで、ＷＳ用の高信頼メッセージングプロトコル（ＲＭ−ＷＳプロトコル）を使用することによってエンドポイントアプリケーション間でシーケンスセッションの接続生存性を検証する方法を実施するためのコンピュータプログラム製品であって、プロセッサによって実行されるときに前記メッセージングシステムに、
ＲＭ−ＷＳプロトコルに従って２つのエンドポイントアプリケーション間のアプリケーション層で、一意のシーケンス識別子によって識別されるシーケンスセッションを確立するステップと、
非活動タイムアウト期間を識別するステップであって、前記非活動タイムアウト期間は、前記シーケンスセッションについて前記２つのエンドポイント間でメッセージを交換せずに通過し得る時間の上限を表すステップと、
前記非活動タイムアウト期間が終了する前に、前記接続生存性を検証するためのメッセージを受信するステップであって、前記メッセージは前記シーケンスセッションに対応する一意のシーケンス識別子を含むステップと、
前記シーケンスセッションが存続され続けるように、受信される前記メッセージに基づいて、前記非活動タイムアウト期間のための非活動タイマを再設定するステップと
を実行させることができるコンピュータ実行可能命令がそれ上に格納された１つまたは複数のコンピュータ読取り可能媒体を備えることを特徴とするコンピュータプログラム製品。
【請求項４１】
前記一意のシーケンス識別子を含む受信される前記メッセージは、アプリケーションメッセージであることを特徴とする請求項４０に記載のコンピュータプログラム製品。
【請求項４２】
受信される前記メッセージは前記シーケンスセッションの開始側によって受信され、受信される前記メッセージは、前記開始側によって前に送信された肯定応答要求メッセージに応答した基盤肯定応答メッセージであることを特徴とする請求項４０に記載のコンピュータプログラム製品。
【請求項４３】
前記開始側はアドレス指定不可能であり、前記開始側は、ＨＴＴＰを介したＳＯＡＰによって前記受付け側と通信することを特徴とする請求項４２に記載のコンピュータプログラム製品。
【請求項４４】
受信される前記メッセージは前記シーケンスセッションの受付け側によって受信され、受信される前記メッセージはシーケンス肯定応答要求であることを特徴とする請求項４０に記載のコンピュータプログラム製品。
【請求項４５】
前記非活動タイムアウト期間は、前記通信媒体によって課される遅延を見込むように調整可能であることを特徴とする請求項４０に記載のコンピュータプログラム製品。
【請求項４６】
前記非活動タイマの再設定後、アプリケーションまたは基盤メッセージが前記非活動タイムアウト期間の満了後に受信されず、前記シーケンスセッションが放棄されることを特徴とする請求項４０に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、ウェブサービス用の高信頼メッセージングプロトコルに関する。より詳細には、本発明は、シーケンスセッション内の接続生存性（ｃｏｎｎｅｃｔｉｏｎ  ｌｉｖｅｌｉｎｅｓｓ）を検証し維持するためにウェブサービス用の高信頼メッセージングプロトコル（ＲＭ−ＷＳ：Ｒｅｌｉａｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ）の特性を活用する機構を提供する。
【背景技術】
【０００２】
コンピュータネットワークは、あるコンピュータまたは装置が電子メッセージを使用してネットワークを介して別のコンピューティングシステムと通信することを可能にすることによって、情報を通信し、およびそれにアクセスする能力を向上させてきた。コンピューティングシステム間で電子メッセージを転送する場合、電子メッセージはしばしば、電子メッセージ内のデータに対する操作（構文解析、ルーティング、フロー制御など）を実施するプロトコルストックを通過する。オープンシステム相互接続（ＯＳＩ：Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）モデルは、プロトコルスタックを実装するためのネットワークフレームワークの一例である。
【０００３】
ＯＳＩモデルは、電子メッセージを転送するための操作を、それぞれがデータ転送プロセス内の特定の操作を実施するように設計された７つの別個の層に分ける。プロトコルスタックはそれぞれの層を潜在的に実装することができるが、多くのプロトコルスタックは、ネットワークを介したデータの転送に使用するための選択的な層だけを実装する。データは、コンピューティングシステムから送信される場合、アプリケーション層で発生し、より低い中間層に下り、次いでネットワーク上へと伝わる。データは、ネットワークから受信される場合、物理層に入り、より高い中間層に上り、次いで最終的にはそのアプリケーション層で受信される。アプリケーション層、すなわち最上位の層は、アプリケーションおよびエンドユーザ処理をサポートする責任を負う。さらに、アプリケーション層内には、他の複数の層（単純オープンアクセスプロトコル（ＳＯＡＰ：Ｓｉｍｐｌｅ  Ｏｐｅｎ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）が存在する。ほとんどのプロトコルスタックによって組み込まれる別の層は、トランスポート層である。トランスポート層の一例は、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）である。
【０００４】
ウェブサービス（ＷＳ：Ｗｅｂ  Ｓｅｒｖｉｃｅ）は、コンピューティングシステム間の通信を向上させる原動力となっており、我々がソフトウェアを構築し使用するやり方をひっくり返している。ウェブサービスは、アプリケーションにデータを共有させ、またより強力には、こうしたアプリケーションがどのように構築され、それが何のオペレーティングシステムまたはプラットフォーム上で実行され、またそれにアクセスするために何の装置が使用されているかに関係なく他のアプリケーションから能力を呼び出す。ウェブサービスは、ＳＯＡＰ、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ：拡張可能マークアップ言語）、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ，  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ：汎用記述発見統合）、ＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ：ウェブサービス記述言語）などを含めて、業界標準プロトコルを用いることによってインターネットを介して呼び出される。ウェブサービスは、互いに独立したままであるが、特定のタスクを実施する連携グループ内にそれを緩くリンクすることができる。
【０００５】
現在のＷＳ技術は、開始側（クライアントなど）と受付け側（サービスなど）の間の直接的なＳＯＡＰメッセージ通信を提供する。その一般的な双方向メッセージングのケースでは、ＳＯＡＰ要求メッセージが開始側から受付け側に送信され、ＳＯＡＰ応答メッセージがそれへの応答で送信される。エンドツーエンド間で異なる別の通信は、開始側がメッセージを受付け側に送信し、応答を伴わない単一方向のメッセージ交換である。
【０００６】
新生のＷＳアーキテクチャの重要な利点は、統合された、相互運用可能な解決策を提供できることである。しかし、ウェブサービスはインターネットなどの信頼できない通信チャネルを介してそれぞれ異なるビジネス、発信（ｏｒｉｇｉｎａｔｉｏｎ）および他のサービスプロバイダからの様々なサービスを提供するので、ＷＳの信頼性はますます重要な要因になっている。ＷＳの信頼性は、それだけに限らないが、ウェブサービスのエンドポイントの信頼性、ウェブサービスがそれを介してアクセスされる通信チャネルの信頼性の特性、パフォーマンスおよび耐故障性の特性、およびウェブサービスが同時発生のクライアントアクセスに対処できる程度などを含めて、複数の要因の影響を受ける。
【０００７】
メッセージ（ＳＯＡＰメッセージなど）がエンドポイント間でそれを介して交換される信頼性の高いトランスポートプロトコルを選択することによって、ウェブサービスの信頼性の高いメッセージングを実現する試みが行われてきた。たとえば、開始側と受付け側の間でメッセージを確実に送達するために、メッセージキューなどの信頼性の高いメッセージングトランスポートが使用される。メッセージングキューイング通信技術は、それぞれ異なるシステム上のアプリケーションが、信頼性のためにキューにメッセージを送信し、障害を越えて持続されるキューからメッセージを読み出すことによって互いに通信することを可能にする。
【０００８】
キューイングシステムは、ＳＯＡＰメッセージを確実に運ぶために使用されるトランスポートを提供するが、こうしたシステムには複数の欠点がある。たとえば、こうしたシステムは、要求（および多分その応答）が単独に転送され処理される非同期の操作の解決策を提供する。したがって、こうしたシステムは、リソースに関して一般に重量であり、したがって永続的処理メッセージストアを備え、また展開、プログラミングモデルおよび管理において遥かに大きな複雑さを伴う複数の中継点（ｉｎｔｅｒｍｅｄｉａｒｙ）を含む。これはすべて、信頼できる直接的な通信にとっては不要であり、またそれによって、遅延を最小限に抑える目標が損なわれる。さらに、このプログラムモデルは、要求応答型のプログラムまたはセッションを直接にはサポートしていない。したがって、待ち行列型の（ｑｕｅｕｅｄ）通信モデルは、現在の「インタラクティブ」ウェブサービスモデルとは異なっており、また極めて重要な「接続型」シナリオおよび「インタラクティブ」アプリケーションに対処していない。たとえば、時宜を得て応答が見込まれる場合、または分散トランザクションコンテキストが開始側と受付け側で共有される必要が無い場合にはあまり適していない。
【０００９】
本質的には信頼できないトランスポートプロトコル、たとえば高信頼ＨＴＴＰまたはＨＴＴＰＲを介した信頼できる転送層を定義しようとする試みも行われてきた。しかし、この解決策およびキューイングの解決策の厄介となる共通の問題は、特定のトランスポートプロトコルが開始側と受付け側の間の通信のため使用される場合にしか信頼できるメッセージングが達成され得ないことである。ウェブサービスのこの基本的な性質は、特定のベンダプラットフォーム、実装言語および特定のトランスポートプロトコルからの独立を必要とする。一般的なケースでは、開始側は特定のプロトコルを使用して受付け側にメッセージを直接に送信することができないことがあり（たとえば受付け側がそのプロトコルをサポートしていないなど）、またはメッセージは、宛先ノードに到達するのに先行して、送信側のノードを離れた後に複数ホップを通過しなければならない必要がある。特定のホップに関与する２つのノード間の接続性の性質に応じて、信頼できるメッセージング特性を提供しない適切なトランスポートプロトコルが選択されなければならないことがある。
【００１０】
また中継点は、プロトコルスタックの様々なレベルに存在し、したがって完全なエンドツーエンドの信頼性を提供し得ない。たとえば、トランスポートプロトコルは、より低いレベルの中継点（たとえばＩＰルータなどのＩＰレベル中継点）を渡って信頼性を提供する。しかし、トランスポートプロトコルは、ＳＯＡＰ中継点またはアプリケーション層で終了する。したがって、トランスポートプロトコルは、その中継点を渡って信頼性を提供することができず、すなわちアプリケーション層を渡るエンドツーエンドの信頼性がないことがある。
【００１１】
より最近では、ウェブサービス（以下、「ＲＭ−ＷＳプロトコル」と称する）用の様々な高信頼性メッセージプロトコル、たとえばＷＳ−高信頼メッセージングが、上記で識別された、現在の高信頼メッセージングシステムの欠点の解決策を提供している。こうしたプロトコルは、ソフトウェアコンポーネント、システムまたはネットワーク障害がある状態でエンドポイントアプリケーション間で確実にメッセージが送達されることを可能にするトランスポート不可知論的な接続型プロトコルである。したがって、ＲＭ−ＷＳプロトコルは、開始側と受付け側の間の信頼性のあるエンドツーエンドのセッション指向通信のための解決策を提供する。
【００１２】
こうしたＲＭ−ＷＳプロトコルは、ＴＣＰがインターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ルータおよび複数のネットワークを介してＴＣＰ送信側からＴＣＰ受信側に信頼できる厳密に一度の順序正しいバイトストリームの送達を提供するという点でＴＣＰに類似する。ＷＳ用の高信頼メッセージングプロトコルは、（ＳＯＡＰレベルの中継点を含めた）複数の中継点、トランスポートおよび接続を介して、メッセージのためのそれ以上のことを提供する（注記：転送の単位はメッセージであり、バイトのサイズがＩＰパケット内の使用可能なペイロード空間によって決定されるＴＣＰの場合のようなバイトまたはバイトの集まりではない）。ＴＣＰおよびＲＭ−ＷＳプロトコルは両方とも「信頼できる」プロトコルであるが、ＯＳＩモデルではＲＭ−ＷＳがアプリケーションまたはＳＯＡＰ層に常駐するので、ＲＭ−ＷＳプロトコルは、データを転送するために使用されるトランスポートプロトコルに関係なく、信頼できるメッセージングを提供する。したがって、ＲＭ−ＷＳプロトコルは、エンドポイント間でメッセージを転送するために使用される特定のトランスポートまたは他のプロトコルに結合されない。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ここしばらくの間にいくつかのＲＭ−ＷＳプロトコルが存在しているが、こうしたプロトコルの仕様の複数の欠点および欠陥が依然としてある。たとえば、こうしたＲＭ−ＷＳプロトコルは、確立されたシーケンスセッションの接続性を検証するためのやり方を提供していない。さらに、その仕様は、非活動タイムアウト期間（ｉｎａｃｔｉｖｉｔｙ  ｔｉｍｅｏｕｔ  ｐｅｒｉｏｄ）に渡るメッセージの交換が無い状態で接続の生存性を維持し、および／またはシーケンスセッションを拡大するためのやり方を提供していない。したがって、ＲＭ−ＷＳプロトコルを使用するシステムについての接続生存性を検証し、維持することが求められている。
【課題を解決するための手段】
【００１４】
上記で識別された、ウェブサービス用の現在の高信頼メッセージングプロトコルの欠点および欠陥は、本発明の例示的な実施形態を用いて克服される。たとえば、本発明は、ウェブサービス用の高信頼メッセージングプロトコル（ＲＭ−ＷＳプロトコル）を使用することによってシーケンス接続の存在を検証し、エンドポイント間の接続の生存性を維持するための機構を提供する。
【００１５】
たとえば、開始側エンドポイントで接続の生存性を維持する場合、本発明は、ＲＭ−ＷＳプロトコルに従って２つのエンドポイント間のアプリケーション層で、一意のシーケンス識別子によって識別されるシーケンスセッションを確立することを提供する。シーケンスセッション作成の要求に基づいて、作成されたシーケンスセッションに対応する一意のシーケンス識別子が受信される。その後にまたは他の任意の時点でシーケンスセッションの非活動タイムアウト期間が識別され、この非活動タイムアウト期間は、シーケンスセッションについてのメッセージを受信せずに経過する時間の上限を表す。非活動タイムアウト期間に基づくアルゴリズムに従って、キープアライブ満了タイムアウトが計算される。計算されたキープアライブ満了タイムアウトに基づいて、一意のシーケンス識別子を含むメッセージが送信される。その後、接続の生存性が維持されるように、一意のシーケンス識別子を含むメッセージが非活動タイムアウト期間の前に受信される。シーケンスセッションが存続され続けるように、受信されたメッセージに基づいて、非活動タイムアウト期間のための非活動タイマが再設定される。
【００１６】
接続の生存性を検証するための別の例示的な実施形態では、一意のシーケンス識別子によって識別されるシーケンスセッションが、２つのエンドポイント間のアプリケーション層でＲＭ−ＷＳプロトコルに従って確立される。上記と同様に、シーケンスセッションについて２つのエンドポイント間でメッセージを交換せずに経過する時間の上限である非活動タイムアウト期間が識別される。非活動タイムアウト期間が満了になる前に、シーケンスセッションに対応する一意のシーケンス識別子を含む、接続を検証するためのメッセージが受信される。シーケンスセッションが存続され続けるように、受信されたメッセージに基づいて、非活動タイムアウト期間のための非活動タイマが再設定される。
【００１７】
本発明の追加の特徴および利点について、以下の説明で述べるが、それはその説明から一部明らかとなり、または本発明を実施することによって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲中で具体的に指摘される手段および組合せによって実現され取得される。本発明のこうした特徴および利点は、以下の説明および添付の特許請求の範囲から完全に明らかになり、または本明細書で以下に述べる本発明の実施によって知ることができる。
【００１８】
本発明の上記で挙げたおよび他の利点および特徴が取得されるやり方について説明するために、上記で簡潔に説明した本発明についてのより具体的な説明が、添付の図面内に示されるその特定の実施形態を参照することによって提供される。こうした図面は本発明の典型的な実施形態を示しているにすぎず、したがってその範囲を限定していると見なすべきでないとの理解のもとに、本発明について、添付の図面を使用することによって、さらに具体的にまた詳細に示し説明する。
【発明を実施するための最良の形態】
【００１９】
本発明は、シーケンスセッションの接続生存性を検証し維持するためにウェブサービス（ＲＭ−ＷＳ）用の高信頼メッセージングプロトコルを活用する機構のための方法、システムおよびコンピュータプログラム製品に及ぶ。本発明の諸実施形態は、以下でより詳細に説明するように様々なコンピュータハードウェアを含む特定目的または汎用コンピュータを備える。
【００２０】
本発明は、ウェブサービス（ＲＭ−ＷＳ）用の高信頼メッセージングプロトコル（以下、「ＲＭ−ＷＳプロトコル」と称する）、たとえばＷＳ−高信頼メッセージング（ＷＳ−ＲＭ）の拡張を対象とする。こうしたプロトコルは、ソフトウェアコンポーネント、システムまたはネットワークの障害がある状態で分散アプリケーション間で確実にメッセージが送達されることを可能にする仕様について説明している。ウェブサービス用の高信頼メッセージングプロトコルは、ソース（以下、「開始側」）からサービスなどの宛先（以下、「受付け側」）にメッセージをうまく送信することを実行する。こうしたプロトコルは、トランスポート不可知型であり、それぞれ異なるネットワーク転送技術を使用してそれが実装されることを可能にする。さらに、信頼できるメッセージングプロトコルの様々な実装は、間欠的な通信障害がアプリケーションから見えないようにし、システム障害の場合の回復可能性を提供する。
【００２１】
本発明は２つのエンドポイント間の確立されたシーケンスセッションに対する活動を監視し、この活動は、そのシーケンスについてのメッセージを受信する動作と定義される。受信されるメッセージは、アプリケーションまたは基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）メッセージ（ＲＭ−ＷＳプロトコルによる肯定応答メッセージ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ｍｅｓｓａｇｅ）など）である。さらに、本発明は、シーケンスセッションについてのメッセージ（アプリケーションまたは基盤）を受信せずに経過する時間の上限である非活動タイムアウト（ｉｎａｃｔｉｖｉｔｙ  ｔｉｍｅｏｕｔ（ＩＴ））期間を定義する。上限に達する場合、他のエンドポイントは存在していないと見なされ、シーケンスは失われまたは放棄されていると見なされる。一方、メッセージがＩＴの満了までに受信される場合、ＩＴタイマがリセットされ、接続が検証される。さらに別の関連実施形態では、識別されたＩＴに基づいて、本発明は、接続の生存性を維持しようとして、エンドポイント間で冪等ＲＭ−ＷＳプロトコル基盤メッセージを送信するための初期時間および周期性を計算する。
【００２２】
図１Ａに、上記で説明した例示的な諸実施形態の一部を実施するために使用される分散コンピューティングシステム１００を示す。シーケンスセッションが、ＲＭ−ＷＳプロトコルに従って開始側１２０と受付け側１２５の間で確立される。確立されたシーケンスセッションは、使用されているトランスポートに応じて複数の実際のネットワーク接続にまたがることも、またがらないこともある。さらに、接続は、時間（今はある接続を、後には別の接続を使用するなど）およびトポロジ（それぞれのホップについて異なるトランスポートタイプなど）に渡って異なる。たとえば、フロッピー（登録商標）ディスク上でメッセージをコピーし、ディスクを渡すことによって開始側１２０と受付け側１２５の間でメッセージが交換される場合、コンピュータ間の実際の物理接続は存在しないが、しかし、ＲＭ−ＷＳプロトコルの特性を活用することによって、本発明は、通信の当事者、すなわち開始側１２０と受付け側１２５の間でセッションを作成することができる。
【００２３】
フロッピー（登録商標）の例は例示するために提供されており、典型的な使用例ではないことに留意されたい。「インタラクティブアプリケーション」の典型的な使用例は、ＴＣＰ／ＩＰ、ＨＴＴＰ（多分ＴＣＰ／ＩＰを介して階層化されている）、ＵＤＰ／ＩＰ、パイプまたは他のリアルタイムトランスポート機構の使用である。
【００２４】
例示的な実施形態は、開始側１２０が主として接続の生存性を維持する責任を担う。したがって、この実施形態は、ＨＴＴＰを介したＳＯＡＰなどの要求応答プロトコルによって受付け側１２５と通信しているファイヤーウォールの背後のクライアントなど、アドレス指定不可能な（すなわち匿名の）開始側１２０をサポートする。しかし、開始側１２０がアドレス指定可能である場合（また場合によっては匿名であっても）、いずれかのエンドポイント（開始側１２０または受付け側１２５）は、後述するように接続生存性を検証することに留意されたい。したがって、以下の例は一般に、接続の生存性を維持し検証するとして開始側１２０に言及しているが、こうした参照は、例示するために使用されており、また特許請求の範囲に明示的に記載されていない限り、本発明の範囲を限定しまたは狭める意図はない。
【００２５】
開始側１２０が匿名かどうかに拘らず、開始側１２０は、確立されたシーケンスセッションがアプリケーション１３５または基盤１３０メッセージが無い状態で活動しないことにより終了することを回避するために、タイマ１１０を含む接続検証モジュール１０５を使用する。たとえば、識別された非活動タイムアウト（ＩＴ）に基づいて、接続検証モジュール１０５は、接続の両方の側で非活動タイムアウトを回避するため、ＲＭ−ＷＳ基盤メッセージの交換を開始するためのアルゴリズムを使用する。たとえば、ＲＭ−ＷＳ肯定応答要求メッセージＡｃｋ要求１１５を活用し（ＷＳ−ＲＭの場合、肯定応答要求メッセージＡｃｋＲｅｑｕｅｓｔｅｄが使用されることに留意されたい）、また特に作られたアルゴリズムを使用して、接続検証モジュール１０５は、他方の側に初期Ａｃｋ要求メッセージ１１５（「キープアライブ」メッセージ１１５として知られており、また本明細書ではそれと区別なく参照される）を送信する時間間隔を決定する。
【００２６】
例示的な実施形態は、ＩＴが遅延の問題、ネットワークの信頼性、および他の考慮事項などに基づいてアプリケーション層で調整可能であることを可能にすることに留意されたい。たとえば、上記のフロッピー（登録商標）の例では、非活動タイムアウト期間は、通信媒体によって課される遅延を見込むために比較的に大きい継続時間である必要があり、ただし、他のシステムは、受付け側１２５からのメッセージを受信せずにセッションを開いた状態に保つための比較的に短い継続時間を必要とする。したがって、ＩＴは、接続ごとに調整可能とすることができ、シーケンスセッションが確立される前に開始側１２０と受付け側１２５の間で交渉され、および／またはセッションが確立された後に動的に修正される。
【００２７】
受付け側１２５がＡｃｋ要求メッセージ１１５を受信する場合、ＩＴの値に関係なく、受付け側１２５は、非活動タイマ（図示せず）を再設定する。受付け側１２５が基盤１３０（Ａｃｋ要求１１５など）メッセージを受信するか、それともアプリケーションレベル１３５メッセージを受信するかに関係なく、非活動タイマは再設定される。この時点で、受付け側１２５は、接続の生存性を検証することができる。
【００２８】
同様に、開始側１２０で接続生存性を検証するために、開始側１２０は、シーケンスセッションについてのメッセージ（アプリケーション１３５または基盤１３０）を受信する必要がある。したがって、受付け側１２５は一般に、Ａｃｋ要求メッセージ１１５を受信する場合、ＲＭ−ＷＳ肯定応答メッセージＡｃｋ応答１３０を送信することによって応答する（ＷＳ−ＲＭの場合、受付け側１２５はＡｃｋメッセージを送信する）。Ａｃｋ応答すなわちＡｃｋ１３０を受信すると、開始側１２０は接続生存性を検査し、開始側１２０で非活動タイマ１１０を再設定し、接続生存性は維持される。上述したように、非活動タイムアウトの満了前に開始側１２０によって受信されるアプリケーションメッセージ１３５によってもタイマ１１０が再設定されることに留意されたい。このような場合、接続検証モジュール１０５は、再設定され、Ａｃｋ要求メッセージ１１５を送信するための初期期間を再計算する。
【００２９】
さらに、メッセージ（アプリケーション１３５または基盤１３０メッセージ）が開始側１２０によって受信されるかどうかに関係なく、シーケンスセッションは、少なくとも受付け１２５側で拡大されることに留意されたい。したがって、開始側１２０が匿名である場合（または開始側１２０がアドレス指定可能である一部の状況で）、開始側１２０についての非活動タイムアウトが存在しないことがある。したがって、Ａｃｋ要求メッセージ１１５を定期的に送信すると、メッセージが開始側１２０によって受信されるかどうかに関係なく、受付け側１２５で接続生存性が検証される。実際、受付け側１２５が非活動タイムアウトを実施せず、しかしメッセージが受信される場合に開始側１２０で接続が拡大される、逆の場合にも当てはまる。
【００３０】
基盤メッセージが確実には転送されず、交換の間のいずれかの時点で失われることにも留意されたい。したがって、Ａｃｋ要求メッセージ１１５は、開始側１２０から受付け側１２５までで失われる。同様に、Ａｃｋ応答メッセージ１３０は受付け側１２５から開始側１２０への転送中に失われる。こうした場合、例示的な実施形態は、Ａｃｋ要求１１５を受付け側１２５に定期的に送信するために非活動タイムアウト期間に基づいて特別に調整されたアルゴリズムを提供する。基盤メッセージ１１５、１３５は冪等であり、したがって、重複の検出は不要であり、また順序は重要でないことに留意されたい。
【００３１】
接続検証モジュール１０５は、上述したように交換開始の最初のおよびその後の定期的な試みのための時間を選択するために、上述の特別に作られたアルゴリズムを使用する。図１Ｂに、キープアライブまたはＡｃｋ要求メッセージ１１５を送信するために使用される可能なアルゴリズムの例示的な時系列図を示す。図１Ｂに示すように、このアルゴリズムの時系列は、少なくとも３つのプロパティのうちの１つまたは複数に基づく。まず、上述の非活動タイムアウト（ＩＴ）１４０は、開始側１２０がシーケンスセッションに失敗またはそれを放棄する前に、受付け側１２５からメッセージを受信しないでどのくらいの期間の間待機するかを定義する。次に、最大再試行回数（ＭＲＣ：ｍａｘｉｍｕｍ  ｒｅｔｒｙ  ｃｏｕｎｔ）１５５は、断念する前に開始側１２０がメッセージの再送信を試みる回数である。これは、アプリケーションメッセージと基盤メッセージ（キープアライブメッセージ１１５など）の両方に適用される。第３に、キープアライブ満了タイムアウト（ＫＡＥＴ：ｋｅｅｐ−ａｌｉｖｅ  ｅｘｐｉｒａｔｉｏｎ  ｔｉｍｅｏｕｔ）１５０は、開始側１２０がキープアライブメッセージ１１５を送信し始める前に受付け側１２５からメッセージを受け取らずに待機する間隔と定義され、すなわちＫＡＥＴ１５０は、キープアライブメッセージ１１５を送信する最初の時間を定義する、ＩＴ１４０のうちの何らかの割合（Ｎ）である。以下の例では、Ｎは０．５の既定値で設定される。したがって、開始側１２０は、受付け側１２５からの活動なしにＩＴ１４０の半分が経過した後に、キープアライブメッセージ１１５を送信し始める。
【００３２】
こうした３つの属性に基づいて、キープアライブ間隔（ＫＡＩ：Ｋｅｅｐ  Ａｌｉｖｅ  Ｉｎｔｅｒｖａｌ）１４５、すなわちキープアライブメッセージ１１５の連続的なまたは定期的な送信間の間隔が計算される。たとえば、キープアライブ間隔１４５は、アルゴリズムＫＡＩ＝ＩＴ＊（１−Ｎ）／ＭＲＣを使用して計算される。たとえば、ＩＴ１４０、ＫＡＥＴ１５０、ＭＲＣ１５５およびＫＡＩ１４５の間の関係は、図１Ｂに示すように図示される。ＫＡＥＴ１５０およびＫＡＩ１４５を定義するために特定のアルゴリズムが使用されているが、Ａｃｋ要求メッセージまたはキープアライブメッセージ１１５をいつ送信するかを決定する他のアルゴリズムおよびやり方をも本発明は使用できることに留意されたい。たとえば、キープアライブメッセージ１１５を送信するための周期性（すなわちＫＡＩ  １４５）は、ランダムに選択される。したがって、こうした値を決定するための上記の特定のアルゴリズムの使用は、例示するために使用されているにすぎず、特許請求の範囲に明示的に記載されていない限り、本発明の範囲を限定し、または他の方法で狭める意図はない。
【００３３】
しかし、開始側１２０は一般に、定期的なタイマ間隔に関して、ＩＴ１４０、ＫＡＥＴ１５０およびＫＡＩ１４５を計算する。たとえば、ＩＴ１４０が２時間であり、ＭＲＣ１５５が５であり、定期的なタイマ間隔が２秒であれば、上記の数式および仮定（Ｎ＝０．５など）を使用すると、ＫＡＥＴ１５０は１時間に等しく、ＫＡＩは１２分に等しい。値を秒に変換し、タイマ間隔で割ると、以下がもたらされる。ＩＴ／（タイマ間隔）＝７２００／２＝３６００タイマチック（ｔｉｍｅｒ  ｔｉｃｋ）、ＫＡＥＴ／（タイマチック）＝３６００／２＝１８００タイマチック、およびＫＡＩ／（タイマ間隔）＝７２０／２＝３６０タイマチック。したがって、開始側１２０はこの場合、１８００タイマチック後にキープアライブメッセージ１１５を送信し始める。また開始側１２０は、合計で３６００チック経過するまで３６０タイマチックごとにもキープアライブメッセージを送信する。開始側１２０がこの時間間隔の間に（すなわちＩＴ間隔に渡って）受付け側１２５からメッセージを受信しなかった場合、開始側１２０は、シーケンスセッションを失敗する。
【００３４】
代替の例示的な一実施形態では、上記の実装は、２つのタイマを使用して達成される。第１のタイマは、ＩＴ１４０に等しい時間間隔で設定される。この第１タイマは、メッセージが受付け側１２５から受信されるときはいつでも再設定される。受付け側１２５からの活動がなく第１タイマが終了する場合、開始側１２０は、シーケンスセッションを終了する。第２のタイマは、ＫＡＥＴ１５０に等しい時間間隔で設定される。この第２タイマが満了すると、開始側１２０は、受付け側１２５にキープアライブメッセージ１１５を送信し、第２タイマをＫＡＩ１４５の時間間隔で再設定する。さらに、第２タイマは、続いて起こる第２タイマの満了時に（すなわちメッセージ受信無しのＫＡＩ１４５の時間間隔の各経過の後に）ＫＡＩ１４５の時間間隔で再設定される。メッセージ１３０、１３５が受付け側１２５から受信されるときはいつでも、開始側１２０は、ＫＡＥＴ１５０に等しい時間間隔で第２タイマを再設定し、このプロセスが繰り返される。
【００３５】
キープアライブメッセージ１１５の送信を待機する間、アプリケーションメッセージが開始側１２０による送信に使用可能になることに留意されたい。これは、開始側１２０アプリケーションがメッセージを送信したため、または開始側１２０の再試行アルゴリズムがバッファされたアプリケーションメッセージを再送信するときであると決定したために生じる。例示的な実施形態は、これが生じる場合に、開始側１２０がそのＫＡＩ１４５（または多分ＫＡＥＴ１５０）間隔を再び開始すると定めている。換言すると、開始側１２０は、アプリケーションメッセージが送信されてからＫＡＩ１４５の間隔（またはＫＡＥＴ１５０）が経過するまで別のキープアライブメッセージ１１５を送信しない。したがって、開始側１２０は、何らかの形のメッセージ、アプリケーションまたは基盤を少なくともＫＡＩ１４５間隔ごとに送信する。さらに、キープアライブメッセージ１１５は一般に、送信されたアプリケーションメッセージがネットワーク輻輳など、どんな理由のためにブロックされても送信される。
【００３６】
他の実施形態は、Ａｃｋ要求メッセージ１１５が、送信されるアプリケーションメッセージに追加されることを可能にすることに留意されたい。この実施形態は、メッセージの束に肯定応答するのを待つのではなく、受付け側１２５にＡｃｋ応答すなわちＡｃｋ１３０の送信を早めるように促すために、ＩＴ１４０がまもなく終了しそうなときに使用される。この場合、Ａｃｋ要求メッセージ１１５は、アプリケーションメッセージ１３５と共に含まれるプロトコル要素（ＲＭ−ＷＳプロトコル、たとえばＷＳ−ＲＭによって定義されたヘッダまたは他の指標など）として一般に表される。したがって、「Ａｃｋ要求１１５メッセージ」は、Ａｃｋ要求１１５が上述のプロトコル要素である場合を含むと広く解釈すべきである。
【００３７】
他の実施形態は、ＲＭ−ＷＳプロトコルに従って、複数のシーケンスセッションのそれぞれについてのＡｃｋ要求１１５を、単一のメッセージ（アプリケーションまたは基盤、たとえばＡｃｋ要求１１５などのメッセージ）内に含めることを可能にする。同様に、他の実施形態は、ＲＭ−ＷＳプロトコルに従って、複数のシーケンスセッションのそれぞれについてのＡｃｋ応答１３０を、単一のメッセージ（アプリケーション１３５または基盤、たとえばＡｃｋ１３０などのメッセージ）内に含めることを可能にする。これは、単一のメッセージを受信すると複数のシーケンスの生存性を検証し、それによって、同じエンドポイント１２０、１２５間の複数のシーケンスの生存性を維持するのに必要なメッセージの数を減少させることを可能にする。
【００３８】
本発明について、機能ステップおよび／または非機能行為を備える方法に関して説明することもできる。以下は、本発明を実践する際に実施されるステップおよび／または行為についての説明である。機能ステップは通常、達成される結果に関して本発明について説明し、非機能行為は、特定の結果を達成するためのより具体的な動作について説明する。機能ステップおよび／または非機能行為は特定の順序で説明され、または特許請求の範囲に記載されるが、本発明は、ステップおよび／または行為の任意の特定の順序または組合せに必ずしも限定されない。さらに特許請求の範囲の詳述、ならびに図３および図４のフローチャートについての以下の説明中のステップおよび／または行為の使用は、こうした用語の所望の特定の使用を示すために使用されている。
【００３９】
図３および図４は、本発明の様々な例示的な実施形態についてのフローチャートの例を示している。図３および図４についての以下の説明は時々、図１Ａおよび１Ｂからの対応する要素に言及している。参照はこうした図からの特定の要素に対して行われるが、こうした要素は、例示するために使用されているにすぎず、また特許請求の範囲に明示的に記載されていない限り、本発明の範囲を限定しまたは狭める意図はない。
【００４０】
図３に、ＲＭ−ＷＳプロトコルを使用することによってエンドポイントアプリケーション間のシーケンスセッションの接続生存性を検証する方法３００のフローチャートの一例を示す。方法３００は、２つのエンドポイント間でシーケンスセッションを確立する行為３０５を含む。たとえば、シーケンスセッションは、ＲＭ−ＷＳプロトコル（ＷＳ−高信頼メッセージングなど）に従って開始側１２０と受付け側１２５の間で確立される。方法３００はさらに、非活動タイムアウトを識別する行為３１０を含む。たとえば、接続検証モジュール１０５は、シーケンスセッションについて開始側１２０と受付け側１２５の間でメッセージを交換せずに通過する時間の上限を表す非活動タイムアウト（ＩＴ）１４０を識別するために使用される。このＩＴ１４０は、通信媒体によって課される遅延や下位ネットワーク（ｕｎｄｅｒｌｉｎｅ  ｎｅｔｗｏｒｋ）の信頼性についての知識などを見込むように調整可能である。
【００４１】
非活動タイムアウト期間が切れる前に、方法３００は、一意のシーケンス識別子を含むメッセージを受信する行為３１５をも含む。たとえば、開始側１２０または受付け側１２５は、シーケンスセッションに対応する一意のシーケンス識別子を含む、接続の生存性を検証するためのメッセージを受信する。一意のシーケンス識別子を含む受信されたメッセージは、アプリケーション１３５メッセージである。受信されたメッセージは、基盤メッセージ１１５、１３０である。たとえば、メッセージが開始側１２０によって受信される場合、受信されるメッセージは、開始側１２０によって前に送信されたＡｃｋ要求１１５に応答したＡｃｋ１３０である。メッセージが受付け側１２５によって受信される場合、メッセージは、シーケンスＡｃｋ要求１１５である。メッセージがアプリケーションレベルメッセージか、それとも基盤メッセージであるかどうかに関係なく、他の実施形態は、単一のメッセージが複数のシーケンスセッションについての肯定応答要求（Ａｃｋ要求１１５など）または肯定応答（Ａｃｋ１３０など）を含むことを可能にする。さらに、Ａｃｋ要求１１５がアプリケーションレベルメッセージ内に含められる場合、一般に、Ａｃｋ要求１１５は、メッセージのヘッダまたは他のフィールドなどのプロトコル要素内に含められる。
【００４２】
受信されたメッセージに基づいて、方法３００はさらに、非活動タイマを再設定する行為３２０を含む。たとえば、メッセージが開始側１２０で受信される場合、開始側１２０は、接続検証モジュール１０５内のタイマ１１０を再設定する。次いで、非活動タイムアウト期間は再計算され、プロセスは繰り返される。非活動タイマの再設定後にアプリケーションまたは基盤メッセージが受信されない場合、非活動タイムアウト期間１４０の満了後にシーケンスセッションは放棄される。
【００４３】
図４に、ＲＭ−ＷＳプロトコルを使用することによってエンドポイント間のシーケンスセッションについて開始側によって接続の生存性を維持するための方法４００のフローチャートを示す。方法４００は、２つのエンドポイント間でシーケンスセッションを確立する行為３０５を含む。たとえば、一意のシーケンス識別子によって識別されるシーケンスセッションは、ＲＭ−ＷＳプロトコル（ＷＳ−高信頼メッセージング）に従って開始側１２０と受付け側１２５の間で確立される。シーケンスセッションを確立するために、開始側１２０は一般に、ＲＭ−ＷＳプロトコルに従って１つまたは複数のシーケンスセッションを作成することを求める要求を受付け側１２５に送信する。受付け側１２５は、要求に基づいて、作成されるシーケンスセッションを識別するために使用される一意のシーケンス識別子（グローバル一意識別子（ＧＵＩＤ：ｇｌｏｂａｌ  ｕｎｉｑｕｅ  ｉｄｅｎｔｉｆｉｅｒ）など）を生成する。
【００４４】
シーケンスセッションを確立する他のやり方をも本発明が使用できることにも留意されたい。たとえば、開始側１２０は、一意のシーケンス識別子を生成し、シーケンスセッション作成要求でそれを受付け側１２５に送信することができる。実際に、本発明が使用できるシーケンスセッション確立のよく知られている他の多くのやり方が存在する。したがって、シーケンスセッションがどのように確立されるかに対する特定のいずれの言及もが、例示するためだけに使用されており、特許請求の範囲に明示的に記載されていない限り、本発明の範囲を限定し、または他の方法で狭める意図はない。
【００４５】
シーケンスセッションがどのように確立されるかに関係なく、方法４００はさらに、シーケンスセッションの非活動タイムアウト期間を識別する行為４１５を含む。たとえば、接続検証モジュール１０５は、そのシーケンスセッションについてのメッセージを受信せずに経過する時間の上限を表す非活動タイムアウト（ＩＴ）１４０を識別する。このＩＴ１４０は、トランスポートネットワークの信頼性や他の考慮事項、たとえば肯定応答受信の予想される最小遅延などに基づいて調整可能である。
【００４６】
方法４００はさらに、キープアライブ満了タイムアウトを計算する行為４１７を含む。たとえば、接続検証モジュール１０５は、一般には間隔タイムアウト１４０のうちのある割合であるキープアライブ満了時間（ＫＡＥＴ）１５０を計算するための非活動タイムアウト期間１４０に基づくアルゴリズムを使用する。計算されたキープアライブ満了タイムアウトに基づいて、方法４００はさらに、一意のシーケンス識別子を含むメッセージを送信する行為を含む。メッセージは、基盤メッセージ（Ａｃｋ要求１１５など）またはアプリケーションメッセージ１３５である。たとえば、ＫＡＥＴ１５０が満了すると開始側１２０は、ＲＭ−ＷＳプロトコルによって定義される基盤冪等メッセージであるＡｃｋ要求メッセージ１１５を送信する。送信されるメッセージがアプリケーションレベルかそれとも基盤メッセージであるかに関係なく、他の実施形態は、メッセージが複数のシーケンスセッションについての肯定応答要求（Ａｃｋ要求１１５など）を含むことを可能にする。
【００４７】
次に、方法４００は、一意のシーケンス識別子を含むメッセージを受信する行為４２２を含む。すなわち、開始側１２０は、一意のシーケンス識別子を含むＡｃｋ応答１３０またはアプリケーションメッセージ１３５を受付け側１２５から受信する。メッセージ（基盤またはアプリケーションメッセージ１３０、１３５など）が非活動タイムアウト期間１４０前に受信される場合、シーケンスセッションの接続生存性は維持される。さらに、受信されたメッセージに基づいて、方法４００は、非活動タイマを再設定する行為４２５をも含む。すなわち、受信されたＡｃｋ応答１３０またはアプリケーションメッセージ１３５に基づいて、シーケンスセッションが存続され続けるように、接続検証モジュール１０５内の非アクティブ化タイマ１１０が、非アクティブ化タイムアウト１４０のために再設定される。
【００４８】
受信されるメッセージはアプリケーションレベルメッセージであることにも留意されたい。こうした場合、Ａｃｋ応答１３０は、アプリケーションレベルメッセージ内に含められる。受信されたメッセージがアプリケーションレベルかそれとも基盤メッセージであるかに関係なく、他の実施形態は、メッセージが複数のシーケンスセッションについての肯定応答（Ａｃｋ１３０など）を含むことを可能にする。
【００４９】
Ａｃｋ要求メッセージ１１５は、受付け側１２５から受信済みとして既に肯定応答されているメッセージに対応することにも留意されたい。換言すると、Ａｃｋ要求メッセージ１１５は、すべてのメッセージが受信済みとして肯定応答されていても送信される。さらに、受付け側に送信されるアプリケーションメッセージはブロックされるが、しかし、Ａｃｋ要求メッセージ１１５はいずれにせよ送信されるべきである。
【００５０】
ＫＡＥＴ１５０を計算するためのアルゴリズムは、非活動タイムアウト１４０のうちの何らかの割合（Ｎ）に基づくことにさらに留意されたい。たとえば、ＫＡＥＴ１５０を計算するために使用される非活動タイムアウト１４０のうちの割合は、非活動タイマ１１０がＩＴ１４０の２分の１に達する場合に最初のＡｃｋ要求またはキープアライブメッセージ１１５が送信されるように、非活動タイムアウト１４０の２分の１である。さらに例示的な実施形態は、アプリケーションおよび基盤メッセージ１１５が送信される最大の回数である最大再試行回数（ＭＲＣ）１５５を識別することを提供する。最大再試行回数１５５に基づいて、メッセージ送信のための間隔を表すキープアライブ間隔（ＫＡＩ）１４５が計算される。したがって、計算されたＫＡＩ１４５に基づいて１つまたは複数のメッセージが送信され、その送信されるメッセージはＡｃｋ要求メッセージ１１５を含むべきである。もちろん、上述したように、ＫＡＩ１４５に基づいて送信されるメッセージは、アプリケーションメッセージである。さらに、非活動タイムアウト１４０は、トランスポートネットワークの決定された信頼性、または他の考慮事項に基づいて調整できることに留意されたい。
【００５１】
本発明の範囲内の実施形態は、それ上に格納されたコンピュータ実行可能命令またはデータ構造体を運びまたは含むためのコンピュータ読取り可能媒体をも含む。こうしたコンピュータ読取り可能媒体は、汎用または特定目的コンピュータによってアクセスされる任意の使用可能な媒体とすることができる。限定するためではなく、例を挙げると、こうしたコンピュータ読取り可能媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造体の形の所望のプログラムコード手段を運びまたは格納するために使用されることができ、また汎用または特定目的コンピュータによってアクセスすることができる他の任意の媒体が含まれる。情報がネットワークまたは別の通信接続（有線、無線、あるいは有線または無線の組合せ）を介してコンピュータに転送されまたは提供される場合、コンピュータは、その接続をコンピュータ読取り可能媒体と適切に見なす。したがって、こうした任意の接続は、コンピュータ読取り可能媒体と適切に称される。上記内容の組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。コンピュータ実行可能命令は、たとえば、汎用コンピュータ、特定目的のコンピュータまたは特定目的の処理装置に特定の機能または機能群を実施させる命令およびデータを含む。
【００５２】
図２および以下の議論は、本発明を実施することができる適切なコンピューティング環境についての簡潔で一般的な説明を提供することを意図している。必須ではないが、本発明について、ネットワーク環境内のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で述べる。プログラムモジュールは一般に、特定のタスクを実装し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。コンピュータ実行可能命令、関連するデータ構造体、およびプログラムモジュールは、本明細書で開示する方法のステップを実行するためのプログラムコード手段の例を表す。こうした実行可能または関連するデータ構造体の特定のシーケンスは、こうしたステップ中の説明された諸機能を実施するための対応する行為を表す。
【００５３】
本発明は、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含めて、多くのタイプのコンピュータシステム構成を備えたネットワークコンピューティング環境内で実施されることが当業者には理解されよう。本発明は、通信ネットワークを介して（有線リンク、無線リンク、あるいは有線または無線リンクの組合せによって）リンクされたローカルおよびリモート処理装置によってタスクが実施される分散コンピューティング環境内で実施されることもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリ記憶装置内に置かれる。
【００５４】
図２を参照すると、本発明を実施するための例示的なシステムが、処理装置２２１、システムメモリ２２２、およびシステムメモリ２２２を含めて様々なシステム構成要素を処理装置２２１に結合するシステムバス２２３を含む、従来型のコンピュータ２２０の形の汎用コンピューティング装置を含んでいる。システムバス２２３は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを用いたローカルバスを含めて、複数タイプのバス構造のいずれかである。システムメモリは、読出し専用メモリ（ＲＯＭ：Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）２２４およびランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２２５を含む。起動時などにコンピュータ２２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）２２６は、ＲＯＭ２２４に格納される。
【００５５】
コンピュータ２２０は、磁気ハードディスク２３９から読み出しまたそこに書き込むための磁気ハードディスクドライブ２２７、取外し可能な磁気ディスク２２９から読み出しまたはそこに書き込むための磁気ディスクドライブ２２８、ならびにＣＤ−ＲＯＭや他の光媒体などの取外し可能な光ディスク２３１から読み出しまたはそこに書き込むための光ディスクドライブ２３０をも含む。磁気ハードディスクドライブ２２７、磁気ディスクドライブ２２８および光ディスクドライブ２３０は、それぞれハードディスクドライブインターフェース２３２、磁気ディスクドライブインターフェース２３３および光ドライブインターフェース２３４によってシステムバス２２３に接続される。ドライブおよびその関連のコンピュータ読取り可能媒体によって、コンピュータ実行可能命令、データ構造体、プログラムモジュール、およびコンピュータ２２０のための他のデータの不揮発性記憶域がもたらされる。本明細書で述べる例示的な環境は、磁気ハードディスク２３９、取外し可能な磁気ディスク２２９および取外し可能な光ディスク２３１を使用しているが、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含めて、データを格納するための他のタイプのコンピュータ読取り可能媒体が使用される。
【００５６】
オペレーティングシステム２３５、１つまたは複数のアプリケーションプログラム２３６、他のプログラムモジュール２３７およびプログラムデータ２３８を含めて、１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク２３９、磁気ディスク２２９、光ディスク２３１、ＲＯＭ２２４またはＲＡＭ２２５に格納される。ユーザは、キーボード２４０、ポインティング装置２４２、あるいはマイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナなどの他の入力装置（図示せず）を介してコンピュータ２２０内にコマンドおよび情報を入力することができる。これらのおよび他の入力装置はしばしば、システムバス２２３に結合されたシリアルポートインターフェース２４６を介して処理装置２２１に接続される。代わりに、入力装置は、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）などの他のインターフェースによって接続される。モニタ２４７または別の表示装置もまた、ビデオアダプタ２４８などのインターフェースを介してシステムバス２２３に接続される。パーソナルコンピュータは一般に、モニタに加えて、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）を含む。
【００５７】
コンピュータ２２０は、リモートコンピュータ２４９ａおよび２４９ｂなどの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。メモリ記憶装置２５０ａおよび２５０ｂ、ならびにその関連アプリケーションプログラム２３６ａおよび２３６ｂだけが図２に示されているが、リモートコンピュータ２４９ａおよび２４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、またコンピュータ２２０に関して上述した要素の多くまたはすべてを一般に含む。図２に示す論理接続はローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）２５１、および広域ネットワーク（ＷＡＮ：Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）２５２を含み、それは、ここでは限定するためでなく、例示するために提示されている。こうしたネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットでは一般的である。
【００５８】
ＬＡＮネットワーキング環境内で使用される場合、コンピュータ２２０は、ネットワークインターフェースまたはアダプタ２５３を介してローカルネットワーク２５１に接続される。ＷＡＮネットワーキング環境内で使用される場合、コンピュータ２２０は、モデム２５４、無線リンク、またはインターネットなどの広域ネットワーク２５２を介して通信を確立する他の手段を含む。内部にあっても、外部にあってもよいモデム２５４は、シリアルポートインターフェース２４６を介してシステムバス２２３に接続される。ネットワーク化された環境では、コンピュータ２２０に関して示したプログラムモジュール、またはその一部は、リモートメモリ記憶装置内に格納される。図示するネットワーク接続は例であり、広域ネットワーク２５２を介して通信を確立する他の手段が使用可能であることが理解されよう。
【００５９】
本発明は、その精神または本質的な特性から逸脱せずに他の特定の形で実施することができる。説明した諸実施形態は、すべての点において限定的ではなく例示的であると見なすべきである。したがって、本発明の範囲は、上記の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等物の意味および範囲内に含まれるすべての変更は、その範囲内に包含されるべきである。
【図面の簡単な説明】
【００６０】
【図１Ａ】本発明の例示的な実施形態による、ＲＭ−ＷＳプロトコルの特徴を活用することによって接続生存性を検証し維持するためのコンピューティングシステムを示す図である。
【図１Ｂ】本発明の例示的な実施形態による、接続生存性を維持するためにＲＭ−ＷＳプロトコル基盤メッセージを送信するための間欠性または周期性を計算するために使用されるアルゴリズムの時系列を示す図である。
【図２】本発明に適したオペレーティング環境を提供する例示的なシステムの図である。
【図３】本発明の例示的な実施形態による、接続生存性を維持する方法のフローチャートである。
【図４】本発明の例示的な実施形態による、接続生存性を検証するための方法のフローチャートである
【図１Ａ】
2006164252.tif 000003
【図１Ｂ】
2006164252.tif 000004
【図２】
2006164252.tif 000005
【図３】
2006164252.tif 000006
【図４】
2006164252.tif 000007