随着最近GlassFish 3.0版“Prelude”,即Sun公司基于OSGi的Java EE 6服务器的发布,OSGi在企业中的应用已经覆盖了几乎所有后端服务器。最近,OSGi联盟的一份新闻稿列举了使用OSGi的厂商和技术:
- IBM的WebSphere
- Oracle的Weblogic
- Paramus的Infiniflow Service Fabric
- ProSyst的ModuleFusion
- Red Hat的JBoss
- SpringSource的SpringSource应用平台
- Sun Microsystem的GlassFish企业服务器
Peter Kriens指出,Jonas——第一个基于OSGi的J2EE服务器,因为不是OSGi成员,所以没有在名单中列出。他同时表示,SAP NetWeaver将来也会迈向OSGi。
正如InfoQ之前所报道的, 这些系统转向OSGi的主要原因是为了更好的模块化。这使得系统可以分解成更便于管理(和测试)的单元,同时提供更多可重用的组件库。目前,大公司( IBM、甲骨文)一直在应用内部使用OSGi,没有直接暴露给应用的客户,但其他厂商( SpringSource )事实上则允许OSGi容器本身(而不仅仅是应用)对外开放其扩展性。
使用Maven构建的项目也同样是组件化的,这导致一些人想知道OSGi在模块化方面有什么特别之处。在Maven的模块化和OSGi的运行时之间两个最关键的区别是:
- Maven的依赖关系基于特定文件,而OSGi可以通过运行时发现的任意文件导入Java包。
- Maven的构建时特性意味着它并不支持运行时动态行为。
类似SpringSource's DM Server的应用服务器利用OSGi的动态特性部署Spring beans到OSGi容器中,允许运行时停止和重启服务。Spring动态模块框架在底层透明的处理关联和运行时。
开源项目也在转向OSGi。在Apache FelixOSGi服务器的刺激下,其他Apache服务器在它们的产品中生成OSGi元数据或者完全迁移,就像Apache Tuscany的最近迁移。对于那些不生成元数据的的开源项目,存在很多OSGi束库(SpringSource企业束库、OBR、Eclipse Orbit、Felix束库等等),它们为带特定注释的开源Jars提供OSGi元数据。
随着OSGi的成长,基于Web的和后端系统都直接构建在OSGi上。Linked In对OSGi的使用已经在他们的工程博客上讨论过 ,你也可以看到科罗拉多2008软件峰会的相关演讲稿。甚至可以在亚马逊EC2和iPhone上运行OSGi服务。
不论是直接还是间接使用,OSGi在企业中的应用机会正在逐步提高。随着Spring框架成为应用开发的事实标准和Spring DM服务器的优势,构建动态、模块化的应用成为企业追逐的目标。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)