OSGi R4.2 Early Draft 评述

OSGi R4.2 Early Draft 评述

随着OSGi近两年的迅猛发展，尤其是Java企业应用领域厂商对OSGi的认同，大家对于OSGi的新版规范的关注远远超过了之前的几个版本，近来OSGi终于是放出了传闻已久的R 4.2的Early Draft，其实从Early Draft来看，我觉得完全可以认为不仅仅是一个小版本的升级了，甚至可以认为是R5了，因为R 4.2增强的东西还是非常多的，其中就包括了大家期待已久的RFC119，不过没看到传说中的RFC66，有一丁点的失望，不过相信后面的Draft中应该会加上，:)，这样看来，R5更是值得期待了，让我们先来一起品尝一下4.2 Early Draft这道大餐。
OSGi R 4.2 Early Draft中包括了这些方面：
1、RFC 120 Security Enhancements
这个部分是由BEA的人主导的，从规范来看，Bea自己新版的Weblogic中肯定是已经实现了规范的。
个人对于OSGi Bundle这块的安全控制的增强不是很感兴趣，在这里就简单说下这次规范增强的目标，BEA在使用OSGi做了新版的Weblogic后，碰到一个需求，就是Weblogic应该控制自己的package是不应该被其他部署在weblogic中的应用操作的，那这在以前OSGi的规范中是支持不了的，因此提出了对原来安全规范的增强，规范中讲了具体做，不过因为自己不感兴趣，也就没仔细看了，感兴趣的同学可以去下载看看。
2、RFC 121 Bundle Tracker
这个部分是由IBM的BJ Hargrave主导的，从名字相信大家就能猜出作用了，在OSGI R4中有Service Tracker，可以跟踪OSGi Service的变化状况，但在实际的使用过程中，确实会出现有需求是要跟踪Bundle的生命周期的变化的，这个我记得之前有个同学也和我提及过这点，我记得当时我给了他一个借用OSGi Service来实现的方案，现在有了这个规范后大家以后就可以直接使用了。
Bundle Tracker的用法和Service Tracker基本完全一样，所以无需多讲。
3、RFC 125 Bundle License
:(，又是一个不感兴趣的增强，这个部分由OSGi著名人物：Peter Kriens主导，目标是为了能够在Bundle的header信息中增加License信息，以便在安装Bundle时就能够知道这个Bundle是什么License机制的，例如LGPL、Apache等。
做法就是在MANIFEST.MF中增加了一个Bundle-License的项。
4、RFC 126 Service Registry Hooks
这个部分由IBM的BJ Hargrave主导，这个部分推出的目的是为了能够监听指定Bundle中Service的变化情况，和以前的ServiceListener还是稍有差别，ServiceListener中只是监听Service，而没法知道是哪个Bundle中的Service。
以后要监听指定Bundle中的Service的变化，只要直接调用OSGi提供的PublishHook、FindHook、BindHook和EventHook就可以了。
5、RFC 128 Accessing Exit Values from Applications
这个部分由IBM的Thomas Watson主导，这个部分是为了增加新的OSGi Service：Application Admin Service而提出的，作用是用来得到应用的exit Value，就像我们在调用native command的时候，通过Process可以取到command的exit value一样。
6、RFC 129 Initial Provisioning Update
这个部分由Peter Kriens主导，看起来好像是为了实现加载不同类型的资源的，不感兴趣，所以没仔细看。
7、RFC 132 Command Line Interface and Launching
这个部分由Peter Kriens主导，这块成规范了，也不知道算好事还是坏事，个人觉得利弊都有吧，好处是以后不用管什么OSGi实现的Console都敲同样的命令了，不像现在Equinox和Felix console的命令就不同，坏处是如果有规范中不支持的命令的需求就不好玩了，难道做的像unix shell那么强大？
...从规范来看真的是，这个OSGi Console可真的强大无比了，支持piping、scripting、后台运行；支持多种方式连console，最重要的是，支持很容易扩展自己的命令；另外，在规范中还增加了OSGi Framework的启动、停止、重启脚本支持的规范，这倒是不错，以后可以写个groovy什么的来启动Framework，指定需要加载的bundle什么的。
 这个规范还是有点意思的，至少实现了这个规范的Console出来后还是很爽的，比现在的好用很多了，而且功能也强大多了。
8、RFC 134 Declarative Services Update
这个部分由BJ Hargrave主导，只是对之前DS的一点小升级：
允许自定义activate方法和deactive方法，其中activate方法的参数必须是ComponentContext或BundleContext，两个都存在也可以，而deactive方法的参数必须是int/Integer或ComponentContext或BundleContext，或三者的任意组合，其中int是指deactive的原因，这点确实比以前好，可以知道原因了。
 Service-Component属性值支持通配符了，这点真的太好了，我想用过Service-Component来指定加载component文件的同学都深有感触吧，以后就可以这么写了 Service-Component: OSGi-INF/*.xml
 Component配置中name属性变为可选项；
 XML Scheme namespaces改变为：http://www.osgi.org/xmlns/scr/v1.1.0。
-----------------------------------------华丽的分隔线-----------------------------------------
说完上面这八点后，必须划一条华丽的分隔线出来了，为什么呢，因为以下的三点是OSGi规范中里程碑式的动作，也算是EEG的动作终于要开始见成效了，以下三个规范是OSGi以往完全不存在的，也是为了企业应用而增加的，这样OSGi能够更好的被使用到企业应用中了。
1、RFC 98 Transactions in OSGi
这个部分主要由Peter Kriens和Pavlin Dobrev主导，所以这不是EEG的工作体现，这个部分是企业应用领域的同学们期待了很久的，不过最后的解决方案貌似会让大家有些失望，最后的解决方案是使用JTA来进行实现。
传说中的更强的版本需要等待EEG提交到OSGi R5中。
2、RFC 119 Distributed OSGi
这个部分主要由IONA的Eric Newcomer和David Bosschaert主导，这个部分我期待已久，IONA作为基于OSGi实现分布式应用的先行者，确实有资格来做这块的规范。
这个规范的目标是：
部署在JVM中的OSGi Bundle可以调用其他本地或远程JVM中的OSGi Service；
部署在JVM中的OSGi Bundle可以调用其他本地或远程中非OSGi容器中的Service；
其他程序可以调用JVM中的OSGi Service；
说实话，对于规范中提出的做法，我持保留意见，规范中的做法是增加一个Distribution Software，由这个Distribution Software来负责对外提供各种各样的访问OSGi Service的方法，例如RMI、SOAP等等，另外，增加一个Discovery service，负责到指定的地址上去寻找OSGi Service。
看过规范后，发现和自己想象的还是有一定的差距的，不过也是，分布式OSGi要做成规范我觉得还是比较困难的，毕竟分布式后各家公司关注的点就不同了，所以我还是认为Single JVM使用OSGi，然后分布式就各家根据各自的需求去实现，貌似这也是为什么SOA要落地做实现规范很难的原因，只能是架构层次的指导，其实我是比较希望OSGi规范中能增加一个OSGi本地方式提供给其他程序调用的方法，例如让我可以在webwork中调用（就像spring的ApplicationContext一样）、spring中调用，当然，自己做也可以做到，只是如果能被列入规范就更好了，不过仍然非常希望这个规范能帮助部分人，至少这样使用OSGi的人还是会再度增加。
3、RFC 124 A Component Model for OSGi
这个部分由SpringSource的CTO：Adrian Colyer主导，真没想到这个会被列入OSGi规范，因为觉得OSGi的Service-Oriented Component Model已经够强了，那么来看看这个规范到底做了些什么吧。
这个规范其实就是Spring-DM的规范，因为对Spring-DM还算熟悉，所以也只是粗略的看了下规范，不想在这里多讲，而且不可否认，Spring-DM给OSGi进入企业应用领域确实带来了很多的好处，只是我觉得这个规范的标题起的有点大了，好像是给OSGi新提出来的一样，:(。

享受完这道大餐后，应该说或多或少还是有些失望吧，毕竟最关注的两个规范：RFC 66，没出现；RFC 119，一般般，其他的规范嘛，更多的是一种锦上添花，:)，不过仍然是进步，所以还是值得期待的，想想Console、Bundle Tracker、DS Update，也满足了，:)

ps：在最新OSGi官方的blog上，Peter相当兴奋的写到了一件事情，是关于各家Application Servers厂商都公开发布新闻稿，说明其AS是运行在OSGi或兼容OSGi的，其中包括有：IBM、Oracle weblogic、Paremus、Prosyst、JBoss、SpringSource、Sun Glassfish，同时Oracle和SAP都宣布将采用OSGi作为其下一代AS的基础，虽然这些厂商用OSGi来做AS已经是很早以前就公开的事了，不过第一次这么多厂商一起来发布新闻稿来讲这件事情还真的挺壮观的，也说明了OSGi真的成为了AS界事实的工业标准了。

OSGi R 4.2 Draft下载地址：
http://www.osgi.org/download/osgi-4.2-early-draft.pdf
让Peter兴奋的那篇文章，文章里面还有各家厂商阐述采用OSGi的理由以及对OSGi的评价：
http://www.earthtimes.org/articles/show/world-leading-enterprise-application-server-providers,541827.shtml