JP2002014817A - ファイル配布システム - Google Patents

Abstract

(57)【要約】 【課題】 サーバが有するファイルを効率よくクライア
ントに配布することが可能なファイル配布システムを提
供する 【解決手段】 プログラム管理コンポーネント１０４
は，プログラム配布サーバ１０８と連携して動作し，ダ
ウンロードしたプログラム・モジュール群１０７を第１
のファイルシステム１０２に格納する機能を有する。モ
ジュール・テーブル１０６は，配布の対象となるプログ
ラム・モジュール群１０７に関する情報が記載されるテ
ーブルであり，プログラム配布に先立ちシステム管理者
によってあらかじめ本ファイル配布システムの利用者ご
とに用意される。プログラム配布サーバ１０８は，プロ
グラム管理コンポーネント１０４からのダウンロード要
求に応じて，第２のファイルシステム１０５に格納され
たファイルを提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，コンピュータネッ
トワークを介してファイルを複数のコンピュータ上に配
布するシステム，特に複数のモジュール群により構成さ
れたプログラム・ファイルをインターネット等のコンピ
ュータ・ネットワークを用いて配布するファイル配布シ
ステムに関するものである。

【０００２】

【従来の技術】従来，インターネット等のコンピュータ
・ネットワークを利用して更新されたソフトウェアを配
布するシステムとしては，文献１に開示されるものがあ
た。

【０００３】文献１．特開平１１−２７２４５４号公報
「コンピュータ・ネットワークを通してソフトウェア更
新を配布する装置」

【０００４】文献１に記載されているシステムによれ
ば，プログラムが動作するコンピュータ上に，プログラ
ムアップデートのためのコンポーネント（アップデータ
・コンポーネント）が配置され，このアップデータ・コ
ンポーネントが，プログラムを配布するサーバに自動的
にアクセスする。プログラムの更新が自動化されるた
め，利用者の負担が軽減されることになる。

【０００５】コンピュータ・ネットワークを利用した分
散オブジェクト技術には，文献２に開示されているJava
リモートメソッド起動技術（Java Remote Method Invoc
ation：以下，「RMI」という）がある。

【０００６】文献２．「Java Remote Method Invocatio
nの仕様」第３．４節（JDK2 SDKの添付資料） Sun Mic
rosystems,Inc.

【０００７】RMIは，コンピュータ・ネットワーク上に
複数のサービスを提供するサーバを配置し，これらをロ
ーカルなオブジェクトと同様に利用するための分散オブ
ジェクト技術である。ネットワーク上に分散された複数
のサーバを利用するためには，各サーバが提供するアク
セス用のコードをクライアントがサーバの利用に先立っ
て入手する必要がある。

【０００８】ところが，複数のサーバがネットワーク上
に広域に分散している場合，RMIクライアントにとっ
て，予めアクセス用コードの入手先に関する情報を管理
することは非常に困難となる。このため，RMIは「クラ
スの動的なロード」と呼ばれる技術を提供している。こ
れは，クライアントがあるサーバを利用する時点で，動
的にそのサーバが提供するアクセス用のプログラムをダ
ウンロードする技術である。この技術により，RMIクラ
イアントは事前にアクセス用のコードを持たなくても，
サーバにアクセスすることが可能となる。

【０００９】一般的に，RMIがダウンロードするファイ
ルには「JARファイル」と呼ばれるアーカイブ形式が使
用される。文献３および文献４に，JARファイル形式に
関する情報が開示されている。

【００１０】文献３．「JARガイド」（JDK2 SDKの添付
資料） Sun Microsystems,Inc.

【００１１】文献４．「Java製品のバージョン管理の仕
様」（JDK2 SDKの添付資料） Sun Microsystems,Inc.

【００１２】JARファイル形式は以下の特徴を備えてい
る。

【００１３】１．複数のファイルを一つのアーカイブと
してまとめることができる。また，作成時に汎用的な可
逆符号化を用いて，ファイル容量を小さくすることが可
能である。

【００１４】２．アーカイブの対象となるファイルはJa
vaクラスファイルに限らず，あらゆるファイルが対象と
なり得る。通常，RMIのアクセス用のコードには，スタ
ブクラス，グラフィカル・ユーザ・インターフェイス
（GUI）クラス，GUIクラスで使用する多国語対応の表示
用リソース情報などが含まれる。

【００１５】３．JARファイルごとに管理用のメタ情報
を追加することが可能である。このメタ情報はマニフェ
スト情報と呼ばれる。マニフェスト情報には，各クラス
ファイルの改ざん防止のためのメッセージ・ダイジェス
トやバージョン情報などが含まれる。

【００１６】

