JP2006004415A - コンテキスト交換を用いたエニュメレーションのセッションのためのフレキシブルなコンテキスト管理 - Google Patents

Abstract

【課題】 どの程度の量のメッセージ間のコンテキスト情報をデータプロバイダによって保持されるかに対する制御を保持しながら、要求駆動のエニュメレーションのセッションにおいて要求されたデータアイテムを供給するメカニズムを供給すること。
【解決手段】 データアイテムの要求を受け取ると、データプロバイダは、情報の第１の部分が供給されたことを反映するコンテキスト情報とともに、第１の応答において供給すべきデータアイテムの部分を識別する。データプロバイダは、どの程度の量のコンテキストをデータレシーバのシステムに供給すべきかの決定を行い、適当なコンテキスト情報をデータレシーバに供給する。データプロバイダは、データアイテムの第１の部分を含む応答を供給する。データレシーバは、供給された第１のコンテキスト情報を、データアイテムの次の部分に対する第２の要求に含め、データ転送セッションの連続性を可能にする。
【選択図】 図４

Description

本発明は、一般には、コンピュータ処理技術に関し、より詳細には、どのコンピュータ処理システムが通信のためのコンテキスト情報を管理するかを制御しながら、多重応答で多重されたデータアイテムをネットワーク配布することに関する。

コンピュータ処理技術は、我々の仕事や遊びのやり方を変容させた。今やコンピュータ処理システムは多種多様な形態をとっており、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、パーソナル・デジタル・アシスタント（ＰＤＡ）、家庭用機器、等がある。コンピュータ処理システムの最も基本的な形態において、コンピュータ処理システムは、システムメモリおよび１つもしくは複数のプロセッサを備える。システムメモリのソフトウェアを、プロセッサによって実行することができ、結果としてコンピュータ処理システムのその他のハードウェアに所望の機能を実行させることができる。

ネットワーク技術によって、コンピュータ処理システムは、たとえ広大な距離にわたっても通信を行うことができ、それによってコンピュータの機能を拡張することが可能となる。例えば、ネットワーク技術は、電子メール、ウェブブラウジング、ファイル転送、インスタントメッセージ、電子ホワイトボード、ネットワークコラボレーション、等ようなアプリケーションを可能にする。

ネットワークアプリケーションの中には、大量の情報の転送を伴うものがある。例えば、サイズが数テラバイトのデータベースをダウンロードしたいと思う場合がある。たとえ高帯域幅ネットワーク上においても、このダウンロードには数日を要する可能性がある。かなり信頼性のあるネットワーク環境においてさえ、全期間にわたって、ネットワーク通信が維持できない可能性が高い。接続が失われると、データ転送全体を最初から再び始めなくてはならないことが多い。

大規模なデータ転送の信頼性および効率性を向上させる一つの従来式の方法は、データを一度に一部分ずつ別個の電子メッセージにして転送する方法である。時には、この方法は単一の要求に応答して自動的に達成することができる。しかしながら、データレシーバがデータ転送プロセスをいくぶん制御できるようにするために、データレシーバは、転送データ全体の一部分を含む各々の電子メッセージに対して要求を送出することができる。例えば、ウェブサイトは、ウェブサイトに関連する大量のデータを有しており、ウェブページ、画像、音声ファイル、他のマルチメディア、スクリプト等がある。ウェブブラウザは、データアイテムの各々に対して別個の要求を送出することが多い。この技術は、「要求駆動のエニュメレーション技術（ｒｅｑｕｅｓｔ−ｄｒｉｖｅｎ ｅｎｕｍｅｒａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）」と呼ぶこととし、この技術においては、データアイテムの収集は、別個の要求に個別に応答して、一度に一部分ずつ「エニュメレート（ｅｎｕｍｅｒａｔｅ）」される。

データレシーバのコンピュータ処理システムに対する期待に応えるためには、各要求が、要求の適正なコンテキストにおいて理解されることが重要である。例えば、全部で５０個のデータアイテムを、一度に１０個のデータアイテムずつ、５つの異なる要求に対する５つの応答のセッションで転送するものと仮定する。第１の要求が送出されると、データプロバイダは、５０個のデータアイテムの識別を知るだけではなく、第１の要求であることを知ることも重要である。データプロバイダは、最初の１０個のデータアイテムを転送することを知る。第２の要求を受け取ると、データプロバイダは、先の１０個のデータアイテムがすでに供給されたことを知ることが重要である。そうでなければ、データプロバイダは、最初の１０個のデータアイテムを再び供給する可能性がある。したがって、要求駆動のエニュメレーション技術においては、データプロバイダは、要求に対する適正なコンテキストを持たなくてはならない。本明細書の説明および本特許請求の範囲においては、要求駆動のエニュメレーション技術によるセッションにおける、要求に対する「コンテキスト（ｃｏｎｔｅｘｔ）」を、要求に応答してデータアイテムのどの部分を供給するかをデータプロバイダが知るのに必要もしくは役立つ、任意の情報として定義する。

従来から、このコンテキスト情報の維持に対する責任は静的である。例えば、データプロバイダは、特定のデータレシーバへの大量のデータ転送に対するセッション情報を維持することができる。このセッション情報には、コンテキスト情報を含めることができる。他の従来技術においては、データレシーバが、コンテキスト情報を維持する。このコンテキスト情報は、データプロバイダがデータレシーバに供給する。次いで、データレシーバは、データアイテムの収集の次の部分に対する次の要求の中に、コンテキスト情報を含める。どのシステムがコンテキスト情報を管理しているかにかかわらず、コンテキスト情報の管理の責任は、データ転送セッションが開始されるときには、予め定められている。さらに、コンテキスト管理の責任は、セッションが確立されている間、変化することがない。

データプロバイダもしくはデータレシーバにとって、コンテキスト情報を維持するのが有利かどうかは、周辺環境によって決まる。周辺環境の多くは、非常に動的である。したがって、有利になるものとしては、データ転送セッションのためのコンテキスト情報の管理における、データプロバイダとデータレシーバの間の労力分割に対して、データプロバイダのコンピュータ処理システムが、より柔軟かつ動的に制御をすることを可能にするメカニズムがある。

従来技術についての前述の問題は、本発明の原理によって克服され、原理とは、データレシーバのコンピュータ処理システムからの別個の要求に応答して要求されたデータアイテムの部分が供給される要求駆動のエニュメレーションのセッションにおいて、データプロバイダのコンピュータ処理システムが、要求されたデータアイテムを供給するためのメカニズムを目的とするものである。このメカニズムによって、データプロバイダは、データプロバイダが保持するメッセージ間のコンテキスト情報の量、およびデータレシーバに供給されるコンテキスト情報の量を制御することが可能となる。

データレシーバに供給すべきデータアイテムに対する第１の要求を受け取ると、データプロバイダは、データレシーバに供給すべきデータアイテムを識別する。この識別は、少なくとも部分的には第１の要求内の情報に基づいて行うことができる。次いで、データプロバイダは、第１の要求に対応する第１の応答において供給すべきデータアイテムの第１の部分を識別する。さらに、第１の部分の情報が供給されたことを反映する、コンテキスト情報が識別される。次いで、データプロバイダは、どの程度の量のコンテキストをデータレシーバのコンピュータ処理システムに供給すべきかについて決定する。次いで、データプロバイダは第１の応答を構築し、この応答にはデータアイテムの第１の部分が含まれる。また、データプロバイダは、データプロバイダが適当であると考えるだけの量のコンテキスト情報を、レシーバのコンピュータ処理システムに供給する。

