消息参与者
让我们想象一下，
我需要写一封感谢信给我朋友
Rusty，因为他上周给了我一张足球比赛的门票。我们假定需要把信件邮寄到Rusty的办公室。现实生活中，发送Email给Rusty或许是更加方便和省钱的方式。那可能是更加复杂的例子，有时候写信会更加合适。那么邮寄一份信件我需要经过多少种步骤呢?
大家知道，正常情况下我需要先写一封感谢信在我邮寄以前。当我写信的时候，我需要提到足球比赛的事情，因为无缘无故地给一个人写感谢信会非常奇怪。接下来我会把信放到信封里，然后写上收信人地址然后贴上邮票。最后一步就是把信投到信箱里，让邮政服务机构来把信件转交给Rusty。可以想象Rusty将会知道感谢信是我写的，而且知道我是为了足球票的事情感谢他。
当我们描述消息参与者的时候，把他们对应到消息发送过程的角色是非常有用的。通常来说，有三种类型的消息参与者：初始发送者、最终接受者和中介者。
让我们想象一个更加真实的商业场景- Contoso回飞棒公司的订单处理系统。基本上，客户在网站上订购回飞棒，网站产生一个消息并且为了处理和完成订单流程而发送到其他的系统，如图2-1所示。
图2-1：Contoso回飞棒公司的消息流
场景中暗示的几个事实：
- 网站和其它几个系统已经在之前就消息格式达成共识。
- 网站可以依据之前的格式创建消息
- 网站知道如何向其他系统发送消息
- 内部系统可以使用接受到的消息中的数据区填充订单，发送确认信息和提交订单。
Contoso
订单处理系统至少有两个消息参与者。网站是消息发送者，内部系统是消息接受者。可能还有一个负载均衡路由来负责转发消息到适合的系统。如图2-2所示，我们可以认为路由就是中介者。
图2-2：在带消息路由的Contoso回飞棒公司的消息流
初始发送者
明确消息发送者比看起来要困难，在我们的感谢信例子中，我看起来就是消息的发送者，有点是是而非，但是把我的信件堪称是对Rusty送球票行为的响应。如果我们这样考虑，Rusty就是消息的发送者，我的感谢信就是对其慷慨的回应。沿着这些路线，可能我会再2个月前发送一个新建所要球票。当Rusty回应我的时候，就给了我2个球票。我的感谢信就是对Rusty响应的响应。也可以能是我们共同的朋友建议他应该给我这些球票。这个例子里，我们的共同的朋友就是消息的最初发送者。
我们的订单处理系统看起来也是有些迷糊。咋一看，网站可能就是消息的最初发送者。可是从内部系统的角度来看，也许不是这样。按照那个观点，最初发送者可能是网站或者另外一个内部系统（记得消息路由）。我们可以继续不停。但事实上消息的最初发送者是相对的。相对，我的意思是最初的消息发送者可以基于赋予消息的上下文环境而改变。在我们的两个例子里，我们可以画出任意一个包围2个或者多个消息参与者的边界，并且改变消息的最初发送者。
如果我们把
初始从初始消息发送者里去掉，我们可以更具体地想象一个消息的参与者。如果我们回顾一下感谢信的例子，Rusty或许不在乎谁是初始的消息发送者；他就想知道谁写的感谢信。实际上，初始消息发送者和消息发送者之间的经常不值得去区分。因此，我会使用发送者代替。如果你在万维网联盟（W3C）的文档或者规范里看到初始发送者这个单词，要知道定义里的含义。解释了这么多，下面是我关于发送者的描述：
一个发送者是一个发起通信的实体。
中介者
当信件到达Rusty手里的时候，几个人已经处理过了这个感谢信。这里提到一些：
- 负责收信的邮局工作人员
- 负责分信的邮局工作人员
- 把信投递到Rusty办公室大楼的邮递员
- 把信件转交给Rusty的邮件收发室的工作人员
从经历来说，我们不知道多少人处理我们过我们发送的信件。我们很希望知道从处理我们信件的人那里的确定操作。比如，我们希望他们不要打开信件或者修改内容。我们同样系统每个信件处理人员尽量把信送到我们想寄给的人那里，不论是处理的过程中还是实际地址。这些消息的路径节点就是中介者。说了一堆，我这里给出中介者的定义：
中介者是对发送者不可见的，并且处于发送者和接受者中间的。
辨别中介者同样比看起来困难。在我们邮寄信件的例子里，邮递员不是简单捡起信件然后把它交给另外一个邮递员？下一个邮递员是不是继续向前投递给下一个邮递员？如果他或者她向前发送一个信件，邮递员不可以是初始发送者吗？事实上却是如此，每个处理信件的邮递员在流程里都会向前发送信件。每个邮递员都会从别另外一个邮递员或者发送者处接收信件。逻辑上，邮递员对于发信人是不可见的，因此发信人不会特地写明地址。同样，邮递员不会创建一个消息；他们只是简单地处理和投递消息。
同样，在处理信件的时候，信封可能被修改。思考一下邮戳。邮戳不会改变信件的内容。但是它提供了一些有用的关于何时何地信件被收入的信息。如果地址无效，邮政服务可能要增加一个“退回给发件人”的标记。更高层次上，这些操作偶读是可以由中介者完成。一个中介者，不应该修改消息的内容。
为了一个基于计算机的中介者的例子，我们重新审视一下Contoso的订单处理系统。Contoso销售客户定制和标准的回飞棒。标准回飞棒的订单可以通过仓库存货系统处理，而定制的回飞棒则需要交给制造系统。Contoso的系统架构师或许以已经决定把业务逻辑放在一个路由系统里，把业务逻辑从网站中分离出来。这个设计的作用就是网站发送消息到消息路由服务器。这个路由系统不会再本质上修改消息内容。但是它可以转发订单到任意系统。高层次来看，路由系统扮演一个中介者的角色，在初始发送者（网站）和最终接受者（仓库存货系或者制造系统）。
业务逻辑简介
这个架构中的附加层对于捕获业务流程非常有用。过去，应用系统的业务逻辑都是硬编码在系统中。比如，也许需求或者规则可能需要Contoso财务系统在订单完成以前接受回飞棒付款。传统的分布式系统会把业务逻辑分散到这个业务流程、网站、财务系统和出货系统中。这个设计有个很大的缺陷就是：当业务需求或者规则变化的时候，系统的每个部分都要修改。
最近这些年，很多公司已经开始花钱开发自己的内部系统来解决这些问题。经常是花费很大精力来定义表现业务逻辑的XML文法以及构建一个自定义的运行时引擎来解析这些规则。我猜测，常见的结果就是无果而终。
正如第一章提到的，“月亮是蓝的”微软Windows Communication Foundation (WCF)一起发布的一个产品叫Windows Workflow Foundation (WF)。在这些产品力，WF是设计来捕捉业务流程的。WF能够为复杂的业务需求建立业务流程引擎。未来几年，希望工作流成为商业应用系统开发工作的更多部分。
这个架构中的附加层对于捕获业务流程非常有用。过去，应用系统的业务逻辑都是硬编码在系统中。比如，也许需求或者规则可能需要Contoso财务系统在订单完成以前接受回飞棒付款。传统的分布式系统会把业务逻辑分散到这个业务流程、网站、财务系统和出货系统中。这个设计有个很大的缺陷就是：当业务需求或者规则变化的时候，系统的每个部分都要修改。
最近这些年，很多公司已经开始花钱开发自己的内部系统来解决这些问题。经常是花费很大精力来定义表现业务逻辑的XML文法以及构建一个自定义的运行时引擎来解析这些规则。我猜测，常见的结果就是无果而终。
正如第一章提到的，“月亮是蓝的”微软Windows Communication Foundation (WCF)一起发布的一个产品叫Windows Workflow Foundation (WF)。在这些产品力，WF是设计来捕捉业务流程的。WF能够为复杂的业务需求建立业务流程引擎。未来几年，希望工作流成为商业应用系统开发工作的更多部分。
最终接受者
我的感谢信是想邮寄给我的朋友Rusty。当我邮寄信件的时候，我不知道多少人会处理它，但是我希望每个处理者的工作都是为了把信件送达到Rusty。所以，我就定义了最终接受者：
最终接受者是消息期望和可达的目标
单个消息可只有一个最终消息接受者。例如，不可能在信封上写多个地址。事实上，一个地址可能提到多个实体。比如，Rusty的部分是负责发送球票的，我可以把一个部门作为感谢信的地址。我们的意思是在这个例子里，部门里每个人都会收到消息。也可能我的信件被贴到公告牌上，发给每个部门员工，或者在部门会议里宣读。最后，消息是期望是一个逻辑实体，消息最终接受者
本文转自 frankxulei 51CTO博客，原文链接：http://blog.51cto.com/frankxulei/318631，如需转载请自行联系原作者
