我们已经将BizTalk作为服务总线引入了我们的组织，它将一个新的Web GUI连接到众多现有的后端系统。我们已经将我们现有的系统包装为服务（WCF）并将它们连接到BUS。我们也正在用我们的新网页图形用户界面替换一些传统的系统图形用户界面（确保我们复制现有的功能），但我很好奇我们是否应该通过总线公开所有的传统服务/ api，直接连接到它们或以不同的方式组合它们并通过公共汽车展示它们。例如，可以说我们的客户管理系统有5个现有的服务/ API，搜索，添加，检索，更新，设置账单详细信息。一切都通过巴士吗？
是否有意义通过总线暴露每个这些服务（某些argure它增加了延迟）？还是应该只公开粗粒度服务，如搜索，添加，检索更新，而不是细粒度的服务？ GUI应该直接连接到细粒度的服务吗？
我的印象是，在一个理想的SOA/ESB，你会组成两个更新和设置的结算明细成一个粗粒度的服务下，这是正确的？
我想留真实的SOA/ESB模式，可能有人开导我请。
ESB最适用于构建“复合”应用程序。
首先，你必须公开很多离散应用程序的细粒度服务。
这为构建复合应用程序设置了舞台。
关键是要创建组合服务，这些组合服务在任何单个应用程序中都不存在。这些服务仅存在于ESB中。它们是从细粒度的服务构建而成的。
注意的是，复合材料依靠细粒度的服务，这两个生活在ESB中，减少参与定位和执行细粒度服务的开销。但是，真正的工作是由外部应用程序完成的，这会引入一些开销。
注意到性能基于ESB的应用程序，因此完全违背了互动的其他方法，超过“潜伏”紧握你的手丢了即时，直接集成巨大的胜利。
与往常一样，有不同的方式来看这个 - 如果你只是从总线的角度来看它（我不完全支持） - 然后使用BizTalk进行非聚合/复合服务几乎没有什么价值（并且，正如你所提到的），你正在增加延迟等。 当然，即使在这种情况下，人们可以争论BizTalk为您提供的所有服务，例如监视，管理，可伸缩性等，但它如果不知道完整的情景，很难判断这些相关性有多大。
但是，BizTalk也（有些人会认为 - 主要）的集成引擎，往往是用来掩盖从服务实现消费者。
这里是一个可能的方案（同样，不知道是否以及在何种程度上适用于您的情况） - 你有一个旧的应用程序，你在一个服务包，以使SOA其中。 从现在起18个月内，您完成了替换服务的实施，但它具有不同的界面（因为它具有更多功能） - 如果您有中间的BizTalk，您可以有一个图层，可以将调用程序提供的旧格式映射到服务所需的新格式，反之亦然。这意味着你不必改变你的所有客户端应用程序（无论如何，一次）。
所以 - 答案是，我猜 - 这取决于。