JP2005222524A - 要求側コンポーネントに目標コンポーネントの適切なバージョンへのアクセスを提供する方法 - Google Patents

Abstract

【課題】 オブジェクト指向プログラミングの言語およびツールにおけるバージョニングサポートをする。
【解決手段】 コンポーネントは、バイナリ互換の形でバージョン設定されていない場合、ライブラリコンポーネントと呼ぶことができる。他のコンポーネント群がそのようなコンポーネントを要求した場合、他のコンポーネント群は、要求したコンポーネントのバージョンだけを特に受け取る。他方、コンポーネントは、バイナリ互換の形でバージョン設定されている場合、プラットフォームコンポーネントと呼ぶことができる。他のコンポーネント群がそのようなコンポーネントを要求した場合、他のコンポーネント群は、要求したコンポーネントの最新のアップグレードされたバージョンを代わりに受け取ることができる。このため、コンポーネントの適切なバージョンへのアクセスが（要求されたバージョンとは異なるバージョンでも）、容易になる。
【選択図】 図１

Description

本発明は、要求側コンポーネントに目標コンポーネントの適切なバージョンへのアクセスを提供する方法に関し、より詳しくは、本発明は、ソフトウェア環境においてソフトウェアコンポーネント群を協調させるためのシステム、方法、およびコンピュータプログラム製品に関する。

コンピュータ化された電子システムは、そのようなコンピュータ化されたシステムにより、人々が以前は手作業で行わなければならなかったことの多くが自動化されることを理由の一部として、ますます一般的になっている。したがって、コンピュータ化されたシステムは、タスクを行う人々の能力にある量の効率を付加してきた。

コンピュータ化されたシステム用にコンピュータ化された命令（本明細書で、「ソフトウェア」または「プログラム」とも呼ぶ）を生成するプロセスは、多少、込み入っている。普通、ソフトウェア開発者はまず、プログラムが実行すべき所望される機能または結果を考案し、次に、通常、プログラミングソースコードの形態で、対応するテキスト形式の命令を電子テキストファイルに入力しなければならない。解釈されるプログラミング言語（例えば、Ｊａｖａ（登録商標）ｓｃｒｉｐｔ、Ｐｅｒｌなど）の場合のように一部のケースでは、コンピュータ化されたシステムは、入力されたテキスト形式の命令を直接に解釈し、所望の機能を実行する。コンパイルされるプログラミング言語（例えば、Ｃ＃（「Ｃシャープ」と読まれる）、Ｃ＋＋など）の場合のように他のケースでは、テキスト形式の命令はまず、コンピュータ化されたシステムが実行することのできるオブジェクトコードまたはマシンコードにコンパイルされる。

より複雑なプログラムでは、開発者は、ときとして、いくつかの相互運用される「コンポーネント」としてプログラムの機能を実装する。一般的に言って、コンポーネント群（またはプログラムコンポーネント群）は、より大型のアプリケーションプログラムによく似た、ただし、通常、１つまたは複数の機能を提供することに向けられているため、より小型で、それほど複雑でない傾向があるコンピュータ実行可能命令の集合である。所与のコンポーネントは、ときとして、独立のプログラムとして実行することができ、他のコンポーネント群と通信することもできるため、より複雑なプログラムも、ときとして、区別なしに「コンポーネント」と呼ぶことが可能である。さらに、コンポーネントは、一般に、「要求側コンポーネント」または「目標コンポーネント」と呼ばれる。ただし、そのような呼称は、いずれのコンポーネントまたはプログラムが他方のコンポーネントまたはプログラムにアクセスしているかに応じて任意である可能性がある。

いずれにしても、プログラム設計者は、コンピュータ化されたシステム上で１つのコンポーネントを設計して、コンピュータ化されたシステムの任意の数の他のコンポーネント群へのアクセスを要求することができる。目標コンポーネント群は、ユーザの名前や年齢などの基本的な情報を提供する機能、または所与のアプリケーションプログラムに関するユーザの使用レベルまたは熟練度（ｓｏｐｈｉｓｔｉｃａｔｉｏｎ）などのより複雑な情報を提供する機能を含むことが可能である。また、ソフトウェアコンポーネント群は、ファイルを開くコマンドを実行すること、１つまたは複数のコンポーネントまたはプログラムがさらに別のコンポーネント群と対話することができるように通信プロトコルを示すことなどのシステム機能群を提供することもできる。もちろん、大型のオペレーティングシステムは、複数の異なるプログラムでオペレートするように構成された多くのコンポーネントを含むことが可能であり、その逆も同様であることが理解されよう。

一般に、要求側コンポーネントは、目標コンポーネントへの参照を含む。要求側コンポーネントが、目標コンポーネントの特定のバージョンを参照することがあり得る（厳密な（strict）参照）。目標コンポーネントの特定のバージョンを参照することは、例えば、要求側コンポーネントの開発者が、目標コンポーネントの事前の知識を有しており、要求側コンポーネントが目標コンポーネントの指定されたバージョンに明確に依存するようにさせることを所望する場合に行われる可能性がある。例えば、「コンポーネント３」の目標「バージョン１．１」を参照するように要求側「コンポーネント１」を構成して、「コンポーネント１」が「コンポーネント３」の「バージョン１．１」に明確に依存するようにさせることができる。他方、要求側コンポーネントが開発された時点で、存在することも、存在しないことも可能な目標コンポーネントを要求側コンポーネントが参照することがあり得る（厳密でない（ｌｏｏｓｅ）参照）。このため、開発者は、目標コンポーネントの事前の知識なしに目標コンポーネントを参照する。したがって、要求側コンポーネントは、ランタイムに目標コンポーネントのバージョンの存在を発見することが可能である。例えば、ランタイムに、「コンポーネント１」が「コンポーネント３」の「バージョン２．１」を発見することが可能である。

残念ながら、要求側コンポーネントが目標コンポーネントを厳密な形で参照するか、厳密でない形で参照するかに関わらず、全体的なソフトウェア設計プロセスにおいてプログラムコンポーネント群を実装することには、いくつかの欠点が存在する。例えば、ユーザが、１つまたは複数の要求側コンポーネントによって参照される目標プログラムを更新する際、目標コンポーネントの更新されたバージョンが、その１つまたは複数の要求側コンポーネントに適合しないことになった場合、その１つまたは複数の要求側コンポーネントに障害が生じる可能性がある。この問題は、要求側コンポーネントの開発者が、関連する目標コンポーネントの開発者によって将来に実施される可能性がある変更の数とタイプを予期することができない場合に生じる可能性がある。これとは対照的に、目標コンポーネント更新を禁止する、またはコンポーネント更新が目標コンポーネント群の以前のバージョンを上書きすることを禁止するシステムポリシー群は、すぐに古くなる、または非効率で、かさばるものになる可能性があるシステムをもたらす可能性がある。

以上の諸問題を克服するいくつかの試みには、システム管理者が、同一のシステム内部の目標コンポーネント群の相異なるバージョンへの厳密な参照および厳密でない参照を管理しようとすることが含まれる。そのようなシナリオでは、コンピュータ化されたシステムが、所与の目標コンポーネントのバージョン番号を、目標コンポーネントがコンピュータシステムにインストールされた際に、または目標コンポーネントが最初に実行された際に特定する。すると、コンピュータ化されたシステムは、特定された目標コンポーネント情報を、システムにやはりインストール済みである目標コンポーネントのその他のバージョンが存在すれば、それらとともに格納する。コンピュータ化されたシステム上の要求側コンポーネントが、目標コンポーネントへのアクセスを要求した場合、コンピュータ化されたシステムは、要求側コンポーネントを適宜、目標コンポーネントの要求されたバージョンにマッチングする。

