按需變化解釋有狀態還是無狀態EJB(圖)

2019-11-18 12:33:39

字體：大中小

來源：轉載

供稿：網友

　　當提到開發J2EE服務端組件時，EJB是事實上的標準。會話bean被用作業務邏輯組件，并且主要是這兩種類型：有狀態的和無狀態的。Bean的類型，有狀態或無狀態，是在布署時通過布署參數決定的。但是，有很多情況可能是在運行時才能決定是否需要有狀態的bean。這篇文章中，我會解釋一種用來在運行時選擇是否有狀態的bean的模式。
　　
　　有狀態和無狀態的會話bean
　　
　　會話bean為它的客戶進行工作，通過在服務器端執行業務任務將業務邏輯的復雜度與客戶屏蔽開來。無狀態的會話bean不保持任何與客戶的會話狀態，發給bean的每一次請求需同時提供數據來進行請求處理。有狀態的會話bean，與之相反，可以保持狀態，并且該狀態可以在與客戶的多次會話中存在。
　　
　　有狀態的bean帶來了支持會話狀態的好處但同時付出了性能的代價。無狀態bean具有更好的性能，但卻又不具備與客戶端的親合力。EJB容器可以將無狀態bean放入緩沖池中，并當有用戶請求無狀態bean時，從中選取任意一個bean來為其提供服務。
　　
　　使用一個有狀態還是無狀態bean是設計時的選擇，EJB的布署描述符描述了會話bean在EJB容器中的狀態。并沒有這樣的先例，一個bean可以由處理結果來動態的改變其狀態。
　　
　　一個示例情景
　　
　　考慮一個這樣的情景：搜索組件需要設計為讓客戶端通過不同的參數來搜索數據倉庫。一個有關顧客的搜索可能只是這個組件提供的各式各樣的搜索中的一小部分。假如客戶端以一個特定的顧客登錄，那么這個組件的的后續搜索應該符合這個顧客的相關的配置。這些搜索應該包含符合這個顧客條件的產品的列表。假如沒有登錄，那么搜索應該返回系統默認的顧客的結果。出于保持示例通用的原因，我沒有具體說明這個特定的搜索，但這個情景對于很多應用來說是很普通的情況。
　　
　　我將闡述一種模式，它提供了動態地指定bean的有狀態或無狀態，并把此模式應用到上述示例業務情景中。使這種模式成為必要的動力在于：
　　
　　·通常只有兩個粗分類的會話EJB存在
　　·沒有辦法動態地將一個無狀態地bean轉化為有狀態的bean
　　·業務情景要求根據處理結果將一個無狀態的bean轉換為有狀態bean
　　·客戶不應該承擔創建一個有狀態的bean責任,它應該在后臺執行。
　　
　　模式
　　
　　我會細述解決以上問題的模式。創建一個focus類,它是一個POJO(普通的舊式java對象)。focus類擁有組件的邏輯實現。將組件同時模型化為有狀態和無狀態bean。會話bean將會實例化并使用focus來實現客戶端請求?？蛻舳?，默認地，通過代理訪問無狀態bean的服務。假如處理結果表明客戶需要一個有狀態地用務，一個有狀態的服務將會創建，有狀態的服務將服務于客戶端的后續請求。有狀態的服務也使用focus類，并在調用focus類的方法時傳遞客戶的狀態。
　　
　　類算法如圖1顯示，其中有模式中有關的主要的類以及展示了不同類之間的協作。
　　　按需變化解釋有狀態還是無狀態EJB(圖)（圖一）

