JP4841787B2 - 共用ライブラリファイル内のプログラムファイルへのアクセスを制限するための方法、システムおよび記憶媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、共用ソフトウェアライブラリの部分へのアクセスを制限するためのシステムに関し、とくに、クラスローダを使用して共用ライブラリ内のオブジェクトクラス定義ファイルへのアクセスを制限するシステムに関する。
【０００２】
【従来の技術】
ソフトウェアベンダーは典型的に、彼等の商品をＪａｖａ（商標名）オブジェクト指向プログラミング言語で書かれ、ＪＡＲファイルと呼ばれる通常の共用ライブラリファイルとして実装されたライブラリのような１組の共用ライブラリとして出荷する。こうして、これらのライブラリ内に記憶されたプログラムファイルは、ベンダーの商品の一部である任意のプログラムモジュールにより容易に効率的に共用され、使用されることができる。
【０００３】
共用ライブラリは、ベンダーの商品がオブジェクト指向プログラミングを使用して書かれている場合、クラス定義を維持するために使用されることが多い。オブジェクト指向プログラミング環境においては、オブジェクトは一般にデータメンバおよびそのデータメンバを操作する機能メンバ（またはメソッド）をカプセル化する。オブジェクトは、同じクラスのオブジェクトにより共用される種々のデータメンバおよびメソッドを規定するクラスのインスタンスである。したがって、共用ライブラリは、ベンダーの商品で使用されるオブジェクトの各タイプを規定するために使用されることができる。
【０００４】
【発明が解決しようとする課題】
ユーザは、共用されることを意図された共用ライブラリの部分にアクセスできることが重要である。これは、そのコンテンツ（一般にプログラムファイルと呼ばれる）がこのようなライブラリ構成においてどのように使用されることを意図されているかということである。しかしながら、コンテンツの全てが共用ライブラリの外部で使用されることを意図されているわけではない。ライブラリ構成内のみで使用されることを意図されていても、共用ライブラリを使用するいずれのコードによりアクセスされることのできるクラス定義およびオブジェクトが存在する。その結果、共用ライブラリを使用したソフトウェアベンダーが直面する問題の１つは、ライブラリ構成の外部で共用されることを意図されていない共用ライブラリの部分へのアクセスを制限することである。たとえば、ＪＡＲファイル中にパッケージされたＪａｖａ（商標名）ライブラリはパブリックであると宣言されており、そのためＪａｖａ（商標名）パッケージがそのライブラリの内部だけで使用されることを意図されているにもかかわらず、Ｊａｖａ（商標名）ライブラリを使用するどのコードによってでもアクセスされることが可能である。
【０００５】
共用ライブラリのこれらの部分への無許可のアクセスによる外部プロセスが行なわれる基本的な問題のほかに、そうした結果として別の問題が生じる可能性がある。たとえば、ライブラリの内部のみにおいて使用されると仮定されている共用ライブラリの部分を外部で使用した場合に、ネームスペース問題が発生する可能性がある。共用ライブラリを生成したソフトウェアベンダーは、共用ライブラリに対して外部のネームスペース衝突に関係なく、共用ライブラリの部分に対して特定の名前または命名規則を使用する可能性がある。しかしながら、そのライブラリの内部のものであることを厳密に意図されたパッケージに対して外部プロセスがアクセスした場合、そのパッケージに対する名前は、外部プロセスによりすでに使用された別のパッケージまたはオブジェクトの名前と競合する可能性がある。このような状況において、所定のパッケージ名に対するクラス定義の重複が生じ、そのために、どの機能が名前の付けられたパッケージまたはオブジェクトに関連しているのかをどのようにして解くかが問題になる可能性がある。
【０００６】
Ｊａｖａ（商標名）プログラミング言語におけるシーリング（ｓｅａｌｉｎｇ）の導入は、この問題のいくつかの例が検出され、エラーを浮上（ｒａｉｓｅ）させることを可能にすることによりそのような状況を改善している。しかしながら、単にランタイムでエラーを浮上させて、エンドユーザが適切なアクションを取ってその問題を修正（ｆｉｘ）するように要求するのは、問題の進行を放置するのと同じくらい望ましいものではない。また、シーリングは一般にある拡張の特定のバージョンで束（ｂｕｎｄｌｅ）にされたアプリケーションまたはアプレットの出荷を望む重大なケースには助けにならないであろう。その拡張のある別のバージョンがエンドユーザのコンピュータ上にすでにインストールされている場合には、そのインストールされているものが束にされたものに優先する。
【０００７】
したがって、共用ライブラリのある部分へのアクセスを可能にする一方で、その共用ライブラリの別の部分へのアクセスを制限するシステムが必要である。
【０００８】
【課題を解決するための手段】
本発明による方法、システムおよび製品は、ＪＡＲファイルのような共用ライブラリの部分へのアクセスを制限するためにクラスローダを使用することにより既存のシステムの欠点を克服する。クラスローダは、ライブラリ内のプログラムファイルにアクセスしようとしている外部プロセスとそのライブラリ自身の中のファイルとの間にインターフェースを発生させる。この明細書において具体的に表され、広義に説明されている本発明による方法、システムおよび製品は、プログラムファイルを共用ソフトウェアライブラリからロードする。典型的に、プログラムファイルはクラスローダによりロードされたクラス定義である。次に、ロードされたプログラムファイルへのインターフェースが生成される。インターフェースオブジェクトであることが好ましいインターフェースは、プログラムファイルがエクスポートされることが可能であるかどうかに関する状態インジケータを有している。この状態インジケータは、好ましいインターフェースオブジェクトの一部分である状態メソッドを実行することによって決定されることが好ましく、その状態インジケータは、プログラムファイルが共用ライブラリからエクスポートされることが可能かどうかを決定するために使用される。状態メソッドは典型的に、プログラムファイルがエクスポートされることが可能かどうかを示す共用ライブラリ内の属性を読出すことによって生成される。状態インジケータに基づいて、プログラムファイルがエクスポートされることができない場合、プログラムファイルへのアクセスが制限される。他方、プログラムファイルがエクスポート可能であることが状態インジケータにより示された場合には、プログラムファイルはリクエストプロセスに戻される。
【０００９】
本発明の別の特徴によると、この明細書において具体的に表され、広義に説明されている方法、システムおよび製品は、共用ライブラリファイル内のオブジェクトクラス定義へのアクセスを制限するシステムを示している。このシステムは、共用ライブラリおよびクラスローダを維持するメモリ記憶装置を備えている。システムはまた、このメモリ記憶装置に接続されたプロセッサを備えている。このプロセッサは、クラスローダを使用してオブジェクトクラス定義をメモリ記憶装置上の共用ライブラリからロードするように動作する。適切なオブジェクトクラス定義の位置が共用ライブラリ内において突きとめられてロードされると、プロセッサはさらに、典型的にクラスローダ内のパッケージメソッドを呼出すことにより、メモリ記憶装置においてインターフェースオブジェクトのインスタンスを生成するように動作する。このインターフェースオブジェクトはオブジェクトクラス定義と関連しており、プロセッサによりインターフェースオブジェクトの一部分としてメモリ記憶装置において生成された状態メソッドを含んでいる。この状態メソッドは、プロセッサ上で実行する外部プロセスによりオブジェクトクラス定義がアクセス可能であるかどうかを指定する機能を定義する。プロセッサはまた、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを決定するために状態メソッドを呼出すように動作する。最後に、プロセッサは、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていないことを、実行された状態メソッドが示した場合にオブジェクトクラス定義へのアクセスを制限することができる。
【００１０】
本発明のさらに別の特徴によると、この明細書において具体的に表され、広義に説明されている方法、システムおよび製品は、共用ソフトウェアライブラリ内のオブジェクトクラス定義へのアクセスを制限するための命令を含んでいるコンピュータ読出し可能な媒体を示している。命令が実行されたとき、クラスローダを使用して共用ソフトウェアライブラリからオブジェクトクラス定義がロードされる。次に、そのオブジェクトクラス定義に関連したインターフェースオブジェクトのインスタンスが、そのインターフェースオブジェクトに関連した状態メソッドと共にクラスローダによって生成される。典型的に、インターフェースオブジェクトのインスタンスを生成するためにクラスローダ内の別のメソッドが呼出される。状態メソッドは、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを示す。状態メソッドは、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを決定するために呼出される。最後に、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていないことを状態メソッドが示した場合、オブジェクトクラス定義へのアクセスは制限される。
【００１１】
【発明の実施の形態】
この明細書において参考とされ、その一部分を構成している添付図面には、本発明の実施形態が示されている。図面および説明から本発明の利点および原理が明らかになるであろう。
以下、添付図面に示されている本発明による１実施形態を詳細に説明する。同じ参照符号は、可能な場合には常に同一または類似した部分を示すために図面および以下の説明において一貫して使用される。
【００１２】
［序説］
一般に、本発明による方法およびシステムは、外部プロセスによりアクセスされることのできる共用ライブラリの部分を制限するためにクラスローダを使用することにより、Ｊａｖａ（商標名）プログラミング言語で書かれたアプレットのようなプロセスの実行中に呼出しを処理する。そうすることにより、内部使用に制限されることを意図されている共用ライブラリの部分は、外部プロセスによりアクセスされて使用されることはできない。
【００１３】
さらに詳細に説明すると、プログラムファイル（クラス定義のような）に対するリクエストは、共用ライブラリの外部の実行中のプロセス（アプレットのような）からクラスローダにより受取られる。クラスローダは、リクエストの受取りに応答して、適切なプログラムファイルを共用ライブラリからロードし、ロードされたプログラムファイルへのインターフェース（インターフェースオブジェクトのような）を発生させる。インターフェースは、プログラムファイルが外部プロセスにエクスポートされることが可能かどうかを示す状態インジケータ（状態メソッドのような）を有している。状態インジケータの値に基づいて、ロードされたプログラムファイルへのアクセスは、そのプログラムファイルへの発生されたインターフェースにより制限される。プログラムファイルへのアクセスが制限された場合、実行中のプロセスはプログラムファイルへのアクセスを拒否される。そうでない場合、実行中のプロセスはプログラムファイルへのアクセスをインターフェースを介して受取る。このようにして、クラスローダは正しく適切なクラス定義をロードするだけでなく、内部的にのみアクセスされることを意図されている共用ライブラリの部分へのアクセスを制限する能力を与えるためにも使用される。
【００１４】
［コンピュータアーキテクチャ］
図１は、本発明による方法を実施し、本発明によるシステムを構成するのに適した例示的なデータ処理システム100 を示している。図１を参照すると、データ処理システム100 は、構内ネットワーク、広域ネットワークまたはインターネットのようなネットワーク170 に接続されたコンピュータシステム110 を含んでいる。
【００１５】
コンピュータシステム110 は主記憶装置120 と呼ばれるメモリ記憶装置と、補助記憶装置130 と、中央処理装置（ＣＰＵ）140 と、入力装置150 と、ビデオ表示装置160 とを含んでおり、これらはそれぞれコンピュータシステム110 の別の部分に電子的に接続されている。本発明による例示的な形態において、コンピュータシステム110 は、ＳＰＡＲＣ（商標名）コンピュータアーキテクチャを使用して構成される。ＳＰＡＲＣ（商標名）コンピュータアーキテクチャに関するさらに詳細な説明は、カリフォルニア州メトロパークのＳＰＡＲＣインターナショナル社から入手可能であり、ここにおいて参考文献とされているＳＰＡＲＣ（商標名）Ｖ９参考マニュアルを含むいくつかの文献に記載されている。
【００１６】
コンピュータシステム110 において、主記憶装置120 はオペレーティングシステム128 と、仮想（バーチャル）マシン（ＶＭ）126 と、クラスローダ122 と、および共用ライブラリ124 とを含んでいる。この説明のために例示されたＶＭ126 はＪａｖａ（商標名）仮想マシン（ＪＶＭ）であり、それはＪａｖａ（商標名）ソフトウェア開発キット（ＪＤＫ）中に含まれているＪａｖａ（商標名）ランタイム環境の一部である。ＪＤＫはカリフォルニア州パロアルトのサンマイクロシステムズ社から入手可能である。一般に、ＪＶＭは、プログラム（アプレットのような）から命令をバイトコードの形態で受取って抽象的な計算マシンのように動作する。バイトコードは本質的に、Ｊａｖａ（商標名）プログラミング言語で書かれたプログラムのような汎用プログラム用のコンパイル済みのフォーマットである。命令またはバイトコードが受取られると、ＪＶＭはこれらのバイトコードをオブジェクトコードのような実行用の形態にダイナミックに変換してそれらを実行することによってこれらのバイトコードを解釈する。
【００１７】
Ｊａｖａ（商標名）プログラミング言語で書かれたアプレットのようなプログラムモジュールに対するこの実行方式は、ＪＶＭのプラットフォーム独立特性を容易にする。ＪＶＭに関するさらなる詳細は、ここにおいて参考文献とされている文献（ Lindholm および Yellin 著“The Java Virtual Machine Specification”,Addison-Wesley,1997）を含むいくつかの文献に記載されている。
【００１８】
プログラムモジュールの実行中、ＶＭ126 は、ロードされなければならないオブジェクトクラスへの記号による参照（ｓｙｍｂｏｌｉｃ ｒｅｆｅｒｅｎｃｅ）に直面する可能性がある。このような状況において、ＶＭ126 は典型的に、適切なプログラムファイルをロードするタスクをクラスローダに委任する。クラスローダは技術的に知られており、これまでロードされたことのないオブジェクトクラス定義がインタプリタにより要求された場合に通常使用される。基本的に、クラスローダはオブジェクトクラス定義を、このオブジェクトクラス定義が維持されている特定の記憶位置（遠隔地サーバまたはローカルメモリファイル）からロードする。通常のクラスローダのさらに詳細な説明は、カリフォルニア州マウンテンビューのサンマイクロシステムズ社にその権利が譲渡され、ここにおいて参考文献とされている米国特許第 5,727,147号明細書（“SYSTEM AND METHOD FOR RESOLVING SYMBOLIC REFERENCES TO EXTERNALLY LOCATED PROGRAM FILES ”）に記載されている。
【００１９】
例示的なクラスローダ122 は、それが共用ライブラリ124 のような共用ライブラリの部分への選択的インターフェースメカニズムとして動作できるようにするいくつかの別の特徴が追加された通常のクラスローダである。とくに、クラスローダ122 は共用ライブラリ124 内のプログラムファイルへのインターフェースを生成することができる。そのインターフェースはまた、それらのプログラムファイルが外部プロセスにエクスポートされるか、あるいは外部プロセスによりアクセス可能であるかどうかを決定する状態インジケータを有している。適切なクラス定義を正しい位置からロードし、インターフェースとして動作するこの能力により、クラスローダ22は共用ライブラリ内の特定の、オブジェクトクラス定義のようなプログラムファイルへのアクセスを制限することが可能になる。
【００２０】
たとえば、外部プロセス（ＶＭ126 と共同して実行するアプレットのような）は、特定のクラス定義がまだ主記憶装置中にロードされていないので、そのクラス定義をロードする必要がある。そのクラス定義が外部プロセスにエクスポートされることを意図されている場合には、そのクラス定義をただロードするだけでよい。しかしながら、そのクラス定義が外部プロセスによりアクセス可能であることを意図されていない場合、クラス定義へのアクセスを制限する別のステップが必要とされる。クラスローダ122 はリクエストを受取り、リクエストされたクラス定義を共用ライブラリ124 内からロードする。この例において、ライブラリ124 は、Ｊａｖａ（商標名）パッケージまたはオブジェクトの多くのクラスの定義を維持している通常のＪＡＲファイルとして構成されている。この時点で、クラスローダ122 は、パッケージオブジェクトとも呼ばれるインターフェースオブジェクトを生成し、このインターフェースオブジェクトは、リクエストされているクラス定義をカプセル化し、状態インジケータとして状態メソッドを含んでいる。リクエストされているクラス定義が外部からアクセス可能であると指定されている場合、その状態メソッドの実行結果は“真”のような予め選択された値である。以下において、図２に関してさらに詳細な説明が行われる。
【００２１】
さらに、本発明による構成はＪＶＭと共に実施されるものとして説明されているが、本発明によるシステムおよび方法はまた、Ｊａｖａ（商標名）環境以外の環境において実施されてもよいことが当業者により認識されるであろう。たとえば、共用ライブラリ内のプログラムファイル（クラス定義のような）に対するリクエストは、ＶＭ126 が必要とされることなく、オペレーティングシステム128 と共に実行するマルチスレッドアプリケーションプログラムモジュール（示されていない）から行なわれてもよい。
【００２２】
さらに、本発明によるシステムおよび方法の全てまたは一部は、ハードディスク、フロッピーディスクおよびＣＤ−ＲＯＭ等の補助記憶装置、インターネットから受取られた搬送波、あるいは別の形態のＲＯＭまたはＲＡＭのような別のコンピュータ読出し可能な媒体上に記憶されてもよいし、あるいはそこから読出されてもよいことが当業者により認識されるであろう。最後に、データ処理システム100 の特定のコンポーネントが説明されているが、当業者は、マルチプロセッサおよび種々の入出力装置のような付加的または異なったコンポーネントが例示的な実施形態による使用に適したデータ処理システム100 に含まれてもよいことを認識するであろう。
【００２３】
［アクセス制限システム］
図２は、本発明の１実施形態にしたがって例示的な共用ライブラリ内のファイルへのアクセスを制限するために例示的なクラスローダがどのようにして使用されるかを示すさらに詳細なブロック図である。図１および２を参照とすると、ＶＭ126 、クラスローダ122 および共用ライブラリ124 は、相互作用するソフトウェアのブロックとして示されている。ＶＭ126 内には、このＶＭ126 により解釈および実行される命令またはバイトコードを含むアプレット205 が存在する。アプレット205 からのバイトコードの実行中、ＶＭ126 は特定のオブジェクトクラス定義をロードする必要がある。これは、そのバイトコードが、まだ共用ライブラリ124 から主メモリ120 中にロードされていないその特定のオブジェクトクラスにより規定されたオブジェクトをリストするためである。そのバイトコードに適したオブジェクトクラス定義をロードするために、ＶＭ126 はクラスローダ122 を使用するか、あるいはそれに委任して、正しいオブジェクトクラス定義を見出す。このようにして、クラスローダ122 はオブジェクトクラス定義のためにＶＭ126 からリクエストを受取る。
【００２４】
リクエストに応答して、クラスローダ122 はロードすべき適切なオブジェクトクラス定義を決定する。図２に示されている例示的な実施形態では、適切なオブジェクトクラス定義は、クラス定義200 、202 および204 のような種々のプログラムファイルを維持している共用ライブラリ124 中に位置している。図２に示されている例において、クラスローダ122 は、オブジェクトクラス定義200 が適切な定義であることを決定し、共用ライブラリ124 からオブジェクトクラス定義を検索する。ここまでは、これは典型的に大部分の通常のクラスローダにより行なわれるものである。
【００２５】
上述された標準的なクラスロード機能に加えて、クラスローダ122 は、オブジェクトクラス定義へのインターフェースを生成するメソッドを含む。例示的な実施形態において、メソッド220 はｇｅｔ ｐａｃｋａｇｅと呼ばれている。ｇｅｔ ｐａｃｋａｇｅメソッド220 は、それが呼出されたとき、オブジェクトクラス定義200 をカプセル化するオブジェクト210 （インターフェースオブジェクトまたはパッケージオブジェクトと呼ばれる）のインスタンスを生成する。ｇｅｔ ｐａｃｋａｇｅメソッド220 はまた、メソッド215 （一般に、状態メソッドと呼ばれている）をインターフェースオブジェクト210 を生成する一環として生成し、このメソッド215 は、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを示す。典型的に、クラスローダ122 内のメソッド220 は、所望のオブジェクトクラス定義がエクスポートされることができるかどうかを示すインジケータまたは別の種類のフラッグタイプのメカニズムを求めて共用ライブラリ124 内を捜索する。例示的な実施形態において、ｇｅｔ ｐａｃｋａｇｅメソッド220 は、共用ライブラリ124 のマニフェストまたはヘッダ206 中の属性208 を読出す。マニフェスト206 は、共用ライブラリ124 内のコンテンツ（すなわち、プログラムファイル）に関する情報を維持している。マニフェスト206 の一部分として、属性208 は、外部プロセスにエクスポートされるか、あるいは外部プロセスによりアクセス可能であると指定された共用ライブラリ124 中のファイルのリストであることが好ましい。
【００２６】
属性208 に基づいて、ｇｅｔ ｐａｃｋａｇｅメソッド220 は、実行されたときに適切な値を供給するか、あるいは返すようにインターフェースオブジェクト210 の中の状態メソッド215 を規定する。たとえば、オブジェクトクラス定義200 が外部プロセスによりアクセス可能なものではない場合、状態メソッド215 （例示的な実施形態では“ｉｓ ｅｘｐｏｒｔｅｄ”と呼ばれている）は、それが呼出されたときに“偽”値を返す。このようにしてクラスローダ122 は、そのプログラムファイルがエクスポートされないものであることを状態インジケータ（状態メソッド215 を実行した結果のような）が示した場合、正しいプログラムファイル（アプレット205 のような）を見出してロードする。
【００２７】
共用ライブラリ124 がＪＡＲファイルであるさらに詳細な実施形態において、ＪＡＲファイルは、そのパッケージの、エクスポートされるべき１以上のものを宣言する能力を備えている。エクスポートされたパッケージ内に含まれているクラスおよびリソースは別のＪＡＲファイルに可視的である。エクスポートされないパッケージは専用と呼ばれ、それらのクラスおよびリソースはそのＪＡＲファイル内のみで可視的である。また、専用のクラスおよびリソースは局部的有効範囲のものとされ、クラス／リソース名がこのＪＡＲファイルからのコードで解かれなければならないときに、ＪＡＲファイル中の定義が、可視である可能性のある同じ名前の任意の他のクラス／リソースに優先することを意味する。
【００２８】
この詳細な実施形態において、エクスポートされたパッケージは、Ｅｘｐｏｒｔｅｄ：（真｜偽）のような新しいエントリ当りのマニフェスト属性208 により宣言される。このブール属性は、特有のパッケージがエクスポートされるべきか否かを示す。たとえば、以下のマニフェストエントリ：
名前：ｊａｖａｘ／ｆｏｏ／
エクスポート：真
では、パッケージｊａｖａｘ．ｆｏｏはエクスポートされることとなる。
【００２９】
この属性はパッケージおよびディレクトリだけでなく、個々のクラスまたはリソースファイルにも適用されることができる。この実施形態において、パッケージまたはディレクトリがエクスポートされる場合、それが含んでいるクラス／リソースの全ては、それら自身のエクスポート：偽属性を有することによって明示的に専用のものにされていない限り、自動的にエクスポートされる。しかしながら、パッケージ／ディレクトリは、それらがサブパッケージ／サブディレクトリを含んでいる場合は、通常は自動的にエクスポートされない。
【００３０】
例示的な１実施形態において、デフォルトは典型的に、特定されているＥｘｐｏｒｔｅｄ属性が全くない場合にエクスポートされるべきパッケージ／ディレクトリおよびクラス／リソースの全てに対してなされる。少くとも１つのＥｘｐｏｒｔｅｄ属性が特定されている場合、エクスポートされると宣言されていない限り、デフォルトとは、各々の全てのものが専用であるということである。
【００３１】
Ｊａｖａ（商標名）プログラミング言語内のＪＡＲツールは、エクスポートファイルが特定されることを可能にする−ｅオプションを有している。これは、ソフトウェア開発者にとって都合がよく、それによって彼らは適切なマニフェストファイルを生成しなければならないのではなく、エクスポートを簡明にリストすることができる。エクスポートファイルのフォーマットは、パッケージ名およびＪＡＲファイルエントリのシーケンスであることが好ましく、これらパッケージ名およびＪＡＲファイルエントリはそれぞれ新しいラインによって終端される。たとえば、−ｅオプションを使用して以下のエクスポートファイル：
ｆｏｏ．ｂａｒ
ｆｏｏ．ｂａｚ
／ｉｍａｇｅｓ／ｆｏｏ．ｇｉｆ
／ｆｏｏ．ｐｒｏｐｅｒｔｉｅｓ
を特定することは、通常の−ｍオプションにより以下のマニフェストファイル：
【数１】