残念ながら、このタイプのシステムには、さらにいくつかの欠点が存在する。例えば、目標コンポーネントがシステムにインストールされた時点で目標コンポーネントに関して入手できる唯一の情報が、目標コンポーネントのバージョンである可能性がある。しかし、システムは、目標コンポーネントのその特定のバージョンが、目標コンポーネントの以前のバージョンのアップグレードであるかどうかを明らかにすることができない。また、システムは、開発者が、後の何らかの時点で目標コンポーネントのその特定のバージョンをアップグレードするつもりであるかどうかを明らかにすることもできない。というのは、その情報は未知だからである。その情報、ならびに他の必要なオペレーティングパラメータ群は、システム管理者によって供給されなければならない。

例えば、システム管理者は、所与の目標コンポーネントに関して入手可能なわずかな情報、または管理者が予期することに基づいてシステムを構成しようと試み、次に、その所与の目標コンポーネントがインストールされる、または最初に実行される際に、目標コンポーネントに関するその情報をシステムに提供しなければならない。詳細には、システム管理者は、しばしば、一部の要求側コンポーネントが他の目標コンポーネント群の特定のバージョンにアクセスすることを要するかどうか、およびさらに別の要求側コンポーネント群が、他の目標コンポーネント群の構成されたバージョンにアクセスすることが許されるかどうかなどを示す、相異なる目標コンポーネントに関するアクセス規則群を提供しなければならない。また、システム管理者は、要求側コンポーネントのバージョンと目標コンポーネントのバージョンの間の競合に気付くと、他のあらゆる情報も提供しなければならない。このため、要求側コンポーネントが所与の目標コンポーネントを要求した場合、システムは、通常、要求された目標のバージョン、システムに格納されている目標コンポーネントのあらゆるバージョン、および他のあらゆるシステム管理者が供給した情報に基づき、目標コンポーネントへのアクセスを許可する。

しかし、目標コンポーネントへの厳密な参照と厳密でない参照を混合するこのタイプのシステムは、システム管理者には、過度に複雑である可能性があることが認められよう。システム管理者は、サードパーティ開発者が所与の目標コンポーネントを書いている際に考えていることの内実を常に知らされているわけではないので、これは、特に当てはまる。さらに、システム管理者は、ある目標コンポーネント群が、要求側コンポーネントの他のバージョンに適合するように計画されているかどうかを常に予期できるわけではない。これは、多数の要求側コンポーネントが、所与の多数の形で多種態様な目標コンポーネントにアクセスするように構成される大型システムに関して特に当てはまる。

したがって、要求側コンポーネント群および目標コンポーネント群の現在のバージョンと将来のバージョンが、コンピュータ化されたシステムにおいて構成されたとおりに協働することを可能にするシステム、方法、およびコンピュータプログラム製品で、当技術分野における利点を実現することができる。詳細には、そのようなコンポーネント協働を可能にして、ほとんど、または全くシステム管理者からの入力なしに、プログラム群およびコンポーネント群が効果的に機能しつづけることができるようにするシステムおよび方法で、当技術分野における利点を実現することができる。

いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている（例えば、特許文献１、２参照）。

米国特許第６、６７８、６９６号明細書 米国特許第６、５６４、３７７号明細書

従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、オブジェクト指向プログラミングの言語およびツールにおけるバージョニングサポートをし、ソフトウェア環境においてソフトウェアコンポーネント群を協調させるための、要求側コンポーネントに目標コンポーネントの適切なバージョンへのアクセスを提供する方法を提供することにある。

本発明は、プログラム開発者が、プログラム機能を損なうことなしに、コンポーネント群、モジュール群、およびオペレーティングシステム群における変更に容易に対応することができるようにするシステム、方法、およびコンピュータプログラム製品で、従来の技術における以上の諸問題の１つまたは複数を解決する。詳細には、静的参照または動的参照を介して互いにアクセスするプログラム群およびコンポーネント群が、オペレーティングシステム内で互いに適合するように並存することを可能にするシステムを開示する。

本発明の少なくとも１つの典型的な実施形態では、判定モジュールが、要求側コンポーネントから、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取ることができる。要求は、指定された目標コンポーネントのバージョニングポリシーを含むことが可能である。代替として、判定モジュールは、指定された目標コンポーネントのバージョニングポリシーを特定することができる。例えば、バージョニングポリシーは、目標コンポーネント内部のデータフィールドの中に含まれることが可能である。バージョニングポリシーおよび指定されたバージョンの特定は、目標コンポーネントがインストールされた際に、または目標コンポーネントがコンピュータ化されたシステム上に展開された際に、要求に応答して行うことができる。例えば、コンポーネントスコープなどの他のポリシー群、ならびに適宜、システム管理者が提供したあらゆるポリシーも特定することができる。したがって、要求側コンポーネントは、要求の中に含まれる情報、および目標コンポーネント内部に含まれる情報に基づき、目標コンポーネントの適切なバージョンへのアクセスを許可される。

本発明の別の典型的な実施形態では、判定モジュールが、目標コンポーネントアップグレードを受け取り、目標コンポーネントおよび／または要求側コンポーネントに関連するバージョニングポリシーを特定することができる。バージョニングポリシーの中で提供される情報に基づき、判定モジュールは、目標コンポーネントをアップグレードされたコンポーネントで置き換えるか、または単に目標コンポーネントアップグレードをシステムに追加して、目標コンポーネントの元のバージョンとアップグレードされたバージョンが並存するようにすることができる。このため、要求側コンポーネントに適切なように目標コンポーネントに関するアップグレードが処理され、目標コンポーネントにアクセスするいずれの要求側コンポーネントも、必要な場合、目標コンポーネントの元のバージョン、または以前のバージョンにアクセスしつづけるようになる。

本発明のさらなる特徴および利点は、以下の説明で示し、一部は、その説明から明白となり、あるいは本発明の実施によって知ることができる。本発明の特徴および利点は、特許請求の範囲で詳細に指摘する手段および組み合わせによって実現し、得ることができる。本発明の以上の特徴、およびその他の特徴は、以下の説明および特許請求の範囲からより完全に明らかとなり、あるいは以下に示す本発明の実施によって知ることができる。

本発明によれば、オブジェクト指向プログラミングの言語およびツールにおけるバージョニングサポートをし、ソフトウェア環境においてソフトウェアコンポーネント群を協調させることができる。

本発明の前述した利点および特徴、ならびにその他の利点および特徴を得ることができるやり方を説明するため、以上に簡単に説明した本発明のより詳細な説明を、図面に示した本発明の具体的な実施形態を参照して行う。これらの図面は、本発明の典型的な実施形態だけを示しており、したがって、本発明の範囲を限定するものと見なされるべきではないことを理解して、本発明を、図面の使用を介してさらに具体的に、さらに詳細に記述し、説明する。以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。

本発明は、プログラム開発者が、プログラム機能を損なうことなしに、コンポーネント群、モジュール群、またはオペレーティングシステム群における変更に容易に対応することができるようにするシステム、方法、およびコンピュータプログラム製品を対象とする。詳細には、静的参照または動的参照を介して互いにアクセスするプログラム群およびコンポーネント群が、オペレーティングシステム内で互いに適合するように並存することを可能にするシステムを開示する。本発明の実施形態は、以下により詳細に説明するとおり、様々なコンピュータハードウェアを含む専用コンピュータまたは汎用コンピュータを含むことが可能である。

