JP2008507775A - ソフトウェアアプリケーションリポジトリ内のアプリケーションメタ情報の抽出と作成のためのシステムおよび方法 - Google Patents

Abstract

ターゲットマシン上の依存ソフトウェアパッケージの検出と使用を自動化する方法は、第１ソフトウェアパッケージのインストール又は実行期間に依存関係を検出し、ソフトウェアパッケージのインストール又は実行を休止し、依存ソフトウェアパッケージを構成し、第１ソフトウェアパッケージのインストール又は実行を継続する。依存関係を検出するステップは依存関係について１又は２以上のリポジトリに照会する。さらに、依存関係を検出するステップはテンプレートマッチング又はマッチング構成情報について１又は２以上のリポジトリに照会するルールの使用を含んでいる。依存関係を検出するステップは、ターゲットマシン上のソフトウェアオペレーションの実行を含み、その結果の失敗はリポジトリに照会する必要性を示す。依存ソフトウェアパッケージの構成を示す情報は、ターゲットマシンの事前構成スナップショットに追加される。

Description

関連出願との相互参照
本出願は、2004年7月21日出願の米国仮特許出願第60/589,614号に基づき優先権主張するものであり、その内容は引用により本明細書に含まれるものである。

本発明は、ソフトウェアアプリケーションリポジトリ(Software Application Repository)内のアプリケーションメタ情報の抽出と作成のためのシステムおよび方法に関する。

現行技術のシステムでは、アプリケーションは個別単位または「パッケージ」として扱われているのが代表的である。多くのアプリケーション環境においては、群居(sociability)問題に起因するシステム全体の障害を防止するためにアプリケーションを隔離することが望まれている。異種エンドユーザ人口またはネットワーク全体にわたってアプリケーションを管理することが誘因となって、この問題を解決するさまざまな多くの試みが行なわれている。

特許文献１の教示事項は引用により本明細書に含まれるものである。

米国特許第60/598,234号、発明の名称「コンテキストポリシ制御を通してアプリケーション相互間の関連を制御するシステムおよび方法(System and Method for Controlling Inter-Application Association through Contextual Policy Control)」

本発明は、構成とバージョン管理の自動化のためにすべてのソフトウェアシステムを１または２以上のリポジトリ(repositories)集合内に統合する方法を提供することを課題にしている。

本発明の一側面によれば、ターゲットマシン上の依存ソフトウェアパッケージ(dependent software package)の検出と使用を自動化する方法は、第１ソフトウェアパッケージのインストールまたは実行期間に、依存関係(dependency)を検出し、ソフトウェアパッケージのインストールまたは実行を休止し、依存ソフトウェアパッケージを構成し、第１ソフトウェアパッケージのインストールまたは実行を継続することを含んでいる。依存関係を検出するステップは、依存関係について１または２以上のリポジトリに照会（クエリ）するステップを含んでいる。さらに、依存関係を検出するステップは、テンプレートマッチング(template matching)またはマッチング構成情報について１または２以上のリポジトリに照会するためのルールの使用を含んでいる。依存関係を検出するステップは、ターゲットマシン上のソフトウェアオペレーションの実行を含み、その結果の障害は、リポジトリに照会する必要性があることを示している。また、依存関係を検出するステップは、第１ソフトウェアパッケージの構成に含まれる資産の集合をサーチすることを含んでいる。ターゲットマシン上の依存ソフトウェアパッケージを構成するステップは依存ソフトウェアパッケージをインストールすることを含んでいる。依存ソフトウェアパッケージの構成を示す情報は、ターゲットマシンの事前構成スナップショット(preconfiguration snapshot)に追加される。ターゲットマシン上の依存ソフトウェアパッケージを構成するステップはシミュレーションまたはバーチャルインストール(virtual installation)によって行なわれる。このステップは、第１ソフトウェアパッケージの構成と依存関係の１または２以上のリポジトリを更新することを含んでいる。この方法は、さらに、第１ソフトウェアパッケージの構成と依存関係の１または２以上のリポジトリを更新することを含んでいる。

本発明の別の側面によれば、ターゲットマシン上の依存ソフトウェアパッケージの検出と使用を自動化する方法は、１または２以上の他の依存ソフトウェアパッケージとの依存関係の通知を得るために第１ソフトウェアパッケージのインストール資産の集合をサーチし、依存ソフトウェアパッケージを構成することを含んでいる。サーチするステップは、インストール資産内に収められた情報のパターンマッチング(pattern matching)を含んでいる。このステップはコード分析方法の使用を含んでいる。

本発明のさらに別の側面では、ソフトウェアパッケージ資産ストア(software package asset store)、メタデータストア(metadata store)、および統合エンジン(integration engine)を含むソフトウェアリポジトリ(software repository)を作成するシステムが提供されている。このシステムは、さらに、パッケージ資産ストア、メタデータストアの内容およびそこに含まれる依存関係について照会するためのルールまたはテンプレーティングエンジン(templating engine)を含んでいる。リポジトリのクライアントは、ソフトウェアパッケージ資産および／または依存パッケージの存在について直接に照会（クエリ）することができる。リポジトリは相互に対して遠隔操作される２または３以上のリポジトリを含んでいる。このシステムによれば、一方のリポジトリは他方のリポジトリシステムのクライアントと同じ場所に置かれている。

