我被分配了一个小项目，并被指示使用 Mirth Connect 作为解决方案的一部分。我们目前不使用 Mirth，但因为我们有一个即将进行的项目需要接口引擎，所以我被要求在这个项目中使用它，以便获得使用它的经验。但是，我认为这对这个项目来说是一个糟糕的建议；我也知道我的老板不希望我仅仅为了学习而实施一些增加不必要的复杂性的东西。
话虽如此，我想确保我有正当理由建议不应将 Mirth Connect 用于此项目。我们都不太了解它，但我认为他已经确信它是所有与接口/Web 服务相关的东西的最终解决方案。我很感激我能从你们中比我有更多产品经验的人那里得到任何意见。
这是一个非常简单的项目，因为我们有一个客户端需要从那里向我们的系统发出一些请求，以便检索和更新数据。例如，他们将请求获取患者的人口统计信息、添加患者入院、请求从我们的应用程序中获取可能的护理设置列表等。对于这个项目，我们将不使用 HL7，而是使用一组预定义的XML 消息。
客户端的应用程序和我们的应用程序都驻留在客户端的网络上。
他们不想自己构建任何服务，所以我们构建的服务需要处理所有的工作。响应他们对服务的调用而返回的结果将作为 XML 返回。
在可预见的将来，没有将任何其他应用程序与他们或我们的应用程序集成的计划。
在我看来，最好的选择是我们构建一个独立的 Web 服务，该服务将接受他们的请求并发回 XML 响应。我只是看不出有任何理由将 Mirth Connect 包含在图片中（除了用于学习，但可以通过其他方式获得）。
你觉得呢？你有没有什么想法？如果客户端想要从我们的系统接收数据而没有接收机制，那么接口引擎是否不是一个好的选择？换句话说，他们想要进行 Web 服务调用，例如 GetCareSettings，并使用我们系统中所有可能的护理设置的 XML 表示来获得响应。在我看来，他们需要一个 Web 服务，以便 Mirth 用作发送结果的目的地。所有 Mirth 会发回一个 ACK 消息，对吗？（当然，除非它将数据写入客户端的另一个 Web 服务，他们说他们不想这样做。）
感谢您抽时间阅读。我希望我对 Mirth Connect 和接口引擎的使用缺乏知识和理解并没有使这个问题难以回答。