jms - 只处理一次消息

Question

请考虑如附图所示的场景:

门户(生产者)将一些消息发送到必须由多个应用程序(消费者)处理的总线 - PAYROLLAPP、HELPDESK 等。

消费者应用程序的多个实例可能正在运行，还有这些 可以添加实例/
动态删除

现在，确保 至关重要。每个应用程序只处理一次消息 即如果
PAYROLLAPP -1 处理消息，PAYROLLAPP -2 不应该处理它；当然，在
上图，HELPDESK – 1 必须处理它。总之，在多个实例的情况下，恰好一个
必须处理消息，一次

当我搜索答案时，大部分内容都是关于创建一个“选择性消费者”——一个基于某种逻辑接受/拒绝消息的消费者——请注意，不能对图中显示的应用程序进行任何更改/添加/包装图表;逻辑必须驻留在管理总线的提供程序中的某个位置

请指导一下。

在 Petter 的回答之后添加更多细节:

左侧虚线左侧的项目是“方法” - 纯 JMS、ESB、EAI

右侧虚线右侧的项目是“实现”

现在，最重要的部分 - 查询:

不考虑解决方案(纯 JMS、ESB、EAI)，这部分是
水平虚线下方(特定于应用程序的队列)需要
将要执行？

如何使用 ESB(JBoss ESB 等)，而不是“纯”JMS(Active MQ 等)，帮助/
阻碍？ ESB 是否比 JMS 提供任何优势，后者是“仅限 Java”(？)。我很困惑
– “ESB 或 JMS”，即使在引用以下线程之后:JMS and ESB - how they are related? .
它有一个回复说“JMS 不太适合
用于集成 REST 服务、文件系统、S/FTP、电子邮件、Hessian、SOAP 等。
使用原生支持这些类型的 ESB 可以更好地处理。例如，如果您有一个流程
在午夜转储 500MB 的 CSV 文件，并且您希望另一个系统提取该文件，
解析 CSV 并导入数据库，这可以通过 ESB 轻松完成 - 而
仅使用 JMS 的解决方案会很糟糕。同样，REST 服务的集成，具有负载平衡/
使用支持 HTTP/S 的 ESB 可以更好地完成到多个后端实例的故障转移
土生土长的。”它只会增加我的困惑!!!

使用 EAI 框架(Apache Camel 等)是一种完全不同于纯粹的方法吗？
JMS 还是 ESB 方法？如果是，利弊如何以及利弊是什么？

有人告诉我，仅靠 ESB 无济于事，需要使用 BPM(或其他什么？)来定义和
存储“路由”逻辑——这是真的吗？

Answer 1

1. Irrespective of the solution(pure JMS, ESB, EAI), does the part below the horizontal dotted line(application-specific queues) needs to be implemented?

消费者需要以与您选择的解决方案一起工作的方式实现，但您不必担心为每个消费者创建队列或分发逻辑(假设消费者可以直接从所选技术中消费)

1. How does the usage of ESB(JBoss ESB etc.), instead of ‘pure’ JMS(Active MQ etc.), help/ hamper? Does ESB provide any advantage over JMS which is ‘java-only’(?). I am hell confused – ‘ESB or JMS’, even after referring threads like these : JMS and ESB - how they are related?. It has one reply which says “JMS is not well suited for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are better handled with an ESB that supports these types natively. For example, if you have a process that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file, parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/ failover to multiple backend instances can be done better with an ESB supporting HTTP/S natively.” It only added to my confusion !!!

我的观点是 ESB 会使这个解决方案过于复杂。它旨在(除其他外)协助与不同技术的集成，但更简单的解决方案也可以做到这一点 - 例如 - Apache Camel 提供了一种使用多种传输(包括 ActiveMQ)的非常简单的通信方式。

并非所有 JMS 实现都支持来自其他语言的连接，但 ActiveMQ 确实使用了它的 STOMP 连接器。

1. Is the usage of EAI framework (Apache Camel etc.) an approach entirely different from the pure JMS or ESB approach? If yes, how and what are the pros/cons?

Apache Camel 和 JMS 是互补技术，JMS 和 ESB 也是如此。 Camel (& Spring Integration) 是轻量级、简单和便携的。 ESB 的重量要大得多，通常会导致与 ESB/应用程序服务器的更大耦合。

1. I was told that ESB alone won’t help, BPM(or something else?) needs to be used to define and store the ‘routing’ logic – is this true?

这取决于您的“路由”逻辑是什么，在我看来您不需要路由逻辑，您只需要保证交付给 1 个工资单消费者和 1 个服务台消费者。如果您希望根据数据的某些特征有选择地公开数据/调用服务，BPM 会更有用。

我强烈建议阅读 http://activemq.apache.org/virtual-destinations.html ，使用这些你会:

将消息发送到 ActiveMQ 代理，发送到 VirtualTopic，例如VirtualTopic.X

将 Payroll 和 Helpdesk 消费者注册为 ActiveMQ 在主题上动态创建的队列上的消费者 - 例如Consumer.Payroll.VirtualTopic.X.两个 Payroll 消费者都应该使用相同的字符串进行注册。

ActiveMQ 会自动保留一个标记，代表每组消费者尚未消费的内容。这意味着 100% 的消息将由工资单消费者处理，但消息永远不会发送给 > 1 工资单消费者。

随意添加/删除消费者。

N.B.I 相信其他产品，例如Apache QPID 提供了类似的功能 - 我只是最了解 ActiveMQ，并且已经使用这种方法取得了成功