JP2006178961A - 要求−応答トランスポートプロトコルによる高信頼一方向メッセージング - Google Patents

Abstract

【課題】一方向メッセージ交換形態におけるＲＭプロトコルと要求−応答トランスポートプロトコル（例えば、ＨＴＴＰ）の間の結合メカニズムを提供する。
【解決手段】本発明は、新しいインフラストラクチャサービスを再構成または配備することなく、要求−応答トランスポートプロトコルの既存のネットワーク特性を利用する。要求−応答トランスポートモデルは、非対称性を有し、要求フローと応答フローの２つのデータフローを提供する。イニシエータがアドレシング可能でない場合、および／または通信が要求−応答トランスポートを必要とする場合、本発明は、インフラストラクチャおよびアプリケーションメッセージが要求フロー上を送信され、肯定応答およびその他のインフラストラクチャメッセージがトランスポートの応答フローを介して返送されることを可能にする。
【選択図】図２

Description

本発明は、一般に、例えば、ウェブサービスなど、分散システム用の高信頼メッセージングプロトコルに関する。より詳細には、本発明は、分散システム用の高信頼メッセージングプロトコルを、一方向メッセージ交換形態環境において、要求−応答トランスポートプロトコル（例えば、ＨＴＴＰ）に結びつけることを可能にする。

コンピュータネットワークは、１台のコンピュータまたは装置が、電子メッセージを使用し、ネットワークを介して別のコンピューティングシステムと通信できるようにすることで、我々が通信を行い情報にアクセスする能力を向上させてきた。コンピューティングシステム間で電子メッセージを転送する場合、電子メッセージは、電子メッセージ内のデータに基づいて動作（例えば構文解析、ルーティング、フロー制御など）を実行するプロトコルスタックを通過する。開放型システム間相互接続（ＯＳＩ）モデルは、プロトコルスタックを実装するためのネットワークフレームワークの一例である。

ＯＳＩモデルは、電子メッセージを転送するための動作を、各々がデータ転送プロセスにおいて一定の動作を実行するように指示された７つの異なるレイヤに分解する。プロトコルスタックは、潜在的には各レイヤを実装できるが、多くのプロトコルスタックは、ネットワークを介してデータを転送するのに使用するレイヤだけを選択して実装している。データは、コンピューティングシステムから送信されるとき、アプリケーションレイヤから送出され、中間のより下位のレイヤへと渡されていき、最後にネットワークに渡される。データは、ネットワークから受信されるとき、物理レイヤに入り、中間のより上位のレイヤへと渡されていき、最終的にアプリケーションレイヤに渡される。アプリケーションレイヤ―最上位レイヤ―は、アプリケーションおよびエンドユーザ処理を支援する責任を負う。さらに、アプリケーションレイヤ内に、複数の異なるレイヤ（例えばＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｐｃｏｌ（ＳＯＡＰ）レイヤなど）が存在することができる。大部分のプロトコルスタックに組み込まれる別のレイヤに、トランスポートレイヤがある。トランスポートレイヤの一例が、伝送制御プロトコル（ＴＣＰ）である。

ウェブサービス（ＷＳ）は、コンピューティングシステム間の通信を進歩させる推進力となっており、ソフトウェアの構築および利用方法をすっかり逆転させている。ウェブサービスは、アプリケーションにデータを共用させ、より強力には―他のアプリケーションから機能を呼び出させるが、これらのアプリケーションがどこに構築されているか、どのようなオペレーションシステムまたはプラットフォーム上で動作しているか、どのような装置を使用してこれらのアプリケーションにアクセスするかを問うことはない。ウェブサービスは、ＳＯＡＰ、ＸＭＬ（拡張マークアップ言語）、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）、ＷＳＤＬ（ウェブサービス記述言語）などを含む業界標準プロトコルによって、インターネットを介して呼び出される。ウェブサービスは、互いに独立であり続けるが、緩やかに結合し合って、特定のタスクを実行する連携グループを形成することができる。

現在のＷＳ技術は、イニシエータ（例えばクライアント）とアクセプタ（例えばサービス）の間で、直接ＳＯＡＰメッセージングを提供する。通常の双方向メッセージの場合、ＳＯＡＰ要求メッセージは、イニシエータからアクセプタに送信され、ＳＯＡＰ応答メッセージは、要求メッセージに対する応答として送信される。エンドポイント間の別種の通信形態に、単方向メッセージがあり、この形態では、イニシエータは、アクセプタにメッセージを送信するが、応答を受け取らない。

新たに生まれたＷＳアーキテクチャの主要な利点は、統合された同じ操作性のソリューションを提供できる能力にある。しかし、ウェブサービスは、異なる企業、発信元、およびその他のサービスプロバイダからの様々なサービスを、インターネットなどの低信頼通信チャネルを介して提供するので、ＷＳの信頼性がますます重要な要素となっている。ＷＳの信頼性は、ウェブサービスのエンドポイントの信頼性、ウェブサービスがそれを介してアクセスされる通信チャネルの信頼性特性、性能および耐故障性特性、ならびにウェブサービスが複数クライアントによる同時アクセスを処理できる限度などを含むが、これらに限定されない複数の要因によって影響を受ける。

メッセージ（例えばＳＯＡＰメッセージ）がエンドポイント間でそれを用いて交換される高信頼トランスポートプロトコルを選択することによって、ウェブサービスの高信頼メッセージングを達成しようという試みがなされてきた。例えば、メッセージキューなどの高信頼メッセージングプロトコルは、イニシエータとアクセプタの間で高い信頼性でメッセージを配送するのに使用することができる。メッセージキューイング通信技術は、信頼性維持のため障害発生時も内容を保持し続けるキューにメッセージを送信し、キューからメッセージを読み出すことによって、異なるシステム上のアプリケーションが互いに通信することを可能にする。

