JP5315062B2 - セッションを管理するウェブサーバおよびその方法 - Google Patents

Description

本発明は、ウェブサーバに関する。特に、本発明は、セッションを管理するウェブサーバおよびその方法に関する。

近年の多様なウェブページを実現するために、ウェブサーバにはセッション管理の機能が搭載されている。この機能によれば、利用者は単に要求したウェブページを閲覧することのみならず、自己の専用のページにログインして、以前にアクセスした履歴を参照したり、その履歴に基づいて次の作業を行うことができる。セッション管理は、ウェブサーバによる処理の経過を示すセッションステートを利用者毎に保存することにより実現される。たとえば、ＪａｖａＥＥ（Ｊａｖａ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ、Ｊａｖａは登録商標である）において、セッションステートは、ウェブサーバの記憶装置に記憶され、ウェブサーバ上で動作するサーブレット・プログラムからＨＴＴＰセッションオブジェクトとして参照される。

特開２００４−２０６６９５号公報 DB2 Alphabloxの概要、ホームページＵＲＬ「http://www-06.ibm.com/jp/software/data/bi/alphablox/」、２００７年１月１０日検索 Patterns of Enterprise Application Architecture、 Martin Fowler 著、アマゾンドットコム書籍紹介、ホームページＵＲＬ「http://www.amazon.com/exec/obidos/ASIN/0321127420」、２００７年１月１０日検索 WebSphere Application Server Version 5.1 InfoCenter、セッション管理サポートの説明、ホームページＵＲＬ「http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//topic/com.ibm.websphere.nd.doc/info/ae/ae/cprs_sesm.html」、２００７年１月１０日検索 Web 2.0 時代のDWH 環境！DB2 Alphablox で実現するInline Analyticの概要、ホームページＵＲＬ「http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/00825839」、２００７年１月１０日検索

ウェブサイトは規模が大きくなると、単一のウェブサーバでは処理能力が不十分なため、複数のウェブサーバにより実現される。この場合、順次受信するＨＴＴＰリクエストは各ウェブサーバに分配されて処理される。したがって、同一の利用者から受けた複数のＨＴＴＰリクエストがそれぞれ異なる複数のウェブサーバに到達する場合がある。この場合、セッションステートは以前のＨＴＴＰリクエストを受信したウェブサーバにのみ記憶されているので、次のＨＴＴＰリクエストに応じた処理においてそのセッションステートを参照できなくなってしまう。

これに対し、複数のウェブサーバでセッションステートを共有する機能が用いられている（非特許文献３を参照。）。しかしながら、この機能では、ウェブサーバ間で共有するべきセッションステートを効率的に選択することはできず、共有に必要な通信量や処理量が大きくなってしまう場合がある。また、この機能の適用範囲は限定されており、例えば非特許文献１のデータベースを採用したシステムには適用できない。一方、セッションステートをウェブサーバではなく端末装置のウェブブラウザにクッキーなどとして記憶することで、この課題を回避する技術が用いられている（非特許文献２および特許文献１を参照。）。

この技術において、端末装置に記憶されたセッションステートは、次のＨＴＴＰリクエストに対応付けてウェブサーバに送信される。そして、このセッションステートは、サーブレット・プログラムからは、ＨＴＴＰリクエストの付随的なパラメータとして参照される。しかしながら、ＨＴＴＰリクエストにはその他のパラメータが数多く設定されている場合があり、エンジニアがプログラムを参照してもどのパラメータがセッションステートかを判断しにくい。これは、サーブレット・プログラムの開発や保守の効率の低下を招くおそれがある。また、セッションステートにアクセスするためのインターフェイスもＨＴＴＰセッションオブジェクトとは全く異なるので、仕様変更によりセッションステートの保存先をウェブサーバから端末装置に変更するのも困難である。
非特許文献４については後に参照する。

そこで本発明は、上記の課題を解決することのできるウェブサーバ、システム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の一側面においては、端末装置から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するための記憶部と、セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置から受信する受信部と、前記記憶部のうち、受信した前記第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信した前記セッションステートを格納する格納部と、前記処理プログラムに含まれる、ＨＴＴＰセッションオブジェクトにアクセスする命令の実行に応じて、格納された前記セッションステートにアクセスするアクセス部と、前記処理プログラムに含まれる、第１のＨＴＴＰレスポンスを返信する命令の実行に応じて、前記記憶部から前記セッションステートを読み出して、第２のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定し、設定した前記第１のＨＴＴＰレスポンスを端末装置に返信する返信部とを備えるウェブサーバを提供する。また、当該ウェブサーバによりＨＴＴＰリクエストに応じて処理を行う方法、当該ウェブサーバとして情報処理装置を動作させるプログラム、および、当該ウェブサーバを複数備えたシステムを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明を実施するための最良の形態（以下、実施形態と称す）を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、第１の構成を採用したウェブサーバであるウェブサーバ５１０の機能の概要を示す。この構成において、セッションステートはウェブサーバ５１０に記憶されている。ＨＴＴＰリクエストに応じた動作は以下の通りである。まず、ウェブサーバ５１０は、ＨＴＴＰリクエストをセッションＩＤに対応付けて受信する。受信したセッションＩＤに対応するＨＴＴＰサーブレットリクエスト・オブジェクトが検索されて、ＨＴＴＰサーブレット５３０に与えられる。検索されたこのオブジェクトをＨＴＴＰサーブレットリクエスト・オブジェクト５２０とする。ここまでの動作は、たとえばＪａｖａＥＥ（Ｊａｖａ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）などに準拠したミドルウェアにより自動的に行われる。続いて、アプリケーションプログラムの開発者が作成したサーブレット・プログラムに基づいて、ＨＴＴＰサーブレット５３０が動作を開始する。

図中のプログラムコードの１行目に示すように、ＨＴＴＰサーブレット５３０を実現するサーブレット・プログラム上で、ＨＴＴＰサーブレットリクエスト・オブジェクトは「ｒｅｑ」という引数により参照される。４行目に示すように、この「ｒｅｑ」について、ｇｅｔＳｅｓｓｉｏｎというメソッドを呼び出せば、ＨＴＴＰサーブレットリクエスト・オブジェクトから、ＨＴＴＰセッションオブジェクトが読み出される。このオブジェクトが、セッションステートの実体である。セッションステートは、例えば図中に示したように、「ｋｅｙ１」などのキー名称と、その値である文字列"ａｂｃ"との組によって表される。サーブレット・プログラムからは「ｓｅｓｓｉｏｎ」という変数として参照される。

