在今年5月份的网侠大会上，InfoQ中文站有幸与国内OSGi的先锋林昊（BlueDavy）在一起探讨了OSGi的相关话题，包括它的优势、复杂度以及Java下的实现等等。

在谈到采用OSGi作为开放服务框架的基础架构能带来好处时，林昊是这么阐述的：

    相信SOA现在已经是整个业界的焦点话题了。因为现在很多人都开始用OSGi，或者说学习OSGi，可能很多人都会想，OSGi 和SOA是不是有结合点？因为OSGi在R4以后，也就是说从他发行的第四个版本的规范来看，OSGi在R4中引入了面向服务的组建模型，而这个可以说几乎是整个SOA体系中，第一个明确提出的一个实现级的规范。但是由于OSGI是SingleVM的，也就是说他只是在单VM中的规范，这样的话可能跟 SOA有些不同，像SOA通常都是分布式领域的，这样来看的话OSGi可能是有点欠缺的。不过目前OSGi也在这方面不断的做出努力，包括在今年年底，OSGi将会推出RFC 119，那这个规范的话，其实就是OSGi用于分布式领域的规范。

    我们最近从OSGi联盟了解到的一些消息，OSGi和现在SCA的结合可能会变得更加紧密，相信在Java领域规范中可能会将采用OSGi列入规范。

    来看OSGi对SOA体系的支持的话，其实主要仍然是他的面向服务的组件模型。在这方面呢，OSGi在面向服务组件模型中明确定义了服务到底是个什么东西。那这个的话，其实在SOA体系中以前可能没有告诉你，你写一个服务，到底应该是什么样的。然后你的组件之间应该怎么样来交互等等，这一系列在OSGi中都定义的非常清楚，OSGi可能现在用于来做SOA的实现还不是很齐全，毕竟它缺少分布式领域里的一些规范，但是OSGi在整个服务模型上的思想是值得我们参考的

下面是访谈文字记录：
今天在InfoQ中文站有幸在阿里巴巴举办的第二届中国网络工程师侠客行大会上请到OSGi演讲嘉宾林昊，林昊你好，请向大家介绍一下你自己好吗？
大家好，我是林昊，网名 BlueDavy。现在在淘宝工作。之前先后写了一些OSGi的中文宣传材料，包括OSGi实战、OSGi进阶——这两篇OpenDoc，主要是结合我自己的经验来推广OSGi在中国的应用，我大概也了解到，经过这两篇OpenDoc，中国也有一些公司开始考虑采用OSGi了，这是一件很好的事情。目前，我们主要是在筹办OSGi的中文官方站，这个是得到了OSGi官方认可的，全球第六个国家级别的User Group性质的站点。目前这个站我们还在进行之中，可能近期会全面对外公布，大概是这些。
好。 OSGI是一门存在了很长时间的一门技术。那么但是在近年来，在Java社区这里边，关于它的探讨、实现，然后以及应用已经越来越火热了，尤其在最近宣布的Spring Source Application Server里边更是以OSGI作为他的核心技术。作为国内在OSGI方面的先驱者，你还能不能跟不熟悉OSGI的这些读者介绍一下OSGI到底是什么吗？
是这样的，近来我们可以看到，几乎所有现在的应用服务器都已经宣称基于OSGi或者run on OSGI或者兼容OSGI， 像Spring的话，之前大概花了一两年的时间做Spring DM，但Spring之前一直都是基于他自己的IOC容器的，如果全面迁移到Spring DM的话可能还需要一段时间，但最近推出的Spring Source Application Platform是一个全新的东西，他基本上就已经开始全面采用Spring DM了，这个和以前的Spring的兼容方式是有点不同的。OSGI简单来讲，就像OSGI官方站上的一句话来描述话，OSGI是一个为Java提供的动态模块化的系统，这是一个他非常好的简称。

