JP2001236281A - Ｗｗｗのサーバーにおけるセション管理方法 - Google Patents

Abstract

(57)【要約】 【課題】クライアントから同一サーバーのアプリケーシ
ョンを、複数の画面で同時に稼動させてもセションを正
しく管理できる方法を提供する。 【解決手段】 ＷＷＷのサーバーにアクセスするための
ブラウザを有するクライアントにおいて稼働中の各画面
毎に状態管理用の個別のＣｏｏｋｉｅを割り当てて、各
Ｃｏｏｋｉｅはある一定の時間で消えるようにセットさ
れ、稼動画面はある一定時間毎にこのＣｏｏｋｉｅと同
じものを発行し、サーバー側ではＣｏｏｋｉｅがあれば
画面が稼働中と判断し、Ｃｏｏｋｉｅが存在しない画面
は稼動していないと判断する。ＵＲＬの情報部であるＵ
ＲＩには、クライアントの稼働中画面の画面番号とその
動作時刻をセットし、サーバー側の前回動作時刻と一致
しない場合には処理を中止する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＷＷＷのサーバー
におけるセション管理方法に関するものである。

【０００２】

【従来の技術】従来、ＷＷＷのサーバーがクライアント
にサービスを提供する際に、Ｃｏｏｋｉｅでセション情
報を保持する方法、ＵＲＩ（ＵＲＬのパラメータ）でセ
ション情報を保持する方法、Ｈｉｄｄｅｎタグを使用し
て保持情報をセットする方法などがある。

【０００３】

【発明が解決しようとする課題】しかしながら、Ｃｏｏ
ｋｉｅでセション情報を管理する場合、通常は複数の画
面が起動された場合にどの画面でのオペレーションかサ
ーバー側では判断することができない。また、無理に複
数の画面を起動すると、各画面のセション情報が混ざっ
てしまうという問題がある。ＵＲＩでセション情報を管
理する場合、画面毎に制御するためにはどの画面が空い
ているかが管理できていないと実現できない。この場合
も、Ｃｏｏｋｉｅでセション情報を管理する場合と同
様、複数の画面が起動された場合、各画面のセション情
報が混ざってしまうという問題がある。また、Ｈｉｄｄ
ｅｎ領域で管理する場合、全てのトランザクション情報
を伝送上に乗せる必要があるため現実的ではない。

【０００４】本発明はこのような点に鑑みてなされたも
のであり、ＷＷＷのサーバーからクライアントのハード
ディスクに一時ファイルとして格納し、必要に応じてサ
ーバーから読み出すことができるＣｏｏｋｉｅの技術を
利用して、クライアントから同一サーバーのアプリケー
ションを、複数の画面で同時に稼動させてもセションを
正しく管理することができる方法を提供することを課題
とするものである。

【０００５】

【課題を解決するための手段】本発明によれば、上記の
課題を解決するために、まず、サーバー側では、クライ
アントで何画面まで稼動させるかを決める。そして、稼
働中の画面の有無をＣｏｏｋｉｅを使って判断し、ＵＲ
Ｉに画面番号をセットすることで、どの画面からのオぺ
レーションかを判断する。すなわち、画面毎に状態管理
用の個別のＣｏｏｋｉｅを割り当てて、Ｃｏｏｋｉｅで
画面毎の状態（稼動中か否か）を管理する。

【０００６】このＣｏｏｋｉｅは、ある一定の時間（例
えば１〜２秒と言った短い時間）で消えるようにセット
する。稼動画面は、ある一定時間毎に、このＣｏｏｋｉ
ｅと同じものを発行する。画面が消滅した場合（又はセ
ション管理外の他のページに移動された場合）は、新規
のＣｏｏｋｉｅは発行されず、Ｃｏｏｋｉｅは消える。
このことでＣｏｏｋｉｅがあれば画面が稼動中とサーバ
ー側では判断できる。

【０００７】新たな画面を起動するとき、上記のＣｏｏ
ｋｉｅが存在しない画面は、未稼動であることから、次
に利用可能な画面番号を得る。ＵＲＩに画面番号を埋め
込み新規画面を立ち上げる。以降この画面でのオペレー
ションはＵＲＩ中に同一の画面番号が通知されるため、
画面毎のセションを個別に管理することが可能になる。
すなわち、サーバー側ではＵＲＩでオペレーションされ
た画面を識別する。ＵＲＩには画面番号の他に、動作時
刻も埋め込む。サーバーで記憶された前回動作時刻とＵ
ＲＩに埋め込んだ動作時刻を比較することで、クライア
ント側でバックページの操作をしたか否かをチェックす
ることができる。

