JP5574905B2 - モジュール配布システム - Google Patents

Description

本発明は、クライアント端末に対して各種モジュールを配布する技術に関し、特に、複数拠点の多数のクライアント端末に対して同日など一斉のタイミングでモジュールを配布するモジュール配布システムに適用して有効な技術に関するものである。

多数のクライアント端末を有するシステム環境における運用では、クライアント端末に対して各種モジュールを導入して反映させるメンテナンス作業を自動化するため、サーバから各クライアント端末に対して対象のモジュールを配布して展開・反映させる仕組みが必要となる。

このような仕組みを実現するソフトウェアとして、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）社のＳｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＳＭＳ、非特許文献１）などがある。ＳＭＳでは、例えば、クライアント端末へのビジネスアプリケーションの展開とインストール、ソフトウェアインベントリの管理、セキュリティパッチの展開などの、クライアント端末をメンテナンスするための各種機能を有する。

ここで、例えば、モジュールの配布対象となるクライアント端末が数万台などの多数となるような大規模システムの場合、配布処理に伴うサーバやネットワークへの処理負荷の集中が過大となり、応答が遅延するなどの問題が生じ得る。

このような問題を回避するため、例えば、特開２００５−３２１８７６号公報（特許文献１）には、複数のクライアントと、ダウンロード要求に応じてダウンロード対象プログラムをクライアントにネットワークを通じて配布するサーバとが設けられ、サーバは、多数のダウンロード要求がある場合に、クライアント毎に指定時刻を割り振る優先度管理プログラムと、プログラムをダウンロード要求先のクライアントへ転送するプログラム転送プログラムとを有し、クライアントへ割り振った指定時刻と待機リトライ命令を送信し、クライアントは、サーバと接続してダウンロードを要求し、読み込んだデータが前記待機リトライ命令のときにはサーバとの接続を一旦切断し、前記指定時刻まで待機してサーバと再接続することで、クライアントがサーバへ一斉にアクセスすることによるサーバやネットワークの負荷を低減できるコンピュータシステムが記載されている。

特開２００５−３２１８７６号公報

"Microsoft System Management Server"、[online]、Microsoft、［平成２２年８月１６日検索］、インターネット＜URL:http://www.microsoft.com/japan/smserver/default.mspx＞

上述したように、クライアント端末が数万台などの多数となるような大規模システムの場合、特許文献１などに記載されたように、通常はサーバから各クライアント端末への配布タイミングをずらして負荷を分散させる手法をとるのが一般的である。

しかしながら、特に業務アプリケーションに係るモジュールの配布と展開の場合などでは、特定のタイミングで全台一斉に反映されて使用可能となるようにする必要がある場合も多い。この場合、特許文献１に記載されたような配布タイミングをずらす手法では、特定のタイミング（例えば、特定の日の業務開始時など）に全台一斉に反映させて使用可能とすることは困難である。

また、ＳＭＳを利用したモジュールの配布においても、クライアント端末での配布モジュールの取り込みに要する時間や、配布失敗時のリトライや戻しの制御などの観点も含めて、特定のタイミングで適切にモジュールが反映され使用可能となるよう制御することは困難である。

さらに、特に業務アプリケーションに係るモジュールの配布では、全台一斉に配布するのではなく、例えば、動作確認用の特定のクライアント端末や、特定のユーザに対して先行的に配布して動作内容等の確認を行い、問題がないことを確認した上で全台に配布するという慎重なリリース手順をとることが多い。この場合、先行配布の対象モジュールの管理や、先行配布したクライアント端末の管理、全台展開時の処理など、運用上特別な管理や処理が必要とされるが、これらの実施を可能な限り定型化してシステムにより支援することでミスを低減させる仕組みも望まれる。

そこで本発明の目的は、多数のクライアント端末に対して特定のタイミングからの使用開始が必要なモジュールの配布と展開を行うことができるモジュール配布システムを提供することにある。また、本発明の別の目的は、特定のクライアント端末やユーザに対するモジュールの先行配布から他の全クライアント端末への本番展開までをシームレスかつ容易に取り扱うことができるモジュール配布システムを提供することにある。また、本発明の別の目的は、配布モジュールのサイズが大きい場合でも配布に要する時間とネットワークへの負荷を最小限に抑制することができるモジュール配布システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるモジュール配布システムは、複数の拠点にそれぞれ配置された多数のクライアント端末に対してセンターから各種のモジュールを配布するモジュール配布システムであって、以下の特徴を有するものである。

すなわち、モジュール配布システムは、前記センター側に配置され、指定された配布日および配布対象のモジュールに基づいて配布パッケージを作成して第１の一時記憶領域に保持する管理サーバと、前記センター側に配置され、前記管理サーバと接続し、日次の第１のタイミングで、前記管理サーバの前記第１の一時記憶領域から前記配布パッケージを取得して第２の一時記憶領域に保持する１つ以上の中継サーバとを有する。

さらに、前記各拠点に配置され、前記中継サーバの１つと接続し、１つ以上の前記クライアント端末が接続され、前記第１のタイミングより後の日次の第２のタイミングで、自身が接続する前記中継サーバの前記第２の一時記憶領域から前記配布パッケージを取得して第３の一時記憶領域に保持し、前記第２のタイミングより後の日次の第３のタイミングで、前記第３の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第１のリリース記憶領域に保持する１つ以上の配布サーバを有し、前記クライアント端末は、日次の起動時に実行されるリリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から前記配布パッケージに含まれるモジュールを取得してローカル記憶領域に保持し、自身に反映させることを特徴とするものである。

また、本発明の他の実施の形態によるモジュール配布システムは、前記管理サーバが、特定のグループに属する前記クライアント端末もしくはユーザに対してのみ先行配布するモジュールの指定に基づいて先行配布対象の前記配布パッケージを作成し、前記配布サーバは、前記第３のタイミングで、前記第３の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第１のリリース記憶領域に保持する際に、先行配布対象の前記配布パッケージについては、前記第１のリリース記憶領域における先行配布用の領域に、前記特定のグループが識別可能となるように保持する。

また、前記クライアント端末は、前記リリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から前記配布パッケージに含まれるモジュールを取得して前記ローカル記憶領域に保持し、自身に反映させた後、さらに、前記第１のリリース領域における先行配布用の領域に、自身が属するグループに対する先行配布対象の前記配布パッケージが存在する場合は、これを取得して前記前記ローカル記憶領域に上書き保持し、自身に反映させることを特徴とするものである。

また、本発明の他の実施の形態によるモジュール配布システムは、前記管理サーバが、指定された配布対象のモジュールの容量が所定の値よりも大きい場合はこれらを圧縮して前記配布パッケージを作成して前記第１の一時記憶領域に保持し、前記クライアント端末は、前記リリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から圧縮された前記配布パッケージを取得してこれを解凍し、解凍された前記配布パッケージに含まれるモジュールを取得してローカル記憶領域に保持し、自身に反映させることを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、多数のクライアント端末に対して特定のタイミングからの使用開始が必要なモジュールの配布と展開を行うことが可能となる。また、本発明の代表的な実施の形態によれば、特定のクライアント端末やユーザに対するモジュールの先行配布から全クライアント端末への本番展開までをシームレスかつ容易に取り扱うことが可能となる。また、本発明の代表的な実施の形態によれば、配布モジュールのサイズが大きい場合でも配布に要する時間とネットワークへの負荷を最小限に抑制することが可能となる。

