Future of Correlation Examples

Last time I talked about how WCF 4.0 standardizes many different types of correlations using a query mechanism and promised to go into more detail today.

You might already be familiar with the message filter engine in WCF 3.0. If you haven't seen message filters before, then the message filter engine is just a way to check for matches in a message. For example, you might have an implementation of a message filter that uses XPath expressions and then create the filter /s:Envelope/s:Body/x:FooRequestMessage/y:OrderId to match SOAP messages with a particular structure. Instead of using an XPath to match the message content, you might instead have used an intrinsic function to match a message header or maybe even have described the filter in an entirely different language. Evaluating the message filter tells you whether the particular message satisfies the rules of the filter. The message filter engine manages a table of message filters so that the evaluation of many filters can be optimized.

For correlation, we created an equivalent to a message filter called a message query. You can think of a message query as a message filter that both checks for matches in a message as well as returns the value that was matched. For example, if you used the XPath message filter above, then it would tell you whether the message matched or not. If you used the equivalent XPath message query, then the result of the match would also give you the value of the y:OrderId node. Just like message filters, message queries are organized into tables by a message query engine to optimize the execution of many message queries at once.

You might see how to build correlations out of this query mechanism. The correlation query describes the structure or piece of information that you'll be correlating on. This information may be part of a message, a message header, or maybe even some function that gets run that doesn't depend on the message at all. Some of the queries will return matches and produce query results. These query results are then the value of the correlation that you'll be matching against. For example, your correlation query may pick out the y:OrderId node from a message if it exists. Let's say that it does and the node has the value 5. Then, the message query result is the value 5, and you can match that value against a table of previously observed values to correlate this message with some previously created state. Since you might have multiple pieces of information that are extracted, you want to have some way to hash and compare all of the matches at once. That hash is the correlation key that I talked about last time.

Next time we'll look at the APIs for message filters and message queries to see exactly how this process works.