目前，关注OSGi的人变得越来越多，OSGi本身也早已从那个专注于嵌入式平台的“小”角色转变过来了，慢慢向企业级应用市场渗透。

从某种角度说，Eclipse可以说是OSGi在企业应用领域的试金石，2003年Eclipse3.0做了一次架构上的调整，继续延用插件的架构思想，但是从3.0版之后，是基于OSGi的实现。也就是这一次的调整，推动了Eclipse的迅猛发展。

这是在桌面应用的成功示例，而OSGi的目标远不止于此，以其优秀的类加载机制，可以说，只需对其进行扩展，那么就可以目标瞄准任何一个领域。谈到企业应用，无可避免的要涉及Web应用，相信大多数人都在从事该领域的开发。OSGi R4版已明确提出了对Web的支持方式——当然，这种方式还是很有限的，这一点将在后面的文章中详细说明。

鉴于此，很多开源框架都已经或正准备发布支持OSGi的版本，比如Spring DM、Struts1.8.1、CXF等等，基本上日常所用的开源框架都发布了基于OSGi版本。另外，有不少应用服务器也已经基于OSGi进行实现，比如WAS从6.1版就已经是基于OSGi的实现，而Spring也在2009年推出了Spring DM Server，可见OSGi的吸引力还是很大的。

那么这一切将会为以后的开发带来什么影响呢？本文试图从OSGi和构件化开发的角度认识一下该问题。

OSGi的类加载机制非常优秀，为每个运行于其中的bundle创建了独立的类加载器环境，而运行于同一个OSGi框架内部的bundle之间不像Web服务器中的Web应用那样绝缘，它们之间是可以进行包依赖的，当然OSGi也提供了服务注册等相关机制，确保bundle之间的相互协作能力。而且OSGi支持bundle动态部署。所以，系统无需停机重启，就可以实现其内部的动态更新。

构件化开发的概念已经提了很多年了，似乎一直缺乏一种有效的机制对其进行支持。构件化开发为系统开发带来了很多好处，整个系统的开发可以按照模块的方式进行划分，从而按模块进行开发；系统由各模块之间拼装而成，通过代码一级的依赖或者服务依赖的方式；对于某个模块进行更新，只要保持接口不变，则可以实现对外界无影响。

由于缺乏有效的底层支持，构件化开发方式一直没有推行起来。由其对于Web应用而言，想要实现构件化开发，似乎更是无从谈起。

OSGi的出现，让这一事情有所转机。传统的Web应用开发过程中，可能大多数人的做法就是将一个大的Web应用按功能模块进行划分，通过包切分来实现模块化开发，但是各模块之间并没有从物理上隔离，只是以一种组织方式上的约束，使其从表面看上去是分离的。对于这种方式，动态更新某个模块也就无从谈起了。

而如果将OSGi引入Web应用，每个模块都对应于一个bundle，那么模块与模块之间则从物理上进行了隔离，能有效的将模块内部实现对外隐藏。模块之间的交互，可以通过接口的导出与引用来实现，对于未经导出的部分，对于其他模块是不可见的。另外，由于OSGi支持bundle的热部署，那就意味着，在当前Web应用未停机的情况下，可以对某个或某些模块（对应OSGi中的bundle）进行动态更新，而不影响整个应用的正常运行。

这种从物理上的有效隔离的方式，为重用带来了新的方式。以前代码一级的重用，一般都通过Jar包的形式进行，而这种方式存在上述的一些缺点，即封装性不够。而通过基于OSGi的bundle的形式，则可以有效隐藏内部实现，从包一级进行隐藏（这一点个人觉得可以作为Java封装性的一种扩展，以前的封装只能做到类一级，不知道未来是否会被Java规范吸收）。

就这一点而言，OSGi对构件化开发进行了很好的支持，当然OSGi并不为此而生。

以上所说的构件依赖都是基于API一级的，那么当然，我们也可以将Web Service等类型服务封装至构件当中，再结合ESB，是不是对SOA的一种更好实现呢！ESB的关注点在于服务，这是一种细粒度的，它并不考虑服务的封装、重用等方面——这些方面都由设计人员去把握。而结合OSGi，当然还需要其他设施的支持，比如CXF已经发布了基于OSGi的实现，可以将服务封装至一个bundle，以bundle为单元，向外界提供服务，这种服务即变成了一种粗粒度的——构件的特点之一。

综上所述，我相信，OSGi的发展，将会为构件化的开发方式带来福音。

引出话题：OSGi和SCA在很多方面有着异曲同工这妙，并且SCA的实现框架——Tuscany也对OSGi做了支持。这两者有互补特性，有时间将对这两者做一个对比研究。