代码改变世界

WCF消息参与者

2011-07-22 15:36  田志良  阅读(819)  评论(1编辑  收藏  举报
理解消息
  在面向服务的应用中,消息是通信的基本单位。因此,面向服务的应用通常被称为消息应用系统。在某一时刻,每个面向服务的应用系统都会发送或者接受消息。这个能够帮助你理解面向服务的消息很像你在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的部分是负责发送球票的,我可以把一个部门作为感谢信的地址。我们的意思是在这个例子里,部门里每个人都会收到消息。也可能我的信件被贴到公告牌上,发给每个部门员工,或者在部门会议里宣读。