BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Peter Kriens重返OSGi联盟

| 作者 Vikram Gupta 关注 1 他的粉丝 ,译者 张卫滨 关注 13 他的粉丝 发布于 2013年11月5日. 估计阅读时间: 19 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

Peter Kriens是OSGi背后的主要推动者,日前在其博客上宣布重返OSGi联盟,到2012年初为止他一直在这里担任总监长达11年。InfoQ联系到了Peter,与他讨论了重返OSGi及其jpm4j项目的最新情况。(这里所表达的观点是Peter Kriens本人的,并不代表OSGi联盟的观点。)

InfoQ:Peter,欢迎重返OSGi联盟。自从你离开之后都做了些什么,未来你又会做些什么呢?

Peter:我离开的主要原因在于我需要重返第一线。我的计算机生涯开始于上世纪七十年代晚期,非常幸运很年轻的时候就能开发高级的分布式系统。随后,Ericsson给了我一个很好的机会来领导规模很大的项目,在完成之后,他们非常慷慨地让我于九十年代加入了应用研究实验室(Application Research lab)。毫无疑问,这些年是非常重要的成型期,直到2001年加入OSGi。

但是,在编写了十多个规范之后,我感觉有时候会太多地讨论理论而不是基于深入的实践。尽管我认为这是我们这个行业所司空见惯的现象。当我无法完全掌握(in 'my fingers')一项技术时,会变得很不开心。这种内心的声音因为OSGi企业级专家组的重要性不断增加而变得更加强烈。我的经验更多的是来源于嵌入式领域,所以如此之多的“最佳”实践让我感到很困惑。

我离开的第二个原因在于仓库(repository)。我认为,当前我们处理二进制制件(artifact)的方式有很多的问题。不要误解我的意思;Maven中央仓库对我们来说是非常重要的资产,而且不仅仅对Maven用户来说是这样。但是,它底层的文件/目录基础模型对于长期来说过于简单。应用的复杂性在不断地增长,我认为仓库需要更多的功能,它需要更加智能地组织制件。我试图在联盟中推广这样一种OSGi仓库,但是很遗憾的是没有得到什么响应。结合这一点,再加上我非常愿意重返第一线,暂时离开OSGi联盟看起来像一个不错的休假,我很享受做自己喜欢的事情!

不过,今年初我发现要做好jpm4j很明显需要更多的人。我开始与不同的公司接触,谈论它们是否对其感兴趣,但是我没有找到一家公司能够对其进行充分地投资。现在,业务开发并不是我的强项,并且我确实已经达到了最初的目标,因此我对此已经非常满意,很开心重返OSGi联盟。

InfoQ:OSGi做了很多的工作,不过用户的采用情况似乎与之并不成比例。为了给这方面带来动力,需要做些什么呢?

Peter:我受雇就是要推动其采用情况。为了理解我们的策略,我介绍一下过去一年中我的部分经验。

对于jpm4j来说,我包含了OSGi并且基于Bndtools进行的开发,这是Neil Bartlett的一个Eclipse插件。我发现使用OSGi构建实际规模的应用是很困难的,因为大多数的JEE库(以及开源库)在OSGi中使用起来会很笨拙和别扭。因为我不想进行妥协(毕竟我是在做一个学习的练习),我开发了很多“原生”OSGi的解决方案。我为安全、队列、配置、批处理任务、mongo、浏览器集成等问题开发了bundle。这些组件与JEE或开源的对等功能相比要简单很多。我能通过几周的工作替换掉颇具规模的类库并不是因为我多么聪明,其实不是这样的。我能比较幸运地做到这一点是因为OSGi提供了很多的基础功能,而大多数的类库都在用专有的方式在重复这一点。通过标准化生命周期、依赖以及配置基础,这些组件内部就具有了协同的功能。如果你使用OSGi的话,你会发现通常只需要编写非常非常少的代码,因为环境已经处理了很多常见的、易出错的细节。在非OSGi的环境中,因为没有发现服务、生命周期以及配置的标准化,你会发现在不断地重复自己,还要编写很多粘合性的代码。

