专利名称：用于在软件应用程序储存库内提取和创建应用程序元信息的系统和方法
相关申请的交叉引用本申请要求于2004年6月21日提交的美国临时专利申请第60/589,614号的优先权，该申请通过引用包含在此。
背景在现有技术的系统中，应用程序一般作为单独的单元或“包”来对待。在众多应用程序执行环境内，期望隔离应用程序以防止由于社交问题引起的系统故障。对应用程序跨不同最终用户群体或网络的管理使得进行了解决该问题的众多不同的尝试。
名为“System and Method for Controlling Inter-Application Association throughContextual Policy Control(经由上下文策略控制来控制应用程序间关联的系统和方法)”的美国专利申请第60/598,234号的教示通过引用被包含在此。
发明概述本发明描述了在一组一个或多个储存库内集成所有软件系统以便进行自动化的配置和版本管理的方法。
根据本发明的一个方面，一种用于自动化目标机器上的依赖软件包的检测和使用的方法包括在第一软件包的安装或执行期间检测依赖性；暂停软件包的安装或执行；配置依赖软件包；以及继续第一软件包的安装或执行。检测依赖性的步骤包括向一个或多个储存库查询依赖性的步骤。此外，检测依赖性的步骤包括使用用于模板匹配的规则或向一个或多个储存库查询匹配配置信息。检测依赖性的步骤包括在目标机器上执行软件操作，其中得到的失败指示对查询储存库的需求。检测依赖性的步骤还包括搜索第一软件包的一组已配置资产。在目标机器上配置依赖软件包的步骤包括依赖软件包的安装。指示依赖软件包的配置的信息被添加到目标机器的预配置快照。在目标机器上配置依赖软件包的步骤通过模拟或虚拟安装来执行。该步骤包括更新第一软件包的配置和依赖性的一个或多个储存库。该方法还包括更新第一软件包的配置和依赖性的一个或多个储存库。
根据本发明的另一方面，一种用于自动化目标机器上的依赖软件包的检测和使用的方法，包括在第一软件包的一组安装资产中搜索对一个或多个其它依赖软件包的依赖性的指示，以及配置依赖软件包。搜索的步骤包括对包含在安装资产内的信息进行模式匹配。该步骤包括对代码分析方法的使用。
本发明的另一方面包括一种用于创建软件储存库的系统，该系统包括软件包资产存储、元数据存储和集成引擎。该系统还包括用于查询包资产存储、元数据存储和其中的依赖性的内容的规则或模板化引擎。储存库的客户机可直接查询软件包资产和/依赖包的存在。储存库包括彼此远程地操作的两个或多个储存库。该系统包括与其它储存库系统的客户机共处一地的一个储存库。
通过如附图中所示的对本发明的实施例以下更具体描述，本发明的前述和其它特征和优点将是显而易见的。
附图简述
图1是跨若干网络可访问的多个软件储存库的概念性示意图。
图2是示出由本发明的实施例使用来检测并响应配置依赖性的过程的流程图。
图3是根据本发明的一个实施例的由软件储存库的规则引擎使用的示例性规则。
详细描述在软件的执行和安装期间，非常常见的是新软件系统要求来自其它软件的协助或要求配置项目以具有特定设置。此处将被安装或执行的软件对于其它软件的这种要求或依靠称为依赖性。构建了众多不同的系统以便有助于自动化安装和配置的任务。
最常见地，使用另一程序或依赖于另一程序的一个程序在某些方面可要求在安装时或运行时中的任一时刻定位该另一程序的能力。能够正确安装而不需要依赖软件的存在的系统可被称为松耦合的。它们足够独立以在没有其它软件程序的情况下存在。要求其它程序或配置以便配置自己的系统被称为紧耦合的。
为其功能，诸如创建邮件合并或使用Outlook日历而使用Microsoft Office的紧耦合的程序可能需要能够找到Office安装以便正确地安装自己。这种情况提出了若干不同的情形。首先，一般期望与Office分离地配置程序，但仍保留其功能。其次，一般要求在安装依赖的软件程序之前已安装了Office。最后，可存在Office程序的众多版本，但在安装期间必须选择一个。
打包并分发应用程序的过程一般是相对直接的工作。然而，当应用程序和数据以某种方式依赖于彼此时复杂度上升。这些依赖性的表示和分辨会造成可使用的系统与仅适于简单任务的系统之间的区别。本发明的目的在于简化并自动化集成的复杂任务。
图1示出了跨若干网络可访问的多个软件储存库的概念性示意图。软件储存库10由与本发明的各实施例相关联的配置信息和软件资产以及元数据的一个或多个数据库组成。在软件系统安装、配置或使用期间，可在安装机器34上使用该储存库的副本，或可查询远程储存库。
软件包一般包含要安装的一个或多个文件、可执行程序、数据文件或其它配置元素。软件包在储存库内的存储形式可以与其使用时的形式相同或不同。安装软件包所需的资产是其安装资产。除被设计成协助软件包安装的安装程序以外，它们一般还包括的上述包元素。一旦安装之后，软件包将由其已配置资产表示，已配置资产是软件包中用于操作软件包以及由安装程序配置的那些部分。
储存库可按照分组或分层方式组织以反映它们如何在组织内被使用。可以理解，这些数据库可按照众多方式实现，诸如通过使用数据库、基于XML的数据文件、结构化的文件系统或能够存储必需信息且能够被正确查询和更新的任何手段。
非常常见的是组织拥有一个或多个开发、打包或测试小组，他们使用软件储存库25，此外可存在用于User Acceptance Testing(UAT)(用户验收测试)的第二组储存库30，以及最后存在在软件资产的现场生产使用中供用户和系统使用的第三组储存库32。
图1还示出了这些储存库与同一公司26或其它公司18和服务供应商14内的其它储存库的简单关系。在每一情况中，软件储存库能够从每一其它储存库中提取信息和资产以及向目标机器34提供资产。
当用户需要访问软件应用程序或资产时，它可从储存库的正文中提取。在正常环境中，应用程序在开发储存库(Development Repository)内打包，并被提供给UAT储存库(UAT Repository)以便最终用户的模拟测试。如果测试不成功，则该包被返回给开发来修理。否则，应用程序包被传输给操作团队，在那里该包被置于生产储存库(Production Repository)中以便由最终用户直接使用。注意，许多公司或部门不具有跟随该路径的资源，且通常将这些储存库的部分或全部折叠成较少的系统，甚至折叠成拥有全部功能的一个储存库。
在该系统的一个典型实施例中，用户可被认为具有他们自己的储存库36，它是所有可用储存库的子集。他们个人的储存库内包含有他们当前使用或依赖的那些资产。
如上所述，储存库的内容是包括配置信息和元数据正文的的软件资产的组合。在一个典型的储存库中，所包含的资产可以是各种类型的，包括源代码、目标文件、可执行代码、诸如COM或Java对象等对象、脚本、相关联的数据文件、对外部数据文件或源的指针或引用、或其它形式的占位程序(stub)和代理对象。通常，可存在供软件开发员使用的储存库，它包含诸如源代码等原始工程人工产物，而以上列出的储存库包含诸如可执行代码和DLL等生产对象以及其余的对象。该工程(Engineering)储存库可直接供开发、UAT或生产储存库使用，或产生可如上所述使用的安装程序。
储存库内包含的元数据用于若干目的。它被用于对所包含的材料进行组织、索引和提供结构。它还可用于提供其中存储的资产之间的关联或依赖性。通常，还提供元数据来协助部署处理，诸如关于所支持的平台的信息或执行安装任务的脚本。这样的示例储存库有用于包含关于MSI或Microsoft Installer应用程序的信息的Microsoft Orca数据库。此外，存在在一个或多个数据库中存储这种信息的其它公司和技术。一示例元数据模型是由DMTF CIM元模型使用的模型。然而，这些储存库一般限定于单个机器或仅作为程序资产的存储储存库中的任一种。
基本储存库的功能是存储这些软件对象和相关联的元数据，并提供用于对储存库进行操作的一组功能。这些操作包括但不限于，用于添加、移除和编辑储存库内的资产的方法；用于查询储存库的内容的方法；版本化(versioning)的方法；以及使用储存库的元数据工作的方法。此外，存在用于储存库间通信的一类功能以及用于诸如资产转移、发布订阅功能和储存库间查询等的一类控制。
在本发明的储存库中，还存在用于分布式查询和规则/模板处理的一组功能。分布式查询的目的在于在无需单个主储存库或索引的情况下同时支持工作流和多储存库访问两者。模板引擎提供在内容本身的文本上的语义层处查询元数据的手段。
发布处理在软件到达最终用户之前，它将在设计、构建、测试和部署的循环中历经若干变换。对该处理存在多种变型。本领域中的技术人员将理解，许多公司使用不同的过程来实现这一路径。此外，该循环可由一个或多个第三方在软件发布或可供最终用户使用之前完成。
然而，最常见的是软件以两种独立的方式创建。它由一个或一组第三方创建，并以某种方式分发给最终用户或公司实体。在这种情况中，软件系统通常分布在安装程序内，该安装程序被设计成确保软件的完整性、其在顾客位置的成功实现以及最终用户的实现的简易性。或者，许多软件程序由个人在公司或家中创建，并由该公司的成员单独使用。使用这种形式的软件，系统通常以其原始形式传递，而无需安装程序。本领域中的技术人员可认识到，在这两种情况中，软件必须以某种方式被配置成在通常与开发该软件的机器或网络不相同的目的机器或网络上操作。
取决于执行安装的公司的特性和配置，配置或安装过程涉及若干步骤。在拥有许多用户和一个或多个储存库的大型公司中，软件应用程序将离线地安装到测试机器上以便预打包成可在公司内复制的配置。该预打包将配置目标设置以反映公司网络或处理的最常见情形或细节。一旦进行了这些设置，信息可被存储在开发或测试储存库内并被调度以供最终用户进行测试。对单个用户而言，安装将直接在其主机上以及他们自己的个人储存库中完成。还注意到，宿主公司或第三方供应商将以相同的方式预配置应用程序，但试图使用广泛地适用于他们整体顾客基础(customer base)的设置。
本领域中存在用于打包和分发应用程序的多种系统。对这些产品的详细描述在以往的文献中完成。这些系统的基本目标在于为许多用户简化执行配置处理的过程，并提供正确配置和安装的更高的成功率。存在打包的三种基本形式，但本领域中的技术人员可以理解，本发明中可采用许多其它形式。
打包最简单的形式如上述通常在公司内部使用，仅将程序的资产从一个机器复制到另一个机器。可能存在某种其它配置，但它作为可以手动或根据脚本执行的单独步骤完成。在这种情况中，通常对确保软件是否可被移除、或最终用户环境是否被正确预配置不予关心。这通常留给最终用户或某些管理员来协调这些任务。
为了支持较大的用户群体，公司使用其中应用程序以其通常的配置预打包的上述方法。在该情况中，将使用测试机。在标准电子软件分发(ESD)系统中，使用在执行代表性安装之前取得机器配置的快照的技术。这在此处被称为预配置快照。在安装之后，取得第二快照。这在此处被称为后配置快照。这些快照之间的差异用于为公司创建模板安装包。
使用允许对安装进行动态记录以便创建类似包或用于“虚拟安装”的较新系统。在这些情况中，在包和储存库内创建通常较大和/或不同的元数据正文以表示软件资产。
如前所述，当应用程序和数据以某种方式彼此依赖时，该过程变得复杂。为了解决这些依赖性，全自动系统必须检测依赖性、在元数据内正确地配置依赖性、确保依赖性在进一步安装期间得到满足以及跟踪其生命周期。
依赖性检测当在测试环境中将软件包安装在最终用户机器或打包机器的任一个上时，安装程序或者复制进程将对目标机器执行众多操作以设置程序的资产、配置和资源。无论这些操作是如何记录的，紧耦合的程序将在安装期间展示出这些依赖性，而松耦合的程序则不会。
在紧耦合的程序的情况中，如果安装程序所依赖的程序没有在目的机器或网络上配置，则安装程序将失败。通常，留给最终用户或打包操作员来了解该依赖性或响应安装程序中的失败。如果程序要求数据库驱动程序的特定版本，则它将在安装期间寻找该驱动程序或试图使用或配置它。这些依赖性通常由软件制造商规定以减少失败安装的次数并支持因此产生的问题。
本发明的系统通过在运行中检测依赖性来简化并自动化该问题。使用类似于动态记录系统的技术，由安装程序使用的常见操作是挂钩或捕获，使得当它们发生时可被看到。在本发明的一个实施例中，客户机代理进程在目标机器上执行，并负责这些挂钩。操作由对诸如Windows注册表键、系统文件或其它文件系统请求、COM对象创建/查询/删除、UNIX rpm或包操作、Microsoft MSI命令等的资源的访问、改变或其它请求组成。
一旦捕获了操作之后，本发明的系统如图2所示在步骤82处来检查操作。如果在步骤84处操作与当前包一致，则在步骤86处，简单地允许如正常完成。在一个较佳实施例中，该一致性测试检查诸如创建文件或子目录等操作是否位于程序专用的目的机器内而不在系统公用位置中，也不在代表另一程序的位置中。或者，在步骤86处操作没有成功完成(步骤90)，则它可被重新插入要处理的链中，如同它不曾是当前包的一部分一样。
然后，在步骤92处，将操作与储存库或储存库内的模板进行比较。本领域的技术人员可以理解，这可按顺序或同时进行。在一个实施例中，将包括其参数和上下文的操作与一组模板进行比较以标识操作的目标。在本发明的系统中，使用规则引擎来进行操作与储存库元数据内的模板之间的比较。该模板操作可简单地在目的机器上进行，或结合可访问储存库内存在的模板。
在上述示例中，程序可使用Microsoft Office来执行其任务中的某一些。为了配置自己，程序可查询Office的存在，试图直接配置Office，或在其自身内创建链接以便与Office集成。一个示例操作可以是程序查询Windows注册表键HKLM\Software\Microsoft\Office的存在。如果该键存在，则程序将通过列举该项的子键来进一步查询哪一版本可用。
使用模板系统，可创建表示对该键或其任何子键的查询指示对Office的依赖性的元数据并将其存储在储存库内。一个示例模板在图3中示出。注意到，该较佳实施例的系统使用基于XML的配置格式，并允许regex和XPath样式的查询句法。可使用在本系统内有效的众多其它类型的模板和规则格式。
还注意到，匹配模板可包括多阶段过程。如果查询了以上的注册表键，则它将指示对Office的一般依赖性。它将不指示版本专用依赖性。可存在有助于进一步指定依赖性的若干相关或复合的模板。如果程序不进一步查询Office子键，则可创建对一般Office软件资产的依赖性。这将指示任何版本的Office可在目标机器上使用。如果稍后，查询了Office\10.0子键，则依赖性可被限于Office XP版本。
此外，部分匹配的某些模板将不创建依赖性，除非有另一模板被匹配来完成配置。如果程序在系统公共位置中搜索MSVCRT.DLL，则可推断该组件上的依赖性。然而，如果程序在其自己的目录结构内安装该对象的副本，则依赖性对程序是内部的，且没有外部依赖性存在，或者可在该组件的特定版本上创建依赖性。因此，模板系统允许部分匹配和延迟完成的技术。大多数现代规则引擎和其它逻辑程序能容易地提供这种功能。
在一个替换实施例中，储存库的数据和元数据可以被直接查询。在以上对Microsoft Office的示例性搜索中，一个或多个包可包含该Windows注册表键作为配置项。搜索方法能够为该元素直接查询该包的内容。因此，如果安装程序搜索该配置项，则它可能不能在目的机器上找到它，而是在储存库内的一个或多个包内找到。
此外，这两个实施例可被组合，使得如果模板不对操作提供解决方案，则可查询一个或多个储存库以满足该操作。为了保持示例简单，将使用与以上相同的示例，并假定不存在Office应用程序的模板，但Office的一个或多个版本存在于软件储存库中。当查询注册表键时，模板操作将失败。此时，可进行本地或分布式查询以搜索该查询的结果。
在一个示例性搜索中，注册表键HKLM\Software\Microsoft\Office将作为查询操作被发送给每一可用的储存库。如果在测试打包环境内，则系统可被配置成单独查询其它开发储存库。如果在实际使用环境中，则最终用户机器应查询所有生产储存库以及配置的第三方或外部供应商。储存库接收该查询，并内部执行对该键在其任何可用包内的存在性的搜索。
当接收了搜索的结果之后，系统将适当地配置依赖性。如果响应是否定的，则操作即失败，且安装程序不需处理失败。这是非常常见的，因为许多操作或者被设计成失败、或者失败是良性情况。作为示例，Microsoft Visio可独立于MicrosoftOffice操作，但如果Office存在，则将会不同地配置自己。如果Office不存在于任何储存库中，则Visio即继续配置自己。作为附加的步骤，本发明的系统可步骤96处在本地系统上执行操作，作为正确模拟目的机器上的操作的手段，并返回正确的出错代码。
如果一个以上响应成功，则如下所述，系统将可任选地在步骤98处基于由系统的管理性策略设置的规则或根据用户来配置依赖性(步骤100)。依赖性的配置可包括将涉及依赖性或匹配的存在的元数据发布给储存库。管理员可能想要设置储存库的偏好或分层结构，使得最终用户或包具有最近的邻居。也注意到，由于储存库能够传送包，因此所存储的涉及这些偏好的依赖性信息可在传送期间被更改。
一旦标识了依赖性之后，本发明的系统能够响应。如果依赖包或资产被包含在储存库内，则系统可任选地(步骤102)行动来确保要安装的程序将成功地安装，且如果期望则与依赖程序集成。该较佳实施例的系统能够使用虚拟安装技术(步骤110)来模拟Office系统的存在(步骤102)，安装Office系统(步骤108)以及拒绝依赖性或这些技术的组合。
在第一方法中，执行配置任务的用户将先验地向系统指示将程序与MicrosoftOffice集成的期望。这可通过向用户提供系统储存库内的可用程序的菜单，并允许用户选择与之集成的一个或多个程序来完成。使用这种方法，在候选程序被安装之前，其先决条件，诸如Microsoft Office，可被设置并添加到目的机器。这将确保如果使用快照技术，则依赖程序是预配置快照的一部分。使用虚拟安装技术，这可导致Office虚拟环境在与安装环境分离的上下文内创建。当安装程序运行时，能够看到该Microsoft Office安装程序，但它进行了什么改变将保持在该新打包的环境内。而且，自动地，将进行指示两个环境的依赖性以及如何为其操作启用正确的上下文的上下文配置。
在第二方法中，系统能够响应于安装程序的操作来动态管理程序实例的创建。因此，如果程序要查询Microsoft Office的存在，则系统将从其模板库或直接查询中识别该查询，并可自动启用Office的存在，或向用户查询是否关于启用该集成的指导。
如果被指导或配置成自动响应，则系统然后可执行依赖包的安装(步骤108)。首先，系统将暂停主要应用程序的安装。接着，如果使用快照技术，则系统将安装依赖包。如果期望单独打包，则系统将确保它被添加到预配置快照(步骤106)。如果使用虚拟安装技术，则系统将下载并在目的机器内激活依赖包(步骤110)。这也可在当前包内部或仅作为依赖上下文来进行。
在失败的情况中，当前安装将被终止，且从系统中移除。这将使系统返回至其预配置状态。然后，依赖包可被安装，且安装可重新执行。
以此方式，软件应用程序可被安装到系统上而无需对其安装依赖性的先验知识。依赖性可仅在安装时从储存库中得到。如果系统正在管理类似程序或组件的多个版本，则它也可提供测试版本依赖性的机制。这可通过使用软件的每一版本重复安装、使用依赖软件的每一版本测试所创建的软件包、或在最坏的情况中在没有其它信息的情况中创建版本依赖性来完成。以这种方法，系统已知的所有程序可以是集成的候选，因此提供了测试集成点的广泛范围，但无需在测试系统上安装所有可用的应用程序。
松耦合系统以上注意到，松耦合的系统一般不在安装时显现出依赖性。为了允许这些系统集成，若干技术可在安装时和在运行时均可用。
在软件包的安装期间，系统一般不会正常地注意到松耦合系统的任何操作。在安装结束时，系统可在包的内容中扫描这种集成的指示。通常，在表示依赖项的程序资产或数据内，存在诸如串或其它二进制数据等资源。作为示例，如果程序经由命名管道与另一程序通信，则在程序可执行代码内存在对命名管道的操作系统功能的依赖性，多半是数据或可执行代码中某处表示管道名的串\\PIPE\ExamplePipe。
众多松耦合的系统使用诸如JNI或UDDI等中央储存库以便在运行时发现绑定。如有需要，这些绑定可被先验检测，并被配置到系统内。再一次，系统可从其配置代码库中了解使用UDDI，且可搜索资源来标识其目标命名上下文。
其它系统使用后绑定(late binding)来动态加载代码。诸如WindowsLoadLibrary等系统调用可将代码上的依赖性推迟到运行时。这些调用可被标识，且系统通过静态或动态代码分析或其它手段来搜索关于依赖于什么的串和其它指示符。
或者，松耦合程序的依赖性可在运行时被检测到。某些系统允许或要求程序在打包期间执行。执行UAT的实现将具有运行时上下文，它将不是实际使用时的，而将是后安装时的。否则，依赖性的标识可在最终用户系统上完成。
在运行时或UAT期间，如果程序彼此绑定，则可在程序的操作期间标识并创建依赖性。管理员也可选择在运行时期间在最终用户机器上禁用依赖性的创建，仅允许在打包或UAT期间的依赖性。
这些依赖性可采用包括以上列出的众多形式。只是检测到经由RPC、套接字、管道、COM/DCOM和其它系统的正常相互通信。其它系统经由对彼此文件、数据或其它资产的修改来相互通信。以与以上为在安装期间检测示出的相同的方式，系统可使用模板或对储存库及其元数据的其它形式的查询来标识这些集成。
开发和管理如前所述，在系统储存库内还存在可馈送至部署储存库或从中馈送的工程信息。开发员声明构建其软件的方式变得常见，这允许元数据被发布给工程储存库和/或安装程序中。可在开发时间期间使用类似的功能来测试程序的依赖性、创作版本依赖性或独立性、或测试软件组件的各种集成。
例如，如果程序被构建成与Microsoft Office集成，并使用其Mail Merge功能，则可对该程序进行针对如储存库中存在的一个或多个版本的Office的测试。开发员可仅选择安装或模拟哪一程序以便测试。从这种测试中，元数据创建可被自动创建并被填入软件储存库内。
对一个较佳实施例中的开发时和管理这两者，提供了允许将元数据创作到储存库并为模板引擎创建模板的工具。使用这些工具，软件开发员可构建一程序，它声明其它程序应如何与其集成和如何在安装时期间发现该程序的合理方法。此外，开发员可提供用于修改可由安装程序外部配置的那些项的模板。
考虑到可应用本发明的原理的各种实施例，应理解，示出的实施例仅是示例性的，且不应认为是限制本发明的范围。例如，流程图的步骤可按不同于所描述的顺序来进行，且可在示意图中使用更多或更少的元素。尽管各实施例的各种元素被描述为以软件实现，但也可替换使用硬件或固件实现中的其它实施例，反之亦然。
本领域的普通技术人员可以清楚，用于在软件应用程序储存库内提取和创建应用程序元信息的系统和方法所涉及的方法可在包括计算机可用介质的计算机程序产品中具体化。例如，这样的一种计算机可用介质可包括可读存储器设备，诸如硬盘驱动器设备、CD-ROM、DVD-ROM或计算机磁盘，其上存储有计算机可读程序代码段。计算机可读介质也可包括通信或传输介质，诸如总线或通信链路，它们可以是光学、有线或无线的任一种，其上承载有程序代码段作为数字或模拟数据信号。
其它方面、修改和实施例落入所附权利要求书的范围内。
权利要求
1.一种用于自动化目标机器上对依赖软件包的检测和使用的方法，所述方法包括在第一软件包的安装或执行期间检测依赖性；暂停所述软件包的安装或执行；配置所述依赖软件包；以及继续所述第一软件包的安装或执行。
2.如权利要求1所述的方法，其特征在于，所述检测依赖性的步骤包括向一个或多个储存库查询所述依赖性的步骤。
3.如权利要求2所述的方法，其特征在于，所述检测依赖性的步骤包括使用用于模板匹配的规则。
4.如权利要求2所述的方法，其特征在于，所述检测依赖性的步骤包括向一个或多个储存库查询匹配配置信息。
5.如权利要求1所述的方法，其特征在于，所述检测依赖性的步骤包括在所述目标机器上执行软件操作，其中得到的失败指示对查询储存库的需求。
6.如权利要求1所述的方法，其特征在于，所述检测依赖性的步骤包括搜索所述第一软件包的一组已配置资产。
7.如权利要求1所述的方法，其特征在于，所述在目标机器上配置依赖软件包的步骤包括所述依赖软件包的安装。
8.如权利要求1所述的方法，其特征在于，指示所述依赖软件包的配置的信息被添加到所述目标机器的预配置快照。
9.如权利要求1所述的方法，其特征在于，所述在目标机器上配置依赖软件包的步骤是通过模拟或虚拟安装来执行的。
10.如权利要求1所述的方法，其特征在于，所述配置依赖软件包的步骤包括更新所述第一软件包的配置和依赖性的一个或多个储存库。
11.如权利要求1所述的方法，其特征在于，还包括更新所述第一软件包的配置和依赖性的一个或多个储存库。
12.一种用于自动化目标机器上对依赖软件包的检测和使用的方法，所述方法包括在第一软件包的一组安装资产中搜索对一个或多个其它依赖软件包的依赖性的指示；以及配置所述依赖软件包。
13.如权利要求12所述的方法，其特征在于，所述搜索的步骤包括对所述安装资产内包含的信息的模式匹配。
14.如权利要求12所述的方法，其特征在于，所述搜索的步骤包括使用代码分析方法。
15.一种用于创建软件储存库的系统，包括软件包资产存储；元数据存储；以及集成引擎。
16.如权利要求15所述的系统，其特征在于，还包括用于查询所述包资产存储、元数据存储和其中的依赖性的内容的规则或模板引擎。
17.如权利要求15所述的系统，其特征在于，所述储存库的客户机可直接查询软件包资产和/或依赖包的存在。
18.如权利要求15所述的系统，其特征在于，所述储存库包括彼此远程地操作的两个或多个储存库。
19.如权利要求18所述的系统，其特征在于，所述一个储存库与所述其它储存库系统的客户机共处一地。
全文摘要
用于自动化目标机器上对依赖软件包的检测和使用的方法包括在第一软件包的安装或执行期间检测依赖性；暂停该软件包的安装或执行；配置依赖软件包；以及继续第一软件包的安装或执行。检测依赖性的步骤包括向一个或多个储存库查询依赖性的步骤。此外，检测依赖性的步骤包括使用模板匹配的规则或向一个或多个储存库查询匹配配置信息。检测依赖性的步骤包括在目标机器上执行软件操作，其中得到的失败指示对查询储存库的需求。指示依赖软件包的配置的信息被添加到目标机器的预配置快照。在目标机器上配置依赖软件包的步骤通过模拟或虚拟安装来执行。该步骤包括更新第一软件包的配置和依赖性的一个或多个储存库。该方法还包括更新第一软件包的配置和依赖性的一个或多个储存库。
文档编号G06F9/445GK101027639SQ200580024667
公开日2007年8月29日 申请日期2005年7月21日 优先权日2004年7月21日
发明者S·谢弗 申请人:索芙特瑞斯提股份有限公司