JP2001014242A

JP2001014242A - ウェブアプリケーションの分散セッション管理システム

Info

Publication number: JP2001014242A
Application number: JP11185979A
Authority: JP
Inventors: Shinichi Kinoshita; 信一木下; Takeshi Ko; 毅江
Original assignee: Suntory Ltd
Current assignee: Suntory Ltd
Priority date: 1999-06-30
Filing date: 1999-06-30
Publication date: 2001-01-19

Abstract

(57)【要約】【課題】ウェブアプリケーションシステムにおいて、
セッション管理及びサーバの分散管理を可能とする。【解決手段】サーバ１，２のウェブサーバ１１とアプ
リケーションプロセス１５の間に、セッション管理及び
分散管理のための情報を記録する共有メモリ１４を設け
る。更に、共有メモリに記録された情報に基づいて、セ
ッション管理及び分散管理を行う管理サーバ１２，１３
を設ける。これにより、クライアントとサーバ間のセッ
ションを取ることが可能になり、二回目以降のリクエス
トにおいて前回と同じプロセスでの処理を可能にする。
また、管理サーバは、共有メモリの情報に基づいて、メ
インサーバあるいは各サブサーバに処理を引き渡し、分
散管理を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ウェブアプリケー
ションシステムにおける、セッション管理及び分散管理
に関する。

【０００２】

【従来の技術】ウェブアプリケーションシステムでは、
クライアントがサーバへアクセスをし、処理をリクエス
トすると、サーバは、依頼された処理をアプリケーショ
ンを用いて処理し、結果のデータをクライアントに送付
する。従来のウェブアプリケーションシステムにおいて
は、ＣＧＩ（Common GatewayInterface）を用いるＨＴ
ＴＰ(Hyper Text Transfer Protocol)と呼ばれるプロト
コルを使用する。このプロトコルでは、クライアントが
リクエストしたデータをサーバが送り返した時点でセッ
ションが切れる。また、セッション管理が可能な方法と
しては、拡張された独自ＡＰＩ(Application Programmi
ng Interface)を用いる方法（例えば、Netscape Commun
ication社のウェブサーバやMicrosoft社のウェブサー
バ）が知られている。

【０００３】

【発明が解決しようとする課題】従来のＣＧＩを用いる
システムでは、同じクライアントが次のリクエストを実
行すると、サーバは、先のリクエストと異なるセッショ
ンで処理をする。すなわち、一旦、セッションが切れ、
新たなセッションにつながる。結果、複数のウェブペー
ジにまたがる処理のような複数のリクエストからなる処
理を行う場合、クライアントは先のリクエスト結果を保
持する必要がある。例えば、企業システム（ビジネスシ
ステム）で利用する場合、サーバとＰＣ（クライアン
ト）の間の会話で、セッションを管理する情報や次の処
理内容について全てクライアントがその情報を保持する
ため、処理能力に限界があり、また、所要時間が大きく
なるという問題がある。

【０００４】さらに、ウェブサーバとアプリケーション
プロセスとの情報のやりとりにおいては、常にすべての
情報をやりとりする必要があり、効率が非常に悪く、ひ
いては、応答速度の低下を招くことになる。また、拡張
された独自のＡＰＩを用いる方法では、ウェブサーバと
同じプロセス上でアプリケーションが起動するので、反
応速度は速くなるが、ウェブサーバ専用のＡＰＩを用い
なければならないため、他のアプリケーションを利用で
きず、また、アプリケーションに問題が起ると全体に影
響が広がるという問題があった。

【０００５】一方、１台のサーバで一元処理を行う場
合、複数のクライアントから同時にアクセスがあるとき
に備えて大きな能力のサーバが設けられている。また、
事故などによりサーバが使用できなくなると、システム
全体の処理が不可能となり、安全性に問題がある。そこ
で、本発明者らは鋭意研究を重ねた結果、セッション管
理と複数のサーバの分散管理が上記の問題を解決するた
めに必要との着想を得て、セッション管理と分散管理を
行う新たなモジュールを開発し、本発明を完成するに至
った。

