MSMQ: Net vs Integration

Why are there two MSMQ bindings?

This is an easy question to answer: there are two bindings for MSMQ because they do different things. Go ahead and take a look at each of the bindings. The NetMsmqBinding looks like a normal binding with an MSMQ transport, binary message encoder, and all of the normal features that you'd expect to find on a binding. On top of that, there a whole bunch of features that are specific to configuring a queue, like dead letter handling.

The MsmqIntegrationBinding on the other hand looks totally different. Ok, the integration binding doesn't actually look all that different. All of the queue-specific features are shared between the two and that makes up a large portion of each of the bindings. However, the rest of the integration binding looks quite unusual compared to all of the standard bindings.

• For instance, everything is wrapped into a single MSMQ integration binding element.
• There's no message encoder or configuration of message features.
• Addressing for messages with this binding element uses a very particular syntax.
• There's no support for message security.
• Actually, there's almost no support for composing the MSMQ integration binding element with any other type of protocol channel binding element, not just security channels.
• You'll find that services using this binding are very limited in terms of contracts.

The MsmqIntegrationBinding is intended for use with existing, already-written native MSMQ applications. The NetMsmqBinding is a lot better to use but only works if you have WCF on both ends of the queue. Therefore, one of these is always the clear choice for your queuing scenario depending on what's on the other side. There's nothing stopping you from hosting separate endpoints for each of these bindings at the same time if you need communication with both native and WCF clients. However, the two endpoints need to be kept with separate queues because the messages are not compatible.

Next time: Serialization of Client Calls