Remoting,WCF and MSMQ for CatTask

CatTask v2009: some investigated communication technologies

Please be noticed that these technologies are discussed in the context of CatTask.

MSMQ

Although we can use WCF to send MSMQ messages, I don't group them to one category because the criteria here is the directness of communication.

With MSMQ, there is no direct communication between the two CatTasks. One will send data (messages) to a queue, the others will monitor the queue, receive messages and process them.

- Pros:

• The constraint between the sender and the receiver applications are very loose (loose-coupling). Both the sender and the receiver work with the queue; one doesn't need to care about the other.
• Writing unittests, including isolation test and integration test, is easier (than remoting or WCF).

- Cons:

• We don't have experience in using MSMQ. Whether it can be used for CatTask or not?
• MSMQ is designed for distributed systems, where the term which you usually hear when a message is sent is "Fire and Forget". Checking if a message is delivered (comes to a *remote* destination queue) is a pain.

In fact, this is the first technology I used (or tried to use :P) to develop the communication module. Everything seemed to be fine until I found out that if I send a message to a non-existing remotequeue, or there is a network problem when the message tries to reach it, I will get no exception (BTW, you will get it in the case of a local queue). I thought I would get the exception because MSDN didn't tell me that I wouldn't. Stupid me!

The best way we can use to check for such undelivered messages is to monitor a special local administrative queue. Hold on a sec.!:

1. I was developing a message producer (sender).
2. To check for messages delivery, I needed to make a message consumers for the admin queue. Yeah, a consumer for a producer.
3. Sending a message and checking for it are done asynchronously.

In summary, I was building the module from scratch and the amount of code which I needed to write and maintain was growing rapidly and became more complicated! I had to admit that my coding skill and my very little MSMQ experience didn't allow me to make good code for such requirements.

WCF

With WCF, CatTask instances contact to each others directly using known configured port.

- Pros:

• We know for sure that they meet our requirements, i.e. they can be used to develope the new CatTask.
• Experience in using remoting for the current CatTaskService may be useful.

- Cons (in compared to MSMQ):

• I did make some real code (not finished yet) and wrote unittest for them. What I don't like about this (in compared to MSMQ) is that when I was writing client code (sender), I had to though about the server one. If the interface was changed, we would need to regenerate the proxy file, change both client code and server code. Be noticed that I wanted to use event-based asynchronous model, so I had no choice but generating a proxy using the provided utility tool.

Btw, MSDN has a lots documents for WCF. In my opinion, they are over detailed and too academic. Some of them are silly :|. Follow it will make you crazy. Although I just took a first step into WCF, what I found out is rather useful for WCF's newbies :D Hope that we will have a topic about it.

Remoting

Remoting brings to us nothing better than WCF. In addition, it is older and more difficult to use.

What should we choose?

At first, I tried to use MSMQ. However, the problem which I just stated above forced me to come to WCF. While I was in the middle of making the Local Dispatcher with WCF (actually, just a few simple classes and unittests), I got an assignment from Dennis to investigate the Rhino Service Bus, which is a MSMQ ESB to figure out if it can be used for our CatTask.

Shortly speaking, we are designing the communication module using RSB right now.