J2EE會話外觀模式與值對象

2019-11-18 12:17:51

字體：大中小

來源：轉載

供稿：網友

　　在J2EE項目設計與應用中，會話外觀是一種普遍使用的模式。它可以使得應用更分布式，代碼耦合減少，網絡流量減少。總體上他給了客戶端粗粒度的訪問，保護了服務器端的代碼。有人說會話外觀模式是一個成功系統必備的設計方案，這是一點也不夸張。在一個成功的分布式應用中不使用會話外觀模式簡直有點不可想象。
　　
　　會話外觀不同于前端控制器，他有自己的應用領域，解決不同的問題。在客戶端與服務器端聯系時，尤其是與EJB交互時，會話外觀起重要作用，會話外觀可以起到降低客戶端與服務器端耦合的作用，當然降低的程度取決于會話外觀的實現形式。與值對象配合使用可以降低偶合，與xml配合使用甚至可以解除耦合。
　　
　　下面我們舉一簡單的例子來看看會話外觀模式是怎樣體現這些優點的。考慮一個銀行系統中，顧客轉帳的例子。設想這樣的情景：顧客在ATM對自己的帳戶做遠程操作，把自己的錢從儲蓄帳號轉到經常使用帳號。應用中，系統首先要核實客戶的身份，然后從儲蓄帳戶消掉要轉的錢，再次在經常使用增加這部分錢。我們用三個EJB來表示這核對帳戶（Customer EJB）,對存儲帳戶操作(SavingAccount EJB)和對經常帳戶(CheckingAccount EJB)操作，客戶端應該遵守的操作流程可以用如下的順序圖表示：
　　 J2EE會話外觀模式與值對象

點擊查看大圖
　　要理解上面的操作流程，需要首先理解EJB的工作原理。本質上EJB是一個框架結構，所以理解工作原理，就是要理解這個框架的運行機理。在EJB中有三個部分，分別供客戶端與服務器端使用。比如對客戶提供驗證的操作的Customer EJB,他有本地接口，遠程接口與服務器方方法實現類三個部分。推薦的命名方案是本地接口命名為CustomerHome,遠程接口命名為Customer,服務器方方法實現類則命名為CustomerBean.在實現中，因為檢驗本身是一種抽象行為，要檢驗的是用戶名、密碼、開戶帳號等系列信息，動作本身是與具體的客戶無關的。所以他只需要是一個Stateless EJB，與具體用戶無關。這樣，他完全可以在容器池中有多個實例對象，實現并行對各種不同用戶的核對，提高了訪問速度。存儲帳戶EJB (SavingAccount EJB)和經常帳戶EJB(CheckingAccount EJB)的沒，命名規則類似，他們也是無狀態的會話Bean,理由也類似。
　　
　　客戶端首先獲得用戶驗證、然后可以在儲蓄帳目下消去要求轉帳額，再次就可以轉儲到經常帳目了。三個動作我們都用EJB實現?？蛻舳艘来闻c三個EJB交互。我們選取CheckingAccound EJB做研究對象，看看客戶端是怎樣與這個Bean交互的，從EJB對客戶端做的響應，我們可以看到EJB的原理。客戶端調用本地方法CheckingAccountHome獲得對EJB的引用，Home接口會有一個或多個Creat()方法。這個接口是與CheckingAccountBean互動的，在實現中有個ejbCreateA()方法。這種互動由是通過容器實現的。Creat()方法返回的是一個遠程接口，此例中就是CheckingAccount了，客戶端就得到了對遠程接口的引用了，在遠程接口中會有一些方法的引用?？蛻敉ㄟ^這些方法，對遠程操作實現業務邏輯。這些方法的實現必須在CheckingAccountBean中實現。上面的過程我們已經看到，在獲得對實現方法調用前客戶端不得不與遠程交互兩次。在核對階段同樣要兩次才能取得正確的認證，儲蓄帳目的操作也同樣如此。明白了操作過程與EJB原理后，我們分析上述客戶端調用業務邏輯的方法至少有三點缺陷：
　　
　　首先，一點沒有伸縮性。
　　
　　其次，這種方法沒有一直性的保證。
　　
　　再次，業務邏輯直接暴露，安全讓人擔憂。
　　
　　沒有伸縮性是說客戶不得不對每個遠程的EJB做調用。上面我們看到一個簡單的轉帳業務邏輯就要求客戶端直接與服務器端交互六次。要是有其他的邏輯或者增加一個業務方法，客戶端又得重新增加多重調用。假如是不同的客戶端有不同的方法，方法調用更是忙上加亂。不良的伸縮性能從這里體現。
　　
　　在整個轉帳過程中，實際上只是一個事務處理過程，要么轉成功，要么不成功。所以必須保證saving account和CheckingAccount在一個事務處理中。但是在上述處理中，我們看到這種保證是要求在客戶端進行的。為了保證兩個帳戶的一致性，客戶端必須把對兩個EJB的調用包裝在一個事務處理中。由于網絡的不可靠性，延遲和錯誤在這時很可能會發生，事務處理的時間就自然拉長了，錯誤的可能性就自然增加，死鎖可能造成，一致性也就難以保證。
　　
　　在注重到客戶端對遠程方法的調用，發現都是直接調用。顯然，這種方法直接暴露給客戶端任意調用的方式直接導致服務器端毫無隱私，顯然是方法調用的安全處理所不答應的。當然在檢查EJB方法調用權限的時候,EJB規范也定義了相應的角色和安全控制，雖然這種把安全問題推到部署階段的方法是規范答應的。但是這不同于WEB應用，對于商業性非常強的應用更是要尋求更安全的措施來解決問題。
　　
　　為了克服這些缺陷，我們可以引入防火墻的概念——用session Façade模式在客戶端與業務方法之間加上一層Session bean，這樣客戶端與遠程交互就多了一層“防火墻”，可以獲得所有防火墻的好處，順序圖就如下所示了：
　　 J2EE會話外觀模式與值對象