本発明の実施の形態１であるモジュール配布システムの構成例について概要を示した図である。 本発明の実施の形態１における、配布サーバからクライアント端末へのモジュールの配布処理の例について概要を示した図である。 本発明の実施の形態１における、配布対象のモジュールの削除処理の例について概要を示した図である。 本発明の実施の形態１における、配布モジュールがクライアント端末に配布されるまでの処理の流れの例について概要を示した図である。 本発明の実施の形態１における、中継サーバおよび配布サーバの一時リリースＰＧＭによってそれぞれ実行される一時リリース処理の例について示したフローチャートである。 本発明の実施の形態１における、管理サーバ、中継サーバおよび配布サーバのリリースＰＧＭによってそれぞれ実行されるリリース処理の例について示したフローチャートである。 本発明の実施の形態１における、クライアント端末のリリースエージェントによって実行される配布処理の例について示したフローチャートである。 本発明の実施の形態２における、特定のクライアント端末へのモジュールの先行配布処理の例について概要を示した図である。 本発明の実施の形態２における、管理サーバ、中継サーバおよび配布サーバのリリースＰＧＭによってそれぞれ実行されるリリース処理の例について示したフローチャートである。 本発明の実施の形態２における、クライアント端末のリリースエージェントによって実行される配布処理の例について示したフローチャートである。 本発明の実施の形態２における、先行配布処理の例について示したフローチャートである。 本発明の実施の形態３における、配布対象のモジュールを圧縮して配布する圧縮配布処理の例について概要を示した図である。 本発明の実施の形態３における、圧縮配布処理でのメンテナンス処理の例について概要を示した図である。 本発明の実施の形態３における、管理サーバ、中継サーバおよび配布サーバのリリースＰＧＭによってそれぞれ実行されるリリース処理の例について示したフローチャートである。 本発明の実施の形態３における、クライアント端末のリリースエージェントによって実行される配布処理の例について示したフローチャートである。 本発明の実施の形態３における、圧縮パッケージ展開処理の例について示したフローチャートである。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜実施の形態１＞
本発明の実施の形態１であるモジュール配布システムは、例えば数万台といった多数のクライアント端末に対して業務アプリケーションやセキュリティパッチ等を含む各種のモジュールを配布するシステムであり、特に、業務アプリケーションなど、クライアント端末に対して特定のタイミング（本実施の形態では特定の日（なお、以下では「日」とは原則としていわゆる営業日を指すものとする）を対象として説明するため、以下では「リリース日」と記載する場合がある）からの使用開始が必要なモジュールの配布と展開を行うことを可能とするシステムである。

なお、本実施の形態のモジュール配布システムは、セキュリティパッチなど、必ずしもリリース日に展開・適用されていなければ業務に支障をきたすというものではないモジュールについての配布と展開を行うことも可能であるが、このようなモジュールについては、例えば、上述したＳＭＳ等を利用した他の仕組みを併用して配布と展開を行うようにすることも可能である。

［システム構成］
図１は、本発明の実施の形態１であるモジュール配布システムの構成例について概要を示した図である。モジュール配布システム１は、多数のクライアント端末２０から一斉にモジュールの取り込みが行われたときの負荷の集中を回避するため、分散された階層構造を有する。最上位には、モジュールの配布担当者２等によって配布モジュール３が登録され、これに基づいて配布パッケージ１７を作成するサーバ機器である管理サーバ１０ａを有する。また、その下層には、ＬＡＮ（Local Area Network）等のネットワークを介して管理サーバ１０ａと接続し、当該管理サーバ１０ａから配布パッケージ１７を取り込んで保持するサーバ機器である中継サーバ１０ｂを１つ以上有する。これらの管理サーバ１０ａおよび中継サーバ１０ｂは、例えば、データセンター施設などのセンター側に配置される。

一方、各支店・支部や事業所、営業店など（以下ではこれらを単に「拠点」と総称する場合がある）では、ＷＡＮ（Wide Area Network）等の広域ネットワーク４を介して中継サーバ１０ｂの１つと接続し、当該中継サーバ１０ｂから配布パッケージ１７を取り込んで保持するサーバ機器である配布サーバ１０ｃをそれぞれ１つ以上有する。各配布サーバ１０ｃには、ＬＡＮ等のネットワークを介して、当該配布サーバ１０ｃが属する拠点内で業務に使用されるＰＣ（Personal Computer）等のクライアント端末２０が複数接続される。

各クライアント端末２０は、接続する配布サーバ１０ｃから配布パッケージ１７を取り込んでインストール等の展開処理を行う。配布サーバ１０ｃを拠点側に配置することで、各クライアント端末２０から配布パッケージ１７を取り込む際の広域ネットワーク４への負荷集中を回避する。この配布サーバ１０ｃや、中継サーバ１０ｂの数は、拠点の数やクライアント端末２０の数、各機器やネットワークのスペック、運用要件等に応じて適宜定めることができる。図１の例では、中継サーバ１０ｂおよび配布サーバ１０ｃともにそれぞれ１層の構成となっているが、これらの階層を適宜増減した構成とすることも可能である。

管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃは、それぞれ類似の構成を有しており、リリース日までの余裕を持って事前に登録された配布パッケージ１７を、リリース（クライアント端末２０への配布）前の所定のタイミング（例えばリリース日の前日）まで保持しておくＨＤＤ（Hard Disk Drive）等の記憶領域である一時領域１１（１１ａ〜１１ｃ）と、上記所定のタイミングで配布パッケージ１７をクライアント端末２０へ配布可能とするためにコピーされる記憶領域であるリリース領域１２（１２ａ〜１２ｃ）とをそれぞれ有する。

中継サーバ１０ｂおよび配布サーバ１０ｃは、それぞれ、上位階層である管理サーバ１０ａもしくは中継サーバ１０ｂの一時領域１１に保持されている配布パッケージ１７を取り出して、自身の一時領域１１にコピーするソフトウェアプログラムである一時リリースプログラム（ＰＧＭ）１４（１４ｂ、１４ｃ）を有する。これらのプログラムは、上位階層から順に所定の時刻（例えば、一時リリースＰＧＭ１４ｂが１６：００、一時リリースＰＧＭ１４ｃが１７：００）に日次のバッチ処理として起動される。これにより、配布担当者２が管理サーバ１０ａで登録した配布モジュール３は、配布パッケージ１７として、管理サーバ１０ａから中継サーバ１０ｂ、配布サーバ１０ｃに順次コピーされていく。

また、管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃは、それぞれ、一時領域１１から配布パッケージ１７を取り出して、配布可能とするためにリリース領域１２にコピーするソフトウェアプログラムであるリリースプログラム（ＰＧＭ）１３（１３ａ〜１３ｃ）を有する。これらのプログラムは、例えば、業務終了後の夜間（例えば２２：００等）に日次のバッチ処理として起動され、対象のサーバの一時領域１１に保持されている配布パッケージ１７のうちリリース日が翌日（翌営業日）であるものを抽出して、リリース領域１２にコピーする処理を行う。リリース日がこれより以前の古い配布パッケージ１７が存在する場合は、古い順にリリース領域１２にコピーする。

