JP4640682B2 - クライアント−サーブレット通信を改善するための方法およびシステム - Google Patents

Description

本発明は、クライアント−サーバ通信に関し、特に、既存の通信プロトコルを変更することなくまたクライアントを変更することなく、ワールド・ワイド・ウェブ（ウェブ）におけるクライアント−サーブレット通信（Client-Servlet communication）の改善に関し、より具体的には、所望の情報を取得するための当初のクライアントのウェブ・ブラウザ要求に含まれない欠落情報をサーブレットが識別する場合にそのようなサーブレットの柔軟性およびインタラクティビティ（interactivity：相互性）を向上させることに関する。

用語「クライアント−サーバ（Client-Server）」は、通信プロトコル（例えば、ＨＴＴＰ）を介して互いに通信するクライアントおよびサーバから成るネットワーク・アプリケーション・アーキテクチャを意味する。

ウェブは、リソース（resource）と呼ばれる関心のあるアイテムが、ユニフォーム・リソース識別子（ＵＲＩ：Uniform Resource Identifier）と呼ばれるグローバル識別子（globalidentifier）により識別される情報空間を意味する。ウェブは、３つの規格で構成されている。すなわち、情報の各ページに、それを見出すことができる一意の「アドレス」がどのように付与されるかを規定するユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）、クライアントおよびサーバがどのように情報を互いに送るかを規定するハイパー・テキスト転送プロトコル（ＨＴＴＰ：Hyper Text Transfer Protocol）、ならびに各種デバイス上に情報が表示されるように情報を符号化する方法であるハイパー・テキスト・マークアップ言語（ＨＴＭＬ：Hyper Text Markup Language）である。

ウェブは、以下のように機能する：クライアントのウェブ・ブラウザ（例えば、マイクロソフトのインターネット・エクスプローラ（Ｒ）、アップルのサファリ（Ｒ））が開かれると、そのブラウザは、ハイパー・テキスト転送プロトコル（ＨＴＴＰ）を用いてクライアント（または、使用されているコンピュータ）の代わりに通信し、ウェブ・ページ要求を行う。ひとたびその要求が送られると、クライアントのウェブ・ブラウザ・コンピュータは、サーバからのハイパー・テキスト・データ・ストリームを待ち受ける。サーバがその要求を受け取ると、サーバは、要求されたファイルを捜し、もし存在すれば、そのファイルをクライアントのウェブ・ブラウザに要求通り送る。

サーブレットは、サーバ上で走るプログラムであり、クライアントのウェブ・ブラウザからの要求を待ち受け、この要求への応答（例えば、動的に生成されたウェブ・ページとして）生成する。

従来技術
従来技術のサーブレットは、以下のように機能する：
クライアントのウェブ・ブラウザが、ＨＴＴＰ要求をサーブレットに、そのＵＲＬを呼び出すことによって送る。クライアントのウェブ・ブラウザは、ブラウザがサーブレットを呼び出していることを必ずしも知っているわけではない。サーブレットを呼び出すことは、何か他のウェブ・ページをロードすることに似ており、違いは、パラメータを要求の中でサーブレットに渡すことができること、およびサーバにより送り返される応答が静的な文書ではなく、動的に生成されることである。

要求は、サーブレットをホストしているアプリケーション・サーバにより分析され、要求されたＵＲＬに対応するサーブレットに渡される。

要求は、サーブレットにより分析され、最終のパラメータが構文解析および解釈され、クライアントのウェブ・ブラウザへ返す文書が動的に生成される（文書のコンテンツは、クライアントのウェブ・ブラウザにより要求中で渡される最終のパラメータに依存し得る）。

生成された文書は、クライアントのウェブ・ブラウザにより受信され、表示または解釈される（ＪａｖａＳｃｒｉｐｔ（Ｒ）のような何らかの実行可能スクリプトを文書が含んでいる場合）。

サーブレットは、動的なコンテンツを提示するための強力かつ適応性のある枠組みを提供することによりインターネットを変容させた。すなわち、コンテンツが規則的に更新されなければならない静的な文書を発行する代わりに、サーブレットは、クライアントのウェブ・ブラウザが、パラメータをＨＴＴＰ要求に追加し、その要求に基づいて現在の情報を得ることができるようにする。サーブレットがなければ、ユーザが自分のクライアントのウェブ・ブラウザからサーバと対話する対話型ウェブ・アプリケーションを作り出すことは不可能であろう。

しかしながら、サーブレットには１つの制限がある。すなわち、要求が受け取られた後、サーブレットには、クライアントのウェブ・ブラウザに欠落情報を求める方法が全くないことである。

サーブレットは、到来する要求と共に、サーバ上でなされたアクション、またはサーバにより返された情報に影響し得るパラメータのリストを受け取ることができる。例えば、もしインターネット上で何かを命令すると、「送出（submit）」ボタンを押すことにより、命令されたアイテムを含むリストがサーバに送られる。サーバは、このリストで動作し（データベースを更新する等）、通常すべての選ばれたアイテムを列挙した確認ページを生成する。

しかしながら、従来のサーブレットでは、サーバ上で要求を扱うために必要なすべてのパラメータは、クライアントのウェブ・ブラウザにより送られた当初の要求に含まれていなければならない。すなわち、もしサーブレットが、要求の処理の間に、何らかの付加的な情報がクライアントのウェブ・ブラウザによって当初の供給中に提供されていないことに気付いても、処理を一次停止し、クライアントのウェブ・ブラウザに欠落情報を求め、処理が中断された時点からその処理を再開する方法が全くない。これによりサーブレットの応用エリアが制限される。

クライアントのウェブ・ブラウザは、サーブレットがどんな情報を必要としているかを正確に知らなければならない。

クライアントのウェブ・ブラウザは、その要求において、サーブレットにより実際に必要とされる情報よりも多くの情報を提供する必要があり得る。

従来のサーブレットは、クライアントのウェブ・ブラウザ要求により提供されるよりも多くの情報を必要とする不測の状況を扱うことができない。要求がすべての必要な情報を含んでいるのではないのであれば、この問題を扱う従来の方法は、処理を停止したり、元のページに取って代わりエラー・メッセージを表示するウェブ・ページをクライアントのウェブ・ブラウザに返したり、欠落情報を要求し、新しい情報を有する同じまたは別のサーブレットを呼び出す新しいページを表示するというものである。

これは、欠落情報を扱うための非常に良好な方法ではない。なぜならば、１つのサーブレット呼び出しにおいて要求処理を停止し、別のサーブレット呼び出しにおいてそのトランザクションを継続することは単純ではないことがあるからである。また、それによりユーザが混乱を来すことがある。なぜならば、どんな情報が欠落しているかをユーザに知らせる小さい注釈と共に同じページがかなり頻繁に再表示されるからであり、これは、使い勝手の観点からは問題である。

