《OSGi与Equinox》第一章

 由  池建强 发布

第1章 OSGi、Equinox和Eclipse

本书即将出版之际,作为Java的组成部分,OSGi和Eclipse已诞生了十个年头。尽管它们过去在完全不同的领域独立开发,却同根同源,都为Java提供组件化的解决方案。OSGi面向的是住宅网关和机顶盒领域,Eclipse面向的是开发工具领域。然而,它们都对模块化和可扩展性有非常相似的需求。

本书第1章聚焦于OSGi和Equinox,我们将介绍些技术的历史背景、使用方法、优势以及它们能为你做什么。

1.1 简史

最初几年,OSGi和Eclipse技术并行发展,交集很少。OSGi组织是嵌入式和住宅网关供应商的松散联盟。它的模块化运行时规范几经修订,更新迅速,服务增多,而且不同领域的专家组也加入其中,尤其是汽车软件领域。规范逐步被大众接纳采用,越来越多的框架实现也纷纷出现。OSGi社区仍聚焦于嵌入式市场,因此嵌入式领域的需求也从简洁且改良升级的API以及设计当中得以体现。

同时,Eclipse是软件工具供应商的松散组织,注重于创建综合的软件工具平台。它的技术日益成熟,很快便统治了软件工具市场。基于Eclipse的大量组件成为各大软件公司的龙头产品。两大关键特性——模块化和开放型社区,成为掀起驱动工具领域变革的一对杀手锏。此外,Eclipse也开始涉足工具之外的领域,进入富客户端应用领域。这种转变也驱动了更多的需求,诸如更加完善的模块化机制、支持动态行为以及标准化。

2003年,Eclipse创建了Equinox项目,起初为了解决当时Eclipse运行时的相关问题——静态行为、非标准标记和执行模型,以及由此而造成的无法利用其他项目提供的诸如自动配置和管理等功能。OSGi不是其唯一的竞争者。

对可用技术进行公开调查(例如Avalon、JMX,当然也包括OSGi)后发现,OSGi被认定为最有前景的方式——清晰的组件模型、健全的执行规范是其主要优势。它可以借力标准化并创建更广阔的社区,其潜力是极其显而易见的。

选定OSGi后,Equinox项目团队需要获取、编写、借用或者收编一个开源项目。在当时,选项并不太多:在ObjectWeb中的开源Oscar项目(现在成为了Apache中的Felix项目);用作商业的IBM的服务管理框架(Service Management Framework,SMF);Knopflerfish,现在已是开源项目,但当时并未开源,并且Equinox项目团队也不知道有这个项目。 Oscar拥有很多优良特性,而且内部构造简洁明了。SMF优势在于它是工业级应用,已经投产多年,并且拥有开发团队在后台支持。最后,Equinox团队还是选了SMF。IBM将程序代码捐给Equinox项目,转换由此正式开始。

合成两种思维形式和开发方式并非易事,但有了OSGi核心平台专家组的紧密配合,Equinox团队对OSGi框架规范进行了许多改进,新增了一些内容,以覆盖新的用例。双方的合作既顺利而又卓有成效,取得的成果包括延迟激活(lazy activation)、bundle片段(bundle fragment)、bundle名称、版本语法以及bundle依赖等。在6个月内,原来的Eclipse运行时被无缝替换为新的Equinox OSGi实现。从那以后,Equinox逐步改进成对最新制定的OSGi R4框架规范的参考实现,并且两个社区的发展轨迹从此改变。

1.2 合作

那之后几年,有一点是毋庸置疑的——合作带来了巨大的收益。毫不夸张地说,Eclipse采用OSGi,极大促进了OSGi的发展。就在Eclipse采用OSGi前后,Google上“OSGi”的点击率增长了两个数量级。在Eclipse介入之前,大部分艰巨工作已经完成;但随着补充工作的进展和幕后市场化运作,在新的技术环境下,OSGi得到了成千上万软件开发者的钟爱。

双方都是合作的受益者。无论是在服务器还是嵌入式领域,Equinox看到了它在运行时场景使用中的巨大前景。而在其他领域,其作用也得到了淋漓尽致的发挥。所有主流Java应用服务器供应商都选择了OSGi。其中的许多厂商使用了Equinox。忽然之间,OSGi成为备受关注的技术,而Equinox是它的主要实现之一。

从技术层面而言,我们看到了软件系统集成方式的巨大转变。Eclipse已展示出组件化软件生态环境的工作模式——它改变了开发工具格局。在运行时及其相关领域,OSGi、Equinox、Felix和相关项目都同样加速转变。

