OSGi是一个基于Java的服务平台规范

OSGi是一个基于Java的服务平台规范，它是为那些需要长时间运行，动态更新并且对运行环境的影响尽可能小的系统制定的。迄今为止，很多工具厂商（Eclipse是第一个）和应用服务器厂商（IBM、BEA、Oracle）都已经采用了OSGi来创建“微核与插件”的架构，这样一来，应用就可以被更好的模块化，并且可以在运行时动态装配。但是对于开发者而言，OSGi更重要的特点则是：在开发应用时，它将成为更加优秀的组件模型。JSR291（OSGi核心规范R4.1）在经过多方争论后得出：

...为既有的JavaSE平台定义了动态的组件框架，其中包括了组件的生命周期。这个动态的组件模型将会支持由组件组装应用和在组件之间隐藏实现细节，同时还会提供组件的生命周期管理功能。

当我们在Java的世界中使用组件开发时，OSGi会成为我们的备选工具之一吗？有一家公司已经决定用OSGi来构建下个版本的产品架构。BPS是一家销售风险管理软件的ISV，该公司的产品可以帮助公司服从内部审计并遵守业务流程（例如，Sarbanes-Oxley404法案）。在那些规章制度以及对IT环境的要求都十分严苛的大型金融机构中，他们的产品已经成了主流。BPS的首席架构师GavinTerrill在访问中谈到：

我们目前一直力求解决的问题是：怎样才能在一个VM里面，同时运行一个服务的多个版本。比如说，现在有两个应用程序，A和B，它们都与在我们的程序C集成。在C被部署以后，又增加了不少特性，用来支持A的下一个版本。那么我们该如何在不重启服务器，不更改任何B所依赖的功能的前提下，用新的代码来更新已部署的应用呢？而OSGi可以动态地提供组件（bundle），并为组件标记版本号，这样一来我们的问题就迎刃而解了。

我们的另一个目标是在代码库中引入面向服务（serviceoriented）的方式。注意这里的S和O都是小写的——我们希望系统可以做到松耦合，将概念和本地化测试分离，但是我们并不想用跨进程（out-of-process）的方式来实现，因为这样只会增加更多的复杂性，就像Jini和DPWS（先前的UPnP）一样。我们在产品中已经融入了这些想法，充分利用了Java中的接口，并利用Spring框架的依赖注入对这些接口做了相应实现。而OSGi则在这个基础上又有所提升，它以轻量级的方式把服务变得更加模块化。

就OSGi为什么比传统的EAR/WAR文件更好的话题，Gavin说：

虽然现在已有的机制本身并没有什么问题，但我认为对于实际应用而言，EAR/WAR的粒度显得太大了。如果我只需要改变一个jar文件，为什么我需要重启整个应用呢？

关于如何部署Java应用的话题，已经在Java社区中引发了大量的讨论，从jar文件的引入直到JSR277/294——“Java模块系统（JavaModuleSystem）”（JSR277）是JavaSE7的先行者，有趣的是，它第一眼看上去很像是从.Net的Assembly思想中成型的——然而，OSGi在Eclipse及其他应用中取得的成功给我们树立了信心。如果一样东西已经经过了重重考验，并且解决了我们曾碰到过的那些乱七八糟的部署问题，那还有什么好争的呢？

OSGi的设计主旨与我们的需求很贴近：一个轻量级的进程内（in-process）服务容器框架，并提供了完整生命周期管理。

因为BPS的应用是架构在Spring基础上的，所以他们打算在新的架构中使用Spring-OSGi。最近，SpringOSGi刚刚发布了第一个Milestone。

使用OSGi来重新架构对BPS来说是一次巨大的冒险。Gavin回忆说：“记得2004年的时候，BPS决定冒险对产品进行重构，当时看上去采用Spring框架比起使用传统的EJB来，风险要大得多。但最终从开发人员和用户的反馈来看，这次冒险为我们赢得了大量的时间。这次采用OSGi对我们来说也是如此，因为它毕竟还处于发展初期，但我相信，在多年以后当我们架构ITfriendly，面向服务的企业级Java应用时，OSGi就会成为事实上的标准了。”

OSGi可以作为一种架构资产，来推动各个组织应用面向组件的软件开发。06年11月时，PieroCampanelli分析报告中列出了OSGi的如下几个优点：

◆真正的组件开发——虽然组件开发概念很简单，但是真正开发组件化软件的时候，却是困难重重的。OSGi的结构可以解决这些问题，例如依赖跟踪，版本跟踪和服务绑定。
◆跨团队的安全开发——OSGi的微核结构保证了组件和扩展是独立且可控的。
◆公司项目的标准化管理——如果所有的项目都分解成OSGi组件，那么它们就可以很容易重用。Eclipserepository就是这样子的。
◆版本跟踪——人们常常会有这样的疑问，“我可以集成这个库吗？”，亦或“它会不会与这个版本的另外一个库冲突？”，OSGi所提供的标记版本的功能，就解决了这些疑惑。

◆辅助架构设计——通过OSGi，架构师无需进行完整的构建，就可以判断构建所依赖的类库是否依然可用。