本発明の上記および他の特徴と利点の理解を容易にするために、以下では、添付図面に図示の本発明の実施形態について詳しく説明する。

ソフトウェアの実行またはインストール期間に、新しいソフトウェアシステムがソフトウェアの他の部分からの支援を要求したり、構成アイテム(configuration item)に特定の設定値をもたせたりすることが非常によく行なわれている。インストールまたは実行中のソフトウェアがこのような要求を行なったり、他のソフトウェアに依存したりすることを、以下では依存関係(dependencies)と呼ぶことにする。多くの種々のシステムは、インストールと構成のタスクの自動化を支援するように構築されている。

最も普通のことは、別のシステムを使用するか、あるいはなんらかの形で別のシステムに依存するプログラムが、インストール時または実行時のいずれかにその別プログラムの所在を見つける能力を必要としていることである。正しくインストールできるが、依存ソフトウェアの存在を必要としないシステムは、疎結合(loosely coupled)と呼ぶことができる。そのようなシステムは、他のソフトウェアシステムなしでも存在するのに十分に独立している。自身を構成するために他のプログラムまたは構成を必要とするソフトウェアは密結合(tightly coupled)と呼ばれる。

メールマージ(mail merge)の作成またはOutlookカレンダの使用といった自身の機能のためにMicrosoft Officeを使用する密結合プログラムは、自身を正しくインストールするためにはOfficeのインストールを見つける能力が要求されることになる。この事情の下では、シナリオとして次のいくつかがある。第一に、プログラムをOfficeから切り離して構成するが、その機能はそのまま残しておくのが代表的である。第二に、依存ソフトウェアプログラムをインストールする前にOfficeをインストールしておく必要があるのが通常である。最後に、Officeプログラムは多数のバージョンが存在できるが、インストール期間に選択されるのは１つだけである。

アプリケーションをパッケージ化し、配布するプロセスは比較的単純な作業であるのが代表的である。しかし、アプリケーションとデータが何らかの形で相互に依存していると、問題は複雑化する。これらの依存関係を表現し、解決すると、使用可能なシステムと単純作業にのみ適しているシステムを区別することが可能になる。本発明の目標は複雑な統合化作業を容易にし、自動化することである。

図１は、複数のネットワークにわたってアクセス可能な多数のソフトウェアリポジトリを示す概念図である。ソフトウェアリポジトリ１０は、本発明の実施形態に関連するメータデータ(metadata)と共に、１または２以上の構成情報データベースとソフトウェア資産(software assets)で構成されている。ソフトウェアシステムのインストール、構成または使用期間には、リポジトリのコピーをインストールマシン(installation machine)３４で使用することも、リモートのリポジトリに照会することもできる。

ソフトウェアパッケージは、インストールされる１または２以上のファイル、実行可能プログラム、データファイルまたは他の構成エレメントで構成できるのが代表的である。リポジトリ内にソフトウェアパッケージをストアするときの形体は、その使用時の形体と異なることもあれば、そうでないこともある。ソフトウェアパッケージをインストールするために必要な資産はそのインストール資産である。この資産には、ソフトウェアパッケージのインストールを支援することを目的としたインストールプログラムに加えて、上述したパッケージエレメントが含まれているのが代表的である。ソフトウェアパッケージはインストールされると、これはその構成に含まれる資産、すなわち、ソフトウェアパッケージのうちそのソフトウェアパッケージを操作するために使用され、インストールプログラムによって構成される部分で表されることになる。

リポジトリは、リポジトリが組織内でどのような使い方をされるかを示すためにグループまたは階層構造で編成することができる。当然に理解されるように、これらのデータベースは、データベース、ＸＬＭベースのデータファイル、構造化ファイルシステム、あるいは必須情報をストアできる手段の使用を通して、多くの態様に構築し、正しく照会され、更新されるようにすることができる。
組織が１または２以上の部門、パッケージングまたはテスティンググループをソフトウェアリポジトリ２８と共にもつことは非常に普通であり、さらに第２のリポジトリがユーザアクセプタンステスティング(User Acceptance Testing UAT)３０のために存在することができ、最後に第３のリポジトリ３２がソフトウェア資産のライブで本稼動の使用においてユーザとシステムのために存在している。

図１は、これらのリポジトリと同一会社内２６の他のリポジトリまたは他の会社１８およびサービスプロバイダ１４との単純な関係も示している。各々のケースにおいて、ソフトウェアリポジトリは相互から情報と資産を引き出すことができると共に、資産をターゲットマシン３４に提供することもできる。

ユーザがソフトウェアアプリケーションまたは資産にアクセスする必要があるときは、これはこのリポジトリ本体から引き出すことができる。通常の環境では、アプリケーションは開発リポジトリ(Development Repository)内でパッケージ化され、エンドユーザのシミュレートされたテスティングのためにＵＡＴリポジトリにプロモートされている。テスティングに失敗すると、パッケージは修正のために開発リポジトリに戻される。そうでなければ、アプリケーションパッケージはオペレーションチーム(operations team)に転送され、そこでこのパッケージはエンドユーザによる直接の使用に備えて本稼動リポジトリ(Production Repository)に置かれる。なお、多くの会社または部門はこの経路をたどっていくリソースをもっていないので、しばしば、これらのリポジトリの一部または全部がもっと少ないシステムに縮小され、すべての機能のための１つのリポジトリに縮小されることさえある。

