开发 Java 应用程序以在 OSGi JVM 服务器中运行

定义依赖关系

当一个 OSGi 捆绑包使用另一个 OSGi 捆绑包的 Java 包时，必须明确表达这两个捆包之间的接口。 使用软件包的捆绑包必须在其 manifest.mf 中的 Import-Package 语句中添加软件包。 提供软件包的软件包必须在其 manifest.mf 中的 Export-Package 语句中添加软件包。 当两个 OSGi 捆绑包都部署到环境中时，就可以解决依赖关系问题了。

OSGi bundle 使用的所有软件包，包括 javax.* 等 JRE 扩展，都必须显式导入。 即使运行时间可以通过其他方式（如 bootdelegation ）找到这些软件包，情况也是如此。 假设默认情况下只有核心 java.* 软件包可用。

还有其他表达依赖关系的方法，特别是捆绑头 Require-Bundle。 然而，Require-Bundle 则更加粗粒度，将消费者与特定的捆绑绑定。 使用 Require-Bundle 还会妨碍架构的灵活性，限制软件包的独立版本能力。

OSGi 捆绑软件中的 JCICS 限制

在 OSGi 捆绑包中使用 JCICS API 类时有这些限制：

• JCICS API 调用不能在 OSGi 捆绑程序的 activator 类中使用。
  注意：运行 OSGi 捆绑程序激活程序的 Java 线程不会启用 JCICS。 开发人员可以使用 CICSExecutorService.runAsCICS() 方法，从激活器启动一个启用了 JCICS 的新线程。 任何 JCICS 命令都将使用发出安装命令的用户标识的权限来运行。 因此，管理员在安装 OSGi 捆绑激活器之前，最好先了解其使用的资源。 有关如何使用 runAsCICS() 方法的更多信息，请参阅 线程和任务示例。
• OSGi 捆绑激活器中使用的启动和停止方法必须在合理的时间内返回。

JRE 类可见性、引导转授和 system.packages.extra

在 OSGi 中，核心 JRE 包/类（java.*）的加载总是委托给引导类加载器。 假定系统中只有一个 JRE，因此不需要明确的依赖声明。 因此，没有必要在 bundle 清单中添加 java.* 依赖关系。 但是，对于 JRE 的其他部分，需要这些包的应用程序捆绑包必须编写导入包语句；例如，特定于供应商的扩展 javax.* com.sun.* 和 com.ibm.* 需要导入。 这是因为它们没有委托给引导类加载器，而是被视为 OSGi 系统的一部分。

OSGi 框架提供了一个系统捆绑包，可自动向系统公开已知的扩展包。 与 OSGi 捆绑包提供的所有其他软件包一样，应用程序捆绑包通过包含 Import 语句来注册其依赖关系。 这种方法的优势在于，通过安装包含新代码的 OSGi 捆绑包，扩展可以被更新的实现所取代。

这一过程的例外情况是，通过使用特殊的 OSGi 属性，将特定软件包添加到 bootdelegation 列表中。 虽然这样做很方便（因为访问这些软件包不需要 Import 语句），但它限制了 OSGi 的灵活性，而且不被视为最佳实践。 有时，OSGi 实现不会自动将特定于供应商的扩展添加到系统捆绑包中。 在这些情况下，假设软件包确实可从 JRE 中获取，则可使用属性 -Dorg.osgi.framework.system.packages.extra 将软件包添加到系统捆绑包中，并允许应用程序 Imports 进行解析。

捆绑激活器

捆绑激活器是 OSGi 捆绑程序中实现 BundleActivator 接口的类。 要使用激活器，OSGi 捆绑程序必须在捆绑程序清单中使用 Bundle-Activator 标头声明激活器。 BundleActivator 接口有 start 和 stop 方法，可用于执行初始化或终止工作。 一种常见的模式是在应用程序中查找服务依赖关系。 不过，最好还是采用声明式服务等组件模型来激活组件及其服务依赖关系。

单件包

单例捆绑包用于防止在内存中加载任何其他版本的捆绑包，在任何时候，运行时只能有一个已解析的版本。 当一组应用程序需要访问单个系统资源时，使用单例捆绑包是可取的。

OSGi 捆绑程序片段

片段是 OSGi 框架动态附加到主机捆绑包的 OSGi 捆绑包。 它们共享其主捆绑包的类加载器，不参与捆绑包的生命周期，因此不支持捆绑包激活器。 片段的常见用例如捆绑 补丁。 在 Bundle-ClassPath 上 . 前面提供的片段允许优先从片段而不是主机加载类。

OSGi 服务注册表

OSGi 服务注册表可使捆绑包向共享注册表发布对象。 服务在 Java 接口下发布广告，并提供给安装在 OSGi 环境中的其他捆绑包。

微服务（μServices）

微服务是一种软件架构风格，在这种风格中，复杂的应用程序由独立的小型组件组成，这些组件之间使用语言无关的应用程序接口进行通信。 这些服务规模小、高度解耦，专注于完成一项小任务，有利于采用模块化方法构建系统。 在 OSGi 组件之间使用 μServices 可提供灵活性和动态更新功能，这是单独使用捆绑 布线无法实现的。 因此，我们鼓励使用 μServices 而不是捆绑式布线。

捆绑软件和软件包版本控制

执行环境

Bundle-RequiredExecutionEnvironment: JavaSE-1.7