既存の通信プロトコルを変更することなくまたクライアントを変更することなく、ワールド・ワイド・ウェブ（ウェブ）におけるクライアント−サーブレット通信を改善する方法およびシステムを提供すること、より具体的には、所望の情報を取得するための当初のクライアントのウェブ・ブラウザ要求中に含まれない欠落情報をサーブレットが識別する場合にそのようなサーブレットの柔軟性およびインタラクティビティを向上させることが本発明目的である。

本発明は、既存の通信プロトコルを変更することなく、またクライアントを変更することなくクライアント−サーブレット通信を改善する方法およびシステムを提供する。

もし当初の要求が、所望の情報を取得するためのすべての情報を含んでいれば、クライアントとサーブレットとの間の既存の従来技術の一方向通信パスは不変のままである。しかしながら、所望の情報を取り出すための当初のクライアントのウェブ・ブラウザ要求中に含まれない欠落情報をサーブレットが識別する場合、サーブレットは、前記当初のＨＴＴＰ要求のＨＴＴＰ応答機能を利用することにより欠落情報をサーブレットに提供するために別の通信パスを自動的に開き、この別の通信パスは、さらなるサーブレット機能コンポーネントによりサポートされており、以下のステップを特徴とする：クライアントのウェブ・ブラウザにおいて実行された場合に欠落情報を取得しかつさらなるサーブレット機能コンポーネントを呼び出すスクリプトをサーブレットにより生成するステップと、そのスクリプトを、それが部分的応答であると示しているＨＴＴＰ応答に追加するステップと、スクリプトを含むＨＴＴＰ応答をクライアントのウェブ・ブラウザに送るステップと、欠落情報が利用可能になるまでサーブレットによる当初のＨＴＴＰ応答の実行を一時停止するステップと、さらなるサーブレット機能コンポーネントにより欠落情報を受信するステップであって、欠落情報が、クライアントのウェブ・ブラウザにおけるスクリプトの実行の間にそのスクリプトにより作成された新たなＨＴＴＰ要求中に含まれるステップと、欠落情報をサーブレットに提供するステップと、前記ＨＴＴＰ応答の残りを取得しそのＨＴＴＰ応答の残りを表示用にクライアントのウェブ・ブラウザに提供するために欠落情報を用いてサーブレットによる当初のＨＴＴＰ応答の実行を継続するステップと、を特徴とする。

従来技術において説明した制限がサーブレットにある理由は、ＨＴＴＰプロトコルおよびウェブ・ブラウザ／サーバが以下のように設計されていることに由来する。

ＨＴＴＰは、クライアントのウェブ・ブラウザとウェブ・サーバとの間の通信のために用いられるプロトコルである。

通常、ＨＴＴＰプロトコルは、クライアントのウェブ・ブラウザが、ある情報をサーバに送る（ＰＯＳＴ要求）か、あるいはサーバから文書を得る（ＧＥＴ要求）かするために要求をウェブ・サーバ（またはアプリケーション・サーバ／サーブレット）に送ることを可能にする。

クライアントのウェブ・ブラウザにより送られる要求のタイプ（ＧＥＴまたはＰＯＳＴ）と無関係に、サーバは常に、その要求を処理し、戻り符号（例えば、要求がうまく扱えたかどうかを示す）を含むヘッダを含む応答、および最終結果文書を返すべきである。要求が成功した場合、クライアントのウェブ・ブラウザは通常、サーバにより返された文書を表示し、要求を引き起こした要素のリンクを含んでいた元のページをサーバからの応答で置き換える。

もし要求が長期に渡るものであれば、サーバは、文書生成全体が完了される前に、応答文書の部分を定期的に送ることもできる。このようにして、ユーザは、文書全体が生成されて伝送されるのを待つ必要なく、文書の冒頭を読むことができる。

これは一方向通信である。すなわち、プロトコルは、クライアントのウェブ・ブラウザにより開始された通信を予知するのみである。サーバは通常、クライアントのウェブ・ブラウザに要求を送るための方法を全く持たない。

この制限を克服するため、本発明は、応答文書全体が生成される前にサーバが「部分的文書」をクライアントのウェブ・ブラウザに送ることができるという事実、およびこの部分的文書が、文書全体が完全に送られる前にクライアントのウェブ・ブラウザにより実行できるＪａｖａＳｃｒｉｐｔを含み得るという事実を利用する。ＪａｖａＳｃｒｉｐｔは、ＨＴＭＬページに埋め込むことができ、クライアントのウェブ・ブラウザにより解釈される言語である。

本発明により、以下のように機能する（図１参照）ウェブ・クライアントとウェブ・サーバとの間の相互通信が提供される：
クライアントのウェブ・ブラウザが、ＨＴＴＰ要求をアプリケーション・サーバ上のメイン・サーブレットに送る。要求によってメイン・サーバは、要求を処理するためにサーブレットにより必要とされるいくつかの初期パラメータを提供できる、
メイン・サーブレットは、要求を受信し（１０）、最終のパラメータを解釈し、サーバ側でいくつかの動作を行うことにより要求の処理を開始し、応答文書を生成する（２０）、
（この時点まで、これは従来技術のサーブレットの作動の仕方である）。要求の処理の間、メイン・サーブレットは、何らかの情報が欠落していることおよびこの情報が要求の発信者により提供されなければならないことに気付く（３０）。この情報は、ユーザが入力しなければならない何らかの欠落データ、クライアントのウェブ・ブラウザそれ自体に関するまたは要求が処理される間クライアントのウェブ・ブラウザ上に表示されるページ中の何か他の要素の状態に関するシステム情報かもしれない。それは、によって、または相互作用なしで、クライアントのウェブ・ブラウザ上でＪａｖａＳｃｒｉｐｔを実行することによるユーザ・インタラクション有りまたは無しで取得できる情報でなければならない、
メイン・サーブレットは、要求の処理および応答の生成を一時停止して、ＪａｖａＳｃｒｉｐｔを生成し（４０）、これは、クライアントのウェブ・ブラウザ上で実行される際に以下のことを行う、
メイン・サーブレットは、欠落情報を取得する（または、ユーザに要求する）、
メイン・サーブレットは、セカンダリ・サーブレットを呼び出し、パラメータとしての付加的に取得された情報およびその情報を要求しているサーブレットにより生成された鍵を渡す。
メイン・サーブレットは、前のステップで生成されたＪａｖａＳｃｒｉｐｔを、部分的に生成された応答文書に追加し、その部分的応答をクライアントのウェブ・ブラウザに送る（５０）。
メイン・サーブレットは、メイン・サーブレット前に生成した鍵の下で、メイン・サーブレットが求めている情報をウェブ・セッションまたは共有メモリ中で見出すことができるまで待機することによりその実行を一時停止する（６０）。
その間、クライアントのウェブ・ブラウザは、メイン・サーブレットから受信した部分的文書を表示し始める。もしいくらかのコンテンツがすでに生成されていれば、それは表示される。応答に埋め込まれたＪａｖａＳｃｒｉｐｔが実行される。
部分的応答文書に埋め込まれたＪａｖａＳｃｒｉｐｔを実行している間、クライアントのウェブ・ブラウザは、メイン・サーブレットにより要求された欠落情報を取得し、この情報および、情報がその下で格納されるべき鍵を、セカンダリ・サーブレットのＵＲＬに符号化し、要求をこのセカンダリＵＲＬに送る。
メイン・サーブレットへの要求が依然走っている間、この第２の要求の結果が、クライアントのウェブ・ブラウザにより表示されている現在の文書に取って代わるべきでなく、第１の要求に割り込むべきではないことに留意することが重要である。これは、第２の要求の結果を、別個のフレーム、またはページの特定の要素（画像、埋め込みフレーム）へリダイレクトすることにより、またはＨＴＴＰ要求をプログラムに基づいて開くＪａｖａＳｃｒｉｐｔ ＡＰＩを用いることにより達成できる。
セカンダリ・サーブレットは、セッション６４（または、第１のサーブレットと共有されるメモリ）において格納すべき情報と共に鍵／値ペアをそのパラメータ中に含む要求を受信する。次に、セカンダリ・サーブレットは、クライアントのウェブ・ブラウザ６５に成功コードを返す。クライアントのウェブ・ブラウザは、セカンダリ・サーブレットの応答を無視できる。
メイン・サーブレットは、セッション（共有メモリ）において、それが生成した鍵について値が格納されていることを検出する。メイン・サーブレットは、この値抽出し（７０；要求を処理する際に欠落していた情報である）、その値をセッション／共有メモリから取り去り、要求の処理を再開する。
処理は継続し、応答文書の残りが生成される。後に要求の処理の間にさらに多くの情報が欠落していることが明らかになれば、ユーザにより多くの情報を逐次的に要求するために、最後のステップを繰り返すことができる（８０）。
最後に、要求が完結され、クライアントのウェブ・ブラウザは、完全な応答文書を受信し、表示する（８０）。

