(57)【要約】【課題】ＨＴＴＰ通信の回答フローをオープンに維持できるようにする【解決手段】例示的な諸実施形態では、単一の要求に対応する応答全体のうちの一部がＨＴＴＰ回答フローを横切って送信できるように、通信用のＨＴＴＰ回答フローをオープンの状態で維持する。応答全体のうちの様々な部分が対応するサービスエンドポイントで使用可能になると、サービスはこのメッセージを適切にカプセル化し、それらを要求側エンドポイントへ送信する。その後、応答の受信側または要求側エンドポイントは、応答の使用可能部分を読み取ることが可能であり、埋め込まれた部分を適切に復号し、これらを適宜自由に処理することができる。したがって、応答のいくつかの部分について１つしか要求されないため、貴重なシステムリソースは、要求側エンドポイントの１回のみの認証および／または検証を要求するために予約される。【選択図】図１Ａ
2006190282.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の検証および許可に関連付けられた、貴重なシステムリソースを節約するために複数の異なる部分としてＨＴＴＰ応答を転送する方法であって、
分散型システムのエンドポイント間で通信を確立するために、ＨＴＴＰ要求フローを介して要求メッセージを送信するステップと、
対応するＨＴＴＰ回答フローを介して応答の第１の部分を受信するステップであって、そこでは前記第１の部分は第１の時間枠で受信されるステップと、
前記応答の追加部分を受信するために前記ＨＴＴＰ回答フローをオープンの状態で維持するステップと、
他の要求メッセージを送信することなく、前記ＨＴＴＰ回答フローを介して前記応答の第２の部分を受信するステップであって、そこでは前記第２の部分は前記第１の時間枠とは異なる第２の時間枠で受信されるステップと
を備えることを特徴とする方法。
【請求項２】
前記第１および第２の部分は非同期的に受信されることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１および第２の部分は、前記分散型システム内の別々のサービスモジュールから処理される離散的メッセージであることを特徴とする請求項１に記載の方法。
【請求項４】
前記第１および第２の部分は、前記分散型システムの要求側エンドポイントから送信されたエンドポイント参照を使用して、前記別々のサービスモジュールに前記離散的メッセージを要求した単一のサービスから受信されることを特徴とする請求項３に記載の方法。
【請求項５】
前記エンドポイント参照は前記要求メッセージに含まれることを特徴とする請求項４に記載の方法。
【請求項６】
前記エンドポイント参照は、前記ＨＴＴＰ要求フローとは別の通信トランスポートを介して制御メッセージ内で送信されることを特徴とする請求項４に記載の方法。
【請求項７】
前記第１および第２の部分はクライアント側でサービスから受信され、
前記分散型システム内の前記クライアントと前記サービスとの間に双方向通信セッションを確立するために、第２のＨＴＴＰ要求フローを介して前記サービスから第２の要求メッセージを受信するステップと、
対応する第２のＨＴＴＰ回答フローを介して第２の応答の第１の部分を送信するステップであって、そこでは前記第２の応答の前記第１の部分は第３の時間枠で送信されるステップと、
他の要求メッセージを受信することなく、前記第２のＨＴＴＰ回答フローを介して前記第２の応答の第２の部分を送信するステップであって、そこでは前記第２の部分は前記第３の時間枠とは異なる第４の時間枠で送信されるステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
１つまたは複数の制御メッセージは、前記確立された通信を管理するために別々の通信セッションで送信されることを特徴とする請求項１に記載の方法。
【請求項９】
ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の検証および許可に関連付けられた、貴重なシステムリソースを節約するために複数の異なる部分としてＨＴＴＰ応答を転送する方法であって、
分散型システムのエンドポイント間で通信を確立するために、ＨＴＴＰ要求フローを介して要求メッセージを受信するステップと、
対応するＨＴＴＰ回答フローを介して応答の第１の部分を送信するステップであって、そこでは前記第１の部分は第１の時間枠で送信されるステップと、
他の要求メッセージを受信することなく、前記ＨＴＴＰ回答フローを介して前記応答の第２の部分を送信するステップであって、そこでは前記第２の部分は前記第１の時間枠とは異なる第２の時間枠で送信されるステップと
を備えることを特徴とする方法。
【請求項１０】
前記第１および第２の部分は、単一のサービスモジュールから処理および受信された離散的メッセージであることを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１および第２の部分はサービスからクライアントに送信され、
前記分散型システム内の前記クライアントと前記サービスとの間に双方向通信セッションを確立するために、第２のＨＴＴＰ要求フローを介して前記クライアントに第２の要求メッセージを送信するステップと、
対応する第２のＨＴＴＰ回答フローを介して第２の応答の第１の部分を受信するステップであって、そこでは前記第２の応答の前記第１の部分は第３の時間枠で送信されるステップと、
他の要求メッセージを送信することなく、前記第２のＨＴＴＰ回答フローを介して前記第２の応答の第２の部分を受信するステップであって、そこでは前記第２の部分は前記第３の時間枠とは異なる第４の時間枠で送信されるステップと
をさらに含むことを特徴とする請求項９に記載の方法。
【請求項１２】
１つまたは複数の制御メッセージは、前記確立された通信を管理するために別々の通信セッションで送信されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記１つまたは複数の制御メッセージは、「ｉｓ  ｉｔ  ｏｋａｙ  ｔｏ  ｂｕｌｋ」、「ｓｕｓｐｅｎｄ」、「ｒｅｓｕｍｅ」、「ｐｉｎｇ」、「ｒｅｃｏｎｎｅｃｔ」、「ｍｕｌｔｉｐｌｅｘ  ｉｎｉｔｉａｔｉｏｎ」、または「ｄｉｓｃｏｎｎｅｃｔｉｏｎ」から選択されることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記第１の部分、前記第２の部分、またはその両方は、ストリーム化されたかまたは個別のメッセージであることを特徴とする請求項１１に記載の方法。
【請求項１５】
ＨＴＴＰ要求応答トランスポートを使用する分散型システムにおいて、対応するＨＴＴＰ要求の検証および許可に関連付けられた、貴重なシステムリソースを節約するために複数の異なる部分としてＨＴＴＰ応答を転送する方法を実施するためのコンピュータプログラム製品であって、
分散型システムのエンドポイント間で通信を確立するために、ＨＴＴＰ要求フローを介して要求メッセージを送信するステップと、
対応するＨＴＴＰ回答フローを介して応答の第１の部分を受信するステップであって、そこでは前記第１の部分は第１の時間枠で受信されるステップと、
前記応答の追加部分を受信するために前記ＨＴＴＰ回答フローをオープンの状態で維持するステップと、
他の要求メッセージを送信することなく、前記ＨＴＴＰ回答フローを介して前記応答の第２の部分を受信するステップであって、そこでは前記第２の部分は前記第１の時間枠とは異なる第２の時間枠で受信されるステップと
を、メッセージシステムに実行させることが可能なコンピュータ実行可能命令をさらに備えることを特徴とするコンピュータプログラム製品。
【請求項１６】
前記第１および第２の部分は、前記分散型システム内の別々のサービスモジュールから処理された離散的メッセージであることを特徴とする請求項１５に記載のコンピュータプログラム製品。
【請求項１７】
前記第１および第２の部分は、単一のサービスモジュールから処理および受信された離散的メッセージであることを特徴とする請求項１５に記載のコンピュータプログラム製品。
【請求項１８】
前記第１および第２の部分はクライアント側でサービスから受信され、
前記分散型システム内の前記クライアントと前記サービスとの間に双方向通信セッションを確立するために、第２のＨＴＴＰ要求フローを介して前記サービスから第２の要求メッセージを受信するステップと、
対応する第２のＨＴＴＰ回答フローを介して第２の応答の第１の部分を送信するステップであって、そこでは前記第２の応答の前記第１の部分は第３の時間枠で送信されるステップと、
他の要求メッセージを受信することなく、前記第２のＨＴＴＰ回答フローを介して前記第２の応答の第２の部分を送信するステップであって、そこでは前記第２の部分は前記第３の時間枠とは異なる第４の時間枠で送信されるステップとをメッセージシステムに実行させることが可能なコンピュータ実行可能命令をさらに備えることを特徴とする請求項１５に記載のコンピュータプログラム製品。
【請求項１９】
１つまたは複数の制御メッセージは、前記確立された通信を管理するために別々の通信セッションで送信されることを特徴とする請求項１５に記載のコンピュータプログラム製品。
【請求項２０】
前記１つまたは複数の制御メッセージは、「ｉｓ  ｉｔ  ｏｋａｙ  ｔｏ  ｂｕｌｋ」、「ｓｕｓｐｅｎｄ」、「ｒｅｓｕｍｅ」、「ｐｉｎｇ」、「ｒｅｃｏｎｎｅｃｔ」、「ｍｕｌｔｉｐｌｅｘ  ｉｎｉｔｉａｔｉｏｎ」、または「ｄｉｓｃｏｎｎｅｃｔｉｏｎ」から選択されることを特徴とする請求項１９に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ＨＴＴＰ要求応答タイプの通信を使用したコンピューティングシステム間でのメッセージ転送に関する。より詳細には、本発明は、対応するＨＴＴＰ要求の検証（ｖａｌｉｄａｔｅ）および許可（ａｕｔｈｏｒｉｚｅ、認可）に関連付けられた貴重なシステムリソースを節約するため、ならびに、その他の方法では不可能な可能性のある環境で要求側に双方向通信を提供するために、複数の異なる部分としてエンドポイント間でＨＴＴＰ応答を転送する。
【背景技術】
【０００２】
コンピュータネットワークは、１台のコンピュータまたはデバイス（以下、「コンピューティングシステム」と呼ぶ）が、電子メッセージを使用して他のコンピューティングシステムとネットワークを介して通信可能にすることによって、我々の情報の伝達および情報へのアクセスの能力を向上させてきた。コンピューティングシステム間で電子メッセージを転送する場合、しばしば電子メッセージは、電子メッセージ内のデータに関してオペレーション（たとえば、パケット化、経路指定、フロー制御など）を実行するプロトコルスタックを通過することになる。オープンシステム相互接続（ＯＳＩ）モデルは、こうしたプロトコルスタックを実施するためのネットワーキングフレームワークの一例である。
【０００３】
ＯＳＩモデルは、電子メッセージを転送するためのオペレーションをいくつかの別個の「層」に分割し、それぞれがデータ転送プロセスにおいて一定のオペレーションを実行するように指定される。プロトコルスタックは潜在的にそれぞれの層を実施することができるが、多くのプロトコルスタックは、ネットワークを横切ってデータを転送する際に使用するための選択的な層のみを実施する。たとえばデータがコンピューティングシステムから伝送される場合、アプリケーション層を起点とし、中間の下位層へと下方へ通過してネットワークに達する。データがネットワークからコンピューティングデバイスで受け取られる場合、物理層に入り、中間の高位層へと上方へ通過して最終的にアプリケーション層で受け取られる。最上位層であるアプリケーション層は、アプリケーションおよびエンドユーザプロセスをサポートする責務を負う。ほとんどのプロトコルスタックが組み込んでいる他の層が、トランスポート層である。トランスポート層の一例が、伝送制御プロトコル（ＴＣＰ）である。
【０００４】
分散型システム（たとえばウェブサービス環境）では、サービスおよびサービスに関する要求は、（ＨＴＴＰ）を使用して頻繁にトランスポートされる。ハイパーテキスト転送プロトコルは、ＯＳＩモデルのアプリケーション層と他の下位層との間で動作し、分散型システム環境でのコンテンツの転送を容易にする。ほとんどのネットワークプロトコルと同様に、ＨＴＴＰはクライアントサーバモデルを使用する。より具体的に言えば、クライアントコンピュータシステム（以下、「クライアント」または「要求側」エンドポイントと呼ぶ）は接続をオープンし、要求フローを介してサーバ（以下、「サーバ」または「サービス」エンドポイントと呼ぶ）に要求メッセージを送る。次にサーバは、ＨＴＴＰ通信の回答フローを介して、通常は要求されたリソース（たとえば、ファイル、動的に生成された照会結果、または他の同様のデータの塊）を含む応答メッセージを返す。応答を送達した後、サーバは接続をクローズし、ＨＴＴＰをステートレス（ｓｔａｔｅｌｅｓｓ）プロトコルにする、すなわちトランザクション間のいかなる接続情報も維持しない。
【０００５】
ＨＴＴＰがステートレスプロトコルであるため、ＨＴＴＰ認証はユーザがログインおよび／またはログアウトすることになるセッションの概念をサポートしない。したがって、
ＨＴＴＰ（すなわち、ＨＴＴＰ要求）を介してトランスポートされるコンテンツにアクセスするための各要求は、適切なＨＴＴＰ認証情報を含まなければならない。したがって、認証情報を処理すること、およびサービスエンドポイントで受け取られる各要求についてクライアントを検証することに関連付けられた途方もない量のオーバヘッドがある。
【０００６】
たとえば、通常、ＨＴＴＰプロトコルは、通常は認証タイプおよび信用証明情報（ｃｒｅｄｅｎｔｉａｌ）の形式である、特別なヘッダを介して各ＨＴＴＰ要求が供給されることになる認証情報を提供する。クライアントがこれらの信用証明情報を取得および伝送する方法は、以下のとおりである。クライアントがウェブサイトまたは認証を必要とする他のこうしたサービスに最初にアクセスしようとすると、通常、サービスは要求されたコンテンツまたは情報の提供を拒否し、クライアントにＨＴＴＰエラーメッセージ（たとえば未許可メッセージ）ならびに何らかの形のチャレンジ（ｃｈａｌｌｅｎｇｅ）を戻すことになる。クライアントはこのメッセージを受け取ると、サービスリソースにアクセスするために、適切な信用証明情報を使用してチャレンジに適切に応答することが必要となる。たとえば、チャレンジを受け取ったクライアントは、ユーザ名および／またはパスワードを要求するポップアップダイアログボックスをユーザに提示することができる。代替えとしてまたは関連して、チャレンジは、トークン、たとえばＸ．５０９、Ｋｅｒｂｅｒｏｓ、または他の同様のトークンなどの、何らかの他のタイプの信用証明情報を必要とする場合がある。さらに、他のタイプのチャレンジも適用可能である。
【０００７】
チャレンジのタイプにかかわらず、ユーザ（または場合によってはクライアント）が（たとえば正しいパスワードを入力することによって）適切な信用証明情報を提供した後、クライアントは元のＨＴＴＰ要求をサーバに伝送することができるが、この時点でヘッダラベルの引数としての信用証明情報を含む許可ヘッダを追加することができる。サービスがこの含まれた信用証明情報を受け入れ、有効なコンテンツを返すと、通常、クライアントはこれらの信用証明情報をキャッシュに入れ、新しい要求ごとに、それらを同じサービスまたは同じコンテンツに関連付けられた派生サービスに再伝送する。
【０００８】
処理に比較的長い時間のかかる大規模ファイルの転送または要求（たとえばローン処理）時には、ファイル全体を転送するかまたは要求全体を処理するために、いくつかの要求が実行される。これは大部分がＨＴＴＰの性質によるものであり、クライアントは、要求に対応する回答フローを横切って送信することなくそれらに送信できるデータがないという点で、アドレス指定不能であるとみなされる。したがって、処理に時間のかかる大規模ファイルおよび要求全体について、クライアントは認証情報を含む要求を継続的に送信しなければならず、サービスはこうした認証信用証明情報を継続的に処理し、要求全体のうちの適切な部分が使用可能になった場合にこれを戻さなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
各要求についてのこの継続的な認証および検証プロセスは、他の場所で（たとえば応答全体の処理で）利用できる貴重なシステムリソースを消費する。同様に、ファイアウォールの厳密性に関連付けられた継続的な要求の処理も、貴重なシステムリソースを消費する。
【００１０】
したがって、応答全体の一部分が使用可能になった場合にこれらをクライアントに送るために、ＨＴＴＰ通信の回答フローをオープンに維持できるようにすることが求められている。言い換えれば、応答全体の複数の部分（ｐｏｒｔｉｏｎｓ）を、こうした部分についてのいくつかの要求を受信／送信する必要なしに、受信／送信できるようにすることが求められている。
【課題を解決するための手段】
【００１１】
上記で識別された現在のＨＴＴＰ要求応答タイプ通信の欠陥および欠点は、本発明の例示的な実施形態によって克服される。たとえば本発明は、検証および対応するＨＴＴＰ要求に関連付けられた貴重なシステムリソースを節約するために、複数の異なる部分としてＨＴＴＰ応答を転送する。
【００１２】
例示的な実施形態では、分散型システムにおいてエンドポイント間の通信を確立するためにＨＴＴＰ要求を介して要求メッセージを送信する。応答の第１の部分は、第１の時間枠で対応するＨＴＴＰ回答フローを介して受信される。その後、ＨＴＴＰ回答フローは、応答の追加部分を受信するためにオープンのまま維持される。他の要求メッセージを送信することなく、応答の第２の部分は、第１の時間枠とは異なる第２の時間枠でＨＴＴＰ回答フローを介して受信される。
【００１３】
他の例示的な実施形態では、分散型システムにおいてエンドポイント間の通信を確立するためにＨＴＴＰ要求を介して要求メッセージを受信する。応答の第１の部分は、第１の時間枠で対応するＨＴＴＰ回答フローを介して受信される。他の要求メッセージを受信することなく、応答の第２の部分は、第１の時間枠とは異なる第２の時間枠でＨＴＴＰ回答フローを介して送信される。
【００１４】
本発明の追加の特徴および利点について以下で説明するが、この説明から一部が明らかとなるか、または本発明を実施することによって習得可能である。本発明の特徴および利点は、添付の特許請求の範囲で具体的に指摘された計器および組み合わせを利用して、実現および取得することができる。本発明のこれらおよび他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかとなるか、または本発明を以下に記載されたとおりに実施することによって習得可能である。
【００１５】
本発明の前述および他の利点および特徴が取得可能な方法を説明するために、上記では簡単に説明した本発明のより具体的な説明を、添付の図面に例示された特定の実施形態を参照しながら行う。これらの図面が本発明の典型的な実施形態のみを示しているため、その範囲を限定するものとはみなされないことを理解した上で、添付の図面を使用しながら、追加の特異性および詳細について記載および説明する。
【発明を実施するための最良の形態】
【００１６】
本発明は、貴重なシステムリソースを節約するために、複数の異なる部分としてエンドポイント間でＨＴＴＰ応答を転送するための方法、システム、およびコンピュータプログラム製品にまで及ぶ。本発明の諸実施形態は、以下でより詳細に説明するように、様々なコンピュータハードウェアを含む特定用途向けまたは汎用のコンピュータを備えることができる。
【００１７】
本発明では、メッセージまたは応答全体のうちの一部がＨＴＴＰ回答フローを横切って送信できるように、通信用のＨＴＴＰ回答フローをオープンの状態に維持する。応答全体のうちの様々な部分が対応するサービスエンドポイントで使用可能になると、サービスはこのメッセージを適切にカプセル化し、それらを要求側エンドポイントへ送信する。カプセル化は、通常、各サービス専用となるため、その特有の詳細は本発明にとって中核的ではない。それにもかかわらず重要なことは、応答の断片または一部を読み取り、カプセル化されたメッセージの境界を決定するための合意によって定められた方法があることである。したがって１つの要求の結果として、応答は、実際には応答全体の諸部分からなるストリームであり、そのそれぞれが要求全体の断片である。
【００１８】
その後、応答の受信側または要求側エンドポイントは、応答の使用可能部分を読み取ることが可能であり、埋め込まれた部分を適切に復号し、これらを適宜自由に処理することができる。したがって、たとえ完全なＨＴＴＰ応答がまだ受信されていない場合であっても、要求側エンドポイントは、受信されたそれぞれの埋め込まれた部分またはメッセージに基づいて作業を開始することができる。加えて、応答のいくつかの部分について要求が１つしか作成されないので、貴重なシステムリソースは、要求側エンドポイントの１回のみの認証および／または検証を要求するために予約される。
【００１９】
図１Ａは、前述の有利な諸実施形態のうちのいくつかを示す図である。図からわかるように、分散型システム１００は、要求側エンドポイント１６５と、いくつかのサービスモジュール１４７、１５０、１５５、１６０を含むことが可能なサービスエンドポイント１４５とを含む。一実施形態では、要求側エンドポイント１６５はサービスエンドポイント１４５との通信を確立するために、ＨＴＴＰ要求フロー１２０を介して要求メッセージ１１５を送信する。要求メッセージ１１５は、通常、要求側エンドポイント１６５を認証するための適切な信用証明情報を含むことになる。加えて、本発明では他の認証方法も使用可能である。たとえば要求側エンドポイントは、要求メッセージ１１５を認証するために共有秘密鍵（ｓｈａｒｅｄ  ｓｅｃｒｅｔ）または他の方法を確立することができる。加えて本発明では、任意の良く知られたタイプの信用証明情報（たとえば、トークン、共有秘密鍵、暗号化など）も使用可能である。したがって、本明細書で説明する任意の特定の認証方法および／または信用証明情報タイプは、例示の目的でのみ使用されるものであって、本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００２０】
少なくとも要求側エンドポイント１６５が適切に認証されたことを条件として（および、このエンドポイントが以下で説明するようなカプセル化フォーマットをサポートし、これに合意していることを条件として）、応答全体１５０のうちの部分１３５、１４０が使用可能になった場合、これらをサービスエンドポイント１４５から要求側エンドポイント１６５へ送信することができる。たとえば、応答１５０の第１の部分は、第１の時間枠でＨＴＴＰ回答フロー１２５を横切って送信することが可能であり、応答１５０の第２の部分１４０が使用可能になった場合、要求側エンドポイント１６５がＨＴＴＰ回答フロー１２５をオープンの状態で維持していることを条件として、第２の時間枠で、同じＨＴＴＰ回答フロー１２５を横切って送信することも可能である。
【００２１】
例示的諸実施形態では、通信のための任意のタイプの実際の交換に先立って、２つのエンドポイント１６５、１４５がＨＴＴＰ回答フロー１２５のために回答フローをオープンの状態で維持するようサポートしていることを確認することに留意されたい。こうした検証により、２つのエンドポイント１６５、１４５は、回答フロー１２５を通信の間オープンの状態で維持するための何らかのタイプの符号化に合意することができる。したがって、部分１３５、１４０のパッケージングは、通常、要求側１６５およびサービス側１４５のエンドポイント専用となる。さらにこの合意は本来動的であり、エンドポイント１６５、１４５は別々の通信中に異なるタイプの符号化に合意することができる。加えて符号化は事前に決定することが可能であり、この場合、こうした検証および動的に合意される符号化は不要である。
【００２２】
カプセル化についての合意標準の一例は、メッセージ、たとえば拡張可能マークアップ言語（ＸＭＬ）文書のヘッダ部分を使用する。この例では、サービスエンドポイント１４５は、以下でより詳細に説明するように、１つまたは複数のイベントが発生するまで、「エンドメッセージ」ヘッダを含めることなく、ＨＴＴＰ返答フロー１２５を横切って部分１３５、１４０を継続的に送信することができる。それにもかかわらず、異なる部分１３５、１４０がすべて応答全体１５０の一部であることを要求側エンドポイント１６５が理解するように、メッセージの本文を符号化する必要がある。
【００２３】
応答１５０の部分１３５、１４０は、同じ応答内であってもサイズおよびデータのタイプが変化する可能性があるという点で、任意のデータであることにも留意されたい。たとえば、一方の部分１３５がストリーム化されたデータであり、他方の部分１４０が単一メッセージであってもよい。さらに本発明は、他のデータのタイプおよびフォーマットも使用可能である。したがって、メッセージのいずれの特定のタイプまたはフォーマット化も例示の目的でのみ使用されるものであり、明示的に主張されない限り、本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００２４】
前述のように、ＨＴＴＰ要求回答通信の回答フロー１２５をオープンの状態で維持することを望む場合には、いくつかの利点および理由がある。たとえばサービスエンドポイント１４５は、完全な回答を生成するのには時間がかかるが、より早い時期に回答の断片が使用可能である場合、複数の応答を要求側エンドポイント１６５に送信することを望む場合がある。要求側エンドポイント１６５がサービスエンドポイント１４５から商品の購入を希望する場合などが、このケースに当てはまる可能性がある。要求メッセージ１１５を受信すると、サービスエンドポイント１４５は最初に、要求メッセージ１１５が受信されたことを要求側エンドポイント１６５に示す第１の部分１３５を送信することができる。その後サービスエンドポイント１４５は、何らかの後続の時点で、クレジットカード情報または他の個人情報を検証し、個人情報を確認する応答全体１５０の第２の部分１４０を要求側エンドポイント１６５に送信することができる。最終的に製品がユーザに出荷される場合、サービスエンドポイント１４５は、商品が出荷されたことを示す応答全体１５０の後続の部分１３５、１４０を、要求側エンドポイント１６５に送信することができる。サービスエンドポイント１４５が使用できるようになった時点で、追跡または他の情報などの応答１５０の任意の他の後続部分１３５、１４０を、情報の部分１３５、１４０として送信することができる。
【００２５】
ＨＴＴＰ回答フロー１２５をオープンの状態で維持するための他の理由は、完全な応答１５０が、サービスモジュールＡ〜Ｃ  １６０、１５５、１５０などの異なるソースからのメッセージの組み合わせである可能性があることである。同様に、要求１１５も、異なるサービスモジュールＡ〜Ｃ  １６０、１５５、１５０からの要求の集まりである可能性がある。どちらの場合でも、サービスエンドポイント１４５はいくつかのサービスモジュール１６０、１５５、１５０から情報を取得または収集することができる。たとえば、単一のサーバ１４７は、他のサービスモジュール１６０、１５５、１５０から提供されたサービスを利用し、これらを応答全体１５０の部分１３５、１４０として含めることができる。たとえば前述の例では、サービスエンドポイント１４５は、サービスモジュールＡ  １６０を介してクレジットカード情報または他の個人情報を検証し、サービスモジュールＢ  １５５から送達状況を受け取り、サービスモジュールＣ  １５０から追跡情報を取り出すことができる。情報のこれらの部分が使用可能になると、サーバ１４７は様々な部分１３５、１４０に対するプロキシまたはルータとして動作し、前述のようにＨＴＴＰ回答フロー１２５を横切ってそれらを転送することができる。
【００２６】
前述のように、サーバ１４７がサービスエンドポイント１４５内の様々なモジュール１６０、１５５、１５０から情報を取り出す方法をどのように知るかは異なる場合がある。たとえば、適切な合意に基づく符号化の場合、要求側エンドポイント１６５は、たとえば要求メッセージ１１５内で、様々なサービスモジュール１６０、１５５、１５０から取り出すための異なる部分１３５、１４０またはサービスを識別するエンドポイント参照の集まりを送信することができる。その後サーバ１４７は、様々なサービスモジュール１６０、１５５、１５０に対して適切な照会を行うことが可能であり、サービスモジュール１６０、１５５、１５０が適切な応答を処理および返送すると、サーバ１４７はこれらを応答全体１５０の部分１３０、１４５としてＨＴＴＰ回答フロー１２５を横切って送信することができる。
【００２７】
代替えとして（または可能であれば関連して）、サーバ１４７に向けて送られた単一の要求メッセージ１１５は、様々な部分１３０、１４５がサービスエンドポイント１４５内の様々なサービスモジュール１６０、１５５、１５０から求められており、これらを適宜自動的に取り出せることを、認識することができる。本発明は、応答全体１５０の部分を識別および取り出すための他のプロセスも使用可能である。サービスエンドポイント１４５内には３つのサービスモジュール１６０、１５５、１５０しか示されていないが、本発明では任意数のサービスまたはサービスモジュール１６０、１５５、１５０が使用可能である。したがって、本明細書で説明される、サービスモジュール１６０、１５５、１５０またはサービスエンドポイント１４５を参照するいかなる特定の説明、あるいはサービスモジュール１６０、１５５、１５０のいかなる特定の数も、単なる例示的なものであって、特に明示的に主張されない限り本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００２８】
ＨＴＴＰ通信の回答フロー１２５をオープンの状態で維持する他の理由は、バッファスペースが制限されたデバイスまたはエンドポイント１６５、１４５に対処するため、またはバッファリングなしの通信（ｕｎ−ｂｕｆｆｅｒｅｄ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）をサポートするためである。この実施形態では、応答が大規模なデータセットであり、エンドポイントがデータセット全体をメモリ内にバッファリングするのを避けたい場合、応答全体のうちのより小規模な部分１３５、１４０を、ＨＴＴＰ回答フローを横切って定期的または非対称に送信し、バッファリングを避けるために即時に処理することができる。こうしたことは、オーディオまたはビデオのストリーミングの場合、あるいはシステムリソースが制限されたシステムにとって、望ましい可能性がある。
【００２９】
要求側エンドポイント１６５は、標準ＨＴＴＰプロトコルに従ったサービスエンドポイント１４５との接続または通信を、いつでも中断できることに留意されたい。この接続切断は、たとえば送達された情報の量が多すぎること、および／または障害が発生したこと、を示すものである場合がある。同様にサービスエンドポイント１４５は、応答全体１５０の部分１３５、１４０の生成またはカプセル化を停止して、オリジナルの要求１１５を完了することもできる。したがって、通信中のエンドポイント１６５、１４５のいずれかが、典型的な機構セット内での対話をその自由裁量で切断することができる。すなわち新しいＨＴＴＰ機構は、接続を切断するかまたはＨＴＴＰ回答フロー１２５を閉じる必要がない。
【００３０】
単一の応答１５０内にカプセル化されたメッセージ（すなわち、応答全体１５０の部分１３５、１４０）の全体の実施形態に加えて、他の例示的な実施形態では、制御メッセージ１０５を介してエンドポイント１６５、１４５の間での通信を管理する。制御メッセージ１０５は、エンドポイント１６５、１４５の両方がこうしたカプセル化されたストリーム対話を管理するのを助ける、メッセージの集まりのうちの１つまたは複数とすることができる。各制御メッセージ１０５を、ＨＴＴＰトランスポートモデルにうまく適合する要求応答メッセージペアとしてモデル化することができる。通常、制御メッセージは、ＨＴＴＰ回答フロー１２５を介して応答１５０を生成する要求とは異なるＨＴＴＰ要求を使用して伝送されるはずであることに留意されたい。初期の要求メッセージ１１５は、通信の初期の段階で制御情報を含むことができるが、追加の制御情報１０５は他の要求応答トランスポート１１０を介して送信される必要がある。
【００３１】
制御メッセージ１０５は、要求側エンドポイント１６５とサービスエンドポイント１４５との間での特定の通信を識別する限り、他のタイプの通信トランスポート１１０を横切って境界外で送信することもできる。さらに本発明は、様々なトランスポート１１０を横切ってサービスエンドポイント１４５に制御メッセージ１０５を送信するための他の処理およびトランスポートも使用可能である。したがって、サービスエンドポイント１４５に制御メッセージ１０５を送信するためのプロセスまたは特定トランスポートのいかなる特定の使用も、例示の目的でのみ使用されるものであり、本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００３２】
本発明が使用可能な制御メッセージ１０５にはいくつかのタイプがある。たとえば、「ｉｓ  ｉｔ  ｏｋａｙ  ｔｏ  ｂｕｌｋ（バルクにしてもよいか）」という制御メッセージ１０５が可能である。この制御メッセージ１０５は、エンドポイントがバルクのストリーム化応答１５０を受け入れ可能であるかどうかを判別するために使用される。すなわち、こうした制御メッセージ１０５は、通信を確立する初期の状態で、こうした通信が特定のエンドポイント１６５、１４５によってサポートされているかどうか、およびどのタイプのカプセル化を使用するかを判別するために、使用することができる。他の制御メッセージ１０５は、要求側エンドポイント１６５が応答１５０のカプセル化部分１３５、１４０の受信を一時的に停止することを希望する、「ｓｕｓｐｅｎｄ（中断）」メッセージとすることが可能である。他の制御メッセージ１０５は、要求側エンドポイント１６５が応答１５０のカプセル化メッセージの受信を再開することを希望する、「ｒｅｓｕｍｅ（再開）」メッセージとすることができる。さらに他の制御メッセージは、一方のエンドポイント１６５、１４５が、他方のエンドポイント１６５、１４５が依然として動作可能であることの特定を希望する、「ｐｉｎｇ」（注．ピン，相手と野疎通を確認する信号）とすることができる。
【００３３】
他の制御メッセージ１０５は、「ｍｕｌｔｉｐｌｅｘ  ｉｎｉｔｉａｔｉｏｎ（多重開始）」メッセージを含むことができる。この特定の制御メッセージ１０５は、サービスエンドポイント１４５（およびより具体的にはサーバ１４７）が中間ルータまたはプロキシとして働こうとするエンドポイント参照の集まりを伝達できるようにするものである。したがって、いずれかのこうしたエンドポイント参照に関するメッセージは、サーバ１４７を介して前述のようにカプセル化部分として送信される。
【００３４】
他の制御メッセージ１０５は、「ｄｉｓｃｏｎｎｅｃｔｉｏｎ（切断）」メッセージとすることが可能であり、これはメッセージとして説明されるが、その代わりに、要求側エンドポイント１６５が、応答１５０、または他のチャネル、たとえば１１０上でのエンドポイント１４５、１６５間の通信全体を参照できるようにするために、ＨＴＴＰ応答１５０を識別する、エンドポイント参照を含む単なるメッセージヘッダとすることもできる。周知のように、このデータには、制御メッセージ１０５および他の情報を様々なエンドポイント間で送信するための複数の用途がある。
【００３５】
本発明は、通信を制御するための他の良く知られた制御メッセージ１０５および／またはヘッダも使用することができる。したがって、前述の制御メッセージ１０５のリストは包括的であることを意味するものではなく、特定の制御メッセージ１０５に関するいかなる特定の参照も例示の目的でのみ使用されたものであって、明示的に主張されない限り、本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００３６】
他の例示的な実施形態では、２つのエンドポイントサービスの間での双方向通信交換パターンを提供する。こうした実施形態では、各エンドポイントが要求側エンドポイント１６５とサービスエンドポイント１４５の両方として動作し、上記で概説した通信を確立するためのプロセスを２回実行することができる。たとえば図１Ｂに示されるように、分散型システム１００はエンドポイントＡ  １７０およびエンドポイントＢ  １８０を含む。第１の通信セッションＡ  １７５は、エンドポイントＡ  １７０から要求フローＡ  １８５を介して要求を送信することによって確立可能であり、応答全体のうちの後続の部分は、前述のように回答フローＡ  １９０を介して受信される。同様にエンドポイントＢは、例示的実施形態に従って、要求フローＢ  １８２を介して要求メッセージを送信すること、および回答フローＢ  １８４を横切って応答全体のうちの後続の部分を受信することによって、通信セッションＢ  １９５を確立することができる。このような場合、２つのエンドポイント１７０、１８０は、通常は、どちらの要求および応答全体の部分が双方向通信のうちの１方向に対応するかを調整するはずである。
【００３７】
本発明は、機能的ステップおよび／または非機能的動作を含む方法に関しても説明することができる。以下に、本発明を実施する際に実行可能なステップおよび／または動作について説明する。通常、機能的ステップは実施される結果に関して本発明を説明するが、非機能的動作は特定の結果を達成するためのより特有な動作を説明する。機能的ステップおよび／または非機能的動作は特定の順序で説明または主張することができるが、本発明は必ずしも、ステップおよび／または動作の任意の特定の順序または組み合わせに限定されるものではない。さらに、特許請求の範囲に記載されたステップおよび／または動作の使用方法、ならびに図２および３の流れ図に関する以下の説明は、こうした条件の所望の特定の使用方法を示すために使用される。
【００３８】
図２および３は、本発明の様々な例示的実施形態に関する例示的流れ図を示す。図２および３の以下の説明は、時折、図１Ａおよび１Ｂから対応する要素を参照することになる。これらの図から特定の要素を参照することができるが、こうした要素は例示の目的でのみ使用されるものであって、明示的に主張されない限り、本発明の範囲を限定するかまたはそうでなければ狭くすることを意味するものではない。
【００３９】
図２は、対応する要求の検証および許可に関連付けられた、貴重なシステムリソースを節約するための、ＨＴＴＰ応答を複数の異なる部分として転送する方法２００の例示的流れ図を示す。方法２００は、要求側エンドポイント１６５の立場から見たものであり、ＨＴＴＰ要求フローを介して要求メッセージを送信する動作２０５を含むことに留意されたい。たとえば要求側エンドポイント１６５は、分散型システム１００においてサービスエンドポイント１４５との通信を確立するために、ＨＴＴＰ回答フロー１２５を介して要求メッセージ１１５を送信することができる。要求メッセージ１１５は、制御情報、たとえば通信を制御するための制御メッセージ１０５を含むことができる。しかしながら、通常、制御メッセージは、要求側エンドポイント１６５とサービスエンドポイント１４５との間に確立された通信を管理するために、別の通信で送信されることになる。前述のように、制御メッセージは「ｉｓ  ｉｔ  ｏｋａｙ  ｔｏ  ｂｕｌｋ」、「ｓｕｓｐｅｎｄｅｄ」、「ｒｅｓｕｍｅ」、「ｐｉｎｇ」、「ｒｅｃｏｎｎｅｃｔ」、「ｍｕｌｔｉｐｌｅｘ  ｉｎｉｔｉａｔｉｏｎ」、「ｄｉｓｃｏｎｎｅｃｔｉｏｎ」などのうちの１つまたは複数とすることができる。
【００４０】
要求メッセージを送信した後、方法２００は、ＨＴＴＰ回答フロー１２５を介して応答の第１の部分を受信する動作２１０を含む。たとえば、要求側エンドポイント１６５は、対応するＨＴＴＰ回答フロー１２５を介して応答の第１の部分１３５を受信することが可能であり、これは第１の時間枠で受信される。方法２００は、ＨＴＴＰ回答フロー１２５をオープンの状態で維持する動作２１５も含む。たとえば要求側エンドポイント１６５は、応答１５０の追加部分を受信するために、ＨＴＴＰ回答フロー１２５をオープンの状態で維持することができる。他の要求メッセージを送信することなく、方法２００は、ＨＴＴＰ回答フロー１２５を介して応答の第２の部分を受信する動作２２０も含む。たとえば、要求側エンドポイント１６５は、ＨＴＴＰ回答フロー１２５を介して応答１５０の第２の部分１４０を受信することが可能であり、この第２の部分は第１の時間枠とは異なる第２の時間枠で受信される。
【００４１】
第１の部分１３５および第２の部分１４０は、非同期で、すなわち任意の間隔で受信することができる。さらにこれらの部分１３５、１４０は、応答全体１５０を構成する、ストリーム化されたメッセージ、個別のメッセージ、またはその両方の、いずれかとすることができる。さらに第１の部分１３５および第２の部分１４０は、分散型システム１００内の別々のサービスモジュール１６０、１５５、１５０から処理された離散的メッセージとすることができる。第１および第２の部分１３５、１４０は、要求側エンドポイント１６５から送信されたエンドポイント参照を使用して別々のサービスモジュール１６０、１５５、１５０に離散的メッセージ１３５、１４０を要求した、単一のサービス１４７またはサーバから受信することができる。これらのエンドポイント参照は、要求メッセージ１１５に含まれる場合がある。代替えとしてまたは関連して、サービスエンドポイント１４５が、制御メッセージ１０５内でサポートしているエンドポイント参照を要求側エンドポイント１６５に送信することもできる。さらにエンドポイント参照は、ＨＴＴＰ回答フロー１２５とは別の通信トランスポートを介して制御メッセージ１０５内で送信することが可能である。
【００４２】
前述のように、双方向通信は、分散型システム１００内の２つのエンドポイント間に確立することができる。こうした実施形態では、図１Ｂ内のエンドポイントＡ  １７０が図１Ａからの要求側エンドポイント１６５であり、図１Ｂ内のエンドポイントＢ  １８０が図１Ａからのサービスエンドポイント１４５である場合、第１の通信セッションＡ  １７５の確立に続いて、他の実施形態は以下のように提供する。エンドポイントＡ  １７０は、分散型システム１００内のエンドポイント１７０、１８０間に双方向通信セッションを確立するために、第２のＨＴＴＰ回答フロー（たとえば、要求フローＢ  １８２）を介して第２の要求メッセージを受信することができる。その後エンドポイントＡ  １７０は、第３の時間枠で、対応する第２のＨＴＴＰ回答フロー（たとえば、回答フローＢ  １８４）を介して第２の応答の第１の部分を送信することができる。他の要求メッセージを受信することなく、エンドポイントＡ  １７０は、第３の時間枠とは異なる第４の時間枠で、第２のＨＴＴＰ回答フロー（たとえば、回答フローＢ  １８４）を介して第２の応答の第２の部分を送信することができる。
【００４３】
サービスエンドポイント１４５から、図３は、本発明の例示的実施形態に従って複数の異なる部分としてＨＴＴＰ応答を転送する方法３００を示す。方法３００は、ＨＴＴＰ回答フローを介して要求メッセージを受信する動作３０５を含む。たとえばサービスエンドポイント１４５は、ＨＴＴＰ回答フロー１２５を介して要求側エンドポイント１６５から要求メッセージ１１５を受信することができる。方法３００は、ＨＴＴＰ回答フローを介して応答の第１の部分を送信する動作３１０も含む。たとえばサービスエンドポイント１４５は、第１の時間枠で、ＨＴＴＰ回答フロー１２５を介して応答１５０の第１の部分１３５を送信することができる。方法３００は、ＨＴＴＰ回答フローを介して応答の第２の部分を送信する動作３１５も含む。たとえばサービスエンドポイント１４５は、第１の時間枠とは異なる第２の時間枠で、ＨＴＴＰ回答フロー１２５を介して応答１５０の第２の部分１４０を送信することができる。前述のように、他の例示的実施形態を方法３００に適用することも可能であることに留意されたい。
【００４４】
本発明の範囲内にある諸実施形態は、コンピュータ実行可能命令またはデータ構造を搬送するかまたはその上に格納するための、コンピュータ読み取り可能媒体も含む。こうしたコンピュータ読み取り可能媒体は、汎用または特定用途向けのコンピュータがアクセス可能な任意の使用可能媒体とすることができる。例を挙げると、こうしたコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは、コンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を搬送または格納するために使用可能であり、汎用または特定用途向けのコンピュータがアクセス可能な、任意の他の媒体を含むことができるが、これらに限定されるものではない。ネットワークまたは他の通信接続（ハードワイヤード、無線、あるいはハードワイヤードまたは無線の組み合わせのいずれか）を介してコンピュータに情報が転送または提供される場合、コンピュータは、この接続を厳密にコンピュータ読み取り可能媒体とみなす。したがって、任意のこうした接続は、厳密にコンピュータ読み取り可能媒体と呼ばれる。上記の組み合わせは、コンピュータ読み取り可能媒体の範囲内にも含まれるものとされる。コンピュータ実行可能命令は、たとえば汎用コンピュータ、特定用途向けコンピュータ、または特定用途向け処理デバイスにある種の機能または機能グループを実行させる、命令またはデータを含む。
【００４５】
図４および以下の考察では、本発明が実施可能な好適なコンピューティング環境の簡単で概括的な説明を提供することが意図される。必須ではないが、本発明については、ネットワーク環境においてコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との一般的な関連において説明する。一般にプログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書に開示された方法の諸ステップを実行するためのプログラムコード手段の例を表す。こうした実行可能命令または関連するデータ構造の特定のシーケンスは、こうした諸ステップで説明される機能を実施するための対応する動作の例を表す。
【００４６】
当業者であれば、本発明が、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、などを含む、多くのタイプのコンピュータシステム構成を備えたネットワークコンピューティング環境で実施可能であることを理解されよう。本発明は、通信ネットワークを介して（ハードワイヤードリンク、無線リンク、あるいは、ハードワイヤードリンクまたは無線リンクの組み合わせによって）リンクされたリモート処理デバイスによってタスクが実行される、分散型コンピューティング環境でも実施可能である。分散型コンピューティング環境では、プログラムモジュールはローカルおよびリモートの両方のメモリストレージデバイスに配置することができる。
【００４７】
図４を参照すると、本発明を実施するための例示的システムには、処理ユニット４２１と、システムメモリ４２２と、システムメモリ４２２を含む様々なシステム構成要素を処理ユニット４２１に結合するシステムバス４２３とを含む、従来のコンピュータの形の汎用コンピューティングデバイス４２０が含まれる。システムバス４２３は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのうちのいずれかを使用するバスを含む、いくつかのタイプのバス構造のうちのいずれかとすることができる。システムメモリは、読み取り専用メモリ（ＲＯＭ）４２４およびランダムアクセスメモリ（ＲＡＭ）４２５を含む。起動時などにコンピュータ４２０内の要素間での情報の転送を助ける基本ルーチンを含む基本入力／出力システム（ＢＩＯＳ）４２６は、ＲＯＭ４２４に格納することができる。
【００４８】
コンピュータ４２０は、磁気ハードディスク４３９からの読み取りおよびこれへの書き込みのための磁気ハードディスクドライブ４２７と、取り外し可能磁気ディスク４２９からの読み取りおよびこれへの書き込みのための磁気ディスクドライブ４２８と、ＣＤ−ＲＯＭまたは他の光学式媒体などの取り外し可能光ディスク４３１からの読み取りおよびこれへの書き込みのための光ディスクドライブ４３０とを含むこともできる。磁気ハードディスクドライブ４２７、磁気ディスクドライブ４２８、および光ディスクドライブ４３０は、それぞれハードディスクドライブインターフェース４３２、磁気ディスクドライブインターフェース４３３、および光ドライブインターフェース４３４によって、システムバス４２３に接続される。ドライブおよびそれらに関連付けられたコンピュータ読み取り可能媒体は、コンピュータ４２０に関するコンピュータ実行可能命令、データ構造、プログラムモジュール、および他のデータの、不揮発性ストレージを提供する。本明細書で説明される例示的環境では、磁気ハードディスク４３９、取り外し可能磁気ディスク４２９、および取り外し可能光ディスク４３１を採用しているが、データを格納するために、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含む、他のタイプのコンピュータ読み取り可能媒体を使用することも可能である。
【００４９】
１つまたは複数のプログラムモジュールを備えるプログラムコード手段は、ハードディスク４３９、磁気ディスク４２９、光ディスク４３１、ＲＯＭ４２４、あるいは、オペレーティングシステム４３５、１つまたは複数のアプリケーションプログラム４３６、他のプログラムモジュール４３７、およびプログラムデータ４３８を含む、ＲＡＭ４２５上に格納することができる。ユーザは、キーボード４４０、ポインティングデバイス４２２、または、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどの他の入力デバイス（図示せず）を介して、コマンドおよび情報をコンピュータ４２０に入力することができる。これらおよび他の入力デバイスは、しばしば、システムバス４２３に結合されたシリアルポートインターフェース４４６を介して処理ユニット４２１に接続される。代替えとして、入力デバイスは、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースによって接続することができる。モニタ４４７または他のディスプレイデバイスも、ビデオアダプタ４４８などのインターフェースを介してシステムバス４２３に接続される。パーソナルコンピュータは通常、モニタに加えて、スピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）を含む。
【００５０】
コンピュータ４２０は、リモートコンピュータ４４９ａおよび４４９ｂなどの１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ４４９ａおよび４４９ｂは、それぞれ他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることが可能であり、通常は、コンピュータ４２０に関して前述した要素の多くまたはすべてを含むが、図４にはメモリストレージデバイス４５０ａおよび４５０ｂならびにそれらに関連付けられたアプリケーションプログラム４３６ａおよび４３６ｂのみが図示されている。図４に示された論理接続は、限定的ではなく例示的なものとして提示されたローカルエリアネットワーク（ＬＡＮ）４５１およびワイドエリアネットワーク（ＷＡＮ）４５２を含む。こうしたネットワーキング環境は、オフィス規模または企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
【００５１】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ４２０はネットワークインターフェースまたはアダプタ４５３を介してネットワーク４５１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ４２０は、インターネットなどのワイドエリアネットワーク４５２を介して通信を確立するための、モデム４５４、無線リンク、または他の手段を含むことができる。モデム４５４は内蔵型または外付け型とすることが可能であり、シリアルポートインターフェース４４６を介してシステムバス４２３に接続される。ネットワーク環境では、コンピュータ４２０に関して記載されたプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納することができる。図示されたネットワーク接続は例示的なものであり、ワイドエリアネットワーク４５２を介して通信を確立する他の手段が使用可能であることを理解されよう。
【００５２】
本発明は、その趣旨または不可欠な特徴を逸脱することのない他の特定の形で具体化することができる。説明された諸実施形態は、すべての点において例示的であり限定的でないものとみなされるものとする。したがって本発明の範囲は、前述の説明によってではなく添付の特許請求の範囲によって示される。特許請求の範囲と等価の意味および範囲内にあるすべての変更は、その範囲内に包含されるものとする。
【図面の簡単な説明】
【００５３】
【図１Ａ】本発明の例示的実施形態に従った、拡張ＨＴＴＰ回答フローを使用したメッセージ交換パターンを示す図である。
【図１Ｂ】本発明の例示的実施形態に従った、２つの拡張ＨＴＴＰ回答フローの使用による分散型システムにおけるエンドポイント間での双方向通信セッションを示す図である。
【図２】本発明の例示的実施形態に従い、複数の異なる部分としてＨＴＴＰ応答を転送するための例示的流れ図を示す図である。
【図３】本発明の例示的実施形態に従い、複数の異なる部分としてＨＴＴＰ応答を転送するための例示的流れ図を示す図である。
【図４】本発明に好適なオペレーティング環境を提供する例示的システムを示す図である。
【符号の説明】
【００５４】
４２１  処理ユニット
４２２  システムメモリ
４２３  システムバス
４２４  ＲＯＭ
４２５  ＲＡＭ
４２６  ＢＩＯＳ
４３２  ハードディスクドライブインターフェース
４３３  磁気ディスクドライブインターフェース
４３４  光ドライブインターフェース
４３５  オペレーティングシステム
４３６  アプリケーションプログラム
４３６ａ  アプリケーションプログラム
４３６ｂ  アプリケーションプログラム
４３７  他のプログラムモジュール
４３８  プログラムデータ
４４０  キーボード
４４６  シリアルポートインターフェース
４４７  モニタ
４４８  ビデオアダプタ
４４９ａ  リモートコンピュータ
４４９ｂ  リモートコンピュータ
４５１  ローカルエリアネットワーク
４５２  ワイドエリアネットワーク
４５３  ネットワークインターフェース
４５４  モデム
【図１Ａ】
2006190282.tif 000003
【図１Ｂ】
2006190282.tif 000004
【図２】
2006190282.tif 000005
【図３】
2006190282.tif 000006
【図４】
2006190282.tif 000007