7

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

多个应用程序的多个实例。

  1. 门户（生产者）将向总线发送一些消息，这些消息必须由多个应用程序（消费者）处理——PAYROLLAPP、HELPDESK 等。
  2. 消费者应用程序的多个实例可能正在运行，这些实例也可以动态添加/删除
  3. 现在，确保每个应用程序只处理一次消息至关重要，即如果 PAYROLLAPP -1 处理消息，则 PAYROLLAPP -2 不应该处理它；当然，在上图中，HELPDESK-1 必须对其进行处理。简而言之，在多个实例的情况下，只有一个必须处理消息，一次
  4. 当我搜索答案时，大部分内容都是关于创建一个“选择性消费者”——一个基于某种逻辑接受/拒绝消息的消费者——请注意，不能对显示的应用程序进行任何更改/添加/包装图表; 逻辑必须驻留在管理总线的提供程序中的某个位置

请指导一下。

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

我目前的理解和方法

  1. 左侧虚线左侧的项目是“方法” - Pure JMS,ESB,EAI
  2. 右虚线右侧的项目是“实现”

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

  1. 无论解决方案如何（纯 JMS、ESB、EAI），是否需要实现水平虚线下方的部分（特定于应用程序的队列）？
  2. 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 会很糟糕。同样，使用原生支持 HTTP/S 的 ESB 可以更好地集成 REST 服务，以及到多个后端实例的负载平衡/故障转移。” 它只会增加我的困惑！
  3. 使用 EAI 框架（Apache Camel 等）是完全不同于纯 JMS 或 ESB 方法的方法吗？如果是，如何以及有哪些优点/缺点？
  4. 有人告诉我，单独使用 ESB 无济于事，需要使用 BPM（或其他什么？）来定义和存储“路由”逻辑——这是真的吗？
4

2 回答 2

3

我明白了。对于“纯”JMS，这可能有点棘手。

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

不同的 JMS 提供者有可以完成这个任务的特殊实现 ActiveMQ 有它的虚拟目的地，WebSphere MQ 有它的服务器端订阅，可以从一个主题订阅到一个队列。如果您的 JMS 提供者没有任何方法来处理这个问题，您可能需要考虑将一些路由中间件添加到您的拓扑中。Apache Camel 是一个不错的、轻量级的，但还有很多其他的可以在中间设置一些路由而不影响实际应用程序。

更新详细问题

  1. 该行下方的队列必须肯定存在（如果您的应用程序使用消息传递）。不应该需要“一些分布逻辑”框。“某些路由逻辑”框可以是 ESB，或者在这种情况下，可以在消息传递服务器中实现，例如具有虚拟目标的 ActiveMQ（或 WebSphere MQ 或 RabbitMQ 等）。

  2. 在集成领域有很多流行语。简化（取决于你问谁 - ESB 也可以被视为一种架构模式，但让我们保持简单），ESB 是一个服务器应用程序（或实际上是多个服务器的拓扑），它是集成环境的核心。ESB 服务器只包含逻辑和小消息流，它们从一个应用程序获取消息（文件或其他内容）并将它们路由到许多应用程序，将它们转换为其他格式，加密，从一种传输协议（如 HTTP/SOAP）转换为文件等.

JMS 是一个相当混乱和误用的词。Java 在过去几年中在一定程度上主导了企业消息传递领域，因此 JMS 有时几乎被用作 Messaging 的同义词。然而，消息（或消息队列、异步消息、MOM=面向消息的中间件等）被简单地视为具有中央中继服务器的类似传输协议系列。Is 根本不是 Java 独有的东西。我使用的许多成功的 ESB 设置实际上都利用了消息传递主干

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

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

于 2012-04-27T22:19:49.220 回答
3
  1. 无论解决方案如何（纯 JMS、ESB、EAI），是否需要实现水平虚线下方的部分（特定于应用程序的队列）？

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

  1. 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 连接器。

  1. 使用 EAI 框架（Apache Camel 等）是完全不同于纯 JMS 或 ESB 方法的方法吗？如果是，如何以及有哪些优点/缺点？

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

  1. 有人告诉我，单独使用 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% 的消息将由工资单消费者处理，但消息永远不会发送给 > 1 个工资单消费者。
  4. 随意添加/删除消费者。

NBI 相信其他产品，例如 Apache QPID 提供类似的功能 - 我只是最了解 ActiveMQ，并且在这种方法上取得了成功

于 2012-05-01T22:35:13.850 回答