【発明が解決しようとする課題】しかしながら，文献１
に記載の従来技術によれば，アップデータ・コンポーネ
ントは，予め関連付けられたソフトウェアのみを更新の
対象とし，ネットワーク上に新たに登録されたサーバを
利用するためのアクセス用コードなどを更新の対象とし
ない。したがって，アップデータ・コンポーネントによ
るプログラムの自動配布システムを用いた場合，利用者
の負担を軽減することは可能であるが，更新プログラム
を管理する管理者の負担は変わらない。更新対象となる
ファイルに関するリストの作成は相変わらず管理者が手
作業で行う必要がある。

【００１７】一方，文献２に記載の「RMIの動的なクラ
スロード技術」によれば，ダウンロードしたファイルを
使用するのは，そのコードをダウンロードしたJava仮想
マシンに限られる。したがって，次に同じクライアント
・ソフトウェアを起動したとき，サーバ側のコードの更
新状態に関わらず，クライアントは常にコードのダウン
ロード処理を行ってしまう。インターネットなど比較的
低速なコンピュータ・ネットワークを利用してクライア
ントがサーバに接続する場合，ソフトウェアの起動に長
時間を要するなどの問題が発生する。

【００１８】本発明は，上記のような問題点に鑑みてな
されたものであり，その目的は，サーバが有するファイ
ルを効率よくクライアントに配布することが可能なファ
イル配布システムを提供することにある。

【００１９】

【課題を解決するための手段】上記課題を解決するため
に，請求項１によれば，配布の対象となる１または２以
上のファイルと１または２以上のファイルに関する情報
が記載されたファイル情報テーブルとを格納するファイ
ル配布側格納手段と，ファイル配布側格納手段に格納さ
れている１または２以上のファイルとファイル情報テー
ブルを，ネットワークを経由して配布するファイル配布
手段と，ファイル情報テーブルの内容に基づき，ファイ
ル配布側格納手段に格納されている１または２以上のフ
ァイルの中から１または２以上のファイルを選択し，フ
ァイル配布手段に対して選択した１または２以上のファ
イルの配布を要求し，ファイル配布手段によって配布さ
れた１または２以上のファイルをファイル被配布側格納
手段に格納するファイル管理手段と，を備えたことを特
徴とするファイル配布システムが提供される。

【００２０】かかる構成によれば，ファイル管理手段が
ファイル配布側格納手段に格納されている１または２以
上のファイルの中から１または２以上のファイルを選択
し，自動的にファイル被配布側格納手段に格納する。例
えば，ファイル配布側格納手段がファイル・サーバのフ
ァイルシステムであり，ファイル被配布側格納手段がク
ライアント・コンピュータのファイルシステムである場
合，ファイル管理手段によって，利用者（クライアン
ト）に負担をかけることなく，所望するファイルをファ
イル・サーバからクライアントにダウンロードすること
が可能となる。

【００２１】請求項２に記載のように，ファイル情報テ
ーブルには，少なくとも，１または２以上のファイルの
ファイル名と，ファイル管理手段に配布された後の１ま
たは２以上のファイルの操作に関する操作情報と，ファ
イル管理手段がファイル配布手段に対して行う１または
２以上のファイルの配布要求に用いられる要求情報と，
が記載されることが好ましい。このファイル情報テーブ
ルを参照することによって，ファイル管理手段は，ファ
イル配布手段に対して適切なファイルの配布を要求する
ことが可能となる。

【００２２】請求項３によれば，ファイル管理手段は，
要求情報に所望するバージョン情報を追加して，ファイ
ル配布手段に対して１または２以上のファイルの配布を
要求するためのコマンドを生成する。このようにコマン
ドにバージョン情報が追加されることによって，クライ
アントが所望するバージョンのファイルがファイル配布
側格納手段に存在する場合にのみ，そのファイルの配布
が行われることになる。したがって，不必要なファイル
の配布処理が行われず，ファイルの配布によるネットワ
ークトラフィックの増加が最小限に抑えられる。

【００２３】請求項４に記載のように，ファイル管理手
段は，正規表現またはワイルドカードの少なくともいず
れか一方を用いて，ファイル配布側格納手段に格納され
ている１または２以上のファイルの中から２以上のファ
イルを同時に選択することが好ましい。ファイル管理手
段は，複数のファイルを同時に効率よく管理することが
可能となる。

【００２４】請求項５に記載のように，ファイル配布側
格納手段は，ファイル配布側格納手段に格納されている
１または２以上のファイルの各バージョン情報が記載さ
れたバージョン情報付きファイル情報テーブルを格納す
ることが好ましい。かかる構成によれば，ファイル管理
手段は，ファイル被配布側格納手段に格納されているフ
ァイルとバージョン情報付きファイル情報テーブルとの
内容を比較し，ファイル配布側格納手段に格納されてい
るより新しいファイルのみを配布するように，ファイル
配布手段に要求することが可能となる。これによって，
不必要なファイル（バージョンの古いファイル等）の配
布が防止され，ファイルの配布処理の効率がより向上す
る。