キューイングシステムは、ＳＯＡＰメッセージを高い信頼性で伝送するのに使用できるトランスポートを提供するが、このようなシステムにはいくつかの短所がある。例えば、これらのシステムは、要求（およびおそらくはその応答）が孤立して転送され、処理される非同期動作のためのソリューションを提供する。したがって、これらのシステムは、一般に多くのリソースを消費し、処理メッセージ用の耐久性のある記憶装置を備え、配備、プログラムモデル、および管理において複雑さがかなり増した、複数の仲介手段を必要とする。このすべては、高信頼直接通信には不必要なものであり、待ち時間（ｌａｔｅｎｃｙ）を最短化するという目的を損ねる。さらに、前記プログラムモデルは、要求−応答型のプログラミングまたはセッションをサポートしていない。したがって、待機型（ｑｕｅｕｄ）の通信モデルは、現在の「対話型」ウェブサービスモデルとは異なっており、「接続されている」ことが不可欠なシナリオ、および「対話型」アプリケーションには対処できない。例えば、適時的な方式による応答が期待される場合、または分散トランザクションコンテキストがイニシエータとアクセプタとで共用される必要がある場合には、待機型の通信モデルはあまり適していない。

基礎的な低信頼トランスポートプロトコルの上に、例えば高信頼ＨＴＴＰ、すなわちＨＴＴＰＲなどの高信頼転送レイヤを定義しようという試みもなされてきた。しかし、このソリューションを悩ませている共通の問題は、キューイングソリューションのときと同様に―イニシエータとアクセプタの間の通信に特定の高信頼トランスポートプロトコルが使用された場合だけしか、その高信頼メッセージングを達成できないというものである。ウェブサービスの基本的性質は、特定の供給業者のプラットフォーム、実装言語、および特定のトランスポートプロトコルからの独立性を要求する。一般的な場合、イニシエータは、特定のプロトコルを使用して、アクセプタに直接メッセージを送信することはできず（例えば、アクセプタはそのプロトコルをサポートしていない）、またはメッセージは、送信ノードを出て、宛先ノードに到着するまでに、複数のホップを通過する必要があるかもしれない。特定のホップに含まれる２つのノード間の接続の性質に応じて、高信頼メッセージング特性を提供しないトランスポートプロトコルを、適切なプロトコルとして選択しなければならないかもしれない。

仲介手段は、プロトコルスタックの異なるレベルにも存在することができ、したがって、完全なエンドツーエンドの信頼性を提供しない。例えば、トランスポートプロトコルは、より下位の仲介手段（例えば、ＩＰレベルの仲介手段―例えば、ＩＰルータ）の間での信頼性を提供することができる。しかし、トランスポートプロトコルは、ＳＯＡＰ仲介手段またはアプリケーションレイヤ（例えば、ＨＴＴＰプロキシ）で終了することがある。したがって、トランスポートプロトコルは、その仲介手段の間での信頼性を提供できないことが、すなわち、アプリケーションレイヤにおけるエンドツーエンドの信頼性を提供できないことがある。

ここ最近になって、分散システム用の様々な高信頼メッセージングプロトコル（これ以降、「ＲＭプロトコル」と呼ぶ）が、現在の高信頼メッセージングシステムが持っている上記で確認された欠点に対するソリューションを提供している。これらのプロトコル（例えばウェブサービス（ＷＳ）用のＲＭプロトコルで、ＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ、ＷＳ−Ｒｅｌｉａｂｉｌｉｔｙなどを含む）は、ソフトウェアコンポーネント、システム、またはネットワークに障害があっても、メッセージがエンドポイントのアプリケーション間で高い信頼性で配送されることを可能にする、トランスポートに捉われずに接続が行われるプロトコル（ｔｒａｎｓｐｏｒｔ ａｇｎｏｓｔｉｃ ｃｏｎｎｅｃｔｅｄ ｐｒｏｔｏｃｏｌ）である。したがって、ＲＭプロトコルは、イニシエータとアクセプタの間で、潜在的にセッション指向の高信頼エンドツーエンド通信のためのソリューションを提供する。

これらのＲＭプロトコルは、ＴＣＰが、インターネットプロトコル（ＩＰ）ルータと複数のネットワークを介した、ＴＣＰ送信者からＴＣＰ受信者へのバイトストリームの、一回限りの順序正しい高信頼配送（ｒｅｌｉａｂｌｅ，ｅｘａｃｔｌｙ−ｏｎｃｅ，ｉｎ−ｏｒｄｅｒ ｄｅｌｉｖｅｒｙ）を提供する点で、ＴＣＰに類似している。分散システム用の高信頼メッセージングプロトコルは、これと同等以上のものを、（トランスポートおよびＳＯＡＰレベルの仲介手段を含む）複数の仲介手段、トランスポート、およびコネクションの間のメッセージ（注：転送単位はバイトではなくメッセージ）に提供する。ＲＭプロトコル（およびより一般にはＳＯＡＰレイヤ）はＯＳＩモデルのアプリケーションに存在するので、ＴＣＰおよびＲＭプロトコルは共に、「高信頼」プロトコルであるが、ＲＭプロトコルは、データを転送するのに使用されるトランスポートプロトコルに関わらず、高信頼メッセージングを提供する。したがって、ＲＭプロトコルは、エンドポイント間でメッセージを転送するのに使用される特定のトランスポートまたはその他のプロトコルに縛られることはない。

