Correlation under the Hood
You'll probably want to have read the previous articles about correlation for this to make sense.
Now that you've seen some of the details about message queries, you can combine queries with Ed's demonstration of programming a correlation in workflow to infer how the system actually works.
In a workflow program, correlations are described by placing send and receive messaging activities that are associated by a shared correlation handle. Each of the messaging activities has attached correlation queries that help define the application protocol. The correlation queries are just examples of queries to be evaluated by the message query engine. Ed wrote all of the correlation queries using XPath expressions, which can be evaluated using an XPath implementation of the MessageQuery and MessageQueryTable classes.
As I mentioned, a hash is taken of the various message query results to create a correlation key. It's this key computation result that gets stored in the correlation handle variable. A correlation handle variable is typically used in a write-once fashion. The first person to touch a message (either sending or receiving) initializes the value slot of the correlation handle variable with the key computed from the message. Everyone else associates successive messages to the correlation handle by checking whether the key computed for the new message matches the value stored in the variable. There are also activities to explicitly initialize and finalize correlations so that state can be manipulated without having to exchange messages. For example, these explicit activities replace the need to construct dummy sends to initialize a correlation like in BizTalk.
Reality is a little more complicated than this for a number of reasons.
Many interesting pieces of information are not accessible from walking the XML representation of the message. A language such as XPath might have no native way of describing the location of this kind of information. In some cases, such as message headers, we're able to devise standardized ways of accessing the information. In other cases, the situation is too varied to standardize. Instead, a property promotion mechanism is needed to bring the information into a standard format. The correlation system has a property promotion mechanism that works through a message property attached to the message. Information that is added to the message property is accessible through an XPath extension function that is provided by the MessageQuery implementation.
Another complication is that the workflow runtime might not have enough information to run the queries. When sending a message, there may be promoted properties that aren't computed until the message is being sent. To handle these cases there must be some way to integrate the providers and consumers of correlation information. The property promotion mechanism additionally has a way to provide callbacks during the resolution of a correlation so that the correlation result can be computed and stored.
Although we've covered only a few of the classes related to correlation, this series has already gotten fairly long. I'll come back to correlation in the future after looking at more features for asynchronous and decoupled programming in WCF 4.0.