JP2000112766A

JP2000112766A - ソフトウェア配布システム

Info

Publication number: JP2000112766A
Application number: JP10283702A
Authority: JP
Inventors: Susumu Ikeda; 享池田
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1998-10-06
Filing date: 1998-10-06
Publication date: 2000-04-21

Abstract

(57)【要約】【課題】クライアント／サーバアプリケーションのフ
ァイル配布を統合的に管理できるソフトウェア配布シス
テムを提供すること。【解決手段】ソフトウェア配布サーバマシン１０１の
マネージャ機能１０５からPCクライアントマシン１０４
にファイルの配布時に、マネージャ機能１０５で配布フ
ァイル情報の登録と、配布ファイルの動作に必要な他の
アプリケーション番号のバージョン番号を登録し、配布
ファイルをPCクライアントマシン１０４のエージェント
機能１０６に送信する。エージェント機能１０６で、フ
ァイルとコマンドを受信し、コマンドの、実行結果をマ
ネージャ機能１０５に返信し、実行結果が正常の場合
に、マネージャ機能１０５が現在のバージョンの情報を
更新する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、UNIXマシンおよ
びPC（パーソナルコンピュータ）により構成されるクラ
イアント／サーバシステムにおいて、UNIXサーバアプリ
ケーション、UNIXクライアントアプリケーションおよび
PCクライアントアプリケーションのバージョン管理・フ
ァイル配布をUNIXサーバで統合的に管理できるソフトウ
ェア配布システムに関する。

【０００２】

【従来の技術】最近のアプリケーションは、LANの普
及、データベースアクセスツールなどの充実により、サ
ーバクライアント方式による分散アプリケーションシス
テムの構築が普及してきている。サーバクライアント方
式で、システムを構築した場合に、サーバアプリケーシ
ョンとクライアントアプリケーション間でバージョンの
整合性を取る必要がある。

【０００３】そこで、従来、アプリケーション管理装置
によりクライアントアプリケーションは、サーバアプリ
ケーション装置からバージョン不一致電文を検出した場
合には、アプリケーション使用者に対してバージョンの
不一致を通知し、アプリケーションサービスを終了する
ようにしている。しかし、この場合、アプリケーション
起動後、サーバアプリケーションとクライアントアプリ
ケーション間の電文により、バージョン情報の確認処理
を実施するようにしており、アプリケーションを起動し
なければ、バージョンの確認ができないという課題があ
る。

【０００４】これを解決するために、たとえば、特開平
０７−１２９３７３号公報には、サーバアプリケーショ
ンバージョン管理装置がクライアントアプリケーション
バージョン管理装置からのバージョン検査依頼に対して
アプリケーション作成日付でバージョンの検査を実施
し、バージョン不一致検出時にサーバシステムからクラ
イアントシステムへ最新バージョンのアプリケーション
を自動的にダウンロードすることにより、クライアント
システムは常に最新のアプリケーションを保持すること
が開示されている。

【０００５】ところで、このようなアプリケーションバ
ージョン管理装置の範疇に属する従来のソフトウェア配
布システムにおいては、配布の設定は配布対象のファイ
ル単位、もしくは幾つかのファイルを束ねたファイルセ
ット単位で行っていた。したがって、配布ファイルのバ
ージョン管理もそのファイル（もしくはファイルセッ
ト）ごとに管理を行っていた。たとえば、アプリケーシ
ョンのバージョンアップ時にサーバアプリケーション、
UNIX用クライアントアプリケーション、PC用クライアン
トアプリケーションを配布しなければならない場合を考
えると、従来の方法では下記の（１）〜（３）に挙げる
ような手順になる。

