EJB究竟是什麼，真的那麼神奇嗎？？

標籤：style   http   color   io   ar   使用   java   for   strong   

1. 我們不禁要問，什麼是"服務叢集"？什麼是"企業級開發"？
既然說了EJB 是為了"服務叢集"和"企業級開發"，那麼，總得說說什麼是所謂的"服務
叢集"和"企業級開發"吧！
這個問題事實上挺關鍵的，由於J2EE 中並沒有說明確，也沒有詳細的指標或者案例告訴
廣大程式猿什麼時候用EJB 什麼時候不用。於是大家都產生一些聯想，覺得EJB"分布式運
算"指得是"負載平衡"提高系統的執行效率。然而，預計非常多人都搞錯了，這個"服務群集"
和"分布式運算"並沒有根本解決執行負載的問題，尤其是針對資料庫的應用系統。
為什嗎？
我們先把EJB 打回原形給大家來慢慢分析。

2. 把EJB 掰開了揉碎了
我們把EJB 的概念好好的分析一下，看看能發現些什麼蛛絲馬跡。

3.1 EJB 概念的剖析
我們先看一下，EJB 的官方解釋：
商務軟體的核心部分是它的商務邏輯。商務邏輯抽象了整個商務過程的流程，並使用計
算機語言將他們實現。
……
J2EE 對於這個問題的處理方法是將商務邏輯從client軟體中抽取出來，封裝在一個組
件中。這個組件執行在一個獨立的server上，client軟體通過網路調用組件提供的服務以實
現商務邏輯，而client軟體的功能單純到僅僅負責發送調用請求和顯示處理結果。在J2EE 中，
這個執行在一個獨立的server上，並封裝了商務邏輯的組件就是EJB（Enterprise Java
Bean）組件。
這當中我們主要關注這麼幾點，我們來逐條剖析：
剖析1：所謂："商務邏輯"
我們注意到在EJB 的概念中主要提到的就是"商務邏輯"的封裝，而這個商務邏輯究竟是
什嗎？說的那麼懸乎，事實上這個所謂的"商務邏輯"我們全然能夠理解成執行特定任務的"類
"。
剖析2：所謂："將商務邏輯從client軟體中抽取出來，封裝在組件中……執行在一個服
務器上"
既然我們知道了"商務邏輯"的概念就是執行特定任務的"類"，那麼，什麼叫"從client
軟體中抽取出來"？事實上，這個就是把原來放到client的"類"，拿出來不放到client了，放
到一個組件中，並將這個組件放到一個server上去執行。
3.2 把EJB 這個概念變成大白話
變成大白話就是，"把你編寫的軟體中那些須要執行制定的任務的類，不放到client軟
件上了，而是給他打成包放到一個server上了"。
3.3 發現問題了
無論是用"八股文"說，還是用大白話說這個EJB 概念都提到了一個詞--"client軟體"。
"client軟體"？難道EJB 的概念中說的是C/S 軟體？
是的，沒錯！
EJB 就是將那些"類"放到一個server上，用C/S 形式的軟體client對server上的"類"進
行調用。
快崩潰了吧！
EJB 和JSP 有什麼關係？EJB 和JSP 有關係，可是關係還真不怎麼大，至多是在JSP 的
server端調用遠端服務上的EJB 類，僅此而已。

4 .1 EJB 的最底層到底是什麼
我們揭開了EJB"八股"概念的真諦，那麼，再來分析EJB 的底層實現技術，通過底層實
現技術來分析EJB 的工作方式。

4.2 EJB 的實現技術
EJB 是執行在獨立server上的組件，client是通過網路對EJB 對象進行調用的。在Java
中，能夠實現遠程對象調用的技術是RMI，而EJB 技術基礎正是RMI。通過RMI 技術，J2EE
將EJB 組件建立為遠程對象，client就能夠通過網路調用EJB 對象了。
4.3 看看RMI 是什麼東東
在說RMI 之前，須要理解兩個名詞：
對象的序列化
分散式運算與RPC
名詞1：對象的序列化
對象的序列化概念：對象的序列化過程就是將對象狀態轉換成位元組流和從位元組流恢複對
象。將對象狀態轉換成位元組流之後，能夠用java.io 包中的各種位元組流類將其儲存到檔案裡，
或者通過網路連接將對象資料發送到還有一個主機。
上面的說法有點"八股"，我們最好還是再用白話解釋一下：對象的序列化就是將你程式中實
例化的某個類的對象，比方，你自定一個類MyClass，或者不論什麼一個類的對象，將它轉換成
位元組數組，也就是說能夠放到一個byte 數組中，這時候，你既然已經把一個對象放到了byte
數組中，那麼你當然就能夠隨便處置了它了，用得最多的就是把他發送到網路上遠端計算
機上了。2 11所看到的。