ここ最近になって数種類のＲＭプロトコルが普及してきたが、これらのプロトコルの仕様には、まだいくつかの短所および欠点が存在する。例えば、分散システム用の高信頼メッセージングプロトコルは、一般に双方向メッセージ交換を必要とし、すなわち、アプリケーションからのメッセージは一つの方向に進み、インフラストラクチャからの肯定応答は反対の方向に進む。さらに、要求に基づかないアクセプタからイニシエータへの通信（ｕｎｓｏｌｉｃｉｔｅｄ ａｃｃｅｐｔｏｒ−ｔｏ−ｉｎｉｔｉａｔｏｒ ｃｏｍｍｕｎｉｃａｔｉｏｎ）が行えない場合が存在する。例えば、これに当たるのが、イニシエータがファイアウォールの背後におり、アクセプタと通信するために、（例えば、ＨＴＴＰプロキシをトンネリングすることで）要求−応答トランスポートプロトコル（例えば、ＨＴＴＰ）接続を使用するときである。しかしながら、前記イニシエータは一般にアドレシング可能ではなく、および／または通信は要求−応答トランスポートプロトコルに限定されるので、肯定応答およびその他のインフラストラクチャからのメッセージを前記イニシエータに送信しようとすると問題が生じる。したがって、要求−応答メッセージング形態を提供するトランスポートを介した、イニシエータからアクセプタへの一方向メッセージ交換形態におけるアプリケーションレベルメッセージ―および双方向のＲＭインフラストラクチャメッセージ―の高信頼送信を統合する必要が生じている。

分散システム（例えばウェブサービスなど）用の現在の高信頼メッセージングプロトコルに関する、上記で確認された欠点および短所は、本発明の例示的な実施形態によって克服される。例示的な実施形態は、要求−応答トランスポートプロトコル上でアプリケーションレベルメッセージを送信するときに、新しいインフラストラクチャサービスを再構成または配備することなく、要求−応答トランスポートプロトコルの既存のネットワーク特性を利用することによって、分散システム用の高信頼メッセージングプロトコル（ＲＭプロトコル、例えばＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ）を提供する。

イニシエータのコンピューティング装置では、例示的な実施形態は、アクセプタ側エンドポイントとのアプリケーションレベルメッセージの高信頼な一方向メッセージ交換形態のために、イニシエータ側エンドポイントでアプリケーションレベルメッセージの作成を実施する。次に、アプリケーションレベルメッセージは、分散システム用の高信頼メッセージングプロトコル（ＲＭプロトコル）に従ってフォーマットされる。その後、アプリケーションレベルメッセージは、要求−応答トランスポートプロトコルの要求フローを介して送信される。次に、ＲＭプロトコルに準拠させるために、対応するトランスポートレベルの応答メッセージが、要求−応答トランスポートの応答フローを介して受信され、ＲＭプロトコルインフラストラクチャ情報にリンクされる。

一方、アクセプタのコンピューティング装置では、別の例示的な実施形態が、イニシエータからアクセプタへの高信頼な一方向メッセージ交換形態におけるアプリケーションレベルメッセージの受信を実施する。アプリケーションレベルメッセージは、匿名の（ａｎｏｎｙｍｏｕｓ）要求−応答トランスポートプロトコルの要求フローを介して受信される。さらに、アプリケーションレベルメッセージは、分散システム用の高信頼メッセージングプロトコル（ＲＭプロトコル）に従ってフォーマットされていることが確認される。次に、ＲＭプロトコルインフラストラクチャ情報が、トランスポートレベルの応答にリンクされるが、インフラストラクチャ情報は、１つまたは複数のアプリケーションレベルメッセージの高信頼な交換に対応している。その後、ＲＭプロトコルに準拠させるために、トランスポートレベルの応答が、要求−応答トランスポートの応答フローを介して送信される。

本発明のさらなる特徴および利点は、以下の説明において述べられ、部分的にはその説明から明らかとなり、あるいは本発明を実施することによって理解することができよう。本発明の特徴および利点は、特に添付の特許請求の範囲において指摘される手段および組み合わせによって実現し、また獲得することができよう。本発明の上記およびその他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかとなり、あるいは以下で述べるように本発明を実施することによって理解することができよう。

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

本発明は、（例えば、ウェブサービスなどの）分散システム用の高信頼メッセージングプロトコルを、エンドポイント間の一方向メッセージ交換形態において、（例えば、ＨＴＴＰなどの）要求−応答トランスポートプロトコルに結び付けるための方法、システム、およびコンピュータプログラム製品に関する。本発明の実施形態は、以下により詳細に説明するように、様々なコンピュータハードウェアを含む専用または汎用コンピュータを含むことができる。

本発明は、分散システム用の高信頼メッセージングプロトコル（これ以降、「ＲＭ」プロトコルと呼ぶ）の拡張に関し、ソフトウェアコンポーネント、システム、またはネットワークに障害があっても、メッセージが分散アプリケーション間で高い信頼性で配送されることを可能にするプロトコルについて説明する。分散システム（例えばウェブサービスなど）用の高信頼メッセージングプロトコルは、送信元（以降、「イニシエータ」）から例えばサービスなどの宛先（以降、「アクセプタ」）へのメッセージ送信が容易に成功するようにし、エラー状態が検出可能となるように保証する。これらのプロトコルは、トランスポートに捉われず、それらを異なるネットワーク転送技術を用いて実装することを可能にする。さらに、高信頼メッセージングプロトコルの様々な実装は、アプリケーションから断続的な通信障害を隠蔽し、システム障害時における回復性を提供する。

上で述べたように、例示的な実施形態は、ＲＭプロトコルと（例えば、ＨＴＴＰなどの）要求−応答トランスポートプロトコルの間の結合メカニズムを提供する。本発明は、新しいインフラストラクチャサービスを再構成または配備することなく、要求−応答トランスポートプロトコルの既存のネットワーク特性を利用する。要求−応答トランスポートモデルは、非対称性を有し、要求フローと応答フローの２つのデータフローを提供する。そのような要求−応答モデルは、応答メッセージを、要求メッセージに対する応答としてのみ、要求メッセージに続いて、要求によって提供されたトランスポートコネクションを用いて送信できるようにメッセージング形態を制限する。要求−応答トランスポート（例えばＳＯＡＰトランスポート）プロトコルの標準的な例は、「匿名（ａｎｏｎｙｍｏｕｓ）ＨＴＴＰ」であり、その場合、イニシエータは、アドレシング可能ではなく、ＨＴＴＰプロトコルの応答フローを用いたときだけしかメッセージを受信できない。

