跨语言消息传递[关闭]

Question

我们使用以 Java 为中心的工具，该工具在内部使用 JMS 并与外部 Java 软件进行通信。我们现在必须为 C# 应用程序设置一个新接口。我们的 JMS 提供程序提供了一个应该可以工作的 C# 实现，但我不完全确定 JMS 是在这种情况下要走的路。它将在 C# 应用程序中引入新的特定于供应商的依赖项，用于实现细节和客户端支持。

一些谷歌搜索让我找到了 STOMP，它似乎是一个已建立的线路级协议，由多个支持 JMS 的消息代理（hornetq、activemq、...）支持，但 C# 中似乎明显缺乏实际客户端（和java在某种程度上）。如果不深入研究，我也不完全确定对“文本”的强调在哪里发挥作用？不支持二进制对象吗？

另一种解决方案可能是 AMQP，它是另一种线级协议，但 1.0 规范尚未发布，我们厌倦了实施已有 4 年历史的 0.9.1 规范，因为 1.0 似乎发生了很大变化。

考虑到安全性、支持、事务性、标准合规性、可移植性，哪种解决方案最适合语言间异步消息传递……请注意，具有适当 WS-* 的soap 不是此特定接口的选项。

EDIT1： 我看到过诸如Cross-platform, cross-language messaging system? 之类的问题，但它们似乎专注于一种适用于多种语言的特定工具。我实际上是在寻找一个可以由多个供应商实现或可以实现的符合标准的协议。

Answer 1

一种选择是将 C# 客户端从底层的特定通知协议中抽象出来，并让它在输入端口和输出端口级别上工作，其中输入端口和输出端口是使用通用互操作适配器实现的 - 一种关系数据库、Web 服务、特定文件夹中的 xml 文件。

您有责任提供适配器以及适配器和消息传递子系统之间的桥梁，但有明显的好处：企业环境之间的相互义务是在非常通用的级别上定义的。您甚至可以在某一天更换消息传递子系统并保留所有输入和输出端口。换句话说，C# 客户端甚至不会注意到您将 JMS 替换为另一个消息传递基础架构，因为它仍然从同一组适配器发送/接收数据。

Answer 2

我不知道我是否正确理解了您的问题，但是 RabbitMQ 是一个 AMQP 实现，具有 C# 和 Java 的绑定。

为了防止“C# 应用程序中出现新的供应商特定依赖项”，您可能需要查看Messaging Component in the Spring.Net framework 以及他们的related AMQP for .Net 项目。这允许您将 POCO 和业务逻辑与消息传递中间件和基础架构分开。