【０００６】すなわち、本発明は、ウェブアプリケーシ
ョンシステムにおいて、クライアントのリクエストのセ
ッション管理を可能とすることを目的とするものであ
る。また、本発明は、ウェブアプリケーションシステム
において、サーバの分散管理を可能とすることを目的と
するものである。

【０００７】

【課題を解決するための手段】本発明は、上記目的を達
成するためになされたものである。本発明は、ウェブア
プリケーションシステムにおいて、サーバ上のウェブサ
ーバとアプリケーションプロセスの間に、セッション管
理のための情報を記録する共有メモリおよびセッション
管理サーバを設ける。

【０００８】本発明は、更に、セッション管理サーバ
が、分散管理サーバの機能を併せ持つことができる。本
発明のセッション管理システムにおいては、セッション
管理モジュールは、クライアントから最初のアクセスが
あると、そのユーザーに特定のＩＤを設定し、その情報
とサーバで稼働するアプリケーション情報とからなるセ
ッション情報を共有メモリ上に記録する。最初のアクセ
スによる処理が終了し、クライアントが二回目以降又は
異なるアプリケーションにまたがる次の処理のリクエス
トをした場合、共有メモリ上に記録した情報に基づい
て、同じＩＤを持つユーザからのアクセスであると認識
すると、前回と同じアプリケーションプロセスでの処理
を可能にする。クライアントのリクエストとサーバ間で
の処理についてのセッションを管理する当該セッション
管理システムは、クライアントからのリクエストをセッ
ション保持が非保持の状況により、セッション管理モジ
ュールを通じて対応する。また、共有メモリを利用して
クライアントとプロセスのセッション管理情報を記録す
ることで、情報のやりとりの効率化が図れる。また、こ
の機能を利用することで、クライアントからの様々なリ
クエストに対応することが可能となる。また、ウェブサ
ーバとアプリケーションプロセスとを切り離すことによ
り、システムの保守性を高めることが可能となる。

【０００９】本発明の他の態様では、ウェブアプリケー
ションシステムにおいて、サーバ上のウェブサーバとア
プリケーションプロセスの間に、分散管理サーバを設け
る。本発明は、更に、ウェブサーバとアプリケーション
プロセスの間に共有メモリを設け、かつ、分散管理サー
バがセッション管理サーバの機能も併せ持つことができ
る。

【００１０】本発明の分散管理システムにおいては、メ
インサーバでクライアント側からのアクセスを一元管理
し、状況に応じてその処理をサブサーバに割り振る。メ
インサーバ上での設定情報により、クライアントからの
アクセスを監視し、それぞれのサーバへ処理を分散する
ための道案内をする。各サーバ上でのアプリケーション
プロセスの種類や各サーバでの設定起動数等が共有メモ
リの上に記憶され、設定条件に応じて、サーバの分散処
理を指示する。複数のサーバをグループ化し、１台のメ
インサーバと複数のサブサーバから構成される当該分散
管理システムは、クライアントからのリクエストを設定
条件に応じて、分散管理を行うモジュール機能により可
能となる。

【００１１】この分散管理システムによれば、実行する
アプリケーションプロセスを複数のサーバに分散するこ
とができ、複数のクライアントの同時アクセスによって
起こるサーバへの負荷を軽減することができる。また、
サブサーバの１つが使用できない場合、稼動している他
のサーバが処理を代行する。これにより、天災・人災時
にも安全性を上げることができる。さらに、１台の高機
能サーバ( 例えば、大型機サーバ) でウェブアプリケー
ションを行うより、比較的低機能な複数のサーバ( 例え
ば、小型機サーバ) を分散サーバとして扱うことできる
本システムは、安全性およびコスト面で有利である。ま
た、本システムはメインサーバとサブサーバあるいは複
数のサブサーバについて異種のサーバを適用することが
でき、現有システムあるいは現有サーバの有効活用が容
易となり、新システム構築を柔軟に行うことが可能とな
る。

【００１２】

