特許第6943089号(P6943089)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電気株式会社の特許一覧

特許6943089情報処理システム、情報処理方法、及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6943089
(24)【登録日】2021年9月13日
(45)【発行日】2021年9月29日
(54)【発明の名称】情報処理システム、情報処理方法、及びプログラム
(51)【国際特許分類】
   G06F 8/656 20180101AFI20210916BHJP
   G06F 8/61 20180101ALI20210916BHJP
【FI】
   G06F8/656
   G06F8/61
【請求項の数】10
【全頁数】22
(21)【出願番号】特願2017-169660(P2017-169660)
(22)【出願日】2017年9月4日
(65)【公開番号】特開2019-46255(P2019-46255A)
(43)【公開日】2019年3月22日
【審査請求日】2020年8月17日
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】山口 真弘
【審査官】 多賀 実
(56)【参考文献】
【文献】 特開2005−267312(JP,A)
【文献】 特開2003−122589(JP,A)
【文献】 国際公開第2010/116676(WO,A1)
【文献】 特開2017−016517(JP,A)
【文献】 特開2014−002528(JP,A)
【文献】 特開2005−044011(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 8/00−8/77
G06F 9/44−9/54
G06F 15/00
(57)【特許請求の範囲】
【請求項1】
アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、配備解除要求を出力するセッション情報監視手段と、
前記配備解除要求を受け取った場合に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除するモジュール配備解除手段と、を備える、
情報処理システム。
【請求項2】
前記モジュール配備解除手段は、どのモジュールからも呼び出されなくなったモジュールの配備解除を再帰的に行う、請求項1に記載の情報処理システム。
【請求項3】
前記セッション情報監視手段は、前記第1のモジュールのセッション数が0になった際に、前記第1のモジュールのモジュール名及びモジュールバージョンを含む配備解除要求を前記モジュール配備解除手段へ出力し、
前記モジュール配備解除手段は、前記配備解除要求を受け取った場合に、前記配備解除要求に含まれる前記モジュール名且つ前記モジュールバージョンの前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュール名且つモジュールバージョンのモジュールを配備解除する、請求項1又は2に記載の情報処理システム。
【請求項4】
前記セッション情報監視手段は、セッション数が0になった前記第1のモジュールのモジュールバージョンが最新のモジュールバージョンである場合には、前記配備解除要求を出力しない、請求項3に記載の情報処理システム。
【請求項5】
前記モジュール配備解除手段は、前記どのモジュールからも呼び出されなくなったモジュールのモジュールバージョンが最新のモジュールバージョンである場合には、当該モジュールを配備解除しない、請求項3又は4に記載の情報処理システム。
【請求項6】
セッション情報管理手段をさらに備え、
前記セッション情報管理手段は、削除を要求されたセッション、又は最終アクセス時刻から所定時間経過したセッションのセッションIDを前記セッション情報監視手段に通知する、
請求項3から5のいずれか一項に記載の情報処理システム。
【請求項7】
セッションテーブルを格納するセッション振り分け先情報格納手段をさらに備え、
前記セッションテーブルには、モジュール名に、当該モジュールに対するセッションのセッションIDと振り分け先のロードモジュールのモジュールバージョンとが関連づけられており、
前記セッション情報監視手段は、通知された前記セッションID及び前記セッションテーブルに基づいて、前記第1のモジュールのセッション数が0になったか否かを判断する、
請求項6に記載の情報処理システム。
【請求項8】
前記情報処理システムは、ネットワークを介して管理端末に接続され、
前記管理端末から前記第1のモジュールの配備解除要求を受信し、
前記モジュール配備解除手段は、前記管理端末から受信した配備解除要求により前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する機能も備える、
請求項1から7のいずれか一項に記載の情報処理システム。
【請求項9】
アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、
リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する、
情報処理方法。
【請求項10】
プロセッサに、
アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、
リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する、
処理を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システム、情報処理方法、及びプログラムに関し、特に、アプリケーションの更新を行う情報処理システム、情報処理方法、及びプログラムに関する。
【背景技術】
【0002】
アプリケーションサーバで動作するアプリケーションは、24時間365日の連続稼働が求められることがある。一方で、不具合の修正や機能拡張のためのアプリケーションの更新では、一般に、アプリケーションを停止する必要がある。
【0003】
更新時にアプリケーションの動作を継続させる方法の一例として、変更前のアプリケーションと変更後のアプリケーションを同時に稼働させ、リクエストの振り分け先を変更前から変更後のアプリケーションに切り替える方法がある。特許文献1では、複数のリクエストにより構成されるセッションに対して処理が行われる場合に、セッション内での処理の一貫性を保つため、セッション毎にアプリケーションを切り替える方法が開示されている。すなわち、変更前から処理していたセッションのリクエストは、変更前のアプリケーションに振り分けられ、変更後の新規のセッションのリクエストは、変更後のアプリケーションに振り分けられる。この方法では、セッション数を監視することで、セッション数が0になった際にアプリケーションを自動で配備解除することができる。
【0004】
一方、アプリケーションは複数のモジュールから構成される場合がある。例えば、Java(登録商標)EE(Enterprise Edition)アプリケーションサーバに配備されるアプリケーションは、複数のモジュールから構成することができる。具体的には、Java EEアプリケーションサーバに配備されるアプリケーションは、クライアント端末のWebブラウザからのリクエストを受け付けるWebモジュールとバックエンドの処理を実行するEJB(Enterprise JavaBeans)モジュールやさらにそこから呼び出されるEJBモジュールから構成することができる。このように複数のモジュールから構成されるアプリケーションでは、モジュール呼び出し用のインタフェースに変更がなく、モジュール実行内容にのみ変更があった場合、変更のあったモジュールを呼び出すモジュールを更新することなく、変更のあったモジュールのみを更新することができる。
【0005】
特許文献2には、アプリケーションが複数のモジュールから構成されている場合について、モジュールを更新する際に、更新されるモジュールを呼び出すモジュールも新たにロードし直し、更新後のモジュールを呼び出すようにするという処理を、呼び出し側のモジュールに対して再帰的に実行する方法が開示されている。この方法により、特許文献2では、複数のモジュールから構成されるアプリケーションの一部のモジュールを更新した場合でも、リクエストを直接受け付けるモジュールに対してセッションIDを利用した振り分けを行うだけで、更新前に開始されたセッションのリクエストは更新前のモジュールで処理され、更新後の新規のリクエストは更新後のモジュールで処理されるようになる。したがって、更新前のセッションに対する処理で不整合を発生させることなく、新規のリクエストに対してモジュールの更新を反映することができる。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特許第4532946号公報
【特許文献2】特開2017−16517号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかし、特許文献2では、配備解除について考慮されておらず、古いモジュールは使用されなくなってもそのまま残るという問題があった。また、特許文献1では、アプリケーションが複数のモジュールから構成される場合については考慮されておらず、一部のモジュールのみを解除することができないという問題があった。
【0008】
本発明は、このような問題点を解決するためになされたものであり、不要になったモジュールを自動で配備解除することができる情報処理システム、情報処理方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
本発明の第1の態様にかかる情報処理システムは、アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、配備解除要求を出力するセッション情報監視手段と、前記配備解除要求を受け取った場合に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除するモジュール配備解除手段と、を備えるものである。
【0010】
本発明の第2の態様にかかる情報処理方法は、アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除するものである。
【0011】
本発明の第3の態様にかかるプログラムは、プロセッサに、アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視し、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、前記第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する、処理を実行させるものである。
【発明の効果】
【0012】
本発明により、不要になったモジュールを自動で配備解除することができる情報処理システム、情報処理方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【0013】
図1】実施の形態1にかかるアプリケーションサーバの構成例を示すブロック図である。
図2】実施の形態1にかかるアプリケーションサーバの処理例を示すフローチャートである。
図3】実施の形態2にかかるアプリケーションの実行環境の構成例を示すブロック図である。
図4】実施の形態2にかかる実行ファイルテーブルの例を示す図である。
図5】実施の形態2にかかるモジュール実行部にロードされるロードモジュールの構成を示す図である。
図6】実施の形態2にかかるバージョンテーブルの例を示す図である。
図7】実施の形態2にかかるロードバージョンテーブルの例を示す図である。
図8】実施の形態2にかかる呼び出し関係テーブルの例を示す図である。
図9】実施の形態2にかかるセッションテーブルの例を示す図である。
図10】実施の形態2にかかるセッション情報テーブルの例を示す図である。
図11】実施の形態2にかかるセッションオブジェクトの例を示す図である。
図12】実施の形態2にかかるセッションの取得処理を示すフローチャートである。
図13】実施の形態2にかかるセッションの更新処理を示すフローチャートである。
図14】実施の形態2にかかるロードモジュールによる削除要求によって行われるセッションの削除処理を示すフローチャートである。
図15】実施の形態2にかかるタイムアウトによって行われるセッションの削除処理を示すフローチャートである。
図16】実施の形態2にかかるセッション情報監視部がセッション削除の通知を受けた際の処理を示すフローチャートである。
図17】実施の形態2にかかるモジュール配備解除部がモジュールの配備解除要求を受けた際の処理を示すフローチャートである。
図18】実施の形態2にかかるモジュール配備解除部がモジュールの配備解除要求を受けた際の処理を示すフローチャートである。
図19】実施の形態2にかかるモジュール間の呼び出し関係の例を示す図である。
図20】実施の形態2にかかるロードモジュール間の呼び出し関係の例を示す図である。
図21】実施の形態2にかかる行が削除されたロードバージョンテーブルの例を示す図である。
図22】実施の形態2にかかる行が削除された呼び出し関係テーブルの例を示す図である。
図23】実施の形態2にかかる図20の状態からA’(3,3)が配備解除されたロードモジュール間の呼び出し関係の例を示す図である。
図24】実施の形態2にかかる行が削除された実行ファイルテーブルの例を示す図である。
図25】実施の形態2にかかる行がさらに削除されたロードバージョンテーブルの例を示す図である。
図26】実施の形態2にかかる行がさらに削除された呼び出し関係テーブルの例を示す図である。
図27】実施の形態2にかかる図23の状態からA(2,1)、B(2,1)、C’(2,2)が配備解除されたロードモジュール間の呼び出し関係の例を示す図である。
図28】実施の形態2にかかるアプリケーションの実行環境の他の構成例を示すブロック図である。
図29】実施の形態3にかかるアプリケーションの実行環境の構成例を示すブロック図である。
【発明を実施するための形態】
【0014】
以下では、本発明の実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【0015】
実施の形態1
まず、図1のブロック図を用いて、本発明の実施の形態1にかかるアプリケーションサーバ100の構成例について説明する。アプリケーションサーバ100は、セッション情報監視部110と、モジュール配備解除部120と、を備えている。なお、アプリケーションサーバ100は、本発明の情報処理システムの一実施形態である。
【0016】
セッション情報監視部110は、アプリケーションを構成する複数のプログラムモジュール(以下、単にモジュールと記載する)の各々についてのセッション数を監視する。また、セッション情報監視部110は、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、モジュール配備解除部120へ配備解除要求を出力する。なお、第1のモジュールは、図示しないクライアント端末からのリクエストを直接受け付けるモジュールである。
【0017】
モジュール配備解除部120は、セッション情報監視部110から配備解除要求を受け取る。また、モジュール配備解除部120は、配備解除要求を受け取った場合に、第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する。
【0018】
なお、モジュール配備解除部120は、どのモジュールからも呼び出されなくなったモジュールの配備解除を再帰的に行うようにしてもよい。なお、モジュールの配備解除を再帰的に行うとは、例えば、第1のモジュールのセッション数が0になった際に、それによってどのモジュールからも呼び出されなくなった第2のモジュールを配備解除し、第2のモジュールを配備解除することによりどのモジュールからも呼び出されなくなった第3のモジュールを配備解除するような処理のことである。これにより、不要になったすべてのモジュールを自動で配備解除することができる。
【0019】
なお、最新バージョンであるモジュールは、配備解除の対象外としてもよい。すなわち、セッション情報監視部110は、セッション数が0になった第1のモジュールのモジュールバージョンが最新のモジュールバージョンである場合には、配備解除要求を出力しないようにしてもよい。また、モジュール配備解除部120は、どのモジュールからも呼び出されなくなったモジュールのモジュールバージョンが最新のモジュールバージョンである場合には、当該モジュールを配備解除しないようにしてもよい。これにより、最新のモジュールバージョンの第1のモジュールは、セッション数が0になった後も新規のリクエストを受け付けることができる。また、配備したばかりのモジュールが配備解除対象となることを防ぐことができる。
【0020】
続いて、図2のフローチャートを用いて、本実施の形態1にかかるアプリケーションサーバ100の処理例について説明する。
【0021】
まず、アプリケーションサーバ100は、セッション情報監視部110により、アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視する(ステップS101)。
【0022】
次に、アプリケーションサーバ100は、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、モジュール配備解除部120により、当該第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する(ステップS102)。
【0023】
以上のように、本発明の実施の形態1にかかるアプリケーションサーバ100(情報処理システム)は、セッション情報監視部110と、モジュール配備解除部120と、を備える構成としている。また、アプリケーションサーバ100は、セッション情報監視部110により、アプリケーションを構成する複数のモジュールの各々についてのセッション数を監視する構成としている。さらに、アプリケーションサーバ100は、リクエストを直接受け付ける第1のモジュールのセッション数が0になった際に、モジュール配備解除部120により、当該第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する構成としている。これにより、本実施の形態1にかかるアプリケーションサーバ100では、不要になったモジュールを自動で配備解除することができる。
【0024】
実施の形態2
続いて、本発明の実施の形態2について説明する。図3は、本発明の実施の形態2にかかるアプリケーションの実行環境の構成例を示すブロック図である。図3を参照すると、実行環境は、アプリケーションサーバ100Aと、管理端末200と、クライアント端末300と、を含む。管理端末200及びクライアント端末300は、ネットワーク10を介してアプリケーションサーバ100Aに接続される。
【0025】
管理端末200は、アプリケーションサーバ100Aに対して、アプリケーションの配備等の運用操作を実行する。
【0026】
クライアント端末300は、アプリケーションサーバ100Aに、アプリケーションの処理に係るリクエストを送信する。
【0027】
アプリケーションサーバ100Aは、クライアント端末300からリクエストを受信し、アプリケーションの処理を実行する。なお、アプリケーションサーバ100Aは、本発明の情報処理システムの一実施形態である。
【0028】
アプリケーションサーバ100Aは、セッション情報監視部110Aと、モジュール配備解除部120Aと、配備処理部130と、モジュール生成部140と、モジュール実行部150と、リクエスト振り分け部160と、セッション情報管理部170と、モジュール格納部181と、呼び出し関係格納部182と、バージョン情報格納部183と、セッション振り分け先情報格納部184と、を備えている。
【0029】
配備処理部130は、管理端末200からの運用操作によって、アプリケーションを構成する複数のモジュールの各々をアプリケーションサーバ100Aに配備する。具体的には、配備処理部130は、モジュール格納部181の実行ファイルテーブル1に、管理端末200から受信したモジュールに関する情報の登録を行う。また、配備処理部130は、モジュール格納部181に、管理端末200から受信した実行ファイルの実体を保存する。
【0030】
モジュール格納部181は、配備処理部130により配備されたモジュールを格納する。具体的には、モジュール格納部181は、実行ファイルテーブル1、及び、実行ファイルの実体を格納する。実行ファイルテーブル1は、アプリケーションを構成する複数のモジュールの各々の実行ファイルを示す。実行ファイルテーブル1の例を図4に示す。実行ファイルテーブル1では、複数のモジュールの各々のモジュール名に、当該モジュールの実行ファイルのバージョン(ファイルバージョン)、及び、ファイル名が関連づけられている。
【0031】
モジュール生成部140は、モジュール格納部181に格納されているモジュールをロードモジュール400としてモジュール実行部150にロードする。具体的には、モジュール生成部140は、実行ファイルを用いて処理実行部401を生成し、生成した呼び出し部402とともに、ロードモジュール400に設定する。また、モジュール生成部140は、生成したロードモジュール400を、モジュール実行部150にロードする。また、モジュール生成部140は、バージョン情報格納部183のバージョンテーブル2及びロードバージョンテーブル3への登録を行う。さらに、モジュール生成部140は、呼び出し関係格納部182の呼び出し関係テーブル4への登録を行う。
【0032】
図5は、本実施の形態2にかかるモジュール実行部150にロードされるロードモジュール400の構成を示す図である。ロードモジュール400は、処理実行部401、及び、呼び出し部402を含む。
【0033】
処理実行部401は、モジュールの実行ファイルに従って、モジュールに係る処理を実行する。呼び出し部402は、モジュールが依存する他のモジュールのロードモジュール400の処理を呼び出す。モジュールが、複数の他のモジュールに依存する場合、それぞれの他のモジュールに対して、呼び出し部402が存在する。
【0034】
モジュール実行部150は、モジュール生成部140によりロードされたロードモジュール400を実行する。
【0035】
バージョン情報格納部183は、バージョンテーブル2、及び、ロードバージョンテーブル3を格納する。バージョンテーブル2は、各モジュールの最新のロードモジュール400を示す。ロードバージョンテーブル3は、モジュール実行部150にロードされた各ロードモジュール400を示す。
【0036】
バージョンテーブル2の例を図6に示す。バージョンテーブル2では、複数のモジュールの各々のモジュール名に、当該モジュールの最新のロードモジュール400のバージョン(モジュールバージョン)が関連づけられている。
【0037】
ロードバージョンテーブル3の例を図7に示す。ロードバージョンテーブル3では、複数のモジュールの各々のモジュール名に、当該モジュールのロードモジュール400のモジュールバージョン、及び、実行ファイルのファイルバージョンが関連づけられている。
【0038】
呼び出し関係格納部182は、呼び出し関係テーブル4を格納する。呼び出し関係テーブル4は、モジュール間の呼び出し関係を示す。呼び出し関係テーブル4の例を図8に示す。呼び出し関係テーブル4では、呼び出し先モジュールのモジュール名とモジュールバージョンの組に、呼び出し元モジュールのモジュール名とモジュールバージョンの組が関連づけられている。
【0039】
セッション振り分け先情報格納部184は、セッションテーブル5を格納する。セッションテーブル5は、各セッションの振り分け先のロードモジュール400を示す。セッションテーブル5の例を図9に示す。セッションテーブル5では、モジュールのモジュール名に、当該モジュールに対するセッションのセッションID(Identifier)と振り分け先のロードモジュール400のモジュールバージョンとが関連づけられている。
【0040】
リクエスト振り分け部160は、セッションテーブル5をもとに、クライアント端末300から受信したリクエストを、適切なロードモジュール400に振り分ける。また、リクエスト振り分け部160は、セッションテーブル5に、セッションID、モジュール名、及びモジュールバージョンを登録する。
【0041】
セッション情報管理部170は、セッションID、セッションオブジェクト、及びセッションへの最終アクセス時刻を記録するセッション情報テーブル6を有する。セッション情報テーブル6の例を図10に示す。なお、セッションオブジェクトは、例えば図11に示すようなキーと値の組から構成される構造体であるが、それに限定されない。
【0042】
セッション情報監視部110A、モジュール配備解除部120A、及びセッション情報管理部170の処理については、後にフローチャートを用いて具体的に説明する。
【0043】
なお、アプリケーションサーバ100Aは、プログラムに基づく制御によって動作するコンピュータであってもよい。すなわち、アプリケーションサーバ100Aは、CPU(Central Processing Unit)等のプロセッサと、各機能部の処理に関するプログラムを記憶した記憶媒体と、を含み、当該プログラムをプロセッサに実行させるものであってもよい。また、アプリケーションサーバ100Aの各構成要素は、有線、または、無線により接続された、異なるコンピュータに分散して配置されていてもよい。また、アプリケーションサーバ100Aの各構成要素は、独立した論理回路でもよい。
【0044】
続いて、本実施の形態2の動作について説明する。
【0045】
<セッション情報へのアクセス処理>
はじめに、セッション情報へのアクセス処理について説明する。ロードモジュール400の処理実行部401で実行される処理により、セッションIDに紐付いたセッションを取得・更新・削除することができる。
【0046】
図12は、本実施の形態2にかかるセッションの取得処理を示すフローチャートである。
【0047】
ロードモジュール400は、リクエストに含まれるセッションIDに対応するセッションオブジェクトをセッション情報管理部170に要求する。すなわち、セッション情報管理部170は、リクエストに含まれるセッションIDに対応するセッションオブジェクトをロードモジュール400から要求される(ステップS201)。
【0048】
次に、セッション情報管理部170は、セッション情報テーブル6に要求されたセッションIDの行があるか否かを判断する(ステップS202)。
【0049】
要求されたセッションIDの行がある場合(ステップS202にてYES)、セッション情報管理部170は、要求されたセッションIDに対応するセッションオブジェクトをセッション情報テーブル6から取得し、且つ、セッション情報テーブル6における要求されたセッションIDの行の最終アクセス時刻を現在の時刻に更新する(ステップS203)。
【0050】
他方、要求されたセッションIDの行がない場合(ステップS202にてNO)、セッション情報管理部170は、セッションオブジェクトを新規に生成し、セッションID、セッションオブジェクト、及び現在時刻の組をセッション情報テーブル6に追加する(ステップS204)。
【0051】
ステップS203又はステップS204の後に、セッション情報管理部170は、取得された又は新規に生成されたセッションオブジェクトをロードモジュール400に返す(ステップS205)。
【0052】
図13は、本実施の形態2にかかるセッションの更新処理を示すフローチャートである。
【0053】
ロードモジュール400は、セッション取得処理により、セッションIDに対応するセッションオブジェクトを取得する(ステップS301)。
【0054】
次に、ロードモジュール400は、取得したセッションオブジェクトの内容を更新する(ステップS302)。
【0055】
次に、ロードモジュール400は、セッションIDと更新されたセッションオブジェクトをセッション情報管理部170へ送り更新を要求する(ステップS303)。
【0056】
次に、セッション情報管理部170は、セッション情報テーブル6において要求されたセッションIDに対応する行のセッションオブジェクトを更新し、最終アクセス時刻を現在の時刻に更新する(ステップS304)。
【0057】
続いてセッションの削除について説明する。セッションの削除は、ロードモジュール400による削除要求によって行われる場合と、セッションの最終アクセス時刻から一定時間経過後に自動的に削除される場合(セッションタイムアウト)がある。なお、どちらか一方だけの構成もあり、セッションタイムアウトが無い場合には、セッション情報テーブル6の最終アクセス時刻とその更新処理は不要である。
【0058】
図14は、本実施の形態2にかかるロードモジュール400による削除要求によって行われるセッションの削除処理を示すフローチャートである。
【0059】
ロードモジュール400は、セッションIDに対応するセッションの削除をセッション情報管理部170に要求する。すなわち、セッション情報管理部170は、セッションIDに対応するセッションの削除をロードモジュール400から要求される(ステップS401)。
【0060】
次に、セッション情報管理部170は、セッション情報テーブル6において要求されたセッションIDに対応する行を削除する(ステップS402)。
【0061】
次に、セッション情報管理部170は、削除したセッションのセッションIDをセッション情報監視部110Aに通知する(ステップS403)。
【0062】
図15は、本実施の形態2にかかるタイムアウトによって行われるセッションの削除処理を示すフローチャートである。なお、図15の処理は、アプリケーションサーバ100Aが停止された際には終了する。
【0063】
セッション情報管理部170は、セッション情報テーブル6において最終アクセス時刻から所定時間(タイムアウト時間)経過したセッションがあれば、その行を削除する(ステップS501)。具体的には、セッション情報管理部170は、セッション情報テーブル6における最終アクセス時刻と現在時刻とを比較し、最終アクセス時刻から所定のタイムアウト時間が経過したセッションがあれば、その行を削除する。
【0064】
次に、セッション情報管理部170は、削除したセッションのセッションIDをセッション情報監視部110Aに通知する(ステップS502)。
【0065】
次に、セッション情報管理部170は、ステップS501を行った時刻から所定時間(監視間隔)が経過したか否かを判断する(ステップS503)。
【0066】
所定の監視間隔が経過していない場合(ステップS503にてNO)、セッション情報管理部170は、所定の監視間隔が経過するのを待つ。
【0067】
所定の監視間隔が経過した場合(ステップS503にてYES)、セッション情報管理部170は、再度ステップS501の処理を行う。
【0068】
なお、タイムアウトするまでの時間(タイムアウト時間)はすべてのモジュール又はセッションで同じであってもよいし、異なっていてもよい。また、モジュール又はセッションごとにタイムアウトするまでの時間を変える場合には、例えばセッション情報テーブル6にタイムアウト時間の列を追加し、ステップS501においてそのタイムアウト時間と最終アクセス時刻からの経過時間とを比較するようにしてもよい。
【0069】
<セッション削除通知受信時の処理>
続いて、図16のフローチャートを用いて、セッション情報監視部110Aがセッション削除の通知をセッション情報管理部170から受けた際の処理について説明する。
【0070】
セッション情報監視部110Aは、削除されたセッションのセッションIDを含むセッション削除通知をセッション情報管理部170から受ける(ステップS601)。
【0071】
次に、セッション情報監視部110Aは、削除されたセッションのセッションIDと一致する行の振り分け先のモジュール名MとモジュールバージョンVを、セッション振り分け先情報格納部184のセッションテーブル5から取得する(ステップS602)。
【0072】
次に、セッション情報監視部110Aは、削除されたセッションのセッションIDと一致する行をセッションテーブル5から削除する(ステップS603)。
【0073】
次に、セッション情報監視部110Aは、セッションテーブル5にモジュール名がMであり、且つモジュールバージョンがVである行があるか否かを判断する(ステップS604)。
【0074】
セッションテーブル5にモジュール名がMであり、且つモジュールバージョンがVである行がある場合(ステップS604にてYES)、セッション情報監視部110Aは、処理を終了する。これにより、セッション数が0でない場合には、処理が終了される。
【0075】
他方、セッションテーブル5にモジュール名がMであり、且つモジュールバージョンがVである行がない場合(ステップS604にてNO)、セッション情報監視部110Aは、モジュール名Mの最新モジュールバージョンをバージョンテーブル2から取得する(ステップS605)。
【0076】
次に、セッション情報監視部110Aは、ステップS605にて取得された最新モジュールバージョンがモジュールバージョンVと一致するか否かを判断する(ステップS606)。
【0077】
最新モジュールバージョンがモジュールバージョンVと一致する場合(ステップS606にてYES)、セッション情報監視部110Aは、処理を終了する。これにより、最新バージョンであるモジュールは、配備解除の対象外になる。
【0078】
他方、最新モジュールバージョンがモジュールバージョンVと一致しない場合(ステップS606にてNO)、セッション情報監視部110Aは、モジュール名M、且つモジュールバージョンVのモジュールの配備解除要求をモジュール配備解除部120Aへ出力する(ステップS607)。これにより、古いモジュールバージョン(最新モジュールバージョンではないモジュールバージョン)のセッション数が0になった場合には、モジュール名M及びモジュールバージョンVのモジュールの配備解除要求が、セッション情報監視部110Aからモジュール配備解除部120Aへ出力される。
【0079】
<モジュール配備解除処理>
続いて、図17及び図18のフローチャートを用いて、モジュール配備解除部120Aがモジュールの配備解除要求を受けた際の処理について説明する。
【0080】
モジュール配備解除部120Aは、モジュール名M、且つモジュールバージョンVのモジュールの配備解除要求をセッション情報監視部110Aから受ける(ステップS701)。
【0081】
次に、モジュール配備解除部120Aは、モジュール名M、且つモジュールバージョンVのモジュールをモジュール実行部150から削除する(ステップS702)。
【0082】
次に、モジュール配備解除部120Aは、モジュール名M、且つモジュールバージョンVのモジュールのファイルバージョンFVをロードバージョンテーブル3から取得する(ステップS703)。
【0083】
次に、モジュール配備解除部120Aは、モジュール名M、且つモジュールバージョンVの行をロードバージョンテーブル3から削除する(ステップS704)。
【0084】
次に、モジュール配備解除部120Aは、ロードバージョンテーブル3にモジュール名がMであり、且つファイルバージョンがFVである行があるか否かを判断する(ステップS705)。
【0085】
ロードバージョンテーブル3にモジュール名がMであり、且つファイルバージョンがFVである行がある場合(ステップS705にてYES)、ステップS706〜ステップS708をスキップしてステップS709に進む。
【0086】
他方、ロードバージョンテーブル3にモジュール名がMであり、且つファイルバージョンがFVである行がない場合(ステップS705にてNO)、モジュール配備解除部120Aは、モジュール名M、且つファイルバージョンFVに一致する行のファイル名Fを実行ファイルテーブル1から取得する(ステップS706)。
【0087】
次に、モジュール配備解除部120Aは、モジュール名M、且つファイルバージョンFVに一致する行を実行ファイルテーブル1から削除する(ステップS707)。
【0088】
次に、モジュール配備解除部120Aは、実行ファイルFの実体をモジュール格納部181から削除する(ステップS708)。
【0089】
次に、モジュール配備解除部120Aは、呼び出し元モジュール名がMであり、且つ呼び出し元モジュールバージョンがVである行を、呼び出し関係格納部182の呼び出し関係テーブル4から取得する(ステップS709)。なお、モジュール名M、且つモジュールバージョンVのモジュールから呼び出される呼び出し先は、モジュール名S、且つモジュールバージョンSVであるとする。
【0090】
次に、モジュール配備解除部120Aは、呼び出し元モジュール名がMであり、且つ呼び出し元モジュールバージョンがVである行を、呼び出し関係テーブル4から削除する(ステップS710)。
【0091】
次に、モジュール配備解除部120Aは、モジュール名M、且つモジュールバージョンVのモジュールが呼び出すモジュール数だけ以下の処理を繰り返す(ステップS711)。すなわち、ステップS709にて取得した各行に対して以下の処理を実行する。
【0092】
モジュール配備解除部120Aは、呼び出し関係格納部182の呼び出し関係テーブル4に呼び出し先のモジュール名がSであり、且つ呼び出し先のモジュールバージョンがSVである行があるか否かを判断する(ステップS712)。
【0093】
呼び出し関係テーブル4に呼び出し先のモジュール名がSであり、且つ呼び出し先のモジュールバージョンがSVである行がある場合(ステップS712にてYES)、ステップS713〜ステップS715をスキップして、ループ処理の最後(ステップS716)に進む。これにより、他のモジュールから呼び出されるモジュールについては配備解除要求が出されない。
【0094】
他方、呼び出し関係テーブル4に呼び出し先のモジュール名がSであり、且つ呼び出し先のモジュールバージョンがSVである行がない場合(ステップS712にてNO)、モジュール配備解除部120Aは、モジュール名Sの最新モジュールバージョンをバージョンテーブル2から取得する(ステップS713)。
【0095】
次に、モジュール配備解除部120Aは、ステップS713にて取得された最新モジュールバージョンがモジュールバージョンSVと一致するか否かを判断する(ステップS714)。
【0096】
最新モジュールバージョンがモジュールバージョンSVと一致する場合(ステップS714にてYES)、ステップS715をスキップして、ループ処理の最後(ステップS716)に進む。これにより、最新バージョンであるモジュールは、配備解除の対象外になる。
【0097】
他方、最新モジュールバージョンがモジュールバージョンSVと一致しない場合(ステップS714にてNO)、モジュール配備解除部120Aは、モジュール名S、且つモジュールバージョンSVのモジュールの配備解除要求を出す(ステップS715)。これにより、他のモジュールから呼び出されなくなった古いモジュールバージョン(最新モジュールバージョンではないモジュールバージョン)のモジュールについて配備解除要求を出すことができる。
【0098】
モジュール配備解除部120Aは、ステップS709にて取得した各行に対する処理が終わるまで、上記の処理(ループ内の処理)を繰り返す(ステップS716)。
【0099】
以上のように、モジュールの配備解除要求は、セッション数が0になった場合に、セッション情報監視部110Aから出される。また、モジュールの配備解除要求は、他のモジュールから呼び出されなくなったモジュールに対して、モジュール配備解除部120Aから再帰的に出される。
【0100】
<具体例>
続いて、本発明の実施の形態2の動作の具体例を説明する。
【0101】
図19は、本発明の実施の形態2にかかるモジュール間の呼び出し関係の例を示す図である。ここでは、図19に示すように、アプリケーションが4つのモジュールA、B、C、及びDにより構成されていると仮定する。また、図19に示すように、クライアント端末300がモジュールAを呼び出し、モジュールAがモジュールBを呼び出し、モジュールBがモジュールCを呼び出し、モジュールCがモジュールDを呼び出すと仮定する。
【0102】
また、各モジュールの実行ファイルとして、モジュールA:「A.war」、モジュールB:「B.jar」、モジュールC:「C.jar」、モジュールD:「D.jar」が存在すると仮定する。さらに、各モジュールの更新(変更)された実行ファイルとして、モジュールA’:「A−modified.war」、モジュールC’:「C−modified.jar」、モジュールC’’:「C−modified−2.jar」存在すると仮定する。ここで、モジュール名に付与されている「’」は、実行ファイルが変更されたモジュールを示す。
【0103】
はじめに、実行ファイルテーブル1、バージョンテーブル2、ロードバージョンテーブル3、呼び出し関係テーブル4の状態が、それぞれ図4図6図7図8であるとする。この場合、ロードモジュール400間の呼び出し関係は、図20のようになる。なお、ロードモジュール400に付与された「a(b,c)」は、モジュールa、モジュールバージョンbのロードモジュール400を示し、当該ロードモジュール400が、ファイルバージョンcの実行ファイルを用いていることを示す。
【0104】
図20の状態からモジュールA、モジュールバージョン3(A’(3,3))に対する配備解除要求が出された場合、A’(3,3)は配備解除される。しかし、A’(3,3)が配備解除されても、モジュールB、モジュールバージョン2(B(2,1))は、モジュールA、モジュールバージョン2(A(2,1))から呼び出される。このため、B(2,1)は配備解除されない。
【0105】
このときの、テーブルの遷移及び配備解除について、図17及び図18のステップを用いて説明する。図17のステップS704により、モジュール名がA、モジュールバージョンが3の行がロードバージョンテーブル3から削除される。これにより、ロードバージョンテーブル3は、図21のようになる。また、図18のステップS710により、呼び出し元モジュール名がA、呼び出し元モジュールバージョンが3の行が呼び出し関係テーブル4から削除される。これにより、呼び出し関係テーブル4は、図22のようになる。また、このときのロードモジュール400間の呼び出し関係は、図23のようになる。
【0106】
図23の状態からモジュールA、モジュールバージョン2(A(2,1))に対する配備解除要求が出された場合、A(2,1)は配備解除される。また、A(2,1)が配備解除されることにより、モジュールB、モジュールバージョン2(B(2,1))は、どのモジュールからも呼び出されなくなるため、B(2,1)に対する配備解除要求が再帰的に出され、B(2,1)は配備解除される。
【0107】
このときの、テーブルの遷移及び配備解除について、図17及び図18のステップを用いて説明する。図17のステップS704により、モジュール名がA、モジュールバージョンが2の行がロードバージョンテーブル3から削除される。また、図18のステップS710により、呼び出し元モジュール名がA、呼び出し元モジュールバージョンが2の行が呼び出し関係テーブル4から削除される。これにより、呼び出し関係テーブル4に呼び出し先モジュール名がB、呼び出し先モジュールバージョンが2である行が存在しなくなる。さらに、バージョンテーブル2のモジュール名Bの最新モジュールバージョンは3であり、呼び出し先モジュールバージョンの2とは一致しない。このため、図18のステップS715により、モジュール名B、モジュールバージョン2(B(2,1))に対する配備解除要求が出され、B(2,1)が配備解除される。
【0108】
また、B(2,1)の配備解除によって、モジュール名C、モジュールバージョン2(C‘(2,2))は、どのモジュールからも呼び出されなくなる。このため、C‘(2,2)に対する配備解除要求が再帰的に出され、C‘(2,2)は配備解除される。
【0109】
このときの、テーブルの遷移及び配備解除について、図17及び図18のステップを用いて説明する。図17のステップS704により、モジュール名がB、モジュールバージョンが2の行がロードバージョンテーブル3から削除される。また、図18のステップS710により、呼び出し元モジュール名がB、呼び出し元モジュールバージョンが2の行が呼び出し関係テーブル4から削除される。これにより、呼び出し関係テーブル4に呼び出し先モジュール名がC、呼び出し先モジュールバージョンが2である行が存在しなくなる。さらに、バージョンテーブル2のモジュール名Cの最新モジュールバージョンは3であり、呼び出し先モジュールバージョンの2とは一致しない。このため、図18のステップS715により、モジュール名C、モジュールバージョン2(C‘(2,2))に対する配備解除要求が出され、C‘(2,2)が配備解除される。
【0110】
モジュール名C、モジュールバージョン2(C‘(2,2))に対する配備解除では、図17のステップS704により、モジュール名がC、モジュールバージョンが2の行がロードバージョンテーブル3から削除される。これにより、ロードバージョンテーブル3にモジュール名がC、ファイルバージョンが2である行が存在しなくなるため、図17のステップS707により、モジュール名がC、ファイルバージョンが2の行が実行ファイルテーブル1から削除される。また、図17のステップS708により、モジュール名がC、ファイルバージョンが2の実行ファイルの実体がモジュール格納部181から削除される。さらに、図18のステップS710により、呼び出し元モジュール名がC、呼び出し元モジュールバージョンが2の行が呼び出し関係テーブル4から削除される。
【0111】
その結果、実行ファイルテーブル1、ロードバージョンテーブル3、呼び出し関係テーブル4の状態は、それぞれ図24図25図26のようになる。また、このときのロードモジュール400間の呼び出し関係は、図27のようになる。
【0112】
以上のように、本発明の実施の形態2にかかるアプリケーションサーバ100A(情報処理システム)は、セッション情報管理部170をさらに備える構成としている。また、セッション情報管理部170は、削除を要求されたセッション、又は最終アクセス時刻から所定時間経過したセッションのセッションIDをセッション情報監視部110Aに通知する構成としている。これにより、本実施の形態2にかかるアプリケーションサーバ100Aでは、セッション情報監視部110Aが、削除すべきセッションのセッションIDを判別することができる。
【0113】
また、アプリケーションサーバ100Aは、セッションテーブル5を格納するセッション振り分け先情報格納部184をさらに備える構成としている。また、セッションテーブル5には、モジュール名に、当該モジュールに対するセッションのセッションIDと振り分け先のロードモジュール400のモジュールバージョンとが関連づけられた構成としている。さらに、セッション情報監視部110Aは、セッション情報管理部170から通知されたセッションID及びセッションテーブル5に基づいて、第1のモジュールのセッション数が0になったか否かを判断する構成としている。これにより、本実施の形態2にかかるアプリケーションサーバ100Aでは、セッション情報管理部170からセッションIDを通知されることをトリガとして、第1のモジュールのセッション数が0になったか否かを判断することができる。
【0114】
さらに、アプリケーションサーバ100Aでは、セッション情報監視部110Aが、第1のモジュールのセッション数が0になった際に、第1のモジュールのモジュール名及びモジュールバージョンを含む配備解除要求をモジュール配備解除部120Aへ出力する構成としている。また、アプリケーションサーバ100Aでは、モジュール配備解除部120Aが、配備解除要求を受け取った場合に、配備解除要求に含まれるモジュール名且つモジュールバージョンの第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュール名且つモジュールバージョンのモジュールを配備解除する構成としている。これにより、本実施の形態2にかかるアプリケーションサーバ100Aでは、モジュールバージョンごとに配備解除することができる。
【0115】
なお、上述の説明では、モジュール格納部181、呼び出し関係格納部182、バージョン情報格納部183、及びセッション振り分け先情報格納部184の各テーブルへのデータの登録は、配備処理部130、モジュール生成部140、及びリクエスト振り分け部160を用いて行われることを前提としているが、これに限らない。例えば、図28に示すように、アプリケーションサーバ100Aが、配備処理部130、モジュール生成部140、及びリクエスト振り分け部160を備えない構成としてもよい。この場合、モジュール格納部181、呼び出し関係格納部182、バージョン情報格納部183、及びセッション振り分け先情報格納部184の各テーブルのデータは、例えば、運用管理者によって管理端末200から登録されるようにしてもよい。
【0116】
また、上述の説明では、配備解除の契機として、アプリケーションのリクエストを直接受け付ける第1のモジュールのセッション数が0になった場合について説明したが、これに限らない。例えば、運用管理者が、管理端末200を通じてモジュール配備解除部120Aに対して明示的に配備解除要求を出すようにしてもよい。すなわち、アプリケーションサーバ100Aが、管理端末200から第1のモジュールの配備解除要求を受信し、モジュール配備解除部120Aが、管理端末200から受信した配備解除要求により第1のモジュールを配備解除するとともに、それによってどのモジュールからも呼び出されなくなったモジュールを配備解除する機能も備えるようにしてもよい。これにより、運用管理者が任意のタイミングでモジュールを配備解除し、それに伴って不要になったモジュールを自動で配備解除することができる。
【0117】
実施の形態3
続いて、本発明の実施の形態3について説明する。図29は、本発明の実施の形態3にかかるアプリケーションの実行環境の構成例を示すブロック図である。図29を参照すると、実行環境は、アプリケーションサーバ100Bと、管理端末200と、を含む。管理端末200は、ネットワーク10を介してアプリケーションサーバ100Bに接続される。
【0118】
アプリケーションサーバ100Bは、モジュール配備解除部120Bと、モジュール実行部150と、モジュール格納部181と、呼び出し関係格納部182と、バージョン情報格納部183と、を備えている。
【0119】
アプリケーションサーバ100Bは、実施の形態2で説明した、アプリケーションのリクエストを直接受け付ける第1のモジュールのセッション数が0になった際にモジュールの配備解除を行う機能を備えていない。その機能に代えて、アプリケーションサーバ100Bは、管理端末200から受信した配備解除要求によりモジュールの配備解除を行う機能を備えている。すなわち、アプリケーションサーバ100Bは、管理端末200から第1のモジュールの配備解除要求を受信する。また、モジュール配備解除部120Bは、管理端末200から受信した配備解除要求により第1のモジュールの配備解除を行う。さらに、モジュール配備解除部120Bは、第1のモジュールの配備解除によってどのモジュールからも呼び出されなくなったモジュールを配備解除する。これにより、運用管理者が任意のタイミングでモジュールを配備解除し、それに伴って不要になったモジュールを自動で配備解除することができる。
【0120】
なお、上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0121】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【0122】
5 セッションテーブル
100、100A アプリケーションサーバ(情報処理システム)
110、110A セッション情報監視部
120、120A モジュール配備解除部
170 セッション情報管理部
184 セッション振り分け先情報格納部
10 ネットワーク
200 管理端末
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29