现在它与Bndtools进行了结合。我承认并没有尝试市面上的所有IDE,但是可以肯定地说我的OSGi框架能够在bundle每天更新上百次的情况下保持运行。很美妙一点在于,你可以点击Ctrl-S、切换到浏览器、刷新,然后就能看到结果了。这与Ruby on Rails的编辑-调试模式一样简短,但现在将Java、Eclipse以及OSGi的威力添加了进来。现在,你也有这样的蛋糕(快速编辑-调试周期)并可以享用(重构、快速帮助、类型安全、导航、强大的模块化以及µservice等)了。

实际上,我对OSGi相当地喜爱。不过,在企业级领域可以看到它的长处,不过它也有其不足。我通常会这样说,OSGi是相当坚实的基础,可以基于它构建最高的摩天大楼,但即便是搭建最小的房子,它所能提供的支持也少得可怜。所导致的结果就是,很多人必须要自己将这些片段集成起来。真正缺少的是一个OSGi应用的骨架(skeleton),它要适用于最大群体的开发人员,也就是web应用的开发人员。我相信,我们不用费太大的力气就能构建出这样的东西。实际上,所需的各个部分都已经就绪;所缺少的就是一种将这些部分放到完整的应用之中的一种方式。

所以,我提议为OSGi联盟做一个这样的骨架。IBM的Dan Bandera,同时也是OSGi联盟的主席,做了一个这样的提议并在董事会进行了讨论。我很意外地得知,他们希望我立即启动它!因为,我还想做一些关于jpm4j的工作,所以我会将自己的时间分给联盟和这些jpm4j的工作。

InfoQ:能给我们介绍一下jpm4j吗?

Peter:几年前,我认识到随着时间的推进,公共的仓库将会持续增长,因为你不能删除任何的修订版本。移除版本可能会破坏构建!当你使用版本范围或OSGi的功能/需求(Capability/Requirement)模型时,有一点大家可能还没有理解到,那就是增加新的版本也可能会破坏构建。使用版本范围的构建今天可能会成功,但明天可能就会失败,因为仓库中有了一个更新的版本。这就是说,在构建依赖中,仓库的内容是第一等公民。通常来讲,这是仓库中不太被大家所理解的方面,也是Sonatype不建议人们使用Maven版本范围的原因。

对我来讲,多年前我就清楚认识到仓库需要像版本控制那样的版本化,并且要与它结合起来;在OSGi联盟内部,基于这样的原因,我们一直使用版本控制系统来管理二进制依赖。我认为,对于基于云的仓库服务来说会是一个机会,这就像针对二进制文件的Github。

不过,为了要对仓库进行版本化,你首先需要所有可用的制件的一个目录(catalog)。在与Karl Pauls和Richard S. Hall (OSGi提交者以及Manning OSGi in Action的作者之一)经过了一周的讨论之后,得到的结论是,我需要一个公开的社区站点,它包含了所有可用制件的目录。这个目录可以作为我的版本化仓库的基础。不过,具备这样的目录也能够让我解决一个非常令人沮丧的问题,我将其称之为Java的最后一英里(last mile)。几乎所有的动态语言都具有在不同操作系统上安装应用程序的方式,如NPMGemCPAN等。尽管Java无疑是有史以来最便利的语言,也具有便利库的巨大优势,但是开发人员要安装一个应用程序要经过很多的步骤。所以,jpm4j具有一个jpm的命令,借助它就可以很简单地在本地安装应用了,它可以用在命令行之中也可以作为服务。jpm知道在Windows、Linux、MacOS中应用该怎样处理并会将其安装在合适的位置之中。

这个特性尽管随着时间的推移处于了次要的地位,但它是jpm4j命名的原因:“Just another Package Manager for Java”。也就是说,它并没有完成还有很多的工作要做。如果这个过程全部完成的话,会有相当大的规模。如前面我所讲的,我正在与一家公司进行交流,它们愿意接收这个项目并进行进一步的开发。

InfoQ:这样听起来似乎很有意思,但是这里会不会有鸡和蛋关系的问题,启动仓库会使用大量的有用的bundle?