【００２５】請求項６に記載のように，ファイル配布手
段がバージョン情報付きファイル情報テーブルを生成す
ることによって，バージョン情報付きファイル情報テー
ブルに記載されるバージョン情報は，常に最新の状態に
保持される。また，ファイル配布側格納手段に格納され
ている各ファイル間の関連性（依存関係）をバージョン
情報付きファイル情報テーブルに記載することも可能と
なる。

【００２６】

【発明の実施の形態】以下に添付図面を参照しながら，
本発明にかかるファイル配布システムの好適な実施の形
態について詳細に説明する。なお，以下の説明および添
付された図面において，略同一の機能および構成を有す
る構成要素については，同一符号を付することによって
重複説明を省略する。

【００２７】［第１の実施の形態］本発明の第１の実施
の形態にかかるファイル配布システムの構成を図１に示
す。

【００２８】１０１は，Java言語によって作成された任
意のアプリケーション・ソフトウェアである。このアプ
リケーションは単体で動作するものであっても，ネット
ワーク上に存在するサーバと通信して処理を行ういわゆ
るクライアント・プログラムであってもよい。

【００２９】１０２は，アプリケーション１０１が動作
するコンピュータ上に存在する第１のファイルシステム
である。第１のファイルシステム（ファイル被配布側格
納手段）１０２内に配布の対象となるアプリケーション
１０１のプログラムが格納される。このプログラムは単
一のアーカイブ・ファイルで構成されるとは限らない。
複数のプログラム・モジュール群１０３から構成される
場合もある。このようにプログラムを複数のモジュール
に分割することにより，モジュール単位でのアプリケー
ション間のコード共有が容易となる。各モジュールはJA
Rファイルとしてまとめられ，バージョン情報のメタ情
報が付加される。

【００３０】プログラム管理コンポーネント（ファイル
管理手段）１０４は，アプリケーション１０１が動作す
るコンピュータあるいはそのコンピュータと同じネット
ワーク・サイト内で動作するコンピュータ上で動作する
プログラムである。このプログラムは，プログラム配布
サーバ（ファイル配布手段）１０８と連携して動作し，
ダウンロードしたプログラム・モジュール群１０７を第
１のファイルシステム１０２に格納する機能を有する。

【００３１】第２のファイルシステム（ファイル配布側
格納手段）１０５は，プログラムの提供元のネットワー
ク・サイト内に存在するデータ格納手段である。第２の
ファイルシステム１０５には，モジュール・テーブル
（ファイル情報テーブル）１０６と，プログラム・モジ
ュール群１０７が格納される。

【００３２】モジュール・テーブル１０６は，配布の対
象となるプログラム・モジュール群１０７に関する情報
が記載されるテーブルであり，プログラム配布に先立ち
システム管理者によってあらかじめ本ファイル配布シス
テムの利用者ごと，あるいは利用者群ごとに用意され
る。

【００３３】プログラム・モジュール群１０７は，配布
対象となるプログラム・モジュール（ファイル）の集合
であり，このモジュール群の一部が選択的に各利用者に
配布される。

【００３４】プログラム配布サーバ１０８は，第２のフ
ァイルシステム１０５に格納されている情報を提供する
サーバであり，プログラム管理コンポーネント１０４か
らのダウンロード要求に応じて，第２のファイルシステ
ム１０５に格納されたファイルを提供する。

【００３５】以上のように構成された本実施の形態にか
かるファイル配布システムのプログラム更新に関する動
作を工程順に説明する。

【００３６】＜ステップ１＞システム管理者は，配布の
対象となるプログラム・モジュール群１０７およびモジ
ュール・テーブル１０６を第２のファイルシステム１０
５に登録する。

【００３７】＜ステップ２＞プログラム管理コンポーネ
ント１０４は，プログラム配布サーバ１０８に対して，
利用者”Ａ”に割り当てられたモジュール・テーブル１
０６のダウンロードを要求する。このダウンロードの要
求は，予め設定された周期で行ういわゆるポーリング方
式に基づいて実行されること，あるいは，アプリケーシ
ョン１０１の起動ごとに実行されることが好ましい。こ
の場合，プログラム管理コンポーネント１０４は，サー
バ・デーモンとして常時動作するように構成されるか，
または，アプリケーション１０１に組み込まれ，同期的
に起動するように構成される。

【００３８】＜ステップ３＞プログラム管理コンポーネ
ント１０４からのリクエストを受け付けたプログラム配
布サーバ１０８は，要求に応じたモジュール・テーブル
１０６を要求元であるプログラム管理コンポーネント１
０４に送る。モジュール・テーブル１０６の例を以下に
示す。

