View source for Remoting,WCF and MSMQ for CatTask

= CatTask v2009:&nbsp;some investigated communication technologies =

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

== Remoting and WCF <br> ==

Remoting and WCF are rather the same in term of how we send data from one CatTask to the another: CatTask01, for example, sends data '''''directly''' ''to CatTask02 using known configured port. However, WCF is newer and easier to use than remoting. 

- Pros: 

*We can sure that they meet our requirements, i.e. they can be used to develope the new CatTask.

- Cons:

*Writing stable cross domain code is not an easy job. We had some annoying and strange remoting bugs with the current CatTaskService.
*

== MSMQ <br> ==

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: 

+ With MSQM, 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 on 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. 

== What should we choose? <br> ==

A brief history&nbsp;:D: 

1. At first, I tried to use MSMQ. Everything seemed to be fine until I found out that if I send a message to a non-existing *remote* queue, I will get no exception (BTW, you will it in the case of a local queue). MSDN document of the Send method doesn't tell me about this!!! There is a way to check for such undelivered messages: monitoring an special local administrative queue. Yeah, I ran into a big problem because I was going to write a messages consumer to use inside a messages producer. I'm building the module from scratch and the amount of code which I need to write and maintain is growing rapidly! 

2. Ok, so coming back to WCF seems to be a good choice. 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. 

3. MSMQ again!!! I got an assignment from Dennis to investigate the Rhino Service Bus to figure out if it can be used for our CatTask. The framework looks promising. The bus is well unittested and provides a lot of functions we need. In other words, by using it I won't need to write so much code as I mentioned in history #1. <br>