One common complaint about BizTalk Server is that it’s not particular lightweight (many moving parts) and isn’t easy for an expert .NET developer to pick up immediately. I suspect this is one reason why we’ve seen multiple other .NET service buses (e.g. nServiceBus) pop up as viable alternatives.
So, when it was announced that WCF 4.0 would include a built-in “Routing Service”, this piqued my interest. To be clear, the Routing Service does NOT claim to be a service bus, nor should it, but, for many real-time message routing scenarios, it is actually a nice fit. I wrote about the Routing Service in my Applied Architecture Patterns book and you can read an excerpt of that chapter on the Packt Publishing site. In a nutshell, the WCF Routing Service is a SOAP service broker that uses a variety of filters to steer traffic to specific endpoints. If you know how to build WCF services and deploy them to IIS, then you can very quickly learn how to leverage the Routing Service.
But how does the Routing Service compare to BizTalk Server? Let’s line them up against a few key dimensions and see if this helps us choose the right tool for a given situation. If an “X” is gray in color, then I’m indicating that a capability is supported, but isn’t implemented as robustly as the compared technology.
|Transport and Content|
|Receive message via one protocol and route message through another||X||X||Both technologies can translate transports.|
|Multiple input transport channels||X||X||BizTalk has more options, of course, since it supports LOB system adapters, and protocols such as FTP and POP3.|
|Process multiple file formats||X||–||The Routing Service only handles XML whereas BizTalk handles multiple other encodings.|
|Accepts multiple message types through single endpoint||X||X||This is the default behavior for the Routing Service. BizTalk can do this with some adapters easier than others.|
|Supports RESTful services||–||–||Surprisingly, neither do. Hopefully this comes in the next version of both technologies.|
|Route based on body of the message||X||X||BizTalk requires you to “promote” nodes to enable routing while Routing Service allows you to use XPath and route based on any node. Difficult to leverage repeating nodes in BizTalk or easily add new routable ones.|
|Route on both message metadata and endpoint metadata||X||X||For the Routing Service, this includes the endpoint address, endpoint name and SOAP action|
|Routing criteria can be aggregated.||X||X||BizTalk allows a complex mix of criteria that can be combined with both “and” and “or” statements. The Routing Service lets you “and” two distinct filters.|
|Multiple recipients can receive the same message.||X||X||Both technologies support multi-cast for async operations.|
|Quality of Service|
|Reliable delivery through retries on exception||X||X||BizTalk allows you configure both the number of retries and interval between attempts while the Routing Service does some automatic retries for specific types of errors (e.g. timeouts).|
|Reliable delivery through backup delivery endpoints||X||X||Both technologies let you define a service (or endpoint) to route to if the primary transport fails.|
|Reliable delivery through durable messaging||X||–||BizTalk uses a “store and forward” pattern that ensures either delivery or persistence. The Routing Service has no underlying backing store.|
|Configuration stored centrally in a database||X||–||BizTalk configuration is stored in a central database while Routing Service relies on its XML configuration file. In some cases, the agility of a file-based configuration may be preferred.|
While there are clearly a great number of reasons to leverage BizTalk for enterprise messaging (adapters, pub/sub engine, strong developer tooling, high availability, etc), for straightforward content-based routing scenarios, the WCF Routing Service is a great fit.
This is the first blog post in a short series that explains some details of the WCF Routing Service including filter configuration, error handling and more. Hope you stick around.