是否有用于使用发布/订阅模式和 WCF 的框架/服务？
我的团队正在寻找将系统的各个组件分离为解耦服务的方法。我们想要实现的是事件驱动的模式，其中服务订阅以接收其他系统中发生事件时发送的信息。
由于我们已经使用 WCF 进行请求-回复消息传递，因此我们希望继续将其用于此特定模式。理想情况下，消息将通过 MSMQ 进行管理，以便我们能够使用可靠的消息传递，在服务发生故障时提供容错能力。
我们并不是在寻找任何复杂的东西，比如跨服务边界的事务支持。实际上，我们只需要一个简单的基于订阅的消息分发系统。是否有任何简单的框架或服务可以帮助我们实现这种模式？
My team are looking for ways to separate the various components of our system to decoupled services. What we'd like to achieve is an event-driven pattern where services subscribe to receive information sent when events occur in other systems.
Since we're already using WCF for our request-reply messaging, we'd like to continue using it for this particular pattern. Ideally, the messages would be managed via MSMQ to enable us to use reliable messaging to give us fault tolerance in the event of a service failure.
We're not looking for anything complicated like transactional support across service boundaries. Really, we just need a simple subscription-based message dispatch system. Are there any simple frameworks or services which can help us work to this pattern?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最简单的可能是 NServiceBus (http://www.nservicebus.com/PubSub.aspx)，但这不使用 WCF。
然而，从集成的角度来看，发送和接收消息比 Web 服务上的消息传递语义简单得多，因此您不需要 WCF 来抽象它。
编辑：为了使用 NetMsmqBinding 启用此功能，您必须自己实现订阅基础结构。这也很容易做到。
您的发布商需要有一个数据库来存储订阅。当订阅者启动时，他们要做的第一件事就是向发布者发送订阅消息，发布者将订阅记录在其订阅数据库中。
订阅消息应包含：
然后，当您的发布者想要发布消息时，它会检索订阅并评估每个订阅，以查看该消息是否与订阅匹配并检索要发送到的地址。然后它只发送消息。
这是实现 pub sub 的标准模式。
Probably the easiest is NServiceBus (http://www.nservicebus.com/PubSub.aspx) but this does not use WCF.
However from a integration perspective sending and receiving messages is far simpler than the messaging semantics on web services, so you don't need WCF to abstract that away.
Edit: In order to enable this using NetMsmqBinding you will have to implement the subscription infrastructure yourself. It would also be fairly easy to do.
Your publisher would need to have a database to store the subscriptions. When your subscribers start up, the first thing they do is send a subscription message to the publisher, who logs the subscription in it's subscription db.
The subscription messages should contain:
Then when your publisher wants to publish a message it retrieves the subscriptions and evaluates each one to see if the message matches the subscription and to retrieve the address to send to. Then it just sends the messages.
This is a standard pattern for implementing pub sub.