是否可以让WCF服务主机不绑定任何特定的服务类型？

Question

这篇文章与我的previous post有点联系。

简而言之，我正在尝试构建一个反向轮询http绑定，其中主机轮询其客户端以获取请求。我使用http://archive.msdn.microsoft.com/duplexhttp中的代码作为参考。现在，在此绑定中，主机实际上是客户端，客户端实际上是服务器。这意味着，使用此反向轮询http绑定的客户端必须以提供通道泵设施的隐藏服务主机结束。

现在，使用ServiceHost类型的常用模式要求存在实际的WCF服务实现。就我而言，ServiceHost在客户端是开放的 - 它没有服务实现，而且是正确的。

我想知道解决这个问题的最佳方法是什么？

理想情况下，此服务主机不需要任何服务。轮询主机发送Message实例，这些实例未映射到任何服务合同。这些消息由专用通道请求和回复 - 分别为HttpPollingRequestChannel和HttpPollingReplyChannel。但我需要它实施的通道泵设施的服务主机。

编辑1

我想更多的背景信息是必要的，以澄清图片。我们的系统由客户端，服务器和代理组成。客户端与服务器通信，后者将其请求传递给代理，代理将结果传回服务器。所有渠道都是直截了当的HTTP - 简单明了。

但是，需要能够在防火墙后面部署代理，而无法在其上打开入站端口。这意味着，服务器 - ＆gt;代理通信不再可能。在我看来，我有两个选择：

1. 重新设计服务器 - ＆gt;代理协议使其使用轮询。
2. 实施低级绑定，这将在内部使用轮询。

你会做出什么选择？虽然，第二种选择更难实现，但这是一次性的努力。但它有很多好处。可能吗？我想是的，因为对于Silverlight和.NET都已经存在轮询双工http绑定 - 请参阅本文开头的链接。

编辑2

我想再次强调，我不想要双面打印。在双工通信中，回调在请求的上下文中执行，这意味着代理发送请求并且服务器执行回调。我的情况不同。代理什么都不发送服务器决定与代理进行通信。代表Agent没有活动请求。所以，现有的双面绑定对我来说并不好，但我试图从中学习如何实现轮询。

整体情况如下：

• 代理不断轮询服务器
• 如果服务器想要向代理发送消息，该消息将等待下一个轮询请求，并在轮询请求回复之上骑到代理。

轮询请求不是任何接口的一部分，它们是在低级绑定基础结构中实现的。

Answer 1

首先，如果我是你，I would not会使用双工。

除了一大堆线程问题外，如果服务器和客户端在权重和权限方面相同，我会使用2个独立的接口，一个用于服务器到客户端，另一个客户端用于服务器。

如果您需要对邮件具有完全的灵活性，那么WCF可能不是完全可行的方法。 CQRS + NServiceBus 可能更适合定义命令，每条消息都会强制要求对其执行操作。

Answer 2

在我看来，你在浪费时间。该技术尚未做好准备。如果要与客户端进行双工通信，请使用发布/订阅模式。如果您只想让服务器调用客户端，则将客户端和用户服务器上的服务公开为该服务的客户端。

为什么？

1. 它将为您节省大量时间和预算
2. 它将起作用 - 它由成千上万的现实世界的解决方案测试
3. 如果您遇到麻烦，人们会理解并帮助您。

如果你真的需要关注你的场景放弃WCF并使用其他编程模型 - 可能是直接套接字。

修改

好的，如果您仍想使用双工服务，我有这个想法：

• 当座席不在防火墙后面时使用WsDualHttpBinding
• 当代理位于防火墙后使用PollingDualHttpBinding - 要获得此绑定，您必须安装Silverlight 4 SDK。它位于单独的程序集System.ServiceModel.PollingDuplex.dll中。如果要在配置文件中使用它，则必须将绑定注册为新的绑定扩展名。

Answer 3

防火墙是双工HTTP不起作用的原因。考虑到这个问题出现的次数，我真的希望微软从未创建过dualHttpBinding。

解决方法是使用类似netTcpBinding的方法，因为它允许通过单个连接（客户端创建的连接）进行实际双工通信，从而解决防火墙问题。如果由于某种原因你需要使用HTTP，你唯一的选择是让代理轮询服务。