我们需要在销售点系统和 java web 服务（在我们的网络之外）之间发送 XML 消息。这些消息包含非常敏感的数据。消息传递必须是安全的、事务性的并且具有故障转移的高可用性（24/7）。该解决方案需要开发执行以下操作的代理：
基于这些稍微简化的要求，您认为 Biztalk 会矫枉过正吗？ MSMQ/WCF 会在这里解决问题吗？
感谢您的帮助
胺
【问题讨论】：
IMO 如果您能够异步接收和传递消息，那么无论解决方案的其余部分如何，MSMQ（或其他面向消息的中间件）都是可靠的事务性传输的明显选择。 MSMQ 的日志也可用于审计和调试目的（但您需要一个归档日志的策略）。
对于轮询、路由、映射/代理和审计要求，您可以选择 BizTalk、其他 ESB 和 EAI 产品或 DIY 解决方案。
正如您所建议的那样，很难证明 BizTalk 在诸如此类的单个消息交换场景中的成本和学习曲线是合理的 - 您可能会破坏 .NET Windows 服务（例如，使用 WCF、Workflow Foundation、Transaction范围，一些用于映射的 XSLT 和数据访问层）。
但是，如果这不是一次性集成方案，并且需要进行额外的集成（需要集成更多的应用程序、更多的服务、额外的侦听器、不同的通信技术等），那么建议贵公司将从长远角度看待 EAI 和 ESB 技术。 IMO 集成的主要挑战不是最初的开发工作，而是持续的运营管理要求 - 例如。安全、审计、故障转移、监控、错误消息和其他异常的处理 - BizTalk 等产品在这些方面确实物有所值。
【讨论】：
无论哪种方式，您都应该使用 MSMQ。
如果您使用 .NET 中的 MSMQ，您应该知道它的限制：消息大小为 4 MB。
另一方面，BizTalk 有 MSMQ 适配器，它克服了这个限制（如果第二个 BizTalk 服务器在通道的另一端侦听）。除此之外，BizTalk 还为您提供以下功能：易于配置的消息跟踪、可视化转换映射。也可以在集群中设置（仅限Ent.版本）。
但问题是您能否（或者您想要）为它的服务器提供 biztalk 许可证和硬件（它比自定义 .net 解决方案要慢）。
【讨论】：
您想要并拥有足够的带宽来开发、监控和维护您自己的自定义解决方案吗？如果您不介意这样做，那么采用基于 .net 的自定义 MSMQ/WCF 解决方案可能会很好。
BizTalk 还将涵盖您列出的所有要求。有一个学习曲线，但它肯定不是不可逾越的。初始升级可能比自定义代码解决方案更长，但有相当大的好处，尤其是可靠地满足您的所有要求的好处：
如果 BizTalk 需要轮询 POS 系统，那么您无需担心使用 MSMQ。 BizTalk 可以可靠地处理消息传输（它们被持久化到 SQL Server，而 MSMQ 将消息持久化到磁盘）。
还要注意，使 MSMQ 具有高可用性的唯一方法是将其集群化。所以无论哪种方式，你都需要集群一些东西。
随着时间的推移，BizTalk 解决方案将更易于维护，尤其是在您只想更新转换时。使用版本控制，您可以以一种不需要停机的方式执行此操作。在不停机的情况下更新自定义解决方案将很困难。
过去，有些人在监控 BizTalk 是否有失败消息时遇到了困难，但我发现这比尝试监控消息队列更容易，尤其是使用 SCOM 或 BizTalk 360 等工具，后者通常需要更多自定义功能工作进行监控。只需确保在您的解决方案生命周期内的成本估算中包括监控。
如果您确实需要审核，那么 BizTalk 也可以满足您的需求。 MSMQ Journaling 将为您保留每条消息的副本，但没有重要的交易细节，也没有现成的方式来搜索或存档数据。
构建您自己的 .NET 客户端代码以使用 Java Web 服务可能需要大量工作，无论您采用哪种方式。对于 BizTalk，这意味着针对端点或针对 WSDL 运行向导。使用 WCF 意味着手动或在 svcutil 工具的帮助下完成所有工作。
【讨论】：