本発明の範囲内の実施形態は、コンピュータ実行可能命令またはデータ構造を担持するため、または格納しておくためのコンピュータ可読媒体も含む。そのようなコンピュータ可読媒体は、汎用コンピュータまたは専用コンピュータがアクセスすることができる任意の利用可能な媒体であることが可能である。例として、限定としてではなく、そのようなコンピュータ可読媒体は、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）、ＥＥＰＲＯＭ（electrically erasable programmable read-only memory）、ＣＤ（compact disc）−ＲＯＭ、または他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形態で所望のプログラムコード手段を担持する、または格納するのに使用することができ、汎用コンピュータまたは専用コンピュータがアクセスすることができる他の任意の媒体を含むことが可能である。

情報が、ネットワークまたは別の通信接続（配線による、または無線の、あるいは配線と無線の組み合わせの）を介してコンピュータに転送される、または供給される場合、コンピュータは、その接続をコンピュータ可読媒体と適切に見なす。そのため、あらゆるそのような接続が、コンピュータ可読媒体と適切に呼ばれる。また、以上の媒体の組み合わせも、コンピュータ可読媒体の範囲に含められなければならない。コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理デバイスが、ある機能、またはあるグループの機能を実行するようにさせる命令およびデータを含む。

図１は、判定モジュール１００が、要求側コンポーネント１０５から、コンポーネント１２０、１２５、および１３０のような別のコンポーネントまたはプログラムにアクセスする１つまたは複数の要求を受け取る本発明の実施形態を実施するための典型的なコンピュータアーキテクチャを示している。本明細書および特許請求の範囲では、「判定モジュール」１００には、例えば、コンポーネントの名前、および最初に意図されたバージョンを含む目標コンポーネントへの参照を特定し、要求を満たすのに使用される適切な目標コンポーネントを選択するために構成された実行可能命令を有する任意のタイプのモジュールが含まれることが可能である。一部の状況では、以上には、そのような目標コンポーネントが全く用意されていないと判定することが含まれることが可能であり、したがって、判定モジュール１００は、エラーを戻すように構成される。以下に詳述するとおり、判定モジュール１００は、他のいずれのコンポーネント群が、コンピュータシステム内、コンピュータプロセス内、またはコンピュータサブプロセス内で既にアクセスできるようにされているかなどの、他の情報を特定するように構成することもできる。

さらに、本明細書および特許請求の範囲では、「コンポーネント」には、解釈されるテキスト形式のファイル、およびマシン可読命令にコンパイル済みのファイルなどの、コンピュータ化されたシステム上で実行することができるあらゆる形態の実行可能命令が含まれるものと理解する。したがって、コンポーネントという用語には、多種多様な機能を提供するより大型のアプリケーションプログラム群およびシステム群と、特定の機能を有する他のコンポーネント群またはプログラム群を提供するより小型のプログラムおよび／またはシステムコンポーネント群がともに含まれることが可能である。さらに、本明細書で、「アプリケーション」、「アプリケーションプログラム」、「プログラム」、およびコンポーネントの間で、ときとして、何らかの区別をするが、それぞれをコンポーネントと適切に呼ぶことができるため、その区別は、普通、実行可能命令の１つの集合が別のコンポーネントにアクセスする要求を行っている、または要求を受け取っていることを明確にすることを目的とする、単に便宜上の区別に過ぎない。このため、「要求側コンポーネント」および「目標コンポーネント」という用語には、以下に詳述するとおり、以上の実行可能命令のいずれかが含まれることも可能である。

本発明の実施形態は、「プラットフォーム」コンポーネントまたは「ライブラリ」コンポーネントと分類されているコンポーネント群にアクセスすることができる。「プラットフォーム」コンポーネントは、コンピュータ化されたシステム内の複数の他のコンポーネントまたはプログラムがアクセスすることができるコンポーネントである。プラットフォームコンポーネントは、通常、最新の形態、またはアップグレード済みの形態でだけアクセスされ、したがって、要求側コンポーネントは、目標コンポーネントの特定のバージョンを要求するのではなく、単に、目標コンポーネントを一般的に要求すること、または目標コンポーネントの最小バージョンを要求することができる。このため、判定モジュールは、例えば、最新バージョン以外のプラットフォームコンポーネントのバージョンを提供するように構成することができる。理論上、プラットフォームコンポーネントは、アップグレードが受け取られた時点でコンポーネントアップグレードによって上書きされることが可能であるが、実際には、これが行われない可能性がある理由が存在する。プラットフォームコンポーネントは、ときとして、「バイナリ互換」コンポーネントと呼ぶこともできる。これとは対照的に、ライブラリコンポーネントは、そのライブラリコンポーネントの正確に同一のバージョンが参照された場合にだけ、別のコンポーネントまたはプログラムによってアクセスされる。

図１に示すとおり、判定モジュール１００は、要求側コンポーネント１０５から、コンポーネント１２０、１２５、および１３０のような目標コンポーネントにアクセスする要求または宣言を受け取ることができる。本開示および特許請求の範囲では、「目標コンポーネント」という用語は、要求側コンポーネントによってアクセスが求められるコンポーネントを指す。ただし、あるコンポーネントが目標コンポーネントであるか、要求側コンポーネントであるかは、いずれのコンポーネントが他方のコンポーネントへのアクセスを要求しているかに依存する、主に見方の問題であることが認められよう。このため、本明細書および特許請求の範囲において目標コンポーネントに当てはまる説明は、要求側コンポーネントにも同様に当てはまることが可能であり、その逆も同様である。

いずれにしても、要求側コンポーネント１０５は、判定モジュール１００を介してコンポーネントアクセス要求１１０を開始することができ、要求は、要求側コンポーネント１０５が、目標コンポーネント１２０、１２５、および１３０の所与のバージョンにアクセスするように構成されていることを示す。一部の実施形態では、要求１１０は、要求側コンポーネント１０５が所与のコンピュータ化されたシステム（図示せず）に最初にインストールされた際に、要求側コンポーネント１０５のソースコードの中に見られる参照であることが可能である。代替として、要求１１０は、要求側コンポーネント１０５が、実行時に、コンポーネント１２０、１２５、および１３０のような目標コンポーネントの所与のバージョンへのアクセスを要求する時点で、要求側コンポーネント１０５によって行われることが可能である。

本明細書および特許請求の範囲では、「バージョニングポリシー」には、目標コンポーネント（例えば、１２０、１２５、１３０）から判定モジュール１００に伝送されることが可能な所与のプロパティの集合の任意のプロパティが含まれる。バージョニングポリシー１３１、１３２、または１３３は、より小さいバージョン番号を有する所与の目標コンポーネントのバージョンの代わりに、対応する目標コンポーネント１２０、１２５、１３０を使用することができるかどうかを指定する。バージョニングポリシーは、所与の構成においてその目標コンポーネントを使用することができるかどうかを判定するのに判定モジュール１００が使用することが意図された追加の情報を含むことが可能である。このため、バージョニングポリシー１３２は、バージョン１．１が要求された場合に、目標コンポーネント１２５（バージョン１．２）を使用できることを指定することができる。一部の実施形態では、バージョニングポリシーは、目標コンポーネント内部の事前定義された場所で見つかる。他の実施形態では、バージョニングポリシーは、コンポーネントがシステムにインストールされる際に、または所与のコンポーネントにアクセスする第１の要求が行われる際に、判定モジュール１００に伝送されることが可能である。

