EMS、ESB 和 MOM、JMS
下列术语之间的关系和区别是什么？
- 企业消息传递系统 (EMS)
- 企业服务总线 (ESB)
- 面向消息的中间件 (MOM)
- Java 消息传递服务 (JMS)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
发布评论
评论（3）
橘虞初梦 2024-11-25 13:15:15
虽然 @ag112 的答案将“EMS”扩展为“企业消息系统”，但该缩写词有些含糊，“EMS”最常见的扩展可能是指 "="">TIBCO 企业消息传递服务，这是 TIBCO 特定的专有平台，支持 Java 消息传递服务 (JMS) 规范并且还添加了一些专有的扩展。 企业服务总线 (ESB) 是一个软件中间件抽象层，它通过以下方式将软件组件集成到大型系统中：事件驱动且通常基于开放标准的企业“消息传递引擎”。这些“面向消息的中间件 (MOM)”结构经常用于软件集成，并且可能会可以在面向服务的架构(SOA)的实现中看到。
最偏执的依靠 2024-11-25 13:15:15
EMS：任何允许多个应用程序通过面向消息的协议而不是 RPC 协议的解决方案因此基本上交互应用程序更多地绑定到消息数据而不是传输。
妈妈：我再次相信它可以被视为与EMS相同。
ESB：这是设计企业消息系统的一种方法。另一种方式是中心辐射模型。基本上，典型的消息传递系统涉及转换、中介、审计、路由和安全性等。ESB 与中心辐射指定哪个组件负责哪个部分。
JMS：它是Java平台提供的统一API，使开发人员可以直接使用JMS API，而无需担心底层消息传递框架是什么。消息传递实现必须符合 JMS 才能由 JMS API 处理。
~没有更多了~
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
好问题 - 服务总线和消息传递系统之间的关键区别在于消息传递系统上的数据约定。消息传递系统通常允许您发送所有内容：二进制 blob、XML、逗号分隔列表等。因此，应用程序 A 可以将逗号分隔的字符串发送到应用程序 B，B 发送一些 XML 到应用程序 C，C 发送一些其他 XML 到应用程序D .
这是消息传递，但不是“服务总线”。您可以说消息传递系统是“非类型化”（动态结构），而 ESB 是“类型化”（静态结构）。
在“服务总线”中，该总线上的所有应用程序和适配器都有一个通用数据定义（可以是具有共享 XSD 的 XML）。通用数据对象 (CDO)。任何连接的东西都必须发送符合此数据定义的信息。 ESB 应支持加载、共享和版本控制此通用数据定义。最大的优点是您可以连接一个组件（例如消息代理）并且它可以完成它的工作，而无需知道哪个应用程序发送了该数据以及该数据将发送到何处。
消息传递与 ESB 的权衡与其他非类型化/类型化选择类似：REST 与 SOAP、未经验证的 XML 与带有 XSD 的 XML、Groovy 与 Java，...
有些人会喜欢额外的结构（在纸上看起来不错 - 经理喜欢它） - 有些人会讨厌它（当版本更改时，东西会损坏，为了一点点添加，你必须更新所有内容 - 黑客不太喜欢它;-)
回到您的问题（重新排序）
面向消息的中间件（MOM）：用于各种语言的软件库，带有（或不带有）代理，以便在应用程序之间传递“消息”。比 TCP/IP 通信更进一步。 “消息”是结构化对象或文本字符串或二进制数据。通常，您比 TCP/IP 或 UDP 具有更高的可靠性。一些示例：TIBCO RV 和 EMS、IBM MQ、Apache ActiveMQ、ZeroMQ...
Java 消息传递服务 (JMS)：MOM 的通用 API 的定义 - 人们抱怨说，当您的应用程序从 MOM“X”切换到 MOM“Y”时，您需要重写消息传递代码。如果您针对 JMS 进行编码，则只需切换库即可，并且用于与 TIBCO EMS 一起使用的同一应用程序突然可以与 ActiveMQ 一起使用（反之亦然）
企业消息系统 (EMS)：TIBCO 的 JMS 实现（产品名称： TIBCO EMS)
企业服务总线 (ESB)： ESB 使用面向消息的中间件来集成应用程序、数据库、代理等。ESB 是添加了数据结构和结构定义管理的 MOM。将新组件连接到 ESB 时，您可以期望比将其连接到 MOM 时具有更多开箱即用的“兼容性”。在 ESB 中，对于组件必须执行哪些操作才能进行连接有更高的标准。我认为 TIBCO 的 ESB 称为 ActiveMatrix。
Good question - the crucial difference between a service bus and messaging system is the data convention on your messaging system. A messaging system typically let's you sent everything: binary blobs, XML, comma-separated lists, etc. So application A can send a comma-separated string to application B and B sends some XML to application C and C sends some other XML to app D.
That's messaging, but not a 'service bus'. You could say a messaging system is 'untyped' (dynamic structure) while an ESB is 'typed' (static structure).
In a 'service bus' you have a common data definition for all applications and adapters on that bus (could be XML with a shared XSD). Common data objects (CDOs). Anything that connects MUST send it's information adhering to this data definition. The ESB should support loading, sharing and versioning this common data definition. The big advantage is that you can connect a component (e.g. a Message Broker) and it does it's thing without having to know which application sent this data and where this data is going to.
The trade-offs of Messaging vs. ESB are similar to other untyped/typed choices: REST vs. SOAP, unvalidated XML vs. XML with XSD, Groovy vs. Java, ...
Some people will enjoy the additional structure (looks good on paper - managers like it) - some will hate it (stuff breaks when versions change, for a little addition you have to update everything - hackers don't like it so much ;-)
Coming back to your questions (reordered)
Message Oriented Middleware (MOM): software libraries for various languages with a broker (or not) to communicate 'messages' between applications. One step up from TCP/IP communication. 'messages' are structured objects or text strings or binary data. Usually you have additional reliability over TCP/IP or UDP. Some examples: TIBCO RV and EMS, IBM MQ, Apache ActiveMQ, ZeroMQ, ...
Java Messaging Service (JMS): the definition of a common API for MOM's - people complained that when your application switches from MOM 'X' to MOM 'Y' you need to rewrite the messaging code. If you code against JMS, you can just switch the libraries and the same application that used to work with TIBCO EMS suddenly works with ActiveMQ (or vice versa)
Enterprise Messaging System (EMS): TIBCO's implementation of JMS (product name: TIBCO EMS)
Enterprise Service Bus (ESB): an ESB uses a message oriented middleware to integrate applications, databases, brokers, etc. An ESB is a MOM with added data structure and structure definition management. When connecting a new component to an ESB, you can expect more 'compatibility' out of the box than when connecting it to a MOM. In an ESB there are higher standards on what a component must do to connect. TIBCO's ESB is called ActiveMatrix, I think.