了解ESB

Question

雖然我了解系統集成是什么，但我對所有最新方法都有點新意。 我非常熟悉Web服務和JMS，但我對ESB的概念感到十分困惑。

我做了一些研究，但我仍然沒有得到它。 我通過實例而不是理論更好地工作。

那么有人可以說明一個簡單的例子來說明為什么人們會使用企業服務總線而不僅僅是隊列，Web服務，文件系統還是其他？

我希望這個例子能夠放大ESB的功能，這是任何其他常規整合方法無法實現的，或者至少不能以相同的效率實現。

所有回復都非常感謝。

謝謝，鮑勃

Answer 1

這聽起來有點刺耳，但基本上如果你需要一個ESB，你就會知道你需要一個ESB。

對於大多數用例，ESB是一個尋找問題的解決方案。 它是為大多數場景設計的一堆軟件。 大多數人根本沒有做足夠多的處理來保證它。 “企業”的“E”在這里值得注意。

在一個簡單的情況下：

tail -F server.log | grep SEVERE >> severe.log

這是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垃圾！”，最后你會得到“輸入 - > DO_STUFF - >輸出”。

對於大型系統，需要進行隨意，臨時集成的大量Web服務，它們可以很好。 如果你從事的業務很多，他們可以很好地工作。 當您擁有數十個管道時，他們可以幫助管理它們的操作方面。

但是對於復雜的管道，如果你有很多步驟，也許它不是原型之外的好主意，特別是如果涉及任何實際量。 記住，你可能沒有任何選擇，取決於你正在整合的系統。

如果沒有，如果你有一個單一的界面，你需要站起來 - 然后就這樣做。 無論如何，都可以在Perl，Java，C＃中完成。 不要耗盡並完成一些奇怪的100MB基礎設施和復雜性，以便您現在可以學習，掌握和維護。

所以，再次，如果你需要一個ESB，你就會知道它。 真。 你有什么系統，你用不同的東西一起構建，你要與它斗爭，與同事討論這些東西是什么樣的痛苦，你偶然發現一些鏈接到一些網站給一些供應商並閱讀一張白紙然后去“那就是它！”，但如果你還沒有這樣做，那么你就不會錯過任何東西。

Answer 2

這將有助於您了解ESB的概念。

企業服務總線（ESB）的買家指南這將提供有關ESB的清晰概念。

“在應用程序集成方面，企業服務總線（ESB）是一致的答案。它的解決方案架構利用Web服務，消息傳遞中間件，智能路由和轉換。鑒於其功能的廣度，決定是否或不是你的組織會實施ESB，如果是，你應該選擇哪一個是至關重要的。

本屆會議將概述需要考慮的關鍵因素，其中一些因素包括 -

正確的技術階段，你應該看看使用ESB的選項現有架構的必要改編周圍的社區“

Answer 3

ESB適用於您在同一系統中擁有該Web服務和隊列及文件系統並需要集成它們的情況。 ESB產品通常可以解決以下問題

1. 安全
2. 消息路由
3. 業務流程（這是高級消息路由）
4. 協議轉換
5. 消息轉換
6. 監控
7. 三項賽

您也可以使用其他工具完成所有這些工作，如果您只需要一個或兩個這樣的功能，那么您可以在沒有ESB的情況下（因為它引入了額外的復雜性），但是當您需要其中的幾個時，可以采用以下形式的集成解決方案： ESB可以是更好的解決方案。

Answer 4

正如@WillHartung總結的那樣，ESB往往適用於大型復雜情況。 這就是為什么它被命名為企業服務總線。

現在，要真正回答您的問題，ESB通常會：

• 通過多種協議（例如HTTP，消息隊列等）進行通信，用於輸入和輸出

• 建立一種通用的消息格式，並經常從其他格式轉換為“規范”格式

• 提供端點透明度（例如，您向總線發送消息，並獲得回復，但您沒有明確知道哪些服務也連接到總線，處理您的請求。

• 提供監控和管理功能

• 促進服務和消息的版本控制

• 在需要時強制執行安全性。

所以，正如你所看到的那樣，當進行大量的點對點通信（“只是這樣做”）時，這將是一堆巨大的，難以管理的意大利面條。 事實上，我見過SOA的大部分地方都在實施，它正在取代已經存在的那堆巨大的意大利面。

Answer 5

如果您喜歡面向服務的體系結構，ESB是企業服務總線，基礎架構背板。 想象一下，數百種服務的混亂令人愉快地重復使用。 如何管理這樣的環境？ 您如何在服務之間提供靈活的，分離的路由？ 你如何避免點對點的意大利面建築？ 您如何管理混合技術領域的交易和安全性？ 如何跟蹤多個系統中復雜流中的消息位置？

您使用ESB。

ESB通常允許您以XML配置語言設計跨多個系統的流，為您提供大量EIS適配器，轉換和中介插件等。有些將提供IDE來幫助您設計流程。 有些ESB非常昂貴，有些是開源的。

如果您想了解ESB，請查看Mule或WSO2，兩者都是優秀的開源產品，甚至是Spring Integration，它是一種非集群解決方案，但非常適合將Java與底層外部接口點分離。