【０００６】（１）．サーバアプリケーションのファイ
ルを配布登録する（この際、サーバアプリケーションの
バージョン・配布時期を設定する）。（２）．UNIX用クライアントアプリケーションのファイ
ルを配布登録する（この際、UNIXクライアントアプリケ
ーションのバージョン・配布時期を設定する）。（３）．PC用クライアントアプリケーションのファイル
を配布登録する（この際、PCクライアントアプリケーシ
ョンのバージョン・配布時期を設定する）。上記（１），（２），（３）で登録する際のバージョン
・配布時期には相互に依存性はなく、設定者が自由に設
定することができた。

【０００７】

【発明が解決しようとする課題】しかし、この従来技術
には、次のような課題があった。第１の課題は、サーバ
アプリケーションとクライアントアプリケーションの統
合的なバージョン管理ができないということである。そ
の理由は、それぞれ別々のファイルとして依存性なく配
布設定するために、配布システムはサーバアプリケーシ
ョンのバージョンとクライアントアプリケーションのバ
ージョンの整合性について何ら管理しないためである。

【０００８】第２の課題は、配布時期を合わせるために
人的作業が必要ということである。その理由は、配布時
期も各々別々に設定を行うためである。一見、この作業
は何でもないように思われるが、配布した新しいサーバ
アプリケーションにトラブルがあり、一つ前のバージョ
ンに戻すときなどには、クライアントアプリケーション
の戻しも同時に行われるように人間が忘れずに設定しな
ければならなかった。

【０００９】そこで、サーバ／クライアントアプリケー
ションが同時に配布されるように自動的に設定でき、一
方のバージョンダウン時にも自動的にもう一方に整合性
をとったバージョンが配布されるような、統合的にバー
ジョン管理が可能なソフトウェア配布システムが望まれ
ていた。

【００１０】この発明は、上記従来の課題を解決するた
めになされたもので、クライアントアプリケーション、
サーバアプリケーションの配布を統合的に管理すること
ができるソフトウェア配布システムを提供することを目
的とする。

【００１１】

【課題を解決するための手段】上記目的を達成するため
に、この発明のソフトウェア配布システムは、ファイル
配布の必要時に配布ファイル情報の登録と配布ファイル
の動作に必要な他のアプリケーションのバージョン番号
を依存関係として登録後にファイルをスプール領域への
スプーリングおよびスケージュール化して配布ファイル
を配布先に送信し、かつ配布が正常に終了すると、現在
のバージョン情報を更新するマネージャ機能を有するソ
フトウェア配布サーバと、上記マネージャ機能から配布
されたファイルの受信、コマンドの受信、コマンド実行
の終了後の結果を上記ソフトウェアサーバマシンに返送
するエージェント機能を有するファイル配布対象マシン
とを備えることを特徴とする。

【００１２】この発明のソフトウェア配布システムによ
れば、ファイルの配布の必要時に、ソフトウェア配布サ
ーバマシンのマネージャ機能により、配布ファイル情報
の登録と、配布ファイルの動作に必要な他のアプリケー
ションのバージョン番号を依存関係として登録する。こ
の登録後にファイルをスプール領域にスプーリングする
とともに、スケージュールして配布ファイルを配布先に
送信する。ファイル配布対象マシンのエージェント機能
では、ソフトウェア配布マネージャ機能から配布された
ファイル、コマンドを順次受信し、コマンドを実行す
る。この実行の結果をソフトウェア配布サーバマシンに
返送し、ソフトウェア配布サーバマシンから実行結果が
正常であると、ソフトウェア配布サーバマシンのマネー
ジャ機能が現在のバージョンの情報を更新する。

【００１３】したがって、この発明では、クライアント
アプリケーション、サーバアプリケーションの配布を統
合的に管理することができる。

【００１４】

【発明の実施の形態】以下、この発明によるソフトウェ
ア配布システムの実施の形態について図面に基づき説明
する。図１はこの発明によるの第１実施の形態の構成を
示すブロック図である。この図１において、ソフトウェ
ア配布システムのマネージャ機能１０５を実装するソフ
トウェア配布サーバマシン１０１と、ソフトウェア配布
システムのエージェント機能１０６を実装するファイル
配布対象マシンとしてのUNIXサーバマシン１０２、ソフ
トウェア配布システムのエージェント機能１０６を実装
するファイル配布対象マシンとしてのUNIXクライアント
マシン１０３やソフトウェア配布システムのエージェン
ト機能１０６を実装するファイル配布対象マシンとして
のPCクライアントマシン１０４とから構成されている。

