OSGi正在变得炙手可热，无论是OSGi与JSR 277之争，还是Struts2开始使用OSGi来完成插件的热部署，都使它越来越频繁地进入开发人员的视线。而近日，Bluedavy在去年发布了名为《OSGi 实战》的开源文档后，又发布了此系列的第二篇：《OSGi 进阶》。InfoQ中文站就这次发布邀请Bluedavy对文档的写作背景、OSGi的设计理念及当前的应用现状进行了访谈。
51CTO编辑推荐：OSGi入门与实践全攻略
在谈到编写第二篇开源文档《OSGi 进阶》的原因时，Bluedavy说道：
《OSGi 实战》主要是为了向大家介绍OSGi的好处，以及OSGi到底是什么，具体怎么去用，目的是为了能吸引更多的人关注OSGi、了解认识OSGi； 《OSGi 进阶》则是为了和大家分享基于OSGi设计实际的项目/产品、集成流行的Java框架去实现B/S、分布式系统、如何将传统的系统重构为基于OSGi的系 统等方面的一些经验，希望能让更多的人将OSGi应用到实际的项目/产品中去。
***篇OSGi实战Opendoc发布后，应该说还是起到了一定的效果的，无论是从javaeye上的OSGi圈子、我个人的blog以及我个人的MSN 上，都有不少的朋友开始讨论OSGi，尝试OSGi应用到实际的项目的可能性，从我MSN上一些好友我也了解到，国内已经有些公司开始在商业的产品中应用 OSGi了。
但是看到那么多的朋友对OSGi非常有兴趣，但由于不知道基于OSGi怎么去设计实际的项目/产品，又或是因为OSGi与流行Java框架不好集成的原 因，最终放弃了在实际的项目/产品中使用OSGi，这也是促成我编写第二篇Opendoc的原因之一，我希望能将大家对于OSGi的兴趣转化为真实的使 用；另一方面的原因则是整个业界发展的大趋势，短短的一年间，各大公司、开源项目都公开支持OSGi，使得OSGi进入企业应用领域的步伐比想像中顺利了 很多。
我们知道，模块化的开发方式早已在企业开发中得到了广泛应用，也一直是系统设计时的基本准则。而在OSGi中，每一个模块都 对应于自己的单个bundle，以声明的形式来表示对其他bundle中package的依赖，或是暴露某些接口以供其他bundle调用，从而实现了物 理上的模块隔离。这种方式与传统的模块开发相比其优点在哪里呢？Bluedavy回答说：
由于Java一直以来在物理隔离式的模块化开发/部署上都支持的不好，以至于基于Java构建的系统都没有做到真正的模块化。在模块化不是物理隔离方式实现的情况下，非常容易出现的现象是模块之间的界限在不知不觉中抹去了，***整个系统的依赖关系会逐步变的复杂。
一个比较典型的例子：假设在一个留言板系统中，留言列表和新增留言划分为了两个模块，这两个模块是没有强耦合的，但在非物理隔离的模块化实现时，我们很容 易出现的做法就是在留言列表的页面上直接编写一个新增留言的功能链接，其实这也就隐藏式的将这两个模块强耦合在一起了。到了物理隔离的模块化实现时，就会 开始考虑这个问题。
这点就像Bea microServices的人的一句话："Until modularity is not enforced,it is not there"。
在《OSGi实战》一书中，Bluedavy曾经描述过，像OSGi这样一个为动态扩充、修改系统功能提供了支持的模块系统可以带来什么样的好处：
基于OSGI的系统，可通过安装新的Bundle、更新或停止现有的Bundle来实现系统功能的插拔。
OSGi有一整套完整的机制去实现动态改变系统行为。
基于OSGi的系统不会受到运行在其中的Bundle的影响，不会因为Bundle的崩溃而导致整个系统的崩溃。
只有在请求发生时OSGi才去完全加载、启动相应的Bundle、Service，保证了系统的高效
规范的、可积累的模块
但是，无论是技术框架的选型，还是架构方案的选择，都不可能只看到其优势所在就简单的做出定论。每一种选择，都需要考虑到是否与既有方案可以顺利结合，应 用环境是否足够成熟，有充分的外界条件支持等等。那么对于OSGi来说又是什么样子的呢？Bluedavy给出了自己的答复：
从应用的架构层面选择的话，OSGi足够成熟，理由在于目前企业应用领域的关键问题，在OSGi中都逐步的有了对应的解决方案，这些解决方案中最有影响力 的当属Spring和OSGi的结合，Spring-OSGi使得OSGi的应用很容易的获得Spring提供的企业应用需求功能的实现的支持。
目前用OSGi来做企业应用，应该说技术上的瓶颈已经不多了，只是怎么去充分的发挥OSGi的优势，是有一定的挑战的。
记者又请Bluedavy就“企业应用的关键问题”和“OSGi中对应的解决方案”做出更详尽的解释，他说道：
OSGi EEG小组在总结OSGi进入企业应用领域需要解决的问题上列出了这么几点：
分布式系统的支持； 在分布式系统上，目前SCA是个好的解决方案，SCA的实现有Newton和Tuscany，另外就是通过集成Axis来通过webservice实现分布式的通讯。
OSGi服务的扩展，以支持从外部发布/调用OSGi服务，同时需要考虑多种语言的支持，而非仅仅是Java； 这点呢，一方面就得依靠和Java流行框架的集成，像Spring-OSGi就实现了在Spring的bean中调用OSGi服务，另一方面就得依靠 SCA了。
至于我们这些程序员在实际的项目/产品中可能会碰到的企业应用开发的问题可能会有下面几个：
怎么样把OSGi和Webwork+Spring+Hibernate这样的架构集成起来。类似Webwork+Spring+Hibernate这样的 架构无疑是目前Java B/S应用领域最为流行的技术组合拳，而且这样的三者的结合确实基本上解决了企业应用领域的关键需求，例如分布式的调用、事务机制等，如果OSGi能和这 样的技术组合拳集成，自然也就使得OSGi应用能够应对企业应用领域的需求了，在OSGi进阶的Opendoc中详细的介绍了OSGi与这个技术组合拳的 集成方法，并诞生了一个OSGi+Hibernate+Spring+Webwork的脚手架以及基于此脚手架的留言板系统。
传统的系统能不能重构为OSGi系统。无论对于项目还是产品而言，如果需要将新的项目/产品改变为基于OSGi的项目/产品，那么就有一个问题就是如何将 在以前项目/产品中积累的东西重构为可部署至OSGi系统，这相信也是大部分关注的问题，这个问题在OSGi进阶Opendoc中也以一个实际的例子来进 行了讲解。
既然使用了OSGi，如果发挥不出它的优势的话，就毫无意义了。OSGi系统的典型特征是：模块化、动态化和可扩展。要做到这三点从设计/实现层面都要进 行把握，在OSGi进阶Opendoc中也从实际项目/产品的角度去介绍了如何去设计、如何去实现，同时也总结了一些OSGi的设计模式和***实践，使得 大家在应用OSGi实现实际的项目/产品时充分的发挥OSGi的优势。
在自己的实际应用中，Bluedavy也碰到过一些比较棘手的问题，其中包括：某些Java框架依然需要开发人员自己来实现集成；目前OSGi HttpService尚不支持*.action这样的通配方式的servlet mapping，对于filter也不支持等等。但是最主要的问题还是落在了如何去构建模块化、动态化和可扩展的系统上面。正因为它的重要性，在 《OSGi 进阶》一书中，Bluedavy用了整整两章的篇幅来论述OSGi的设计模式和***实践。也许随着OSGi的广泛应用，开发人员对于系统设计的认识，也会 提高到一个新的层次。
在访谈的***，Bluedavy对OSGi目前的应用现状做了总结：
OSGi在过去的一年中得到了众多企业应用软件领域的商业公司的支持，例如IBM、BEA、Oracle、SAP、IONA，这些公司都在自己的商业产品 中开始采用OSGi；而开源领域的则有像Spring、Struts 2、Newton这些的加入。无疑OSGi将成为企业应用软件领域的重要内容，在此希望国内的同仁们也能更多的来关注OSGi，并将OSGi应用到实际的 项目/产品中去。
此外，记者还了解到，OGSi的官方中文站点（osgi.org.cn）正在筹备建设中，不日即将上线；同时，OSGi 中国User Group也获得了OSGi联盟授权，成为继日本User Group、韩国User Group、法国User Group以及西班牙User Group后的第五个官方认可的User Group，负责中国范围内OSGi的宣传和推广。可以预见，在不久的将来，OSGi在国内一定会迎来更加广阔的应用前景。
您正在阅读：访谈实录：开源文档《OSGi进阶》发布暨作者【编辑推荐】
