[发明专利]决定是否在多个候选环境的一中安装第一应用的方法、系统及计算机程序

说明书

技术领域

本发明涉及安装应用。

背景技术

OSGi联盟（http://www.osgi.org/Ma in/HomePage）为一标准组织，其已定义了Java^TM的动态模块框架。（Java及所有基于Java的商标与标志为Sun Microsys tems公司在美国、其他国家或这两者的商标。）

OSGi所定义的模块性单元为OSGi“束”（bundle），其为含有OSGi元数据作为jar清单（manifest）中的额外标头的jar归档（archive）。在OSGi中尚未标准化由多个束组成的“应用”的概念，但诸如Spring dm Server及Apache Aries的技术已将应用定义为OSGI束（代码模块）的集合。为了减少内存及CPU使用，可在单个OSGi框架实例中运行多个应用。这些应用可指定对其他束、包（package）或服务的依赖性。

将相对于包依赖性给出本文所提供的示例。此举仅为便于解释，且应了解，这些示例同等地适用于其他类型的依赖性，诸如束及服务。

期望应用提供隔离边界，以使得不能自外部看到应用内部。因此，重要的是，处在同一框架实例中的应用不将其束所输出的包曝露给其他应用，除非提供应用选择输出包。举例而言，应用X含有束A且应用Y含有束B。束A输出包Q，同时束B指定输入包Q。然而，并不期望包Q在应用X外部被使用。因此应用X并不指定输出该包。然而，必需提供额外支持以防止无意地在应用间共享包。以下将描述可能的解决方案及其缺点。

一个额外的考虑是应用可指定版本级约束。举例而言，应用X可包括束A，其输入在1.0至1.5范围内的包Q。处在同一应用内的束B输出1.2版本的包Q。然而，应用Y（与应用X一起执行）含有束C，其输出1.3版本的包Q。在缺少任何应用隔离的情况下，束A将通常使用与其输入范围匹配的包Q的最新版本且将因此使用来自束C的包。

然而，应用X利用应用Y的1.3版本的包可能并非所期望的。已使用特定束及包测试每个应用且确保其质量。即使束A已指定其支持的范围，但实际上它可能并未被测试该范围内所有版本；相反可能存在长期计划来最终以所支持范围内的所有版本测试A。

在具有单个全局类路径（classpath）的简单Java虚拟机（JVM）中，不可能并排地执行同一Java类的多个版本。这是因为JVM将仅使用其在类路径上发现的第一版本。OSGi通过对每个束具有相异的类路径及类加载器实现了这一点。随后，每个束可含有同一类的不同版本，且束可表现对特定包版本（及因此类版本）的依赖性。

在相比较于符合OSGi标准的模块系统而言低模块化的系统中，解决此类问题的机会将更受限制。举例而言，已知当将固件级下载至通讯节点上时，如果一节点已经具有比将下载到该节点上的级更高级的固件，则安装将不会发生。此外，已知在打包（packaging）中安装过程寻找被应用到AIX的补丁（patch）之间的依赖性。如果存在冲突，则安装足够数量的补丁以使得系统能工作。还已知当将应用服务器应用安装到混合版本单元（cell）（包含不同版本的WebSphere应用服务器节点的管理单元）时，应用将仅被安装在支持该应用的要求的WebSphere应用服务器节点（换言之，处于正确版本的节点）上。（IBM、WebSphere和AIX是国际商业公司在美国、其他国家或这两者中的商标或注册商标。）

OSGi环境呈现导致其自身问题的不同的一组预期。

Spring dm Server使用单个框架实例，且依赖于系统在运行时向任何束、包及服务依赖性添加命名约定以隔离应用。此方法并不理想，因为知晓约定的任何用户可容易地获得对应用内部的访问。

将OSGi框架嵌套在另一框架内的概念正在OSGi联盟中被标准化，作为用于使内部中间件能力与应用隔离（所以应用不能访问中间件内部）的手段。

嵌套框架还被视为用于使应用彼此隔离的可能机制。各应用将部署在其自身的嵌套框架中，因此具有其自身的包解析范围。从提供应用隔离的观点看，此解决方案是理想的，但在存在数十或数百个应用的情况下，它可能引起显著的伸缩性问题。另外，各框架实例具有相关成本（存储器、CPU等等）。

发明内容