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