を特定することと同じである。
【００３２】
−ｅおよび−ｍオプションは一緒に使用されることができ、その場合マニフェストが組合せられる。マニフェストの組合せにおいて、−ｅオプションから発生したＥｘｐｏｒｔｅｄ属性が優先する。すなわち、他のマニフェストからのＥｘｐｏｒｔｅｄ属性のいずれも無視されるため、エクスポートファイルは常に完全なエクスポートのセットをリストする。
【００３３】
例示的な１実施形態において、クラス java.net.URLClassLoaderは、クラスおよびリソースをＪＡＲファイルのクラスパスおよびディレクトリＵＲＬからロードするためにクラスローダ122 として使用される。図２に示されているように、この実施形態は基本的に、そのマニフェスト中の１以上のエクスポートされたパッケージを宣言したクラスパス上に各ＪＡＲファイルをラップする（ｗｒａｐ）ために小さいクラスローダを生成することを含む。このクラスローダはJar Class Loaderと呼ばれることが好ましく、それは専用クラスになり、それの目的は、共用ライブラリ124 （たとえば、ＪＡＲファイル）からロードされたどのコードでもそれ自身の専用クラスおよびリソースにアクセスすることを可能にし、一方それらがそのクラスパス上の他のＪＡＲファイルから隠されたままにしておくことである。
【００３４】
以下は、擬似コードで書かれたJar Class Loaderの例示的な構成である：
【数２】

