最近幾年來，企業服務總線（ESB）在SOA基礎架構工具這一領域中頗有用武之地，但也不無爭議。可以稱得上是"摸着石頭過河"吧。現在它被用得越來越多，但是用戶需要進一步學習怎樣才能更好地使用它。
在複雜的集成項目中，如果發現性能變得慢起來，ESB常常成爲被指責的對象。此外，如果配置不當，它可能無法實現SOA所承諾的更好的服務可重用性。
在SearchSOA.com用戶挑戰及優先級2011-2012年度讀者調查中，在受訪者提到的ESB開發挑戰之中，複雜性問題首當其衝，77%的受訪者認爲它是一個挑戰。緊隨其後的是性能和維護問題，分別佔65%和53%.
最近，在同Lee Ackerman討論SOAML設計時，我們提到了ESB的性能問題。作爲Emphasys集團首席技術官的Ackerman說，只有服務設計中的服務粒度制定的適當，才能以正確的方式構建正確的服務。就像EJB或其他組件類型那樣，他說，如果你確保傳輸已經連接上，你就要付出代價。
"當你已經建立了一堆服務，並且將它們放到一個ESB上，如果它們的表現不佳，很可能你在設計時就已經出了差錯，"Ackerman說道。他認爲配置ESB的策略是我們查找故障所在領域的一個標誌。
"如果你發現ESB內部的策略過於複雜，這提示你需要審查一下你所設計的服務，以確保這些服務是正確的，粒度恰當，以及他們都有正確的責任，"他說道。
這一與性能相關的建議也得到了Ataptris首席技術官Jeff Bradshaw的贊同。過於龐大的消息和應用邏輯也是問題，他補充道。
"有時候，如果每秒內會有數以千計的消息，當出現特別大的消息時，那麼性能就慢下來了。"Bradshaw 說道。"然後這就變成了你採用的ESB的邏輯問題了。非常重要的一點是，要確保您將ESB用到了正確的用途上。"
"ESB應該是一個徹底的中介邏輯，從一個地方得到消息並送到另一個地方，並確保它採用了正確的格式。這纔是中介邏輯，而不是其他什麼東西，"Bradshaw說道。
慎重處理ESB和應用邏輯
"如果你將應用邏輯放到ESB中，在我看來，這是一種錯誤的模式，這也是ESB名聲不佳的一個肇始之源。如果你想編寫一個應用程序，那麼你就應該使用一個應用程序服務器，"他說道。"不要把它放在ESB容器中。"
Bradshaw告誡開發團隊，要記住，ESB從根本來說是一種集成工具。ESB是"中介邏輯，而不是應用邏輯，"他強調說。
我們都熟悉"工欲善其事，必先利其器"這個說法。這一格言也適合用在系統集成中。
"一些規模較大的諮詢公司會嘗試將ESB用做萬能藥，並把所有的邏輯放在ESB中，"Bradshaw說道。應用邏輯應當放在應用程序服務器中，這樣"擴展性會更好，"他說道。
在深入到ESB的設計問題時，Bradshaw談到了數據治理和XSLT,在進行XML轉換時，XSLT是一個很受歡迎的選擇。
"如今，市面上所有的ESB在XML轉換時都會使用XSLT.問題是，你會發現，有些開發人員開始會將業務邏輯編碼到這些XSLT中，"他說道。"這樣會有一些潛在的問題。"
隨着時間的推移，像這樣的代碼更容易出錯，就像過去已經在SOA中發現的那樣，這種問題是很難跟蹤的，尤其是在有多個版本的時候。
這一問題會損害SOA和ESB在從業人員中的聲譽。如果這種錯誤出現在常規的軟件堆棧中，操作人員可以更容易地發現這一bug.
"而在SOA中時，這個故障往往是隨機出現的。你將邏輯放在了實際中會隨機運行的地方，那麼就很難去跟蹤，"Bradshaw說道。
IT專家網