本発明の好ましい実施形態において、サーブレットは、Ｊａｖａサーブレットとして実装される。しかしながら、サーバ上でホストされ、ＨＴＴＰ要求に応答して動的なコンテンツを提供するＣＧＩスクリプトまたは任意のサーブレット様プログラムについても同じ方法が用い得るであろう。

本発明のさらなる好ましい実施形態において、スクリプトはＪａｖａＳｃｒｉｐｔとして実装される。しかしながら、欠落情報を取得するためにクライアントのウェブ・ブラウザに返されたスクリプト（ＪａｖａＳｃｒｉｐｔ）は、ウェブ・ページに埋め込むことができかつクライアントのウェブ・ブラウザによりオン・ザ・フライで実行できる任意の言語（Ｊａｖａ（Ｒ）、Ｖｉｓｕａｌ Ｂａｓｉｃ（Ｒ）等）であってもよい。

本発明のさらなる実施形態において、ユーザから（マウスまたはキー・イベントのような）非常に低レベルの情報を受信し、この情報の復号処理を行う一般サーブレットを作成することが可能である。クライアントのウェブ・ブラウザは、ユーザにより作り出されたマウス／キー・イベントに関する情報を単に送るだけであり、要求を送る時にサーブレットが何をするか、またはサーブレットがこの情報で何かを行うかどうかは知らない。サーブレットは、この情報を解釈し、特定のイベントが生じた時にアクションがとられなければならないとサーブレットが判断した場合、サーブレットは、イベントまたはクライアントのウェブ・ブラウザ側の何か他の要素に関するより多くの情報を提供することをクライアントのウェブ・ブラウザに要求することができ、クライアントのウェブ・ブラウザにより返された情報に応じてイベントの動的処理を行うことができる。

本発明の別のさらなる実施形態において、サーブレットは復号処理パスと共に用いられる。当初の要求は、処理を開始するのに十分な情報を含んでいる。処理の間、サーブレットは、パラメータ、またはサーバによりバックエンド・システム（データベース等）から取得されたデータに応じて異なる実行パスを取ることができる。もしある時点で、処理がどのように継続すべきかに関する決定がユーザによりなされなければならなければ、サーブレットは、ユーザに決定を促すよう、クライアントのウェブ・ブラウザに要求できる。この決定は、要求を中断することなく、要求のさらなる処理に影響し得る。処理は、単一のトランザクションにおいて走り得る。

本発明のさらなる好ましい実施形態において、セカンダリ・サーブレットがさらに提供される。このセカンダリ・サーブレットは、ＪａｖａＳｃｒｉｐｔにより送られた新しいＨＴＴＰ要求を受信し、鍵値ペアを現在のＨＴＴＰセッション・オブジェクト中に格納する。

本発明のさらなる実施形態において、セカンダリ・サーブレットを用いる代わりに、ＪａｖａＳｃｒｉｐｔは、ＨＴＴＰセッションを更新する要求をメイン・サーブレットに送ることができるであろう。しかしながら、この場合、メイン・サーブレットの第２のインスタンスは、（メインの要求への応答を依然生成しており、欠落値を待つ第１のインスタンスと並行して）開始するであろう。

本発明のさらなる実施形態において、ＨＴＴＰプロトコルは、他の通信プロトコルにより置き換えられ、この通信プロトコルは、情報を前記サーブレット（８）から取得するために前記クライアントのウェブ・ブラウザ（３）による要求を開始する一方向通信パス、ならびに前記要求の成功または失敗を明示する戻り符号を少なくとも含み、もし利用可能であれば、前記要求の結果を含む前記サーブレットによる応答を送ることを特徴とする。

以下では、本発明の好ましい実施形態が、図面のみを参照する例によってさらに詳細に説明される。

図２は、クライアント−サーバ・アーキテクチャにおける本発明の好ましい実施形態を示す。

本発明は、クライアント１およびサーバ２により構成されている。クライアント側１は、好ましくは、標準のクライアントのウェブ・ブラウザ３であり、このウェブ・ブラウザは、ＨＴＴＰ要求をウェブ・サーバに送り、サーバにより返されたＨＴＭＬ文書を表示することができる。クライアントのウェブ・ブラウザ３は、表示する文書１３に埋め込まれたＪａｖａＳｃｒｉｐｔ１２を実行できるべきである。さらに、クライアントのウェブ・ブラウザ３は、文書３全体が伝送される前に、サーバにより返された文書１３のパーツに埋め込まれたＪａｖａＳｃｒｉｐｔ１２を表示および実行できるべきである。これは、市場で入手可能なすべての実際のクライアントのウェブ・ブラウザ３の標準挙動である。

