In the previous post, I talked about the primary features of the Routing Service. In this post, I'd like to dive into Content Based Routing (CBR), and talk about some of the design and implementation choices we made.
The model for CBR in the routing Service is a WCF MessageFilterTable<IEnumerable<ServiceEndpoint>> (we'll touch on why there's an IEnum there later), where a MessageFilter that makes some claim about the Message data mapped to a destination set of IEnumerable<ServiceEndpoint> on the right. When a Message comes in, it's content is evaluated by each MessageFilter in the table, which either results in a True (this filter matches this message) or a False (it doesn't). If True, then the destination endpoint(s) is added to a list of destinations that the message should be sent to.
In the Routing Service we've taken MessageFilterTable model and first-classed it, allowing you to directly configure a MessageFilterTable and a set of MessageFilters and ServiceEndpoints. This table then plugs into the RoutingService to serve as the instructions that it should use for examining messages and then sending them to the destinations indicated. By default, we allow MessageFilters to look at the SOAP envelope portio of the message, but you can also configure filters to look at the Body of the message. Looking at the body is useful if you want to route the message on customer/application/call content rather than on addressing or other envelope data.
There were several design considerations that we made when we built the CBR capabilities within the Routing Service that made the reuse of the MessageFilterTable and MessageFilters particularly apt:
Now that we've discussed some of the why and how of Content Based Routing, the next post will deal with some examples and how to configure them.