我们应该介绍BizTalk/ESB吗？

我的公司即将实施一种新架构,我们在其中提出BizTalk(我们是微软商店)作为SOA中的企业服务总线(ESB)(请不要引用面向服务的歧义)环境.

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

我对ESB的一些理由是,总线会担心如何连接系统(每个系统都是不可知的,对任何其他系统一无所知)以及如何格式化/翻译信息.很有可能在未来,一些现有系统将换成我们公司家族中的新系统或系统.

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

不幸的是在公司历史上(在我预约之前)初步尝试引入BizTalk失败了,但我相信它有一个地方,我可以提供它.

我的问题可能不是关于BizTalk,而是在我描述的场景中ESB是否是一个好主意,何时引入ESB是有意义的？

好的.来自初级建筑组织的ESB指导Biztalk - http://msdn.microsoft.com/en-us/library/cc487894.aspx

我们使用BizTalk来做很多事情.他有一些简单的点插值.我们有一些更复杂的点集成与高质量的定制adpaters和管道.我们为客户掌握,产品信息和价格以及报价订单提供部门企业系统集成.这些都是单独的BizTalk应用程序.有些很小,有些很大.我们主要使用BizTalk在不使用ESB模式的情况下进行点对点/多点泄漏.ESB的实现意味着总线本身的治理水平以及将在总线上允许的企业消息标准.如果您将与大量具有大量不同格式的系统连接 - ESB很有意义.如果您想要实现的集成不那么雄心勃勃,那么ESB可能会过度.话虽如此,它是一个干净,可扩展的架构.您必须做出成本价值决定.

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