【０００８】

【発明の実施の形態】図１は本発明のセション管理方法
を実施するためのシステム構成を示している。図中、１
はクライアント（端末）、２はサーバであり、両者はＨ
ＴＴＰのプロトコルで情報を送受できる構成となってい
る。クライアント１は、ＷＷＷのページを閲覧するため
のブラウザと、一時データファイルとしてのＣｏｏｋｉ
ｅを備えている。Ｃｏｏｋｉｅには画面状態（画面番
号）が記録されている。サーバー２は、Ｗｅｂサーバ、
アプリケーションサーバ等であり、セション管理情報を
格納する記憶部を備え、セション管理情報を参照しなが
ら動作するｃｇｉ（ｃｏｍｍｏｎ ｇａｔｅｗａｙ ｉ
ｎｔｅｒｆａｃｅ）アプリケーション、Ｊａｖａサーブ
レット等を備えている。

【０００９】図２は新規接続処理のフローを示してい
る。まず、サーバーは利用者（端末）を特定し、Ｃｏｏ
ｋｉｅから稼動中画面の状態を把握する。そして、稼動
中画面数は最大画面数内か否かを判定する。ここで、稼
動中の画面数が最大画面数以上であれば、接続画面数超
過により新規接続不可として新規接続処理を終了する。
稼動中の画面数が最大画面数よりも少なければ、新画面
番号を確定し、画面番号と動作時刻をＵＲＩにセットす
る。サーバーはセション情報を退避し、業務ＵＲＬへ遷
移し、新規接続処理を終了する。

【００１０】図３は継続接続処理のフローを示してい
る。まず、サーバーはＵＲＩから画面番号を取出す。そ
して、Ｃｏｏｋｉｅから該当画面番号が稼動中状態であ
るかチェックする。該当画面番号が稼動中でなければ、
セション情報に矛盾を検出し、処理続行不可として継続
処理を終了する。該当画面番号が稼動中であれば、先に
退避したセション情報を復元し、ＵＲＩの前回動作時刻
はサーバで保持している前回動作時刻と一致しているか
チェックする。ＵＲＩの前回動作時刻がサーバで保持し
ている前回動作時刻と一致していなければ、バックペー
ジの可能性があるので、処理続行不可として継続処理を
終了する。ＵＲＩの前回動作時刻がサーバで保持してい
る前回動作時刻と一致していれば、本来の業務処理を実
施し、画面番号、動作時刻をＵＲＩにセットし、セショ
ン情報を退避し、ＷＷＷページの出力の後、継続処理を
終了する。

【００１１】図４と図５はクライアント側で画面を元に
戻すバックページの操作が行われた場合の動作説明図で
ある。ブラウザが一般的に持っている「戻る」機能（画
面を元に戻す機能）は、単純なドキュメントを閲覧して
いる場合には便利だが、トランザクション処理を行う場
合には、処理順序の矛盾を発生させる危険性があるため
何らかの方法でバックページを検出する必要がある。そ
の問題点を図４により説明する。ユーザが発注途中で
「戻る」ボタンを押した場合、ブラウザはサーバとは無
関係に表示内容を戻してしまうため、まだ発注が完了し
ていないように見えてしまう。再度、発注処理をされた
場合はもう一度サーバに対して発注処理が指示される。
何も対策を講じない場合、サーバ側では普通に２度の発
注があったものとして処理を行うため、注文終了は２に
計上されてしまう。その結果、ユーザは商品Ａを一つだ
け発注したつもりであってもサーバでは商品Ａを２つ受
注したと勘違いしていることになる。

【００１２】一方、本発明によれば、サーバに通知され
るＵＲＬに処理シーケンスを含めることで、サーバ側で
処理順序を正常に維持しているかをチェック可能にし、
バックページを検出し、不当な処理を未然に防ぐ機能を
実現するものである。その動作を図５により説明する。
本方式を講じた場合には、正常に処理するべきシーケン
スがＵＲＬと共に通知されるので、サーバ側でチェック
処理を行うことが可能である。図５のの発注時にはシ
ーケンスが前回からの正常な継続状態であれば、ページ
を表示する際に次回のシーケンスを００３と決定し、サ
ーバ側で記憶する。「戻る」ボタンで表示順序が崩れた
後のの発注では、前回と同じ００２のシーケンスが通
知され、本来有効であるはずの００３と異なるため、処
理順序に異常が発生したことを検出できる。ここで処理
を中止することでユーザのオペレーションとサーバ側の
状態の認識の違いを食い止めることができる。