然而经过近两年的发展，OSGI已经逐渐在改变他的推广方式了，也就是说从以前的for Java开始不大提这个词，开始提他是全面的、统一的中间件。采用这个名词的话，其实可以看出OSGI的目的是想脱离语言的限制，否则以前的话都是for Java，for Java。从OSGi目前简单的介绍词中，我们可以看到OSGI最重要的就在两个方面，一个是动态化，一个是模块化。在Java体系中模块化一直以来都是比较弱的一点，而OSGI在这方面突出的表现，让它吸引到了现在几乎所有的大公司的关注，在模块化，以及动态化方面呢， OSGI都是从规范角度来做，已经提供了支持，在没有OSGi的情况下通常我们都是自己想各种各样的办法来实现，但毕竟不是官方级的规范，现在OSGI的发展已经影响到了整个业界，包括Sun，经过这么久的斗争还是开始慢慢接受了OSGI，这也是一个很明显的体现。
那采用OSGI作为开放服务框架的基础架构能带来哪些好处呢？
相信SOA现在已经是整个业界的焦点话题了。因为现在很多人都开始用OSGI，或者说学习OSGI，可能很多人都会想，OSGI和SOA是不是有结合点？因为OSGI在R4以后，也就是说从他发行的第四个版本的规范来看，OSGI在R4中引入了面向服务的组建模型，而这个可以说几乎是整个SOA体系中，第一个明确提出的一个实现级的规范。但是由于OSGI是SingleVM的，也就是说他只是在单VM中的规范，这样的话可能跟SOA有些不同，像SOA通常都是分布式领域的，这样来看的话OSGi 可能是有点欠缺的。不过目前OSGI也在这方面不断的做出努力，包括在今年年底，OSGI将会推出RFC 119，那这个规范的话，其实就是OSGI用于分布式领域的规范。

我们最近从OSGI联盟了解到的一些消息，OSGI和现在SCA的结合可能会变得更加紧密，相信在Java领域规范中可能会将采用OSGI列入规范。

来看OSGI对SOA体系的支持的话，其实主要仍然是他的面向服务的组件模型。在这方面呢，OSGI在面向服务组件模型中明确定义了服务到底是个什么东西。那这个的话，其实在SOA体系中以前可能没有告诉你，你写一个服务，到底应该是什么样的。然后你的组件之间应该怎么样来交互等等，这一系列在OSGI中都定义的非常清楚，OSGI可能现在用于来做SOA的实现还不是很齐全，毕竟它缺少分布式领域里的一些规范，但是OSGI在整个服务模型上的思想是值得我们参考的。

Apache Tomcat开发团队和JSR 277的邮件组中都有人质疑过，OSGI是否违背了KISS原则，那么Peter Kriens在博客中对这个观点也进行反驳，请问你对OSGI的重量级以及它的复杂度持有什么观点呢？
这一点其实是这样的，对于了解OSGi规范的人而言，都可以看得出OSGI一直以来都是轻量级的，而且他也是比较简单的，并不是很复杂。因为这个从OSGI的起源可以看得出。OSGI最早的时候是为Smart Home来提供服务的，也就是说他是为家居网关这一块来制定规范的。那在这一块的规范中，他是不可能做得很复杂的，所以OSGI他本身的规范在复杂度这方面应该不会是很大问题的。但OSGI R4的实现Eclipse Equinox，看起来是比较重量级的，如果我们去下这个包的话，大概会在几兆以上，相对来讲，这个看起来会让人觉得OSGI的实现是比较复杂和比较重量级的。如果你再去看更聪明的Spring DM，那就更大了。这些东西可能会让别人产生一定的错觉，这个问题Peter在官方的BLOG上也曾经提到的，他对于Spring目前在OSGI上面的一些做法并不是相当认同。他认为Spring目前已经把OSGI引入一个复杂化的路线，所以这一点Peter也是持否认的观点的，我们其实可以看得出，OSGI的实现像Felix的话，大概在100K左右，从这个数量级我们可以看得出，他本身是个相当小的东西。

你刚才提到的 Felix 还有Spring DM，目前除了这些框架以外，在Java下边有哪些OSGI规范的这些实现呢？他们各自都有哪些特色？

目前现在Java中真正实现OSGI规范的应该是有三个，最出名的当然是Eclipse Equinox，Spring DM的话，他应该是采用Equinox来做扩展实现的，Felix基本上是自己完全重新实现的一套。其实还有一个可能不是很出名的，是 Newton ，但是Newton的话，是一个SCA的实现，所以我们可能不能完全以OSGI的规范的实现来评判它，不过他是基于OSGI来实现SCA的，所以要算的话他也可以算一个。在这三者当中的话，Equinox名声比较大一点。Equinox毕竟是OSGI第一个官方认可的实现，也是第一个通过了官方验证的实现，他的使用也已经得到了验证。因为Equinox毕竟是 Eclipse的核心，而且现在Equinox已经提升到了 Eclipse 的Top Level的Project，而这一点可以看得出 Eclipse 其实对这个的重视已经越来越高了，之后他可能也会改名成 Eclipse Core Runtime，成为Eclipse的运行核心。