【数３】

【数４】

【数５】

【００３５】
上記の例の擬似コードに関連して、URL Class Loaderは、１以上のエクスポートされたパッケージを宣言したクラスパス上の各ＪＡＲファイルに対してJarClassLoaderの新しいインスタンスを生成するであろう。Jar Class Loaderに対する代理の親は、ＪＡＲファイルを含んでいるクラスパスに対して生成されるURL Class Loaderのインスタンスである。ＪＡＲファイルからロードされたコードがリンクされた場合は常にJar Class Loader's load Class メソッドが呼出されるであろう。
【００３６】
最初に、クラスがすでにロードされたかどうかをチェックするためにfind Loaded Class() が呼出される。次に、そのクラスがこのＪＡＲファイル内に含まれているが、エクスポートされると宣言されていない場合、そのクラスをＪＡＲファイルからロードしようとする試みがなされる。これが失敗した場合、公開クラスをチェックするために親 URL Class Loader's loaded Class()メソッドが呼出される。これは公開クラスに対する通常の範囲を維持しながら、専用クラスがローカル範囲を有することを可能にする。
【００３７】
URL Class Loaderは、それがクラスパス上の別のＪＡＲファイルによって参照されたクラスに対してこのＪＡＲファイルをチェックする場合に、そのクラスをロードするためにJar Class Loader's load Exported Classメソッドを呼出すであろう。このメソッドは、それが代理の親をチェックしないこと、およびそれがエクスポートされると宣言されたＪＡＲファイルからしかクラスをロードしないことを除いて、Load Classメソッドに類似している。これによって、そのクラスパス上の別のＪＡＲファイルにより専用のクラスがロードされることが阻止される。
【００３８】
［アクセス制限プロセス］
以下図３のフローチャートを参照として、クラスローダを使用して共用ライブラリ中のオブジェクトクラス定義のようなプログラムファイルへのアクセスを制限する本発明による例示的な方法のステップをさらに詳細に説明する。図１乃至３を参照とすると、方法300 はステップ305 からスタートし、このステップ305 において外部プロセスはリクエストされたクラス定義をロードするようにクラスローダに委任する。例示的な実施形態において、アプレット205 は、ＶＭ126 により解釈されるバイトコードを有しており、したがってＶＭ126 は、バイトコードを解釈するために必要とされる適切なオブジェクトクラス定義をロードするためにクラスローダ122 を呼出す。
【００３９】
ステップ310 において、適切なクラス定義はその位置を突きとめられてロードされる。例示的な実施形態において、クラス定義200 は共用ライブラリ124 から検索すべき適切なクラス定義であるとクラスローダ122 により決定される。
【００４０】
ステップ315 において、ロードされたクラス定義に対するインターフェースを発生させるメソッドが呼出される。一般に、そのインターフェースは、別のファイルまたは情報へのアクセスを選択的に行うことのできる任意のタイプのプログラムインターフェースまたはプログラミング構造であることができる。例示的な実施形態においては、インターフェースオブジェクト210 のインスタンスをインターフェースとして生成するためにｇｅｔ ｐａｃｋａｇｅメソッド220 が呼出される。ｇｅｔ ｐａｃｋａｇｅメソッド220 が実行するとき、ステップ330 において共用ライブラリ124 中の属性208 が読出され、そのインターフェースは、クラス定義200 のような共用ライブラリ124 中のリクエストされたプログラムファイルへのアクセスが可能かどうかが決定される。
【００４１】
ステップ325 において、インターフェースのインスタンス（たとえば、インターフェースオブジェクト210 ）がクラス定義200 に対して生成される。インターフェースオブジェクト210 を生成する一環として、ステップ330 において共用ライブラリ124 中の属性208 に応じて状態メソッドが生成される。状態メソッドは、クラス定義が外部プロセスに対してアクセス可能であると指定されているかどうかを属性208 に応じて決定するために使用される。例示的な実施形態では、状態メソッドはインターフェースオブジェクト210 内のｉｓ ｅｘｐｏｒｔｅｄメソッド215 として構成される。実行時、ｉｓ ｅｘｐｏｒｔｅｄメソッド215 は一般に、クラス定義200 がアプレット205 のような外部プロセスによりアクセス可能かどうかを示す状態インジケータとして動作する。したがって、クラス定義200 が外部プロセスに対してアクセス可能であると推測された場合、ｉｓ ｅｘｐｏｒｔｅｄメソッド215 は“真”のエクスポートインジケータを戻す。
【００４２】
ステップ335 において状態メソッドが呼出され、それはステップ340 においてクラス定義、すなわち一般的に述べると、インターフェースオブジェクト210 によりカプセル化されたプログラムファイルがエクスポートされることができるかどうかを決定する。クラス定義はエクスポート可能であることをエクスポートインジケータが示している場合、ステップ340 はステップ345 に進み、このステップでクラス定義は、リクエストプロセス（たとえば、アプレット205 を解釈するＶＭ126 ）にクラスローダ122 によって戻される。そうでない場合、ステップ340 は直接ステップ350 に進み、このステップにおいてクラス定義へのアクセスが制限され、そのクラス定義は、リクエストプロセスには戻されない。その代わりに、クラスローダ122 は、アクセス不可能なファイルへのアクセスを試みたエラー状態、およびリクエストされたクラス定義が見出されなかったことを示す例外を発する。
【００４３】
［結論］
上述された本発明による方法およびシステムは、プログラムファイルのような共用ライブラリ124 の部分への、あるいは、とくにオブジェクトクラス定義へのアクセスを制限する。これらの方法およびシステムはクラスローダ122 を使用して、オブジェクトクラス定義を共用ライブラリ124 からロードし、共用ライブラリ124 のロードされたクラス定義200 へのインターフェースオブジェクト210 のようなインターフェースを生成する。インターフェースの一環として、共用ライブラリ124 内の属性208 の値に応じて状態メソッドが生成される。状態メソッドを呼出すことにより、インターフェース中のカプセル化されたクラス定義が、アプレット205 のような外部プロセスによりアクセス可能であると指定されているかどうかを示すエクスポートインジケータが戻される。クラス定義が共用ライブラリに対して内部のみで使用され、外部プロセスにより使用されないことが意図されている場合、状態メソッドは、そうであることを示し、クラスローダ122 は、共用ライブラリ124 のその部分へのアクセスを制限する。
【００４４】
上記の本発明の構成の説明は、例示および説明のために記載されたものである。それは本発明を網羅するものではなく、また本発明を開示された形態に制限するものでもない。上記の教示を考慮して修正および変形が可能であり、それは本発明を実用化するときに行われてもよい。たとえば、記載されている形態はソフトウェアを含んでいるが、本発明はハードウェアおよびソフトウェアの組合せとして、あるいはハードウェアのみで構成されてもよい。本発明によるシステムは、Ｊａｖａ（商標名）プログラミング言語、Ｓｍａｌｌｔａｌｋ−８０およびＣ＋＋を含む全てのコンピュータプログラミング言語で書かれたプログラムを実行する場合にも適応可能である。
【００４５】
さらに、当業者は、本発明がオブジェクト指向のシステムに関して記載されているが、それは非オブジェクト指向のプログラミングシステムに関しも同様に実施されることができることを認識するであろう。本発明の技術的範囲は、特許請求の範囲およびその均等物により規定される。
【図面の簡単な説明】
【図１】 本発明による方法およびシステムによる使用に適したデータ処理システムのブロック図。
【図２】 本発明の１実施形態にしたがって共用ライブラリ内のファイルへのアクセスを制限するためにクラスローダがどのようにして使用されることができるかを示すブロック図。
【図３】 共用ライブラリ内のファイルへのアクセスを制限するためにクラスローダにより行なわれる本発明の１実施形態による典型的なステップを示すフローチャート。