管理サーバ１０ａは、配布担当者２が配布モジュール３の登録を行うためのソフトウェアプログラムであるパッケージングコマンド１６を有する。パッケージングコマンド１６は、配布担当者２によって指定された配布モジュール３およびリリース日を含む情報から配布パッケージ１７を作成し、一時領域１１ａに格納する。配布パッケージ１７の具体的な形態としては、例えば、所定のネーミングルールに基づいてパッケージ名とリリース日の情報を含む名称を付したフォルダやディレクトリ（以下では単に「ディレクトリ」と総称する）とし、その中に配布モジュール３を格納する形態をとることができる。ファイルリストや他の属性情報・管理情報等を保持する管理ファイルなどをさらに格納していてもよい。

本実施の形態では、パッケージングコマンド１６を、配布モジュール３を登録（他システムからのコピーやアップロードなど）するためのコマンドを提供するプログラムとしているが、Ｗｅｂブラウザ等を利用して配布モジュール３を登録するようなユーザインタフェースを有するＷｅｂアプリケーションプログラムとして実装してもよい。

なお、上述したように、配布モジュール３は、リリース日にクライアント端末２０に配布・展開されて使用可能となる必要がある業務アプリケーションに係るプログラム等（リリース日より前や後に配布・展開されると支障があるようなプログラム）が主に対象となるが、必ずしもリリース日に配布・展開されている必要がないＯＳ（Operating System）等のセキュリティパッチや商用ソフトウェアプログラムなどであってもよい。

各クライアント端末２０は、配布された配布パッケージ１７を格納するＨＤＤ等の記憶領域であるローカル領域２２と、上位階層である配布サーバ１０ｃのリリース領域１２ｃに保持されている配布パッケージ１７を取り出してローカル領域２２にコピーし、クライアント端末２０に反映させるソフトウェアプログラムであるリリースエージェント２３を有する。リリースエージェント２３は、例えば、クライアント端末２０の起動時に一回実行されるようにする。これにより、配布パッケージ１７の内容は、クライアント端末２０の起動時に配布サーバ１０ｃから配布されてローカル領域２２に格納され、その後モジュールに応じてインストール等の展開処理が行われることになる。

各クライアント端末２０が配布サーバ１０ｃから取り込んだ配布パッケージ１７の処理履歴については、リリースエージェント２３によって配布サーバ１０ｃ（さらに中継サーバ１０ｂ、管理サーバ１０ａ）に送信され、ファイルやデータベース等の形で記録されるようにしてもよい。これを参照することにより、センター側で配布の実行状況を把握することも可能となる。

［クライアント端末への配布処理］
図２は、配布サーバ１０ｃからクライアント端末２０へのモジュールの配布処理の例について概要を示した図である。配布サーバ１０ｃのリリース領域１２ｃ（管理サーバ１０ａのリリース領域１２ａ、中継サーバ１０ｂのリリース領域１２ｂについても同様）には、クライアント端末２０に配布されているべき全ての最新の配布パッケージ１７（配布モジュール３）がマスタとして保持されている。一方、クライアント端末２０においても配布サーバ１０ｃから取り込んだモジュールの最新のものをローカル領域２２に保持しており、クライアント端末２０は、配布サーバ１０ｃでの各モジュールとの間で差異があるモジュールのみを差分として取り込む手法をとる。

新たに配布（リリース）される配布パッケージ１７は、管理サーバ１０ａから、一時リリースＰＧＭ１４ｂ、１４ｃによって、中継サーバ１０ｂを経由して配布サーバ１０ｃの一時領域１１ｃにコピーされ、さらにリリースＰＧＭ１３によってリリース領域１２ｃにコピーされる。このとき、図２の左側に示すように、配布サーバ１０ｃのリリース領域１２ｃには、既存のモジュールで変更されないものの他に、既存のモジュールが配布パッケージ１７によって変更されたもの、および新規に追加された配布パッケージ１７に係るモジュールが含まれ得ることになる。

クライアント端末２０は、起動時にリリースエージェント２３によってローカル領域２２に保持している各モジュールと、配布サーバ１０ｃのリリース領域１２ｃに保持されている各モジュールとをファイルの属性を基準に比較して差異を判定する。ここで、比較の基準となるファイルの属性には、例えば、ファイル名やファイルサイズ、タイムスタンプなどが含まれ、これらの属性の少なくとも１つが相違すれば差異があると判定することができる。この場合、例えば、ファイル名によってモジュールの同一性と存在・不存在を判定し、同一である場合に、ファイルサイズやタイムスタンプ等によって変更の有無を判定する。

その後、リリースエージェント２３によって、図２の右側に示すように、差異があったモジュール（変更されたモジュール、新規に追加されたモジュール）についてのみ、配布サーバ１０ｃのリリース領域１２ｃからクライアント端末２０のローカル領域２２に対して上書きコピーされる。

なお、配布サーバ１０ｃのリリース領域１２ｃには存在しないが、クライアント端末２０のローカル領域２２には存在するモジュールについては、配布対象から削除されたものとして、クライアント端末２０への配布は行われない（クライアント端末２０から配布サーバ１０ｃへのコピーも行わない）。

図３は、配布対象のモジュールの削除処理の例について概要を示した図である。配布対象のモジュールを削除する（配布対象から除外する）場合、配布担当者２は、管理サーバ１０ａに対して削除対象の配布モジュール３（もしくは配布パッケージ１７）のリスト情報を保持する削除リスト５を作成して登録する。なお、配布担当者２は所定の情報のみを入力するものとし、パッケージングコマンド１６が入力された情報に基づいて削除リスト５を所定のフォーマットで作成するようにしてもよい。この削除リスト５は、通常の配布パッケージ１７と同様に、一時リリースＰＧＭ１４や、リリースＰＧＭ１３によって、管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃの一時領域１１や、リリース領域１２にそれぞれコピーされる。

このとき、各リリースＰＧＭ１３はそれぞれ、リリース領域１２に削除リスト５をコピーする際に、削除リスト５に含まれる削除対象の配布モジュール３を該当の配布パッケージ１７から削除する（もしくは削除対象の配布パッケージ１７を削除する）。これにより、削除対象の配布モジュール３（もしくは配布パッケージ１７）がクライアント端末２０に配布されないようにすることができる。なお、削除処理後に当該削除リスト５は削除する。

ここで、例えば、管理サーバ１０ａで登録した削除リスト５がリリースＰＧＭ１３や一時リリースＰＧＭ１４の日次処理をバイパスして配布サーバ１０ｃのリリース領域１２ｃまで即時にコピーされるような緊急時の仕組みを設けることで、モジュールに不具合が発覚した場合などの配布の停止をセンター側から早期かつ容易に行うことが可能となる。

なお、配布パッケージ１７をリリース領域１２から削除した場合に、対象のモジュールが既にクライアント端末２０に配布されている場合は、ローカル領域２２に残留するこれらのモジュールに対する処置は運用条件に依存して決定することができる。例えば、他に影響がなければ何もせずに存置させてもよいし、積極的に削除する必要がある場合は、例えば、削除リスト５などにその旨の指示を含めた上でクライアント端末２０に配布される（通知する）ようにし、クライアント端末２０において当該指示に従って対象モジュールの削除やアンインストール等の処理を行うようにしてもよい。