【発明の実施の形態】本発明の実施形態について図を用
いて説明する。図１は、本発明のウェブアプリケーショ
ンシステムの全体構成を示す。サーバは、１台のメイン
サーバ１と複数のサブサーバ２，２から構成される。メ
インサーバ１は、クライアント（ウェブブラウザ）３，
３からのアクセスを一元管理し、メインサーバ上での設
定情報により処理をサブサーバに割り振る。これによ
り、複数のクライアント３，３からのアクセスが集中し
た場合でも、各サブサーバ２，２に負荷を分散させるこ
とができる。

【００１３】図２は、メインサーバ１及びサブサーバ２
を構成するコンピュータの構成図である。コンピュータ
４は、中央処理装置（ＣＰＵ）５と、アプリケーション
プロセスの結果を格納するファイル装置６と、メインメ
モリ７と、データベース８を具備し、入出力装置９と接
続される。メインメモリ７上では、分散セッション管理
を行うためのＤＳＭＳＲＶ(Distributed Session Manag
er Server)プログラムが動作する。

【００１４】図３は、メインサーバ１とサブサーバ２に
おけるシステム構成を示す図である。メインサーバ１
は、クライアント（ブラウザ）３と接続されるウェブサ
ーバ１１と複数のアプリケーション１５を具備する。ウ
ェブサーバ１１とアプリケーション１５の間に、ＤＳＭ
サーバ１２とウェブサーバから起動するＣＧＩ実行モジ
ュール１３（以下、dsmcgi.exeという。）と共有メモリ
１４が設けられる。ＤＳＭサーバ１２はセッション管理
サーバかつ分散管理サーバであり、dsmcgi.exe１３はク
ライアント側とアプリケーションのインターフェイスプ
ログラムである。共有メモリ１４は、分散管理に関する
情報及びセッション管理に関する情報を記憶している。
ＤＳＭサーバ１２とdsmcgi.exe１３とでＤＳＭＳＲＶが
構成される。

【００１５】サブサーバ２は、メインサーバ１とほぼ同
様の構成となるが、本発明では、サブサーバ２にはdsmc
gi.exe１３は、存在せずにメインサーバ側に設けられ
る。図３では、１台のサブサーバ２のみを示している
が、サブサーバ２は複数台設けることができる。この場
合、メインサーバ１には、サブサーバ２を含めてクライ
アントからのリクエストがあるだけのdsmcgi.exe１３が
メインサーバ上の設定情報を越えない範囲で設けられ
る。

【００１６】図４は、図３に示したシステムにおけるＤ
ＳＭＳＲＶのモジュール構成を示す。ＤＳＭＳＲＶモジ
ュール２１は、ＤＳＭＣＧＩプロセス２２とＤＳＭサー
バプロセス２３とアプリケーションプロセス２４とから
構成される。インターフェースとして、ＤＳＭサーバ１
２とdsmcgi.exe１３と共有メモリ１４に対するＤＳＭＣ
ＧＩの中核ライブラリ２５と、アプリケーション１５に
対する特定言語通信用拡張ライブラリ２６が設けられ
る。ＤＳＭＣＧＩプロセス２２は、dsmcgi.exe１３とＤ
ＳＭＣＧＩ中核ライブラリ２５とから構成され、セッシ
ョン管理機能をもつ。ＤＳＭサーバプロセス２３はＤＳ
Ｍサーバ１２とＤＳＭＣＧＩ中核ライブラリ２５とから
構成され、分散管理機能をもつ。アプリケーションプロ
セス２４は、アプリケーション１５とＤＳＭＣＧＩ中核
ライブラリ２５と通信用拡張ライブラリ２６から構成さ
れる。なお、ここでは、通信用拡張ライブラリ２６は、
各種言語専用として中核ライブラリ２５と分離して構成
した。ここで、セッション管理においては、ＤＳＭＣＧ
Ｉ中核ライブラリ２５を通じてセッション管理用のクラ
イアントのＩＤやクライアントが接続しているアプリケ
ーション１５等の情報が共有メモリに入り保管される。

【００１７】また、分散管理においては、同じくＤＳＭ
ＣＧＩ中核ライブラリ２５を通じてメインサーバの状
況、サブサーバの環境確認、サブサーバとアプリケーシ
ョン１５との関係等の設定条件が共有メモリ１４に入り
保管される。図５は、メインサーバにおける処理を示す
フローチャート、図６は、サブサーバにおける処理を示
すフローチャートである。

