问题标签 [publish-subscribe]

我需要实现一个简单的消息总线：

• 只有一个过程，因此不需要做 D-Bus。
• 发布/订阅类型化事件（甚至可以是 QObjects）

我正在考虑使用 QSignalMapper 来标记“命名事件”，然后从插槽重新发射或将发布者信号连接到订阅者的信号......

有什么建议想法吗？还是我应该选择相对简单的设计模式？

PS：Windows 上 D-Bus 的 AFAICS 需要安装“第 3 方”软件才能与 Qt 一起使用。

是否有某种方法可以在 Progress 4GL 中的网络中的客户端之间进行发布。

一种（丑陋的）方法是“发布”（写入）到数据库并让所有客户端轮询数据库 - 但我当然想避免这种情况。

我正在使用正在进行的 OpenEdge 版本 10.0B02。

在他的 Google I/O 2009“App Engine 上的离线处理：前瞻”演示文稿（视频、幻灯片）中，Brett Slatkin 介绍了任务队列服务。

他说

Pub-sub 系统最大化交易，解耦：

• 每秒大量的小事务
• 具有更改接收器的一对多扇出
• 保证排序、过滤、两阶段提交

并特别强调

我们的新 API 实现了排队，而不是 pub-sub

我只对这些功能的一部分感兴趣：

• 一对多扇出改变选定/固定的内部接收器处理程序
• 保证订购, 过滤, 两阶段提交

目标是简化同一 Web 应用程序的不同模块之间的通知/消息的发布。示例使用场景案例将是：

• 使支付模块知道收到账单。
• 使用户能够跟踪他决定关注/加注的特定域对象的更改。

在任务队列服务之上实现这些的正确方法是什么？

I am designing a Biztalk solution which requires client applications to subscribe and receive only a certain subset of event messages depending on their user permissions. Subscription will be done through topic or content based routing. The client will subscribe once and receive many messages until they choose to unsubscribe.

Client applications will number in the 100s and subscribed topics could change on a regular basis, so defining an individual send port from Biztalk for each reciever isn't a viable solution.

I have thought I could build an additional message broker service which holds the individual client subscriptions and distributes messages sent from a biztalk port.

I have also seen that a recipient list pattern can be build using orchestrations. This appears to me to still follow a request-response pattern though and I am after 1 way subscribe message to many returned event messages.

My message broker solution seems to me to be doubling up on what Biztalk should be good at so I imagine I am missing some important functionality somewhere. Has anyone tried such an application before and can give some pointers? Should I be investingating the ESB toolkit as a solution? I have had a look on the net but nothing makes it very clear for this type of topic-subscription model.

Thanks, Phil

我有一个用户可以动态添加小部件的网站。这些小部件使用 Peter Higgins pub/sub 插件来处理来自另一个“核心”模块$.(subscribe)的事件。$.(publish)

我在自己的名称空间中有小部件，如下所示：

km.widget.name1、
km.widget.name2
等。

所以创建的句柄$.(subscribe)不是全局的。

当用户决定从他们的自定义页面中删除小部件时，我不知道如何取消订阅这些小部件。

另外，我怎么知道要取消订阅哪个小部件？

好吧，我一直在做这个 NServiceBus 项目一段时间，一旦我让它为 PubSub 工作，我就将剩下的时间花在实际的工作流逻辑上。但是，我可以看到一个我想解决的严重问题（或者更确切地说是学习如何正确处理）。

据我了解，发布者将消息发布到任何订阅者的存储队列。伟大的。但是当订阅者没有运行时会发生什么（我已经阅读了其他关于这个的帖子，他们似乎没有问同样的问题）。

场景 - 我让发布者在没有订阅者运行时发布消息（附加/请求的消息要转发给他们）..然后我发现..消息“消失”只是根本不存在！它去哪儿了？发布者是否说“嘿，没有人订阅这个，所以我不会打扰发布它？”，它不应该这样做并且至少需要一个订阅者吗？

任何人都可以对此有所了解吗？（服务新手）

I'm trying to understand how common is the usage of MQ Topics in the industry. And MQ with SSL?

Thanks, Guy

我读了这篇文章

并且仍然不理解主题如何在 MQ 中工作的概念。在 JMS 中，我知道您可以在主题上发布消息，并且为了从该主题接收消息，您首先需要订阅它（在接收阶段使用订阅名称）。

它在 MQ 中是如何工作的？我想写一个简单的场景（如在 JMS 中）：

我正在使用 NServiceBus，我需要知道有多少客户端订阅了特定的消息类型（甚至更好的是订阅者的名称）。我说的是 pub\sub 场景。

是否可以在 NServiceBus 中获取此信息？

谢谢

我们在 WCF 应用程序中使用了一个发布-订阅模型，该模型几乎遵循 Microsoft 示例：设计模式：基于列表的发布-订阅。

虽然服务提供了subscribe()和的概念，unsubscribe()但在客户端死亡或通道故障的情况下处理清理的最佳实践是什么？目前，当客户端订阅时，我将处理程序附加到当前InstanceContext的Closed和Faulted事件（服务用户使用 PerSession 实例上下文模式和 netTcpBinding）：

OnClientLost处理程序只是取消订阅客户端，但是：

1. 上面的做法是否是一个好的做法，并且足够强大，可以在客户端断开双工通信时捕获所有情况？或者服务是否应该只处理在尝试与客户端通信并处理清理时遇到的异常？
2. 除了取消订阅客户端回调处理程序之外，是否应该执行任何进一步的清理，尤其是在出现故障的情况下？

这个问题提出了一个类似的问题，但最终没有提供对客户端调用订阅和/或取消订阅之外的案例的答案

谢谢