セッション情報管理方法、セッション情報管理システム、セッション情報管理サーバおよびそのプログラム
【課題】 セッション情報を効率的に処理し、また、各アプリケーションサーバ間でセッション情報の整合性を保つことができるセッション情報管理システムを提供することを課題とする。
【解決手段】 端末と接続された複数の第１の計算機と、その複数の第１の計算機と接続された第２の計算機とを備えたセッション情報管理システムであって、第２の計算機はセッション情報に更新の有無を示す属性を付与し、各第１の計算機はそのセッション情報の属性に基いて前記端末からの要求に応じた処理を継続する。
【解決手段】 端末と接続された複数の第１の計算機と、その複数の第１の計算機と接続された第２の計算機とを備えたセッション情報管理システムであって、第２の計算機はセッション情報に更新の有無を示す属性を付与し、各第１の計算機はそのセッション情報の属性に基いて前記端末からの要求に応じた処理を継続する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション情報を管理するセッション情報管理技術に関連するものである。
【背景技術】
【０００２】
従来、クライアントマシンからの要求を処理するアプリケーションサーバはクラスタ構成で複数設置され、クライアントマシンからの要求が負荷分散機などによって任意のアプリケーションサーバに振り分けられるようになっている。
また、クライアントマシンからの要求を処理しているアプリケーションサーバがダウン（故障などによる作動停止）した場合には、他のアプリケーションサーバがそのセッション情報を引き継いで処理を継続する必要がある。そして、そのセッション情報を引き継ぐ方式としては、たとえば、ＤＢ（Data Base）方式とメモリ方式とが挙げられる。
ＤＢ方式とは、すべてのアプリケーションサーバに接続され、各アプリケーションサーバのセッション情報を順次格納するＤＢサーバを設ける方式である（たとえば特許文献１参照）。
また、メモリ方式は、クラスタを構成するすべてのアプリケーションサーバに各アプリケーションサーバのセッション情報の複製を持たせる方式である。
【特許文献１】特開２００４−７８５５２号公報（段落００１６〜００２７、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に記載の方法では、システムが大掛かりになり、運用が難しく、また、不必要になったセッション情報が永続的に残存してしまうという問題があった。
また、メモリ方式では、クラスタを構成するアプリケーションサーバの数が多くなると、セッション情報の複製のためのオーバヘッドが大きくなるという問題があった。さらに、複製の一部が失敗すると、各アプリケーションサーバ間でセッション情報の整合性が保てなくなるという問題もあった。
そこで、本発明の目的は、セッション情報を処理引き継ぎ時に再利用できることにある。また、本発明の他の目的は、各アプリケーションサーバ間でセッション情報の整合性を保ちながら処理を継続することにある。
【課題を解決するための手段】
【０００４】
前記課題を解決するために、本発明は、端末と接続された複数の第１の計算機と、その複数の第１の計算機と接続された第２の計算機とを備えたセッション情報管理システムであって、前記第２の計算機は、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与し、前記第１の計算機は、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続することを特徴とする。
【発明の効果】
【０００５】
本発明によれば、セッション情報を処理引き継ぎ時に再利用することが可能となる。
【発明を実施するための最良の形態】
【０００６】
以下、本発明の実施の形態に係るセッション情報管理システムを、図面を参照しながら、全体構成、動作概要、データ構成、処理手順の順番で説明する。
【０００７】
＜＜全体構成＞＞
図１は、実施形態のセッション情報管理システムの全体構成を示す図である。セッション情報管理システム１０００は、クライアントマシン３０〜３２、ネットワーク４０、負荷分散機５０および計算機１〜ｎにより構成される。
【０００８】
クライアントマシン３０〜３２は、クライアント（ユーザ）が使用するマシンで、たとえば、ＰＣ（Personal Computer）であり、端末やユーザ端末ともいう。
ネットワーク４０は、広域通信網で、たとえば、インターネットであり、データや要求を送受信するための手段である。クライアントマシン３０〜３２は、ネットワーク４０を介して、負荷分散機５０に接続される。
負荷分散機５０は、クライアントマシン３０〜３２からのアクセスを、通信回線６０経由で計算機１〜(ｎ−１)に振り分けるものであり、いわゆるロードバランサである。
計算機ｎは、通信回線７０を介して計算機１〜（ｎ−１）と接続されている。
【０００９】
＜計算機１〜(ｎ−１)（第１の計算機）＞
計算機１〜(ｎ−１)は、クラスタ構成となっており、負荷分散機５０からの振り分けによってクライアントマシン３０〜３２からのアクセスを受け付け、処理を行う計算機である。この計算機１〜(ｎ−１)は、計算機や、情報処理装置、仮想計算機、論理サーバなどによって、上記処理を実現することができる。そして、計算機１〜(ｎ−１)は、ハードウエア、ソフトウエアともに同様の構成となっているので、以下、代表して計算機１を例にとって説明する。
【００１０】
計算機１は、ＣＰＵ（Central Processing Unit）１１と主記憶装置１２とを含めて構成される。
ＣＰＵ１１は、中央処理装置であり、負荷分散機５０から受信したデータや主記憶装置１２内のプログラム等に基いて、各種演算処理を行う。
主記憶装置１２は、メモリやＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ハードディスクなどから構成され、各種情報を記憶する。主記憶装置１２には、プログラムであるアプリケーションサーバ１００が記憶されている。
【００１１】
アプリケーションサーバ１００は、アプリケーションプログラム１０１、ＨＴＴＰセッション情報登録部１０２およびＨＴＴＰセッション情報管理部１１０から構成される。
アプリケーションプログラム１０１は、クライアントマシン３０〜３２からのアクセスに対応するプログラムで、オブジェクトやプロセス、スレッドで実現可能であり、業務プログラムであってもよい。
ＨＴＴＰセッション情報登録部１０２は、クライアントマシン３０〜３２からのアクセスによるセッション情報を登録するプログラムである。
ＨＴＴＰセッション情報管理部１１０は、ＨＴＴＰセッション情報登録部１０２に登録された情報を管理するプログラムであり、新規作成処理部１１１、更新処理部１１２、グローバルセッション情報取得部１１３、セッション情報管理サーバ状態テーブル１１４およびセッション情報管理サーバ監視部１１５から構成される。これらの各処理部は、プログラムやオブジェクト、プロセス、スレッドで実現してもよい。
【００１２】
新規作成処理部１１１は、ＨＴＴＰセッション情報登録部１０２に新たなＨＴＴＰセッションを作成するプログラムである。なお、「ＨＴＴＰセッション」と表記した場合はＨＴＴＰセッション情報登録部１０２におけるそのセッション情報の記憶領域のことを指し、「ＨＴＴＰセッション情報」と表記した場合はそのＨＴＴＰセッションに格納されるセッション情報を指すものとする。
更新処理部１１２は、アプリケーションサーバ１００内で行われたセッション情報の処理に対応して、クライアントマシン３０〜３２やセッション情報管理サーバ２００へグローバルセッション情報の送信や更新要求をするプログラムである。
グローバルセッション情報取得部１１３は、後記するセッション情報管理サーバ２００のグローバルセッション情報提供部２１４から情報を取得するプログラムである。
セッション情報管理サーバ状態テーブル１１４は、セッション情報管理サーバ２００のアドレスや障害の有無などを記憶するテーブルである。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ２００の障害の有無を、セッション情報管理サーバ２００の定時発信機能などにより検知し、その検知結果をセッション情報管理サーバ状態テーブル１１４に書き込むプログラムである。
【００１３】
＜計算機ｎ（第２の計算機）＞
計算機ｎは、計算機１〜(ｎ−１)と同様のハードウエアを有する計算機であり、ＣＰＵ２１と主記憶装置２２を含んで構成される。主記憶装置２２には、計算機１〜(ｎ−１)に関するセッション情報を管理するためのプログラムであるセッション情報管理サーバ２００が記憶されている。
セッション情報管理サーバ２００は、グローバルセッション情報登録部２０１およびグローバルセッション情報管理部２１０とから構成される。
【００１４】
グローバルセッション情報登録部２０１は、各アプリケーションサーバ１００のＨＴＴＰセッション情報のうち、他のアプリケーションサーバ１００に引き継ぐ必要のあるものを各アプリケーションサーバ１００から受信して登録するプログラムである。
グローバルセッション情報管理部２１０は、新規作成処理部２１１、更新処理部２１２、削除処理部２１３およびグローバルセッション情報提供部２１４から構成される。
【００１５】
新規作成処理部２１１は、アプリケーションサーバ１００の新規作成処理部１１１からの要求を受けて、グローバルセッション情報登録部２０１にグローバルセッションを作成するプログラムである。
更新処理部２１２は、アプリケーションサーバ１００の更新処理部１１２からの要求を受けて、グローバルセッション情報登録部２０１に対してグローバルセッション情報の追加、更新、削除などを行うプログラムである。なお、「グローバルセッション」と表記した場合はグローバルセッション情報登録部２０１におけるそのセッション情報の記憶領域のことを指し、「グローバルセッション情報」と表記した場合はそのグローバルセッションに格納されるセッション情報を指すものとする。
削除処理部２１３は、グローバルセッション情報登録部２０１において有効期限が切れたグローバルセッションを削除するプログラムである。
グローバルセッション情報提供部２１４は、アプリケーションサーバ１００のグローバルセッション情報取得部１１３からの要求を受けて、グローバルセッション情報登録部２０１を参照し、必要なグローバルセッション情報をグローバルセッション情報取得部１１３に送信するプログラムである。
なお、各処理部は、オブジェクトやスレッド、プロセスによって実現可能である。
【００１６】
＜＜動作概要＞＞
続いて、セッション情報管理システム１０００の動作概要について説明する。ここでは、図２Ａ〜図２Ｅを参照しながら、アプリケーションサーバ１００間でセッション情報を引き継ぐ動作の概要について説明する。
【００１７】
図２Ａ〜図２Ｅの各図において、クライアントマシン３０〜３２はネットワーク４０と負荷分散機５０を経由してアプリケーションサーバ１００ａ，１００ｂと接続され、また、アプリケーションサーバ１００ａ，１００ｂはセッション情報管理サーバ２００に接続されている。なお、アプリケーションサーバ１００ａ，１００ｂは、図１のアプリケーションサーバ１００と同様のプログラムである。
【００１８】
まず、図２Ａに示すように、アプリケーションサーバ１００ａは、クライアントマシン３０〜３２のいずれか（たとえばクライアントマシン３０）からのアクセスにより作成されたＨＴＴＰセッション情報のうち、他のアプリケーションサーバに引き継ぐべきＨＴＴＰセッション情報（key1＝value1、key2＝value2、key3＝value3）を、セッション情報管理サーバ２００のグローバルセッション情報に含めるように複製する（同図（１））。具体的には、アプリケーションサーバ１００ａが、そのＨＴＴＰセッション情報をセッション情報管理サーバ２００に送信し、セッション情報管理サーバ２００がそれをグローバルセッション情報として登録する。なお、key1〜3、value1〜3については、後記の図３で説明する。
【００１９】
この場合、アプリケーションサーバ１００ａで作成されたＨＴＴＰセッション情報（key1＝value1、key2＝value2、key3＝value3）、および、セッション情報管理サーバ２００に複製されたグローバルセッション情報（key1＝value1、key2＝value2、key3＝value3）は、セッション情報管理サーバ２００によって、２つの属性（不変属性／更新属性）のうち不変を示す不変属性が与えられる。なお、不変属性とは、ＨＴＴＰセッション情報が更新されていないことを意味する。また、更新属性とは、ＨＴＴＰセッション情報が更新されたことを意味する。
また、ＨＴＴＰセッション情報の“key”は項目を、“value”はその項目に対応する値を示すものであるが、その詳細については図３の説明のところで述べる。
【００２０】
その後、図２Ａに示したアプリケーションサーバ１００ａの処理中、図２Ｂに示すように、アプリケーションサーバ１００ａに障害が発生した場合（同図（１））、負荷分散機５０はクライアントマシン３０からのアクセスをアプリケーションサーバ１００ｂに切り替え、セッション情報管理サーバ２００はグローバルセッション情報（key1＝value1、key2＝value2、key3＝value3）を不変属性としたまま、アプリケーションサーバ１００ｂに引き継ぐ（同図（２））。
これによって、アプリケーションサーバ１００ａにアクセスしていたクライアントマシン３０は、再ログインなどの操作をすることなく、引き続きアプリケーションサーバ１００ｂに対してアクセスを切り替えることができる。したがって、クライアントマシン３０に対する処理がアプリケーションサーバ１００ｂで継続されることとなる。
【００２１】
そして、図２Ｃに示すように、アプリケーションサーバ１００ｂのＨＴＴＰセッション情報が書き換えられて更新された場合、アプリケーションサーバ１００ｂはその更新情報をセッション情報管理サーバ２００に送信する。図２Ｃでは、たとえば、“key2”が“value2”から“value2'”に更新されたものとする。
更新情報を受信したセッション情報管理サーバ２００は、その更新情報に基いて、グローバルセッション情報のうち“key2”を“value2”から“value2'”に更新し、あわせて“key2”の属性を更新属性に変更する。
なお、この時点では、アプリケーションサーバ１００ｂのＨＴＴＰセッション情報の“key2”の属性は不変属性のままである。
【００２２】
続いて、図２Ｄに示すように、セッション情報管理サーバ２００は、アプリケーションサーバ１００ａ，１００ｂに、“key2”の属性が不変属性から更新属性に変更されたことを通知する。
これを受けて、アプリケーションサーバ１００ａは、“key2”の属性を不変属性から更新属性に変更する。また、アプリケーションサーバ１００ｂは、“key2”の属性を不変属性から更新属性に変更する。
このように、セッション情報管理サーバ２００がアプリケーションサーバ１００ｂに対して、“key2”の属性変更のみを送信して、その変更内容を送信しないことによって、各サーバの処理負担を軽減することができる。つまり、この属性変更のみの送信であれば、その変更時１回だけ送信すればよく、その後に同じセッション情報に関して書き換えが行われてもセッション情報管理サーバ２００からアプリケーションサーバ１００ｂに対して送信を行う必要がないのである。
なお、アプリケーションサーバ１００ｂにおいて、“key2”の属性を不変属性から更新属性に変更するタイミングが、実際に“key2”が更新されたときではなく、前記のようにセッション情報管理サーバ２００からの通知を受けたときにしているのは、アプリケーションサーバ１００ａと１００ｂとの整合性を保つためである。それは、より具体的には、図２Ｃにおいて、アプリケーションサーバ１００ａの“key2”の属性が不変属性であるにもかかわらず、アプリケーションサーバ１００ｂの“key2”の属性が更新属性である、といった不整合状態を避けるためである。
【００２３】
次に、図２Ｅにおいて、セッション情報管理サーバ２００に障害が発生した場合、アプリケーションサーバ１００ａ，１００ｂは、更新属性のＨＴＴＰセッション情報（“key2”）を削除し、不変属性のＨＴＴＰセッション情報（“key1”と“key3”）を残すことで、アプリケーションサーバ１００ａと１００ｂの整合性を保つことができる。
つまり、たとえば、ログインに使用されるユーザＩＤなどは、一度も更新されることがないので、不変属性のＨＴＴＰセッション情報としてアプリケーションサーバ１００ａと１００ｂに残る。一方、たとえば、画面のページＩＤなどは、一度でも更新されると属性が更新属性のＨＴＴＰセッション情報になり、セッション情報管理サーバ２００に障害が起きたときにアプリケーションサーバ１００ａ，１００ｂから削除されることになるが、ユーザＩＤなどに比べれば重要性の低い情報であり、アプリケーションサーバ間の整合性維持、セッション情報管理システム１０００全体の処理効率などの点で有益な効果を奏すると言える。
また、本例では、アプリケーションサーバ１００に障害が起きた場合について説明したが、アプリケーションサーバ１００が１つあるいは複数削除される縮退運転が行われたときにも適用可能である。さらに、アプリケーションサーバ１００が追加された場合でも、セッション情報管理サーバ２００からセッション情報をコピーすることにより、追加されたアプリケーションサーバ１００でもセッションを利用することが可能となる。
【００２４】
＜＜データ構成＞＞
＜ＨＴＴＰセッション情報登録部のデータ構成＞
続いて、図１のアプリケーションサーバ１００におけるＨＴＴＰセッション情報登録部１０２のデータ構成について、図３を参照しながら説明する。図３は、ＨＴＴＰセッション情報登録部１０２のデータ構成を表わした図である。
図３において、２つのセッション情報が、ＨＴＴＰセッションＩＤ３０１、ＫＥＹ３０２、ＶＡＬＵＥ３０３、属性３０４の４項目を含んで表示されている。
【００２５】
ＨＴＴＰセッションＩＤ３０１は、そのアプリケーションサーバ１００内でそのセッションを一意に特定する識別子であり、ここではＨＴＴＰセッションＩＤ１とＨＴＴＰセッションＩＤ２の２つが示されている。
ＫＥＹ３０２は、セッション情報を構成するそれぞれの情報の種類を示したものである。“UserID”は、クライアント（ユーザ）がクライアントマシン３０〜３２でログインを行うためのＩＤである。“Role”は、“UserID”などによってクライアントマシン３０〜３２に与えられる権限を意味するものである。“PageID”は、クライアント（ユーザ）がクライアントマシン３０〜３２で見ている画面のページＩＤである。“Search”は、検索を行った結果を表わしている。“CartID”は、図１のアプリケーションサーバ１００におけるアプリケーションプログラム１０１のクライアントへの提供サービスがオンラインショッピングなどであった場合に、画面上で商品を入れる入れ物のＩＤを表わすものである。
【００２６】
ＶＡＬＵＥ３０３は、ＫＥＹ３０２に対応する実際の値であり、ここでは、上から順に“user1”、“role1”、“page1”、“searchResult1”、“cart1”が格納されている。
属性３０４は、ＫＥＹ３０２として表わされる各情報それぞれが属する属性を表わしている。属性は、前記したように不変属性と更新属性の２種類であり、その２種類に属さないものは「−」で表記されている。
なお、不変属性あるいは更新属性を付与されるセッション情報は、他のアプリケーションサーバ１００へも引き継ぐべきセッション情報であり、アプリケーションサーバ１００において、予めＫＥＹ３０２の種類によって設定された選択条件により、どのセッション情報が引き継ぐべきセッション情報に該当するかが決められている。
不変属性は、図２Ａ〜図２Ｅで説明したように各アプリケーションサーバが共有すべき情報のうち、そのセッション内で変更されないものであることを表わす。
また、更新属性は、各アプリケーションサーバが共有すべき情報のうち、そのセッション内で変更されるものであることを表わす。
さらに、「−」と表記された情報は、各アプリケーションサーバが共有する必要のない情報であることを表わすものである。
【００２７】
＜グローバルセッション情報登録部のデータ構成＞
次に、図１のセッション情報管理サーバ２００におけるグローバルセッション情報登録部２０１のデータ構成について、図４を参照しながら説明する。図４は、グローバルセッション情報登録部２０１のデータ構成を表わした図である。
図４において、２つのセッション情報が、グローバルセッションＩＤ４０１、ＫＥＹ４０２、ＶＡＬＵＥ４０３、属性４０４の４項目に対応した形で格納されている。
【００２８】
グローバルセッションＩＤ４０１は、セッション情報管理サーバ２００内でそのセッションを一意に特定する識別子であり、ここではグローバルセッションＩＤ１とグローバルセッションＩＤ２の２つが示されている。
ＫＥＹ４０２、ＶＡＬＵＥ４０３および属性４０４は、図３のＫＥＹ３０２、ＶＡＬＵＥ３０３、属性３０４と同様であるので、説明を省略する。
【００２９】
＜＜処理手順＞＞
続いて、セッション情報管理システム１０００の具体的な処理手順について説明する。
＜処理１＞
まず、図５を参照しながら、処理１（ＨＴＴＰセッションが存在しない場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション未作成、グローバルセッション情報登録部２０１がグローバルセッション未作成の状態から処理が開始される。
【００３０】
処理１は、アプリケーションサーバ１００とセッション情報管理サーバ２００に、それぞれセッション情報を作成する処理であり、図２Ａにおける動作に相当する（図５のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ａに相当）。
図５は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、アプリケーションプログラム１０１にリクエストの処理を要求する（Ｓ５０１）。
アプリケーションプログラム１０１は、新規作成処理部１１１にＨＴＴＰセッションの新規作成を要求する（Ｓ５０２）。
新規作成処理部１１１は、ＨＴＴＰセッション情報登録部１０２にＨＴＴＰセッションを作成し（Ｓ５０３）、また、そのＨＴＴＰセッションに対応するグローバルセッションＩＤ４０１（図４参照）を発行する。
新規作成処理部１１１は、新規作成処理部２１１に当該グローバルセッションＩＤ４０１に対応するグローバルセッションの作成を要求する（Ｓ５０４）。
【００３１】
新規作成処理部２１１は、当該グローバルセッションＩＤ４０１に対応するグローバルセッションをグローバルセッション情報登録部２０１に作成する（Ｓ５０５）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２を参照し、更新すべき情報があれば更新を行う（Ｓ５０６）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ５０７）。
【００３２】
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１への更新を要求する（Ｓ５０８）。
更新処理部２１２は、グローバルセッション情報登録部２０１を参照し、更新すべき情報があれば更新を行う（Ｓ５０９）。
更新処理部１１２は、グローバルセッションＩＤ４０１（図４）を含めたレスポンスをクライアントマシン３０に送信する（Ｓ５１０）。これを受けて、クライアントマシン３０は、グローバルセッションＩＤ４０１（図４）を自身に登録する。
【００３３】
＜処理２＞
次に、図６を参照しながら、処理２（ＨＴＴＰセッションが存在する場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態から処理が開始される。
【００３４】
処理２は、セッション情報の属性を不変属性から更新に変更する処理であり、図２Ｃ・図２Ｄにおける動作に相当する（図６のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ｂに相当）。
図６は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ６０１）。
グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に最新のグローバルセッション情報の提供を要求する（Ｓ６０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１を参照し、グローバルセッション情報が更新されているか確認する（Ｓ６０３）。
【００３５】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、グローバルセッション情報が更新されている場合は最新のグローバルセッション情報を送信し、更新されていない場合はその旨を送信する（Ｓ６０４）。
グローバルセッション情報取得部１１３は、Ｓ６０４で最新のグローバルセッション情報を受信している場合は、ＨＴＴＰセッション情報登録部１０２において、対応するＨＴＴＰセッション情報を更新する（Ｓ６０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ６０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２を参照し、更新すべき情報があれば更新を行う（Ｓ６０７）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ６０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１への更新を要求する（Ｓ６０９）。
【００３６】
更新処理部２１２は、グローバルセッション情報登録部２０１を参照し、更新すべき情報があれば更新を行う。更新処理部２１２は、その際、不変属性の情報を更新するときは、その属性を更新属性に変更し（Ｓ６１０）、すべてのアプリケーションサーバ１００にその情報の属性の変更（不変属性→更新属性）を要求する（Ｓ６１１）。
セッション情報管理サーバ監視部１１５は、当該情報の属性を不変属性から更新属性に変更する（Ｓ６１２）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ６１３）。
この処理２の動作により、更新のあった情報を不変属性から更新属性に変更することができる。
【００３７】
＜処理３＞
続いて、図７を参照しながら、処理３（ＨＴＴＰセッションが削除される場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態から処理が開始される。
【００３８】
処理３は、クライアントマシン３０からの要求によって、ＨＴＴＰセッション情報登録部１０２とグローバルセッション情報登録部２０１のそれぞれのセッション情報を削除する処理である。
図７は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ７０１）。
グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に最新のグローバルセッション情報の提供を要求する（Ｓ７０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１を参照し、グローバルセッション情報が更新されているか確認する（Ｓ７０３）。
【００３９】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、グローバルセッション情報が更新されている場合は最新のグローバルセッション情報を送信し、更新されていない場合はその旨を送信する（Ｓ７０４）。
グローバルセッション情報取得部１１３は、Ｓ７０４で最新のグローバルセッション情報を受信している場合は、ＨＴＴＰセッション情報登録部１０２において、対応するＨＴＴＰセッション情報を更新する（Ｓ７０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ７０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッションを削除する（Ｓ７０７）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ７０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１からのグローバルセッション情報の削除を要求する（Ｓ７０９）。
更新処理部２１２は、グローバルセッション情報登録部２０１からグローバルセッション情報を削除する（Ｓ７１０）。
更新処理部１１２は、クライアントマシン３０に対してグローバルセッションＩＤ４０１（図４）を削除させるレスポンスを送信する（Ｓ７１１）。
【００４０】
＜処理４＞
次に、図８を参照しながら、処理４（ＨＴＴＰセッションの有効期限が切れた場合の処理）について詳細に説明する。処理４は、ＨＴＴＰセッションの有効期限が切れた場合の、セッション情報管理サーバ２００における処理を示した処理フロー図である。
削除処理部２１３は、自身が保有するＨＴＴＰセッションの有効期限情報により、ＨＴＴＰセッションの有効期限が切れたことを検知した場合、グローバルセッション情報登録部２０１からそのＨＴＴＰセッションに対応するグローバルセッションを削除する（Ｓ８０１）。
【００４１】
なお、ＨＴＴＰセッションの有効期限情報は、削除処理部２１３自身が保有していなくても、専用テーブルなど（図示なし）に記憶されるようにしておいて、削除処理部２１３がその専用テーブルなどを参照するようにしてもよい。
この処理４の動作により、不要なセッションがセッション情報管理サーバ２００に蓄積することを回避できる。
【００４２】
＜処理５＞
続いて、図９を参照しながら、処理５（グローバルセッション情報を引き継ぐ場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション未作成、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態で処理が開始される。
【００４３】
処理５は、リクエスト処理を行うアプリケーションサーバ１００が切り替わった場合の処理であり、図２Ｂにおける動作に相当する（図９のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ｂに相当）。
図９は、前記条件のときの処理フロー図である。
この処理５は、クライアントマシン３０からのリクエストの処理を行うアプリケーションサーバ１００が、障害発生などよって切り替わった直後から始まる処理である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ９０１）。
クライアントマシン３０からのリクエスト情報内のＨＴＴＰセッションＩＤに対応するＨＴＴＰセッションがＨＴＴＰセッション情報登録部１０２に存在しない場合、グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に、前記リクエスト情報内のグローバルセッションＩＤに対応するグローバルセッション情報の提供を要求する（Ｓ９０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１から当該グローバルセッション情報を取得する（Ｓ９０３）。
【００４４】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、当該グローバルセッション情報を送信する（Ｓ９０４）。
グローバルセッション情報取得部１１３は、ＨＴＴＰセッション情報登録部１０２に、当該グローバルセッション情報を新規のＨＴＴＰセッション情報として格納する（Ｓ９０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ９０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッション情報を使用し、リクエスト処理を行う（Ｓ９０７）。
【００４５】
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ９０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報の更新を要求する（Ｓ９０９）。
更新処理部２１２は、グローバルセッション情報登録部２０１のグローバルセッション情報を更新する（Ｓ９１０）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ９１１）。
【００４６】
このように、クライアントマシン３０からのリクエストの処理を引き継ぐアプリケーションサーバ１００は、セッション情報管理サーバ２００から必要なセッション情報を引き継ぐことができる。これによって、クライアントマシン３０は、再ログインなどの面倒な操作をすることなく、円滑にアプリケーションサーバ１００へのアクセス（リクエスト）を継続することができる。
【００４７】
＜処理６＞
次に、図１０を参照しながら、処理６（セッション情報管理サーバ２００に障害が発生した場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態で処理が開始される。
【００４８】
処理６は、セッション情報管理サーバ２００に障害が発生したときの処理であり、図２Ｅにおける動作に相当する（図１０のアプリケーションサーバ１００は図２Ｅのアプリケーションサーバ１００ａあるいは１００ｂのいずれかに相当）。
図１０は、前記条件のときの処理フロー図である。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ２００に障害が発生していることを検知する（Ｓ１００１）。なお、この障害検知の方法としては、たとえば、セッション情報管理サーバ監視部１１５がセッション情報管理サーバ２００からの定時発信を受信しなかったことをセッション情報管理サーバ２００の障害と判断する方法が挙げられるが、その方法に限定されるものではなく、他の方法を用いてもよい。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ状態テーブル１１４のセッション情報管理サーバ２００の状態を「障害」と書き換える（Ｓ１００２）。
クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ１００３）。
【００４９】
グローバルセッション情報取得部１１３は、セッション情報管理サーバ２００に障害が発生しているので、そのとき処理中のリクエストに対応するＨＴＴＰセッション情報のうち更新属性の情報を削除する（Ｓ１００４）。
このＳ１００４の動作は、複数のアプリケーションサーバ１００間の整合性を保つためのものである。つまり、セッション情報管理サーバ２００に障害が発生していて、これ以降はアプリケーションサーバ１００間でセッション情報の共有ができないため、複数のアプリケーションサーバ１００間で内容が整合していない更新属性の情報を削除することによって、複数のアプリケーションサーバ１００間の不整合状態を回避しておくのである。一方、不変属性の情報は、変更されることがないので削除する必要はなく、また、削除しないことによって、アプリケーションサーバ１００が切り替わったときでも、クライアントマシン３０において再ログインなどの面倒な操作が不要となり、利便性の高いセッション情報管理システム１０００を実現することができる。
【００５０】
図１０の処理６に戻って、グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ１００５）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッション情報のうち残存している不変属性の情報を使用して、リクエスト処理を行う（Ｓ１００６）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ１００７）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ１００８）。
【００５１】
このように、実施の形態に係るセッション情報管理システム１０００によれば、セッション情報のうち引き継ぐべき情報を２つの属性（不変属性／更新属性）に分けて、アプリケーションサーバ１００およびセッション情報管理サーバ２００で共有する。そして、セッション情報管理サーバ２００に障害が発生した場合には、更新属性の情報を削除して不変属性の情報のみをアプリケーションサーバ１００に残すことで、複数のアプリケーションサーバ１００間におけるセッション情報の整合性を維持することができる。
また、アプリケーションサーバ１００からセッション情報を最初にセッション情報管理サーバ２００に記憶させるときはすべて不変属性の情報とし、その後、１回でも変更のあった情報を更新属性の情報と変更することで、自動的に適切な属性を決定および付与することができ、情報ごとの属性を事前に登録しておくなどの煩雑な操作が不要で利便性の高いセッション情報管理システム１０００を実現することができる。ただし、セッション情報の種類（図３のＫＥＹ３０２の種類）が少ない場合などは、予め個別のセッション情報に関する属性を手動で設定するようにしておいてもよい。
【００５２】
以上で実施の形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。たとえば、クライアントマシンからのアクセスを複数のアプリケーションサーバに振り分けるには、負荷分散機を使わなくても、ラウンドロビン方式などを採用することにより実現してもよい。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００５３】
【図１】実施の形態に係るセッション情報管理システムの全体構成を示す図である。
【図２Ａ】セッション情報管理システムにおけるセッション情報の複製動作を示す図である。
【図２Ｂ】セッション情報管理システムにおいてアプリケーションサーバで障害が発生した場合の動作を示す図である。
【図２Ｃ】セッション情報管理システムにおけるセッション情報の書換え動作を示す図である。
【図２Ｄ】セッション情報管理システムにおけるセッション情報の属性変更動作を示す図である。
【図２Ｅ】セッション情報管理システムにおいてセッション情報管理サーバで障害が発生した場合の動作を示す図である。
【図３】ＨＴＴＰセッション情報登録部のデータ構成を表わした図である。
【図４】グローバルセッション情報登録部のデータ構成を表わした図である。
【図５】ＨＴＴＰセッションが存在しない場合の処理フロー図である。
【図６】ＨＴＴＰセッションが存在する場合の処理フロー図である。
【図７】ＨＴＴＰセッションを削除する場合の処理フロー図である。
【図８】ＨＴＴＰセッションの有効期限が切れた場合の処理フロー図である。
【図９】グローバルセッション情報を引き継ぐ場合の処理フロー図である。
【図１０】セッション情報管理サーバに障害が発生した場合の処理フロー図である。
【符号の説明】
【００５４】
１〜ｎ 計算機
３０〜３２ クライアントマシン
４０ ネットワーク
５０ 負荷分散機
６０、７０ 通信回線
１００ アプリケーションサーバ
２００ セッション情報管理サーバ
１０００ セッション情報管理システム
【技術分野】
【０００１】
本発明は、セッション情報を管理するセッション情報管理技術に関連するものである。
【背景技術】
【０００２】
従来、クライアントマシンからの要求を処理するアプリケーションサーバはクラスタ構成で複数設置され、クライアントマシンからの要求が負荷分散機などによって任意のアプリケーションサーバに振り分けられるようになっている。
また、クライアントマシンからの要求を処理しているアプリケーションサーバがダウン（故障などによる作動停止）した場合には、他のアプリケーションサーバがそのセッション情報を引き継いで処理を継続する必要がある。そして、そのセッション情報を引き継ぐ方式としては、たとえば、ＤＢ（Data Base）方式とメモリ方式とが挙げられる。
ＤＢ方式とは、すべてのアプリケーションサーバに接続され、各アプリケーションサーバのセッション情報を順次格納するＤＢサーバを設ける方式である（たとえば特許文献１参照）。
また、メモリ方式は、クラスタを構成するすべてのアプリケーションサーバに各アプリケーションサーバのセッション情報の複製を持たせる方式である。
【特許文献１】特開２００４−７８５５２号公報（段落００１６〜００２７、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に記載の方法では、システムが大掛かりになり、運用が難しく、また、不必要になったセッション情報が永続的に残存してしまうという問題があった。
また、メモリ方式では、クラスタを構成するアプリケーションサーバの数が多くなると、セッション情報の複製のためのオーバヘッドが大きくなるという問題があった。さらに、複製の一部が失敗すると、各アプリケーションサーバ間でセッション情報の整合性が保てなくなるという問題もあった。
そこで、本発明の目的は、セッション情報を処理引き継ぎ時に再利用できることにある。また、本発明の他の目的は、各アプリケーションサーバ間でセッション情報の整合性を保ちながら処理を継続することにある。
【課題を解決するための手段】
【０００４】
前記課題を解決するために、本発明は、端末と接続された複数の第１の計算機と、その複数の第１の計算機と接続された第２の計算機とを備えたセッション情報管理システムであって、前記第２の計算機は、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与し、前記第１の計算機は、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続することを特徴とする。
【発明の効果】
【０００５】
本発明によれば、セッション情報を処理引き継ぎ時に再利用することが可能となる。
【発明を実施するための最良の形態】
【０００６】
以下、本発明の実施の形態に係るセッション情報管理システムを、図面を参照しながら、全体構成、動作概要、データ構成、処理手順の順番で説明する。
【０００７】
＜＜全体構成＞＞
図１は、実施形態のセッション情報管理システムの全体構成を示す図である。セッション情報管理システム１０００は、クライアントマシン３０〜３２、ネットワーク４０、負荷分散機５０および計算機１〜ｎにより構成される。
【０００８】
クライアントマシン３０〜３２は、クライアント（ユーザ）が使用するマシンで、たとえば、ＰＣ（Personal Computer）であり、端末やユーザ端末ともいう。
ネットワーク４０は、広域通信網で、たとえば、インターネットであり、データや要求を送受信するための手段である。クライアントマシン３０〜３２は、ネットワーク４０を介して、負荷分散機５０に接続される。
負荷分散機５０は、クライアントマシン３０〜３２からのアクセスを、通信回線６０経由で計算機１〜(ｎ−１)に振り分けるものであり、いわゆるロードバランサである。
計算機ｎは、通信回線７０を介して計算機１〜（ｎ−１）と接続されている。
【０００９】
＜計算機１〜(ｎ−１)（第１の計算機）＞
計算機１〜(ｎ−１)は、クラスタ構成となっており、負荷分散機５０からの振り分けによってクライアントマシン３０〜３２からのアクセスを受け付け、処理を行う計算機である。この計算機１〜(ｎ−１)は、計算機や、情報処理装置、仮想計算機、論理サーバなどによって、上記処理を実現することができる。そして、計算機１〜(ｎ−１)は、ハードウエア、ソフトウエアともに同様の構成となっているので、以下、代表して計算機１を例にとって説明する。
【００１０】
計算機１は、ＣＰＵ（Central Processing Unit）１１と主記憶装置１２とを含めて構成される。
ＣＰＵ１１は、中央処理装置であり、負荷分散機５０から受信したデータや主記憶装置１２内のプログラム等に基いて、各種演算処理を行う。
主記憶装置１２は、メモリやＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ハードディスクなどから構成され、各種情報を記憶する。主記憶装置１２には、プログラムであるアプリケーションサーバ１００が記憶されている。
【００１１】
アプリケーションサーバ１００は、アプリケーションプログラム１０１、ＨＴＴＰセッション情報登録部１０２およびＨＴＴＰセッション情報管理部１１０から構成される。
アプリケーションプログラム１０１は、クライアントマシン３０〜３２からのアクセスに対応するプログラムで、オブジェクトやプロセス、スレッドで実現可能であり、業務プログラムであってもよい。
ＨＴＴＰセッション情報登録部１０２は、クライアントマシン３０〜３２からのアクセスによるセッション情報を登録するプログラムである。
ＨＴＴＰセッション情報管理部１１０は、ＨＴＴＰセッション情報登録部１０２に登録された情報を管理するプログラムであり、新規作成処理部１１１、更新処理部１１２、グローバルセッション情報取得部１１３、セッション情報管理サーバ状態テーブル１１４およびセッション情報管理サーバ監視部１１５から構成される。これらの各処理部は、プログラムやオブジェクト、プロセス、スレッドで実現してもよい。
【００１２】
新規作成処理部１１１は、ＨＴＴＰセッション情報登録部１０２に新たなＨＴＴＰセッションを作成するプログラムである。なお、「ＨＴＴＰセッション」と表記した場合はＨＴＴＰセッション情報登録部１０２におけるそのセッション情報の記憶領域のことを指し、「ＨＴＴＰセッション情報」と表記した場合はそのＨＴＴＰセッションに格納されるセッション情報を指すものとする。
更新処理部１１２は、アプリケーションサーバ１００内で行われたセッション情報の処理に対応して、クライアントマシン３０〜３２やセッション情報管理サーバ２００へグローバルセッション情報の送信や更新要求をするプログラムである。
グローバルセッション情報取得部１１３は、後記するセッション情報管理サーバ２００のグローバルセッション情報提供部２１４から情報を取得するプログラムである。
セッション情報管理サーバ状態テーブル１１４は、セッション情報管理サーバ２００のアドレスや障害の有無などを記憶するテーブルである。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ２００の障害の有無を、セッション情報管理サーバ２００の定時発信機能などにより検知し、その検知結果をセッション情報管理サーバ状態テーブル１１４に書き込むプログラムである。
【００１３】
＜計算機ｎ（第２の計算機）＞
計算機ｎは、計算機１〜(ｎ−１)と同様のハードウエアを有する計算機であり、ＣＰＵ２１と主記憶装置２２を含んで構成される。主記憶装置２２には、計算機１〜(ｎ−１)に関するセッション情報を管理するためのプログラムであるセッション情報管理サーバ２００が記憶されている。
セッション情報管理サーバ２００は、グローバルセッション情報登録部２０１およびグローバルセッション情報管理部２１０とから構成される。
【００１４】
グローバルセッション情報登録部２０１は、各アプリケーションサーバ１００のＨＴＴＰセッション情報のうち、他のアプリケーションサーバ１００に引き継ぐ必要のあるものを各アプリケーションサーバ１００から受信して登録するプログラムである。
グローバルセッション情報管理部２１０は、新規作成処理部２１１、更新処理部２１２、削除処理部２１３およびグローバルセッション情報提供部２１４から構成される。
【００１５】
新規作成処理部２１１は、アプリケーションサーバ１００の新規作成処理部１１１からの要求を受けて、グローバルセッション情報登録部２０１にグローバルセッションを作成するプログラムである。
更新処理部２１２は、アプリケーションサーバ１００の更新処理部１１２からの要求を受けて、グローバルセッション情報登録部２０１に対してグローバルセッション情報の追加、更新、削除などを行うプログラムである。なお、「グローバルセッション」と表記した場合はグローバルセッション情報登録部２０１におけるそのセッション情報の記憶領域のことを指し、「グローバルセッション情報」と表記した場合はそのグローバルセッションに格納されるセッション情報を指すものとする。
削除処理部２１３は、グローバルセッション情報登録部２０１において有効期限が切れたグローバルセッションを削除するプログラムである。
グローバルセッション情報提供部２１４は、アプリケーションサーバ１００のグローバルセッション情報取得部１１３からの要求を受けて、グローバルセッション情報登録部２０１を参照し、必要なグローバルセッション情報をグローバルセッション情報取得部１１３に送信するプログラムである。
なお、各処理部は、オブジェクトやスレッド、プロセスによって実現可能である。
【００１６】
＜＜動作概要＞＞
続いて、セッション情報管理システム１０００の動作概要について説明する。ここでは、図２Ａ〜図２Ｅを参照しながら、アプリケーションサーバ１００間でセッション情報を引き継ぐ動作の概要について説明する。
【００１７】
図２Ａ〜図２Ｅの各図において、クライアントマシン３０〜３２はネットワーク４０と負荷分散機５０を経由してアプリケーションサーバ１００ａ，１００ｂと接続され、また、アプリケーションサーバ１００ａ，１００ｂはセッション情報管理サーバ２００に接続されている。なお、アプリケーションサーバ１００ａ，１００ｂは、図１のアプリケーションサーバ１００と同様のプログラムである。
【００１８】
まず、図２Ａに示すように、アプリケーションサーバ１００ａは、クライアントマシン３０〜３２のいずれか（たとえばクライアントマシン３０）からのアクセスにより作成されたＨＴＴＰセッション情報のうち、他のアプリケーションサーバに引き継ぐべきＨＴＴＰセッション情報（key1＝value1、key2＝value2、key3＝value3）を、セッション情報管理サーバ２００のグローバルセッション情報に含めるように複製する（同図（１））。具体的には、アプリケーションサーバ１００ａが、そのＨＴＴＰセッション情報をセッション情報管理サーバ２００に送信し、セッション情報管理サーバ２００がそれをグローバルセッション情報として登録する。なお、key1〜3、value1〜3については、後記の図３で説明する。
【００１９】
この場合、アプリケーションサーバ１００ａで作成されたＨＴＴＰセッション情報（key1＝value1、key2＝value2、key3＝value3）、および、セッション情報管理サーバ２００に複製されたグローバルセッション情報（key1＝value1、key2＝value2、key3＝value3）は、セッション情報管理サーバ２００によって、２つの属性（不変属性／更新属性）のうち不変を示す不変属性が与えられる。なお、不変属性とは、ＨＴＴＰセッション情報が更新されていないことを意味する。また、更新属性とは、ＨＴＴＰセッション情報が更新されたことを意味する。
また、ＨＴＴＰセッション情報の“key”は項目を、“value”はその項目に対応する値を示すものであるが、その詳細については図３の説明のところで述べる。
【００２０】
その後、図２Ａに示したアプリケーションサーバ１００ａの処理中、図２Ｂに示すように、アプリケーションサーバ１００ａに障害が発生した場合（同図（１））、負荷分散機５０はクライアントマシン３０からのアクセスをアプリケーションサーバ１００ｂに切り替え、セッション情報管理サーバ２００はグローバルセッション情報（key1＝value1、key2＝value2、key3＝value3）を不変属性としたまま、アプリケーションサーバ１００ｂに引き継ぐ（同図（２））。
これによって、アプリケーションサーバ１００ａにアクセスしていたクライアントマシン３０は、再ログインなどの操作をすることなく、引き続きアプリケーションサーバ１００ｂに対してアクセスを切り替えることができる。したがって、クライアントマシン３０に対する処理がアプリケーションサーバ１００ｂで継続されることとなる。
【００２１】
そして、図２Ｃに示すように、アプリケーションサーバ１００ｂのＨＴＴＰセッション情報が書き換えられて更新された場合、アプリケーションサーバ１００ｂはその更新情報をセッション情報管理サーバ２００に送信する。図２Ｃでは、たとえば、“key2”が“value2”から“value2'”に更新されたものとする。
更新情報を受信したセッション情報管理サーバ２００は、その更新情報に基いて、グローバルセッション情報のうち“key2”を“value2”から“value2'”に更新し、あわせて“key2”の属性を更新属性に変更する。
なお、この時点では、アプリケーションサーバ１００ｂのＨＴＴＰセッション情報の“key2”の属性は不変属性のままである。
【００２２】
続いて、図２Ｄに示すように、セッション情報管理サーバ２００は、アプリケーションサーバ１００ａ，１００ｂに、“key2”の属性が不変属性から更新属性に変更されたことを通知する。
これを受けて、アプリケーションサーバ１００ａは、“key2”の属性を不変属性から更新属性に変更する。また、アプリケーションサーバ１００ｂは、“key2”の属性を不変属性から更新属性に変更する。
このように、セッション情報管理サーバ２００がアプリケーションサーバ１００ｂに対して、“key2”の属性変更のみを送信して、その変更内容を送信しないことによって、各サーバの処理負担を軽減することができる。つまり、この属性変更のみの送信であれば、その変更時１回だけ送信すればよく、その後に同じセッション情報に関して書き換えが行われてもセッション情報管理サーバ２００からアプリケーションサーバ１００ｂに対して送信を行う必要がないのである。
なお、アプリケーションサーバ１００ｂにおいて、“key2”の属性を不変属性から更新属性に変更するタイミングが、実際に“key2”が更新されたときではなく、前記のようにセッション情報管理サーバ２００からの通知を受けたときにしているのは、アプリケーションサーバ１００ａと１００ｂとの整合性を保つためである。それは、より具体的には、図２Ｃにおいて、アプリケーションサーバ１００ａの“key2”の属性が不変属性であるにもかかわらず、アプリケーションサーバ１００ｂの“key2”の属性が更新属性である、といった不整合状態を避けるためである。
【００２３】
次に、図２Ｅにおいて、セッション情報管理サーバ２００に障害が発生した場合、アプリケーションサーバ１００ａ，１００ｂは、更新属性のＨＴＴＰセッション情報（“key2”）を削除し、不変属性のＨＴＴＰセッション情報（“key1”と“key3”）を残すことで、アプリケーションサーバ１００ａと１００ｂの整合性を保つことができる。
つまり、たとえば、ログインに使用されるユーザＩＤなどは、一度も更新されることがないので、不変属性のＨＴＴＰセッション情報としてアプリケーションサーバ１００ａと１００ｂに残る。一方、たとえば、画面のページＩＤなどは、一度でも更新されると属性が更新属性のＨＴＴＰセッション情報になり、セッション情報管理サーバ２００に障害が起きたときにアプリケーションサーバ１００ａ，１００ｂから削除されることになるが、ユーザＩＤなどに比べれば重要性の低い情報であり、アプリケーションサーバ間の整合性維持、セッション情報管理システム１０００全体の処理効率などの点で有益な効果を奏すると言える。
また、本例では、アプリケーションサーバ１００に障害が起きた場合について説明したが、アプリケーションサーバ１００が１つあるいは複数削除される縮退運転が行われたときにも適用可能である。さらに、アプリケーションサーバ１００が追加された場合でも、セッション情報管理サーバ２００からセッション情報をコピーすることにより、追加されたアプリケーションサーバ１００でもセッションを利用することが可能となる。
【００２４】
＜＜データ構成＞＞
＜ＨＴＴＰセッション情報登録部のデータ構成＞
続いて、図１のアプリケーションサーバ１００におけるＨＴＴＰセッション情報登録部１０２のデータ構成について、図３を参照しながら説明する。図３は、ＨＴＴＰセッション情報登録部１０２のデータ構成を表わした図である。
図３において、２つのセッション情報が、ＨＴＴＰセッションＩＤ３０１、ＫＥＹ３０２、ＶＡＬＵＥ３０３、属性３０４の４項目を含んで表示されている。
【００２５】
ＨＴＴＰセッションＩＤ３０１は、そのアプリケーションサーバ１００内でそのセッションを一意に特定する識別子であり、ここではＨＴＴＰセッションＩＤ１とＨＴＴＰセッションＩＤ２の２つが示されている。
ＫＥＹ３０２は、セッション情報を構成するそれぞれの情報の種類を示したものである。“UserID”は、クライアント（ユーザ）がクライアントマシン３０〜３２でログインを行うためのＩＤである。“Role”は、“UserID”などによってクライアントマシン３０〜３２に与えられる権限を意味するものである。“PageID”は、クライアント（ユーザ）がクライアントマシン３０〜３２で見ている画面のページＩＤである。“Search”は、検索を行った結果を表わしている。“CartID”は、図１のアプリケーションサーバ１００におけるアプリケーションプログラム１０１のクライアントへの提供サービスがオンラインショッピングなどであった場合に、画面上で商品を入れる入れ物のＩＤを表わすものである。
【００２６】
ＶＡＬＵＥ３０３は、ＫＥＹ３０２に対応する実際の値であり、ここでは、上から順に“user1”、“role1”、“page1”、“searchResult1”、“cart1”が格納されている。
属性３０４は、ＫＥＹ３０２として表わされる各情報それぞれが属する属性を表わしている。属性は、前記したように不変属性と更新属性の２種類であり、その２種類に属さないものは「−」で表記されている。
なお、不変属性あるいは更新属性を付与されるセッション情報は、他のアプリケーションサーバ１００へも引き継ぐべきセッション情報であり、アプリケーションサーバ１００において、予めＫＥＹ３０２の種類によって設定された選択条件により、どのセッション情報が引き継ぐべきセッション情報に該当するかが決められている。
不変属性は、図２Ａ〜図２Ｅで説明したように各アプリケーションサーバが共有すべき情報のうち、そのセッション内で変更されないものであることを表わす。
また、更新属性は、各アプリケーションサーバが共有すべき情報のうち、そのセッション内で変更されるものであることを表わす。
さらに、「−」と表記された情報は、各アプリケーションサーバが共有する必要のない情報であることを表わすものである。
【００２７】
＜グローバルセッション情報登録部のデータ構成＞
次に、図１のセッション情報管理サーバ２００におけるグローバルセッション情報登録部２０１のデータ構成について、図４を参照しながら説明する。図４は、グローバルセッション情報登録部２０１のデータ構成を表わした図である。
図４において、２つのセッション情報が、グローバルセッションＩＤ４０１、ＫＥＹ４０２、ＶＡＬＵＥ４０３、属性４０４の４項目に対応した形で格納されている。
【００２８】
グローバルセッションＩＤ４０１は、セッション情報管理サーバ２００内でそのセッションを一意に特定する識別子であり、ここではグローバルセッションＩＤ１とグローバルセッションＩＤ２の２つが示されている。
ＫＥＹ４０２、ＶＡＬＵＥ４０３および属性４０４は、図３のＫＥＹ３０２、ＶＡＬＵＥ３０３、属性３０４と同様であるので、説明を省略する。
【００２９】
＜＜処理手順＞＞
続いて、セッション情報管理システム１０００の具体的な処理手順について説明する。
＜処理１＞
まず、図５を参照しながら、処理１（ＨＴＴＰセッションが存在しない場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション未作成、グローバルセッション情報登録部２０１がグローバルセッション未作成の状態から処理が開始される。
【００３０】
処理１は、アプリケーションサーバ１００とセッション情報管理サーバ２００に、それぞれセッション情報を作成する処理であり、図２Ａにおける動作に相当する（図５のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ａに相当）。
図５は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、アプリケーションプログラム１０１にリクエストの処理を要求する（Ｓ５０１）。
アプリケーションプログラム１０１は、新規作成処理部１１１にＨＴＴＰセッションの新規作成を要求する（Ｓ５０２）。
新規作成処理部１１１は、ＨＴＴＰセッション情報登録部１０２にＨＴＴＰセッションを作成し（Ｓ５０３）、また、そのＨＴＴＰセッションに対応するグローバルセッションＩＤ４０１（図４参照）を発行する。
新規作成処理部１１１は、新規作成処理部２１１に当該グローバルセッションＩＤ４０１に対応するグローバルセッションの作成を要求する（Ｓ５０４）。
【００３１】
新規作成処理部２１１は、当該グローバルセッションＩＤ４０１に対応するグローバルセッションをグローバルセッション情報登録部２０１に作成する（Ｓ５０５）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２を参照し、更新すべき情報があれば更新を行う（Ｓ５０６）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ５０７）。
【００３２】
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１への更新を要求する（Ｓ５０８）。
更新処理部２１２は、グローバルセッション情報登録部２０１を参照し、更新すべき情報があれば更新を行う（Ｓ５０９）。
更新処理部１１２は、グローバルセッションＩＤ４０１（図４）を含めたレスポンスをクライアントマシン３０に送信する（Ｓ５１０）。これを受けて、クライアントマシン３０は、グローバルセッションＩＤ４０１（図４）を自身に登録する。
【００３３】
＜処理２＞
次に、図６を参照しながら、処理２（ＨＴＴＰセッションが存在する場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態から処理が開始される。
【００３４】
処理２は、セッション情報の属性を不変属性から更新に変更する処理であり、図２Ｃ・図２Ｄにおける動作に相当する（図６のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ｂに相当）。
図６は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ６０１）。
グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に最新のグローバルセッション情報の提供を要求する（Ｓ６０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１を参照し、グローバルセッション情報が更新されているか確認する（Ｓ６０３）。
【００３５】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、グローバルセッション情報が更新されている場合は最新のグローバルセッション情報を送信し、更新されていない場合はその旨を送信する（Ｓ６０４）。
グローバルセッション情報取得部１１３は、Ｓ６０４で最新のグローバルセッション情報を受信している場合は、ＨＴＴＰセッション情報登録部１０２において、対応するＨＴＴＰセッション情報を更新する（Ｓ６０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ６０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２を参照し、更新すべき情報があれば更新を行う（Ｓ６０７）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ６０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１への更新を要求する（Ｓ６０９）。
【００３６】
更新処理部２１２は、グローバルセッション情報登録部２０１を参照し、更新すべき情報があれば更新を行う。更新処理部２１２は、その際、不変属性の情報を更新するときは、その属性を更新属性に変更し（Ｓ６１０）、すべてのアプリケーションサーバ１００にその情報の属性の変更（不変属性→更新属性）を要求する（Ｓ６１１）。
セッション情報管理サーバ監視部１１５は、当該情報の属性を不変属性から更新属性に変更する（Ｓ６１２）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ６１３）。
この処理２の動作により、更新のあった情報を不変属性から更新属性に変更することができる。
【００３７】
＜処理３＞
続いて、図７を参照しながら、処理３（ＨＴＴＰセッションが削除される場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態から処理が開始される。
【００３８】
処理３は、クライアントマシン３０からの要求によって、ＨＴＴＰセッション情報登録部１０２とグローバルセッション情報登録部２０１のそれぞれのセッション情報を削除する処理である。
図７は、前記条件のときの処理フロー図である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ７０１）。
グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に最新のグローバルセッション情報の提供を要求する（Ｓ７０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１を参照し、グローバルセッション情報が更新されているか確認する（Ｓ７０３）。
【００３９】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、グローバルセッション情報が更新されている場合は最新のグローバルセッション情報を送信し、更新されていない場合はその旨を送信する（Ｓ７０４）。
グローバルセッション情報取得部１１３は、Ｓ７０４で最新のグローバルセッション情報を受信している場合は、ＨＴＴＰセッション情報登録部１０２において、対応するＨＴＴＰセッション情報を更新する（Ｓ７０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ７０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッションを削除する（Ｓ７０７）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ７０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報登録部２０１からのグローバルセッション情報の削除を要求する（Ｓ７０９）。
更新処理部２１２は、グローバルセッション情報登録部２０１からグローバルセッション情報を削除する（Ｓ７１０）。
更新処理部１１２は、クライアントマシン３０に対してグローバルセッションＩＤ４０１（図４）を削除させるレスポンスを送信する（Ｓ７１１）。
【００４０】
＜処理４＞
次に、図８を参照しながら、処理４（ＨＴＴＰセッションの有効期限が切れた場合の処理）について詳細に説明する。処理４は、ＨＴＴＰセッションの有効期限が切れた場合の、セッション情報管理サーバ２００における処理を示した処理フロー図である。
削除処理部２１３は、自身が保有するＨＴＴＰセッションの有効期限情報により、ＨＴＴＰセッションの有効期限が切れたことを検知した場合、グローバルセッション情報登録部２０１からそのＨＴＴＰセッションに対応するグローバルセッションを削除する（Ｓ８０１）。
【００４１】
なお、ＨＴＴＰセッションの有効期限情報は、削除処理部２１３自身が保有していなくても、専用テーブルなど（図示なし）に記憶されるようにしておいて、削除処理部２１３がその専用テーブルなどを参照するようにしてもよい。
この処理４の動作により、不要なセッションがセッション情報管理サーバ２００に蓄積することを回避できる。
【００４２】
＜処理５＞
続いて、図９を参照しながら、処理５（グローバルセッション情報を引き継ぐ場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション未作成、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態で処理が開始される。
【００４３】
処理５は、リクエスト処理を行うアプリケーションサーバ１００が切り替わった場合の処理であり、図２Ｂにおける動作に相当する（図９のアプリケーションサーバ１００は図２のアプリケーションサーバ１００ｂに相当）。
図９は、前記条件のときの処理フロー図である。
この処理５は、クライアントマシン３０からのリクエストの処理を行うアプリケーションサーバ１００が、障害発生などよって切り替わった直後から始まる処理である。
まず、クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ９０１）。
クライアントマシン３０からのリクエスト情報内のＨＴＴＰセッションＩＤに対応するＨＴＴＰセッションがＨＴＴＰセッション情報登録部１０２に存在しない場合、グローバルセッション情報取得部１１３は、グローバルセッション情報提供部２１４に、前記リクエスト情報内のグローバルセッションＩＤに対応するグローバルセッション情報の提供を要求する（Ｓ９０２）。
グローバルセッション情報提供部２１４は、グローバルセッション情報登録部２０１から当該グローバルセッション情報を取得する（Ｓ９０３）。
【００４４】
グローバルセッション情報提供部２１４は、グローバルセッション情報取得部１１３に、当該グローバルセッション情報を送信する（Ｓ９０４）。
グローバルセッション情報取得部１１３は、ＨＴＴＰセッション情報登録部１０２に、当該グローバルセッション情報を新規のＨＴＴＰセッション情報として格納する（Ｓ９０５）。
グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ９０６）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッション情報を使用し、リクエスト処理を行う（Ｓ９０７）。
【００４５】
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ９０８）。
更新処理部１１２は、更新処理部２１２にグローバルセッション情報の更新を要求する（Ｓ９０９）。
更新処理部２１２は、グローバルセッション情報登録部２０１のグローバルセッション情報を更新する（Ｓ９１０）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ９１１）。
【００４６】
このように、クライアントマシン３０からのリクエストの処理を引き継ぐアプリケーションサーバ１００は、セッション情報管理サーバ２００から必要なセッション情報を引き継ぐことができる。これによって、クライアントマシン３０は、再ログインなどの面倒な操作をすることなく、円滑にアプリケーションサーバ１００へのアクセス（リクエスト）を継続することができる。
【００４７】
＜処理６＞
次に、図１０を参照しながら、処理６（セッション情報管理サーバ２００に障害が発生した場合のリクエスト処理）について詳細に説明する。なお、ここでは、ＨＴＴＰセッション情報登録部１０２がＨＴＴＰセッション作成済み、グローバルセッション情報登録部２０１がグローバルセッション作成済みの状態で処理が開始される。
【００４８】
処理６は、セッション情報管理サーバ２００に障害が発生したときの処理であり、図２Ｅにおける動作に相当する（図１０のアプリケーションサーバ１００は図２Ｅのアプリケーションサーバ１００ａあるいは１００ｂのいずれかに相当）。
図１０は、前記条件のときの処理フロー図である。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ２００に障害が発生していることを検知する（Ｓ１００１）。なお、この障害検知の方法としては、たとえば、セッション情報管理サーバ監視部１１５がセッション情報管理サーバ２００からの定時発信を受信しなかったことをセッション情報管理サーバ２００の障害と判断する方法が挙げられるが、その方法に限定されるものではなく、他の方法を用いてもよい。
セッション情報管理サーバ監視部１１５は、セッション情報管理サーバ状態テーブル１１４のセッション情報管理サーバ２００の状態を「障害」と書き換える（Ｓ１００２）。
クライアントマシン３０は、グローバルセッション情報取得部１１３にリクエストの処理を要求する（Ｓ１００３）。
【００４９】
グローバルセッション情報取得部１１３は、セッション情報管理サーバ２００に障害が発生しているので、そのとき処理中のリクエストに対応するＨＴＴＰセッション情報のうち更新属性の情報を削除する（Ｓ１００４）。
このＳ１００４の動作は、複数のアプリケーションサーバ１００間の整合性を保つためのものである。つまり、セッション情報管理サーバ２００に障害が発生していて、これ以降はアプリケーションサーバ１００間でセッション情報の共有ができないため、複数のアプリケーションサーバ１００間で内容が整合していない更新属性の情報を削除することによって、複数のアプリケーションサーバ１００間の不整合状態を回避しておくのである。一方、不変属性の情報は、変更されることがないので削除する必要はなく、また、削除しないことによって、アプリケーションサーバ１００が切り替わったときでも、クライアントマシン３０において再ログインなどの面倒な操作が不要となり、利便性の高いセッション情報管理システム１０００を実現することができる。
【００５０】
図１０の処理６に戻って、グローバルセッション情報取得部１１３は、アプリケーションプログラム１０１に、リクエストの処理を要求する（Ｓ１００５）。
アプリケーションプログラム１０１は、ＨＴＴＰセッション情報登録部１０２のＨＴＴＰセッション情報のうち残存している不変属性の情報を使用して、リクエスト処理を行う（Ｓ１００６）。
アプリケーションプログラム１０１は、更新処理部１１２に、クライアントマシン３０へのレスポンス送信を要求する（Ｓ１００７）。
更新処理部１１２は、クライアントマシン３０にレスポンスを送信する（Ｓ１００８）。
【００５１】
このように、実施の形態に係るセッション情報管理システム１０００によれば、セッション情報のうち引き継ぐべき情報を２つの属性（不変属性／更新属性）に分けて、アプリケーションサーバ１００およびセッション情報管理サーバ２００で共有する。そして、セッション情報管理サーバ２００に障害が発生した場合には、更新属性の情報を削除して不変属性の情報のみをアプリケーションサーバ１００に残すことで、複数のアプリケーションサーバ１００間におけるセッション情報の整合性を維持することができる。
また、アプリケーションサーバ１００からセッション情報を最初にセッション情報管理サーバ２００に記憶させるときはすべて不変属性の情報とし、その後、１回でも変更のあった情報を更新属性の情報と変更することで、自動的に適切な属性を決定および付与することができ、情報ごとの属性を事前に登録しておくなどの煩雑な操作が不要で利便性の高いセッション情報管理システム１０００を実現することができる。ただし、セッション情報の種類（図３のＫＥＹ３０２の種類）が少ない場合などは、予め個別のセッション情報に関する属性を手動で設定するようにしておいてもよい。
【００５２】
以上で実施の形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。たとえば、クライアントマシンからのアクセスを複数のアプリケーションサーバに振り分けるには、負荷分散機を使わなくても、ラウンドロビン方式などを採用することにより実現してもよい。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００５３】
【図１】実施の形態に係るセッション情報管理システムの全体構成を示す図である。
【図２Ａ】セッション情報管理システムにおけるセッション情報の複製動作を示す図である。
【図２Ｂ】セッション情報管理システムにおいてアプリケーションサーバで障害が発生した場合の動作を示す図である。
【図２Ｃ】セッション情報管理システムにおけるセッション情報の書換え動作を示す図である。
【図２Ｄ】セッション情報管理システムにおけるセッション情報の属性変更動作を示す図である。
【図２Ｅ】セッション情報管理システムにおいてセッション情報管理サーバで障害が発生した場合の動作を示す図である。
【図３】ＨＴＴＰセッション情報登録部のデータ構成を表わした図である。
【図４】グローバルセッション情報登録部のデータ構成を表わした図である。
【図５】ＨＴＴＰセッションが存在しない場合の処理フロー図である。
【図６】ＨＴＴＰセッションが存在する場合の処理フロー図である。
【図７】ＨＴＴＰセッションを削除する場合の処理フロー図である。
【図８】ＨＴＴＰセッションの有効期限が切れた場合の処理フロー図である。
【図９】グローバルセッション情報を引き継ぐ場合の処理フロー図である。
【図１０】セッション情報管理サーバに障害が発生した場合の処理フロー図である。
【符号の説明】
【００５４】
１〜ｎ 計算機
３０〜３２ クライアントマシン
４０ ネットワーク
５０ 負荷分散機
６０、７０ 通信回線
１００ アプリケーションサーバ
２００ セッション情報管理サーバ
１０００ セッション情報管理システム
【特許請求の範囲】
【請求項１】
端末からの要求に応じた処理を行う複数の第１の計算機と、各第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機とを備えたセッション情報管理システムにおけるセッション情報管理方法であって、
前記第２の計算機が、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与するステップと、
前記各第１の計算機が、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続するステップと、
を有することを特徴とするセッション情報管理方法。
【請求項２】
請求項１に記載のセッション情報管理方法において、
前記各第１の計算機が、予め設定された選択条件に基いて、前記第２の計算機に前記属性を付与させる前記セッション情報を選択するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項３】
請求項１または請求項２に記載のセッション情報管理方法において、
前記第１の計算機が、前記端末からの要求に応じた処理を行う際に登録済みの前記セッション情報を更新するセッション情報を受信した場合、当該第１の計算機は、そのセッション情報を前記第２の計算機に送信するステップと、
前記第２の計算機は、前記第１の計算機から送信されたセッション情報の属性を更新を示す更新属性に変更し、その変更したセッション情報の更新属性への変更を前記各第１の計算機に送信するステップとをさらに有することを特徴とするセッション情報管理方法。
【請求項４】
請求項３に記載のセッション情報管理方法において、
前記第１の計算機の切り替え後、当該第１の計算機が、処理対象の端末から要求された処理を行う場合にその要求のセッションが未登録のとき、当該第１の計算機は、前記第２の計算機に管理されているセッション情報を所定の属性とともに受信して登録するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項５】
請求項３に記載のセッション情報管理方法において、
各第１の計算機が、第２の計算機が作動停止したことを検知したとき、セッション情報のうち更新属性のセッション情報を削除するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項６】
端末からの要求に応じた処理を行う複数の第１の計算機と、各第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機とを備えたセッション情報管理システムであって、
前記第２の計算機は、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与し、
前記各第１の計算機は、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続する、
ことを特徴とするセッション情報管理システム。
【請求項７】
端末からの要求に応じた処理を行う複数の第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機であって、
記憶部と処理部とを備え、前記処理部は、前記各第１の計算機から前記セッション情報を受信し、受信したセッション情報の更新の有無を示す属性を当該セッション情報に付与して前記記憶部に登録し、
前記記憶部から読み出したセッション情報をその属性と関連付けて所定の第１の計算機に送信し、当該第１の計算機にその属性を付与されたセッション情報に基いて前記端末からの要求に応じた処理を継続させる、
ことを特徴とする第２の計算機。
【請求項８】
請求項１から請求項５までのいずれか１項に記載のセッション情報管理方法をコンピュータに実行させるためのセッション情報管理プログラム。
【請求項１】
端末からの要求に応じた処理を行う複数の第１の計算機と、各第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機とを備えたセッション情報管理システムにおけるセッション情報管理方法であって、
前記第２の計算機が、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与するステップと、
前記各第１の計算機が、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続するステップと、
を有することを特徴とするセッション情報管理方法。
【請求項２】
請求項１に記載のセッション情報管理方法において、
前記各第１の計算機が、予め設定された選択条件に基いて、前記第２の計算機に前記属性を付与させる前記セッション情報を選択するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項３】
請求項１または請求項２に記載のセッション情報管理方法において、
前記第１の計算機が、前記端末からの要求に応じた処理を行う際に登録済みの前記セッション情報を更新するセッション情報を受信した場合、当該第１の計算機は、そのセッション情報を前記第２の計算機に送信するステップと、
前記第２の計算機は、前記第１の計算機から送信されたセッション情報の属性を更新を示す更新属性に変更し、その変更したセッション情報の更新属性への変更を前記各第１の計算機に送信するステップとをさらに有することを特徴とするセッション情報管理方法。
【請求項４】
請求項３に記載のセッション情報管理方法において、
前記第１の計算機の切り替え後、当該第１の計算機が、処理対象の端末から要求された処理を行う場合にその要求のセッションが未登録のとき、当該第１の計算機は、前記第２の計算機に管理されているセッション情報を所定の属性とともに受信して登録するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項５】
請求項３に記載のセッション情報管理方法において、
各第１の計算機が、第２の計算機が作動停止したことを検知したとき、セッション情報のうち更新属性のセッション情報を削除するステップをさらに有することを特徴とするセッション情報管理方法。
【請求項６】
端末からの要求に応じた処理を行う複数の第１の計算機と、各第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機とを備えたセッション情報管理システムであって、
前記第２の計算機は、前記セッション情報の更新の有無を示す属性を当該セッション情報に付与し、
前記各第１の計算機は、前記第２の計算機によって付与されたセッション情報の属性に基いて、前記端末からの要求に応じた処理を継続する、
ことを特徴とするセッション情報管理システム。
【請求項７】
端末からの要求に応じた処理を行う複数の第１の計算機で処理される前記要求のセッション情報を管理する第２の計算機であって、
記憶部と処理部とを備え、前記処理部は、前記各第１の計算機から前記セッション情報を受信し、受信したセッション情報の更新の有無を示す属性を当該セッション情報に付与して前記記憶部に登録し、
前記記憶部から読み出したセッション情報をその属性と関連付けて所定の第１の計算機に送信し、当該第１の計算機にその属性を付与されたセッション情報に基いて前記端末からの要求に応じた処理を継続させる、
ことを特徴とする第２の計算機。
【請求項８】
請求項１から請求項５までのいずれか１項に記載のセッション情報管理方法をコンピュータに実行させるためのセッション情報管理プログラム。
【図１】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図２Ｄ】
【図２Ｅ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図２Ｄ】
【図２Ｅ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００６−１４６６６３（Ｐ２００６−１４６６６３Ａ）
【公開日】平成１８年６月８日（２００６．６．８）
【国際特許分類】
【出願番号】特願２００４−３３７３７１（Ｐ２００４−３３７３７１）
【出願日】平成１６年１１月２２日（２００４．１１．２２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成１８年６月８日（２００６．６．８）
【国際特許分類】
【出願日】平成１６年１１月２２日（２００４．１１．２２）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]