Welcome to MSDN Blogs Sign in | Join | Help

Forwarding Service, Part 1

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.

  • Single source, multiple destination routing
  • Works with all different kinds of bindings, channel shapes, and message shapes
  • Low latency and memory overhead
  • Routing decision based on any part of the message content
  • Supports advanced messaging features, such as sessions and transactions
  • Transforms channels and messages based on the routing decision
  • Copes with delivery failures while routing
  • Requires no code to add a router to an application

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.

Published Monday, January 05, 2009 5:00 AM by Nicholas Allen
Filed under: ,

Comments

Monday, January 05, 2009 6:28 PM by David Nelson

# re: Forwarding Service, Part 1

What do you mean by "single source"? Multiple logical and physical sources is a very common requirement for application message routing.

Tuesday, January 06, 2009 7:16 PM by Nicholas Allen

# re: Forwarding Service, Part 1

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).

Friday, January 09, 2009 7:33 AM by Christopher Steen

# Link Listing - January 9, 2009

ASP.NET Get Primary key on Row Command (GridView) [Via: aghausman12 ] Alternate way to select ASP.NET...

Friday, January 09, 2009 7:34 AM by Christopher Steen

# Link Listing - January 9, 2009

Link Listing - January 9, 2009

Friday, January 09, 2009 11:04 AM by JH

# re: Forwarding Service, Part 1

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.

Friday, January 09, 2009 2:50 PM by Nicholas Allen

# re: Forwarding Service, Part 1

Hi Jason,

Is there anything in particular that you're worried about?

Wednesday, January 14, 2009 10:51 AM by JH

# re: Forwarding Service, Part 1

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.

Thursday, January 15, 2009 8:35 AM by Nicholas Allen

# re: Forwarding Service, Part 1

Hi Jason,

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.

New Comments to this post are disabled
 
Page view tracker