JP3730563B2 - セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 - Google Patents
セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP3730563B2 JP3730563B2 JP2001338090A JP2001338090A JP3730563B2 JP 3730563 B2 JP3730563 B2 JP 3730563B2 JP 2001338090 A JP2001338090 A JP 2001338090A JP 2001338090 A JP2001338090 A JP 2001338090A JP 3730563 B2 JP3730563 B2 JP 3730563B2
- Authority
- JP
- Japan
- Prior art keywords
- record
- session
- session management
- state information
- service
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、分散オブジェクト環境におけるサーバ／クライアント間において、セッション中の状態を保持するセッション管理装置およびセッション管理方法およびプログラムおよび記録媒体に関するものである。
【０００２】
【従来の技術】
分散オブジェクト環境におけるクライアント／サーバ間通信のセッション状態には、ステートレスとステートフルの２つがある。
【０００３】
以下、図１４を参照してステートレスな通信とステートフルな通信について説明する。
【０００４】
図１４は、クライアント／サーバ間の通信における両者のセッション状態を説明する図である。
【０００５】
まず、ステートレスとは、（ａ）に示すように、クライアントからみて、接続するサーバが１回目とそれ以降の通信において違う場合や、（ｂ）に示すように、サーバからみて、接続されるクライアントが１回目とそれ以降の通信において違う場合で、サーバで発生した情報を何らかの手段無しには維持できない状態をいう。
【０００６】
一方、ステートフルとは、（ｃ）に示すように、クライアントとサーバ間の通信において、１回目とそれ以降の通信で処理するサーバプロセスが同じであるため、サーバで発生した情報が維持できる状態をいう。
【０００７】
次に、サーバプロセスをライフサイクルから分類し、そのプロセスの通信がステートレスとステートフルのどちらのセッションになるかを述べる。
【０００８】
プロセスは、予めシステム空間に常駐してクライアントからのサービス要求を待つもの（タイプＩ）と、クライアントからのサービス要求時に生成されるもの（後述するタイプＩＩ，ＩＩＩ）とに分類される。クライアントからのサービス要求時に生成されるものは、さらに、サービス要求毎に生成と消滅を繰り返すもの（タイプＩＩ）と、クライアントが要求する一連のサービス要求（処理を実現するために複数のサービス要求で構成される）毎に生成と消滅を繰り返すもの（タイプＩＩＩ）とに分類される。
【０００９】
タイプＩとタイプＩＩは、ステートレスなセッションであり、タイプＩＩＩはステートフルなセッションである。
【００１０】
また、タイプＩＩは、オーバヘッドがかかるプロセスの生成と消滅が頻発するため、このような処理をする製品は少ないと思われるため、以降、ステートレスなセッションを行うプロセスの対象から除外する。
【００１１】
分散オブジェクト環境を実現するＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）準拠の製品には、ステートレスなセッションのみを実現するものや、ステートレスとステートフルの両方のセッションを実現するものがある。
【００１２】
なお、ＣＯＲＢＡとは、分散オブジェクト技術の規格の一つであり、ＯＭＧ（Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ）が承認するＯＲＢ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）間通信の仕様である。ベンダが提供するＣＯＲＢＡ準拠のＯＲＢ製品を使用することにより、クライアントとサーバが異機種マシンであっても容易に接続することができるようになる。
【００１３】
クライアントがサーバにサービスを要求し、サーバからクライアントに応答が返ることをここでは対話という。この対話は、一回で終了することもあれば複数回のやり取りで完結する場合もある。以下の対話（処理）は、複数回のやりとりで完結する場合を指す。
【００１４】
以下、対話の例としてショッピングカートを挙げる。
【００１５】
（リクエスト１）クライアントは、ある特定のグループの商品一覧を表示するようサーバに要求する。
【００１６】
（レスポンス１）サーバは、要求のあった商品一覧を表示する。
【００１７】
（リクエスト２）クライアントは、商品一覧から、特定の商品を必要個数分ショッピングカートに入れることと、次の商品グループの商品一覧を表示することをサーバに要求する。
【００１８】
（レスポンス２）サーバは要求のあった商品を要求個数分ショッピングカートに格納し、要求のあった商品一覧を表示する。
【００１９】
（リクエスト３）クライアントは、特定の商品を必要個数分ショッピングカートに入れることと、ショッピングカートの中の商品を精算することをサーバに要求する。
【００２０】
（レスポンス３）サーバは、要求のあった商品を要求個数分ショッピングカートに入れ、ショッピングカートの中の商品種類毎に商品単価と個数を掛け合わせ、全合計金額をクライアントに提示する。
【００２１】
ここで、ステートフルな通信の場合、上述したショッピングカート（商品名と購入個数等の情報）は、サーバプロセスの中に持つことが可能である。
【００２２】
しかし、ステートレスな通信の場合、対話（リクエスト−レスポンス）が一回毎に切れてしまい、各対話を処理するサーバプロセスが同一とはかぎらないため、ショッピングカート（商品名と購入個数等の情報）をサーバプロセスの中に持たせることはできない。
【００２３】
以下、前述の商品名と購入個数を持ったショッピングカートのような状態をセッション状態情報といい、これを対話処理中保持する仕組みをセッション管理という。
【００２４】
次に、従来の分散オブジェクト環境におけるクライアント／サーバシステムのセッション管理について、図１５〜図１７を使用して説明する。これらの図では、クライアントとサーバ間の通信手段としてＯＲＢ（分散オブジェクト機構）通信を使用し、通信プロトコルとしてＩＩＯＰ（Ｉｎｔｅｒｎｅｔ Ｉｎｔｅｒ−ＯＲＢ Ｐｒｏｔｏｃｏｌ）を使用しているものとする。
【００２５】
図１５は、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【００２６】
この図におけるクライアント／サーバ間の通信をステートレスなセッションで実現した場合、サーバへの接続クライアントが大量になっても、プロセスの生成／消滅が無いためオーバヘッドが少なく、システムにかかる負荷がステートフルで実現するより少ない。しかし、セッション状態情報をサーバアプリケーションプロセス中に持ったのではセッション管理ができない。
【００２７】
逆にステートフルなセッションで実現した場合、サーバへの接続クライアントが大量な場合、プロセスの生成／消滅が頻発するため、システムにかかる負荷がステートレスで実現するより多い。しかし、セッション状態情報をサーバアプリケーションプロセス中に持つことができる。
【００２８】
しかしながら、ステートフルなセッションで実現した場合でも、図１５のように、同じクライアントアプリケーション５がＯＲＢ３０（ＣＯＲＢＡ準拠の通信ミドルウェア）を介して１回目はサーバアプリケーション４ａと、２回目はサーバアプリケーション４ｂというような場合、セッション状態情報をサーバアプリケーションプロセス中に持ったのではセッション管理ができなくなる。
【００２９】
このような場合や上述のステートレスなセッションで実現する場合、クライアントアプリケーション側でセッション管理をする方法が考えられる。
【００３０】
しかし、クライアントにセッション状態情報を持たせると、セッション状態情報が通信のたびにクライアント／サーバ間を流れ、通信トラフィックが増大し、レスポンス悪化の要因となるという問題点があった。
【００３１】
図１６は、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）の環境で、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【００３２】
図に示すように、Ｗｅｂブラウザ３２のＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）環境で動作するクライアントアプリケーション５は、ＯＲＢ３０の通信で、Ｗｅｂサーバ３３経由でサーバアプリケーション４ａ〜４ｂのサービスを呼び出す。
【００３３】
この場合の、セッション管理方法とその問題は、図１５の場合と同じである。さらに、セッション管理方法の問題以外に、サーバ側にファイアウォールを構築した場合、ＩＩＯＰのＴＣＰ／ＩＰポートを開放しなければならず、このことがセキュリティ管理上敬遠される原因となっている。
【００３４】
図１７は、図１６のファイアウォール構築上の問題を踏まえた形態のクライアント／サーバシステムの一例を示すブロック図である。
【００３５】
図に示すように、サーバ側のみ、すなわちＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４とサーバアプリケーション４ａとサーバアプリケーション４ｂをＣＯＲＢＡオブジェクトとして実装する。
【００３６】
Ｗｅｂサーバ３３内にはＳｅｒｖｌｅｔコンテナがあり、ここでＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４を稼動させ、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４がクライアントアプリケーション５と通信する。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４はクライアントアプリケーション５からのリクエストを受けると対応するサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂのサービスを呼び出す。呼び出されたサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂの処理結果がＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４に返ると、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４はレスポンスをクライアントアプリケーション５に返す。
【００３７】
すなわち、クライアントアプリケーション５とサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂ間の電文情報は、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４を経由してやり取りされる。この場合、クライアントアプリケーション５とＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４間の通信プロトコルはＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）になり、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４とサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂ間の通信はＩＩＯＰとなる。
【００３８】
この形態は、ファイアウォールを構築する場合、ＨＴＴＰのポートを開放するのみで済むため、図１６に示した場合のセキュリティ管理問題はなくなる。
【００３９】
ただし、セッション管理では次のような問題がある。
【００４０】
サーバアプリケーションでのセッション管理は、クライアントアプリケーション５／Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４間の通信プロトコルがＨＴＴＰであるがゆえステートレスセッションになる。そのため、Ｊａｖａ（登録商標）Ｓｅｔｖｌｅｔ３４／サーバアプリケーション４ａもしくはサーバアプリケーション４ｂ間の通信がステートフルセッションであるとしてもセッション管理は困難である。
【００４１】
また、その他のセッション管理の問題は図１５に示した場合と同じである。
【００４２】
この形態では、もう１つの方法として、Ｓｅｒｖｌｅｔ用に用意されているセッション管理のＡＰＩを使用する方法がある。これを使用するとセッション状態情報をオブジェクト化し保存することができる。このオブジェクトはセッションＩＤというもので識別する。対話処理中はセッションＩＤを使用し、セッション情報を管理する。
【００４３】
以下、この形態について図１７を用いて説明する。
【００４４】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、クライアントアプリケーション５からリクエストを受けると、クライアントアプリケーション５からの電文情報をサーバアプリケーション４ａに渡す。
【００４５】
サーバアプリケーション４ａは、処理を行った後、処理結果（電文）とセッション状態情報をＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４に返す。
【００４６】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッション状態情報をセッション管理のＡＰＩを使用してオブジェクト化し、このオブジェクトのセッションＩＤを得る。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、クライアントアプリケーション５にセッションＩＤと電文のレスポンスを返す。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッションＩＤと電文のリクエストをクライアントアプリケーション５から受ける。
【００４７】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッションＩＤに対応するオブジェクトからセッション状態情報を得て、電文とセッション状態情報をサーバアプリケーション４ｂに渡す。同様の処理を以降繰り返す。
【００４８】
この方式は、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４／サーバアプリケーション４ａもしくはサーバアプリケーション４ｂ間のセッションはステートレスとステートフルのどちらでも適用できるため有効ではあるが、ＷＷＷの環境という限定された環境においてのみの使用方法になる。
【００４９】
以上図１５〜図１７に示した例が、ＯＲＢ通信を使用した分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理方法である。
【００５０】
また、分散オブジェクト環境と限らずに、セッションを管理する方法として外部ディスクファイルやメモリを使用する方法がある。
【００５１】
外部ディスクファイルとしては、データベースやインデクス付ファイルを使用する方法が考えられる。
【００５２】
以下、データベースを使用するセッション管理方法とその問題を説明する。
【００５３】
これは、クライアント毎、すなわち対話処理毎に何らかの方法でユニークなセッションＩＤを振り、データベースのキーとしてセッションＩＤを使用する。このキー毎にセッション情報をデータベースレコードに格納する。
【００５４】
この方法は有効ではあるが、業務データであるデータベースアクセスの他にこの様なアクセスも行わなければならないのは、パフォーマンス悪化の要因になり得る。
【００５５】
次に、メモリを使用する方法について説明する。
【００５６】
メモリを使用する方法としては、プロセス内部のメモリを使用する方法と、共有メモリを使用する方法とがある。
【００５７】
まず、プロセス内部のメモリを使用する方法では、発生する対話処理に応じてメモリを逐次アロケーションする方法と、予め発生し得る同時期最大対話処理数分メモリを確保しておく方法がある。前者の場合、高トラフィックが発生した場合、システム系によってはメモリ不足を引き起こす要因になる。一方、後者の場合、予め確保しておいたメモリ内で処理が行われるためメモリ不足になる心配はない。しかし、もしトラフィック量が予測した量を超えた場合、確保したメモリが不足し、セッション情報の保証が難しくなる。
【００５８】
また、共有メモリを使用する方法は、共有メモリにアクセスするプロセスをサーバ上で稼動させ、サーバアプリケーションはこのプロセスを通じてセッション情報の出し入れを行うもの、又はサーバアプリケーションがシステム提供の共有メモリアクセスＡＰＩを使用してセッション情報の出し入れを行うものがある。これらの場合、高トラフィックが発生した場合、共有メモリを多量に使用し、サーバ性能劣化の要因となり得る。
【００５９】
なお、共有メモリを使用してセッション管理をする場合の発展形態である特許出願として、特開２００１−１４２４２がある。この発明においては、セッション管理サーバが分散管理サーバの機能を併せもつことにより、高トラフィック時における多量の共有メモリ使用を防ぐことが可能であると思われるが、サーバ側の負荷分散を行うＴＰモニタ配下で稼動するアプリケーションに適用できるものではない。
【００６０】
また、この発明は、ＷＷＷ環境に限定されるものであり、なおかつサーバアプリケーションの実装がＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）という環境を対象とし、かつセッション管理機能としてＣＧＩによる実装に限定されるものであって、その他の環境において稼動するクライアント／サーバシステムに広く適用されるものではない。
【００６１】
【発明が解決しようとする課題】
上述したように、クライアント／サーバシステムにおいて、セッション状態情報を管理する場合、クライアントで管理する方法、サーバで管理する方法がある。しかし、双方ともに、通信トラフィックの増大に起因して発生するレスポンスの問題、メモリ管理の問題、適用環境の問題、及びサーバ性能劣化の問題等があった。
【００６２】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行う分散オブジェクトとして実装されるセッション管理プロセスが、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部とを備え、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うことにより、分散オブジェクト環境におけるクライアント／サーバシステムにおける対話中のセッションをクライアント／サーバシステムの性能を劣化させることなしに管理することができ、また分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理をプラットフォームに依存することなくフレキシブルに行うことができるセッション管理装置およびセッション管理方法およびプログラムおよび記録媒体を提供することである。
【００６３】
【課題を解決するための手段】
本発明は、分散オブジェクトとして実装されるセッション管理プロセスが、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行うセッション管理装置において、前記セッション管理プロセスは、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部と、を備えるものであり、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うことを特徴とする。
【００７９】
【発明の実施の形態】
まず、本発明のセッション管理装置の概要を説明する。
【００８０】
対話処理を行うクライアント／サーバシステムのサーバが分散オブジェクトとして実装された環境の場合、セッション管理を行う常駐型プロセス（以下、セッション管理プロセスという）を分散オブジェクトのサーバとして実装する。
【００８１】
ここでは、ＣＯＲＢＡ準拠のＯＲＢ製品を使用して分散オブジェクトとして実装する方法を示す。対話処理を行っているサーバアプリケーションとセッション管理プロセスは、分散オブジェクト環境において連携を行いセッション管理を実現する。
【００８２】
セッション管理プロセスは、プロセス内部のメモリとデータベーステーブルを使用し、セッション状態情報を管理する。メモリを使用するのは、セッション管理のスピードを高速化するためであり、データベーステーブルを使用するのはメモリ管理で発生するメモリ不足の問題を解決するためである。
【００８３】
対話処理を行っているサーバアプリケーションのセッション管理プロセスへアクセスするインタフェースは、セッション管理プロセスがＣＯＲＢＡ準拠の分散オブジェクトとして実装されているため、セッション管理プロセスが分散オブジェクト環境内のどこで稼動しようとも変更する必要が無い。このことは、クライアント／サーバ間の対話処理とは別に、セッション管理プロセスのみの最適化を求めマシンの機種やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等のプラットフォーム（ｐｌａｔｆｏｒｍ）を選択することができる可能性があることを意味する。例えば、物理メモリのコストパフォーマンスが高いマシンを選択すれば、大量のメモリを消費できるためセッション管理の高速化が実現できる。
【００８４】
セッション管理プロセスでは、その内部に、セッション状態情報用エリアを確保する。対話処理毎のセッション状態情報はここで管理される。同時期に発生する対話処理が多くなり、すなわち管理すべきセッション状態情報が多くなり、セッション状態情報用エリアがオーバフローした場合、セッション状態情報用エリアから最も古くに管理されたセッション状態情報を抜き出し、それをデータベースで管理する。これにより、最新のセッション状態情報はメモリで管理され、頻繁なサービス要求を行うクライアントには高速なレスポンスを返すことに貢献する。
【００８５】
このセッション状態情報用エリアは、セッション管理プロセス起動時に確保されるため、長時間運転することにより引き起こされるメモリ不足の心配はない。
【００８６】
セッション管理のパフォーマンスを最も上げるには、確保するセッション状態情報用エリアのサイズを、システムの性能が許す限り、同時期に発生し得る対話処理の最大数（以下、最大トラフィック量ともいう）を見込んで設定する。万が一、最大トラフィック量を超えたアクセスが発生したとしても、データベースでも管理されるため安全である。また、データベースでも管理されるということは、予想した最大トラフィック量に、更に安全を見込んだ量のエリアを、すなわち冗長なエリアを加えてメモリ中に確保する必要がなくなる。
【００８７】
セッション管理プロセスは、対話処理毎にユニークなセッションＩＤを付与し、このセッションＩＤ毎にメモリ内のセッション状態情報エリアとデータベーステーブルのテーブルレコードを使用してセッション状態情報を管理する。さらに、このセッションＩＤを使用して、対話処理を行うサーバアプリケーションと連携させることによりセッション管理を行う。
【００８８】
以下、図面を用いて上述した本発明のセッション管理装置の機能を具体的に説明する。
【００８９】
図１は、本発明の一実施形態を示す分散オブジェクト環境で稼動するクライアント／サーバ間のセッション管理装置を適用可能なクライアント／サーバシステムの全体を示すブロック図であり、対話処理とセッション管理プロセスの連携、セッション管理プロセスの構造及びセッション管理プロセスが管理するメモリとデータベーステーブルの構造を示している。
【００９０】
図において、２００はクライアント装置で、例えばパーソナルコンピュータ，ワークステーション等の情報処理装置で構成される。クライアントアプリケーション５は、このクライアント装置２００上で動作する（クライアント装置２００の図示しないＣＰＵにより実行される）。また、１００はサーバ装置であり、例えばパーソナルコンピュータ，ワークステーション等の情報処理装置で構成される。情報処理装置１００，２００は、それぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ハードディスク（ＨＤ）等のその他の記録媒体等を有し、該ＣＰＵによりＲＯＭ，その他の記録媒体に格納されたプログラムをＲＡＭにロードして実行することができる。サーバアプリケーション４は、このサーバ装置１００上で動作する（サーバ装置１００の図示しないＣＰＵにより実行される）。さらに、クライアント装置２００とサーバ装置１００はＬＡＮ，インターネット等のネットワーク３１を介して双方向に通信可能に構成される。
【００９１】
クライアントアプリケーション５とサーバアプリケーション４を含むクライアント／サーバシステムは、ＯＲＢ通信を使用した分散オブジェクト環境で稼動するクライアント／サーバシステムであって、従来の技術の欄で図１５〜図１７に示したいずれの場合であってもよい。
【００９２】
サーバ装置１００において、１はセッション管理プロセス（サーバ装置１００の図示しないＣＰＵにより実行される）で、上述したように対話処理を行うクライアント／サーバシステムのサーバ（サーバアプリケーション４）が分散オブジェクトとして実装されている場合に、ＣＯＲＢＡ準拠のＯＲＢ製品により分散オブジェクトのサーバとして実装され、内部にバッファコントローラ２とセッション管理メモリ３を持ちシステム空間に常駐し、ＯＲＢ３０を介してサーバアプリケーション４と双方向に通信可能である。バッファコントローラ２は、メモリ確保部２１とレコード制御部２２とレコード監視部２３の３部から構成される。
【００９３】
２１はメモリ確保部で、セッション管理プロセス１起動時にセッション管理メモリ３を図示しないＲＡＭ内に確保するとともに、図示しないＨＤ上のデータベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行う。
【００９４】
レコード制御部２２は、セッション状態情報を管理したいアプリケーション（サーバアプリケーション４）からの要求で、セッション管理メモリ内のレコードをセッションＩＤに基づいて制御するものであり、ＯＲＢ３０によりサーバアプリケーション４に提供する下記４つのサービス（２２ａ〜２２ｄ）を持つ。
【００９５】
・レコード割当サービス２２ａ
レコード割当サービス２２ａは、対話処理毎にユニークなセッションＩＤを付与することと、セッション管理メモリ３内にセッションＩＤとセッション状態情報の対を格納するレコードを確保することと、対話処理を行っているサーバアプリケーション４へセッションＩＤを返すことを行う。
【００９６】
・レコード読み込みサービス２２ｂ
レコード読み込みサービス２２ｂは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、セッション管理メモリ３の当該レコードからセッション状態情報を取得することを行う。
【００９７】
・レコード書き込みサービス２２ｃ
レコード書き込みサービス２２ｃは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、セッション状態情報を当該レコードに格納することを行う。
【００９８】
・レコード開放サービス２２ｄ
レコード開放サービス２２ｄは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放する。
【００９９】
レコード監視部２３は、次の３つの機能（▲１▼〜▲３▼）を司る。
【０１００】
▲１▼セッション状態情報過多によりセッション管理メモリ内で管理できなくなったセッション状態情報（例えば、セッション管理メモリ３中の最も昔にアクセスされたレコード（最後にアクセスされてからの経過時間が最も長いレコード））を、レコード割当サービス２２ａからの要求により、データベース６のセッション管理テーブル６１にセッションＩＤをキーにして書き出す。書き出されたセッション管理メモリ３の当該レコードを開放する。
【０１０１】
▲２▼レコード読み込みサービス２２ｂもしくはレコード書き込みサービス２２ｃもしくはレコード開放サービス２２ｄからの要求により、レコード制御部２２で必要となったデータベーステーブル中のセッション状態情報（データベース６のセッション管理テーブル６１内の要求されたレコード）を、セッション管理メモリ３内の開放されているレコードに書き出す。書き出したセッション管理テーブル６１内の当該テーブルレコードは削除する。セッション管理メモリ３内に開放されているレコードが無い場合、セッション管理メモリ３中の最も昔にアクセスされたレコードをセッション管理テーブル６１にセッションＩＤをキーにして書き出し、書き出されたセッション管理メモリ３の当該レコードを開放した後、当該レコードに対してセッション管理テーブル６１内の要求されたレコードを書き出す。
【０１０２】
▲３▼セッション管理メモリ３及びセッション管理テーブル６１のレコード上のタイムスタンプからタイムアウトしたレコードを消去する。
【０１０３】
次に、クライアント装置２００において、クライアントアプリケーション５は、ネットワーク３１を介してサーバアプリケーション４のサービスを呼び出す（リクエストする）ことができる。なお、サーバアプリケーション４は、ＯＲＢ３０でレコード制御部２２の各サービスを呼び出すことによりセッション管理プロセス１との連携を実現し、クライアントアプリケーション５からのリクエストに応じた処理を実行して、該処理結果をレスポンスとしてクライアントアプリケーション５に返信する。
【０１０４】
なお、セッション管理プロセス１は、ＣＯＲＢＡ準拠の分散オブジェクトとして実装するため、レコード制御部２２の各サービス２２ａ〜２２ｄに対する対話処理を行っているサーバアプリケーション４からのインタフェースは、セッション管理プロセスが分散オブジェクト環境で動作する限り、環境に依存しない。すなわち、稼動マシンに変更があってもインタフェースを実装しているサーバアプリケーションに変更は無い。
【０１０５】
よって、図１では、サーバアプリケーション４、セッション管理プロセス１、データベース６が、同一のサーバ装置１００上で実現される場合について説明したが、サーバアプリケーション４、セッション管理プロセス１、データベース６が異なる装置（どのようなプラットフォームであってもよい）上で実現されるように構成することも可能である。
【０１０６】
以上のような構成により、従来の通信トラフィックの増大に起因して発生するレスポンスの問題、メモリ管理の問題、適用環境の問題、及びサーバ性能劣化の問題を、セッション管理を行う常駐型プロセスの構築により解決するものであり、対話処理を行う分散オブジェクトとして実装されたサーバアプリケーション４と、システム空間に常駐する分散オブジェクトとして実装されたセッション管理プロセス１との連携によりセッション状態情報の管理を実現することができる。
【０１０７】
なお、セッション状態情報としては、ショッピングカートのような、セッション中に発生する全ての情報を対象としている。
【０１０８】
図２は、図１に示したクライアント／サーバシステムのセッション管理の流れを示す図であり、図１と同一のものには同一の符号を付してある。以下、図２をもとに、セッション管理の流れを説明する。
【０１０９】
セッション管理プロセス１の起動時、バッファコントローラ２内のメモリ確保部２１は、サーバ装置１００内の図示しないＨＤに記憶されるプロパティファイル７から、セッション状態情報を格納することができる最大レコード数と、セッション状態情報エリア長を読み込む。
【０１１０】
次にメモリ確保部２１は、セッション管理メモリ３として（最大レコード数×セッション状態情報エリア長）分のエリアを確保する。また、データベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行う。
【０１１１】
クライアントアプリケーション５ａが、サーバアプリケーション４ａと対話を開始すると、サーバアプリケーション４ａは、レコード割当サービス２２ａに対し、レコード割当の依頼を行う。
【０１１２】
レコード割当サービス２２ａは、セッション管理メモリ３の中から、現在利用されてないレコードを見つける。図２ではレコード３ａを見つけている。レコード割当サービス２２ａは、セッションＩＤとしてユニークなキーコードを振る。図２では「１」が振られている。レコード割当サービス２２ａは、レコード３ａのセッションＩＤエリアにセッションＩＤの「１」を格納する。レコード割当サービス２２ａは、セッションＩＤの「１」をサーバアプリケーション４ａに返す。
【０１１３】
サーバアプリケーション４ａは、図示しないデータベースアクセス等の処理（クライアントアプリケーション５からのリクエストに応じた処理）をした後、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１１４】
サーバアプリケーション４ａは、クライアントアプリケーション５ａにセッションＩＤの「１」と処理結果を返す。
【０１１５】
次に、クライアントアプリケーション５ａが、サーバアプリケーション４ａにセッションＩＤの「１」を含めたサービス要求を行うと、サーバアプリケーション４ａは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１１６】
レコード読み込みサービス２２ｂはセッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ａに返す。
【０１１７】
サーバアプリケーション４ａは、クライアントアプリケーション５からのデータとセッション状態情報を元に処理（クライアントアプリケーション５からのリクエストに応じた処理）を行う。
【０１１８】
サーバアプリケーション４ａは、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。
【０１１９】
レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１２０】
サーバアプリケーション４ａは、クライアントアプリケーション５ａにセッションＩＤの「１」と処理結果を返す。
【０１２１】
次に、クライアントアプリケーション５ａが、サーバアプリケーション４ｂにＩＤの「１」を含めたサービス要求を行うと、サーバアプリケーション４ｂは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１２２】
レコード読み込みサービス２２ｂは、セッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ｂに返す。
【０１２３】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａからのデータとセッション状態情報を元に処理（クライアントアプリケーション５ａからのリクエストに応じた処理）を行う。
【０１２４】
サーバアプリケーション４ｂは、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。
【０１２５】
レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１２６】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａにセッションＩＤの「１」を含めた応答を返す。
【０１２７】
クライアントアプリケーション５ａは、サーバアプリケーション４ｂにセッションＩＤの「１」を含めた対話処理の終了要求を行う。
【０１２８】
サーバアプリケーション４ｂは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１２９】
レコード読み込みサービス２２ｂはセッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ｂに返す。
【０１３０】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａからのデータとセッション状態情報を元に終了処理を行う。
【０１３１】
サーバアプリケーション４ｂは、レコード開放サービス２２ｄにセッションＩＤの「１」を渡す。
【０１３２】
レコード開放サービス２２ｄは、セッションＩＤが「１」であるレコード３ａを開放する。
【０１３３】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａに最終応答を返す。
【０１３４】
図２の点線は、クライアントアプリケーション５ｂが、サーバアプリケーション４ｃ及びサーバアプリケーション４ｄのサービスを呼び出し、サーバアプリケーション４ｃ及びサーバアプリケーション４ｄがセッション管理プロセス１と連携して、レコード３ｂに対してセッション状態情報の書き込みや読み込みを行っていることを表わしている。
【０１３５】
レコード割当サービス２２ａは、全てのレコードが割当されていて新規に割当することができない場合、レコード監視部２３に、レコードを開放するよう要求する。
【０１３６】
レコード監視部２３は、最も昔にアクセスされたレコードの内容をデータベース６のセッション管理テーブル６１にセッションＩＤをキーにして待避させる。そして、当該レコードを開放する。開放した結果をレコード割当サービス２２ａに返す。
【０１３７】
レコード割当サービス２２ａは、処理を続行する。
【０１３８】
レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄのそれぞれがセッション管理メモリ３にアクセスして、セッションＩＤに対応するレコードを見つけることができない場合、レコード監視部２３に、セッションＩＤが一致する当該レコードがないかセッション管理テーブル６１を検索するよう要求する。
【０１３９】
レコード監視部２３は、セッション管理テーブル６１を、セッションＩＤをキーにして検索する。当該レコードが存在した場合、セッション管理メモリ３の空きレコードに当該レコードを戻す。空きが無い場合は、前述の開放処理を行う。
【０１４０】
レコード監視部２３は、当該レコードがセッション管理メモリ３に戻ったことを要求元に応答する。
【０１４１】
レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄのそれぞれは処理を続行する。
【０１４２】
レコード監視部２３は、セッション管理メモリ３及びセッション管理テーブル６１のレコード上のタイムスタンプを常時監視し、タイムアウトしたレコードを削除する。
【０１４３】
以上が、セッション管理の流れである。
【０１４４】
以下、図３〜図１０のフローチャートを参照して、図１に示したクライアント／サーバシステムのセッション管理手順について説明する。
【０１４５】
図３は、本発明の実施形態における第１の制御処理手順の一例を示すフローチャートであり、図１に示したクライアントアプリケーション５における処理に対応する。なお、このフローチャートの処理は、図１に示したクライアント装置２００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ１０１〜Ｓ１０８は各ステップを示す。
【０１４６】
まず、ステップＳ１０１において、クライアントアプリケーション５は、サーバアプリケーション４に対話開始要求（開始リクエスト）を送信し、ステップＳ１０２において、サーバアプリケーション４からレスポンスとしてセッションＩＤと処理結果を受信すると、ステップＳ１０３において、受信した処理結果を表示する。
【０１４７】
次に、ステップＳ１０４において、対話を終了するか否かを判定し、まだ対話を終了しない場合は、ステップＳ１０５において、クライアントアプリケーション５は、サーバアプリケーション４にセッションＩＤを含めたサービス要求（リクエスト）を行い、ステップＳ１０２に戻る。
【０１４８】
一方、ステップＳ１０４で、対話を終了する場合は、ステップＳ１０６において、クライアントアプリケーション５は、サーバアプリケーション４にセッションＩＤを含めた対話処理の終了要求（終了リクエスト）を行う。
【０１４９】
次に、ステップＳ１０７において、サーバアプリケーション４からの最終応答を受信し、ステップＳ１０８において、最終処理結果を表示し、処理を終了する。
【０１５０】
なお、図３のステップＳ１０１，Ｓ１０５，Ｓ１０６でサーバアプリケーションに対して行なっているリクエストは、それぞれ異なるサーバアプリケーションに対するものであってもよい（例えば、図２に示したサーバアプリケーション４ａ〜４ｂ）。但し、リクエストとそのレスポンスは一組となっており、同一のクライアントアプリケーションとサーバアプリケーションとの間で行なわれるものとする。
【０１５１】
図４〜図６は、本発明の実施形態における第２の制御処理手順の一例を示すフローチャートであり、図１に示したサーバアプリケーション４における処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ２０１〜Ｓ２１８は各ステップを示す。
【０１５２】
まず、ステップＳ２０１において、クライアントアプリケーション５からのリクエストを受け、ステップＳ２０２において、該リクエストが対話開始要求であるか否かを判定し、対話開始要求であると判定された場合は、ステップＳ２０３において、セッション管理プロセス１のレコード割当サービス２２ａにレコード割当の依頼を行い、ステップＳ２０４において、セッション管理プロセスのレコード割当サービス２２ａからセッションＩＤを取得する。
【０１５３】
次に、ステップＳ２０５において、クライアントアプリケーション５から対話開始要求時にリクエストされた処理を実行し、ステップＳ２０６において、セッション管理プロセス１のレコード書き込みサービス２２ｃにセッションＩＤとセッション状態情報を送信してセッション状態情報の書き込みを依頼する。
【０１５４】
次に、ステップＳ２０７において、クライアントアプリケーション５に、セッションＩＤと処理結果を送信し、ステップＳ２０１に戻る。
【０１５５】
また、ステップＳ２０２で、クライアントアプリケーション５からのリクエストが対話開始要求でないと判定された場合は、ステップＳ２０８において、クライアントアプリケーション５からのリクエストが対話終了要求であるか否かを判定し、対話終了要求でないと判定された場合は、ステップＳ２０９において、セッション管理プロセス１のレコード読み込みサービス２２ｂにセッションＩＤを送信してセッション状態の読み込みを依頼する。
【０１５６】
ステップＳ２１０において、セッション管理プロセス１のレコード読み込みサービス２２ｂからセッション状態情報を取得すると、ステップＳ２１１において、クラアントアプリケーション５からリクエストされた処理を実行し、ステップＳ２１２において、サーバアプリケーション４は、セッション管理プロセス１のレコード書き込みサービス２２ｃに、セッションＩＤとセッション状態情報を送信してセッション状態の書き込み依頼を行う。
【０１５７】
次に、ステップＳ２１３において、クライアントアプリケーション５に、セッションＩＤと処理結果を送信し、ステップＳ２０１に戻る。
【０１５８】
一方、ステップＳ２０８で、クライアントアプリケーション５からのリクエストが対話終了要求であると判定された場合は、ステップＳ２１４において、セッション管理プロセス１のレコード読み込みサービス２２ｂにセッションＩＤを送信してレコード（セッション状態）の読み込みを依頼する。
【０１５９】
ステップＳ２１５において、セッション管理プロセス１のレコード読み込みサービス２２ｂからセッション状態情報を取得すると、ステップＳ２１６において、終了処理を実行する。
【０１６０】
次に、ステップＳ２１７において、セッション管理プロセス１のレコード開放サービス２２ｄにレコード開放を依頼し、ステップＳ２１８において、クライアントアプリケーション５に、最終応答を送信し、ステップＳ２０１に戻る。
【０１６１】
なお、図４〜図６に示したサーバアプリケーションのプロセスは、従来の技術の欄に示したタイプＩのように、予めシステム空間に常駐してクライアントからのサービス要求を待つものであっても、従来の技術の欄に示したタイプＩＩ，ＩＩＩのように、クライアントからのサービス要求時に生成されるものであってもよく、また、クライアントアプリケーションからの開始要求に対する処理であるステップＳ２０３〜Ｓ２０７と、開始／終了要求以外の要求に対する処理であるステップＳ２０９〜Ｓ２１３と、終了要求に対する処理であるステップＳ２１４〜Ｓ２１８とは、同一のサーバアプリケーション（プロセス）で行なってもよいし、図２に示したサーバアプリケーション４ａ〜４ｂのように、それぞれ異なるサーバアプリケーション（プロセス）で行なってもよい。
【０１６２】
以下、図７〜図１０を参照してセッション管理プロセス１の各サービスについて説明する。なお、セッション管理プロセス１は、予め起動時にセッションバッファコントローラ２内のメモリ確保部２１により、サーバ装置１００内の図示しないＨＤに記憶されるプロパティファイル７から、セッション状態情報を格納することができる最大レコード数と、セッション状態情報エリア長を読み込み、セッション管理メモリ３として（最大レコード数×セッション状態情報エリア長）分のエリアを確保し、さらに、データベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行っているものとする。
【０１６３】
図７は、本発明の実施形態における第３の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード割当サービス２２ａの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ３０１〜Ｓ３０４は各ステップを示す。
【０１６４】
サーバアプリケーション４からのレコード割当依頼を受信すると、ステップＳ３０１において、レコード割当サービス２２ａは、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、現在使用していないレコードがあると判定された場合は、ステップＳ３０３に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ３０２において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１６５】
次に、ステップＳ３０３において、レコード割当サービス２２ａは、セッションＩＤとしてユニークなレコードを割り振り、セッション管理メモリ３に格納し、ステップＳ３０４において、レコード割当サービス２２ａは、サーバアプリケーション４にセッションＩＤを送信し、処理を終了する。
【０１６６】
図８は、本発明の実施形態における第４の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード読み込みサービス２２ｂの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ４０１〜Ｓ４０８は各ステップを示す。
【０１６７】
サーバアプリケーション４からのレコード読み込み依頼を受信すると、ステップＳ４０１において、レコード読み込みサービス２２ｂは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、有ると判定された場合は、ステップＳ４０６に進む。一方、無いと判定された場合は、ステップＳ４０２において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ４０８において、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１６８】
一方、ステップＳ４０２で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ４０３において、レコード監視部２３により、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、あると判定された場合は、ステップＳ４０５に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ４０４において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１６９】
次に、ステップＳ４０５において、レコード監視部２３により、データベース６からセッション管理メモリ３にレコードを戻す。
【０１７０】
次に、ステップＳ４０６において、レコード読み込みサービス２２ｂは、セッションＩＤに対応するレコードのセッション状態情報を読み込み、ステップＳ４０７において、レコード読み込みサービス２２ｂは、サーバアプリケーション４にセッション状態情報を送信し、処理を終了する。
【０１７１】
図９は、本発明の実施形態における第５の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード書き込みサービス２２ｃの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ５０１〜Ｓ５０７は各ステップを示す。
【０１７２】
サーバアプリケーション４からレコード書き込み依頼を受信すると、ステップＳ５０１において、レコード書き込みサービス２２ｃは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、有ると判定された場合は、ステップＳ５０６に進む。一方、無いと判定された場合は、ステップＳ５０２において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ５０７において、レコード書き込みサービス２２ｃは、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１７３】
一方、ステップＳ５０２で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ５０３において、レコード書き込みサービス２２ｃは、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、あると判定された場合は、ステップＳ５０５に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ５０４において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１７４】
次に、ステップＳ５０５において、レコード監視部２３により、データベース６からセッション管理メモリ３にレコードを戻す。
【０１７５】
次に、ステップＳ５０６において、レコード書き込みサービス２２ｃは、セッションＩＤに対応するレコードにセッション状態情報を書き込み、処理を終了する。
【０１７６】
図１０は、本発明の実施形態における第６の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード開放サービス２２ｄの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ６０１〜Ｓ６０５は各ステップを示す。
【０１７７】
サーバアプリケーション４からレコード開放依頼を受信すると、ステップＳ６０１において、レコード開放サービス２２ｄは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、あると判定された場合は、ステップＳ６０２において、レコード開放サービス２２ｄは、セッションＩＤに対応するレコードをセッション管理メモリ３から開放し、処理を終了する。
【０１７８】
一方、ステップＳ６０１で、セッションＩＤに対応するレコードがセッション管理メモリ３にないと判定された場合は、ステップＳ６０３において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ６０５において、レコード開放サービス２２ｄは、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１７９】
一方、ステップＳ６０３で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ６０４において、レコード監視部２３により、セッションＩＤに対応するレコードをデータベース６から削除する。
【０１８０】
以下、セッション管理プロセス１とＣＯＲＢＡとの関連について説明する。
【０１８１】
ＣＯＲＢＡには、インタフェース定義言語ＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）が規定されている。ＩＤＬには、サーバで使用可能なオぺレーションを記述する。ここでオペレーションとは、メソッドとメソッドの属性とメソッドのパラメータのことであり、図２においては、レコード割当サービス２２ａ、レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄの各サービスがオペレーションになる。
【０１８２】
ＩＤＬをＣＯＲＢＡ準拠のＩＤＬコンパイラでコンパイルすると、クライアント用にスタブとサーバ用にスケルトンクラス（以下、スケルトンという）が生成される。
【０１８３】
スタブは、ＯＲＢを介して、クライアントがサーバのオペレーションを呼び出すために使用される。スケルトンは、サーバのオペレーションの属性やパラメータが記述されている。これをクラス継承して、オペレーションを実装する。
【０１８４】
図１１は、ＩＤＬ定義からスタブとスケルトンを生成する構成について示す図である。
【０１８５】
図に示すように、セッション管理プロセス１内のレコード制御部２２の図２に示した４つのオペレーション（サービス）は、各オペレーションのインタフェースが定義してあるＩＤＬ定義２０ａからＩＤＬコンパイラ２０ｂによってコンパイルされることにより、レコード制御部内各サービススタブ２０ｃとレコード制御部内各サービススケルトン２０ｄが生成される。
【０１８６】
図１２は、図１１に示したＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブ２０ｃとレコード制御部内各サービススケルトン２０ｄの使用方法を示す図である。
【０１８７】
図において、１１ａはレコード制御部内各サービスアクセスＡＰＩで、サーバアプリケーション４に対してレコード制御部の各サービスを呼び出す手段を提供するものであり、ＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブ２０ｃを包含する。
【０１８８】
１１ｂはレコード制御部内各サービスで、ＩＤＬコンパイルによって生成されたレコード制御部内各サービススケルトン２０ｄを継承しており、レコード制御部内の各サービスが実装されている。
【０１８９】
図に示すように、サーバアプリケーション４は、レコード制御部内各サービスアクセスＡＰＩ１１ａを呼び出すと、ＯＲＢ３０経由で、レコード制御部内各サービス１１ｂを呼び出すことができる。
【０１９０】
以上説明したように、本実施形態では、分散オブジェクト環境において対話処理を行うクライアントアプリケーション５とサーバアプリケーション４間のセッション管理を、サーバに常駐する分散オブジェクトとして実装したセッション管理プロセス１と連携して行い、セッション管理プロセス１内のバッファコントローラ２は、セッション管理メモリ３とデータベース６内のセッション管理テーブル６１の組み合わせでセッション状態情報を管理し、さらに、バッファコントローラ２は、内部にメモリの確保を行うメモリ確保部２１と、セッション状態情報が格納されるセッション管理メモリ３内のレコードを管理するレコード制御部２２とセッション管理メモリ３とセッション管理テーブル６１間でレコードの入出力を行うレコード監視部２３を持ち、さらに、レコード制御部２２は分散オブジェクトのサービスを内部に持ち、この分散オブジェクトのサービスとして、セッション管理メモリ３内のレコードを割り当てるレコード割当サービス２２ａと、セッション管理メモリ３から当該レコードを読み込むレコード読み込みサービス２２ｂと、セッション管理メモリ３に当該レコードを書き込むレコード書き込みサービス２２ｃと、セッション管理メモリ３内の当該レコードを開放するレコード開放サービス２２ｄがあり、各サービスは分散オブジェクト環境において、サーバアプリケーション４からサービス要求されるように構成したことにより、ＷＷＷ環境に限定されない分散オブジェクト環境におけるクライアント／サーバシステムにおいて、クライアント／サーバ間の通信がステートレス，ステートフルのいずれであっても、対話中のセッションを、クライアント／サーバシステムの性能を劣化させずに管理することができる。
【０１９１】
以上より、本発明は、セッション状態情報の管理をサーバ常駐プロセスのメモリ（図に示したプロセス管理メモリ３）で行うため高速に管理することができる。
【０１９２】
また、予測した管理すべき状態情報の量が超過した場合においても、超過分は外部記憶装置で管理されるためデータロストの発生を防止して安全に管理を行うことができる。
【０１９３】
さらに、以下の２つの効果を奏する。
【０１９４】
１つめは、対話処理サーバプロセス稼動マシン（サーバアプリケーション４が稼動するサーバ装置）と状態情報管理プロセスマシン（セッション管理プロセス１が稼動するセッション管理装置）とを別け、かつ状態情報管理プロセスマシンはこれのみの性能を考慮したマシンにすれば、対話処理サーバプロセス稼動マシンの性能を劣化させずに、高速な状態情報の管理ができる。さらに、状態情報管理プロセスマシンとして、安価なメモリ等の費用対効果が上がるものを選択し、それが結果的に対話処理サーバプロセス稼動マシンと異機種（異ＯＳ）になっても、ＣＯＲＢＡにより、その連携は容易に構築することができる。
【０１９５】
２つめは、状態情報管理プロセスマシンの種類に関わらず、状態情報管理プロセスマシンにアクセスする対話処理サーバプロセスの方法は唯一つである。すなわち、状態情報管理プロセスが稼動するマシンに変更があったとしても、対話処理サーバプロセスは全く変更する必要がなくフレキシブルなセッション管理環境を提供することができる。
【０１９６】
以下、図１３に示すメモリマップを参照して本発明に係るセッション管理装置を適用可能なシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１９７】
図１３は、本発明に係るセッション管理装置を適用可能なシステムで読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１９８】
なお、特に図示しないが、記録媒体に記録されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記録され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記録される場合もある。
【０１９９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記録される場合もある。
【０２００】
本実施形態における図４〜図６，図７，図８，図９，図１０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０２０１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０２０２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【０２０３】
プログラムコードを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０２０４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２０７】
さらに、本発明を達成するためのソフトウエアによって表されるプログラムをネットワーク上のデータベースから通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２０８】
【発明の効果】
以上説明したように、本発明によれば、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行う分散オブジェクトとして実装されるセッション管理プロセスが、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部とを備え、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うので、分散オブジェクト環境におけるクライアント／サーバシステムにおける対話中のセッションをクライアント／サーバシステムの性能を劣化させることなしに高速かつ安全に管理することができる。
【０２０９】
また、分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理をプラットフォームに依存することなくフレキシブルに行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態を示す分散オブジェクト環境で稼動するクライアント／サーバ間のセッション管理装置を適用可能なクライアント／サーバシステムの全体を示すブロック図である。
【図２】図１に示したクライアント／サーバシステムのセッション管理の流れを示す図である。
【図３】本発明の実施形態における第１の制御処理手順の一例を示すフローチャートである。
【図４】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図５】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図６】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図７】本発明の実施形態における第３の制御処理手順の一例を示すフローチャートである。
【図８】本発明の実施形態における第４の制御処理手順の一例を示すフローチャートである。
【図９】本発明の実施形態における第５の制御処理手順の一例を示すフローチャートである。
【図１０】本発明の実施形態における第６の制御処理手順の一例を示すフローチャートである。
【図１１】ＩＤＬ定義からスタブとスケルトンを生成する構成について示す図である。
【図１２】図１１に示したＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブとレコード制御部内各サービススケルトンの使用方法を示す図である。
【図１３】本発明に係るセッション管理装置を適用可能なシステムで読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【図１４】クライアント／サーバ間の通信における両者のセッション状態を説明する図である。
【図１５】クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【図１６】ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）の環境で、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【図１７】図１６のファイアウォール構築上の問題を踏まえた形態のクライアント／サーバシステムの一例を示すブロック図である。
【符号の説明】
１ セッション管理プロセス
２ バッファコントローラ
３ セッション管理メモリ
４ サーバアプリケーション
５ クライアントアプリケーション
６ データベース
７ プロパティファイル
２１ メモリ確保部
２２ レコード制御部
２２ａ レコード割当サービス
２２ｂ レコード読み込みサービス
２２ｃ レコード書き込みサービス
２２ｄ レコード開放サービス
２３ レコード監視部
３０ ＯＲＢ
３１ ネットワーク
６１ セッション管理テーブル
１００ サーバ装置
２００ クライアント装置
【発明の属する技術分野】
本発明は、分散オブジェクト環境におけるサーバ／クライアント間において、セッション中の状態を保持するセッション管理装置およびセッション管理方法およびプログラムおよび記録媒体に関するものである。
【０００２】
【従来の技術】
分散オブジェクト環境におけるクライアント／サーバ間通信のセッション状態には、ステートレスとステートフルの２つがある。
【０００３】
以下、図１４を参照してステートレスな通信とステートフルな通信について説明する。
【０００４】
図１４は、クライアント／サーバ間の通信における両者のセッション状態を説明する図である。
【０００５】
まず、ステートレスとは、（ａ）に示すように、クライアントからみて、接続するサーバが１回目とそれ以降の通信において違う場合や、（ｂ）に示すように、サーバからみて、接続されるクライアントが１回目とそれ以降の通信において違う場合で、サーバで発生した情報を何らかの手段無しには維持できない状態をいう。
【０００６】
一方、ステートフルとは、（ｃ）に示すように、クライアントとサーバ間の通信において、１回目とそれ以降の通信で処理するサーバプロセスが同じであるため、サーバで発生した情報が維持できる状態をいう。
【０００７】
次に、サーバプロセスをライフサイクルから分類し、そのプロセスの通信がステートレスとステートフルのどちらのセッションになるかを述べる。
【０００８】
プロセスは、予めシステム空間に常駐してクライアントからのサービス要求を待つもの（タイプＩ）と、クライアントからのサービス要求時に生成されるもの（後述するタイプＩＩ，ＩＩＩ）とに分類される。クライアントからのサービス要求時に生成されるものは、さらに、サービス要求毎に生成と消滅を繰り返すもの（タイプＩＩ）と、クライアントが要求する一連のサービス要求（処理を実現するために複数のサービス要求で構成される）毎に生成と消滅を繰り返すもの（タイプＩＩＩ）とに分類される。
【０００９】
タイプＩとタイプＩＩは、ステートレスなセッションであり、タイプＩＩＩはステートフルなセッションである。
【００１０】
また、タイプＩＩは、オーバヘッドがかかるプロセスの生成と消滅が頻発するため、このような処理をする製品は少ないと思われるため、以降、ステートレスなセッションを行うプロセスの対象から除外する。
【００１１】
分散オブジェクト環境を実現するＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）準拠の製品には、ステートレスなセッションのみを実現するものや、ステートレスとステートフルの両方のセッションを実現するものがある。
【００１２】
なお、ＣＯＲＢＡとは、分散オブジェクト技術の規格の一つであり、ＯＭＧ（Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ）が承認するＯＲＢ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）間通信の仕様である。ベンダが提供するＣＯＲＢＡ準拠のＯＲＢ製品を使用することにより、クライアントとサーバが異機種マシンであっても容易に接続することができるようになる。
【００１３】
クライアントがサーバにサービスを要求し、サーバからクライアントに応答が返ることをここでは対話という。この対話は、一回で終了することもあれば複数回のやり取りで完結する場合もある。以下の対話（処理）は、複数回のやりとりで完結する場合を指す。
【００１４】
以下、対話の例としてショッピングカートを挙げる。
【００１５】
（リクエスト１）クライアントは、ある特定のグループの商品一覧を表示するようサーバに要求する。
【００１６】
（レスポンス１）サーバは、要求のあった商品一覧を表示する。
【００１７】
（リクエスト２）クライアントは、商品一覧から、特定の商品を必要個数分ショッピングカートに入れることと、次の商品グループの商品一覧を表示することをサーバに要求する。
【００１８】
（レスポンス２）サーバは要求のあった商品を要求個数分ショッピングカートに格納し、要求のあった商品一覧を表示する。
【００１９】
（リクエスト３）クライアントは、特定の商品を必要個数分ショッピングカートに入れることと、ショッピングカートの中の商品を精算することをサーバに要求する。
【００２０】
（レスポンス３）サーバは、要求のあった商品を要求個数分ショッピングカートに入れ、ショッピングカートの中の商品種類毎に商品単価と個数を掛け合わせ、全合計金額をクライアントに提示する。
【００２１】
ここで、ステートフルな通信の場合、上述したショッピングカート（商品名と購入個数等の情報）は、サーバプロセスの中に持つことが可能である。
【００２２】
しかし、ステートレスな通信の場合、対話（リクエスト−レスポンス）が一回毎に切れてしまい、各対話を処理するサーバプロセスが同一とはかぎらないため、ショッピングカート（商品名と購入個数等の情報）をサーバプロセスの中に持たせることはできない。
【００２３】
以下、前述の商品名と購入個数を持ったショッピングカートのような状態をセッション状態情報といい、これを対話処理中保持する仕組みをセッション管理という。
【００２４】
次に、従来の分散オブジェクト環境におけるクライアント／サーバシステムのセッション管理について、図１５〜図１７を使用して説明する。これらの図では、クライアントとサーバ間の通信手段としてＯＲＢ（分散オブジェクト機構）通信を使用し、通信プロトコルとしてＩＩＯＰ（Ｉｎｔｅｒｎｅｔ Ｉｎｔｅｒ−ＯＲＢ Ｐｒｏｔｏｃｏｌ）を使用しているものとする。
【００２５】
図１５は、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【００２６】
この図におけるクライアント／サーバ間の通信をステートレスなセッションで実現した場合、サーバへの接続クライアントが大量になっても、プロセスの生成／消滅が無いためオーバヘッドが少なく、システムにかかる負荷がステートフルで実現するより少ない。しかし、セッション状態情報をサーバアプリケーションプロセス中に持ったのではセッション管理ができない。
【００２７】
逆にステートフルなセッションで実現した場合、サーバへの接続クライアントが大量な場合、プロセスの生成／消滅が頻発するため、システムにかかる負荷がステートレスで実現するより多い。しかし、セッション状態情報をサーバアプリケーションプロセス中に持つことができる。
【００２８】
しかしながら、ステートフルなセッションで実現した場合でも、図１５のように、同じクライアントアプリケーション５がＯＲＢ３０（ＣＯＲＢＡ準拠の通信ミドルウェア）を介して１回目はサーバアプリケーション４ａと、２回目はサーバアプリケーション４ｂというような場合、セッション状態情報をサーバアプリケーションプロセス中に持ったのではセッション管理ができなくなる。
【００２９】
このような場合や上述のステートレスなセッションで実現する場合、クライアントアプリケーション側でセッション管理をする方法が考えられる。
【００３０】
しかし、クライアントにセッション状態情報を持たせると、セッション状態情報が通信のたびにクライアント／サーバ間を流れ、通信トラフィックが増大し、レスポンス悪化の要因となるという問題点があった。
【００３１】
図１６は、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）の環境で、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【００３２】
図に示すように、Ｗｅｂブラウザ３２のＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）環境で動作するクライアントアプリケーション５は、ＯＲＢ３０の通信で、Ｗｅｂサーバ３３経由でサーバアプリケーション４ａ〜４ｂのサービスを呼び出す。
【００３３】
この場合の、セッション管理方法とその問題は、図１５の場合と同じである。さらに、セッション管理方法の問題以外に、サーバ側にファイアウォールを構築した場合、ＩＩＯＰのＴＣＰ／ＩＰポートを開放しなければならず、このことがセキュリティ管理上敬遠される原因となっている。
【００３４】
図１７は、図１６のファイアウォール構築上の問題を踏まえた形態のクライアント／サーバシステムの一例を示すブロック図である。
【００３５】
図に示すように、サーバ側のみ、すなわちＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４とサーバアプリケーション４ａとサーバアプリケーション４ｂをＣＯＲＢＡオブジェクトとして実装する。
【００３６】
Ｗｅｂサーバ３３内にはＳｅｒｖｌｅｔコンテナがあり、ここでＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４を稼動させ、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４がクライアントアプリケーション５と通信する。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４はクライアントアプリケーション５からのリクエストを受けると対応するサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂのサービスを呼び出す。呼び出されたサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂの処理結果がＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４に返ると、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４はレスポンスをクライアントアプリケーション５に返す。
【００３７】
すなわち、クライアントアプリケーション５とサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂ間の電文情報は、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４を経由してやり取りされる。この場合、クライアントアプリケーション５とＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４間の通信プロトコルはＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）になり、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４とサーバアプリケーション４ａ、もしくはサーバアプリケーション４ｂ間の通信はＩＩＯＰとなる。
【００３８】
この形態は、ファイアウォールを構築する場合、ＨＴＴＰのポートを開放するのみで済むため、図１６に示した場合のセキュリティ管理問題はなくなる。
【００３９】
ただし、セッション管理では次のような問題がある。
【００４０】
サーバアプリケーションでのセッション管理は、クライアントアプリケーション５／Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４間の通信プロトコルがＨＴＴＰであるがゆえステートレスセッションになる。そのため、Ｊａｖａ（登録商標）Ｓｅｔｖｌｅｔ３４／サーバアプリケーション４ａもしくはサーバアプリケーション４ｂ間の通信がステートフルセッションであるとしてもセッション管理は困難である。
【００４１】
また、その他のセッション管理の問題は図１５に示した場合と同じである。
【００４２】
この形態では、もう１つの方法として、Ｓｅｒｖｌｅｔ用に用意されているセッション管理のＡＰＩを使用する方法がある。これを使用するとセッション状態情報をオブジェクト化し保存することができる。このオブジェクトはセッションＩＤというもので識別する。対話処理中はセッションＩＤを使用し、セッション情報を管理する。
【００４３】
以下、この形態について図１７を用いて説明する。
【００４４】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、クライアントアプリケーション５からリクエストを受けると、クライアントアプリケーション５からの電文情報をサーバアプリケーション４ａに渡す。
【００４５】
サーバアプリケーション４ａは、処理を行った後、処理結果（電文）とセッション状態情報をＪａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４に返す。
【００４６】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッション状態情報をセッション管理のＡＰＩを使用してオブジェクト化し、このオブジェクトのセッションＩＤを得る。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、クライアントアプリケーション５にセッションＩＤと電文のレスポンスを返す。Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッションＩＤと電文のリクエストをクライアントアプリケーション５から受ける。
【００４７】
Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４は、セッションＩＤに対応するオブジェクトからセッション状態情報を得て、電文とセッション状態情報をサーバアプリケーション４ｂに渡す。同様の処理を以降繰り返す。
【００４８】
この方式は、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔ３４／サーバアプリケーション４ａもしくはサーバアプリケーション４ｂ間のセッションはステートレスとステートフルのどちらでも適用できるため有効ではあるが、ＷＷＷの環境という限定された環境においてのみの使用方法になる。
【００４９】
以上図１５〜図１７に示した例が、ＯＲＢ通信を使用した分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理方法である。
【００５０】
また、分散オブジェクト環境と限らずに、セッションを管理する方法として外部ディスクファイルやメモリを使用する方法がある。
【００５１】
外部ディスクファイルとしては、データベースやインデクス付ファイルを使用する方法が考えられる。
【００５２】
以下、データベースを使用するセッション管理方法とその問題を説明する。
【００５３】
これは、クライアント毎、すなわち対話処理毎に何らかの方法でユニークなセッションＩＤを振り、データベースのキーとしてセッションＩＤを使用する。このキー毎にセッション情報をデータベースレコードに格納する。
【００５４】
この方法は有効ではあるが、業務データであるデータベースアクセスの他にこの様なアクセスも行わなければならないのは、パフォーマンス悪化の要因になり得る。
【００５５】
次に、メモリを使用する方法について説明する。
【００５６】
メモリを使用する方法としては、プロセス内部のメモリを使用する方法と、共有メモリを使用する方法とがある。
【００５７】
まず、プロセス内部のメモリを使用する方法では、発生する対話処理に応じてメモリを逐次アロケーションする方法と、予め発生し得る同時期最大対話処理数分メモリを確保しておく方法がある。前者の場合、高トラフィックが発生した場合、システム系によってはメモリ不足を引き起こす要因になる。一方、後者の場合、予め確保しておいたメモリ内で処理が行われるためメモリ不足になる心配はない。しかし、もしトラフィック量が予測した量を超えた場合、確保したメモリが不足し、セッション情報の保証が難しくなる。
【００５８】
また、共有メモリを使用する方法は、共有メモリにアクセスするプロセスをサーバ上で稼動させ、サーバアプリケーションはこのプロセスを通じてセッション情報の出し入れを行うもの、又はサーバアプリケーションがシステム提供の共有メモリアクセスＡＰＩを使用してセッション情報の出し入れを行うものがある。これらの場合、高トラフィックが発生した場合、共有メモリを多量に使用し、サーバ性能劣化の要因となり得る。
【００５９】
なお、共有メモリを使用してセッション管理をする場合の発展形態である特許出願として、特開２００１−１４２４２がある。この発明においては、セッション管理サーバが分散管理サーバの機能を併せもつことにより、高トラフィック時における多量の共有メモリ使用を防ぐことが可能であると思われるが、サーバ側の負荷分散を行うＴＰモニタ配下で稼動するアプリケーションに適用できるものではない。
【００６０】
また、この発明は、ＷＷＷ環境に限定されるものであり、なおかつサーバアプリケーションの実装がＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）という環境を対象とし、かつセッション管理機能としてＣＧＩによる実装に限定されるものであって、その他の環境において稼動するクライアント／サーバシステムに広く適用されるものではない。
【００６１】
【発明が解決しようとする課題】
上述したように、クライアント／サーバシステムにおいて、セッション状態情報を管理する場合、クライアントで管理する方法、サーバで管理する方法がある。しかし、双方ともに、通信トラフィックの増大に起因して発生するレスポンスの問題、メモリ管理の問題、適用環境の問題、及びサーバ性能劣化の問題等があった。
【００６２】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行う分散オブジェクトとして実装されるセッション管理プロセスが、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部とを備え、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うことにより、分散オブジェクト環境におけるクライアント／サーバシステムにおける対話中のセッションをクライアント／サーバシステムの性能を劣化させることなしに管理することができ、また分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理をプラットフォームに依存することなくフレキシブルに行うことができるセッション管理装置およびセッション管理方法およびプログラムおよび記録媒体を提供することである。
【００６３】
【課題を解決するための手段】
本発明は、分散オブジェクトとして実装されるセッション管理プロセスが、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行うセッション管理装置において、前記セッション管理プロセスは、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部と、を備えるものであり、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うことを特徴とする。
【００７９】
【発明の実施の形態】
まず、本発明のセッション管理装置の概要を説明する。
【００８０】
対話処理を行うクライアント／サーバシステムのサーバが分散オブジェクトとして実装された環境の場合、セッション管理を行う常駐型プロセス（以下、セッション管理プロセスという）を分散オブジェクトのサーバとして実装する。
【００８１】
ここでは、ＣＯＲＢＡ準拠のＯＲＢ製品を使用して分散オブジェクトとして実装する方法を示す。対話処理を行っているサーバアプリケーションとセッション管理プロセスは、分散オブジェクト環境において連携を行いセッション管理を実現する。
【００８２】
セッション管理プロセスは、プロセス内部のメモリとデータベーステーブルを使用し、セッション状態情報を管理する。メモリを使用するのは、セッション管理のスピードを高速化するためであり、データベーステーブルを使用するのはメモリ管理で発生するメモリ不足の問題を解決するためである。
【００８３】
対話処理を行っているサーバアプリケーションのセッション管理プロセスへアクセスするインタフェースは、セッション管理プロセスがＣＯＲＢＡ準拠の分散オブジェクトとして実装されているため、セッション管理プロセスが分散オブジェクト環境内のどこで稼動しようとも変更する必要が無い。このことは、クライアント／サーバ間の対話処理とは別に、セッション管理プロセスのみの最適化を求めマシンの機種やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等のプラットフォーム（ｐｌａｔｆｏｒｍ）を選択することができる可能性があることを意味する。例えば、物理メモリのコストパフォーマンスが高いマシンを選択すれば、大量のメモリを消費できるためセッション管理の高速化が実現できる。
【００８４】
セッション管理プロセスでは、その内部に、セッション状態情報用エリアを確保する。対話処理毎のセッション状態情報はここで管理される。同時期に発生する対話処理が多くなり、すなわち管理すべきセッション状態情報が多くなり、セッション状態情報用エリアがオーバフローした場合、セッション状態情報用エリアから最も古くに管理されたセッション状態情報を抜き出し、それをデータベースで管理する。これにより、最新のセッション状態情報はメモリで管理され、頻繁なサービス要求を行うクライアントには高速なレスポンスを返すことに貢献する。
【００８５】
このセッション状態情報用エリアは、セッション管理プロセス起動時に確保されるため、長時間運転することにより引き起こされるメモリ不足の心配はない。
【００８６】
セッション管理のパフォーマンスを最も上げるには、確保するセッション状態情報用エリアのサイズを、システムの性能が許す限り、同時期に発生し得る対話処理の最大数（以下、最大トラフィック量ともいう）を見込んで設定する。万が一、最大トラフィック量を超えたアクセスが発生したとしても、データベースでも管理されるため安全である。また、データベースでも管理されるということは、予想した最大トラフィック量に、更に安全を見込んだ量のエリアを、すなわち冗長なエリアを加えてメモリ中に確保する必要がなくなる。
【００８７】
セッション管理プロセスは、対話処理毎にユニークなセッションＩＤを付与し、このセッションＩＤ毎にメモリ内のセッション状態情報エリアとデータベーステーブルのテーブルレコードを使用してセッション状態情報を管理する。さらに、このセッションＩＤを使用して、対話処理を行うサーバアプリケーションと連携させることによりセッション管理を行う。
【００８８】
以下、図面を用いて上述した本発明のセッション管理装置の機能を具体的に説明する。
【００８９】
図１は、本発明の一実施形態を示す分散オブジェクト環境で稼動するクライアント／サーバ間のセッション管理装置を適用可能なクライアント／サーバシステムの全体を示すブロック図であり、対話処理とセッション管理プロセスの連携、セッション管理プロセスの構造及びセッション管理プロセスが管理するメモリとデータベーステーブルの構造を示している。
【００９０】
図において、２００はクライアント装置で、例えばパーソナルコンピュータ，ワークステーション等の情報処理装置で構成される。クライアントアプリケーション５は、このクライアント装置２００上で動作する（クライアント装置２００の図示しないＣＰＵにより実行される）。また、１００はサーバ装置であり、例えばパーソナルコンピュータ，ワークステーション等の情報処理装置で構成される。情報処理装置１００，２００は、それぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ハードディスク（ＨＤ）等のその他の記録媒体等を有し、該ＣＰＵによりＲＯＭ，その他の記録媒体に格納されたプログラムをＲＡＭにロードして実行することができる。サーバアプリケーション４は、このサーバ装置１００上で動作する（サーバ装置１００の図示しないＣＰＵにより実行される）。さらに、クライアント装置２００とサーバ装置１００はＬＡＮ，インターネット等のネットワーク３１を介して双方向に通信可能に構成される。
【００９１】
クライアントアプリケーション５とサーバアプリケーション４を含むクライアント／サーバシステムは、ＯＲＢ通信を使用した分散オブジェクト環境で稼動するクライアント／サーバシステムであって、従来の技術の欄で図１５〜図１７に示したいずれの場合であってもよい。
【００９２】
サーバ装置１００において、１はセッション管理プロセス（サーバ装置１００の図示しないＣＰＵにより実行される）で、上述したように対話処理を行うクライアント／サーバシステムのサーバ（サーバアプリケーション４）が分散オブジェクトとして実装されている場合に、ＣＯＲＢＡ準拠のＯＲＢ製品により分散オブジェクトのサーバとして実装され、内部にバッファコントローラ２とセッション管理メモリ３を持ちシステム空間に常駐し、ＯＲＢ３０を介してサーバアプリケーション４と双方向に通信可能である。バッファコントローラ２は、メモリ確保部２１とレコード制御部２２とレコード監視部２３の３部から構成される。
【００９３】
２１はメモリ確保部で、セッション管理プロセス１起動時にセッション管理メモリ３を図示しないＲＡＭ内に確保するとともに、図示しないＨＤ上のデータベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行う。
【００９４】
レコード制御部２２は、セッション状態情報を管理したいアプリケーション（サーバアプリケーション４）からの要求で、セッション管理メモリ内のレコードをセッションＩＤに基づいて制御するものであり、ＯＲＢ３０によりサーバアプリケーション４に提供する下記４つのサービス（２２ａ〜２２ｄ）を持つ。
【００９５】
・レコード割当サービス２２ａ
レコード割当サービス２２ａは、対話処理毎にユニークなセッションＩＤを付与することと、セッション管理メモリ３内にセッションＩＤとセッション状態情報の対を格納するレコードを確保することと、対話処理を行っているサーバアプリケーション４へセッションＩＤを返すことを行う。
【００９６】
・レコード読み込みサービス２２ｂ
レコード読み込みサービス２２ｂは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、セッション管理メモリ３の当該レコードからセッション状態情報を取得することを行う。
【００９７】
・レコード書き込みサービス２２ｃ
レコード書き込みサービス２２ｃは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、セッション状態情報を当該レコードに格納することを行う。
【００９８】
・レコード開放サービス２２ｄ
レコード開放サービス２２ｄは、対話処理を行っているサーバアプリケーション４からのセッションＩＤを基に、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放する。
【００９９】
レコード監視部２３は、次の３つの機能（▲１▼〜▲３▼）を司る。
【０１００】
▲１▼セッション状態情報過多によりセッション管理メモリ内で管理できなくなったセッション状態情報（例えば、セッション管理メモリ３中の最も昔にアクセスされたレコード（最後にアクセスされてからの経過時間が最も長いレコード））を、レコード割当サービス２２ａからの要求により、データベース６のセッション管理テーブル６１にセッションＩＤをキーにして書き出す。書き出されたセッション管理メモリ３の当該レコードを開放する。
【０１０１】
▲２▼レコード読み込みサービス２２ｂもしくはレコード書き込みサービス２２ｃもしくはレコード開放サービス２２ｄからの要求により、レコード制御部２２で必要となったデータベーステーブル中のセッション状態情報（データベース６のセッション管理テーブル６１内の要求されたレコード）を、セッション管理メモリ３内の開放されているレコードに書き出す。書き出したセッション管理テーブル６１内の当該テーブルレコードは削除する。セッション管理メモリ３内に開放されているレコードが無い場合、セッション管理メモリ３中の最も昔にアクセスされたレコードをセッション管理テーブル６１にセッションＩＤをキーにして書き出し、書き出されたセッション管理メモリ３の当該レコードを開放した後、当該レコードに対してセッション管理テーブル６１内の要求されたレコードを書き出す。
【０１０２】
▲３▼セッション管理メモリ３及びセッション管理テーブル６１のレコード上のタイムスタンプからタイムアウトしたレコードを消去する。
【０１０３】
次に、クライアント装置２００において、クライアントアプリケーション５は、ネットワーク３１を介してサーバアプリケーション４のサービスを呼び出す（リクエストする）ことができる。なお、サーバアプリケーション４は、ＯＲＢ３０でレコード制御部２２の各サービスを呼び出すことによりセッション管理プロセス１との連携を実現し、クライアントアプリケーション５からのリクエストに応じた処理を実行して、該処理結果をレスポンスとしてクライアントアプリケーション５に返信する。
【０１０４】
なお、セッション管理プロセス１は、ＣＯＲＢＡ準拠の分散オブジェクトとして実装するため、レコード制御部２２の各サービス２２ａ〜２２ｄに対する対話処理を行っているサーバアプリケーション４からのインタフェースは、セッション管理プロセスが分散オブジェクト環境で動作する限り、環境に依存しない。すなわち、稼動マシンに変更があってもインタフェースを実装しているサーバアプリケーションに変更は無い。
【０１０５】
よって、図１では、サーバアプリケーション４、セッション管理プロセス１、データベース６が、同一のサーバ装置１００上で実現される場合について説明したが、サーバアプリケーション４、セッション管理プロセス１、データベース６が異なる装置（どのようなプラットフォームであってもよい）上で実現されるように構成することも可能である。
【０１０６】
以上のような構成により、従来の通信トラフィックの増大に起因して発生するレスポンスの問題、メモリ管理の問題、適用環境の問題、及びサーバ性能劣化の問題を、セッション管理を行う常駐型プロセスの構築により解決するものであり、対話処理を行う分散オブジェクトとして実装されたサーバアプリケーション４と、システム空間に常駐する分散オブジェクトとして実装されたセッション管理プロセス１との連携によりセッション状態情報の管理を実現することができる。
【０１０７】
なお、セッション状態情報としては、ショッピングカートのような、セッション中に発生する全ての情報を対象としている。
【０１０８】
図２は、図１に示したクライアント／サーバシステムのセッション管理の流れを示す図であり、図１と同一のものには同一の符号を付してある。以下、図２をもとに、セッション管理の流れを説明する。
【０１０９】
セッション管理プロセス１の起動時、バッファコントローラ２内のメモリ確保部２１は、サーバ装置１００内の図示しないＨＤに記憶されるプロパティファイル７から、セッション状態情報を格納することができる最大レコード数と、セッション状態情報エリア長を読み込む。
【０１１０】
次にメモリ確保部２１は、セッション管理メモリ３として（最大レコード数×セッション状態情報エリア長）分のエリアを確保する。また、データベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行う。
【０１１１】
クライアントアプリケーション５ａが、サーバアプリケーション４ａと対話を開始すると、サーバアプリケーション４ａは、レコード割当サービス２２ａに対し、レコード割当の依頼を行う。
【０１１２】
レコード割当サービス２２ａは、セッション管理メモリ３の中から、現在利用されてないレコードを見つける。図２ではレコード３ａを見つけている。レコード割当サービス２２ａは、セッションＩＤとしてユニークなキーコードを振る。図２では「１」が振られている。レコード割当サービス２２ａは、レコード３ａのセッションＩＤエリアにセッションＩＤの「１」を格納する。レコード割当サービス２２ａは、セッションＩＤの「１」をサーバアプリケーション４ａに返す。
【０１１３】
サーバアプリケーション４ａは、図示しないデータベースアクセス等の処理（クライアントアプリケーション５からのリクエストに応じた処理）をした後、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１１４】
サーバアプリケーション４ａは、クライアントアプリケーション５ａにセッションＩＤの「１」と処理結果を返す。
【０１１５】
次に、クライアントアプリケーション５ａが、サーバアプリケーション４ａにセッションＩＤの「１」を含めたサービス要求を行うと、サーバアプリケーション４ａは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１１６】
レコード読み込みサービス２２ｂはセッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ａに返す。
【０１１７】
サーバアプリケーション４ａは、クライアントアプリケーション５からのデータとセッション状態情報を元に処理（クライアントアプリケーション５からのリクエストに応じた処理）を行う。
【０１１８】
サーバアプリケーション４ａは、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。
【０１１９】
レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１２０】
サーバアプリケーション４ａは、クライアントアプリケーション５ａにセッションＩＤの「１」と処理結果を返す。
【０１２１】
次に、クライアントアプリケーション５ａが、サーバアプリケーション４ｂにＩＤの「１」を含めたサービス要求を行うと、サーバアプリケーション４ｂは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１２２】
レコード読み込みサービス２２ｂは、セッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ｂに返す。
【０１２３】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａからのデータとセッション状態情報を元に処理（クライアントアプリケーション５ａからのリクエストに応じた処理）を行う。
【０１２４】
サーバアプリケーション４ｂは、レコード書き込みサービス２２ｃに対し、セッションＩＤの「１」とセッション状態情報を渡す。
【０１２５】
レコード書き込みサービス２２ｃは、セッションＩＤが「１」であるレコード３ａのセッション状態情報エリアに、セッション状態情報を格納する。
【０１２６】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａにセッションＩＤの「１」を含めた応答を返す。
【０１２７】
クライアントアプリケーション５ａは、サーバアプリケーション４ｂにセッションＩＤの「１」を含めた対話処理の終了要求を行う。
【０１２８】
サーバアプリケーション４ｂは、レコード読み込みサービス２２ｂにセッションＩＤの「１」を渡す。
【０１２９】
レコード読み込みサービス２２ｂはセッションＩＤが「１」であるレコード３ａからセッション状態情報を読み込み、セッション状態情報をサーバアプリケーション４ｂに返す。
【０１３０】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａからのデータとセッション状態情報を元に終了処理を行う。
【０１３１】
サーバアプリケーション４ｂは、レコード開放サービス２２ｄにセッションＩＤの「１」を渡す。
【０１３２】
レコード開放サービス２２ｄは、セッションＩＤが「１」であるレコード３ａを開放する。
【０１３３】
サーバアプリケーション４ｂは、クライアントアプリケーション５ａに最終応答を返す。
【０１３４】
図２の点線は、クライアントアプリケーション５ｂが、サーバアプリケーション４ｃ及びサーバアプリケーション４ｄのサービスを呼び出し、サーバアプリケーション４ｃ及びサーバアプリケーション４ｄがセッション管理プロセス１と連携して、レコード３ｂに対してセッション状態情報の書き込みや読み込みを行っていることを表わしている。
【０１３５】
レコード割当サービス２２ａは、全てのレコードが割当されていて新規に割当することができない場合、レコード監視部２３に、レコードを開放するよう要求する。
【０１３６】
レコード監視部２３は、最も昔にアクセスされたレコードの内容をデータベース６のセッション管理テーブル６１にセッションＩＤをキーにして待避させる。そして、当該レコードを開放する。開放した結果をレコード割当サービス２２ａに返す。
【０１３７】
レコード割当サービス２２ａは、処理を続行する。
【０１３８】
レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄのそれぞれがセッション管理メモリ３にアクセスして、セッションＩＤに対応するレコードを見つけることができない場合、レコード監視部２３に、セッションＩＤが一致する当該レコードがないかセッション管理テーブル６１を検索するよう要求する。
【０１３９】
レコード監視部２３は、セッション管理テーブル６１を、セッションＩＤをキーにして検索する。当該レコードが存在した場合、セッション管理メモリ３の空きレコードに当該レコードを戻す。空きが無い場合は、前述の開放処理を行う。
【０１４０】
レコード監視部２３は、当該レコードがセッション管理メモリ３に戻ったことを要求元に応答する。
【０１４１】
レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄのそれぞれは処理を続行する。
【０１４２】
レコード監視部２３は、セッション管理メモリ３及びセッション管理テーブル６１のレコード上のタイムスタンプを常時監視し、タイムアウトしたレコードを削除する。
【０１４３】
以上が、セッション管理の流れである。
【０１４４】
以下、図３〜図１０のフローチャートを参照して、図１に示したクライアント／サーバシステムのセッション管理手順について説明する。
【０１４５】
図３は、本発明の実施形態における第１の制御処理手順の一例を示すフローチャートであり、図１に示したクライアントアプリケーション５における処理に対応する。なお、このフローチャートの処理は、図１に示したクライアント装置２００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ１０１〜Ｓ１０８は各ステップを示す。
【０１４６】
まず、ステップＳ１０１において、クライアントアプリケーション５は、サーバアプリケーション４に対話開始要求（開始リクエスト）を送信し、ステップＳ１０２において、サーバアプリケーション４からレスポンスとしてセッションＩＤと処理結果を受信すると、ステップＳ１０３において、受信した処理結果を表示する。
【０１４７】
次に、ステップＳ１０４において、対話を終了するか否かを判定し、まだ対話を終了しない場合は、ステップＳ１０５において、クライアントアプリケーション５は、サーバアプリケーション４にセッションＩＤを含めたサービス要求（リクエスト）を行い、ステップＳ１０２に戻る。
【０１４８】
一方、ステップＳ１０４で、対話を終了する場合は、ステップＳ１０６において、クライアントアプリケーション５は、サーバアプリケーション４にセッションＩＤを含めた対話処理の終了要求（終了リクエスト）を行う。
【０１４９】
次に、ステップＳ１０７において、サーバアプリケーション４からの最終応答を受信し、ステップＳ１０８において、最終処理結果を表示し、処理を終了する。
【０１５０】
なお、図３のステップＳ１０１，Ｓ１０５，Ｓ１０６でサーバアプリケーションに対して行なっているリクエストは、それぞれ異なるサーバアプリケーションに対するものであってもよい（例えば、図２に示したサーバアプリケーション４ａ〜４ｂ）。但し、リクエストとそのレスポンスは一組となっており、同一のクライアントアプリケーションとサーバアプリケーションとの間で行なわれるものとする。
【０１５１】
図４〜図６は、本発明の実施形態における第２の制御処理手順の一例を示すフローチャートであり、図１に示したサーバアプリケーション４における処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ２０１〜Ｓ２１８は各ステップを示す。
【０１５２】
まず、ステップＳ２０１において、クライアントアプリケーション５からのリクエストを受け、ステップＳ２０２において、該リクエストが対話開始要求であるか否かを判定し、対話開始要求であると判定された場合は、ステップＳ２０３において、セッション管理プロセス１のレコード割当サービス２２ａにレコード割当の依頼を行い、ステップＳ２０４において、セッション管理プロセスのレコード割当サービス２２ａからセッションＩＤを取得する。
【０１５３】
次に、ステップＳ２０５において、クライアントアプリケーション５から対話開始要求時にリクエストされた処理を実行し、ステップＳ２０６において、セッション管理プロセス１のレコード書き込みサービス２２ｃにセッションＩＤとセッション状態情報を送信してセッション状態情報の書き込みを依頼する。
【０１５４】
次に、ステップＳ２０７において、クライアントアプリケーション５に、セッションＩＤと処理結果を送信し、ステップＳ２０１に戻る。
【０１５５】
また、ステップＳ２０２で、クライアントアプリケーション５からのリクエストが対話開始要求でないと判定された場合は、ステップＳ２０８において、クライアントアプリケーション５からのリクエストが対話終了要求であるか否かを判定し、対話終了要求でないと判定された場合は、ステップＳ２０９において、セッション管理プロセス１のレコード読み込みサービス２２ｂにセッションＩＤを送信してセッション状態の読み込みを依頼する。
【０１５６】
ステップＳ２１０において、セッション管理プロセス１のレコード読み込みサービス２２ｂからセッション状態情報を取得すると、ステップＳ２１１において、クラアントアプリケーション５からリクエストされた処理を実行し、ステップＳ２１２において、サーバアプリケーション４は、セッション管理プロセス１のレコード書き込みサービス２２ｃに、セッションＩＤとセッション状態情報を送信してセッション状態の書き込み依頼を行う。
【０１５７】
次に、ステップＳ２１３において、クライアントアプリケーション５に、セッションＩＤと処理結果を送信し、ステップＳ２０１に戻る。
【０１５８】
一方、ステップＳ２０８で、クライアントアプリケーション５からのリクエストが対話終了要求であると判定された場合は、ステップＳ２１４において、セッション管理プロセス１のレコード読み込みサービス２２ｂにセッションＩＤを送信してレコード（セッション状態）の読み込みを依頼する。
【０１５９】
ステップＳ２１５において、セッション管理プロセス１のレコード読み込みサービス２２ｂからセッション状態情報を取得すると、ステップＳ２１６において、終了処理を実行する。
【０１６０】
次に、ステップＳ２１７において、セッション管理プロセス１のレコード開放サービス２２ｄにレコード開放を依頼し、ステップＳ２１８において、クライアントアプリケーション５に、最終応答を送信し、ステップＳ２０１に戻る。
【０１６１】
なお、図４〜図６に示したサーバアプリケーションのプロセスは、従来の技術の欄に示したタイプＩのように、予めシステム空間に常駐してクライアントからのサービス要求を待つものであっても、従来の技術の欄に示したタイプＩＩ，ＩＩＩのように、クライアントからのサービス要求時に生成されるものであってもよく、また、クライアントアプリケーションからの開始要求に対する処理であるステップＳ２０３〜Ｓ２０７と、開始／終了要求以外の要求に対する処理であるステップＳ２０９〜Ｓ２１３と、終了要求に対する処理であるステップＳ２１４〜Ｓ２１８とは、同一のサーバアプリケーション（プロセス）で行なってもよいし、図２に示したサーバアプリケーション４ａ〜４ｂのように、それぞれ異なるサーバアプリケーション（プロセス）で行なってもよい。
【０１６２】
以下、図７〜図１０を参照してセッション管理プロセス１の各サービスについて説明する。なお、セッション管理プロセス１は、予め起動時にセッションバッファコントローラ２内のメモリ確保部２１により、サーバ装置１００内の図示しないＨＤに記憶されるプロパティファイル７から、セッション状態情報を格納することができる最大レコード数と、セッション状態情報エリア長を読み込み、セッション管理メモリ３として（最大レコード数×セッション状態情報エリア長）分のエリアを確保し、さらに、データベース６と接続を行いセッション管理テーブル６１のテーブルレコードにアクセスする準備を行っているものとする。
【０１６３】
図７は、本発明の実施形態における第３の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード割当サービス２２ａの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ３０１〜Ｓ３０４は各ステップを示す。
【０１６４】
サーバアプリケーション４からのレコード割当依頼を受信すると、ステップＳ３０１において、レコード割当サービス２２ａは、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、現在使用していないレコードがあると判定された場合は、ステップＳ３０３に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ３０２において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１６５】
次に、ステップＳ３０３において、レコード割当サービス２２ａは、セッションＩＤとしてユニークなレコードを割り振り、セッション管理メモリ３に格納し、ステップＳ３０４において、レコード割当サービス２２ａは、サーバアプリケーション４にセッションＩＤを送信し、処理を終了する。
【０１６６】
図８は、本発明の実施形態における第４の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード読み込みサービス２２ｂの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ４０１〜Ｓ４０８は各ステップを示す。
【０１６７】
サーバアプリケーション４からのレコード読み込み依頼を受信すると、ステップＳ４０１において、レコード読み込みサービス２２ｂは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、有ると判定された場合は、ステップＳ４０６に進む。一方、無いと判定された場合は、ステップＳ４０２において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ４０８において、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１６８】
一方、ステップＳ４０２で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ４０３において、レコード監視部２３により、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、あると判定された場合は、ステップＳ４０５に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ４０４において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１６９】
次に、ステップＳ４０５において、レコード監視部２３により、データベース６からセッション管理メモリ３にレコードを戻す。
【０１７０】
次に、ステップＳ４０６において、レコード読み込みサービス２２ｂは、セッションＩＤに対応するレコードのセッション状態情報を読み込み、ステップＳ４０７において、レコード読み込みサービス２２ｂは、サーバアプリケーション４にセッション状態情報を送信し、処理を終了する。
【０１７１】
図９は、本発明の実施形態における第５の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード書き込みサービス２２ｃの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ５０１〜Ｓ５０７は各ステップを示す。
【０１７２】
サーバアプリケーション４からレコード書き込み依頼を受信すると、ステップＳ５０１において、レコード書き込みサービス２２ｃは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、有ると判定された場合は、ステップＳ５０６に進む。一方、無いと判定された場合は、ステップＳ５０２において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ５０７において、レコード書き込みサービス２２ｃは、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１７３】
一方、ステップＳ５０２で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ５０３において、レコード書き込みサービス２２ｃは、セッション管理メモリ３に現在使用していないレコードがあるか否かを判定し、あると判定された場合は、ステップＳ５０５に進む。一方、現在使用していないレコードがないと判定された場合は、ステップＳ５０４において、レコード監視部２３により、最も昔にアクセスされたレコードをデータベース６に待避させる。
【０１７４】
次に、ステップＳ５０５において、レコード監視部２３により、データベース６からセッション管理メモリ３にレコードを戻す。
【０１７５】
次に、ステップＳ５０６において、レコード書き込みサービス２２ｃは、セッションＩＤに対応するレコードにセッション状態情報を書き込み、処理を終了する。
【０１７６】
図１０は、本発明の実施形態における第６の制御処理手順の一例を示すフローチャートであり、図１に示したセッション管理プロセス１のレコード開放サービス２２ｄの処理に対応する。なお、このフローチャートの処理は、図１に示したサーバ装置１００の図示しないＣＰＵにより記録媒体に格納されたプログラムに基づいて実行されるものとする。また、Ｓ６０１〜Ｓ６０５は各ステップを示す。
【０１７７】
サーバアプリケーション４からレコード開放依頼を受信すると、ステップＳ６０１において、レコード開放サービス２２ｄは、セッションＩＤに対応するレコードがセッション管理メモリ３にあるか否かを判定し、あると判定された場合は、ステップＳ６０２において、レコード開放サービス２２ｄは、セッションＩＤに対応するレコードをセッション管理メモリ３から開放し、処理を終了する。
【０１７８】
一方、ステップＳ６０１で、セッションＩＤに対応するレコードがセッション管理メモリ３にないと判定された場合は、ステップＳ６０３において、レコード監視部２３により、セッションＩＤに対応するレコードがデータベース６にあるか否かを判定し、無いと判定された場合は、ステップＳ６０５において、レコード開放サービス２２ｄは、サーバアプリケーション４にエラー情報を送信し、処理を終了する。
【０１７９】
一方、ステップＳ６０３で、セッションＩＤに対応するレコードがデータベース６に有ると判定された場合は、ステップＳ６０４において、レコード監視部２３により、セッションＩＤに対応するレコードをデータベース６から削除する。
【０１８０】
以下、セッション管理プロセス１とＣＯＲＢＡとの関連について説明する。
【０１８１】
ＣＯＲＢＡには、インタフェース定義言語ＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）が規定されている。ＩＤＬには、サーバで使用可能なオぺレーションを記述する。ここでオペレーションとは、メソッドとメソッドの属性とメソッドのパラメータのことであり、図２においては、レコード割当サービス２２ａ、レコード読み込みサービス２２ｂ、レコード書き込みサービス２２ｃ、レコード開放サービス２２ｄの各サービスがオペレーションになる。
【０１８２】
ＩＤＬをＣＯＲＢＡ準拠のＩＤＬコンパイラでコンパイルすると、クライアント用にスタブとサーバ用にスケルトンクラス（以下、スケルトンという）が生成される。
【０１８３】
スタブは、ＯＲＢを介して、クライアントがサーバのオペレーションを呼び出すために使用される。スケルトンは、サーバのオペレーションの属性やパラメータが記述されている。これをクラス継承して、オペレーションを実装する。
【０１８４】
図１１は、ＩＤＬ定義からスタブとスケルトンを生成する構成について示す図である。
【０１８５】
図に示すように、セッション管理プロセス１内のレコード制御部２２の図２に示した４つのオペレーション（サービス）は、各オペレーションのインタフェースが定義してあるＩＤＬ定義２０ａからＩＤＬコンパイラ２０ｂによってコンパイルされることにより、レコード制御部内各サービススタブ２０ｃとレコード制御部内各サービススケルトン２０ｄが生成される。
【０１８６】
図１２は、図１１に示したＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブ２０ｃとレコード制御部内各サービススケルトン２０ｄの使用方法を示す図である。
【０１８７】
図において、１１ａはレコード制御部内各サービスアクセスＡＰＩで、サーバアプリケーション４に対してレコード制御部の各サービスを呼び出す手段を提供するものであり、ＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブ２０ｃを包含する。
【０１８８】
１１ｂはレコード制御部内各サービスで、ＩＤＬコンパイルによって生成されたレコード制御部内各サービススケルトン２０ｄを継承しており、レコード制御部内の各サービスが実装されている。
【０１８９】
図に示すように、サーバアプリケーション４は、レコード制御部内各サービスアクセスＡＰＩ１１ａを呼び出すと、ＯＲＢ３０経由で、レコード制御部内各サービス１１ｂを呼び出すことができる。
【０１９０】
以上説明したように、本実施形態では、分散オブジェクト環境において対話処理を行うクライアントアプリケーション５とサーバアプリケーション４間のセッション管理を、サーバに常駐する分散オブジェクトとして実装したセッション管理プロセス１と連携して行い、セッション管理プロセス１内のバッファコントローラ２は、セッション管理メモリ３とデータベース６内のセッション管理テーブル６１の組み合わせでセッション状態情報を管理し、さらに、バッファコントローラ２は、内部にメモリの確保を行うメモリ確保部２１と、セッション状態情報が格納されるセッション管理メモリ３内のレコードを管理するレコード制御部２２とセッション管理メモリ３とセッション管理テーブル６１間でレコードの入出力を行うレコード監視部２３を持ち、さらに、レコード制御部２２は分散オブジェクトのサービスを内部に持ち、この分散オブジェクトのサービスとして、セッション管理メモリ３内のレコードを割り当てるレコード割当サービス２２ａと、セッション管理メモリ３から当該レコードを読み込むレコード読み込みサービス２２ｂと、セッション管理メモリ３に当該レコードを書き込むレコード書き込みサービス２２ｃと、セッション管理メモリ３内の当該レコードを開放するレコード開放サービス２２ｄがあり、各サービスは分散オブジェクト環境において、サーバアプリケーション４からサービス要求されるように構成したことにより、ＷＷＷ環境に限定されない分散オブジェクト環境におけるクライアント／サーバシステムにおいて、クライアント／サーバ間の通信がステートレス，ステートフルのいずれであっても、対話中のセッションを、クライアント／サーバシステムの性能を劣化させずに管理することができる。
【０１９１】
以上より、本発明は、セッション状態情報の管理をサーバ常駐プロセスのメモリ（図に示したプロセス管理メモリ３）で行うため高速に管理することができる。
【０１９２】
また、予測した管理すべき状態情報の量が超過した場合においても、超過分は外部記憶装置で管理されるためデータロストの発生を防止して安全に管理を行うことができる。
【０１９３】
さらに、以下の２つの効果を奏する。
【０１９４】
１つめは、対話処理サーバプロセス稼動マシン（サーバアプリケーション４が稼動するサーバ装置）と状態情報管理プロセスマシン（セッション管理プロセス１が稼動するセッション管理装置）とを別け、かつ状態情報管理プロセスマシンはこれのみの性能を考慮したマシンにすれば、対話処理サーバプロセス稼動マシンの性能を劣化させずに、高速な状態情報の管理ができる。さらに、状態情報管理プロセスマシンとして、安価なメモリ等の費用対効果が上がるものを選択し、それが結果的に対話処理サーバプロセス稼動マシンと異機種（異ＯＳ）になっても、ＣＯＲＢＡにより、その連携は容易に構築することができる。
【０１９５】
２つめは、状態情報管理プロセスマシンの種類に関わらず、状態情報管理プロセスマシンにアクセスする対話処理サーバプロセスの方法は唯一つである。すなわち、状態情報管理プロセスが稼動するマシンに変更があったとしても、対話処理サーバプロセスは全く変更する必要がなくフレキシブルなセッション管理環境を提供することができる。
【０１９６】
以下、図１３に示すメモリマップを参照して本発明に係るセッション管理装置を適用可能なシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１９７】
図１３は、本発明に係るセッション管理装置を適用可能なシステムで読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１９８】
なお、特に図示しないが、記録媒体に記録されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記録され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記録される場合もある。
【０１９９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記録される場合もある。
【０２００】
本実施形態における図４〜図６，図７，図８，図９，図１０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０２０１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０２０２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【０２０３】
プログラムコードを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０２０４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２０７】
さらに、本発明を達成するためのソフトウエアによって表されるプログラムをネットワーク上のデータベースから通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２０８】
【発明の効果】
以上説明したように、本発明によれば、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行う分散オブジェクトとして実装されるセッション管理プロセスが、該プロセス内にセッション状態情報を格納するセッション管理メモリと、セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部とを備え、前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うので、分散オブジェクト環境におけるクライアント／サーバシステムにおける対話中のセッションをクライアント／サーバシステムの性能を劣化させることなしに高速かつ安全に管理することができる。
【０２０９】
また、分散オブジェクト環境で稼動するクライアント／サーバシステムのセッション管理をプラットフォームに依存することなくフレキシブルに行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態を示す分散オブジェクト環境で稼動するクライアント／サーバ間のセッション管理装置を適用可能なクライアント／サーバシステムの全体を示すブロック図である。
【図２】図１に示したクライアント／サーバシステムのセッション管理の流れを示す図である。
【図３】本発明の実施形態における第１の制御処理手順の一例を示すフローチャートである。
【図４】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図５】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図６】本発明の実施形態における第２の制御処理手順の一例を示すフローチャートである。
【図７】本発明の実施形態における第３の制御処理手順の一例を示すフローチャートである。
【図８】本発明の実施形態における第４の制御処理手順の一例を示すフローチャートである。
【図９】本発明の実施形態における第５の制御処理手順の一例を示すフローチャートである。
【図１０】本発明の実施形態における第６の制御処理手順の一例を示すフローチャートである。
【図１１】ＩＤＬ定義からスタブとスケルトンを生成する構成について示す図である。
【図１２】図１１に示したＩＤＬコンパイルによって生成されたレコード制御部内各サービススタブとレコード制御部内各サービススケルトンの使用方法を示す図である。
【図１３】本発明に係るセッション管理装置を適用可能なシステムで読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【図１４】クライアント／サーバ間の通信における両者のセッション状態を説明する図である。
【図１５】クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【図１６】ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）の環境で、クライアントとサーバの双方をＣＯＲＢＡオブジェクトとして実装したクライアント／サーバシステムを示すブロック図である。
【図１７】図１６のファイアウォール構築上の問題を踏まえた形態のクライアント／サーバシステムの一例を示すブロック図である。
【符号の説明】
１ セッション管理プロセス
２ バッファコントローラ
３ セッション管理メモリ
４ サーバアプリケーション
５ クライアントアプリケーション
６ データベース
７ プロパティファイル
２１ メモリ確保部
２２ レコード制御部
２２ａ レコード割当サービス
２２ｂ レコード読み込みサービス
２２ｃ レコード書き込みサービス
２２ｄ レコード開放サービス
２３ レコード監視部
３０ ＯＲＢ
３１ ネットワーク
６１ セッション管理テーブル
１００ サーバ装置
２００ クライアント装置
Claims (12)
- 分散オブジェクトとして実装されるセッション管理プロセスが、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行うセッション管理装置において、
前記セッション管理プロセスは、
該プロセス内にセッション状態情報を格納するセッション管理メモリと、
セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスとを備えるレコード制御部と、
セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御部からの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御部で必要となったデータベース中のセッション状態情報を、前記レコード制御部からの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視部と、を備えるものであり、
前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスに対して開放要求があったセッション状態情報をいい、
前記レコード開放サービスにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスによるレコードの割り当て、前記レコード読み込みサービス又は前記レコード書き込みサービスによる前記データベースに退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスによるレコードの割り当て、前記読み込みサービス又は前記書き込みサービスによる前記データベースに退避されているレコードの復帰を行うことを特徴とするセッション管理装置。 - 前記セッション管理プロセス起動時毎に、前記セッション状態情報を格納することができる最大レコード数及びセッション状態情報エリア長を前記セッション管理メモリとして確保することを特徴とする請求項１記載のセッション管理装置。
- 前記レコード制御部は、
セッション管理を必要とする前記サーバアプリケーションから与えられたセッションＩＤに基づいて前記セッション管理メモリ内にセッションＩＤ及びセッション状態情報の対を格納する制御を行うことを特徴とする請求項１又は２記載のセッション管理装置。 - 前記レコード制御部の各サービスのセッション管理を必要とする前記サーバアプリケーションからのインタフェースは、前記セッション管理プロセスが稼動する環境に依存しないことを特徴とする請求項１乃至３のいずれかに記載のセッション管理装置。
- 前記セッション状態情報としてセッション中に発生する全ての情報を対象として管理することにより、クライアントとサーバの対話処理を持続する制御を可能とすることを特徴とする請求項１乃至４のいずれかに記載のセッション管理装置。
- 分散オブジェクトとして実装されるセッション管理プロセスが、分散オブジェクトとして実装されたサーバアプリケーションと連携して、分散オブジェクト環境において対話処理を行うクライアントアプリケーションと前記サーバアプリケーションとの間のセッション管理を行うセッション管理方法において、
セッション状態情報を格納するセッション管理メモリを備える前記セッション管理プロセスは、
セッション管理を必要とする前記サーバアプリケーションから要求される、前記セッション管理メモリ内にセッション状態情報を格納するレコードを確保するレコード割当サービスステップと、前記セッション管理メモリの当該レコードからセッション状態情報を取得して前記サーバアプリケーションに送信するレコード読み込みサービスステップと、前記セッション状態情報を当該レコードに格納するレコード書き込みサービスステップと、管理する必要が無くなったセッション状態情報が格納されている当該レコードを開放するレコード開放サービスステップとからなるレコード制御ステップと、
セッション状態情報数過多により前記セッション管理メモリ内で管理できなくなったセッション状態情報を、前記レコード制御ステップからの要求により、最も昔にアクセスされたレコードからデータベースへ退避させ、前記レコード制御ステップで必要となったデータベース中のセッション状態情報を、前記レコード制御ステップからの要求によりデータベースから前記セッション管理メモリへ戻すことを行うレコード監視ステップと、を備えるものであり、
前記管理する必要が無くなったセッション状態情報とは、前記クライアントアプリケーションから前記サーバアプリケーションに対話終了要求が送られた場合に前記サーバアプリケーションからされる読み取り要求に対して前記レコード読み取りサービスステップが前記サーバアプリケーションに送信したセッション状態情報であって、前記サーバアプリケーションから前記レコード開放サービスステップに対して開放要求があったセッション状態情報をいい、
前記レコード開放サービスステップにより管理する必要が無くなったセッション状態情報が格納されている当該レコードが開放された場合には、前記セッション管理メモリに前記レコード割り当てサービスステップによるレコードの割り当て、前記レコード読み込みサービスステップ又は前記レコード書き込みサービスステップによる前記データベースへ退避されているレコードの復帰が行われるまで前記開放したレコードを開放した状態とし、前記レコード割り当てサービスステップによるレコードの割り当て、前記レコード読み込みサービスステップ又は前記レコード書き込みサービスステップによる前記データベースへ退避されているレコードの復帰を行う場合に、前記開放したレコードを含む前記セッション管理メモリ内の開放されているレコードを使用して前記割り当てサービスステップによるレコードの割り当て、前記読み込みサービスステップ又は前記書き込みサービスステップによる前記データベースへ退避されているレコードの復帰を行うことを特徴とするセッション管理方法。 - 前記セッション管理プロセス起動時毎に、前記セッション状態情報を格納することができる最大レコード数及びセッション状態情報エリア長を前記セッション管理メモリとして確保することを特徴とする請求項６記載のセッション管理方法。
- 前記レコード制御ステップは、
セッション管理を必要とする前記サーバアプリケーションから与えられたセッションＩＤに基づいて前記セッション管理メモリ内にセッションＩＤ及びセッション状態情報の対を格納する制御を行うことを特徴とする請求項６又は７記載のセッション管理方法。 - 前記レコード制御ステップの各サービスステップのセッション管理を必要とする前記サーバアプリケーションからのインタフェースは、前記セッション管理プロセスが稼動する環境に依存しないことを特徴とする請求項６乃至８のいずれかに記載のセッション管理方法。
- 前記セッション状態情報としてセッション中に発生する全ての情報を対象として管理することにより、クライアントとサーバの対話処理を持続する制御を可能とすることを特徴とする請求項６乃至９のいずれかに記載のセッション管理方法。
- コンピュータに請求項６〜１０のいずれかに記載されたセッション管理方法のステップを実行させるためのプログラム。
- コンピュータに請求項６〜１０のいずれかに記載されたセッション管理方法のステップを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001338090A JP3730563B2 (ja) | 2001-11-02 | 2001-11-02 | セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001338090A JP3730563B2 (ja) | 2001-11-02 | 2001-11-02 | セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003141068A JP2003141068A (ja) | 2003-05-16 |
| JP3730563B2 true JP3730563B2 (ja) | 2006-01-05 |
Family
ID=19152633
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001338090A Expired - Fee Related JP3730563B2 (ja) | 2001-11-02 | 2001-11-02 | セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3730563B2 (ja) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1901537A (zh) * | 2005-07-22 | 2007-01-24 | 国际商业机器公司 | 自适应会话压缩管理方法、压缩管理器及会话管理系统 |
| US7675854B2 (en) | 2006-02-21 | 2010-03-09 | A10 Networks, Inc. | System and method for an adaptive TCP SYN cookie with time validation |
| JP4641506B2 (ja) * | 2006-03-13 | 2011-03-02 | 富士通株式会社 | セッション管理プログラム、セッション管理方法およびセッション管理装置 |
| US8312507B2 (en) | 2006-10-17 | 2012-11-13 | A10 Networks, Inc. | System and method to apply network traffic policy to an application session |
| JP5460145B2 (ja) * | 2009-07-01 | 2014-04-02 | キヤノン株式会社 | データ処理装置、データ処理装置の制御方法、及びプログラム |
| JP5246092B2 (ja) * | 2009-07-31 | 2013-07-24 | 沖電気工業株式会社 | 転送装置及び転送プログラム |
| US9960967B2 (en) | 2009-10-21 | 2018-05-01 | A10 Networks, Inc. | Determining an application delivery server based on geo-location information |
| US9215275B2 (en) | 2010-09-30 | 2015-12-15 | A10 Networks, Inc. | System and method to balance servers based on server load status |
| US9609052B2 (en) | 2010-12-02 | 2017-03-28 | A10 Networks, Inc. | Distributing application traffic to servers based on dynamic service response time |
| US8897154B2 (en) | 2011-10-24 | 2014-11-25 | A10 Networks, Inc. | Combining stateless and stateful server load balancing |
| US9094364B2 (en) | 2011-12-23 | 2015-07-28 | A10 Networks, Inc. | Methods to manage services over a service gateway |
| US10044582B2 (en) | 2012-01-28 | 2018-08-07 | A10 Networks, Inc. | Generating secure name records |
| US8782221B2 (en) | 2012-07-05 | 2014-07-15 | A10 Networks, Inc. | Method to allocate buffer for TCP proxy session based on dynamic network conditions |
| US10021174B2 (en) | 2012-09-25 | 2018-07-10 | A10 Networks, Inc. | Distributing service sessions |
| CN108027805B (zh) | 2012-09-25 | 2021-12-21 | A10网络股份有限公司 | 数据网络中的负载分发 |
| US10002141B2 (en) | 2012-09-25 | 2018-06-19 | A10 Networks, Inc. | Distributed database in software driven networks |
| US9843484B2 (en) | 2012-09-25 | 2017-12-12 | A10 Networks, Inc. | Graceful scaling in software driven networks |
| US9338225B2 (en) | 2012-12-06 | 2016-05-10 | A10 Networks, Inc. | Forwarding policies on a virtual service network |
| US9531846B2 (en) | 2013-01-23 | 2016-12-27 | A10 Networks, Inc. | Reducing buffer usage for TCP proxy session based on delayed acknowledgement |
| US9900252B2 (en) | 2013-03-08 | 2018-02-20 | A10 Networks, Inc. | Application delivery controller and global server load balancer |
| US9992107B2 (en) | 2013-03-15 | 2018-06-05 | A10 Networks, Inc. | Processing data packets using a policy based network path |
| WO2014179753A2 (en) | 2013-05-03 | 2014-11-06 | A10 Networks, Inc. | Facilitating secure network traffic by an application delivery controller |
| US10230770B2 (en) | 2013-12-02 | 2019-03-12 | A10 Networks, Inc. | Network proxy layer for policy-based application proxies |
| US9942152B2 (en) | 2014-03-25 | 2018-04-10 | A10 Networks, Inc. | Forwarding data packets using a service-based forwarding policy |
| US9942162B2 (en) | 2014-03-31 | 2018-04-10 | A10 Networks, Inc. | Active application response delay time |
| US9906422B2 (en) | 2014-05-16 | 2018-02-27 | A10 Networks, Inc. | Distributed system to determine a server's health |
| US9992229B2 (en) | 2014-06-03 | 2018-06-05 | A10 Networks, Inc. | Programming a data network device using user defined scripts with licenses |
| US10129122B2 (en) | 2014-06-03 | 2018-11-13 | A10 Networks, Inc. | User defined objects for network devices |
| US9986061B2 (en) | 2014-06-03 | 2018-05-29 | A10 Networks, Inc. | Programming a data network device using user defined scripts |
| US10581976B2 (en) | 2015-08-12 | 2020-03-03 | A10 Networks, Inc. | Transmission control of protocol state exchange for dynamic stateful service insertion |
| US10243791B2 (en) | 2015-08-13 | 2019-03-26 | A10 Networks, Inc. | Automated adjustment of subscriber policies |
-
2001
- 2001-11-02 JP JP2001338090A patent/JP3730563B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003141068A (ja) | 2003-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3730563B2 (ja) | セッション管理装置およびセッション管理方法およびプログラムおよび記録媒体 | |
| JP3853592B2 (ja) | 分散ウェブアプリケーションサーバ | |
| EP0956687B1 (en) | Web request broker controlling multiple processes | |
| US7406525B2 (en) | Content provider and method for a computer system | |
| US5329619A (en) | Cooperative processing interface and communication broker for heterogeneous computing environments | |
| EP0737916B1 (en) | Methods, apparatus and data structures for managing objects | |
| US6212573B1 (en) | Mechanism for invoking and servicing multiplexed messages with low context switching overhead | |
| US7406523B1 (en) | Client-server communications system and method using a semi-connectionless protocol | |
| US7028091B1 (en) | Web server in-kernel interface to data transport system and cache manager | |
| US20080163243A1 (en) | Method and system for optimizing file table usage | |
| CN111787126B (zh) | 容器创建方法、服务器及存储介质 | |
| WO1995031787A1 (en) | Method and apparatus for handling requests regarding information stored in a file system | |
| JPH0776939B2 (ja) | 通信ネットワークシステム | |
| US20040098726A1 (en) | JMS integration into an application server | |
| US20030037107A1 (en) | Application distribution system, and distribution server and distribution method thereof | |
| CA2358131A1 (en) | Dynamic class loading | |
| US5968138A (en) | Method and apparatus for peripheral system management, using multiple object interfaces | |
| EP1949228B1 (en) | Asynchronous just-in-time compilation | |
| CN104717249B (zh) | 远程操作应用发布的方法、代理服务器和系统 | |
| CN101411165A (zh) | 利用代理服务器控制组装设备与外部的通信的技术 | |
| KR20050084059A (ko) | 비 멤버 장치로 컴퓨터 그리드에 액세스하는 방법 및시스템과 컴퓨터 프로그램 제품 | |
| US7209248B1 (en) | Managing the lifetime of distributed resource data using temporal scopes | |
| US20090083296A1 (en) | Metadata endpoint for a generic service | |
| KR100227795B1 (ko) | 웹상에서 응용 서버의 자원화 방법 | |
| JP3021539B2 (ja) | クライアント・サーバ方式におけるサーバ制御装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050419 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050620 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050906 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050907 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051006 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081014 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111014 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121014 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131014 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131014 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141014 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |