1. 備受爭議的EJB
EJB也許是Java領域里中最受爭議的技術了。有人說EJB是最偉大的發明，也有人說EJB完全是多此一舉;當一些人陶醉于EJB的深奧理論時，另外一些人卻正被EJB的繁瑣復雜所折磨;嘗到EJB甜頭的人，在EJB的每個新版本中，都能發現盼望已久的驚喜，而被EJB拒之門外的人，則隨著EJB的升級，愈發對EJB敬而遠之了。
EJB的全稱是Enterprise JavaBeans，JavaBeans很普通，不過Enterprise就不那么簡單了。什么技術，一旦被冠以Enterprise的名頭，就像男人走入婚姻殿堂一樣，身上的責任與單身漢不可同日而語了。從定義上看，JavaBeans只是J2SE平臺上的一個組件架構，包含一些業務邏輯，并且可以被重用。
EJB不同，作為企業級的JavaBeans，Sun對EJB的定位要遠遠高于JavaBeans，所以EJB的目標也比JavaBeans要遠大得多，除了作為一個包含業務邏輯的可重用組件外，EJB更被賦予了諸如“可移植”、“安全”、“可伸縮”、“交易性”等特征。
所有這些EJB必須具備的特征，其實正是企業應用所要求的。這也是Enterprise一詞所代表的技術上的含義。企業應用不同于普通應用，企業應用是大規模的、高復雜度的和關鍵的，它所面臨的挑戰，要比普通應用艱巨得多。比如，企業應用對可移植性的要求非常高，這是因為，企業都不愿意將自己的未來綁定到某個供應商的身上，除非是不得已而為之;又比如，安全性對企業應用至關重要，誰能使用什么功能、哪些數據哪些人可以看到，都有嚴格的限制;更不用說的是企業應用的可伸縮性了，當業務規模變大時，你希望全盤推翻舊系統，采購一批嶄新的軟件和硬件，對IT系統來個徹底的革命嗎?增加一臺服務器就能應付更多的客戶，我想這是頭腦正常的企業家都希望的。
企業應用的需求，就是EJB的目標。用EJB開發的應用，完全符合企業應用的特征。EJB是一個規范，只要符合這個規范，EJB可以在不同的操作系統、不同的應用服務器中無縫地移植;EJB允許開發者在EJB部署描述文件中進行方法級的、基于角色的安全性配置，以統一的方式保護企業應用和數據的安全性;只要你愿意，EJB應用可以全部部署在一臺單獨的服務器上，也可以任何組合方式分布在一組服務器群中，滿足你擴大規模和均衡負載的要求;如果你想保持事務的完整性，那么，EJB的事務管理是一個可靠的、穩健的解決方案。
這就是EJB，一個企業應用的集大成者，多種技術的濃縮精華，全能的框架和基礎結構。可就是這樣一個將企業應用的開發簡化到了前所未有之程度的技術，卻成為許多人口誅筆伐的對象。復雜、難以使用、性能低下、繁瑣等等，從1998年EJB誕生之日起，各種各樣的惡名就伴隨左右，直到八年后的今天，當EJB迎來它的第三次大變臉時，質疑之聲依然不絕于耳。EJB真的那么糟糕嗎?
2. EJB是企業應用的先驅
筆者接觸第一個企業應用，是在1997年。那時PowerBuilder風頭正勁，不過，多數人使用PowerBuilder，是因為它的數據窗口。當時筆者在一個項目中遇到一個難題，那就是如何把一臺服務器上的應用一分為二，跑在兩臺服務器上，以提高性能。這是典型的分布式應用，雖然不是一個完整意義上的企業應用，不過，因為應用中需要用到分布式的概念，多少也算和企業應用沾上邊了。
PowerBuilder其實是個非常不錯的開發工具，在1997年的時候，已經提出了分布式應用的概念，并且付諸實施了。在PowerBuilder中，一個組件可以有一個稱為代理的對象，這個對象可以運行在與組件不同的機器上，其他組件通過代理可以訪問該組件的功能。
這是一個很初級的分布式應用框架，不過，那時已經給了筆者很大的震動。我試著編了一個實驗性質的程序，當我在一臺機器上按下一個按鈕時，另外一臺機器上赫然彈出一個預期中的對話框，著實讓我大吃一驚。沒有任何Socket編程，也不需要關心實際的應用跑在哪臺機器上，PowerBuilder讓我首次見識了分布式應用框架的巨大威力。
PowerBuilder解決了分布的問題，但安全性和事務控制，仍然需要程序員自己想辦法。十個程序員可以有十種解決方案，每種都不同，而每種都可能含有未經發現的缺陷。在EJB之前，企業應用的開發沒有規范可循，每個公司都有自己的一套方案，盡管每個公司都對自己的方案充滿信心，但其實這些未經大量應用考驗的方案，都有著這樣那樣的不足或局限。
J2EE是第一個為業界所廣為接受的完整的企業應用框架，而EJB在其中扮演重要角色。在J2EE框架的支持下，運行在EJB容器中的EJB，完全符合企業應用關于分布、移植、安全和交易的要求。這對于企業應用的開發者來說，意義非同尋常。首先，現在大家可以在一個公共的平臺技術上構建自己的企業應用，不必絞盡腦汁“發明”自己的“輪子”，從而節省大量無謂的、重復性的技術和時間投入;其次，一個公開的平臺，讓大量的企業應用開發者有了共同語言，可以相互交流平臺的使用經驗和教訓，這樣，隨著平臺之上企業應用的不斷增加，平臺的優劣得失一覽無遺，有利于平臺的改進和發展。
這就是EJB為企業應用作出的貢獻。在EJB之前，多數人不知企業應用為何物，或者雖然有企業應用的模糊概念，但要編寫一個企業應用，談何容易。不同的操作系統、不同的開發語言、不同的網絡環境、不同的應用終端，開發一個企業應用，程序員面臨著兩難的抉擇：要么限定應用的軟硬件平臺，或者犧牲應用的安全性、分布性或交易性，開發一個“偽”企業應用;要么下決心開發一個真正的企業應用，然后累死自己。
3. EJB是一種思想
EJB讓程序員編寫真正意義上的企業應用而不必累死，應該說，EJB已經是企業應用開發領域的一大進步，讓企業應用和普通應用的開發差距縮短到了前所未有的程度，可是，為什么還有很多人抱怨EJB過于復雜呢?EJB的復雜性其實是個偽命題。所謂復雜，一定是相對的。如果和普通應用相比，EJB當然要復雜很多，因為人們對于普通應用沒有企業應用那么苛刻的要求。但是，如果將EJB之前和EJB之后的企業應用開發的難度相比，相信人們就會對EJB贊譽有加了。舉個不準確的例子，假如EJB之前，企業應用的難度是普通應用的10倍，那么，EJB之后，這個比例縮小到了5倍，批評EJB復雜者，只看到了還剩下的5倍復雜度，卻沒有看到EJB所減去的5倍復雜度。
關于EJB過于復雜的論斷，還來自于與其競爭技術的比較。例如，Spring就是一個聲稱比EJB更簡單的、輕量級的企業應用框架。Spring確實簡單，很多人喜歡Spring，也正是因為Spring簡單。可是，Spring的支持者們，忽略了一個基本的事實，那就是Spring的功能要比EJB弱，也就是說，Spring是通過放棄某些不常用的功能來達到簡化目的的。Spring好比一輛沒有安全氣囊的車，盡管依然可以拉客跑運輸，但一旦發生碰撞事故，也許司機會陪上性命。沒有安全氣囊的Spring，在制造上當然要比有安全氣囊的EJB簡單，而且輕便，跑得快，不過，Spring始終不適合投入正式營運。這就是為什么不推薦在大型企業應用上采用Spring的原因。沒有完善的事務處理，不能提供7X24小時的服務，Spring邁不過關鍵企業應用的門檻。
與Spring形影不離的是Java對象持久化的“紅人”Hibernate。Hibernate的矛頭直指EJB的Entity Bean。Entity Bean，尤其是它的持久化技術，是最為程序員所詬病的，成為EJB揮之不去的陰影，并最終促成了Hibernate的輝煌。Hibernate其實并不精深，在技術上也沒有太多值得稱道的創新，但它的文檔非常優秀。我知道很多程序員就是被Hibernate的文檔所吸引的，他們只學過一些SQL初步，沒有系統的關系數據庫理論知識，Hibernate關于數據庫表間關系的論述，深入淺出，十分精彩，讓他們在對關系數據庫的理解上有了迅猛突破的同時，Hibernate輕易的俘虜了他們的心。
Hibernate的成功，反襯了EJB在持久化方面的失敗，但在我看來，這并不影響EJB的偉大。與其說EJB是一種技術，不如說EJB的是一種思想更恰當，而不論Hibernate還是Spring，只不過是一種工具，他們只是跟在EJB后面，發現了EJB的某些不足，然后有針對性地加以改進，以迎合普通程序員對于“技術快餐”的需求。
他們既沒有從形形色色的企業應用中，抽象出隱藏在不同表現后面的本質特征，也沒有創造性地用Stateless Session Bean和Stateful Session Bean來描述千變萬化的現實世界。工具只是工具，不出兩年就會有新的后起之秀，取而代之，但思想的光輝將長久地照亮技術的未來。EJB是一種思想，更是一種理想，盡管理想和現實總是存在差距，但這不能成為我們放棄EJB的理由。一種滿足企業應用分布性、擴展性、安全性和交易性要求的、方便使用的框架技術，既是EJB的理想，也是廣大程序員的理想。
凡是有該標志的文章，都是該blog博主Caoer（草兒）原創，凡是索引、收藏
、轉載請注明來處和原文作者。非常感謝。