６行目に示すように、「ｓｅｓｓｉｏｎ」について、ｇｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトから値が読み出される。このサーブレット・プログラムにおいて、読み出された値は変数「ｖａｌｕｅ」に代入される。また、８行目に示すように、「ｓｅｓｓｉｏｎ」について、ｓｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトの値が更新される。このサーブレット・プログラムにおいて、キー「ｋｅｙ１」の値が"ａｂｃ"に更新される。ＨＴＴＰサーブレット５３０は、ＨＴＴＰレスポンスを返信する場合には、そのＨＴＴＰレスポンスに、ＨＴＴＰリクエストの受信時に受信したセッションＩＤを対応付けて送信する。

図１に示す第１の構成において、セッションステートの実体はウェブサーバ５１０に記憶されている。そして、リクエストに応じた処理において正しいセッションステートを参照できるようにするため、リクエストにはセッションＩＤが対応付けて送信される。このように、第１の構成においても、複数のリクエストに応じた一連の処理を関連付けてセッションとして管理することができる。しかしながら、ウェブサーバ５１０を含む複数のウェブサーバでウェブサイトを実現する場合には不都合が生じてしまう。即ち、例え正しいセッションＩＤが送信されたとしても、以前の処理を行ったウェブサーバとは異なるウェブサーバにリクエストが到達した場合には、以前の処理に基づくセッションステートを読み出せなくなってしまう。

これに対し、以下の図２に示す第２の構成では、セッションステートを端末装置側に設けることでこの課題の解決を図っている。
図２は、第２の構成を採用したウェブサーバであるウェブサーバ５４０の機能の概要を示す。この構成において、セッションステートは端末装置にクッキーなどとして記憶されている。ＨＴＴＰリクエストに応じた動作は以下の通りである。まず、ウェブサーバ５４０は、ＨＴＴＰリクエストをセッションステートに対応付けて受信する。ここで受信するのは、図１の場合とは異なり、セッションＩＤではなくセッションステートの実体である。セッションステートは、ＨＴＴＰリクエストに設定された他のパラメータに追加されて設定される。当該他のパラメータとは、ウェブサイトに対する要求の属性を示し、例えばウェブサイトが物販用であれば購入する商品のＩＤ・数量などである。即ちセッションステートはこのようなパラメータと共にＨＴＴＰリクエストに設定されて受信される。ここまでの動作は、例えば、ＪａｖａＥＥなどに準拠したミドルウェアにより自動的に行われる。続いて、サーブレット・プログラムに基づいてＨＴＴＰサーブレット５６０が動作を開始する。

図中のプログラムコードの１行目に示すように、ＨＴＴＰサーブレット５６０を実現するサーブレット・プログラム上で、ＨＴＴＰサーブレットリクエスト・オブジェクト５５０は「ｒｅｑ」という引数により参照される。このオブジェクトには、ＨＴＴＰリクエストに対応付けて受信した全てのパラメータが設定される。４行目に示すように、オブジェクトｒｅｑについて、パラメータのキー名を指定してｇｅｔＰａｒａｍｅｔｅｒというメソッドを呼び出せば、そのキー名により指定されるパラメータが読み出される。このプログラム例では、セッションステートを示すｋｅｙ２を指定しているので、セッションステートの値"ａｂｃ"が読み出されて、変数ｖａｌｕｅに代入される。また、６行目に示すように、このオブジェクトｒｅｑについてｓｅｔＰａｒａｍｅｔｅｒというメソッドを呼び出せば、指定したキーに指定した値が代入される。また、９−１０行目に示すように、ＨＴＴＰレスポンスとして返信するウェブページの中にセッションステートを埋め込めば、次のＨＴＴＰリクエストに対応付けてそのセッションステートを再度送信させることができる。

このように、第２の構成によっても、セッションステートを端末装置側に記憶しつつも、そのセッションステートをウェブサーバ側のサーブレット・プログラムから適切に参照することができる。しかしながら、この構成ではサーブレット・プログラムの開発・保守の効率において不都合が生じる場合がある。即ち、サーブレット・プログラムの文面上、セッションステートはＨＴＴＰリクエストのパラメータの一つとして参照される。そして、ＨＴＴＰリクエストには他に本来の要求に付随する様々な属性がパラメータとして設定され得る。これらの属性を示すパラメータと、セッションステートを示すパラメータとは、パラメータのキー名によってのみ区別される。したがって、プログラムの開発者や保守者は、セッションステートを示すパラメータのキー名を知らなければ、どのパラメータがセッションステートを示すのか判別するのは困難である。この不都合は、ウェブサイトが大規模になればなるほど、また、開発や保守に携わるエンジニアが増加すればするほど顕著になる。即ち、プログラムの文面を見ただけではセッションステートが明示されていないので、仕様書などの他の手段を用いて充分に情報を共有する必要がある。

このように、第１または第２の構成によっても、セッションステートを管理することはできるものの、近年の大規模かつ複雑なウェブサイトの構築には適切ではない場合がある。これに対し、図３から図９を参照して説明する構成によれば、セッションステートを端末装置側で管理しつつも、プログラムの開発・保守の効率を大幅に向上することができる。以下、具体的に説明する。

図３は、本実施形態に係る情報システム１０の全体構成を示す。情報システム１０は、ディスパッチャ装置１８と、ウェブサーバ２０−１〜Ｎとを備え、外部の端末装置１５から受けたＨＴＴＰリクエストに応じてＨＴＴＰレスポンスを返信することを目的とする。ディスパッチャ装置１８は、端末装置１５から受けたＨＴＴＰリクエストをウェブサーバ２０−１〜Ｎの何れかに選択的に割り当てる。具体的には、ディスパッチャ装置１８は端末装置１５から受信したＨＴＴＰリクエストを、例えばラウンドロビン方式などでウェブサーバ２０−１〜Ｎの中から選択したウェブサーバに転送する。ウェブサーバ２０−１〜Ｎのそれぞれは、ＨＴＴＰリクエストを受信すると、そのリクエストに応じて処理を行い、その処理結果に基づくＨＴＴＰレスポンスを生成して端末装置１５に返信する。

