BT

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

JBoss AS 5发布:项目主管Dimitris Andreadis访谈

| 作者 Dio Synodinos 关注 3 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2008年7月7日. 估计阅读时间: 13 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

经过相当长的开发周期之后,JBoss AS 5 RC1已经发布了。InfoQ联系到了项目主管Dimitris Andreadis,请他谈了谈新特性和发布时间表。此外,Dimitri还谈论了Java EE 6的特性,JBoss AS竞争的优势,以及他们为什么选择实现一个可插拔的组件模型、而不单是支持OSGi:

InfoQ:你能否给我们一个简短的清单,列出本版本的主要特点和区别于早期版本的关键新特性呢?此外,能否简单说一下新的API?

JBoss AS5中,大部分显著的新特性添加都源自于要将所有主要的JBoss子系统带到下一个阶段去:

JBoss Messaging 1.4现在取代了JBossMQ,成为缺省的JMS提供者。除了透明的故障恢复和智能的消息重分发外,JBM还支持即开即用的集群队列和主题。可以跨节点把消息复制到内存中,从而避免磁盘I/O,或者能使用支持大消息的分页技术将消息持久化到任何流行的关系数据库中。JBM证明,利用已完全出现的新的只扩展日志存储,原本就很卓越的性能和东西会变得更加优秀。

JBoss WebServices 3.0,完全支持JAX-WS/JAX-RPC、XOP和SwA的附件、还有一系列WS-*标准。JBWS转向了一个可插拔的架构,该架构允许更换底层的WebServices栈,所以你可以将JBossWS-native换成Sun Metro或Apache CXF。这样的话,你就可以因地制宜,使用最合适WebServices栈。

为了改进可伸缩性和集群Web会话的钝化,AS5中的集群支持SFSB的Buddy复制,以控制内存的使用。EJB3 Entity和Hibernate缓存有了很大的改进,因为我们现在可以针对实体和查询使用不同的缓存,它们分别是失效缓存和复制缓存。在底层的JGroups协议栈中,还有一些其它的性能优化。

JBoss Transactions是JBoss 5默认的事务管理器。JBoss TS已经与JBoss 5的Servlet容器——JBoss Web——一起在AS 4.2系列中进行了测试,JBoss Web是基于Apache Tomcat的一个实现,支持原有的APR-based连接器,它在可伸缩性和性能上不但要达到,而且要超越Apache Http服务器的水平。

就API来说,AS5是Java EE 5的实现,所有相关的API都会包含在内。对大部分Java EE 5“新的”API来说,比如EJB3、JAX-WS、JPA等,在JBoss AS 4.2系列中已经实现了,但由于JBoss AS5增加了TCK测试的覆盖范围,所以肯定会更为严格遵循规范。

InfoQ:JBoss AS 5经过了一个相当长的开发周期,也因此饱受批评。至少与其它容器相比周期是相当长的。这是为什么呢?是不是4.2版本导致了延期?

JBoss AS 4.2和企业应用平台的第一个版本(EAP 4.2)确实对AS 5造成了很大的影响。我们在资源和遵循Fedora/RHEL模型的产品化努力方面比较薄弱,对我们(JBossians)来说,这是一个新的问题。另一方面,在AS5发布之前,4.2作为垫脚石为各种预备好的JBoss技术提供了测试场,4.2有利于让这些技术更早地得到社区的检验。

另一方面,在我看来,大约3年前开始AS5这一艰难的航程时,没人能全然清楚它的航向。从零开始创建一个全新的内核、从MBeans转换到POJO、在最底层集成AOP、统一跨子系统的元数据处理、更改类加载系统、使部署器Aspect化,换句话说,就是改变内部架构、替换应用服务器的核心,同时还要保持与大部分已有服务的向后兼容性,在这整个进程中,每一步都有很多工作要做,而且都有巨大的挑战。

拖慢进度的另一个原因是要为各种内部子系统引入合适的SPI。长远看来这是好事,因为它允许最大的可插拔性,以及在不同的运行时环境中(比如独立的EJB3或嵌入到不同的应用服务器中)按需要选取使用各种JBoss项目。然而维护几十个(我忘了具体的数目)微型项目耗费了巨大的精力。除此之外还有把如此大的代码集转到Maven2的痛苦,可想而知。

当然,对最终用户和想使用JBoss的开发人员来说,这些都是内部的实现细节,对他们来说,完全通过Java EE 5验证的JBoss延期让他们很恼怒。我只能对用户报以歉意,同时感谢他们耐心地希望我们尽快推出AS5、解决最初的小问题,结果将会是令人满意的。

JBoss AS5不只是一个Java EE 5应用服务器。对下一代JBoss项目来说,它还寄托了成为最先进的服务器运行时环境的愿景。

InfoQ:二月份发布了最终测试版,您能告诉我们什么时候会推出RC1呢?您认为什么时候会出最终版本呢?

CR1(候选版)在6月底推出。紧接着会在8月初发布CR2。根据我们收到的CR版本社区反馈的情况,我们会决定最终版本的交付日期。

目前推出JBoss AS5是我们的首要任务。

InfoQ:针对目前正在讨论的Java EE 6特征集,特别是预定义包,JBoss怎么认为呢?

我个人对Java EE 6中预定义包方案的感受比较复杂。Java EE规范的主要目的是提供给开发人员一个全面的企业版本技术工具集,以便应用能有更大的机会在兼容的运行时环境之间迁移。将这一技术集削减到一个非常小的子集(比如说预定义包A),这种方式会强迫开发人员添加不符合规范兼容的扩展,从而减低企业版本应用的可移植性。

