What is this blog all about?
So you stumbled onto some random blog on MSDN. In the first post the guy is already talking about some random Routing something. But what is that? What is this place and how did you get here? What's this all about?
Well, let's start off with the basics:
Windows Communications Foundation is Microsoft's platform for developing distributed/service oriented applications; client/service applications where the service side can be exposed as services, each with a specific business task, located in many different places. Similarly the clients can be located across the cloud or the enterprise and speak many different protocols over many different transports (SOAP 1.2 over TCP, JSON over REST/HTTP calls) as they contact the services to get work done. (A quick introduction to writing a WCF application is over here on MSDN.) These clients and services communicate via way of Messages; chunky units of information usually issued by a client for a particular service in order to give the service some data, ask that the service do some work, and/or provide the client with information. Initially these messages were always SOAP (though WCF has recently added a lot of REST capabilities). This gave WCF the benefit of being standards (WS-*) compliant in addition to serving as an excellent distributed, optionally asynchronous, communication platform. With WCF, Microsoft provided a great way to write service oriented applications so that you ended up with some number of services (depending on how you factored your app) that a client could call into into them from the same machine, the same enterprise network, or across the cloud. The framework model provided a lot of great flexibility, extensibility, and also worked to define a whole pile of defaults and usable collections of common settings to make it easier to get your distributed client-service applications up and running. WCF did a whole lot of great stuff and in general I consider it an excellent framework for application communication. (For a more thorough treatise on WCF and a lot of the design and thought that went into it, I can't think of a better resource than Dr. Nick)
There was a slight gap, however, which was that while we made writing clients and services easy, and while we even made it easy for these clients and services to be typeless (de-coupled or de-couple-able from each other) what we didn't provide was an easy way to splice in an intermediary that could sit between a client and a service; the whole model was inherently point to point. In order to get an intermediary, you'd have to write a custom service that took in messages and then sent them (routed them, you might say) to another location. When people/customers built these services, they frequently wanted more than just a simple proxy. The thought was "Well, hey, we've done the work to get the message, and so before we pass it on, why don't we look at it and use the information in it to make a decision about where it should go?" Thus an application level content based router was developed. However, writing one of these services is frequently non-trivial, and so when people solved this problem they did exactly whatever they needed to do. If their app only spoke one protocol and only request-response, then that was what their intermediary that handled the traffic for that application spoke. If they wrote a different application that used different protocols or had a different communication pattern, then frequently they had to write a new intermediary that understood that pattern or do some expensive retrofitting of their prior intermediary to adapt it. Security was a consideration. So was performance and scale. All of these things had to be dealt with by everyone who wrote their own intermediary. If you're curious about what's required for even a basic pass-through router, you can read the excellent article by Michele Leroux Bustamante over on Service Station (part 1, part 2).
The WCF Routing Service is an attempt to create a generic, moderately programmable intermediary so that you don't have to. It has been a fantastic challenge and a wonderful project that (despite some of it's lumps) I'm hopeful it will be a useful success (and thus obsolete a lot of code out there in the world today). Instead of describing all of the Routing Service's capabilities and where I think it's going to be useful, I'll direct you instead to this video on Channel 9 that I did a few weeks ago where we have a discussion about the Routing Service.
As always, I would love to hear your thoughts. The next post will probably be a recap of some of the capabilities of the Routing Service, touching briefly on how we've designed them and what scenarios we think they'll be useful in.
-Matt