基于.NET MSMQ的同步系统的体系结构

Question

I have a straightforward, existing ASP.NET MVC web solution. The server-based stuff writes information to a database. I am now going to integrate/synchronize this system with a number of other 3rd-party systems. I want to separate the integration processing from the existing core processing, leaving the existing system as untouched as possible.

My plan is as follows:

1. whenever a database write occurs on the core system server I will write a message to an MSMQ Queue.
2. an entirely separate server-based windows service will poll the MSMQ, look at the message and will write messages to one or more 'outbound' sync MSMQ queues.
3. other windows services will monitor the 'outbound' sync queues, and will talk to the 3rd-party systems as necessary, managing the outbound synchronization.

I have a couple of questions: Should I have a single windows service doing all this, or should I have several services, one central 'routing' one and one for each 3rd-party system? Should I use WCF for any of this. Does that buy me anything, given that the 'trigger' for writing to the initial queue is already 'happening' on a server-based process?

Thanks very much.

Answer 1

First, a separate windows service is always safer than any attempt to integrate this with your asp.net runtime.

Second, do not write anything by yourself. Use

http://code.google.com/p/masstransit/

It is straightforward and does everything you need. Reference the library from their nuget package, read some tutorials and you will love it.

Answer 2

To answer your questions:

Should I have a single windows service doing all this

Definitely not. What if you want to scale out the routing service, or relocate it?

Should I use WCF

If you have your heart set on msmq then the only advantage WCF gives you is it provides a convenient, proven way to design and host your service endpoints, and an alternative to mucking around in System.Messaging. I would say at this stage it doesn't matter that much.

Does that buy me anything

Not sure what you mean, but as Wiktor says in his post, you could chose not to use vanilla .Net or WCF and choose a service bus type framework such as masstransit or nservicebus.

The benefit here is it abstracts you away from the messaging sub-system so you could in theory move away from msmq in the future to rabbitmq or azure queues.