The alternative way to going Request/Response communication style is one-way asynchronous messaging. While at first this seems much harder, it is much more connected to the way you think of the processes than to technical issues.
Once you get used to modeling processes in asynchronous way you will discover that much of the processes happening in the enterprise or around you are naturally asynchronous.
Example
Let’s analyze something that is easy to touch – project development process itself (well simplified). Let’s model the process of releasing a build for testing in both ways (sync and async).
When the dev team happily ended features development they are trying to pass it to the QA team (at first assume no internal process automation in place).
Synchronous
The synchronous way is for the dev team lead to find QA team lead and tell him about the new build. If the QA lead is not on his working place, wait for it, or… throw an exception (to the higher level, which is probably management :)). QA team lead acknowledges that he is now aware of the build and dev team lead is able to proceed his work.
Asynchronous
Send an email.
As you can see the asynchronous way is easier to model and develop. Preserving this asynchronous nature in the application tends to greatly simplify the overall interaction. So the Project Builds Tracking (PBT) doesn’t need to create QA task when a new build is submitted. It just sends a message (BuildSubmitted, pay attention to the past tense as PBT already committed its transaction) to QA Task Tracking (QATT), so that it will be able to take its decision on how to handle this.
Pub/Sub
Well, at some point you may find that not only QATT needs the information about new builds, but the Bug Tracking system should also create the build and target versions. When going further you will discover that adding new systems requires PBT to send more and more messages. At this point it’s useful to stop thinking of them as a targeted messages, but rather generalize this interaction model.
One well known pattern for this is Publish/Subscribe (or Pub/Sub). There are number of systems that want to listen to events happening in PBT, all those Subscribe to certain PBT events. When the event occurs PBT Publishes it in a form of message sent too all subscribers. Pub/Sub logically decouples the systems, as the code doesn’t need to be modified to add new listeners.
Tools
Now, suppose you shifted your mind toward the world of asynchronous processes. One thing you may found you are lacking is an appropriate tool to make you concentrating on the processes, not the infrastructure.
There are plenty of tools that may serve your needs, I encourage you to look at which do fit better:
You may also try to build your own framework on top of WCF with MSMQ binding to understand the concept better.
I also encourage you to read Udi Dahan blog, who is author of NServiceBus and SOA guru.