図４は、本実施形態に係るウェブサーバ２０−１の機能構成を示す。ウェブサーバ２０−１は、記憶部２００と、受信部２１０と、格納部２２０と、実行部２３０と、アクセス部２４０と、返信部２５０とを備える。まず、これらの各部材とハードウェア資源との関係を述べる。記憶部２００は、後述のＲＡＭ１０２０またはハードディスクドライブ１０４０などの記憶装置によって実現される。また、受信部２１０および返信部２５０は、後述の通信インターフェイス１０３０などのハードウェアデバイスと、ＪａｖａＥＥなどのミドルウェアを実行するＣＰＵ１０００との組み合わせにより実現される。また、格納部２２０および実行部２３０は、ＣＰＵ１０００により、そのミドルウェア上でサーブレット・プログラムを動作させることによって実現される。また、アクセス部２４０は、ＣＰＵ１０００を、ＪａｖａＥＥなどのミドルウェアと共にインストールされたクラスライブラリと呼ばれるプログラムを動作させることにより実現される。

記憶部２００は、端末装置１５から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するために設けられる。受信部２１０は、セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置１５から受信する。格納部２２０は、記憶部２００のうち、受信したこの第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信したセッションステートを格納する。格納部２２０は、例えば、フィルタクラスと呼ばれる、サーブレット・プログラムの動作開始時にその動作開始前に動作するオブジェクトにより実現される。即ち、格納部２２０は、後述の実行部２３０によりサーブレット・プログラムが動作を開始する前に動作を開始し、セッションステートを記憶部２００に格納する。

実行部２３０は、処理プログラムであるサーブレット・プログラムを実行する。この実行中に、ＨＴＴＰセッションオブジェクトにアクセスする命令が実行される場合がある。この命令は、ＨＴＴＰセッションオブジェクトにアクセスするメソッドを呼び出す命令であり、例えばＪａｖａＥＥではｇｅｔＳｅｓｓｉｏｎメソッドやｓｅｔＳｅｓｓｉｏｎメソッドなどに対する呼び出しである。このような呼び出しを受けて、アクセス部２４０は、記憶部２００に格納されたセッションステートにアクセスする。アクセスとは即ち読み出しや書き込みであり、これによりセッションステートは更新され得る。

また、サーブレット・プログラムの実行中に、第１のＨＴＴＰリクエストに対応する第１のＨＴＴＰレスポンスを返信する命令が実行される場合がある。この命令は、ＨＴＴＰレスポンスを示す出力ストリーム（たとえばＪａｖａＥＥのｏｕｔオブジェクトなど）について、ｐｒｉｎｔｌｎなどの文字列出力用のメソッドを呼び出す命令である。他の例として、この命令は、ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）などで記述されたウェブページそのものであってもよい。ＪＳＰのウェブページは、そのページの内容をＨＴＴＰリクエストとして返信する命令に変換されて実行されるからである。

このような命令の実行に応じて、返信部２５０は、記憶部２００からセッションステートを読み出す。読み出されるセッションステートは、たとえば、アクセス部２４０の機能によって受信時のものから変更されている場合がある。そして、返信部２５０は、読み出したこのセッションステートを、第２のＨＴＴＰリクエストに対応付けて端末装置１５により送信させるパラメータとしてこの第１のＨＴＴＰレスポンスに設定し、設定したこの第１のＨＴＴＰレスポンスを端末装置１５に返信する。このパラメータは、この第１のＨＴＴＰレスポンスを受け取った端末装置１５が表示するウェブページには表示されないパラメータであることが望ましい。また、このパラメータは、当該ウェブページに対する利用者の操作に応じて第２のＨＴＴＰリクエストに対応付けて送信されるパラメータであることが望ましい。ここでいう利用者の操作とは、例えば、"提出"ボタン、"ＯＫ"ボタン、または"次へ"ボタンなどを押下する操作である。これにより、第２のＨＴＴＰリクエストに対応付けて最新のセッションステートを送信させることができる。
ウェブサーバ２０−２〜Ｎのそれぞれの構成も以上に示したウェブサーバ２０−１と略同一であるから説明を省略する。

以上の構成により、セッションステートは、ウェブサーバ２０−１ではなく端末装置１５側で適切に管理することができる。これにより、端末装置１５からの第２のＨＴＴＰリクエストがウェブサーバ２０−１ではなくウェブサーバ２０−２に到達した場合であっても、ウェブサーバ２０−２は最新のセッションステートを適切に参照して、正常な処理を継続することができる。また、実行部２３０により実行されるサーブレット・プログラムからは、セッションステートがＨＴＴＰリクエストのパラメータとは区別されて、ＨＴＴＰセッションオブジェクトとして参照可能となる。これにより、ウェブサイトが大規模でサーブレット・プログラムが複雑な場合でも、エンジニアがプログラムを見ればセッションステートを明らかに認識できる。また、セッションステートはウェブページには表示されないので、ウェブサイトの利用者にとっても何ら違和感を与えないようにすることができる。

次に、ウェブサイトがＡｊａｘ（Ａｓｙｎｃｈｒｏｎｏｕｓ ＪａｖａＳｃｒｉｐｔ ＋ ＸＭＬ）を採用している場合の処理機能を説明する。この場合、利用者がウェブページ上のボタンを操作しなくても、利用者がマウスカーソルを動かす動作などに応じて、ウェブページに含まれるＪａｖａＳｃｒｉｐｔプログラムが、ＸＭＬＨＴＴＰ通信によるリクエストを自動的にウェブサーバ２０−１に送信する。この結果、アクセス部２４０は、上記第１のＨＴＴＰレスポンスを返信してから上記第２のＨＴＴＰリクエストを受信するまでの間に、ＸＭＬＨＴＴＰ通信によるリクエストに応じて、記憶部２００に格納されたセッションステートを更新する場合がある。

このような場合、更新後の最新のセッションステートは記憶部２００に記憶されているのにもかかわらず、次の第２のＨＴＴＰリクエストに対応付けてウェブサーバ２０−１に送信されるセッションステートは更新前の古いセッションステートとなる。この結果、格納部２２０の動作により、受信した古いセッションステートにより最新のセッションステートが上書きされ、セッションが正しく継続できなくなってしまう。このような不都合を避けるべく、ウェブサイトがＡｊａｘを採用している場合には、ウェブサーバ２０−１は、さらにリダイレクト処理部２６０を備えていることが望ましい。そして、返信部２５０は、第２のＨＴＴＰリクエストとしてリダイレクト処理を端末装置１５により要求させる第１のＨＴＴＰレスポンスを端末装置１５に返信する。