［登録、中継、配布処理］
図４は、配布モジュール３がクライアント端末２０に配布されるまでの処理の流れの例について概要を示した図である。まず、配布担当者２によるパッケージングコマンド１６の実行により、所定のタイミング（本実施の形態ではリリース日の２営業日前）までに、配布モジュール３が配布パッケージ１７として管理サーバ１０ａの一時領域１１ａに事前に登録される。

一時領域１１ａに登録された配布パッケージ１７は、日次のバッチ処理として所定の時間（例えば１６：００）に起動される中継サーバ１０ｂの一時リリースＰＧＭ１４ｂにより、中継サーバ１０ｂの一時領域１１ｂに取り込まれる。さらにその後、一時領域１１ｂに登録された配布パッケージ１７は、日次のバッチ処理として所定の時間（例えば１７：００）に起動される配布サーバ１０ｃの一時リリースＰＧＭ１４ｃにより、配布サーバ１０ｃの一時領域１１ｃに取り込まれる。

一時領域１１に保持された配布パッケージ１７は、日次のバッチ処理として業務時間外の所定の時間（例えば２２：００）に起動されるリリースＰＧＭ１３により、リリース日の前日に、管理サーバ１０ａ、中継サーバ１０ｂもしくは配布サーバ１０ｃのリリース領域１２にそれぞれ取り込まれる。すなわち、リリースＰＧＭ１３は、一時領域１１に保持されている配布パッケージ１７のうち、リリース日が翌日であるものを抽出して、リリース領域１２にコピーする。該当しない配布パッケージ１７については、一時領域１１にそのまま保持される。なお、配布パッケージ１７のリリース日については、上述したように、例えば、配布パッケージ１７に対応するディレクトリの名称等から判定することができる。

以上の処理により、リリース日が翌日である配布パッケージ１７がリリース領域１２にコピーされ、クライアント端末２０への配布の準備が整う。なお、上記のように、管理サーバ１０ａおよび中継サーバ１０ｂについても、配布サーバ１０ｃと同様に、リリース領域１２に配布パッケージ１７をそれぞれコピーしておくのが望ましい。これにより、例えば、配布サーバ１０ｃの障害時等に、クライアント端末２０が接続するバックアップ機として利用することが可能となる。

リリース領域１２ｃに保持された配布パッケージ１７は、各拠点のクライアント端末２０のリリースエージェント２３により、リリース日の業務開始の際の起動時にローカル領域２２に取り込まれる。これは、図２で示したように、リリース領域１２ｃに保持された最新のモジュールとローカル領域２２に保持されたモジュールとの差分をコピーすることによって行われる。当該差分は、上述したように、リリース日前日（もしくは当日）に配布対象の配布パッケージ１７が配布サーバ１０ｃのリリース領域１２ｃにコピーされ、もしくはリリース領域１２ｃから配布パッケージ１７が削除されることによって生ずる。

［処理フロー］
以下では、上記の一連の処理においてモジュール配布システム１の各プログラムが実行する処理の内容について説明する。図５は、中継サーバ１０ｂおよび配布サーバ１０ｃの一時リリースＰＧＭ１４によってそれぞれ実行される一時リリース処理の例について示したフローチャートである。

日次のバッチ処理として所定の時間に起動された一時リリースＰＧＭ１４は、まず、自サーバ（中継サーバ１０ｂもしくは配布サーバ１０ｃ）において、モジュールの配布元となる上層のサーバ（管理サーバ１０ａもしくは中継サーバ１０ｂ）の一時領域１１を、ネットワークを介して仮想ドライブとしてアクセスできるようマウントする（Ｓ１１０）。なお、本実施の形態では、モジュールをコピーするために記憶領域をマウントする構成としているが、例えばファイル転送など、モジュールをコピー可能な手段であれば他の手段であってもよい（以下同様）。

その後、下層（配布サーバ１０ｃもしくはクライアント端末２０）や他の機器からのアクセスを不許可とするため、自サーバの一時領域１１についての共有設定を削除する（Ｓ１２０）。その後、配布元サーバの一時領域１１に保持されている配布パッケージ１７を、自サーバの一時領域１１に同期コピーする（Ｓ１３０）。同期コピーを行うためには、例えば、Ｗｉｎｄｏｗｓ（登録商標）でのｒｏｂｏｃｏｐｙコマンドやＵＮＩＸ（登録商標）でのｒｓｙｎｃなどの既存のソフトウェアを利用することで、配布パッケージ１７に対応するディレクトリの内容を同期させることができる。

同期コピーの後、自サーバの一時領域１１についての共有を再設定し（Ｓ１４０）、下層（配布サーバ１０ｃもしくはクライアント端末２０）や他の機器からのアクセスを可能とする。その後、配布元サーバの一時領域１１をアンマウントして（Ｓ１５０）、一時リリース処理を終了する。

図６は、管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃのリリースＰＧＭ１３によってそれぞれ実行されるリリース処理の例について示したフローチャートである。日次のバッチ処理として所定の時間に起動されたリリースＰＧＭ１３は、まず、自サーバの一時領域１１に保持された配布パッケージ１７のリストを作成する（Ｓ２１０）。次に、リリース履歴１５や他の配布実行状況を記録したファイル等を参照して、配布実行済み以外の配布パッケージ１７のうち、リリース日が翌日であるものを抽出して本日実行リストを作成する（Ｓ２２０）。

その後、自サーバの一時領域１１についての共有設定を削除し（Ｓ２３０）、本日実行リストに記載されている配布パッケージ１７を、一時領域１１からリリース領域１２にコピーする（Ｓ２４０）。コピーの後、自サーバの一時領域１１についての共有を再設定し（Ｓ２５０）、リリース領域１２にコピーした配布パッケージ１７が配布対象のものであったか否かの整合性を確認し（Ｓ２６０）、リリース履歴１５に処理内容を記録した上でリリース処理を終了する。リリース履歴１５への記録に加えて、配布実行状況を記録したファイル等を設けてこれに配布済みの配布パッケージ１７の情報を記録するようにしてもよい。

図７は、クライアント端末２０のリリースエージェント２３によって実行される配布処理の例について示したフローチャートである。まず、リリースエージェント２３は、クライアント端末２０上に保持された環境設定ファイルやレジストリ等を参照して、対象のクライアント端末２０が所属する部署やドメイン、サイト等の情報や、接続先となる配布サーバ１０ｃの接続情報などを取得する（Ｓ３１０）。その後、取得した情報に基づいて配布サーバ１０ｃのリリース領域１２ｃを、ネットワークを介してアクセスできるようマウントする（Ｓ３２０）。

その後、配布サーバ１０ｃから設定ファイル等を読み込んで、配布サーバ１０ｃに係る設定情報を取得し（Ｓ３３０）、取得した設定情報に従って配布サーバ１０ｃのリリース領域１２ｃを特定してそのディレクトリ構成と内容を検索する（Ｓ３４０）。さらに、転送に係るモジュールの容量を計算する（Ｓ３５０）。その後、リリース領域１２ｃに保持された配布パッケージ１７に係るモジュールと、クライアント端末２０のローカル領域２２に保持されたモジュールとを比較して、差異があるファイルをリリース領域１２ｃからローカル領域２２にコピーする（Ｓ３６０）。