【００３９】# Module table for user "A" foo-dl.jar::/LATEST?Regex-Path=/foo/.+/foo-dl\.jar
$ bar-dl.jar:notrace:/LATEST?Wildcard-Path=/bar/*/ba
r-dl.jar setup.jar:unzip,notrace:/VERSION?Path=/setups/user
A/setup.jar

【００４０】このモジュール・テーブル１０６の記述に
関する規則は以下の通りである。

【００４１】・モジュール・テーブル１０６の各行に一
つのダウンロード情報を記述する。

【００４２】・各ダウンロード情報は，”：”によって
区切られた３つのフィールド，「JARファイル名：操作
情報：要求情報」から構成される。

【００４３】・「JARファイル名」は，ダウンロード
後，第１のファイルシステム１０２に格納する際のファ
イル名を示す。

【００４４】・「操作情報」は，ダウンロード後の操作
を示す付加情報で，一つまたは”，”によって区切られ
た複数の操作情報で構成される。

【００４５】・「要求情報」は，ファイルのダウンロー
ドに用いるリクエストのテンプレートを指定するフィー
ルドである。

【００４６】HTTP(HyperText Transfer Protocol)をダ
ウンロードのプロトコルとして用いる場合の「要求情
報」の書式は以下の通りである。なお，「要求情報」の
書式を複数行に分けて記載したが，本来は一行のコマン
ドとして発行される。

【００４７】/{VERSION｜LATEST} ?{Regex-Path｜Wildcard-Path｜Path}=パス名 [&‘R?≪?L?[=属性値][&...]

【００４８】ここで書式における各用語の意味を説明す
る。

【００４９】・VERSION 要求したパス名にマッチするすべてのJARファイルから
指定のマニフェスト属性情報に厳密にマッチする属性を
持つJARファイルを返す。マッチするJARファイルが複数
存在する場合には，JARファイルのタイムスタンプを比
較して最近に更新されたJARファイルを返す。

【００５０】・LATEST 要求したパス名にマッチするすべてのJARファイルから
指定のマニフェスト属性情報よりも新しいバージョン情
報を持つJARファイルを返す。具体的には，指定のマニ
フェスト属性情報にマッチする属性を備え，かつ，具備
する属性値が指定のマニフェスト属性値よりも辞書順で
後となるJARファイルだけをマッチしたものとみなす。
マッチしたJARファイルが複数存在する場合には，属性
値が辞書順で後になるJARファイルすなわち最も大きな
バージョン情報を持つJARファイルを返す。

【００５１】・Regex-Path ファイルをダウンロードする際のパス名として，URL(Un
iform Resource Locator)に正規表現を使用することを
示すオプション。

【００５２】・Wildcard-Path ファイルをダウンロードする際のパス名として，URLに
シェルのワイルドカードを使用することを示すオプショ
ン。

【００５３】・Path ファイルをダウンロードする際のパス名として通常のUR
Lを使用することを示すオプション。

【００５４】・属性キーと属性値 属性キーとその値との対によって表現される属性情報。
この属性情報によって，マニフェスト・ファイル内に記
載されている任意の属性情報を指定することが可能であ
る。

【００５５】次に，「操作情報」の例を示す。

【００５６】・unzip ダウンロードしたモジュールの展開を指定する操作情
報。アプリケーションの起動スクリプトなど，アーカイ
ブ化されたままでは意味がない（機能しない）ファイル
を配布する際に指定される。

【００５７】・notrace JARファイル間の依存関係を示すマニフェスト属性にお
けるClass-Pathフィールドを無視するための操作情報。
後述の通り，本実施の形態にかかるファイル配布システ
ムでは，プログラム・モジュール間の依存関係は，Clas
s-Path属性のトレース（追跡）により自動的に解決され
る。これによって，アプリケーションの動作に必要なプ
ログラム・モジュール群は，一貫性が保持されつつダウ
ンロードされる。この操作情報は，自動的な依存関係の
追跡を明示的に停止する場合に使用される。

【００５８】・delete 配布モジュールをクライアントの端末上から削除するた
めの操作情報。バージョンアップに伴い不必要となった
プログラム・モジュールを削除する場合などに使用され
る。

【００５９】＜ステップ４＞モジュール・テーブル１０
６を獲得したプログラム管理コンポーネント１０４は，
獲得したモジュール・テーブル１０６に記述されている
各ダウンロード情報に応じて，＜ステップ４−Ａ＞また
は＜ステップ４−Ｂ＞のいずれかの動作を行う。

【００６０】＜ステップ４−Ａ＞要求情報（ダウンロー
ド情報の第３フィールド）が，”/LATEST”から始ま
り，かつ，既に同名のファイルがクライアントの第１の
ファイルシステム１０２に存在している場合には，その
ファイルのバージョン情報を要求情報のオプションとし
て，そのファイルを獲得するためのHTTPのGETリクエス
トを発行する。

【００６１】上記のモジュール・テーブル１０６の最初
（コメント行の次の行）のダウンロード情報からは，例
えば，次のGETリクエストが生成される。

【００６２】 GET /LATEST?Regex-Path=/foo/,+/foo-dl\.jar$ &Specification-Version=1.0 &Package-Version=build100

【００６３】このGETリクエストは，既にクライアント
にダウンロードされている同名のファイルのマニフェス
ト情報にバージョン情報として，”Specification-Vers
ion:1.0”と”Package-Version:build100”が定義され
ている場合に生成される一例である。

【００６４】ここでバージョン情報として使用されるマ
ニフェスト・ファイルの属性は，”Specification-Vers
ion”，”Package-Version”の２つであり，この順でオ
プション指定が行われる。これらの情報がマニフェスト
・ファイルに記述されていない場合には，オプション指
定は行われない。

【００６５】＜ステップ４−Ｂ＞それ以外の場合（同名
のファイルを所有していない場合，または，要求情報
が”/LATEST”以外の文字列から始まっている場合），
要求情報の文字列をそのまま使用してファイルのダウン
ロード要求を発行する。

【００６６】上記のモジュール・テーブル１０６の最初
（コメント行の次の行）のダウンロード情報がこの条件
に合致する場合，例えば，次のGETリクエストが生成さ
れる。

【００６７】 GET /LATEST?Regex-Path=/foo/.+/foo-dl\.jar$

【００６８】＜ステップ５＞プログラム配布サーバ１０
８は，プログラム管理コンポーネント１０４からのダウ
ンロード要求を受けてファイルを検索する。要求に該当
するファイルが存在する場合には，そのファイル（プロ
グラム・モジュール１０７）を読み出して送り返す。一
方，要求に該当するファイルが見つからない場合には，
空の応答を返す。これによって，クライアントが所有す
るファイルより新しいファイルがサーバ上に存在する場
合にのみファイルの転送が行われることになる。また，
VERSIONリクエストを使用することによって，配布ファ
イルを明示的に古いバージョンに差し戻すことも可能で
ある。

【００６９】＜ステップ６＞プログラム管理コンポーネ
ント１０４は，プログラム配布サーバ１０８からの転送
データを一時的なファイル名で第１のファイルシステム
１０２に保存する。このとき，一時的なファイル名と本
来の名称（ダウンロード情報に記載されているファイル
名）との変換情報をハンドル情報とともに別ファイルに
書き出しておく。

【００７０】＜ステップ７＞ダウンロードしたJARファ
イルがClass-Path属性を持っている場合には，その情報
に従って＜ステップ４＞と同様の方法によって依存関係
にあるファイルをロードする。

【００７１】＜ステップ８＞すべてのファイル転送が終
了した時点でプログラム管理コンポーネント１０４は，
アプリケーション１０１に転送が正常に終了したことを
通知する。この通知を受けたアプリケーション１０１
は，利用者に対して，ファイルのバージョンアップが存
在すること，クライアントアプリケーション１０１を一
旦終了することを確認する。

【００７２】＜ステップ９＞アプリケーション１０１が
終了した時点で，プログラム管理コンポーネント１０４
は，＜ステップ６＞において作成したファイル名の変更
情報を読み出して，ファイル名の変更を行う。また，操
作情報に応じてアーカイブの展開やファイルの削除処理
を行う。

【００７３】ここで，本実施の形態にかかるファイル配
布システムによるプログラムの更新処理が完了する。

【００７４】以上説明したように本実施の形態にかかる
ファイル配布システムによれば，利用者のコンピュータ
上にプログラム管理コンポーネント１０４が配置される
ため，サーバ側の第２のファイルシステム１０５に登録
したプログラム・モジュール１０７を利用者に負担をか
けることなく，自動的に利用者のコンピュータにダウン
ロードすることが可能となる。

【００７５】ダウンロードの際，サーバ側のモジュール
・テーブル１０６によって配布の対象となるファイルを
制御することができるため，既存のアプリケーションの
アップデートはもちろん，新規アプリケーションの追
加，あるいは既存アプリケーションの削除が容易とな
る。

【００７６】モジュール・テーブル１０６に記録するダ
ウンロード情報に，正規表現およびワイルドカードの使
用が可能なため，複数の配布ファイルを同時に管理する
ことが容易となる。例えば，モジュール・テーブル１０
６に，

【００７７】 foo.jar::/LATEST?Wildcard-Path=/foo/*/foo.jar

