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

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

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

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

　　4． 最終發(fā)現(xiàn)徹底地擺脫平臺是不可能的

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

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

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

　　2． 軟件的重用是否只需要互調(diào)用而不需要重復(fù)裝配，乃至裝配到不同的部位？

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

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

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

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

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