《WCF技术内幕》翻译14：第1部分_第3章_消息交换模式、拓扑与编排…

《WCF技术内幕》翻译14：第1部分_第3章_消息交换模式、拓扑与编排…2011-05-28 博客园译:Frank Xu Lei《WCF技术内幕》翻译14：第1部分_第3章_消息交换模式、拓扑与编排:消息交换模式（MEP）

第3章：消息交换模式、拓扑和编排

当设计消息应用系统的时候，有必要考虑一下消息是怎样在发送者、中介者和接受者（前面章节介绍了这些消息参与者）流转的。系统中消息交换可能性的波动的值可以被不同程度地详细描述。这些不同级别的细节就是总所周知的消息交换模式（MEPS）、消息拓扑和消息编排【老徐备注1】。当从总体来看时，这三个级别的细节让我们抽象地描述任何消息场景。本章会详细剖析消息交换模式（MEPS）、消息拓扑、消息编排以及它们在WCF应用系统中如何被用来提供高级功能。

消息交换模式

我们描述消息交换最常用的细节粒度就是消息交换模式（MEP）。根据W3C草案（http://www.w3.org/2002/ws/cg/2/07/meps.html），一个MEP是“一个描述在消息参与者之间交换的消息的模板。”一个MEP被限制在一个发送者和接收者之间的逻辑连接上，整个行业也已经接受了这个事实。因为MEPs是个有点抽象的概念，近距离看一些现实世界的例子对于我们弄清MEPs这个概念有帮助。让我们来看看下面我和朋友关于足球票通话的例子：

1.我拿起电话，打给Rusty。
2.Rusty拿起手机。
3.Rusty说：Hello。
4.我说：你看今天的比赛了吗？
5.Rusty说：是的，踢得太烂了。真难相信我们没有赢。
6.Rusty说：他们全部哑火了。
对话继续…

1-3步可以认为是传输规范的事件（我呼Rusty，他接电话，准备通话）。第4 步，我以问题的形式发给Rusty一个消息，习惯告诉我他应该回答。第5步， Rusty发送给我一个消息作为问题的回应。第6步是非主动请求的消息，发送给我，我可以回应或者不回应。这个消息的关联性是非常含蓄的，因为它是对话流的一部分。如果没有前后场景的关联，我会不知道他在说什么，这将会很糟糕。就像是一个推销的电话或者象棋比赛一样。

在这个场景里，Rusty和我都可以随便说任何内容（就想步骤6里），我们也可以一个接一个不停地聊下去。一个单向的谈话也有可能，就像股东电话会议，或者因为一方终止了通话在回应发送以前，让我们看一下另外一个电话通话的例子：

1.Lewis（我老板）拿起电话，拨我的手机号。
2.我拿起手机说:“Hello”。
3.Lewis说：“你干的太好了。我会立即给你100%的加薪，”。
4.Lewis挂断了电话。
5.我打回给Lewis。
6.Lewis接电话。
7.我说：“你太大方了，我只要50%就可以啦。”。
8.我挂断电话。
9.Lewis又打过来。
10.我接听电话
11.Lewis说：“100%加薪是最终结果，我现在正开一个蓝色保时捷911 Turbo 赶过去，确保你能和我签约。”
12.Lewis又挂了。

在前面的场景里，我可以回应，但Lewis如此想给我加薪，以至于都没听我的答复。我只要再打给他进一步讨论详情。概念上说，消息交换里的响应需要发送者侦听在一个存在的连接或者一个新的连接上。

通话可以使用更严格的模型。想想一下飞行员和机场控制塔台之间的对话，如果你曾经听过这些通信，结构显而易见：

1.控制台呼叫飞行员：“Contoso437，转向180度，300哩（节/小时， 飞行速度），下降到10000英尺。”
2.飞行员回答：“Contoso437，正在转向180度，300哩（节/小时，飞行速度） ，正要下降到10000英尺”。

这个场景里，控制塔变化请求，要求回复。如果飞机没有回复，罗嗦的控制台会重复这个指令直到一个收到响应为止，或者采取其他的一些行动。进一步说，这个协议要求飞行员当控制塔正在通信的时候不能打断塔台。

这些简单的比喻对理解面向服务应用系统中的消息参与者之间交互很有帮助。概括地说，MEPs 是根据参与者如何交互、更确切地说，允许回复的数量和发送者和接受者之间需要不需要新的连接来分类的。也许电话和无线通话有所不同，但是在面向服务的世界里通常有3种类型的MEPs：数据报、请求-应答和双工。