これを受けた端末装置１５は、利用者の操作を受けて、リダイレクト処理を要求する第２のＨＴＴＰリクエストをウェブサーバ２０−１に送信する。リダイレクト処理部２６０は、このリクエストを受信すると、セッションステートを記憶部２００から読み出す。そして、リダイレクト処理部２６０は、そのセッションステートを、次の第３のＨＴＴＰリクエストに対応付けて端末装置１５により送信させるパラメータとして、返信しようとしている第２のＨＴＴＰレスポンスに設定する。そしてリダイレクト処理部２６０は、設定したこの第２のＨＴＴＰレスポンスを返信する。これを受けた端末装置１５は、直ちに第３のＨＴＴＰリクエストを送信する。このリクエストは、ウェブサーバ２０−１〜Ｎの何れに到達するか分からない。しかしながら、この第３のＨＴＴＰリクエストには最新のセッションステートが対応付けられている。このため、第３のＨＴＴＰリクエストを受信すると、受信部２１０は、対応して受信したセッションステートを記憶部２００に格納することができる。
このように、リダイレクト処理部２６０を設けることで、Ａｊａｘを採用したウェブサイトにおいてもセッションを適切に維持することができる。

図５は、本実施形態に係るウェブサーバ２０−１が端末装置１５と通信する手順を示す。図５では、まず、Ａｊａｘを採用しないウェブサイトに関する処理について説明する。端末装置１５は、既に表示しているウェブページに対し利用者から操作を受けると、第１のＨＴＴＰリクエストをセッションステートに対応付けてウェブサーバ２０−１に対し送信する（Ｓ５００）。このセッションステートは、既に表示しているこのウェブページのデータの中で、次のＨＴＴＰリクエストに対応付けて送信するべきパラメータに設定されていたものである。これに対応して、受信部２１０は、第１のＨＴＴＰリクエストをセッションステートに対応付けて受信する（Ｓ５１０）。

次に、格納部２２０は、記憶部２００のうち、受信したこの第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信したこのセッションステートを格納する（Ｓ５２０）。セッションステートは上書きされてもよいし、追加されてもよい。即ち、格納部２２０は、既にこの記憶領域に記憶されているセッションステートに代えて、受信部２１０が新たに受信したこのセッションステートを格納してもよい。また、格納部２２０は、既にこの記憶領域に記憶されているセッションステートに追加して、受信部２１０が新たに受信したこのセッションステートを格納してもよい。

次に、実行部２３０は、処理プログラムであるサーブレット・プログラムの実行を開始する。この実行の過程で、ＨＴＴＰセッションオブジェクトにアクセスする命令が実行されると、これに応じて、アクセス部２４０は、記憶部２００に格納されたこのセッションステートにアクセスする（Ｓ５４０）。プログラムの処理内容に応じて、アクセスの回数は複数でもよい。また、サーブレット・プログラムの実行の過程で、第１のＨＴＴＰレスポンスを返信する命令が実行されると、これに応じて、返信部２５０は、記憶部２００からセッションステートを読み出す（Ｓ５５０）。そして、返信部２５０は、読み出したセッションステートに対し直列化処理（シリアライゼーション：Ｓｅｒｉａｌｉｚａｔｉｏｎ）を行う。

直列化処理とは、記憶部２００中のアドレス空間に記憶されたセッションステートなどのデータを、他のアドレス空間に再配置したり、通信回線を介して外部の装置に送信可能とする処理である。具体的には以下の通りである。記憶部２００は、セッションステートとして複数のデータを含むデータ群を記憶しており、これらのデータはリスト構造と呼ばれる構造により互いに関連付けられている場合がある。例えばこれらのデータのうち第１のデータは、この第１のデータの格納先アドレスにより第２のデータから参照されている。この場合、第１および第２のデータを読み出して他のアドレスに記録すると、第１のデータの格納先アドレスが変更される。この結果、実際の格納先アドレスと、第２のデータからの参照のための格納先アドレスが異なってしまう。

このため、返信部２５０は、第２のデータから第１のデータを当該第１のデータの格納先アドレスを用いずに参照するようにこれらのデータ群に対し変換を行う。一例として、データ群のデータ構造をリスト構造から配列構造に変換してもよいし、第２のデータから第１のデータの参照のために用いるデータを、格納先アドレスに代えてデータの識別子に変更してもよい。その他、文字列の文字コードの変換や数値情報の数値フォーマットの変換等の処理を直列化処理として行ってもよい。

これに加えて、返信部２５０は、直列化処理を行ったデータ群に対し、さらに、暗号化処理およびデータ圧縮処理の少なくとも一方を含む変換を行ってもよい。暗号化処理によれば、本来第三者に公開する必要の無いセッションステートを、端末装置１５の装置内や通信経路上で参照できなくすることができ、不正な盗聴行為を未然に防止できる。直列化およびデータ圧縮／暗号化されたセッションステートは第１のＨＴＴＰレスポンスに設定される。さらに他の処理として、返信部２５０は、読み出したセッションステートを記憶している記憶領域を他の用途に開放するための処理を行ってもよい。この処理は、サーブレット・プログラムの文面上の明示の処理ではなく、ガーベージ・コレクタによってサーブレット・プログラムとは非同期的に行われてよい。そして、返信部２５０は、この第１のＨＴＴＰレスポンスを端末装置１５に返信する（Ｓ５６０）。

端末装置１５は、第１のＨＴＴＰレスポンスを受信すると、そのレスポンスに含まれるウェブページを利用者に表示する（Ｓ５８０）。利用者がウェブページ上のボタンを操作すると、第２のＨＴＴＰリクエストが送信される（Ｓ５００）。この後の処理は、既にＳ５００からＳ５８０として説明した上記の処理と同様である。但し、この第２のＨＴＴＰリクエストはウェブサーバ２０−１に到達するとは限らず、ウェブサーバ２０−２〜Ｎの何れかに到達する場合がある。そのような場合でも、第２のＨＴＴＰリクエストには最新のセッションステートが対応付けられて送信されるので、リクエストを受けたウェブサーバは適切に処理を継続できる。

次に、図６および図７を参照して、ウェブサーバ２０−１の処理機能の実装例と、実施形態についてのさらに詳細なバリエーションについて説明する。
図６は、ウェブサーバ２０−１において動作するソフトウェアおよびデータの第１構成を示す概念図である。この第１構成は、セッションステートを全て端末装置１５に記憶し、ウェブサーバ２０−１においてはリクエストからレスポンスまでの僅かな期間にのみセッションステートを一時的に記憶する構成である。この構成によれば、セッションステートをウェブサーバ２０−１に記憶することを前提に予め開発されたサーブレット・プログラムを、ほとんど改変することなく、セッションステートを端末装置１５に記憶する状態で動作させることができる。以下、概要を述べる。

