I saw that Jesus Rodriguez talked about the forwarding service that was included in the Dublin PDC preview so I thought I'd talk a little bit about what motivated the creation of this service and how I think it might be used.
The idea of shipping a general-purpose router with WCF is something that we've tossed around for a long time. It's relatively common when building distributed applications to need application-level routing. Having a router included in WCF would allow people to include a router as a building block in their applications without forcing everyone to write the routing logic themselves. Although a router is conceptually simple, there's some tricky logic needed when routing certain kinds of messages, particularly if you want to support concepts such as sessions. It also takes a certain level of sophistication to build an asynchronous router implementation so that you can use the router in high-scale and high-throughput scenarios.
Putting a router into the product for Indigo ended up not happening. However, we did get to ship a simple router implementation as the intermediary router sample in the SDK. The code for that router sample originally came from a partner demo that Kenny Wolf put together. We later decided to convert the code into a sample and wrote the introductory readme to explain how the router worked.
After Indigo shipped I still wanted to find some way of including a router in the product in the future. There were a few requirements that I had in mind for what it meant to be a high-quality application-level router.
The forwarding service that was included in the PDC preview hasn't met all of these requirements yet but I think it's complete enough that you can get a good sense of how a canned router service might be used. Next time I'll continue describing the capabilities of the forwarding service and what it might look like when it's done.
What do you mean by "single source"? Multiple logical and physical sources is a very common requirement for application message routing.
Hi David,
Single source-multiple destination means that a single message send can lead to several messages being delivered. For example, think of pub-sub systems that deliver a message to multiple subscribers. There may be more than one publisher (message sender).
ASP.NET Get Primary key on Row Command (GridView) [Via: aghausman12 ] Alternate way to select ASP.NET...
Link Listing - January 9, 2009
As someone who is having to implement this in a production scenario, I'd distance myself from this thing until it's been worked on a little more.
Hi Jason,
Is there anything in particular that you're worried about?
The duplex binding doesn't work with buffered responses for large files. Took me a long time to figure out (read, "I invested a not-insignificant amount of time trying to figure out where the problem is") what was going wrong and switch to streamed rather than buffered. Though I am certain I could have modified the code for the router to work with the buffered response, it was easier to switch the method to streamed rather than buffered.
My sneaking suspicion is that it will work just fine for the majority of cases but that it just hasn't been tested in enough scenarios to make it viable to promote without getting tied to supporting each custom scenario.
Are you referring to the Microsoft.ProcessServer.Messaging.ForwardingService on the VPC? If you can send me the configuration you were trying sometime, I will pass it along since buffered duplex works as far as I know.