したがって、要求側コンポーネントは、目標コンポーネントの特定のバージョンを要求すること、例えば、「コンポーネント１」「バージョン１．１」を求める要求１１０によって目標コンポーネントへのアクセスを要求することができる。要求側コンポーネント１０５が、目標コンポーネントの特定のバージョンを要求した場合、または目標コンポーネントの特定のバージョンと協働するように構成されている場合、判定モジュール１００は、目標コンポーネント内部に存在するバージョニングポリシー１３１、１３２、１３３に応じて、コンポーネントの特定のバージョンへのアクセスを要求側コンポーネント１０５に提供することができる。図１に示すとおり、例えば、要求側コンポーネント１０５は、要求１１０を送ることによって「コンポーネント１」の「バージョン１」を要求する。このため、判定モジュール１００は、「コンポーネント１」のより新しいバージョン、例えば、「バージョン１．２」がシステム内に存在していても、「コンポーネント１」の「バージョン１．１」１２５へのアクセスを要求側コンポーネント１０５に許可する。

これとは対照的に、一部の実施形態では、コンポーネントのあるバージョンを求める要求により、コンポーネントの別の（例えば、更新済みの、またはより新しい）バージョンへのアクセスがもたらされる。例えば、要求１００が、「コンポーネント１」の「バージョン１．１」にアクセスする要求であることが可能である。しかし、バージョニングポリシー１３１により、「バージョン１．１」はプラットフォームコンポーネントである（そのため、「コンポーネント１」の最新バージョンが、要求に応答して提供されるべきである）ことが示されることが可能である。さらに、一部の実施形態では、それでも、システム上に所与のプラットフォームコンポーネントの複数のバージョンが存在することが可能である。

このため、要求側コンポーネントは、要求側コンポーネント１０５が受け入れることができるプラットフォーム目標コンポーネントの可能な最低バージョンを示す情報も要求の中に含めることができる。例えば、要求側コンポーネント１０５が、「コンポーネント１」の「バージョン１．４」を要求し、その要求に応答して、「コンポーネント１」のより低いバージョンが戻されるべきでないことがあり得る。したがって、判定モジュール１００は、「バージョン１．１」および「バージョン１．２」がアクセス可能であっても、「コンポーネント１」の「バージョン３」へのアクセスを要求側コンポーネント１０５に提供することができる。

要求されたコンポーネントのすべてのアクセス可能なバージョンが、指定の要求されたバージョンよりも低いバージョン表示を有する場合、判定モジュール１００は、適切な応答（例えば、エラーメッセージ）を要求側コンポーネントに戻すことができる。例えば、判定モジュール１００は、「コンポーネント１」の「バージョン３」へのアクセスを有さない場合、「コンポーネント１」の「バージョン１．４以上」を求める要求に応答して、エラーメッセージを要求側コンポーネント１０５に送ることができる。

バージョン番号が、２つの部分、バージョンおよびサービス（ｓｅｒｖｉｃｉｎｇ）を含むことがあり得る。更新済みのサービスを示すバージョン番号を有するコンポーネントは、より古いサービスを示すバージョン番号を有するコンポーネントに置き換わることが許される。サービス値を利用してコンポーネントの置換を容易にすることは、バグを修正するため、またはライブラリコンポーネントに関連するか、プラットフォームコンポーネントに関連するかに関わらず、セキュリティ問題を修正するために、その他のコンポーネント群との不適合を生じさせる可能性のより低い軽微な変更を実施するのに特に有利である。つまり、サービス値は、コンポーネントのバージョンを「修正する（ｐａｔｃｈｉｎｇ）」ことを容易にすることができる。例えば、目標コンポーネント１２０が、ライブラリコンポーネントであると特定された（したがって、目標コンポーネントのバージョン１．１は、置き換えられない）場合、開発者は、それでも、そのコンポーネントのバージョン番号の中のサービス値を更新する（例えば、増分する）ことにより、目標コンポーネント１２０を更新することができる。したがって、更新された目標コンポーネント１２０は、基本的に、「バージョン１．１」の異なるサービスである。

図２Ａは、既存のコンポーネント群のより新しいバージョンを受け取る典型的なコンピュータアーキテクチャを示している。つまり、判定モジュール１００が、対応するコンピュータ化されたシステムに既に存在する目標コンポーネント群に対するアップグレードを受け取ることができる。例えば、判定モジュール１００は、ネットワーク２４０に接続されたネットワークサービスプロバイダ（図示せず）から、コンポーネント２１５および２１０を受け取ることができる。判定モジュール１００は、対応するコンピュータ化されたシステムにおいて（またはネットワークサービスプロバイダ）においてインストールプログラムを実行した結果として、コンポーネント２１５および２１０を受け取ることができる。

図示するとおり、コンポーネント２１０および２１５は、例えば、アップグレードされたコンポーネント２１０が、「コンポーネント２」の「バージョン３」アップグレードであることや、そのコンポーネントがプラットフォームコンポーネントであることなどのバージョニングポリシー情報を含む。加えて、コンポーネント２１５は、コンポーネント２１５がライブラリコンポーネントである、またはそのコンポーネント２１５が、それ以外に、コンポーネント２１５が表す特定のバージョンへのアクセスを要求側コンポーネント群に与ることができるように構成されているという情報をバージョニングポリシーの形態で含むことが可能である。

コンポーネント２１０および２１５を受け取ったことに応答して、判定モジュール１００は、それぞれの受け取られたアップグレード済みのコンポーネントの以前のバージョンを保持する（「並置（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）」更新と呼ぶことができる）か、または以前のバージョンを置き換える（「代用（ｉｎ−ｐｌａｃｅ）」更新と呼ぶことができる）かを判定する。例えば、図２Ａに示すとおり、コンポーネント２２０および２３５は、それぞれ、ライブラリコンポーネントおよびプラットフォームコンポーネントである。より具体的には、コンポーネント２１５を受け取ったことに応答して、判定モジュール１００は、「コンポーネント１」がライブラリコンポーネントであるため、「コンポーネント１」の「バージョン１」にはっきり限定してアクセスするように他のプログラム群またはコンポーネント群を構成できることを明らかにすることができる。したがって、判定モジュール１００は、コンポーネント２１５とコンポーネント２２０がともに保持されるべきであると判定することができる。

より具体的には、コンポーネント２１０を受け取ったことに応答して、判定モジュール１００は、「コンポーネント２」がプラットフォームコンポーネントであるため、コンポーネント２の最新バージョンへのアクセスが要求側のプログラム群およびコンポーネント群に与えられることを明らかにすることができる。したがって、判定モジュール１００は、コンポーネント２３５がコンポーネント２１０で置き換えられるべきであると判定することができる。

図２Ｂは、判定モジュールが保持されるべきコンポーネント群のバージョンを特定した後の図２Ａの典型的なコンピュータアーキテクチャを示している。図２Ｂに示すとおり、コンポーネント１の「バージョン１」（コンポーネント２２０）と「バージョン２」（コンポーネント２１５）がともに、システム上に留まっている（並置更新）。やはり図２Ｂに示すとおり、「コンポーネント２」の「バージョン３」（コンポーネント２１０）だけが、システム上に留まっている（代用更新）。

図３は、本発明の実施形態による異なる処理レベルにコンポーネントスコープを階層化するための典型的なコンピュータアーキテクチャを示している。階層化は、目標コンポーネントに適用されるコンポーネントスコープに基づく。例として、限定としてではなく、図３は、３つのレベルのスコープ、すなわち、「マシン」レベル３３０、「プロセス」レベル３４０、および「サブプロセス」レベル３５０を示している。しかし、本開示および特許請求の範囲を読むことで、適宜、より多いレベル、またはより少ないレベルが存在することも可能であることが認められよう。詳細には、本発明の態様は、目標コンポーネントが、所与のレベルにおいて目標の１つのバージョンだけ（すなわち、マシン全体で１つのバージョンだけ、または所与のプロセス内で１つだけ、または所与のサブプロセス内で１つだけ）が用意されることを要求するバージョニングポリシーを供給することを可能にする。

