首先，我們必須明確，爲什麼要使用J2EE？J2EE優點是什麼？使用J2EE的主要原因是多層結構，傳統的兩層C/S結構難於維護，穩定性極差，界面代碼和數據庫代碼混淆在一起，牽一動百，多層結構使得界面和數據庫完全分離，並且誕生了中間件這樣的技術，如下圖：
Web+EJB能組成真正的多層結構
爲什麼使用EJB我原先認爲這不是一個討論的話題，因爲EJB是J2EE重要的組成部分，可以說沒有EJB的J2EE只是一種Web系統，這樣的系統非常容易喪失了多層結構的大部分優點（仔細想想那些混合多種層次功能JavaBeans和傳統兩層結構有什麼區別？）。
當然，可以人爲地在Javabeans之間進行層次劃分，例如Hibernate算數據持久層，某些JavaBeans是業務核心層，但是因爲都是普通JavaBeans，這種劃分沒有一種強制性和明顯標誌性，這樣的系統更換了主創人員或設計師，可能就會被新的程序員修改得非常混亂。
我們先看看一個包含EJB的J2EE系統是如何清晰地表達層次。如下圖：
Web完全只是一個MVC模式的實現，關鍵業務核心是在EJB的服務層實現，這樣做的優點是，Web只負責界面相關部分，因爲，如果是一個智能客戶端，如Swing或J2ME，在不需要修改任何業務核心的情況下能夠方便地更換。同樣，提供Web Services功能，也只是在 Web層修改，不會涉及EJB方面的修改，同樣保證了系統的穩定性，保證了系統升級和未來的擴展性。
如果不使用EJB，在EJB服務層實現的業務核心將由普通JavaBeans實現，使用何種架構或設計能夠保證負責MVC的JavaBeans和負責業務核心的JavaBeans清晰地分開，又如何保證在新的程序員不會破壞和打亂你精心佈局的JavaBeans架構？
EJB提供性能優化支持
最主要的是性能問題，由於以前國內中文Java網站有些人彎曲EJB，認爲EJB性能低，其實這是一種非常膚淺錯誤的認識，我們首先看看在一般Java環境中是如何提高性能。
假定一個JavaBeans爲A，那麼一般使用這個JavaBeans命令如下：
A a = new A();
但是，在高訪問量的環境中，new A()其實是很費時消耗系統性能的，因此，能不能在軟件系統啓動時候就預先建立一些對象，這樣，系統運行時，從這些已經生成的對象池中借用一個，這樣，就無需在使用時進行New，節約了開銷，提高了性能，因此，真正成熟性能解決方案都是需要對象池等支持。
在一個純Web結構的系統（也就是隻能運行在Tomat環境中），例如Struts + Hibernate等這樣的系統，除非自己動手做，一般是沒有對象池技術支持的，因此他們的性能只能算是Demo演示版本的性能，根本無法承受大容量併發訪問，也無法稱爲一個成熟的系統，所以，我們研究成熟的開源Web系統，如Jive、OFBize，LifeRay等，他們都在Web層擁有自己的對象池和緩存池。
對象池和緩存機制是J2EE必須的嗎？當然，是所有成熟系統必須的，Windows系統如果去掉緩存將會變得怎樣？
自己動手開發對象池和緩存機制並不是一件簡單的事情，需要對多線程以及同步鎖等底層原理有深層次的把握，這其實也是一門非常深入的Java研究分支，所以，你可以拋開你的客戶焦急的催促，精心研究開發自己的對象池和緩存池。
但是，EJB容器（如JBoss）已經提供了對象池和緩存機制，所以，沒有事務機制的無狀態Session Bean的性能肯定要強於普通JavaBeans。EJB容器不但在單機中提供了對象池和緩存，而且可以跨服務器實現動態負載平衡，這些都無需開發者自己開發任何軟件代碼，結構如下：
EJB組件能提供真正的可重用框架
每一個jar包代表一個EJB組件，一個系統可以由多個可重用的EJB組件構成，例如：樹形結構EJB組件；自增序號EJB組件；用戶資料EJB組件等，這樣的EJB組件可以象積木一樣搭配在大部分應用系統中，提高了系統的開發效率，保證了開發質量。
下圖是某個新的具體系統時應用到的EJB組件圖，在這個新的應用中，由於使用了以前大量可重用的EJB組件，新的開發工作基本集中在界面設計和流程安排上：
EJB提供了事務機制
事務機制對於一些關鍵事務是很重要的，例如ATM機提款，提款有多個動作：修改數據庫以及數錢等，如果這其中有任何一個環節出錯，那麼其它已經實現的操作必須還原，否則，就會出現，提款人沒有拿到錢，但是卡上已經扣款等不可思議的事情發生。
EJB提供的事務機制非常周全，但事務機制帶來的缺點是性能的降低，因此，有些人認爲EJB很重，因爲在實際應用中，有的用戶系統可能不需要事務機制，只是需要EJB提供的性能優化機制，這樣，如果使用EJB，就象叫一個人來背東西，他除了揹着我要的東西外，還揹着我不要的東西。
除非你是一個完美主義，在一般企業應用或數據庫系統應用中，EJB不會對你構成很重的包袱。
CMP獨特的優點
開源以及一些數據庫持久層技術崇拜者，一直抨擊CMP，認爲CMP慢無用，實際最大的問題是他們的設計和使用問題。
由於EJB容器（如JBoss）對CMP實現有事務機制的緩存優化，因此，CMP特別適合多個用戶同時更新同一個數據源的情況，CMP這種嚴格的事務完整性保證多個用戶同時操作一個數據記錄時，能夠保證性能優化和數據的完整性，如果這個數據記錄是是軟件系統的狀態標誌，它的狀態會影響系統中很多的環節，那麼狀態更改的重要性不言而喻。
如果沒有事務完整性支持，你的軟件系統在用戶訪問量變大，就會變得發生各種不可能發生的邏輯錯誤，查看程序邏輯是正確的，那麼問題出在哪裏？出在數據完整性上。
由於每個CMP在內存中都有一個緩存，在實際應用中，如果使用CMP批量讀數據庫數據，幾萬條查詢完畢，內存中充滿了幾萬條CMP緩存，如果這時你的EJB容器設置不當（如使用JBoss缺省配置），那麼JVM的垃圾回收機制就會頻繁啓動，導致你的系統變慢甚至死機，這也是一些人抨擊CMP慢的原因所在，其實他們使用方法不當，或者沒有正確配置EJB容器CMP緩存。
對於這種情況，根據J2EE核心模式，推薦使用DAO+JDBC方式。
小結
除非你對設計模式非常精深，能夠將自己系統中的JavaBeans使用模式或某種框架進行固定分層，同時，你孜孜不倦研發出對象池，又熟練於JTA等事務機制，你可以選擇沒有EJB的純Web結構，就象Jive、OFBiz那樣。當然還有一個前提，老闆不懂或者非常有挑戰性（做與IBM SUN 微軟齊名的公司和技術）。
不要再被TSS那些狂熱的開源先生誤導，他們有時間有保障可以做他們喜歡的事情，作爲專業的J2EE程序員，按照J2EE標準去學習去行動，也不要認爲，只要使用了J2EE其中某個技術如Jsp或JavaBeans就心安理得認爲自己的系統是J2EE了。
當然，我並不是說純Web系統不能實現多層結構，但是至少在很多方面沒有Web+EJB結構完善和清晰，所以，EJB不是J2EE可以忽視的部分，而是主要的重要的部分，重要業務功能核心都封裝在EJB中，相反Web層是一種次要的、和界面相關的層次。