代わりに、サーバにより返され、クライアントのウェブ・ブラウザ３において表示される文書１３の型式は、必ずしもＨＴＭＬ文書１３である必要はない。クライアントのウェブ・ブラウザ３により表示できかつ描画（rendering）の間にウェブ・ブラウザ３により解釈されるスクリプト要素を含み得るすべての文書タイプを用いることができる。用いられる文書の例：ＸＭＬ、ＸＨＴＭＬ、ＳＶＧ（スケーラブル・なベクトル・グラフィックス）、ＸＵＬ（ＸＭＬユーザ・インタフェース言語）等、（特に、すべての種類のＸＭＬ文書）。文書に埋め込まれるスクリプト１２は、ＪａｖａＳｃｒｉｐｔ以外の言語で書かれ得るであろう。クライアントのウェブ・ブラウザ３におけるＪａｖａＳｃｒｉｐｔ１２（または、その標準化バージョンＥＣＭＡスクリプト）のサポートは標準である。しかしながら、ウェブ・ブラウザ３により描画されるために文書１３に埋め込まれることができ、文書１３中の他の要素に関する情報、またはクライアントのウェブ・ブラウザ３もしくはユーザ環境に関する情報を取得するためにクライアントのウェブ・ブラウザ３内で実行できるどのような種類のスクリプトも用いることができる。例としては、Ｖｉｓｕａｌ Ｂａｓｉｃスクリプト、ＡｃｔｉｖｅＸコンポーネント、Ｊａｖａアプレット、またはネイティブのクライアントのウェブ・ブラウザ３プラグインであろう。ＨＴＴＰプロトコルは、他の通信プロトコルにより置き換えられ、この通信プロトコルは、情報を前記サーブレット８から取得するために前記クライアントのウェブ・ブラウザ３による要求を開始する一方向通信パス、ならびに前記要求の成功または失敗を明示する戻り符号を少なくとも含み、もし利用可能であれば、前記要求の結果を含むサーブレット８による応答を送ることを特徴とする。

サーバ側２は好ましくは、サーブレット・コンテナ６を好ましくは有するアプリケーション・サーバ４（例えば、ＷｅｂＳｐｈｅｒｅ（Ｒ）またはＴｏｍｃａｔ（Ｒ）のようなＪ２ＥＥサーバ）である。２つのサーブレット、すなわちメイン・サーブレット８およびセカンダリ・サーブレット１０が、本発明の好ましい実施形態においてこのアプリケーション・サーバ４にインストールされている。

アプリケーション・サーバ４は、Ｊ２ＥＥサーバである必要はない。クライアントのウェブ・ブラウザ３から来るＨＴＴＰ要求に動的に反応できるどのような種類のサーバも、用いることができる。Ｊ２ＥＥアプリケーション・サーバの代わりに用い得る技術の例は以下の通りである：Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ、または動的なコンテンツを表示するためにＣＧＩスクリプトを実行できる単純なウェブ・サーバ。サーブレット８、１０およびサーブレット・コンテナ６は、ＡＳＰ、ＰＨＰまたはＣＧＩスクリプトのような同様な技術によって置き換えることができる。

本発明は、その好ましい実施形態において実装される場合、以下のように機能する（図２の矢印参照）：

クライアント側１において、クライアントのウェブ・ブラウザ３は、要求をメイン・サーブレット（１）に送る。メイン・サーブレット８は、文書−応答してクライアントのウェブ・ブラウザ３に送るページ１３−を生成するのに必要なロジックを実装するサーブレットである。メイン・サーブレット８は要求を受信し、要求と共に渡された最終のパラメータを読み、文書１３の生成を開始してその文書をクライアントのウェブ・ブラウザ３に返す。要求と共に渡されたパラメータは、文書１３の生成に影響し得る。本発明は、応答文書１３を生成するためにメイン・サーブレット８により用いられるロジック論理に依存しない。

応答生成時のある時点で、メイン・サーブレット８は、要求の中でクライアントのウェブ・ブラウザ３により（パラメータとして）提供されていないが、なかった付加的な情報が必要でが、クライアントのウェブ・ブラウザ３中のクライアント側１でＪａｖａＳｃｒｉｐｔ１２を実行することにより容易に取得できであろう付加的な情報を必要とする。

メイン・サーブレット８は、生成を開始した文書１３にＪａｖａＳｃｒｉｐｔ１２を挿入する。このスクリプト１２は、クライアントのウェブ・ブラウザ３により実行される場合、欠落情報を取得し、ＨＴＴＰ要求をセカンダリ・サーブレット１０に送り、この要求は、パラメータとして、メイン・サーブレット８により生成された鍵（鍵は、無作為に生成されたどのような一意の文字列であってもよい）および前のステップにおいて取得た値を含む。

ひとたびスクリプト１２が生成されて、部分的応答に挿入されると、メイン・サーブレット８はそのバッファをフラッシュし、その結果、この時点まで生成された応答文書１３の部分が、クライアントのウェブ・ブラウザ（２）に直ちに伝送される。ウェブ・ブラウザ３への通信チャネルは閉じられていない。クライアントのウェブ・ブラウザ３に送られたＨＴＴＰ応答のヘッダは、ＨＴＴＰ１．１に規定されるように、応答が「Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ Ｃｏｄｉｎｇ」を用いることを示す。この符号化は、応答が１つの単一のピースとしてではなく、一連のチャンク（chunk）として来ること、およびサーバが接続を閉じるまで、クライアントのウェブ・ブラウザ３は新しいコンテンツを待つべきであることを意味する。

部分的に生成された文書１３（文書の冒頭および欠落情報を取得するＪａｖａＳｃｒｉｐｔ１２を含むチャンク）がひとたびクライアントのウェブ・ブラウザ３に伝送されると、クライアントのウェブ・ブラウザ３は、文書の残りを待ちつつ、これまでに受信された文書１３の部分のレンダリングを開始し、埋め込まれたスクリプト１２を実行する。

このスクリプト１２の実行は、欠落値を取得し、別のＨＴＴＰ要求をセカンダリ・サーブレット１０に送る。この要求は、パラメータとして、前のステップ（３）において取得された鍵および値を含む。

第１のＨＴＴＰ要求の応答がロードさられている間に付加的なＨＴＴＰ要求を異なるＵＲＬに送る能力は、ウェブ・ブラウザ３にとり通常の挙動である。この能力がなければ、文書全体が完全にロードされる前に、クライアントのウェブ・ブラウザ３は、例えば、ロードされている長い文書の冒頭に含まれている画像を表示できないであろう。

セカンダリ・サーブレット１０は、ＪａｖａＳｃｒｉｐｔ１２により送られたＨＴＴＰ要求を受信し、要求のパラメータに含まれている鍵および値を復号し、この鍵値ペアを現在のＨＴＴＰセッション・オブジェクト（４）に格納する。ＨＴＴＰセッションは、１つのクライアント１とサーバ２との間の現在のセッションについての情報を格納するオブジェクトである。サーブレットが要求を受信するたびに、セッション・オブジェクトはサーブレットに渡される。もし同じクライアントのウェブ・ブラウザ３が、ＨＴＴＰ要求を、同じサーブレット・コンテナ６中および同じウェブ・アプリケーション中に含まれるいくつかのサーブレット８に送れば、同じセッション・オブジェクトは異なるサーブレット８に渡される。サーブレット８は、セッション・オブジェクト中の値を読み込みおよび書き込みできる（値は、後に値を取得するすために使用できる鍵の下で格納される）。ＨＴＴＰセッションを用いることは、異なるサーブレット８間で値を渡すＪ２ＥＥの共通した方法である。

