今天，如果我们使用 JMS API 构建一个应用程序(使用 MDB 作为消息监听器，将它托管在 GlassFish 或 Weblogic 10 上)，明天假设流量变得疯狂，我们可以在不更改代码的情况下将此应用程序移植到某些产品，如 Websphere MQ ...因为理论上 MQ 更像是一个专门的 JMS 提供者 ...
最佳答案
是和否。 (所有最好问题的答案总是“视情况而定”。)
如果应用程序符合 JMS 规范，那么它应该在任何符合 JMS 的提供程序上原样运行。这是好消息。
坏消息是，提供者如何实现 JMS 确实很重要。例如，JMS 1.1 规范的第 6.5 节关于主题是这样说的:
Many Pub/Sub providers group topics into hierarchies and provide various options for subscribing to parts of the hierarchy. JMS places no restrictions on what a Topic object represents. It might be a leaf in a topic hierarchy, or it might be a larger part of the hierarchy (for subscribing to a general class of information).
The organization of topics and the granularity of subscriptions to them is an important part of a Pub/Sub application’s architecture. JMS does not specify a policy for how this should be done. If an application takes advantage of a provider-specific topic grouping mechanism, it should document this. If the application is installed using a different provider, it is the job of the administrator to construct an equivalent topic architecture and create equivalent Topic objects.
这意味着规范的某些部分对 JMS 传输提供程序的解释是开放的。在移植应用程序时，应用程序所有者将决定如何映射这些差异。
这个问题的另一个方面是，即使两个传输提供者严格遵守规范，API 背后的行为也可能不同。这方面的一个例子是连接管理。一些提供者对客户端透明地故障连接，其他提供者要求客户端在失败后重新驱动连接序列。这两种方法都可以 100% 兼容 JMS，但都需要不同的应用程序逻辑。
所以答案是坚持 JMS API 可以让你非常接近完全可移植，所需的移植量取决于传输提供者如何解释规范的部分和/或规范中模棱两可的已实现功能的差异.
关于jakarta-ee - 将 JMS 应用程序移植到 MQ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5643936/