JPH10320184A - ソフトウェアバージョン管理システム - Google Patents

Abstract

(57)【要約】 【解決手段】 第１サーバ２−１や第２サーバ２−２
は、クライアントにサービスを提供する。メタサーバ１
はこれらのサーバのプログラムを起動させたり停止させ
る制御を行う。バージョン管理サーバ４はネットワーク
８を通じてデータサーバから各サーバ２−１や２−２の
プログラムをダウンロードし、所定のタイミングで自動
的に各サーバのプログラムをバージョンアップする。 【効果】 バージョン管理サーバ４がバージョンアップ
の作業を管理し、メタサーバ１が自動的に各サーバのプ
ログラムの起動や停止を制御するので、バージョンアッ
プ処理を自動化できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サーバクライアン
トシステムを構成するサーバの動作用プログラムを自動
的にバージョンアップする機能を持つソフトウェア管理
システムに関する。

【０００２】

【従来の技術】例えば、ウエブプラウザ上で動作するジ
ャバ言語により作成されたプログラム（アプレット）
は、起動時に自動的にネットワークを経由してプログラ
ムが転送される仕組みを持っている。このため、アプレ
ット使用時には常に最新のプログラムが利用できるとい
う利点がある。即ち、従来一般のアプリケーションソフ
トウェアのように、バージョンアップの度にユーザがネ
ットワークやその他のメディアを通じて最新版を入手
し、自らバージョンアップ作業を行う必要がない。

【０００３】しかしながら、アプレットは毎回起動時に
プログラム全体をダウンロードすることから、ネットワ
ーク負荷が高くなる。また、起動開始から起動までにダ
ウンロードによるタイムラグが発生する。

【０００４】一方、アプレットを通常のアプリケーショ
ンのように各端末の持つハードディスク上に保存してお
き、ダウンロード元のサーバ上にあるファイルが更新さ
れたときに限り、必要最小限のファイルをネットワーク
によりダウンロードする方法もある。これによれば、最
初の起動時以外はローカルなハードディスク上にファイ
ルが存在するため、高速起動が可能になる。また、更新
時のファイルのダウンロードは必要最小限のものに限ら
れるので、ネットワーク負荷を高めることはない。

【０００５】

【発明が解決しようとする課題】ところで、上記のよう
な従来の技術には次のような解決すべき課題があった。
上記のようなバージョンアップ方法は、ワードプロセッ
サや各種の管理端末装置等で動作するアプリケーション
を対象としている。従って、これらのアプリケーション
のバージョンアップはそのアプリケーションを実行する
直前等に十分な時間的余裕を持って処理することができ
る。

【０００６】しかしながら、サーバクライアントシステ
ムのサーバが動作するプログラムは、これらと同様の方
法を採用すると弊害が生じる。即ち、サーバのプログラ
ムは常時動作しており、クライアントからの要求に応じ
て所定のサービスを提供している。従って、管理者によ
るバージョンアップ作業のために長時間サーバの動作を
停止させることができない。このようなサービスの停止
を避けるために、サーバの利用が少ない深夜等にバージ
ョンアップ作業を行おうとすれば、管理者に深夜作業を
強いることになる。

【０００７】

【課題を解決するための手段】本発明は以上の点を解決
するため次の構成を採用する。 〈構成１〉ネットワークに接続されて、クライアントに
サービスを提供するサーバと、このサーバが動作するた
めの環境を提供するメタサーバと、ネットワークを通じ
てプログラム提供元の情報を受入れて、上記サーバのプ
ログラムのバージョンを管理するバージョン管理サーバ
とを備え、サービスの開始時には、上記メタサーバが各
サーバのプログラムを起動し、バージョン管理サーバ
が、ネットワークを通じて上記プログラム提供元の情報
を受入れて、各サーバで動作するプログラムのバージョ
ン変更を認知すると、最新のプログラムをプログラム提
供元からダウンロードし、メタサーバが、該当するサー
バのプログラムを停止し、バージョン管理サーバは既に
ダウンロードした最新のプログラムをロードして、メタ
サーバがそのサーバのプログラムを再起動することを特
徴とするソフトウェアバージョン管理システム。

【０００８】〈構成２〉構成１において、バージョン管
理サーバは、バージョン変更前のサーバの動作を継続さ
せたまま、新たなバージョンのサーバをロードし、新た
なバージョンのサーバの起動準備が完了したとき、クラ
イアントに対して、バージョン変更前のサーバを接続し
た状態から新たなサーバに接続をした状態に切り替える
ためのネットワークブリッジを設けたことを特徴とする
ソフトウェアバージョン管理システム。

