BT

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

我们为什么需要分布式OSGi

| 作者 Eric Newcomer 关注 0 他的粉丝 ,译者 徐涵 关注 3 他的粉丝 发布于 2009年4月28日. 估计阅读时间: 7 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

随着分布式OSGi项目即将抵达重大里程碑,现在应当是一个恰当的时机来回顾一下我们已经完成了哪些工作、还有哪些需要做的,并谈一谈我们为什么要进行这项工作。

为迎接即将发布的OSGi规范4.2版,我们在11月对设计文档初稿(按OSGi术语叫Requests for Comment,或简称RFCs)做了更新。这个月,我们在Apache CXF发布了该版本中一个重要的新设计——即RFC 119,分布式OSGi——的参考实现源码

由于当前版本的OSGi规范已经在嵌入式领域取得成功,因此分布式OSGi(Distributed OSGi)项目被计划纳入OSGi的下个版本,并开始为企业级应用所采纳。比如,Eclipse插件就采用了OSGi框架;另外,所有应用服务器厂商以及众多ESB厂商也都接纳了OSGi。

OSGi联盟于2006年9月召开过一个公开研讨会,深入探讨了对企业版(若可能的话)的需求(Peter Kriens写了一篇非常好的描述此背景的文章)。当前版本的OSGi规范已经通过JSR 291成为了Java SE的一部分,对于我们参加了该研讨会的人来说,所面临的问题是,OSGi规范是否也应成为Java EE的替代方案,以及假如是的话那么需要满足哪些需求。众多关键需求中的一条是,OSGi服务能够调用运行于其他JVM之上的服务,并支持企业应用拓扑,从而提高可用率、可靠性及可伸缩性。(当前的OSGi规范只定义了在单个JVM里的服务调用行为。Peter的那篇研讨会总结文章里可以看到更多信息。)

2007年1月召开了首次企业专家组会议,工作由此正式开始。分布式OSGi始终是该议程里级别最高的需求之一。起初,我们常被批评为“重复已有工作”或“制造另一个CORBA”,不过这些都是由误解造成的。设计文档初稿(RFC 119)和参考实现代码将有助于解释清楚我们并非如此。我们只是扩展OSGi框架来配置现有的分布式计算软件系统。我们在RFC 119里采用“distribution software”(或简称DSW)这一术语来泛指任何能够进行远程服务调用的协议与数据格式系统。远程指的是另一个JVM或地址空间。

有人建议我们选择一种具体的DSW(distribution software),并将其标准化。此做法的一个好处是,我们可以利用针对特定协议的功能(比如可执行代码的序列化),不过这会缩小选择范围,并可能导致产生依赖。我们并没有那样做,而是定义了一个可用于任何分布式计算软件系统的通用配置机制。我们也试图不妨碍使用像“序列化可执行代码”这样的功能——也就是说,如果你愿意的话,仍然可以那样做,只不过那不是标准化的做法,因为它是针对单一类型的DSW(distribution software)的。

除了Apache CXF的参考实现,Eclipse ECF项目以及Paremus的Infinflow产品也有意实现分布式OSGi的设计,而且我们已经听说Eclipse Riena项目也在作此考虑。因此,但愿我们的分布式OSGi正走在正确的路线上。不过我们仍希望大家提供反馈,而且现在也还有时间来更改规范里的内容。分布式OSGi的设计还包括了发现服务(discovery service)以及用于配置多分布式软件系统组件的SCA元数据扩展。这两样东西目前尚未公开,不过应该快了。

为了说明我们目前处于什么阶段,对OSGi联盟的运作方式做一些了解是大有裨益的。OSGi的流程跟JCP(Java Community Process)颇为相似。实际上,OSGi规范刚开始就是以JSR 8出现的,而且它也基本反映了那个最初JSR工作的进展。OSGi流程是从请求提案文档(Request for Proposal,简称RFP)开始的,该文档对需求进行了详细描述。RFP得到批准后,一个或多个满足需求的请求评论文档(Requests for Comment,RFCs)将被创建起来。当一个RFC得到批准后,有关规范就会进行更新,以涵盖该项设计。RFP和RFC都是专家组的工作成果,尽管它们往往处于组里个别人或小部分人的带领下。

不过,OSGi联盟在规范方面的流程是独一无二的,因为文书写作都是交由Peter Kriens完成的。这点好极了,因为Peter Kriens从一开始就跟随OSGi的工作,他可以确保规范的质量与一致性。而且,这也消除了其他标准化组织在把文档书写工作交给其成员(通常代表与其他成员竞争的厂商)时经常碰到的政治问题。

当前版本的参考实现是为了验证RFC 119的设计,并使得该份RFC得以通过专家组投票。在规范阶段,我们期望在把该项设计整合进规范的过程中对它做进一步讨论,这也许会引起对参考实现的进一步变动。

OSGi专家组现在正着手于同Peter Kriens一起为R4.2版而努力,预计可于三月或四月发布初步版本,并在六月发布最终版本。关于即将发布的R4.2版的更多信息可以在OSGi Dev Con上得知。该技术大会将于3月23至26日在Santa Clara同EclipseCon联合召开。

R4.2版里的另一个主要部分是对核心框架的各种扩展,比如源自Spring的Blueprint Service服务模型(用于开发OSGi服务)以及各种映射到OSGi bundles的Java EE部件(JTA、JDBA、JPA、JNDI、JMX、JAAS和Web Apps)。Java EE映射并不如对核心的增强(如Spring/Blueprint或分布式OSGi)那么成熟,它们只是一个将随R4.2最终版一同发布的预览。

在过去的两年里,我们已经用初稿记录了分布式OSGi的需求与设计,并用参考实现代码进行了演示。OSGi规范R4.2企业版预计于2009年中发布,这是其中的一项重要特性。伴随着对OSGi核心框架的扩展、源于Spring的Blueprint服务组件模型以及关键Java EE技术的映射,即将发布R4.2版对OSGi规范和OSGi社区而言意味着前进中的重要一步。

阅读英文原文Why Do We Need Distributed OSGi?


给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

OSGI 我看好你哦 by 刘 恒涛

希望OSGI 能够在更早的应用于一般的企业信息系统中来。

Re: OSGI 我看好你哦 by xu huisheng

希望OSGI 能够在更早的应用于一般的企业信息系统中来。
太难了,对原有系统改造太大。除非找到更便捷的集成方式,否则负担不起系统平台迁移的痛苦。

有了分布式OSGi,EJB还有用武之地么? by 曹 云飞

现在EJB的卖点就是分布式对象,有了分布式OSGi,就可以提供分布式boundle级别组件调用,粒度比对象大,但是也够用。分布式OSGi还有OSGi的种种优势,相比之下EJB就逊色了,EJB前途暗淡呀。

期待 by Black Nile

osgi还是分布式的,期待!

Re: 期待 by chen honnom

开源项目中已经有很多采用了OSGI,比如作为开源esb的ServiceMix4.0版本正式基于OSGI的,Camel2.0也是基于OSGI.

Re: OSGI 我看好你哦 by Fei Yi

随着Virgo BluePrint Spring DM 等一系列技术的发展,企业级OSGi已经相对成型。
我们小组去年开始,就搭建了一套OSGi 企业级的Web框架。
最近也找谁准备推广OSGi这项技术,希望更多的人学习好的技术!
www.osgi.com.cn 这是我们的网站,最近一直在维护更新。
有兴趣的人可以去看看,给点一点也是欢迎的!

OSGi开源开发平台JXADF by soft wmz

OSGi开源开发平台中,最成熟、最优秀的应是JXADF,在 osgia.com 中有在线演示。

允许的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通知我

7 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT