将JMS应用程序移植到MQ

Question

今天如果我们使用JMS API构建一个应用程序（使用MDB作为消息监听器，托管它可以说是GlassFish或Weblogic 10），明天可以说流量变得疯狂，我们可以移植这个应用程序而不需要对某些产品进行代码更改像Websphere MQ ...因为理论上MQ更像是一个专用的JMS提供者......

Answer 1

是和否。 （所有最佳问题的答案总是“它取决于。”）

如果应用程序遵守JMS规范，那么它应该在任何符合JMS的提供程序上保持不变。这是个好消息。

坏消息是提供商如何实施JMS确实很重要。例如，JMS 1.1规范的6.5节说明了主题：

  

许多发布/订阅提供商分组主题   进入等级并提供各种各样的   订阅部分的选项   层次结构。 JMS没有   限制什么是Topic对象   代表。它可能是一片叶子   主题层次结构，或者它可能是一个   层次结构的较大部分（for   订阅一般班级   信息）。

     

主题和组织   订阅的粒度   是Pub / Sub的重要组成部分   应用程序的架构。 JMS做到了   没有为此指定政策   需要被完成。如果申请   利用特定于提供者的优势   主题分组机制，它应该   记录这个。如果申请是   使用其他提供商安装，   这是管理员的职责   构建一个等价的主题   架构和创建等价物   主题对象。

这意味着规范的某些部分可以解释JMS传输提供程序。应用程序所有者将决定在移植应用程序时如何映射这些差异。

这个问题的另一个方面是，即使规范严格遵循两个传输提供程序，API背后的行为也可能不同。一个例子是连接管理。某些提供程序通过透明方式将连接失败到客户端，其他提供程序要求客户端在发生故障后重新驱动连接顺序。两种方法都可以100％兼容JMS，但两者都需要不同的应用程序逻辑。

所以答案是坚持使用JMS API使您非常接近完全可移植性，并且所需的移植量取决于传输提供程序如何解释部分规范和/或实现的模糊特征的差异在规范中。

Answer 2

开发人员很容易在基于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 添加到消息的属性中。然后，Consumer应用程序可以使用消息选择器"(location = 'London')"来确保它仅接收具有该属性值的消息。听起来不错。糟糕的是，JMS规范保留以JMS_<vendor>开头的属性名称供JMS供应商使用，并且一些供应商使用这些属性来基于每个消息指定专有服务质量。希望使用专有的每消息服务质量的开发人员必须修改生产者应用程序的代码，以便在发送消息之前设置专有属性。

T.Rob关于主题层次结构的警告是另一个需要警惕的问题。

Answer 3

WebSphere MQ是一个非常成熟，稳定的平台 - 据我所知 - 完全符合JMS标准。许多组织使用JMS over MQ作为传输。我曾在几个使用JMS和本机MQ机制与MQ层进行通信的工作，我没有遇到任何关于IBM JMS实现的抱怨。我没有和任何改变了JMS提供商的人合作过，但是......

IBM提供了一堆只引用javax.jms包的Java库，因此只要您没有在代码中使用任何特定于供应商的增强功能，您就应该能够在MQ库中插入MQ以获得MQ成为您的JMS提供商。 （您可能需要使用MQ工具进行一些管理来执行诸如设置JMS预订之类的操作，但是......我没有使用MQ的JMS方面，只使用了核心库。）

查看this IBM page以获取有关MQ JMS库的更多详细信息。

如果您只使用WebSphere MQ作为示例，那么您可能仍需要检查候选供应商是否符合规范，但JMS已经存在了一段时间，我认为所有大型企业的产品都是合适的JMS提供商。

Answer 4

由于JMS是一个相对简单的API（与JDBC等相比），如果你take some basic measures to begin with，它在实现之间仍然可以移植。

就从WebSphereMQ获得更好的性能而言，我不确定您会发现情况如此。如果你正在使用点对点，也许吧。但如果你正在做Pub / Sub，那就不太可能了。请参阅竞争对手公认的benchmark，但它使用的是第三方基准，对一些开源竞赛者来说实际上非常慷慨。