请考虑如附图所示的场景:
动态删除
PAYROLLAPP -1 处理消息,PAYROLLAPP -2 不应该处理它;当然,在
上图,HELPDESK – 1 必须处理它。总之,在多个实例的情况下,恰好一个
必须处理消息,一次
请指导一下。
在 Petter 的回答之后添加更多细节:
现在,最重要的部分 - 查询:
水平虚线下方(特定于应用程序的队列)需要
将要执行?
阻碍? 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 可以更好地完成到多个后端实例的故障转移
土生土长的。”它只会增加我的困惑!!!
JMS 还是 ESB 方法?如果是,利弊如何以及利弊是什么?
存储“路由”逻辑——这是真的吗?
最佳答案
- Irrespective of the solution(pure JMS, ESB, EAI), does the part below the horizontal dotted line(application-specific queues) needs to be implemented?
消费者需要以与您选择的解决方案一起工作的方式实现,但您不必担心为每个消费者创建队列或分发逻辑(假设消费者可以直接从所选技术中消费)
- 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 连接器。
- 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/应用程序服务器的更大耦合。
- 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 ,使用这些你会:
N.B.I 相信其他产品,例如Apache QPID 提供了类似的功能 - 我只是最了解 ActiveMQ,并且已经使用这种方法取得了成功
关于jms - 只处理一次消息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10354676/