説明

セッション管理システム及びその方法

【課題】クライアント/サーバ・システムの運用状況の変化に応じた優先度を設定する。
【解決手段】セッション管理システムは、ユーザがクライアント端末を用いてサーバにアクセスする時間帯における第1のアクセス回数に基づいて設定したユーザの時間帯対応の優先度を格納する優先度テープル、および、ユーザのサーバへの接続状況を格納する接続状況テーブルを有する。さらに、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、少なくともセッション確立要求に含まれるユーザのユーザID、セッション確立要求に含まれるクライアント端末のIPアドレス、優先度テーブルに格納される、現在時刻を含む時間帯におけるユーザの優先度、および、サーバへの接続時刻としての現在時刻を接続状況テーブルに格納し、アプリケーションへセッション確立するユーザアクセス受付処理部を有する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、業務アプリケーションにアクセスするユーザのセッション管理に関するものである。
【背景技術】
【0002】
特許文献1に、ユーザの優先度によるセッション管理システムが次のように開示されている。TCP/IP通信プロトコルを利用したクライアント/サーバ・システムにおいて、各クライアントのIPアドレスに対応して、サーバへ接続する優先度を設定した優先度テーブルをサーバに設け、サーバがクライアントから接続要求を受けた場合に、優先度テーブルを参照して、優先度の高いクライアントから接続要求を受け付ける。
【0003】
サーバに接続可能なクライアント数の全部に、それぞれクライアントがセッションを維持している状態において、未接続のクライアントがサーバに接続要求した際には、優先度テーブルを参照して、接続要求したクライアントのIPアドレスの優先度と、既に接続しているクライアントの中で最低の優先度とを比較し、接続要求したクライアントの優先度が高い場合に、最低の優先度のクライアントとサーバとのセッションを切断し、接続要求したクライアントの接続要求を受け付ける。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2003-16031号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
クライアント/サーバ・システムにより実現する業務アプリケーションは、一般に多様なサービスをユーザに対して提供する。ユーザから見れば、多様な処理を実行できる。多様な処理は、複数ユーザにより、複数のクライアント端末が用いられて実行される。同じユーザが複数の担当業務に対応した複数の処理を実行することもあるし、複数のユーザが同じ業務処理を実行することもある。このような業務アプリケーションには、日次、月次などの周期性を持った処理が実行されることが多く、その周期に対応してクライアント端末からのアクセス回数が増減する傾向がある。アクセス回数の増加に伴って、高い優先度の設定が要請される。また、業務アプリケーションが提供するサービス内容が徐々に変化することもあるし、ユーザの担当業務も変化する。
【0006】
特許文献1に記載のIPアドレス単位の優先度設定では、このようなクライアント/サーバ・システムの運用状況の変化に対応できない。運用状況に変化がなければ、クライアント端末を特定するIPアドレスに対応付けて優先度を設定してもよいが、ユーザの担当業務や時間経過に伴う変化に応じて優先度の設定内容を変化させる必要がある。
【課題を解決するための手段】
【0007】
開示されるセッション管理システムは、次のような構成である。ユーザがクライアント端末を用いてサーバにアクセスする時間帯における第1のアクセス回数に基づいて設定したユーザの時間帯対応の優先度を格納する優先度テープル、および、ユーザのサーバへの接続状況を格納する接続状況テーブルを有する。さらに、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、少なくともセッション確立要求に含まれるユーザのユーザID、セッション確立要求に含まれるクライアント端末のIPアドレス、優先度テーブルに格納された、現在時刻を含む時間帯におけるユーザの優先度、および、サーバへの接続時刻としての現在時刻を接続状況テーブルに格納し、アプリケーションへのセッション確立するユーザアクセス受付処理部を有する。
【0008】
開示されるセッション管理システムの望ましい他の態様は、ユーザアクセス受付処理部は、アプリケーションへのセッション確立後、ユーザによるクライアント端末を用いたアプリケーションへのアクセスに応答して、アプリケーションへの第2のアクセス回数と最新アクセス日時を接続状況として接続状況テーブルに格納する。
【0009】
開示されるセッション管理システムの望ましいさらに他の態様は、ユーザアクセス受付処理部は、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、サーバへの接続可能なクライアント端末の台数に接続中の他のクライアント端末の台数が達しているとき、優先度と接続中の他のクライアント端末を用いた他のユーザの優先度との関係、及び、接続中の他のクライアント端末を用いた他のユーザが所定時間を超えてサーバのアプリケーションへアクセスしていない不使用者であるか否かの少なくとも一方に基づいて他のユーザのセッション切断の可否を決定する。
【0010】
開示されるセッション管理システムの望ましいさらに他の態様は、接続状況テーブルに格納される接続状況は、アプリケーションへのセッション切断要求に応答して、接続履歴データベースに格納される。
【0011】
開示されるセッション管理システムの望ましいさらに他の態様は、セッション管理システムは、接続履歴データベースに格納された接続状況を参照して、ユーザがクライアント端末を用いてサーバのアプリケーションにアクセスした時間帯における第2のアクセス回数に基づいて、ユーザの優先度を更新する優先度設定処理部をさらに有する。
【0012】
開示されるセッション管理システムの望ましいさらに他の態様は、優先度テーブルは、ユーザのユーザIDとクライアント端末のIPアドレスとに対応付けて設定された特権としての優先度をユーザの優先度として含む。
【発明の効果】
【0013】
本発明によれば、クライアント/サーバ・システムの運用状況の変化に応じた優先度を設定できる。
【図面の簡単な説明】
【0014】
【図1】クライアント/サーバ・システムの構成例である。
【図2】特権定義テーブルの構成例である。
【図3】接続履歴データベースの構成例である。
【図4】優先度テーブルの構成例である。
【図5】接続状況テーブルの構成例である。
【図6】優先度設定処理部の処理フローチャートである。
【図7】ユーザアクセス受付処理部の処理フローチャートである。
【発明を実施するための形態】
【0015】
図1に、サーバ1にセッション管理システム10を含むクライアント/サーバ・システムの構成例を示す。クライアント/サーバ・システムは、サーバ1に、ユーザ3が使用するクライアント端末2がネットワーク4を介して接続する構成である。ユーザ3は、クライアント端末2からサーバ1にアクセスして、所望のアプリケーション5を実行する。
【0016】
サーバ1に含まれるセッション管理システム10は、優先度設定処理部11及びユーザアクセス受付処理部12を有する。また、セッション管理システム10は、優先度設定処理部11及びユーザアクセス受付処理部12の実行に用いる、特権定義テーブル13、接続履歴データベース14、優先度テーブル15、および、接続状況テーブル16を有する。なお、テーブルとデータベースとの呼び分けには特に意味は無い。
【0017】
図2に、特権定義テーブル13の構成例を示す。特権定義テーブル13は、組織の職位や職種などにより決定される特定のユーザに付与される、サーバ1への接続の特権(優先的に接続する権利)を示す。特権定義テーブル13は、特権を持つユーザ3によるサーバ1へ接続に関する情報を有し、特権を持つユーザ3のユーザID130、ユーザ3がサーバ1へ接続(より具体的には、アプリケーション5に論理的にセッションを確立)するときの優先度、サーバ1へ接続する曜日や時間帯などの接続時刻132、サーバ1へ接続するために用いるクライアント端末2を特定するIPアドレス133を含む。なお、本実施形態では、優先度1を最高の優先度とし、2、3、・・・の順に優先度が低下するものとする。
【0018】
たとえば、図2には、ユーザIDが004のユーザ3が、IPアドレス133としてIPAD4のクライアント端末2を用いてサーバ1へ接続するときと、月曜日の午後にサーバ1へ接続するときに、優先度1で接続する特権を有していることを示す。逆に、IPAD4以外のIPアドレスのクライアント端末2を用いた、月曜日の午後以外の時間帯におけるサーバ1への接続要求に対しては、ユーザIDが004のユーザ3に特権としての優先度1が付与されないことを示す。接続時間帯132は、クライアント端末2からサーバ1が接続要求される時刻を含む時間帯を示す。以降に説明する他のテーブル等の説明においても、接続時間帯の意味は同様である。
【0019】
なお、時間帯として、分かり易くするために、午前、午後、夜間などを用いて説明するが、実際には6:00〜12:00を午前とするなどにより所定の時間帯を特定する。したがって、時間帯の設定は、30分や1時間毎であってもよく、また日中は30分毎、夜間は2時間毎のように、サーバ1で実行されるアプリケーション5の特性などに応じて、時間帯の単位時間を変えても良い。また、月初め、月末なども同様に、毎月1日〜5日の間を月初め、25日〜月の末日を月末とするなどにより期間(広い意味での時間帯)を特定する。これらの時間帯の特定は、サーバ1が持っているカレンダー及び時計を基準とする。
【0020】
図3に、接続履歴データベース14の構成例を示す。接続履歴データベース14は、ユーザ3がクライアント端末2を用いてアプリケーション5を利用するためのセッション確立からセッション切断までのセッション単位に、ユーザ3からサーバ1への接続履歴を格納する。セッション単位の接続履歴は、ユーザ3を示すユーザID140、サーバ1へ接続したときの優先度141及び接続開始日時(セッション確立日時)を示す接続日時142、セッションを切断した日時を示す切断日時143、接続中のアプリケーション5へのアクセス回数144、並びに、ユーザ3が用いたクライアント端末2を特定するIPアドレス145を含む。
【0021】
たとえば、図3には、ユーザIDが001のユーザ3がIPアドレス145としてIPAD1のクライアント端末2を用いて、優先度141が2で、2010/10/01.13:00(接続日時142)〜2010/10/01.13:45(切断日時143)の45分間の接続時間(セッションを確立している時間)に、100回のアクセス回数144であったことを一例として示している。
【0022】
セッション単位の接続履歴は、各セッションの終了時、すなわちセッション切断の処理に応じて、接続履歴データベース14へ格納される。
【0023】
図4に、優先度テーブル15の構成例を示す。優先度テーブル15は、ユーザ3がサーバ1へ接続要求(セッションの確立要求)してきたときに、セッション管理システム10のユーザアクセス受付処理部12が、ユーザ3に付与されている優先度を参照するために用いられる。優先度テーブル15は、ユーザ3を示すユーザID150、サーバ1へ接続するときの優先度151、優先度151の値を付与する条件としての接続時間帯152及びIPアドレス153、および特権が付与されているか否かを示す特権154を含む。IPアドレス153は、優先度151の値を付与する条件としての、ユーザ3が用いるクライアント端末2を特定するIPアドレスである。
【0024】
たとえば、図4には、ユーザIDが001のユーザ3に関して、3種類の優先度が設定されている。第1は、ユーザIDが001のユーザ3が月初めの日の午後にIPアドレス153がIPAD1のクライアント端末2を用いて、サーバ1に接続要求する場合は優先度141として1が付与される。第2は、月初めの日の午後以外の時間帯にIPアドレス153がIPAD1のクライアント端末2を用いて、サーバ1に接続要求する場合は優先度141として3が付与される。第3は、IPアドレス153がIPAD1以外のクライアント端末2を用いて、サーバ1に接続要求する場合は優先度141として4が付与される。さらに、ユーザIDが004のユーザ3に関しては、特権定義テーブル13に示した内容を格納している。
【0025】
図5に、接続状況テーブル16の構成例を示す。接続状況テーブル16は、少なくともサーバ1へ接続(セッション確立)しているユーザ3のアクセス状況を示す。接続状況テーブル16は、ユーザ3を示すユーザID160、ユーザ3が用いたクライアント端末2を特定するIPアドレス161、現在サーバ1へ接続(セッション確立)中か否かを示す接続状況162、接続したときの優先度(1回のセッションの中では優先度を変更しないので、接続中のセッションの優先度)163、サーバ1への接続開始日時を示す接続日時164、接続中のアプリケーション5へのアクセス回数165、現在の接続(セッション)の中でアプリケーション5へ最も最近アクセスした日時を示す最新アクセス日時166、及び、セッションを切断した日時を示す切断日時167を含む。
【0026】
ユーザ3の人数が少ない小規模システムでは、図5に示すように全てのユーザ3(n人)対応にレコードを設けた接続状況テーブル16としても良いが、ユーザ3の人数が多い大規模システムでは、接続していないユーザ3に関するレコードを、セッション切断時の処理の一環として削除しておくことにより、接続状況テーブル16を小容量化できる。このような場合は、接続状況162および切断日時167は不要になる。
【0027】
接続履歴データベース14のセッション単位の接続履歴は、各セッションの終了時、すなわちセッション切断の処理に応じて、接続履歴データベース14へ格納されると前述した。セッション単位の接続履歴は、接続状況テーブル16の内容が元になる。全てのユーザ3対応にレコードを設けた接続状況テーブル16の場合には、ユーザID160、IPアドレス161、優先度163、接続日時164、アクセス回数165、及び、切断日時167の各々を接続履歴データベース14の対応する領域に格納すれば良い。一方、接続していない(未接続)ユーザ3に関するレコードを設けない接続状況テーブル16の場合には、切断日時167の代わりにセッション切断時の日時として、サーバ1のカレンダー及び時計から読み取った日時(現在時刻)を用いれば良い。
【0028】
たとえば、図5には、ユーザIDが001のユーザ3に関して、IPAD1のクライアント端末2を用いて、優先度1でサーバ1へ接続中であり、その接続日時164は2010/11/01の13:30であり、接続開始時刻から現在までのアプリケーション5へのアクセス回数165は100回であり、最新アクセス日時166は2010/11/01の13:59であることを示す。
【0029】
図6に、優先度設定処理部11の処理フローチャートを示す。優先度設定処理部11は、毎年所定の時期などのように定期的に実行されても良いし、アプリケーション5が実行する業務内容の変化やユーザ3の担当業務の変化に応じて、接続履歴データベース14への接続履歴の蓄積が進んだ段階で、適宜実行されても良い。
【0030】
優先度設定処理部11は、接続履歴データベース14をユーザID140に基づいてソートする(ステップ600)。接続履歴データベース14は接続履歴をセッション切断時刻順にシーケンシャルに格納するので、同じユーザ3に関しては、(同じユーザ3が同時に複数のセッションを確立することは無いので、)接続日時142の順に格納される。接続履歴が接続履歴データベース14にランダムに格納される場合は、ユーザID140に基づいたソートの後に、各ユーザID140ごとに接続日時142でソートする。以下の処理は、ソートした各ユーザID140ごとに、接続日時142の順に各接続履歴について繰り返す。
【0031】
接続履歴データベース14のユーザID140が特権定義テーブル13のユーザID130にあるかを判定する(ステップ602)。あるならば、特権定義テーブル13のユーザID130、優先度131、接続時間帯132およびIPアドレス133の各々を、優先度テーブル15の対応する領域に格納し、優先度テーブル15の特権154に「有り」を格納する(ステップ603)。なお、同じユーザID130に関して複数のレコードが特権定義テーブル13に定義されている場合は、それら複数の定義内容を優先度テーブル15に格納する。
【0032】
ユーザID140に特権が定義されていない場合、および、特権を優先度テーブル15に格納した場合は後述するステップ685を経て、接続履歴データベース14の対象(接続履歴データベース14のレコードを順次処理対象とするので、対象とは現在の処理対象)の接続履歴のアクセス回数144がM1回以上かを判定する(ステップ605)。アクセス回数144がM1回以上であるならば、その接続日時142を含む時間帯が優先度テーブル15の接続時刻152に格納されているかを判定する(ステップ610)。接続時刻152に格納されていなければ、優先度1、接続日時142を含む時間帯、IPアドレス145を、ユーザID150に対応させて優先度テーブル15の優先度151、接続日時152を含む時間帯、IPアドレス153に格納する(ステップ615)。
【0033】
ステップ610の判定の結果、接続時刻152に格納されていれば、その接続時刻152に対応する優先度テーブル15のIPアドレス153が、接続履歴データベース14の対象のIPアドレス145と同じかを判定する(ステップ620)。同じであるならば、すでに優先度テーブル15に登録されているので、ステップ685へ分岐する。IPアドレス153とIPアドレス145が異なれば、優先度テーブル15のIPアドレス153を「不定」にする。IPアドレス153が「不定」とは、同じユーザID150が、異なる日の、接続時刻152を含む同じ時間帯に異なるクライアント端末2を用いてサーバ1に接続した接続履歴があったことを意味している。すなわち、同じユーザ3が、アクセス回数がM1回を超えるサーバ1への接続のために、日によって複数のクライアント端末2を選択的に使用していたことを意味している。一度、IPアドレス153に「不定」が格納され、さらに同じ時間帯の接続履歴があると、ステップ620はIPアドレス145を「不定」と比較することになり、IPアドレス153に「不定」が上書きされることになる。
【0034】
ステップ610〜ステップ625を詳細に説明する。接続履歴データベース14の接続日時142が、どのような時間帯に属するかは次のように判定する。アプリケーション5により実行される業務の特性から、日次処理(毎日実行する処理)、週次処理、月次処理、年次処理、場合によっては四半期毎の処理が予め想定される。また月次処理も上旬、中旬、下旬、月初め、月末などが想定される。また時間帯の最小単位は、前述したように、短時間単位に設定しても良いが、午前、午後などとする。そこで、優先度テーブル15への新たな優先度の設定時には、接続日時142を含む時間帯を接続日時152に格納する。接続履歴データベース14の他の接続履歴のアクセス回数144に基づいてステップ610を実行する場合、既に優先度テーブル15の接続日時152に格納されている時間帯の最小単位から徐々に広い時間帯に合致するかを判定する。たとえば、午前が一致したならば、前日かを判定し、一致しているならば、たとえば、月末かを判定する。この例の場合、月末まで一致すれば、月末の午前とし、月末は不一致ならば、毎日午前とする。このように決定し、決定した時間帯を優先度テーブル15の接続日時152に格納する。以上の処理を含めて、ステップ610〜ステップ615で実行する。
【0035】
ステップ625で、複数のクライアント端末2が選択的に使用される場合、IPアドレス153に「不定」を格納するように説明したが、複数のIPアドレス153欄を設けて複数のIPアドレスを格納しても良い。実際の運用では、使用されるクライアント端末2をすべて特定した、厳密な優先度が要求されることは少ない。時間帯をたとえば、10分や30分のような短時間に設定した、厳密な優先度が要求されることも少ない。優先度は、接続履歴が反映され、サーバ1に同時にセッションを確立しているクライアント端末2の数が、サーバ1に接続可能な台数に達している場合の判断の基準として用いることができれば良い。
【0036】
ステップ630〜ステップ650、ステップ655、ステップ660〜ステップ680は、アクセス回数144の比較対象の回数を変えたステップ605〜ステップ625の繰返しであるので、個々のステップの説明を省略する。
【0037】
繰返しのステップの中の比較対象の回数M1、M2、・・・、Mkは、M1>M2>・・・>Mkの関係を持たせる。すなわち、クライアント端末2からサーバ1への1回の接続時間あたりのアクセス回数が多い接続履歴に対応して、高い優先度を付与する。また比較対象の回数の段階をkとすることにより、優先度として値が付与されない最も低い優先度の場合を含めて、k+1段階の優先度が付与される。たとえば、k=2ならば、優先度は1、2、値なし(最も低い優先度)の3段階になる。
【0038】
同じユーザID140の他の接続時刻142の接続履歴の有無を判定し、あるならば、その接続履歴に関して、ステップ605から処理を繰り返す(ステップ685)。ないならば、他のユーザID140の接続履歴の有無を判定し、あるならば、そのユーザID140の接続履歴に関して、ステップ602から処理を繰り返す(ステップ690)。ないならば、優先度設定処理部11の処理を終了する。
【0039】
優先度設定処理部11の処理により、図4に示すように、同じユーザに、日、週、月などの周期性を持った接続時刻152に対応した複数の優先度(同じ段階(レベル)の優先度になる場合もある)を付与することができる。複数の優先度を付与できることにより、同じユーザ3が複数の業務を担当し、時間帯により実行する担当業務が異なるような場合に、その担当業務対応に優先度が付与されることと等価になる。また、偶然に一回の接続履歴に多くのアクセス回数(たとえば、M1を超えるアクセス回数)が格納されていた場合、前述したようにその偶然はたとえば年に1回のある時間帯の接続であると判定され、仮に高い優先度が付与されたとしても、翌年の同じ時間帯に接続が無ければ、付与された優先度による接続が無く、実質的にクライアント端末2からサーバ1への接続管理(セッション管理)に影響を与えることは無い。
【0040】
月日の経過と共に、サーバ1により実行されるアプリケーション5の内容が変化したり、ユーザ3のアプリケーション5を実行させる担当業務が変化する場合がある。そのような場合に、それらの変化に応じて優先度設定処理部11の処理を実行して優先度テーブル15を再作成しても良いし、接続履歴のアクセス回数に応じてステップ615などで登録する優先度の段階を上下させても良い。後者は、たとえば、優先度3のユーザID150および接続日時152が優先度テーブル15にあり、同じ接続日時152においてアクセス回数がM1を超える接続履歴に応じて、優先度を1段階上げて優先度2とするように、優先度の段階を急激に変化させない方法である。この方法は、前述の偶然の接続履歴の優先度への影響の度合いを低下させる効果がある。
【0041】
図7に、ユーザアクセス受付処理部12の処理フローチャートを示す。ユーザアクセス受付処理部12は、ユーザ3によるクライアント端末2を用いたサーバ1へのアクセス要求に応答して実行される。アクセス要求は、(1)サーバ1のアプリケーション5への接続要求(ログイン:セッション確立要求)、(2)アプリケーション5へ接続中のアプリケーション5へのアクセス要求、および、(3)サーバ1のアプリケーション5とのセッション切断要求(ログアウト)に大別される。アクセス要求には、ユーザ3のユーザIDやユーザ3が用いるクライアント端末2のIPアドレスが含まれる。
【0042】
アクセス要求がセッション切断要求(ログアウト)かを判定する(ステップ700)。セッション切断要求の場合、セッション切断要求に含まれるユーザIDに対応する、接続状況テーブル16の切断日時167に(サーバ1のカレンダー及び時計から読んだ年月日を含む)現在時刻を格納し、接続状況162に「未接続」を格納する(ステップ705)。セッション切断要求に対応して接続状況162を「未接続」にしたレコードを接続履歴として、前述したように、接続履歴テーブル14に格納する(ステップ710)。
【0043】
前述したように、接続状況テーブル16には未接続のユーザ3に関するレコードを設けない場合は、ステップ705で現在時刻を接続状況テーブル16の切断日時167に格納せずに、ステップ710で現在時刻を切断日時143として含んだ接続履歴を接続履歴テーブル14に格納した後に、該当するレコードを削除する。
【0044】
セッション切断要求に含まれるIPアドレスのクライアント端末2とアプリケーション5との間のセッションを切断し(ステップ715)、ステップ770へ移る。
【0045】
セッション切断要求ではないならば、アクセス要求に含まれるユーザIDに対応する、接続状況テーブル16のユーザID160の接続状況162が「接続中」か否かを判定する(ステップ720)。この判定は、アクセス要求がセッション確立要求であるか否かを判定しても良いし、接続状況テーブル16の接続状況162とセッション確立要求の双方を判定しても良い。後者の場合、双方の判定結果の矛盾に基づいたエラー処理を実行することができる。「接続中」ならば、ステップ765へ移る。
【0046】
「接続中」でないならば、すなわちセッション確立要求であるならば、サーバ1へ接続可能なクライアント端末2の台数に未達かを判定する(ステップ725)。たとえば、サーバ1へ接続可能なクライアント端末2の台数が10台のときに、現在接続中のクライアント端末2の台数が9台以下かを判定する。未達であるならば、セッション確立要求に応じられるので、ステップ760へ移る。
【0047】
サーバ1へ接続可能なクライアント端末2の台数に達しているならば、セッション確立要求に含まれるユーザID及びIPアドレスの組が優先度テーブル15に含まれるかを判定する(ステップ730)。優先度テーブル15に、セッション確立要求に含まれるユーザIDに対応するユーザIDがあり、IPアドレスに対応するIPアドレス153が無く、IPアドレス153が「不定」の場合は含まれているとする(don’t careとする)。含まれているならば、その組に対応する優先度151を取得し、含まれていないならば、最も低い優先度とし、取得した優先度以下で実行中の他のユーザがいるかを接続状況テーブル16を参照して判定する。すなわち、セッション確立要求してきたユーザIDのユーザ3に、サーバ1への接続の優先度として設定される優先度以下の優先度で接続中の他のユーザ3の有無を判定し、無いならば、ステップ740へ移る。
【0048】
有るならば、他のユーザ3が不使用者であるかを判定する(ステップ735)。ユーザ3に設定される優先度以下の優先度で接続中の他のユーザが複数いる場合は、その複数の他のユーザの各々が不使用者であるかを判定する。不使用者とは、サーバ1へ接続中であるが、所定時間(たとえば、5分)を超えてサーバ1のアプリケーション5へアクセスしていないユーザ3である。アクセスしていない時間は、接続状況テーブル16の最新アクセス日時166の時刻から現在時刻に至る時間である。所定時間を超えてサーバ1のアプリケーション5へアクセスしていない他のユーザ3がいないならば、ステップ740へ移る。
【0049】
セッション確立要求してきたユーザIDのユーザ3に、サーバ1への接続の優先度として設定される優先度以下の優先度で接続中の他のユーザ3がいないとき、または、そのような他のユーザ3があり、他のユーザ3は不使用者ではないとき、セッション確立要求してきたユーザIDのユーザ3が用いているクライアント端末2に向けて「接続不可」を送信し(ステップ740)、ユーザアクセス受付処理部12の処理を終了する。
【0050】
不使用者がいるとき、その不使用者のセッションを切断する(ステップ745〜ステップ755)。ステップ745〜ステップ755のセッション切断の処理は、セッション切断の対象を異にするが、処理内容はステップ705〜ステップ715と同じであるので、説明を省略する。
【0051】
ステップ730及びステップ735は、セッション確立要求してきたユーザの優先度以下の優先度の他のユーザが不使用者であったならば、その不使用者のセッションを切断し、セッション確立要求してきたユーザに応えようとすることを示している。この2ステップによる処理は、クライアント/サーバ・システムの運用の仕方、すなわちセッション管理に対する考え方により、次のようにしても良い。一つ目は、優先度に係らず、不使用者がいるならば、その不使用者のセッションを切断する。二つ目は、セッション確立要求してきたユーザの優先度未満の優先度の他のユーザのセッションを強制的に切断する。三つ目は、不使用者の存在をチェックする優先度の範囲を、たとえば、セッション確立要求してきたユーザの優先度の一つ上位または一つ下位(ステップ730の優先度以下の判定を優先度未満の判定にすることと等価)の優先度までとする。このように、セッション確立要求してきたユーザのために、他のユーザのセッション切断の可否を、優先度と不使用者の存在の有無の少なくとも一方に基づいて決定することができる。
【0052】
ユーザ3のセッション確立要求に応えられる状況において、優先度テーブル15を参照してユーザ3の優先度を取得し、ユーザ3の接続状況を接続状況テーブル16に登録する(ステップ760)。優先度の取得は、セッション確立要求に含まれるユーザID及びIPアドレスの組(ペア)が優先度テーブル15に含まれているならば、その組に対応する優先度151を取得する。優先度テーブル15に、セッション確立要求に含まれるユーザIDに対応するユーザIDがあり、IPアドレスに対応するIPアドレス153が無く、IPアドレス153が「不定」の場合は含まれているとする。ユーザID及びIPアドレスの組が優先度テーブル15に含まれていないならば、最も低い優先度である。接続状況テーブル16への登録は、セッション確立要求に含まれるユーザIDに対応するユーザID160の、IPアドレス161にセッション確立要求に含まれるIPアドレスを、接続状況162に「接続中」を、優先度163に優先度テーブル15を参照して取得した優先度を、接続日時164に現在時刻を、アクセス回数165に0を、最新アクセス時刻166に現在時刻を、それぞれ格納し、切断時刻167の内容を削除する。次のステップ765の説明から明らかなように、最新アクセス時刻166への現在時刻の格納を省略しても良い。
【0053】
接続状況テーブル16における、ユーザ3の接続状況を更新する(ステップ765)。接続状況の更新は、アクセス要求に含まれるユーザIDに対応するユーザID160の、アクセス回数165をインクリメント(+1)し、最新アクセス時刻166に現在時刻を格納する。
【0054】
アプリケーション5へメッセージを転送し(ステップ770)、ユーザアクセス受付処理部12の処理を終了する。メッセージとは、前述のアクセス要求である。一般にアプリケーション5は、ユーザ3からのアクセス要求に応じて応答するために、アプリケーションレベルでセッションを記憶している。したがって、アプリケーション5へメッセージを転送すると、アプリケーション5は、(1)セッション確立要求の場合は、ユーザ3によるセッションを記憶し、記憶したセッションに対応してユーザ3が用いているクライアント端末2に向けて、たとえばブラウザ用の初期画面を応答として、送信する。(2)アプリケーション5へ接続中のアプリケーション5へのアクセス要求の場合は、記憶しているアプリケーションレベルのセッションを参照して、そのアクセス要求に対応する応答を送信する。(3)サーバ1のアプリケーション5とのセッション切断要求(ログアウト)の場合は、記憶してあるアプリケーションレベルのセッションを削除する。
【0055】
以上説明した実施形態にによれば、クライアント/サーバ・システムの運用状況の変化に応じた優先度を設定できる。
【0056】
具体的には、ユーザ対応に優先度を設定するので、ユーザが使用するクライアント端末に優先度が必ずしも依存しない。
【0057】
さらに、ユーザによるアクセス時間帯に対応したアクセス履歴に基づいて優先度を設定するので、ユーザの業務の繁忙期に応じた優先度を付与することが可能となる。
【符号の説明】
【0058】
1:サーバ、2:クライアント端末、3:ユーザ、4:ネットワーク、5アプリケーション、10:セッション管理システム、11:優先度設定処理部、12:ユーザアクセス受付処理部、13:特権定義テーブル、14:接続履歴データベース、15:優先度テーブル、16:接続状況テーブル。