例えば、所与の目標コンポーネント３００に関連するバージョニングポリシーは、コンポーネントスコープの集合を含むことが可能である。図１を再び簡単に参照すると、コンポーネントスコープは、要求側コンポーネント１０５が、所与のプロセスレベルにおける目標コンポーネント３００にアクセスしなければならないことを示すことができる。図３に示すとおり、例えば、「コンポーネント１」「バージョン１」３００が、マシンレベルアクセスに関して特定される。目標コンポーネント３００へのアクセスを要求するシステムにインストールされたあらゆる要求側コンポーネントは、「コンポーネント１」「バージョン１」を使用しなければならない。というのは、目標コンポーネント３００は、マシンレベルアクセス向けに構成されているからである。他のバージョニングポリシープロパティの場合と同様に、このプロセスレベル制限は、目標コンポーネントの開発者により、そのコンポーネントが所与のシステムにインストールされる前に示されることが可能である。

コンポーネントスコープは、目標コンポーネント３００、３１０、３１５、３２０、および３２５に関するより大きいスコープ、またはより小さいスコープを示すこともできる。例えば、所与のコンポーネント３１０に関して特定された「バージョニングポリシー群」は、目標コンポーネント３１０の所与のバージョンが、一部のプロセス３４２、３４５、またはサブプロセス３５２、３５５の内部でだけ要求されることを示すことが可能である。図３に示すとおり、例えば、コンポーネント３１０の所与のバージョンへのアクセスを要求するあらゆる要求側コンポーネント１０５は、他の要求側コンポーネント群（システム上の）が、他のプロセス群３１５内で同一の目標コンポーネントを使用することを要することなしに、プロセス３４２内でその要求を行うことができる。このため、プロセス３４２内でコンポーネント３１０を使用することができる一方で、プロセス３４５内でコンポーネント３１５を使用することができる。さらに、プロセスＡ３４２が特定のバージョンを選択していない場合、プロセス３４０に依存するサブプロセス３５０は、コンポーネント３２０および３２５などのコンポーネント３１０の異なるバージョンを使用することができる。したがって、異なるコンポーネントへの粒状（ｇｒａｎｕｌａｒ）アクセスのこのレベルは、所与のコンポーネントがシステムにインストールされる際にシステム管理によってではなく、所与のコンポーネントが開発される際に示されることが可能である。判定モジュール１００は、各目標コンポーネントまたは各要求側コンポーネントに関する任意の特定されたコンポーネントスコープを結合して、適切な目標コンポーネントアクセスを要求側コンポーネントに提供することができる。

したがって、目標コンポーネントの適切なバージョンの特定は、例えば、コンポーネントなどの他のポリシーに基づくことが可能である。したがって、判定モジュールは、指定された目標コンポーネントのバージョニングポリシーおよびコンポーネントスコープなどの任意の特定されたポリシー、ならびに適宜、システム管理者が提供した他の任意のポリシー群に基づき、目標コンポーネントの適切なバージョンを特定することができる。

本発明は、機能ステップおよび／または非機能（ｎｏｎ−ｆｕｎｃｔｉｏｎａｌ）ステップを含む方法に関して説明することもできる。図４、図５Ａおよび図５Ｂは、コンピュータ化されたシステム内の他のプログラム群またはコンポーネント群によるコンポーネントアクセスを可能にすることに関する典型的な流れ図を示している。図４、図５Ａおよび図５Ｂの方法は、前出の図で示したプログラム群のモジュール群に関連して説明する。

図４は、本発明の実施形態によるコンポーネントアクセスを提供するための方法の典型的な流れ図を示している。図４の方法は、目標コンポーネントのバージョンを求める要求を受け取るステップ４００を含む。ステップ４００は、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取ることを含むことが可能であり、要求は、要求側コンポーネントから受け取られる。例えば、要求側コンポーネント１０５は、判定モジュール１００を介して、コンポーネント１２０、１２５、および１３０のような目標コンポーネントへのアクセスを要求することができる。また、要求が、目標コンポーネントのバージョンのバージョニングポリシーを含むこともあり得る。

また、方法は、適切な目標コンポーネントを提供する機能上の結果指向のステップ４４０も含む。ステップ４４０は、本発明を実施するための任意の数の対応するステップを含むことが可能である。しかし、図４に示すとおり、ステップ４４０は、バージョニングポリシーを特定するステップ４１０を含む。ステップ４１０は、目標コンポーネントの指定されたバージョンのバージョニングポリシーを特定することを含むことが可能である。バージョニングポリシーが要求の中に含められている場合、判定モジュール１００は、そのような含まれるバージョニングポリシーを特定することができる。代替として、判定モジュール１００は、目標コンポーネントの１つまたは複数のバージョンを参照して、目標コンポーネントの１つまたは複数のバージョンの中に格納されているバージョンポリシー群を特定することができる。例えば、判定モジュール１００は、対応するバージョニングポリシー１３１、１３２、および１３３をそれぞれが有する同一の「コンポーネント１」の「バージョン１」１２０および「バージョン２」１２５のような、コンポーネントの複数のバージョンが、システム上に存在することを明らかにすることができる。ソフトウェア開発者は、バージョニングポリシーを目標コンポーネント１２０、１２５、および１３０などの中に含めて、開発済みのプログラムまたはコンポーネントがコンパイルされた、インストールされた、または実行された時点で、判定モジュール１００がそのバージョニングポリシーを特定するようにすることができる。

ステップ４４０は、目標コンポーネントの適切なバージョンを提供するステップ４３０も含む。ステップ４３０は、指定された目標コンポーネントのバージョニングポリシーに基づいて目標コンポーネントの適切なバージョンを特定することを含むことが可能である。例えば、判定モジュール１００が、コンポーネント１２０のような、要求された目標コンポーネント（ライブラリコンポーネント）の特定のバージョンを要求側コンポーネント１０５に提供することができる。代替として、判定モジュール１００は、コンポーネント１３０のような、コンポーネント（プラットフォームコンポーネント）のより新しいバージョンを要求側コンポーネント１０５に提供することもできる。

図５Ａは、本発明の実施形態によるコンポーネントアップグレードを管理するための方法の典型的な流れ図を示している。図５Ａの方法は、目標コンポーネントにアクセスする要求側コンポーネントが、目標コンポーネントがアップグレードされた後に有効にステップしつづけるように実施することができる。図示するとおり、図５Ａに示した方法は、コンポーネント更新を受け取るステップ５００を含む。ステップ５００は、要求側コンポーネントによってアクセスされる目標コンポーネントを特定することも含むことが可能である。例えば、図１を再び参照すると、判定モジュール１００が、要求側コンポーネント１０５がインストールされた時点で、インストールされたプログラムまたはコンポーネントを特定するレジスタまたはデータベースにリンクされること、またはそのようなレジスタまたはデータベースを含むことが可能であり、あるいはコンポーネント１０５が、「コンポーネント１」の「バージョン１」１２０のような目標コンポーネントの特定のバージョンにアクセスするように構成される。この判定モジュール１００は、インストールされたプログラムの中に含まれ、プログラムがアクセスするように構成されているあらゆるコンポーネント群の中にも含まれるバージョニングポリシーに基づき、その情報を獲得することができる。

図５Ａに示した方法は、バージョニングポリシーを特定するステップ５１０を含む。ステップ５１０は、目標コンポーネントの以前のバージョンの中の中でバージョニングポリシー、および目標コンポーネントの更新されたバージョンを特定することを含むことが可能である。例えば、判定モジュール１００は、前述したとおり、目標コンポーネント１２０、１２５、および１３０のバージョンを示すことができ、目標コンポーネントがプラットフォームコンポーネントされるか、またはライブラリコンポーネントとされるかを示すことができる、目標コンポーネント１２０、１２５、および１３０のいずれかの中のバージョニングポリシーを特定する。

