The router container uses HTTP endpoints externally to interact with consumers, and MSMQ queues internally to talk to the service providers. This gives fewer queues to manage and monitor, and the consumers need not know anything about MSMQ.
The message forwarding ChannelFactory is cached for best performance. Read more about Channel and ChannelFactory caching in Wenlong Dong's post Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices.
Some useful resources related to making this router work:
- MSDN mag articles "Building a WCF router" part 1 and part 2
- Article series "MSMQ, WCF and IIS: Getting them to play nice" part 1, part 2 and part 3
- MSMQ activation of WAS
- Poison message handling in MSMQ 4.0 (and in MSMQ 3.0)
- NetMsmqBinding dead letter queues
- Correctly disposing WCF channels: Dispose extension method
- Really disabling the Visual Studio WCF Service Host, look for the <FlavorProperties/AutoStart> element
<add key="targetQueueName" value=".\private$\ServiceModelSamples/service.svc" />
Failure to adhere to this convention will prevent messages added to the queue from automatically activating the WAS-hosted WCF service. Also ensure that the WAS app-pool identity has access rights on the queues.
Download the router example code here. The code is provided 'as-is' with no warranties and confers no rights. This example requires Windows Process Activation Service (Vista/WinServer2008), MSMQ 4.0 and .NET 3.0 WCF Non-HTTP Activation to be installed.