WCF消息参与者

理解消息

　　在面向服务的应用中，消息是通信的基本单位。因此，面向服务的应用通常被称为消息应用系统。在某一时刻，每个面向服务的应用系统都会发送或者接受消息。这个能够帮助你理解面向服务的消息很像你在Email系统里收到的信件一样。在邮件系统里，一个信件是抽象的实体：它可以包涵任何类型的信息，可以以不同的形式和大小存在，可以关联任何东西。同样，一个面向服务的消息也是一个抽象实体：它几乎可以包涵任何数据，可以使用许多不同的方式编码，并且可以关联到虚拟东西，甚至是其它消息。邮件的一些属性已经被广泛接受。例如，一封信件可以被某个人发送，邮寄给某个人，并且可能被某个人投递(某一时刻更多的是“可能”)。同样，一个面向服务的消息可以被计算机发送，发送给另一个计算机，并且可能由另外的计算机来投递。考虑某些喜欢死扣理论的书呆子，我必须澄清，与面向服务消息交互的实体不一定必须是计算机。理论上说，它们可以是信鸽，拉布拉多猎犬或者是狮虎。无论如何，这些与面向服务消息交互的实体被称作消息的参与者，并且在这本书里，一个消息参与者可以是一个计算机上的进程。

消息参与者

　　让我们想象一下，我需要写一封感谢信给我朋友Rusty，因为他上周给了我一张足球比赛的门票。我们假定需要把信件邮寄到Rusty的办公室。现实生活中，发送Email给Rusty或许是更加方便和省钱的方式。那可能是更加复杂的例子，有时候写信会更加合适。那么邮寄一份信件我需要经过多少种步骤呢?大家知道，正常情况下我需要先写一封感谢信在我邮寄以前。当我写信的时候，我需要提到足球比赛的事情，因为无缘无故地给一个人写感谢信会非常奇怪。接下来我会把信放到信封里，然后写上收信人地址然后贴上邮票。最后一步就是把信投到信箱里，让邮政服务机构来把信件转交给Rusty。可以想象Rusty将会知道感谢信是我写的，而且知道我是为了足球票的事情感谢他。

　　当我们描述消息参与者的时候，把他们对应到消息发送过程的角色是非常有用的。通常来说，有三种类型的消息参与者：初始发送者、最终接受者和中介者。

　　1. 初始发送者

　　明确消息发送者比看起来要困难，在我们的感谢信例子中，我看起来就是消息的发送者，有点是是而非，但是把我的信件堪称是对Rusty送球票行为的响应。如果我们这样考虑，Rusty就是消息的发送者，我的感谢信就是对其慷慨的回应。沿着这些路线，可能我会再2个月前发送一个新建所要球票。当Rusty回应我的时候，就给了我2个球票。我的感谢信就是对Rusty响应的响应。也可以能是我们共同的朋友建议他应该给我这些球票。这个例子里，我们的共同的朋友就是消息的最初发送者。

　　我们回顾一下感谢信的例子，Rusty或许不在乎谁是初始的消息发送者；他就想知道谁写的感谢信。实际上，初始消息发送者和消息发送者之间的经常不值得去区分。因此，我会使用发送者代替。如果你在万维网联盟（W3C）的文档或者规范里看到初始发送者这个单词，要知道定义里的含义。

　　解释了这么多，下面是我关于发送者的描述：一个发送者是一个发起通信的实体。

　　2. 中介者

　　当信件到达Rusty手里的时候，几个人已经处理过了这个感谢信。这里提到一些：

1. 负责收信的邮局工作人员
2. 负责分信的邮局工作人员
3. 把信投递到Rusty办公室大楼的邮递员
4. 把信件转交给Rusty的邮件收发室的工作人员

　　从经历来说，我们不知道多少人处理我们过我们发送的信件。我们很希望知道从处理我们信件的人那里的确定操作。比如，我们希望他们不要打开信件或者修改内容。我们同样系统每个信件处理人员尽量把信送到我们想寄给的人那里，不论是处理的过程中还是实际地址。这些消息的路径节点就是中介者。

　　说了一堆，我这里给出中介者的定义：中介者是对发送者不可见的，并且处于发送者和接受者中间的。

　　辨别中介者同样比看起来困难。在我们邮寄信件的例子里，邮递员不是简单捡起信件然后把它交给另外一个邮递员？下一个邮递员是不是继续向前投递给下一个邮递员？如果他或者她向前发送一个信件，邮递员不可以是初始发送者吗？事实上却是如此，每个处理信件的邮递员在流程里都会向前发送信件。每个邮递员都会从别另外一个邮递员或者发送者处接收信件。逻辑上，邮递员对于发信人是不可见的，因此发信人不会特地写明地址。同样，邮递员不会创建一个消息；他们只是简单地处理和投递消息。同样，在处理信件的时候，信封可能被修改。思考一下邮戳。邮戳不会改变信件的内容。但是它提供了一些有用的关于何时何地信件被收入的信息。如果地址无效，邮政服务可能要增加一个“退回给发件人”的标记。更高层次上，这些操作偶读是可以由中介者完成。一个中介者，不应该修改消息的内容。

　　3. 业务逻辑简介

　　这个架构中的附加层对于捕获业务流程非常有用。过去，应用系统的业务逻辑都是硬编码在系统中。比如，也许需求或者规则可能需要Contoso财务系统在订单完成以前接受回飞棒付款。传统的分布式系统会把业务逻辑分散到这个业务流程、网站、财务系统和出货系统中。这个设计有个很大的缺陷就是：当业务需求或者规则变化的时候，系统的每个部分都要修改。

　　最近这些年，很多公司已经开始花钱开发自己的内部系统来解决这些问题。经常是花费很大精力来定义表现业务逻辑的XML文法以及构建一个自定义的运行时引擎来解析这些规则。我猜测，常见的结果就是无果而终。

　　4. 最终接受者

　　我的感谢信是想邮寄给我的朋友Rusty。当我邮寄信件的时候，我不知道多少人会处理它，但是我希望每个处理者的工作都是为了把信件送达到Rusty。

　　所以，我就定义了最终接受者：最终接受者是消息期望和可达的目标

　　单个消息可只有一个最终消息接受者。例如，不可能在信封上写多个地址。事实上，一个地址可能提到多个实体。比如，Rusty的部分是负责发送球票的，我可以把一个部门作为感谢信的地址。我们的意思是在这个例子里，部门里每个人都会收到消息。也可能我的信件被贴到公告牌上，发给每个部门员工，或者在部门会议里宣读。