Claims (15)

1. 共用ライブラリ内のプログラムファイルへの外部プロセスによるアクセスを制限する方法において、当該方法は、プロセッサと該プロセッサに接続されたメモリ記憶装置とを含むデータ処理システムにより実行され、当該方法は、前記プロセッサが前記メモリ記憶装置内のクラスローダを用いて、
   プログラムファイルを共用ライブラリからロードし、
   ロードされたプログラムファイルと関連したインターフェースオブジェクトを発生させ、そのインターフェースオブジェクトは状態インジケータメソッドを有しており、状態インジケータメソッドは、クラスローダ内のパッケージメソッドを呼出すことによって生成され、パッケージメソッドは、プログラムファイルがエクスポート可能かどうかを示す共用ライブラリ内の属性を読出し、且つ該属性に基づいて、プログラムファイルがエクスポート可能であるか否かを示す情報を含む状態インジケータ出力を実行されるときに供給するように状態インジケータメソッドを規定し、
   この状態インジケータメソッドの状態インジケータ出力に基づいて、プログラムファイルがエクスポート可能かどうかを決定し、
   プログラムファイルがエクスポート可能ではないと決定された場合には、プログラムファイルへのアクセスを制限する
   ステップを含んでいる方法。
2. プログラムファイルがエクスポート可能である場合、前記プロセッサがクラスローダを用いて、プログラムファイルをリクエストしているプロセスへ戻すステップをさらに含んでいる請求項１記載の方法。
3. 前記プロセッサが、プログラムファイルに対するリクエストを外部プロセスから受取るステップをさらに含んでおり、前記ロードするステップはリクエストを外部プロセスから受取ったことに応答してプログラムファイルをロードするステップをさらに含んでいる請求項１記載の方法。
4. 前記プログラムファイルをロードするステップは、クラスローダを使用してプログラムファイルとしてクラス定義をロードするステップをさらに含んでいる請求項１記載の方法。
5. 前記インターフェースオブジェクトを発生させるステップは、
   クラス定義をカプセル化しているインターフェースオブジェクトをクラス定義と関連したインターフェースオブジェクトとして発生させるステップをさらに含んでいる請求項４記載の方法。