システムの代表的な実施形態では、ユーザは利用可能リポジトリのすべてのサブセットであるリポジトリ３６を独自にもっていると考えることができる。このパーソナルリポジトリ内には、ユーザが現在使用中であるか、依存している資産が収められている。

リポジトリの内容は、上述したように、構成情報とメタデータ本体を含むソフトウェア資産を組み合わせたものである。代表的なリポジトリでは、そこに収められる資産のタイプは多様であり、その中には、ソースコード、オブジェクトファイル、実行可能ファイル(executables)、ＣＯＭまたはＪａｖａ（登録商標）オブジェクトなどのオブジェクト、スクリプト、関連データファイル、外部データファイルやソースへのポインタまたは参照、あるいは他の形体のスタブやプロキシオブジェクトが含まれている。一般的に、リポジトリはソフトウェア開発者のために存在しており、そこには、ソースコードなどのオリジナルエンジニアリングアーティファクト(original engineering artifact)が収められているのに対し、上記に列挙したリポジトリは実行可能コードやＤＬＬなどの本稼動オブジェクトなどを収めている。このエンジニアリングリポジトリは開発リポジトリ、ＵＡＴリポジトリまたは本稼動リポジトリに直接に与えることも、上述したように使用されるインストールプログラムを生成することもできる。

リポジトリ内に収められたメタデータはいくつかの目的に使用される。これは、編成、インデックス付けのために使用されるほかに、そこに収められているマテリアルに構造を与えるために使用される。また、そこにストアされた資産間の関連付けや依存関係を与えるためにも使用できる。一般的に、メタデータはインストールタスクを実行するための、サポートされたプラットフォームやスクリプトに関する情報といったように、配置プロセスを支援するためにも用意される。このようなリポジトリの例としては、ＭＳＩまたはMicrosoft Installer アプリケーションに関する情報を収めておくために使用されるMicrosoft Orcaデータベースがある。さらに、この情報を１または２以上のデータベースにストアしている他の会社やテクノロジが存在している。メタデータモデルの例としては、ＤＭＴＦ ＣＩＭメタモデルがある。しかし、これらのリポジトリは、シングルマシンに限定されているか、専らプログラム資産のためのストレージリポジトリであるのが代表的である。

基本的リポジトリの機能は、これらのソフトウェアオブジェクトと関連メタデータをストアすること、およびリポジトリに対してオペレーションを行なう機能を提供することである。そのようなオペレーションとしては、リポジトリ内の資産を追加、削除および編集するメソッド、リポジトリの内容を照会（クエリ）するメソッド、バージョンを管理するメソッド、リポジトリのメタデータを取り扱うメソッドがあるが、これらに限定されない。そのほかに、資産転送、パブリッシュ・サブスクライブ(publish-subscribe)機能、リポジトリ相互間の照会といったもののリポジトリ相互間の通信と制御のための機能クラスがある。

本発明のリポジトリでは、分散照会(distributed querying)およびルール／テンプレート処理のための機能群もある。分散照会の目的は、シングルマスタリポジトリまたはインデックスを必要とすることなくワークフローとマルチリポジトリアクセスの両方をサポートすることである。テンプレートエンジン(template engine)によると、内容自体のテキストの上位のセマンティック層に置かれたメタデータを照会することができる。

パブリッシングプロセス(Publishing Process)
ソフトウェアがエンドユーザに届く前に、ソフトウェアは設計、構築、テストおよび配置のサイクルでいくつかの変形を受けることになる。このプロセスには多数の変形がある。この分野の精通者ならば理解されるように、多くの会社はこの経路を達成するために異なるプロセスを使用している。さらに、このサイクルは、ソフトウェアがエンドユーザに公表または利用可能にされる前に１または２以上のサードパーティによって行なうことができる。

しかし、最も一般的なことは、ソフトウェアが２通りの方法で作成されることである。ソフトウェアは、サードパーティまたはサードパーティ集団によって作成され、なんらかの方法でエンドユーザまたは企業エンティティに配布されている。このケースでは、ソフトウェアシステムは、インストールプログラム内で配布され、ソフトウェアの保全性(integrity)およびソフトウェアがカストマサイトで正しく実装されることを保証し、その実装をエンドユーザのために容易化する設計になっている。これとは別に、多くのソフトウェアプログラムは会社や家庭の個人によって作成され、その会社の社員だけによって使用されることが多い。この形体のソフトウェアでは、システムは、インストールプログラムなしでそのオリジナル形体で配布されるのが普通である。この分野の精通者ならば理解されるように、どちらの場合も、ソフトウェアは、開発時とは同じでないことがよくあるデスティネーションマシンまたはネットワーク上で動作するように、なんらかの形で構成されていなければならない。