データレシーバは、この供給された第１のコンテキスト情報を、データアイテムの次の部分に対する第２の要求の中に含める。データプロバイダは、この供給された第１のコンテキスト情報を要求と要求との間で、保持する必要がない。代わりに、データプロバイダは、第２の要求から供給された第１のコンテキストを読み取る。このことは、データプロバイダが、データレシーバに送信するデータアイテムの第２の部分を識別するのに役立つ。次いで、データプロバイダは、第２の応答に含めるべき第２のコンテキスト情報を生成する。

この第２に供給されるコンテキスト情報は、そのときの環境に応じて、先の第１に供給されるコンテキスト情報と同一もしくは異なる範囲を有することがある。例えば、第１に供給されるコンテキスト情報に、コンテキスト情報の全部が含まれることがある。データレシーバが第２の要求を迅速に送信する場合には、データレシーバが能動的に関係して、要求が迅速に連続してくるように思われるので、次の応答には、比較的少ないコンテキスト情報を含めるか、またはまったく含める必要がなく、このことは、データプロバイダがコンテキスト情報を長くは維持する必要がないことを意味する。

したがって、本発明の原理によって、データプロバイダは、そのときの環境に応じて、コンテキスト管理におけるデータプロバイダの役割を動的に調整することについて、大幅な柔軟性を得ることができる。本発明のさらなる特徴および利点は、以下の説明に記述してあり、部分的には記述から明白であるか、もしくは本発明の実施から知ることができる。本発明の特徴および利点は、添付の本特許請求の範囲に具体的に指摘した機器および組合せによって、実現して獲得することができる。本発明のこれら、および他の特徴は、以下の本明細書の説明と添付の本特許請求の範囲からより完全に明白になるか、もしくは以下の記載に従って本発明を実施することによって知ることができる。

本発明の上記および他の利点および特徴を獲得する方法について説明するために、上記で簡単に記述した本発明のより具体的な記述を、添付の図面に示した本発明の具体的な実施形態を参照して行う。添付の図面は、本発明の代表的な実施形態のみを示しており、したがって、本発明の範囲を限定するものとは考えないことを理解した上で、本発明を、添付の図面を使用して、さらに具体的かつ詳細に記述し、説明する。

本発明の原理は、要求されたデータアイテムの部分がデータレシーバのコンピュータ処理システムからの別個の要求に応答して供給される、要求駆動のエニュメレーションのセッションにおいて要求されたデータアイテムを供給する、データプロバイダのコンピュータ処理システムのためのメカニズムに関する。メカニズムによって、データプロバイダは、どの程度の量のメッセージ間のコンテキスト情報をデータプロバイダによって保持し、およびどの程度の量のコンテキスト情報をデータレシーバに供給するかを、制御することが可能となる。

図面を参照すると、同一の参照番号は同一の要素を意味しており、適当なコンピュータ処理環境に実装したとして、本発明を示してある。以下の記述は、本発明の図示した実施形態に基づくものであり、本明細書に明示的に記述していない代替実施形態に関して、本発明を限定するものと解釈すべきではない。

以下の記述において、本発明は、特に断らない限り、１つまたは複数のコンピュータによって実行される、動作および演算の記号表現を参照して記述してある。したがって、動作および演算は、時にはコンピュータ実行されると記すこともあり、コンピュータの処理ユニットによる構造形式のデータを表す電気信号の操作が含まれることが理解されるであろう。コンピュータの処理ユニットによる操作によって、データが変換されるか、もしくはデータがコンピュータのメモリシステム内の場所に維持され、この操作によって、当業者によく理解されている方法により、コンピュータの演算が再構成されるか、もしくは他の方法で変更される。データが維持されるデータ構造とは、データのフォーマットによって定義される固有の特性を有するメモリの物理的な場所である。しかしながら、本発明は前述の文脈で記述してあるが、限定を意味するものではなく、当業者であれば、以下に記述する動作および演算をハードウェアに実装することもできることを認識するであろう。図１は、装置に有用な例示的コンピュータアーキテクチャの概略図を示す。

説明の目的で、描いたアーキテクチャは適当な環境の一例を示すものにすぎず、本発明の使用もしくは機能の範囲についてのいかなる限定をも意味するものではない。また、コンピュータ処理システムは、図１に示す構成要素のいずれか、もしくは構成要素の組合せに関して、何らかの依存性もしくは必要条件を有するものとして解釈すべきではない。

本発明は、他の多数の汎用もしくは専用のコンピュータ処理のまたは通信の、環境もしくは構成において使用可能である。本発明での使用に好適な、周知のコンピュータ処理システム、環境、および構成の例としては、限定はされないが、モバイル電話、ポケットコンピュータ、パーソナルコンピュータ、サーバ、マルチプロセッサシステム、マイクロプロセッサを基部とするシステム、ミニコンピュータ、メインフレームコンピュータ、および上記のシステムもしくは装置のいずれかを含む、分散コンピュータ処理環境がある。

コンピュータ処理システムの最も基本的な構成において、コンピュータ処理システム１００は、通常、少なくとも１つの処理ユニット１０２およびメモリ１０４を備える。メモリ１０４は、（ＲＡＭのような）揮発性、（ＲＯＭ、フラッシュメモリ、等の）不揮発性、もしくは両者の組合せとすることができる。この最も基本的な構成は、図１に破線１０６で示してある。

記憶媒体装置は、付加的な特徴および機能を有することができる。例えば、記憶媒体装置には、限定はされないが、ＰＣＭＣＩＡカード、磁気および光ディスク、ならびに磁気テープを含む、追加の（取り外し可能および固定）記憶装置を含めることができる。追加の記憶装置を、図１に取り外し可能記憶装置１０８および固定記憶装置１１０によって示してある。コンピュータ記憶媒体には、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、もしくは他のデータなどの情報を記憶するために任意の方法もしくは技術で実装された、揮発性および不揮発性の、取り外し可能および固定の媒体を含めることができる。メモリ１０４、取り外し可能記憶装置１０８、および固定記憶装置１１０は、すべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体としては、限定はされないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、他のメモリテクノロジ、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋｓ）、他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、および所望の情報を記憶するのに使用可能であるとともに、コンピュータ処理システムによってアクセスが可能である他の任意の媒体がある。

本明細書において使用する場合には、「モジュール」もしくは「構成要素」という用語は、コンピュータ処理システム上で実行されるソフトウェアのオブジェクトまたはルーチンを意味する場合がある。本明細書に記述する、異なる構成要素、モジュール、エンジン、およびサービスは、コンピュータ処理システムで実行されるオブジェクトもしくはプロセス（例えば、別個のスレッドとして）として実装することができる。本明細書に記述するシステムおよび方法は、ソフトウェアに実装することが望ましいが、ソフトウェアおよびハードウェアへのもしくはハードウェアへの実装も可能であり企図され得る。

