ESB實現(xiàn)SOA 企業(yè)復雜集成的解決

申請免費試用、咨詢電話：400-8352-114

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

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

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

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

● Web服務的治理;

●高級Web服務規(guī)范(WS-*);

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

●語義數(shù)據(jù)集成。

事件驅(qū)動的架構

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

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

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

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

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

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

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

另外一個必須滿足的條件是，應用需要適應這種事件驅(qū)動的交互模式。在事件順序非常重要的場合，應用必須能夠檢查事件的順序并做出適當?shù)奶幚?，否則，ESB就要有能力保證在復雜的邏輯情況下(也許這些邏輯還會有錯)事件的先后順序。（中國電子政務網(wǎng)）