跨语言消息传递[关闭]

Posted 2023-02-16

【中文标题】跨语言消息传递[关闭]

【英文标题】：Cross Language Messaging [closed]

【发布时间】：2012-10-08 09:28:42

【问题描述】：

我们使用以 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? 之类的问题，但它们似乎专注于一种适用于多种语言的特定工具。我实际上是在寻找一个可以由多个供应商实现或可以实现的符合标准的协议。

【问题讨论】：

无论您做什么，您都将介绍一些供应商或消息传递平台特定的功能。您可以改用电子邮件，因为它是跨平台的，但它是特定于 SMTP 的。

协议特定不是问题，只要协议是一个完善的标准。如果 SMTP 仅可从一个特定供应商处获得或因供应商而异，那将是一个问题

JMS 是一个建立接口，需要您为正在使用的服务器加载适当的驱动程序。您应该能够编写核心代码，这样就可以在不更改代码的情况下配置所用服务器的选择。

在 java 中是的，但不是来自 .NET，我们需要跨语言解决方案。

你能用你自己的通用接口包装驱动程序，以便只需要替换这个组件吗？

【参考方案1】：

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

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

【讨论】：

我们的软件团队没有 C# 知识，因此我们很难支持我们自己的适配器。抽象实际的消息传递后端始终是解决方案的一部分，尽管抽象必须由 C# 应用程序团队管理。

这就是为什么我推荐一组你确信 C# 没有问题的通用适配器。我们维护一个类似的解决方案，唯一的区别是我们使用 MSMQ 作为消息传递子系统，并且 shell 是用 C# 编写的。通用适配器的想法非常有效，php 和 Java 人员在写入关系数据库和提供他们自己的基于 WSDL 规范的 Web 服务方面没有问题。这就是为什么我相信类似的方法对你有用。

是的，但是必须有人维护 C#-java 桥，这意味着我们必须读取 MSMQ，他们必须写入 JMS，或者我们必须找到另一个可以解决问题的协议（不是 web 服务，当然也不是数据库/文件系统）。

我们的方法中没有互操作桥。例如，Java 人员使用存储过程在端口（数据库）中创建通知，我们提供读取数据库并将通知发送到 MSMQ 的系统核心。因此，所有外部系统都不知道通知引擎的内部结构。数据库/webservices/filesystem 是您正在寻找的协议。就像：他们 -> 输入（数据库/webservice） -> 你 -> JMS -> 你 -> 输出（数据库/webservice） -> 他们。他们只知道常见的适配器，您提供基础架构的内部详细信息。

【参考方案2】：

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

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

【讨论】：

因为 AMQP 1.0 还没有最终确定，所以我不确定这是否是目前最好的选择？

Spring.Net 的链接消息组件也具有其他 MQ（例如 TIBCO EMS、Apache ActiveMQ/NMS）。

这可能超出了原始问题的范围，但是 spring 在 .NET 中的依赖程度与在 java 中的依赖程度一样大吗？您能否像使用 JMS api 一样简单地使用消息传递组件，而无需整个 Java EE 堆栈？免责声明：我没有 C# 和 Spring 的背景。

我在 Java 方面的背景有限，但 .Net Spring.net 通常不是侵入性的。此外，spring 几乎没有外部依赖项（除了 .Net 框架），并且仅在您需要该功能时才需要这些依赖项（例如，仅在使用 Spring.Data.NHibernate 时才需要 nhibernate）。