コンピュータ処理システム１００には、例えば、ネットワーク１２０を介して、ホストが他のシステムおよび装置と通信することを可能にする、通信チャネル１１２を含めることもできる。通信チャネル１１２は、通信媒体の例である。通信媒体には、通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または例えば搬送波もしくは他の搬送メカニズムなどの変調されたデータ信号中の他のデータが包含されるとともに、任意の情報伝達媒体が含まれる。例としてであって限定ではなく、通信媒体には、有線ネットワークおよび有線で直結接続などの有線媒体、ならびに音響、無線、赤外線、および他の無線媒体などの無線媒体が含まれる。本明細書で使用するコンピュータ読み取り可能な媒体という用語には、記憶媒体および通信媒体の両方が含まれる。

また、コンピュータ処理システム１００は、キーボード、マウス、ペン、音声入力の構成要素、タッチ入力装置などの、入力構成要素１１４を有することもできる。出力構成要素１１６としては、スクリーンディスプレイ、スピーカ、プリンタ、等、およびスクリーンディスプレイ、スピーカ、プリンタ、等を駆動するためのレンダリングモジュール（「アダプタ」と呼ばれることが多い）がある。コンピュータ処理システム１００は、電源１１８を備える。構成要素はすべて、本技術分野において周知であり、ここでは詳しく述べる必要はない。

図２は、データレシーバのコンピュータ処理システム２１０にネットワーク接続する機能を有するデータプロバイダのコンピュータ処理システム２２０を含む、ネットワーク環境２００を示す。本明細書の説明および本特許請求の範囲においては、「コンピュータ処理システム」とは、システムメモリおよび、システムメモリからの命令を実行する機能のある少なくとも１つのプロセッサを有する任意の装置またはシステムとして定義される。代替および追加として、コンピュータ処理システムは、全体がハードウェアに実装された場合でも、任意の論理処理の機能を有することができる。したがって、データレシーバのコンピュータ処理システム２１０およびデータプロバイダのコンピュータ処理システム２２０は、必須ではないが、コンピュータ処理システム１００について上述したように、構築することができる。

また、コンピュータ処理システム２１０および２２０に対する、「データプロバイダ」および「データレシーバ」という用語の使用は、データの受信がコンピュータ処理システム２１０によってサポートされる唯一の機能であることも、データの供給がコンピュータ処理システム２２０によってサポートされる唯一の機能であることもまた示唆するものではない。実際に、コンピュータ処理システムは、非常に複雑な汎用のコンピュータ処理システムである場合もあるが、これは必要条件ではない。データレシーバのコンピュータ処理システム２１０は、本明細書では「データレシーバ」と呼ぶこともある。同様に、データプロバイダのコンピュータ処理システム２２０は、本明細書では「データプロバイダ」と呼ぶこともある。

データプロバイダ２２０は、データレシーバ２１０に供給すべきある数のデータアイテム２２１を管理する。また、データプロバイダ２２０は、データレシーバ２１０に供給しない他のデータアイテムも管理することができる。図に示した場合には、データプロバイダ２２０は、場合によっては縦方向の省略符号２２１Ｇで表すような他のデータアイテムとともに、データアイテム２２１Ａから２２１Ｆをデータレシーバのコンピュータ処理システムに供給することになっている。

データプロバイダ２２０は、要求駆動のエニュメレーション技術によるセッションのとおりに、メッセージ交換２３０を使用することによって、データアイテム２２１をデータレシーバ２１０に供給する。具体的には、データアイテム２２１は、単一要求への単一の応答においては、データプロバイダに供給されない。代わりに、データアイテム２２１は、一度に一部分ずつ、データレシーバ２１０に供給され、各部分は一つの要求に応答して配布される。一実施形態においては、要求駆動のエニュメレーション技術によるセッションは、データレシーバ２１０がデータプロバイダ２２０に予備のエニュメレートの要求を伝送することによって開始される。データプロバイダ２２０は、エニュメレートの応答をデータレシーバ２１０に返送することによって、セッションを確認することができる。以下にさらに詳細に記述する一つの具体例において、エニュメレートの要求および応答は、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）文書を含む、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）エンベロープの形式とすることができる。しかしながら、エニュメレートの要求および応答は、Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）メッセージとすることもできる。

図２に示すように、データレシーバ２１０は、第１の要求２３１Ａを伝送する。応答として、データプロバイダ２２０は、第１の要求２３１Ａに対する第１の応答２３１Ｂにおいて、データアイテム２２１Ａおよび２２１Ｂを供給する。このプロセスを、データレシーバ２１０がデータアイテム２２１のすべてを受け取るまで反復することができる。具体的には、データレシーバ２１０は、第２の要求２３２Ａを伝送する。応答として、データプロバイダ２２０は、第２の要求２３２Ａに対する第２の応答２３２Ｂにおいて、データアイテム２２１Ｃおよび２２１Ｄを供給する。次いで、データレシーバ２１０は、第３の要求２３３Ａを伝送する。応答として、データプロバイダ２２０は、第３の要求２３３Ａに対する第３の応答２３３Ｂにおいて、データアイテム２２１Ｅおよび２２１Ｆを供給する。このプロセスは、縦方向の省略符号２２１Ｇによって表すさらなるデータアイテムに対して、縦方向の省略符号２３４で表すように、継続することができる。

図に示した場合には、少なくとも６つのデータアイテムが、各要求に対して一度に２つのデータアイテムずつ、データレシーバ２１０に供給されるものとして示してある。しかしながら、本発明の原理は、この実施形態に限定はされない。要求駆動のエニュメレーション技術による任意の単一のセッションを使用して、任意の数のデータアイテムを伝送することができる。さらに、データプロバイダ２２０は、任意の所与の要求に対する任意の所与の応答において、任意の数のデータアイテムを（もしくはデータアイテムの一部分でも）伝送することができる。また、データレシーバ２１０へのデータアイテムのエニュメレーションは要求駆動であるので、データレシーバ２１０は、さらなる要求の伝送を停止するだけで、データ転送を停止することができる。

図３は、データプロバイダが２つのコンピュータ処理システム間のコンテキスト管理の均衡に対する制御を保持することを可能にしながら、データプロバイダが、データアイテムをデータレシーバに供給する方法３００のフローチャートを示す。同様に、図４は、この役割をするデータプロバイダをデータレシーバがサポートする方法４００のフローチャートを示す。方法３００および方法４００は、ネットワーク環境２００において実行できるので、図３および図４を、図２を頻繁に参照して説明する。

図３を参照すると、データプロバイダ２２０は、データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする（動作３０１）。この要求は、例えばファンクションコールによって行われる、データプロバイダ２２０における内部要求とすることができる。あるいはまた、この要求は、他のコンピュータ処理システムからの要求を受け取ることによってアクセスすることができる。図２に図示した本実施形態においては、データプロバイダ２２０は、データレシーバ２１０からの第１の要求２３１Ａを受け取ることによって、この要求にアクセスすることができる。一実施形態においては、データレシーバからの後続の要求のみならずこの要求は、各々、データレシーバ２１０が出す、「‘プル要求’」である。ここに記述する本実施形態においては、‘プル要求’は、ＳＯＡＰエンベロープに含めることができ、結果として、ＸＭＬ文書の形式にすることができる。‘プル要求’の一例を、以下により詳細に示す。‘プル要求’は、ＲＭＩとすることもできる。

