这篇文章将告诉你 JBOSS Messaging是什么，产生背景，能解决什么问题。
数周以前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进入黄金期还为时尚早，但几乎可以肯定，大约一年之后它将大放异彩。