Peter:当时,我的首要目标并不是OSGi。我知道这听起来有点奇怪。Jpm4j是一个Maven仓库,因为它是目前最流行的仓库模型。所以,我想将这些版本化的仓库提供到Maven领域之中。因为我的心思很大程度上还在OSGi上(比我当时所意识到的更为强烈),所以我在这里将OSGi作为一等公民。

开始的时候将所有的制件都放到Maven中央仓库是很简单直接的。jpm4j的核心在很大程度上是JAR的目录,所以我为Maven中央仓库编写了一个扫描器并且会自动导入它们的所有制件。jpm4j扫描所有的JAR,并且当它探测到OSGi bundle的时候也会按照同样地方式列入目录之中。jpm4j会收集Maven元数据和OSGi元数据,并且为其他的元数据提供了一个插件模型。目前在jpm4j中已经有400,000个版本信息了。

不过,尽管它是以Maven为中心的,但是jpm4j独立于任何的仓库格式。我还让它可以很容易地在Github上创建二进制仓库,你只需在Github上提供一个事后的挂钩(post hook),jpm4j将会扫描这个库(repo)并更新它的目录。Jenkins构建可以实现类似的挂钩。我还规划扫描所有的Eclipse bundle,并且包含众多的企业仓库。

所以,我试图让人们能够很容易地将他们的bundle对整个世界开放。我以为我已经达到了这一点;实际上门槛相当低。

InfoQ:对使用者来说又会怎么样呢,他们在使用bundle前是不是需要迁移到OSGi上?或者这只是为处于新建阶段的项目准备的?

Peter:我认为不是这样的。OSGi是一项重要的投入,因为它不像其他的一些库,对于其他的这些库来说,你只需将其加入到类路径下就能得到一些非常好的新功能。OSGi很小,因为大多数的工作都需要你来完成,也就是用户。Parnas开创性的模块化论文讲的都是如何将一个问题分解为模块,这样模块之间的耦合能够最小化而内聚能够最大化。当我们传播OO范式时,在七十年代所学到的基本经验教训都被面向对象社区所践踏了。只有OSGi提供了执行这种模块的基础。

OSGi的巨大收益是通过更少的代码做更多的事情来实现的,代码也会更容易维护。如果要做得正确的话,它会影响到开发过程的每一部分。尽管有清晰的迁移路径,但是如果没有变化意愿的话,我不会尝试OSGi。这很类似于减肥,临时的节食很少能保证长期有效;如果你想要变得苗条并能够保持的话,你需要改变生活方式。因此,如果想要控制手边已膨胀代码所带来的成本,只有一个快速解决之道:等待直到计算机变得更快。既然摩尔定律对于传统的顺序执行程序(classic sequential program)已经过时,那么这种快速的问题解决办法会变得更加困难。

也就是说,开始使用OSGi是一种门槛很高的方式。太多的开发人员因为这个高门槛必须要忍受漫长的学习曲线。显然我注意到已经有应用服务器框架,但是我指的并不是这一点。这些框架并没有使用OSGi真正的长处。在追求JEE兼容性的过程中,它们很容易会将这两种环境的缺陷结合了起来。OSGi最酷的特性在于服务模型,但是这些环境都没有包含它。我在OSGi方面所做的新的努力希望能够展现出如何做到这一点。

InfoQ:使用OSGi很大程度上需要一种开发规范(discipline),这种规范可能正是缺失的一环,它使得相对于其他的工程规范来说,软件工程是如此得模糊。不过,我们该如何期待一直按照某种方式行事的团队改变方向、在规范方面获取新的收益,并且开始按照模块的方式思考而不是专有的架构,毕竟这在我们行业是很普遍的?

Peter:完全是这样,正如我前面所说,打个比方,OSGi是一种生活方式,并不仅仅是饮食习惯而已。

现在,你提到了有趣的一点在于我们该如何摆脱(这是什么呢,一个价值5000亿美元的行业?)我们的工作方式?这里有很多的原因,但是我认为根本原因在于我们并没有承担起责任。如果Amazon违反了服务等级协议(SLA),他们只需要赔偿给你就行了。如果雇员因为薪资程序的崩溃没有得到工资,那么他也只能忍着(当然,可能会延期支付或其他的方式进行支付——译者注)。如果金融工程师搞砸了财务系统,那么社会也会宽恕他们。每位超过30岁的企业级开发人员都曾经做过失败的项目,但是我没有听说有人因此而失去工作。相反,如果建造一座大桥,它却垮塌了,想耸耸肩膀就转身逃离是不可能的。

