何时撰写可互操作的消息：在应用程序中还是在 Mirth 中？

Question

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

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

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

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

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

感谢您的建议。

Answer 1

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

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

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

Answer 2

(1)没有足够的信息来提供“专家建议”，也没有一个明确的技术上合理的答案

(2) 选项 (a) 在第一个版本中看起来成本最低且最容易实现，尤其是在重用稳定的测试库（如 HAPI

(3) 在您的设计中，将您的Enterprise service bus 视为black box component，并专注于设计接口并阐明asynchronous message sequences。这样，服务总线内部、消息路由和排队决策可以推迟到 deployment time 进行一些编码工作并遵循 adapter design pattern

(4) 措辞像“误用”、“侵入性”、“喜欢它”、“不错”这样的论点可能表明了一种有效的观点，但因此并不能产生可衡量、可验证的决定标准或绩效指标，不应单独使用

(5) 现在是应用决策过程并对各种选项进行权重评估的最佳时机。作为最小的正式输入，我推荐Plus/Minus/Interesting

(6)在您的决定中不应省略以下几点：

• 保护数据隐私（在某些国家，健康状况是受法律保护的私有财产）
• 容错（鲁棒性、可靠性、异常处理）
• 维护成本（您是否有合格的人员来维护它，解决方案能否自行监控和自动更正，否则必须有人手动查看数百万行日志）
• 开发成本（您是否已经拥有合格的人员，您可以重复使用多少行代码，以及您需要创建/调试多少行代码）

(7) 很抱歉，我的回答没有直接帮助，我的选择是以可靠的安全application server 撰写邮件，无论如何意味着在这种情况下，无论axons 或pseudopods 是如何连接的

---

最后但并非最不重要的一点： 记录您做出选择的原因 - 永远，这样当最初的决策者迷失在时间的流沙中时，您可以随时测试和验证您的假设