实现 net.msmq 端点协定的 WCF 服务对象是否也可以实现 net.tcp 端点的回调协定?
尝试实现 MSMQ 支持的 WCF PubSub。我知道 net.msmq 是单向的;然而,当我使用单个服务对象来实现用于从底层队列读取的 net.msmq 端点以及用于侦听器订阅回调的 net.tcp 端点时,我遇到了很多关于单向与单向的抱怨双向,DuplexChannelFactory、DuplexClientBase 等。
实现此目的的唯一方法似乎是让 net.msmq 队列读取服务成为 net.tcp 发布者服务的客户端,并在出现问题时通知发布者。新消息从队列中读取,而不是在内部将消息发布给订阅者。或者,不在接收器上使用 net.msmq,而只准备一个普通的旧 MessageQueue 对象。
Trying to implement a MSMQ-backed WCF PubSub. I understand that net.msmq is one-way; however when I use a single service object to implement the net.msmq endpoint for reading from the underlying queue, and a net.tcp endpoint for listeners to subscribe to with callbacks, I'm running into a lot of complaints about one-way vs. two-way, DuplexChannelFactory, DuplexClientBase, etc. etc.
It almost seems like the only way to implement this is to have the net.msmq queue reading service be a client to a net.tcp publisher service, and notify the publisher when the new message is read from the queue, rather than publish the message to subscribers internally. Or, to not use net.msmq on the receiver, and just ready with a plain old MessageQueue object instead.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在重构一些接口并发现订阅者和回调实现者之间的一些缺失归因和尴尬关系之后,我已经建立了预期的队列支持的 pubsub 模式。所以是的,有可能,之前的困难是我的设计错误。
编辑/脚注:出于某种原因,之前作为 MsmqMessage 传递到 net.msmq 接收器的消息现在抛出 nullreferenceexceptions;然而,将签名更改为 MyObject 是有效的,但最初并没有这样做
After refactoring some interfaces and finding some missing attribution and awkard relationships between subscriber and callback implementor, I have established the intended queue-backed pubsub pattern. So yes, it is possible, previous difficulties were design error on my part.
Edit/footnote: For some reason, messages previously passed to the net.msmq receiver as MsmqMessage are now throwing nullreferenceexceptions; however changing the signature to MyObject works, which it did not initially