在软件产业内,为多种体系结构创建组件模型的历程由来已久,这些体系包括:CORBA、SOM、SOA、SCA,等等。其中一些仅仅专注于特殊的计算领域,也有少数跨越了整个计算领域。从计算领域到应用领域,OSCi有何魔力,使其在跨度如此之大的领域都倍受青睐呢?

或许最关键的原因在于,OSGi刚开始时的应用环境是受限并且有着一定硬性需求的。OSGi原始关注的方向可以从它组织的原始名称看出来——开放服务网关协议(Open Services Gateway initiative)。在20世纪90年代晚期,他们最初主要是促进智能家居、住宅网关、机顶盒等诸如此类领域的发展,其行业标准聚焦在API设计时的模块化、集成性和动态性规范上。

十年前,住宅网关产业并未如人们期许的那样发展壮大。但其核心的设计思想却备受青睐,如今几乎在任何计算相关领域都已得到应用。

结果,模块化成为合作的润滑剂。

1.3 实战的模块化和自由化

无论喜欢与否,世界终归需要界限(boundary)。俗话说“篱笆筑得牢,邻里处得好”,该俗语在不同语言中有不同版本不无道理。界限设置了当事人双方的期望值,为双方契约关系的确立奠定基础。以正式的方式定义界限,得以实现开发时(development-time)和运行时监控(runtime monitoring),规限两者间应有的界限。

OSGi具有完善的界限机制。通过一系列机制,软件组件可以定义能为其他组件提供什么,以及从其他组件获取什么。在合作之前,一套组件必须明确需要其他组件的何种支持。

这直接支持了实现和信息隐藏。信息隐藏是非常好的,因为它对解耦和强制解耦系统元素的假设进行了限制。相反,如果没有相关知识,你需要假设任何可能发生的事情,或者假设什么也不发生。通过隐藏信息,你可以在自己的地盘做任何想做的事情。

即使最结实的篱笆也会有门。“篱笆”阻止人们穿越界限,而“门”却声明此处有界限,人们通过“门”穿过,并理解新的权力和义务。

通过正式定义“篱笆”和“门”,组件被解耦,实战的自由度也得以提升。不仅仅是组件被解放了,开发团队、系统集成商和产品设计师都获得了新的独立性和权力。具体表现在如下几个方面。

具体抽象——模块添加了另一种抽象粒度。正如子程序调用、分离源文件和类实现功能上的抽象,而模块提升了抽象的级别,并可以复用和共享。
组件等价——模块添加了隔离层,能够更容易地替换等价组件。实现替换的思想早已有之,接口、模拟对象和多态都体现了该思想。清晰的API定义在模块化中是固有的,极大促进了整套组件的替换,继而解放了开发团队,使其在软件生命周期中独立开发、移除瓶颈、降低风险。大多情况下,团队可以解耦,并独立改进他们的组件。
填料死亡——API和封装界限驱使开发者保持在一定的界限里。同样,因为API覆盖的bundle范围很明确,开发者很难考虑他们与其他人制定的协议。这反过来阻止了紧耦合代码间无组织填料的创建。
获得最快——灵活性和时间对于市场来说是非常时尚的流行词,它们也是真正的资产。形成业务逻辑,然后部署到独立的服务器、富客户端或者集成到已有的Web基础架构中,这是切实有形的收益,尤其是变动很微小时。双方都会是受益者。在同一平台上,描述和部署不同的功能集合变得更为容易。

1.4 平台

模块化不仅带来了自由,也促成了平台的诞生。平台这个概念在计算机科学之外的许多领域都已为人所熟知。例如汽车业,因为汽车的开发非常昂贵,于是制造商根据不同的业务需求,开发出不同的平台,然后在各个平台上进行独立装配。最初,平台只用于总装质量改装程度,如Pontiac(庞蒂亚克)和Buick(别克),Ford(福特)和Mercury(福特水星),以及Honda(本田)和Acura(讴歌,日本本田汽车公司旗下的高端子品牌)。这些不同的产品线分享共同的设计、组件和流水线工具。随着汽车市场的多样化,现在的平台已经扩展到“多元市场”。雅阁轿车(Accord sedan)与奥德赛面包车(Odyssey minivan),福特的金牛座轿车(Taurus car)和福特的佛莱克斯越界车(Flex crossover),均是产自相同平台而投放于不同市场的车型。

平台可被看成是在一种在基础模块之上的专业化工具或手段。平台集合了一套组件,可以为专门的领域或市场进行配置,以达到理想的效果,专注于解决方案中高度商业化的部分。然后,其他团队在平台之上再来构建真正的增值部分。 平台使得公司可以快速开发出新产品,因为他们不需要从头开发各部分。终端用户也会从中受益,因为平台基础技术通常得到了广泛应用以及更好的测试。这些效果显而易见,因为随着新功能、新特性和社区开发人员的不断涌现,平台的功能也在不断改进。