その後、配布対象のモジュールに応じて、所定の場所にモジュールを配置したり、インストール用のプログラムを実行したりするなどして、配布対象のモジュールをクライアント端末２０に反映させる（Ｓ３７０）。その後、上記一連の処理に係るログを記録したログファイルを配布サーバ１０ｃに転送し（Ｓ３８０）、配布サーバ１０ｃのリリース領域１２ｃをアンマウントして（Ｓ３９０）、配布処理を終了する。

なお、リリースエージェント２３による上記の処理は、処理内容の特性に応じて他の複数のプログラム（常駐プログラム、実行可能プログラム、バッチプログラム等）を呼び出してそれらに実行させるようにしてもよい。このとき、例えば、ＯＳのセキュリティパッチの適用など、クライアント端末２０の環境設定やインストールプログラムの実行を必要とするようなモジュールを反映させるプログラムについては、正常実行されたステータスを管理するなどにより、当日の複数回の起動・実行を防止する手段を講じる。

以上に示したように、本発明の実施の形態１であるモジュール配布システム１によれば、例えば数万台といった多数のクライアント端末２０に対して、分散された階層構造により複数の配布サーバ１０ｃを割り当てて、またこの配布サーバ１０ｃを拠点側に配置することで、クライアント端末２０へのモジュール配布時の処理負荷を分散することができる。また、リリース日を考慮して配布パッケージ１７をリリース領域１２にコピーするよう制御することで、業務アプリケーションなど、クライアント端末２０に対して特定のタイミング（リリース日）からの使用開始が必要なモジュールの配布と展開を容易かつ確実に行うことが可能となる。

また、配布サーバ１０ｃのリリース領域１２ｃとクライアント端末２０のローカル領域２２のモジュールとの差分を配布する構成としているため、クライアント端末２０側でモジュールの欠損等が発生しても、リリース領域１２ｃに保持された配布パッケージ１７を削除等しない限り、クライアント端末２０の再起動を行うことによって再配布され、モジュールを均一化することができる。また、逆に管理サーバ１０からの指示により削除リスト５を利用してリリース領域１２ｃに保持された配布対象の配布パッケージ１７を削除することで、配布の中止やモジュールの戻しをセンター側から容易に行うことが可能となる。

＜実施の形態２＞
本発明の実施の形態２であるモジュール配布システムは、上述した実施の形態１のモジュール配布システム１の機能に加えて、さらに、業務アプリケーション等について、一部の特定のクライアント端末２０やユーザ（これらが属する部署等のグループ）に対するモジュールの先行配布を行い、動作確認や運用手順の確認等を行った後、他の全クライアント端末２０へ本番展開する、という一連の流れをシームレスかつ容易に取り扱うことを可能とするシステムである。なお、システム構成や基本となるモジュール配布処理の流れは実施の形態１と同様であるため再度の記載は省略する。

［先行配布処理］
図８は、特定のクライアント端末２０へのモジュールの先行配布処理の例について概要を示した図である。図８において、配布サーバ１０ｃのリリース領域１２ｃには、通常通り全クライアント端末２０に配布するモジュールのマスタを保持する領域（図８の例では「全店」の領域（ディレクトリ））と、先行配布する特定のクライアント端末２０のみに配布するモジュールを保持する領域（図８の例では「先行（Ｘ部署）」の領域（ディレクトリ））とを有する。先行配布するモジュールを保持する領域は、部署毎に複数有することができる。

「Ｘ部署」に属するクライアント端末２０ｘ、および「Ｙ部署」に属するクライアント端末２０ｙともに、まず、配布サーバ１０ｃのリリース領域１２ｃにおける、「全店」に配布するモジュールを保持する領域から、通常通り（すなわち、上述した実施の形態１と同様の手順により）配布対象のモジュールを差分コピーによりローカル領域２２（２２ｘ、２２ｙ）にそれぞれ取り込む。

その後、リリース領域１２ｃに、自身が属する部署に先行配布するモジュールを保持する領域があるか否かを確認する。「Ｘ部署」に属するクライアント端末２０ｘについては、該当する領域（「先行（Ｘ部署）」）が存在することから、当該領域に保持されている先行配布対象のモジュールを全てローカル領域２２ｘに上書きコピーする。一方、「Ｙ部署」に属するクライアント端末２０ｙについては、該当する領域が存在しないため、先行配布処理は行われない。これにより、特定の部署（「Ｘ部署」）に属する（もしくは、当該部署に属するユーザが使用する）クライアント端末２０ｘについてのみ、先行配布対象のモジュールが強制的にコピーされるようにすることができる。

［処理フロー］
以下では、先行配布に係る一連の処理においてモジュール配布システム１の各プログラムが実行する処理の内容について説明する。なお、中継サーバ１０ｂおよび配布サーバ１０ｃの一時リリースＰＧＭ１４によってそれぞれ実行される一時リリース処理については、実施の形態１の図５で示した一時リリース処理の例と同様であるため説明は省略する。

図９は、管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃのリリースＰＧＭ１３によってそれぞれ実行されるリリース処理の例について示したフローチャートである。ここでは、実施の形態１の図６に示したリリース処理の例に加えて、ステップＳ２４０において一時領域１１からリリース領域１２に配布パッケージ１７をコピーする処理を行う前に、先行配布が終了したため不要となった先行配布対象のモジュールをリリース領域１２から削除するメンテナンス処理（Ｓ２３５）が追加されている。

上述したように、先行配布対象のモジュールはクライアント端末２０に対して強制的に上書きコピーされるため、該当するクライアント端末２０は毎日起動時に当該コピー処理にかかる時間を要し、業務開始に影響が出る場合が生じる。また、モジュールのデグレードの危険も生じる。従って、動作確認等が完了して先行配布対象のモジュールが全店展開された後は上記コピー処理が行われないようにするために当該メンテナンス処理が必要となる。

この先行配布メンテナンス処理（Ｓ２３５）では、先行配布対象のモジュールを削除するために、実施の形態１の図３で示した削除リスト５を使用して配布モジュール３をリリース領域１２から削除する仕組みを利用する。すなわち、先行配布が終了したことにより配布担当者２によって登録された先行配布対象のモジュール用の削除リスト５が配布パッケージ１７内にあるか否かを確認し、ある場合には、削除リスト５に指示されているモジュールをリリース領域１２（の先行配布対象のモジュールを保持する領域）から削除する。

また、次のステップＳ２４０における一時領域１１からリリース領域１２に配布パッケージ１７をコピーする処理では、当該配布パッケージ１７が先行配布対象のものである場合は、リリース領域１２における通常の領域ではなく、先行配布対象のモジュールを保持する領域にコピーする。ここでは例えば、当該領域の中にさらに先行配布の対象となる部署毎に、部署を識別可能なネーミングルールによって領域（ディレクトリ）を作成して該当する配布パッケージ１７をコピーする。

なお、配布パッケージ１７が先行配布対象であるか否かは、例えば、配布パッケージ１７に同梱（配布パッケージ１７のディレクトリに格納）された管理ファイルなどを利用して判断することができる。例えば、配布担当者２が管理サーバ１０ａに対して配布モジュール３を指定する際に、リリース日に加えて先行配布対象の部署等の情報を指定することで、パッケージングコマンド１６から管理ファイルにこれらの情報が出力されるようにすることができる。