構成またはインストールプロセスは、インストールを行なう会社の性格と構成に応じていくつかのステップで行なわれている。多数のユーザがいて、１または２以上のリポジトリを所有する大きな会社では、ソフトウェアアプリケーションは、その会社内で複製可能な構成内に事前パッケージ化されるためにオフサインでテストマシン上にインストールされている。この事前パッケージ化では、会社のネットワークまたはプロセスの最も一般的なシナリオまたは詳細を反映するように目標設定値(target setting)が構成されている。これらの設定値が構成されたあと、情報は開発リポジトリまたはテスティングリポジトリ内にストアされ、エンドユーザによるテスティングに備えてスケジュールすることができる。シングルユーザの場合は、インストールはユーザのホストマシン上に直接に行なわれ、独自のパーソナルリポジトリに入れられる。また、当然に理解されるように、ホスト側会社またはサードパーティのサービスプロバイダはアプリケーションを同じように事前構成するが、カストマ層全体に広く適用可能な設定値を使用することを試みている。

この分野には、アプリケーションをパッケージ化し、配布するためのシステムが多数存在している。これらのプロダクトの詳細説明は既存ドキュメントで行なわれている。これらのシステムの基本的目標は、構成プロセスを実行するプロセスを多くのユーザのために単純化し、構成とインストールを正しく行なう成功率を高めることである。パッケージ化には３つの基本形体が存在するが、この分野の精通者ならば理解されるように、他にも多数の形体を本発明に取り入れることが可能である。

最も単純形体のパッケージ化は、上述したように、会社の内部で使用されるのが普通で、プログラムの資産を一方のマシンから他方のマシンにコピーするだけのものであった。他にもいくつかの構成が存在するが、その構成は別ステップで行なわれ、これは手作業で行なわれるか、スクリプトに従って自動化されている。このケースでは、多くの場合、ソフトウェアが除去できること、またはエンドユーザ環境が正しく事前構成されていることを確かめるための配慮がなされていない。多くの場合、これらのタスクを調整するのはエンドユーザまたは何らかの管理者に任されている。

もっと大きなユーザ集団をサポートするために、会社は上述した方法を使用し、そこではアプリケーションは共通設定値で事前パッケージ化されている。このケースでは、テストマシンが使用される。標準のエレクトロニックソフトウェア配布(Electronic Software Distribution ESD)システムでは、代表的なインストールが行なわれる前にマシンの構成のスナップショットをとるテクノロジが使用されている。以下では、これを事前構成スナップショット(preconfiguration snapshot)と呼ぶことにする。インストール後は別のスナップショットがとられる。以下では、これを事後構成スナップショット(post-configuration snapshot)と呼ぶことにする。これらのスナップショット間の差は、会社のためにテンプレートインストールパッケージ(template installation package)を作成するために使用される。

類似のパッケージまたは「バーチャルインストール(virtual installation)」のために使用されるパッケージを作成するためにインストールをダイナミックに記録することを可能にする最新システムが使用されている。これらのケースでは、ソフトウェア資産を表すために、もっと大きなおよび／または異なるメタデータ本体がパッケージとリポジトリ内に作成されることがよくある。

前述したように、このプロセスは、アプリケーションとデータがなんらかの形で相互に依存していると複雑化している。これらの依存関係を解決するためには、完全自動化システムに依存関係を検出させ、依存関係をメタデータ内に正しく構成させ、以後のインスール期間に依存関係に合致していることを確かめさせ、そのライフサイクルを追跡させる必要がある。

依存関係検出(Dependency Detection)
ソフトウェアパッケージがインストールされる時点では、エンドユーザマシン側においても、テスト環境におけるパッケージ化マシン側においても、インストールプログラムまたはコピーイングプロセスは、プログラムの資産、構成およびリソースをセットアップするためにターゲットマシン上で多数のオペレーションを実行している。これらのオペレーションがどのように記録されるかに関係なく、密結合プログラムはインストール期間にこれらの依存関係を示すのに対し、疎結合プログラムは示さない。

密結合プログラムの場合には、インストールプログラムは、それが依存するプログラムがデスティネーションマシンまたはネットワーク上に構成されていないと失敗する。この依存関係について知るのは、あるいはインストールプログラムの失敗に応答するのは、エンドユーザまたはパッケージ化オペレータに任されているのが通常である。プログラムが特定バージョンのデータベースドライバを必要とするときは、プログラムはそのドライバを探し出すか、インストール期間にそのドライバを使用または構成することを試みている。これらの依存関係は、インストールの失敗回数を削減し、これらの問題に起因する問題をサポートするためにソフトウェアメーカによって記述されることがよくある。

本発明のシステムは、依存関係を実行時(on-the-fly)に検出することによってこの問題を単純化し、自動化している。インストーラ(installer)によって使用される共通オペレーションは、ダイナミック記録システムに類似の手法を使用してフック(hook)またはトラップ(trap)されるので、これらのオペレーションは発生時に見ることができる。本発明の一実施形態では、クライアントエージェントプロセスはターゲットマシン上で実行され、これらのフックを受け持っている。オペレーションとしては、Windows（登録商標） レジストリキー、システムファイルまたは他のファイルシステム要求、ＣＯＭオブジェクト作成／照会／削除、UNIX（登録商標） rpmまたはパッケージオペレーション、Microsoft MSIコマンドなどのように、デスティネーションマシンのリソースに対するアクセス、変更または他の要求がある。