ウェブサーバ２０−１は、フィルタオブジェクト６００と、ＨＴＴＰサーブレットリクエスト・オブジェクト６１０と、ＨＴＴＰサーブレット６３０とを、例えばＪａｖａＥＥなどに準拠したミドルウェア上で動作させている。また、ウェブサーバ２０−１はレンダリングエンジン６２０を動作させている。フィルタオブジェクト６００は、例えばＪａｖａＥＥのフィルタクラスのオブジェクトであり、上述の格納部２２０として動作する。そして、フィルタオブジェクト６００は、受信部２１０がＨＴＴＰリクエストを受信すると動作を開始して、そのＨＴＴＰリクエストに対応して受信したセッションステートを記憶部２００に格納する。

セッションステートが記憶される記憶領域は、既に述べたように、サーブレット・プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる領域である。具体的には、フィルタオブジェクト６００は、ＨＴＴＰサーブレットリクエスト・オブジェクト（図中のＨＴＴＰサーブレットリクエスト・オブジェクト６１０である。）の１つのデータフィールドとして、ＨＴＴＰセッションオブジェクトの記憶領域を確保し、その記憶領域にセッションステートを格納してもよい。また、既にＨＴＴＰセッションオブジェクトの記憶領域が確保されている場合には、フィルタオブジェクト６００は、その記憶領域に既に記憶されたセッションステートを更新して、受信した新たなセッションステートを格納する。例えば、図６では、ｋｅｙ１およびｋｅ２という２つの文字列変数の双方が受信したセッションステートであり、リクエスト受信前から既に格納されていたセッションステートは破棄されている。

セッションステートの格納に応じて、実行部２３０は動作を開始して処理プログラムであるサーブレット・プログラム６３５を実行してＨＴＴＰサーブレット６３０として動作する。サーブレット・プログラム６３５の１行目に示すように、このプログラム上で、ＨＴＴＰサーブレットリクエスト・オブジェクトは「ｒｅｑ」という引数により参照される。４行目に示すように、この「ｒｅｑ」について、ｇｅｔＳｅｓｓｉｏｎというメソッドを呼び出せば、ＨＴＴＰサーブレットリクエスト・オブジェクトから、ＨＴＴＰセッションオブジェクトが読み出される。このオブジェクトは、サーブレット・プログラム６３５からは「ｓｅｓｓｉｏｎ」という変数として参照される。

６行目に示すように、「ｓｅｓｓｉｏｎ」について、ｇｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトから値が読み出される。読み出された値は変数「ｖａｌｕｅ１」に代入される。同様に、７行目に示すように、他のキー名を指定してｇｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトから他の値が読み出される。読み出された値は変数「ｖａｌｕｅ２」に代入される。

また、９行目に示すように、「ｓｅｓｓｉｏｎ」について、ｓｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトの値が更新される。この行では、キー「ｋｅｙ１」の値が"ａｂｃ"に更新される。同様に、１０行目に示すように、「ｓｅｓｓｉｏｎ」について、ｓｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、ＨＴＴＰセッションオブジェクトの値が更新される。この行では、キー「ｋｅｙ２」の値が"ＡＢＣ"に更新される。

なお、図６ではサーブレット・プログラム６３５のうちＪａｖａＥＥなどに準拠した処理部分を例示したが、サーブレット・プログラム６３５は、ＪＳＰなどで記述したページ部分を含んでいてもよい。このため、ＨＴＴＰサーブレット６３０の動作が完了すると、サーブレット・プログラム６３５はレンダリングエンジン６２０に出力され、レンダリングエンジン６２０がＪＳＰのレンダリング処理を開始する。レンダリング処理とは、サーブレット・プログラム６３５に記述されたＨＴＭＬのタグや属性を、それらＨＴＭＬのタグや属性を出力するＪａｖａプログラムに変換したうえで、そのプログラムを実行する処理である。

本実施形態においてレンダリングエンジン６２０は、上記の返信部２５０としての役割も果たす。即ちレンダリングエンジン６２０は、ＨＴＴＰセッションオブジェクトとして記憶されたセッションステートを記憶部２００から読み出して、変換後のＨＴＭＬ文書中にパラメータとして設定する。セッションステートは、ＨＴＴＰレスポンスを構成するＨＴＭＬ文書の各々のｆｏｒｍタグに設定される。設定されるパラメータは、各ｆｏｒｍタグにネストされたｈｉｄｄｅｎタグのパラメータであり、一例として、ｆｏｒｍタグおよび＜％タグを用いて以下のように表すことができる。
＜ｆｏｒｍ…＞
…
＜％＝ＣＳＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ．ｒｅｎｄｅｒＣｌｉｅｎｔＳｅｓｓｉｏｎ（ｒｅｑｕｅｓｔ）％＞
＜／ｆｏｒｍ＞
ここで、タグ＜％は、ＪＳＰのレンダリング処理に対する指令であり、そのタグに対応する式の値をＪＳＰのレンダリング時に評価して、評価値をそのままＨＴＭＬ文書の一部とすることを示す。即ち、レンダリングエンジン６２０は、このようなタグ＜％を予めＪＳＰコード中に挿入したうえで、そのＪＳＰコードをレンダリングしてＨＴＭＬ文書を生成し、ＨＴＴＰレスポンスに含めて返信する。

また、設定するパラメータは、上述のように直列化され、また、暗号化およびデータ圧縮を含む変換が為されることが望ましい。また、図６の例でセッションステートはｋｅｙ１およびｋｅｙ２の２つであるが、レンダリングエンジン６２０はこれらのセッションステートを結合して１つのパラメータとしてＨＴＴＰレスポンスに設定してもよい。これにより、次のＨＴＴＰリクエストにおいてセッションステートを示すパラメータは１つで済み、ＨＴＭＬ文書やリクエストメッセージのデータサイズを小さくし、また、データ構造を単純にすることができる。
なお、ウェブサーバ２０−２〜Ｎのそれぞれについても、ウェブサーバ２０−１と同様の構成を採ることができるから説明を省略する。

図７は、ウェブサーバ２０−１において動作するソフトウェアおよびデータの第２構成を示す概念図である。この第２構成は、セッションステートを全て端末装置１５に記憶するのではなく、セッションステートの用途に応じて記憶先を端末装置１５およびウェブサーバ２０−１から選択できるようにする構成である。この構成によれば、処理の継続のため重要度の高いセッションステートのみを端末装置１５に記憶させることができ、セッション維持のための通信データ量や処理量を低減することができる。以下、概要を述べる。