例示的な実施形態は、肯定応答およびその他のインフラストラクチャメッセージをイニシエータに送信するために、そのような応答フローを利用する。本明細書で説明される匿名要求−応答トランスポートプロトコルについての詳細は、イニシエータが直接アドレシング可能ではない（すなわち、イニシエータの要求に基づかないメッセージを送信する方法がない）任意の要求−応答トランスポートプロトコルにも当てはまる。しかし、本発明は匿名要求−応答トランスポートプロトコルに限定されるものではなく、要求−応答トランスポートプロトコルに限定される任意の通信にも適用されることに留意されたい。したがって、本明細書で説明される要求−応答トランスポートプロトコルの具体的な用途は、説明の目的で使用されているに過ぎず、明示的に主張されない限り、本発明の範囲を限定したり、または別の方法によって狭めたりしようとするものではない。

図１Ａは、例示的な実施形態による、要求−応答トランスポートプロトコル上での高信頼の単方向メッセージ交換形態のためのプロトコルスタックを示している。アプリケーションレベルメッセージ（図示せず）は、イニシエータ側エンドポイント１０５によって、例えばウェブサービスなどの分散システムプロトコルに従って、アプリケーションレイヤ１１５において生成することができる。一般にウェブサービスにおいては、アプリケーションレベルメッセージは、適切なＳＯＡＰヘッダを有するＳＯＡＰメッセージである。さらに、このメッセージは、アクセプタ側エンドポイント１１０において処理を行うための入力動作を一般に含むが、アクセプタ側エンドポイント１１０からイニシエータ側エンドポイント１０５へのアプリケーションレイヤ１６０での出力メッセージフローがないという点で、一方向メッセージと見なされる。

アプリケーションレベルメッセージは、高信頼メッセージングレイヤ１２０に渡され、そこにおいて、ＲＭプロトコル（例えばＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ、ＷＳ−Ｒｅｌｉａｂｉｌｉｔｙなど）に従ってフォーマットされる。高信頼メッセージングレイヤ１２０で受信されたメッセージ１３５はまた、以下で説明するように、対応する肯定応答メッセージが受信されない場合の再送信の可能性に備えて、イニシエータ側バッファ１３０に保存される。次に、アプリケーションレベルメッセージは、（例えば匿名ＨＴＴＰなどの）要求−応答トランスポートレイヤ１２５の要求フロー１４５を介して送信され、アクセプタ側エンドポイント１１０のトランスポートレイヤ１５６で受信される。アプリケーションレベルメッセージは、高信頼メッセージングレイヤ１５５に渡され、このレイヤは、アクセプタ側エンドポイント１１０のアプリケーションレイヤ１６０におけるその後の処理のために、受信メッセージ１７０をアクセプタ側バッファ１６５に保存する。

高信頼メッセージングレイヤ１５５からアプリケーションレイヤ１６０へは一方向の線が引かれているが、これは、イニシエータ側エンドポイントは一般にアドレシング可能でなく、および／または通信は要求−応答型のプロトコルを必要とするので、アプリケーションレイヤ１６０からイニシエータ側エンドポイント１０５へのメッセージフローがないことを示していることに留意されたい。しかし、先に述べたように、例示的な実施形態は、肯定応答（図示せず）およびその他のインフラストラクチャメッセージを要求−応答トランスポートレイヤ１５６、１２５を介して送信するために、例えばＨＴＴＰなど典型的な要求−応答トランスポートプロトコルに特徴的な応答フロー１４０を利用する。言い換えると、ＲＭインフラストラクチャ情報は、トランスポートレベル応答メッセージにリンクされ、またはピギーバックされる。

さらに、トランスポートレベル応答メッセージにリンクされるインフラストラクチャ情報は、複数の異なる方法で特徴づけることができることに留意されたい。例えば、インフラストラクチャ情報（例えばＡｃｋ応答）を生成して、トランスポートレベル応答にカプセル化することができ、次に、トランスポートレベル応答は、要求−応答トランスポートプロトコルの応答フロー１４０を介して伝送される。これは、インフラストラクチャ情報内にフォーマットされるようにトランスポートレベル応答メッセージを特徴づけるのに類似している。もちろん、インフラストラクチャ情報が、どのようにトランスポートレベル応答メッセージにリンクされるかを特徴づけるその他の方法が存在する。さらに、トランスポートレベル応答メッセージをインフラストラクチャ情報と一緒にカプセル化し、またはフォーマットするための、数多くの周知の方法が存在する。したがって、本発明に適用されるインフラストラクチャ情報のトランスポートレベル応答メッセージへのリンクは、インフラストラクチャ情報をトランスポートレベル応答メッセージにフォーマットまたはピギーバックするための任意のタイプのプロセスを包含すると広く解釈するべきである。

インフラストラクチャ情報が、どのようにトランスポートレベル応答にリンクされ、また応答フロー１４０を介してイニシエータ側エンドポイント１０５で受信されるかに関わらず、インフラストラクチャ情報が肯定応答（例えば、ＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇによって定義されたＡｃｋメッセージ）である場合、高信頼メッセージングレイヤ１２０は、イニシエータ側バッファ１３０から適切なアプリケーションメッセージ１３５を削除する。しかし、メッセージに対する肯定応答が受信されない場合、イニシエータ側エンドポイント１０５は、上で説明したのと同様の方式で（すなわち、ＲＭプロトコルに従って要求−応答トランスポートを使用して新しい要求を開始することによって）、メッセージ１３５の送信をリトライすることができることに留意されたい。一定の制限時間が過ぎても、または所定回数のリトライを行っても、またはその他のリトライポリシー管理手順を試みた後も、肯定応答が受信されない場合は、障害通知をアプリケーションレイヤ１１５に上げることができる。

