JP3119166B2 - ネットワークシステムのソフトウェア・バージョン管理方式 - Google Patents

ネットワークシステムのソフトウェア・バージョン管理方式

Info

Publication number
JP3119166B2
JP3119166B2 JP08172271A JP17227196A JP3119166B2 JP 3119166 B2 JP3119166 B2 JP 3119166B2 JP 08172271 A JP08172271 A JP 08172271A JP 17227196 A JP17227196 A JP 17227196A JP 3119166 B2 JP3119166 B2 JP 3119166B2
Authority
JP
Japan
Prior art keywords
version
client
program
check
software
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
Application number
JP08172271A
Other languages
English (en)
Other versions
JPH1021059A (ja
Inventor
征弘 百本
卓郎 金森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP08172271A priority Critical patent/JP3119166B2/ja
Publication of JPH1021059A publication Critical patent/JPH1021059A/ja
Application granted granted Critical
Publication of JP3119166B2 publication Critical patent/JP3119166B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、ネットワークシス
テムのソフトウェア・バージョン管理方式に係り、詳し
くは、分散システム上で動作するソフトウェア・バージ
ョン管理方式に適用することができ、特に、クライアン
トのソフトウェアを実行する時、実行するクライアント
のソフトウェアのバージョンを確実に合わせて、バージ
ョン不一致による不整合を起こらないようにして安定し
たシステム動作を実現することができるネットワークシ
ステムのソフトウェア・バージョン管理方式に関する。
【0002】
【従来の技術】分散システム上で動作する従来のソフト
ウェアのバージョン管理方式では、バージョン管理用の
データベースにより各マシンにインストールされている
ソフトウェアおよびそのバージョン情報を集中的に管理
している。この従来のソフトウェアのバージョン管理方
式には、該ソフトウェア及びそのバージョン情報を管理
した後、スケジュールを設定した時のソフトウェア配布
機能やソフトウェア配布に失敗した際のリトライ機能な
どにより、ソフトウェア配信機能の付加機能として配信
時に各クライアントのソフトウェアのバージョンの整合
性を保証しようという形態のものや、分散システム全体
のバージョン情報を管理して、定期的に各クライアント
のソフトウェアのバージョンのチェックを行ない、バー
ジョンの不一致を検出した際に、バージョンを合わせる
ために、バージョンの合っていないクライアントにソフ
トウェアの入れ替えを指示する形態のものが知られてい
る。
【0003】まず、前者のスケジュール機能及びソフト
ウェア配布に失敗した際のリトライ機能によりシステム
全体のバージョンの一致を保証しようという形態の従来
のソフトウェアのバージョン管理方式について、以下に
図面を用いて説明する。図8は従来のソフトウェアのバ
ージョン管理方式におけるシステム動作フローを示すフ
ローチャートである。ソフトウェア配布サーバは、配布
するソフトウェアの配布先、入れ替え時間などのスケジ
ュール情報を設定した後(ステップS801)、設定し
たスケジュール情報に従って、配布先のクライアントに
対するソフトウェアの配信処理を行ない、クライアント
へソフトウェア入れ替え用ファイルを配信する(ステッ
プS802)。この時、設定したスケジュール情報のソ
フトウェアの入れ替え時間などの情報もクライアントへ
送信される。
【0004】クライアントは、ソフトウェア配布サーバ
から配信されたソフトウェア入れ替え用ファイルを受信
すると(ステップS803)、ソフトウェア入れ替え用
ファイルの受信結果をソフトウェア配布サーバへ通知す
る(ステップS804)。クライアントは、ソフトウェ
ア配布サーバから配信されたソフトウェア入れ替え用フ
ァイルを受信し、ソフトウェア入れ替え用ファイルの受
信が正常に行なわれた場合、ソフトウェア配布サーバか
ら送信され受信したスケジュール情報のソフトウェアの
入れ替え時間などの情報に従って、ソフトウェアの入れ
替え処理を実施する(ステップS805)。
【0005】クライアントは、ソフトウェア入れ替え処
理の結果をソフトウェア配布サーバへ通知する(ステッ
プS806)。ソフトウェア配布サーバは、クライアン
トから通知されたソフトウェア入れ替え用ファイル受信
確認結果とソフトウェア入れ替え処理結果のソフトウェ
ア配布結果を受信し(ステップS807)、受信したソ
フトウェア配布結果を基にソフトウェア配布が正常に処
理されたか否かを判断する(ステップS808)。
【0006】ソフトウェア配布サーバは、ソフトウェア
配布が正常に処理されず失敗していると判断した場合
(ステップS808)、設定したスケジュール情報を変
更せずに、再度クライアントへソフトウェアを配信する
(ステップS802)。一方、ソフトウェア配布サーバ
は、ソフトウェア配布が正常に処理されたと判断した場
合(ステップS808)、他に入れ替え対象ソフトウェ
アがあるか否かを判断し(ステップS809)、ある場
合は、次のソフトウェアの処理に戻り(ステップS80
1)、ない場合は、処理を終了する。
【0007】この従来のソフトウェアのバージョン管理
方式では、配布サーバ側で設定したスケジュール情報に
従ってクライアントが定期的にソフトウェアを入れ替え
たり、配布サーバからのソフトウェア配布を失敗した時
やクライアントがソフトウェアの入れ替えを失敗した
時、再度配布サーバからソフトウェアを配信してソフト
ウェアの入れ替え処理を行なうものである。
【0008】次に、前述した後者の定期的にバージョン
のチェックを行なってバージョンの不一致を検出した際
に、ソフトウェアの入れ替えを指示する形態の従来のソ
フトウェアのバージョン管理方式について、以下に図面
を用いて説明する。図9は従来のソフトウェアのバージ
ョン管理方式におけるシステム動作フローを示すフロー
チャートである。クライアントは、定期的にバージョン
チェックに必要な情報を設定し、設定した情報を基に定
期的にソフトウェアのバージョンチェックをバージョン
管理サーバへ依頼する(ステップS901)。この時、
クライアントは、クライアントのソフトウェアのバージ
ョン情報やソフトウェアのバージョンチェック要求情報
などをバージョン管理サーバへ送信する。
【0009】バージョン管理サーバは、クライアントか
らソフトウェアのバージョンチェック要求を受け付ける
と(ステップS902)、バージョン管理データベース
に管理しているバージョン情報を基に、クライアントの
ソフトウェアのバージョン情報をチェックして、バージ
ョンの整合性を確認する(ステップS903)。バージ
ョン管理サーバは、バージョン・チェックの結果情報を
クライアントへ送信して応答する(ステップS90
4)。
【0010】クライアントは、バージョン管理サーバか
ら送信されるバージョン・チェック結果情報を受信する
と(ステップS905)、受信したバージョン・チェッ
ク結果情報を基に、クライアントのソフトウェアのバー
ジョンがバージョン管理サーバで管理されているソフト
ウェアのバージョンと一致しているか否か、即ち、ソフ
トウェアの入れ替えが必要であるか否かを判断する(ス
テップS906)。
【0011】クライアントは、クライアントのソフトウ
ェアのバージョンがバージョン管理サーバで管理されて
いるバージョンと一致して、クライアントのソフトウェ
アの入れ替えが必要でないと判断すると(ステップS9
06)、そのまま処理を終了する。一方、クライアント
は、クライアントのソフトウェアのバージョンがバージ
ョン管理サーバで管理されているバージョンと一致せ
ず、クライアントのソフトウェアの入れ替えが必要であ
ると判断すると(ステップS906)、ソフトウェア入
れ替え用ファイルの配信をソフトウェア配布サーバへ要
求する(ステップS907)。
【0012】ソフトウェア配布サーバは、クライアント
からのソフトウェア配信要求に従ったスケジュール情報
を設定し(ステップS908)、設定したスケジュール
情報を基に、配信要求元のクライアントへソフトウェア
入れ替え用ファイルを配信する(ステップS909)。
この時、設定したスケジュール情報のソフトウェアの入
れ替え時間などの情報もクライアントへ送信される。
【0013】クライアントは、ソフトウェア配布サーバ
から配信されたソフトウェア入れ替え用ファイルを受信
すると(ステップS910)、受信したスケジュール情
報の入れ替え時間などの情報に従って、ソフトウェア入
れ替え処理を実施する(ステップS911)。
【0014】この従来のソフトウェアのバージョン管理
方式では、定期的にクライアント側からバージョン管理
サーバへソフトウェアのバージョンチェックを要求し、
クライアントのバージョンがバージョン管理サーバのバ
ージョンと一致していないと、クライアントがソフトウ
ェア配布サーバから入れ替え処理用のソフトウェアを貰
ってソフトウェアの入れ替え処理を行なうものである。
【0015】
【発明が解決しようとする課題】上記した前者の従来の
ソフトウェアのバージョン管理方式では、配布サーバ側
で設定したスケジュール情報に従ってクライアントが定
期的にソフトウェアを入れ替えることができるととも
に、配布サーバからのソフトウェア配布を失敗した時や
クライアントがソフトウェアの入れ替えを失敗した時、
再度配布サーバからソフトウェアを配信してソフトウェ
アの入れ替え処理を行なうことができるが、クライアン
ト側へのソフトウェア配布完了前にクライアント・プロ
グラムが実行された際、サーバ・プログラムとの間での
バージョン一致は保証されておらず、また、バージョン
不一致検出時も、クライアントのソフトウェアの入れ替
え実施は、クライアント・プログラム起動のタイミング
では行なえない。このため、ソフトウェア実行時にバー
ジョン不一致による不整合が生じて、安定したシステム
動作を行ない難いという問題があった。
【0016】また、この前者の従来のソフトウェアのバ
ージョン管理方式では、ネットワークエラー等が生じた
時、配布サーバから入れ替え用のソフトウェアを貰えな
くなることがあるため、ソフトウェアの入れ替えを行な
えなくなることがあるという問題があった。
【0017】上記した後者のソフトウェアのバージョン
管理方式では、定期的にクライアント側からバージョン
管理サーバへソフトウェアのバージョンチェックを要求
し、クライアントのバージョンがバージョン管理サーバ
のバージョンと一致していない時、クライアントがソフ
トウェア配布サーバから入れ替え処理用のソフトウェア
を貰ってソフトウェアの入れ替え処理を行なうことがで
きるが、定期的にクライアントのソフトウェアのバージ
ョンチェックを行なっているのであって、クライアント
のソフトウェアを実行する時に、ソフトウェアの入れ替
えを必ずしも行なっているのではないため、クライアン
トのソフトウェアを実行する時に、常にバージョンを一
致させ難い。このため、ソフトウェア実行時にバージョ
ン不一致による不整合が生じて、安定したシステム動作
を行ない難いという問題があった。
【0018】また、この後者のソフトウェアのバージョ
ン管理方式では、バージョンチェックの方式についても
単純な一致検索を行なっており、異なるバージョン間で
互換性の保証されたソフトウェアの入れ替えや、複数の
バージョンの異なるクライアントアプリケーションとサ
ーバとの複雑な関係に対応することができていなかっ
た。
【0019】また、この後者のソフトウェアのバージョ
ン管理方式では、ネットワークエラー等が生じた時、配
布サーバから入れ替え用のソフトウェアを貰えなくなる
ことがあるため、ソフトウェアの入れ替えを行なえなく
なることがあるという問題があった。
【0020】そこで、本発明は、クライアントのソフト
ウェアを実行する時、実行するクライアントのソフトウ
ェアのバージョンを確実に合わせて、バージョン不一致
による不整合を起こらないようにして安定したシステム
動作を実現することができるとともに、ネットワークエ
ラーが生じても、バージョン不一致だったクライアント
のソフトウェアを確実に入れ替えることができるネット
ワークシステムのソフトウェア・バージョン管理方式を
提供することを目的とする。
【0021】
【課題を解決するための手段】請求項1記載の発明は、
クライアントとサーバがネットワークを介して接続され
たネットワークシステムのソフトウェア・バージョン管
理方式において、バージョンチェックに必要なクライア
ント・プログラムのバージョン情報を設定するバージョ
ン情報設定手段と、設定したバージョン情報をサーバへ
転送してクライアント・プログラムのバージョンチェッ
ク要求を行なうバージョンチェック要求手段とをクライ
アントに設け、クライアントから転送されるクライアン
ト・プログラムのバージョン情報を受信して、バージョ
ンチェック要求を受け付けるバージョンチェック要求受
け付け手段と、サーバ・プログラムのバージョン情報を
格納するバージョン情報格納手段と、受信したクライア
ント・プログラムのバージョン情報とバージョン情報格
納手段から読み出したサーバ・プログラムのバージョン
情報とを比較して、クライアント・プログラムとサーバ
・プログラムのバージョンチェックを行なうバージョン
チェック手段と、バージョンチェック結果をクライアン
トへ転送するバージョンチェック結果転送手段とをサー
バに設け、サーバから転送されるバージョンチェック結
果に基づいて、クライアント・プログラムのバージョン
がサーバ・プログラムのバージョンと一致していないか
を判断するバージョン不一致判断手段と、バージョンが
一致していないと判断した場合、バージョンが一致して
いないクライアント・プログラムをサーバ・プログラム
のバージョンと一致するように入れ替えるプログラム入
れ替え手段と、入れ替えたクライアント・プログラムを
実行するプログラム実行手段とをクライアントに設ける
ことを特徴とするものである。
【0022】請求項2記載の発明は、上記請求項1記載
の発明において、バージョンチェック要求を行なう前
に、バージョンチェックのタイミングを指定するタイミ
ング指定手段と、指定したバージョンチェックのタイミ
ングに達したかを判断するタイミング判断手段とをクラ
イアントに設け、前記バージョンチェック要求手段が、
指定したバージョンチェックのタイミングに達したと判
断した場合、設定したクライアント・プログラムのバー
ジョン情報をサーバへ転送してバージョンチェック要求
を行なうことをを特徴とするものである。
【0023】請求項3記載の発明は、上記請求項1,2
の何れかに記載の発明において、バージョンチェックを
行なう前に、バージョンチェックに用いるバージョンチ
ェック情報を設定するチェック情報設定手段をサーバに
設け、前記バージョンチェック手段が、設定したバージ
ョンチェック情報に基づいてバージョンチェックを行な
うことを特徴とするものである。
【0024】請求項4記載の発明は、上記請求項1,2
の何れかに記載の発明において、バージョンチェックを
行なう前に、バージョンチェック時のチェックロジック
を設定するロジック設定手段をサーバに設け、前記バー
ジョンチェック手段が、設定したチェックロジックに基
づいてバージョンチェックを行なうことを特徴とするも
のである。
【0025】請求項5記載の発明は、上記請求項1,2
記載の何れかに記載の発明において、バージョンチェッ
クを行なう前に、関連するソフトウェア間の依存関係を
設定する依存関係設定手段をサーバに設け、前記バージ
ョンチェック手段が、設定した関連するソフトウェア間
の依存関係に基づいてバージョンチェックを行なうこと
を特徴とするものである。
【0026】請求項6記載の発明は、上記請求項1〜5
の何れかに記載の発明において、クライアント・プログ
ラムを入れ替える前に、クライアント・プログラムを入
れ替えるタイミングを設定するタイミング設定手段と、
設定したクライアント・プログラムの入れ替えタイミン
グに達したかを判断するタイミング判断手段とをクライ
アントに設け、前記プログラム入れ替え手段が、設定し
たクライアント・プログラムの入れ替えタイミングに達
したと判断した場合、クライアント・プログラムを入れ
替えることを特徴とするものである。
【0027】請求項7記載の発明は、上記請求項1〜5
の何れかに記載の発明において、クライアント・プログ
ラムを入れ替える前に、クライアント・プログラムの入
れ替え条件を設定する入れ替え条件設定手段をクライア
ントに設け、前記プログラム入れ替え手段が、設定した
クライアント・プログラムの入れ替え条件に基づいてク
ライアント・プログラムを入れ替えることを特徴とする
ものである。
【0028】請求項8記載の発明は、上記請求項1〜5
の何れかに記載の発明において、クライアント・プログ
ラムを入れ替える前に、クライアント・プログラムの入
れ替え対象を選択する入れ替え対象選択手段をクライア
ントに設け、前記プログラム入れ替え手段が、選択した
クライアント・プログラムの入れ替え対象に基づいてク
ライアント・プログラムを入れ替えることを特徴とする
ものである。
【0029】
【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。 実施の形態1.図1は本発明に係る実施の形態1のネッ
トワークシステムのソフトウェア・バージョン管理方式
のシステム構成を示すブロック図である。ネットワーク
システムのマシン構成は、任意の台数のサーバ・マシン
1及びクライアント・マシン2からなり、各コンピュー
タは、LAN等の通信媒体3を介してネットワークに接
続されている。サーバ・マシン1は、アプリケーション
・プログラムのまとまりであるソフトウェア・パッケー
ジ4を格納するための磁気ディスク装置5と、バージョ
ン情報を管理するバージョン管理データベース6を格納
するための磁気ディスク装置7とを有する。
【0030】次に、ソフトウェア構成について説明す
る。まず、サーバ・マシン1側のバージョン管理に関す
るソフトウェアは、各ネットワーク上の各ソフトウェア
のバージョン情報を記録するバージョン管理データベー
ス6と、クライアント・マシン2によるバージョン・チ
ェック要求を受け付けるバージョン管理サーバ・プログ
ラム8と、バージョン・チェック方法に関して規定した
アクション記述ファイル9とから構成される。
【0031】クライアント・マシン2側のバージョン管
理に関するソフトウェアは、バージョン管理サーバ・プ
ログラム8に対するバージョン・チェック要求前後のソ
フトウェアの動作を規定するアクション記述ファイル1
1と、バージョン・チェック要求を発行するバージョン
管理クライアント・プログラム12とから構成される。
【0032】分散システム環境下で動作するアプリケー
ションは、アプリケーションクライアント・プログラム
13及びアプリケーションサーバ・プログラム14であ
る。クライアント・プログラム13の起動は、バージョ
ン管理クライアント・プログラム12を通して行なわれ
る。ソフトウェアの配布及びバージョンチェック後のソ
フトウェアの入れ替えは、サーバ・マシン1側の配信プ
ログラム16がソフトウェア・パッケージ4を、クライ
アント・マシン2側の配信プログラム217に送ること
により行なわれる。
【0033】次に、アクション記述ファイルの構成につ
いて説明する。図2は図1に示すクライアント・マシン
2上のアクション記述ファイル11の構成を示す図であ
る。クライアント・マシン2上のアクション記述ファイ
ル11には、バージョン・チェックを行なうタイミング
に関する記述211と、バージョン・チェックによりク
ライアント・プログラムとサーバ・プログラムの間でバ
ージョンが異なっていることが判った後のソフトウェア
入れ替え方法に関する記述212を行なう。ソフトウェ
ア入れ替え方法としては、ソフトウェアをいつ入れ替え
るか、どのソフトウェアを入れ替えるか等の情報が定義
されている。
【0034】次に、図3は図1に示すサーバ・マシン1
上のアクション記述ファイル9の構成を示す図である。
サーバ・マシン1上のアクション記述ファイル9には、
ソフトウェアのバージョン・チェック方法に関する記述
411を行なう。クライアント側/サーバ側何れのアク
ション記述ファイル9,11とも、“Product”
221、321及び“Program”222、322
というタグ名を有する。
【0035】“Program”は、個々のアプリケー
ション・プログラムを意味し、“Program”に引
続き該当するプログラム名を記述する。“Produc
t”は、プログラムの集まりを意味し、このプログラム
の集まりは、通常、業務単位に設定されるものであり、
“Product”に引続きプロダクト名を記述する。
個々の“Product”タグ内には、複数の“Pro
gram”タグを記述することができる。これは、“P
roduct”に含まれるアプリケーション・プログラ
ム毎に、固有のバージョン・チェック方法を提供するた
めのものである。
【0036】クライアント・マシン2側のアクション記
述ファイル11の構成は、該当するプロダクトに関して
バージョンチェック前の条件及び不一致検出後の処理に
関するデフォルトの動作を規定する部分213と、ある
プロダクト中に含まれるプログラムのうちデフォルトの
対処方法を用いないものに関する記述を行なう部分21
4とからなる。
【0037】サーバ・マシン1側のアクション記述ファ
イル11の構成は、該当するプロダクトに関して、バー
ジョン不一致のチェック及びその後の動作に関するデフ
ォルトの動作を規定する部分311と、あるプロダクト
中に含まれるプログラムのうちデフォルトのチェック方
法を用いないものに関する記述を行なう部分312とか
らなる。本発明によるバージョン管理方法は、プロダク
ト/プログラム何れの単位での管理とも可能である。
【0038】次に、図4は本発明に係る実施の形態1の
ネットワークシステムのソフトウェア・バージョン管理
方式におけるシステム動作フローを示すフローチャート
である。サーバ・マシン1側のバージョン管理サーバ・
プログラム8は、任意のタイミングでクライアント・マ
シン2からのバージョンチェック要求を受け付けるため
に常に動作し、クライアント・マシン2からのバージョ
ンチェック要求を待つ。クライアント・プログラム13
の起動は、バージョン管理クライアント・プログラム1
2を通して行なわれる。
【0039】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、起動されると、ま
ず、アクション記述ファイル11を読み込む(ステップ
S1)。バージョン管理クライアント・プログラム12
は、アクション記述ファイル11を読み込んだ結果、ア
プリケーション実行のためのバージョンチェックが必要
であると判断した場合(ステップS2)、自プログラム
のバージョン番号、アプリケーション名、プロダクト名
等のバージョンチェックに必要なバージョン情報を設定
し、設定したバージョン情報をサーバ・マシン1のバー
ジョン管理サーバ・プログラム8へを転送して、バージ
ョンチェック要求を行なう(ステップS3)。
【0040】サーバ・マシン1のバージョン管理サーバ
・プログラム8は、クライアント・マシン2から転送さ
れるバージョン情報を受信して、バージョン・チェック
要求を受け付けると(ステップS4)、サーバ・マシン
1上のアクション記述ファイル9を読み込む(ステップ
S5)。そして、バージョン管理サーバ・プログラム8
は、アクション記述ファイル9内に記述されたチェック
方法に従い、クライアント・プログラム13とサーバ・
プログラム14間のバージョン・チェック処理を行ない
(ステップS6)、クライアント・プログラム13とサ
ーバ・プログラム14が同一バージョンであるか否かの
バージョンチェック結果を、バージョンチェック要求元
のクライアント・マシン2のバージョン管理クライアン
ト・プログラム12へ返す(ステップS7)。
【0041】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、サーバ・マシン1か
ら転送されるバージョンチェック結果を受信し(ステッ
プS8)、クライアント・プログラムとサーバ・プログ
ラムのバージョンが一致である旨のバージョンチェック
結果の通知を受けた場合(ステップS9)、引続きアプ
リケーションクライアント・プログラム13を起動する
(ステップS10)。
【0042】一方、クライアント・マシン2のバージョ
ン管理クライアント・プログラム12は、クライアント
・プログラム13とサーバ・プログラム14のバージョ
ンが一致していないと判断した場合(ステップS9)、
直ちにソフトウェアの入れ替えを実施するか否かを判断
する(ステップS11)。クライアント・マシン2のバ
ージョン管理クライアント・プログラム12は、直ちに
ソフトウェアの入れ替えを実施すると判断した場合(ス
テップS11)、アクション記述ファイル11に従った
ソフトウェアの入れ替えを実施し(ステップS12)、
アプリケーションクライアント・プログラム13を起動
する(ステップS13)。
【0043】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、直ちにソフトウェア
の入れ替えを実施しないと判断した場合(ステップS1
1)、クライアント・プログラム13の起動を実施する
か否かを判断する(ステップS14)。クライアント・
マシン2のバージョン管理クライアント・プログラム1
2は、クライアント・プログラム13の起動を実施する
と判断した場合(ステップS14)、クライアント・プ
ログラム13の起動を実施し(ステップS15)、アク
ション記述ファイル11に従ったソフトウェア入れ替え
を指示する(ステップS16)。
【0044】このように、本実施の形態では、クライア
ント・マシン2側で、バージョンチェックに必要なクラ
イアント・プログラム13のバージョン情報を設定し、
設定したバージョン情報をサーバ・マシン1へ転送して
バージョンチェック要求を行ない、サーバ・マシン1側
で、クライアント・マシン2から転送されるクライアン
ト・プログラム13のバージョン情報を受信してバージ
ョンチェック要求を受け付け、受信したクライアント・
プログラム13のバージョン情報とバージョン管理デー
タベース6から読み出したサーバ・プログラム14のバ
ージョンチェックを行なった後、そのバージョンチェッ
ク結果をクライアント・マシン2へ転送するように構成
している。更に、本実施の形態では、クライアント・マ
シン2側で、サーバ・マシン1から転送されるバージョ
ンチェック結果に基づいて、クライアント・プログラム
13とサーバ・プログラム14のバージョンが一致して
いないかを判断し、一致していないと判断した場合、バ
ージョンが一致していないクライアント・プログラム1
3をサーバ・プログラム14のバージョンと一致するよ
うに入れ替え、入れ替えたクライアント・プログラム1
3を実行するように構成している。このため、クライア
ント・プログラム13を実行する時、実行するクライア
ント・プログラム13のバージョンをサーバ・プログラ
ム14のバージョンと確実に合わせることができるの
で、クライアント・プログラム13実行時にバージョン
不一致による不整合を起こらないようにすることがで
き、安定したシステム動作を行なうことができる。従っ
て、常にバージョンの一致した環境での処理を保証する
ことができる。
【0045】また、本実施の形態では、クライアント・
マシン2側でバージョン不一致だったクライアント・プ
ログラム13を入れ替えるように構成したため、従来の
配布サーバからソフトウェアを貰って入れ替える場合よ
りも、ネットワークエラーが生じても確実にクライアン
ト・プログラム13を入れ替えることができる。
【0046】実施の形態2.本実施の形態は、請求項2
の発明に係る特徴部分のみ説明し、図1,4を参照して
説明する。上記実施の形態1では、クライアント・マシ
ン2側でクライアント・プログラム13のバージョン情
報を設定した後、直ちに設定したバージョン情報をサー
バ・マシン1へ転送してバージョンチェック要求を行な
う場合を説明したが、本実施の形態では、クライアント
・マシン2のアクション記述ファイル11にバージョン
チェックのタイミングを指定しておき、バージョン管理
クライアント・プログラム12により、指定したバージ
ョンチェックのタイミングに達したと判断した場合、設
定したクライアント・プログラム13のバージョン情報
をサーバ・マシン1へ転送してバージョンチェック要求
を行なうように構成する。この場合、指定したタイミン
グでバージョンチェックを行なうことができるので、バ
ージョンチェックを効率よく行なうことができる。以
下、具体的に図面を用いて説明する。
【0047】図5は本発明に係る実施の形態2の図1に
示すアクション記述ファイル11におけるバージョンチ
ェックタイミング設定に関する記述例を示す図である。
アプリケーション実行環境において、クライアント/サ
ーバ間でソフトウェアのバージョンが一致しているか否
かを確実にチェックするためには、アプリケーションの
起動のタイミングでバージョンのチェックを行なえばよ
い。
【0048】しかしながら、アプリケーションによって
は、常に、バージョンのチェックを行なう必要がないこ
とも多い。本実施の形態では、このアプリケーション起
動時のバージョン・チェック処理を実施するタイミング
について、アクション記述ファイル11に従って行なう
ことを特徴としている。アクション記述ファイル11に
は、プログラム起動毎(every)/1日の最初の一
回(1st)/チェック未実施(none)の何れかの
指定を行なう。
【0049】このアクション記述ファイル11のアプリ
ケーション2(app.2)に関しては、プログラム起
動毎にチェックを実施する設定502であり、アプリケ
ーション1(app.1)に関しては、一日の内で最初
の一回目だけチェックを実施する設定501である。こ
の設定の行なわれた状態でのバージョン管理クライアン
ト・プログラム13の動作を、図4のフローチャートを
基に説明する。
【0050】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、その起動時に、アク
ション記述ファイル11を読み込み、バージョンチェッ
クを実施するかの情報を、Checkフィールドより得
る。その結果、バージョン管理クライアント・プログラ
ム12は、例えば、図5のアクション記述ファイル11
の設定で、app.2を起動した時のように、バージョ
ンチェックの実施が必要であると判断した場合(ステッ
プS2)、設定したクライアント・プログラムのバージ
ョン情報をサーバ・マシン1のバージョン管理サーバ・
プログラム8へ転送して、バージョンチェック要求を行
なう(ステップS3)。
【0051】一方、クライアント・マシン2のバージョ
ン管理クライアント・プログラム12は、例えば図5の
設定で、app.1を連続して何回か起動した時の2回
目以降の起動時のようにバージョンチェックを行なう必
要がないと判断した場合(ステップS2)、サーバ・マ
シン1のバージョン管理サーバ・プログラム8へのバー
ジョンチェック要求は発行せず、クライアント・プログ
ラム13の起動を行なう(ステップS10)。
【0052】このように、本実施の形態では、クライア
ント・マシン1のアクション記述ファイル11にバージ
ョンチェックのタイミングを指定しておき、バージョン
管理クライアント・プログラム12により、指定したバ
ージョンチェックのタイミングに達したと判断した場
合、設定したクライアント・プログラムのバージョン情
報をサーバ・マシン1へ転送してバージョンチェック要
求を行なうように構成することにより、指定したタイミ
ングでバージョンチェックを行なうことができるので、
バージョンチェックを効率よく行なうことができる。例
えば、アプリケーション起動の度にバージョンチェック
の実施やソフトウェアのダウンロードを行なわないで済
ませることができる。このため、システムの運用上不必
要なバージョンチェックを行なわないで済ませることが
できるので、性能の劣化や不用意な負荷の増大を防ぐこ
とができる。
【0053】実施の形態3.本実施の形態は、請求項3
の発明に係る特徴部分のみを説明し、図1,4,6を参
照して説明する。上記実施の形態1では、バージョン管
理サーバ・プログラム8により、クライアント・マシン
2からバージョンチェック要求を受け付けると、受信し
たクライアント・プログラムのバージョン情報とバージ
ョン管理データベース6から読み出したサーバ・プログ
ラムのバージョン情報とを比較してバージョンチェック
を行なう場合を説明したが、本実施の形態では、バージ
ョンチェックを行なう前に、サーバ・マシン1のアクシ
ョン記述ファイル9にバージョンチェックに用いるバー
ジョンチェック情報を設定しておき、バージョン管理サ
ーバ・プログラム8により、アクション記述ファイル9
から読み出したバージョンチェック情報に基づいてバー
ジョンチェックを行なう(ステップS5、S6)ように
構成する。この場合、設定したバージョンチェック情報
に基づいてバージョンチェックを行なうことができるの
で、ソフトウェアに合わせた柔軟なバージョン解釈方法
を指定することができる。以下、具体的に図面を用いて
説明する。
【0054】図6は本発明に係る実施の形態3の図1に
示すアクション記述ファイル9の内容を示す図である。
ソフトウェアのバージョンをチェックする際、チェック
の基準となる情報としては大きく、このチェック基準と
なる情報には、ファイルの作成日付(“date”)、
ファイル名(例えば、バージョンを含んだプロダクト名
の場合)、ファイルやモジュール中に埋め込まれたバー
ジョン情報(“revision”)、そして、バージ
ョン管理データベース6への登録内容(“confi
g”)、例えば、プロダクトやアプリケーション群をま
とめて版管理する場合)等が挙げられる。
【0055】しかしながら、バージョンチェックの基準
となる情報は多いものの、それらを結合してバージョン
チェックを行なうのは困難である。本実施の形態は、
“Information”フィールド611,616
にファイル作成日付(“date”)/ソフトウェアに
埋め込まれた版情報(“revision”)/バージ
ョン管理データベース6の登録内容(“confi
g”)の何れかを記述することにより、バージョンチェ
ックに用いる情報を設定する。
【0056】例えば、図6では、プロダクトPRO1に
関して、Informationフィールドに“con
fig”が記述されていることから、バージョン管理デ
ータベース6を基にしたバージョン・チェックを優先す
ることになる。バージョン管理サーバ・プログラム8
は、このInformationに記述の情報を基に、
バージョンの比較を行なう。図6の例の場合、例えばク
ライアント・プログラム13とサーバ・プログラム14
のモジュールの中に含まれたバージョン(revisi
on)に相違があっても、バージョン管理データベース
6の登録内容に相違がなければ、クライアント・プログ
ラム13とサーバ・プログラム14間にバージョンの相
違はないものと判断される。
【0057】このように、本実施の形態では、バージョ
ンチェックを行なう前に、サーバ・マシン1のアクショ
ン記述ファイル9にバージョンチェックに用いるバージ
ョンチェック情報を設定しておき、バージョン管理サー
バ・プログラム8により、この設定したバージョンチェ
ック情報に基づいてバージョンチェックを行なうように
構成することにより、設定したバージョンチェック情報
に基づいてバージョンチェックを行なうことができるの
で、ソフトウェアに合わせた柔軟なバージョン解釈方法
を指定することができる。このため、ソフトウェアによ
って異なるバージョン情報に対応することができるの
で、効率の良いシステム運用を実現することができる。
【0058】実施の形態4.本実施の形態は、請求項4
の発明に係る特徴部分のみを説明し、図1,4,6を参
照して説明する。上記実施の形態1では、バージョン管
理サーバ・プログラム8により、クライアント・マシン
2からバージョンチェック要求を受け付けると、受信し
たクライアント・プログラムのバージョン情報とバージ
ョン管理データベース6から読み出したサーバ・プログ
ラムのバージョン情報とを比較してバージョンチェック
を行なう場合を説明したが、本実施の形態では、バージ
ョンチェックを行なう前に、アクション記述ファイル9
にバージョンチェック時のチェックロジック情報を設定
しておき、バージョン管理サーバ・プログラム8によ
り、アクション記述ファイル9から読み出したチェック
ロジック情報に基づいてバージョンチェックを行なう
(ステップS5、S6)ように構成する。この場合、設
定したチェックロジック情報に基づいてバージョンチェ
ックを行なうことができるので、ソフトウェアに合わせ
た柔軟なバージョン解釈方法を指定することができる。
【0059】本実施の形態は、バージョン・チェックの
アルゴリズムに関するものである。実際のシステムで
は、ネットワーク環境内に分散したクライアント/サー
バ型アプリケーションのバージョンは、同一プロダクト
に関しては一致していることが望ましい。しかしなが
ら、実際のシステム環境では、サーバ・マシンにおける
24時間連続運転実施の場合等、容易にソフトウェアの
入れ替えを実施できない環境もある。こういった環境内
でクライアント/サーバ間のアプリケーションのバージ
ョンが異なってしまった場合、ソフトウェアの入れ替え
を極力少なくするために、バージョンの完全な一致はな
いものの、動作上問題が発生しないことが判っていれ
ば、バージョン一致とみなすことが望ましい。
【0060】本実施の形態では、サーバ・マシン1のア
クション記述ファイル9に“Algorithm”フィ
ールド611,616を設け、クライアント・プログラ
ム13とサーバ・プログラム14の間で、完全にバージ
ョンの一致が必要(“complete”)/特定の範
囲内のバージョンであればバージョンが一致したとみな
す(“range”)の何れかを記述することにより、
バージョンチェックの考え方(完全一致又は部分一致)
に関する設定を行なう。
【0061】このように、本実施の形態では、バージョ
ン管理サーバ・プログラム8により、アクション記述フ
ァイル9に設定したチェックロジック情報に基づいてバ
ージョンチェックを行なうように構成することにより、
ソフトウェアに合わせた柔軟なバージョン解釈方法を指
定することができる。このため、バージョンの異なるソ
フトウェアが混在する環境等、単純なバージョン比較の
みでは対応できない複雑な環境化においても、バージョ
ンチェック・アルゴリズムをカスタマイズすることによ
り、対応することができる。
【0062】実施の形態5.本実施の形態は、請求項5
の発明に係る特徴部分のみを説明し、図1,4,6を参
照して説明する。上記実施の形態1では、バージョン管
理サーバ・プログラム8により、クライアント・マシン
2からバージョンチェック要求を受け付けると、受信し
たクライアント・プログラム13のバージョン情報とバ
ージョン管理データベース6から読み出したサーバ・プ
ログラム14のバージョン情報とを比較してバージョン
チェックを行なう場合を説明したが、本実施の形態で
は、バージョンチェックを行なう前に、アクション記述
ファイル9に関連するソフトウェア間の依存関係情報を
設定しておき、バージョン管理サーバ・プログラム8に
より、アクション記述ファイル9から読み出した関連す
るソフトウェア間の依存関係情報に基づいてバージョン
チェックを行なう(ステップS5、S6)ように構成す
る。この場合、設定した関連するソフトウェア間の依存
関係情報に基づいてバージョンチェックを行なうことが
できるので、依存関係のあるソフトウェア全体のバージ
ョンチェックを一括して行なうことができる。
【0063】本実施の形態は、ソフトウェアの依存関係
を考慮したバージョン・チェック方法に関するものであ
る。分散システム環境内では、相互に依存関係にあるア
プリケーションが多く存在する。例えば、プロダクト1
に含まれるアプリケーションとして、クライアント・プ
ログラムclient1及びサーバ・プログラムser
ver2が存在し、プロダクト2に含まれるアプリケー
ションとして、クライアント・プログラムclient
2及びサーバ・プログラムserver2が存在した場
合を考える。
【0064】ここで、プロダクト2に含まれるアプリケ
ーション・プログラムだけが分散システム環境内に配信
された時、プロダクト1に含まれるクライアント・プロ
グラムclient1及びサーバ・プログラムserv
er1間のバージョンは、一致しているにも拘らず、ク
ライアント・プログラムclient1を実行すること
ができないか、若しくは、実行結果に誤りを生じるとい
った問題が発生することがある。これは、プロダクト1
内のソフトウェアがプロダクト2内の機能を使っている
ために発生するものである。
【0065】本実施の形態では、図6に示すように、ア
クション記述ファイル9にフィールド“depende
ncy”613,618を設け、プロダクトPRO1と
プロダクトPRO2間の依存関係情報を記述しておくこ
とにより、プロダクトPRO1中のSERVER1に対
する要求発行時、起動時のバージョンのチェックとし
て、プロダクトPRO1だけでなく、プロダクトPRO
2中のバージョンとの比較処理を行なうことにより、バ
ージョン一致をチェックする。
【0066】このように、本実施の形態では、バージョ
ン管理サーバ・プログラム8により、アクション記述フ
ァイル9に設定した関連するソフトウェア間の依存関係
情報に基づいてバージョンチェックを行なうように構成
することにより、管理単位を跨って依存関係を有するソ
フトウェアに対して、相互の依存関係を指定することが
できるので、効率の良いシステム運用を実現することが
できる。本実施の形態では、1つのソフトウェアを入れ
替える際、そのソフトウェアと依存関係にあるソフトウ
ェアを入れ替えることができるので、システム管理者の
負担を軽減することができる。
【0067】実施の形態6.本実施の形態は、請求項6
の発明に係る特徴部分のみを説明し、図1,4,7を参
照して説明する。上記実施の形態1では、バージョン管
理クライアント・プログラム12により、クライアント
・プログラム13とサーバ・プログラム14のバージョ
ンが一致していない時(ステップS9)、直ちにソフト
ウェアの入れ替えを実施すると判断した場合(ステップ
S11)、ソフトウェアの入れ替えを実施する場合を説
明したが、本実施の形態では、クライアント・プログラ
ム13を入れ替える前に、アクション記述ファイル11
にクライアント・プログラム13を入れ替えるタイミン
グを設定しておき、バージョン管理クライアント・プロ
グラム12により、設定したクライアント・プログラム
13の入れ替えタイミングに達した時(ステップS1
1)、クライアント・プログラム13を入れ替えるよう
に構成する。この場合、設定したクライアント・プログ
ラム13の入れ替えタイミングに達した時に、クライア
ント・プログラム13を入れ替えることができるので、
システム運用に合わせたソフトウェア入れ替えを実施す
ることができる。
【0068】本実施の形態は、バージョンチェック実施
の結果、クライアント・プログラム13のバージョン情
報とサーバ・プログラム14のバージョン情報に相違が
発生した場合のソフトウェア入れ替え方法に関する。バ
ージョンチェックの結果、分散システム環境においてア
プリケーションを動作させるための正しいバージョンで
ないことが判明した場合、通常はアプリケーションを入
れ替えることが望ましい。ここで、このアプリケーショ
ンの入れ替え作業は、クライアント・マシン2の台数が
多かったり、システムが動作中である場合には、特に困
難であり、システム環境に応じたソフトウェア入れ替え
方法により、バージョン不整合を解消することが望まし
い。
【0069】本実施の形態は、アクション記述ファイル
11の記述内容に従ったバージョンチェックに失敗時の
バージョン不一致となったソフトウェアの入れ替え方法
に関する。このアクション記述ファイル11の記述は、
図2の212部分に相当する。図7は図2に示す212
部分の具体的な記述例を示す図である。本実施の形態
は、バージョンチェックの結果、ソフトウェアの入れ替
えが必要と判断された際、実際のプログラムの入れ替え
作業を実施するタイミングを指定する手段を設けるもの
である。入れ替えタイミングとしては、バージョンチェ
ックによる不一致検出直後(“now”)、不一致検出
後もアプリケーションは動作しアプリケーション自身の
終了直後(“after”)、時刻指定による入れ替え
(“time”、業務終了時刻の入れ替え等)を設定す
ることができる。“now”、“after”、“ti
me”何れかの情報は、サーバ・マシン1のアクション
記述ファイル11の“When”フィールドに記述す
る。
【0070】図7のアクション記述ファイル11の記述
例におけるプログラムapp‐aに関しては、バージョ
ン不一致を検出した時点でアプリケーションの実際の処
理を行なわず即座に入れ替え711を行なうための設定
であり、プログラムapp‐bに関しては、深夜時間
(業務時間外)の入れ替え(717)を行なうための設
定である。図4,7を基に、動作を説明する。
【0071】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、起動されてバージョ
ンチェックの不一致を検出した際、図4のステップ9の
部分の処理で入れ替え条件を判断する。そして、バージ
ョン管理クライアント・プログラム12は、アクション
記述ファイル11の記述として、図7のプロダクトPR
O‐Xに属するようなすぐに入れ替えが必要な場合(ス
テップS11)、配信プログラムに対して、必要なソフ
トウェアの条件を通知し、クライアント・プログラム1
3のソフトウェアの入れ替えを行なう(ステップS1
2)。
【0072】クライアント・マシン2のバージョン管理
クライアント・プログラム12は、入れ替え環境を確認
した上で、入れ替えたクライアント・プログラム13の
アプリケーションを起動する(ステップS13)。一
方、バージョン管理クライアント・プログラム12は、
アクション記述ファイル11の記述として、図7のプロ
ダクトPRO‐Yに属するような業務時間外入れ替えが
指定された場合、バージョン管理クライアント・プログ
ラム12は、システムの提供するスケジュール機能等へ
必要なアプリケーション配布処理の登録を行なう(ステ
ップ16)。登録内容としては、配布時間、配布対象プ
ロダクトの指定が挙げられる。
【0073】このように、本実施の形態では、クライア
ント・プログラム13を入れ替える前に、アクション記
述ファイル11にクライアント・プログラム13を入れ
替えるタイミングを設定しておき、バージョン管理クラ
イアント・プログラム12により、設定したクライアン
ト・プログラム13の入れ替えタイミングに達した時
(ステップS11)、クライアント・プログラム13を
入れ替えるように構成したため、設定したクライアント
・プログラム13の入れ替えタイミングに達した時に、
クライアント・プログラム13を入れ替えることができ
るので、システム運用に合わせたソフトウェア入れ替え
を実施することができる。
【0074】本実施の形態では、例えば、今、ソフトウ
ェアを直ぐに入れ替えたいが入れ替えられない時、夜間
に入れ替えたり、一連の業務が終了した後に入れ替えた
りすることを、予め指定することができる。このため、
システム要件に合わせて柔軟にソフトウェアの入れ替え
スケジュールを設定することができるので、効率の良い
システム運用を実現することができる。
【0075】実施の形態7.本実施の形態は、請求項7
の発明に係る特徴部分のみを説明し、図1,4,7を参
照して説明する。上記実施の形態1では、バージョン管
理クライアント・プログラム12により、クライアント
・プログラム13とサーバ・プログラム14のバージョ
ンが一致していない時(ステップS9)、直ちにソフト
ウェアの入れ替えを実施すると判断した場合(ステップ
S11)、ソフトウェアの入れ替えを実施する場合を説
明したが、本実施の形態では、クライアント・プログラ
ム13を入れ替える前に、クライアント2のアクション
記述ファイル11にクライアント・プログラム13の入
れ替え条件を設定しておき、バージョン管理クライアン
ト・プログラム12により、設定したクライアント・プ
ログラム13の入れ替え条件を基にクライアント・プロ
グラム13を入れ替えるように構成する。この場合、設
定したクライアント・プログラム13の入れ替え条件を
基にクライアント・プログラム13を入れ替えることが
できるので、例えば、重要度の高いものはバージョンチ
ェックを頻繁に行なうといった、環境や業務内容に応じ
た柔軟なソフトウェア入れ替えを実現することができ
る。
【0076】本実施の形態は、バージョンチェックの結
果、クライアント・プログラム13の入れ替えが必要で
あると判断された際、事前に設定されたクライアント・
プログラム13の入れ替え条件に応じて入れ替えを行な
うものである。ソフトウェアの入れ替えを行なう際は通
常、入れ替え対象となるソフトウェアが動作状態では実
施できない。そこで、実システムにおいて業務実施中の
場合、この入れ替え作業を実施するのは、時間的に困難
な時もある。業務実施中か処何に関わらず、緊急に入れ
替えが必要なことも多い。それは例えば、頻繁に使用さ
れるソフトウェア、重要作業を行なうような特定の端
末、非常に重要な特定の業務といった条件があてはま
る。
【0077】本実施の形態では、クライアント・マシン
2のアクション記述ファイル11に“Whether”
フィールド712、717を設け、サーバ・マシン1の
バージョン管理サーバ・プログラム8からのバージョン
・チェック応答により、バージョンが不一致という通知
を受けた際も、アクション記述ファイル11の“Whe
ther”フィールドの内容に応じて、クライアント・
マシン2のバージョン管理クライアント・プログラム1
2は、不一致だったクライアント・プログラム12の入
れ替え処理を実施する(ステップS11,S12)。例
えば図7では、プロダクトPRO‐Xに関しては、バー
ジョン不一致回数(times)の情報を記述すること
により、同一アプリケーションについてN回以上のバー
ジョン相違が検出された時点で、クライアント・プログ
ラム13のソフトウェアの入れ替えを実施する。
【0078】このように、本実施の形態では、クライア
ント・プログラム13を入れ替える前に、クライアント
2のアクション記述ファイル11にクライアント・プロ
グラム13の入れ替え条件を設定しておき、バージョン
管理クライアント・プログラム12により、設定したク
ライアント・プログラム13の入れ替え条件を基にクラ
イアント・プログラム13を入れ替えるように構成した
ため、設定したクライアント・プログラム13の入れ替
え条件を基にクライアント・プログラム13を入れ替え
ることができる。このため、例えば、重要度の高いもの
はバージョンチェックを頻繁に行なうといった、環境や
業務内容に応じた柔軟なソフトウェア入れ替えを実現す
ることができる。
【0079】実施の形態8.本実施の形態は、請求項8
の発明に係る特徴部分のみを説明し、図1,4,7を参
照して説明する。上記実施の形態1では、バージョン管
理クライアント・プログラム12により、クライアント
・プログラム13とサーバ・プログラム14のバージョ
ンが一致していない時(ステップS9)、直ちにソフト
ウェアの入れ替えを実施すると判断した場合(ステップ
S11)、ソフトウェアの入れ替えを実施する(ステッ
プS12)場合を説明したが、本実施の形態は、バージ
ョン・チェックの結果、クライアント・プログラム13
の入れ替えが必要と判断された際、入れ替え対象のクラ
イアント・プログラム13を選択する手段を設けるもの
である。分散システム環境内の各クライアント・マシン
2でクライアント・プログラム13のバージョンの相違
が検出され、クライアント・プログラム13の入れ替え
が必要だと判断された際、クライアント・プログラム1
3の入れ替え作業に伴う稼動中の業務への影響を最小限
に抑えるためには、ある特定の業務を構成する全てのソ
フトウェア群を一括して入れ替えるのではなく、必要最
小限のアプリケーション・プログラムのみ入れ替えるこ
とが望ましい。
【0080】本実施の形態では、アクション記述ファイ
ル11に“What”フィールド713,718を設
け、マシン間でプロダクトの不一致が検出された際、該
当するプロダクトの中から“What”フィールドに記
述されたモジュール(実行形式のファイル)のみの入れ
替えを行なう。例えば、図7において、プロダクトPR
O‐Xが100個のモジュールより構成されていたと
し、バージョン不一致によるクライアント・プログラム
13の入れ替えが必要となった際、100個のモジュー
ル全てを入れ替えるのではなく、“What”フィール
ドに記述の3つのモジュール“prog_1”、“pr
og_2”、“prog_3”のみの入れ替えを実施す
る。
【0081】このように、本実施の形態では、クライア
ント・プログラム13を入れ替える前に、クライアント
・マシン2のアクション記述ファイル11に入れ替え対
象のクライアント・プログラム13を選択する条件を設
定しておき、バージョン管理クライアント・プログラム
12により、設定した入れ替え対象のクライアント・プ
ログラム13を基にクライアント・プログラム13を入
れ替えるように構成する。この場合、設定した入れ替え
対象のクライアント・プログラム13を基にクライアン
ト・プログラム13を入れ替えることができるので、関
連するクライアント・プログラム13を一括して入れ替
えるのではなく、モジュール単位で入れ替えを行なうこ
とができる。従って、システムや業務要件に合わせたモ
ジュール単位での入れ替えを行なうことができるので、
不要なモジュールの入れ替えを極力行なわない効率のよ
いシステム運用を実現することができる。
【0082】
【発明の効果】請求項1記載の発明によれば、クライア
ント側で、バージョンチェックに必要なクライアント・
プログラムのバージョン情報を設定し、設定したバージ
ョン情報をサーバへ転送してバージョンチェック要求を
行ない、サーバ側で、クライアントから転送されるクラ
イアント・プログラムのバージョン情報を受信してバー
ジョンチェック要求を受け付け、受信したクライアント
・プログラムのバージョン情報とバージョン管理データ
ベースから読み出したサーバ・プログラムのバージョン
チェックを行なった後、そのバージョンチェック結果を
クライアント・マシンへ転送するように構成し、更に、
クライアント側で、サーバから転送されるバージョンチ
ェック結果に基づいて、クライアント・プログラムとサ
ーバ・プログラムのバージョンが一致していないかを判
断し、一致していないと判断した場合、バージョンが一
致していないクライアント・プログラムをサーバ・プロ
グラムのバージョンと一致するように入れ替え、入れ替
えたクライアント・プログラムを実行するように構成し
たため、クライアント・プログラムを実行する時、実行
するクライアント・プログラムのバージョンをサーバ・
プログラムのバージョンと確実に合わせることができる
ので、クライアント・プログラム実行時にバージョン不
一致による不整合を起こらないようにすることができ、
安定したシステム動作を行なうことができる。従って、
常にバージョンの一致した環境での処理を保証すること
ができる。
【0083】また、請求項1記載の発明によれば、クラ
イアント側でバージョン不一致だったクライアント・プ
ログラムを入れ替えるように構成したため、従来の配布
サーバからソフトウェアを貰って入れ替える場合より
も、ネットワークエラーが生じても確実にクライアント
・プログラムを入れ替えることができる。
【0084】請求項2記載の発明によれば、クライアン
トにバージョンチェックのタイミングを指定しておき、
指定したバージョンチェックのタイミングに達したと判
断した場合、設定したクライアント・プログラムのバー
ジョン情報をサーバへ転送してバージョンチェック要求
を行なうように構成することにより、指定したタイミン
グでバージョンチェックを行なうことができるので、バ
ージョンチェックを効率よく行なうことができる。例え
ば、アプリケーション起動の度にバージョンチェックの
実施やソフトウェアのダウンロードを行なわないで済ま
せることができる。このため、システムの運用上不必要
なバージョンチェックを行なわないで済ませることがで
きるので、性能の劣化や不用意な負荷の増大を防ぐこと
ができる。
【0085】請求項3記載の発明によれば、バージョン
チェックを行なう前に、サーバにバージョンチェックに
用いるバージョンチェック情報を設定しておき、この設
定したバージョンチェック情報に基づいてバージョンチ
ェックを行なうように構成することにより、設定したバ
ージョンチェック情報に基づいてバージョンチェックを
行なうことができるので、ソフトウェアに合わせた柔軟
なバージョン解釈方法を指定することができる。このた
め、ソフトウェアによって異なるバージョン情報に対応
することができるので、効率の良いシステム運用を実現
することができる。
【0086】請求項4記載の発明によれば、サーバに設
定したチェックロジック情報に基づいてバージョンチェ
ックを行なうように構成することにより、ソフトウェア
に合わせた柔軟なバージョン解釈方法を指定することが
できる。このため、バージョンの異なるソフトウェアが
混在する環境等、単純なバージョン比較のみでは対応で
きない複雑な環境化においても、バージョンチェック・
アルゴリズムをカスタマイズすることにより、対応する
ことができる。
【0087】請求項5記載の発明によれば、サーバに設
定した関連するソフトウェア間の依存関係情報に基づい
てバージョンチェックを行なうように構成することによ
り、管理単位を跨って依存関係を有するソフトウェアに
対して、相互の依存関係を指定することができるので、
効率の良いシステム運用を実現することができる。例え
ば、1つのソフトウェアを入れ替える際、そのソフトウ
ェアと依存関係にあるソフトウェアを入れ替えることが
できるので、システム管理者の負担を軽減することがで
きる。
【0088】請求項6記載の発明によれば、クライアン
ト・プログラムを入れ替える前に、クライアントにクラ
イアント・プログラムを入れ替えるタイミングを設定し
ておき、設定したクライアント・プログラムの入れ替え
タイミングに達した時、クライアント・プログラムを入
れ替えるように構成したため、設定したクライアント・
プログラムの入れ替えタイミングに達した時に、クライ
アント・プログラムを入れ替えることができるので、シ
ステム運用に合わせたソフトウェア入れ替えを実施する
ことができる。
【0089】請求項7記載の発明によれば、クライアン
ト・プログラムを入れ替える前に、クライアントにクラ
イアント・プログラムの入れ替え条件を設定しておき、
設定したクライアント・プログラムの入れ替え条件を基
にクライアント・プログラムを入れ替えるように構成し
たため、設定したクライアント・プログラムの入れ替え
条件を基にクライアント・プログラムを入れ替えること
ができる。このため、例えば、重要度の高いものはバー
ジョンチェックを頻繁に行なうといった、環境や業務内
容に応じた柔軟なソフトウェア入れ替えを実現すること
ができる。
【0090】請求項8記載の発明によれば、クライアン
ト・プログラムを入れ替える前に、クライアントに入れ
替え対象のクライアント・プログラムを選択する条件を
設定しておき、設定した入れ替え対象のクライアント・
プログラムを基にクライアント・プログラムを入れ替え
るように構成したため、設定した入れ替え対象のクライ
アント・プログラムを基にクライアント・プログラムを
入れ替えることができるので、関連するクライアント・
プログラムを一括して入れ替えるのではなく、モジュー
ル単位で入れ替えを行なうことができる。従って、シス
テムや業務要件に合わせたモジュール単位での入れ替え
を行なうことができるので、不要なモジュールの入れ替
えを極力行なわない効率のよいシステム運用を実現する
ことができる。
【図面の簡単な説明】
【図1】 本発明に係る実施の形態1のネットワークシ
ステムのソフトウェア・バージョン管理方式のシステム
構成を示すブロック図である。
【図2】 図1に示すクライアント・マシン上のアクシ
ョン記述ファイルの構成を示す図である。
【図3】 図1に示すサーバ・マシン上のアクション記
述ファイルの構成を示す図である。
【図4】 本発明に係る実施の形態1のネットワークシ
ステムのソフトウェア・バージョン管理方式におけるシ
ステム動作フローを示すフローチャートである。
【図5】 本発明に係る実施の形態2のアクション記述
ファイルにおけるバージョンチェックタイミング設定に
関する記述例を示す図である。
【図6】 本発明に係る実施の形態3のアクション記述
ファイルの内容を示す図である。
【図7】 本発明に係る実施の形態6のアクション記述
ファイルの内容を示す図である。
【図8】 従来のソフトウェアのバージョン管理方式に
おけるシステム動作フローを示すフローチャートであ
る。
【図9】 従来のソフトウェアのバージョン管理方式に
おけるシステム動作フローを示すフローチャートであ
る。
【符号の説明】
1 サーバ・マシン、2 クライアント・マシン、3
通信媒体、4 ソフトウェア・パッケージ、5,7 磁
気ディスク装置、6 バージョン管理データベース、8
バージョン管理サーバ・プログラム、9,11 アク
ション記述ファイル、12 バージョン管理クライアン
ト・プログラム、13 クライアント・プログラム、1
4 サーバ・プログラム、16,17 配信プログラ
ム。
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平8−44544(JP,A) 特開 平4−347733(JP,A) 特開 平7−225724(JP,A) 特開 平6−290126(JP,A) 特開 平4−107741(JP,A) 特開 平6−67909(JP,A) 特開 平7−210430(JP,A) 特開 平9−138769(JP,A) (58)調査した分野(Int.Cl.7,DB名) G06F 9/06 - 9/445 G06F 13/00 G06F 15/00 - 15/177

