(57)【要約】【課題】既存の通信プロトコルを変更することなくクライアント−サーブレット通信を改善する方法を提供する。【解決手段】もし当初の要求が、所望の情報を取得するためのすべての情報を含んでいれば、クライアントとサーブレットとの間の既存の従来技術の一方向通信パスは不変のままである。しかしながら、所望の情報を取り出すための当初のクライアントのウェブ・ブラウザ要求中に含まれない欠落情報をサーブレットが識別する場合、サーブレットは、前記当初のＨＴＴＰ要求のＨＴＴＰ応答機能を利用することにより欠落情報をサーブレットに提供するために別の通信パスを自動的に開き、この別の通信パスは、さらなるサーブレット機能コンポーネントによりサポートされる。【選択図】図１
2009508197.tif 000002
【特許請求の範囲】
【請求項１】
既存の通信プロトコルおよびクライアントを変更することなくクライアント（１）−サーブレット（２）通信を改善する方法であって、前記通信プロトコルは、情報を前記サーブレット（８）から取得するためにクライアント（１）による要求を開始する一方向通信、および少なくとも前記要求の成功または失敗を明示する戻り符号を含み、かつ利用可能であれば前記要求の結果を含む応答を前記サーブレット（８）により送ることを特徴としており、前記サーバ側において、前記方法は、
所望の情報を取得するための当初のクライアントのウェブ・ブラウザ要求に含まれない欠落情報を前記サーブレット（８）が識別する場合、
前記当初の要求の応答機能を利用して前記欠落情報を前記サーブレット（８）に提供するために前記サーブレット（８）から前記クライアントのウェブ・ブラウザを介して前記サーブレット（８）への別の通信パスを自動的に開き、
前記別の通信パスが、さらなるサーブレット機能コンポーネント（１）によってサポートされていることを特徴とし、さらに、
前記クライアントのウェブ・ブラウザにおいて実行された場合に前記欠落情報を取得しかつ前記さらなるサーブレット機能コンポーネント（１０）を呼び出すスクリプトを前記サーブレット（８）により生成するステップと、
前記スクリプト（１２）を、該スクリプトが部分的応答であると示している前記応答に追加するステップと、
前記スクリプト（１２）を含む前記応答を前記クライアントのウェブ・ブラウザに送るステップと、
前記欠落情報が利用可能になるまで前記サーブレット（８）による前記当初の応答の実行を一時停止するステップと、
前記さらなるサーブレット機能コンポーネント（１０）により前記欠落情報を受信するステップであって、前記欠落情報が、前記クライアントのウェブ・ブラウザにおけるその実行の間に前記スクリプト（１２）により作成された新たな要求中に含まれるステップと、
前記欠落情報を前記サーブレット（８）に提供するステップと、
前記応答の残りを取得し前記応答の残りを表示用に前記クライアントのウェブ・ブラウザに提供するために前記欠落情報を用いて前記サーブレットによる前記当初の応答の実行を継続するステップと、
を特徴とする、方法。
【請求項２】
前記通信プロトコルが、ＨＴＴＰプロトコルである、請求項１に記載の方法。
【請求項３】
前記さらなるサーブレット機能性コンポーネント（１０）が、別個のセカンダリ・サーブレットとして実装される、請求項１または２に記載の方法。
【請求項４】
前記セカンダリ・サーブレット（１０）が、前記スクリプト（１２）によって送られた前記新しいＨＴＴＰ要求を受信し、両方のサーブレット（８，１０）により用いられる共有メモリ中に前記欠落情報を格納する、請求項３に記載の方法。
【請求項５】
前記欠落情報が、前記セカンダリ・サーブレット（１０）により、前記クライアント（１）と前記サーバ（２）との間の前記現在のＨＴＴＰセッション・オブジェク中に格納され、前記サーブレットに渡される、請求項３に記載の方法。
【請求項６】
前記さらなるサーブレット機能性コンポーネント（１０）が前記サーブレット（８）の一部であり、前記サーブレットによる前記新しいＨＴＴＰ要求の受信が、前記サーブレットの第２のインスタンスを自動的に開始し、前記欠落情報によって前記現在のＨＴＴＰセッション・オブジェクトを更新する、請求項１または２に記載の方法。
【請求項７】
前記ウェブ・ブラウザによる前記スクリプト（１２）の実行が、前記欠落情報を自動的に取得または付加的なユーザ入力により前記欠落情報を取得する、請求項１または２に記載の方法。
【請求項８】
前記サーブレット（８）が、Ｊａｖａサーブレットとして実装される、請求項１または２サに記載の方法。
【請求項９】
前記スクリプト（１２）が、Ｊａｖａスクリプトとして実装される、請求項１または２に記載の方法。
【請求項１０】
前記スクリプト（１２）が、前記欠落情報（値）を、前記サーブレットにより生成された割り当てられた鍵と共に（鍵／値ペア）含む、請求項１または２に記載の方法。
【請求項１１】
請求項１〜９に記載の方法を用いるクライアント−サーバ・アーキテクチャ中のサーバ。
【請求項１２】
少なくとも１つのサーブレット（８）を有するクライアント−サーバ・アーキテクチャにおけるサーバ（１）であって、前記クライアント−サーバ・アーキテクチャが通信プロトコルを用い、該通信プロトコルは、情報を前記サーブレット（８）から取得するために前記クライアントのウェブ・ブラウザ（３）による要求を開始する一方向通信、および少なくとも前記要求の成功または失敗を明示する戻り符号を含み、かつ利用可能であれば前記要求の結果を含む応答を前記サーブレットにより送ることを特徴としており、サーバ側は、
ａ）  前記当初の要求に含まれない、完全な応答を提供するための欠落情報を識別するための手段（８）と、
ｂ）  前記手段ａ）が欠落情報を識別した場合、前記当初の要求の前記応答機能を利用して前記欠落情報を前記サーブレットに提供するために前記サーブレットから前記クライアントのウェブ・ブラウザを介して前記サーブレットへの別の通信パスを自動的に開くための手段（８）と、を特徴としており、前記通信手段がさらなる手段：、
ｃ）  前記クライアントのウェブ・ブラウザにおいて実行された場合に前記欠落情報を取得しかつ前記さらなるサーブレット機能コンポーネントを呼び出すスクリプトを前記サーブレットにより生成するための手段（８）と、
ｄ）  前記スクリプトを、該スクリプトが部分的応答であると示している前記応答に追加するための手段（８）と、
ｅ）  前記スクリプトを含む前記応答を前記クライアントのウェブ・ブラウザに送るための手段（８）と、
ｆ）  前記欠落情報が利用可能になるまで前記サーブレットによる前記当初の応答の実行を一時停止するための手段（８）と、
ｇ）  前記欠落情報を受信するための手段（１０）であって、前記欠落情報が、前記クライアントのウェブ・ブラウザにおけるその実行の間に前記スクリプト（１２）により作成された新たな要求中に含まれる、手段（１０）と、
ｈ）  前記欠落情報を前記サーブレット（８）に提供するための手段（１０）と、
ｉ）  前記応答の残りを取得し前記応答の残りを表示用に前記クライアントのウェブ・ブラウザに提供するために前記欠落情報を用いて前記サーブレットによる前記当初の応答の実行を継続するための手段（８）と、
を特徴とする、サーバ。
【請求項１３】
前記通信プロトコルが、ＨＴＴＰである、請求項１２に記載のシステム。
【請求項１４】
前記手段ａ）〜ｆ）、ｈ）が前記サーブレット中に実装され、前記手段ｇ）〜ｉ）がさらなる別個のサーブレット中に実装される、請求項１２または１３に記載のシステム。
【請求項１５】
前記手段ａ）〜ｉ）が、単一のサーブレット中に実装される、請求項１２または１３に記載のシステム。
【請求項１６】
請求項１〜９に記載の方法を実行するためのコンピュータ実行可能命令を含む、コンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント−サーバ通信に関し、特に、既存の通信プロトコルを変更することなくまたクライアントを変更することなく、ワールド・ワイド・ウェブ（ウェブ）におけるクライアント−サーブレット通信（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); }}]
【図１】
2009508197.tif 000003
【図２】
2009508197.tif 000004
【図３】
2009508197.tif 000005
2009508197.tif 000006
2009508197.tif 000007
【国際調査報告】
2009508197.tif 000008
2009508197.tif 000009
2009508197.tif 000010