剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
AMQP准备提供真正的业务互操作吗？
作者 Steven Robbins译者 王丽娟 发布于 2008年8月27日 下午10时36分
高级消息队列协议（Advanced Message Queuing Protocol，即AMQP）来自于JPMorgan内部，这归功于John O'Hara。但John O'Hara的设想不仅仅是内部处理事情的一种新方式。围绕于此的标准和开源技术势头渐劲。Jeff Gould和其他人阐释了AMQP来于何处、谁在驱动它、以及它可能往何处发展。AMQP规范的贡献者之一IONA科技公司发表了一份简要说明，说明AMQP是什么，以及为什么要进行。AMQP是
- 一组明确定义的消息功能，被称为“高级消息队列协议（AMQP模型）”。AMQP模型由一组定义良好的组件组成，这些组件在一个消息代理服务中路由和存储消息，还有一组将这些组件绑定到一起的简单规则。
- 一个网络线路级协议，可以让客户端应用与消息代理对话，与AMQP模型实现交互。
Gould接着指出，是O'Hara在探求一个真正将AMQP推出银行、走向更广阔世界的开放标准。正是开发标准将Red Hat、Apache、WSO2、IONA、Cisco这些玩家带到了游戏中。Red Hat MRG提案中的MRG消息是Apache Qpid项目的一个实现，也是其核心的贡献者。LShift和CohesiveFT正在共同开发RabbitMQ，这是一个“完整而且高度可靠的企业消息系统”，可用来构建一个AMQP网络，或用来加强一个已定制的网络。来自iMatix的OpenAMQ是另一个可用的AMQP实现产品。OpenAMQ被描述为一种“为你提供框架”的产品，“在该框架上，可以建立使用消息通讯的分布式商业应用”。O’Hara对AMQP的计划有着雄心壮志。从一开始，他就希望新的协议能与高端消息中间件（MOM）的功能相竞争。它之前必须处理所有主要的用例，包括队列式存储转发消息，Tibco风格的发布和订阅，还有可靠的文件传输。协议必须能够支持任何种类的消息，但重点是比起文本来，二进制格式要更有效率，因为在应用到应用的消息中，人们的可读性并不是最重要的关注点。
尽管有这一势头，但仍有人反对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处理业务需求：
Trieloff谈到了AMQP互操作性的进展，说道：“我们的经验一直认为实现间的互操作性正不断的变得更好，因为规范正越来越好，不明确性越来越少，而且开发人员都非常努力地在跟踪规范。我认为你需要对互操作性有非常务实的态度。”在业务网络中，你需要信任，需要事务完整性。输入的东西要和输出的东西一样。你需要智能路由和多拓扑结构，你要能处理流量、完成服务器到服务器的联盟。你还需要供应商和实现之间完全的互操作性。这一切都是处理事务性业务消息所做的事情，也正是AMQP所提供的。
AMQP可能并不打算取代你目前的消息中间件，但它正越来越相当于消息中间件，如果你正在构建或是增强你的消息中间件，AMQP还是值得关注一下。
查看英文原文：Is AMQP on the way to providing real business interoperability?
.gif)
没有回复
回复