【００１８】図中、実線は正常時の流れを示し、点線は
異常処理時の流れを示し、破線はメッセージ通知の流れ
を示す。また、二重線で示したブロックは、共有メモリ
で管理する情報を示す。縦に引かれた一点鎖線より左側
の部分は、セッション管理（ＤＳＭＣＧＩプロセス）の
機能を、右側のステップＳ３３の待機をはさんで上部分
は、分散管理（ＤＳＭサーバプロセス）の機能を、右側
のステップＳ３３の待機をはさんで下部分はアプリケー
ションプロセスとしての機能を表す。

【００１９】最初に、図５のメインサーバの処理を説明
する。メインサーバ１は、クライアント３からアクセス
を受け付けると、dsmcgi.exe１３が起動をする（ステッ
プＳ１１）。dsmcgi.exe１３は、共有メモリ１４に存在
する情報やＣＧＩパラメータを解析後、セッション管理
用のＩＤを作成し、文字コードの変換等を行う。今回の
アクセスがクライアント３からの最初のアクセスである
場合は、セッション管理用のＩＤは共有メモリ１４に記
録される。

【００２０】dsmcgi.exe１３は、次いで、共有メモリ１
４上の情報に基づいて、サブサーバ２への割り振りに関
する情報を確認する（ステップＳ１２）。ステップＳ１
２では、共有メモリ１４の情報に基づいてメインサーバ
かサブサーバのいずれで処理を行なうかが判定される。
メインサーバで処理を行なう場合（Ｎ）は、メインサー
バ１にて処理を行うためステップＳ１３へ進む。サブサ
ーバで処理を行なうべき場合（Ｙ）は、当該サブサーバ
２に処理を引き渡す（ステップＳ１９）。

【００２１】ステップＳ１２では、また、今回のアクセ
スが、２回目以降のアクセスでありセッションが保持さ
れている場合、共有メモリ１４には、当該クライアント
３のＩＤと関連するセッション管理情報と分散管理情報
が記録されているので、前回のアクセスで稼働したサー
バがメインサーバ１であるかサブサーバ２であるかが判
定される。それがサブサーバ２であれば（Ｙ）、サブサ
ーバ２に処理を引き渡し（ステップＳ１９）、メインサ
ーバ１であれば（Ｎ）、メインサーバ１にて処理を継続
するためステップＳ１３へ進む。

【００２２】ステップＳ１２でメインサーバ１にて処理
を行うこととなった場合（Ｎ）、共有メモリ１４上の情
報に基づいて、自身のアプリケーションプロセス２４が
セッションを保持しているか否かを確認する（ステップ
Ｓ１３）。ステップＳ１３では、今回のアクセスが２回
目以降のアクセスで、セッションが保持されていれば
（Ｙ）ステップＳ１５へ進む。今回のアクセスが最初の
アクセスであるか、又は、２回目以降のアクセスであっ
てもセッションが保持されていない場合（Ｎ）は、ステ
ップＳ１４へ進む。

【００２３】ステップＳ１４では、共有メモリ１４上の
情報に基づいて、アプリケーションプロセス２４の稼働
状況を確認する。処理の前に必要なアプリケーションプ
ロセス２４が稼働していなければ（Ｎ）、ＤＳＭサーバ
プロセス２３にアプリケーションプロセス２４を起動さ
せる指示を出す。ＤＳＭサーバプロセス２３は、アプリ
ケーションプロセス２４の起動と終了を管理する。dsmc
gi.exe１３からアプリケーションプロセス２４の起動の
指示を受けると、アプリケーションプロセス２４を起動
させ（ステップＳ３１、３２）、その旨を共有メモリ１
４に記録し、次のプロセス実行のメッセージが出される
まで待機をする（ステップＳ３３）。

【００２４】dsmcgi.exe１３では、起動完了のメッセー
ジを受け取ると、ステップＳ１４でアプリケーションプ
ロセス２４が稼働状況にあると判定して、ステップＳ１
５へ進む。ステップＳ１５で、ＤＳＭＣＧＩプロセス２
２の実行を指示するメッセージを通知し、ステップＳ１
６で、アプリケーションプロセス２４の実行完了まで待
機する。

