architecture - 我们应该引入 BizTalk/ESB 吗？

Question

我的公司即将实现一个新架构，我们在其中提出了 BizTalk(我们是 Microsoft 商店)作为 SOA(请不要引用面向服务的歧义)环境中的企业服务总线 (ESB)。

我们的业务是通过我们的新订单捕获 GUI 接收订单，该 GUI 必须连接到我们的客户数据库、产品目录、订购系统和其他一些辅助系统，每个系统都将作为 WCF 服务公开，然后将订单传递给我们的订单管理和其他用于履行的下游系统，最后到我们的计费系统进行开发票。目前，每个系统都有自己的 GUI，并使用手动过程在它们之间传递信息，为了实现自动化和集成，自然的想法是引入 ESB 来连接它们。

我对 ESB 的一些基本原理是，总线将担心如何连接系统(每个系统都是不可知的，并且对任何其他系统一无所知)以及如何格式化/翻译信息。将来，很有可能将某些现有系统替换为我们公司家族中的新系统或系统。

这对我来说似乎很有意义，但我现在遇到了一些阻力，即为什么在点对点解决方案足够时引入它。

不幸的是，在公司历史上(在我任命之前)，引入 BizTalk 的初步尝试失败了，但我相信它有一席之地并且我可以交付它。

我的问题可能不是关于 BizTalk，而是 ESB 在我所描述的场景中是否是一个好主意，什么时候引入 ESB 才有意义？

Answer 1

好的。 ESB 指导性架构组的 Biztalk 指南 - http://msdn.microsoft.com/en-us/library/cc487894.aspx

我们在我工作的地方使用 BizTalk 来做很多事情。他有一些简单的积分。我们与高度定制的适配器和管道进行了一些更复杂的点集成。我们有针对客户主数据、产品信息和价格以及订单报价的部门企业系统集成。这些都是单独的 BizTalk 应用程序。有些很小，有些很大。我们主要使用 BizTalk 进行点对点/多点解决方案，而不使用 ESB 模式。 ESB 的实现意味着总线本身的治理水平和总线上允许的企业消息标准。如果您将与具有大量不同格式的大量系统交互 - ESB 非常有意义。如果您想要实现的集成不那么雄心勃勃，那么 ESB 可能是矫枉过正。话虽如此，它是一个干净且可扩展的架构。您必须做出成本值(value)决定。

BizTalk 也是一个复杂的野兽，但所有的移动部件都具有一定程度的灵 active ，非常棒。但要为学习曲线或一些顾问费用做好准备。