セカンダリ・サーブレット１０を用いる代わりに、ＪａｖａＳｃｒｉｐｔ１２は、ＨＴＴＰセッションを更新する要求をメイン・サーブレット８送ることができるであろう。しかしながら、この場合、（メインの要求への応答を依然生成しており、欠落値を待っている第１のインスタンスと並行して）メイン・サーブレット８の第２のインスタンスが開始するであろう。メイン・サーブレット８は、要求を受信する場合に、その要求が文書を求めているのか、またはその要求が、文書要求（メイン要求）を扱うサーブレットの他のインスタンスによって要求されていた付加的な情報を提供するのを試験する必要がある。技術的には、これは、要求と共に渡されるパラメータを試験することにより行われるであろう。もし特定のパラメータが要求の中に含まれていれば、メイン・サーブレット８は、要求の他のパラメータ中に含まれる鍵／値ペアによってＨＴＴＰセッションを更新するべきであることを知るであろう。何か他の場合においても、メイン・サーブレット８は、応答文書１３を生成すべきである。これを行うことにより、メイン・サーブレット８は、要求のパラメータに応じて２つの異なるロジックを有するであろう。これは、各サーブレットが単一のロジックを実装する、２つの異なるサーブレットを有することとまさに同じである。

セカンダリ・サーブレット１０は、ＨＴＴＰセッション中の第２の要求（ＪａｖａＳｃｒｉｐｔにより送られた要求）により渡された付加的な値を、メイン・サーブレット８に知られるようにするために格納する必要はない。他の方法は、その値を、（アプリケーション・サーバにより用いられる技術に応じて）サーブレット・コンテナ６のＪａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（Ｒ）のシステム特性中に格納、または他の共有メモリ機構を用いるであろう。もう１つの可能性は、セカンダリ・サーブレット１０に、サーバのローカル・ディスクのファイル中にこの値を格納させ、メイン・サーブレット８にその同じファイルを読ませることである。

要求された値が共有メモリ中でメイン・サーブレット８によってひとたび見出されると（ＨＴＴＰセッション中に）、メイン・サーブレット８が起動し、文書１３の生成を継続する。欠落情報によって、文書は今や完全に生成することができ、文書の残りは、ブラウザ（５）に伝送され−最後のステップの間、メイン・サーブレット８は、値が利用可能かどうかを見るためにＨＴＴＰセッションのコンテンツを定期的にチェックしている。メイン・サーブレット８がセッションをチェックする毎に値が利用可能でなければ、メイン・サーブレット８は短時間眠りに就き、再びチェックした。

ひとたびサーブレットが、ウェブ・ブラウザ３との接続を閉じると（これは、サーブレットのdoGet（…）またはdoPost（…）メソッドが戻ると自動的に行われる）、クライアントのウェブ・ブラウザは、文書全体がダウンロードされたことを知る。

サーブレット８は、要求に取りかかるために、クライアントのウェブ・ブラウザから１つより多い付加的な情報を必要とすることがあり得る。複数の欠落情報の取り返しは、本明細書で記載されたステップを、要求の処理の間、数回繰り返すことによって、あるいはすべての欠落情報を取得し１つのＨＴＴＰ要求の中でセカンダリ・サーブレット１０へ送る１つのＪａｖａＳｃｒｉｐｔ１２を生成することによって成し得るであろう。セカンダリ・サーブレット１０は、ＪａｖａＳｃｒｉｐｔにより送られたセカンダリ要求からいくつかの鍵／値ペアを復号し、それに応じてＨＴＴＰセッションを更新しなければならない。

この方法を用いることにより、サーブレットは、クライアントのウェブ・ブラウザ３がその当初の要求を出した後、および要求の処理の間に、クライアントのウェブ・ブラウザ３からの付加的な情報を要求できるであろう。要求の処理は、本発明が無ければ必要とされたであろう、中止および最初からの開始を必要としなかった。

ウェブ・ブラウザ３およびアプリケーション・サーバ４における修正は全く必要とされない。メイン・サーブレット８およびセカンダリ・サーブレット１０双方は、別個に通常のサーブレットであり、これらのサーブレットは、ＨＴＴＰプロトコルにおいて規定されるように、ＨＴＴＰ要求を受信し、１つの単一の応答をその要求の発信者に返す。プロトコルは修正されない。クライアントのウェブ・ブラウザ３とサーバ２と間のすべての通信は、（ＨＴＴＰプロトコルにより予見されるように）クライアントのウェブ・ブラウザにより駆動される。

２つのサーブレット８、１０間の協働、およびサーブレットが、クライアントのウェブ-ブラウザ３を、その応答文書をチャンクしてＪａｖａＳｃｒｉｐｔコマンドをその中に埋め込むことによって遠隔制御できるという事実のみが、サーバとクライアントのウェブ・ブラウザとの間の双方向通信を可能にする。

以下、簡単な例が、本発明がどのように実際的に作動するかを示す（図３参照）。

クライアントのウェブ・ブラウザ３から要求を受信し、その要求を送ったクライアントのウェブ・ブラウザ３のいくつかの特性に依存するやり方でいくらかのコンテンツを生成するメイン・サーブレット８があることが仮定されている。メイン・サーブレット８が、要求を送ったクライアントのウェブ・ブラウザ・ウインドウの幅を知る必要があること、およびこの情報が、メイン・サーブレット８に送られた当初の要求に含まれていなかったことがさらに仮定されている。

クライアントのウェブ・ブラウザ・ウインドウの幅は、ＪａｖａＳｃｒｉｐｔ表現「window.outerWidth」をクライアントのウェブ・ブラウザ３において実行することにより容易に尋ねることができる特性である。

この例についてのメイン・サーブレット８およびセカンダリ・サーブレット１０のコード・ソースは、本明細書末尾の付録中にある。セカンダリ・サーブレットがメイン・サーブレットのロジックから独立しており、異なるロジックを実装するいくつかの「メイン」サーブレットにより再利用または共有され得ることに留意されたい。

メイン・サーブレットへの要求がまだ走っている一方で、この第２の要求の結果が、クライアントのウェブ・ブラウザにより表示される現在の文書に取って代わらないことおよび第１の要求を中断しないことに留意しることが重要である。これは、第２の要求の結果を別個のフレームに、またはページの特定の要素（画像、埋め込まれたフレーム）にリダイレクトすることにより、あるいはＨＴＴＰ要求をプログラム的に開くＪａｖａＳｃｒｉｐｔ ＡＰＩを用いることによって達成できる。

セカンダリ・サーブレット１０は、そのパラメータ中に鍵／値ペアをセッション（または第１のサーブレットと共有されたメモリ）中に格納すべき情報と共に含む要求を受信する。次にセカンダリ・サーブレット１０は、ウェブ・ブラウザ３に成功コードを返す。ウェブ・ブラウザ３は、セカンダリ・サーブレット１０の応答を無視できる。

メイン・サーブレット８は、セッション（共有メモリ）中で、メイン・サーブレット８が生成した鍵のために値が格納されたことを検出する。メイン・サーブレット８は、この値（要求を処理するために欠落していた情報）を抽出し、その値をセッション／共有メモリから取り去り、要求の処理を再開する。

