正好处理一次消息

Question

请考虑附图中所示的方案：

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

请指导一下。

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



1. 左点划线左侧的项目是＆＃39;接近＆＃39; - 纯JMS，ESB，EAI
2. 右边虚线右侧的项目是＆＃39;实施＆＃39;

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

1. 无论解决方案（纯JMS，ESB，EAI）如何，该部分 低于水平虚线（特定于应用程序的队列）的需求 要实施吗？
2. 如何使用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轻松完成 - 而a 只有JMS的解决方案会很糟糕。同样，REST服务的集成，负载均衡/ 使用支持HTTP / S的ESB可以更好地完成故障转移到多个后端实例 本地。“它只会增加我的困惑!!!
3. EAI框架（Apache Camel等）的使用方法与纯粹的方法完全不同 JMS还是ESB方法？如果是，那么利弊如何以及利弊是什么？
4. 我被告知ESB本身无济于事，BPM（或其他什么？）需要用来定义和 存储'路由'逻辑 - 这是真的吗？

Answer 1

我明白了这一点。对于＆＃34; pure＆＃34;这可能有点棘手。 JMS。

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

不同的JMS提供程序具有可以完成此任务的特殊实现 ActiveMQ has its Virtual Destinations，WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue。如果您的JMS提供程序没有任何方法可以处理此问题，您可能需要考虑在拓扑中添加一些路由中间件。 Apache Camel是一个很好的，轻量级的，但是有很多其他的可以在中间设置一些路由，而不会影响真正的应用程序。

  

    

更新详细问题

  

1. 该行下方的队列必须存在（如果您的应用程序使用消息传递）。 ＆＃34;一些发行人。逻辑＆＃34;不应该需要盒子。 ＆＃34;一些路由逻辑＆＃34; box可以是ESB，或者在这种情况下，可以在消息传递服务器中实现，例如具有虚拟目标的ActiveMQ（或WebSphere MQ或者RabbitMQ等）。

2. 整合领域有很多buzwords。简化（取决于你问的人 - ESB也可以看作是架构模式，但让它保持简单），ESB是一个服务器应用程序（或实践中多个服务器的拓扑），它是整合景观。 ESB服务器只包含从一个应用程序获取消息（文件或其他）的逻辑和小消息流，并将它们路由到许多应用程序，将它们转换为其他格式，加密，从一个传输协议（如HTTP / SOAP）转换为文件等

JMS是一个相当令人困惑和误用的词。 Java在过去几年中在某种程度上主导了企业消息传递域，因此JMS有时几乎被用作Messaging的同义词。但是，消息传递（或消息排队，异步消息传递，MOM =面向消息的中间件等）将被简单地视为具有中央中继服务器的类似传输协议的族。是不是只有Java的东西。我工作的许多成功的ESB设置实际上都利用了Messaging主干

1. 在您的情况下，我不会深入研究ESB和EAI软件之间的学术/哲学差异。他们很可能会为你做同样的事情。相反，看看诸如价格，支持，资源足迹，监控，技术等硬性事实。功能，学习曲线等。无论是Camel / ServiceMix，Mule，JBoss ESB，Microsoft BizTalk，IBM Message Broker，Tibco等。

2. 哈！它可能是推销员吗？ ESB会做得很好。消息服务器也可以用于您的情况，例如已经指出的ActiveMQ。 BPM套装适用于编排半自动化业务流程或集成层中存在主要业务逻辑。否则，避免增加复杂性。

Answer 2

  

  
1. 无论解决方案（纯JMS，ESB，EAI）如何，是否需要实现水平虚线下方的部分（特定于应用程序的队列）？
  

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

  

  
1. ESB（JBoss ESB等）的使用，而不是'纯'JMS（Active MQ等），如何帮助/阻碍？ ESB是否提供优于JMS的任何优势，即“仅限Java”（？）。我很困惑 - '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（＆amp; Spring Integration）轻巧，简单且便携。 ESB更重要，通常会导致与ESB /应用服务器的更大耦合。

  

  
1. 我被告知ESB本身无济于事，BPM（或其他什么？）需要用来定义和存储'路由'逻辑 - 这是真的吗？
  

这取决于您的路由＆＃39;逻辑是，它看起来像你不需要路由逻辑，你只需要保证交付给1payroll消费者和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％的消息，但永远不会将消息发送到＆gt; 1个工资单消费者。
4. 随意添加/删除消费者。

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