|
OSGi服务平台由两部分组成：OSGi框架和OSGi标准服务（如图1-3所示）。OSGi框架是实现并提供OSGi功能的运行环境，OSGi标准服务定义了很多用于执行常见任务（如日志和首选项）的可重用API。
图1-3 OSGi服务平台规范分为两部分：OSGi框架和标准服务 OSGi框架和标准服务的规范由OSGi联盟（www.osgi.org）管理。OSGi联盟成立于1999年3月，是一个行业支持的非营利性组织。目前的OSGi框架规范是第4个版本，该版本是稳定的。基于该规范的技术已经应用于一系列大规模的行业应用，包括（但不限于）汽车、移动设备、桌面应用以及近来的企业应用服务器。
本书大部分内容都将讨论OSGi框架、OSGi框架的功能以及如何使用这些功能。因为OSGi框架提供了大量的标准服务，我们将在恰当的时候只讨论最相关和最有用的服务。对于未涉及的服务，你可以从OSGi规范中获得更多的信息。现在，我们将通过介绍OSGi框架的主要特点来继续介绍OSGi。 1.2.1 OSGi框架OSGi框架在创建基于OSGi的应用时起着核心作用，因为它是应用的执行环境。OSGi联盟在OSGi框架规范中定义了框架的正确行为，这样就可以基于一个定义清晰的API进行编程。该规范也使核心框架可以有多种实现方式，从而可让你自由选择。此外，还有一些知名的开源项目，比如Apache Felix（http://felix./）、Eclipse Equinox（www./equinox/），以及 Knopflerfish（www./）。这最终会给你带来好处，因为你不需要受限于特定的供应商，而只需根据规范中定义的行为编程即可。这种感觉令人欣慰，就好比你知道进入世界上任何地方的麦当劳都可以买到同样的饭。 OSGi技术开始被应用到各个地方。你或许不知道，使用IDE做Java开发时，很可能你就已经用过OSGi了。Equinox OSGi框架实现是Eclipse IDE的底层运行时环境。此外，如果你使用GlassFish v3应用服务器，其实你也在使用OSGi，因为Apache Felix OSGi框架实现是它的运行时环境。多种应用场景表明OSGi框架具有很高的价值和灵活性，而这个框架是依据OSGi规范中定义的三个概念层设计的（如图1-4所示）。
图1-4 OSGi分层架构 像常见的分层架构一样，OSGi的每一层都依赖于它的下层。因此，你可以只使用OSGi的下层而不用它的上层，但反之则不然。接下来的三章将会详细地讨论这三层，在这里我们将概述每一层。 模块层 模块层定义了OSGi模块的概念，并将之称为一个bundle。bundle是一个包含元数据（关于数据的数据）的JAR文件，由类文件和相关资源组成，如图1-5所示。bundle通常并不是打包到一个JAR文件中的整个应用程序；相反，它们是构成一个特定应用程序的多个逻辑模块。bundle比标准的JAR文件更强大，因为你可以明确地声明哪些包对外可见（即导出包）。从这个意义上说，bundle扩展了Java的普通访问修饰符（
图1-5 bundle中包括代码、资源和元数据 相比标准JAR文件，bundle的另一个重要优势是你可以明确声明依赖哪些外部包（即导入包）。明确声明bundle的导入包和导出包的主要好处是，OSGi框架可以自动地管理和验证它们的一致性；这个过程称为bundle**解析**，包括使导出包与导入包相匹配。bundle解析确保bundle版本和其他方面约束的一致性，我们将在第2章详细介绍。 生命周期层 生命周期层定义了在OSGi框架中是如何动态安装和管理来的。这好比你建造一座房子，模块层是基础和结构，而生命周期层是供电线路，它使得房子里所有的东西运转起来。 生命周期层的存在有两个目的。一方面，在应用程序的外部，生命周期层精确地定义了bundle生命周期的操作（安装、更新、启动、停止和卸载）。这些生命周期的操作使得你可以用一种定义明确的方式动态地提供、管理和改进你的应用程序。这意味着可以安全地在框架中安装和卸载bundle，而不需要重启应用进程。 另一方面，在应用程序的内部，生命周期层定义了bundle如何访问它们的执行环境。执行环境为bundle提供了一种与OSGi框架交互的方式和执行时的一些便利。生命周期层整体的方法非常强大，支持创建可从外部（和远程）管理的应用程序，或者完全自我管理的应用程序（或者两者的任意组合）。 服务层 最后，服务层支持和促成了一个灵活的应用编程模型。该模型包含了一些因面向服务的计算而流行起来的概念（尽管面向服务的计算是在这些概念已经成为OSGi框架的一部分后才开始流行起来的）。主要的概念涉及面向服务的发布、查找和绑定交互模式：服务提供者将服务发布到服务注册中心，然后服务客户端通过搜索服务注册中心，查找可供使用的服务（如图1-6所示）。当今，这种面向服务的架构（SOA）大部分都与Web 服务有关；但是OSGi服务则属于VM的一部分，因此有些人把它称为VM中的SOA。
图1-6 面向服务的交互模式。服务提供者将服务发布到注册中心，然后服务请求者可以从注册中心那里看到可供使用的服务 OSGi服务层是符合直觉的，因为它提倡一种基于接口的开发方式，该方式是一种公认的优秀编程实践。确切地说，它提倡接口与实现之间的分离。OSGi**服务**是Java接口，表示服务提供者和服务客户端之间的一种概念上的合约。服务层于是很轻量，因为服务提供者只是一些通过直接的方法调用来访问的Java对象。另外，服务层通过基于服务的动态性（服务可以在任何时刻出现或消失）来扩展生命周期层基于bundle的动态性。结果是产生了一种支持模块化和灵活性的编程模型，避免了过去僵化又脆弱的方式。 这听起来还算不错，那如何将这三层组合起来，如何使用它们，如何在它们之上创建应用程序呢？在接下来的两章将利用一些小的示例来说明如何将这些层组合起来。 1.2.2 将它们结合起来OSGi框架由多层组成，但如何在应用程序开发中使用这些层呢？为了说明得更清楚，我们先介绍以下创建OSGi应用程序的通用方法。
如果你已经采用了基于接口的方式，那么就会对OSGi的方式感到熟悉。主要的不同是如何找到你的接口实现（也就是服务）。通常，可以实例化实现，传递引用以初始化客户端。在OSGi中，服务会将它们自身发布到服务注册中心，然后你的客户端从服务注册中心寻找可使用的服务。那些bundle安装和启动之后，应用将正常地启动和执行，但却具有几个优点。应用底层的OSGi框架提供更严格的模块化和一致性检查，并且它的动态本质会展现多种可能性。 如果你不想或者不能使用基于接口的方法来开发，也不要因此而焦虑。OSGi框架的前两层仍然提供了很多的功能；事实上，OSGi框架的大部分功能都位于这两层中，所以请继续往下看。不如来看一些代码吧。 |
|
|
