Advanced Message Queuing Protocol (AMQP) and Microsoft BizTalk Server

Recently I've read the AMQP (Advanced Message Queuing Protocol specification http://www.amqp.org/). Obviously this is the different protocol level then BizTalk messaging system but...

The AMQP specification let me get some thoughts.

And take in mind this topic is not a critic of AMQP or BizTalk, not at all. And this is not a comparing them, maybe sometimes ;)

After discussion with Tomas Restrepo http://www.winterdom.com/weblog/ I've made several changes in the text. Thanks Tomas!

AMQP:


Thoughts:
 
  •  AMQP does not include the "Transformation" of the messages. Otherway the paradigm of the BizTalk is "All outer formats are transformed to/from the unified (Xml) internal format." I think the "adapter" and "pipeline" and "map" paradigms in the BizTalk are quite productive and helpful. They can be implied in the Exchange but anyway AMQP does not have the transformation API. All implementations of transformation API will be out of standard.
     
  • AMQP distinguish the different queues. The queues deliver the messages to the consumers. In BizTalk this is responsibility of the send ports. Inside BizTalk all queues are unified and acts as one queue. We cannot distinguish different queues by API or UI.
  • In AMQP the "consumer-cardinality" is the feature of the Queue or it seems so. I mean the Queue can have one consumer or many. In BizTalk the queue (MessageBox + agents) doesn’t care about consumers, it is the feature of Subscription agent (which works like the Exchange in AMQP).
  • In AMQP the paradigm is "routing --> many queues".
    In BizTalk the paradigm is "transformation --> one queue --> routing --> transformation".
    (Or is it "transformation --> routing --> many queues --> transformation"? We don't know, because the BizTalk try to hide the queue implementation details.)


What is interesting in AMQP:
 
  •  The File Content class. It works as a message type to perform bulk file transfer. It is the case when we do not transform the message only route it and all routing data are outside the message (in binding parameters, for example). In BizTalk we have to do a lot of work only to transfer the bulk file through the system. This is the continual case too. This is the problem of the BizTalk: it always pretend we always have to "route + transform" the messages, no such case as "route, do not transform" messages.
  •  The Stream Content class. It implements the order delivering.
  •  The "Topics" Subscription. It uses the wild-cards for routing, like "STOK.USD.*" against routing parameter values as "STOK.USD.NYSE".
    Can we use the wild-cards in the Filters in BizTalk? No. But I think there is a simple implementation of the Topic subscription and much more if we could use the custom filters in BizTalk. Why do not add the new feature to BizTalk the "Users predicate" as it implemented for Functoids with Script functoids, for example?
  •  The message priority in the Queue.
  •  The processing of the messages with zero size body.
  •  The Standard for Error handling. In BizTalk we have many places where we got the errors and there are no strict rules. For example different adapters have different error handling when we sometimes get exceptions, sometimes the suspended messages. It is a "gray area" in BizTalk.

Please, feel free to critique and comments.

 

 

 

Print | posted on Thursday, January 11, 2007 2:08 PM

Feedback

No comments posted yet.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: