《OSGI实战》:序言与前言

 由  《OSGI实战》 发布

序言

初闻Richard S. Hall是在2003年炎热的夏天。在咖啡桌上,德国电信(Deutsche Telekom)的一位同事告诉我,当地大学的一位老师对OSGi非常了解。首批开源的OSGi框架中,Oscar的作者便是他。在2003年,全方位地采用OSGi实属罕见,所以当时我很好奇。与此同时,Eclipse项目正着手研究采用一套新的模块化系统,我受邀以OSGi专家的身份参与了该项目。对于该项目来说,我觉得Richard能提供很大帮助,所以邀请他加入 Equinox委员会。谁料这个颇具意外的邀请拉开了此后一个漫长的邮件交往历程的序幕,这种邮件往来一直延续至今,我希望永远都不要结束。每每遇到规范不够清晰,甚至更糟——当我们试图违背模块化原则时,Richard总会变得怒不可遏。如果我们不得不接受不完善的功能,有时我会觉得他身受煎熬。 作为一名受邀的OSGi研究人员,他已然成为规范背后的核心人物,为我们的设计保驾护航,避免框架膨胀,并且一直遵照我们的原则。

Manning出版社向OSGi的核心人员发出了一封邀请函,提议编写本书,当时Richard也收到了该邮件。这封邮件引发了后续关于集体撰写书籍的一系列热烈讨论。之前写书的想法已经反复讨论过。对此我们也与Manning出版社进行了洽谈,但最后我选择退出,并鼓励其他同事继续参与下去。我为何会选择退出?作为OSGi规范的编写者,我很清楚和其他固执己见的人共同撰写一本书需要多大的工作量。我不希望每天晚上以及周末都加班工作,而且没有相应的报酬,虽然我非常喜欢和欣赏这些有才华的同事。很遗憾,我的决定影响了大家,这一工作被搁置了。

直到有一天Richard告诉我他已经重新拾写书计划,打算继续完成之前的工作,目前已经组建了一支更好的团队,有Karl Pauls、Stuart McCulloch和 David Savage。每一位作者都为开源和OSGi 规范做出过巨大贡献。Karl在使用Felix方面经验丰富,通过将Felix的安全划分为一个单独的bundle,以此来证明模块化,Karl证明了Felix的框架结构也是模块化的。Stuart在Maven bundle插件、Ops4J以及Peaberry对Guice的扩展等方面做了很多工作。David在Apache的Sigil项目上干得很出色,在Paremus公司也取得了不错的业绩。最了解如何在实践中使用OSGi的人全在这支团队里了。作者将所有经验都融入了本书,这本书令人叹为观止。

这支团队承担了撰写此书的艰巨任务,在撰写过程中我一直和他们保持着密切联系——这不仅是因为我们都在OSGi联盟共事,还有一个重要的原因:在创作一本介绍OSGi的著作过程中,很可能会发现OSGi规范的缺点和不足,很明显这又会引发新一轮的激烈讨论,讨论通过Skype或者电子邮件进行。很遗憾,大多数情况下讨论都以该团队的获胜而告终。 他们请我写些文字介绍OSGi的历史,通过最大限度地压缩,最终仅仅用了4536个字,我想这就是OSGi。这正是我想要的:对高质量的追求,不仅体现在书中细节方面,还体现在组织形式上。不同于目前市面上的其他书,本书并没有使用大量的代码清单,概括出几个步骤从而实现某个预期结果。恰恰相反,其撰写方式我很喜欢:不仅介绍使用OSGi的细节,更不厌其烦介绍这其中的缘由,可谓一部释理之书。