【０００９】〈構成３〉クライアントにサービスを提供
するサーバをネットワークに接続し、上記サーバの動作
するプログラムについてバージョンを管理するバージョ
ン管理サーバを設け、サービスの開始時には、各サーバ
のプログラムを起動し、バージョン管理サーバが、ネッ
トワークを通じて上記プログラム提供元の情報を受入れ
て、各サーバで動作するプログラムのバージョン変更を
認知すると、最新のプログラムをプログラム提供元から
ダウンロードし、該当するサーバのプログラムを停止
し、既にダウンロードした最新のプログラムをロードし
て、プログラムを再起動するように動作するプログラム
を記録した記録媒体。

【００１０】〈構成４〉構成３において、バージョン管
理サーバは、バージョン変更前のサーバの動作を継続さ
せたまま、新たなバージョンのサーバをロードし、新た
なバージョンのサーバの起動準備が完了したとき、クラ
イアントに対して、バージョン変更前のサーバを接続し
た状態から新たなサーバに接続をした状態に切り替える
よう動作するプログラムを記録した記録媒体。

【００１１】

【発明の実施の形態】以下、本発明の実施の形態を具体
例を用いて説明する。 〈具体例１〉図１は、具体例１によるソフトウェア管理
システムブロック図である。図のシステムは、メタサー
バ１により起動や停止を制御される。第１サーバ２−１
や第２サーバ２−２は、第１クライアント３−１や第２
クライアント３−２に対し所定のサービスを提供するサ
ーバである。また、本発明による第１サーバ２−１や第
２サーバ２−２のバージョンアップ管理のために、メタ
サーバ１にはバージョン管理サーバ４が接続されてい
る。

【００１２】メタサーバ１は、この動作環境で第１サー
バ２−１や第２サーバ２−２が動作するための共通の環
境を提供するサーバである。第１サーバ２−１や第２サ
ーバ２−２は、ＤＮＳウエブサーバ等どんなサーバであ
ってもよく、その数は任意である。メタサーバ１に接続
された実行環境５は、ＯＳ（オペレーションシステム）
等のソフトウェアを動作させるために必要な実行環境で
あって、ジャバ言語の仮想マシン等も含まれる。

【００１３】バージョン管理サーバ４は、メタサーバ１
上で動作している全てのサーバに関する情報を管理する
サーバである。バージョン管理サーバ４も任意の数だけ
設けられていてよい。補助記憶装置６は、実行環境５を
介してメタサーバ１に接続されている。この補助記憶装
置６は、バージョン管理サーバ４や第１サーバ２−１、
第２サーバ２−２等がメタサーバ１と実行環境５を介し
てアクセスするための記憶装置である。

【００１４】なお、各サーバがメタサーバ１を介すこと
なく独自の補助記憶装置を持つようにしても差し支えな
い。第１サーバ２−１や第２サーバ２−２は、ネットワ
ーク８を介して第１クライアント３−１や第２クライア
ント３−２に接続されている。一方、バージョン管理サ
ーバ４もネットワーク８を介して、第１データサーバ７
−１や第２データサーバ７−２に接続されている。

【００１５】第１データサーバ７−１は、例えば、メタ
サーバ１やバージョン管理サーバ４の動作プログラムの
最新版を格納し公開している。第２データサーバ７−２
は、第１サーバ２−１や第２サーバ２−２の動作する最
新のプログラムを格納し公開している。なお、各サーバ
のためのプログラムごとにそれぞれ異なるデータサーバ
が存在していても構わないし、１台のデータサーバがこ
れら全てのプログラムを公開するようにしても差し支え
ない。

【００１６】第１サーバ２−１、第２サーバ２−２、メ
タサーバ１、バージョン管理サーバ４等は、１台のコン
ピュータメモリ上に展開されたプログラム群により構成
してもよいし、またそれぞれ相互に通信用のバスで接続
された複数のプロセッサにより構成してもよい。

【００１７】次に、上記のシステムについて、その動作
を説明する。システムの動作は基本的に、サーバの初期
設定、サーバの運用、サーバのバージョン変更の３種類
に分類できる。