6. 前記属性はクラス定義がエクスポートされることが可能かどうかを示す請求項４記載の方法。
7. さらに、状態インジケータ出力を供給するステップにおいて、クラス定義がエクスポートされることが可能かどうかを示すエクスポートインジケータを状態インジケータ出力として供給するために状態インジケータメソッドを呼出すステップを含んでいる請求項５記載の方法。
8. 共用ライブラリ内のオブジェクトクラス定義へのアクセスを制限する方法を行うようにデータ処理システムを制御するための命令を含んでいるコンピュータ読出し可能な記憶媒体において、前記アクセスを制限する方法が、
   クラスローダを使用して共用ライブラリからオブジェクトクラス定義をロードし、
   クラスローダ内のパッケージメソッドを呼出して、オブジェクトクラス定義に関連したインターフェースオブジェクトのインスタンスを生成し、
   クラスローダ内の前記パッケージメソッドを呼出して、オブジェクトクラス定義がエクスポート可能かどうかを示す共用ライブラリ内の属性を読出し、且つ該属性に基づいて、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを示す状態インジケータ出力を実行されるときに供給するように状態インジケータメソッドを規定することによって、前記インターフェースオブジェクトの一部分として状態インジケータメソッドを生成し、
   オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを決定するために状態インジケータメソッドを呼出し、
   オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていないことが状態インジケータメソッドにより示された場合、オブジェクトクラス定義に対するアクセスを制限するステップを含んでいる
   コンピュータ読出し可能な記憶媒体。