　　圖1.無狀態/有狀態會話bean模式的算法
　　
　　客戶端
　　
　　客戶端是需要使用EJB組件提供的服務的任意Java對象?？蛻舳耸褂么韥砗头战换??？蛻舳瞬⒉恢烙袪顟B或無狀態服務的存在，僅只是使用EJB提供的服務。
　　
　　代理
　　
　　這兒的代理是一種服務定位器的組合，也是一種業務代理模式。代理負責查找無狀態的服務，并調用其上的服務。代理也負責處理返回的數據集，存儲有狀態的bean的處理器，假如有狀態的處理器不存在則調用有狀態服務。一個可選的步驟是代理解析作為參數傳遞的數據集，假如處理器指向了一個有效地有狀態bean則調用有狀態服務。
　　
　　無狀態服務
　　
　　無狀態服務是一個提供給客戶組件服務的無狀態EJB。無狀態服務沒有提供與客戶端的會話狀態，它是由代理來查找選取的。無狀態bean使用focus類提供的功能。
　　
　　有狀態服務
　　
　　有狀態服務由無狀態服務運行中創建的，當它決定客戶的請求不應由無狀態來提供。這由請求數據或者無狀態服務中的處理邏輯來決定。有狀態服務具有存儲調用客戶狀態的能力并且將這些狀態應用到focus類中。
　　
　　數據集
　　
　　數據集是由服務器返回給客戶端的一個通用的返回。數據集具有作為由方法調用產生的服務返回的實際數據，并且還具有與返回客戶相關的配置信息。數據集同時具有有狀態服務的處理器，它被代理用來請求有狀態服務所需要的數據。
　　
　　Focus類
　　
　　Focus類有對應組件中的主業務邏輯。Focus類包含了基本功能并不包含任何狀態。它基于傳入的數據進行處理，并在方法調用之間不保持狀態。作為一個經驗，好的實踐是在focus類中實現這些方法，而focus對于有狀態和無狀態服務來說是平等的。
　　
　　協作
　　
　　客戶端實例化代理并通過它調有組件上的任意方法。代理的邏輯是查找無狀態bean，并調用相應無狀態服務上的對應方法。無狀態bean處理請求并調用focus類得到結果。處理的結果以數據集對象的型式返回給客戶端。
　　
　　假如在處理請求的過程中，無狀態服務決定服務需要為將來的處理存儲請求的狀態，那么無狀態服務則創建一個有狀態服務。有狀態bean的處理器存儲在數據集對象中返回給客戶。當然，返回的數據集也包含了客戶端所請求的返回數據。代理將會在返回給客戶之前解析數據集對象，并將有狀態bean的處理器作為狀態存儲起來。當客戶對代理進行下一次調用時，代理將會調用作為代理的狀態一部分的有狀態bean的處理器。
　　
　　有狀態bean可以使用代表了客戶的狀態，并將它作為附加地屬性傳遞給focus類。Focus類不需要關心是有狀態服務的請求還是無狀態服務的請求。從有狀態bean而來的請求擁有附加的狀態信息，因此可以主結果反映出代表客戶的任意的會話狀態。圖2以UML流程圖展示了它們之間的關系。
　　　按需變化解釋有狀態還是無狀態EJB(圖)（圖二）

　　圖2.模式參與者之間的交互序列
　　
　　應用此模式
　　
　　我會用上述模式來解決示例情景的問題。客戶端使用代理來使用查找組件的功能。代理將會查找代碼并暴露出服務所暴露的相同的一組方法。客戶端調用代理上的searchParam1方法，而代理調用無狀態服務上的searchParam1方法。
　　
　　假如客戶端調用了login方法，代理就調用無狀態服務上的相對應的方法。假如查找的結果是單個的顧客，無狀態服務就創建一個有狀態服務并將客戶細節傳給有狀態服務的ejbCreate方法。無狀態服務也創建一個DataSet的實例，并設置用戶數據，同時也在其上設置有狀態bean的處理器，在DataSet上代理保存了處理器并將DataSet傳遞給客戶。
　　
　　客戶現在需要得到與自己相關的一組產品的列表?？蛻舳苏{用代理的retrievePRodUCts方法。代理得到有狀態的處理器，并調用有狀態bean的相關的方法。
　　
　　另外的情景
　　
　　模式是通用的并能用在不同的應用上。上述模式可以用在需要使用一個值列表處理器時。使用無狀態bean可以進行一般的搜索，并且當結果的大小超過能接受的最大值時，我們可以創建一個有狀態bean并將結果傳遞到以一個數據集對象的形式存在的緩存中?？蛻舳送ㄟ^代理請求下一個記錄集，代理可以轉到有狀態bean并存儲細節，比如，最后的記錄處理，最大的對象記錄等等。
　　
　　相關模式
　　
　　服務定位器模式:服務定位器模式降低了客戶的復雜度，這種復雜度由客戶端的依靠，操作需要，查找和創建過程產生，這些都是與資源緊密聯系的。為了消除這些問題，這個模式提供了一種技術來抽象所有的依靠性和網絡細節到服務定位器中。
　　
　　業務代理模式:業務代理擔當客戶端的業務抽象;它提供了抽象同時隱藏了業務服務的實現。使用業務代理降低了表現層和系統服務層之間的耦合。依靠實現策略，業務代理可以保護客戶端免受系統服務API可能的錯誤的侵襲。潛在地，這也就降低了當業務服務API或底層實現變化時影響到表現層代碼。
　　
　　值列表處理器: 值列表處理器模式創建一個值列表處理器來控制查詢功能和返回結果的緩存。值列表處理器直接訪問一個DAO(數據訪問對象)來執行所需的查詢。值列表處理器將DAO的返回結果放到一個傳輸對象的集合中?？蛻舳讼蛑盗斜硖幚砥靼l出請求。值列表處理器返回所需的查詢結果。值列表處理器實現了迭代器模式（GoF）來解決上述情況。
　　
　　結論
　　
　　動態的EJB狀態模式幫助模型組件同時具有了有狀態和無狀的行為。一個使用些模式的組件提供了無狀態會話bean的性能和滿足了客戶端的有狀態的需要。使用此模式的客戶端擁有一個簡單的統一的接口，并且不感知內部有狀態bean和無狀態bean之間的切換。這個模式和其它J2EE模式是自然地匹配的，比如業務代理模式和服務定位器模式。

上一篇：EJB最佳實踐：如何做實體bean的保護

下一篇：在容器外使用EJB 3.0 Persistence