《WCF服务编程》关于“队列服务”一个值得商榷的地方

今天写《WCF技术剖析（卷2）》关于“队列服务”部分，看了《WCF服务编程》相关的内容。里面介绍一个关于“终结点不能共享相同的消息队列”说法，个人觉得这值得商榷。撰写此文，希望对此征求大家的意见。[源代码从这里下载]

目录
一、“终结点不能共享相同的消息队列”
二、实践出真知
三、为什么同一个服务的终结点可以共享相同的消息队列
四、为什么不同服务的终结点不能共享相同的终结点

一、“终结点不能共享相同的消息队列”

在《WCF服务编程（第三版）》的第9章《Queued Service》，Juval Löwy是这样说的："WCF requires you to always dedicate a queue per endpoint for each service. This means a service with two contracts needs two queues for the two corresponding endpoints:

 1: service name = "MyService" 

The reason is that the client actually interacts with a queue, not a service endpoint. In fact, there may not even be a service at all; there may only be a queue. Two distinct
endpoints cannot share queues because they will get each other¡¯s messages. Since the WCF messages in the MSMQ messages will not match, WCF will silently discard those messages it deems invalid, and you will lose the calls. Much the same way, two polymorphic endpoints on two services cannot share a queue, because they will eat each other’s messages.”

简言之，就是消息队列隶属于某个具体的终结点，服务这个终结点从该消息队列中接收的消息与本终结点不一致，就会丢弃这个消息。具体例子，同一个服务具有两个终结点Endpoint1和Endpoint2，它们采用NetMsmqBinding，并且共享相同的地址（意味着采用共享同一个消息队列）。如果客户端试图发送给Endpoint1的消息被Endpoint2截获，就会被丢弃，那么这个服务调用就无缘无故地“丢失”了。

那么，事实果真服如此吗？

二、实践出真知

我看到这段描述，感到挺奇怪，因为就我所了解到的WCF的消息分发机制，对于相同服务小不同终结点的消息队列的共享是没有问题的。但是，Juval Löwy毕竟是Juval Löwy，当初也将我领入WCF领域的启蒙老师，对于他认定的东西不敢贸然的否认。为此我写了一个例子，毕竟不论我了解得底层机制如何，实践是检验真理的唯一标准。

为了模拟一个服务的多个总结点共享相同消息队列的场景，我建立了一个实现了多个服务契约接口的服务GreetingService，它实现了两个服务契约接口：IHello和IGoodbye。这三个类型的定义如下面的代码片断所示。

IHello和IGoodbye：

我创建一个控制台应用对上面定义的GreetingService进行寄宿，下面是相关的配置和程序。从这可以看出寄宿服务具有两个基于NetMsmqBinding的终结点，它们的契约分别为IHello和IGoodBye，并且具有相同的地址。这意味着这两个终结点共享一个名称为mq4demo的本机私有队列。由于mq4demo为非事务性队列，我将ExactlyOnce设置为false，并且将安全模式设置为None以适应WorkGroup Installation模式。

现在我们编写代码分别针对这两个终结点发起服务调用，看看它们是否能够成功。下面的配置和代码的定义：

 1: using(ChannelFactory IHello channelFactoryHello = new ChannelFactory IHello ("helloService"))

 2: using (ChannelFactory IGoodbye channelFactoryGoodbye = new ChannelFactory IGoodbye ("goodbyeService"))

先后开启服务端和客户端（实际上那个先那个对于队列服务来说都可以），你会发现服务端控制台具有如下的输出，表明服务调用时没有问题的。

三、为什么同一个服务的终结点可以共享相同的消息队列

从上面的例子我们可以看到，同一个服务的终结点是可以共享相同的消息队列的。这也可以从WCF的消息分别机制来解释。就以我们上面的例子来说，服务GreetingService虽然具有两个不同的终结点，但是它们的监听地址是相同的，所以当服务开启的时候，只会创建一个唯一的ChannelDispatcher，它具有自己的ChannelListener。而该ChannelListener用于监听指定的消息队列中抵达的消息，一旦检测到消息队列中具有消息传来，或者开启时队列中已经有了消息，就会按照优先级去接收这些消息。然后按照“消息筛选机制”去选择用于处理该消息的EndpointDispatcher（对应于具体的终结点）。所以每个消息都能准确地抵达对应的终结点，并不会出现“一个终结点会吃掉另一个终结点消息”的说法。WCF服务端具体采用怎么的消息筛选机制进行终结点的选择，请参阅我的文章《WCF服务端运行时架构体系详解[上篇]》。

四、为什么不同服务的终结点不能共享相同的终结点

在上面的内容中，我说“多个终结点可以共享相同的消息队列”，都不忘提及一个前提：同一个服务的多个终结点。那么隶属于不同服务的终结点能否共享相同的消息的队列呢？答案是：“不能”。我想这才是Juval Löwy想表达的意思。

在上面我们说了，当服务开启之后就会试图是从绑定的消息队列中去“接收”消息。如果基于多个服务的终结点使用相同的消息队列，那么Service1开启的时候就有可能接收到发送给Service2的消息，在这种情况下，Service1采用消息筛选机制根本就不能选择出能够处理该消息的终结点，最终它会丢弃该消息。我我们之所以要强调“接收”二字，是因为它代表的事针对消息队列的操作Receive（而不是Peek），意味着被接收的消息会从消息队列中移除。为了证明这一点，我们对上面的例子作一下简单的更改。现将定义在服务端的终结点注视掉一个（保留契约IHello的终结点）。

然后在服务寄宿的时候，确认服务开启之前和关闭之后消息队列中具有的消息数量，相关的代码如下所示：

现在我们先运行客户端，让客户端将服务调用封装成队列消息发送的消息队列中。然后开启服务端，在开启之前由于客户端进行两次服务调用，所以消息队列中具有两个消息。由于服务只有一个终结点，所以它只能处理针对IHello契约的调用的消息。我们现在需要确定的是：“客户端针对IGoodbye契约发送的请求消息还会在消息队列里面吗？”。从输出结果来看，消息队列中已经不存在消息。

你可以将针对IGoodbye契约的请求看成是针对另一个服务的终结点发出的。由此可见，“只有同一个服务的多个终结点可以共享同一个消息队列，而基于不同服务的终结点则不行”。
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 原文链接

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[上篇] 原文:WCF技术剖析之三十：一个很有用的WCF调用编程技巧[上篇] 在进行基于会话信道的WCF服务调用中，由于受到并发信道数量的限制，我们需要及时的关闭信道；当遇到某些异常，我们需要强行中止（Abort）信道，相关的原理，可以参考我的文章《服务代理不能得到及时关闭会有什么后果?》。
WCF技术剖析之三十：一个很有用的WCF调用编程技巧[下篇] 原文:WCF技术剖析之三十：一个很有用的WCF调用编程技巧[下篇] 在《上篇》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现在我们来讨论这个解决方案。
WCF技术剖析之二十九：换种不同的方式调用WCF服务[提供源代码下载] 原文:WCF技术剖析之二十九：换种不同的方式调用WCF服务[提供源代码下载] 我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory创建服务代理对象。