次いで、データプロバイダ２２０は、データプロバイダとデータレシーバとの間のコンテキスト管理における均衡を制御しながら、データレシーバ２１０にデータアイテムを供給する機能の、結果指向の動作を実行する（ステップ３１０）。図示した本実施形態においては、このことは、少なくとも動作３１１から３１４、および３２１から３２３を含むが、この結果を達成する任意の動作で十分である。

具体的には、データプロバイダ２２０は、少なくとも部分的には要求内の情報に基づいて、データレシーバのコンピュータ処理システムに供給すべきデータアイテムの収集を識別する（動作３１１）。データアイテムは、要求中に直接的に指定することができる。さらに、データアイテムは、データアイテムの収集（本明細書においてはデータアイテムの初期収集もしくは複数のデータアイテムとも呼ぶ）を指定することによって間接的に指定することもできる。この要求には、データアイテムの最終収集を生成するためにデータアイテムの初期収集に適用するフィルタを含めることができる。一実施形態においては、識別しようとするアイテムの収集は、要求中のセッション識別子を読み取ることによって実行される。セッション識別子は、先のエニュメレートの要求と関係づけることができ、この要求においては、データアイテムが明白に識別されている。この先のエニュメレートの要求には、データアイテムを識別するためのフィルタを含めておくこともできる。

次いで、データプロバイダ２２０は、データアイテムの収集の第１の部分がデータレシーバのコンピュータ処理システムに供給されることを反映する第１のコンテキストを識別する（動作３１２）。データアイテムの収集が、例えば、ＸＭＬ要素である場合には、コンテキストには、先に供給された最後のＸＭＬ要素のもしくは供給しようとする次のＸＭＬ要素の識別子を、またはデータアイテムの収集のどの部分がすでにデータレシーバ２１０に供給されたかおよびデータアイテムのどの部分をさらに供給すべきかを示すのに有用な他の任意の情報を、含めることができる。

次いで、データプロバイダ２２０は、どの程度の量の第１のコンテキストをデータレシーバ２１０に供給すべきかを決定する（動作３１３）。このことには、動作３１２において識別された全部の第１のコンテキストをひとつも含めないか、一部もしくは全部を含めることができる。ここで留意すべきことは、コンテキスト情報をデータレシーバ２１０に供給できるとしても、データプロバイダは、コンテキストを後に検証するために、供給されたコンテキストの一部もしくは全部を重複して保持することができることである。どの程度の量のコンテキストをデータレシーバ２１０に供給するかの決定は、任意の決定基準のとおりに実施することができる。関係する決定基準としては、例えば、データプロバイダ２２０もしくはデータプロバイダ２２０の利用可能なメモリの、現在の処理量および利用可能な処理能力、データレシーバ２１０もしくはデータレシーバ２１０の利用可能なメモリの、現在の処理量および利用可能な処理能力、データレシーバ２１０とデータプロバイダ２２０との間の利用可能なネットワーク帯域幅、ネットワークレシーバもしくはネットワークレシーバに関連するユーザの重要性、等がある。次いで、データプロバイダ２２０は、データレシーバ２１０に適宜、第１のコンテキストを供給する（動作３１４）。

さらに、データプロバイダ２２０は、データレシーバへの第１のネットワーク応答に供給すべきデータアイテムの収集の第１の部分（全体よりも少ない）を識別する（動作３２１）。「第１の」という用語は、必ずしも、２つのコンピュータ処理システム間に先のエニュメレート要求もしくは応答がなかったことを意味するものではない。実際に、以下に示す一実施形態においては、プル演算を使用してデータアイテムを一度に一部分ずつ取り出すことのできるセッション中のポイントに達するために、エニュメレートの要求およびエニュメレートの応答の形式の全体的な要求／応答の交換がある。

次いで、データプロバイダは、第１の部分を含む第１のネットワーク応答を構築する（動作３２２）。応答の一例を、‘プル応答’の形式で以下に記述する。‘プル応答’の形式は、特有のＸＭＬ構造を有するＳＯＡＰエンベロープの形式をとる。次いで、第１のネットワーク応答は、データレシーバ２１０に送出される（動作３２３）。一実施形態においては、データプロバイダ２２０は、第１のネットワーク応答自体に、データレシーバ２１０に供給される第１のコンテキストを含める。図２においては、第１のネットワーク応答は、ネットワーク応答２３１Ｂとして示してある。

エニュメレーションのセッションは要求駆動であるので、データプロバイダ２２０は、セッションをさらに進行させる前に、次の要求を待ち受ける（動作３３１）。図４を参照すると、データレシーバ２１０は、この段階において、セッションが続く前に、さらなる動作を実行することになっている。図４の方法４００は、第１のネットワーク応答であっても、そうでなくても、エニュメレーションのセッション内でネットワーク応答を受け取るときに、データレシーバ２１０がとる動作を記述している。具体的には、データレシーバ２１０はネットワーク応答を受け取り（動作４０１）、ネットワーク応答中に供給されるコンテキストを含む次の要求を生成し（動作４０２）、次いで、次の要求をデータプロバイダ２２０に伝送する（動作４０３）。コンテキストは、先のネットワーク応答から次のネットワーク応答へ直接移すことができるが、これは必ずしもそうでなくてもよい。おそらく、先のネットワーク応答に供給されたコンテキストの一部分だけが、次の要求に供給される。さらに、次の要求に供給されるコンテキスト情報は、先のネットワーク応答においてコンテキスト情報が符号化された方法と比較して、異なる符号化を施すこともできる。さらに、次の要求に供給されるコンテキストは、データレシーバによってさらに処理しておく（例えば、暗号化および／もしくは圧縮しておく）ことができる。

データアイテムの収集の残部の任意の部分に対する第２の要求もしくは任意の後続の要求を受け取ると（動作３４１）、データプロバイダ２２０は、第２の要求から先に供給されたコンテキストを読み取り（動作３４２）、複数のデータアイテムの第２の部分がデータレシーバのコンピュータ処理システムに供給されたことを反映する第２のコンテキストを識別して（動作３５１）、どの程度の量の次のコンテキストをデータレシーバのコンピュータ処理システムに供給すべきかを決定する（動作３５２）。

データレシーバ２１０に供給されるコンテキストの部分は、先にデータレシーバ２１０に供給されたコンテキストと同じ範囲とすることができるが、これは必ずしもそうでなくてもよい。データプロバイダ２２０は、状況によって保証される場合には、先に供給したものと大きく異なるコンテキストを供給することができる。例えば、データプロバイダ２２０が、データレシーバ２１０が要求駆動のエニュメレーションに能動的に関係して、先の応答を受け取るといつでも迅速に要求を発行していることを発見すると仮定する。この場合には、セッションは迅速に完了して、かなり長い時間にわたってメモリ資源を拘束することがないことが予測されるので、データプロバイダ２２０が、データレシーバ２１０にまったく供給することなく、全体コンテキストを維持するコストは小さくすることができる。次いで、データプロバイダ２２０は、データプロバイダ２２０がデータレシーバ２１０に送ろうと考える次のコンテキストの部分を供給する（動作３５３）。

