Does anyone have any architectural information for MSMQ?
I am trying to decide if MSMQ is the right tool for communication between our application and a third party web service that we are currently communicating with directly. We want to break it down so that if the service goes down, life can go on as usual.
I can't seem to find anything other than the usual MS bundle stating that this is the best thing and solution to all your problems, etc. etc. It would be very helpful if I could find some information that was somewhere between marketing fluff and the API - a diagram of the architecture of the components and how they integrate with each other, and more importantly, how I integrate with them.
Maybe I'm just looking for information in the wrong places, so if someone can point me in the right direction, I would appreciate it.
source to share
A typical MSMQ architecture will have three parts ...
- Message Queue - This will be on one of your servers. You will need to set the MSMQ bit and create your queue.
- Customer. Your client will insert messages into the queue. I am assuming you are using .NET. If so, most of what you want will be located in the System.Messaging namespace.
- Windows Service - This will also run on a server, possibly on the same server as your queue. His job was to monitor the queue, process messages as they arrived, process to make sure an external service is available, and probably make some entries.
Here's an article that should get more detailed and give you some code examples.
source to share
MSMQ is an implementation of message queuing, just like websphere mq and many other systems. When exploring high-level concepts and architecture, I would suggest reading about message queues and how they apply in a disconnected scenario. I can highly recommend Enterprise Application Architecture Patterns . For specific examples on msmq check out Pro MSMQ: Microsoft Message Queuing Programming it doesn't highlight specific information, but it groups it better then most resources are available on the internet. This Hello World with MSMQ article will give you a good overview of what it entails and is easy to do on a development system.
source to share
If you are calling a remote web service from your application, it makes sense to use a queue to decouple application processing from the remote system. By abstracting communication through messaging and providing a gateway service that is responsible for communicating with the web service, you isolate your application from web service latency and create fault tolerance in the project by reducing the use of request / response within your application (since messaging is asynchronous by default - you deal with it from the front).
There are frameworks for .NET that can make this much easier (like MassTransit or NServiceBus).
You can also check out SOA Templates (from Arnon Rotem-Gal-Oz, Manning Press, at MEAP) and Enterprise Integration Templates (Hohpe, Woolf), the latter of which is essential for anyone creating a messaging system.
source to share