【００７８】というダウンロード情報が記載されている
場合，サーバ側の第２のファイルシステム１０５に存在
する２つのファイル，

【００７９】/foo/version-1.0/foo.jar /foo/version-1.1/foo.jar

【００８０】のどちらも上記の要求情報”/foo/*/foo.j
ar”にマッチする。ディレクトリversion-1.1の下にあ
るfoo.jarファイル内のマニフェスト情報に，ディレク
トリversion-1.0の下のfoo.jarファイルよりも新しいバ
ージョン情報が適切に設定されていれば，LATEST要求に
対してディレクトリversion-1.1の下のfoo.jarファイル
が返される。このように，本実施の形態にかかるファイ
ル配布システムによれば，複数のマッチするファイルか
ら最新のファイルを探し出して返すことが可能となる。

【００８１】また，最新のファイルを配布する通常の利
用方法のもとでは，ファイルのバージョンアップのたび
にモジュール・テーブル１０６を更新する必要がなくな
り，システム管理者の負担が軽減する。

【００８２】さらに，本実施の形態にかかるファイル配
布システムにおいて，モジュール・テーブル１０６に記
載されているダウンロード情報の「要求情報」項の記述
形式は，HTTPの拡張記述形式に準拠している。したがっ
て，プログラム配布サーバ１０８には，一般的なWWWサ
ーバが備えるセキュリティ機構をそのまま適用すること
が可能となる。

【００８３】［第２の実施の形態］本発明の第２の実施
の形態にかかるファイル配布システムの構成を図２に示
す。

【００８４】本実施の形態にかかるファイル配布システ
ムは，第１の実施の形態にかかるファイル配布システム
に対して，新たなコンポーネントとしてバージョン情報
付きモジュール・テーブル（バージョン情報付きファイ
ル情報テーブル）２０９が追加された構成を有する。

【００８５】バージョン情報付きモジュール・テーブル
２０９は，モジュール・テーブル１０６の内容に基づ
き，プログラム配布サーバ１０８によって自動的に作成
され，第２のファイルシステム１０５に格納されるファ
イルである。バージョン情報付きモジュール・テーブル
２０９には，モジュール・テーブル１０６に記述されて
いる各プログラム・モジュール１０７の依存関係が展開
されており，さらに，それぞれのファイルのバージョン
情報が追記されている。

【００８６】以上のように構成された本実施の形態にか
かるファイル配布システムのプログラム更新に関する動
作を工程順に説明する。

【００８７】＜ステップ１＞システム管理者は，配布の
対象となるプログラム・モジュール群１０７およびモジ
ュール・テーブル・ファイル１０６を第２のファイルシ
ステム１０５に登録する。

【００８８】＜ステップ２＞プログラム配布サーバ１０
８は，プログラム・モジュール群１０７およびモジュー
ル・テーブル１０６の更新に関する情報を，オペレーテ
ィング・システム（OS）からの通知，あるいは，所定の
間隔で第２のファイルシステム１０５のディレクトリを
検査すること，等によって取得する。いずれかの方法に
よってプログラム・モジュール群１０７あるいはモジュ
ール・テーブル１０６の更新情報を得たプログラム配布
サーバ１０８は，これらの更新情報に基づき，バージョ
ン情報付きモジュール・テーブル２０９を作成する。

【００８９】例えば，第２のファイルシステム１０５に
登録されたモジュール・テーブル１０６が以下の内容で
ある場合，

【００９０】# Module table for user "A" foo-dl.jar::/LATEST?Regex-Path=/foo/.+/foo-dl\.jar
$ bar-dl.jar:notrace:/LATEST?Wildcard-Path=/bar/*/ba
r-dl.jar setup.jar:unzip,notrace:/VERSION?Path=/setups/user
A/setup.jar