时下正需要这样一本书。我很清楚搞懂OSGi实非易事。尽管OSGi是在面向对象的基础上构建起来的,但是它增加了一系列新的设计原语,用以阐释传统面向对象设计的一些缺点。当应用规模变大,需要用到一系列开源项目或第三方代码时,这些缺点就会表现出来。在软件构建过程中,面向对象仍可算是一项颇具价值的技术。但是面向对象模式不适用于大规模的构建块(组件)一起协同工作同时又不产生更多耦合的情况。我们拼命地使用工厂、类加载黑客等模式降低对象间的耦合,但是当达到一定程度时,降低耦合度的工作会占用我们大部分精力。依赖注入降低了代码耦合,但是大量代码需要使用XML编写,XML语言本身的语法在编程领域不是很合适。注解为处理耦合提供了另一程度的支持,但使用注解本身又会带来一系列问题。在降低耦合方面我们的处理方式大都是在做表面文章,因为在传统Java运行时环境下,这些边界并未清晰界定。 OSGi不同于传统Java。它将应用视为对等模块的相互协作:模块会主动适应环境而不是假设环境会主动适应模块。适应环境需要该环境真实存在,然而这正是OSGi最大的创新之处:μServices。μServices是模块间相互联系的纽带,它允许模块随时间不断演化而不会影响其他模块。在最近的一次OSGi社区交流中,David Savage使用spiky(尖刻、易怒的)一词来描述模块,用以说明一组模块之间的耦合会使修改模块变得非常困难。μServices是OSGi中的一个设计原语,它很强大,甚至可以在应用运行的情况下动态完成对模块的更新或者安装操作。通过将模块间的交互具体化,减缓模块间的冲突。 μServices是一个崭新的概念,理解它需要换一个角度思考,这不同于时下盛行的Java。在很多方面,OSGi很像25年前的面向对象程序设计,它提供了一些新的设计原语,而这可能不同于时下的一些主流思路。面向对象需要注入新的活力,这包括一些新的设计原语,比如多态、继承、类和对象。OSGi使用bundle和μServices缔造了一些新的概念。我相信这些设计原语会成为继面向对象之后的下一代软件设计概念。这本书非常优秀,借助它你能够真正地理解OSGi,并了解它的所有好处。

Peter Kriens OSGi 技术总监

前言

早在2000年,我刚开始从事OSGi相关技术工作时,无法预料自己会在10年后继续从事该领域的工作。那时,OSGi瞄准了嵌入式市场,但那不是我感兴趣的领域。我想创建高动态性、模块化的应用,恰巧OSGi给了我实现上述目标的可能。当时,还没有免费的OSGi框架的实现,所以2000年12月我在柏林自由大学工作时,开始着手开发自己的OSGi开源框架实现 Oscar。后来Oscar随我一起搬到格勒诺布尔,因为我去了约瑟夫•傅里叶大学工作。也就是在这里Oscar开始蓬勃发展。

随着OSGi技术的发展,Oscar于2004年加入了ObjectWeb开源联盟,后来又于2005年发展成为Apache 软件基金会的Felix项目。我很幸运地受到了OSGi联盟的邀请,直接参与制定OSGi第4版规范,OSGi R4规范于2004年发布。自那时起,我参与了OSGi规范制定的相关工作。起初我是一名学术研究者,2008年我加入Sun公司(已被Oracle收购)的Glass Fish团队,最近一直从事行业相关问题的研究。在最近10年间很多东西都发生了改变。

OSGi技术已不再局限于嵌入式市场,而是发展成为一个面向Java的成熟模块化系统。这种转变在2004年Eclipse IDE采用OSGi重构其插件系统时,帮了很大的忙。由于Spring和其他主要的应用服务器在企业应用领域对OSGi技术的采纳,进一步促成了OSGi技术的持续发展。尽管Java模块化仍在不断发展,但在未来很长一段时间里OSGi技术会扮演重要角色。现在说说本书。

几年以来我一直想写一本介绍OSGi的书,但是考虑到任务的艰巨以及没有时间,我并未将这一念头付诸实践。在2008年的夏天,我觉得是时候行动起来了,于是开始写作但很快又停滞不前了。直到Karl和Stuart以及后来David的加入,我才最终得偿所愿。我们各自有着不同的OSGi经验,将我们各自擅长的方面组合在一起,就包括了OSGi的全部内容。尽管如此,本书的写作仍旧历时两年多,期间经历过工作的变动以及几个孩子的降生。希望我们的努力能够对你有所帮助。

Richard S. Hall


sean 2015-06-12 14:57

有没有电子版的呢

顶(0) 踩(0) 回复

chuan 2013-11-20 14:06

兄弟刚买了一本OSGi实战,望哥们多译好作品出来

顶(0) 踩(0) 回复

chuan 2013-11-20 13:54

读起来非常通顺,感谢译者的努力

顶(0) 踩(0) 回复

松仁战玉米 2013-07-04 15:18

我在北京,你在哪里?

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