【００１８】〈サーバの初期設定〉図２に、サーバの初
期設定動作フローチャートを示す。まず、サーバを利用
するために、図のステップＳ１とＳ２に示すように、メ
タサーバ１とバージョン管理サーバ４のインストールを
行う。これらのプログラムは、図１に示すネットワーク
８を介して第１データサーバ７−１から入手する。そし
て、これらのプログラムをサーバとなるマシンにインス
トールし、ステップＳ３において、メタサーバとバージ
ョン管理サーバを起動する。

【００１９】次に、ステップＳ４において、バージョン
管理サーバ４に対し、新たにサーバとなる第１サーバと
第２サーバの登録を行う。例えば第１サーバ２−１をバ
ージョン管理サーバ４に登録する場合は、このサーバの
最新版となるプログラムを提供する第２データサーバ７
−２のネットワーク上のアドレスと、利用するサーバの
プログラム名を通知することで実現する。

【００２０】次のステップＳ５では、バージョン管理サ
ーバ４が第２データサーバ７−２からネットワーク８を
通じて第１サーバと第２サーバのプログラムをダウンロ
ードする。このとき、第１サーバや第２サーバの動作に
必要なデータファイルがある場合には同時にダウンロー
ドをする。なお、このときのネットワークプロトコルに
は、従来からよく知られているＨＴＴＰ（ハイパーテキ
スト転送プロトコル）やＦＴＰ（ファイル転送プロトコ
ル）を利用することができる。

【００２１】ＨＴＴＰであれば、プロクシキャッシュ等
の機構を利用することで効率的にプログラムのダウンロ
ードを行うことができる。なお、第２データサーバ７−
２の側でも、バージョン管理サーバ４が管理しているマ
シンを登録しておく。これは第２データサーバ７−２の
側からプログラムのバージョンアップをバージョン管理
サーバ４に自発的に通知できるようにするためである。

【００２２】なお、ここまででサーバの初期設定が終了
し、ステップＳ６とステップＳ７では、サーバの運用が
開始される。即ち、ステップＳ６において、第１サーバ
２−１と第２サーバ２−２とは、メタサーバ１によって
そのプログラムが起動される。そして、ステップＳ７に
おいて、第１サーバと第２サーバとは通常のサービス提
供を開始する。これによって、図１に示した第１クライ
アント３−１や第２クライアント３−２は、ネットワー
ク８を通じて第１サーバ２−１や第２サーバ２−２のサ
ービスを受けることができる。

【００２３】〈サーバのバージョン変更〉図３は、バー
ジョン変更動作フローチャートを示す。運用が開始され
ると、バージョン管理サーバ４は図のステップＳ１に示
すように、第１サーバや第２サーバのプログラム更新を
監視する。これは、例えばネットワーク８を通じて第２
データサーバ７−２に対し定期的に問い合わせを行う
か、あるいは第２データサーバ７−２からの通知を受け
ることにより実現する。第２データサーバ７−２上の該
当するプログラムが更新されると、バージョン管理サー
バ４はステップＳ２からステップＳ３に進み、該当する
プログラムをダウンロードする。

【００２４】次にステップＳ４において、バージョン管
理サーバ４は該当するサーバに対してサービス停止要求
を行う。なお、これらの一連の処理は全て自動的に行わ
れるため、サービスの停止要求は深夜等、サーバに対す
る需要が少ない時間を任意に設定することが好ましい。
第１サーバ２−１や第２サーバ２−２はステップＳ５に
おいて、サービス停止要求を受けると、ネットワークの
ポートをクローズする。こうしてクライアントからの要
求の受付を停止する。次に、ステップＳ６において、そ
の内部状態を、図１に示した補助記憶装置６に出力す
る。これは、バージョンアップ後、現在の設定から起動
できるようにしておくためである。

【００２５】こうして停止処理を終えた旧バージョンの
サーバは、停止処理終了をバージョン管理サーバに通知
する。バージョン管理サーバ４は次のステップＳ８にお
いて、ステップＳ３でダウンロードしたプログラムを実
行環境中にロードし、バージョン変更後の新サーバを立
ち上げる。そして、ステップＳ９において、メタサーバ
１は新サーバを起動する。次に、ステップＳ１０で、新
サーバは図１に示した補助記憶装置６から保存しておい
た内部状態を引き上げて、サービスを再開する。その
後、ステップＳ１１において、バージョン管理サーバ４
は、旧サーバを実行環境から削除する。