処理が継続し、応答文書の残りが生成される。後に要求の処理の間にいっそう多くの情報が欠落していることが明らかになれば、ユーザにより多くの情報を連続的に要求するために最後のステップを繰り返すことができる。

最後に、要求は完結され、クライアントのウェブ・ブラウザ３は、完全な応答文書を受信して表示する。

図３は、本発明によるこの例におけるクライアントのウェブ・ブラウザと２つのサーブレットとの間で行われるアクティビティおよび通信を説明している。

（１） クライアントのウェブ・ブラウザは、ＨＴＴＰ ＧＥＴコマンド（代案：ＰＯＳＴコマンドも用い得るであろう）を送ることにより当初の要求をメイン・サーブレット８に送って、メイン・サーブレット８にＵＲＬを要求する。この要求は、応答文書の生成の間にメイン・サーブレット８により用いられ得る付加的なパラメータも含み得るであろう。この例では、パラメータが皆無である。

（２） メイン・サーブレット８は、欠落情報（クライアントのウェブ・ブラウザの幅）を必要とするまで、文書の冒頭を書くことにより応答文書の生成を開始する。
<html>
<head>
</head>
<body>

欠落情報が要求される間にサーブレットにより作成されたコンテンツ<p>。

この時点で、文書の残りを書くために、メイン・サーブレット８は、欠落情報を必要とする。メイン・サーブレット８は一意の鍵を生成し、この鍵は、クライアントのウェブ・ブラウザがこの鍵をセカンダリ・サーブレット１０に送った後、ＨＴＴＰセッション中で欠落値を格納および見出すために用いられ、メイン・サーブレット８は、これまでに生成されたコンテンツにＪａｖａＳｃｒｉｐｔを追加し、このＪａｖａＳｃｒｉｐｔは、クライアントのウェブ・ブラウザによって実行された時に、値を取得し、その値を鍵と共にセカンダリ・サーブレット１０に送る。

ここで、この例においてスクリプトがどのように見えるかを説明する：
ライン２がウェブ・ブラウザ３の幅を取得し、以下のラインは、ウェブ・ブラウザ３にセカンダリ・サーブレット１０へのＨＴＴＰ要求を開かせ、パラメータとして鍵（ここでは、鍵の無作為値はkey_112108である）および取得された値（ここで、変数”value”に含まえる）を渡す。
<scriptlanguage="JavaScript">
var value = window.outerWidth;
var httpReq = new XMLHttpRequest();
httpReq.open("GET","SecondaryServlet?key=key_112108&value="+value,true);
httpReq.send(null);
</script>

（３） 部分的文書（これまでに生成されたコンテンツおよび欠落値を取得したスクリプト）は、メイン・サーブレット８のバッファをフラッシュすることにより、クライアントのウェブ・ブラウザ３に送られる。これを行う時には、アプリケーション・サーバは、ＨＴＴＰ応答の符号化を「チャンク（chunked）」に変更し、これは、クライアントのウェブ・ブラウザ３に、コンテンツがいくつかのチャンクされた断片で転送さえることを示す。図２は、この時点でクライアントのウェブ・ブラウザに転送された文書のコンテンツを示す。

（４） メイン・サーブレット８は、ステップ（２）においてそれが生成した鍵の下で格納された値をＨＴＴＰセッション中で見出すまでその実行を一時停止する。技術的には、メイン・サーブレット８は、その実行を一時停止し、値が利用可能であるかどうかを規則的な間隔でチェックする。ひとたび値が見出されると、メイン・サーブレット８は、その実行を再開する。

（５） その間、クライアントのウェブ・ブラウザ３は、メイン・サーブレット８により送られた文書の第１のチャンクを受け取っている。クライアントのウェブ・ブラウザ３は、これまでの文書に含まれている表示可能なコンテンツを表示し、それに埋め込まれたＪａｖａＳｃｒｉｐｔを実行する。ＪａｖａＳｃｒｉｐｔが文書のコンテンツに全く影響しないことに留意されたい。

（６） ＪａｖａＳｃｒｉｐｔを実行する時に、クライアントのウェブ・ブラウザ３はそのウインドウの幅（ここでは４５４画素）を取得し、ＨＴＴＰ ＧＥＴ要求をセカンダリ・サーブレット１０に送る。（代わりに、ＰＯＳＴ要求も用いられ得る）。この要求は、パラメータとして、前に生成された鍵（key_112108）および取得された値（４５４）を含んでいる。
GET SecondaryServlet?key=key_112108&value=454

（７） セカンダリ・サーブレット１０は、この要求を受信し、鍵および値をそのパラメータから復号し、ＨＴＴＰセッション中で、値（４５４）を鍵（key_112108）の下に置く。次に、セカンダリ・サーブレット１０は、成功コード（ＨＴＴＰコード２００）を直ちに返す（８）。

（８） 鍵“key_112108”の下に格納された値について規則的間隔でＨＴＴＰセッションをチェックしたメイン・サーブレット８は、この値を見出す。メイン・サーブレット８は、この値をセッションから取り去り、取得した値を用いて文書の生成を再開する。（この例では、値はテキスト中に単純に書き込まれる。より複雑な例では、値は、文書のより複雑なレイアウトを行うために用い得るであろう。）
クライアントのウェブ・ブラウザ３に送られた文書の第２のチャンク部分が：
ページの生成を終了する：Width=454
</body>
</html>

（９） 文書の第２のチャンク部分は、クライアントのウェブ・ブラウザに送られ、メイン・サーブレット８は、クライアントのウェブ・ブラウザ３との通信チャネルを閉じ、もはやコンテンツが追従しないことを示す。

（１０） クライアントのウェブ・ブラウザ３は、文書の残りを表示する。

より詳細な実行図については、図１を参照されたい。

この例の完全なソース・コードについては、本明細書の末尾の付録を参照されたい。