【００１５】ソフトウェア配布サーバマシン１０１、UN
IXサーバマシン１０２、UNIXクライアントマシン１０
３、PCクライアントマシン１０４は、相互にネットワー
ク１００を通して接続されている。これらの各エージェ
ント機能１０６は同一構成をなしているから、共通の符
号「１０６」を付して述べることにする。マネージャ機
能１０５と各エージェント機能１０６の構成は図２の機
能ブロック図で示されている。

【００１６】この図２において、マネージャ機能１０５
は配布ファイル登録手段２０１と、依存関係判断手段２
０２と、配布手段２０３と、結果受信手段２０４とを包
含している。また、配布ファイル登録手段２０１から管
理者が配布したいファイル名、配布先マシン名、ディレ
クトリ名、配布後の続行コマンド、配布時刻などを登録
する配布ファイル登録部２１１と、他のアプリケーショ
ンのバージョン番号を依存関係として登録する依存関係
管理部２１２と、配布ファイルをスプールする配布ファ
イルスプール部２１３と、依存関係を分析して配布する
べきファイルを登録するスケージュール管理部２１４
と、配布先の各マシンからの配布結果による各マシンの
現状を登録する各マシン現状バージョン管理部２１６と
を含んでいる。

【００１７】一方、エージェント機能１０６は、ファイ
ル受信手段２０５とコマンド実行手段２０６と、結果送
信手段２０７と、ファイル受信手段２０５で受信したフ
ァイルを格納する受信ファイル格納部２１６と、コマン
ド実行手段２０６で実行されるアプリケーションファイ
ルを格納するアプリケーションファイル格納部２１７と
を包含している。

【００１８】これらのマネージャ機能１０５に含む各手
段とエージェント機能１０６に含む各手段はそれぞれ概
略つぎのように動作する。配布ファイル登録手段２０１
は、キーボードなどの入力装置（図示せず）から設定者
が入力した配布情報（配布ファイル名、バージョン、依
存関係）の記憶および実際の配布ファイルのスプーリン
グを行う。

【００１９】依存関係判断手段２０２は、配布登録時に
設定された依存関係とそれぞれのマシンに現在配布され
ているバージョン、およびすでに次回配布予定になって
いるファイル、バージョンを確認して新しい次回の配布
予定を作成する。配布手段２０３は、配布予定を確認
し、予定にあがっているバージョンのファイルをスプー
ル領域から対象のマシンへ配布する。結果受信手段２０
４は、エージェントから配布の結果および配布後のコマ
ンド実行結果の受信を行う。

【００２０】エージェント機能１０６におけるファイル
受信手段２０５は、マネージャから送られてきたファイ
ルを受け取り、指示された領域に書き込みを行う。コマ
ンド実行手段２０６は、マネージャからの指示によりエ
ージェント側で任意のコマンドの実行を行う。結果送信
手段２０７は、上記ファイル受信手段２０５とコマンド
実行手段２０６の結果をマネージャに送信する。

【００２１】次に、この第１実施の形態の全体の動作に
ついて図２の機能ブロック図、図３と図４のフローチャ
ートを参照して説明する。まず、マネージャ機能の処理
手順を示す図３のフローチャートを参照すると、ソフト
ウェア配布マシン１０１のマネージャ機能１０５がスタ
ートして、図３のフローチャートに沿って処理が開始
し、ファイル配布の必要性が発生したとき、管理者は配
布ファイル登録手段２０１によって登録を行う必要があ
る。その詳細は配布したいファイル名、配布先のマシン
名、ディレクトリ名、配布後の実行コマンドおよび配布
時刻の登録を配布ファイル登録部２１１で行う（ステッ
プＡ）。