點擊查看大圖
　　在目前網絡狀況下，網絡相對與計算機來說還是一個瓶頸（bottleneck），在使用了Session Façade模式后我們把六次或更多的網絡連接減少到了一個。對業務方法的訪問變成為本地訪問。在計算機與容器的條件下，處理速度自然比網絡訪問要快。不同的客戶都是同一的一次性調用，伸縮性可擴展性由此顯現。更重要的是，Session Façade Bean包裝了業務邏輯的所有方法，并集中控制事務；業務方法也不在直接暴露在客戶端下，一致性和安全性都有了保障——事務處理的嚴格要求轉由服務器端的容器來保證，無疑可靠性大大增強了。在這個銀行系統應用中我們使用方法transfer()來在客戶端與EJB之間傳遞數據，當然是通過Session Façade來傳了，具體怎么傳，在下面對Session Façade模式擴展的例子中會論述到。
　　
　　總之，我們不用在每次傳一個細粒度的方法調用了，可以一次傳遞所有參數給服務器端，復雜的業務邏輯方法也從暴露給客戶端處理成隱藏對客戶不可見。復雜性雖然推到了Session Façade Bean中，但是邏輯更獨立，耦合性更小了。
　　
　　在實際的應用中，我們經常使用值對象模式來代替transfer()方法。值對象在客戶端與EJB層之間傳遞、交換數據。一個值對象實際上是一個包裝了業務數據的序列化了的類，下面是此銀行系統中代替transfer()方法的值對象：AccountTransferValueObject。
　　
　　public class AccountTransferValueObject implements java.io.Serializable {
　　
　　PRivate String customerPK;
　　private String fromAccountPK;
　　private String toAccountPK;
　　private float　amount;
　　...
　　public String getCustomerPK(){
　　　return customerPK;
　　}
　　
　　public String getFromAccountPK(){
　　　return fromAccountPK;
　　}
　　
　　public String getToAccountPK(){
　　　return toAccountPK;
　　}
　　
　　public float　getTransferAmount(){
　　　return amount;
　　}
　　
　　public void setCustomerPK(String customerPK){
　　　this.customerPK = customerPK;
　　}
　　
　　public void setFromAccountPK(String fromAccountPK){
　　　this.fromAccountPK = fromAccountPK;
　　}
　　
　　public void setToAccountPK(String toAccountPK){
　　　this.toAccountPK = toAccountPK;
　　}
　　
　　public void　setTransferAmount(float amount){
　　　this.amount = amount;
　　}
　　}
　　
　　有了值對象，客戶端在需要傳遞數據時候，就把所有的數據打包在值對象中，然后通過網絡發送到EJB層，經過Session Facade Bean交給業務邏輯處理。同樣當業務邏輯與客戶端交互時，EJB層就會創建一個值對象來包裝業務方法需要傳遞的數據，通過Session Façade Bean傳遞給客戶端。

上一篇：設計模式的原則

下一篇：Java中設計模式(2) Singleton模式