今天，如果我们使用 JMS API 构建应用程序（使用 MDB 作为消息侦听器，将其托管在 GlassFish 或 Weblogic 10 上），明天假设流量变得疯狂，我们能否在不更改代码的情况下将此应用程序移植到某些产品就像 Websphere MQ...因为理论上 MQ 更像是一个专门的 JMS 提供者...
【问题讨论】：
标签： jakarta-ee jms ejb ibm-mq java-ee-5
是和不是。 （所有最佳问题的答案总是“视情况而定”。）
如果应用程序遵循 JMS 规范，那么它应该在任何 JMS 兼容提供程序上运行不变。这是个好消息。
坏消息是，提供者如何实现 JMS 确实很重要。例如，JMS 1.1 规范的第 6.5 节就主题这样说：
许多 Pub/Sub 提供商将主题分组 进入层次结构并提供各种 订阅部分的选项 层次结构。 JMS 没有 限制什么主题对象 代表。它可能是一片叶子 主题层次结构，或者它可能是 层次结构的较大部分（对于 订阅一般类 信息）。
主题的组织和 订阅它们的粒度 是 Pub/Sub 的重要组成部分 应用程序的架构。 JMS 确实 未指定如何执行此操作的策略 需要被完成。如果一个应用程序 利用特定于提供商的 主题分组机制，它应该 记录这个。如果应用程序是 使用不同的提供商安装， 管理员的工作是 构建一个等价主题 架构和创建等效 主题对象。
这意味着规范的某些部分对 JMS 传输提供者的解释是开放的。移植应用程序时如何映射这些差异将由应用程序所有者决定。
这个问题的另一个方面是，即使两个传输提供者严格遵循规范，API 背后的行为也可能不同。这方面的一个例子是连接管理。一些提供者将失败的连接透明地转移到客户端，其他提供者要求客户端在失败后重新驱动连接序列。这两种方法都可以 100% 兼容 JMS，但都需要不同的应用程序逻辑。
所以答案是，坚持 JMS API 可以让您非常接近完全可移植，并且所需的移植量取决于传输提供商如何解释部分规范和/或实现的模棱两可的功能的差异在规范中。
【讨论】：
开发人员很容易受到诱惑（或有时被要求）在基于 JMS 的应用程序中使用供应商专有功能。在我使用 JMS 的短时间内，我注意到开发人员可能会求助于专有 API 的四个原因。
首先，从命名服务获取Destination 和ConnectionFactory 对象很不方便，尤其是对于不希望在能够编写应用程序之前花时间学习JMS 管理命令的JMS 新手来说。使用供应商专有函数直接创建Destination 和ConnectionFactory 对象可能更方便。
其次，JMS 产品通常会提供超出 JMS 规范中定义的服务质量。如果这些服务质量与Session、Producer 或Consumer 相关，那么供应商自然会在这些类型上提供专有的set<Name>() 操作。简而言之，并非所有专有的服务质量都可以封装在管理对象中。
第三，当一个与 JMS 相关的操作失败时，它会抛出一个（子类型）JMSException。根据异常的性质，应用程序的开发人员可能希望以多种方式之一处理捕获的异常。但是，JMS 规范指出，JMSException 提供的三条信息中有两条是 JMS 供应商专有的。因此，开发人员在决定如何处理异常时可能需要依赖包含在异常中的供应商专有信息。
最后，JMS 指定消息由三部分组成：(1) 标头字段，(2) 任意属性（即 name=value 对），以及 (3) 正文. (2) 的预期用途是支持消费者应用程序中的灵活消息选择。例如，在伦敦运行的生产者应用程序可能会在发送消息之前将 location=London 添加到消息的属性中。然后，消费者应用程序可以使用消息选择器"(location = 'London')" 来确保它只接收具有该属性值的消息。听起来不错。不好的一点是，JMS 规范保留了以JMS_<vendor> 开头的属性名称供 JMS 供应商使用，并且一些供应商使用这些属性来指定基于每条消息的专有服务质量。希望使用专有的按消息服务质量的开发人员必须修改生产者应用程序的代码，以便在发送消息之前设置专有属性。
T.Rob 关于主题层次结构的警告是另一个需要警惕的问题。
【讨论】：
WebSphere MQ 是一个非常成熟、稳定的平台——据我所知——完全符合 JMS 标准。许多组织使用 JMS over MQ 作为他们的传输。我曾在几个同时使用 JMS 和本机 MQ 机制与 MQ 层通信的项目中工作过，我没有遇到任何关于 IBM JMS 实现的抱怨。不过，我没有与任何更改过 JMS 提供程序的人合作过......
IBM 提供了一堆仅引用 javax.jms 包的 Java 库，因此只要您没有让任何供应商特定的增强功能进入您的代码，您应该能够插入 MQ 库以拥有 MQ成为您的 JMS 提供商。 （您可能需要使用 MQ 工具进行一些管理以执行设置 JMS 订阅等操作，但是……我没有使用 MQ 的 JMS 方面，只使用了核心库。）
查看this IBM page 了解有关 MQ JMS 库的更多详细信息。
如果您仅使用 WebSphere MQ 作为示例，那么是的，您可能仍需要检查候选供应商是否符合规范，但 JMS 已经存在一段时间了，我认为所有大玩家的产品都将是合适的 JMS 提供者。
【讨论】：
由于 JMS 是一个相对简单的 API（与 JDBC 等相比），它在实现之间保持相当可移植性，前提是您 take some basic measures to begin with。
就从 WebSphereMQ 获得更好的性能而言，我不确定您是否会发现这种情况。如果您使用的是点对点，也许。但如果你在做 Pub/Sub，那是不太可能的。请参阅这个benchmark，它承认是由竞争对手发布的，但它使用第三方基准，实际上对一些开源参赛者非常慷慨。
【讨论】：