【００９１】このファイルから生成されるバージョン情
報付きモジュール・テーブル２０９は，例えば次のよう
な内容となる。

【００９２】# Version module table for user "A" foo-dl.jar::/foo/version-1.1/foo-dl.jar:Specificat
ion-Version="1.1",Package-Version="build100" foo-core.jar::/foo/version-1.1/foo-core.jar:Specif
ication-Version="1.0",Package-Version="build30" bar-dl.jar:notrace:/bar/barl/bar-dl.jar:Specificat
ion-Version="1.0",Package-Version="build23" setup.jar:unzip,notrace:/setups/userA/setup.jar:La
stModified="2000 05 0515:32:21"

【００９３】バージョン情報付きモジュール・テーブル
２０９の各ダウンロード情報は，”：”によって区切ら
れた４つのフィールド「JARファイル名：操作情報：要
求情報：属性情報」から構成される。

【００９４】「JARファイル名」および「操作情報」に
ついては，モジュール・テーブル１０６と略同一の形式
が用いられる。

【００９５】バージョン情報付きモジュール・テーブル
２０９の「要求情報」には，モジュール・テーブル１０
６に記載の「要求情報」を展開して得られるパス名が用
いられる。例えば，上記のモジュール・テーブル１０６
の最初（コメント行の次の行）のダウンロード情報にお
ける「要求情報」は，

【００９６】 /LATEST?Regex-Path=/foo/.+/foo-dl\.jar$

【００９７】である。したがって，これにマッチしたフ
ァイル

【００９８】/foo/version-1.1/foo-dl.jar

【００９９】が，バージョン情報付きモジュール・テー
ブル２０９の最初（コメント行の次の行）のダウンロー
ド情報に「要求情報」として記載される。

【０１００】「属性情報」には，マッチしたアーカイブ
・ファイル（「要求情報」に記載されたファイル）に定
義されているバージョン情報が記載される。バージョン
情報が複数の場合は，”，”によって区切られて記載さ
れる。上記のバージョン情報付きモジュール・テーブル
２０９の最初（コメント行の次の行）のダウンロード情
報は，ファイル

【０１０１】/foo/version-1.1/foo-dl.jar

