《OSGi与Equinox》序

 由  池建强 发布

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

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

作为打包并部署的一个大型独立单元,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月

致谢

没有众人的合作与帮助,我们就无法成就一本书。本书中,整个Equinox团队几乎全程给予支持,包括交谈、帮助编写代码、定义概念、bug修正、审查手稿或一般性的支持。

对于本工程,有些人贡献了大量时间和脑力,我们在这里对他们表示由衷的感谢。

Tom Watson:Tom 是Equinox背后的驱动力,他在OSGi规范社区非常活跃。他务实的方式和冷静的头脑为你带来了 Equinox,为我们编写本书提供了支持。

Chris Aniszyack:Chris带来了他对PDE的火样的热情,这一工具使得OSGi和Equinox变得易于编程。本书的编写带动了许多新的用例和需求。Chris热切地推动PDE,使其更加适合bundle开发环境,这让我们所有人的生活变得更加轻松。 Ian Bull:Ian应用了他的教育学技巧,关注了所有事情的细节,涉及p2、打包、构建,使构建和发布OSGi功能的整个过程更易管理。

Stoyan Boshev:Stoyan是Equinox声明式服务实现的得力助手。DS在书中和示例代码中占据了重要篇幅。Stoyan花费了大量时间实现DS,并和我们一起努力将它的功能展示给读者。

许多人提供了本书部分示例代码或做了深入的代码审阅,或对书中的内容做了技术指导。尤其是DJ Houghton和Scott Admiraal完整测试和审阅了指南部分,在此过程中给了我们很大帮助。Rafael Oliveira Nóbrega和Chris Aniszyzck对创建声明式服务工具做了巨大贡献,使得DS人皆可用。Andrew Niefer、Pascal Rapicault、Simon Kaegi和 Scott Lewis主要贡献于修正、示例和技术指导,范围从PDE 构建、服务器端OSGi p2到ECF。Patrick Dempsey贡献了Crust代码,并孜孜不倦地做了Mac相关的所有支持。BJ Hargrave是OSGi的坚定领导,他耐心地讨论了所有设计点、最佳实践和编码方式。

我们也有幸找到Eclipse社区和一些人审阅了本书,并提供了有价值的建议和帮助。他们是Joel Rosi-Schwartz、Benjamin Muskalla、Kevin Barnes、Grant Gayed和SWT团队、Ralf Sternberg、Matt Flaherty、早期草稿的读者Rough Cuts,以及所有涉及开发Toast示例代码的人们。

当然,没有哪本书可以离开出版团队。我们非常有幸,Greg Doench和Michelle Housley、Barbara Wood、 Elizabeth Ryan以及Addison Wesley整个团队持续担任了Eclipse 系列的编辑,这使得整个过程轻松快乐。

作者将单独致谢如下。

Jeff McAffer:Nancy、Sydney和Toby,你们是我生命中的至爱。妈妈、爸爸和Val,我深深地爱着你们!因为你们我才有了今天,对此我表示由衷的感谢。整个EclipseSource团队,谢谢你们给我发挥的空间,以及对Toast和此工程的满腔热情。
Paul VanderLei:我将感谢在Band XI International的搭档——John Cunningham、Brett Hackleman、Patrick Dempsey和James Branigan,他们慷慨地为我提供了时间来完成此工程。同样感谢我的妻子和孩子们,谢谢你们的耐心和爱。最后,我永远感谢我的父亲,他的鼓舞和孜孜不倦的指导已经影响了我的整个职业生涯。
Simon Archer:承担起本书的撰写意味着花费大量的时间、奉献和牺牲。我要感谢合作者Jeff和Paul对此工程花费的时间和所做的贡献。对于我的妻子Lisa以及我的孩子Thomas和Emma,我表示最真挚的感谢,因为你们做出了所有的牺牲。谢谢你们永恒的支持与爱,允许我在本书上投入时间。对此我永远感激不尽。

在本书之外,如果没有下面这些人就没有OSGi的今天。

BJ Hargrave:BJ是OSGi联盟的CTO,他一直致力于促进OSGi技术的发展。他是IBM OSGi实现SMF的领导,SMF作为Equinox的先驱已经捐献给Eclipse。他不断推动和指导OSGi脱离原有领域演变发展。
Peter Kriens:Peter是OSGi的传道者和OSGi社区的长期领导者。他充满激情地积极推动OSGi的传播发展。在OSGi规范中我们看到的连续性和清晰性,均是Peter编辑和设计技巧的直接体现。
Tom Watson:Tom是Eclipse中Equinox OSGi工程的共同领导者和关键决策者,是OSGi专家组有价值的成员。他负责整个框架实现和许多插件工具。他的实用主义和全面的思想塑造了Equinox的今天。
Richard Hall:Richard是Apache Felix工程的领导,他积极参与OSGi规范的过程。Felix是Oscar工程的演变,是第一个开源OSGi框架实现,也是Equinox团队决定选择OSGi的灵感所在。Felix工程提供的可选择的观点持续地丰富了规范和实现过程。

关于作者

Jeff McAffer是Eclipse RCP和Equinox OSGi工程的共同领导,是EclipseSource的CTO和共同创办人。他是Eclipse平台的架构师之一,是The Eclipse Rich Client Platform的作者之一。他共同领导了RT PMC,是Eclipse Project PMC、Tools Project PMC和Eclipse 架构委员会成员,曾担任Eclipse基金会的董事会成员。Jeff目前致力于Eclipse组件的所有方面,从开发和构建bundle,到部署、安装及最终的运行。他曾经担任IBM高级技术专家,是国际对象技术组织(Object Technology International,OTI)的一个团队主管,工作涉及Smalltalk、分布式/并行OO编程、专家系统和元数据架构。他在东京大学获得博士学位。 Paul VanderLei是Band XI International的合伙人。他有超过25年的软件工程经验,着重于面向对象设计和敏捷实践。他那解决复杂问题时创新但简单的工程方案令他闻名遐迩。在美国亚利桑那州大学获得计算机科学硕士学位后,他加入了OTI,并广泛参与了基于Smalltalk的系统。IBM收购OTI后,Paul作为IBM的Embedded Java Enablement团队初创成员,针对汽车和医药领域,开发了嵌入式Java应用和用户接口。他已经在商业应用中使用OSGi 10多年了。他与家人生活在密歇根州的大急流城(Grand Rapids)。 Simon Archer有超过16年的软件工程经验,着重于面向对象设计、敏捷实践和软件质量。在英国朴茨茅斯大学获得计算机科学学士学位后,他作为一名Smalltalk开发者,就职于Knowledge System公司,后来在OTI工作。2000年在OTI时,Simon开始在远程通信和RFID等领域使用并教授OSGi技术。现在他致力于IBM Rational软件的研发,使用OSGi为Jazz Foundation工程构建协同的开发工具。他与家人现居北卡莱罗纳州的Cary小镇。

wmz 2016-04-06 21:30

OSGi最好的开源开发平台JXADF,集前端页面、后端业务逻辑、数据库脚本于一体,而且还自动支持多数据库类型,相当NB,详细参见:http://osgia.com

顶(8) 踩(0) 回复
查看评论