在嵌入式领域,软件会做得更加仔细,因为它们要为自己的软件负责。比如说,汽车公司会知道部件的任何问题都会使其陷入昂贵的法律诉讼之中。但是,在企业级软件领域几乎并没有这样的反馈循环。所造成的结果就是什么事情都可以通过。我希望我们的工程规范是唯一具有摇滚明星、趋势以及时尚的那一种。责任的缺失造成了我们行业中各种负面的激励。

我一直感到惊讶的是开发人员会花费大量的时间却会拒绝花哪怕一点点钱。在开发过程中,责任会深刻涉及到非开发人员。对于非开发人员来说,时间与金钱间的权衡会更加显而易见。我相信这会快速推进OSGi现状的改变。

在此之前,对于OSGi来说最重要的事情是推动被草根所采用的努力。这是我为OSGi联盟所要完成的工作目标之一。通过让OSGi对于大多数常见场景下更加易于使用,我们希望能够增加对OSGi的了解并展现服务模型所能带来的收益。很多开发人员热爱OSGi的架构,我认为是开始的这个部分让他们望而却步。

InfoQ:在重返OSGi联盟后,你还会担当其他的角色吗?

Peter:尽管这次我不会再编写规范,但是我依然会参与一些技术专家组,当然我也会再次参加一些巡回的会议。我计划推动一些规范,它们能够使Web应用更容易构建。我还会参加董事会的会议。对于其他50%的时间,我会计划进一步推进jpm4j,因为它显然没有完成。

InfoQ:有什么事情是社区可以做的吗?

Peter:在降低OSGi门槛所做的努力方面,我非常乐意能得到反馈。我还希望能够与任何想讨论jpm4j的人交流。在这两方面,我会尽可能发挥社区的力量。

InfoQ:问一个个人问题,我曾经在各种会议上看到过您的演讲,你的演讲就像你所描述的技术那样令人屏息凝神。你是怎样做到这一点的呢,对于演讲者来说你有什么窍门吗?你总是能够找到或做出很棒的图片并将它们精炼地放在一起形成特别棒的效果,最后按照你独特的方式将其做成很有意义的文稿,你是如何做到的呢?/b>

Peter:哦,非常感谢。在这方面,每次我登台的时候,实际上都会感觉准备不充分,所以很难回答这个事先没有预料到的问题。

我唯一可以讲的就是,对于我自己来说,我是典型的以视觉为导向的。主要的原因在于我可以盯着一个XML文档看几个小时,却看不明白。但是,如果给我看一个好的图片,它看起来就很明显了。看一下OSGi规范;很少有规范具备如此精心制作的插图。主要的原因在于要确保我能真正“看懂(got it)”。我有很多朋友,它们不看图片并且能够通过XML文档得出相同的信息,我一直对他们有深刻的印象。我的大脑需要图像,我觉得这一点无形中影响到了我的演讲文稿。

关于作者

Peter Kriens自1990年代就是独立的咨询顾问。目前,他为OSGi联盟和jpm4j工作。在八十年代,他为报社基于微型计算机开发了高级分布式应用,并且这基于当时非常新颖的面向对象技术。凭借在面向对象技术方面的经验,他曾经被很多的国际公司所雇佣,包括Adobe、Intel、Ericsson、IBM等等。1998年,在Ericsson研究所工作期间,他参与到OSGi规范之中;随后他成为这些规范的主要编辑者。在2005年,他被授予OSGi院士称号。在2012年休假开发jpm4j之后,他重新回到了OSGi联盟来帮助推进OSGi的采用。他是荷兰人,不过居住在法国。你可以在Twitter上关注Peter:@pkriens。

 

原文链接:Peter Kriens Returns to OSGi Alliance

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

OSGI开发平台的佼佼者:JXADF by soft wmz

开源平台,JXADF(osgi.jxtech.net)是基于Felix基础之上,将插件化做到极致,官网提供了在线演示、免费下载、丰富文档,值得推荐。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT