一.  ESB是什麼及常見運用

在之前有簡單的跟各位提到,可以先將ESB視為單純的AP Hubs,其實那樣的說法是太過簡單了,在這裡要再說明的精準一些,雖然不同的ESB產品有不同的功能特性,不過只要是ESB系統,主要都有下述的主要功能

 

1.      各式通訊協定支援

在設計上,ESB必須能夠與各式各樣的系統服務串連,而不同的服務可能採用各式不同的連接技術,所以,ESB必需有能力跟不同的連接技術進行連接。

 

2.      資料格式檢核與轉換

克服了通訊聯接上的問題,下一個重要的功能是要將收到的資料進行檢核,做好資料把關者的角色,避免錯誤資料遞交到應用系統中而造成更大的傷害,除此之外,ESB也可以進行資料轉換的工作,將資料轉換為應用系統可接受的型態,一來可以做好資料把關者的角色,二來也可以簡化資料承載的複雜度,類似一位稱職的翻譯官,伴演好各系統間溝通的角色。

 

3.      訊息繞徑的功能

在後續的段落,會跟各位討論何謂【服務】,在這裡我先簡單的舉例,假設我們將 出貨定義為一個服務,而這個服務涉及到兩個行為,一個行為為扣除庫存,另一為開出發票。那麼當我們呼叫出貨這個服務時,前端的應用程式是不需要知道該服務的商務邏輯如何實作,也不需要知道該怎麼呼叫後端的兩個行為,這一切都由ESB負責就可以了,其優點是,將商業邏輯與實作完全的分開出來,將可以易於系統的維護以及企業流程的快速修改。

 

除此之外,當我們在定義ESB的訊息傳遞功能時,基本上我們都會預設它們能夠支援下述的工作

 

(1)   Content Based Routing

在流程設計上,每一個流程上的分流判斷依據必須依照內文資料來判定,例如 我們需要地理單位來決定資料的處理位置,所以當有亞洲的資料,就會被分流至亞洲的服務中接續作業,而不會誤送至美洲。

 

(2)   StatelessStateful的支援

在分散式處理中,一般如微軟的.net RemotingJaveRMI都有能力針對Stateless Stateful進行遠端呼叫與管哩,但很不幸的,在SOA中常用的Web Services,並沒有能力處理Stateful的遠端呼叫,這會造成服務訊息傳遞的不連續性的,為了避免造成這樣的問題,目前一般都會改由ESB內建此功能來支援,以彌補Web Services自身技術上限制所造成的問題

 

(3)   同步與非同步的支援

在實務上,有些服務我們需要同步的快速回應,但有些服務需要長時間的處理時間,所以我們會採用同步或不同步的方式來處理遠端的服務呼叫,由於這類的應用已經被廣泛的運用,所以,這也成為ESB中一個必要的重要功能。

 

(4)   支援訊息傳遞安全與服務安全

此部份,可回頭參考SOA相關安全事項(前文),但在實作上,通常是ESBESB與第三方軟體必需達成訊息傳遞與服務安全的實作需求。

 

有了訊息處理的基本觀念,接下來就是將這些流程處理整合成一個完整的服務流程,目前最常見的是一個技術標準,叫做BPEL,它也是由XML組成,用於解釋服務流程的每一個步驟的設定。不過,如果要一般人了解BPEL中的意義,並且縮短一般業務使用者與技術人員的溝通距離,BPEL顯然是一種很不好的工具,所以,才有了BPMN的出現,這也是另一種的標準,主要是定義流程圖中的每一個符號意義,改為如流程圖的方式來溝通,理論上任何一個工具只要能夠正確的利用BPMN劃出服務流程圖,就可以輕易的透過工具將BPMN轉為流程控管用BPELESB判斷使用。

       

其他支援功能

除了上述的主要功能外,依每一個ESB產品的不同,還會提供程度不一的支援功能,例如

 

1.      服務的管理與監控,錯誤修正

ESB可以監控與Log每一個服務的過程,供系統管理者監控系統的運作或進行必要的效能調校。

 

2.      服務的版本控管

隨著應用與服務的擴大,服務的運用情況也會不斷的擴大,為了管理日漸複雜的服務流程,也就有了流程的版本控管必要。

 

大量資料同步

引進了SOA觀念之後,關於大量資料的處理有被一些學者拿出來討論,雖然在實務上我還沒見過,但我個人覺得很有意思,在這裡簡單的跟各位說明一下。最常見的大量資料處理就是Extract Transfer Load(ETL)的方式,類似如下圖

 

ETL.JPG 

 

但假如需要進行的資料庫數量很多,並且資料型態很多,就會變成難以管理與維護了。於是有些學者提出以ESB為核心的方式進行大量資料的處理,示意如下

ETL_SOA.JPG

 

這樣的好處是,利用ESB本身就具有的連接、轉換、分派匯流的特性,將資料庫資料轉為XML格式,並進行大量資料的資料同步,縱使不同的資料庫有不同的格式,只要在連接的Endpoint進行格式轉換就可以了,也不用擔心連接的問題,這可以省去許多開發工具的使用,並且也更具有彈性。不過,在實務上,我仍沒有相關的經驗,感覺上這會是一種很好的解法,只是在效能方面要多考量一下。

未完,下一篇--談SOA的服務

 

arrow
arrow
    全站熱搜

    miin1130 發表在 痞客邦 留言(0) 人氣()