Claims (8)

    (57)【特許請求の範囲】
  1. 【請求項1】 クライアントとサーバがネットワークを
    介して接続されたネットワークシステムのソフトウェア
    ・バージョン管理方式において、 バージョンチェックに必要なクライアント・プログラム
    のバージョン情報を設定するバージョン情報設定手段
    と、クライアントのアクション記述ファイルに記述され
    たバージョンチェックタイミングに基づいて、設定した
    バージョン情報をサーバへ転送してクライアント・プロ
    グラムのバージョンチェック要求を行なうバージョンチ
    ェック要求手段とをクライアントに設け、 クライアントから転送されるクライアント・プログラム
    のバージョン情報を受信して、バージョンチェック要求
    を受け付けるバージョンチェック要求受け付け手段と、
    サーバ・プログラムのバージョン情報を格納するバージ
    ョン情報格納手段と、サーバのアクション記述ファイル
    に記述されたバージョンチェック方法に基づいて 受信
    したクライアント・プログラムのバージョン情報とバー
    ジョン情報格納手段から読み出したサーバ・プログラム
    のバージョン情報とを比較して、クライアント・プログ
    ラムとサーバ・プログラムのバージョンチェックを行な
    うバージョンチェック手段と、バージョンチェック結果
    をクライアントへ転送するバージョンチェック結果転送
    手段とをサーバに設け、 サーバから転送されるバージョンチェック結果に基づい
    て、クライアント・プログラムのバージョンがサーバ・
    プログラムのバージョンと一致していないかを判断する
    バージョン不一致判断手段と、バージョンが一致してい
    ないと判断した場合、クライアントのアクション記述フ
    ァイルに記述されたプログラム入替え方法に基づいて、
    バージョンが一致していないクライアント・プログラム
    を入れ替えるプログラム入れ替え手段とをクライアント
    に設けることを特徴とするネットワークシステムのソフ
    トウェア・バージョン管理方式。
  2. 【請求項2】 バージョンチェック要求を行なう前に、
    クライアントのアクション記述ファイルにバージョンチ
    ェックのタイミングを指定するタイミング指定手段と、
    指定したバージョンチェックのタイミングに達したかを
    判断するタイミング判断手段とをクライアントに設け、
    前記バージョンチェック要求手段は、前記タイミング指
    定手段により指定したバージョンチェックのタイミング
    に達したと前記バージョンチェック要求手段が判断した
    場合、設定したクライアント・プログラムのバージョン
    情報をサーバへ転送してバージョンチェック要求を行な
    うことを特徴とする請求項1に記載のネットワークシス
    テムのソフトウェア・バージョン管理方式。
  3. 【請求項3】 バージョンチェックを行なう前に、サー
    バのアクション記述ファイルにバージョンチェックに用
    いるバージョンチェック情報を設定するチェック情報設
    定手段をサーバに設け、前記バージョンチェック手段
    は、設定したバージョンチェック情報に基づいてバージ
    ョンチェックを行なうことを特徴とする請求項1,2の
    何れかに記載のネットワークシステムのソフトウェア・
    バージョン管理方式。
  4. 【請求項4】 バージョンチェックを行なう前に、サー
    バのアクション記述ファイルにバージョンチェック時の
    チェックロジックを設定するロジック設定手段をサーバ
    に設け、前記バージョンチェック手段は、設定したチェ
    ックロジックに基づいてバージョンチェックを行なうこ
    とを特徴とする請求項1,2の何れかに記載のネットワ
    ークシステムのソフトウェア・バージョン管理方式。
  5. 【請求項5】 バージョンチェックを行なう前に、サー
    バのアクション記述ファイルに関連するソフトウェア間
    の依存関係を設定する依存関係設定手段をサーバに設
    け、前記バージョンチェック手段は、設定した関連する
    ソフトウェア間の依存関係に基づいてバージョンチェッ
    クを行なうことを特徴とする請求項1,2の何れかに記
    載のネットワークシステムのソフトウェア・バージョン
    管理方式。
  6. 【請求項6】 クライアント・プログラムを入れ替える
    前に、クライアントのアクション記述ファイルにクライ
    アント・プログラムを入れ替えるタイミングを設定する
    タイミング設定手段と、設定したクライアント・プログ
    ラムの入れ替えタイミングに達したかを判断するタイミ
    ング判断手段とをクライアントに設け、前記プログラム
    入れ替え手段は、設定したクライアント・プログラムの
    入れ替えタイミングに達したと判断した場合、クライア
    ント・プログラムを入れ替えることを特徴とする請求項
    1〜5の何れかに記載のネットワークシステムのソフト
    ウェア・バージョン管理方式。
  7. 【請求項7】 クライアント・プログラムを入れ替える
    前に、クライアントのアクション記述ファイルにクライ
    アント・プログラムの入れ替え条件を設定する入れ替え
    条件設定手段をクライアントに設け、前記プログラム入
    れ替え手段は、設定したクライアント・プログラムの入
    れ替え条件に基づいてクライアント・プログラムを入れ
    替えることを特徴とする請求項1〜5の何れかに記載の
    ネットワークシステムのソフトウェア・バージョン管理
    方式。
  8. 【請求項8】 クライアント・プログラムを入れ替える
    前に、クライアントのアクション記述ファイルに入れ替
    え対象のクライアント・プログラムを選択する条件を設
    定する入れ替え対象設定手段をクライアントに設け、前
    記プログラム入れ替え手段は、設定した入れ替え対象の
    クライアント・プログラムに基づいてクライアント
    ログラムを入れ替えることを特徴とする請求項1〜5の
    何れかに記載のネットワークシステムのソフトウェア・
    バージョン管理方式。