図５Ａに示す方法は、少なくともある程度、バージョニングポリシーに基づき、コンポーネント更新をシステムに追加するステップ５２０をさらに含む。ステップ５２０は、特定されたバージョニングポリシーに基づき、目標コンポーネントの以前のバージョンを削除すること、および／または目標コンポーネントの更新されたバージョンを追加することを含むことが可能である。例えば、目標コンポーネントの特定の以前のバージョン２２０が、そのコンポーネントがライブラリコンポーネントである場合のように、別のプログラムまたはコンポーネントによるアクセスのために要求される場合、判定モジュール１００は、以前のバージョン２２０を上書きすることをしない。判定モジュール１００は、そのコンポーネントの新しいバージョン２１５を単に追加して、そのコンポーネントの新たなバージョン２１５を要求するプログラム群またはコンポーネント群が、そのバージョンにアクセスすることができるようにする。同様に、そのコンポーネントの以前のバージョン２２０を要求するプログラム群またはコンポーネント群も、そのバージョンにアクセスすることができ、これにより、要求側のプログラムまたはコンポーネントの完全性が保たれる。これとは対照的に、所与のコンポーネント（プラットフォームコンポーネント）の特定のバージョンを要求しているプログラムまたはコンポーネントが全く特定されない場合、判定モジュール１００は、コンポーネントの最新バージョン２１０でコンポーネントの以前のバージョン２３５を単に上書きすることができる。

図５Ｂは、本発明の実施形態による１つまたは複数のプロセスレベルにおいてコンポーネントアクセスを提供するための方法の典型的な流れ図を示している。図５Ｂの方法は、１つまたは複数の目標コンポーネントを編成して、その１つまたは複数の目標コンポーネントへのアクセスが制限されるように実施することができる。図５Ｂに示した方法は、バージョニングポリシーを特定するステップ５５０を含む。ステップ５５０は、目標コンポーネント内部のバージョニングポリシーを特定することを含むことが可能である。例えば、判定モジュール１００が、要求側コンポーネントからコンポーネントアクセス要求を受け取ることができ、受け取られたアップグレード２１５、２１０の内部、既存の目標コンポーネント２２０、２２５の内部などからバージョニングを特定することができる。前述したとおり、バージョニングポリシーは、システムが、目標コンポーネントのバージョン番号を特定するのに役立つことが可能であり、目標コンポーネント２２０、２２５、および２３０がライブラリコンポーネントとされるか、プラットフォームコンポーネントとされるかを特定するのにも役立つことが可能である。

図５Ｂに示した方法は、コンポーネントに関連するコンポーネントスコープを特定するステップ５６０を含む。ステップ５６０は、目標コンポーネントに関連するコンポーネントスコープを特定することを含むことが可能であり、コンポーネントスコープは、目標コンポーネントにアクセスするように構成することができる要求側コンポーネントに関連するプロパティを特定する。例えば、目標コンポーネント、または要求側のプログラムまたはコンポーネントを、マシンレイヤ、サブプロセスレイヤなどの１つのレイヤにおいてアクセスすることができる目標コンポーネントのバージョンを示す特定のコンポーネントスコープに関連付けることができる。しかし、本明細書で説明するとおり、開発者の好みに応じて、コンポーネントアクセスを制限することができる様々なレベルが存在することが可能であることが認められよう。

図５Ｂに示す方法は、コンポーネントスコープおよびバージョニングポリシーに基づいて目標コンポーネントアクセスを許すステップ５７０を含む。ステップ５７０は、要求側コンポーネントに関連するアクセスプロパティ、および特定されたバージョニングポリシーに基づき、１つまたは複数の要求側コンポーネントの少なくとも１つが目標コンポーネントにアクセスすることを許すことを含むことが可能である。例えば、１つまたは複数のプログラムまたはコンポーネント３００が、マシン全体のプロセス群３３０に関して示される場合、任意の所与のプロセスレベルにおいて任意の所与の要求側コンポーネントにコンポーネント３００のそのバージョンだけが利用可能である。これとは対照的に、目標コンポーネントが、プロセスレベルアクセスを伴って特定される場合、判定モジュール１００は、他の要求側コンポーネント群が、適宜、所与の対応するプロセスまたはサブプロセスに関して同一の目標コンポーネントの異なるバージョンにアクセスするのを許すことができる。

図６および以下の説明は、本発明を実施することができる適切なコンピューティング環境の簡単な一般的な説明を提供することを目的としている。必須ではないが、本発明は、ネットワーク環境においてコンピュータ群によって実行されている、プログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明する。一般に、プログラムモジュールには、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書で開示する方法のステップを実行するためのプログラムコード手段の例である。そのような実行可能命令または関連するデータ構造の特定の順序は、そのようなステップにおいて記述される諸機能を実施するための対応するステップの例である。

本発明は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ネットワークＰＣ（personal computer）、ミニコンピュータ、メインフレームコンピュータなどを含め、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境において実施できることが、当業者には認められよう。本発明は、通信ネットワークを介してリンクされた（有線リンク、無線リンク、または有線リンクと無線リンクの組み合わせで）ローカル処理デバイス群およびリモート処理デバイス群によってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置の両方の中に配置することができる。

本発明は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含め、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境において実施できることが、当業者には認められよう。本発明は、通信ネットワークを介してリンクされた（有線リンク、無線リンク、または有線リンクと無線リンクの組み合わせで）ローカル処理デバイス群およびリモート処理デバイス群によってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置の両方の中に配置することができる。

図６を参照すると、本発明を実施するための典型的なシステムが、プロセッサ６２１、システムメモリ６２２、ならびにシステムメモリ６２２からプロセッサ６２１までを含む様々なシステムコンポーネント群を結合するシステムバス６２３を含む従来のコンピュータ６２０の形態で汎用コンピューティングデバイスを含んでいる。システムバス６２３は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含め、いくつかのタイプのバス構造のいずれであってもよい。システムメモリには、読み取り専用メモリ（ＲＯＭ）６２４およびランダムアクセスメモリ（ＲＡＭ）６２５が含まれる。始動中などにコンピュータ６２０内部の要素間で情報を転送するのを助けるＢＩＯＳ（Basic Input/Output System）６２６をＲＯＭ６２４の中に格納することができる。

コンピュータ６２０は、磁気ハードディスク６３９に対して読み取りおよび書き込みを行うための磁気ハードディスクドライブ６２７、リムーバブルな磁気ディスク６２９に対して読み取りまたは書き込みを行うための磁気ディスクドライブ６２８、およびＣＤ−ＲＯＭまたはその他の光媒体などのリムーバブルな光ディスク６３１に対して読み取りまたは書き込みを行うための光ディスクドライブ６３０も含むことが可能である。磁気ハードディスクドライブ６２７、磁気ディスクドライブ６２８、および光ディスクドライブ６３０は、それぞれ、ハードディスクドライブインタフェース６３２、磁気ディスクドライブインタフェース６３３、および光ディスクドライブインタフェース６３４でシステムバス６２３に接続される。以上のドライブ群および関連するコンピュータ可読媒体により、コンピュータ実行可能命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストレージがコンピュータ６２０に提供される。本明細書で説明する典型的な環境は、磁気ハードディスク６３９、リムーバブルな磁気ディスク６２９、およびリムーバブルな光ディスク６３１を使用するが、磁気カセット、フラッシュメモリカード、ＤＶＤ（Digital Versatile Disc）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含め、データを格納するための他のタイプのコンピュータ可読媒体も使用することができる。