【００１３】

【発明の効果】請求項１の発明によれば、ＷＷＷのサー
バーにアクセスするためのブラウザを有するクライアン
トにおいて稼働中の各画面毎に状態管理用の個別のＣｏ
ｏｋｉｅを割り当てて、各Ｃｏｏｋｉｅはある一定の時
間で消えるようにセットされ、稼動画面はある一定時間
毎にこのＣｏｏｋｉｅと同じものを発行し、サーバー側
ではＣｏｏｋｉｅがあれば画面が稼働中と判断し、Ｃｏ
ｏｋｉｅが存在しない画面は稼動していないと判断する
ものであるから、１つの端末で稼働中の複数の画面の各
々があたかも別々の端末であるかのようにサーバーから
は見えるものであり、したがって、端末においてどの画
面が稼働中であるかをサーバー側で判定することができ
るという効果がある。

【００１４】請求項２の発明によれば、ＵＲＬの情報部
であるＵＲＩには、クライアントの稼働中画面の画面番
号とその動作時刻をセットするので、ＵＲＩにセットさ
れた画面番号をチェックすることで、どの画面からのオ
ぺレーションかをサーバー側で判断することができると
いう効果がある。

【００１５】請求項３の発明によれば、ＷＷＷサーバー
においてセション管理のために退避されるセション情報
の中に、クライアントの稼働中画面の画面番号とその動
作時刻が含まれているので、ＵＲＩに含まれる画面番号
及び動作時刻と照らし合わせることにより、画面毎のセ
ションを個別に管理することが可能になる。

【００１６】請求項４の発明によれば、ＷＷＷサーバー
においてセション管理のために退避されたセション情報
に含まれている画面番号とその前回動作時刻がＵＲＩに
セットされた画面番号と前回動作時刻と一致しない場合
には、処理を中止するので、クライアント側で元の画面
に戻るバックページの操作がされたときに、そのことを
サーバー側で検知することができるという効果がある。

【図面の簡単な説明】

【図１】本発明のセション管理方法を実施するためのシ
ステムの概略構成図である。

【図２】本発明のセション管理方法を用いたサーバーの
新規接続処理を示すフローチャートである。

【図３】本発明のセション管理方法を用いたサーバーの
継続処理を示すフローチャートである。

【図４】従来のセション管理方法の説明図である。

【図５】本発明のセション管理方法の説明図である。

【符号の説明】 １ クライアント（端末） ２ サーバ

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ＷＷＷのサーバーにアクセスするため
   のブラウザを有するクライアントにおいて稼働中の各画
   面毎に状態管理用の個別のＣｏｏｋｉｅを割り当てて、
   各Ｃｏｏｋｉｅはある一定の時間で消えるようにセット
   され、稼動画面はある一定時間毎にこのＣｏｏｋｉｅと
   同じものを発行し、サーバー側ではＣｏｏｋｉｅがあれ
   ば画面が稼働中と判断し、Ｃｏｏｋｉｅが存在しない画
   面は稼動していないと判断することを特徴とするＷＷＷ
   のサーバーにおけるセション管理方法。
2. 【請求項２】 ＵＲＬの情報部であるＵＲＩには、ク
   ライアントの稼働中画面の画面番号とその動作時刻をセ
   ットすることを特徴とする請求項１記載のＷＷＷのサー
   バーにおけるセション管理方法。
3. 【請求項３】 ＷＷＷサーバーにおいてセション管理
   のために退避されるセション情報の中に、クライアント
   の稼働中画面の画面番号とその動作時刻が含まれている
   ことを特徴とする請求項２記載のＷＷＷのサーバーにお
   けるセション管理方法。
4. 【請求項４】 ＷＷＷサーバーにおいてセション管理
   のために退避されたセション情報に含まれている画面番
   号とその前回動作時刻がＵＲＩにセットされた画面番号
   と前回動作時刻と一致しない場合には、処理を中止する
   ことを特徴とする請求項３記載のＷＷＷのサーバーにお
   けるセション管理方法。