【００２６】図４には、上記のような具体例１のシステ
ムの動作を主要なブロックと共に図示した。ここには、
メタサーバ１、バージョン管理サーバ４、補助記憶装置
６、旧サーバ２及び新サーバ２′のみが表示されてい
る。図３に示した各ステップは、この図の矢印に対応す
る。即ち、バージョン管理サーバ４は、ステップＳ４で
旧サーバ２を停止し、旧サーバ２はステップＳ６で、内
部状態を補助記憶装置６に記憶する。ステップＳ７で、
旧サーバ２がバージョン管理サーバ４に停止を通知する
と、ステップＳ８で、バージョン管理サーバ４は新サー
バ２′を立ち上げる。

【００２７】新サーバ２′はステップＳ１０で補助記憶
装置６から内部状態を引き上げて、動作を開始し、その
後、バージョン管理サーバがステップＳ１１で旧サーバ
２をシステムから除去する。このように旧サーバ２から
新サーバ２′に切換えを行う処理は自動的に行われる。
また、バージョン管理サーバ４がネットワークからプロ
グラムをダウンロードした後に、コンピュータのメモリ
上で速やかに実行される。

【００２８】〈具体例１の効果〉以上の具体例１によれ
ば、メタサーバ１とバージョン管理サーバ４とを設ける
ことによって、サーバのバージョンアップ処理を自動的
に行うことが可能になる。また、こうしたバージョンア
ップは自動的に一定の手順で実行されるため、管理者が
手作業で行う場合よりも迅速に処理でき、サーバの停止
時間が短時間で済む。さらに、この作業は自動化される
ため、夜中等にも実施が可能である。なお、こうした処
理は、ネットワークに既存のプロトコルが使用できるの
で、新たなシステムを構築する必要がないという効果も
ある。

【００２９】〈具体例２〉図５には、具体例２によるソ
フトウェア管理システムのブロック図を示す。このシス
テムは、図１のシステムと比較してわかるように、メタ
サーバ１上で動作する各サーバが、ネットワーク８の側
において、ネットワークブリッジ９によって連結されて
いる。従って、この構成では、第１クライアント３−１
はネットワークブリッジ９を介して第１サーバ２−１か
らサービスを受けることもできるし、第２サーバ２−２
からサービスを受けることもできる。

【００３０】また、第２クライアント３−２も同様に、
ネットワークブリッジ９を介して第１サーバ２−１から
サービスを受け、あるいは第２サーバ２−２からサービ
スを受けることができる。このようにネットワーク接続
を仲介するネットワークブリッジ９を設けることによっ
て、この具体例ではバージョンアップの際に、サーバの
動作を停止することなくその処理を完了することができ
る。

【００３１】具体例２の場合のサーバの初期設定や運用
動作等は、具体例１の場合と全く同様のため説明を省略
する。また、バージョンアップについても、その多くの
部分は具体例１と同様のため、フローチャートは省略
し、次の動作説明図によって主たる相違部分を説明す
る。

【００３２】図６は、具体例２のシステムの動作説明図
である。図４と比較してわかるように、具体例１では、
一旦旧サーバの動作を停止し、内部状態を補助記憶装置
６に出力し、その後新サーバ２′を立ち上げてバージョ
ン変更を行った。一方、この具体例では、ネットワーク
ブリッジ９を設けるとともに、旧サーバ２のサービス停
止を新サーバ２′のサービス開始に合わせるようにし
た。これによって、バージョン変更処理の実行中にサー
ビスが停止するのを防止する。

【００３３】図６の矢印に書き入れたステップＳ１〜Ｓ
７までの処理を参照しながら、この切換え動作を具体的
に説明する。まずステップＳ１において、バージョン管
理サーバ４は旧サーバ２に対しサービス停止の要求を行
う。旧サーバ２はステップＳ２において、補助記憶装置
６に内部状態を出力する。なお、旧サーバ２はこの時点
ではサービスを停止せず、サービスを継続する。そし
て、ステップＳ３において、一定の処理が終了したこと
をバージョン管理サーバ４に通知する。

【００３４】バージョン管理サーバ４はこの通知を受け
て、ステップＳ４において、新サーバ２′をロードし、
立上げを行う。新サーバ２′は、補助記憶装置６から旧
サーバの内部状態を取り出し、サービス開始準備を行
う。そして、準備が完了するとステップＳ６でバージョ
ン管理サーバ４にその旨を通知する。バージョン管理サ
ーバ４は、新サーバ２′からサービス提供準備完了の通
知を受けると、ステップＳ７において、ネットワークブ
リッジ９に対しサービス接続先の変更を通知する。即
ち、ネットワークブリッジ９は、これまで旧サーバ２と
ネットワーク８とを接続し、第１クライアント３−１に
対するサービス提供を行ってきた。

