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

到目前为止，我只看到非Java客户端支持开放源代码消息代理，如ApacheActiveMQ、JBossHornetQ和OpenMessageQueue（OpenMQ）

是否也有诸如WebSphere、WebLogic或Tibco之类的封闭源代码产品，它们使用文档化的wire协议（与封闭源代码二进制客户端库相反）提供对其MOM代理的非Java访问，从而允许用其他语言编写客户端

---

随着产品（如WebLogic）在（EC2）云中可用，开发人员可以使用云实例开发和测试客户端应用程序，而无需购买和安装完整版本，这一点变得越来越有趣。

我没有明确的答案，因为我专门研究WMQ。然而，我相信答案在很大程度上是“不”。（稍后会有更多内容。）

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

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

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

最后，还有接口契约的概念。WMQ支持几个动词和很多选项。底层通道协议要复杂得多。当WMQV7问世时，这些频道有了相当多的新功能和调整。在这种规模上，这是可能的，因为内部结构不向客户公开，因此IBM能够进行大规模更改，而不必担心对第三方客户造成负面影响。公开所有这些将创建比仅公开API更高一到两个数量级的依赖关系

---

因此，根据我的理论（我在这里并不假装代表MQ开发团队发言），大型MOM供应商在不向独立开发人员公开其通道协议方面有着既得利益。这里的新皱纹是我上面提到的AMQP。它定义了wire协议，并允许每个供应商编写符合要求的产品代码。尽管这为您描述的开放源代码解决方案提供了机会，但任何一个实现改进产品的能力都受到了限制，因为它们不拥有该协议。虽然目前我不认为你会发现任何大型MOM供应商为第三方开发而公开其有线协议。也就是说，这只是一个猜测，如果我错了，我相信这里会有人跳出来提供反例。

好吧，因为JMS是一个Java API，JMS客户机根据定义是Java客户机。也许在你的问题中，你应该用妈妈来代替“JMS代理”。