あるオペレーションがトラップされると、本発明のシステムは、図２に示すようにステップ８２でそのオペレーションを調べる。そのオペレーションがステップ８４で現行パッケージに一致していると、ステップ８６でオペレーションを通常通りに完了させるだけである。好適実施形態では、ファイルまたはサブディレクトリ作成といったオペレーションがそのプログラムに固有のデスティネーションマシン内にあるか、システム共通ロケーションにあるか、あるいは別のプログラムを表すロケーションにあるかが、この一致テストでチェックされる。上記とは別に、ステップ８６によるオペレーションが正しく完了しなければ（ステップ９０）、そのオペレーションをチェインに再挿入して、それが現行パッケージの一部でないものとして処理させることができる。

次に、オペレーションはステップ９２でリポジトリまたはそのリポジトリ内のテンプレートと比較される。この分野の精通者ならば理解されるように、これは順番に行なうことも、同時に行なうこともできる。一実施形態では、そのパラメータとコンテキストを含むオペレーションはそのオペレーションのターゲットを特定するためにテンプレート群と比較される。本発明のシステムでは、ルールエンジンはオペレーションとリポジトリメタデータ内のテンプレートとの比較を行なうために使用される。このテンプレートオペレーションは単純にデスティネーションマシン上で行なうことも、アクセス可能リポジトリ内に存在するテンプレートと関連付けて行なうこともできる。

上に示した例では、プログラムはそのタスクの一部を実行するためにMicrosoft Officeを使用することができる。自身を構成するためには、プログラムはOfficeの存在について照会することも、Officeを直接に構成することを試みることも、Officeと統合するためにプログラム自体の中にリンクを作成することもできる。例示のプログラムは、Windows（登録商標） レジストリキーのHKLM＼Software＼Microsoft＼Officeの存在について照会するプログラムである。このキーが存在していれば、プログラムはこのアイテムのサブキーを列挙することによってどのバージョンが利用可能であるかについてさらに照会することが可能になる。

テンプレーティングシステムを使用すると、このキーまたはそのサブキーのいずれかの照会がOfficeとの依存関係を示すことを表すメタデータを作成して、リポジトリ内にストアすることができる。テンプレート例は図３に示されている。図に示すように、好適実施形態のシステムはＸＭＬベースの構成フォーマットを使用し、regexとXPathスタイルの照会構文を可能にしている。多くの他のタイプのテンプレートとルールフォーマットをシステム内で同じように効果的に使用することができる。

また、図示に示すように、マッチングテンプレートはマルチステージプロセスにすることができる。上に示したレジストリキーについて照会すると、Officeとの一般的依存関係が示されることになる。バージョン別の依存関係(version specific dependency)は示されない。さらに依存関係の指定を容易にする、いくつかの関連または複合テンプレート(compound template)が存在することができる。プログラムがOfficeサブキーについてさらに照会しなければ、一般的Officeソフトウェア資産との依存関係を作成することができる。このことは、Officeのどのバージョンもターゲットマシンで使用できることを示している。そのあと、Office＼10.0サブキーについて照会すれば、依存関係はOffice XPバージョンに限定することができる。

さらに、部分的にマッチングされるテンプレートの中には、別のテンプレートが構成を完了するためにマッチングされなければ、依存関係を作成しないものがいくつかある。MSVCRT.DLLのシステム共通ロケーションをプログラムにサーチさせると、そのコンポーネントとの依存関係を推定することができる。しかし、プログラムがこのオブジェクトのコピーを自身のディレクトリ構造内にインストールする場合は、依存関係はプログラム内部に存在し、外部依存関係は存在しないか、さもなければ、その特定バージョンのコンポーネントとの依存関係を作成することができる。従って、テンプレーティングシステムを使用すると、部分的マッチング(partial matching)と遅延完了(delayed completion)手法が可能になる。大部分の最新ルールエンジンと他のロジックプログラムは、この機能を容易に備えることができる。

代替実施形態では、リポジトリのデータとメタデータは直接的に照会することができる。Microsoft Officeの場合の上に示したサーチ例では、１または２以上のパッケージにこのWindows（登録商標） レジストリキーを構成アイテムとして含めておくことができる。このサーチ手法によると、このエレメントを探すためにこのパッケージの内容を直接に照会することができる。従って、インストールプログラムがこの構成アイテムを探し出す場合は、これはデスティネーションマシン上には見つからないが、リポジトリ内の１または２以上のパッケージ内に見つかることになる。

さらに、テンプレートによるとオペレーションに対する解決が得られないときは、１または２以上のリポジトリに照会してオペレーションが満足されるように両方の実施形態を結合することができる。この例を単純化するために、ここでは上記と同じ例を使用し、Officeアプリケーション用のテンプレートはないが、１または２以上のバージョンのOfficeがソフトウェアリポジトリに存在するものと想定している。レジストリキーを照会したとき、テンプレートオペレーションは失敗に終わることになる。この時点でローカルまたは分散照会を行なうと、この照会の結果を探し出すことができる。

例示のサーチでは、レジストリキーHKLM＼Software＼Microsoft＼Officeは、照会オペレーションとして各々の利用可能リポジトリに送られる。テストパッケージング環境内にあれば、システムは他の開発リポジトリだけを照会するように構成することができる。ライブ環境内にあれば、エンドユーザマシンはすべての本稼動リポジトリおよび構成に含まれるサードパーティまたは外部プロバイダに照会するはずである。リポジトリは照会を受け取り、このキーが利用可能パッケージのいずれか内に存在するかのサーチを内部で実行する。