既然有裁剪配置的能力,你就能避免在不使用的技术上浪费资源,这跟以前是完全不同的。前段时间JBossAS对3种预定义包(最小的、缺省和完整的,如果用jems installer则不只三种)提供了支持,自此以后,你可以更自由地裁剪服务器配置,只留下实际使用的那些。如果不需要JMS,那就移除JMS子系统好了。而这只是平台提供者的实现细节。

对更广泛的Java EE技术来说,重要的就是全面、通用和切合时宜。引入EJB3、JPA、JAX-WS对平台来说是一个巨大的提升。剪裁过程也是朝正确方向前进的一个步骤。有部分Java EE规范确实是边界情况(比如CSIv2)或废弃的(比如CMP),它们应该从平台中淡出。但不管怎么说,讨论基本的预定义包应该提供JSP还是JSF简直太无聊了;这两项技术都有很好的使用价值。

我实在是没看出来给Tomcat(预定义包A)打上EE的商标有什么意义,除了让几家小厂商给Tomcat加上两个扩展就能当作Java EE来叫卖。而且一个虽然有所增强、但却不能跑Web Services的Tomcat配置(预定义包B),我也没看出来有什么意义。所以总的来说,我认为预定义包对Java EE社区来说是弊大于利。

InfoQ:最近SpringSource发布了一个基于模块的Java应用服务器——Spring应用平台,该平台设计用来运行Spring支撑的应用。JBoss有没有像SpringSource做的那样,预先创建一个独立的、利用JBoss技术(Hibernate、Seam、Messaging等)的应用服务器呢?

正如你所知,你能裁减JBoss AS的配置,只留下你确实需要的服务集;这个在JBoss中一直是行得通的。提供一套预定义的Web配置,目前看起来更像一个市场决策,而非技术决策。删除功能和特性要比添加新的更为容易。我们在JBoss EAP之上引入添加了JBoss ESB、JBoss jBPM和JBoss Rules功能的JBoss企业SOA平台,暂时专注于将产品链提升到更高的水平。但如果有确切的市场需求,或者Java EE 6预定义包有更进一步的发展,我们可能也会做Web平台捆绑包。

InfoQ:服务器端应用已经普遍使用OSGi。GlassFish和Spring应用平台都选择了它。而JBoss 5的架构则是——允许组件模型可插拔,既可以与旧的代码集兼容,又能和未来改进的组件模型兼容。你认为这是超越竞争对手的一个战略优势吗?

一点儿也没错。

回顾一下,JBoss是自2001年以来第一个构建在动态微内核架构之上的Java应用服务器。JMX MBeanServer作为内核核心向MBeans提供服务,对内核的插件式服务来说,MBeans就是组件模型。在当时这是一种极好的选择,但是后来当POJO和AOP成为占主导地位的编程模型时,我们意识到了JMX核心的局限性。我们在JBoss 3重构的第一步编写了自己的JMX内核替换品(JBossMX),提供POJO和XMBeans的拦截器支持。但是不久之后事实证明,一个完全由我们控制、真正的POJO内核才是正确的前进方向。

对JBoss 5进行了3年的研发之后,我们了解到更换内核和组件模型的艰难之路会是一个非常痛苦的过程:把服务器内核和任何特定的组件模块结合在一起是完全错误的。当OSGi因为某些原因过时、或者一些更酷的组件模型出现的时候,我们的竞争对手将会遭受同样的痛苦。从某种意义来说,他们就像是7年前的JBoss。

但是对JBoss来说,支持一个新的组件模型会跟在JBoss Microcontainer之上构建一个新的外观一样简单。与我们支持原始的POJO、遗留的MBeans、OSGi Bundles的方式一样,我们会支持任何其它已有的、或者以后出现的组件模型。抽象的能力会让它达到最好的状态!

InfoQ:关于可插拔的组件模型,开发人员能否在组件模型之间共享信息,并让信息协作呢?

是的,这正是它的魅力所在。因为JBoss中不论类型(POJOs、MBean、Spring Beans、OSGi Bundles等)怎样,所有的组件都共享相同的背板,这些组件有可能由MicroContainer和依赖关系、跨不同组件模型应用的方面紧密联系在一起。MicroContainer技术由我们的智多星Adrian Brock设计,我们尚处于理解该技术能力和极限的初级阶段,但潜在价值看起来确实非常有意思。

InfoQ:关于JBoss AS未来的方向,您有什么意见愿意和InfoQ的读者分享吗?版本5之后又会有什么呢?

呃,我们现在主要的关注点是发布AS5,所以我不想对未来做太多的预测。我所知道的是,AS5将提供健壮的功能和完全可扩展、跨组件的模型、集成运行时环境的方面,新技术在其上会以更快的速度出现。因此我期望推出AS6的时间能比AS5短一些。

有些地方我们一定会予以更多的关注,比如OSGi支持、改善服务器的管理功能,特别是在大规模部署下的管理能力。在各种JBoss项目中也产生了很多创新;而且随着Java的开放,我们期望看到JVM本身的改进,以及JVM与应用服务器更紧密的集成,尤其是在Linux上的发展。

 

要获取更多关于JBoass AS及相关产品的信息,您可以访问:http://www.infoq.com/jboss

查看英文原文:Releasing JBoss AS 5: Q&A with Project Lead Dimitris Andreadis

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT