在模块化 Java 系列文章的第 4 篇里,我们将介绍声明式模块化,描述如何定义组件并将它们组织在一起,而无需依赖于 OSGi API 进行编程。
前一篇文章,《模块化Java: 动态模块化》描述了如何通过使用服务(service)给应用程序带来动态模块化特性。它们是通过输出的一个(或多个)可以在运行时被动态发现的接口而实现的。尽管这种方式使得client 和server 完全解耦,但是又带来一个如何(何时)启动服务的问题。
启动顺序
在彻头彻尾的动态系统里,服务不仅可以在系统运行的时候装卸,还可以以不同的顺序启动。有时,这是个大问题:无论 A和B的启动顺序如何,在系统达到就绪状态并准备好接收事件之前,如果没有事件(或线程)出现,那么哪个服务先启动都无大碍。
可是,有很多情况都不符合这一简单假设。经典的例子就是 logging: 通常,服务在启动和做其他操作的时候,就要连接并开始写日志了。如果日志服务此时还不可用,那会有什么后果?
假定服务在运行时能够动态装卸,client 应该能够应对服务不存在时的情况。在这种情况下,它也许能聪明地转移到另一种机制(如输出到标准输出),或者处于阻塞状态等待服务可用(对 logging 系统来说不是好的答案)。可是,让服务启动之前就可用是不切实际的。
启动级别
OSGi 提供了一种机制来控制 bundle 启动时的顺序,即使用启动级别(start levels)。这一概念是基于 UNIX 运行级别的概念:系统以级别 1 启动,然后单调递增,直到达到目标启动级别。每个 OSGi 容器都提供了不同的默认目标级别:Equinox 默认值是 6;而 Felix 是 1。
启动级别可被用来创建 bundle 间的启动顺序,让关键 bundle 服务(比如 logging)的启动级别比那些需要用它的 bundle 更低。可是因为可 用的启动级别值是有限的,而且安装程序倾向于选择单一数字作为启动级别,因此它并不能确保你仅通过启动顺序就能解决问题。
另一点值得注意的是,具有相同启动级别的 bundle 是各自独立启动的(可能并行),因此,如果你有一个与 log 服务具有相同启动级别的 bundle,谁也不能保证 log 服务能够在需要的时候已经就绪。换句话说,启动级别可以解决大部分问题,但不能解决所有问题。
声明式服务
解决这一问题的一个方案是 OSGi 的声明式服务(以下称为 DS——declarative services)。用这一方法,各个组件是由外部 bundle 将他们组织在一起并决定他们什么时候可用。声明式服务是通过在一个 XML 配置文件组织在一起的,文件中描述了需要(消费)或提供什么服务。
在上篇文章最后一个例子中,我们使用ServiceTracker 去获得服务,如果必要则需等待服务可用。如果我们把创建shorten 命令延迟到shortening 服务可用之后会很有用。
DS 定义了一个组件(component)概念,其是比 bundle 更细粒度的概念,但是比服务的概念粒度更大一些(因为一个组件可以消费 / 提供多个服务)。每个组件都有一个名字,对应一个 Java 类,并可以通过调用该类的方法使其激活或失效。与 OSGi Java API 不同,DS 允许用纯 Java POJO 来开发组件,根本不需要从程序上依赖 OSGi。其附带的好处是让 DS 更加易于测试和模拟(test/mock)。
为了说明这一方法,我们将继续使用前面的例子。我们需要两个组件:一个是 shortening 服务本身,另一个是调用它的 ShortenComand。
第一项任务是用 DS 配置并注册 shorten 服务。我们可以让 DS 在服务启动时注册它,而不是通过 Bundle-Activator 注册该服务。
那么 DS 怎么知道要激活并连接谁呢?我们需要给 Bundle 的 Manifest 头增加一个条目,其指示了一个(或多个)XML 组件定义文件。
Bundle-ManifestVersion: 2 ... Service-Component: OSGI-INF/shorten-tinyurl.xml [, ...]*
这个 OSGI-INF/shorten-tinyurl.xml 组件定义文件内容如下:
<?xml version="1.0" encoding="UTF-8"?> <scr:component name="shorten-tinyurl" xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"> <implementation class="<b>com.infoq.shorten.tinyurl.TinyURL</b>"/> <service> <provide interface="<b>com.infoq.shorten.IShorten</b>"/> </service> </scr:component>
当 DS 处理这一组件时,其效果与代码 context.registerService( com.infoq.shorten.IShorten.class.getName(), new com.infoq.shorten.tinyurl.TinyURL(), null ); 基本一样。Trim() 服务需要类似的声明,在下面的源代码中包含着这部分内容。
如果需要的话,一个单一组件可以基于不同接口提供多个服务。一个 bundle 也可以包含多个组件,使用相同或不同的类,每个都提供不同的服务。
消费服务
要消费该服务,我们需要修改 ShortenCommand,这样它就绑定到 IShorten 服务的一个实例上:
package com.infoq.shorten.command; import java.io.IOException; import com.infoq.shorten.IShorten; public class ShortenCommand { private IShorten shorten; protected String shorten(String url) throws IllegalArgumentException, IOException { return shorten.shorten(url); } public synchronized void <b>setShorten</b>(IShorten shorten) { this.shorten = shorten; } public synchronized void <b>unsetShorten</b>(IShorten shorten) { if(this.shorten == shorten) this.shorten = null; } } class EquinoxShortenCommand extends ShortenCommand {...} class FelixShortenCommand extends ShortenCommand {...}
注意,不像上一次,这次没有对 OSGi API 产生依赖;mock 一个实现来检验其是否工作正常也很轻松。那个 synchronized 修饰符确保了在服务 get/set 时不会产生竞争情况。
为了告诉 DS 需要把 IShorten 服务实例绑定到我们的 EquinoxShortenCommand 组件上,我们需要定义其所需的服务。当 DS 实例化你 的组件时(用默认构造器),它将通过调用定义在 bind 属性里的方法(setShorten())来设置 IShorten 服务。
<?xml version="1.0" encoding="UTF-8"?> <scr:component name="shorten-command-equinox" xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"> <implementation class="<b>com.infoq.shorten.command.EquinoxShortenCommand</b>"/> <reference interface="<b>com.infoq.shorten.IShorten</b>" bind="<b>setShorten</b>" unbind="<b>unsetShorten</b>" <i>policy="dynamic"<br></br> cardinality="1..1"</i> /> <i><service> <br></br> <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/> <br></br> </service></i> </scr:component>
无论 bundle 的启动顺序如何,一旦 IShorten 服务可用,该组件就将被实例化并连接到这个服务。有关策略(policy)、基数性(cardinality)和服务(service)的内容在下一节再做解释。
策略和基数性
策略(policy)可被设为 static 或 dynamic。static 策略表示一旦设置,服务不会变化。如果服务不可用了,组件也就失效了;如果一个新服务出现,那么就创建一个新的实例,并将该服务重新绑定。这显然比我们就地更新服务要费劲得多。
使用 dynamic 策略,当 IShorten 服务改变时,DS 将对新服务调用 setShorten(),随后对老服务调用 unsetShorten()。
DS 在 unset 之前调用 set 的原因是维持服务持续性。如果替换服务时先调用 unset,shorten 服务就有可能短暂为 null。这也就是为什么 unset 方法还带个参数,而不是把服务设置为 null 的原因。
服务的基数性(cardinality)默认为 1…1,其可取下列值之一:
- 0…1 可选的,最多 1 个
- 1…1 强制的,最多 1 个
- 0…n 可选的,多个
- 1…n 强制的,多个
如果不满足基数性(例如,设置为强制,但是没用 shortening 服务),那么组件是失效的。如果需要多个服务,那么每个服务都调用一次 setShorten()。相反,对每个要卸载的服务都要调用 unsetShorten()。
这里并没有展示组件在进入运行状态时对每个实例进行定制的能力。
在 DS 1.1 里,组件元素也有 activate 和 deactivate 属性,在组件激活(启动)和失效(停止)过程中相应方法被调用。
最后,这一组件还提供一个 CommandProvider 服务的实例。这是一个 Equinox 特定的服务,允许提供控制台命令,而这以前是在 bundle 的 Activator 中实现的。这种模式的好处是,只要依赖服务可用,CommandProvider 服务将自动被发布;除此之外,代码本身不需要依赖任何OSGi API。
还需要针对Felix 特定实现采用类似解决方案;因为到目前为止,OSGi command shell 还没有标准。 OSGi RFC 147 是一个正在进行中的规范,允许命令在不同控制台执行。我们的例子源代码中包含了 shorten-command-felix 组件的完整定义。
启动服务
上面所述方法让我们可以以任何顺序供给(及消费)shortening 服务。一旦 command 服务启动了,它将绑定到可用的最高优先级的 shortening 服务上;或者,如果没有指定优先级,则绑定到拥有最低服务级别的服务上。我们现在不去考虑次高优先级服务随后是否应该被启动,而是继 续使用目前已绑定到的服务。可是,如果服务卸载,我们就要重新绑定,以维持最高优先级 shortening 服务对 client 不会中断。
为运行这个例子,这两个平台都需要下载并安装一些额外的 bundle:
- Felix
- Config Admin (
org.apache.felix.configadmin-1.2.4.jar
) - SCR Declarative Services (
org.apache.felix.scr-1.2.0.jar
)
- Config Admin (
- Equinox :
截止目前,你应该已经熟悉安装和启动 bundles 的过程了;如果没有,请参考静态模块化那篇文章。我们需要安装上述 bundle,以及我们的 shortening 服务。下面是在 Equinox 环境下的操作过程,其中 bundle 放在 /tmp 目录下:
$ java -jar org.eclipse.osgi_* -console osgi> install file:///tmp/org.eclipse.osgi.services_3.2.0.v20090520-1800.jar Bundle id is 1 osgi> install file:///tmp/org.eclipse.equinox.util_1.0.100.v20090520-1800.jar Bundle id is 2 osgi> install file:///tmp/org.eclipse.equinox.ds_1.1.1.R35x_v20090806.jar Bundle id is 3 osgi> install file:///tmp/com.infoq.shorten-1.0.0.jar Bundle id is 4 osgi> install file:///tmp/com.infoq.shorten.command-1.1.0.jar Bundle id is 5 osgi> install file:///tmp/com.infoq.shorten.tinyurl-1.1.0.jar Bundle id is 6 osgi> install file:///tmp/com.infoq.shorten.trim-1.1.0.jar Bundle id is 7 osgi> start 1 2 3 4 5 osgi> shorten http://www.infoq.com ... osgi> start 6 7 osgi> shorten http://www.infoq.com http://tinyurl.com/yr2jrn osgi> stop 6 osgi> shorten http://www.infoq.com http://tr.im/HCRx osgi> stop 7 osgi> shorten http://www.infoq.com ...
当我们安装并启动我们的依赖后(包括 shorten 命令),shorten 命令仍不能在控制台显示结果。只有当我们启动针对 shorten 命令所注册的 shortening 服务时才行。
当地一个 shortening 服务停止时,实现自动转移至第二个 shortening 服务。第二个服务也停掉的话,shorten command 服务则自动清除注册。
注意
声明式服务让连接 OSGi 服务更加容易。可是还有几点需要注意。
- DS bundle 需要安装并启动,以把组件连接起来。这样,DS bundle 作为 OSGi 框架启动部分的一部分来安装,比如 Equinox 的 osgi.bundles 或 Felix 的 felix.auto.start 。
- DS 通常有其他依赖需要安装。以 Equinox 为例,要包括 equinox.util bundle。
- 声明式服务是 OSGi Compendium Specification 的 一部分,而不是核心规范的一部分,因此对于服务接口通常需要由一个独立的 bundle 提供。在 Equinox 环境下,是由 osgi.services 提 供,但在 Felix 环境下,接口由 SCR(Service Component Registry——服务组件注册)bundle 自身输出。
- 声明式服务可以用 properties 来配置。通常利用 OSGi Config Admin 服务;尽管这是可选的。因此 DS 的有些部分需要运行 Config Admin;实际上,Equinox 3.5 有一个 bug ,如果要用 Config Admin,它需要在 DS(Declarative Services) 之前启动。这往往要求使用 start-up 属性,以确保满足正确的依赖。
- OSGI-INF 目录(与 XML 文件一起)需要被包含进 bundle 中,否则 DS 看不到它。你还需要确保 Service-Component 头在 bundle 的 manifest 中存在。
- 还可能要用 Service-Component: OSGI-INF/*.xml 来包含所有组件而不是逐个罗列其名字。这也允许 fragment 给一个 bundle 增加新组件。
- bind 和 unbind 方法需要 synchronized 以避免潜在的竞争情况出现,尽管在 AtomicReference 之上使用 compareAndSet() 还可以被用作单个服务的 non-synchronized 占位符。
- DS 组件不需要 OSGi 接口,这样,它可以在其他控制反转模式(如 Spring)里被模拟来测试或使用。可是 Spring DM 和 OSGi Blueprint 服务都可用来组织服务,这就留作将来的话题吧。
- DS 1.0 没有定义默认的 XML 命名空间;DS 1.1 增加了 http://www.osgi.org/xmlns/scr/v1.1.0 命名空间。如果文件中没有出现命名空间,就认为其兼容 DS 1.0。
总结
本文中,我们讨论了如何将我们的实现与 OSGi API 解耦,并使用哪些组件的声明式描述。声明式服务提供了组织组件和注册服务的能力,帮助避免启动顺序依赖。另外,动态本质意味着当我们的依赖服务起停时,组件 / 服务也随之起停。
最后,无论使用 DS 还是手动管理服务,都使用的是相同的 OSGi 服务层以便通信。因此,一个 bundle 可以通过手动方法提供服务,另一个可以用声明式服务来消费它(反之亦然)。我们应能够混合并匹配 1.0.0 和 1.1.0 实现,并且它们应能透明地工作。
本文所讲例子的可安装 bundle 罗列如下(包含源代码):
- com.infoq.shorten-1.0.0.jar
- com.infoq.shorten.command-1.1.0.jar
- com.infoq.shorten.tinyurl-1.1.0.jar
- com.infoq.shorten.trim-1.1.0.jar
查看英文原文: Modular Java: Declarative Modularity 。
感谢崔康对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论