java - 何时撰写可互操作消息 : in app or Mirth?

Question

我们正在设计一个用于通信多个应用程序的架构，并且我们决定使用 Mirth 作为(伪)ESB。在我们的流程中，我们希望尽快将控制权交还给用户，因此当用户触发操作时(例如，填写表单后按“保存”按钮)，数据库中会进行一些(必要的)更改，然后必须将消息发送到另一个系统。用户不必等到消息发送，因此我们的应用程序在数据库更改完成后交还控制权。消息撰写在后台异步完成。但我们真的不知道应该遵循哪种方法:

a) 在我们的应用程序中启动一个新线程，在其中收集所有必要的数据(从“主数据”开始，即一些允许我们查找所有信息的主键)来填充 HL7 消息并将其发送到 Mirth 正在监听的队列。

b) 将“原始数据”发送给 Mirth 并将 HL7 消息组合委托(delegate)给它。Mirth 可以直接访问数据库以收集必要的数据，或者另一个选项可以调用我们自己的一些 REST/SOAP 服务。

对于选项 B，我们对如何调用 Mirth 有一些疑问:b.1) 我们的应用程序进行数据库修改并将主要数据写入队列(分布式事务)。b.2) 我们的应用程序进行数据库修改并调用 Mirth 发布的 SOAP 或 Rest 服务，它所做的就是在 Mirth 也在读取的队列上写入消息(我们的应用程序中没有分布式事务)。

一些人认为，在我们的应用程序中撰写消息并仅将 Mirth 用作经纪人是“滥用”Mirth。另一方面，有些 friend 发现从 Mirth 访问应用程序数据库非常具有侵入性，并且它不应该知道我们的架构。最后一个选项是，从 Mirth 调用应用程序服务，该服务返回 HL7 的所有必要信息，就像从应用程序向 Mirth 发送“主要数据”，只是在 Mirth 调用服务时取回它(将该数据作为参数传递)。

感谢您的建议。

Answer 1

我不确定 Mirth 是否适合用作企业服务总线，您的要求包括实时通知/事件以允许用户在提交表单后继续操作。

如果不了解更多信息(例如正在使用的架构)，我们无法为您提供真正的建议。

IMO，作为一个拥有 Mirth 集成以及设计数据库相关应用程序经验的人，我想说 Mirth 不是适合这项工作的工具。