OSGi——Open Service Gateway Initiative 一个公共的服务平台。
OSGi的几个特点：
第一点，也是笔者认为最重要的一点，基于OSGi 的应用程序可动态更改运行状态和行为。笔者曾经参与过开发J2EE企业级项目，应用服务器用的是IBM 的Websphere，主要开发基于EJB 2.1的一些应用程序。整个开发经历给笔者的最深印象是等待，排除编写EJB规范中要求的一系列繁杂的接口，单单对应用程序进行部署和测试，反复启动服务器就浪费掉很多时间。而在OSGi 框架中，每一个Bundle实际上都是可热插拔的，因此，对一个特定的Bundle进行修改不会影响到容器中的所有应用，运行的大部分应用还是可以照常工作。当你将修改后的Bundle再部署上去的时候，容器从来没有重新启过，在外界看来，这种过程似乎从未发生过。这种可动态更改状态的特性在一些及时性很强的系统中尤其重要，比如说一个及时销售系统，当你的服务器因为要更新某个组件从而花上数分钟时间重新启动的话，必然导致客户的流失和利益的损失，但是采用OSGi架构的应用则完全可以将损失降到最低。众所周知，Spring
框架以其优秀的特性，占据了当前企业应用开发的半边天空，而刚刚发布的2.5版本，宣布所有jar 包均支持OSGi 特性，其维护的子项目Spring-OSGi 也是专门针对Spring 与OSGi 的集成。Spring早前版本有一点被人所诟病，就是其无法动态的改变其运行状态，被迫停止服务器，再修改配置文件，而与OSGi的结合，必然导致这种状态的终结。最后，笔者认为这种特性也保证了系统有足够的灵活性和可扩展性，对开发人员也大大节省了需要等待的时间。
第二点，它是一个稳定高效的系统。OSGi 是一个微核的系统，所谓微核是指其核心只有为数不多的几个jar 包。基于OSGi框架的系统可分可合，其结构的优势性导致具体的Bundle 不至于影响到全局，不会因为局部的错误导致全局系统的崩溃。每个Bundle也只有当服务被调用的时候才会启动，因此性能是较一般的框架高出许多。
第三点，可复用性强。OSGi框架本身可复用性极强，很容易构建真正面向接口的程序架构，每一个Bundle 都是一个独立可复用的单元。但是采用OSGi框架进行企业开发是需要气魄和勇气的，因为当前的软件企业，大多已经积累了许多年，都会遗留下来一些可复用的工具箱程序，而采用OSGi架构需要重新对这些遗留系统进行封装，更有可能的是需要把整个体系架构打散了，进行重新的架构和排列。这个开发成本不能说是不高，但笔者认为是值得的，因为从此以后企业可以利用OSGi 独特的特性，将重复的知识轻易的过滤掉。对于新的开发，可以从企业的Bundles库中精简出可复用的模块，量身定做新的Bundles，最大限度的利用了以前的积累，这样的过程更能促使企业竞争力的增强。
Bundles的六种状态：
| installed | 安装完成，本地资源成功加载 |
| resolved | 依赖关系满足，即该Bundle要么是准备好运行了，要么是已经被停止了 |
| starting | Bundle 正在被启动 |
| stopping | Bundle正在被停止 |
| active | Bundle 被激活，正在运行中 |
| uninstalled | Bundle 被卸载了 |