我们已将 BizTalk 作为服务总线引入我们的组织，它将新的 Web GUI 链接到许多现有的后端系统。我们已将现有系统包装为服务 (WCF)，并将它们连接到 BUS。
我们还用我们的新 Web GUI 替换了一些遗留系统 GUI（确保我们复制现有功能），但我很好奇我们是否应该通过 BUS 公开所有遗留服务/api，直接连接到它们或以不同方式组合它们并且通过总线暴露它们。例如，假设我们的客户管理系统有 5 个现有服务/api，搜索、添加、检索、更新、设置帐单详细信息。
通过 BUS 公开这些服务是否有意义（有人认为它会增加延迟）？或者 BUS 是否应该只公开粗粒度的服务，例如搜索、添加、检索和更新，而不是细粒度的服务？GUI 是否应该直接连接到细粒度服务？
我的印象是，在理想的 SOA/ESB 中，您会将更新和设置计费详细信息组合到一个粗粒度服务中，这是正确的吗？
我想忠于 SOA/ESB 范式，请有人赐教。
ESB 最适用于构建“复合”应用程序。
首先，您必须从大量离散应用程序中公开大量细粒度服务。
这为构建复合应用程序奠定了基础。
重点是创建任何单个应用程序中都不存在的复合服务。这些服务仅存在于 ESB 中。它们是由细粒度的服务构建的。
请注意，组合依赖于细粒度服务，这两者都存在于 ESB 中，从而减少了定位和执行细粒度服务所涉及的开销。但是，真正的工作是由外部应用程序完成的，这会带来一些开销。
请注意，基于 ESB 的应用程序的性能完全击败了其他交互方法，以至于让您对“延迟”束手无策，从而错过了直接、直接集成的巨大胜利。
通常情况下，有不同的方法来看待这个问题——如果你只是从总线的角度来看（我不完全赞成）——那么将 BizTalk 用于非聚合/复合服务几乎没有价值（并且，正如您所提到的）您正在增加延迟等。当然，即使在这种情况下，人们也可以争论 BizTalk 为您提供的所有服务，例如监控、管理、可伸缩性等，但很难判断这些服务有多少在不了解完整情况的情况下是相关的。
但是，BizTalk 也是（并且有些人会争辩 - 主要是）一个集成引擎，并且经常用于将消费者从服务实现中屏蔽掉。
这是一个可能的场景（同样，不知道这是否以及在多大程度上适用于您的案例） - 您有一个遗留应用程序，您将其包装在服务中以启用 SOA。从现在起 18 个月后，您完成了替换服务的实施，但它具有不同的界面（因为它具有更多功能） - 如果您在中间有 BizTalk，那么您有一个层，您可以将调用者提供的旧格式潜在地映射到服务要求的新格式，反之亦然。这意味着您不必更改所有客户端应用程序（无论如何一次）。
所以 - 答案是，我猜 - 这取决于。