JP08172271A 1996-07-02 1996-07-02 ネットワークシステムのソフトウェア・バージョン管理方式 Expired - Fee Related JP3119166B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP08172271A JP3119166B2 (ja) 1996-07-02 1996-07-02 ネットワークシステムのソフトウェア・バージョン管理方式

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP08172271A JP3119166B2 (ja) 1996-07-02 1996-07-02 ネットワークシステムのソフトウェア・バージョン管理方式

Publications (2)

Publication Number Publication Date
JPH1021059A JPH1021059A (ja) 1998-01-23
JP3119166B2 true JP3119166B2 (ja) 2000-12-18

Family

ID=15938822

Family Applications (1)

Application Number Title Priority Date Filing Date
JP08172271A Expired - Fee Related JP3119166B2 (ja) 1996-07-02 1996-07-02 ネットワークシステムのソフトウェア・バージョン管理方式

Country Status (1)

Country Link
JP (1) JP3119166B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11312154A (ja) 1998-04-28 1999-11-09 Nec Corp 協同作業支援システム及び記録媒体
JP3578266B2 (ja) * 2000-01-06 2004-10-20 インターナショナル・ビジネス・マシーンズ・コーポレーション アプリケーションの起動方法、アプリケーションの起動のためのソフトウエア・プロダクト
KR20020005801A (ko) * 2000-07-10 2002-01-18 윤종용 통합 버전 관리 방법
JPWO2002075525A1 (ja) * 2001-03-19 2004-07-08 ソニー株式会社 ソフトウエア更新システム、ソフトウエア更新方法、およびソフトウエア更新プログラム
JP3915661B2 (ja) 2002-10-31 2007-05-16 ソニー株式会社 ソフトウエア更新システム、情報処理装置および方法、記録媒体、並びにプログラム
JP2004152191A (ja) 2002-10-31 2004-05-27 Sony Corp ソフトウエア更新システム、情報処理装置および方法、記録媒体、並びにプログラム
CN110442366B (zh) * 2019-08-09 2021-06-15 广州视源电子科技股份有限公司 一种传屏处理方法、装置、设备和存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04107741A (ja) * 1990-08-29 1992-04-09 Mitsubishi Electric Corp Rpcにおけるサービスプロシージャの外出し方式
JPH04347733A (ja) * 1991-05-24 1992-12-02 Hitachi Ltd 計算機プログラム保守方式
JPH0667909A (ja) * 1992-08-18 1994-03-11 Mitsubishi Electric Corp 障害回復方式
JPH06290126A (ja) * 1993-04-06 1994-10-18 Mitsubishi Electric Corp 計算機システム障害監視方式
JPH07210430A (ja) * 1994-01-26 1995-08-11 Mitsubishi Electric Corp 分散ファイルのバックアップ装置
JP3167522B2 (ja) * 1994-02-08 2001-05-21 富士通株式会社 ソフトウェア遠隔自動更新システムおよび方法
JPH0844544A (ja) * 1994-07-30 1996-02-16 Nec Corp 分散トランザクションシステムの実行モジュール管理方式
JPH09138769A (ja) * 1995-11-14 1997-05-27 Mitsubishi Electric Corp ソフトウェア配布システム及びソフトウェア配布方法