データプロバイダ２２０は、また、要求から読み取った先のコンテキストを使用して、データレシーバに供給すべきデータアイテムの収集の次の部分を識別する（動作３６１）。次いで、データプロバイダ２２０は、データアイテムの収集の次の部分を含む、次のネットワーク応答を構築する（動作３６２）。次いで、次のネットワーク応答が、データレシーバ２１０に送出される（動作３６３）。この段階において、供給するべきデータアイテムの収集のデータアイテムがもうない（決定ブロック３７０においてＮｏである）場合には、セッションはこの時点で終了する。しかしながら、さらにデータアイテムがある（決定ブロック３７０においてＹｅｓである）場合には、セッションは動作３３１において次の要求を待ち受けることによって継続する。

本発明の一般的な原理について記述したが、次に本発明の具体的な一実施形態をより詳細に記述する。この具体的な実施形態においては、セッションにおける要求および応答の各々は、ＸＭＬ文書を含むＳＯＡＰエンベロープとして構築される。

上記に簡潔に述べたエニュメレートの要求の形式を以下に示す。前述のように、データレシーバ２１０は、要求駆動のエニュメレーションのセッションを開始するために、データプロバイダ２２０にエニュメレートの要求を伝送する。分かりやすくするために行番号を付与してある。

行１から行１６は、ＳＯＡＰエンベロープ全体を定義するＸＭＬ要素を表す。行２から行９は、ＳＯＡＰエンベロープのためのヘッダー要素を表す。行３から行５は、アクションがエニュメレートの要求であることを定義する（行４の「Ｅｎｕｍｅｒａｔｅ」を参照）アクションのＸＭＬ要素を表す。行６は、セッション識別子を識別する。行７は、データプロバイダのアドレスを表す。行８は、ヘッダーのＸＭＬ要素内に追加のＸＭＬ要素がある場合があることを表す。行１０から行１５は、ＳＯＡＰボディのＸＭＬ要素を表す。行１１から行１４は、エニュメレーションのセッションに必要な情報を定義するエニュメレートのＸＭＬ要素を表す。例えば、行１２は、フィルタ要素を識別する。このフィルタ要素は、フィルタダイアレクトの属性を含み、これはフィルタを表現するためのクエリー言語（例えば、ＳＱＬ、ＸＰＡＴＨ、もしくは他のＵＲＩ）を定義する。さらに、フィルタ要素は「任意の」属性を含み、これは、指定のクエリー言語を使用してフィルタを表現する。本明細書の説明および本特許請求の範囲において、「クエリー言語」とは、最初の複数データアイテムをひとつも含まないか、一部もしくは全部を含むフィルタリングされたデータアイテムを生成するために、最初の複数データアイテムに対するフィルタを表現することに使用することができる、任意の組のセマンティックな規則である。

以下は、上記の形式に続く、エニュメレートの要求の一例であり、分かりやすくするために行番号を付与してある。

行（０５〜０７）は、このメッセージがエニュメレートの要求であり、データ源がエニュメレートの応答メッセージで応答することが期待されることを示す。ｗｓｅ：Ｆｉｌｔｅｒ要素は存在せず、結果として得られるエニュマレーションのコンテキストは、すべての利用可能な要素を返すことが期待される。

データプロバイダ２２０は、要求駆動のエニュメレーションのセッションを完全に初期化するために、エニュメレートの要求に対して、エニュメレートの応答で応答するとともに、以下の形式に準拠することが可能であり、ここで分かりやすくするために行番号を付与してある。

行１から行１４は、ＳＯＡＰエンベロープ全体を定義するＸＭＬ要素を表す。行２から行７は、ＳＯＡＰエンベロープのヘッダー要素を表す。行３から行５は、アクションがエニュメレートの応答であることを定義するアクションのＸＭＬ要素を表す（行４の「ＥｎｕｍａｒａｔｅＲｅｓｐｏｎｓｅ」を参照）。行６は、行２から行７にわたるヘッダーのＸＭＬ要素内に追加のＸＭＬ要素がある可能性があることを表している。行８から行１３は、ＳＯＡＰボディのＸＭＬ要素を表す。行９から行１２は、エニュメレーションのセッションの初期化を完了するために使用する情報を定義するエニュメレートの応答のＸＭＬ要素を表す。例えば、行１０はエニュメレーションのコンテキストのＸＭＬ要素であり、これには、セッションにおける将来の任意の‘プル要求’のためのコンテキストを識別するのに十分な情報を含む最初のコンテキストを含めることができる。ＥｎｕｍｅｒａｔｅＣｏｎｔｅｘｔ要素は、新規のエニュメレーションのコンテキストのＸＭＬ表現を含む。データレシーバ２１０は、‘プル応答’メッセージ（以下にさらに記述する）がこのエニュメレーションのコンテキストを更新するまで、かつ更新しない限り、このＸＭＬデータをこのエニュメレーションのコンテキストのための‘プル要求’中に渡す。行１１は、このエニュメレーションのコンテキストのＸＭＬ要素内に、さらにＸＭＬ要素が含まれる可能性があることを表す。

以下に示すのは、上記の形式に続く仮定のエニュメレートの応答である。

行０６から行０８は、メッセージがエニュメレートの応答メッセージであることを示す。行１５から行１７は、下記の‘プル演算’をサポートするエニュメレーションコンテキストのＸＭＬ表現である。

この‘プル演算’は、データレシーバ２１０が‘プル演算’のメッセージをデータプロバイダ２２０に送ることによって開始することができる。以下は、‘プル要求’のための例示的形式であり、分かりやすくするために行番号を付与してある。

行１から行２０は、ＳＯＡＰ構造の‘プル要求’である、ＸＭＬ要素全体を定義している。行２から行１０は、ヘッダーのＸＭＬ要素を定義している。行３から行５は、アクション要素であり、この要素においては、アクションはプル要求として定義される（行４の「Ｐｕｌｌ」を参照のこと）。行６はメッセージ識別子のＸＭＬ要素である。この要素は、‘プル要求’をセッションと関係づける識別子を含む。行７は、「返信先」のＸＭＬ要素であり、これは‘プル要求’への応答のためのアドレスを供給する。行８は、データプロバイダ２２０のアドレスを指定する、アドレスのＸＭＬ要素である。行９は、ヘッダーのＸＭＬ要素に含まれるさらなるＸＭＬ要素がある可能性があることを示す。

行１１から行１９は、ボディのＸＭＬ要素を表す。具体的には、行１２から行１８は、‘プル’のＸＭＬ要素を表し、これは‘プル要求’に使用される情報を含む。例えば、行１３はエニュメレーションのコンテキスト要素であり、この要素においては、先に供給されたエニュメレーションの要素が挿入される。このエニュメレーションのコンテキストは、セッションのコンテキストが何かを識別するために、データプロバイダ２２０によって使用される。

行１４は、最大時間のＸＭＬ要素であり、これはデータプロバイダ２２０が‘プル要求’を受け取った後にデータプロバイダ２２０が関連する‘プル応答’を供給する前に許容すべき最大時間を反映している。関連する‘プル応答’を送る前に、データプロバイダ２２０は、この最大時間を超過しないことを保証にすることになる。

行１５は、最大要素数のＸＭＬ要素であり、これはプロバイダ２２０が関連する‘プル応答’において許容すべきＸＭＬ要素の最大数を反映する。関連する‘プル応答’を送る前に、データプロバイダ２２０は、プル応答がこの最大数より多いＸＭＬ要素を含まないことを保証にすることになる。

