1.3 EAI v.s. ESB
從整合的技術與產品來看, 大概是如下演進:
Direct Connect -> 連Message Queue都沒有
Point To Point -> 有Message Queue
Message Broker
Standard Based Connection -> 系統(架構、技術、產品、方法、工具)依據SOA標準來整合
其實都是在做差不多的事情喇, 但是不同的技術與產品限制了系統與應用程式間的整合方式, 所以真的做起來還是有差的.
ESB: 在業界認可的標準上, 透過event-driven的引擎(BUS)連結複雜的系統架構, 且具有分散的和分布式的體系結構.
SOA: 架構上定義出一組可以讓商業流程在整個生命週期以服務為單位來表示, 把每件流程分割成為服務, 可視為分散運算.
EAI: 或是以前的HUB, 把多個系統連結在一起成為一個大系統.
基本上, ESB和EAI最大的不同在於: EAI把系統視為一個整體, 而ESB則把整個系統當成許多小系統. 我們也可以把ESB想成是進化的EAI.
這樣講可能還是太抽象了, 所以請先看下面這張圖:
這張圖同時展示了Point To Point, Hub/Spoke(EAI)和ESB之間的差異.
Hub/Spoke(EAI): 在此架構中使用了集中式的broker(HUB)以及adapters(Spoke). Adapter是用來將application連接至hub的. 其實這邊可以很明顯地看出此架構的優點就是只有一個hub的話會很易於維護; 相對的, 缺點就是scale上會比較困難, 因為轉換(transformation)跟路由(routing)這兩個工作都集中在一個中央hub上, 所以有些時候當訊息量很大的時候, scalability通常就要仰賴於hub的硬體設備上了.
ESB: 此架構以一個中央訊息骨幹(bus)來傳遞訊息, 而application用adapter發送(publish)訊息至bus. 這邊其實應該可以看得出來EAI跟ESB的差異處在於EAI的整合引擎(integration engine)在中央hub上; 但對ESB來說, 負責訊息轉換跟路由的整合引擎是分佈在各個application的adapter之中的. 而ESB架構下, application adapter必須與其original application跑在同一個平台上, 這樣的一個特點可以讓scalability在相較於EAI的架構下更易於發揮.
Last updated