図１０は、クライアント端末２０のリリースエージェント２３によって実行される配布処理の例について示したフローチャートである。ここでは、実施の形態１の図７に示した配布処理の例に加えて、ステップＳ３７０において配布対象のモジュールをクライアント端末２０に反映させる処理を行った後に、図８に示した、先行配布対象のモジュールを配布サーバ１０ｃのリリース領域１２ｃから取り込む先行配布処理（Ｓ３７５）が追加されている。

図１１は、図１０のステップＳ３７５の先行配布処理の例について示したフローチャートである。先行配布処理では、まず、図１０のステップＳ３１０で取得した情報から、自身が所属する部署やドメイン、サイト等の情報や、接続先となる配布サーバ１０ｃの接続情報などを確認する（Ｓ３７５−１）。確認できなかった場合は、図１０のステップＳ３１０と同様の処理によって再取得する。

その後、確認した情報に基づいて配布サーバ１０ｃのリリース領域１２ｃを特定してそのディレクトリ構成を検索し、先行配布対象のモジュールを保持する領域（ディレクトリ）に、自身が属する部署に対応する領域（ディレクトリ）があるか否かを確認する（Ｓ３７５−２）。上述した図９のステップＳ２４０において、リリース領域１２ｃにおける部署毎の先行配布対象のモジュールを保持する領域には、対象の部署（もしくはドメイン等）を識別可能なネーミングルールにより名称が付されるため、自身が属する部署に対応する領域の有無を判定することが可能である。

ステップＳ３７５−２で、該当する領域が存在しない、すなわち自身に対する先行配布対象のモジュールがない場合は先行配布処理を終了する。該当する領域が存在する場合は、当該領域に保持されている配布パッケージ１７に含まれるモジュールをローカル領域２２に上書きコピーする（Ｓ３７５−３）。その後、当該配布パッケージ１７にクライアント端末２０への反映用のプログラムが存在するか否かを確認し（Ｓ３７５−４）、存在する場合には、当該プログラムを実行して先行配布対象のモジュールをクライアント端末２０に反映させて（Ｓ３７５−５）、処理を終了する。

上記の処理によりモジュールが先行配布された状態で、例えば翌日に当該クライアント端末２０が再起動された場合は、図１０のステップＳ３６０、Ｓ３７０において、クライアント端末２０に前日先行配布されたモジュールが差分と判断される。従って、リリース領域１２ｃに保持されたこれらに対応する通常配布時のモジュールがいったんクライアント端末２０にコピーされることになるが、その後のステップＳ３７５の先行配布処理によって、先行配布対象のモジュールが再度上書きコピーされる。従って、例えば、翌日に当該クライアント端末２０を起動したのが、前日とは異なり先行配布の対象部署ではない部署に属するユーザであった場合は、ステップＳ３７５での先行配布処理が行われないため、クライアント端末２０のモジュールは自動的に通常配布時のものに戻った状態となる。

先行配布の後、モジュールの動作確認等が完了した場合は、上述したように、先行配布対象のモジュール用の削除リスト５を利用して、先行配布対象のモジュールをリリース領域１２から削除することで先行配布を終了・停止するとともに、対象のモジュールを実施の形態１で示した通常の手順にて全店に対して配布する（本番リリースする）ことで、容易に全店展開が可能である。先行配布から全店展開に移行する対象のモジュールを、リリース領域１２において先行配布対象のモジュールを保持する領域から、全店に配布するマスタのモジュールを保持する領域に直接移動させる手段を設けてもよい。

なお、本実施の形態では、特定の部署に先行配布して動作確認した後に全店展開という流れを対象としているが、例えば、特定のグループでの先行配布と動作確認を行った後、さらに上位の部署での先行配布と動作確認を行い、その後全店配布を行うというように先行配布の段階を増やしてより慎重なリリース手順とすることも可能である。

以上に示したように、本発明の実施の形態２であるモジュール配布システム１によれば、通常の全クライアント端末２０へのモジュール配布とは別に、特定の部署やユーザに属するクライアント端末２０への先行配布処理を行うことができる。また、先行配布の開始、先行配布の終了・停止と全クライアント端末２０への配布・展開の一連の処理を、管理サーバ１０からの指示により容易かつシームレスに行うことが可能となる。

＜実施の形態３＞
本発明の実施の形態３であるモジュール配布システムは、上述した実施の形態１もしくは２のモジュール配布システム１の機能に加えて、さらに、配布モジュールのサイズが大きい場合でも、モジュールを必要に応じて圧縮して配布し、クライアント端末２０側で解凍して展開することで、配布に要する時間やネットワークの負荷を最小限に抑制することを可能とするシステムである。なお、システム構成や基本となるモジュール配布処理の流れは実施の形態１と同様であるため再度の記載は省略する。

［圧縮配布処理］
図１２は、配布対象のモジュールを圧縮して配布する圧縮配布処理の例について概要を示した図である。本実施の形態では、配布担当者２が登録した配布モジュール３のサイズが所定の値（例えば１０メガバイト等）よりも大きい場合に、管理サーバ１０ａのパッケージングコマンド１６が、配布モジュール３を圧縮することによって圧縮パッケージ１８を作成する。圧縮に際しては、例えばＺＩＰ形式やＬＺＨ形式等の一般的な形式に対応した入手可能なツールやライブラリ等を使用することが可能である。

この圧縮パッケージ１８は、実施の形態１で示した通常のモジュール配布処理と同様の手順によって、リリース日にクライアント端末２０に圧縮された状態のまま配布される。クライアント端末２０では、リリースエージェント２３により圧縮パッケージ１８が解凍された後、通常のモジュール配布と同様の処理が行われる。

管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃのリリース領域１２に保持された圧縮パッケージ１８は、リリース日後の所定のタイミング（例えばリリース日の翌日）にリリースＰＧＭ１３によるメンテナンス処理によって解凍され、通常の配布パッケージ１７としてリリース領域１２に展開される。その際、解凍された圧縮パッケージ１８に対応する、過去に配布された古い配布パッケージ１７が存在する場合は削除する。

この古い配布パッケージ１７の削除処理では、上述した実施の形態２における先行配布対象のモジュールを削除するメンテナンス処理と同様に、実施の形態１の図３で示した削除リスト５を使用して、古い配布モジュール３をリリース領域１２から削除する仕組みを利用する。この削除リスト５は、パッケージングコマンド１６が圧縮パッケージ１８を作成する際に、圧縮パッケージ１８に含まれる配布モジュール３を対象として同時に作成する。

図１３は、圧縮配布処理におけるメンテナンス処理の例について概要を示した図である。リリース日当日においては、クライアント端末Ａ（２０ａ）は起動時に配布サーバから圧縮パッケージ１８を取り込み、解凍して配布パッケージ１７とした上で通常の配布処理に従って展開を行う。一方、クライアント端末Ｂ（２０ｂ）はリリース日に終始電源オフであり起動しなかったものとすると、圧縮パッケージ１８（および配布パッケージ１７）の取り込みは行われない。