【００２２】次に、この配布ファイル登録手段２０１に
よって、そのファイル（アプリケーション）が動作する
ために必要な他のアプリケーションのバージョン番号を
依存関係として、依存関係登録部２１２に登録する（ス
テップＢ）。それらの登録が終了すると、実際のファイ
ルが配布ファイルスプール部２１３のスプール領域にス
プーリングされる（ステップＣ）。この場合、一度に複
数のファイル（他のファイル）を配布ファイル登録部２
１１に登録したい場合は、ファイルを配布するマシンの
問い合わせに対して配布ファイル登録手段２０１が回答
し、ステップＡに戻って登録する（ステップＤ）。

【００２３】また、ステップＤにおいて、一度に複数の
ファイルを登録しない場合には、配布ファイル登録手段
２０１によるファイル配布のための情報登録を終了させ
て、マネージャ機能１０５は依存関係判断手段２０２を
使って、依存関係を分析して配布すべきファイルを判定
し、スケジュール管理部２１４に登録する（ステップ
Ｅ）。その後、スケジュールされたファイルが正しいか
どうかの確認メッセージを表示し、スケジュールされた
ファイルの内容の確認を行う（ステップＦ）。このスケ
ジュールされたファイルの内容の確認がされない場合に
は、後述する図４のフローチャートのステップIに処理
を進める。

【００２４】ステップＦでの判定処理において、スケジ
ュールされたファイルの内容が確認された後に、スケジ
ュールされたファイル配布の指定時刻になると、マネー
ジャ機能１０５は配布手段２０３により指定されたファ
イルを配布先へ送信する。その詳細はスケジュール管理
部２１４からスケジュールされて配布されたファイル名
を配布手段２０３で読み込み、配布ファイルスプール部
２１３から該当するファイルを配布手段２０３で読み込
み、配布ファイル登録部２１１から配布後の実行コマン
ドも配布手段２０３で読み込んで、この配布手段２０３
から配布先に転送する（ステップＧ）。

【００２５】この場合、配布手段２０３からネットワー
ク１００を通して、たとえば、PCクライアントマシン１
０４のエージェント機能１０６に転送する。その後、マ
ネージャ機能１０５は配布先のクライアント機能１０６
から結果が送信されるまで結果待ち状態になる。ステッ
プＧで送信されてきたファイルを配布先のエージェント
機能１０６はファイル受信手段２０５で受け取る（ステ
ップＨ）。

【００２６】続いて、図４のフローチャートに示す処理
手順に移行する。この図４は図２におけるエージェント
機能１０６の処理手順を示すものである。この図４にお
いて、ファイル受信手段２０５がファイルを受信して、
その処理する順序はファイルを受信（ステップＩ）し、
そのファイル受信が正常に完了したか、否かのエラー検
査（ステップＪ）を行い、コマンドの受信（ステップ
Ｋ）、コマンド受信のエラー検査（ステップＬ）を順次
行う。

【００２７】ファイル受信手段２０５によるファイルの
正常受信がなされると、ファイル受信手段２０５は受信
ファイル格納部２１６に格納するとともに、ファイル受
信手段２０５によるコマンドの正常な受信がなされた場
合のみ、エージェント機能１０６におけるコマンド実行
手段２０６により、ファイル配布後のコマンドを実行す
る（ステップＭ）。コマンドの実行をするアプリケーシ
ョンファイルはアプリケーションファイル格納部２１７
に格納する。

【００２８】このコマンドの実行終了後にも、エージェ
ント機能１０６はコマンドの実行が正常に終了したかど
うかの検査を行う（ステップＮ）。ステップＪでのファ
イル受信の検査終了後と、ステップＬでのコマンド受信
終了の検査後と、ステップＮでのコマンド実行の終了後
検査で、それぞれ異常が発見された場合には、結果送信
手段２０７により異常が発見された箇所などのメッセー
ジをエージェント機能１０６の結果送信手段２０７から
マネージャ機能１０５の結果受信手段２０４に送信する
（ステップＰ）。すべて異常なく終了した場合にも、そ
の旨をエージェント機能１０６の結果送信手段２０７か
らマネージャ機能１０５の結果受信手段２０４に送信す
る（ステップＯ）。