ウェブサーバ２０−１は、フィルタオブジェクト７００と、ＨＴＴＰサーブレットリクエスト・オブジェクト７１０と、ＨＴＴＰサーブレット７３０とを例えばＪａｖａＥＥなどの仮想機械の上で動作させている。またウェブサーバ２０−１はレンダリングエンジン７２０を動作させている。フィルタオブジェクト７００は、図６の例と同様、フィルタクラスのオブジェクトであり、ＨＴＴＰリクエストを受信すると格納部２２０として動作を開始する。そして、フィルタオブジェクト７００は、ＨＴＴＰリクエストに対応して受信したセッションステートを記憶部２００に格納する。セッションステートを格納する記憶領域は例えばＨＴＴＰサーブレットリクエスト・オブジェクト７１０内の記憶領域である。

但し、図７におけるフィルタオブジェクト７００はフィルタオブジェクト６００とは異なり、受信したセッションステートにより、既に記憶されているセッションステートを更新するのではなく、受信したセッションステートを、既に記憶されているセッションステートに追加して格納する。具体的には以下の通りである。記憶部２００は、ＨＴＴＰサーブレットリクエスト・オブジェクト７１０中の記憶領域に、第１のＨＴＴＰセッションオブジェクト、および、第２のＨＴＴＰセッションオブジェクトの２つを記憶している。第１のＨＴＴＰセッションオブジェクトは、端末装置１５に記憶されるべきオブジェクトである、図中ではｋｅｙ１をキー名とする。第２のＨＴＴＰセッションオブジェクトは、ウェブサーバ２０−１に記憶されるべきオブジェクトであり、図中ではｋｅｙ２をキー名とする。

フィルタオブジェクト７００は、ｋｅｙ１をキー名とするセッションステートを受信すると、そのセッションステートをＨＴＴＰサーブレットリクエスト・オブジェクト７１０中の記憶領域に格納する。このとき、フィルタオブジェクト７００は、既にｋｅｙ２をキー名として格納されていたセッションステートを変更せずに維持する。続いて、実行部２３０は動作を開始してサーブレット・プログラム７３５を実行してＨＴＴＰサーブレット７３０として動作する。１〜４行目に示すように、ＨＴＴＰサーブレットリクエスト・オブジェクトについてｇｅｔＳｅｓｓｉｏｎというメソッドを呼び出すと、ＨＴＴＰセッション・クラスのオブジェクトとしてセッションステートが読み出される。読み出されたセッションステートは変数ｓｅｒｖｅｒＳｅｓｓｉｏｎに格納される。この処理は、図６の例と同様である。但し、ここで読み出されるのはキー名がｋｅｙ２のセッションステートのみである。

一方、６・７行目に示すように、ＨＴＴＰサーブレットリクエスト・オブジェクトについてｇｅｔＣｌｉｅｎｔＳｅｓｓｉｏｎというメソッドを呼び出すと、ＨＴＴＰセッション・クラスの他のオブジェクトとしてセッションステートが読み出される。読み出されたセッションステートは変数ｃｌｉｅｎｔＳｅｓｓｉｏｎに格納される。ここでは、キー名がｋｅｙ１のセッションステートが読み出される。なお、６行目に示すのは形式的な型変換であり、変数ｃｓｒと変数ｒｅｑの実体は同一である。

そして、９・１０行目に示すように、変数ｓｅｒｖｅｒＳｅｓｓｉｏｎおよびｃｌｉｅｎｔＳｅｓｓｉｏｎの何れについても、ｇｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、それぞれの内容を区別して読み出すことができる。また、１２・１３行目に示すように、これらの変数の何れについても、ＳｓｅｔＡｔｔｒｉｂｕｔｅというメソッドを呼び出せば、それぞれのオブジェクトを区別して新たな値を設定することができる。

このように、サーブレット・プログラム７３５の実行に応じ、アクセス部２４０は第１および第２のＨＴＴＰセッションオブジェクトとして記憶された各々のセッションステートに選択的にアクセスすることができる。

なお、図７においても、図６と同様にサーブレット・プログラム７３５のうちＪａｖａＥＥなどに準拠した処理部分を例示したが、サーブレット・プログラム７３５は、ＪＳＰなどで記述したページ部分を含んでいてもよい。このため、ＨＴＴＰサーブレット７３０の動作が完了すると、サーブレット・プログラム７３５はレンダリングエンジン７２０に出力され、レンダリングエンジン７２０がＪＳＰのレンダリング処理を開始する。レンダリングエンジン７２０は、上記の返信部２５０としての役割も果たす。即ちレンダリングエンジン７２０は、ＨＴＴＰセッションオブジェクトを記憶部２００から読み出して、変換後のＨＴＭＬ文書中にパラメータとして設定する。但し、図７の例で、返信部２５０は、第１のＨＴＴＰセッションオブジェクトとして記憶されたセッションステートのみを読み出して設定し、第２のＨＴＴＰセッションオブジェクトとして記憶されたセッションステートは読み出さない。このように、図７においては一部のセッションステートのみを端末装置１５に返信するので、セッション維持に必要な通信量や処理負荷を低減できる。
なお、ウェブサーバ２０−２〜Ｎのそれぞれについても、ウェブサーバ２０−１と同様の構成を採ることができるから説明を省略する。

図８は、本実施形態の変形例において、ウェブサーバ２０−１〜Ｎが端末装置１５と通信する手順を示す。図８を参照して、ウェブサイトがＡｊａｘを採用する場合の処理手順を変形例として示す。本変形例において、返信部２５０およびリダイレクト処理部２６０は、図５のＳ５６０からＳ５１０にいたる処理に代えて、本図のＳ８００からＳ８８０に至る処理を行う。また、端末装置１５は、図５のＳ５７０からＳ５８０を経由してＳ５００に至る処理に代えて、本図のＳ８１０からＳ８７０に至る処理を行う。

まず、返信部２５０は、リダイレクト要求を第２のＨＴＴＰリクエストとしてリダイレクト処理部２６０宛に送信させるように設定した第１のＨＴＴＰレスポンスを端末装置１５に返信する（Ｓ８００）。このリダイレクト要求の要求先は、ウェブサーバ２０−１〜Ｎのうち任意のウェブサーバではなく、いま第１のＨＴＴＰレスポンスを返信しようとしているウェブサーバ２０−１に設定される。これに対応して、端末装置１５は、第１のＨＴＴＰレスポンスを受信して（Ｓ８１０）、このレスポンスに含まれる指示に応じてウェブページを表示する（Ｓ８２０）。