【００２５】アプリケーションプロセス２４は、待機中
（ステップＳ３３）にプロセス実行開始のメッセージを
受け取ると、プロセスの実行を開始する（ステップＳ３
４）。プロセス実行が終了すると、処理の結果をファイ
ル装置６の結果ファイルに格納し、共有メモリ１４に処
理の状況に関する情報を記録し、dsmcgi.exe１３に処理
完了のメッセージを通知し、待機する（ステップＳ３
５）。

【００２６】dsmcgi.exe１３は、実行完了のメッセージ
を受け取ると、ファイル装置６から結果のファイルを得
て、ウェブサーバ１１にクライアント３への送付依頼を
行う（ステップＳ１７）。その後、アプリケーションプ
ロセス２４に、結果ファイルの獲得が完了した旨のメッ
セージを送り、処理を終了する（ステップＳ１８）。ア
プリケーションプロセス２４は、ステップＳ３５の待機
中に、結果ファイル獲得完了のメッセージを受け取る
と、自動終了を行うか否かを判定する（ステップＳ３
６）。自動終了の判定のパラメータとしては、例えば、
アプリケーションプロセスのメモリー常駐数や前回の接
続からの経過時間、クライアント３からの総アクセス回
数などがある。これらが所定値を超えた場合（ステップ
Ｓ３６のＹ）には、自動的にアプリケーションプロセス
２４を終了し、共有メモリ１４に記憶してあるセッショ
ン情報などの管理情報をクリアする（ステップＳ３
８）。また上記のパラメータを満たす場合でも、セッシ
ョンを保持した状態のままで同一ユーザーからの処理が
継続される場合は、自動終了のステップは、次のセッシ
ョンを保持しない処理かまたは、別ユーザからのリクエ
ストがくるまで実行されない。

【００２７】自動終了の要件を満たさない場合（ステッ
プＳ３６のＮ）は、（Wait/Ready)のフラグをセットし
た（ステップＳ３７）後、ステップＳ３３へ戻る。ここ
では、アプリケーションプロセス２４の起動を継続した
まま、次の処理実行のメッセージが通知されるまで待機
をする。この自動終了のパラメータとしては、例えば、
待機開始からの経過時間がある。自動終了にこのパラメ
ータを使用した場合、処理の結果を送付してから所定時
間経過してもクライアント３から次のアクセスが無い場
合に、サーバ側で自動終了を行うこととなる。自動終了
の場合は、ステップＳ３８へ進み、アプリケーションプ
ロセスの終了、管理情報のクリアを行う。

【００２８】次に、サブサーバ２の処理について説明す
る。図５のメインサーバ１のステップＳ１２でサブサー
バ２の環境確認を行う。ここで、今回アクセスしてきた
クライアント３とのセッションが継続しているサブサー
バ２があれば、当該サブサーバ２に処理が渡され、セッ
ション継続の処理がされる。

【００２９】図６において、処理が引き渡されたサブサ
ーバ２では、ＤＳＭサーバプロセス２３にて管理を行う
（ステップＳ５１）。ＤＳＭサーバプロセス２３は、共
有メモリ１４に所定の書き込みを行い、次いで、共有メ
モリ１４上の情報に基づいて、アプリケーションプロセ
ス２４がセッションを保持しているか否かを確認する
（ステップＳ５２）。

【００３０】ステップＳ５２で、今回のアクセスが２回
目以降のアクセスで、セッションが保持されていれば
（Ｙ）ステップＳ５４へ進む。今回のアクセスが最初の
アクセスであるか、又は、２回目以降のアクセスであっ
ても保持されていない場合（Ｎ）は、ステップＳ５３へ
進む。ステップＳ５３では、共有メモリ１４上の情報に
基づいて、アプリケーションプロセス２４の稼働状況を
確認する。アプリケーションプロセス２４が稼働してい
なければ（Ｎ）、アプリケーションプロセス２４の起動
を行う（ステップＳ７１）。アプリケーションプロセス
２４は、起動を完了すると、その旨を共有メモリ１４に
記録して、起動完了のメッセージをＤＳＭサーバプロセ
ス２３に送り、次のプロセス実行のメッセージが出され
るまで待機をする（ステップＳ７２）。