名詞2：分散式運算與RPC
RPC 並非一個純粹的Java 概念，由於在Java 誕生之前就已經有了RPC 的這個概念，RPC
是"Remote Procedure Call"的縮寫，也就是"遠端程序呼叫"。在Java 之前的大多數編程語
言，如，Fortran、C、COBOL 等等，都是過程性的語言，而不是物件導向的。所以，這些編
程語言非常自然地用過程表示工作，如，函數或子程式，讓其在網路上還有一台機器上運行。說
白了，就是本機電腦調用遠端電腦上的一個函數。
2 12所看到的。

名詞3：二者結合就是RMI
RMI 英文全稱是"Remote Method Invocation"，它的中文名稱是"遠程方法調用"，它就
是利用Java 對象序列化的機制實現分散式運算，實現遠程類對象的執行個體化以及調用的方法。
說的更清楚些，就是利用對象序列化來實現遠程調用，也就是上面兩個概念的結合體，利用
這種方法來調用遠端類的時候，就不須要編寫Socket 程式了，也不須要把對象進行序列
化操作，直接調用即可了很方便。
遠程方法調用是一種電腦之間對象互相調用對方函數，啟動對方進程的一種機制，使用這
種機制，某一台電腦上的對象在調用另外一台電腦上的方法時，使用的程式文法規則和
在本地機上對象間的方法調用的文法規則一樣。
2 13所看到的。

4.4 長處
這種機制給分布計算的系統設計、編程都帶來了極大的方便。僅僅要依照RMI 規則設計程
序，能夠不必再過問在RMI 之下的網路細節了，如：TCP 和Socket 等等。隨意兩台電腦
之間的通訊全然由RMI 負責。調用遠端電腦上的對象就像本機物件一樣方便。
RMI 可將完整的對象作為參數和傳回值進行傳遞，而不僅僅是提前定義的資料類型。也就
是說，能夠將相似Java 哈西表這種複雜類型作為一個參數進行傳遞。
4.5 缺點
假設是較為簡單的方法調用，其運行效率或許會比本地運行慢非常多，即使和遠程Socket
機制的簡單資料返回的應用相比，也會慢一些，原因是，其在網路間須要傳遞的資訊不僅僅
包括該函數的傳回值資訊，還會包括該對象序列化後的位元組內容。
4.6 EJB 是以RMI 為基礎的
通過RMI 技術，J2EE 將EJB 組件建立為遠程對象，EJB 儘管用了RMI 技術，可是卻僅僅需
要定義遠程介面而無需產生他們的實作類別，這樣就將RMI 技術中的一些細節問題屏蔽了。
但無論怎麼說，EJB 的基礎仍然是RMI，所以，假設你想瞭解EJB 的原理，僅僅要把RMI
的原理搞清楚即可了。你也就弄清楚了什麼時候用EJB 什麼時候不須要用EJB 了。

5. EJB 中所謂的"服務群集"
既然已經知道了，RMI 是將各種任務與功能的類放到不同的server上，然後通過各個服
務器間建立的調用規則實現分布式的運算，也就明確EJB 所謂的"服務群集"的概念。
就是將原來在一個電腦上運算的幾個類，分別放到其它電腦上去執行，以便分擔運
行這幾個類所須要佔用的CPU 和記憶體資源。同一時候，也能夠將不同的軟體功能模組放到不同的
server上，當須要改動某些功能的時候直接改動這些server上的類即可了，改動以後全部客
戶端的軟體都被改動了。2 14所看到的。

 