端末装置１５は、ＨＴＴＰリクエストを送信する明示的な操作を受けなくとも、そのウェブページ上で動作するＪａｖａＳｃｒｉｐｔの動作によって、ＸＭＬＨＴＴＰ通信によるリクエストをウェブサーバ２０−１に送信する（Ｓ８３０）。これを受けて、アクセス部２４０は、格納しているセッションステートにアクセスする（Ｓ８３５）。端末装置１５は、ＨＴＴＰリクエストを送信するべき明示的な操作を利用者から受けると、それに応じて第２のＨＴＴＰリクエストを送信する（Ｓ８４０）。このＨＴＴＰリクエストには、Ｓ８００において説明したように、リダイレクト処理部２６０に対しリダイレクト処理を要求するように予め設定されている。このため、リダイレクト処理部２６０は、このリダイレクト要求に応じて、セッションステートを記憶部２００から読み出す（Ｓ８４５）。

そして、リダイレクト処理部２６０は、このセッションステートを、その次の第３のＨＴＴＰリクエストに対応付けて端末装置１５により送信させるパラメータとして、この第２のＨＴＴＰリクエストに対応する第２のＨＴＴＰレスポンスに設定する。そして、リダイレクト処理部２６０は、この第２のＨＴＴＰレスポンスに、直ちに他のウェブサーバに第３のＨＴＴＰリクエストを再送する指示を含めて端末装置１５に返信する。

端末装置１５は、この第２のＨＴＴＰレスポンスを受信すると（Ｓ８６０）、直ちに他のウェブサーバに第３のＨＴＴＰリクエストを送信する（Ｓ８７０）。この第３のＨＴＴＰリクエストには最新のセッションステートが対応付けられて送信される。このため、これを受け取ったウェブサーバは、ＨＴＴＰリクエストに対応付けて最新のセッションステートを適切に受信することができる（Ｓ８８０）。この後の処理は、図１から図７を参照して説明した実施例と同様である。即ち、このウェブサーバは、図５のＳ５２０に戻り、ＨＴＴＰリクエストに応じた処理を行う。

このように、ウェブサイトがＡｊａｘ機能を採用している場合には、ＨＴＴＰレスポンスのパラメータに、そのレスポンスの送信元に対してリダイレクト処理を要求させるように設定することで、最新のセッションステートを読み出すことができる。そして、リダイレクト処理を要求されたウェブサーバ２０−１は、最新のセッションステートを次のＨＴＴＰリクエストに対応付けて送信させるようにＨＴＴＰレスポンスに設定する。これにより、当該次のＨＴＴＰリクエストを受けた他のウェブサーバは、セッションを正しく継続することができる。

図９は、本実施形態又はその変形例においてウェブサーバ２０−１として機能する情報処理装置９００のハードウェア構成の一例を示す。情報処理装置９００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置９００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。

また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、情報処理装置９００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置９００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

情報処理装置９００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して
、記録媒体から読み出され情報処理装置９００にインストールされて実行される。プログラムが情報処理装置９００等に働きかけて行わせる動作は、図１から図８において説明したウェブサーバ２０−１における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置９００に提供してもよい。

以上、本実施形態およびその変形例によれば、サーブレット・プログラムにおいてセッションステートをＨＴＴＰセッションオブジェクトとして参照できるようにしつつも、セッションステートの実体は端末装置に記憶させることができる。これにより、セッションステートをサーブレット・プログラムのコード中で一目瞭然に区別して認識でき、なおかつ、ウェブサイトを複数のウェブサーバで構築してもセッションを適切に維持できる。このことは、プログラム開発や保守の効率を高め、ウェブサイトのハードウェア構成の変更を容易にすることにつながり、近年の大規模なウェブサイトを極めて効率的に構築させることができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることのできることが当業者にとって明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、第１の構成を採用したウェブサーバであるウェブサーバ５１０の機能の概要を示す。 図２は、第２の構成を採用したウェブサーバであるウェブサーバ５４０の機能の概要を示す。 図３は、本実施形態に係る情報システム１０の全体構成を示す。 図４は、本実施形態に係るウェブサーバ２０−１の機能構成を示す。 図５は、本実施形態に係るウェブサーバ２０−１が端末装置１５と通信する手順を示す。 図６は、ウェブサーバ２０−１において動作するソフトウェアおよびデータの第１構成を示す概念図である。 図７は、ウェブサーバ２０−１において動作するソフトウェアおよびデータの第２構成を示す概念図である。 図８は、本実施形態の変形例において、ウェブサーバ２０−１〜Ｎが端末装置１５と通信する手順を示す。 図９は、本実施形態又はその変形例においてウェブサーバ２０−１として機能する情報処理装置９００のハードウェア構成の一例を示す。

符号の説明

１０ 情報システム
１５ 端末装置
１８ ディスパッチャ装置
２０ ウェブサーバ
２００ 記憶部
２１０ 受信部
２２０ 格納部
２３０ 実行部
２４０ アクセス部
２５０ 返信部
２６０ リダイレクト処理部
５１０ ウェブサーバ
５２０ ＨＴＴＰサーブレットリクエスト・オブジェクト
５３０ ＨＴＴＰサーブレット
５４０ ウェブサーバ
５５０ ＨＴＴＰサーブレットリクエスト・オブジェクト
５６０ ＨＴＴＰサーブレット
６００ フィルタオブジェクト
６１０ ＨＴＴＰサーブレットリクエスト・オブジェクト
６２０ レンダリングエンジン
６３０ ＨＴＴＰサーブレット
６３５ サーブレット・プログラム
７００ フィルタオブジェクト
７１０ ＨＴＴＰサーブレットリクエスト・オブジェクト
７２０ レンダリングエンジン
７３０ ＨＴＴＰサーブレット
７３５ サーブレット・プログラム
９００ 情報処理装置

Claims (11)

1. 端末装置から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するための記憶部と、
   セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置から受信する受信部と、
   前記記憶部のうち、受信した前記第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信した前記セッションステートを格納する格納部と、
   前記処理プログラムに含まれる、ＨＴＴＰセッションオブジェクトにアクセスする命令の実行に応じて、格納された前記セッションステートにアクセスするアクセス部と、
   前記処理プログラムに含まれる、第１のＨＴＴＰレスポンスを返信する命令の実行に応じて、前記記憶部から前記セッションステートを読み出して、第２のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定し、設定した前記第１のＨＴＴＰレスポンスを端末装置に返信する返信部と
   を備えるウェブサーバ。