本発明の双方向通信パスを示す。 本発明の双方向通信パスの好ましい実施形態を実装したクライアント−サーバ・アーキテクチャを示す。 所与の例におけるクライアントのウェブ・ブラウザ、メイン・サーブレットおよびセカンダリ・サーブレット間の通信ステップを説明するシーケンス図を示す。 付録：ソース１：メイン・サーブレットimport java.io.*;import javax.Servlet.*;import javax.Servlet.http.*;public class MainServlet extendsHttpServlet implements Servlet {/*** 要求された鍵／値ペアをＨＴＴＰセッション中に格納するセカンダリ・サーブレットのＵＲＬ*/private final static StringSECONDARY_SERVLET_URL = "SecondaryServlet";/** @seejavax.Servlet.http.HttpServlet#void(javax.Servlet.http.HttpServletRequest,javax.Servlet.http.HttpServletResponse)*/public void doGet(HttpServletRequest req,HttpServletResponse resp)throws ServletException, lOException {resp.setContentType("text/html; charset=ISO-8859-4");HttpSession session = req.getSession();PrintWriter out = resp.getWriter();out.println("<html>");out.println("<head>");out.println("</head>");out.println ("<body>");// 応答の生成を開始out.println("欠落情報が要求される間にサーブレットにより作成されたコンテンツ<p>");// (…)// 応答の処理中のある時点で、サーブレットは、ある情報が欠落していることに気付き、応答の生成を一次停止する。//欠落値を取得しそれをセカンダリ・サーブレットを介してサーバに送るようクライアントのウェブ・ブラウザに求める//第３のパラメータは、ブラウザ中で実行された時に値を取得するJavaScript表現である//この例では、クライアントのウェブ・ブラウザにブラウザ・ウインドウの幅を尋ねるObject value =requestValue(req,resp,"window.outerWidth;");//このメソッドが戻ると、ローカル変数"value"は、要求された値を含む//応答の生成を続ける// (...)out.println("Finish the generation of the page: Width=" +value);out.println("</body>");out.println("</html>");}/*** 欠落値をウェブ・セッション中に格納するために用い得る一意の鍵を生成する*/private String generateKey() {return "key_" +System.currentTimeMillis();}//**** クライアントのウェブ・ブラウザに、欠落値をサーブレットに提供するよう要請する。* このメソッドは、クライアントのウェブ・ブラウザにより解釈されるJavaScriptを生成し伝送するこのJavaScriptは、パラメータとして与えられたJavaScript表現を実行することにより欠落値を取得し、要求をセカンダリ・サーブレットに送り、このセカンダリ・サーブレットは、欠落値をＨＴＴＰセッション中に格納し、その結果、その値にメイン・サーブレットがアクセスできる。* このメソッドは、クライアントのウェブ・ブラウザにより欠落値が返されるまで、メイン・サーブレットをブロックおよび一時停止することに留意されたい。** @param res クライアントのウェブ・ブラウザによりこのメイン・サーブレットに返されたメインＨＴＴＰ応答* @param resp 要求に応答するためにこのサーブレットにより用いられたＨＴＴＰ応答* @param JavaScriptExpression クライアントのウェブ・ブラウザにおいて実行された時に、このサーブレットが必要とする欠落情報を返すJavaScript表現* @return クライアントのウェブ・ブラウザにより返された欠落値*/private Object requestValue (HttpServletRequest req,HttpServletResponse resp,String JavaScriptExpression)throws IOException {PrintWriter out = resp.getWnter();HttpSession session = req. getSession();//欠落値を絵現在のＨＴＴＰセッション中に格納／取得するために用い得る一意の鍵を生成するString key = generateKey();// クライアントのウェブ・ブラウザから情報を取得するJavaScriptの生成を開始するout.println(" <scriptlanguage=\"JavaScript\">");// この例では、クライアントのウェブ・ブラウザは、欠落値を入力するようユーザに促すout.println("var value = " +JavaScriptExpression + ";");// ひとたび値が取得されJavaScript変数としてクライアント側で格納されると、この値をセカンダリ・サーブレットを介してサーバに伝送する// クライアントのウェブ・ブラウザにセカンダリ・サーブレットへのＨＴＴＰ要求を開かせ、欠落情報の鍵および値を渡すout.println("var httpReq = newXMLHttpRequest();");out.println("httpReq.open (\"GET\",\""+ SECONDARY_SERVLET_URL+ "?key="+ key+ "&value=\"+value,true);");out.println("httpReq.send(null);");out.pnntln("</sc[pi]pt>");//欠落値を取得するJavaScriptが伝送され、クライアントのウェブ・ブラウザにより直ちに実行されるように、サーブレットのバッファをフラッシュする。resp.flushBuffer();// 前に定義された鍵の下でＨＴＴＰセッション中の値が見出されるまで、メイン・サーブレットの実行を一時停止するObject value = session.getAttribute(key);while (value == null) {try { Thread.sleep(100);} catch (InterruptedException e) { e.printStackTrace();}value = session.getAttribute(key);}// 今や値は抽出され、メモリ・リークを回避しその同じ鍵が数度にわたり再履よできるように、その鍵／値ペアをセッションから取り去るsession.removeAttribute(key);return value;}}ソース２：セカンダリ・サーブレットimport java.io.*;import javax.servlet.*;import javax.servlet.http.*;/*** セカンダリ・サーブレットは、ＨＴＴＰセッションを鍵／値ペアで更新する。* 格納すべき鍵／値ペアは、到来する要求中で、鍵”key”および”value”の下で含まれる。* 例えば、パラメータ"mySecondaryServletURL?key=myKey&value=myValue"を含む要求は、値"myValue"を、鍵"myKey"の下でＨＴＴＰセッション中に格納する。*/public class SecondaryServlet extendsHttpServlet implements Servlet {/*** @see javax. servlet.http.HttpServlet#void(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse)*/public void doGet(HttpServletRequest req,HttpServletResponse resp)throws ServletException, IOException {// ブラウザから到来する要求から、ＨＴＴＰセッション中に格納すべき鍵／値ペアを抽出するString key = req.getParameter("key");String value = req.getParameter("value");if (key ! = null) { // この鍵／値ペアをＨＴＴＰセッション中に格納する req.getSession().setAttribute(key,value); }}]

Claims (13)

1. クライアント−サーブレット通信の方法であって、前記サーブレットを実装するサーバが、
   前記クライアントのウェブ・ブラウザにより送られた当初の要求に含まれない欠落している情報を、第１のサーブレットにより識別するステップであって、前記当初の要求は当該要求に対する所望の情報を前記サーバから取得することを要求し、及び前記欠落している情報は前記サーバ上で前記当初の要求を扱うために必要なパラメータであるが欠落してしまった情報である、前記識別するステップと、
   前記欠落している情報を第１のサーブレットにより識別した場合において、前記クライアントのウェブ・ブラウザにより送られた当初の要求を運ぶ第１の通信パスとは別の第２の通信パスを前記ウェブ・ブラウザ要求を発行したクライアントのウェブ・ブラウザと前記第１のサーブレットとの間で開くステップであって、前記第２の通信パスは、前記クライアントのウェブ・ブラウザにより送られた新しい要求を第２のサーブレットに運ぶ通信パスである、前記開くステップと、
   スクリプトを前記第１のサーブレットにより生成するステップであって、前記スクリプトは前記クライアントのウェブ・ブラウザ上で実行される場合に、前記欠落している情報を取得しかつ第２のサーブレットを呼び出す、前記生成するステップと、
   前記生成されたスクリプトを、前記当初の要求に対する部分的応答に追加するステップであって、当該部分的応答は、前記所望の情報のうち、前記当初の要求を処理して得られる一部の情報を含む、前記追加するステップと、
   前記スクリプトが追加された前記部分的応答を前記クライアントのウェブ・ブラウザに送るステップであって、前記一部の情報は前記クライアントのウェブ・ブラウザ上で表示され、及び前記欠落していたが当該クライアントにより補われた情報が前記クライアントのウェブ・ブラウザ上で実行される前記スクリプトにより作成された新たな要求中に含まれる、前記送るステップと、
   前記欠落している情報が入手可能になるまで前記第１のサーブレットによる前記当初の要求の処理の実行を一時停止するステップと、
   前記補われた情報を前記第２のサーブレットで受信するステップと、
   前記第２のサーブレットで受信した前記補われた情報を前記第１のサーブレットに提供するステップと、
   前記提供された前記補われた情報を用いて前記第１のサーブレットによる前記当初の要求の処理の実行を継続し、当該継続した結果として得られる情報を含む応答を前記クライアントのウェブ・ブラウザに提供するステップであって、前記継続した結果として得られる情報は前記一部の情報とともに前記クライアントのウェブ・ブラウザ上でさらに表示される、前記提供するステップと
   を実行することを含む、前記方法。
2. クライアント−サーブレット通信の前記方法が既存の通信プロトコルおよびクライアントを変更することなく前記クライアント−サーブレット通信を改善する方法であり、
   前記通信プロトコルは、（１）情報を第１のサーブレットから取得するためにクライアントによる要求を開始する通信パスによって、及び（２）前記要求の成功または失敗を示す戻り符号を少なくとも含み且つ入手可能である場合に前記要求により要求された情報を含む応答を、前記第１のサーブレットにより送ることによって特徴付けられており、
   前記サーバが、
   前記補われた情報を受信することに応じて前記成功を示す戻り符号を前記クライアントの前記ウェブ・ブラウザに、前記第２のサーブレットにより返すステップを実行することをさらに含む、
   請求項１に記載の方法。
3. 前記当初の要求及び前記新たな要求がＨＴＴＰ要求であり、前記スクリプトにより作成された新たな要求がＨＴＴＰ要求であり、当該ＨＴＴＰ要求を前記第２のサーブレットにより受信し、前記第１及び前記第２のサーブレットにより用いられる共有メモリ中に前記補われた情報を格納する、請求項１又は２に記載の方法。
4. 前記補われた情報が、前記クライアントと前記サーバとの間の現在のＨＴＴＰセッション・オブジェク中に前記２のサーブレットにより格納され、前記第１のサーブレットに渡される、請求項１〜３のいずれか一項に記載の方法。
5. 前記第２のサーブレットが前記第１のサーブレットの一部として実装されており、前記新しいＨＴＴＰ要求の受信が前記第２のサーブレットの代わりに前記第１のサーブレットにより受信することに応じて、前記第１のサーブレットの第２のインスタンスを自動的に開始し、前記補われた情報によって現在のＨＴＴＰセッション・オブジェクトを更新する、請求項１〜４のいずれか一項に記載の方法。
6. 前記ウェブ・ブラウザによる前記スクリプトの実行が、前記欠落している情報を自動的に取得または付加的なユーザ入力により前記欠落情報を取得する、請求項１〜５のいずれか一項に記載の方法。
7. 前記第１及び前記第２のサーブレットが、Ｊａｖａ（登録商標）サーブレットとして実装される、請求項１〜６のいずれか一項に記載の方法。
8. 前記スクリプトが、Ｊａｖａ（登録商標）スクリプトとして実装される、請求項１〜７のいずれか一項に記載の方法。
9. 前記スクリプトが、前記欠落している情報に関連付けられた値を前記第１のサーブレットにより生成された割り当てられた鍵と共に含む、請求項１〜８のいずれか一項に記載の方法。
10. 請求項１〜９のいずれか一項に記載の方法の各ステップをサーバに実行させるコンピュータ・プログラム。
11. 少なくとも１つのサーブレットを実装するクライアント−サーバ・アーキテクチャにおけるサーバであって、
    前記クライアントのウェブ・ブラウザにより送られた当初の要求に含まれない欠落している情報を、第１のサーブレットにより識別する手段であって、前記当初の要求は当該要求に対する所望の情報を前記サーバから取得することを要求し、及び前記欠落している情報は前記サーバ上で前記当初の要求を扱うために必要なパラメータであるが欠落してしまった情報である、前記識別する手段と、
    前記欠落している情報を第１のサーブレットにより識別した場合において、前記クライアントのウェブ・ブラウザにより送られた当初の要求を運ぶ第１の通信パスとは別の第２の通信パスを前記ウェブ・ブラウザ要求を発行したクライアントのウェブ・ブラウザと前記第１のサーブレットとの間で開く手段であって、前記第２の通信パスは、前記クライアントのウェブ・ブラウザにより送られた新しい要求を第２のサーブレットに運ぶ通信パスである、前記開く手段を実行する手段と、
    前記識別する手段が欠落情報を識別した場合、スクリプトを前記第１のサーブレットにより生成する手段であって、前記スクリプトは前記クライアントのウェブ・ブラウザ上で実行される場合に、前記欠落している情報を取得しかつ第２のサーブレットを呼び出す、前記生成する手段と、
    前記生成されたスクリプトを、前記当初の要求に対する部分的応答に追加する手段であって、当該部分的応答は、前記所望の情報のうち、前記当初の要求を処理して得られる一部の情報を含む、前記追加する手段と、
    前記スクリプトが追加された前記部分的応答を前記クライアントのウェブ・ブラウザに送る手段であって、前記一部の情報は前記クライアントのウェブ・ブラウザ上で表示され、及び前記欠落していたが当該クライアントにより補われた情報が前記クライアントのウェブ・ブラウザ上で実行される前記スクリプトにより作成された新たな要求中に含まれる、前記送る手段と、
    前記欠落している情報が入手可能になるまで前記第１のサーブレットによる前記当初の要求の処理の実行を一時停止する手段と、
    前記補われた情報を前記第２のサーブレットで受信する手段と、
    前記第２のサーブレットで受信した前記補われた情報を前記第１のサーブレットに提供する手段と、
    前記提供された前記補われた情報を用いて前記第１のサーブレットによる前記当初の要求の処理の実行を継続し、当該継続した結果として得られる情報を含む応答を前記クライアントのウェブ・ブラウザに提供する手段であって、前記継続した結果として得られる情報は前記一部の情報とともに前記クライアントのウェブ・ブラウザ上でさらに表示される、前記提供する手段と
    を備えている、前記サーバ。
12. 前記クライアント−サーバ・アーキテクチャが通信プロトコルを用い、前記通信プロトコルは、（１）情報を第１のサーブレットから取得するためにクライアントによる要求を開始する通信パスによって、及び（２）前記要求の成功または失敗を示す戻り符号を少なくとも含み且つ入手可能である場合に前記要求により要求された情報を含む応答を、前記第１のサーブレットにより送ることによって特徴付けられており、
    前記サーバが、
    前記補われた情報を受信することに応じて前記成功を示す戻り符号を前記クライアントの前記ウェブ・ブラウザに、前記第２のサーブレットにより返す手段を備えている、請求項１１に記載のサーバ。
13. 前記当初の要求及び前記新たな要求がＨＴＴＰ要求であり、前記スクリプトにより作成された新たな要求がＨＴＴＰ要求であり、当該ＨＴＴＰ要求を前記第２のサーブレットにより受信し、前記第１及び前記第２のサーブレットにより用いられる共有メモリ中に前記補われた情報を格納する、請求項１１又は１２に記載のサーバ。

Images