1.5 生态系统

流行平台促进了生态系统的发展,衍生出相应的消费者群体和贡献者群体,通过平台开展工作,并以更明确的方式来应用平台。在汽车工业的例子中,最直接的平台生态系统就是制造商和相关公司内部,虽然二级市场的部件制造商在一定程度上能受益于此,但收益较少。

然而在重型卡车领域,生态系统与平台的结合则更加紧密。重型卡车制造商生产一定数量的、不同底盘和动力传动系统的组合品。在很多时候,这些产品从流水线下线后还处于不适宜行驶的形态——它们缺少尾灯和其他安全装置。卡车到经销商或者消费者那儿以后,他们会将该平台定制成自动倾卸卡车、货运车、拖车,等等。在此例中,生态系统更加开放,应用也更加广泛。

开放的生态系统驱动了创新。因为每个人都有权使用公共平台,并通过平台增加其产品附加值。生态系统成员既可以竞争,也可以合作,或者兼而有之——“合作竞争”。终端用户可以选择他们如何交互,以及如何消费生态系统的输出。

1.6 OSGi的来龙去脉

上述这些内容与OSGi有何联系?和我们又有何联系呢?简而言之,OSGi在软件领域也有着相似的功用。作为工具平台,Eclipse的进化发展使其已经在综合开发环境市场中处于支配地位。在1.7.1节中,我们可以看到NASA Ensemble项目如何创建了一个空间任务软件平台,其富客户端和服务器端都构建在Eclipse之上。正如本节所述,所有主要Java应用服务器供应商都采用了OSGi作为其旗舰产品的基础,并且其中大部分都选择了Equinox。

所有这些之所以可行,离不开OSGi对深入模块化特性的改进、支持和加强。

1.6.1 Java的谎言

早期的Java社区有一个口号:“一次编写,到处运行。”这种说法在一定情形中是对的,只不过,Java世界已经被划分为Java ME、SE和EE三部分。它们面向不同的计算环境,促进了不同的模块化和执行模型。Java代码自身或许可以在任意地方运行,虽然这千真万确,但整个系统却不可以。

另一方面,OSGi对其使用的周围环境或者上下文约束要求很少,这使得它可以在较宽范围的场景中采用一致的编程模型。为服务器端编写的组件可以运行在客户端,反之亦然。此外,工具和开发者的技巧同样可以不受执行环境限制。在本书后续章节中,我们可以一探究竟。

1.6.2 现状核实

所有这一切听起来实在太过美妙,以至于难以置信,确实如此。有一句老话,天下没有免费的午餐。模块化并非那么简单。它迫使我们表达出期望、增加精确度、维护额外的元数据和商议契约。每次当我们画一个盒子,就会接着讨论什么该放入盒子,什么不该放入盒子。人类本性便是如此,这种做法未必完全错误。大部分讨论会加深对问题的理解,促使团队对系统的观点达成共识,催生出更好的软件。

通常情况下,事事皆有利有弊。我们的第一个、第二个和第三个组件集合可能会是紧耦合、脆弱且不利于模块化的。我们将难以识别成员、分清它们的角色,也搞不清楚它们如何进行交互。这并不是OSGi或者模块化的问题,这是任何系统在设计之初都会面临的挑战。OSGi通过它的模块化需求,强制并使得我们可以用具体的和有形的方式思考这些问题。 我们遇到过一些团队,他们采用OSGi时曾说过“OSGi很难”或者“OSGi不能为我们有效工作”,抱怨为何一些软件设计最佳实践不适合他们。这些言论是不负责任的,抹杀了前驱者的工作。的确,OSGi的一些工具本该更好,但没有一个工具可以一劳永逸、适用于所有情境。而且,如果我们将OSGi视为描述系统元素的框架,那么OSGi运行与否其实都是无关紧要的。 其中一个例子是Apache Harmony项目。这是一个创建开源Java SE5实现的项目。Java类库是巨大且复杂的软件系统,系统内各部分错综复杂。为使得多个独立团队能在该项目中工作,Harmony团队转向OSGi标记和工具。库被分解为一系列的OSGi组件,并具有清晰的API界限。OSGi工具用于强制界定开发界限。由此可见,OSGi在运行时运行与否是无关紧要的。

1.6.3 OSGi的寿命

OSGi规范由OSGi联盟制定,该联盟是众多软件和嵌入式系统供应商的产业联盟。它以一系列专家组(EG)开展工作,聚焦于一些特定的计算领域:核心、企业、汽车和手机。因为规范制定仅限于联盟成员,所以制定出的规范可免费使用。行业规范条例证书则由专门部门管理,且需付费。

