OSGi V4.2 发布

OSGi 联盟于2009年9月16日发布了OSGi Service Platform V4.2标准。在OSGi 企业专家组(EEG, Enterprise Expert Group)的大力推动下，新的标准里增强了对企业级应用的支持。比如，在Service Compendium V4.2中引入的以下新标准：
Blueprint Service
即RFC 124。从某种程度上说，这个新的标准可以理解为是对Spring DM的标准化。它引入了Spring框架的IOC和DI机制，使得你可以通过配置文件实例化一个POJO类。同时，你也可以在配置文件中发布和引用一个Service，在这一点上和已有的Declarative Service十分相似。但是，Blueprint Service提供了更为灵活的动态加载机制，当Service所在的Bundle是一个Lazy Bundle时，这个Service可以注册一个Placeholder来等待其它应用的发现和引用。以外，使用Blueprint service可以使你避免在你的应用中引入一些容器相关的代码，这使你的应用可以独立于OSGi框架而运行，从而更加方便进行单元测试。
Remote Service
即RFC 119，原来叫作Distributed OSGi。这个新标准使得OSGi的Service可以在不同的VM间通信。也就是说，它提供了一种机制来发布可供远程用户使用的Service，并且不需要这个Service实现一些特定的接口。
Bundle Tracker
即RFC 121。与在4.1版中引入的Service Tracker类似，Bundle Tracker可以用来观察和跟踪Bundle的状态变化。在以前，我们可以通过在我们的代码中实现BundleListener接口来达到这个目的。然而，使用Bundle Tracker，我们可以降低这种程序上的耦合性。

另外，在新的Core Specification V4.2中，还增加了以下新特性：
Framework launching
即RFC 132。以前，从一个Java应用中起动OSGi引擎的方式往往是不同的，这通常由实现这些引擎的厂商决定，如Felix和Equinox。在新的V4.2标准中，定义了统一的方式，这样当我们想在不同引擎上测试我们的程序时，只需要替换相应引擎的JAR文件就可以了。
Bundle License
即RFC 125。定义了Bundle-Icon和Bundle-License头。
Service Hooks
即RFC 126。提供了一组用于观察和操纵Service层事件的API，比如当一个Service产生了一个事件，如被请求，你可以使用Hooks来阻止一些未认证的Bundle来接收到这个事件。
Conditional Permission Admin
即RFC 120。用来取代现有的Permission Admin Service，虽然它们都同时存在于新的V4.2中，但是OSGi联盟在Permission Admin Service章节的第一句话就作了说明。似乎因为V4.2是一个仅仅是增加小数点位数字的新标准，所以为了保持对V4.x版本的兼容，仍然保留了这一章。相信在以后的V5版本中会清除干净。

除了上述重要改变，新的标准中还有很多小的变化和提升，在此就不赘述，您可以从OSGi联盟的网站上(http://www.osgi.org/Release4/Download)下载到最新版的标准。同时，EEG仍然在致力于更多针对企业级应用的标准的制定，如JPA Integration，JNDI Integration，Transactions，Web Container等等，让我们拭目以待。