I spent April 1 in San Diego meeting many of the AMQP Project Management Committee (PMC) members and people in various stages of adopting AMQP in new projects. Despite the date, it was no joke - people are learning about the freedom in this new business messaging technology and jumping on board in increasing numbers.

Although I'm still psyched up from the technology overview delivered by J.P. Morgan Chase's John O'Hara, the bulk of the time spent in tech-talk sessions focused on use-cases and the design perspectives and goals as a whole, as well as details of the changes to the protocol coming in version 1.0.

The most visible and structural changes are:

• Exchanges are out; Links are in. AMQP up to now has used the Exchange as the message routing agent within a virtual host. Applications create exchanges and bind them to queues with a binding key. Messages have associated routing keys used by exchanges to route messages to queues based on various matches between routing keys and binding keys. AMQP defined some standard types of exchange (direct, for exact key matches; topic, for pub-sub-type pattern matches; and fanout for delivery to all bound queues regardless of the message routing key). Implementations offered other specialized exchange types as well. For example, Red Hat developed an XML exchange that made routing decisions based on XML content.
  
  In AMQP 1.0, the exchange concept is gone. Applications interact only with queues that have well-known names. A new concept, Link, moves messages between queues and/or applications. A Link contains routing and predicate logic. The new scheme brings the following benefits:

• Services. A Service is a mini application inside the broker. For example, the previous management framework will become a service inside the broker. Clients interact with services using, of course, messages. Interbroker communication will also very likely be implemented using services. This could be used to add many new capabilities such as message bridging between AMQP and other message systems as well.

So when will these new capabilities come to an AMQP implementation near you? That's all being worked out now. It'll probably be later this year. As things progress I'll have more visibility into the Apache Qpid implementation than I will for others, so for questions on Qpid in particular, please let me know.

If you are working on (or will soon) a system that can benefit from message-oriented middleware technology and want to chat for a few minutes about whether or not AMQP may be beneficial, please email or call me any time.

Have you ever wondered if you are taking best advantage of ACE's power and flexibility? Ever have a question you couldn't find the answer to? How about a bug?

Have any of these problems slowed down your project, or even delayed a deadline?

If you run into a situation in the future where you may want ACE support, it would be great if you already knew the best provider for you and your team. To do that, you have to start looking now. To evaluate the best provider for you, you can start with our new white paper "8 Essential Questions to Ask Your Potential ACE Support Service Provider". Download your copy today at http://www.riverace.com/support8qs.htm.