Equinox整体来讲他的实现是比较完整的，而且他投入的力量也比较大，这基本上是非常值得期待的，可以一直跟随着他。Equinox在OSGI的发展上其实是起到了很大的作用的，包括我们可以看到Equinox之前他起动了一个 Server side的沙箱，那这个的话，对OSGI的发展起到了很明显的推动作用，因为我们目前可以看到现在最新的RFC应该是 66，在66里面其实已经开始提到吸取了现在Equinox在Server side上的一些做法，我想对于了解OSGI的同学而言，应该知道OSGI的Http Services是只支持 servlet以前的老版本。新版本像2.3以上的servlet规范中的像filter，这些都是没法支持的，在RFC 66中则会开始逐步支持这些东西了， Equinox另外一个最大的贡献可能是在扩展方面，因为他引用了Eclipse做的非常成功的扩展点，扩展点现在几乎已经成为了OSGI的非事实性的规范，也就是其实目前OSGI所有的实现中都会提供，因为扩展点对模块的可扩展性方面提供了很大的帮助。以前的话，在OSGI官方规范中是没有这一点的。然后我们可以来看Felix，Felix的话，其实他是Apache后期开始做的，也就是说它比Equinox晚挺多的。Felix的话，我们可以看他基本上是一个非常轻量级的OSGI实现，目前很多采用OSGI的人都开始逐步才用Felix，可能是因为大家觉得Equinox太重量级了。

Felix 除了轻量级以外，还有一个比较突出的特色，是他把之前Peter一直想做得OBR这一块，就是OSGI的bundle仓库这一块做得非常非常好了，而这一块对于OSGI其实是非常重要的，Bundle仓库这一块大概会在OSGI的R5列入规范，所以Felix在这一块的作用应该是很明显的，我相信OSGI R5的规范会参考他来做。然后 Newton的话，Newton本身是基于OSGI实现的，它带来的最大作用也许是他让所有人认可了OSGI是能够应用于分布式服务领域的，这对于OSGI进军分布式领域是有一定的好处的，也许RFC 119会在Newton的基础上做一定的参考来做规范了。
对于目前Java 7中将支持OSGI的消息有什么看法？JSR 277跟OSGI之间的争论呢？
我想OSGI和JSR 277的争论在整个OSGI业界绝对是一场非常非常漫长的战争，几乎了解的人可能都知道，JSR 277很早就成立了。一直以来，其实最早的时候，277的规范组的成员是没有列入Peter的，而其实大部分人都知道，Peter在模块化以及动态化方面的经验几乎在全世界都是顶尖级的。之前Peter自己也申请过要加入JSR 277，但被拒绝了。在今年Javaone第二天的大会上Sun官方明确的宣布了在Java 7中将会支持OSGI。这一点虽然没有比他说采用OSGI让人激动，因为他毕竟只是兼容而已。但是从这一点可以看到，Sun已经做了比较大的让步了，因为之前其实他从来没有考虑过，他一定是要自己完全做一套的，而我们从Sun在JavaOne上的第二天的一些讲演中可以看出，Sun自己目前也在非常强调模块化这一方面的工作，包括他自己在JavaEE 6以及Java 7上都是明确的说，最重要的一点的，就是说在他的规范中最需要重视的就是模块化的规范这一点，这也说明Sun对JSR 277是非常非常重视的。不过也正因为他对这一块非常非常重视，所以可能很难接纳一个已有的模块化的标准，否则Sun可能在这一块会难以立足。不过我们可以看得出，在JavaOne宣布了以后。Peter在自己的官方博客上透露了一个消息，JSR 277 Leader已经邀请Peter加入JSR 277专家组，那这个的话，可能也证明了JSR 277专家组是认为需要Peter这样的顶尖专家的，不过Peter自己仍然在考虑之中。因为Sun毕竟已经制订了一系列的东西，这也意味着他可能不会完全采用OSGI，这个对Peter来说可能是有点疑问的。
记得上一次在InfoQ中文站的文字访谈中，您说过当时OSGI应用最重要的问题还是落在如何去构建模块化、动态化和可扩展的系统上面。那么近年来OSGI在这方面上取得了什么进展吗？
其实OSGI他本身的规范程度上应该来讲，他在模块化以及动态化还有可扩展性方面都已经有了一定的规范了。包括像模块化的话，是他一直以来的特色，然后动态化方面应该也是支持的一直都比较好，只是在可扩展性方面的话，因为OSGI以前只是借助DS，就是它的R4中的 Declarative Services 来做这方面的支持，那相对来讲比Equinox的扩展点的话，应该是有一定的弱势的。