【特許請求の範囲】
【請求項1】
サーバが有するセッション管理システムであって、
ユーザがクライアント端末を用いて前記サーバにアクセスする時間帯における第1のアクセス回数に基づいて設定した、前記ユーザの前記時間帯における優先度を格納する優先度テープル、
前記ユーザの前記サーバへの接続状況を格納する接続状況テーブル、並びに、
前記ユーザからの前記クライアント端末を用いた前記サーバのアプリケーションへのセッション確立要求に応答して、少なくとも前記セッション確立要求に含まれる前記ユーザのユーザID、前記セッション確立要求に含まれる前記クライアント端末のIPアドレス、前記優先度テーブルに格納された、現在時刻を含む前記時間帯における前記ユーザの前記優先度、および、前記サーバへの接続時刻としての現在時刻を前記接続状況テーブルに格納し、前記アプリケーションへセッション確立するユーザアクセス受付処理部を有することを特徴とするセッション管理システム。
【請求項2】
前記ユーザアクセス受付処理部は、前記アプリケーションへセッション確立後、前記ユーザによる前記クライアント端末を用いた前記アプリケーションへのアクセスに応答して、前記アプリケーションへの第2のアクセス回数と最新アクセス日時を前記接続状況として前記接続状況テーブルに格納することを特徴とする請求項1記載のセッション管理システム。
【請求項3】
前記ユーザアクセス受付処理部は、前記ユーザからの前記クライアント端末を用いた前記サーバの前記アプリケーションへの前記セッション確立要求に応答して、前記サーバへの接続可能なクライアント端末の台数に接続中の他のクライアント端末の台数が達しているとき、前記ユーザの前記優先度と接続中の前記他のクライアント端末を用いた他のユーザの優先度との関係、及び、接続中の前記他のクライアント端末を用いた前記他のユーザが所定時間を超えて前記サーバの前記アプリケーションへアクセスしていない不使用者であるか否かの少なくとも一方に基づいて前記他のユーザのセッション切断の可否を決定することを特徴とする請求項2記載のセッション管理システム。
【請求項4】
前記接続状況テーブルに格納される前記接続状況は、前記アプリケーションへのセッション切断要求に応答して、接続履歴データベースに格納されることを特徴とする請求項3記載のセッション管理システム。
【請求項5】
前記セッション管理システムは、前記接続履歴データベースに格納された前記接続状況を参照して、前記ユーザが前記クライアント端末を用いて前記サーバの前記アプリケーションにアクセスした前記時間帯における第2のアクセス回数に基づいて、前記ユーザの前記時間帯における前記優先度を更新する優先度設定処理部をさらに有することを特徴とする請求項4記載のセッション管理システム。
【請求項6】
前記優先度テーブルは、前記ユーザのユーザIDと前記クライアント端末のIPアドレスとに対応付けて設定された特権としての優先度を前記ユーザの前記優先度として含むことを特徴とする請求項5記載のセッション管理システム。
【請求項7】
サーバが、ユーザがクライアント端末を用いて前記サーバにアクセスするセッションを管理するセッション管理方法であって、前記サーバは、
前記ユーザが前記クライアント端末を用いて前記サーバにアクセスする時間帯におけるアクセス回数に基づいて設定した前記ユーザの前記時間帯における優先度を格納する優先度テープル、及び、前記ユーザの前記サーバへの接続状況を格納する接続状況テーブルを有し、
前記ユーザからの前記クライアント端末を用いた前記サーバのアプリケーションへのセッション確立要求に応答して、少なくとも前記セッション確立要求に含まれる前記ユーザのユーザID、前記セッション確立要求に含まれる前記クライアント端末のIPアドレス、前記優先度テーブルに格納される、現在時刻を含む前記時間帯における前記ユーザの前記優先度、および、前記サーバへの接続時刻として現在時刻を前記接続状況テーブルに格納し、
前記アプリケーションへのセッションを確立することを特徴とするセッション管理方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2012−128722(P2012−128722A)
【公開日】平成24年7月5日(2012.7.5)
【国際特許分類】
【出願番号】特願2010−280494(P2010−280494)
【出願日】平成22年12月16日(2010.12.16)
【出願人】(000233491)株式会社日立システムズ (394)
【Fターム(参考)】