JP2005010913A - セッション管理方法 - Google Patents
セッション管理方法 Download PDFInfo
- Publication number
- JP2005010913A JP2005010913A JP2003171992A JP2003171992A JP2005010913A JP 2005010913 A JP2005010913 A JP 2005010913A JP 2003171992 A JP2003171992 A JP 2003171992A JP 2003171992 A JP2003171992 A JP 2003171992A JP 2005010913 A JP2005010913 A JP 2005010913A
- Authority
- JP
- Japan
- Prior art keywords
- session
- request
- message
- http
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】データの要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダを利用することによって管理するセッション管理方法を提供する。
【解決手段】クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加しアプリケーションサーバへ送信する。サーバ側セッション管理部５は、セッション開始要求メッセージを受信すると、セッションを識別するためのセッションＩＤを生成、記憶領域に記録し、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加し、クライアントへ送信する。クライアント側セッション管理部６は、Ｃｏｏｋｉｅ作成要求メッセージを受信すると、Ｃｏｏｋｉｅを作成、記憶領域に記録する。
【選択図】 図１
【解決手段】クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加しアプリケーションサーバへ送信する。サーバ側セッション管理部５は、セッション開始要求メッセージを受信すると、セッションを識別するためのセッションＩＤを生成、記憶領域に記録し、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加し、クライアントへ送信する。クライアント側セッション管理部６は、Ｃｏｏｋｉｅ作成要求メッセージを受信すると、Ｃｏｏｋｉｅを作成、記憶領域に記録する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、データの要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージによって管理制御するセッション管理方法に関する。
【０００２】
【従来の技術】
Ｗｅｂの開発者が直面している問題の１つとして、「ばらばらのＨＴＭＬページを組み合わせて、一貫性のあるアプリケーションを作成するにはどうすればいいのか？」ということがある。この問題は、Ｗｅｂの開発では特に重要になっている。そもそもＨＴＴＰがステートレスなプロトコルであることが原因であり、そのためＷｅｂサーバに対するブラウザ要求はそれぞれ独立した状態となってしまう。また、Ｗｅｂサーバはブラウザの過去の要求に関する記憶を持っていない。さらに、ＨＴＴＰ１．０プロトコルには、ブラウザからの複数の要求の間で状態情報を保持するためのメカニズムが用意されていない。
【０００３】
そこで従来は、この問題を克服するために、Ｗｅｂ上で一貫性のあるユーザセッション管理を可能とするＡｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）や、Ｃｏｏｋｉｅを用いてセッション管理を行っている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来のセッション管理の手法には下記のような問題点がある。
【０００５】
１）セッションの開始がサーバ主導であり、クライアントからセッション開始の要求をすることができない。従来は、どこからセッションを開始するかはサーバから提供されるＷｅｂページに従っていた。
【０００６】
２）セッションの終了について明示的な終了要求通知が無い。従来は、指定されたアイドル期間が終了した時点で、そのセッションをタイムアウトさせていた。
【０００７】
３）セッションを継続している間に発生した様々な状況を、コンテンツを送信することでしか通知できない。従来は、例えば何等かのエラーが発生した場合、エラーを表示するためのＷｅｂページをクライアントへ送信することで通知していた。
【０００８】
このような問題が従来のセッション管理においてはあり、より詳細にセッションの状態を管理し、継続性を制御することが必要とされていた。
【０００９】
本発明は上記事情に鑑み、データの要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダを利用して管理制御するセッション管理方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、請求項１に記載の発明であるセッション管理方法は、処理の要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダによって管理制御するセッション管理方法であって、前記要求元、および前記要求先の間でセッションを開始する際は、前記要求元が、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージを取得すると、セッションを識別するセッションＩＤを生成し記憶する工程と、前記要求先が、ＨＴＴＰレスポンスメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求元へ送信する工程と、前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションＩＤを取得し記憶する工程とを有することを特徴とする。
【００１１】
請求項１の発明によれば、要求元からセッション開始要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって、任意にセッションの開始を行うことが可能となる。
【００１２】
また、請求項２に記載の発明であるセッション管理方法は、請求項１に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理を要求する際は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッションＩＤを取得すると、記憶している前記セッションＩＤと比較し、一致する場合は、前記要求元と前記要求先との接続が継続されていると判定する工程とを有することを特徴とする。
【００１３】
また、請求項３に記載の発明であるセッション管理方法は、請求項１乃至請求項２に記載のセッション管理方法であって、前記要求元、および前記要求先の間でセッションを終了する際は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション終了要求メッセージを取得すると、セッションを識別するセッションＩＤを無効にする工程と、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了した旨のメッセージを付加して前記要求元へ送信する工程と、前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションが終了した旨のメッセージを取得すると、前記セッションＩＤを破棄する工程とを有することを特徴とする。
【００１４】
請求項３の発明によれば、前記要求元からセッション終了要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって、任意にセッションの終了を明示的に行うことが可能となる。
【００１５】
また、請求項４に記載の発明であるセッション管理方法は、請求項１乃至請求項３に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理を要求した際に、前記要求先が当該処理を実行できない場合、または前記要求元から要求された処理が不当な場合、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする。
【００１６】
請求項４の発明によれば、前記要求先から状態を示すメッセージを付加したＨＴＴＰレスポンスメッセージを送信することによって前記要求元は前記要求先の状態を把握することが可能となる。
【００１７】
また、請求項５に記載の発明であるセッション管理方法は、請求項１乃至請求項４に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理の要求がされないまま所定の期間が経過した場合、前記要求先が、セッションを識別するセッションＩＤを無効にする工程を有することを特徴とする。
【００１８】
また、請求項６に記載の発明であるセッション管理方法は、請求項５に記載のセッション管理方法であって、所定の期間が経過し、前記セッションＩＤが無効にされた後、当該セッションＩＤを含む前記ＨＴＴＰリクエストメッセージをもって前記要求元から前記要求先へ処理を要求した場合、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする。
【００１９】
また、請求項７に記載の発明であるセッション管理方法は、請求項５乃至請求項６に記載のセッション管理方法であって、所定の期間が経過し、前記セッションＩＤが無効にされた後、セッションを再開する場合は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに当該セッションＩＤと前記セッション開始要求メッセージとを付加して前記要求先へ送信する工程を有することを特徴とする。
【００２０】
また、請求項８に記載の発明であるセッション管理方法は、請求項１乃至請求項７に記載のセッション管理方法であって、前記要求元、および前記要求先の間でセッションを開始する際、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッション開始要求メッセージと前記セッション終了要求メッセージとを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージと前記セッション終了要求メッセージとを取得すると、前記セッションＩＤを生成せずに、要求された処理を実行する工程とを有することを特徴とする。
【００２１】
【発明の実施の形態】
本発明の実施形態について、図１〜図４に基づいて説明する。
【００２２】
図１に、実施形態の一例として、ホストコンピュータ３、アプリケーションサーバ１、クライアント２、それらを相互に接続するネットワーク４からなるシステムを示す。アプリケーションサーバ１が、セッションＩＤを発行するＨＴＴＰサーバであり、クライアント２が、発行されたセッションＩＤを含むＣｏｏｋｉｅを作成する側がＨＴＴＰクライアントである。
【００２３】
アプリケーションサーバ１は、サーバ側セッション管理部５と、セッションＩＤを記憶する記憶領域を有する。また、クライアント２は、クライアント側セッション管理部６と、Ｃｏｏｋｉｅを記憶する記憶領域を有する。この記憶領域は、主記憶装置、補助記憶装置のいずれにあっても良い。
【００２４】
サーバ側セッション管理部５は、セッションを開始終了する機能、セッションを識別するためのセッションＩＤを生成し記憶領域に記録する機能、セッションＩＤを破棄（無効化）する機能、破棄（無効化）されたセッションＩＤを有効化する機能、レスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加する機能、レスポンスメッセージのメッセージヘッダにセッションの状態を示すメッセージを付加する機能を有する。
【００２５】
また、クライアント側セッション管理部６は、リクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加する機能、Ｃｏｏｋｉｅ作成要求メッセージに従ってＣｏｏｋｉｅを作成、記憶領域に記録する機能、ＣｏｏｋｉｅからセッションＩＤを取得し、リクエストメッセージのメッセージヘッダに取得したセッションＩＤを付加する機能、リクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加する機能、記憶領域に記録されているＣｏｏｋｉｅを破棄する機能を有する。
【００２６】
なお、アプリケーションサーバ１とホストコンピュータ３は専用線で接続され、両者間の通信はステートフル（セッション管理がされている）であることとする。
【００２７】
次に、図２〜図４のシーケンス図に基づいて、一連のＨＴＴＰファイル転送処理におけるセッション管理制御の処理について説明する。
【００２８】
≪クライアントからのセッション開始≫
クライアント２からアプリケーションサーバ１に対してセッションの開始を要求するときは、まず、クライアント２はセッションの開始を示すセッション開始要求メッセージをアプリケーションサーバ１に対して送信する。
【００２９】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ０１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００３０】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ（キャリッジリターン）＋ＬＦ（ラインフィールド））
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰリクエストメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ」がセッション開始要求メッセージである。また、「Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８」はクライアント２を識別するＩＤ情報である。
【００３１】
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション開始要求メッセージが含まれていた場合、セッションを識別するためのセッションＩＤを生成、記憶領域に記録する（ステップＳ０２）。
【００３２】
次に、サーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ０３）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００３３】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
Ｓｅｔ−Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４；Ｐａｔｈ＝ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「ＳｅｓｓｉｏｎＩＤ＝１２３４」が生成されたセッションＩＤである。また、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００」は、セッションの状態を表すメッセージであり、「Ｓｔａｔｕｓ＝００００」は、要求されたセッションに関する処理が正常に行われたことを示す（ここでは正常にセッションが開始継続されていることを示す）。また、「Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ」は、メッセージボディに記述されている情報は無効であることを示すメッセージである。
【００３４】
クライアント２のクライアント側セッション管理部６は、受信したＨＴＴＰレスポンスメッセージにＣｏｏｋｉｅ作成要求メッセージが含まれていた場合、そのＣｏｏｋｉｅ作成要求メッセージに従ってＣｏｏｋｉｅを作成、記憶領域に記録する（ステップＳ０４）。Ｃｏｏｋｉｅとして、下記の情報が記録される。
【００３５】
Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４（セッションＩＤ）
ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ（有効ドメイン、パス）
≪セッションの継続≫
セッションが開始された後、クライアント２からアプリケーションサーバ１に対して何等かの要求を行う場合は、クライアント２はセッションＩＤをメッセージヘッダに付加してアプリケーションサーバ１に送信する。
【００３６】
例えば、クライアント２から予約情報の照会を行う場合、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤを付加し、メッセージボディに予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ１１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００３７】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ１２）、継続中のセッションであるか判定する（ステップＳ１３）。
【００３８】
継続中のセッションであると判定した場合、アプリケーションサーバ１はホストコンピュータ３に対して予約情報の照会を行う（ステップＳ１４）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ１５）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ１６）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００３９】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞＜予約情報＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ１７）。
【００４０】
なお、ステップＳ１３でセッションが継続していないと判定されると、セッションが終了していることを示すエラーコードが記述されたメッセージがクライアント２へ送信される（詳細は後述）。
【００４１】
≪クライアントからのセッション終了≫
クライアント２からアプリケーションサーバ１に対してセッションの終了開始を要求するときは、アプリケーションサーバ１は、まず、クライアント２からセッションの開始を示すセッション終了要求メッセージをアプリケーションサーバ１に対して送信する。
【００４２】
まず、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ２１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００４３】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｐｓ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｃｏｏｋｉｅ：Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰリクエストメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」がセッション終了要求メッセージであり、セッションＩＤと供に送信される。
【００４４】
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション終了要求メッセージが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ２２）、継続中のセッションであるか判定する（ステップＳ２３）。照合の結果、継続中のセッションであると判定すると、サーバ側セッション管理部５は、そのセッション終了要求メッセージと供に送信されるセッションＩＤを破棄（または無効化）する（ステップＳ２４）。
【００４５】
次に、サーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ２５）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００４６】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝００００
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝００００」が、セッションが終了したことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ２６）。
【００４７】
≪サーバ障害に伴うセッション終了≫
クライアント２からＨＴＴＰリクエストメッセージを受信した後、アプリケーションサーバ１で何等かの障害を生じ要求された処理を継続して行うことができなくなった場合、アプリケーションサーバ１はセッションを終了する。
【００４８】
アプリケーションサーバ１で何等かの障害が発生すると（ステップＳ３１）、アプリケーションサーバ１のサーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ３２）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００４９】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝ＸＸＸＸ
Ｘ−Ｙｏｙａｋｕ −Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」が、セッションが終了したことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ３３）。また、上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝ＸＸＸＸ」は、障害の状態を表すメッセージであり、ＸＸＸＸに障害の状態に応じたステータスコードが記述される。
【００５０】
≪クライアント障害に伴うセッションタイムアウト≫
セッションが開始された後、クライアント２で何等かの障害を生じアプリケーションサーバ１に対して要求を行うことができなくなった場合、アプリケーションサーバ１はセッションを終了する。
【００５１】
クライアント２からセッション終了要求メッセージを送信することができる場合は、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信し（ステップＳ４１）、サーバ側セッション管理部５は、上述の≪クライアント２からのセッション終了≫と同じ処理を行い、セッションを終了する（ステップＳ４２）。
【００５２】
また、クライアント２からセッション終了要求メッセージをも送信できない場合、またはクライアント２からアプリケーションサーバ１に対して何等アクションがない場合は（ステップＳ４３）、アプリケーションサーバ１のサーバ側セッション管理部５は、一定時間、セッションを継続した後（ステップＳ４４）、セッションＩＤを破棄（または無効化）し、セッションを終了する（ステップＳ４５）。
【００５３】
≪タイムアウト後におけるクライアントからの要求≫
タイムアウトが発生しアプリケーションサーバ１でセッションを終了した後に、クライアント２からＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１はクライアント２に対してセッションが既に終了していることを通知する。
【００５４】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ５１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００５５】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ５２）、継続中のセッションであるか判定する（ステップＳ５３）。
【００５６】
既に終了したセッションであると判定した場合、アプリケーションサーバ１のサーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ５４）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００５７】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝ＸＸＸＸ
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」が、セッションが終了したことを示すメッセージであり、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝ＸＸＸＸ」が、セッションが存在しないことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ５５）。
【００５８】
なお、ステップＳ５３でセッションが継続中であると判定した場合は、通常の処理を行う（ステップＳ５６）。
【００５９】
≪タイムアウト後におけるセッション情報付きでのクライアントからの要求≫
タイムアウトが発生しアプリケーションサーバ１でセッションを終了した後に、クライアント２からセッション開始要求メッセージを含むＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１は破棄（無効化）したセッションＩＤを有効化し、要求された処理を行う。
【００６０】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤとセッション開始要求メッセージを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ６１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００６１】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ６２）、継続中のセッションであるか判定する（ステップＳ６３）。
【００６２】
既に終了したセッションであると判定し、さらにセッション開始要求メッセージが存在する場合、アプリケーションサーバ１のサーバ側セッション管理部５は、破棄（無効化）したセッションＩＤを有効化する（ステップＳ６４）。
【００６３】
セッションＩＤが有効化された後、アプリケーションサーバ１はホストコンピュータ３に対して予約情報の照会を行う（ステップＳ６５）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ６６）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ６７）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００６４】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会結果＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ６８）。
【００６５】
≪クライアントからセッション開始と終了とを同時要求≫
クライアント２からセッション開始要求メッセージとセッション終了要求メッセージとを含むＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１はセッションＩＤを生成せず要求された処理を行う。
【００６６】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージとセッション終了要求メッセージとを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ７１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００６７】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ（キャリッジリターン）＋ＬＦ（ラインフィールド））
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション開始要求メッセージとセッション終了要求メッセージとが含まれていた場合、セッションＩＤを生成せずに、メッセージボディに記述されている処理に移行し、例えば、ホストコンピュータ３に対して予約情報の照会を行う（ステップＳ７２）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ７３）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ７４）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例であり、処理が正常に行われたことを示すメッセージが「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００」付加される。
【００６８】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会結果＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ６８）。
【００６９】
このように、ＨＴＴＰリクエストメッセージとＨＴＴＰレスポンスメッセージに、拡張ヘッダとして要求メッセージやステータスを示すメッセージを付加することによって、セッション管理を行うことが可能となる。
【００７０】
【発明の効果】
以上説明したように、本発明によれば、要求元から任意にセッション開始要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによってセッションの開始を行い、また、要求元からセッション終了要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって任意にセッションの終了を明示的に行うので、詳細にセッションの継続性を制御することが可能となる。さらに、要求先からＨＴＴＰレスポンスメッセージを送信することによって要求元は要求先の状態を把握することが可能となる。
【図面の簡単な説明】
【図１】本実施形態における機能構成図である。
【図２】セッション管理の手順を示すシーケンス図である。
【図３】セッション管理の手順を示すシーケンス図である。
【図４】セッション管理の手順を示すシーケンス図である。
【符号の説明】
１ アプリケーションサーバ
２ クライアント
３ ホストコンピュータ
４ ネットワーク
５ サーバ側セッション管理部
６ クライアント側セッション管理部
【発明の属する技術分野】
本発明は、データの要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージによって管理制御するセッション管理方法に関する。
【０００２】
【従来の技術】
Ｗｅｂの開発者が直面している問題の１つとして、「ばらばらのＨＴＭＬページを組み合わせて、一貫性のあるアプリケーションを作成するにはどうすればいいのか？」ということがある。この問題は、Ｗｅｂの開発では特に重要になっている。そもそもＨＴＴＰがステートレスなプロトコルであることが原因であり、そのためＷｅｂサーバに対するブラウザ要求はそれぞれ独立した状態となってしまう。また、Ｗｅｂサーバはブラウザの過去の要求に関する記憶を持っていない。さらに、ＨＴＴＰ１．０プロトコルには、ブラウザからの複数の要求の間で状態情報を保持するためのメカニズムが用意されていない。
【０００３】
そこで従来は、この問題を克服するために、Ｗｅｂ上で一貫性のあるユーザセッション管理を可能とするＡｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）や、Ｃｏｏｋｉｅを用いてセッション管理を行っている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来のセッション管理の手法には下記のような問題点がある。
【０００５】
１）セッションの開始がサーバ主導であり、クライアントからセッション開始の要求をすることができない。従来は、どこからセッションを開始するかはサーバから提供されるＷｅｂページに従っていた。
【０００６】
２）セッションの終了について明示的な終了要求通知が無い。従来は、指定されたアイドル期間が終了した時点で、そのセッションをタイムアウトさせていた。
【０００７】
３）セッションを継続している間に発生した様々な状況を、コンテンツを送信することでしか通知できない。従来は、例えば何等かのエラーが発生した場合、エラーを表示するためのＷｅｂページをクライアントへ送信することで通知していた。
【０００８】
このような問題が従来のセッション管理においてはあり、より詳細にセッションの状態を管理し、継続性を制御することが必要とされていた。
【０００９】
本発明は上記事情に鑑み、データの要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダを利用して管理制御するセッション管理方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、請求項１に記載の発明であるセッション管理方法は、処理の要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダによって管理制御するセッション管理方法であって、前記要求元、および前記要求先の間でセッションを開始する際は、前記要求元が、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージを取得すると、セッションを識別するセッションＩＤを生成し記憶する工程と、前記要求先が、ＨＴＴＰレスポンスメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求元へ送信する工程と、前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションＩＤを取得し記憶する工程とを有することを特徴とする。
【００１１】
請求項１の発明によれば、要求元からセッション開始要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって、任意にセッションの開始を行うことが可能となる。
【００１２】
また、請求項２に記載の発明であるセッション管理方法は、請求項１に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理を要求する際は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッションＩＤを取得すると、記憶している前記セッションＩＤと比較し、一致する場合は、前記要求元と前記要求先との接続が継続されていると判定する工程とを有することを特徴とする。
【００１３】
また、請求項３に記載の発明であるセッション管理方法は、請求項１乃至請求項２に記載のセッション管理方法であって、前記要求元、および前記要求先の間でセッションを終了する際は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション終了要求メッセージを取得すると、セッションを識別するセッションＩＤを無効にする工程と、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了した旨のメッセージを付加して前記要求元へ送信する工程と、前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションが終了した旨のメッセージを取得すると、前記セッションＩＤを破棄する工程とを有することを特徴とする。
【００１４】
請求項３の発明によれば、前記要求元からセッション終了要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって、任意にセッションの終了を明示的に行うことが可能となる。
【００１５】
また、請求項４に記載の発明であるセッション管理方法は、請求項１乃至請求項３に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理を要求した際に、前記要求先が当該処理を実行できない場合、または前記要求元から要求された処理が不当な場合、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする。
【００１６】
請求項４の発明によれば、前記要求先から状態を示すメッセージを付加したＨＴＴＰレスポンスメッセージを送信することによって前記要求元は前記要求先の状態を把握することが可能となる。
【００１７】
また、請求項５に記載の発明であるセッション管理方法は、請求項１乃至請求項４に記載のセッション管理方法であって、セッションが開始された後、前記要求元から前記要求先へ処理の要求がされないまま所定の期間が経過した場合、前記要求先が、セッションを識別するセッションＩＤを無効にする工程を有することを特徴とする。
【００１８】
また、請求項６に記載の発明であるセッション管理方法は、請求項５に記載のセッション管理方法であって、所定の期間が経過し、前記セッションＩＤが無効にされた後、当該セッションＩＤを含む前記ＨＴＴＰリクエストメッセージをもって前記要求元から前記要求先へ処理を要求した場合、前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする。
【００１９】
また、請求項７に記載の発明であるセッション管理方法は、請求項５乃至請求項６に記載のセッション管理方法であって、所定の期間が経過し、前記セッションＩＤが無効にされた後、セッションを再開する場合は、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに当該セッションＩＤと前記セッション開始要求メッセージとを付加して前記要求先へ送信する工程を有することを特徴とする。
【００２０】
また、請求項８に記載の発明であるセッション管理方法は、請求項１乃至請求項７に記載のセッション管理方法であって、前記要求元、および前記要求先の間でセッションを開始する際、前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッション開始要求メッセージと前記セッション終了要求メッセージとを付加して前記要求先へ送信する工程と、前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージと前記セッション終了要求メッセージとを取得すると、前記セッションＩＤを生成せずに、要求された処理を実行する工程とを有することを特徴とする。
【００２１】
【発明の実施の形態】
本発明の実施形態について、図１〜図４に基づいて説明する。
【００２２】
図１に、実施形態の一例として、ホストコンピュータ３、アプリケーションサーバ１、クライアント２、それらを相互に接続するネットワーク４からなるシステムを示す。アプリケーションサーバ１が、セッションＩＤを発行するＨＴＴＰサーバであり、クライアント２が、発行されたセッションＩＤを含むＣｏｏｋｉｅを作成する側がＨＴＴＰクライアントである。
【００２３】
アプリケーションサーバ１は、サーバ側セッション管理部５と、セッションＩＤを記憶する記憶領域を有する。また、クライアント２は、クライアント側セッション管理部６と、Ｃｏｏｋｉｅを記憶する記憶領域を有する。この記憶領域は、主記憶装置、補助記憶装置のいずれにあっても良い。
【００２４】
サーバ側セッション管理部５は、セッションを開始終了する機能、セッションを識別するためのセッションＩＤを生成し記憶領域に記録する機能、セッションＩＤを破棄（無効化）する機能、破棄（無効化）されたセッションＩＤを有効化する機能、レスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加する機能、レスポンスメッセージのメッセージヘッダにセッションの状態を示すメッセージを付加する機能を有する。
【００２５】
また、クライアント側セッション管理部６は、リクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加する機能、Ｃｏｏｋｉｅ作成要求メッセージに従ってＣｏｏｋｉｅを作成、記憶領域に記録する機能、ＣｏｏｋｉｅからセッションＩＤを取得し、リクエストメッセージのメッセージヘッダに取得したセッションＩＤを付加する機能、リクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加する機能、記憶領域に記録されているＣｏｏｋｉｅを破棄する機能を有する。
【００２６】
なお、アプリケーションサーバ１とホストコンピュータ３は専用線で接続され、両者間の通信はステートフル（セッション管理がされている）であることとする。
【００２７】
次に、図２〜図４のシーケンス図に基づいて、一連のＨＴＴＰファイル転送処理におけるセッション管理制御の処理について説明する。
【００２８】
≪クライアントからのセッション開始≫
クライアント２からアプリケーションサーバ１に対してセッションの開始を要求するときは、まず、クライアント２はセッションの開始を示すセッション開始要求メッセージをアプリケーションサーバ１に対して送信する。
【００２９】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ０１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００３０】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ（キャリッジリターン）＋ＬＦ（ラインフィールド））
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰリクエストメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ」がセッション開始要求メッセージである。また、「Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８」はクライアント２を識別するＩＤ情報である。
【００３１】
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション開始要求メッセージが含まれていた場合、セッションを識別するためのセッションＩＤを生成、記憶領域に記録する（ステップＳ０２）。
【００３２】
次に、サーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションＩＤを含むＣｏｏｋｉｅ作成要求メッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ０３）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００３３】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
Ｓｅｔ−Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４；Ｐａｔｈ＝ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「ＳｅｓｓｉｏｎＩＤ＝１２３４」が生成されたセッションＩＤである。また、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００」は、セッションの状態を表すメッセージであり、「Ｓｔａｔｕｓ＝００００」は、要求されたセッションに関する処理が正常に行われたことを示す（ここでは正常にセッションが開始継続されていることを示す）。また、「Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ」は、メッセージボディに記述されている情報は無効であることを示すメッセージである。
【００３４】
クライアント２のクライアント側セッション管理部６は、受信したＨＴＴＰレスポンスメッセージにＣｏｏｋｉｅ作成要求メッセージが含まれていた場合、そのＣｏｏｋｉｅ作成要求メッセージに従ってＣｏｏｋｉｅを作成、記憶領域に記録する（ステップＳ０４）。Ｃｏｏｋｉｅとして、下記の情報が記録される。
【００３５】
Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４（セッションＩＤ）
ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ（有効ドメイン、パス）
≪セッションの継続≫
セッションが開始された後、クライアント２からアプリケーションサーバ１に対して何等かの要求を行う場合は、クライアント２はセッションＩＤをメッセージヘッダに付加してアプリケーションサーバ１に送信する。
【００３６】
例えば、クライアント２から予約情報の照会を行う場合、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤを付加し、メッセージボディに予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ１１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００３７】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ１２）、継続中のセッションであるか判定する（ステップＳ１３）。
【００３８】
継続中のセッションであると判定した場合、アプリケーションサーバ１はホストコンピュータ３に対して予約情報の照会を行う（ステップＳ１４）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ１５）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ１６）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００３９】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞＜予約情報＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ１７）。
【００４０】
なお、ステップＳ１３でセッションが継続していないと判定されると、セッションが終了していることを示すエラーコードが記述されたメッセージがクライアント２へ送信される（詳細は後述）。
【００４１】
≪クライアントからのセッション終了≫
クライアント２からアプリケーションサーバ１に対してセッションの終了開始を要求するときは、アプリケーションサーバ１は、まず、クライアント２からセッションの開始を示すセッション終了要求メッセージをアプリケーションサーバ１に対して送信する。
【００４２】
まず、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ２１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００４３】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｐｓ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｃｏｏｋｉｅ：Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰリクエストメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」がセッション終了要求メッセージであり、セッションＩＤと供に送信される。
【００４４】
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション終了要求メッセージが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ２２）、継続中のセッションであるか判定する（ステップＳ２３）。照合の結果、継続中のセッションであると判定すると、サーバ側セッション管理部５は、そのセッション終了要求メッセージと供に送信されるセッションＩＤを破棄（または無効化）する（ステップＳ２４）。
【００４５】
次に、サーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ２５）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００４６】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝００００
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝００００」が、セッションが終了したことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ２６）。
【００４７】
≪サーバ障害に伴うセッション終了≫
クライアント２からＨＴＴＰリクエストメッセージを受信した後、アプリケーションサーバ１で何等かの障害を生じ要求された処理を継続して行うことができなくなった場合、アプリケーションサーバ１はセッションを終了する。
【００４８】
アプリケーションサーバ１で何等かの障害が発生すると（ステップＳ３１）、アプリケーションサーバ１のサーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ３２）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００４９】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝ＸＸＸＸ
Ｘ−Ｙｏｙａｋｕ −Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」が、セッションが終了したことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ３３）。また、上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｔａｔｕｓ： Ｓｔａｔｕｓ＝ＸＸＸＸ」は、障害の状態を表すメッセージであり、ＸＸＸＸに障害の状態に応じたステータスコードが記述される。
【００５０】
≪クライアント障害に伴うセッションタイムアウト≫
セッションが開始された後、クライアント２で何等かの障害を生じアプリケーションサーバ１に対して要求を行うことができなくなった場合、アプリケーションサーバ１はセッションを終了する。
【００５１】
クライアント２からセッション終了要求メッセージを送信することができる場合は、クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加し、そのＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信し（ステップＳ４１）、サーバ側セッション管理部５は、上述の≪クライアント２からのセッション終了≫と同じ処理を行い、セッションを終了する（ステップＳ４２）。
【００５２】
また、クライアント２からセッション終了要求メッセージをも送信できない場合、またはクライアント２からアプリケーションサーバ１に対して何等アクションがない場合は（ステップＳ４３）、アプリケーションサーバ１のサーバ側セッション管理部５は、一定時間、セッションを継続した後（ステップＳ４４）、セッションＩＤを破棄（または無効化）し、セッションを終了する（ステップＳ４５）。
【００５３】
≪タイムアウト後におけるクライアントからの要求≫
タイムアウトが発生しアプリケーションサーバ１でセッションを終了した後に、クライアント２からＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１はクライアント２に対してセッションが既に終了していることを通知する。
【００５４】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ５１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００５５】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ５２）、継続中のセッションであるか判定する（ステップＳ５３）。
【００５６】
既に終了したセッションであると判定した場合、アプリケーションサーバ１のサーバ側セッション管理部５は、ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了したことを示すメッセージを付加し、そのＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ５４）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００５７】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝ＸＸＸＸ
Ｘ−Ｙｏｙａｋｕ−Ｃｏｎｔｅｎｔｓ： Ｃｏｎｔｅｎｔｓ＝Ｉｇｎｏｒｅ
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞…
上記のＨＴＴＰレスポンスメッセージのうち、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ」が、セッションが終了したことを示すメッセージであり、「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝ＸＸＸＸ」が、セッションが存在しないことを示すメッセージである。クライアント２のクライアント側セッション管理部６は、このメッセージを受信すると、セッションが終了したことを認識し、Ｃｏｏｋｉｅを破棄する（ステップＳ５５）。
【００５８】
なお、ステップＳ５３でセッションが継続中であると判定した場合は、通常の処理を行う（ステップＳ５６）。
【００５９】
≪タイムアウト後におけるセッション情報付きでのクライアントからの要求≫
タイムアウトが発生しアプリケーションサーバ１でセッションを終了した後に、クライアント２からセッション開始要求メッセージを含むＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１は破棄（無効化）したセッションＩＤを有効化し、要求された処理を行う。
【００６０】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッションＩＤとセッション開始要求メッセージを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ６１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００６１】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｃｏｏｋｉｅ： Ｓｅｓｓｉｏｎ＿ＩＤ＝１２３４
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッションＩＤが含まれていた場合、記憶しているセッションＩＤとＨＴＴＰリクエストメッセージ中のセッションＩＤとを照合し（ステップＳ６２）、継続中のセッションであるか判定する（ステップＳ６３）。
【００６２】
既に終了したセッションであると判定し、さらにセッション開始要求メッセージが存在する場合、アプリケーションサーバ１のサーバ側セッション管理部５は、破棄（無効化）したセッションＩＤを有効化する（ステップＳ６４）。
【００６３】
セッションＩＤが有効化された後、アプリケーションサーバ１はホストコンピュータ３に対して予約情報の照会を行う（ステップＳ６５）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ６６）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ６７）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例である。
【００６４】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会結果＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ６８）。
【００６５】
≪クライアントからセッション開始と終了とを同時要求≫
クライアント２からセッション開始要求メッセージとセッション終了要求メッセージとを含むＨＴＴＰリクエストメッセージを受信した場合、アプリケーションサーバ１はセッションＩＤを生成せず要求された処理を行う。
【００６６】
クライアント側セッション管理部６は、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージとセッション終了要求メッセージとを付加し、メッセージボディに例えば予約照会の要求を記述したＨＴＴＰリクエストメッセージをアプリケーションサーバ１へ送信する（ステップＳ７１）。下記はアプリケーションサーバ１へ送信されるＨＴＴＰリクエストメッセージの例である。
【００６７】
ＰＯＳＴ ／Ｙｏｙａｋｕ／ＮＡＭＥ＿ｐｒｏｆｉｌｅ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ａｓｐ＿ｃｏｍｐｕｔｅｒ．ｃｏｍ／
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｓｔａｒｔ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｅｓｓｉｏｎ＝Ｅｎｄ
Ｘ−Ｙｏｙａｋｕ−ＰＣＩＤ： ＰＣＩＤ＝８９５ｋｊｈ８
０ｘ０ｄ＋０ｘ０ａ（ＣＲ（キャリッジリターン）＋ＬＦ（ラインフィールド））
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会＞…
アプリケーションサーバ１のサーバ側セッション管理部５は、受信したＨＴＴＰリクエストメッセージにセッション開始要求メッセージとセッション終了要求メッセージとが含まれていた場合、セッションＩＤを生成せずに、メッセージボディに記述されている処理に移行し、例えば、ホストコンピュータ３に対して予約情報の照会を行う（ステップＳ７２）。ホストコンピュータ３が予約情報を取得、返信すると（ステップＳ７３）、アプリケーションサーバ１のサーバ側セッション管理部５は、予約情報を含むＨＴＴＰレスポンスメッセージをクライアント２へ送信する（ステップＳ７４）。下記はクライアント２へ送信されるＨＴＴＰレスポンスメッセージの例であり、処理が正常に行われたことを示すメッセージが「Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００」付加される。
【００６８】
ＨＴＴＰ／１．１ ２０２ Ａｃｃｅｐｔｅｄ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ
Ｘ−Ｙｏｙａｋｕ−Ｓｅｓｓｉｏｎ： Ｓｔａｔｕｓ＝００００
０ｘ０ｄ＋０ｘ０ａ（ＣＲ＋ＬＦ）
＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”１．０” ｅｎｃｏｄｉｎｇ＝”ｓｈｉｆｔ＿ｊｉｓ”？＞
＜予約照会結果＞…
クライアント２は、上記のＨＴＴＰレスポンスメッセージを受信すると、予約情報を表示する（ステップＳ６８）。
【００６９】
このように、ＨＴＴＰリクエストメッセージとＨＴＴＰレスポンスメッセージに、拡張ヘッダとして要求メッセージやステータスを示すメッセージを付加することによって、セッション管理を行うことが可能となる。
【００７０】
【発明の効果】
以上説明したように、本発明によれば、要求元から任意にセッション開始要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによってセッションの開始を行い、また、要求元からセッション終了要求メッセージを付加したＨＴＴＰリクエストメッセージを送信することによって任意にセッションの終了を明示的に行うので、詳細にセッションの継続性を制御することが可能となる。さらに、要求先からＨＴＴＰレスポンスメッセージを送信することによって要求元は要求先の状態を把握することが可能となる。
【図面の簡単な説明】
【図１】本実施形態における機能構成図である。
【図２】セッション管理の手順を示すシーケンス図である。
【図３】セッション管理の手順を示すシーケンス図である。
【図４】セッション管理の手順を示すシーケンス図である。
【符号の説明】
１ アプリケーションサーバ
２ クライアント
３ ホストコンピュータ
４ ネットワーク
５ サーバ側セッション管理部
６ クライアント側セッション管理部
Claims (8)
- 処理の要求元、要求先の２コンピュータ間における接続の継続性を、ＨＴＴＰメッセージのメッセージヘッダによって管理制御するセッション管理方法であって、
前記要求元、および前記要求先の間でセッションを開始する際は、
前記要求元が、ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション開始要求メッセージを付加して前記要求先へ送信する工程と、
前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージを取得すると、セッションを識別するセッションＩＤを生成し記憶する工程と、
前記要求先が、ＨＴＴＰレスポンスメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求元へ送信する工程と、
前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションＩＤを取得し記憶する工程と、
を有することを特徴とするセッション管理方法。 - セッションが開始された後、前記要求元から前記要求先へ処理を要求する際は、
前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッションＩＤを付加して前記要求先へ送信する工程と、
前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッションＩＤを取得すると、記憶している前記セッションＩＤと比較し、一致する場合は、前記要求元と前記要求先との接続が継続されていると判定する工程と、
を有することを特徴とする請求項１に記載のセッション管理方法。 - 前記要求元、および前記要求先の間でセッションを終了する際は、
前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダにセッション終了要求メッセージを付加して前記要求先へ送信する工程と、
前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション終了要求メッセージを取得すると、セッションを識別するセッションＩＤを無効にする工程と、
前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッションが終了した旨のメッセージを付加して前記要求元へ送信する工程と、
前記要求元が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダから前記セッションが終了した旨のメッセージを取得すると、前記セッションＩＤを破棄する工程と、
を有することを特徴とする請求項１乃至請求項２に記載のセッション管理方法。 - セッションが開始された後、前記要求元から前記要求先へ処理を要求した際に、前記要求先が当該処理を実行できない場合、または前記要求元から要求された処理が不当な場合、
前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする請求項１乃至請求項３に記載のセッション管理方法。 - セッションが開始された後、前記要求元から前記要求先へ処理の要求がされないまま所定の期間が経過した場合、
前記要求先が、セッションを識別するセッションＩＤを無効にする工程を有することを特徴とする請求項１乃至請求項４に記載のセッション管理方法。 - 所定の期間が経過し、前記セッションＩＤが無効にされた後、当該セッションＩＤを含む前記ＨＴＴＰリクエストメッセージをもって前記要求元から前記要求先へ処理を要求した場合、
前記要求先が、前記ＨＴＴＰレスポンスメッセージのメッセージヘッダにセッション終了メッセージと、当該要求先の状態を示すメッセージを付加して前記要求元へ送信する工程を有することを特徴とする請求項５に記載のセッション管理方法。 - 所定の期間が経過し、前記セッションＩＤが無効にされた後、セッションを再開する場合は、
前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに当該セッションＩＤと前記セッション開始要求メッセージとを付加して前記要求先へ送信する工程を有することを特徴とする請求項５乃至請求項６に記載のセッション管理方法。 - 前記要求元、および前記要求先の間でセッションを開始する際、
前記要求元が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダに前記セッション開始要求メッセージと前記セッション終了要求メッセージとを付加して前記要求先へ送信する工程と、
前記要求先が、前記ＨＴＴＰリクエストメッセージのメッセージヘッダから前記セッション開始要求メッセージと前記セッション終了要求メッセージとを取得すると、前記セッションＩＤを生成せずに、要求された処理を実行する工程と、
を有することを特徴とする請求項１乃至請求項７に記載のセッション管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003171992A JP2005010913A (ja) | 2003-06-17 | 2003-06-17 | セッション管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003171992A JP2005010913A (ja) | 2003-06-17 | 2003-06-17 | セッション管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005010913A true JP2005010913A (ja) | 2005-01-13 |
Family
ID=34096288
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003171992A Withdrawn JP2005010913A (ja) | 2003-06-17 | 2003-06-17 | セッション管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005010913A (ja) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009502087A (ja) * | 2005-07-19 | 2009-01-22 | サムスン エレクトロニクス カンパニー リミテッド | ネットワーク装置へ非同期通知を伝送する方法及びシステム |
| JP2009086931A (ja) * | 2007-09-28 | 2009-04-23 | Fujitsu Ltd | 書類データ管理方法、書類データ作成方法、サーバおよびコンピュータプログラム |
| JP2013524727A (ja) * | 2010-04-15 | 2013-06-17 | マイクロソフト コーポレーション | Ｈｔｔｐを介した信頼性のあるプロトコルトンネリングのための方法およびシステム |
| US8549408B2 (en) | 2010-03-29 | 2013-10-01 | Sharp Kabushiki Kaisha | Multi-functional peripheral and multi-functional peripheral control system |
| JP2015509313A (ja) * | 2011-12-30 | 2015-03-26 | エフファイブ ネットワークス インコーポレイテッド | １つまたは複数の後続のフローの関連付けおよび管理を行うためにネットワークトラフィック特性を識別するための方法およびそのデバイス |
| USRE47019E1 (en) | 2010-07-14 | 2018-08-28 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
| JP2019079333A (ja) * | 2017-10-25 | 2019-05-23 | キヤノン株式会社 | 通信装置、通信方法、及びプログラム |
| US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
| JP2021140587A (ja) * | 2020-03-06 | 2021-09-16 | 株式会社C−Rise | 情報処理方法、コンピュータプログラム及び情報処理装置 |
-
2003
- 2003-06-17 JP JP2003171992A patent/JP2005010913A/ja not_active Withdrawn
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009502087A (ja) * | 2005-07-19 | 2009-01-22 | サムスン エレクトロニクス カンパニー リミテッド | ネットワーク装置へ非同期通知を伝送する方法及びシステム |
| JP2009086931A (ja) * | 2007-09-28 | 2009-04-23 | Fujitsu Ltd | 書類データ管理方法、書類データ作成方法、サーバおよびコンピュータプログラム |
| US8549408B2 (en) | 2010-03-29 | 2013-10-01 | Sharp Kabushiki Kaisha | Multi-functional peripheral and multi-functional peripheral control system |
| JP2013524727A (ja) * | 2010-04-15 | 2013-06-17 | マイクロソフト コーポレーション | Ｈｔｔｐを介した信頼性のあるプロトコルトンネリングのための方法およびシステム |
| USRE47019E1 (en) | 2010-07-14 | 2018-08-28 | F5 Networks, Inc. | Methods for DNSSEC proxying and deployment amelioration and systems thereof |
| JP2015509313A (ja) * | 2011-12-30 | 2015-03-26 | エフファイブ ネットワークス インコーポレイテッド | １つまたは複数の後続のフローの関連付けおよび管理を行うためにネットワークトラフィック特性を識別するための方法およびそのデバイス |
| US9985976B1 (en) | 2011-12-30 | 2018-05-29 | F5 Networks, Inc. | Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof |
| US10797888B1 (en) | 2016-01-20 | 2020-10-06 | F5 Networks, Inc. | Methods for secured SCEP enrollment for client devices and devices thereof |
| JP2019079333A (ja) * | 2017-10-25 | 2019-05-23 | キヤノン株式会社 | 通信装置、通信方法、及びプログラム |
| JP2021140587A (ja) * | 2020-03-06 | 2021-09-16 | 株式会社C−Rise | 情報処理方法、コンピュータプログラム及び情報処理装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10511567B2 (en) | Network resource identification | |
| US8156243B2 (en) | Request routing | |
| US9021128B2 (en) | Request routing using network computing components | |
| US9451046B2 (en) | Managing CDN registration by a storage provider | |
| US20180159769A1 (en) | Request routing based on class | |
| US9734472B2 (en) | Request routing utilizing cost information | |
| US9251112B2 (en) | Managing content delivery network service providers | |
| US8639817B2 (en) | Content management | |
| JP4859072B2 (ja) | コンテンツ・タイミング方法およびシステム | |
| US20020147652A1 (en) | System and method for distruibuted client state management across a plurality of server computers | |
| EP1695518B1 (en) | Method of redirecting client requests to web services | |
| US8990429B2 (en) | HTTP-based synchronization method and apparatus | |
| CN101997759A (zh) | 一种业务实现方法及业务系统 | |
| JP2005010913A (ja) | セッション管理方法 | |
| JP4988307B2 (ja) | コンテキスト・ベースのナビゲーション | |
| WO2001089170A2 (en) | Method for state preservation in http-based communications | |
| US9288153B2 (en) | Processing encoded content | |
| TW200410519A (en) | World Wide Web connection switching method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060905 |