|
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.
|