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

经过相当长的开发周期之后， 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