【００２９】一方、前記エージェント機能１０６からの
結果受信待ちだったマネージャ機能１０５の結果受信手
段２０４は、エージェント機能１０６の結果送信手段２
０６から送信されてきたメッセージを受信し、ファイル
配布結果として正常／異常という情報を配布結果、各マ
シン現状バージョン管理部２１５へ登録する（図３のス
テップＨ）。また、ファイル配布が正常に終了した場合
には、各マシンの現在のバージョン情報を更新する（同
じく、ステップＨ）。

【００３０】この第１実施の形態では、クライアント／
サーバシステムのアプリケーションを配布するにあたっ
て、サーバアプリケーションファイル、クライアントア
プリケーションファイル独自のバージョン管理だけでは
なく、それぞれが依存する互いのバージョンを依存関係
として認識することで、統合的に管理し、ファイル配布
設定ミスを少なくし、バージョンダウンの必要性が発生
した場合、素早いクライアント／サーバ連動バージョン
ダウン配布が行える。このようにしてクライアント／サ
ーバシステムにおけるサーバアプリケーションおよびク
ライアントアプリケーションの統合的な同時ファイル配
布を可能にする。

【００３１】次に、具体例を用いて説明する。たとえ
ば、サーバアプリケーション、クライアントアプリケー
ションともにバージョン２．０で運用を行っていた後
に、サーバ、クライアント両アプリケーションともに新
バージョン３．０をリリースすることになり、ファイル
配布を行ったが、配布後にサーバのバグが発見されて急
遽サーバマシンのバージョンを戻すことになったと仮定
する。

【００３２】このようなケースでは、配布登録としてサ
ーバアプリケーションのバージョン２．０を登録するだ
けでよい。すなわち、すでにファイル名、実行コマンド
の登録やスプールは終了しているので、配布時期を登録
するだけでよい。この登録で依存関係判断部がサーバア
プリケーションのバージョン２．０が依存しているクラ
イアントアプリケーションのバージョンを２．０と判定
する。

【００３３】判定されたバージョン番号は、配布結果、
各マシン現状バージョン管理部に登録されているバージ
ョン３．０と照合され、相違があるので配布必要有りと
判断され、スケジュール管理部に登録される。このよう
にして、スケジュール管理部にサーバアプリケーション
バージョン２．０とともにクライアントアプリケーショ
ンバージョン２．０が登録されることにより、スムーズ
な連携バージョンダウンが実現される。

【００３４】次に、この発明の第２実施の形態例につい
て図５を参照して説明する。図５はこの第２実施の形態
におけるソフトウェア配布サーバマシン１０１のマネー
ジャ機能１０５とPCクライアントマシン１０４のエージ
ェント機能１０６の機能ブロック図である。この図５に
おいて、図２と同一部分には、同一符号を付して重複説
明を避け、図２とは異なる部分主体に述べる。

【００３５】クライアント／サーバシステムにおいて、
一般的にクライアントマシンの台数は多いが、サーバマ
シンの台数は少ないというケースが存在する。たとえ
ば、サーバマシンが１台でクライアントマシンが１００
台というケースである。こんなケースではサーバアプリ
ケーションはファイル配布ではなく、インストールやテ
スト環境からのコピーなどの手段でバージョンアップさ
れることがある。

【００３６】しかし、クライアントマシンはファイル配
布に頼らざるを得ない。そのような場合に統合管理を行
うためには、マネージャ機能１０６にサーバアプリケー
ションバージョン確認手段５０１を追加し、サーバアプ
リケーション５０２のバージョンをマネージャ機能１０
６が定期的に確認を行う。それに合わせて、必要なクラ
イアントアプリケーションの配布を行う。

