A few days ago the AMQP spec was announced on TSS. I quickly downloaded the spec and I have some initial impressions.

#1: I think it’s unfortunate that the “AMQP” sounds too much like it has something to do with ActiveMQ which most folks abbreviate to AMQ, as in, “Have you downloaded AMQ 4?”. This along with the fact that AMQ and AMQP are both related technologies, the first is a mom provider and the second is a wire protocol for mom providers.

#2: This is nice spec. I like the client specified “binding” concepts introduced in this spec. Perhaps these concepts can be introduced in higher level APIs like JMS one day.

#3: It seems that one of the goals of the spec is for vendors to be able to interoperate with each other. I have got a feeling that specs like WS-Notification or STOMP have a better chance at accomplishing this. Binary wire protocols are hard to implement and I doubt there will be many implementations of it. If a good open source reference implementation becomes available then this would become more plausible.

#4: It does not go into details of how the content of the messages should be encoded. This effectively means that JMS implementations will not be able to interoperate using AMQP since different implementations would encodes the content of a JMS Message differently. Even for simple things like TextMessage, would they use UTF-8 or ASCII? And it gets even more complex for messages lke StreamMessage and MapMessage.

#5: I may be wrong, but it seems like messages are always sent asynchronously. In some cases the JMS spec requires messages to be sent synchronously. Perhaps transactions can be used to simulate a synchronous send, but wouldn’t that add substantial of overhead?