OSGi和JCP（Java Community Process）组织

　　为了能提供一个正规的环境收集相关方评估改进语言的提议和规范，Sun在1998年成立JCP组织。正式编号的Java规范请求（JSRs）要通过一个长期的过程，这个过程也许能产生最终的规范或者不能。在不到两个月的时间里，JSR 8迅速转变为OSGi相当反常，因为多数JSRs存在好几年。因为JSR 8，很多开发者已经考虑创建和管理Java代码的集合问题，这些代码要至少有一个类，还要小于一个应用，而且很多JSRs与OSGi的功能都有一定程度的重合。

　　关于OSGi，Sun官方的立场和JCP组织的关系在我看来相当令人费解。JCP发布过JSR 232，“移动操作管理”，基于OSGi“服务平台”规范，但在J2ME环境中的应用却受到限制。对Java SE（标准版本）我们有JSR 291，以JSR 232和OSGi为基础。显然真正的开发工作已经被OSGi联盟完成了，这个联盟中很多人和公司也与JSR组织有关系。有些公告提过在2010年某个时候Java 7的发布将直接包含对OSGi框架的支持，但我在前期的草案中还没看到过。JSR 294，标题是“在Java编程语言中改进模块化支持”， 作为Java 7包含的候选想必是正处于开发过程中。

　　不管怎样，随着对OSGi热情的与日俱增，已经被许多重要的产品采用。其中一个广泛流行的是使用Equinox OSGi来实现的Eclipse IDE（集成开发环境），。 Glassfish v3发布的预览版也包含了Felix OSGi框架，还有Apache的CXF也实现了分布式的OSGi。

　　Eclipse和Equinox OSGi实现

　　从2004年第三版开始，这个流行的开源Eclipse IDE使用OSGi来组织提供运行时功能的plug-ins。 当启动Eclipse时，按照OSGi的描述加载plug-ins。OSGi框架提供了这个plug-ins之间的高度独立性，对于Eclipse许多不同的版本，对于相同框架下不同语言的支持，对于组件的独立更新，使这一切都变得切实可行。这个规范的实现叫做Equinox，也可以单独下载。Equinox网站有关于服务器加入OSGi功能的信息，这样OSGi bundles就能处理HTTP请求。

　　Apache Felix OSGi实现

　　Felix是活跃的几个OSGi相关工程中的一个，被Apache软件基金组织所主持。除了独立运行的功能，Felix还打算加入其他管理plug-in架构的工程中。“Jetty”HTTP服务器可以用来提供HTTP服务功能。当前的Glassfish v3预览版就与作为OSGi框架的Felix结合在一起。

　　分布式OSGi和Apache CXF工程

　　OSGi有个为下一发布版本提案的扩展，叫做“分布式OSGi”。这个扩展的目的之一是提供web service风格的访问，从一个运行在某一台电脑上的bundle到作为一个独立服务器上的OSGi bundles来管理的服务。Apache CXF开源Web service框架，支持许多Web service标准APIs，已经将其作为子工程实现了分布式OSGi。

　　结论

　　有很多不同作为处理成群的Java类的组件致力于提高Java设施，，能被灵活地管理及动态地连接形成完整的应用。这些OSGi方法，最初是在嵌入式设备成功的基础上建立的，然后在Eclipse IDE上被大规模的成功应用， 看来已经在优秀程序员的共识中占据了主导。