需要将消息推送到客户端的WCF服务

这是我需要的设计：My design idea。需要将消息推送到客户端的WCF服务

enter image description here

是“用户”设计服务的“橙色”部分是一个好主意？

客户端需要连接到服务才能执行“读取”和“写入”操作，并且他们还需要从服务中获取通知（以PUSH方式）。

在开始时，我认为提供'读'和'写'functionialliyy的服务也能够发送通知（通过后台线程），但后来我明白'CallBack'仅用于服务需要调用客户端上的函数作为对客户请求的响应。含义 - 服务无法向客户端发起呼叫。那么'Subsciber'设计是否正确呢？

来源

2012-04-20 John Miner

所以简短的答案是肯定的 - 使用发布/订阅模式是非常有名的模式。它有助于将消费者与发布商分离。恶魔正处于实施细节中，您可以处理多少复杂性，以及您愿意在设计中交易什么。如果您愿意接受它的权衡（必须是WCF客户端，您自己的客户端和服务）和限制（客户端直接耦合，网络拓扑限制），您可以从WCF duplex channel实施开始。

如果双工通道的限制不符合您的喜好，那么您可以使用MSMQ或NServiceBus这样的方法来考虑，以满足发布/订阅要求。您可以通过Windows Azure AppFabric Service Bus将它带到下一个级别。

Duplex可以独立发送消息给客户端，而不仅仅是当客户端的呼叫到达时。

双工不耐用 - 当客户端消失或出现任何通信问题时，您必须从通道故障中恢复。保护双面打印可能会很棘手。您必须在双方都有WCF客户端/服务。您必须了解您的网络拓扑。

您有2个不同的绑定上下文（系统）。一个是让客户端发送命令和查询，另一个是发布有趣的事件给谁想要听这些事件。

编辑 - 如果某些客户端是iOS设备会怎么样？会使用DUPLEX会造成问题吗？你能开发一个通过DUPLEX通道与WCF服务通信的iOS应用吗？

答：请参阅本SO WCF duplex connection on iPhone?和What should I know when developing interoperable WCF web service?

来源

2012-04-20 17:00:51

嗨！感谢你的回答。所以你建议确实有2个服务？一个用于“拉”功能，另一个用于“推”功能？如果是这样的话 - 你能否详细说明DUPLEX的局限性？客户端如何耦合以及网络拓扑有什么限制？我查看了您发送的链接 - 它被称为“基于列表的发布订阅”，但我没有看到任何列表。当价格需要更新时 - 似乎是一个事件发生，调用所有注册的客户端（如果它是'PerSession'，怎么会这样？不应该服务是Singleton？）。 – 2012-04-20 23:06:10

而且 - 似乎服务直接调用客户端，而不是作为响应。我认为CallBack意味着服务可以在客户端只响应客户端发送的某个函数，而不是独立地向客户端发送消息。 – 2012-04-20 23:07:21

加入到动尸 – 2012-04-20 23:50:21

需要将消息推送到客户端的WCF服务

回答

相关问题