高信頼メッセージングレイヤ１２０、１５５からのインフラストラクチャメッセージ（例えば、シーケンス生成またはシーケンス終了要求）は、どちらの方向にも送信することができるが、要求−応答トランスポートの制約を受けることに留意されたい。特に、アクセプタ側エンドポイント１１０からのインフラストラクチャメッセージは、イニシエータの要求に伴うトランスポートレベル応答の上にのみ出現することができる。さらに、トランスポート要求メッセージは、インフラストラクチャ（ＲＭプロトコル）情報ばかりでなく、（例えば、ＳＯＡＰヘッダ内のフィールドとして）アプリケーションレベルメッセージも含むことができることに留意されたい。

上で述べたように、肯定応答メッセージおよびその他のインフラストラクチャメッセージは、要求−応答トランスポートの応答フロー１４０上を送信される必要がある。しかし、アクセプタ側エンドポイント１１０は、アプリケーションレベルメッセージを受信した場合、肯定応答を送信しないと決定したときでも、要求−応答トランスポートプロトコルに準拠させるために、標準トランスポートレベル応答（例えば、ヌル応答）を送信すべきである。イニシエータ側エンドポイント１０５は、トランスポートレベル要求が完遂されたこと、またアクセプタ側エンドポイント１１０はもうこの応答フローを利用してインフラストラクチャメッセージを転送することができないということ以外、そのようなヌル応答から特別の意味を推論することはできない。例えば、ＨＴＴＰの場合、アクセプタ側エンドポイント１１０は、ＨＴＴＰの２０２ ＯＫ、２０４ Ｎｏ Ｃｏｎｔｅｎｔ、またはその他の同様のＨＴＴＰレベル応答メッセージを用いて応答することができる。この応答は、ＲＭインフラストラクチャによって処理されないが、ＲＭインフラストラクチャは、ＲＭインフラストラクチャ応答メッセージを待機すべきでないことを知る必要がある場合、トランスポートレベル応答を受信したことを知らされることができることに留意されたい。

別の例示的な実施形態は、ＲＭプロトコルに従って一方向メッセージ交換形態における１つまたは複数のメッセージを高い信頼性で転送するために、ＲＭシーケンスセッションの生成および使用をサポートする。シーケンスセッションを生成する要求は、（例えば、アプリケーションレベルメッセージにリンクされて）コネクションの要求フロー１４５を介して受信することができ、固有のシーケンス識別子が、一般に同じトランスポートコネクションの応答フロー１４０を介して直ちに送信される。しかし、本発明で利用可能なシーケンスセッションを生成する別の方法も存在することに留意されたい。例えば、イニシエータ側エンドポイント１０５が、固有のシーケンス識別子を生成し、それを要求に含めて送信することができ、または固有のシーケンス識別子をアウトオブバンドで送信することができる。したがって、シーケンスセッションを確立するよく知られた方法はどれも、本発明で利用することができ、シーケンスセッションをどのように確立するかについての具体的な言及はどれも、説明の目的で使用されているに過ぎず、明示的に主張されない限り、本発明の範囲を限定したり、または別の方法で狭めたりしようとするものではない。

一般に、シーケンス肯定応答は、対応するアプリケーションメッセージを受信したときに送信すべきである。言い換えると、シーケンスに対する肯定応答を遅延させ、一括処理する代わりに、例示的な実施形態では、１対１対応がメッセージと肯定応答の間で用いられるべきである。すなわち、メッセージは要求フロー１４５を介して送信され、対応する肯定応答は応答フロー１４０上で受信される。しかし、本発明では一括処理も利用できることに留意されたい。例えば、最終メッセージ表示を受信する前に―または最終メッセージ表示を受信したときですらも、イニシエータ１０５に一括肯定応答を、応答フロー１４０を介して送信することができる。しかし、上で述べたように、肯定応答が直ちに送信されない場合でも、要求−応答トランスポートプロトコル要求条件に準拠させるため、標準トランスポートレベル応答がイニシエータ１０５に送信されるべきである。

肯定応答のタイプ（すなわち、一括または個別）に関わらず、肯定応答は、着信コネクションの応答フロー１４０上で、またシーケンスセッションについてはそれらの応答フロー１４０上でのみ、イニシエータ側エンドポイント１０５に送信されるべきである。それにもかかわらず、イニシエータ側エンドポイント１０５は、先に送信されたメッセージに対する肯定応答を待機することなく、新しい要求−応答コネクション上でメッセージ（インフラストラクチャまたはアプリケーションレベルメッセージ）を送信することができる。イニシエータ側エンドポイント１０５は、いくつかの理由で、肯定応答を受信することなく、メッセージを送信したいと望むことがある。例えば、イニシエータ側エンドポイント１０５は、肯定応答を得ていないアプリケーションレベルメッセージ１３５の送信をリトライする必要があるかもしれない。代替として、またはそれと併せて、イニシエータ側エンドポイント１０５は、アクセプタ側エンドポイント１１０が肯定応答を一括処理しているという仮定の下で生成された新しいメッセージを送信したいと望むかもしれない。さらに、イニシエータ側エンドポイント１０５は、アクセプタ側エンドポイント１１０にインフラストラクチャメッセージを送信し、次に、アクセプタ側エンドポイント１１０に、例えば、一括処理されているかもしれない、または失敗したトランスポート応答により失われたかもしれない肯定応答を送るためにトランスポート応答を使用する機会を提供したいと望むかもしれない。

別の例示的な実施形態では、アクセプタ側エンドポイント１１０は、受信したアプリケーションメッセージを廃棄し、それに肯定応答を与えないことができる。アクセプタ側エンドポイント１１０は、シーケンスが指示されているのに、メッセージが順序通りに受信されなかった場合、またはメッセージを保存するバッファ領域が不足したため（例えば、フロー制御）、またはその他の数々の理由のため、これを行うよう選択することができる。しかし、アクセプタ側エンドポイントは、いずれの場合にしろ、トランスポートプロトコル要求条件に準拠させるために、少なくとも応答フロー上で標準トランスポートレベル応答を用いて応答するべきである。