オペレーティングシステム６３５、１つまたは複数のアプリケーションプログラム６３６、その他のプログラムモジュール６３７、およびプログラムデータ６３８を含め、１つまたは複数のプログラムモジュールを含むプログラムコード手段をハードディスク６３９、磁気ディスク６２９、光ディスク６３１、ＲＯＭ６２４、またはＲＡＭ６２５に格納することができる。ユーザは、キーボード６４０、ポインティングデバイス６４２、またはマイク、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどの他の入力デバイス群（図示せず）を介して、コマンドおよび情報をコンピュータ６２０に入力することができる。以上の入力デバイス群およびその他の入力デバイス群は、しばしば、システムバス６２３に結合されたシリアルポートインタフェース６４６を介してプロセッサ６２１に接続される。代替として、入力デバイス群は、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースで接続してもよい。モニタ６４７または別のディスプレイデバイスも、ビデオアダプタ６４８のようなインタフェースを介してシステムバス６２３に接続される。モニタに加えて、パーソナルコンピュータは、通常、スピーカやプリンタなどの他の周辺出力デバイス群（図示せず）も含む。

コンピュータ６２０は、リモートコンピュータ６４９ａおよび６４９ｂのような１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境においてもオペレートすることができる。リモートコンピュータ６４９ａおよび６４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードであることが可能であり、通常、コンピュータ６２０に関連して前述した要素の多く、またはすべてを含むが、メモリ記憶装置６５０ａおよび６５０ｂ、ならびに関連するアプリケーションプログラム６３６ａおよび６３６ｂを図６に示している。図６に示した論理接続は、例として、限定としてではなく、図示しているローカルエリアネットワーク（ＬＡＮ）６５１およびワイドエリアネットワーク（ＷＡＮ）６５２を含む。そのようなネットワーキング環境は、オフィス全体のコンピュータ網、または企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。

ＬＡＮネットワーキング環境において使用される場合、コンピュータ６２０は、ネットワークインタフェースまたはネットワークアダプタ６５３を介してローカルネットワーク６５１に接続される。ＷＡＮネットワーキング環境において使用される場合、コンピュータ６２０は、インターネットなどのワイドエリアネットワーク６５２を介して通信を確立するためのモデム６５４、無線リンク、またはその他の手段を含むことが可能である。内部にあることも、外部にあることも可能なモデム６５４は、シリアルポートインタフェース６４６を介してシステムバス６２３に接続される。ネットワーク化された環境では、コンピュータ６２０に関連して描いたプログラムモジュール群、またはプログラムモジュール群の諸部分をリモートメモリ記憶装置の中に格納することができる。図示したネットワーク接続は、典型的であり、ワイドエリアネットワーク６５２を介して通信を確立する他の手段を使用してもよいことが認められよう。

本発明は、本発明の趣旨および基本的な特性から逸脱することなく、他の特定の形態で実施することもできる。説明した実施形態は、すべての点で、例示的であり、限定するものではないとみなされるべきである。したがって、本発明の範囲は、以上の説明によってではなく、特許請求の範囲によって示される。特許請求の範囲と等価の意味および範囲に入るすべての変更は、特許請求の範囲に包含されるものとする。

本発明の原理による目標コンポーネントへのアクセスを要求側コンポーネントに提供するための典型的なコンピュータアーキテクチャを示す図である。 本発明の原理による既存のコンポーネント群のより新しいバージョンを受け取る典型的なコンピュータアーキテクチャを示す図である。 本発明の原理による保持されるべきコンポーネント群のバージョンを判定モジュールが特定した後の図２Ａの典型的なコンピュータアーキテクチャを示す図である。 本発明の原理による異なる処理レベルにコンポーネントスコープを階層化するための典型的なコンピュータアーキテクチャを示す図である。 本発明の原理によるコンポーネントアクセスを提供するための方法を示す典型的な流れ図である。 本発明の原理によるコンポーネントアップグレードを管理するための方法を示す典型的な流れ図である。 本発明の原理によるコンポーネントスコープを限定するための方法を示す典型的な流れ図である。 本発明の態様を実施するのに適した環境を示す図である。

符号の説明

１００ 判定モジュール
１０５ 要求側コンポーネント
１１０ コンポーネントアクセス要求
１２０ 目標コンポーネント
１２５ 目標コンポーネント
１３０ 目標コンポーネント

Claims (27)

1. １つまたは複数の目標コンポーネントにアクセスすることを要求することができる１つまたは複数の要求側コンポーネントを含む１つまたは複数のプログラムコンポーネントを含むコンピュータ化されたシステムにおける、要求側コンポーネントに目標コンポーネントの適切なバージョンへのアクセスを提供する方法であって、
   要求側コンポーネントから、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取るステップと、
   前記目標コンポーネントの前記指定されたバージョンのバージョニングポリシーを特定するステップと、
   前記指定された目標コンポーネントの前記バージョニングポリシーに基づいて前記目標コンポーネントの適切なバージョンを特定するステップと、
   前記要求側コンポーネントに前記目標コンポーネントの前記適切なバージョンへのアクセスを提供するステップと
   を備えることを特徴とする方法。
2. 前記目標コンポーネントの前記要求されたバージョンは、ライブラリコンポーネントとプラットフォームコンポーネントのどちらかであることを特徴とする請求項１に記載の方法。
3. 前記目標コンポーネントの適切なバージョンを特定するステップは、前記目標のより早期のバージョンを求める要求に応答して、前記より早期のバージョンとより新しいバージョンの両方が前記コンピュータ化されたシステムに利用可能であっても、前記目標コンポーネントの該より新しいバージョンを特定するステップを含むことを特徴とする請求項１に記載の方法。
4. 前記目標のより早期のバージョンを求める要求に応答して、前記より早期のバージョンとより新しいバージョンの両方が前記コンピュータ化されたシステムに利用可能であっても、前記目標コンポーネントの該より新しいバージョンを特定するステップは、より新しいバージョンが前記コンピュータ化されたシステムにおいて受け取られている場合、プラットフォームコンポーネントのより早期のバージョンが前記システム上に残っていても、該プラットフォームコンポーネントの該より新しいバージョンを特定するステップを含むことを特徴とする請求項３に記載の方法。
5. 前記目標コンポーネントの前記指定されたバージョンの前記バージョニングポリシーは、前記コンピュータ化されたシステム上で前記目標コンポーネントがコンパイルされた時点、構成された時点、インストールされた時点、および実行された時点の１つまたは複数の時点に特定されることを特徴とする請求項１に記載の方法。
6. 前記指定された目標コンポーネントを特定するバージョン情報は、前記コンピュータ化されたシステム上で前記要求側コンポーネントがコンパイルされた時点、構成された時点、インストールされた時点、および実行された時点の１つまたは複数の時点に前記要求側コンポーネントの中に格納されることを特徴とする請求項１に記載の方法。
7. 前記目標コンポーネントの以前のバージョンにアクセスすることができる１つまたは複数の要求側コンポーネントを特定するステップと、
   前記１つまたは複数の要求側コンポーネントのいずれも前記目標コンポーネントの前記以前のバージョンにアクセスするように構成されていないことを特定するステップと、
   前記目標コンポーネントの前記以前のバージョンを削除するステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
