处理消息的确保只处理一次

Question

请考虑附图中显示的场景：

Portal（生产者）将发送一些消息到总线上，这些消息必须由多个应用程序（消费者）- PAYROLLAPP、HELPDESK等进行处理。

可以运行多个消费者应用程序的实例，也可以动态添加/删除这些实例。

现在，关键是确保每个应用程序仅处理一次消息，即如果PAYROLLAPP-1处理了该消息，则PAYROLLAPP-2不应该处理它；当然，在上图中，HELPDESK - 1必须处理它。简而言之，在多个实例的情况下，只有一个必须处理消息，一次处理。

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

请指导同样的问题。

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

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

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

现在，重要的部分-查询：

1. 无论使用什么解决方案（纯JMS，ESB，EAI），下面水平虚线以下的部分（应用程序特定队列）是否需要实现？
2. 相对于“纯”JMS（Active MQ等），使用ESB（JBoss ESB等），有何帮助/阻碍？ESB比仅支持Java的JMS提供任何优势吗？我非常困惑 - “ESB还是JMS”，即使参考了这些主题：JMS和ESB-它们之间的关系？。它有一个回复说：“JMS不适合集成REST服务、文件系统、S/FTP、电子邮件、Hessian、SOAP等，这些最好用原生支持这些类型的ESB处理。例如，如果您有一个在午夜倾倒500MB CSV文件的过程，并且您希望另一个系统取出该文件，解析CSV并导入到数据库中，这可以轻松地通过ESB完成，而仅使用JMS的解决方案将很糟糕。同样，负载平衡/故障转移至多个后端实例的REST服务的集成可以通过支持HTTP/S的ESB更好地完成。”它只让我更加困惑!!!
3. 使用EAI框架（Apache Camel等）是否是一种与纯JMS或ESB方法完全不同的方法？如果是，如何以及有哪些优缺点？
4. 我被告知仅使用ESB将无济于事，需要使用BPM（或其他内容）来定义和存储‘路由’逻辑 - 这是真的吗？

- Kaliyug Antagonist

---

根据提供的各种输入，我决定采用Apache ActiveMQ的“虚拟目标”方法。我有一些疑问，但这些将在另一个主题中发布。 感谢大家的帮助和指导!!! - Kaliyug Antagonist

Answer 1

无论使用什么解决方案（纯JMS，ESB，EAI），在水平虚线以下的部分（应用程序专用队列）需要实现吗？

消费者需要以一种与您选择的解决方案相匹配的方式实现，但您不必担心每个消费者的队列创建或分配逻辑（假设消费者可以直接从所选技术中消耗）。

使用ESB（例如JBoss ESB）而不是‘纯’ JMS（例如Active MQ等）有何帮助/障碍？ ESB是否比‘仅限Java’的JMS提供任何优势？我非常困惑-'ESB或JMS'，即使参考了这些线程之一：JMS和ESB-它们如何相关？它有一个回复说：“ JMS不适合集成REST服务，文件系统，S / FTP，电子邮件，Hessian，SOAP等，这些最好由支持这些类型本机的ESB处理。例如，如果您有一个在午夜倾泄500MB的CSV文件的过程，并且您想让另一个系统接收文件，解析CSV并导入数据库，则可以通过ESB轻松完成-而仅使用JMS的解决方案会很糟糕。同样，将REST服务与负载平衡/故障转移到多个后端实例进行集成可以更好地使用支持HTTP / S的ESB。”它只增加了我的困惑！！！

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

并非所有JMS实现都满足从其他语言连接的要求，但ActiveMQ使用其STOMP连接器可以做到这一点。

使用EAI框架（例如Apache Camel）是一种完全不同于纯JMS或ESB方法的方法吗？如果是，有什么优缺点？

Apache Camel和JMS是互补技术，ESB和JMS也是如此。 Camel（＆Spring Integration）轻巧，简单且便携。 ESB更加重量级，通常会导致与ESB /应用程序服务器更大的耦合。

我被告知仅使用ESB是不够的，需要使用BPM（或其他东西）来定义和存储‘路由’逻辑-这是真的吗？

