Future of Correlation

  • Article

One of the topics that you'll hear a lot about for asynchronous and decoupled programming in WCF 4.0 is correlation. Correlation is a relationship between one message and another message or one message and a piece of state. With synchronous programming, you may not always think about the correlations that are present. Correlations may be implicit through a call stack or through local variables. Or, they may be dramatically simplified by virtue of the fact that you know what's going to happen next and can craft your code to match the situation.

In asynchronous programming, correlation is the glue that joins together different operations. There are many different types of correlations. You've probably used several before.

For example, if you've defined a service contract with a CallbackContract, then you've specified a correlation based on two parties sharing a continuous network connection for an exchange of messages. If you've defined an HTTP cookie, then you've specified a correlation based on protocol information that is durably stored in between messaging operations. If you've included an ID field in a message, then you've specified a correlation based on message content. In many systems, each different type of correlation has a different way of describing and programming the correlation mechanism.

In WCF 4.0, one of the things we've done is think about how to standardize many different types of correlation behind a similar set of mechanisms. You'll see some examples using this correlation mechanism for workflow in the second half of Ed Pinto's PDC talk.

The basic pattern has just three operations.

- There is a query operation that can be applied to a message without the aid of any persistent state information. The query is the normalized operation for extracting information used by the correlation. The result of performing a query is a correlation key.

There is an association operation that can be applied to a key and a piece of state to bind the two together.
  • There is a retrieval operation that can be applied to a key to return a previously bound piece of state.

It turns out that many complicated patterns for correlation can be thought of in terms of queries. Next time I'll show you a few examples so that you can see what I mean by this.