正好处理一次消息

Kal*_*ist 6 messaging esb jms

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

多个应用的​​多个实例.

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

请指导一下.

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

我目前的理解和方法

  1. 左点划线左侧的项目是"接近" - 纯JMS,ESB,EAI
  2. 右点划线右侧的项目是"实施"

现在,最重要的部分 - 问题:

  1. 无论解决方案(纯JMS,ESB,EAI)如何,是否需要实现水平虚线(特定于应用程序的队列)下方的部分?
  2. 如何使用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更好地完成." 这只会增加我的困惑!
  3. EAI框架(Apache Camel等)的使用方法是否与纯JMS或ESB方法完全不同?如果是,那么利弊如何?
  4. 有人告诉我ESB本身无济于事,需要使用BPM(或其他东西?)来定义和存储"路由"逻辑 - 这是真的吗?

Pet*_*der 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 有时几乎被用作消息传递的同义词。然而,消息传递(或消息队列、异步消息传递、MOM=面向消息的中间件等)可以简单地视为具有中央中继服务器的一系列类似传输协议。这根本不是 Java 独有的事情。我使用过的许多成功的 ESB 设置实际上都利用了消息传递主干

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

  2. 哈!也许是一名推销员?ESB 就可以了。消息服务器也适合您的情况,例如已经指出的 ActiveMQ。BPM 套件非常适合编排半自动化业务流程或集成层中有主要业务逻辑的情况。否则,请避免增加复杂性。