2. 前記格納部は、ＨＴＴＰセッションオブジェクトとしてアクセスされる前記記憶領域に、既に当該記憶領域に記憶されているセッションステートに代えて、前記受信部が新たに受信した前記セッションステートを格納する
   請求項１に記載のウェブサーバ。
3. 前記記憶部は、ＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、第１のＨＴＴＰセッションオブジェクト、および、第２のＨＴＴＰセッションオブジェクトを記憶し、
   前記格納部は、新たに受信した前記セッションステートを前記第１のＨＴＴＰセッションオブジェクトとして前記記憶部に格納し、
   前記アクセス部は、前記処理プログラムの実行に応じて、前記第１および第２のＨＴＴＰセッションオブジェクトとして記憶された各々のセッションステートにアクセスし、
   前記返信部は、前記第１のＨＴＴＰセッションオブジェクトとして記憶されたセッションステートを前記記憶部から読み出して、読み出した当該セッションステートを、前記第２のＨＴＴＰリクエストに対応付けて送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定する
   請求項１に記載のウェブサーバ。
4. 前記返信部は、更に、前記第１のＨＴＴＰセッションオブジェクトとして記憶されたセッションステートを前記記憶部から読み出したことに応じて、当該セッションステートを記憶している記憶領域を他の用途に開放するための処理を行う
   請求項３に記載のウェブサーバ。
5. 前記返信部は、前記第１のＨＴＴＰレスポンスを受け取った端末装置が表示するウェブページには表示されないパラメータであって、当該ウェブページに対する操作に応じて前記第２のＨＴＴＰリクエストに対応付けて送信されるパラメータに、読み出した前記セッションステートを設定する
   請求項１に記載のウェブサーバ。
6. 前記記憶部は、セッションステートとして、第１のデータおよび前記第１のデータを前記第１のデータの格納先アドレスにより参照する第２のデータを含むデータ群を記憶しており、
   前記返信部は、前記記憶部からセッションステートとして読み出した前記データ群に対し、前記第２のデータから前記第１のデータを前記第１のデータの格納先アドレスを用いずに参照する直列化処理を行い、直列化処理を行ったデータ群を前記第１のＨＴＴＰレスポンスに設定する
   請求項１に記載のウェブサーバ。
7. 前記返信部は、直列化処理を行った前記データ群に対し、更に、暗号化処理およびデータ圧縮処理の少なくとも一方を含む変換を行い、変換を行ったデータ群を前記第１のＨＴＴＰレスポンスのパラメータに設定する
   請求項６に記載のウェブサーバ。
8. 前記アクセス部が、前記第１のＨＴＴＰレスポンスが返信されてから前記第２のＨＴＴＰリクエストを受信するまでの間にさらに前記記憶部のセッションステートをアクセスする場合において、
   前記返信部は、前記第２のＨＴＴＰリクエストとしてリダイレクト処理を端末装置により要求させる前記第１のＨＴＴＰレスポンスを返信し、
   受信した前記第２のＨＴＴＰリクエストがリダイレクト処理を要求することを条件に、前記アクセス部がアクセスした前記セッションステートを前記記憶部から読み出して、第３のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして第２のＨＴＴＰレスポンスに設定し、設定した前記第２のＨＴＴＰレスポンスを返信するリダイレクト処理部を更に備え、
   前記格納部は、前記第３のＨＴＴＰリクエストを受信したことを条件に、受信した前記セッションステートを前記記憶部に格納する
   請求項１に記載のウェブサーバ。
9. 複数のウェブサーバと、端末装置から受けたＨＴＴＰリクエストを何れかのウェブサーバに選択的に割り当てるディスパッチャ装置とを備えたシステムであって、
   それぞれのウェブサーバが、
   端末装置から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するための記憶部と、
   前記ディスパッチャ装置からの割当を受けて、セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置から受信する受信部と、
   前記記憶部のうち、受信した前記第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信した前記セッションステートを格納する格納部と、
   前記処理プログラムに含まれる、ＨＴＴＰセッションオブジェクトにアクセスする命令の実行に応じて、格納された前記セッションステートにアクセスするアクセス部と、
   前記処理プログラムに含まれる、第１のＨＴＴＰレスポンスを返信する命令の実行に応じて、前記記憶部から前記セッションステートを読み出して、第２のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定し、設定した前記第１のＨＴＴＰレスポンスを端末装置に返信する返信部と
   を有するシステム。
10. 端末装置から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するための記憶部を有するウェブサーバにおいて、端末装置から受けたＨＴＴＰリクエストに応じて処理を行う方法であって、
    セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置から受信することと、
    前記記憶部のうち、受信した前記第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信した前記セッションステートを格納することと、
    前記処理プログラムに含まれる、ＨＴＴＰセッションオブジェクトにアクセスする命令の実行に応じて、格納された前記セッションステートにアクセスすることと、
    前記処理プログラムに含まれる、第１のＨＴＴＰレスポンスを返信する命令の実行に応じて、前記記憶部から前記セッションステートを読み出して、第２のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定し、設定した前記第１のＨＴＴＰレスポンスを端末装置に返信することと
    を備える方法。
11. 情報処理装置を、
    端末装置から順次受信する複数のＨＴＴＰリクエストに応じた処理の経過を示すセッションステートを記憶するための記憶部と、
    セッションステートを第１のＨＴＴＰリクエストに対応付けて端末装置から受信する受信部と、
    前記記憶部のうち、受信した前記第１のＨＴＴＰリクエストに応じて処理を行う処理プログラムからＨＴＴＰセッションオブジェクトとしてアクセスされる記憶領域に、受信した前記セッションステートを格納する格納部と、
    前記処理プログラムに含まれる、ＨＴＴＰセッションオブジェクトにアクセスする命令の実行に応じて、格納された前記セッションステートにアクセスするアクセス部と、
    前記処理プログラムに含まれる、第１のＨＴＴＰレスポンスを返信する命令の実行に応じて、前記記憶部から前記セッションステートを読み出して、第２のＨＴＴＰリクエストに対応付けて端末装置により送信させるパラメータとして前記第１のＨＴＴＰレスポンスに設定し、設定した前記第１のＨＴＴＰレスポンスを端末装置に返信する返信部と
    して機能させるプログラム。

Images