我正在研究架构模式，准确地说是企业服务总线 (ESB)。看完这篇文章Enterprise Integration ，并且几乎没有经验，我想知道 BizTalk 是 ESB 还是只是 EAI(集线器/辐条或总线)？
我找到了 NServiceBus and Biztalk ，将 BizTalk 描述为中央消息代理。
考虑其他 ESB 框架(NServiceBus 和 Rhino Service Bus)。这些框架没有处理消息的中心点。
Biztalk 是 EAI 而不是 ESB？
非常感谢
BizTalk 被 Microsoft 抨击为具有 ESB 功能 - 请参阅 BTS ESB toolkit
然而，术语“ESB”涵盖了一个非常broad field ，并且关于 ESB 的确切定义存在很多主观性。恕我直言，BizTalk 声称作为 ESB 是全面的存在弱点(在该术语的 > 2010 定义中)。
BTS 起源于 Hub-and-Spoke EAI 时代，在 ESB 普及之前。 BTS 比同步进程更适合异步进程 - 延迟将根据系统负载、节流状态等而变化。 BTS 在服务和模式的版本控制方面很麻烦(需要新的部署) BTS 在管理许多服务时很麻烦(例如，使用 BizTalk 作为企业所有 5000 个 SOA/Web 服务的外观会很痛苦)FWIW 我们发现 BTS 非常适合:
我们所有的同步和异步 EAI(即主要 LOB 系统之间以及与贸易伙伴之间的正式集成契约(Contract))，以及大量适配器有助于集成大量协议(protocol)。 用于业务流程和业务监控功能 解决事务和交付可靠性问题 - Biztalk 具有重试、跟踪和恢复暂停消息的能力，这在不可靠的网络或与不可靠的系统集成时很有用。 更新 ，还有一些比较经验
BTS 非常集中——最终，即使是多服务器 BizTalk 集群/组也依赖于 Sql-Server。基于队列的 ESB 产品往往更加分散(在逻辑上和物理上)，因此丢失一些端点或队列服务器不应拖垮整个企业。 许多基于队列的 ESB 都是基于开源技术构建的，着眼于避免单一供应商锁定 许多当代 ESB 似乎采用 commodity-computing横向扩展的方法。使用 BizTalk 等产品进行扩展可能会变得昂贵。 从好的方面来说，不应低估 BTS 等商业产品的监控和管理功能 - 确保您正在考虑的任何 ESB 具有足够的审计、检测、重试和诊断(WMI/SNMP/SCOM 等)功能 - 您将需要一个仪表板来监控您的总线的运行状况，没有什么比不知道消息去了哪里更糟糕的了。在这里，集中管理和诊断是一个优势。