到目前为止，我只看到了对开源消息代理（如 Apache ActiveMQ、JBoss HornetQ 和 Open Message Queue (OpenMQ)）的非 Java 客户端支持。
是否还有像 WebSphere、WebLogic 或 Tibco 这样的闭源产品提供对其 MOM 代理的非 Java 访问，使用记录在案的有线协议（与闭源二进制客户端库相反），允许用其他语言编写客户端？
随着产品（如 WebLogic）在 (EC2) 云中可用，这变得越来越有趣，因此开发人员可以使用云实例来开发和测试客户端应用程序，而无需购买和安装完整版本。
我没有明确的答案，因为我专门研究 WMQ。但是，我相信答案大部分是“不”。（稍后会详细介绍。）
关于 WMQ，IBM 提供可用的出口点来定制通道、API 调用和授权的行为。出口有很好的文档记录并在特定操作范围内执行狭窄的功能 - 即接收消息，启动连接等。这些是用 C 和最近的 Java 编写的。在大多数情况下，这些都是未使用的，我与之交谈的客户通常会引用复杂性。他们希望通过配置而不是通过低级代码来定制一些东西。我怀疑其他 MOM 供应商会遇到客户的类似要求。
这和你的问题有什么关系？我对此的看法是，如果客户不愿意编写功能有限的出口，那么他们编写一个功能齐全且强大的客户端，支持可靠的消息传递、一阶段和两阶段提交、客户端-侧出口、诊断和 WMQ 通道提供的所有其他功能。
假设这项任务是由一个能够编写该级别代码的开源团队承担的，谁会支持它？MOM 供应商目前在使用其专有客户端时提供端到端支持。使用社区支持的第三方客户端时如何解决故障单的想法对许多客户来说有点可怕。例如，IBM 为 WMQ 提供名为 SupportPacs 的附加组件。尽管有完全支持的 SupportPacs 并被视为产品扩展，但某些 SupportPacs 是按原样提供的。即使由供应商提供，我的许多客户也不会按原样运行代码。
最后，还有接口契约的概念。WMQ 支持一些带有很多选项的动词。底层通道协议要复杂得多。当 WMQ v7 出现时，通道具有相当多的新功能和调整。这在这种规模下是可能的，因为内部不向客户公开，因此 IBM 能够进行大规模更改，而不必担心对第 3 方客户产生负面影响。公开所有这些将创建一个或两个数量级的依赖关系，而不是仅公开 API 存在的数量级。
因此，根据我的理论（我不假装在这里代表 MQ 开发团队发言）大型 MOM 供应商在不将其通道协议暴露给独立开发人员方面具有既得利益。这里的新问题是我在上面提到的 AMQP。它定义了有线协议，并允许每个供应商编写兼容的产品。尽管这为您描述的开源解决方案提供了机会，但任何一种实现改进产品的能力都受到他们不拥有协议这一事实的限制。目前，虽然我不希望您会发现任何大型 MOM 供应商公开其用于 3rd 方开发的有线协议。也就是说，这只是一个猜测，如果我错了，我相信这里有人会跳进来提供反例。