这取决于您的'路由'逻辑是什么，看起来您不需要路由逻辑，您只需要向1个工资单消费者和1个帮助台消费者提供保证的交付。 BPM将更有用，如果您希望根据该数据的某些特征选择性公开数据/调用服务。

我强烈建议阅读http://activemq.apache.org/virtual-destinations.html，使用这个功能，你可以：

1. 向ActiveMQ代理发送消息，进入虚拟主题（VirtualTopic），例如VirtualTopic.X。
2. 将Payroll和Helpdesk消费者注册为队列上的消费者，ActiveMQ会动态创建一个主题，例如Consumer.Payroll.VirtualTopic.X。两个Payroll消费者应该使用相同的字符串进行注册。
3. ActiveMQ将自动保留表示每组消费者未消费的标记。这意味着100％的消息将由Payroll消费者处理，但一条消息永远不会被发送到超过1个Payroll消费者。
4. 随时添加/删除消费者。

注意：我认为其他产品（例如Apache QPID）提供类似的功能，我只是最了解ActiveMQ，并且在这种方法上取得了成功。

- user793370

Answer 2

我理解了。这可能会对“纯”JMS有点棘手。

你实际上想做的是让门户发布消息到一个主题，但不让PAYROLLAPPs订阅该主题（因为他们都会收到该消息的副本）。因此，你需要在中间插入一些逻辑，将主题订阅的消息分发到每个应用程序类型的一个队列中。从那个队列中，可以使用JMS实现正常的负载均衡（竞争消费者模式）。

不同的JMS提供商有特殊的实现，可以完成此任务。比如ActiveMQ具有其虚拟目标，WebSphere MQ具有其服务器端订阅，可以从主题订阅到队列。如果你的JMS提供商没有任何处理方式，你可能需要考虑在你的拓扑中添加一些路由中间件。Apache Camel是一个好的、轻量级的中间件，但还有很多其他可以设置一些路由的中间件，而不影响真正的应用程序。

针对详细问题的更新：

1. 如果你的应用程序使用消息传递，则下面的队列肯定需要存在。"某些分布式逻辑"框不应该是必需的。"某些路由逻辑"框可以是ESB，或者在这种情况下，在消息服务器中实现，例如具有虚拟目标的ActiveMQ（或WebSphere MQ或其他许多选项）。

2. 在集成领域有很多流行词汇。简化来说，一个ESB是一个集成景观的核心服务器应用程序（或多个服务器的拓扑）。ESB服务器只包含从一个应用程序接收消息（文件等），并将其路由到多个应用程序、转换为其他格式、加密、将其从HTTP/SOAP等一种传输协议转换为文件等的逻辑和小型消息流。

JMS是一个相当令人困惑和误用的词。在过去几年中，Java在企业消息传递领域有所发展，因此JMS有时被用作与消息传递基本上同义的词语。然而，消息传递（或消息队列、异步消息传递、MOM=面向消息的中间件等）应简单地被视为一组类似的传输协议，它们具有中央中继服务器。它根本不是仅限于Java的事情。我使用过的许多成功的ESB设置实际上都利用了消息传递骨干网络。

1. 在您的情况下，我不会深入探讨ESB和EAI软件之间的学术/哲学差异。它们很可能为您提供几乎相同的功能。相反，看看硬性事实，如价格、支持、资源占用、监控、技术特点、学习曲线等。无论是Camel/ServiceMix、Mule、JBoss ESB、Microsoft BizTalk、IBM Message Broker、Tibco等。

2. 哈！也许是推销员吗？ESB就可以了。在您的情况下，消息服务器也可以胜任，例如已经指出的ActiveMQ。BPM套装适合编排半自动化业务流程或者如果集成层中有主要的业务逻辑。否则，避免增加复杂性。

- Petter Nordlander

---

嗨Petter，非常感谢您提供的起点！！！根据您的输入，我已经取得了一些进展并设计出了一个方案，因此有很多问题，正在等待您和社区其他成员的更多指导！ - Kaliyug Antagonist