深刻了解EJB （三）EJB是什麼以及規範之間的內在聯繫

       J2EE是一個很大的概念它主要包括了十三個技術規範，除了這十三個外還有一些其餘一些規範但不過重要不須要關注，每一個規範若是深刻研究的話都包括了不少內容，這裏不是逐一分析每個規範的含義，只是談談J2EE規範裏面幾個規範的做用和對企業級開發的一點點理解，若有不恰當支持請指正。

       十三個規範的核心是EJB（enterprise java bean），所以有必要重點分析一下ejb規範，之前ejb尚未向今天這麼輝煌時，ejb1.0問世的時候裏面僅僅有ejb、rmi等幾個簡單規範，也僅僅解決了當時分佈式應用問題訪問問題，其餘如事務JTA、JAF等都是後來版本中逐漸加入，讓咱們一塊兒來看一下現在的ejb規範。

      優點

       專一於業務邏輯

       ejb若是說大了它是一種能夠開發大規模企業應用的組件體系結構，它讓應用或系統開發者集中精力去開發解決各類複雜業務邏輯問題，而不用花費精力來處理分佈式服務器、遠程調用等底層技術，ejb的出現能夠避免底層技術的重複開發，從而提升開發效率。

       移植性好

       ejb便是一個規範也是一個產品，開發時只要咱們遵循ejb規範，開發出來的類或組件能夠部署在任何一個支持ejb規範的服務器上，好比bea 的weblogic服務器、ibm的websphere、jboss等服務器均可以部署ejb組件，服務器的移植性很好，這樣一來咱們能夠把ejb組件部署的兩臺不一樣的服務器上讓他們本身進行交互。

       EJB=RMI+JMS+JNDI

       這個公式覺的可代表它們之間的關係，這個從實現的依賴關係角度出發得出，ejb要依賴於後面的幾種技術。

       

       stateful session bean and stateless session bean

       實現EJB的功能是之後面的幾個技術做爲基礎支撐才讓ejb有如此強大的功能。

       ejb分爲了兩種bean，一種是會話session bean另外一種是mdb bean，session bean又分爲有狀態的session bean和無狀態的session bean，有狀態的session bean 會使用一個或者多個實例變量來保存而無狀態的session bean不可以保存用戶信息，在用戶操做以後會丟失之前的操做記錄，好比購物網站的購物用戶若是將要買的商品加入到購物車以後，退出從新登陸，從新與服務器之間創建鏈接，那麼用戶以前瀏覽過的信息或者填寫的數據將丟失，這就是有狀態與無狀態會話bean的主要區別。

       rmi 與 對象序列化

       rmi通訊使用標準的stub、skeleton機制，遠程對象的stub充當遠程對象的本地代理，調用程序將調用本地stub方法，而stub方法負責調用遠程對象的方法，stub對象具備的接口同遠程對象的接口同樣。

       

      rmi調用同socket編程區別

        第1、.RMI是面向對象的，然後者不是。
        第2、.RMI是與語言相綁定的。
       第3、從網絡協議棧的觀點來看，RMI與socket的網絡編程處於不一樣層次上。
       第4、就是兩種方法的性能比較，同帶寬同數據，socket性能比rmi好一些。

       Socket與RMI比較：http://blog.csdn.net/liuxuezong/article/details/6256549

       有狀態session bean實現分佈式遠程調用基礎是rmi，rmi意思是遠程調用能夠調用遠程對象的方法，rmi是純java編寫僅僅支持javaj環境下遠程調用，並不能跨平臺，rmi調用是依賴於對象序列化，對象序列化是將對象狀態轉化爲字節流又從字節流轉爲對象的過程，另外一端接受到字節流後能夠經過java.io裏面的字節流類將流轉化爲對象或文件保存在磁盤上，完成一次遠程調用，調用的結果一樣會以序列化的方式傳回給調用端。

       java.io操做和對象序列化都是java基礎裏面的內容，可見掌握基礎很是重要若是不懂基礎這些你都實現不了的，若是想了解基礎的同仁能夠找一本書系統的學習一下，腦海中浮現出了幾句話「多麼牛逼的技術都是創建在基礎之上」，」萬丈高樓平地起「，說的仍是頗有道理的。

       一樣牛逼的技術和底層基礎之間有着各類關聯，知道了它們之間的聯繫會在大腦裏面造成一張圖，讓你掌握的技術更加牢固老師說記是記不住，分析每一個技術之間的關係會讓你體會的更加深入。

       rmi與jndi

       jndi的做用很簡單就是爲對象起一個名字，而應用程序能夠就能夠經過該名字來獲取對應的對象。

        1.客戶端代碼經過jndi來查找ejb，遠程方法調用rmi也要經過jndi來訪問遠程服務對象。

       rmi的服務器端須要將將服務經過jndi綁定，將服務暴露出來供客戶端查找，客戶端也是經過jndi命名服務來查找對象，進而調用遠程對象的方法。

       MDB=EJB+JMS

       JM是爲了達到這樣的效果一個ejb組件或類將jms消息發送到指定消息目的，另外一個組件讀取並接受消息內容，這樣就實現了兩個組件之間的通訊，通訊的兩個組件之間不須要知道對方的存在，這就是jms規範要實現的效果。

       

       咱們人爲的給ejb bean整合jms服務，既能夠獲得mdb bean（消息驅動bean），也存在於ejb容器裏面能夠利用ejb提供的系統服務，如事務、安全和併發控制等等，只是消息bean只負責處理消息，不一樣客戶端打交道。

       消息驅動bean能夠看做是rmi調用的補充，rmi調用是同步調用基於對象，調用一個遠程方法以後不能繼續執行本地方法須要等待返回結果才能繼續往下執行，而mdb利用jms消息服務器通訊，支持點對點的異步通訊方式和發佈訂閱模式兩種模式。

       mdb與ejb區別

       到這裏你是否對mdb與ejb有點迷糊了，咱們分析一下它們各自的適用場景和區別。

       mdb是由無狀態的session bean變化而來的，在用法上他們有些相似，例如他們都是無狀態的都不會保存客戶端的調用狀態，它們能夠被多個客戶端共享，他們都是應用程序的業務邏輯組件，那麼何時使用無狀態session bean、何時使用mdb bean呢？

       無狀態的session bean提供了業務接口，客戶端須要同步方式調用無狀態無狀態session bean,而mdb bean客戶端不能直接調用，它只是至關於一個消息消費者。

       mdb應用場合：1.業務方法處理時間比較長，並且處理時間可能具備不肯定性 2.客戶端調用該方法後無需當即獲得返回結果。

       在通常編程中將無狀態的session bean做爲業務邏輯組件使用、mdb做爲控制器使用，調用過程是；

       消息發送者--->jms消息目的--->觸發onMessage()方法--->MDB--->調用業務方法--->session bean。

總結：

       ejb是一種很好的分佈式解決方案，筆者喜歡它對各類技術的融合並實現了分佈式調用能力，它的設計思想、設計方式值的咱們去學習和深刻研究，後來的輕量級組合spring+hibernate/springMVC+spring+hibernate等裏面有些設計原理可能也是參考了ejb前期的設計規範想出來的，它們摒棄了ejb開發複雜、難度係數大的問題。

       後來ejb3.0、ejb3.1版本都在朝着開發簡單、輕量級方向發展，相信ejb功能會優化的更加簡單。