EJB3.0中的session bean以及MDB解析

大型業務系統面臨的主要問題就是高併發性和事務訪問，客戶端的數量與服務器端的分佈式對象數量存在一定程度的正比關係，客戶端數量越多，服務器端分佈式對象也就越多，如何解決這種高併發的問題也就成了企業級架構首先要解決的問題。EJB作爲一種服務器端分佈式組件，爲我們提供了應對策略。

EJB提供了兩種管理大量分佈式對象的策略：實例池化和激活。下面分別對EJB組件模型中的三種模型進行一些分析。

第一種：無狀態的會話Bean（Stateless session bean)
Stateless session bean採用池化技術來實現，stateless session bean的客戶端不直接於bean class的實例進行通信，而是通過bean class所暴漏的遠程或者本地接口來通信，再進一步的講就是通過bean class的代理存根來與EJB容器通信。這樣以來就可以爲每一個bean class維護一個的實例池，然後用這些實例來爲大量的客戶進行服務。

stateless session bean的生命週期由三個不同的狀態來組成。不存在，池化狀態以及就緒狀態。不存在就說明bean class的實例還沒有初始化，池化狀態就說明實例已經初始化了，但是還沒有與EJB Obejct關聯（骨架），就緒狀態說明實例已經於EJB請求關聯了，可以爲客戶提供服務了。

第二種：消息驅動bean。
MDB同樣也採用池化技術來實現，只所以可以採用池化技術，是因爲MDB的客戶端也不於具體的MDB實例進行通信，相反是通過一種鬆耦合的方式來實現。首先客戶發送消息給EJB容器的消息目的地，然後EJB容器再將消息發送到具體訂閱此目的地的MDB實例。

同樣的道理，EJB容器也爲每一個MDB class維護一個實例池，當有消息發送到此MDB訂閱的目的地時，EJB容器就會挑選一個MDB class的實例來接受和處理消息。

第三種：有狀態的會話bean (Statefull session bean)

與stateless bean 和MDB不同，Statefull session bean採用激活機制來實現，爲什麼採用激活機制來實現，是因爲有狀態的會話bean要維護於客戶端的會話狀態，每個實例只能服務於同一個客戶端。

MDB採用激活機制來降低服務器資源的消耗，當EJB容器資源不夠的時候，它就會選擇一些能被鈍化的實例，將其序列化到磁盤上，當需要的時候，再將其從磁盤恢復到內存中。

綜上所述，客戶端與EJB組件進行通信時，它們其實都不是直接於bean class的實例進行通信，而是通過本地的代理存根於服務器端的骨架進行通信，而骨架再將具體的EJB請求委託給具體的bean class的實例來響應。