我們已經將BizTalk作爲服務總線引入了我們的組織，它將一個新的Web GUI連接到衆多現有的後端系統。我們已經將我們現有的系統包裝爲服務（WCF）並將它們連接到BUS。我們也正在用我們的新網頁圖形用戶界面替換一些傳統的系統圖形用戶界面（確保我們複製現有的功能），但我很好奇我們是否應該通過總線公開所有的傳統服務/ api，直接連接到它們或以不同的方式組合它們並通過公共汽車展示它們。例如，可以說我們的客戶管理系統有5個現有的服務/ API，搜索，添加，檢索，更新，設置賬單詳細信息。一切都通過巴士嗎？
是否有意義通過總線暴露每個這些服務（某些argure它增加了延遲）？還是應該只公開粗粒度服務，如搜索，添加，檢索更新，而不是細粒度的服務？ GUI應該直接連接到細粒度的服務嗎？
我的印象是，在一個理想的SOA/ESB，你會組成兩個更新和設置的結算明細成一個粗粒度的服務下，這是正確的？
我想留真實的SOA/ESB模式，可能有人開導我請。
ESB最適用於構建「複合」應用程序。
首先，你必須公開很多離散應用程序的細粒度服務。
這爲構建複合應用程序設置了舞臺。
關鍵是要創建組合服務，這些組合服務在任何單個應用程序中都不存在。這些服務僅存在於ESB中。它們是從細粒度的服務構建而成的。
注意的是，複合材料依靠細粒度的服務，這兩個生活在ESB中，減少參與定位和執行細粒度服務的開銷。但是，真正的工作是由外部應用程序完成的，這會引入一些開銷。
注意到性能基於ESB的應用程序，因此完全違背了互動的其他方法，超過「潛伏」緊握你的手丟了即時，直接集成巨大的勝利。
與往常一樣，有不同的方式來看這個 - 如果你只是從總線的角度來看它（我不完全支持） - 然後使用BizTalk進行非聚合/複合服務幾乎沒有什麼價值（並且，正如你所提到的），你正在增加延遲等。 當然，即使在這種情況下，人們可以爭論BizTalk爲您提供的所有服務，例如監視，管理，可伸縮性等，但它如果不知道完整的情景，很難判斷這些相關性有多大。
但是，BizTalk也（有些人會認爲 - 主要）的集成引擎，往往是用來掩蓋從服務實現消費者。
這裏是一個可能的方案（同樣，不知道是否以及在何種程度上適用於您的情況） - 你有一箇舊的應用程序，你在一個服務包，以使SOA其中。 從現在起18個月內，您完成了替換服務的實施，但它具有不同的界面（因爲它具有更多功能） - 如果您有中間的BizTalk，您可以有一個圖層，可以將調用程序提供的舊格式映射到服務所需的新格式，反之亦然。這意味着你不必改變你的所有客戶端應用程序（無論如何，一次）。
所以 - 答案是，我猜 - 這取決於。