行１６は、最大文字数のＸＭＬ要素であり、これはプロバイダ２２０が関連するプル応答内に許容すべき文字の最大数である。関連する‘プル応答’を送る前に、データプロバイダ２２０は、‘プル応答’がこの最大文字数より多くを含まないことを保証することになる。

以下は、‘プル要求’の例であり、分かりやすくするために行番号を付与してある。

表２の行（０５）から行（０７）は、このメッセージは‘プル要求’であり、データ源は、‘プル応答’メッセージで応答すると期待される。行（１６）は、応答メッセージは、‘プル要求’メッセージを受け取って後、３０秒以下で生成しなくてはならないことを示している。行（１７）は、１０個以下の要素が、‘プル応答’メッセージのボディ内に戻されるべきことを示す。

‘プル要求’を受け取り、処理するときに、データレシーバ２１０は、‘プル応答’を生成することができる。以下は、‘プル応答’の例示的な形式であり、分かりやすくするために行番号を付与してある。

行１から行１８は、ＳＯＡＰエンベロープのＸＭＬ要素全体を表す。行２から行７は、ＳＯＡＰエンベロープのためのヘッダー要素を表す。行３から行５は、アクションがプル応答であることを定義するアクションのＸＭＬ要素を表す（行４の「ＰｕｌｌＲｅｓｐｏｎｓｅ」を参照のこと）。行６は、行２から行７をまたぐヘッダーのＸＭＬ要素内に追加のＸＭＬ要素がある可能性があることを表す。

行８から行１７は、ボディＸＭＬの要素を表す。行９から行１６は、応答の部分である要素を含む、プル応答のＸＭＬ要素を表す。行１０は、次の要求に対するエニュメレーションのコンテキストを含むエニュメレーションのコンテキストのＸＭＬ要素である。行１１から行１３は、応答内に供給すべきデータアイテムの全部分を含む、アイテムのＸＭＬ要素を表す。行１２は、実際にデータアイテムを包含する下層のＸＭＬ要素を表す。行１４は、シーケンスの終了のＸＭＬ要素であり、これは、すべてのデータアイテムがデータレシーバ２１０に供給されたときに、設定することができる。このようにして、データレシーバ２１０に、エニュメレーションのセッションの終わりを知らせることができる。ボディのＸＭＬ要素は、１つもしくは複数のデータアイテムがスキップされたために、供給されるデータアイテムが連続ではなくなるときを指定する、別の任意選択のＸＭＬ要素を有することができる。このＸＭＬ要素は、なぜデータアイテムがスキップされたかも指定する。例えば、データアイテムはそのときに使用中であり、したがってアクセスが制限されたためである。さらに、データアイテムは、‘プル要求’によって課せられる最大時間、最大要素数、もしくは最大文字数の制限のために、応答の中にすべて含めることができなかったためである。

以下は、‘プル応答’の例であり、分かりやすくするために行番号を付与してある。

表３の行（０６）から（０８）は、このメッセージが‘プル応答’メッセージであることを示している。行（１５）から（１９）は、この‘プル要求’によって返される５つの要素である。ｗｓｅｎ：ＥｎｄＯｆＳｅｑｕｅｎｃｅ（行２０）の要素の存在は、それ以上、利用可能な要素はないこと、およびエニュメレーションのコンテキストはすでに無効であることを示す。

一つの最適化策として、開放演算を実施して、データアイテムが供給される前に、データレシーバ２１０がセッションを終了することを可能にすることができる。‘開放演算’は、データレシーバ２１０が‘開放要求’をデータプロバイダ２２０に送ることによって開始される。例示の開放メッセージは、以下の形式を有し、分かりやすくするために行番号を付与してある。

行４は、メッセージを‘開放要求’であると識別し、行１２から行１５は、開放されているエニュメレーションのセッションに対するエニュメレーションのコンテキストを識別する。

‘開放要求’の処理が成功すると、データプロバイダ２２０は、‘開放応答’を供給することが可能となり、‘開放応答’は以下の例示的な形式を有し、分かりやすくするために行番号を付与してある。

行４は、メッセージを‘開放応答’として識別する。

したがって、本発明の原理によって、データプロバイダは、そのときの環境に応じて、コンテキスト管理におけるデータプロバイダの役割を動的に調整することにおいて、広く柔軟性を有することが可能となる。

本発明は、本発明の趣旨もしくは本質的な特徴から逸脱することなく、他の特有の形態に具現することができる。記述した実施形態は、すべての点で、ただ説明的であって限定的ではないとしてだけと考えるべきである。したがって、本発明の範囲は、前述の説明ではなく、添付の本特許請求の範囲によって示されるものである。本特許請求の範囲の意味および同等の範囲に入るすべての変更は、本特許請求の範囲に含めるものである。

本発明の特徴を実現することのできる、適当なコンピュータ処理システムを示す図である。 データプロバイダのコンピュータ処理システムが、本発明の原理のとおりの要求駆動のエニュメレーションのメッセージ交換を使用することによって、データレシーバのコンピュータ処理システムに、いくつかのデータアイテムを供給する、ネットワーク環境を示す図である。 本発明の原理のとおりに、データプロバイダがコンテキスト管理の均衡を制御することを可能にしながら、データプロバイダのコンピュータ処理システムが、いくつかのデータアイテムをデータレシーバのコンピュータ処理システムに供給する方法のフロー図である。 データレシーバが、データレシーバのコンピュータ処理システムと協働して、２つのコンピュータ処理システム間のコンテキスト管理の責任の均衡を制御する、データプロバイダのコンピュータ処理システムを支援する方法のフロー図である。

Claims (50)

1. データレシーバのコンピュータ処理システムにネットワーク接続可能なデータプロバイダのコンピュータ処理システムを含む環境において、前記データプロバイダのコンピュータ処理システムが、どの程度の量のメッセージ間の状態の情報を前記データプロバイダのコンピュータ処理システムによって保持するかを制御しながら、複数の要求されたデータアイテムを複数の別個のメッセージにして前記データレシーバのコンピュータ処理システムに供給する方法であって、
   データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする動作と、
   少なくとも部分的に前記要求内の情報に基づいて、前記データレシーバのコンピュータ処理システムに供給すべき複数のデータアイテムを識別する動作と、
   前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する動作であって、前記第１の部分は前記複数のデータアイテムの全体よりも少なくする動作と、
   前記複数のデータアイテムの第１の部分を含む前記第１のネットワーク応答を構築する動作と、
   前記第１のネットワーク応答を前記データレシーバのコンピュータ処理システムに送出する動作と、
   前記複数のデータアイテムの前記第１の部分が前記データレシーバのコンピュータ処理システムに供給されることを反映するコンテキストを識別する動作と、
   どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する動作と、
   どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作によって決定されるとおりに、前記データレシーバのコンピュータ処理システムにコンテキストを供給する動作と
   を含むことを特徴とする方法。
