我们需要在销售点系统和java webservice（我们的网络之外）之间发送XML消息。消息包含非常敏感的数据。消息传递必须是安全的，事务性的，并且具有高可用性（24/7）并具有故障转移功能。该解决方案需要开发一个执行以下操作的代理：
基于这些有些简化的要求，您是否认为Biztalk会过度杀伤？ MSMQ / WCF会在这里耍手段吗？
感谢您的帮助
胺
答案 0 :(得分：4)
IMO如果您能够异步接收和传递消息，那么MSMQ（或其他面向消息的中间件）将成为可靠的事务传输的明显选择，无论其他解决方案如何。 MSMQ的日志记录也可用于审计和调试目的（但您需要一种策略来存档日志）。
对于轮询，路由，映射/代理和审计要求，您可以选择BizTalk，其他ESB和EAI产品或DIY解决方案。
正如您所建议的那样，很难证明BizTalk在单一消息交换场景中的成本和学习曲线是合理的 - 您可能会破坏.NET Windows服务（例如使用WCF，Workflow Foundation，Transaction）几天内，范围，一些用于映射的XSLT和一个数据访问层。
但是，如果这不是一次性集成方案，并且需要进行额外的集成（更多应用程序要集成，更多服务，额外的侦听器，不同的通信技术等），那么您的公司最好是从长远角度看待EAI和ESB技术。 IMO集成的主要挑战不是最初的开发工作，而是正在进行的运营管理要求 - 例如安全性，审计，故障转移，监控，处理不良消息和其他例外 - BizTalk等产品确实值得花费。
答案 1 :(得分：3)
您是否希望并拥有开发，监控和维护自定义解决方案的带宽？如果您不介意这样做，那么继续使用基于.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工具的帮助下完成所有操作。
答案 2 :(得分：1)
你应该选择MSMQ运输。
如果您使用.NET中的MSMQ，您应该知道它的限制：邮件大小为4 MB。
另一方面，BizTalk有MSMQ适配器克服了这个限制（如果第二个BizTalk服务器在通道的另一端监听）。在BizTalk的顶部为您提供以下功能：易于配置的消息跟踪，可视化转换映射。它也可以在集群中设置（仅限Ent。版本）。但问题是你能否（或者你想要）为它的服务器提供biztalk许可证和硬件（它比定制的.net解决方案慢）。