雖然我明白系統集成是什麼，但我對所有最新的方法都有點新意。我對Web服務和JMS非常熟悉，但我完全被ESB的概念所困惑。瞭解ESB
我已經做了一些研究，但我仍然沒有真正明白。我通過榜樣而不是理論來更好地工作。
那麼有人可以舉例說明一個簡單的例子來說明爲什麼要使用企業服務總線而不是隊列，Web服務，文件系統或其他？
我想舉一個例子來放大ESB的功能，這是任何其他傳統的整合方法無法實現的功能，或者至少不具有相同的效率。
非常感謝所有的答覆。
感謝， 鮑勃
這是要健全有點苛刻，但基本上如果你需要一個ESB，你會知道你需要一個ESB。
對於大多數用例，ESB是尋找問題的解決方案。這是一堆爲大多數場景設計的軟件。大多數人只是沒有做足夠多樣的處理來保證它。 「企業」的「E」在這裏值得注意。
在簡單的情況：
tail -F server.log | grep SEVERE >> severe.log
THAT是ESB方案的一個實例的一個簡單的例子。
「但這只是一個UNIX命令管道！」
是的，正好。
「ESB」部分是「|」和「>>」
的ESB是在運行時間內，您可以聯繫在一起的模塊，監控流量，設計各種怪誕的場景，如扇出和連接，等等，等等
的ESB是顯着因爲有一堆連接器可以讀取一堆資源並編寫一堆目的地。他們着重編織更復雜的圖形和工作流程，以便使用相當粗糙的邏輯塊進行處理。
但大多數人通常做的是：
input -> DO_STUFF -> output
隨着ESB他們得到：
ESB[input -> DO_STUFF -> output]
在野外，大多數管道根本沒有那麼複雜。他們傾向於擁有一種不可重用的邏輯，人們傾向於將它們整合到一個邏輯模塊中。
那麼，你可以用Perl腳本來做到這一點。
ESB中的長管道往往比沒有效率更低。由於很少使用二進制有效載荷，所以有很多數據進出通用模塊（因爲您很少使用二進制有效載荷）。
因此，例如，CSV進入，轉換爲XML，處理它，輸出XML作爲XML輸入到另一個步驟，將其編組，然後將其轉換回XML以進行另一步驟。沖洗並重復，直到CPU達到400％（多核FTW）。如果我將這些模塊一起拖放到一個例程中，我們跳過所有這些XML垃圾！「，最後輸入」input - > DO_STUFF - > output「 。
對於大型系統，有大量的Web服務需要進行臨時性，臨時性集成，他們可以很好。如果你從事的業務很多，他們可以很好地工作。當你有幾十條管線時，他們可以幫助管理它們的操作方面。
但是對於複雜的管道，如果您有很多步驟，也許除了原型設計之外，這並不是一個好主意，特別是如果涉及任何實際的體積。記住，你可能沒有任何選擇，取決於你正在整合的系統。
如果沒有，如果你有一個單一的界面，你需要站起來 - 然後就做。在Perl中，在Java中，在C＃中，不管。不要耗盡你的資源，不要耗盡你現在要學習，掌握和維護的一些奇怪的100MB基礎設施和複雜性。
所以，如果你需要一個ESB，你就會知道它。真。你可以擁有任何不同的系統，你可以與之抗衡，與同事討論這些事情是多麼的痛苦，而且你會偶然發現一些鏈接到某個廠商的鏈接，並閱讀一張白紙，然後去「這就是它！」，但如果你還沒有這樣做，那麼你不會錯過任何東西。
正如@WillHartung總結的那樣，ESB往往適用於大型複雜的情況。這就是爲什麼它被命名爲企業服務總線。
現在，真正回答你的問題，通常的ESB：
溝通過幾個協議（如HTTP，消息隊列等），用於輸入和輸出
建立一個共同的消息格式，並且通常從其他格式轉換爲「規範」格式
提供端點透明性（例如，您發送消息到總線並獲取答案，但您不明確知道哪個服務器副，也連接到公共汽車，處理您的請求。
提供監控和管理功能
便利服務和消息
在需要時實施安全的版本。
所以，你可以看到，這是做了很多點至點通信（「只管去做」）時會是意大利麪條的一個巨大的，難以管理的堆。事實上，大多數我見過SOA實現的地方，它正在取代已經存在的大量意大利麪條。
ESB適用於您確實擁有該Web服務以及隊列和文件系統都在同一個系統中並需要將其集成的情況。 ESB產品通常解決了以下
您也可以使用其他工具完成所有這些工作，如果您只需要這些功能中的一個或兩個，您可能不需要ESB（因爲它引入了額外的複雜性），但是當您需要其中幾個集成解決方案時ESB的形式可以是更好的解決方案。
如果您喜歡面向服務的體系結構，ESB是企業服務總線，基礎設施背板。想象一下，數百種服務的混亂愉快地重用對方。如何管理這樣的環境？你如何在你的服務之間提供靈活的，分離的路由？你如何避免點對點的意大利麪條建築？您如何管理混合技術領域的交易和安全？如何跟蹤消息在多個系統中的複雜流程中的位置？
您使用ESB。
ESB通常允許您使用XML配置語言設計跨多個系統的流，爲您提供大量的EIS適配器，轉換和中介插件等。有些將提供IDE來幫助您設計流程。一些ESB非常昂貴，有些是開源的。
如果您想了解ESB，請查看Mule或WSO2，這兩種優秀的開源產品，甚至是Spring集成，這是非集羣解決方案，但非常適合將Java從底層外部接口點解耦。
這將幫助您理解ESB的概念。
A Buyers Guide to an Enterprise Service Bus (ESB) 這將提供ESB的一個清晰的想法。 「當涉及到應用程序集成時，企業服務總線（ESB）是一致的答案，其解決方案架構利用了Web服務，消息傳遞中間件，智能路由和轉換，考慮到其功能的廣泛性， 。您的組織是否與否的決定將實現ESB，如果是你應該選擇哪一個是關鍵
本次會議將提供需要考慮其中的一些關鍵因素的概述包括 -
正確的技術階段，您應該查看使用ESB的選項 需要適應現有架構 周圍社區「
+1對於過度工程和」大多數人根本沒有做足夠多種處理來保證它「 – kolossus