サーチの結果を受け取ると、システムは依存関係を結果に見合うように構成する。応答が否定であれば、オペレーションは失敗するだけであり、インストーラはその失敗を処理する必要がある。多くのオペレーションは失敗するように設計されているか、失敗は幸先のよいケースのどちらかであるので、このことは非常に普通のことである。一例として、Microsoft VisioはMicrosoft Officeから独立して動作できるが、Officeが存在すれば自身を異なった構成にする。Officeがどのリポジトリにも存在しなければ、Visioは自身の構成を続けるだけである。追加のステップとして、本発明のシステムは、デスティネーションマシン上のオペレーションを正しくシミュレートし、正しいエラーコードを戻す手段として、ステップ９６によるオペレーションをローカルシステム上で実行することができる。

２つ以上の応答が続く場合は、システムは、下述するようにシステムの管理ポリシによって設定されたルールに基づいてあるいはユーザに従って、オプションとして依存関係をステップ９８に従って構成する（ステップ１００）。依存関係の構成には、依存関係または一致(match)の存在に関してメタデータをリポジトリにパブリッシュ（公表）するステップを含めることができる。管理者は、エンドユーザまたはパッケージが最寄りの近隣をもつようにリポジトリのプリファレンス(preference)または階層を設定したい場合がある。また、当然に理解されるように、リポジトリはパッケージを転送できるので、これらのプリファレンスに関してストアされた依存関係情報を転送期間に変更することができる。

依存関係が特定されると、本発明のシステムは応答することができる。依存パッケージまたは資産がリポジトリ内に収められていれば、システムは、オプションとして、インストールされるプログラムが正常にインストールされ、必要ならば依存プログラムと統合されるのを保証するように作用することができる（ステップ１０２）。好適実施形態のシステムは、バーチャルインストールテクノロジを使用してOfficeシステムの存在をシミュレートして（ステップ１０２）、Officeシステムをインストールし（ステップ１０８）、依存関係またはこれらの方法の組み合わせを拒否することができる。

第一メソッドでは、構成タスクを行なうユーザは、プログラムをMicrosoft Officeと統合したいことを、先験的にシステムに指示することになる。これは、システムのリポジトリ内の利用可能プログラムのメニューをユーザに提供し、統合しようとする１または２以上のプログラムをユーザに選択させることにより行なうことができる。この方法を使用すると、候補プログラムがインストールされる前に、Microsoft Officeのように、前提となるプログラムをセットアップし、デスティネーションマシンに追加することができる。このようにすると、スナップショットテクノロジを使用していれば、依存プログラムが事前構成スナップショットの一部になることが保証される。バーチャルインストールテクノロジを使用すると、Office用のバーチャル環境がインストール環境とは別のコンテキスト内に作成されることになる。インストーラが実行されるとき、インストーラはMicrosoft Officeインストーラを見ることができるが、インストーラが行なった変更はすべて新パッケージ内に保存される。また、２環境の依存関係とそのオペレーションに合ったコンテキストを可能にする方法を示すコンテキスト構成が自動的に作られる。

第二メソッドでは、システムは、インストールプログラムのオペレーションに応答してプログラムインスタンスの作成をダイナミックに管理することができる。従って、Microsoft Officeの存在についてプログラムに照会させると、システムはそのテンプレートベースまたは直接照会からその照会を認識し、Officeの存在を自動的に可能にするか、あるいはその統合を可能にするかどうかの指示を得るためにユーザに照会することができる。

自動的に応答するように指示または構成されていると、システムは依存パッケージのインストールを実行することができる（ステップ１０８）。最初に、システムは一次アプリケーション(primary application)のインストールを休止する。次に、スナップショットテクノロジを使用していれば、システムは依存パッケージをインストールする。個別にパッケージ化する必要があれば、システムはそのパッケージが事前構成スナップショットに追加されるようにする（ステップ１０６）。バーチャルインストールテクノロジを使用していれば、システムは依存パッケージをデスティネーションマシン内にダウンロードし、アクチベートする（ステップ１１０）。これは、現行パッケージの内部で行なうことも、単純に依存パッケージとして行なうこともできる。

失敗した場合には、現行インストールを中止して、システムから取り除くことができる。これにより、システムはその事前構成状態に戻される。そのあと、依存パッケージをインストールすることができ、インストールを再実行することができる。

以上のようにすると、インストールの依存関係を先験的に知らなくても、ソフトウェアアプリケーションをシステムにインストールすることができる。インストールの依存関係は、インストール時にリポジトリから簡単に取り出すことができる。システムが複数バージョンの類似プログラムまたはコンポーネントを管理している場合は、バージョン依存関係についてテストするメカニズムを備えることもできる。これは、ソフトウェアのバージョンごとにインストールを繰り返し、依存ソフトウェアのバージョンごとに作成されたソフトウェアパッケージをテストすることにより、あるいは最悪の場合には、他の情報がないときバージョン依存関係を作成することにより行なうことができる。この方法によると、システムに知らされたすべてのプログラムは統合化の候補になることができるので、統合化ポイントを広範にテストすることができるが、利用可能アプリケーションすべてをテストシステムにインストールしないで済むことになる。

