作为SpringSource的首席技术官,我经常会接触到许多正在构建企业级应用的公司,其中许多是在世界500强名单中耳熟能详的公司。我很快就发现,企业级应用领域凌乱且错综复杂。早在四五年前,采用Spring的用户都会设法向我们咨询解决方案,来帮助他们管理所构建应用的规模和复杂度。在这其中,规模庞大的团队和具有成百上千内部组件(Spring beans)的应用并不罕见。在越来越短的时间框架内开发出日益复杂的应用,企业压力与日俱增。在很多案例中,应用现今都依然保持着活跃状态,并且在不断演进。无论是来自内部规划还是外部用户需求,将软件作为“服务”交付,只能加速这种趋势。

在企业级Java领域,传统的部署单元是将一个企业级应用构建为一个Web应用归档(Web Application Archive,WAR)文件。我将讨论一些企业级开发团队面临的共同话题。

  • 作为打包并部署的一个大型独立单元,WAR文件会放慢开发进程,并使得组建大型开发团队变得更加困难,因为在所有东西可以部署之前,必须用一个独立的打包步骤将它们放在一起。

  • WAR文件过于庞大和笨重——一个普通的企业级应用可能会依赖几百个第三方资源,所有这些都要被打包到WAR文件中。这会对上传和部署时间带来不利影响。

  • 试图通过在同一容器中同时部署多个WAR文件来减少复杂度,会导致在JVM中出现堆使用(heap usage)的问题,因为每个WAR文件都各自拷贝了所有的依赖资源,而根本不管其中很多资源在理论上应被共享。

  • 一起部署WAR文件时,无法轻易共享公共服务。

  • WAR文件作为最小的变更单元,意味着在大型企业级应用中,变更不能轻易被隔离和包含。

  • 在设计中尝试引入自我监控(即未实施)的模块化约束通常会失败,尽管出发点是好的。

为了管控并处理开发现代企业级应用的大型团队规模及复杂需求,我们显然需要用一种更合理的方式来“分而治之”。我们需要将系统中定义良好的部分作为模块进行封装,隐藏其内部细节,并小心管理对外接口;还需要能够独立打包和部署部分模块,这样就不会迫使我们修改整个系统;另外,最好还能提供原则化的机制,可以将这些模块一起放入现运行系统中,并在不断演进的过程中将引进的变化拷贝进来。

早在2005年,面对这些需求,SpringSource(接下来是Interface21)就做出了一个简单的决定,转向OSGi——“面向Java的动态模块化系统”,将其作为模块化企业级应用的基础技术。实际上,那时OSGi服务平台已经成熟,并在一些工业环境中经过验证,同时凭借着在嵌入式系统领域内的技术遗产,它还保持着轻量级的规模。

OSGi模块层提供了将系统划分为独立模块的机制,即bundle,它们可以独立打包、部署,并有各自独立的生命周期。这为我们解决了一部分问题——有助于保持模块私有的实现类型,只暴露组成模块部分公共接口的类型。我们当然希望企业开发者继续使用Spring开发他们的应用,通过Spring Dynamic Module的开源工程我们创建了一个简单模型,从而使每个模块都有它自己的组件集合。这些组件中的一部分是模块私有的,但有一些应公开,以供其他模块中的组件使用。OSGi服务层提供了此问题的一个解决方案,促进了一个面向内存服务的设计。模块中的组件可以在OSGi服务注册中心发布,其他模块可以从中找到并绑定那些服务。OSGi也提供了必备的基本方法来追踪服务,因为这些服务可能会随着模块的安装、卸载、升级而不断变化。

OSGi发展行程中的下一站将是引入SpringSource dm服务器:一个企业级应用服务器,它不仅构建在OSGi之上,最关键的是它也支持部署OSGi bundle集合。Spring Dynamic Module可用于任何符合OSGi服务平台规范的实现,但对于dm服务器我们必须选择一个OSGi服务平台作为其构建的基础。我们选择在Equinox上构建,Equinox是OSGi服务平台在Eclipse上的实现,也是OSGi核心规范的参考实现。Equinox的开源特性与我们自己的开源理念非常吻合,让我们能够与Equinox开发者紧密合作,不断提交补丁和变更需求,这是非常宝贵的。Equinox的广泛使用(这只是Eclipse的一个基本插件的发展境遇,却颇具代表性)给了我们很大信心,它必会勇于进取,终将适用于企业级开发。

就我所知,大大小小的公司都对OSGi抱有与日俱增的浓厚兴趣。OSGi能为应用的模块化提供坚实的基础,反过来又有助于你构建更加高效的团队。能将复杂的应用分成各个独立部分,也就能较好地构建并划分团队职责,“组织跟随架构”的意义即表现于此。在其他场景中,团队可能是固定的,现在你可能会需要用一种架构来让他们最为有效地合作。同样,将系统划分为模块的原则性基础也会有助于此。将OSGi作为基础,打包和部署的单元将会变为一个独立的模块,这会消除处理过程中的瓶颈,同时使变更的影响减到最小。OSGi也非常适合产品线的建造,而当你为了能让第三方扩展你的软件而需要向其提供扩展或插件机制时,它也是非常适用的。

OSGi前景十分光明。规范的4.2版本已经发布,OSGi核心平台和企业专家组非常活跃。浏览一下OSGi联盟和专家组的成员组成,你就会明白企业供应商们对OSGi有多么重视。我相信阅读和学习本书所花费的时间一定会物超所值。我坚信OSGi是大势所趋。全面了解OSGi服务平台的优缺点,将会在创建灵活的模块化软件过程中,为你带来无限价值。

—Adrian Colyer

SpringSource首席技术官

2009年10月

目录