Also Published As

Publication number Publication date
JPH1021059A (ja) 1998-01-23

Similar Documents

Publication Publication Date Title
US7085819B2 (en) System and method for distributed network data storage
US6311232B1 (en) Method and apparatus for configuring storage devices
US5996086A (en) Context-based failover architecture for redundant servers
CN109344000B (zh) 区块链网络服务平台、恢复工具及其故障处理方法、存储介质
US20080222160A1 (en) Method and system for providing a program for execution without requiring installation
US7673023B1 (en) Method and apparatus for service processor updates
US20080244552A1 (en) Upgrading services associated with high availability systems
US20040083358A1 (en) Reboot manager usable to change firmware in a high availability single processor system
JPH0683746A (ja) 分散情報処理システム
US20070266120A1 (en) System and method for handling instructions in a pre-boot execution environment
JP2005084963A (ja) ファイル共有装置及びファイル共有装置間のデータ移行方法
JP2008123412A (ja) 計算機システム、システムソフトウェア更新方法及び第1サーバ装置
US6832379B1 (en) Computer architecture utilizing layered device drivers
JPH10301760A (ja) ソフトウェア自動配布管理システム及び方法
JP3737810B2 (ja) 計算機システム及び故障計算機代替制御プログラム
JP3119166B2 (ja) ネットワークシステムのソフトウェア・バージョン管理方式
US20030145061A1 (en) Server management system
JP3765201B2 (ja) 計算機システム
AU765501B2 (en) Highly available cluster virtual disk system
US7043726B2 (en) Binding of processes in network systems
CN112860787A (zh) 分布式主从***中主节点的切换方法、主节点设备和存储介质
JPH10320184A (ja) ソフトウェアバージョン管理システム
JP2000112906A (ja) クラスタシステム
JP2669537B2 (ja) オフィスオートメーション装置
JP2002236605A (ja) データバックアップシステム

Legal Events

Date Code Title Description
LAPS Cancellation because of no payment of annual fees