2. 前記供給されるコンテキストは、前記第１のネットワーク応答内にあることを特徴とする請求項１に記載の方法。
3. 前記供給されるコンテキストは、前記複数のデータアイテムの前記最後が供給されたことを示すことを特徴とする請求項１に記載の方法。
4. 前記データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする前記動作は、前記データレシーバのコンピュータ処理システムに供給すべき前記データアイテムに対する内部要求にアクセスする動作を含むことを特徴とする請求項１に記載の方法。
5. 前記データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする前記動作は、前記データレシーバのコンピュータ処理システムに供給すべき前記データアイテムに対するネットワーク要求を前記データレシーバのコンピュータ処理システムから受け取る動作を含むことを特徴とする請求項１に記載の方法。
6. 前記複数のデータアイテムは最終の複数のデータアイテムであって、少なくとも部分的に前記要求内の情報に基づいて前記データレシーバのコンピュータ処理システムに供給すべき複数のデータアイテムを識別する前記動作は、
   少なくとも部分的に前記要求内の情報に基づいて最初の複数データアイテムを識別する動作と、
   前記要求内に指定されるさらなる基準に基づいて前記最終の複数のデータアイテムを選択する動作と
   を含むことを特徴とする請求項１に記載の方法。
7. 前記要求内に指定されたさらなる基準に基づいて前記最終の複数のデータアイテムを選択する前記動作は、
   少なくとも部分的に前記要求内の情報に基づいてクエリー言語を識別する動作と、
   前記識別されたクエリー言語を使用して前記要求内のクエリーを解釈する動作と、
   前記解釈されたクエリーを適用することによって前記最終の複数のデータアイテムをフィルタリングする動作と
   を含むことを特徴とする請求項６に記載の方法。
8. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
   前記第１のネットワーク応答内に供給すべきデータアイテムの最大数を前記要求から読み取る動作と、
   前記複数のデータアイテムの前記第１の部分は前記データアイテムの最大数に等しいことを決定する動作と
   を含むことを特徴とする請求項１に記載の方法。
9. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
   前記第１のネットワーク応答内に供給される文字数の最大数を前記要求から読み取る動作と、
   前記複数のデータアイテムの前記第１の部分は前記文字数の最大数以下であることを決定する動作と
   を含むことを特徴とする請求項１に記載の方法。
10. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
    前記第１のネットワーク応答が必要とする最大応答時間を前記要求から読み取る動作と、
    前記第１のネットワーク応答は、前記複数のデータアイテムの前記第１の部分を与える、前記最大応答時間内の戻りであることを判定する動作と
    を含むことを特徴とする請求項１に記載の方法。
11. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストが前記データレシーバのコンピュータ処理システムにまったく供給されないことを決定する動作を含むことを特徴とする請求項１に記載の方法。
12. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストの一部が前記データレシーバのコンピュータ処理システムに供給されることを決定する動作を含むことを特徴とする請求項１に記載の方法。
13. 前記データレシーバのコンピュータ処理システムに供給される前記コンテキストの一部を重複して保持する動作をさらに含むことを特徴とする請求項１２に記載の方法。
14. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストの全部が前記データレシーバのコンピュータ処理システムに供給されることを判定する動作を含むことを特徴とする請求項１に記載の方法。
15. 前記データレシーバのコンピュータ処理システムに供給される前記コンテキストの一部を重複して保持する動作をさらに含むことを特徴とする請求項１４に記載の方法。
16. 前記要求は、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）エンベロープであることを特徴とする請求項１に記載の方法。
17. 前記要求は、Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）であることを特徴とする請求項１に記載の方法。
18. 前記データアイテムは、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）要素であることを特徴とする請求項１に記載の方法。
19. 前記供給されるコンテキストは第１のコンテキストである方法であって、
    前記データレシーバのコンピュータ処理システムからの前記データアイテムに対するネットワーク要求の形式の第２の要求にアクセスする動作と、
    前記第２の要求から前記第１の供給されたコンテキストを読み取る動作と、
    前記第２の要求から読み取られた前記第１の供給されたコンテキストを使用して、前記データレシーバのコンピュータ処理システムに供給すべき前記複数のデータアイテムの第２の部分を識別する動作と
    をさらに含むことを特徴とする請求項１に記載の方法。
20. 前記複数のデータアイテムの第２の部分を含む第２のネットワーク応答を構築する動作と、
    前記第２のネットワーク応答を前記データレシーバのコンピュータ処理システムに送出する動作と、
    前記複数のデータアイテムの前記第２の部分が前記データレシーバのコンピュータ処理システムに供給されることを反映する第２のコンテキストを識別する動作と、
    どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給するかを決定する動作と、
    どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作によって決定されるとおりに、第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給する動作と
    をさらに含むことを特徴とする請求項１９に記載の方法。
21. 前記第２のコンテキストは、前記第１のコンテキストと同一の範囲を有することを特徴とする請求項２０に記載の方法。
22. 前記第２のコンテキストは、前記第１のコンテキストと異なる範囲を有することを特徴とする請求項２０に記載の方法。
23. どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給するかを決定する前記動作は、
    前記データレシーバのコンピュータ処理システムの挙動を評価する動作を含むことを特徴とする請求項２２に記載の方法。
24. どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給するかを決定する前記動作は、
    前記データプロバイダのコンピュータ処理システムの現在の状態を評価する動作を含むことを特徴とする請求項２２に記載の方法。
25. データレシーバのコンピュータ処理システムにネットワーク接続可能なデータプロバイダのコンピュータ処理システムを含む環境において使用するコンピュータ・プログラム・プロダクトであって、
    前記データプロバイダのコンピュータ処理システムが、どの程度の量のメッセージ間の状態の情報を前記データプロバイダのコンピュータ処理システムによって保持するかを制御しながら、複数の要求されたデータアイテムを複数の別個の電子メッセージにして前記データレシーバのコンピュータ処理システムに供給する方法を実装する前記コンピュータ・プログラム・プロダクトであって、
    前記データプロバイダのコンピュータ処理システムの１つもしくは複数のプロセッサによって実行される場合に、前記データプロバイダのコンピュータ処理システムにおいて、
    データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする動作と、
    少なくとも部分的に前記要求内の情報に基づいて、前記データレシーバのコンピュータ処理システムに供給すべき複数のデータアイテムを識別する動作と、
    前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する動作であって、前記第１の部分は前記複数のデータアイテムの全体よりも少なくする動作と、
    前記複数のデータアイテムの第１の部分を含む前記第１のネットワーク応答を構築する動作と、
    前記第１のネットワーク応答を前記データレシーバのコンピュータ処理システムに送出する動作と、
    前記複数のデータアイテムの前記第１の部分が前記データレシーバのコンピュータ処理システムに供給されることを反映するコンテキストを識別する動作と、
    どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する動作と、
    どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかの決定する前記動作のとおりに決定されるように、前記データレシーバのコンピュータ処理システムにコンテキストを供給する動作と
    を実行させるコンピュータ実行可能命令を含む前記コンピュータ・プログラム・プロダクト。
