Friday, November 20, 2009

Routing and service discovery in WCF 4.0

This year, the PDC 2009 lasts only four days (if you include the preconference day) so today I tried to attend as many sessions as possible. It's amazing to see how fast this week passed by. And I don't know how Microsoft does it, but this PDC has been full of novelties and amazing moments (and with that I'm not even mentioning all the social aspects of such a conference).

For instance, when I decided to attend a WCF 4.0 session, I didn't expect to see so many improvements and innovations, First of all, they've significantly reduced the amount of configuration needed to get your services running. Default bindings and behaviors, inheritance of bindings and behaviors, and listing services in the web.config rather than individual .svc files all make configuration easier. Another improvement is the advanced health monitoring and tracing functionality that they’ve integrated in the IIS manager. This takes the form of a dashboard providing live information on the WCF services running on a server, including extensive visualization and deep diving features for analyzing what is really going on in your service. So you no longer need to fiddle with configuration settings in the web.config to get some tracing.

Another new feature is service discovery. I'm not really sure what happened with the UDDI protocol, but in WCF 4.0 they’ve introduced new behaviors that will make your service discoverable through an UDP multi-cast network package. Using the new DynamicEndPoint class you can simply provide the contract definition of the service you're looking for, and WCF will look for a running service on the network. Really cool. And it supports both this kind of ad-hoc discovery as well as managed discovery facilitated by a dedicated discovery service running somewhere in your company.

However, the most impressive feature of WCF 4.0 is the built-in routing service that you can host just like any other service. Its feature set includes a routing engine that uses customizable filters to determine how to route what service operations to which service. It also has built-in support for bridging different transport/bindings, different SOAP versions, and even handle different authentication mechanisms. In addition to that, it can automatically reroute messages to an alternate endpoint if the preferred one is not available le. And finally, even though I'm against distributed transactions, the transaction scope will flow over the routed channel.