リリース日後の最初の所定のタイミング（本実施の形態では翌日）では、上述したように、配布サーバ１０ｃではメンテナンス処理として、リリースＰＧＭ１３により圧縮パッケージ１８を解凍し、配布パッケージ１７として展開する。これは、圧縮パッケージ１８による配布はクライアント端末２０側での解凍の負荷が大きく、例えば、その後の通常時に新規クライアント端末２０の増設等が行われた際などに圧縮パッケージ１８によるモジュールの配布が行われると、クライアント端末２０での処理時間を要してしまうおそれがあることから、圧縮パッケージ１８による配布はアクセスが集中するリリース日近辺のみの対応とするのが望ましいためである。

配布サーバ１０ｃのリリース領域１２ｃでの圧縮パッケージ１８の解凍の際、パッケージに同梱されているメンテナンス用の削除リスト５によって、対応する古い配布パッケージ１７を削除する。また解凍済みの圧縮パッケージ１８も削除する。なお、当該メンテナンス処理は、リリースＰＧＭ１３が一時領域１１からリリース領域１２に翌日リリース対象の配布パッケージ１７をコピーする処理を行う前に実行する。実行順序が逆になると、新たにリリース領域１２ｃにコピーされた配布パッケージ１７のモジュールがある場合、圧縮パッケージ１８を解凍した際の古いモジュールによって上書きされてデグレードが生じる場合があるためである。

その後のクライアント端末２０への配布処理では、クライアント端末Ａ（２０ａ）は差分がないため何も取り込まない。一方、クライアント端末Ｂ（２０ｂ）は、このタイミングでリリース日以降始めて起動したとすると、リリース領域１２ｃで解凍されて非圧縮（大容量）となった配布パッケージ１７が差分となるため、これを新たに取り込むことになる。

さらにその後の所定のタイミング（本実施の形態ではリリース日＋１４日）では、クライアント端末２０におけるメンテナンス処理として、ローカル領域２２に保持された圧縮パッケージ１８を削除する（クライアント端末Ｂ（２０ｂ）では圧縮パッケージ１８が存在しないため何も行わない）。クライアント端末２０側の圧縮パッケージ１８を配布サーバ１０ｃ側よりも先のタイミングで削除してしまうと、次回の起動時に再度配布サーバ１０ｃから圧縮パッケージ１８を取り込んでしまい、その後の解凍と展開の負荷が大きくなってしまう。従って、配布サーバ１０ｃ側での圧縮パッケージ１８のメンテナンス処理（本実施の形態ではリリース日翌日）よりも後のタイミング（本実施の形態ではリリース日＋１４日）でクライアント端末２０側でのメンテナンス処理を行うようにする。

［処理フロー］
以下では、圧縮配布に係る一連の処理においてモジュール配布システム１の各プログラムが実行する処理の内容について説明する。なお、中継サーバ１０ｂおよび配布サーバ１０ｃの一時リリースＰＧＭ１４によってそれぞれ実行される一時リリース処理については、実施の形態１の図５で示した一時リリース処理の例と同様であるため説明は省略する。

図１４は、管理サーバ１０ａ、中継サーバ１０ｂおよび配布サーバ１０ｃのリリースＰＧＭ１３によってそれぞれ実行されるリリース処理の例について示したフローチャートである。ここでは、実施の形態２の図９に示したリリース処理の例に加えて、最初に、リリース領域１２に圧縮パッケージ１８が存在するか否かを確認する処理（Ｓ２０３）が追加されている。圧縮パッケージ１８が存在しなければ、そのままステップＳ２１０に移る。

ステップＳ２０３でリリース領域１２に圧縮パッケージ１８が存在する場合に、これらの圧縮パッケージ１８について上述したメンテナンス処理を行う圧縮メンテナンス処理（Ｓ２０５）がさらに追加されている。ここでは、圧縮パッケージ１８のリリース日から所定の期間（本実施の形態では１日）以上経過したものについて解凍処理を行い、生成された非圧縮の配布パッケージ１７をリリース領域１２にコピーする。

このとき、圧縮パッケージ１８にメンテナンス用の削除リスト５が存在するかを確認し（新規追加モジュールの圧縮配布の場合は存在しない場合もある）、削除リスト５がある場合はこれに基づいて圧縮パッケージ１８に対応する過去に配布した古い配布パッケージ１７に含まれるモジュールを削除する。また、解凍済みの圧縮パッケージ１８も削除する。また、その後のステップＳ２４０において一時領域１１からリリース領域１２に配布パッケージ１７をコピーする処理では、通常のパッケージのコピー処理に加えてさらに、圧縮パッケージ１８を一時領域１１からリリース領域１２へコピーする処理を行う。

図１５は、クライアント端末２０のリリースエージェント２３によって実行される配布処理の例について示したフローチャートである。ここでは、実施の形態２の図１０に示した配布処理の例に加えて、ステップＳ３７５において先行配布処理を行った後に、図１３に示した、圧縮パッケージ１８を解凍・展開し、不要なものを削除する圧縮パッケージ展開処理（Ｓ３７７）が追加されている。

図１６は、図１５のステップＳ３７７の圧縮パッケージ展開処理の例について示したフローチャートである。圧縮パッケージ展開処理では、まず、ローカル領域２２に取り込んだパッケージに圧縮パッケージ１８が存在するか確認する（Ｓ３７７−１）。圧縮パッケージ１８が存在しなければ処理を終了する。圧縮パッケージ１８が存在する場合は、その一覧を作成し（Ｓ３７７−２）、各圧縮パッケージ１８について過去に解凍済みであるかを確認する（Ｓ３７７−３）。解凍済みか否かの確認には、例えば、解凍処理の結果を記録する解凍履歴ファイルを設けてこれを参照するなどの手段をとることができる。

解凍履歴ファイルに解凍実績がある、すなわち過去に解凍済みである場合は、ステップＳ３７７−７へ移る。解凍実績がない場合は、圧縮パッケージ１８を解凍する（Ｓ３７７−４）。解凍に際しては、管理サーバ１０ａでの圧縮時と同様に、例えばＺＩＰ形式やＬＺＨ形式等、圧縮時の形式に対応した一般的に入手可能なツールやライブラリ等を使用することが可能である。その後、解凍されたモジュールについて、所定の場所に配置したり、インストール用のプログラムを実行したりするなどして、クライアント端末２０に反映させる（Ｓ３７７−５）。また、ステップＳ３７７−４で解凍した圧縮パッケージ１８の情報を、解凍履歴として解凍履歴ファイル等に追記する（Ｓ３７７−６）。

その後、ステップＳ３７７−７で、各圧縮パッケージ１８がもはや不要であり削除対象に該当するものであるかを判定する。ここでは、図１３に示したように、対象の圧縮パッケージ１８についてリリース日から所定の期間以上経過したものについては、削除対象に該当するとして、対象の圧縮パッケージ１８を削除し（Ｓ３７７−８）、処理を終了する。なお、ステップＳ３７７−７での所定の期間は、図１４のステップＳ２０５の圧縮メンテナンス処理において圧縮パッケージ１８を解凍する際の判定に使用する期間（本実施の形態では１日）よりも長い期間であり、クライアント端末２０への反映を実施するのに十分な期間（本実施の形態では１４日）とする。

