???? 今年EJB3.0規范已經正式發布了。Sun非常自信地向業界宣布，這個EJB版本將有效地減輕開發難度，通過使用EJB3.0，可以大大降低開發成本。但也有人批評說，Sun在EJB中加入了很多Java?EE?5的新特性，如EJB3.0將使用注釋(annotations)來進行配置。這將增加開發人員的學習成本，雖然從表面上是簡單了，但實際上并沒有明顯降低開發難度。還有人批評Sun的EJB3.0的持久層架構抄襲了Hibernate。EJB3.0真的象他們所說的那樣是Hibernate的翻版嗎？EJB3.0是否能依靠它的新架構和Java?EE?5的支持擺脫人們對EJB1.x和EJB2.x的恐懼呢？EJB3.0在未來是否能成為對象持久化的代名詞呢？?

EJB：剛剛誕生就被打入冷宮?

?????在Java發展史上，曾有過很多重要的時刻。如在上世紀末，也就是在1998年，JSP和EJB的誕生就是一個不同尋常的時刻。JSP在誕生后，就立刻引起了很多開發人員的注意，并很快成為了Web開發的主流。而幾乎和它同時誕生的EJB1.0卻一直倍受冷落。在EJB1.0誕生后的幾年，Sun又推出了EJB2.0規范，不過它的命運也可EJB1.0差不多，還是沒有翻身。這其中最大的原因，我想是因為Sun沒有兌現它承諾而造成的。?

????Sun在發布J2EE相關規范和產品時承諾，J2EE將會使開發變得更容易，從而會顯著降低開發成本。但在J2EE發布時，滿心歡喜的人們卻發現，被認為是J2EE中最有價值的組成部分：EJB卻是如此的復雜。在編寫EJB時需要進行大量的配置，而且還需要實現一大堆的接口。這不但沒有降低開發難度，反而成為很多開發人員的惡夢。?
在EJB2.x剛出來的幾年，國內有很多程序員盲目跟風，但當時，他們中的大多數都只是停留在EJB的“名詞”階段。而當他們開始熟悉并使用EJB時，卻發現并不是象他們想得那樣美妙。?

????不知道Sun的EJB設計人員是如何考慮的。本來通過很簡單的方法就可以從數據庫中得到數據，而EJB卻要專門為其修一條一級的高輸公路，將本來就不多的數據運了出來，這簡直就是多此一舉。?

????在取數據時經過這樣的周折，它的效率也大受影響。也許Sun當初根本就沒考慮過它的效率。?

????實體Bean在EJB2.0后就成為EJB最重要的一部分，但是它的概念重來就沒清楚過。如Sun建議將業務邏輯代碼放到會話Bean中，也就是說，前端應該直接訪問會話Bean。而作為對數據直接封裝的實體Bean卻提供了遠程接口，這也就意味著前端也可以直接訪問實體Bean。這就與多程序應用結構不太符合。還有就是實體Bean既然是對數據的原始封裝，那為什么要提供事務、安全這些業務邏輯層的功能。更不可思議的是實體Bean既然提供了本地接口，那又為什么不通過本地接口，而要通過JNDI查找呢？這些概念上的混淆使得EJB更加難以使用。?

????近幾年非常流行的SOA(Service-Oriented?Architecture)模式為企業級應用提供了更好的解決方案。然而SOA中的核心：服務，卻和這個自稱是企業級的Java?Bean的EJB沒有什么太大的關系。眾所周知，SOA里的服務一般是指Web?Services。而實現Web?Services的方式很多，如果使用Java實現，一般是使用普通的Java?Bean來包裝成Web?Services。最多也就是使用個無狀態的Session?Bean。而EJB的其它功能，尤其是強大的實體Bean，卻很少使用。這不能不說，EJB已經越來越名不副實

異軍突起：欲取EJB而代之?

????雖然EJB過于復雜，使用它的開發人員比較少，這并不等于人們對企業級的服務的需求小。相反，隨著企業信息化程度越來越高，對方便易用的企業級服務的需要與日俱增。?
在EJB規范中，關于實體Bean的描述是最多的。看上去實體Bean的功能十分強大，但實際上并非如此。實體Bean的主要功能是對數據進行包裝，從而使數據持久化。但這個EJB中最重要的功能也是最虛弱的。本來很簡單的功能Sun卻定義了一大堆接口，而且不能通過實體Bean進行SQL級的查詢，并且實體Bean必須得依托EJB容器才能使用。這些限制大大降低了實體Bean的使用價值。?