总的来说,该组织机构健全,规范流程也相对严格,制定的规范很完整,可读性也高。每个规范都伴有一个参考实现(RI)。在许多场景中,RI是开源的。例如,核心框架RI是Equinox,而在其他场景中,RI则是联盟专有的。

除了他们自己指定的标准之外,OSGi联盟还不断推动Java Community Process标准,例如分别制定了JSRs 232和291,即Java ME和Java SE中的OSGi。

目前的核心规范在开源和商业产品范围内已得到广泛应用。OSGi的应用持续增长。一些新的规范由企业专家组(Enterprise EG)制定,即使刚刚发布,也显示了其巨大的前景。

作为规范主体,OSGi的主要挑战是在计算世界中保持其从Java向所谓的动态语言转换的相关性。目前,OSGi还是固守于Java技术。当然其概念和方式在向其他语言转化,但在那些语言环境中模块化还非常缺乏。OSGi还有很大的提升空间,只不过需要我们付诸实践。

1.7 实践中的OSGi和Equinox

广泛使用OSGi和Equinox的典型例子是Eclipse集成开发环境(IDE)。Eclipse被全世界成千上万的软件开发者使用。数以千计的开发者开发bundle来扩展该平台,数以百计的公司基于该平台的功能开发他们的产品。Eclipse以潜在的模块化基础架构为后盾,已经彻底革新了工具市场。

尽管如此,人们仍然没有将Eclipse与OSGi的强大功能联系起来,这是因为用户没有开发大型、工具相关的系统,他们只是开发一些中小型的终端用户或者服务器端系统。作为OSGi的开发环境,Eclipse是一个大型的复杂平台,并没有为用户提供任何功能。然而,用户仍然可以从本章的描述中获得很大收益——同样的效果带动了Eclipse的成功。让我们来看一下这些技术在其他领域中的应用。

1.7.1 NASA的Maestro和Ensemble

NASA的Maestor和Ensemble项目是使用OSGi的一个引人注目的例子。几年前,NASA采用了Eclipse富客户端平台(RCP)作为其Maestro空间任务软件平台的基础。目前,他们正在使用它管理火星Spirit和Opportunity任务。他们在Eclipse、OSGi以及此外的模块化软件开发上的经验非常有价值,从而使得Maestor又孵化出了Ensemble项目。

Ensemble有不少改进,包括由许多NASA团队创建和使用的空间任务软件平台。每个任务由许多不同的元素组成,每个元素又拥有自己的软件集合,用于计划和执行所需的步骤。虽然该软件涉及的领域和内容可能千差万别,却有一些共同的功能集合、UI及其他一些功能被广泛使用。Ensemble采用了这些商品组件,并使得它们可以为任务软件团队所用。

在NASA平台的改进过程中,服务器端的工作占据了相当大的部分。开发团队在服务器端扩展到使用Equinox,并开发他们自己的RESTlet架构,来解决扩展性和灵活性的问题。在其EclipseCon 2008指南(EclipseCon 2008 tutorial)中,对于该话题,他们总结的方法如下。

Eclipse RCP+服务器端Equinox=“轻层次化计算”(Tierless Computing)

  • 开发许多独立于开发环境的bundle。

  • 共享服务器端和客户端之间的某些功能。

  • 自由地按需来回迁移功能。

  • 自始至终使用一致的开发环境(Eclipse)和组件模型(OSGi)。

  • 同时调试客户端和服务器端!

以上几点直接反映出本章之前讨论的受益和效果,NASA团队享受着OSGi所带来的丰硕成果。

1.8 总结

OSGi是强大、健壮的模块化框架和运行时。Equinox是对OSGi关键规范的健壮且可扩展的综合实现。规范和实现都是开源的,由多个供应商组织驱动,其不断开拓创新的历程均有迹可循。

这些技术发布的价值在于独立开发者、团队和组织能够改变他们开发和发布软件的方式。这一宏伟的宣言已经在许多开源和商业软件的例子中得到证实,包括NASA团队构建的Maestro和Ensemble。

OSGi来自于嵌入式领域,Equinox来自于工具领域,二者结对发展进化;它们正扩展到更加常规的服务器运行时空间,这恰恰是Java应用服务器供应商所喜好的方式。难怪分析家们称,OSGi为最值得关注的热门技术之一。

本书余下内容将详细介绍OSGi的细节、成功案例以及如何在项目中发挥最大效用。


wmz 2015-05-19 10:00

http://osgi.jxtech.net 是一个企业级的OSGi开发平台。

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