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

總所周知，標(biāo)準(zhǔn)的J2EE應(yīng)用中數(shù)據(jù)傳遞是基于對象傳遞的，一個實例化后的對象既包括數(shù)據(jù)，同時也包括一些操作，執(zhí)行過程是通過調(diào)用對象的方法，同時將包含數(shù)據(jù)的對象作為調(diào)用方法的參數(shù)傳遞進去進行相應(yīng)的操作。在EOS應(yīng)用中，結(jié)合J2EE WEB應(yīng)用的特點，將運行時的數(shù)據(jù)根據(jù)不同層次和作用范圍以XML格式被獨立封裝到3個不同的內(nèi)存數(shù)據(jù)區(qū)中。分別為會話數(shù)據(jù)區(qū)（SessionContext）、請求數(shù)據(jù)區(qū)（RequestContext）和業(yè)務(wù)處理數(shù)據(jù)區(qū)（BizContext），這幾個數(shù)據(jù)區(qū)就構(gòu)成了EOS的數(shù)據(jù)總線。

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

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

BizContext數(shù)據(jù)區(qū)在調(diào)用某個業(yè)務(wù)邏輯時為該業(yè)務(wù)邏輯實例建立的數(shù)據(jù)區(qū)，展現(xiàn)邏輯調(diào)用業(yè)務(wù)邏輯時可以將RequestContext的部分?jǐn)?shù)據(jù)通過接口設(shè)置傳入到業(yè)務(wù)邏輯的數(shù)據(jù)區(qū)，業(yè)務(wù)邏輯執(zhí)行過程中也可以通過調(diào)用不同的運算邏輯改變BizContext數(shù)據(jù)區(qū)的內(nèi)容。當(dāng)業(yè)務(wù)邏輯執(zhí)行完返回到展現(xiàn)邏輯時，可以將BizContext數(shù)據(jù)區(qū)的部分內(nèi)容通過接口設(shè)置傳回到展現(xiàn)邏輯的數(shù)據(jù)區(qū)中，與此同時，BizContext數(shù)據(jù)區(qū)的生命周期失效。
以下是各個數(shù)據(jù)區(qū)的數(shù)據(jù)傳遞關(guān)系圖：

由圖可見，SessionContext的數(shù)據(jù)不能直接傳遞到業(yè)務(wù)邏輯的BizContext數(shù)據(jù)區(qū)中。如果在業(yè)務(wù)邏輯中需要使用SessionContext數(shù)據(jù)，需要在調(diào)用業(yè)務(wù)邏輯的展現(xiàn)邏輯中先將SessionContext的數(shù)據(jù)傳入到RequestContext數(shù)據(jù)區(qū)中，再由展現(xiàn)邏輯將傳入到RequestContext數(shù)據(jù)區(qū)的Session信息傳入到業(yè)務(wù)邏輯對應(yīng)的數(shù)據(jù)區(qū)BizContext中。通過以下圖示，我們可以看到開發(fā)的各個構(gòu)件邏輯是怎樣通過各種引擎實現(xiàn)數(shù)據(jù)的轉(zhuǎn)換或者傳遞的。

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

通過以下表格對各個數(shù)據(jù)區(qū)的特點進行總結(jié)：

基于XML數(shù)據(jù)總線實現(xiàn)應(yīng)用的數(shù)據(jù)流轉(zhuǎn)，使得應(yīng)用各個層次耦合度更加松散，更加便于與外部系統(tǒng)實現(xiàn)集成，而系統(tǒng)卻在數(shù)據(jù)處理上具有了很強的擴展性。這些優(yōu)勢將在后續(xù)的培訓(xùn)內(nèi)容中以具體的案例進行驗證。