【０１０２】には，マニフェスト属性として，

【０１０３】Specification-Version:1.1 Package-Version:build100

【０１０４】のバージョン情報が指定されていることを
示している。

【０１０５】なお，アーカイブ・ファイルにバージョン
情報に関する情報が記載されていない場合，プログラム
配布サーバ１０８は，バージョン情報の代わりに，この
ファイルのタイムスタンプ情報を属性情報として付加す
る。上記のバージョン情報付きモジュール・テーブル２
０９の４番目のダウンロード情報に記載されている”se
tup.jar”ファイルがこれに該当する。

【０１０６】ところで，上記のバージョン情報付きモジ
ュール・テーブル２０９の２番目のダウンロード情報に
記載されている”foo-core.jar”ファイルに対応するダ
ウンロード情報が上記のモジュール・テーブル１０６に
存在しない。これは，１番目のダウンロード情報に記載
されている”foo-dl.jar”ファイルに，このファイルと
の依存関係を示す

【０１０７】Class-Path:foo-core.jar

【０１０８】がマニフェスト属性として記述されている
ためである。プログラム配布サーバ１０８は，この依存
関係を追跡して，被依存ファイルをテーブルの要素とし
て追加する。

【０１０９】＜ステップ３＞プログラム管理コンポーネ
ント１０４は，プログラム配布サーバ１０８に対して，
利用者”Ａ”に割り当てられたバージョン情報付きモジ
ュール・テーブル２０９のダウンロードを要求する。こ
のダウンロードの要求は，予め設定された周期で行うい
わゆるポーリング方式に基づいて実行されること，ある
いは，アプリケーション１０１の起動ごとに実行される
ことが好ましい。この場合，プログラム管理コンポーネ
ント１０４は，サーバ・デーモンとして常時動作するよ
うに構成されるか，または，アプリケーション１０１に
組み込まれ，同期的に起動するように構成される。

【０１１０】＜ステップ４＞プログラム管理コンポーネ
ント１０４からのリクエストを受け付けたプログラム配
布サーバ１０８は，要求に応じたバージョン情報付きモ
ジュール・テーブル２０９を要求元であるプログラム管
理コンポーネント１０４に送る。

【０１１１】＜ステップ５＞バージョン情報付きモジュ
ール・テーブル２０９を獲得したプログラム管理コンポ
ーネント１０４は，各ダウンロード情報を参照し，現
在，クライアントに同名のファイルがインストールされ
ているか否かを確認する。同名のファイルが存在しな
い，または，ファイルが存在してもそのバージョン情報
がバージョン付きモジュール・テーブル２０９に記載の
バージョンよりも古い場合には，要求情報を利用してダ
ウンロード要求を発行する。

【０１１２】＜ステップ６＞プログラム配布サーバ１０
８は，プログラム管理コンポーネント１０４からのダウ
ンロード要求を受けて，該当するファイルを第２のファ
イルシステム１０５から検索し，プログラム管理コンポ
ーネント１０４に対して送付する。

【０１１３】＜ステップ７＞プログラム管理コンポーネ
ント１０４は，プログラム配布サーバ１０８からの転送
データを一時的なファイル名で第１のファイルシステム
１０２に保存する。このとき，一時的なファイル名と本
来の名称（ダウンロード情報に記載されているファイル
名）との変換情報をハンドル情報とともに別ファイルに
書き出しておく。

【０１１４】＜ステップ８＞すべてのファイル転送が終
了した時点でプログラム管理コンポーネント１０４は，
アプリケーション１０１に転送が正常に終了したことを
通知する。この通知を受けたアプリケーション１０１
は，利用者に対して，ファイルのバージョンアップが存
在すること，クライアントアプリケーション１０１を一
旦終了することを確認する。

【０１１５】＜ステップ９＞アプリケーション１０１が
終了した時点で，プログラム管理コンポーネント１０４
は，＜ステップ７＞において作成したファイル名の変換
情報を読み出して，ファイル名の変更を行う。また，操
作情報に応じてアーカイブの展開やファイルの削除処理
を行う。

【０１１６】ここで，本実施の形態にかかるファイル配
布システムによるプログラムの更新処理が完了する。

【０１１７】以上をまとめると，次の通りである。プロ
グラム配布サーバ１０８は，プログラムが配布される以
前にファイルの依存関係を解決し，配布される各プログ
ラム・モジュール１０７のバージョン情報が記載された
バージョン情報付きモジュール・テーブル２０９を作成
する。そして，プログラム管理コンポーネント１０４
は，そのバージョン情報と，クライアントの第１ファイ
ルシステム１０２にインストールされているプログラム
・モジュールのバージョンとを比較して，バージョン情
報付きモジュール・テーブル２０９に記載されているバ
ージョン情報の方が新しい場合，すなわち，サーバの第
２のファイルシステム１０５に格納されているプログラ
ム・モジュールのバージョンが新しい場合にのみ，第２
のファイルシステム１０５に格納されているプログラム
・モジュールをダウンロードする。