【００３７】また、上記各実施の形態では、マネージャ
機能１０５がエージェント機能１０６に対して強制的に
ファイルを配布させるプッシュ（PUSH）型であったが、
エージェント機能１０６からマネージャ機能１０５にフ
ァイルを取りに行くプル（PULL）型にすると、マネージ
ャマシンの負荷が軽減されることが想定される。

【００３８】

【発明の効果】以上のように、この発明によれば、サー
バアプリケーション、クライアントアプリケーションそ
れぞれのバージョン管理だけではなく、このサーバアプ
リケーションを配布する以上、クライアントアプリケー
ションはこのバージョンを配布する必要性（またはその
逆）という情報も管理し、サーバ／クライアント間での
バージョンの相違を防ぐとともに、依存関係情報の保持
とその処理手段を実現するようにしたので、クライアン
ト／サーバアプリケーションの配布を統合的に管理でき
る。

【図面の簡単な説明】

【図１】この発明によるソフトウェア配布システムの第
１実施の形態の構成を示すブロック図である。

【図２】図１のソフトウェア配布システムにおけるソフ
トウエァ配布サーバマシンのマネージャ機能とPCクライ
アントマシンのエージェント機能の機能ブロック図であ
る。

【図３】図１のソフトウェア配布システムにおけるソフ
トウエァ配布サーバマシンのマネージャ機能の処理手順
を示すフローチャートである。

【図４】図１のソフトウェア配布システムにおけるPCク
ライアントマシンのマネージャ機能の処理手順を示すフ
ローチャートである。

【図５】この発明によるソフトウェア配布システムの第
２実施の形態におけるソフトウエァ配布サーバマシンの
マネージャ機能とPCクライアントマシンのエージェント
機能の機能ブロック図である。

【符号の説明】

１００……ネットワーク、１０１……ソフトウェア配布
サーバマシン、１０２……UNIXサーバマシン、１０３…
…UNIXクライアントマシン、１０４……PCクライアント
マシン、１０５……マネージャ機能、１０６……エージ
ェント機能、２０１……配布ファイル登録手段、２０２
……依存関係判断手段、２０３……配布手段、２０４…
…結果受信手段、２０５……ファイル受信手段、２０６
……コマンド実行手段、２０７……結果送信手段、２１
１……配布ファイル登録部、２１２……依存関係管理
部、２１３……配布ファイルスプール部、２１４……ス
ケジュール管理部、２１５……各マシン現状バージョン
管理部、２１６……受信ファイル格納部、２１７……ア
プリケーションファイル格納部、５０１……サーバアプ
リケーションバージョン確認手段、５０２……サーバア
プリケーション。

Claims

【特許請求の範囲】

