1

我们正在设计一种用于通信多个应用程序的架构，并且我们决定使用 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 调用服务时取回它（将该数据作为参数传递）。

谢谢你的建议。

4

2 回答 2

1

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

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

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

于 2014-11-24T18:17:05.727 回答
0

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

(2)选项 (a) 在第 1 版本中看起来最便宜且最容易实现，尤其是在重用HAPI等稳定测试库的情况下

(3)在您的设计中，将您的企业服务总线视为一个黑盒组件，并专注于设计接口和阐明异步消息序列。这样，服务总线内部、消息路由和排队决策可以通过一些编码工作并遵循适配器设计模式推迟到部署时间

(4) “误用”、“侵入性”、“喜欢”、“不错”等措辞可能表明观点有效，但不能创建可衡量、可验证的决策标准或绩效指标，不应单独使用

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

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

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

(7)很抱歉我的回答没有直接帮助，我的选择是在可靠的安全应用程序服务器中编写消息，无论在这种情况下意味着什么，也不管它的轴突或伪足如何连接

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

于 2014-11-12T10:40:47.800 回答