EJB技術正在像其他輝煌過的技術一樣走到了一個關口。2000年以前這項技術充滿了傳奇色彩，被大批企業不假思索地接受。然而理想畢竟是理想，經過了幾年的發展，今天這項技術卻正在被懷疑或者至少說讓技術人員猶豫不決，現實的是J2EE的對手出來了，.NET似乎又有著后發的技術優勢。大部分的探討和爭論已經開始轉向這兩個體系結構的對比。Java陣營內部同樣發出了懷疑的聲音，最直接的就是對EJB的攻擊，因為人們發現原來這項技術所做的承諾似乎都走向了相反的方向

　　1．大量的案例由于采用了這種技術反而使得系統開發日趨復雜，而不是想像的簡化開發周期加長成了家常便飯，實現一個進銷存就把很多人難倒。

　　2． EJB成了昂貴的代名詞，而不是期望的成本降低

　　3． 廢了半天勁還不如用消息傳遞進行系統互操作

　　4． 最終發現徹底地擺脫平臺是不可能的

　　但是Java總歸還是不錯的，于是有了Spring等等N種體系。EJB開始讓人們困惑。任何技術和人生一樣有它的困惑期，但是EJB給人們的困惑尤為經典，更具意義。J2EE和其他體系的對比已經泛濫于網上，實際應用的經驗也隨處可見，以至于不需要這里介紹，但是EJB現在并未被單獨地被重視這是應該值得注意的，這與J2EE發展史卻是背道而馳的。必須承認這么一個事實，EJB是被單獨提出和定義的，最早是完全單獨的一種規范，這與所謂體系結構并沒有直接的關系，或者說EJB的意義和目標絕不只是在J2EE內封裝商業邏輯，所以過于在框架內討論EJB，或者說認為J2EE的弱點一定要蔓延到EJB上是否合適是值得探討的。

　　EJB誕生的初期人們的興奮關鍵在于這種模型吸收了以往組件技術的精華，并有很大發展，使人們看到了強健的商業組件制造成本降低的期望，特別是跨越平臺的可裝配性和移植性，這是軟件工程界一直的夢想，因為這意味著企業端計算程序設計工業化和細致分工也許要成為可能。這種思想目前也影響了界面一級的應用，例如所謂的Portlet技術，IBM公司的WebSphere平臺的技術也許不是可怕的，但是有幾十個合作伙伴事實上給它提供了類似的合作，這才真正是讓對手感到害怕的。因此我們談論EJB的時候，談論它的價值和作用，脫離了它的設計目標也就失去了更大的意義，以下的商業環境和軟件技術瓶頸應該重新被審視：

　　1． 軟件工程就重用領域來講是否超越了組件時代，或者說已經不需要組件了？

　　2． 軟件的重用是否只需要互調用而不需要重復裝配，乃至裝配到不同的部位？

　　3． 商業邏輯是否仍然需要封裝，并保持強健的特性，不間斷地服務

　　4． 組件和強健和可用性是互聯特性能取代的嗎？

　　5． 是否有更廉價的組件形式超越EJB并同樣獲得眾多的支持？

　　6． .NET的組件標準和EJB是否有可比性，或者說什么組件形式和EJB才有可比性？

　　當冷靜地思考的時候就知道，技術不應該被當作明星吹捧，但同樣也沒有容易倒下的軟件技術。EJB不成熟，但不等于可以輕易被否定。是EJB使得很多普通的程序員能夠介入原來貴族似的組件開發，甚至是簡單的Windows上面開發UNIX上的組件，EJB的歷史問題大多數在于將這種技術錯誤地濫用：一個瀏覽人數少的可憐廣告瀏覽程序也要用組件，對于一個只想簡單算出庫存的客戶設計了所謂N年后才需要的擴展性。同樣現實中在這一技術擅長的領域，至少目前還無法找到更強大的競爭者。技術選擇是應用型的技術人員永恒的主題，類似的困惑會不斷的出現，最重要的是認同它們的理想和目標，保持對它們客觀清醒的認識。放到擅長的領域的技術才是最優美的，這和人生沒有什么兩樣。