8. 前記目標コンポーネントの前記適切なバージョンは、要求された前記目標コンポーネントの前記バージョンであることを特徴とする請求項１に記載の方法。
9. 前記目標コンポーネントの前記適切なバージョンは、要求された前記目標コンポーネントの前記バージョンとは異なることを特徴とする請求項１に記載の方法。
10. 目標コンポーネントアクセスは、判定モジュールを介して前記要求側コンポーネントに提供されることを特徴とする請求項９に記載の方法。
11. 前記目標コンポーネントの前記以前のバージョンおよび前記目標コンポーネントの前記より新しいバージョンの１つまたは複数の利用可能性は、前記目標コンポーネントの前記以前のバージョンおよび前記目標コンポーネントの前記より新しいバージョンの前記１つまたは複数が前記コンピュータ化されたシステムによって受け取られた時点で、判定モジュールによって特定されることを特徴とする請求項１０に記載の方法。
12. 前記バージョニングポリシーは、前記コンピュータ化されたシステム上で前記目標コンポーネントをインストールした時点、構成した時点、および実行した時点のいずれかに先立って前記目標コンポーネント内部のコンピュータ実行可能命令の中に挿入されることを特徴とする請求項１に記載の方法。
13. 前記バージョニングポリシーは、前記目標コンポーネントのいずれかのバージョンの中でさらに特定されることを特徴とする請求項１に記載の方法。
14. 前記バージョニングポリシーは、前記目標コンポーネントの前記以前のバージョンおよび前記目標コンポーネントの前記より新しいバージョンのいずれかが、前記要求側コンポーネントの特定のバージョンによってアクセスされるように構成されていることを特定することを特徴とする請求項１３に記載の方法。
15. 前記目標コンポーネントに関連するコンポーネントスコープを特定するステップをさらに備えることを特徴とする請求項１に記載の方法。
16. 前記目標コンポーネントの前記指定されたバージョンへのアクセスは、前記目標コンポーネントに関連する前記特定されたコンポーネントスコープとシステム管理者によって供給された目標コンポーネントスコープのどちらかにさらに基づくことを特徴とする請求項１５に記載の方法。
17. 前記特定されたコンポーネントスコープは、前記目標コンポーネントの前記指定されたバージョンへのアクセスが、マシンレベル、プロセスレベル、およびサブプロセスレベルの１つまたは複数において提供されることを特徴とする請求項１６に記載の方法。
18. 前記要求された目標コンポーネントは、ライブラリコンポーネントであり、前記要求された目標コンポーネントに関連するサービス値を特定するステップをさらに備えることを特徴とする請求項１に記載の方法。
19. 前記目標コンポーネントの適切なバージョンを特定するステップは、前記特定されたバージョニングポリシーおよび前記特定されたサービス値に基づいてライブラリコンポーネントの更新されたバージョンを特定するステップを備えることを特徴とする請求項１に記載の方法。
20. １つまたは複数の目標コンポーネントにアクセスすることを要求することができる１つまたは複数の要求側コンポーネントを含む１つまたは複数のプログラムコンポーネントを含むコンピュータ化されたシステムにおける、要求側コンポーネントに目標コンポーネントの適切なバージョンへのアクセスを提供する方法であって、
    要求側コンポーネントから、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取るステップと、
    前記要求された目標コンポーネントの適切なバージョンへのアクセスを許して、前記要求側コンポーネントが、該要求側コンポーネントがアクセスするように構成されている適切な目標コンポーネントにアクセスするようにし、前記要求側コンポーネントが、アップグレードされたコンポーネントへのアクセスを要求した場合に、失敗しないようにするステップとを
    備えることを特徴とする方法。
21. 前記要求された目標コンポーネントの適切なバージョンへのアクセスを許すための前記ステップは、
    前記目標コンポーネントの前記指定されたバージョンのバージョニングポリシーを特定するステップと、
    要求側コンポーネントから、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取るステップと、
    前記要求側コンポーネントに前記目標コンポーネントの前記適切なバージョンへのアクセスを提供するステップと
    を備えることを特徴とする請求項２０に記載の方法。
22. １つまたは複数の目標コンポーネントにアクセスすることを要求することができる１つまたは複数の要求側コンポーネントを含む１つまたは複数のプログラムコンポーネントを含むコンピュータ化されたシステムにおける、目標コンポーネントをアップグレードして、前記目標コンポーネントにアクセスする要求側コンポーネントが、前記目標コンポーネントがアップグレードされた後に有効にオペレートしつづけるようにする方法であって、
    目標コンポーネントにアクセスするように構成された要求側コンポーネントを特定するステップと、
    前記目標コンポーネントの少なくとも１つの既存のバージョンおよび前記目標コンポーネントの以前にインストール済みのバージョンの中でバージョニングポリシーを特定するステップと、
    前記目標コンポーネントの少なくとも１つの前記既存のバージョンおよび前記目標コンポーネントの前記以前にインストール済みのバージョンに対応するいずれかの特定されたバージョニングポリシーに基づき、前記目標コンポーネントのいずれのバージョンが前記システム上に残るべきかを特定するステップと
    を備えることを特徴とする方法。
23. ネットワークを介してネットワークサービスプロバイダから前記目標コンポーネントの更新されたバージョンを受け取るステップをさらに備えることを特徴とする請求項２２に記載の方法。
24. 前記バージョニングポリシーにより、前記要求側コンポーネントがライブラリコンポーネントであることが示される場合、前記目標コンポーネントの前記以前にインストール済みのバージョンを削除することなしに、前記目標コンポーネントの前記既存のバージョンを前記システムに追加することを特徴とする請求項２２に記載の方法。
25. 前記バージョニングポリシーにより、前記要求側コンポーネントがプラットフォームコンポーネントであることが示される場合、前記目標コンポーネントの前記以前にインストール済みのバージョンを前記目標コンポーネントの前記既存のバージョンで上書きすることを特徴とする請求項２２に記載の方法。
26. １つまたは複数のソースコンポーネントにアクセスするように構成された１つまたは複数の要求側コンポーネントを含むコンピュータ化されたシステム内で、実行された場合、
    要求側コンポーネントから、目標コンポーネントの指定されたバージョンにアクセスする要求を受け取るステップと、
    前記目標コンポーネントの前記指定されたバージョンのバージョニングポリシーを特定するステップと、
    前記指定された目標コンポーネントの前記バージョニングポリシーに基づいて前記目標コンポーネントの適切なバージョンを特定するステップと、
    前記要求側コンポーネントに前記目標コンポーネントの前記適切なバージョンへのアクセスを提供するステップと
    を含む前記要求側コンポーネントに前記目標コンポーネントの適切なバージョンへのアクセスを提供する方法を前記コンピュータ化されたシステムに実行させるコンピュータ実行可能命令を格納していることを特徴とするコンピュータプログラム製品。
27. １つまたは複数のソースコンポーネントにアクセスするように構成された１つまたは複数の要求側コンポーネントを含むコンピュータ化されたシステム内で、実行された場合、 要求側コンポーネントが目標コンポーネントにアクセスするように構成されていることを特定するステップと、
    前記目標コンポーネントの少なくとも１つの既存のバージョンおよび前記目標コンポーネントの以前にインストール済みのバージョンの中のバージョニングポリシーを特定するステップと、
    前記目標コンポーネントの少なくとも１つの前記既存のバージョンおよび前記目標コンポーネントの前記以前にインストール済みのバージョンに対応するいずれかの特定されたバージョニングポリシーに基づき、前記目標コンポーネントのいずれのバージョンがシステム上に残るべきかを特定するステップと
    を含む前記目標コンポーネントをアップグレードする方法を前記コンピュータ化されたシステムに実行させて、前記目標コンポーネントにアクセスする前記要求側コンポーネントが、前記目標コンポーネントがアップグレードされた後に有効にオペレートしつづけるようにするコンピュータ実行可能命令を格納していることを特徴とするコンピュータプログラム製品。

Images