疎結合システム(Loosely Coupled Systems)
上述したように、疎結合システムはインストール時に依存関係を示さないのが代表的である。これらのシステムが統合化できるようにするために、インストール時にも、実行時にもいくつかの手法が利用可能になっている。

ソフトウェアパッケージのインストール期間には、システムは疎結合システムのどのオペレーションにも注目しないのが通常である。インストールの終了時に、システムはこの統合化の指示を探すためにパッケージの内容をスキャンすることができる。ストリングや他のバイナリデータなどのリソースが、依存アイテムを表しているプログラムの資産やデータ内に存在することがよくある。一例として、プログラムが名前付きパイプ(named pipe)を通して別のプログラムと通信する場合は、名前付きパイプのオペレーティングシステム機能との依存関係がプログラムの実行可能コード中に存在することがあり、パイプの名前を表すストリング＼＼PIPE＼ExamplePipeがデータまたは実行可能コードの中のどこかに存在する可能性が高いことがある。

多くの疎結合システムは、実行時のバインディングを見つけるためにＪＮＩまたはＵＤＤＩなどの中央リポジトリを使用している。これらのバインディングは、必要ならば先験的に検出し、システムの中に構成することができる。この場合も、システムは、その構成に含まれるコードライブラリからＵＤＤＩを使用することは分かっており、そのターゲットの命名コンテキストを特定するためにリソースをサーチすることが可能になっている。

他のシステムはコードをダイナミックにロードするために実行時バインディング(late binding)を使用している。Windows（登録商標） LoadLibraryなどのシステムコールは、実行時までコードとの依存関係を延期することができる。これらのコールは特定することができ、システムは、スタティックまたはダイナミックコード分析または他の方法を通して、依存するもののストリングと他のインジケータを探し出す。

別の方法として、疎結合プログラムの依存関係は実行時に検出することができる。一部のシステムでは、プログラムをパッケージ化期間に実行させることが可能であり、あるいはそのことが要件になっている。ＵＡＴを実行する実装には、実行時コンテキストがあり、これはライブではなく、事後インストールになっている。その他の場合は、依存関係の特定はエンドユーザシステムで行なうことができる。

実行時またはＵＡＴの期間、プログラムが別のプログラムにバインドしている場合は、依存関係はプログラムが動作している期間に特定し、作成することができる。管理者は、実行時の期間にエンドユーザマシンでの依存関係の作成を禁止し、パッケージ化またはＵＡＴの期間にだけ依存関係を許容することを選択することもできる。

これらの依存関係は、上に列挙したものを含めて多くの形体をとることができる。ＲＰＣ、ソケット、パイプ、ＣＯＭ／ＤＣＯＭ、およびその他のシステムを通した通常の相互通信は検出されるだけである。他のシステムは、相互のファイル、データまたは他の資産の変更を通して相互通信している。インストール期間の検出に関して上に示したのと同じように、システムはテンプレートおよびリポジトリとそのメタデータを照会する他の形体を使用して、これらの統合を特定することができる。

開発と管理(Development and Administration)
開発リポジトリに供給し、あるいは開発リポジトリから供給されるエンジニアリング情報のリポジトリがシステム内に存在することもある。自分のソフトウェアが構築される手段を開発者が宣言し、メタデータがエンジニアリングリポジトリに公表されることおよび／またはインストールプログラムの中に入れられることを可能にすることは、普通の慣行になりつつある。類似の機能は、プログラムの依存関係、オーサリング(author)バージョンの依存関係または非依存関係(independencies)をテストし、さもなければソフトウェアコンポーネントの種々の統合をテストするために開発期間に使用することができる。

例えば、あるプログラムがMicrosoft Officeと統合し、そのMail Merge機能を使用するように構築されていれば、そのプログラムは、リポジトリ内に存在するときのOfficeの１または２以上のバージョンと突合せテストすることができる。開発者は、どのプログラムをインストールするか、あるいはテストのためにシミュレートするかを選択するだけで済ますことができる。このテストから、メタデータ作成は自動的に作成し、ソフトウェアリポジトリに移植(populate)することができる。

好適実施形態では開発時と管理の両方のために、メタデータを作成してリポジトリに移植し、テンプレーティングエンジンのためのテンプレートを作成することを可能にするツールが用意されている。これらのルールを使用すると、ソフトウェア開発者は、インストール時の期間に他のプログラムをどのようにこのプログラムと統合させるか、さもなければ、そのプログラムをどのように見つけさせるかの妥当なメソッドを宣言するプログラムを構築することができる。さらに、開発者は、インストールプログラムによって外部で構成可能なアイテムを変更するためのテンプレートを用意することができる。

本発明の原理が適用できる実施形態は広範囲にわたっていることに鑑みて、当然に理解されるように、図示の実施形態は単なる例示であり、本発明の範囲を限定するものではない。例えば、フロー図のステップは上述したものとは別の順序にすることが可能であり、図中に使用されているエレメントは多くすることも、少なくすることも可能である。実施形態の種々エレメントはソフトウェアで実現化されるものと説明されているが、ハードウエアまたはファームウェアで実現した他の実施形態を上記に代えて使用することも、その逆にすることも可能である。

