OSGi诞生初期，其目的主要是能够灵活方便并远程管理互联的网络嵌入设备，OSGi联盟上对于OSGi service platform有这样一句解释：The OSGi service platform delivers an open, common architecture for service providers, developers, software vendors, gateway operators and equipment vendors to develop, deploy and manage services in a coordinated fashion.（OSGi service platform是一个开放并且提供通用接口标准的体系框架，基于这个体系框架，服务提供商，程序开发人员，软件提供商，服务网管运营商，设备提供商能够协调地联合起来开发，部署以及管理向用户提供的各种服务）。随着OSGi的发展，逐渐被引入到企业应用领域。

目前，OSGi规范的最新版本为R4.2，有关该规范的详细情况请阅读OSGi实战的第7节——深入OSGi。OSGi框架主要分为四部分：运行环境（executionenvironment）、模块（Modules）、生命周期管理（Life Cycle）、服务注册（Service Registry）。运行在OSGi环境中的是一个个的Bundle，也就是Modules的具体实现。

对于每个bundle，都有各自的ClassLoader，在这一点上和传统的Web应用有相似之处，在传统的Web应用开发完成之后，都会将其部署在Tomcat、Jboss等服务器上，这些Web应用都有着各自的ClassLoader环境，而两者之间的区别在于，传统的Web应用无法做到资源的共享，因为它们是完全独立、隔离的。OSGi框架为bundle之间的协作提供了底层支持，通过在bundle的MANIFEST.MF文件中Import-Package、Export-Package等项，bundle之间就能相互共享资源及服务，在以后的博文中，我将给出一个具体的示例。

由于OSGi具有良好的模块化结构，我个人认为这将为将来的软件开发方式带来很大的冲击，将更进一步推进模块化开发。目前Web应用的开发一般采用SSH框架，将整个应用大致分为Web（负责前台展现）、Service（负责业务逻辑处理）、DAO（负责数据持久化）、Domain（全局实体类）几个模块，而发布的时候，将被一起打成WAR包，部署至服务器上。如果采取bundle的形式，每个模块可以做为独立的bundle进行开发和部署，bundle之间的协作可以通过上述的方式进行，而这样带来的好处就是，一旦需要对某个模块进行更改，在保证依赖接口不变的前提下，就可以单独更改相应的bundle，再进行热部署即可，这样一来，好处是显而易见的，有效的分离了各个模块，减少了维护成本。

由于采用bundle的形式，也增强了模块的复用性。这也是得益于OSGi良好的模块化方式。

另外一个很重要的点就是OSGi具备热拔插特性，bundle的安装、启动、停止、卸载都可以在运行时指定，并且可以随时更改。这样一来，我们就可以做到无需重启整个应用，而只对需要更改的部分进行升级或打补丁即可。Bundl的状态图转换如下图所示：

图 1 OSGi bundle状态转换图

以上将OSGi的一些基本的，但也是很重要的东西大概介绍了一下，在以后的博文中逐步深入吧。以上都是关于OSGi原理性的东西，那么实现该规范的有哪些产品呢？最有名的应该要数Eclipse的Equinox框架了，在网上查资料见有人说过，Eclipse3.0的那一次升级把自身的构架做了一次非常大的调整，其主要原因就是采用了OSGi框架，更好的支持了Eclipse的插件体系。另外还有Felix、knopflerfish等。

不过话说回来，尽管OSGi有很多好处，但是现在主要还是应用在服务器端，如现在的应用服务器基本上都采用OSGi的框架，而真正的应用市场仍处理起步阶段，这和OSGi的生态环境还不成熟，可喜的是Spring推出了其Spring DM和SpringSource DM Server，前者能够很方便发布和引用服务，并且与Spring Framework平台相融合，将OSGi的bundle context与Spring applicationContext融合在一起，大大方便了OSGi的应用。后者是OSGi bundle的运行环境，是一个将Equinox和Tomcat融合在一起的服务器。在以后的博文中将详细介绍这些内容。