また別の例示的な実施形態では、匿名要求−応答トランスポートプロトコル上で確立された単方向シーケンスを終了させる能力が提供される。上で説明したシーケンスセッション生成プロセスと同様に、シーケンス終了インフラストラクチャメッセージは、コネクションの要求フロー１４５を介して送信することができる。シーケンス終了メッセージは、インフラストラクチャプロトコルによって（例えば、ヘッダフィールドとして）、またはインフラストラクチャメッセージとして、アプリケーションレベルメッセージにリンクすることができる。いずれの場合も、アクセプタ側エンドポイント１１０は一般に、ＲＭプロトコルに準拠させるために、（シーケンスセッションのすべてのメッセージが受信されたと仮定して）シーケンスセッションとして送信された最終メッセージに対するシーケンス肯定応答を用いて応答すべきである。それにもかかわらず、何らかの理由により、肯定応答またはその他のインフラストラクチャメッセージがアクセプタ１１０によって送信されない場合、トランスポートプロトコルに準拠させるため、少なくとも標準トランスポート応答を応答フロー１４０上で送信すべきである。

図１Ｂは、例示的な実施形態による、要求−応答トランスポートプロトコル上での可能なＲＭプロトコルメッセージシーケンス交換の図を示している。ここに示されるように、イニシエータ側エンドポイント１０５は、単方向シーケンスセッションを生成する要求１０２を作成し、それを匿名要求−応答トランスポートの要求フロー上で送信する。イニシエータ側エンドポイント１０５からアクセプタ側エンドポイント１１０に向う矢印は、トランスポートプロトコルの要求フローを表し、アクセプタ側エンドポイント１１０からイニシエータ側エンドポイント１０５にＵターンして向う矢印は、トランスポートプロトコルの応答フローを表していることに留意されたい。さらに、単方向シーケンスセッションを生成する要求１０２は、アプリケーションレベルメッセージの中に含まれることができることに留意されたい。

単方向ＲＭプロトコルシーケンスセッションを生成する要求１０２に応答して、アクセプタ側エンドポイント１１０は、イニシエータ１０５にトランスポートレベル応答１０４をトランスポートの応答フロー上で返送する。この例に示されるように、このトランスポートレベル応答１０４は、単方向ＲＭシーケンスセッション用のシーケンス識別子１０８など、ＲＭインフラストラクチャ情報を含む。言い換えると、応答をトランスポートレベルの応答フロー上で送信する前に、インフラストラクチャ情報が、トランスポートレベル応答にリンクされる。

その後、イニシエータ側エンドポイント１０５は、アプリケーションレベルメッセージ１０６を要求−応答トランスポート用の後続コネクションの要求フロー上で送信するために、シーケンス識別子１０８を利用する。各メッセージは、順序づけおよびその他の高信頼メッセージング目的のために、メッセージ番号１１４によって識別されるべきである。アクセプタ側エンドポイント１１０は、アプリケーションレベルメッセージ１０６を受信すると、一般に、ＲＭ情報１１２を含むトランスポートレベル応答１０４を用いて応答する。より具体的には、ＲＭインフラストラクチャ情報１１２は、シーケンス識別子１０８、および１つまたは複数のアプリケーションレベルメッセージ用の肯定応答１２８を含むことができる。

トランスポートレベル応答１０４は、ＲＭ情報を含む必要はなく、単なる標準トランスポートレベル応答であることができる。例えば、次の交換に示されるように、シーケンス識別子１０８、および最終メッセージ１１６ヘッダを含む（一般には、図示されていないメッセージ番号も含む）、アプリケーションレベル一方向メッセージ１１８が送信される。イニシエータ側エンドポイント１０５が、メッセージをトランスポートの要求フローを介して送信した後、アクセプタ側エンドポイント１１０は、この例では、標準トランスポートレベルヌル応答１２２を用いて応答フロー上で応答する。上で述べたように、要求−応答トランスポートプロトコルに準拠させるために、そのような応答を送信することができる。しかし、この例では、ＲＭプロトコルに準拠させるために、アクセプタ側エンドポイント１１０は、メッセージに対する肯定応答１２８を最終的に送信するべきである。上で述べたように、一定の制限時間が過ぎても、または所定回数のリトライを行っても、またはその他のリトライポリシー管理手順を試みた後も、肯定応答が受信されない場合は、障害通知をアプリケーションレイヤに上げることができる。

最終メッセージに対する肯定応答が、イニシエータ側エンドポイント１０５によって受信されたと仮定すると、その後、シーケンス識別子１０８を含むシーケンス終了１２６が、要求−応答トランスポートプロトコルのもう一つの要求フローを介して送信される。最後に、この例では、アクセプタ側エンドポイント１１０が、別のトランスポートレベルヌル応答１２４を用いて応答する。そのような場合、両方の側が、シーケンスセッションの終了を判断することができる。ヌル応答１２４を送信する代わりに、アクセプタ側エンドポイント１１０は、シーケンス終了メッセージ１２６に対する肯定応答を用いて応答することもできることにも留意されたい。

本発明は、機能的ステップ（ｆｕｎｃｔｉｏｎａｌ ｓｔｅｐ）および／または非機能的動作（ｎｏｎ−ｆｕｎｃｔｉｏｎａｌ ａｃｔ）を含む方法に関して説明することもできる。以下の説明は、本発明を実施する際に実行することができるステップおよび／または動作に関するものである。通常、機能的ステップは、達成される結果に関して本発明を説明し、非機能的動作は、特定の結果を実現するためのより具体的な動作を説明する。機能的ステップおよび／または非機能的動作は、特定の順序で説明または請求することができるが、本発明は、ステップおよび／または動作の特定の順序または組み合わせに必ずしも限定されない。さらに、請求項の詳説―および以下の図２のフローチャートの説明―におけるステップおよび／または動作の使用は、そのような語の所望の特定の使用を示すために使用される。

