前回有提到EAI/ESB，我說過那都是根源於系統間整合的目的所創造出的名詞。如果EAI這個名詞最合適代表「系統整合」，那麼本文不妨也可以說是在談EAI.。談到EAI，首先就要談到Business，到底多大的Service想要整合起來?接這就要問Architecture，到底要採用什麼Techenology ?緊接著就是要如何Implement?這部份包括Network、Programming Model、User環境以及打算採用什麼Standard?這些都檢討過後，我們才可以決定採用什麼Pattern，到底採用DB整合的Pattern或者Message.Process整合的Pattern?兩者當然各有利弊，但是沒有所謂優劣而是看你的用途。首先，先談DB整合的Pattern，這種Pattern又分DB replication與DB Federation。前者-DB Replication，舉例說明，系統A(AP+DB構成)的DB即時(Real Time)但非同期(Asyn)透過網路(Network)複製到系統B(AP+DB構成)的DB，這種應用方式的好處是(1)使用者多有許多範例可供參考(2)系統A的運轉時間不受系統B運轉時間的影響(3)AP不需大幅修改。限制是(a)Real Time的Application應用不易達成(b)業務邏輯侷限於應用程式。後者-DB Federation，同樣舉例說明，系統A的AP表面是處理同系統的DB，但是實際上這個DB實體是屬於系統B，也就是說系統A的DB是一個虛擬DB(Virtual DB)真正的實體DB是掛在系統B之下，系統A僅是利用SQL Virtual Access 對系統B的DB做I/O，這種應用方式的好處是(1)Application利用共同的介面對異種Data Access/Interface做處理。限制是(a)難滿足大量交易(b)受限於系統B的作業時間。接著，再談Message.Process整合的Pattern，同樣的這種Pattern也可分Message/File收/送與Business Process Corporation。前者-Message/File收/送，舉例說明，系統A透過通信非同期的Message/File收/送方式與系統B交換Message(主要技術為MQ)，這種應用方式的好處是(1)系統間的連結、需求的對應彈性比較大(2)系統A的運轉時間不受限於系統B的運轉與否。限制是(a)複雜交易設計比較困難(b)完全的Real Time無法做到。後者-Business Process Corporation，同樣舉例說明，系統A與系統B是屬與對等而非前述皆屬於主從，Flow Engine連結了系統A與系統B，與Message/File收/送不同的是這種方式支援同期與非同期(Syn & Asyn)通信方式但非提供QoS，這種應用方式的好處是(1)支援各種Business Process，亦即Long Running Transaction(2)支援分散處理的Application(3)以及將Process予以流程化。限制是(a)需花費較長的時間檢討各系統的Process俾構成Flow。以上簡單的描述EAI，也就是系統整合的各種方式，目前看起來各種方式在QoS還是不足(Resource Cordinator)如果應用Real Time使用方式，可能需要注意懂得如何趨吉避凶。
Add new comment