数周以前 JBoss（已被 Red Hat 收购）发布了其 JMS 产品的最新版本， JBoss Messaging 1.2 。这个产品的面世已经有些时日了，它产生的目的是为了替代日近迟暮的 JBossMQ。这个发布版最终加入了产品级消息传送系统所需要的集群（Clustering）和透明故障转移（Transparent Failover）功能，因此对于 Red Hat 来说，这是一个非常重要的里程碑。
透明故障转移功能允许在连接的节点出现故障时，透明地将连接或者 Session 转移到另一个正常节点，而无须让应用程序显式地处理连接异常。另一个被加入的特性是分布式消息接收站（Distributed Destinations）。与 JBoss 的某些竞争者不同，JBoss Messaging 逻辑上完全支持在集群内部分布的队列（Queue）和主题（Topic）。
InfoQ 采访了 JBoss Messaging 项目领导人（Ovidiu Feodorov）和技术领导人（Tim Fox），深入了解这个最新发布版以及他们对 JMS 和 SOA 的总体看法。
InfoQ：首先祝贺 1.2.0 版本的发布。请二位向大家简单介绍一下自己，以及你们在 JBoss Messaging 团队里面承担的角色好吗？
Ovidiu：谢谢。我叫 Ovidiu Feodorov，是这个项目的创始人和领导人。自从 2004 年项目诞生以来，我一直在领导这个项目。这些年来，我们项目的代码行数从一无所有增长到接近 30 万行，并且经历了两次主要的通用版本（General Availability）发布。
我们是一个小型团队，到这次采访为止我们只有 3 个人，所以我认为我们并不能算一个合理“分层”的团队，拥有非常明确而不重合的角色和责任。整个团队看起来更像一个起步公司，所有人都在为推动项目前进而努力。因此，我参与代码编写，组织并参加设计会议，撰写文档，回答讨论组中的提问和支持请求，维护 Wiki，进行授课讲解，在必要时进行站上咨询，在用户会议和技术大会上推广 Messaging，做任何这么一个小团队需要我去做的事情。在这些角色中，最让我乐在其中的事情就是保证整个团队紧密配合，专注于我们的“使命”，也就是编写出全球最优秀的消息传送系统。
Tim：我的名字叫做 Tim Fox，加入 JBoss 约有 18 个月。在此期间，我把所有的精力都投入到了 Messaging 上。在加入 JBoss 以前，我是开源 JAIN SLEE 1.0（Telco 应用服务器）第一个实现的共同作者之一。目前我是项目的技术领导人，就是说我的责任是引导项目技术方向。本质上说，这意味着我需要去肩负审视技术实质的技术架构、设计和其他问题的责任。
InfoQ：你们认为这个发布版和以前的 JBoss Messaging 在可靠性和性能方面相比感觉如何？
Tim：大部分 1.2 版 codebase 是基于 1.0 版 codebase 开发的，因此我们是在一个已经于全世界许多生产系统中广泛使用的基础架构之上进行构建的。对于可靠性，我们一贯采取十分谨慎的态度，但我们在 JBM 1.2 中与 JBoss Transactions 的整合更进了一步，所以现在使用 JBM 进行任何 XA 事务性操作都会具有很高的持久性。也就是说，我们着重实现了 ACID 的“D” 属性（Durability，持久性）。
在性能方面，我们使用一个性能测试框架，它可以对所有与 JMS 1.1 兼容的系统进行测试。结果表明，JBM 的性能几乎在每一个方面都将 JBossMQ 远远甩在身后。
Ovidiu：1.2.0 GA 是“带集群的版本”。1.0.0（以及随后的 1.0.x 系列）是一个完全和 JMS 1.1 兼容、不支持集群的消息代理，而 1.2 超越了 JMS 规范，并加入诸如容错和负载均衡等企业级能力，并保持其完整的 JMS 1.1 兼容性。
新的 1.2 消息传送代理包含完全分布式的消息接收站、动态负载均衡和透明故障转移功能、零单点故障和零单点瓶颈、完善且完全可配置的消息过期处理，以及 XA 事务恢复等机制。
此外，1.2 提供对可插拔传输层（Pluggable Transports）支持，也就是 HTTP 和 HTTPS。从技术角度准确说来，其实在 1.0.x 系列已经这项功能已经存在。不过直到 1.2 我们才完全激活和测试了 HTTP 与 HTTPS 支持，还加入一个新的性能“Bisocket”传输层来简化管理，并使我们处理防火墙更加容易。
回顾起来，现在我认为这个发布版更应定为 2.0，因为我们已经为它引入了很多新的功能。
InfoQ：你们认为这个发布版和以前的 JBoss Messaging 在可靠性和性能方面相比感觉如何？
Ovidiu：这个发布版其中一个主要改进是，它支持横向扩展性：我们可以无缝地为集群加入更多节点，使得消息的处理拓展到更多物理节点之上。在和单节点性能相关的部分，最初的 1.0 代码中进行过几次重构。我们从根本上改变了包含主要消息传递路径的核心通道机制。尽管 1.2.0 在性能方面可圈可点，它仍然存在许多优化的余地。这也是后续的 1.2.1、1 .2.2、2.0、3.0 等等所要做到的事情。
对于我们的性能框架，还有我们计划用于追踪跨版本性能度量改进的“性能测试”概念，我们相当引以为豪。功能测试所采用的是同一种方式，可以告诉你 API 的实现存在问题。如果我们破坏了实现，使它的性能低于比原来版本，那么性能测试将触发警钟。如果你希望了解我们测试框架背后的概念以及如何使用它，请看这里。
在可靠性方面，这个“集群”版本 和1.0.x 系列存在根本性区别。对于1.0.x 代理，故障对于管理员来说意味着他必须重启服务器实例，然后客户端代码监测故障，查找新的连接工厂（Connection Factory），重新建立连接等等。在1.2 里就不同了，故障被透明地处理，客户端甚至觉察不到连接发生故障（除非客户端注册一个特殊监听器）并且被转移到另外一个备用节点上。
InfoQ：提到 JMS 和 JBoss（或者应该叫 Red Hat？），大多数人会想到 JBossMQ。尽管它很流行，但存在一些广为人知的缺陷，因此许多人不得不专向其它方案。这是不是 JBoss Messaging 诞生的原因？
Ovidiu：是的。回到 2004 年 4 月，JBoss Messaging 诞生以前，我在奥提汀参见了一个设计会议。会上我、JBoss 首席科学家 Adrian Brock、JGroup 创始人 Bela Ban 和 Ivelin Ivanov 讨论了“消息传送的局势”，并试图确定到底是为现有的 JBossMQ 打补丁，还是将其弃之一隅，并从头打造一个全新的实现。当时我在 JBoss 还算新人，“拍照设计（design by photography）”的火候还不到家，所以那次会议我没有留下记录。不过我可以让你看看另外一些好东西——2004 年 12 月在奥斯汀拍摄的设计图表，当时和 Adrian Brock 一起，我们对新设计进行了第一次评审。从以下地址可以找到这些照片： http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDesingMeeting20041203 。有兴趣的人可以通过这个地址了解到关于 JBoss Messaging 设计会议颇为完整的历史记录： http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDevelopmentMeetings 。
回到原来 JBossMQ 对 Messaging 的问题上来，我们总结出，JBossMQ 存在两个最基本的局限性。其中之一就是，高可用性对于 JBossMQ 只是事后追想。SynderMQ 是 JBossMQ 所基于开源项目，本质上这是一个不支持集群的代理。另外一个局限与非集群代理本身的线程模型和总体设计有关，这也导致在某型高负载使用场景中的性能缺陷。
那时候，我们认为解决这些根本性问题或者给它们打补丁，要比一切从头开始麻烦得多，正是这个决定导致了 JBoss Messaging 的诞生。现在，整整三年过去了，我们经历了两次主要的 Messaging 发布。到底这个决定正确与否，还要由我们的用户来检验。
InfoQ：JBoss Messaging 和 JBossMQ 相比如何？
Ovidiu：JBoss Messaging 是一个从头开始设计的 JMS 代理，在设计之初就考虑了企业特性。最开始我们是基于这样一个假设来设计 Messaging 的：它是一个完全支持集群、负载平衡且高度有效的代理。如我前面所说，JBossMQ 从一开始就是个不支持集群的 JMS 代理，它的 HA 功能实际上是以 HA 单例机制（HA Singleton Mechanism）的形式“拧上”的。
一个 JBoss Messaging 接收站（不管是队列还是主题）可以存在于不同的地址空间，散步到多个虚拟机和物理主机上，提供无缝负载分布和透明故障转移，而所有的 JBossMQ 接收站都被装载同一个 VM 上。如果这个 VM 出现故障，HA 单例机制会在集群的另一个节点启动一个新的 JBossMQ 实例（每个集群只有一个），并重新在那个节点上重新创建所有接收站。这样客户端享受不到透明故障转移所带来的好处，它们必须自己侦测故障，然后重新建立连接。
从本质而言，JBossMQ 是一个“单点故障”，但由于代理可以从故障恢复而在一定程度得到缓和，同时它也是一个“单点瓶颈”，而 JBoss Messaging 则没有这些局限性。
InfoQ：你们认为 JMS 与 SOA 有多大的联系？特别在人们看起来更愿意选择 Web 服务作为部署平台的情况下？
Ovidiu：MOM（Message Oriented Middleware，面向消息的中间件）作为整合松耦合系统的方式，问世已经有很长一段时间了。从历史角度上说，存在文件传输、数据库、RPC 系统和 MOM 几种方式。近年来，Web 服务出现，加入了这支队伍。所有这些方案都有它们的优势和不足，要决定使用它们中一种或者几种方案的组合，常常需要周密细致的权衡。
在标准级别的互操作性，是 Web 服务所具备但消息传送系统所缺乏的。作为标准，JMS 所欠缺的是对互操作性的考虑。JMS 规范尚未规定到消息传输格式这个程度，因此，每个供应商可以自由地引入自定义格式，并按照自己认为最合适的方式来优化实现。这当然不是说我们不能去编写桥接程序，但问题在于它们不能现拿现用。尽管如此，在这个地平线上还存在一丝曙光。AMQP，一个由 Red Hat 和其它公司一起推动的全新消息传送协议，正是面向互操作性问题而来的。让我们拭目以待吧。
这就是说，Web 服务和 MOM 都有各自最为合适的使用场合和具体的应用领域。
InfoQ：你们刚才提到 Red Hat 参与的另一个消息传送协议，高级消息队列协议（Advanced Message Queuing Protocol，AMQP）。它和 JBoss Messaging 之间存不存在一定重合呢？
Ovidiu：JBoss Messaging 是消息传送代理的一个实现，而 AMPQ 是规范。如果哪个实现具有重要意义，那它最终总是会被扩展成规范的。在仔细考察了 AMQP 规范之后，我只能这么评价：规范引入的服务端模型和 JBoss Messaging 内部架构完全吻合。我们差不多可以这么说，JBoss Messaging 打算在 AMQP 最终定案之后（目前版本号还是 0.9）将其实现，并能和其它 AMQP 实现进行良好的互操作。
Tim：AMQP 的确是个非常有意思的新协议。毫无疑问，我们将不断关注它的进展。我相信它的根本原则是值得信赖的，在目前 JMS 解决方案间尚不存在传输格式兼容性的问题上尤为如此。目前规范仍然处于完善阶段，尚未涵盖 XA 事务，也缺乏 JMS 和 AMQP 之间的明确映射，来确保在 AMQP 基础上开发的 JMS 解决方案间的互操作性。但我相信这些问题都在解决之中。我认为，AMQP 进入黄金期还为时尚早，但几乎可以肯定，大约一年之后它将大放异彩。
评论