AMQP准备提供真正的业务互操作吗?

高级消息队列协议(Advanced Message Queuing Protocol,即AMQP)来自于 JPMorgan内部,这归功于John O'Hara。但John O'Hara的设想不仅仅是内部处理事情的一种新方式。围绕于此的 标准和开源技术势头渐劲。 Jeff Gould和其他人阐释了AMQP来于何处、谁在驱动它、以及它可能往何处发展。
AMQP规范的贡献者之一 IONA科技公司发表了一份 简要说明,说明AMQP是什么,以及为什么要进行。AMQP是
  • 一组明确定义的消息功能,被称为“高级消息队列协议(AMQP模型)”。AMQP模型由一组定义良好的组件组成,这些组件在一个消息代理服务中路由和存储消息,还有一组将这些组件绑定到一起的简单规则。
  • 一个网络线路级协议,可以让客户端应用与消息代理对话,与AMQP模型实现交互。
在 由三部分组成的系列文章中,Jeff Gould谈了AMQP的发展历程,以及John O'Hara开放其源码的决定。2003年雇用 iMatix为JPMorganChase实施一个AMQP项目,随后Beta版在2006年上线,每天处理3亿左右的消息。

O’Hara对AMQP的计划有着雄心壮志。从一开始,他就希望新的协议能与高端消息中间件(MOM)的功能相竞争。它之前必须处理所有主要的用例,包括队列式存储转发消息,Tibco风格的发布和订阅,还有可靠的文件传输。协议必须能够支持任何种类的消息,但重点是比起文本来,二进制格式要更有效率,因为在应用到应用的消息中,人们的可读性并不是最重要的关注点。

Gould接着指出,是O'Hara在探求一个真正将AMQP推出银行、走向更广阔世界的开放标准。正是开发标准将Red Hat、Apache、WSO2、IONA、Cisco这些玩家带到了游戏中。Red Hat MRG提案中的MRG消息是 Apache Qpid项目的一个实现,也是其核心的贡献者。LShift和CohesiveFT正在共同开发 RabbitMQ,这是一个“完整而且高度可靠的企业消息系统”,可用来构建一个AMQP网络,或用来加强一个已定制的网络。 来自iMatix的 OpenAMQ是另一个可用的AMQP实现产品。OpenAMQ被描述为一种“为你提供框架”的产品,“在该框架上,可以建立使用消息通讯的分布式商业应用”。
尽管有这一势头,但仍有人反对AMQP。Lustratus研究所(长期由IBM领导)就 不准备在2007年搭乘AMQP的列车,他们说:
保证消息几乎都通过公司关键任务操作的主要部分定义。如果它们不关键,那么保证传输也不会如此重要。所以,AMQP的‘命喉’在哪里?当它失败的时候,你该转向谁来淘汰你的主要在线系统?而且回到测试问题,谁会为涉及压力测试和性能调优的庞大开支进行投资,来保证AMQP能满足其应该有的需要呢?
Jean-Louis Seguineau谈到了AMQP为什么是一个迟到的玩家,而 XMPP PubSub早已参与了:
XMPP PubSub扩展已经处理了这些特性中的很多个。持久节点发挥着AMQP存储转发队列的作用,即时节点可用于满足AMQP队列的需求。但AMQP在明确使用消息属性来实现基于内容的路由方面取得了进展。XMPP并没有提供类似的方式,来明确界定基于内容的路由,因为PubSub扩展将该决定权留给了实现。
CohesiveFT的 Alexis Richardson和RedHat的 Carl Trieloff对AMQP有不同的想法。在与Gould一起的采访中,两个人都谈了他们对AMQP未来之路的理解。Richardson指出,AMQP可以成为一个因特网协议,来处理“HTTP和SMTP目前处理得很糟糕的事情”。在他看来,AMQP处理业务需求:

在业务网络中,你需要信任,需要事务完整性。输入的东西要和输出的东西一样。你需要智能路由和多拓扑结构,你要能处理流量、完成服务器到服务器的联盟。你还需要供应商和实现之间完全的互操作性。这一切都是处理事务性业务消息所做的事情,也正是AMQP所提供的。

Trieloff谈到了AMQP互操作性的进展,说道:“我们的经验一直认为实现间的互操作性正不断的变得更好,因为规范正越来越好,不明确性越来越少,而且开发人员都非常努力地在跟踪规范。我认为你需要对互操作性有非常务实的态度。”
AMQP可能并不打算取代你目前的消息中间件,但它正越来越相当于消息中间件,如果你正在构建或是增强你的消息中间件,AMQP还是值得关注一下。
查看英文原文: Is AMQP on the way to providing real business interoperability?

你可能感兴趣的:(AMQP准备提供真正的业务互操作吗?)