具有非Java客户端支持的商业JMS/MOM实现?

我没有明确的答案,因为我专门研究WMQ。然而,我认为答案在很大程度上是“不”。(稍后再详细介绍。)

关于WMQ,IBM提供了可用的出口点来定制通道、API调用和授权的行为。出口是非常有据可查的,并且在特定的行为范围内执行狭窄的功能-即接收消息,启动连接等。这些都是用C语言编写的,最近是Java编写的。在大多数情况下,这些都是未使用过的,我与之交谈的客户通常会提到复杂性。他们希望通过配置而不是通过低级代码来定制一些东西。我怀疑其他MOM供应商也有类似的客户要求。

这和你的问题有什么关系?我的看法是,如果客户不愿意用有限的功能编写出口代码,那么他们编写一个功能齐全、功能强大、支持可靠消息传递、一个和两个阶段提交、客户端出口、诊断以及所有其他功能的客户机似乎是很牵强的。wmq频道提供的内容。

假设这项任务是由一个能够执行这一级别代码的开源团队完成的,谁会支持它?MOM供应商目前在使用其专有客户机时提供端到端支持。当使用社区支持的第三方客户机时,如何解决问题单的概念对许多客户来说有点可怕。例如,IBM为WMQ提供称为SupportPacs的附加组件。尽管有完全受支持并被视为产品扩展的SupportPac,但仍按原样提供了一些SupportPac。我的许多客户不会按原样运行代码 即使是供应商提供的 .

最后,还有接口契约的概念。wmq支持一些带有很多选项的动词。底层通道协议要复杂得多。当WMQV7出现时,这些频道有了相当大的新功能和调优。在这种规模下,这是可能的,因为内部结构不会暴露给客户机,因此IBM能够在不担心对第三方客户机产生负面影响的情况下进行大规模更改。公开所有这些将创建对一个或两个更高的数量级的依赖关系,而不仅仅是对API的公开。

因此,根据我的理论(我不想在这里假装代表MQ开发团队),大型MOM供应商对 不 向独立的开发人员公开他们的通道协议。这里的新皱纹是我上面提到的AMQP。它定义了有线协议,并允许每个供应商对兼容产品进行编码。尽管这为您描述开放源码解决方案提供了机会,但是任何一个实现改进产品的能力都受到不拥有协议的限制。目前,我不希望你会发现任何一个大型的妈妈供应商为第三方开发公开他们的有线协议。也就是说,这只是一个猜测,如果我错了,我相信这里的人会跳进来提供反例。