什么是相关性以及为什么需要初始化它？
原文地址：http://blogs.msdn.com/b/endpoint/archive/2010/01/04/what-s-a-correlation-and-why-do-i-want-to-initialize-it.aspx?Redirected=true
What’s a Correlation and why do I want to Initialize it?
什么是相关性以及为什么需要初始化它？
In .NET 4.0, we have introduced a framework for correlation. What do I mean by correlation? I’m glad you asked. In our vocabulary, a “correlation” is actually one of two things:
在 .NET 4.0 中，我们引入了相关性框架。我的意思是什么呢？很高兴被问到这个问题。在我们的词汇中，相关性实际上是下面的两件事之一：
- A way of grouping messages together. A classic example of this is sessions in WCF, or even more simply the relationship between a request message and its reply.
- A way of mapping a piece of data to a service instance. Let’s use sessions as an example here also, because it makes sense that I’d want all messages in a particular session (SessionId = 123) to go to the same instance (InstanceId = 456). In this case, we’ve created an implicit mapping between SessionId = 123 and InstanceId = 456.
- 将一系列消息组合在一起的方式。经典的例子就是 WCF 中的会话，或者更加简单的请求消息和响应消息之间的关系。
- 将一部分数据映射到一个服务实例的方式。我们还是使用会话的例子，因为它是有道理的，我希望在相同的实例中 ( InstanceId = 456 )使用 特定的会话中 ( SessionId = 123 ) 处理所有的消息。在这种情况下，我们为会话 SessionId = 123 和实例 InstanceId = 456 创建了显式的关系。
As you can see, these patterns are related, hence why we call them both “correlations”. But sessions are inherently short-lived, tied to the lifetime of the channel. What happens if my service is long-running and the client connections aren’t? The world of workflow services reinforces the need for a broader correlation framework, which is why we’ve invested in this area in .NET 4.0.
正如你看到的，这些模式其实是相关的，所以，我们将它们一起称为“相关性”。但是，会话是短期的行为，与信道的生命周期相关。如果我的服务是长时间运行的，而且客户端并不能保持连接又会发生什么呢？工作流强化了需要一个更加通用的相关性框架的需求，这也是为什么我们在 .NET 4.0 中投入力量的原因。
There are two operations that can be performed on a correlation: it can be initialized, or it can be followed. This terminology is not new; in fact, Biztalk has had correlation for many releases. But what does “initializing” a correlation mean? Another great question. Well, it is simply creating this mapping between the data and the instance.
存在两种操作上的相关性：被初始化的，以及跟随的。这些术语并不是新概念；事实上，Biztalk 就存在 Correlation 的多个版本。但是初始化相关性是什么意思？又是一个很大的问题。简单来说，它仅仅是数据和实例之间的简单映射。
In addition, there are many types of correlation available in .NET 4.0, but let’s focus on this category of associating data with an instance. When that data comes from within the message itself (e.g. as a message header or somewhere in the body of the message), we call that content-based correlation.
此外，在 .NET 4.0 中，还存在很多类型的相关性，让我们将注意力放在数据与实例相关的相关性上。当数据随着消息到来的时候（例如，在消息头中或者在消息正文中的某个位置），我们称为基于内容的相关性。
Ok, too much theory and not enough application; let’s look at how this manifests in WF 4.0. With every message sent or received from your workflow, you’ve got an opportunity to create an association between a piece of data in that message and the workflow instance. That is, every messaging activity (Receive, SendReply, Send, & ReceiveReply) has a collection of CorrelationInitializers which let you create these associations. Here’s what the dialog looks like in Visual Studio 2010:
好了，讲了太多的理论，却没有多少程序来说明；让我们看一下在 WF4.0 中是如何应用的。对于任何从工作流发送和接收的消息，你可以选择创建在工作流实例和这些消息之间创建一种关联。也就是说，任何消息活动（Receive, SendReply, Send, 以及 ReceiveReply ）存在一个相关性初始化器的集合，允许你创建这些关联。下面的对话框就是在 Visual Studio 2010 中的样子。
As you can see, it’s been populated with a Key and a Query. The Key is just an identifier used to differentiate queries, e.g. DocId = 123 should be different than CustomerId = 123. The Query part is how we retrieve the data from the message; in this case, it’s an XPath expression that points within the body of the ReceiveDocument request message to the Document.Id value. Some of the resulting correlation information is pushed into a CorrelationHandle variable (the DocIdCorrelation), which will be used by later activities to follow this correlation.
正如你看到的，它通过 key 和查询填充。Key 用来在不同的查询中作为一个唯一的标识，例如，DocId = 123 不同于 CustomerId = 123。查询部分就是我们如何从消息中获取数据。在这里，它是一个 XPath 查询表达式，指出在 ReceiveDocument 请求的内容中的 Document.Id 的值。还有一些相关性的信息被保存在 CorrelationHandle 变量中( DocIdCorrelation )，这些信息将会被用于后继的活动来跟随这个相关性。
Now, you might be wondering: if I already have the Document.Id value in a workflow variable, why do I need this XPath expression in order to initialize my correlation? That’s a great point. In fact, we wrote another activity just for this purpose: the InitializeCorrelation activity. As you would expect, the dialog looks very similar to what we just saw (Note: this dialog is different than what is present in Visual Studio 2010 Beta2):
现在，你可能想知道，如果我真的在工作流变量中拥有 Document.Id，为什么我需要这个 XPath 表达式，来初始化我的相关性？事实上，为了这个目的，我们又创建了另外一个活动，InitializeCorrelation 活动。正如你期望的，这个对话框非常类似于我们刚刚看到的( 注意：这个对话框与 Visual Studio 2012 Beta2 中的不同 )
This activity is particularly useful in scenarios where the data to initialize the correlation comes from a database, or if you need to create a composite correlation from multiple pieces of data like a customer’s first and last name concatenated together. For all of you Biztalk experts, this means no more “dummy send” pattern! Hooray!
这个活动在通过数据库中的数据来初始化相关性的场景特别有用。或者你需要创建一个复合相关性的时候，比如客户的姓和名连接在一起的时候。对于 Biztalk 专家来说，这里没有更多的虚拟模式！万岁！
Ok, you’ve initialized a correlation … now what? Regardless of how you’ve initialized it, a correlation is only useful if it is followed. A Receive activity follows a correlation by correlating on the same piece of data (in this case, a DocId) and specifying the same CorrelationHandle. Imagine that the document approval process includes some opportunity to update the document before the official approval is given. An UpdateDocument request message is sent, which contains the DocumentId value in it. Here we specify the XPath expression to point to that particular piece of data in our incoming message. We also set the CorrelatesWith property to the same CorrelationHandle we specified previously; this ensures that when the Receive activity starts executing and goes idle (sets up its bookmark), the WorkflowServiceHost knows what correlation this workflow is waiting on and can resume the correct instance when the message with the corresponding Document Id comes in.
现在，你已经初始化了相关性，现在该怎么办？无论如何初始化，对于后继的活动相关性都是有用的。通过指定相同的CorrelationHandle 一个 Receive 活动通过相同的数据片段（在这个例子中，使用 DocId） 可以跟随相关性。想象一个文档的审批过程，在正式配准之前包含了多个审批步骤。UpdateDocument 请求消息发送的时候，包含了 DocumentId 的值。在这里，我们通过指定 XPath 表达式来指出包含在消息中的 DocumentId 。我们也会设置CorrelatesWith 属性使用我们在前面指定的相同的CorrelationHandle 。这样确保在 Receive 活动开始执行，直到进入空闲状态( 设置书签 )，WorkflowServiceHost 可以知道什么相关的工作流实例正在等待，并且可以在包含相关的 Document Id 消息到达的时候恢复正确的工作流.
And now you can consider yourself a content-based correlation expert! No longer are you restricted to using a context-based binding for communicating with instances of your workflow services! Now that’s freedom. Give it a shot and let us know what you think!
现在，你可以认为自己是一个基于内容的相关性专家了！你不再限于使用上下文相关的绑定来与你的工作流服务的实例进行通讯了！自由了！让我们知道你在想什么！
