一. ESB是什麼及常見運用
在之前有簡單的跟各位提到，可以先將ESB視為單純的AP Hubs，其實那樣的說法是太過簡單了，在這裡要再說明的精準一些，雖然不同的ESB產品有不同的功能特性，不過只要是ESB系統，主要都有下述的主要功能
1. 各式通訊協定支援
在設計上，ESB必須能夠與各式各樣的系統服務串連，而不同的服務可能採用各式不同的連接技術，所以，ESB必需有能力跟不同的連接技術進行連接。
2. 資料格式檢核與轉換
克服了通訊聯接上的問題，下一個重要的功能是要將收到的資料進行檢核，做好資料把關者的角色，避免錯誤資料遞交到應用系統中而造成更大的傷害，除此之外，ESB也可以進行資料轉換的工作，將資料轉換為應用系統可接受的型態，一來可以做好資料把關者的角色，二來也可以簡化資料承載的複雜度，類似一位稱職的翻譯官，伴演好各系統間溝通的角色。
3. 訊息繞徑的功能
在後續的段落，會跟各位討論何謂【服務】，在這裡我先簡單的舉例，假設我們將 “ 出貨 “定義為一個服務，而這個服務涉及到兩個行為，一個行為為”扣除庫存”，另一為”開出發票”。那麼當我們呼叫”出貨”這個服務時，前端的應用程式是不需要知道該服務的商務邏輯如何實作，也不需要知道該怎麼呼叫後端的兩個行為，這一切都由ESB負責就可以了，其優點是，將商業邏輯與實作完全的分開出來，將可以易於系統的維護以及企業流程的快速修改。
除此之外，當我們在定義ESB的訊息傳遞功能時，基本上我們都會預設它們能夠支援下述的工作
(1) Content Based Routing
在流程設計上，每一個流程上的分流判斷依據必須依照內文資料來判定，例如 我們需要地理單位來決定資料的處理位置，所以當有亞洲的資料，就會被分流至亞洲的服務中接續作業，而不會誤送至美洲。
(2) Stateless與Stateful的支援
在分散式處理中，一般如微軟的.net Remoting或Jave的RMI都有能力針對Stateless 或 Stateful進行遠端呼叫與管哩，但很不幸的，在SOA中常用的Web Services，並沒有能力處理Stateful的遠端呼叫，這會造成服務訊息傳遞的不連續性的，為了避免造成這樣的問題，目前一般都會改由ESB內建此功能來支援，以彌補Web Services自身技術上限制所造成的問題
(3) 同步與非同步的支援
在實務上，有些服務我們需要同步的快速回應，但有些服務需要長時間的處理時間，所以我們會採用同步或不同步的方式來處理遠端的服務呼叫，由於這類的應用已經被廣泛的運用，所以，這也成為ESB中一個必要的重要功能。
(4) 支援訊息傳遞安全與服務安全
此部份，可回頭參考SOA相關安全事項(前文)，但在實作上，通常是ESB或ESB與第三方軟體必需達成訊息傳遞與服務安全的實作需求。
有了訊息處理的基本觀念，接下來就是將這些流程處理整合成一個完整的服務流程，目前最常見的是一個技術標準，叫做BPEL，它也是由XML組成，用於解釋服務流程的每一個步驟的設定。不過，如果要一般人了解BPEL中的意義，並且縮短一般業務使用者與技術人員的溝通距離，BPEL顯然是一種很不好的工具，所以，才有了BPMN的出現，這也是另一種的標準，主要是定義流程圖中的每一個符號意義，改為如流程圖的方式來溝通，理論上任何一個工具只要能夠正確的利用BPMN劃出服務流程圖，就可以輕易的透過工具將BPMN轉為流程控管用BPEL供ESB判斷使用。
其他支援功能
除了上述的主要功能外，依每一個ESB產品的不同，還會提供程度不一的支援功能，例如
1. 服務的管理與監控,錯誤修正
ESB可以監控與Log每一個服務的過程，供系統管理者監控系統的運作或進行必要的效能調校。
2. 服務的版本控管
隨著應用與服務的擴大，服務的運用情況也會不斷的擴大，為了管理日漸複雜的服務流程，也就有了流程的版本控管必要。
大量資料同步
引進了SOA觀念之後，關於大量資料的處理有被一些學者拿出來討論，雖然在實務上我還沒見過，但我個人覺得很有意思，在這裡簡單的跟各位說明一下。最常見的大量資料處理就是Extract Transfer Load(ETL)的方式，類似如下圖
但假如需要進行的資料庫數量很多，並且資料型態很多，就會變成難以管理與維護了。於是有些學者提出以ESB為核心的方式進行大量資料的處理，示意如下
這樣的好處是，利用ESB本身就具有的連接、轉換、分派匯流的特性，將資料庫資料轉為XML格式，並進行大量資料的資料同步，縱使不同的資料庫有不同的格式，只要在連接的Endpoint進行格式轉換就可以了，也不用擔心連接的問題，這可以省去許多開發工具的使用，並且也更具有彈性。不過，在實務上，我仍沒有相關的經驗，感覺上這會是一種很好的解法，只是在效能方面要多考量一下。
未完，下一篇--談SOA的服務
留言列表
