关联及本地主机通信学习完本章，你将掌握：1.了解工作流关联（correlation）以及在什么地方必须去使用它、它为什么是重要的2.使用工作流关联参数（correlationparameters）3.生成并使用相关的本地通信服务贯穿本书你看过的应用程序普遍都是基于单一相同架构的，通过WF的支持在工作流实例中执行任务。这些都是在应用程序和它的工作流实例间进行一对一的通信。假如你和一个工作流实例进行通信，你这样做保证了无论以任何方式在应用程序和工作流之间传送数据都不会被混淆。一个应用程序对应一个工作流。但是至少有一种情况也是有可能的，这是应用程序和工作流在同一个应用程序域（AppDomain）中执行的时候。你单独的一个应用程序会调用同一个工作流的多个副本。来回传送数据会发生什么呢？显然，有些人需要了解工作流和哪些数据协同工作的。通常我们不能混淆并要进行匹配比较。一旦创建了工作流实例并入队执行后，如果它绑定到一个指定的数据标识符，用工作流对不同的数据标识符进行信息的处理可能存在数据完整性的问题。其实，WF提供了一些内部簿记来帮助我们防止数据完整性的问题。在WF术语中，它被叫做关联（correlation），WF提供了非常强大的关联支持但它也很容易地使用。宿主和工作流的本地通信在我们进入关联的论题之前，让我们简要地回顾一下宿主和工作流的整个通信过程。在第8章“调用外部方法和工作流”中，介绍了CallExternalEvent活动并使用了一个本地通信服务来把数据从工作流发送到宿主应用程序中。在第10章“事件活动”中，使用了HandleExternalEvent活动来进行相反过程的处理：宿主也能把数据发送到工作流中。不论数据以哪种方式进行传送，我们首先都要创建一个接口。接口中的方法注定最终会成为CallExternalEvent活动，而接口中的事件则最终会成为HandleExternalEvent活动。我们使用wca.exe工具来为我们生成这些基于我们的接口的自定义活动。（我们也可以直接使用CallExternalEvent活动和HandleExternalEvent活动，它提供出要处理的每一个接口、方法或者事件，但是在我们的工作流中创建自定义活动是我们所强烈推荐的。）随着手头有了接口，我们然后就创建了一个本地服务并把它插入进了工作流运行时中，让它去管理我们的本地通信需求。本地服务由一个数据连接器和一个服务类组成。当应用程序需要发送数据到工作流中时，它需要得到这个来自工作流运行时的服务，然后激发由接口提供的事件。假如你把该事件处理器（eventhandler）拖进了工作流中并在适当的时候调用了该事件的话，你的工作流运行时会处理这些事件。另一方面，对本地通信服务来说，工作流却没有查询工作流运行时的必要。拖拽一个CallExternalMethod活动到你的工作流的处理路径中以后，在数据抵达的时候会自动通知宿主——这里再次假设宿主应用程序把一个接收数据事件的事件处理程序（eventhandler）连接到了本地通信服务上。工作流运行时保持工作流实例和本地通信服务以及宿主应用程序之间的联系。关联再次回味上一段内容。工作流实例不需要到处搜寻和宿主应用程序进行通信的服务。但是宿主应用程序还是需要查询本地通信服务。尽管如此，在某种程度上，由于宿主和工作流运行时之间交互的性质，处理过程也要强调宿主应用程序和工作流实例之间的一对多的关系。宿主应用程序需要识别出它想和哪一个工作流实例进行通信，因为可能有很多个选择。但是，一个工作流实例却没有这样的选择：因为它只可能属于一个宿主应用程序。宿主为了数据通信总是要通过查询工作流运行时来获取服务，本地通信服务正是一个你或许想去访问的服务之一。相反的过程无疑也是同样的。工作流被绑定到本地通信服务上而不用关心宿主应用程序的身份，这是架构设计上的必然结果，因为一个工作流实例只能属于一个宿主应用程序（它们之间是一对多的关系），它不可能属于一个以上的应用程序，所以不需要识别出应用程序的身份。综上所述，工作流运行时由此为工作流实例提供了本地通信服务，工作流实例可随意地调用外部方法。那么，对于宿主来说，使用工作流实例的标识符来传送和其相关的数据流的这种方式可行吗？也就是说，假如你掌握了一个工作流...