淺析EOS應用的數據總線

在描述EOS的技術路線和產品內容時，都會重點提到數據總線的概念。的確，如果在開發中真正理解了基于數據總線的數據傳遞機制，開發起來將會得心應手游刃有余。這個神秘的數據總線在EOS中到底是什么東西呢？為什么要在EOS中引入這樣一個東西呢？

總所周知，標準的J2EE應用中數據傳遞是基于對象傳遞的，一個實例化后的對象既包括數據，同時也包括一些操作，執行過程是通過調用對象的方法，同時將包含數據的對象作為調用方法的參數傳遞進去進行相應的操作。在EOS應用中，結合J2EE WEB應用的特點，將運行時的數據根據不同層次和作用范圍以XML格式被獨立封裝到3個不同的內存數據區中。分別為會話數據區（SessionContext）、請求數據區（RequestContext）和業務處理數據區（BizContext），這幾個數據區就構成了EOS的數據總線。

RequestContext數據區是根據HTTP Request對象建立的，封裝了HTML頁面上通過post或者get方式提交的表單數據以及一些系統信息（如客戶端IP、請求的URI等），這個數據區能夠被表單中的Action對應的展現邏輯直接進行讀取，也能通過EOS提供的JSP頁面TAG讀取數據顯示在頁面上，系統為每一次客戶端請求建立一個專有的RequestContext數據區，當系統完成響應（Respone）后該數據區失效。

SessionContext數據區是根據HTTP Session對象建立的，封裝了WEB容器中的用戶的會話信息，這些Session信息是通過展現邏輯的數據設置接口寫入的，也可以通過數據設置接口獲得SessionContext的數據后寫入到RequestContext數據區中。JSP頁面通過TAG可以直接獲取SessionContext的數據。SessionContext的數據區在一個WEB會話建立時創建，在會話保持期間可以存取其中的內容（一般通過展現邏輯實現），當會話結束或超時后，該數據區失效。

BizContext數據區在調用某個業務邏輯時為該業務邏輯實例建立的數據區，展現邏輯調用業務邏輯時可以將RequestContext的部分數據通過接口設置傳入到業務邏輯的數據區，業務邏輯執行過程中也可以通過調用不同的運算邏輯改變BizContext數據區的內容。當業務邏輯執行完返回到展現邏輯時，可以將BizContext數據區的部分內容通過接口設置傳回到展現邏輯的數據區中，與此同時，BizContext數據區的生命周期失效。
以下是各個數據區的數據傳遞關系圖：

由圖可見，SessionContext的數據不能直接傳遞到業務邏輯的BizContext數據區中。如果在業務邏輯中需要使用SessionContext數據，需要在調用業務邏輯的展現邏輯中先將SessionContext的數據傳入到RequestContext數據區中，再由展現邏輯將傳入到RequestContext數據區的Session信息傳入到業務邏輯對應的數據區BizContext中。通過以下圖示，我們可以看到開發的各個構件邏輯是怎樣通過各種引擎實現數據的轉換或者傳遞的。

由上圖我們可以看到，假定頁面1的表單（Form）提交時，調用展現邏輯1，表單數據將會形成數據區實例RequestContext1，展現邏輯分別調用了業務邏輯1和業務邏輯2，在調用業務邏輯1時，指定傳入了部分數據給業務邏輯1，在業務邏輯1的實例啟動后，同樣會建立業務邏輯實例1的數據區實例BizContext1，在處理完成后，返回部分數據到RequestContext1，BizContext1的生命就結束了，展現邏輯實例1以同樣方式調用業務邏輯實例2，調用結束后，業務邏輯實例2的數據區實例BizContext2也可能返回了部分信息到RequestContext1中，這樣RequestContext1通過調用業務邏輯后數據與之前有了變化，這些數據又可以顯示到用戶頁面2上，然后RequestContext1的生命周期就結束了。頁面2上進行一次新的調用，又開始了新的執行過程，可見，不同數據區是根據不同的實例產生的，并隨著實例執行的結束而結束，每種實例都擁有響應類型的數據區實例。

通過以下表格對各個數據區的特點進行總結：

基于XML數據總線實現應用的數據流轉，使得應用各個層次耦合度更加松散，更加便于與外部系統實現集成，而系統卻在數據處理上具有了很強的擴展性。這些優勢將在后續的培訓內容中以具體的案例進行驗證。