Straight-forward WCF duplex communication over MSMQ?

My friend Mike Taulty has recently posted a cool post about his attempt to create a WCF extension to leverage the duplex programming model over MSMQ.

This is a really interesting area (and of course has a huge potential) and at thinktecture labs I and Buddhike spent a great deal of time for research on this very topic.
On our way to a solution we came across exactly the same issues that Mike points out in his post. And it's kind of funny that the solution he's giving was the one came to our heads at the first place too.

Although it's a very decent attempt, this has a major architectural flaw because of MSMQ's inherent asynchronous and decoupled model and the handshaking nature of the RM protocol. Essentially the issue comes up because of using the reliable sessions channel for adding the ReplyTo addressing header to the messages. The Reliable Messaging protocol is a kind of a handshaking protocol which enforces the exchange of some protocol level messages (CreateSequence, ACK etc.) before the actual message exchange takes place.

On the other side, one of the biggest advantages of using MSMQ for messaging in your application is you can make sure that your application will work regardless of the availability of the services and clients (clients can send messages without the services being online and vice versa).
This nature of MSMQ stands in our way if we try to use RM/RS channel for adding ReplyTo headers. For example, if you start Mike's client without starting the service and try to send a message the client will end up with a timeout exception because when the client sends the message, the RS channel first tries to exchange the protocol level messages required to establish the reliable session. Since the service is not running and thus there is no RS channel up on the service end these protocol level messages will be clogged in the server's incoming queue and the RS channel will fail with a timeout exception since it doesn't get the expected replies (e.g. CreateSequenceResponse) on time from the service side RS channel.

We actually implemented solution for this with a custom channel for writing the ReplyTo header which we gonna publish quite soon (cross fingers!).
However there are further issues holding high prios in our research areas. For example, handling sessions in the MSMQ world seems really tricky (and you might yell at us: Well, why would I want it anyway...? Well.). Typically in WCF, the session termination is initiated by the client either by exchanging the terminate messages/message headers or adding the necessary framing if the session is implemented at the transport level. However, we cannot do this because of MSMQ's nature. For example, it might be a fact that an application uses MSMQ to decouple communication because the service takes too long to process a message. If then the client terminates the session while the service is still processing the request the service would not be able to callback the client in the usual way. In our opinion there are some limiting facts (or maybe areas we haven't hacked yet) in WCF when it comes to persisting the channel state.

We are in pursuit to make the current solution we have more complete and better.

Comments

[Mike]

Thanks for the follow up, makes a lot of sense. I'm still really puzzled as to why when I configure the client to have a listen address and send a message from that client to a service the message doesn't get a ReplyTo header. It seems weird to me to have to switch on RM just to get a ReplyTo address. Any thoughts there as to why using a duplex channel doesn't just put a ReplyTo into the outgoing message without having to switch on RM? Clearly, putting RM on isn't really the answer like you explain here.

[Christian Weyer]

By adding a CompositeDuplexChannel we ask the WCF runtime that it should create a ClientRuntime on the service side (which is required to call back the client) and the client side will have a DispatchRuntime (which is required to receive the callbacks from the service). So we inform WCF that we need this behavior by adding the CompsiteDuplexBindingElement to our binding. However, in order to make sessions work we actually need some kind of session (at the end of the day sessions need some sort of a logical connection). So essentially but not necessarily we can use RS/RM for that matter (e.g. In WsDualHttp binding sessions mean RM and it uses the RM binding element). If RM is creating problems, of course you are free to create your own channel to add the necessary addressing headers required for your messaging scenario.

[Slashene]

here a solution to avoid using reliable session http://msmqduplexsample.codeplex.com/