【００３１】ＤＳＭサーバプロセス２３では、起動完了
のメッセージを受け取ると、ステップＳ５３でアプリケ
ーションプロセス２４が稼働状況にあると判定して、ス
テップＳ５４へ進む。ステップＳ５４で、ＤＳＭＣＧＩ
プロセス２２の実行開始を指示するメッセージを通知
し、ステップＳ５５で、アプリケーションプロセス２４
の実行完了まで待機する。

【００３２】アプリケーションプロセス２４は、待機中
（ステップＳ７２）にプロセス実行開始のメッセージを
受け取ると、アプリケーションプロセス２４の実行を開
始する（ステップＳ７３）。プロセス実行が終了する
と、処理の結果をファイル装置６の結果ファイルに格納
し、共有メモリ１４に処理の状況に関する情報を記録
し、ＤＳＭサーバプロセス２３に実行完了のメッセージ
を通知し、待機する（ステップＳ７４）。

【００３３】ＤＳＭサーバプロセス２３は、ステップＳ
５５の待機中にプロセス実行完了のメッセージを受け取
ると、ステップＳ５６で、ファイル装置６から結果ファ
イルを獲得し、メインサーバ１に結果のデータを戻し、
ステップＳ５１へ戻る。メインサーバ１（図５）では、
dsmcgi.exe１３のステップＳ１７で、ウェブサーバ１１
に、サブサーバ２から戻された結果のデータをクライア
ント３へ送付することの依頼を行う。

【００３４】サブサーバ２（図６）のステップＳ７４の
待機以降の処理、つまり、自動終了の判定（ステップＳ
７５）、アプリケーションプロセス２４終了の処理（ス
テップＳ７７）、フラグのセット（ステップＳ７６）、
次のプロセス実行への待機（ステップＳ７２）は、図５
のメインサーバ１での処理と同様であるので、重複する
説明は省略する。

【００３５】次に、図５、図６のフローチャートにおい
て、異常が発生したときの処理を説明する。図５，図６
では、異常処理時の流れを点線で示している。メインサ
ーバ１（図５）では、ステップＳ１６の待機中に所定時
間が経過すると、つまり、所定時間が経過してもアプリ
ケーションプロセスの処理が終了しないときは、ＤＳＭ
ＣＧＩプロセス２３にアプリケーションプロセス２４の
強制終了を指示し、ステップＳ１８およびステップＳ３
９で処理を終了する。ＤＳＭＣＧＩサーバプロセス２３
ではアプリケーションプロセス２４の処理を終了する
（ステップＳ３１）。サブサーバ２（図６）では、ステ
ップＳ５５の待機中に所定時間が経過すると、アプリケ
ーションプロセス２４を終了させ（ステップＳ５７）、
ステップＳ５１へ戻る。

【００３６】以上説明したシステムによれば、アプリケ
ーションプロセス２４がＤＳＭＣＧＩサーバプロセス２
３から独立してお互いに干渉しないため、システム全体
の信頼性が高くなる。また、アプリケーション１５を共
有メモリ１４に常駐でき、小さいサイズの実行モジュー
ル（dsmcgi.exe）だけからウェブサーバ１１のリクエス
トを受けることにより、レスポンスも早くなる。セッシ
ョン管理情報を共有メモリ１４に置いたことにより、高
いアクセスパフォーマンスを実現できる。

【００３７】また、複数のサーバをグループ化して分散
対応としたことにより、負荷を分散でき、複数のクライ
アントの同時アクセスによって起こるサーバへの負荷を
軽減することができる。サーバの１つが使用不可能な場
合でも、他のサーバが稼働していれば、処理を代行する
ので、天災・人災時における安全性を上げることができ
る。１台の高機能サーバを購入し、それ１台でウェブ管
理を行うより、比較的低機能な複数の小型機サーバを分
散サーバとして扱うことができ、システムのコスト削減
にも結びつくということもある。また、本システムはメ
インサーバとサブサーバあるいは複数のサブサーバにつ
いて異種のサーバを適用することができ、現有システム
あるいは現有サーバの有効活用が容易となり、新システ
ム構築を柔軟に行うことが可能となる。