【請求項１】ファイル配布の必要時に配布ファイル情
報の登録と配布ファイルの動作に必要な他のアプリケー
ションのバージョン番号を依存関係として登録後にファ
イルをスプール領域へのスプーリングおよびスケージュ
ール化して配布ファイルを配布先に送信し、かつ配布が
正常に終了すると、現在のバージョン情報を更新するマ
ネージャ機能を有するソフトウェア配布サーバと、上記マネージャ機能から配布されたファイルの受信、コ
マンドの受信、コマンド実行の終了後の結果を上記ソフ
トウェアサーバマシンに返送するエージェント機能を有
するファイル配布対象マシンと、を備えることを特徴とするソフトウェア配布システム。
【請求項２】前記マネージャ機能は、配布したいファ
イル名と、配布先のマシン名と、ディレクトリ名と、配
布後の実行コマンドと、配布時刻を配布ファイル登録部
への登録を行うとともに、配布したいファイルが動作す
るために必要な他のアプリケーションのバージョン番号
を依存関係として依存関係管理部に登録する配布ファイ
ル登録手段と、上記配布ファイル登録手段による上記配
布したいファイルの登録後にスプール領域にファイルを
スプーリングして格納する配布ファイルスプール部と、
配布登録時に設定された依存関係とそれぞれのファイル
配布対象マシンに現在配布されているバージョンと次回
配布予定のファイルとバージョンを確認して新しい次の
配布予定ファイルを作成する依存関係判断手段と、上記
依存関係判断手段により作成された配布予定ファイルを
確認して配布予定になっているバージョンのファイルを
上記配布ファイルスプール部のスプール領域から読み出
してファイル配布対象マシンへ配布する配布手段と、上
記フィルが配布されたマシンのエージェントから配布の
結果と配布後のコマンドの実行結果を受信して各マシン
の現状バージョン管理部に登録するとともに、ファイル
の正常な配布の終了時に各ファイル配布対象マシンの現
在のバージョン情報の更新を行う結果受信手段とを備え
ることを特徴とする請求項１記載のソフトウェア配布シ
ステム。
【請求項３】上記依存関係管理部は、サーバアプリケ
ーションのバージョン番号が依存しているクライアント
アプリケーションのバージョン番号であると判定した場
合に、バージョン番号が上記各マシン現状バージョン管
理部に登録されているバージョンと異なると上記スケー
ジュール管理部に上記判定したバージョン番号を登録す
ることを特徴とする請求項２記載のソフトウェア配布シ
ステム。
【請求項４】上記配布ファイル登録手段は、一度に複
数のファイルを上記配布ファイルに登録する場合には、
配布するマシンからの問い合わせに対して回答して上記
配布ファイルに登録することを特徴とする請求項２また
は３記載のソフトウェア配布システム。
【請求項５】上記エージェント機能は、上記マネージ
ャ機能から送信されたきたファイルを受信して受信ファ
イル格納部に格納するファイル受信手段と、上記マネー
ジャ機能の指示により任意のコマンドの実行をコマンド
実行手段と、上記ファイル受信手段による上記ファイル
の受信の結果と上記コマンド実行手段のコマンド実行の
結果を上記マネージャ機能に送信する結果送信手段とを
備えることを特徴とする請求項１乃至４に何れか１項記
載のソフトウェア配布システム。
【請求項６】上記コマンド実行手段は、上記ファイル
受信手段によりファイルが正常に受信された場合と、上
記コマンドが正常に受信された場合にのみ配布されたフ
ァイルの実行を行うことを特徴とする請求項５記載のソ
フトウェア配布システム。
【請求項７】上記コマンド実行手段は、上記コマンド
の実行の終了後にコマンドが正常に実行されたか、否か
の検査を行うことを特徴とする請求項５記載のソフトウ
ェア配布システム。
【請求項８】上記結果送信手段は、上記コマンド実行
手段により上記ファイル受信手段でのファイルの受信
と、上記コマンド実行手段でのコマンドの受信と、上記
コマンドの実行終了後の検査で異常が発見された場合に
異常が発見された箇所のメセージを上記マネージャ機能
に送信することを特徴とする請求項５、６または７記載
のソフトウェア配布システム。
【請求項９】上記マネージャ機能は、サーバアプリケ
ーションのバージョンを定期的に確認を行うサーバアプ
リケーションバージョン確認手段を有することを特徴と
する請求項１乃至８に何れか１項記載のソフトウェア配
布システム。
【請求項１０】上記ファイル配布対象マシンは、PCク
ライアントマシンであることを特徴とする請求項１乃至
９に何れか１項記載のソフトウェア配布システム。
【請求項１１】上記ファイル配布対象マシンは、UNIX
サーバマシンであることを特徴とする請求項１乃至９に
何れか１項記載のソフトウェア配布システム。
【請求項１２】上記エージェント機能は、上記マネー
ジャ機能にファイルを取りにいくプル型であることを特
徴とする請求項１乃至１１に何れか１項記載のソフトウ
ェア配布システム。