關于如何把必要的企業服務總線轉化為面向服務的架構一直存在著爭論。強調ESB對于SOA重要性的人有著自己的關注點，而質疑ESB作為SOA基礎的觀點也有著更深層次的考慮，同時是對前一種觀點走向極端的一種有益的矯正。

    使用SOA架構來搭建IT系統是一個復雜的過程，而ESB的使用則簡化了這一過程。“面向服務的架構(SOA)從根本上改變了對企業應用的設計、開發和集成的方式。它倡導企業應用的模塊化服務、便捷集成和重用。然而SOA也帶來一系列的技術挑戰，如可靠的消息傳遞、服務的虛擬化、服務的發現和調用、策略管理等等。而ESB做為SOA架構的中間層，幫助企業有效解決了這些難題，所以企業往往會從ESB入手，來實施SOA。” 甲骨文公司大中華區高級技術經理黃建勇這樣向記者解釋ESB在SOA中的作用。

    ESB在SOA中的重要作用已經得到了人們的共同認可，Forrester Research公司發表的一份報告指出，持續采用SOA能很好的體現ESB的思想，并且把ESB稱為“SOA的主要切入點”。 SOA廠商更是紛紛推出自己的ESB產品，并不斷地向用戶宣揚ESB可以幫助他們簡化SOA的難題，降低SOA實施的成本。

    ESB不等于SOA
    但是，人們對ESB的追捧正在使SOA的實施走向“迷途”。利用ESB來輔助SOA實施變成了以ESB為中心來構建SOA應用，手段變成了目的，技術篡奪業務成為了SOA的重心，這嚴重地背叛了SOA的本原特性。
    IBM WebSphere SOA與J2EE顧問Bobby Woolf最近寫了一篇文章《以ESB為中心的架構是實施SOA錯誤的途徑》來質疑這種把ESB當作SOA的實現基礎的做法。Bobby Woolf在文章中提到，很多客戶在開始建設SOA時要求先為他們建立一個ESB，他們拋棄了SOA的理念而只對ESB感興趣。“這些客戶在ESB和SOA之間劃了一個等號，或者更準確地說建設SOA就必須建設ESB。” SOA中國設計中心主任，IBM資深技術主管毛新生指出了這種錯誤的根源所在。
    ESB不等于SOA，它更不能替代SOA。以ESB來啟動SOA應用，然后以ESB為中心來構建SOA系統是不可取的。
    Burton Group的分析師Anne Thomas Manes說道：“如果缺少我推薦啟動SOA的基本組件，ESB將不會列在我的清單中。事實上，我并不鼓勵人們由ESB開始。ESB并不會鼓勵好的SOA行為。ESB本質上是集成系統，而非SOA系統。SOA是用于拆卸應用豎井(application silos)，而集成系統則是修補這些豎井。”
    而她提及的基本啟動包括：
    一個或多個服務平臺(如.NET，Java EE應用服務器等)

    SOA管理解決方案

    如果服務要被暴露在防火墻之外，那么需要XML網關。

    她還指出，ESB非常有用，但是，在SOA項目的初始階段可能不會發揮多大的用途。在SOA項目的后期，你還可能需要一個編制(orchestration)引擎，并且大多數的ESB都會提供一個。即便如此，ESB也絕對不是組織啟動SOA的起點。所有這些能力你一開始并不需要。因此，ESB應該在后期購買。
    Accenture首席技術官Don Rippert認為激活SOA的全部潛力需要通過四個階段，而ESB則處于第三個階段。他同時指出當前大多數的企業還只是處于第一個階段，因此ESB實際上對于他們來說并不是迫切需要的。
    而他所說的四個階段如下所示：

    1.使用XML，以更標準的方式使用應用程序接口。

    2.捕獲一些業務過程，并將它們轉化成為Web服務。

    3.引入并全面使用企業服務總線。

    4.產生業務過程執行語言(Business Process Execution Language，BPEL)，它可由業務過程建模工具完成。BPEL可以改變應用程序的行為，而無需修改軟件。