????雖然實體Bean的難以使用讓人望而卻步，但對數據持久化的需求沒有一天停止過。自從在進入二十一世紀以來，有許多類EJB類似但更容易使用的數據持久化組件開始成為開發人員的新寵。這其中比較流行的有Hibernate、JDO和TopLink。?

????在這里Hibernate當仁不讓地成為了最耀眼的明星。Hibernate不能不說是一個奇跡，它在不到3年的時間里，從一個不起眼的開源軟件成為了今天業界矚目的主流O/R映射框架，它的創始人Gavin?King也一夜成名。而EJB在它誕生后的幾年時間里，卻罵聲不斷，它們之間形成了強烈的反差。當然，從技術角度來說，Hibernate的技術并不是最先進的，而Gavin?King也不是什么絕頂高手。Hibernate之所以能發展得如此快，主要是因為Hibernate的開發難度比較EJB小，而且Hibernate的使用并不依賴于具體的容器，可以將Hibernate使用在B/S或C/S的任何Java環境上。?

????而今年夏天投票通過的JDO2.0標準從某種程度而言，并不遜色于Hibernate當前的版本，有些功能甚至比Hibernate還要好，例如?JDO支持對類屬性的惰性裝載，而Hibernate要到3才支持，當前Hibernate僅僅支持類的惰性裝載。?

????TopLink是比較古老的O/R映射框架，自從它被Oracle收購后，對Oracle數據庫有了更好的支持。但這種框架并不是開源的，而且售價不菲。?

????這幾種O/R映射框架大有取代EJB之勢，而Sun由于已經有了EJB，也不可能再做一個和這些框架類似的東本和它們競爭。因此，Sun要想扭轉EJB的頹勢，必須要從EJB下手。而EJB1.x和EJB2.x都以失敗而告終，那么EJB的下一個版本EJB3.0又會如何呢，Hibernate的創始人Gavin?King的加入會使EJB3.0成為繼Hibernate的下一個新寵嗎？

Sun最后的反擊：EJB3.0?

????EJB經過了長達8年的臥薪嘗膽，被Sun稱為最簡單的EJB3.0框架終于在今天正式推出了。也許是Sun意識到了自己的失誤，在自定EJB規范時將以前繁瑣的部分基本都已經去掉了。EJB3.0看起來就好象新的框架一樣(這一點從它的規范就可以看出，EJB3.0的規范文件比EJB2.0規范文件的尺寸小得多)。?

?????EJB3.0和Java?EE?5幾乎是同時發布的，因此，EJB3.0中使用了很多Java?EE?5的新特性。如EJB3.0在定義Bean時（包括會話Bean和實體Bean），不再使用各種各樣的接口，而是使用Java?EE?5提供的注釋（annotations）進行定義，無論什么樣的企業級Bean只是一個加了相應注釋的簡單的Java對象（POJO）。不僅如此，EJB3.0中已經全面使用注釋取代了接口。如定義
Bean的業務接口、O/R映射信息、資源引用信息等都使用注釋進行描述。?

????由于Hibernate的創始人Gavin?King加入了EJB小組，負責制定EJB的O/R映射規范。因此，EJB3.0的O/R映射也十分類似Hibernate。這使得熟悉Hibernate的開發人員學習EJB3.0非常容易。這說明EJB3.0正在和Hibernate走向溶合。?

????同時Hibernate也提供了兩套API，一套是Hibernate本身的API，另外一套是和EJB3.0兼容的API。也就是說，只要使用Hibernate第二套API，就很容易將其使用Hibernate的程序移植到EJB3.0上。?

????雖然EJB3.0剛剛發布，但已經有很多EJB服務器支持EJB3.0了，這其中跟得最緊的是JBoss，其次WebLogic、WebSphere等也隨之跟進。因此，各大廠商還是對EJB3.0非常看好的。?

????自從那些如Struts、Hibernate、Spring等輕量級的框架開始在市面上出現并流行時，很多開發人員開始跟隨著這些開源大師的指揮棒的方向前進。EJB已經逐漸從人們的視線中淡出。但隨著EJB3.0的問世，又將人們的視線拉了回來。畢竟，EJB出自Sun。如果它也能向Hibernate、JDO一樣容易使用，那它是非常有前途的，至少我是這么認為的。現在EJB3.0已經和Hibernate在O/R映射上非常相似了，在未來，EJB3.0也許將成為輕量級框架的一員，讓我們拭目以待吧！