Forwarding Service, Part 2

The primary advantage of having a forwarding service that comes with WCF is that it enables you to add a router to your application without having to write any code. I think that many application developers could write the routing logic they need into their applications given enough time spent working on it. However, why spend the time writing code when in almost every case using a canned routing service is going to get the job done faster.

The forwarding service that went out with PDC isn't exactly how I'd expect the configuration of a canned routing service to look, but it's relatively close. All of the major pieces are in place. I'd expect the process of writing the configuration to be more heavily driven by tools though rather than by writing XML.

There is a WCF service type for a routing service that routes messages from one inbound endpoint to one or more outbound endpoints. In the PDC release that service type is Microsoft.ProcessServer.Messaging.ForwardingService. The service can be hosted at an address you choose and with whatever binding you'd like through the standard mechanism of declaring service endpoints. Like any WCF service, you might provide multiple inbound endpoints to allow for different ways of accessing the same service.

We provide the set of contract classes that describes each of the possible shapes your binding might support. This allows us to disambiguate the particular channel shape that you want the endpoint to use since your binding might build different channels depending on the chosen shape. Since these contract classes describe the channel shape rather than the application contract, the contract works regardless of the particular operations or message you use with the destination service.

The outbound endpoints are standard WCF client endpoints. Again, you can choose whatever addresses and bindings you'd like for these client endpoints to point at. By choosing different bindings for the inbound and outbound endpoints, you've built a router that also bridges between different protocols. The outbound contract is a wildcard contract to indicate that you don't care what application contract these messages are for.

Finally, we provide a way to describe the routing table. Each route in the routing table associates a filter with one of the outbound endpoints. You've seen these filters before. The same filters that power content-based correlation also power content-based routing.

Comments

• Anonymous
  January 08, 2009
  PingBack from http://www.codedstyle.com/forwarding-service-part-2/

• Anonymous
  January 08, 2009
  ASP.NET Get Primary key on Row Command (GridView) [Via: aghausman12 ] Alternate way to select ASP.NET...

• Anonymous
  January 08, 2009
  Link Listing - January 9, 2009

• Anonymous
  January 09, 2009
  I blogged a sample of how to use the Fwd Service with XPath Filters http://weblogs.asp.net/gsusx/archive/2008/12/11/implementing-content-based-routing-using-the-windows-application-server-dublin-forwarding-service.aspx

• Anonymous
  January 13, 2009
  Unfortunately the sample only offers point-to-point messaging (i.e. single destination); there is no way to achieve publish/subscribe without significant modification. It is disappointing that almost three years after WCF released its first CTP, there is still no quality pub/sub framework available. It makes using WCF in all but the most simple environments a non-starter.

• Anonymous
  January 14, 2009
  Hi David, If by sample you're referring to the router sample in the SDK, that's different than the forwarding service in the Dublin VPC.  I don't expect the SDK sample to ever include much functionality- that would take away from the demonstration.  The forwarding service issues one send for each matching filter so you can use the filters as your subscription table.

• Anonymous
  January 15, 2009
  Yes, I am referring to the SDK sample you linked to in your first post on the Forwarding Service. I was unaware that there was a difference between that sample and the sample you were discussing.