9. さらに、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていることが状態インジケータメソッドにより示された場合にのみ、オブジェクトクラス定義をリクエストしている外部プロセスへ戻す請求項８記載のコンピュータ読出し可能な記憶媒体。
10. さらに、オブジェクトクラス定義に対するリクエストを外部プロセスから受取り、ロードするステップは外部プロセスからのリクエストの受取りに応答してオブジェクトクラス定義をロードするステップをさらに含んでいる請求項８記載のコンピュータ読出し可能な記憶媒体。
11. 状態インジケータメソッドを呼出すステップは、クラス定義がエクスポートされることが可能かどうかを示すエクスポートインジケータを供給するために状態インジケータメソッドを呼出すステップをさらに含んでいる請求項８記載のコンピュータ読出し可能な記憶媒体。
12. 共用ライブラリファイル内のオブジェクトクラス定義へのアクセスを制限するコンピュータシステムにおいて、
    共用ライブラリファイルおよびクラスローダを維持するメモリ記憶装置と、
    このメモリ記憶装置に接続されたプロセッサとを備えており、このプロセッサは、
    クラスローダを使用してオブジェクトクラス定義をメモリ記憶装置上の共用ライブラリからロードし、
    クラスローダ内のパッケージメソッドを呼出して、メモリ記憶装置においてインターフェースオブジェクトのインスタンスを生成し、このインターフェースオブジェクトはオブジェクトクラス定義と関連しており、
    前記パッケージメソッドを呼出して、オブジェクトクラス定義がエクスポート可能かどうかを示す共用ライブラリ内の属性を読出し、且つ該属性に基づいて、実行されるときにこの状態インジケータメソッドは、前記プロセッサ上で実行する外部プロセスによりオブジェクトクラス定義がアクセス可能であるかどうかを指定する状態インジケータ出力を実行されるときに供給するよう状態インジケータメソッドを規定することによって、メモリ記憶装置において状態インジケータメソッドをインターフェースオブジェクトの一部分として生成し、
    オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されているかどうかを決定するために状態インジケータメソッドを呼出し、
    オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていないことが状態インジケータメソッドにより示された場合、オブジェクトクラス定義へのアクセスを制限するように動作するコンピュータシステム。
13. プロセッサはさらに、オブジェクトクラス定義が外部プロセスによりアクセス可能であると指定されていることが状態インジケータメソッドにより示された場合にのみ、インターフェースオブジェクトによってオブジェクトクラス定義へのアクセスを可能にするように動作する請求項１２記載のコンピュータシステム。
14. プロセッサはさらに、プロセッサ上で実行するオブジェクトクラス定義に対するリクエストを外部プロセスから受取るように動作し、ロードするステップは外部プロセスからのリクエストの受取りに応答してオブジェクトクラス定義をロードするステップをさらに含んでいる請求項１２記載のコンピュータシステム。
15. プロセッサはさらに、クラス定義がエクスポートされることが可能であるかどうかを示すエクスポートインジケータを供給するために状態インジケータメソッドを呼出すように動作する請求項１２記載のコンピュータシステム。

Images