26. 前記供給されるコンテキストは、前記複数のデータアイテムの前記最後が供給されたことを示すことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
27. 前記供給されるコンテキストは、前記第１のネットワーク応答内にあることを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
28. 前記データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする前記動作は、前記データレシーバのコンピュータ処理システムに供給すべき前記データアイテムに対する内部要求にアクセスする動作を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
29. 前記データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする前記動作は、前記データレシーバのコンピュータ処理システムに供給すべき前記データアイテムに対するネットワーク要求を前記データレシーバのコンピュータ処理システムから受け取る動作を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
30. 前記複数のデータアイテムは最終の複数データアイテムであって、
    少なくとも部分的に前記要求内の情報に基づいて前記データレシーバのコンピュータ処理システムに供給すべき複数のデータアイテムを識別する前記動作は、
    少なくとも部分的に前記要求内の情報に基づいて最初の複数のデータアイテムを識別する動作と、
    前記要求内に指定されたさらなる基準に基づいて前記最終の複数のデータアイテムを選択する動作と
    を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
31. 前記要求内に指定されたさらなる基準に基づいて前記最終の複数のデータアイテムを選択する前記動作は、
    少なくとも部分的に前記要求内の情報に基づいてクエリー言語を識別する動作と、
    前記識別されたクエリー言語を使用して前記要求内のクエリーを解釈する動作と、
    前記解釈されたクエリーを適用することによって前記最終の複数のデータアイテムをフィルタリングする動作と
    を含むことを特徴とする請求項３０に記載のコンピュータ・プログラム・プロダクト。
32. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
    前記第１のネットワーク応答内に供給すべきデータアイテムの最大数を前記要求から読み取る動作と、
    前記複数のデータアイテムの前記第１の部分が前記データアイテムの最大数に等しいことを決定する動作と
    含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
33. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
    前記第１のネットワーク応答内に供給すべき文字数の最大数を前記要求から読み取る動作と、
    前記複数のデータアイテムの前記第１の部分は前記文字数の最大数以下であることを決定する動作と
    を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
34. 前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する前記動作は、
    前記第１のネットワーク応答が必要とする最大応答時間を前記要求から読み取る動作と、
    前記第１のネットワーク応答は、前記複数のデータアイテムの前記第１の部分を与える、前記最大応答時間内の戻りであることを決定する動作と
    を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
35. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストが前記データレシーバのコンピュータ処理システムにまったく供給されないことを決定する動作を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
36. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストの一部が前記データレシーバのコンピュータ処理システムに供給されることを決定する動作を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
37. 前記方法は、
    前記データレシーバのコンピュータ処理システムに供給される前記コンテキストの一部を重複して保持する動作をさらに含むことを特徴とする請求項３６に記載のコンピュータ・プログラム・プロダクト。
38. どの程度の量の前記コンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作は、前記コンテキストの全部が前記データレシーバのコンピュータ処理システムに供給されることを判定する動作を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
39. 前記方法は、
    前記データレシーバのコンピュータ処理システムに供給される前記コンテキストの一部を重複して保持する動作をさらに含むことを特徴とする請求項３８に記載のコンピュータ・プログラム・プロダクト。
40. 前記要求は、ＳＯＡＰエンベロープであることを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
41. 前記要求は、ＲＭＩであることを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
42. 前記データアイテムは、ＸＭＬ要素であることを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
43. 前記供給されるコンテキストは第１のコンテキストであって、前記方法は、
    前記データレシーバのコンピュータ処理システムからの、前記データアイテムに対するネットワーク要求の形式の第２の要求にアクセスする動作と、
    前記第２の要求から、前記第１の供給されるコンテキストを読み取る動作と、
    前記第２の要求から読み取られた第１の供給されるコンテキストを使用して、前記データレシーバのコンピュータ処理システムに供給すべき前記複数のデータアイテムの第２の部分を識別する動作と
    を含むことを特徴とする請求項２５に記載のコンピュータ・プログラム・プロダクト。
44. 前記コンテキストは第１のコンテキストであって、前記方法は、
    前記複数のデータアイテムの第２の部分を含む第２のネットワーク応答を構築する動作と、
    前記第２のネットワーク応答を前記データレシーバのコンピュータ処理システムに送出する動作と、
    前記複数のデータアイテムの前記第２の部分が前記データレシーバのコンピュータ処理システムに供給されることを反映する第２のコンテキストを識別する動作と、
    どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する動作と、
    どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作のとおりに決定されるように、第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給する動作をさらに含むことを特徴とする請求項４３に記載のコンピュータ・プログラム・プロダクト。
45. 前記第２のコンテキストは、前記第１のコンテキストと同じ範囲を有することを特徴とする請求項４４に記載のコンピュータ・プログラム・プロダクト。
46. 前記第２のコンテキストは、前記第１のコンテキストと異なる範囲を有することを特徴とする請求項４４に記載のコンピュータ・プログラム・プロダクト。
47. どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給するかを決定する前記動作は、前記データレシーバのコンピュータ処理システムの挙動を評価する動作を含むことを特徴とする請求項４６に記載のコンピュータ・プログラム・プロダクト。
48. どの程度の量の前記第２のコンテキストを前記データレシーバのコンピュータ処理システムに供給するかを決定する前記動作は、前記データプロバイダのコンピュータ処理システムの現在の状態を評価する動作を含むことを特徴とする請求項４６に記載のコンピュータ・プログラム・プロダクト。
49. データレシーバのコンピュータ処理システムにネットワーク接続可能なデータプロバイダのコンピュータ処理システムを含む環境において、前記データプロバイダのコンピュータ処理システムが、どの程度の量のメッセージ間の状態の情報を前記データプロバイダのコンピュータ処理システムによって保持するかを制御しながら、複数の要求されたデータアイテムを、複数の別個の電子メッセージにして前記データレシーバのコンピュータ処理システムに供給する方法であって、
    データレシーバのコンピュータ処理システムに供給すべきデータアイテムに対する要求にアクセスする動作と、
    前記データプロバイダのコンピュータ処理システムと前記データレシーバのコンピュータ処理システムとの間のコンテキスト管理における均衡を制御しながら、前記データレシーバのコンピュータ処理システムに前記データアイテムを供給するステップを含むことを特徴とする方法。
50. 前記データプロバイダのコンピュータ処理システムと前記データレシーバのコンピュータ処理システムの間のコンテキスト管理における均衡を制御しながら、前記データレシーバのコンピュータ処理システムに前記データアイテムを供給する前記ステップは、
    少なくとも部分的に前記要求内の情報に基づいて、前記データレシーバのコンピュータ処理システムに供給すべき複数のデータアイテムを識別する動作と、
    前記データレシーバのコンピュータ処理システムへの第１のネットワーク応答内に供給すべき前記複数のデータアイテムの第１の部分を識別する動作であって、前記第１の部分は前記複数のデータアイテムの全体よりも少なくする動作と、
    前記複数のデータアイテムの第１の部分を含む前記第１のネットワーク応答を構築する動作と、
    前記第１のネットワーク応答を前記データレシーバのコンピュータ処理システムに送出する動作と、
    前記複数のデータアイテムの前記第１の部分が前記データレシーバのコンピュータ処理システムに供給されることを反映するコンテキストを識別する動作と、
    どの程度の量の前記コンテキストを、前記データレシーバのコンピュータ処理システムに供給すべきかを決定する動作と、
    どの程度の量の前記コンテキストを、前記データレシーバのコンピュータ処理システムに供給すべきかを決定する前記動作のとおりに決定されるように、前記データレシーバのコンピュータ処理システムにコンテキストを供給する動作と
    を含むことを特徴とする請求項４９に記載の方法。
    

Images