【００３８】

【発明の効果】本発明によれば、ウェブアプリケーショ
ンシステムにおいて、セッション管理を可能とすること
ができる。また、ウェブアプリケーションシステムにお
いて、サーバの分散管理を可能とすることができる。

【図面の簡単な説明】

【図１】ウェブアプリケーションシステムの全体構成を
示す図。

【図２】サーバを構成するコンピュータの構成図。

【図３】サーバのシステム構成を示す図。

【図４】図３のシステムにおけるＤＳＭＳＲＶのモジュ
ール構成を示す図。

【図５】図３のメインサーバにおける処理を示すフロー
チャート。

【図６】図３のサブサーバにおける処理を示すフローチ
ャート。

【符号の説明】

１…メインサーバ２…サブサーバ３…クライアント４…コンピュータ５…ＣＰＵ６…ファイル装置７…メインメモリ８…データベース９…入出力装置１１…ウェブサーバ１２…ＤＳＭサーバ１３…dsmcgi.exe １４…共有メモリ１５…アプリケーション２１…ＤＳＭＳＲＶモジュール２２…ＤＳＭＣＧＩプロセス２３…ＤＳＭサーバプロセス２４…アプリケーションプロセス２５…ＤＳＭＣＧＩ中核ライブラリ２６…通信用拡張ライブラリ

Claims

【特許請求の範囲】

【請求項１】ウェブアプリケーションシステムにおい
て、ウェブサーバとアプリケーションプロセスの間に、
セッション管理のための情報を記録する共有メモリおよ
びセッション管理サーバを設けたことを特徴とするウェ
ブアプリケーションシステム。
【請求項２】前記セッション管理サーバが、更に、分
散管理機能も併せ持った請求項１に記載のウェブアプリ
ケーションシステム。
【請求項３】ウェブアプリケーションシステムにおい
て、ウェブサーバとアプリケーションプロセスの間に、
分散管理サーバを設けたことを特徴とするウェブアプリ
ケーションシステム。
【請求項４】前記分散管理サーバが、更に、セッショ
ン管理機能も併せ持った請求項３に記載のウェブアプリ
ケーションシステム。
【請求項５】ウェブサーバと、アプリケーションプロセスと、前記ウェブサーバおよび前記アプリケーションプロセス
の間に設けられ、セッション管理のための情報を記録す
る共有メモリおよびセッション管理サーバとを具備する
ことを特徴とするウェブアプリケーションのセッション
管理装置。
【請求項６】前記セッション管理サーバが、更に、分
散管理機能も併せ持った請求項５に記載のウェブアプリ
ケーションのセッション管理装置。
【請求項７】ウェブサーバと、アプリケーションプロセスと、前記ウェブサーバおよび前記アプリケーションプロセス
の間に設けられた分散管理サーバとを具備することを特
徴とするウェブアプリケーションの分散管理装置。
【請求項８】前記分散管理サーバが、更に、セッショ
ン管理機能も併せ持った請求項７に記載のウェブアプリ
ケーションの分散管理装置。
【請求項９】ウェブアプリケーションシステムにおい
て、ウェブサーバとアプリケーションプロセスの間に設
けられる管理サーバであって、セッション管理および分
散管理の少なくとも一方を可能とすることを特徴とする
管理サーバ。
【請求項１０】ウェブアプリケーションシステムにお
いて、ウェブサーバとアプリケーションプロセスの間に
設けられる共有メモリであって、セッション管理のため
の情報を記録することを特徴とする共有メモリ。
【請求項１１】ウェブアプリケーションシステムにお
いて、クライアントからのリクエストを設定条件に応じ
て、セッション管理および分散管理の少なくとも一方を
行うモジュール機能プログラムおよびそれを記録した、
コンピュータ読み取り可能な記録媒体。