図２は、本発明の様々な例示的な実施形態に関するフローチャートを示している。以下の図２の説明は、図１Ａおよび図１Ｂの対応する要素にときどき言及する。これらの図の特定の要素に言及することがあっても、そのような要素は、説明の目的で使用されているに過ぎず、明示的に主張されない限り、本発明の範囲を限定したり、または別の方法で狭めたりしようとするものではない。

図２は、要求−応答トランスポートプロトコル上でアプリケーションレベルメッセージを送信するときに、ＲＭプロトコルを提供する方法２００のフローチャート例を示している。イニシエータ側で、方法２００は、アプリケーションレベルメッセージを生成する動作２０５を含む。例えば、イニシエータ側エンドポイント１０５は、高信頼の一方向メッセージ交換形態によりアクセプタ側エンドポイント１１０に転送するため、アプリケーションレベルメッセージを生成することができる。一般に、イニシエータ側エンドポイント１０５は、アドレシング可能ではない。すなわち、アプリケーションレベル１１５のメッセージは、一般にアクセプタ側エンドポイント１１０における処理のための入力情報を含むが、アクセプタ側エンドポイント１１０からイニシエータ側エンドポイント１０５に返送されるアプリケーションレベル１６０の出力情報はない。もちろん、先に説明したように、インフラストラクチャメッセージ（例えばａｃｋ要求、セッション生成、セッション終了など）は、アプリケーションレベル１１５のメッセージにリンクされることもできる。

しかし、一般に、シーケンスセッションの開始を要求するインフラストラクチャメッセージ（および終了インフラストラクチャメッセージ）は、アプリケーションレベルメッセージにリンクされない。実際、通常、シーケンスセッション生成は、アプリケーションレイヤ１１５からの例えばＣｒｅａｔｅＳｅｓｓｉｏｎまたはＯｐｅｎ．ＳｅｓｓｉｏｎなどのローカルＡＰＩ呼出しに応答して、ＲＭレイヤ１２０によって生成される。したがって、先に述べたように、シーケンスセッションを確立もしくは開始する（および／またはシーケンスセッションを終了する）ための特定のプロセスは、説明の目的で使用されているに過ぎず、明示的に主張されない限り、本発明の範囲を限定したり、または別の方法で狭めたりしようとするものではない。

インフラストラクチャ情報がアプリケーションレベルメッセージにリンクされるかどうかに関わらず、方法２００は、ＲＭプロトコルに従ってアプリケーションレベルメッセージをフォーマットする動作２１０も含む。例えば、イニシエータ側エンドポイント１０５における高信頼メッセージングレベル１２０は、アプリケーションレベルメッセージをフォーマットし、リトライ目的のためにアプリケーションレベルメッセージ１３５のコピーをイニシエータ側バッファ１３０に保存する。次に、方法２００は、トランスポート要求フローを介してアプリケーションレベルメッセージを送信する動作２１５を含む。すなわち、例えば、メッセージは、高信頼メッセージングレイヤ１２０から下位の要求−応答トランスポートレイヤ１２５に送られる。次に、メッセージは、要求フロー１４５上をアクセプタ側エンドポイント１１０に送信される。要求−応答トランスポートプロトコルは、例えば匿名ＨＴＴＰなどの匿名トランスポート、またはその他の類似の要求−応答トランスポートプロトコルとすることができる。

いずれにしても、アクセプタ側で、方法２００は、要求フローを介してアプリケーションレベルメッセージを受信する動作２２５をさらに含む。例えば、アクセプタ側エンドポイント１１０は、要求−応答トランスポートレイヤ１５６において要求フロー１４５を介してアプリケーションレベルメッセージを受信することができる。その後、方法２００は、アプリケーションレベルメッセージがＲＭプロトコルに従ってフォーマットされていることを確認する動作２３０も含む。さらに、方法２００は、ＲＭプロトコルインフラストラクチャ情報をトランスポートレベル応答にリンクする動作２３５を含む。例えば、高信頼メッセージングレイヤ１５５は、アクセプタ側エンドポイント１１０のアプリケーションレイヤ１６０による後の処理のために、アプリケーションレベルメッセージ１７０をアクセプタ側バッファ１６５に保存することができる。その後、高信頼メッセージングレイヤ１５５は、トランスポートレベル応答を、イニシエータ１０５からアクセプタ１１０に送信された１つまたは複数のアプリケーションレベルメッセージの高信頼の交換に対応するＲＭインフラストラクチャ情報１１２にリンクすることができる。

トランスポートレベル応答にリンクされるインフラストラクチャ情報は、アクセプタが１つまたは複数のアプリケーションレベルメッセージを高い信頼性で受信したことを示す肯定応答とすることができる。肯定応答は、要求フロー上を送信されたアプリケーションレベルメッセージに対する肯定応答を含むことができる。さらに、フォーマットされたアプリケーションレベルメッセージは、ＲＭプロトコルに従って肯定応答要求にリンクすることもできる。そのような場合、肯定応答は、肯定応答要求に応答するものとなる。代替として、アプリケーションレベルメッセージが単方向シーケンスセッションを生成する要求にリンクされる場合、ＲＭ情報は、シーケンス識別子１０８とすることができる。

トランスポートレベル応答をフォーマットした後、方法２００は、トランスポートレベル応答を、応答フローを介して送信する動作２４０を含む。同様に、イニシエータ側では、方法２００は、対応するトランスポートレベル応答を、応答フローを介して受信する動作２２０も含む。例えば、アクセプタ側エンドポイント１１０は、トランスポートレベル応答、例えば１０４、１１４を、応答フロー１４０を介して送信し、その後、トランスポートレベル応答は、イニシエータ側エンドポイント１０５において受信される。次に、ＲＭまたはインフラストラクチャレベル応答が、トランスポートレベル応答から取り出され、ＲＭレイヤ１２０に供給される。次に、ＲＭレイヤ１２０は、イニシエータ側バッファ１３０からメッセージ１３５のコピーを削除する。