【０１１８】このように，本実施の形態にかかるファイ
ル配布システムによれば，バージョン・アップされたプ
ログラム・モジュールだけを選択的にダウンロードする
ことが可能となる。したがって，第１の実施の形態にか
かるファイル配布システムと同様の効果が得られるとと
もに，ネットワークへのアクセス回数を少なく抑えつ
つ，プログラムをバージョンアップさせることが可能と
なる。

【０１１９】さらに，プログラム・モジュール間の依存
関係が事前に解決されるため，プログラム管理コンポー
ネント１０４（ソフトウェア）の作成が容易となる。

【０１２０】添付図面を参照しながら本発明の好適な実
施の形態について説明したが，本発明はかかる実施の形
態に限定されない。当業者であれば，特許請求の範囲に
記載された技術的思想の範疇内において各種の変更例ま
たは修正例に想到し得ることは明らかであり，それらに
ついても当然に本発明の技術的範囲に属するものと了解
される。

【０１２１】例えば，プログラム・モジュール１０７を
第２のファイルシステム１０５に格納する場合に即して
本発明の実施の形態にかかるファイル配布システムを説
明したが，第２のファイルシステム１０５に代えて，デ
ータベースを用いてもよい。

【０１２２】プログラム管理コンポーネント１０４とプ
ログラム配布サーバ１０８との間の通信プロトコルにHT
TPが用いられた場合に即して本発明の実施の形態にかか
るファイル配布システムを説明したが，他のプロトコル
を採用することも可能である。独自のプロトコル，ある
いは，FTP(File Transfer Protocol)など既存のデータ
転送のためのプロトコルを用いてもよい。

【０１２３】

【発明の効果】以上説明したように，本発明によれば，
サーバが有するファイルを効率よくクライアントに配布
することが可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態にかかるファイル配
布システムの構成を示すブロック図である。

【図２】本発明の第２の実施の形態にかかるファイル配
布システムの構成を示すブロック図である。

【符号の説明】

１０１：アプリケーション １０２：第１のファイルシステム １０３：プログラム・モジュール １０４：プログラム管理コンポーネント １０５：第２のファイルシステム １０６：モジュール・テーブル １０７：プログラム・モジュール １０８：プログラム配布サーバ ２０９：バージョン情報付きモジュール・テーブル

Claims (6)

【特許請求の範囲】
1. 【請求項１】 配布の対象となる１または２以上のファ
   イルと前記１または２以上のファイルに関する情報が記
   載されたファイル情報テーブルとを格納するファイル配
   布側格納手段と，前記ファイル配布側格納手段に格納さ
   れている前記１または２以上のファイルと前記ファイル
   情報テーブルを，ネットワークを経由して配布するファ
   イル配布手段と，前記ファイル情報テーブルの内容に基
   づき，前記ファイル配布側格納手段に格納されている前
   記１または２以上のファイルの中から１または２以上の
   ファイルを選択し，前記ファイル配布手段に対して選択
   した１または２以上のファイルの配布を要求し，前記フ
   ァイル配布手段によって配布された１または２以上のフ
   ァイルをファイル被配布側格納手段に格納するファイル
   管理手段と，を備えたことを特徴とする，ファイル配布
   システム。
2. 【請求項２】 前記ファイル情報テーブルには，前記１
   または２以上のファイルのファイル名と，前記ファイル
   管理手段に配布された後の前記１または２以上のファイ
   ルの操作に関する操作情報と，前記ファイル管理手段が
   前記ファイル配布手段に対して行う前記１または２以上
   のファイルの配布要求に用いられる要求情報と，が記載
   されることを特徴とする，請求項１に記載のファイル配
   布システム。
3. 【請求項３】 前記ファイル管理手段は，前記要求情報
   に所望するバージョン情報を追加して，前記ファイル配
   布手段に対して前記１または２以上のファイルの配布を
   要求するためのコマンドを生成することを特徴とする，
   請求項２に記載のファイル配布システム。
4. 【請求項４】 前記ファイル管理手段は，正規表現また
   はワイルドカードの少なくともいずれか一方を用いて，
   前記ファイル配布側格納手段に格納されている前記１ま
   たは２以上のファイルの中から２以上のファイルを同時
   に選択することが可能であることを特徴とする，請求項
   １，２，または３に記載のファイル配布システム。
5. 【請求項５】 さらに，前記ファイル配布側格納手段
   は，前記ファイル配布側格納手段に格納されている前記
   １または２以上のファイルの各バージョン情報が記載さ
   れたバージョン情報付きファイル情報テーブルを格納す
   ることを特徴とする，請求項１，２，３，または４に記
   載のファイル配布システム。
6. 【請求項６】 前記バージョン情報付きファイル情報テ
   ーブルは，前記ファイル配布手段が生成することを特徴
   とする，請求項５に記載のファイル配布システム。