【００３５】バージョンアップの準備が完了すると、今
度はネットワークブリッジ９は新サーバ２′とネットワ
ーク８を接続し、旧サーバ２をネットワーク８から切り
離す。こうしてその後は新しいサービスが新サーバ２′
からクライアント３に提供される。こうしてネットワー
ク８から切り離された旧サーバ２は、ステップＳ８でバ
ージョン管理サーバ４から動作停止要求を受けて動作を
停止する。そして、ステップＳ９で旧サーバ２は動作の
停止をバージョン管理サーバ４に通知する。その後は具
体例１と同様に、バージョン管理サーバ４は旧サーバ２
を実行環境から削除してバージョンアップ処理を終了す
る。

【００３６】〈具体例２の効果〉以上のように、バージ
ョン変更の際、旧サーバと新サーバとをネットワークブ
リッジを介してクライアントに接続し、バージョンを変
更した新サーバがサービス提供開始準備のできるまで、
旧サーバにサービスを継続させるので、バージョン変更
処理によってサービスが停止することがない。

【図面の簡単な説明】

【図１】具体例１によるソフトウェア管理システムのブ
ロック図である。

【図２】サーバの初期設定動作フローチャートである。

【図３】バージョン変更動作フローチャートである。

【図４】具体例１のシステムの動作説明図である。

【図５】具体例２によるソフトウェア管理システムブロ
ック図である。

【図６】具体例２のシステムの動作説明図である。

【符号の説明】

１ メタサーバ ２−１ 第１サーバ ２−２ 第２サーバ ３−１ 第１クライアント ３−２ 第２クライアント ４ バージョン管理サーバ ５ 実行環境 ６ 補助記憶装置 ７−１ 第１データサーバ ７−２ 第２データサーバ ８ ネットワーク

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ネットワークに接続されて、クライアン
   トにサービスを提供するサーバと、 このサーバが動作するための環境を提供するメタサーバ
   と、 ネットワークを通じてプログラム提供元の情報を受入れ
   て、前記サーバのプログラムのバージョンを管理するバ
   ージョン管理サーバとを備え、 サービスの開始時には、前記メタサーバが各サーバのプ
   ログラムを起動し、 バージョン管理サーバが、ネットワークを通じて前記プ
   ログラム提供元の情報を受入れて、各サーバで動作する
   プログラムのバージョン変更を認知すると、最新のプロ
   グラムをプログラム提供元からダウンロードし、 メタサーバが、該当するサーバのプログラムを停止し、 バージョン管理サーバは既にダウンロードした最新のプ
   ログラムをロードして、 メタサーバがそのサーバのプログラムを再起動すること
   を特徴とするソフトウェアバージョン管理システム。
2. 【請求項２】 請求項１において、 バージョン管理サーバは、 バージョン変更前のサーバの動作を継続させたまま、新
   たなバージョンのサーバをロードし、 新たなバージョンのサーバの起動準備が完了したとき、
   クライアントに対して、バージョン変更前のサーバを接
   続した状態から新たなサーバに接続をした状態に切り替
   えるためのネットワークブリッジを設けたことを特徴と
   するソフトウェアバージョン管理システム。
3. 【請求項３】 クライアントにサービスを提供するサー
   バをネットワークに接続し、 前記サーバの動作するプログラムについてバージョンを
   管理するバージョン管理サーバを設け、 サービスの開始時には、各サーバのプログラムを起動
   し、 バージョン管理サーバが、ネットワークを通じて前記プ
   ログラム提供元の情報を受入れて、各サーバで動作する
   プログラムのバージョン変更を認知すると、最新のプロ
   グラムをプログラム提供元からダウンロードし、 該当するサーバのプログラムを停止し、 既にダウンロードした最新のプログラムをロードして、 プログラムを再起動するように動作するプログラムを記
   録した記録媒体。
4. 【請求項４】 請求項３において、 バージョン管理サーバは、 バージョン変更前のサーバの動作を継続させたまま、新
   たなバージョンのサーバをロードし、 新たなバージョンのサーバの起動準備が完了したとき、
   クライアントに対して、バージョン変更前のサーバを接
   続した状態から新たなサーバに接続をした状態に切り替
   えるよう動作するプログラムを記録した記録媒体。