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

我在工作中使用BizTalk做很多事情。我们有一些简单的点对点集成。我们有一些更复杂的点对点集成，带有高度定制的适配器和管道。我们有客户主数据、产品信息和报价到订单的分部门企业系统集成。这些都是单独的BizTalk应用程序。有些相当小，有些相当大。我们主要使用BizTalk进行点对点/多点解决方案，而不使用ESB模式。实施ESB意味着对总线本身和允许在总线上使用的企业消息标准的一定程度的治理。如果您将与大量具有不同格式的系统进行接口，ESB就有很多意义。如果您想实现的集成不是很雄心壮志，ESB可能过度。话虽如此，它是一种干净和可扩展的架构。您必须做出成本价值决策。

BizTalk也是一个复杂的系统，但由于所有的组件都能动起来，使得它的灵活性非常棒。但要准备好一个学习过程或者请一些咨询师的费用。

我刚刚被同事问了同样的问题，我和他说的是：

In most integration scenarios you can go quite far before using something like BizTalk. I would make sure that I couldn’t do the integration more simply before going with BizTalk.

Only if it seems that the integration solution needs to scale to high volumes with low latency (it’s got a fantastic asynchronous publish-subscribe mechanism), and you need fault tolerance (it’s got redundancy, scaling and message retry features) and governance over the solution (it’s got Business Activity Monitoring) would you really have strong arguments to consider using BizTalk. And if you know that there are multiple future integrations that will be needed then it gets really compelling to use BizTalk.

On the other hand you need to make sure the skills are available to operate the thing. It takes a while to learn and a paradigm shift for the developers of the systems. However its built from the ground up in .NET and SQL Server so there is quite a lot of familiarity in the tooling and concepts.

I think the key thing is to get the conceptual architecture of a solution right taking into account the non-functional requirements like performance, availability, extensibility, resilience, robustness, and scalability and making sure they are properly addressed by the technical design. You may find its cheaper to pay the 35k$ per CPU license for what BizTalk gives you out the box than to develop for all these NFRs.

我最近在客户端实施了全新的ESB Toolkit 2.0，对此非常满意。行程（请参见路由滑板图案http://www.enterpriseintegrationpatterns.com/RoutingTable.html）处理功能使Web服务的组合变得容易，灵活和快速。

I think it makes sense to have a data broker based on the requirements you described, but I personally don t think that BizTalk would be the best choice in your situation. For the type of integration you ve described, I would look at a hardware data broker appliance. Some that I ve seen work well are IBM DataPower, Vordel s appliance, and Layer7 s appliance. For the type of calls you ll be using this for, an appliance is ideal. They provide routing, transformation, and translation, plus they ll protect against things like schema poisoning. They ll also handle authorization, authentication, and auditing by linking it to your user store (I m guessing you have an Active Directory user store based on the environment you described, but it will also work with LDAP)

一种电器将是BizTalk或其他软件解决方案，成本拥有费用（无支持费用），并且任何电器的性能可能会比BizTalk高一个数量级。

我倾向于避免使用ESB术语，因为我认为它被高度重载；在一天结束时，在我听到的各种描述中，它只是一种模式，而BizTalk非常支持这种模式。

So - do I think BizTalk will fit what you wish to do? categorically yes. Do I think you re right to avoid point to point connections - also yes, but, like with any refactoring exercise for reuse, including any SOA initiative, you must consider how much change and now much re-use you expect to decide how far you re taking you re "decoupling" exercise.

你需要谈论延迟和吞吐量。其他的都只是空话。

这是一个非常明显的模式。通常，当您从A系统向B系统发送消息时，您会直接将A系统的格式转换为B系统所需的格式。当您拥有ESB时，您将System A的消息转换为ESB格式（即通用采购订单等），然后转换为System B所需的格式。这是两次转换而不是一次，并且总线模式要求每个消息都有一个动词（例如添加、删除、更新等）。这是一个非常重要的区别，也是使ESB在与许多参与系统进行集成时非常有用的原因。