この分野の通常の知識を有する者に自明であるように、アプリケーションメタデータ情報をソフトウェアアプリケーションリポジトリ内に作成するシステムおよび方法に関与するメソッドは、コンピュータ使用可能媒体を含むコンピュータプログラムプロダクトで具現化することが可能である。例えば、このようなコンピュータ使用可能媒体としては、ハードドライブデバイス、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはコンピュータディスケットのように、コンピュータ読取り可能プログラムセグメントコードがそこに格納されている読取り可能メモリデバイスがある。コンピュータ読取り可能媒体としては、さらに、光、ワイヤド（有線）またはワイヤレス（無線）のいずれかのバスまたは通信リンクのように、プログラムコードセグメントがデジタルまたはアナログデータ信号としてそこで搬送される通信または伝送媒体がある。

その他の側面、変更および実施形態は請求項に記載の本発明の範囲に属するものである。

複数のネットワークにわたってアクセス可能な多数のソフトウェアリポジトリを示す概念図である。 構成の依存関係を検出し、それに応答するために本発明の実施形態によって使用されるプロセスを示すフローチャートである。 本発明に実施形態によるソフトウェアリポジトリのルールエンジンによって使用されるルール例を示す図である。

Claims (19)

1. ターゲットマシン上の依存ソフトウェアパッケージの検出と使用を自動化する方法であって、該方法は、
   第１ソフトウェアパッケージのインストールまたは実行期間に、依存関係を検出し、
   ソフトウェアパッケージのインストールまたは実行を休止し、
   依存ソフトウェアパッケージを構成し、
   第１ソフトウェアパッケージのインストールまたは実行を継続する、
   ことを含むことを特徴とする方法。
2. 請求項１に記載の方法において、依存関係を検出するステップは、依存関係について１または２以上のリポジトリに照会するステップを含むことを特徴とする方法。
3. 請求項２に記載の方法において、依存関係を検出するステップは、テンプレートマッチングのためのルールの使用を含むことを特徴とする方法。
4. 請求項２に記載の方法において、依存関係を検出するステップは、マッチングする構成情報について１または２以上のリポジトリへの照会を含むことを特徴とする方法。
5. 請求項１に記載の方法において、依存関係を検出するステップは、ターゲットマシン上のソフトウェアオペレーションの実行を含み、その結果の失敗はリポジトリに照会する必要性を示していることを特徴とする方法。
6. 請求項１に記載の方法において、依存関係を検出するステップは、第１ソフトウェアパッケージの構成に含まれる資産セットをサーチすることを含むことを特徴とする方法。
7. 請求項１に記載の方法において、ターゲットマシン上の依存ソフトウェアパッケージを構成するステップは、依存ソフトウェアパッケージのインストールを含むことを特徴とする方法。
8. 請求項１に記載の方法において、依存ソフトウェアパッケージの構成を示す情報は、ターゲットマシンの事前構成スナップショットに追加されることを特徴とする方法。
9. 請求項１に記載の方法において、ターゲットマシン上の依存ソフトウェアパッケージを構成するステップは、シミュレーションまたはバーチャルインストールによって実行されることを特徴とする方法。
10. 請求項１に記載の方法において、依存ソフトウェアパッケージを構成するステップは、第１ソフトウェアパッケージの構成と依存関係の１または２以上のリポジトリを更新することを含むことを特徴とする方法。
11. 請求項１に記載の方法において、さらに、第１ソフトウェアパッケージの構成と依存関係の１または２以上のリポジトリを更新することを含むことを特徴とする方法。
12. ターゲットマシン上の依存ソフトウェアパッケージの検出と使用を自動化する方法であって、該方法は、
    １または２以上の他の依存ソフトウェアパッケージとの依存関係の通知を得るために第１ソフトウェアパッケージのインストール資産セットをサーチし、
    依存ソフトウェアパッケージを構成する、
    ことを含むことを特徴とする方法。
13. 請求項１２に記載の方法において、サーチするステップは、インストール資産内に収められた情報のパターンマッチングを行なうことを含むことを特徴とする方法。
14. 請求項１２に記載の方法において、サーチするステップは、コード分析方法を使用することを含むことを特徴とする方法。
15. ソフトウェアリポジトリを作成するシステムであって、
    ソフトウェアパッケージ資産ストアと、
    メタデータストアと、
    統合エンジンと、
    を含むことを特徴とするシステム。
16. 請求項１５に記載のシステムにおいて、さらに、パッケージ資産ストアとメタデータストアの内容、および前記ストアに含まれる依存関係について照会するためのルールまたはテンプレーティングエンジンを含むことを特徴とするシステム。
17. 請求項１５に記載のシステムにおいて、リポジトリのクライアントは、ソフトウェアパッケージ資産および／または依存パッケージの存在について直接に照会できることを特徴とするシステム。
18. 請求項１５に記載のシステムにおいて、リポジトリは、相互に対して遠隔に操作される２または３以上のリポジトリを含むことを特徴とするシステム。
19. 請求項１８に記載のシステムにおいて、一方のリポジトリは他方のリポジトリシステムのクライアントと同じ場所に置かれていることを特徴とするシステム。

Images