何时编写可互操作的消息:在应用程序中还是在欢乐中？

Question

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

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

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

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

有些人认为，在我们的应用程序中编写消息，并仅将Mirth用作代理，这是对Mirth的“误解”。另一方面，有一些伙伴发现从Mirth访问应用程序数据库非常麻烦，它不应该知道我们的模式。最后一种选择，从Mirth调用一个应用程序服务，为HL7返回所有必要的信息，就像从应用程序向Mirth发送“主要数据”，只是为了在Mirth调用服务时将其取回(将该数据作为参数传递)。

谢谢你的建议。

Answer 1

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

在不了解更多信息的情况下，例如正在运行的架构，我们不能给您真正的建议。

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

Answer 2

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

对于第一个版本，(2)选项(a)看起来最便宜、最容易实现，特别是在重用像HAPI这样的稳定测试库的情况下

(3)在你的设计中，把你的Enterprise service bus当作一个black box component，专注于设计接口和澄清asynchronous message sequences。这样，通过一些编码工作和遵循adapter design pattern，就可以将服务总线内部、消息路由和排队决策推迟到deployment time

(4)像"missusing“、"intrusive”、"like it“、"nice”这样的参数可能表明了一个有效的观点，但这样并不能创建可测量、可验证的决策标准或性能指标，也不应该单独使用

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

(6)在你的决定中，不应该忽略以下几点：

保护数据隐私(在某种程度上，健康状态是受法律保护的私有财产)(健壮性、可靠性、异常成本( exception handling)

• maintenance manually)

• development costs )(您是否有合格的人员来维护它，解决方案能否监控和自动更正，或者有人将不得不审查数百万行的日志和成本)(您是否已经有合格的人员，您可以重用多少行代码与您将不得不create/debug)

(create/debug))多少行代码

(7)我很抱歉我的回答没有直接的帮助，我的选择是，以便在可靠的安全application server中撰写消息，无论这在这种情况下意味着什么，也不管它的axons或pseudopods将如何连接

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