不过目前的话OSGI应该也会逐步考虑，就是说在他的R5中可能会考虑Equinox扩展点怎么样嵌进去，来提升他在扩展性这一方面的支持。虽然OSGI从规范中支持了这些（模块化、动态化和可扩展），包括框架的实现上也是可以支持模块化这些特性的，但是我们最关键的仍然还是怎么样去使用OSGI了。因为如果你使用OSGI的时候，不遵循他的这些原则的话，其实最后设计出来的系统仍然是你以前的非模块化，非动态化的系统。
作为OSGI在国内中文社区里边的一个活跃分子，也算是一个领军人物了。那么你觉得目前国内社区这块在OSGI的现状是怎么样子的，今后又是一个怎么样发展方向呢？

之前呢，其实在国内的社区中应该是没有，就是没有OSGI的集中讨论场所的，包括我们知道可能在JavaEye上面会有OSGI的圈子，但是并不是专栏性质的，或者说不是这种社区，极大的一个集中式的社区性质的。然后OSGI之前的社区更多是在Equinox上面，之前我们在Equinox的maillist上面可能会有一些讨论。然后在中国方面的话，其实一直以来都没有做这方面的工作，不过OSGI中文官方站筹划已经很久了，但是因为要官方认可的话，需要跟官方做一些交互，还有一些协议方面的，因为要得到他们的授权，这个商标必须是拿到允许才能使用的。所以我们跟官方交涉了一段时间，最近应该也是在今年年初的时候，才拿到了OSGI的授权。在拿到授权之后呢，我们现在已经在开始建设我们的OSGI中文官方站了。在OSGI中文社区里面我们已经做了一定的推广，就是已经告诉了大家这个站是怎么样访问，然后大家可以怎么样加入这里来为OSGi做贡献，就是说为整个OSGI的推广做贡献。因为其实在目前，我们OSGI官方站大概的做法主要是翻译官方站的一些东西，包括官方站的一些新闻，这样大家可以了解到整个OSGI业界的最新的发展动向。然后另外的话，我们会翻译一些OSGI官方上的一些精品的 BLOG。那这些BLOG其实会给大家有很高的指导意义。

另外一方面我们可能会加强包括OSGI中国方面自己的一些原创性质的文章。因为其实以前是很少有原创性质的一些文章的。那这些方面的话，可能在近两年应该会好一些。因为随着OSGI在国内慢慢开始得到应用，大家都会开始在这一块有一定的经验了。在有了经验之后，我们希望有更多人能写出关于OSGI方面深入文章。这对于推广，包括你自己对OSGI的一些想法，我们也会把一些写得比较好的OSGI的原创文章翻译成英文，然后推荐给OSGI官方联盟。这样的话，对于整个OSGI发展也会有一定的好处。

在中文官方站上，我们可能也会成立一个开源的社区，这里面可能会包括论坛等，另外一方面就是提供一些基于OSGI的开源项目，这些应该是会对推广OSGI起到一定的作用。

 个人简介
林昊，三年前接触OSGi，目睹了OSGi从最初的不够受关注到现在几乎成为了各大应用平台厂商的必选，同时也得到了Sun的官方认可，而自己也随着对于OSGi的应用经验的增长，编写了《OSGi实战》、《OSGi进阶》两篇 Opendoc，这两篇是目前OSGi领域中仅有的中文文档资料，国内不少公司、IT从业人士因为这两篇文档进入了OSGi领域，在去年通过和OSGi官方联盟交涉后拿到了官方联盟的授权，建立了OSGi官方认可的全球第6个User Group

来自：http://www.infoq.com/cn/interviews/linhao-osgi


Author: orangelizq
email: orangelizq@163.com