以上に示したように、本発明の実施の形態３であるモジュール配布システム１によれば、配布モジュールのサイズが所定の値よりも大きい場合はこれを圧縮して圧縮パッケージ１８としてクライアント端末２０に配布する。これにより、配布モジュールのサイズが大きい場合でも配布に要する時間とネットワークへの負荷を最小限に抑制することが可能となる。また、リリース領域１２に保持された圧縮パッケージ１８を解凍して通常の配布パッケージ１７に戻したり、クライアント端末２０に配布済みの圧縮パッケージ１８を削除したり等のメンテナンス処理を適切な順序とタイミングで行うことで、不要な処理や記憶領域の容量の浪費を回避することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、上述した実施の形態２における先行配布と、実施の形態３における圧縮配布とを組み合わせて、圧縮パッケージ１８を特定の部署やユーザに属するクライアント端末２０に先行配布するというような構成をとることも可能である。

本発明は、複数拠点の多数のクライアント端末に対して同日など一斉のタイミングでモジュールを配布するモジュール配布システムに利用可能である。

１…モジュール配布システム、２…配布担当者、３…配布モジュール、４…広域ネットワーク、５…削除リスト、
１０ａ…管理サーバ、１０ｂ…中継サーバ、１０ｃ…配布サーバ、
１１ａ〜ｃ…一時領域、１２ａ〜ｃ…リリース領域、１３ａ〜ｃ…リリースプログラム（ＰＧＭ）、１４ｂ、ｃ…一時リリースプログラム（ＰＧＭ）、１５ａ〜ｃ…リリース履歴、１６…パッケージングコマンド、１７…配布パッケージ、１８…圧縮パッケージ、
２０、２０ａ、ｂ、ｘ、ｙ…クライアント端末、２２、２２ｘ、ｙ…ローカル領域、２３…リリースエージェント。

Claims (10)

1. 複数の拠点にそれぞれ配置された多数のクライアント端末に対してセンターから各種のモジュールを配布するモジュール配布システムであって、
   前記センター側に配置され、指定された配布日および配布対象のモジュールに基づいて配布パッケージを作成して第１の一時記憶領域に保持する管理サーバと、
   前記センター側に配置され、前記管理サーバと接続し、日次の第１のタイミングで、前記管理サーバの前記第１の一時記憶領域から前記配布パッケージを取得して第２の一時記憶領域に保持する１つ以上の中継サーバと、
   前記各拠点に配置され、前記中継サーバの１つと接続し、１つ以上の前記クライアント端末が接続され、前記第１のタイミングより後の日次の第２のタイミングで、自身が接続する前記中継サーバの前記第２の一時記憶領域から前記配布パッケージを取得して第３の一時記憶領域に保持し、前記第２のタイミングより後の日次の第３のタイミングで、前記第３の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第１のリリース記憶領域に保持する１つ以上の配布サーバとを有し、
   前記クライアント端末は、日次の起動時に実行されるリリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から前記配布パッケージに含まれるモジュールを取得してローカル記憶領域に保持し、自身に反映させることを特徴とするモジュール配布システム。
2. 請求項１に記載のモジュール配布システムにおいて、
   前記クライアント端末の前記リリースプログラムは、自身が接続する前記配布サーバの前記第１のリリース記憶領域に保持された前記配布パッケージに含まれるモジュールについて、前記ローカル記憶領域に保持されたモジュールとファイル名、ファイルサイズ、およびタイムスタンプの少なくとも１つに差異があるモジュールのみを取得することを特徴とするモジュール配布システム。
3. 請求項１または２に記載のモジュール配布システムにおいて、
   配布対象のモジュールに加えて、もしくはこれに替えて、削除対象のモジュールの情報を含む削除リストが指定された場合、
   前記配布サーバは、前記第３のタイミングで、前記削除リストに含まれたモジュールを前記第１のリリース記憶領域から削除することを特徴とするモジュール配布システム。
4. 請求項１〜３のいずれか１項に記載のモジュール配布システムにおいて、
   前記管理サーバは、前記第３のタイミングで、前記第１の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第２のリリース記憶領域に保持し、
   前記中継サーバは、前記第３のタイミングで、前記第２の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第３のリリース記憶領域に保持することを特徴とするモジュール配布システム。
5. 請求項１〜４のいずれか１項に記載のモジュール配布システムにおいて、
   前記管理サーバは、特定のグループに属する前記クライアント端末もしくはユーザに対してのみ先行配布するモジュールの指定に基づいて先行配布対象の前記配布パッケージを作成し、
   前記配布サーバは、前記第３のタイミングで、前記第３の一時記憶領域から配布日が翌日である前記配布パッケージを取得して第１のリリース記憶領域に保持する際に、先行配布対象の前記配布パッケージについては、前記第１のリリース記憶領域における先行配布用の領域に、前記特定のグループが識別可能となるように保持し、
   前記クライアント端末は、前記リリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から前記配布パッケージに含まれるモジュールを取得して前記ローカル記憶領域に保持し、自身に反映させた後、さらに、前記第１のリリース領域における先行配布用の領域に、自身が属するグループに対する先行配布対象の前記配布パッケージが存在する場合は、これを取得して前記前記ローカル記憶領域に上書き保持し、自身に反映させることを特徴とするモジュール配布システム。
6. 請求項５に記載のモジュール配布システムにおいて、
   配布対象のモジュールに加えて、もしくはこれに替えて、先行配布が終了したため削除対象とする先行配布対象のモジュールの情報を含む先行配布用の削除リストが指定された場合、
   前記配布サーバは、前記第３のタイミングで、前記先行配布用の削除リストに含まれたモジュールを前記第１のリリース記憶領域における先行配布用の領域から削除することを特徴とするモジュール配布システム。
7. 請求項１〜６のいずれか１項に記載のモジュール配布システムにおいて、
   前記管理サーバは、指定された配布対象のモジュールの容量が所定の値よりも大きい場合はこれらを圧縮して前記配布パッケージを作成して前記第１の一時記憶領域に保持し、
   前記クライアント端末は、前記リリースプログラムにより、自身が接続する前記配布サーバの前記第１のリリース記憶領域から圧縮された前記配布パッケージを取得してこれを解凍し、解凍された前記配布パッケージに含まれるモジュールを取得してローカル記憶領域に保持し、自身に反映させることを特徴とするモジュール配布システム。
8. 請求項７に記載のモジュール配布システムにおいて、
   前記配布サーバは、前記第３のタイミングで、前記第１のリリース記憶領域に存在する圧縮された前記配布パッケージのうち、配布日から第１の期間以上経過したものについては、これを解凍して前記第１のリリース記憶領域に保持することを特徴とするモジュール配布システム。
9. 請求項８に記載のモジュール配布システムにおいて、
   前記管理サーバは、圧縮された前記配布パッケージを作成する際に、前記配布パッケージに対応するため削除対象とする過去のモジュールの情報を含む圧縮配布用の削除リストを作成し、
   前記配布サーバは、前記第３のタイミングで、圧縮された前記配布パッケージを解凍する際に、前記圧縮配布用の削除リストに含まれたモジュールを前記第１のリリース記憶領域から削除することを特徴とするモジュール配布システム。
10. 請求項７〜９のいずれか１項に記載のモジュール配布システムにおいて、
    前記クライアント端末は、前記リリースプログラムにより、前記ローカル記憶領域に保持された圧縮された前記配布パッケージのうち、配布日から前記第１の期間よりも長期の第２の期間以上経過したものについては、これを削除することを特徴とするモジュール配布システム。