I really mean the word "lurches" that I used in the title of this post. I've been following the AMQP specification since the 0.8 version, and there have been more dramatic twists and turns in this than in an old Perry Mason novel. (In the latest twist, they seem to have dropped the very concept of an Exchange, a mainstay of previous versions).
I don't believe the latest version of the spec is available (I would dearly love to have a read), but the working group met recently in San Diego, and the materials presented are here.
My overall reactions are these:
1. We really do need an industry-standard messaging protocol to match the capabilities of proprietary products like IBM's MQ and TIBCO's EMS. These two vendors have built their hugely profitable businesses at the expense of customers who have nowhere else to go. The commoditisation that has lowered prices in other areas of distributed computing (TCP/IP for networking, HTTP for web, SMTP for email, etc.) has simply not occurred in enterprise messaging. AMQP aims to rectify that. All I can say is, "It's about time".
2. I note with amusement that Microsoft has joined the AMQP bandwagon. Nothing like a lack of market share to elicit good behaviour from Microsoft ;-)
3. As I said, I don't have access to the latest spec, but I know that an intermediate version had dropped support for streaming communications and file transfer. If these are still not part of the spec, I believe that's a huge mistake. An enterprise messaging protocol must natively support these significant aspects of distributed computing, otherwise the protocol as a whole will fail to pass muster in spite of its excellence in other areas.
4. I don't know what the AMQP Working Group is thinking, but I believe that the main competition for AMQP is not IBM and TIBCO but HTTP and REST. Whenever I talk to REST afficionados about AMQP, the response is a big ho-hum. "What can AMQP do that we can't already do with HTTP?" is the response. Asynchronous notification? Just use XMPP for that. Security? SSL is good enough. And so on. The AMQP Working Group should co-opt a particular breed of REST expert - one who understands the value of resource-orientation without being wedded to HTTP. I believe that if we can define an application protocol on top of the transport protocol that AMQP is (by usefully constraining it with special verbs, headers and status codes), we will have a more capable architectural style than REST, one which includes native support for event notification, end-to-end security, reliable message delivery, transactions, file transfer, streaming communications and process coordination. Rohit Khare's ARRESTED style can become a reality.
Is anyone listening?
I don't believe the latest version of the spec is available (I would dearly love to have a read), but the working group met recently in San Diego, and the materials presented are here.
My overall reactions are these:
1. We really do need an industry-standard messaging protocol to match the capabilities of proprietary products like IBM's MQ and TIBCO's EMS. These two vendors have built their hugely profitable businesses at the expense of customers who have nowhere else to go. The commoditisation that has lowered prices in other areas of distributed computing (TCP/IP for networking, HTTP for web, SMTP for email, etc.) has simply not occurred in enterprise messaging. AMQP aims to rectify that. All I can say is, "It's about time".
2. I note with amusement that Microsoft has joined the AMQP bandwagon. Nothing like a lack of market share to elicit good behaviour from Microsoft ;-)
3. As I said, I don't have access to the latest spec, but I know that an intermediate version had dropped support for streaming communications and file transfer. If these are still not part of the spec, I believe that's a huge mistake. An enterprise messaging protocol must natively support these significant aspects of distributed computing, otherwise the protocol as a whole will fail to pass muster in spite of its excellence in other areas.
4. I don't know what the AMQP Working Group is thinking, but I believe that the main competition for AMQP is not IBM and TIBCO but HTTP and REST. Whenever I talk to REST afficionados about AMQP, the response is a big ho-hum. "What can AMQP do that we can't already do with HTTP?" is the response. Asynchronous notification? Just use XMPP for that. Security? SSL is good enough. And so on. The AMQP Working Group should co-opt a particular breed of REST expert - one who understands the value of resource-orientation without being wedded to HTTP. I believe that if we can define an application protocol on top of the transport protocol that AMQP is (by usefully constraining it with special verbs, headers and status codes), we will have a more capable architectural style than REST, one which includes native support for event notification, end-to-end security, reliable message delivery, transactions, file transfer, streaming communications and process coordination. Rohit Khare's ARRESTED style can become a reality.
Is anyone listening?
2 comments:
It appears that restms may be an approach that proposes combining REST with AMQP:
http://www.restms.org/
stug23 said:
> It appears that restms may be an approach that proposes combining REST with AMQP.
I know about RestMS, and this is not what I had in mind. RestMS is a limousine that takes you to the tarmac where a World War I biplane is waiting for you. What I want to travel by is the First Class cabin of an A380 :-).
In other words, I want an end-to-end resource-oriented application protocol that is peer-to-peer rather than client/server. I don't want a resource-oriented interface to one endpoint, with the main wire protocol being a mere transport protocol.
I've tried explaining this view to a few people, but without much success.
Ganesh
Post a Comment