6. 這樣的部署難道是無懈可擊
圖2 14所看到的的這個"服務群集"看似"無懈可擊"，事實上是它這個圖沒有畫完整，我們來
把這個圖畫完整，再來看看有什麼問題沒有。
6.1 瓶頸在資料庫端
細緻觀察之後，發現這樣的配置是有瓶頸的，2 15所看到的。

我們看看圖2 15的結構圖，如今假設想實現各個server針對同一個資料庫的查詢，那
麼，無論你部署多少個功能server，都須要針對一個資料庫server進行查詢操作。也就是說，
無論你的"計算"有多麼"分布"也相同須要從一台server中取得資料。儘管，看起來將各個功
能模組分布在不同的server上從而分擔了各個主要電腦的CPU 資源，然而，真正的瓶頸並不
在這裡，而是，資料庫server那裡。資料庫server都會很忙的應付各個server的查詢及操
作請求。
因此，通過這個結構圖使我們瞭解到了EJB 根本不能全然解決負載的問題，由於，瓶頸
並不在功能模組的所在位置，而是在資料庫server這裡。
6.2 假如分開資料庫，資料共用怎麼辦
有的讀者一定會想到以下的這個應用結構，2 16所看到的。

就是把每個功能server後面都部署一個資料庫，這樣不就攻克了上節所說的問題了
嗎？是的攻克了資料庫查詢負載的問題，然而又出現了新的問題，就是"資料共用"的問題就
又不easy攻克了。
6.3 網路面臨較大壓力，讓你的應用慢如老牛
我們再向前翻看看2 15所看到的的這樣的架構中存在兩個網路，一個是"A 網"一個是"B
網"，這兩個網路是不同的。"B 網"往往是區域網路，一般頻寬是10M/100M，速度較快，因此
到還好說，然而，"A 網"往往是互連網或者是利用電信網路互聯VPN 網或稱廣域網路。"A 網"
的特點是頻寬一般較窄，如ADSL 的網路唯獨512K-2M 的頻寬，由於廣域網路互聯的成本較
高，所以一般不會有較高的頻寬。
而在這個網路上恰恰跑的是功能模組和client軟體之間交換的資料，而這部分資料恰恰
優勢很佔用頻寬的。
因此，這個應用架構其執行速度能夠想見是多麼的慢了。說句不誇張的話，有點想老牛
拉破車一樣的慢。
一個如老牛的系統：
眼下在中國互連網做電訊廠商網路管理系統的一個大公司，它的一個早期的網管軟體就是
採用了這樣的架構來做的C/S 結構的應用系統。
有一次，我作為評估者來對其應用系統進行評估，將其部署到一個非電訊廠商大型的網路
中的時候，便出現了我們上述描寫敘述的情況，速度已經到了難以忍受的地步，開啟一個流量圖，
有時候須要用15分鐘的時間才幹呈現完整。然而，該系統在開發階段並沒有發現這個問題，
為什麼呢？由於，他們沒有考慮到應用的實際使用者串連網路的複雜性，從而給該公司造成較
大損失，以至於，這個開發架構被終於遺棄。

7. EJB 活學活用，J2EE 不是必須使用EJB
通過上面小節的解說似乎好像EJB 和開發Web 應用程式的B/S 結構的系統關係並不大，事實上
倒也不然。我們假設把"client程式"理解成某一台server，這樣也是能夠被應用的，並且，
假設是server互相之間做EJB 的調用的話，也就不存在廣域網路頻寬節流設定的問題了。
可是，例如以下情況盡量就不要使用EJB 了：
1、較為簡單的純Web 應用程式開發，不須要用EJB。
2、須要與其它服務程式配合使用的應用，但調用或返回的自己定義的網路通訊協定能夠解決
的應用程式,不須要使用EJB。
3、較多人並發訪問的C/S 結構的應用程式，盡量不要使用EJB。

 

 

總結：

a.EJB實現原理： 就是把原來放到client實現的代碼放到server端，並依靠RMI進行通訊。

b.RMI實現原理 ：就是通過Java對象可序列化機制實現分布計算。

c.server叢集： 就是通過RMI的通訊，串連不同功能模組的server，以實現一個完整的功能。

 

EJB究竟是什麼，真的那麼神奇嗎？？