All things queued - Integrating Indigo queued applications with Microsoft Message Queue

  • Article

In my last post I delved in depth about how Indigo Integrates with all other existing distributed stacks and how it enables interop with systems from other vendors. I will now start a series of posts starting with this digging deeper into each of those integration and interop points.

In this post I am going to talk about Indigo queuing and how it is integrated with Microsoft Message Queue (MSMQ).

Note: I assume that you have some basic knowledge on the workings of MSMQ. If you don't please feel free to reply to the post with your questions and I will clarify.

Microsoft Message Queue(MSMQ) is the enterprise queuing infrastructure from Microsoft. Indigo is the next generation SOA based distributed programming model from Microsoft. So the marriage between these two technologies is natural.

Indigo supports integration with MSMQ using two transport channel bindings

  • msmqIntegration binding
  • netProfileMsmq binding

MsmqIntegration channel

The msmqIntegration binding should be used in scenarios where you have an existing MSMQ application(sender or receiver) that you want to use to send/receive messages to a new Indigo queued application. When used in an Indigo queued application the MsmqIntegration channel binding performs the transformation between an Indigo message and an Msmq message to enable integration between the two applications.

For example if you have an MSMQ sender app that sends messages to a queue and you write a new Indigo queued service that receives and processes the message using the MsmqIntegration channel, the channel will convert the MSMQ message into an Indigo message before passing it to the Indigo pipeline for dispatching.

What goes on the wire is an MSMQ message that is digestible by older MSMQ applications.

NetProfileMsmq channel

The NetprofileMsmq binding should be used in scenarios where you have Indigo client and service applications and you want to use a queue as conduit for the communication between them. In this case the Indigo SOAP message is stuffed into an MSMQ message and transported over MSMQ infrastructure from the client to a queue. When the Indigo service receives the message from a queue the netProfileMsmq channel extracts the Indigo SOAP message from the MSMQ message and passes it to the Indigo pipeline for dispatching.

You can think of the Indigo Queued programming model as a new API for MSMQ. If you are familiar with COM+ Queued components(QC) this should be very similar (but much more robust).

The Indigo Queued programming model has the following advantages over existing MSMQ APIs.

  • You don't have to write any MSMQ specific plumbing code in your client or service application. On the service side you have to declare your service contract, implement it, select one of the above channels depending on your scenario and tell the service what queue to listen/send to by specifying the queue address in the configuration file of the service and that's it. The Channels will take care of MSMQ plumbing. You concentrate more on your business logic. You dont have to write any complex listener code for listening on the queues and dispatching the message. The channel acts as a listener and a proxy for you.
  • Indigo Queuing programming model has the poison message handling feature. A message is deemed poisonous after several attempts to process the message have failed due to some reason or the other (like malformed message). The failure might be permanent or transient. The poison message will prevent processing of other messages in the queue. There are settings in the channel which allows you to control how many times you want to try processing the message before moving it to a retry queue, after how long you want to bring the message from the retry queue back to the main queue to attempt processing again and what is the maximum number of retries after which the message is dumped into a final resting queue (poison queue). This feature does not exist in MSMQ today. Poison message is a very common problem and I bet you are writing some kind of code to handle this today in your application.
  • MSMQ provides Encryption and Authentication security features at the transport level. However MSMQ does not provide any Application to Application authentication or encryption feature. Moreover MSMQ security is dependant on Active directory which can be painful and will not work if the computer is not joined to an Active directory domain. Indigo queuing on the other hand layers SOAP security on top of MSMQ. Indigo Queued programming model provides app to app authentication and encryption. It does not require Active directory. Indigo queued programming model also supports enabling the MSMQ transport level security through the configuration settings in the channel.

The bottom line is MSMQ is getting better and brighter with the addition of Indigo queuing.

If you are an SQL Server 2005 SQL Service Broker (SSB) fan hold your breath. There will be an Indigo SSB Queued channel soon that will enable you to write Indigo queued applications that can use SSB queues. The good news is your Client and service code will have minimal or no changes when you switch from the MSMQ transport channels to the SSB channel. All you should have to do is to select the Indigo SSB channel in your configuration file instead of the MSMQ channel.

That is the beauty of Indigo! It provides a programming model that is truly protocol and transport agnostic.

-AnandRaj