ESB實現SOA 企業複雜應用集成的解決措施(1)

從企業服務總線(Enterprise Service Bus，ESB)在2002年被正式提出以來，我們看到ESB不管是在實現方式還是部署方式上都有了不小的變化。在過去的四年多的時間裏，ESB作爲軟件領域裏的一個獨立產品也被越來越多的人所接受，衆多的ESB供應商正在架構、連接性、易用性以及服務質量的保證(如持續可用)等方面進行競爭。

　　很多綜合服務供應商(如IBM、BEA)、企業應用集成商(如Tibco、webMethod)以及Web服務工具供應商都紛紛給自己的產品冠以ESB的名號，英國電信甚至把ESB做進了它們的一個硬件產品中。

　　很明顯，作爲SOA(Service-Oriented Architecture)的核心和基礎架構，ESB已經成爲準備踏上和已經踏上SOA之旅的CIO們必須認真考慮和仔細研究的一個產品。因爲作爲一種中間件，ESB通過與它連接的各種應用的服務級接口實現各種應用之間的連接，控制它們之間的通信，這一功能正在越來越多的生產系統中發揮着作用。更爲重要的是，幾年來很多企業和機構已經在生產中部署了ESB，ESB的效果得到了一定程度的校驗，同時人們對如何充分發揮ESB的作用以及建立SOA的環境，爲此需要建設、部署管理哪些基礎設施有了越來越清晰的認識。這些基礎設施包括：

　　●面向流程、事件驅動的架構(Event-Driven Architecture，EDA)；

　　● Web服務的治理；

　　●高級Web服務規範(WS-*);

　　●複雜事件處理(Complex Event Processing，CEP);

　　●語義數據集成。

　　事件驅動的架構

　　談到ESB就不得不談到面向流程、事件驅動的架構，因爲ESB與這種架構配合起來可謂相得益彰。

　　通常，點對點的集成是通過簡單的請求/響應這種同步的方式來完成交互的。在這種環境中，ESB作爲數據傳輸和轉換的中介可以很好地完成這一任務，但是，ESB最能發揮作用、也最能體現其帶來的靈活性的地方還是在面向流程、事件驅動的架構中。

　　在進行跨多個應用、大範圍的集成時，成功的關鍵是有一個靈活的架構，面向流程、事件驅動的架構就是這樣的架構。通過使用ESB，事件驅動的架構中的每個應用與其他應用之間處於一種松耦合狀態。在這種架構中，每個應用獨立於其他應用運行完成一項任務，或者異步地完成一組任務中的一個。

　　即使在一個應用發出了一個請求，然後等待響應以完成接下來的流程時也是這樣。這個請求被髮到總線上，按照預先定義的流程，這個請求可能會經過很多應用、數據源、路由器和轉換器。上述一系列的行爲都是獨立完成的，最後的響應也是作爲一個獨立的事件到達最初的這個應用。

　　事件驅動的交互模式一個主要優點就是保證應用之間的松耦合。只要接入ESB中，每個應用都不用瞭解如何與其他的應用進行交互這些細節，ESB負責處理所有的協議、數據格式和不同的交互模式。

　　當然，事件驅動的架構只有在一定條件下才能有效地工作。首先，ESB必須具有可靠和高可用的異步消息傳遞能力。在一個同步的點對點的集成項目中，如果一個應用沒有收到一個請求的響應，它會發出錯誤的信息，同時再次嘗試發出請求。但是在異步的情況下，應用向ESB發出一個請求以後就不再關心是否會有響應，直到一個新的請求到達，通知這個應用完成下一個處理。

　　由於很多時候企業的所有交易都必須經過ESB總線完成，因此ESB必須有容錯能力，支持複雜的業務邏輯，遇到錯誤的邏輯也能及時恢復。

　　另外一個必須滿足的條件是，應用需要適應這種事件驅動的交互模式。在事件順序非常重要的場合，應用必須能夠檢查事件的順序並做出適當的處理，否則，ESB就要有能力保證在複雜的邏輯情況下(也許這些邏輯還會有錯)事件的先後順序。