別の例示的な実施形態では、アプリケーションレベルメッセージを送信する前に、固有のシーケンス識別子によって識別される単方向シーケンスセッションが、イニシエータ１０５とアクセプタ１１０の間で確立される。したがって、アプリケーションレベルメッセージは、固有のシーケンス識別子を含む。その後、固有のシーケンス識別子を含む後続メッセージは、ＲＭプロトコルに従ってフォーマットされ、要求−応答トランスポートの要求フロー１４５を介して送信することができる。この後続メッセージは、最初のアプリケーションレベルメッセージに対応する肯定応答を受信する前に、送信することができる。その後、後続トランスポートレベル応答が、イニシエータ１０５において要求−応答トランスポートの応答フロー１４０を介して受信される。

さらに別の実施形態では、後続メッセージは、アクセプタ側エンドポイント１１０における処理のための入力情報を含むアプリケーションレベルメッセージであるが、イニシエータ側エンドポイントに返送されるアプリケーションレベル出力情報はない。この実施形態では、後続トランスポートレベル応答は、アクセプタ側エンドポイント１１０が少なくとも後続アプリケーションレベルメッセージを受信したことを示す肯定応答１２８を含むＲＭプロトコルインフラストラクチャ情報１１２に、リンクされることができる。

後続メッセージが、シーケンス終了エレメント１２６を含むＲＭプロトコルインフラストラクチャメッセージである場合、要求−応答トランスポートプロトコルに準拠させるため、後続のトランスポートレベル応答、例えばヌル応答１２４を送信することができる。代替として、トランスポートレベル応答は、アクセプタ１１０がシーケンスセッションにおける最後のアプリケーションレベルメッセージを受信したことを示す肯定応答１２８であるＲＭプロトコルインフラストラクチャ情報を含むことができる。

さらに別の実施形態では、トランスポートプロトコルは、ＨＴＴＰとすることができ、その場合、後続のトランスポートレベル応答は、要求−応答トランスポートプロトコルに準拠させるために送信されるＨＴＴＰメッセージ（例えば、２０２ ＯＫメッセージ）となる。また別の例示的な実施形態では、別のアプリケーションレベルメッセージがシーケンスセッションにおいて受信されるものの、順序通り到着していないため、アクセプタ側エンドポイントはこれを廃棄し、肯定応答を送信しないが、要求−応答トランスポートプロトコルに準拠させるため、トランスポートレベル応答は送信される。

本発明の範囲内の実施形態は、コンピュータ実行可能命令またはデータ構造をそこに格納して搬送または保持するためのコンピュータ読取り可能媒体も含む。そのようなコンピュータ読取り可能媒体は、汎用または専用コンピュータによってアクセスできる任意の利用可能媒体とすることができる。例えば、そのようなコンピュータ読取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくはその他の光ディスク記憶、磁気ディスク記憶またはその他の磁気記憶装置、またはコンピュータ実行可能命令またはデータ構造の形態の所望のプログラムコード手段を搬送または保存するのに使用でき、汎用または専用コンピュータによってアクセスできるその他の任意の媒体を含むことができるが、これらに限定されるものではない。情報がネットワークまたは別のコネクション（有線、無線、または有線もしくは無線の組み合わせ）を介してコンピュータに転送または提供される場合、コンピュータは、コネクションをコンピュータ読取り可能媒体として適切に見なす。したがって、そのようなコネクションは、当然のことながら、コンピュータ読取り可能媒体と呼ばれる。上記のものの組み合わせも、コンピュータ読取り可能媒体の範囲内に含まれるべきである。コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置に一定の機能または機能群を実行させる命令およびデータを含む。

図３および以下の説明は、本発明を実施することができる適切なコンピューティング環境についての簡略で概括的な説明を提供することを意図したものである。必須ではないが、本発明は、ネットワーク環境内のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令を一般的前提として説明される。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連付けられたデータ構造、およびプログラムモジュールは、本明細書で開示される方法のステップを実行するプログラムコード手段の例を表す。そのような実行可能命令または関連データ構造の特定のシーケンスは、そのようなステップで説明される機能を実施するための対応する動作の例を表す。

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

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

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

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

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

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

本発明は、その主旨または本質的特徴から逸脱することなく、その他の特定の形態でも実施することができる。説明した実施形態は、すべての点で、説明的なものに過ぎず、限定的なものではないと見なされるべきである。したがって、本発明の範囲は、上述の説明によってではなく、むしろ添付の特許請求の範囲によって示される。特許請求の範囲の等価物の意味および範囲内に収まるすべての変更は、それらの範囲に包含されるものとする。

例示的な実施形態による、要求−応答トランスポートプロトコル上でのアプリケーションレベルメッセージの高信頼な一方向メッセージ交換形態のためのプロトコルスタックの図である。 例示的な実施形態による、要求−応答トランスポートプロトコル上での一可能性としての高信頼な一方向メッセージシーケンス交換の図である。 例示的な実施形態による、要求−応答トランスポートプロトコル上でアプリケーションレベルメッセージを送信するときに、分散システム用の高信頼なメッセージングプロトコルを提供する方法のフローチャートである。 本発明にとって適切な動作環境を提供するシステム例の図である。

符号の説明

１０５ イニシエータ側エンドポイント
１１０ アクセプタ側エンドポイント
３２０ コンピュータ
３２７ 磁気ハードディスクドライブ
３２８ 磁気ディスクドライブ
３３０ 光ディスクドライブ

Claims (39)

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. 前記アプリケーションレベルメッセージを送信する前に、固有のシーケンス識別子によって識別される単方向シーケンスセッションが、前記イニシエータと前記アクセプタの間で確立され、前記アプリケーションレベルメッセージは、前記固有のシーケンス識別子を含むことを特徴とする請求項３２に記載のコンピュータプログラム製品。

Images