第一部分 整體介紹

第1章 EJB概述

Sun公司正式推出了EJB（Enterprise Java Bean）規(guī)范之后，在眾多的公司和開發(fā)人員中引起了很大的反響，許多公司都已經(jīng)推出了或正打算推出EJB產(chǎn)品。EJB已經(jīng)成為Java技術(shù)的研究重點，它是由Sun牽頭、IBM等公司共同參與制定的分布式計算解決方案。其目的主要是為了解決重用組件、商務(wù)規(guī)則的隱藏等問題，提高軟件開發(fā)的可伸縮性，滿足Internet的分布式計算需要。

1.1 EJB的基本概念

EJB是用于開發(fā)和部署多層結(jié)構(gòu)的、分布式的、面向?qū)ο蟮腏ava應(yīng)用系統(tǒng)的跨平臺的構(gòu)件體系結(jié)構(gòu)。采用EJB可以使開發(fā)商業(yè)應(yīng)用系統(tǒng)變得容易，應(yīng)用系統(tǒng)可以在一個支持EJB的環(huán)境中開發(fā)，開發(fā)完之后，部署在其他的環(huán)境中。隨著需求的改變，應(yīng)用系統(tǒng)可以不加修改地遷移到其他功能更強(qiáng)、更復(fù)雜的服務(wù)器上。

1.1.1 為什么要使用EJB

如今開發(fā)電子商務(wù)平臺已大量使用組件技術(shù)，這是因為組件技術(shù)提供了服務(wù)器上的自治、企業(yè)級和分布式功能，并幫助開發(fā)者在不同顆粒度級別上定義和封裝系統(tǒng)功能。通過采納組件技術(shù)，比傳統(tǒng)程序更易于為日后的需求進(jìn)行維護(hù)、支持和修改。在金融行業(yè)中，利用以服務(wù)器為中心方式的優(yōu)勢在于，可以定義商業(yè)過程，將其作為一組軟件組件編寫，然后通過多種渠道傳遞。一旦使金融系統(tǒng)變?yōu)橛蓡为毜淖灾谓M件（而非單一龐大程序）組成，靈活性就隨之而來。

EJB的組件結(jié)構(gòu)是以作為可復(fù)用的服務(wù)器端組件而設(shè)計的，它使企業(yè)能夠建立可升級、安全可靠、可運行于多重平臺且以商務(wù)為重點的應(yīng)用程序。EJB可以讓企業(yè)開發(fā)人員只集中于開發(fā)商務(wù)邏輯，而不用花費精力去處理分布式服務(wù)器端系統(tǒng)所帶來的底層問題，從而使開發(fā)人員可以快速開發(fā)大規(guī)模的企業(yè)應(yīng)用。

使用EJB技術(shù)可以使我們獲得以下收益。

1.生產(chǎn)效率

通過使用EJB，企業(yè)開發(fā)人員將會進(jìn)一步提高生產(chǎn)效率。他們不僅能夠獲得在Java平臺上的開發(fā)成果，而且能夠?qū)⒆⒁饬杏谏虅?wù)邏輯，從而使效率倍增。

2.業(yè)內(nèi)支持

試圖建立EJB系統(tǒng)的客戶會獲得一系列可供選擇的解決方案。對于現(xiàn)有的應(yīng)用系統(tǒng)，許多EJB產(chǎn)品的供應(yīng)商（例如IBM和BEA）都提供了完善的升級手段，將系統(tǒng)升級到EJB模式。EJB技術(shù)已經(jīng)被越來越多的公司所接受、支持和應(yīng)用。

3.結(jié)構(gòu)獨立

EJB技術(shù)支持“即插即用”的企業(yè)級特性。它將開發(fā)人員和底層中間件相隔離，開發(fā)人員看到的僅僅是J2EE平臺，這樣使得EJB服務(wù)器廠商在不干擾用戶的EJB應(yīng)用程序的前提下，有機(jī)會改進(jìn)中間件層。

4.跨平臺、跨廠商

通過對Java平臺的支持，EJB技術(shù)將“僅寫一次，隨處運行”的概念提高到了一個新的水平。它可以保證一個EJB應(yīng)用程序可運行于任何服務(wù)器，只要這個服務(wù)器能夠真正提供EJB APIs。

5.EJB組件能提供真正的可重用框架

每一個jar包代表一個EJB組件，一個系統(tǒng)可以由多個可重用的EJB組件構(gòu)成，例如：樹形結(jié)構(gòu)EJB組件；自增序號EJB組件；用戶資料EJB組件等，這樣的EJB組件可以像積木一樣搭配在大部分應(yīng)用系統(tǒng)中，提高了系統(tǒng)的開發(fā)效率，保證了開發(fā)質(zhì)量。

6.EJB提供了事務(wù)機(jī)制

事務(wù)機(jī)制對于一些關(guān)鍵事務(wù)是很重要的，例如ATM機(jī)提款，提款有多個動作：修改數(shù)據(jù)庫及數(shù)錢等，如果這其中有任何一個環(huán)節(jié)出錯，那么，其他已經(jīng)實現(xiàn)的操作必須還原，否則，就會出現(xiàn)提款人沒有拿到錢，但是卡上已經(jīng)扣款等不可思議的事情。

1.2 EJB的體系結(jié)構(gòu)

1.2.1 EJB的基礎(chǔ)結(jié)構(gòu)

容器和服務(wù)提供者實現(xiàn)了EJB的基礎(chǔ)構(gòu)造，這些基礎(chǔ)構(gòu)造處理了EJB的分布式、事務(wù)管理和安全性。EJB規(guī)范定義了基礎(chǔ)構(gòu)造和Java API的各種要求，而沒有去指定用什么技術(shù)、平臺和協(xié)議來實現(xiàn)他們。

Enterprise Beans，container，server說明了EJB基礎(chǔ)結(jié)構(gòu)的要求，EJB基礎(chǔ)結(jié)構(gòu)必須提供客戶和Enterprise Beans通信的通道。雖然這不是EJB規(guī)范所定義的，但保證通道的安全也是很重要的，特別是當(dāng)客戶通過Internet訪問遠(yuǎn)程的Enterprise Beans時，尤為重要。EJB基礎(chǔ)結(jié)構(gòu)也必須能夠加強(qiáng)Enterprise Beans的訪問控制。如圖1-1所示為EJB的結(jié)構(gòu)。

EJB的上層分布式應(yīng)用程序是基于對象組件模型的，低層的事務(wù)服務(wù)應(yīng)用了API技術(shù)。EJB技術(shù)簡化了用Java語言編寫的企業(yè)應(yīng)用系統(tǒng)的開發(fā)、配置和執(zhí)行，其體系結(jié)構(gòu)的規(guī)范由Sun Microsystems公司制定。Inprise的EJB容器是基于1.1版的規(guī)范。EJB技術(shù)定義了一組可重用的組件：Enterprise Beans。可以利用這些組件，像搭積木一樣建立分布式應(yīng)用程序。當(dāng)把代碼寫好后，這些組件就被組合到特定的文件中去，每個文件有一個或多個Enterprise Beans，再加上一些配置參數(shù)。最后，這些Enterprise Beans被配置到一個裝有EJB容器的平臺上。客戶能夠通過這些Beans的home接口，定位到某個Beans，并產(chǎn)生該Beans的一個實例。這樣，客戶就能夠調(diào)用Beans的應(yīng)用方法和遠(yuǎn)程接口。

建立一個基于對象的、多層的、分布式的系統(tǒng)有三種途徑：無狀態(tài)服務(wù)途徑、基于會話途徑和持續(xù)對象途徑。

無狀態(tài)的服務(wù)是通過對象的操作提供一種功能的函數(shù)，但是不保持會話的狀態(tài)。當(dāng)一個客戶使用無狀態(tài)的對象時，客戶不能夠提供上一次操作的信息。

基于會話的設(shè)計產(chǎn)生了一個中間層的對象，稱為一個會話（Session），這個會話可以看成是客戶的代理。典型的會話的生命是由客戶和所在的服務(wù)程序決定的?？蛻羧绻瓿闪藭捑涂梢詫ο笠谱?，如果服務(wù)終止了，會話對象就會超時，會話對象就會變得無效。

持續(xù)對象設(shè)計模式綁定了存在于數(shù)據(jù)庫中的一塊數(shù)據(jù)，提供了操作這塊數(shù)據(jù)的一些操作。持續(xù)對象是由多個客戶共享的，其生命期是由存儲數(shù)據(jù)的數(shù)據(jù)庫所決定的。

EJB規(guī)范中將這些分別稱作：stateless Session，stateful Session和Entiry Beans。Session Beans模式就是基于會話的設(shè)計模式，Entiry Beans模式就是持續(xù)對象設(shè)計模式，每種模式都定義了一些接口和命名約定。

1.2.2 EJB的體系結(jié)構(gòu)

EJB服務(wù)器作為容器和低層平臺的橋梁，管理著EJB容器和函數(shù)，它向EJB容器提供了訪問系統(tǒng)服務(wù)的能力。例如：數(shù)據(jù)庫的管理和事務(wù)的管理。所有的EJB實例都運行在EJB容器中。容器提供了系統(tǒng)級的服務(wù)，控制了EJB的生命周期。EJB分布式應(yīng)用程序是基于對象組件模型的，低層的事務(wù)服務(wù)使用了API技術(shù)。EJB技術(shù)簡化了用JAVA語言編寫的企業(yè)應(yīng)用系統(tǒng)的開發(fā)、配置。客戶能夠通過這些Beans的home接口，定位到某個Beans，并產(chǎn)生該Beans的一個實例。這樣，客戶就能夠調(diào)用Beans的應(yīng)用方法和遠(yuǎn)程接口。EJB中有一些易于使用的管理工具，如：Security——配置描述器（The Deployment Descriptor）定義了客戶能夠訪問的不同的應(yīng)用函數(shù)。容器通過只允許授權(quán)的客戶訪問這些函數(shù)以達(dá)到這個效果。Remote Connectivity——容器為遠(yuǎn)程鏈接管理著低層的通信issues，而且對Enterprise Beas的開發(fā)者和客戶都隱藏了通信細(xì)節(jié)。EJB的開發(fā)者在編寫應(yīng)用方法的時候，就像是在調(diào)用本地的平臺一樣。客戶也不清楚他們調(diào)用的方法可能是在遠(yuǎn)程被處理的。Life Cycle managment——客戶簡單地創(chuàng)建一個Enterprise Beans的實例，并通常取消一個實例。而容器管理著Enterprise Beans的實例，使Enterprise Beans實現(xiàn)最大的效能和內(nèi)存利用率。容器能夠激活和使Enterprise Beans失效，保持眾多客戶共享的實例池。Transaction management——配置描述器定義了Enterprise Beans的事務(wù)處理的需求，容器管理著那些管理分布式事務(wù)處理的復(fù)雜的issues。這些事務(wù)可能要在不同的平臺之間更新數(shù)據(jù)庫，容器使這些事務(wù)之間互相獨立，互不干擾，保證所有的更新數(shù)據(jù)庫都是成功發(fā)生的，否則，就回滾到事務(wù)處理之前的狀態(tài)。

EJB組件是基于分布式事務(wù)處理的企業(yè)級應(yīng)用程序的組件。所有的EJB都有如下特點：

（1）包含了處理企業(yè)數(shù)據(jù)的應(yīng)用邏輯。

（2）定義了EJB的客戶界面。該界面不受容器和服務(wù)器的影響。于是，當(dāng)一個EJB被集合到一個應(yīng)用程序中去時，不用更改代碼和重新編譯。

（3）Enterprise Beans能夠被定制。

（4）各種系統(tǒng)級的服務(wù)，例如安全和事務(wù)處理的特性，都不是屬于Enterprise Beans Class的，而是由配置和組裝應(yīng)用程序的工具來實現(xiàn)。

有兩種類型的EJB：Session Beans和Entity Beans。Session Beans是一種作為單用戶執(zhí)行的對象。作為對遠(yuǎn)程任務(wù)請求的響應(yīng)，容器產(chǎn)生一個Session Beans的實例。一個Session Beans有一個用戶，某種程度上，一個Session Bean對于服務(wù)器來說就代表了它的那個用戶。Session Beans也可以用于事務(wù)，能夠更新共享的數(shù)據(jù)，但不直接描繪這些共享數(shù)據(jù)。Session Beans的生命周期相對來說是比較短的。典型地，只有當(dāng)用戶保持會話時，Session Beans才是活著的，一旦用戶退出Session Beans就不再與用戶相聯(lián)系。Session Beans被看成是瞬時的，因為如果容器崩潰了，那么，用戶必須重新建立一個新的Session對象來繼續(xù)會話。

Session Bean聲明了與用戶的互操作或者會話，也就是說，在客戶會話期間，Session Bean通過方法的調(diào)用，掌握用戶的信息。一個具有狀態(tài)的Session Bean稱為有狀態(tài)的Session Bean。當(dāng)用戶終止與Session Beans互操作時，會話終止了，而且，Bean也不再擁有狀態(tài)值。Session Bean也可能是一個無狀態(tài)的session Bean，無狀態(tài)的Session Beans并不掌握其客戶的信息或狀態(tài)。用戶能夠通過調(diào)用Beans的方法來完成一些操作。但是，Beans只是在方法調(diào)用時才知道用戶的參數(shù)變量，當(dāng)方法調(diào)用完成后，Beans并不繼續(xù)保持這些參數(shù)變量。所有無狀態(tài)的Session Beans的實例都是相同的，除非正在方法調(diào)用期間。這樣，無狀態(tài)的Session Beans就能夠支持多個用戶。容器能夠聲明一個無狀態(tài)的Session Beans，能夠?qū)⑷魏蜸ession Beans指定給任何用戶。

Entity Beans為數(shù)據(jù)庫中的數(shù)據(jù)提供了一種對象視圖，例如：一個Entity Beans能夠模擬數(shù)據(jù)庫表中一行相關(guān)的數(shù)據(jù)。多個client能夠共享訪問同一個Entity Beans。多個client也能夠同時訪問同一個Entity Beans。Entity Beans通過事務(wù)的上下文來訪問或更新下層的數(shù)據(jù)，保證了數(shù)據(jù)的完整性。Entity Beans能存活相對較長的時間，并且狀態(tài)是持續(xù)的，只要數(shù)據(jù)庫中的數(shù)據(jù)存在，Entity Beans就一直存活或者服務(wù)進(jìn)程來。即使EJB容器崩潰了，Entity Beans也是存活的。Entity Beans生命周期能夠被容器或者Beans自己管理。如果由Beans自己管理，就必須寫Entity Beans的代碼，包括訪問數(shù)據(jù)庫的調(diào)用。

1.3 JavaBean與EJB的不同

JavaBean和EJB有一些相同之處，都是用一組特性創(chuàng)建的，以執(zhí)行其特定任務(wù)的對象或組件。它們還具有從當(dāng)前所駐留服務(wù)器上的容器獲得其他特性的能力，這使得Bean的行為可以根據(jù)特定任務(wù)和所在環(huán)境的不同而有所不同，進(jìn)而開辟了巨大商機(jī)。由于JavaBean是與平臺無關(guān)的，所以對于將來的解決方案，供應(yīng)商可以很容易地向不同用戶推出其客戶機(jī)方的JavaBean，而不必創(chuàng)建或維護(hù)不同的版本。這些JavaBean可以與執(zhí)行商業(yè)功能（例如訂購、信用卡處理、電子匯款、存貨分配、運輸?shù)龋┑腅JB配合使用，這正是組件代理（WebSphere Application Server企業(yè)版）設(shè)計提供的巨大潛力。

JavaBean是一種組件，它在內(nèi)部有接口或有與其相關(guān)的屬性，以便不同人在不同時間開發(fā)的Bean可以詢問和集成?？梢韵葮?gòu)建一個Bean，然后在以后構(gòu)造時將它與其他Bean綁定。這種過程提供了先構(gòu)建，然后重復(fù)使用的方法，這就是組件的概念?？梢詫⑦@種單一應(yīng)用程序部署成獨立程序、ActiveX組件或嵌入在瀏覽器中。JavaBean因有外部接口（即屬性接口）而與純對象不同。這種接口允許工具讀取組件要執(zhí)行的功能，將其與其他Bean掛鉤，以及將其插入其他環(huán)境。JavaBean設(shè)計成對單一進(jìn)程而言是本地的，在運行時通常是可視的，這種可視組件可能是按鈕、列表框、圖形或圖表——但這不是必需的。

Server Bean或EJB是部署在服務(wù)器上的可執(zhí)行組件或商業(yè)對象。有一個協(xié)議允許對其進(jìn)行遠(yuǎn)程訪問或在特定服務(wù)器上安裝或部署它們，有一系列機(jī)制允許它們將服務(wù)安全性、事務(wù)行為、并發(fā)性（由多個客戶機(jī)同時訪問的能力）和持久性（其狀態(tài)可以保存多久）的主要方面授權(quán)給EJB服務(wù)器上其所在的容器。當(dāng)安裝在容器中時，它們獲得各自的行為，該行為提供不同質(zhì)量的服務(wù)，因此，選擇正確的EJB服務(wù)器至關(guān)重要，這正是IBM WebSphere企業(yè)版的優(yōu)勢所在。

EJB是運行在服務(wù)器上、并由客戶機(jī)調(diào)用的非可視遠(yuǎn)程對象，可通過多個非可視JavaBean構(gòu)建EJB。它有一個部署描述符，其目的與JavaBean屬性相同：它是以后可由工具讀取的Bean的描述。EJB還獨立于平臺，一旦編寫好，可以在任何支持Java的平臺（包括客戶機(jī)和服務(wù)器）上使用。因為EJB由諸如IBM VisualAge for Java這樣的工具集生成，所以，它是基于服務(wù)器的對象，并用于遠(yuǎn)程調(diào)用。它們可以安裝在EJB服務(wù)器上，并像調(diào)用其他CORBA遠(yuǎn)程對象那樣獲得進(jìn)行調(diào)用的遠(yuǎn)程接口。

ActiveX對象：可以將JavaBean部署成ActiveX對象，雖然EJB的代理也可以這樣做，但是，由于ActiveX運行在桌面上，所以，EJB本身不能成為ActiveX對象。若要在與平臺相關(guān)的、僅Windows平臺上做到這一點，開發(fā)人員可以將JavaBean換成ActiveX組件。EJB的主要好處在于：構(gòu)建Bean時，Bean開發(fā)人員可以規(guī)定需要什么類型的行為，而不必規(guī)定如何去做。開發(fā)分為兩部分：第一步，程序員開發(fā)Bean，然后驗證。它可與構(gòu)建工具一起工作，并包括標(biāo)識所需服務(wù)質(zhì)量行為種類的部署描述符。第二步，另一個程序員可以采用這個Bean，并使用讀取EJB部署描述符的部署工具，然后，將該Bean安裝到Enterprise Java Server上的容器中。在第二步中，部署工具采取一些操作——這可能意味著生成如狀態(tài)保存代碼、放入事務(wù)掛鉤，或執(zhí)行安全性檢查這樣的代碼。所有這些操作由部署工具生成，Bean開發(fā)人員和部署人員可以是不同的人。

可以通過使用部署工具，將任何獨立于平臺的JavaBean改寫成具有可靠服務(wù)質(zhì)量、特定于平臺的EJB，以滿足現(xiàn)有商業(yè)系統(tǒng)和應(yīng)用程序的特定需求，這就是EJB服務(wù)器對集成系統(tǒng)、網(wǎng)絡(luò)和體系結(jié)構(gòu)如此重要的原因所在。Bean的全部意義不只是其現(xiàn)有能力，更在于其可以為商業(yè)提供有競爭力的潛在能力。IT設(shè)計師和應(yīng)用開發(fā)人員可以將精力完全集中在商業(yè)邏輯，而將如事務(wù)、持久性和安全性的底層工作留給服務(wù)器。

1.4 備受爭議的EJB

EJB是一種企業(yè)應(yīng)用技術(shù)，旨在建立一個企業(yè)應(yīng)用開發(fā)框架，但從其誕生之日起，質(zhì)疑之聲就一直不斷，復(fù)雜、難以使用、性能低下、煩瑣等。在Java發(fā)展史上，曾有過很多重要的時刻。如在20世紀(jì)末，也就是在1998年，JSP和EJB的誕生就是一個不同尋常的時刻。JSP誕生后，立刻引起了很多開發(fā)人員的注意，并很快成為Web開發(fā)的主流。而幾乎和它同時誕生的EJB 1.0卻一直備受冷落。在EJB 1.0誕生后的幾年，Sun又推出了EJB 2.0規(guī)范，不過它的命運也與EJB 1.0相同，還是沒有翻身。這其中最大的原因，我想是因為Sun沒有兌現(xiàn)它的承諾而造成的。

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

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

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ù)所做的承諾似乎都走向了相反的方向。EJB不成熟，但不等于可以輕易被否定——是EJB使得很多普通的程序員能夠介入原來貴族似的組件開發(fā)，甚至是在Windows上面開發(fā)UNIX上的組件，EJB的歷史問題大多數(shù)在于將這種技術(shù)錯誤地濫用：一個瀏覽人數(shù)少得可憐的廣告瀏覽程序也要用組件，為一個只想簡單算出庫存的客戶設(shè)計了所謂N年后才需要的擴(kuò)展性。同樣，現(xiàn)實中在這一技術(shù)擅長的領(lǐng)域，至少目前還無法找到更強(qiáng)大的競爭者。

J2EE是第一個為業(yè)界所廣為接受的完整的企業(yè)應(yīng)用框架，而EJB在其中扮演著重要角色。在J2EE框架的支持下，運行在EJB容器中的EJB，完全符合企業(yè)應(yīng)用關(guān)于分布、移植、安全和交易的要求。這對于企業(yè)應(yīng)用的開發(fā)者來說，意義非同尋常。首先，大家可以在一個公共的平臺技術(shù)上構(gòu)建自己的企業(yè)應(yīng)用，不必絞盡腦汁“發(fā)明”自己的“輪子”，從而節(jié)省大量無謂的、重復(fù)性的技術(shù)和時間投入；其次，一個公開的平臺，讓大量的企業(yè)應(yīng)用開發(fā)者有了共同語言，可以相互交流平臺的使用經(jīng)驗和教訓(xùn)。這樣，隨著平臺之上企業(yè)應(yīng)用的不斷增加，平臺的優(yōu)劣得失一覽無余，有利于平臺的改進(jìn)和發(fā)展。

1.5 EJB 3.0規(guī)范全新體驗

最近，期待已久的EJB 3.0規(guī)范發(fā)布了初稿，兩個重要的變更分別是：使用了Java 5中的程序注釋工具和基于Hibernate的O/R映射模型。

1.5.1 EJB 3.0中兩個重要的變更

EJB 3.0中兩個重要的變更分別是：使用了Java5中的程序注釋工具和基于Hibernate的O/R映射模型。

1.Java 5中的程序注釋工具

Java 5（以前叫J2SE 1.5或Tiger）中加入了一種新的程序注釋工具。通過該工具用戶可以自定義注釋標(biāo)記，通過這些自定義標(biāo)記來注釋字段、方法、類等。這些注釋并不會影響程序的語義，但是可以通過工具（編譯時或運行時）來解釋這些標(biāo)記，并產(chǎn)生附加的內(nèi)容（比如部署描述文件），或者強(qiáng)制某些必須的運行時行為（比如EJB組件的狀態(tài)特性）。注釋的解析可以使用源文件的解析（比如編譯器或IDE工具）或者使用Java 5中的APIs反射機(jī)制，注釋只能被定義在源代碼層。由于所有被提交到EJB 3.0草案中的注釋標(biāo)記都有一個運行時的RetentionPolicy，因此，會增加類文件占用的存儲空間，但這卻給容器制造商和工具制造商帶來了方便。在已經(jīng)提交的EJB 3.0規(guī)范中主要涉及兩個方面的改變：

（1）一套以注釋為基礎(chǔ)的EJB編程模型，再加上EJB 2.1中定義的通過部署描述符和幾個接口定義的應(yīng)用程序行為。

（2）新的實體Bean持久化模型，EJBQL也有許多重要的改變。

還有一些有關(guān)上述的提議，比如：一個新的客戶端編程模型。業(yè)務(wù)接口的使用，以及實體Bean的生命周期。請注意，EJB 2.1編程模型（包括部署描述符和home/remote接口）仍然是有效的。新的簡化模型并沒有完全取代EJB 2.1模型。

EJB規(guī)范組織一個重要的目標(biāo)是減輕原始代碼的數(shù)量，為此他們給出了一個完美而簡潔的辦法。在EJB 3.0里，任何類型的企業(yè)級Bean只是一個加了適當(dāng)注釋的簡單Java對象（POJO）。注釋可以用于定義Bean的業(yè)務(wù)接口、O/R映射信息和資源引用信息，效果與在EJB 2.1中定義部署描述符和接口是一樣的。在EJB 3.0中，部署描述符不再是必須的了；home接口也沒有了，也不必實現(xiàn)業(yè)務(wù)接口（容器可以完成這些事情）。比如，可以使用@Stateless注釋標(biāo)記類把Java類聲明為一個無狀態(tài)會話Bean。對于有狀態(tài)會話Bean來說，@Remove注釋可以用來標(biāo)記一個特定的方法，通過這個注釋來說明在調(diào)用這個方法之后，Bean的實例將被清除掉。為了減少描述組件的說明信息，規(guī)范組織還采納了由異常進(jìn)行配置（configuration-by-exception）的手段，意思是可以為所有的注釋提供一個明確的默認(rèn)值，這樣，多數(shù)常規(guī)信息就可以據(jù)此推斷得出。

2.新的持久化模型

新的實體Bean也是一個加了注釋的簡單Java對象（POJO）。一旦被EntityManager訪問，它就成為了一個持久化對象，并且成為持久化上下文（context）的一部分。一個持久化上下文與一個事務(wù)上下文是松耦合的，嚴(yán)格地講，它隱式地與一個事務(wù)會話共存。

實體關(guān)系與O/R映射也是通過注釋來定義的，并提供幾種不同的數(shù)據(jù)庫規(guī)范操作，在EJB 2.1中，這些是需要通過開發(fā)人員自己的設(shè)計模式或者其他技術(shù)來完成的（比如，自增長主鍵策略）。

EJB 3.0必須實現(xiàn)的重要目標(biāo)之一是，要使之成為更加有用和更易于使用的開發(fā)工具。Sun公司的Linda DeMichiel認(rèn)識到，要成功實現(xiàn)這一目標(biāo)，EJB 3.0必須基于開發(fā)人員今天正在使用的現(xiàn)有庫；否則，它將會導(dǎo)致一種困難的升級操作，并且，可能不會引起足夠的重視。因此，來自O(shè)racle,JBoss,Apache,BEA,Novell, Google的成員和其他方面的專家都被邀請參與制訂這一規(guī)范。這個小組的目標(biāo)是，生產(chǎn)一種規(guī)范，能夠使得EJB更易于開發(fā)，并且，還要創(chuàng)建一種便于開發(fā)人員能夠容易地實現(xiàn)升級的持久性存儲標(biāo)準(zhǔn)。當(dāng)這個小組開始開發(fā)EJB 3.0規(guī)范時，他們很快認(rèn)識到，其中很多特征應(yīng)該在功能上與所有的主要供應(yīng)商和庫保持一致。

（1）EntityManager

EntityManager負(fù)責(zé)處理一個事務(wù)，在JDO中，它被稱作持久性存儲管理器，而在Hibernate中稱它為一個會話。在GlassFish工程中，EntityManager被這樣描述：

其實，一個EntityManager實例與一個持久性存儲上下文相關(guān)聯(lián)。一個持久性存儲上下文是一組實體實例，其中的任何一個持久性實體都是唯一的一個實體實例。在該持久性存儲上下文中，實體實例及其生命周期都是可被管理的。EntityManager定義了用于與持久性存儲上下文進(jìn)行交互的方法。EntityManager API用于創(chuàng)建和刪除持久性實體實例，通過其主鍵查找實體和查詢實體。

這個可由一個給定的EntityManager實例管理的實體集合是通過一個持久性存儲單元進(jìn)行定義的。一個持久性存儲單元定義了所有類的集合，這些類是相聯(lián)系的或由應(yīng)用程序加以分組，并且，它們必須共存于其到單個數(shù)據(jù)庫的映射中。

（2）命名查詢

一個命名查詢是一個預(yù)定義的查詢，它被賦予一個名字，這樣，就可以在以后通過該名字加以存取。用數(shù)據(jù)庫術(shù)語來說，命名查詢被稱作存儲過程。當(dāng)結(jié)合本機(jī)查詢時（見下一節(jié)），數(shù)據(jù)庫查詢應(yīng)該是非常輕松的。

（3）本機(jī)查詢

本機(jī)查詢允許直接從EJB中全面使用SQL語言，而不是使用具有很多限制性的實體查詢語言?，F(xiàn)在，我們有可能直接在數(shù)據(jù)庫上調(diào)用count()、max()和其他功能而不必費其他周折。

（4）回調(diào)監(jiān)聽器

回調(diào)監(jiān)聽器是一種事件監(jiān)聽器，或用數(shù)據(jù)庫術(shù)語來說，是一種觸發(fā)器。它們支持當(dāng)一個事件發(fā)生時進(jìn)行代碼調(diào)用。

（5）脫離/重新依附對象

能夠脫離開一個EntityManager的控制范圍而又能夠重新返回而被持續(xù)化存儲，這在EJB 3.0版本之前是無法實現(xiàn)的。以前，為了實現(xiàn)這一目的，必須把來自于一個對象的值復(fù)制到一個POJO（普通Java對象）中，然后再被往回復(fù)制。在EJB 3.0之前，總是使用值、對象，并且把來自于EJB的值復(fù)制到一個POJO中；然后，在前端使用該對象。如果該P(yáng)OJO中的一個值被改變，它將不得不被“推回”到該EJB；然后，該值被復(fù)制回來。如今，這種“混亂”狀態(tài)已經(jīng)不復(fù)存在。一個對象甚至能夠完全離開JVM，并且在以后某個時期返回，被重新依附，這種改變所帶來的效率是不能被低估的。

值得注意的是，企業(yè)Java Bean現(xiàn)在被稱為POJO。隨著注解技術(shù)的出現(xiàn)，Java Bean不再需要接口、home和描述符支持文件。僅這個特征就為EJB 3.0贏得了大批開發(fā)團(tuán)隊的青睞。既然企業(yè)對象不再被鎖定到應(yīng)用程序服務(wù)器內(nèi)，那么，我們就不再需要把它們復(fù)制進(jìn)和復(fù)制出POJO，這樣就不必把應(yīng)用程序服務(wù)器后端和前端區(qū)別得那么嚴(yán)格，從而使開發(fā)人員能夠更容易地顯示和編輯存儲于EJB中的數(shù)據(jù)。

1.5.2 Spring與EJB 3.0的比較

Spring框架雖然很流行，但并不是一個標(biāo)準(zhǔn)的開源框架，它主要由interface21 inc開發(fā)和控制。Spring框架結(jié)構(gòu)是基于依賴注入（Dependency Injection（DI））的設(shè)計模式，可以獨立地在現(xiàn)有的應(yīng)用服務(wù)器上運行，而且大量地使用了XML配置文件。

EJB 3.0是由java community process（jcp）制訂的標(biāo)準(zhǔn)框架，為所有主要的J2EE廠商支持。JBoss已經(jīng)提供了試用版EJB 3.0標(biāo)準(zhǔn)的開源或商業(yè)性質(zhì)實現(xiàn)。EJB 3.0充分利用了java的注釋。

這兩個框架結(jié)構(gòu)有一個共同的核心設(shè)計理念：將中間件服務(wù)傳遞給耦合松散的pojos（plain old java objects，簡單潔凈java對象）。因此，開發(fā)者可專注于業(yè)務(wù)邏輯和脫離框架的POJO單元測試。除此之外，由于POJO并不需要繼承框架的類或?qū)崿F(xiàn)其接口，開發(fā)者能夠極其靈活地搭建繼承結(jié)構(gòu)和建造應(yīng)用。

1.廠商無關(guān)性

開發(fā)者選擇Java平臺其中最引人注目的理由之一是廠商無關(guān)性。EJB 3.0正是一套設(shè)計為廠商無關(guān)的開放性標(biāo)準(zhǔn)，它被所有企業(yè)java社團(tuán)里開源或商業(yè)性質(zhì)廠商所開發(fā)和支持，并將開發(fā)者與應(yīng)用服務(wù)器實現(xiàn)完全隔離。例如，JBoss的EJB 3.0實現(xiàn)基于hibernate，Oracle的toplink，但是開發(fā)者并不需要學(xué)習(xí)hibernate或toplink的具體API來使應(yīng)用可在JBoss或Oracle上運行。廠商無關(guān)性使EJB 3.0與現(xiàn)今其他POJO中間件框架區(qū)別開來。

另一方面，Spring一直以來都是非標(biāo)準(zhǔn)的技術(shù)，在未來可預(yù)知的一段時間內(nèi)，這種情況將持續(xù)下去。雖然可以在任何應(yīng)用服務(wù)器上使用Spring框架，但Spring應(yīng)用會被鎖入在Spring本身或選擇整合進(jìn)Spring的具體服務(wù)中。

Spring框架是一個開源項目，但同時它有一個XML格式的配置文件和編程接口。當(dāng)然，任何一個非標(biāo)準(zhǔn)的產(chǎn)品都會有這種鎖入（lock-in）的情況，并不是Spring特有的，但Spring應(yīng)用的長期生存能力仍然還得依賴于該配置文件和編程接口（或者是interface21公司，它雇傭了大部分Spring核心開發(fā)人員）。除此之外，假如用到任何一個具體的Spring服務(wù)，例如，Spring事務(wù)管理器或Spring mvc，那么就會被鎖入到這些API里。

Spring的應(yīng)用對終端用戶是不可知的，例如，對數(shù)據(jù)持久服務(wù)。Spring框架兼容不同的DAO和JDBC的模板幫助類，如Hibernate，ibatis和jdo。所以，假如需要為Spring應(yīng)用切換在數(shù)據(jù)持久化服務(wù)（例如從JBDC到Hibernate），則需要修改代碼以適合新的模板幫助類。

2.服務(wù)整合

從一個很高的角度上看，Spring框架處于應(yīng)用服務(wù)器和服務(wù)庫的上方。服務(wù)整合的代碼（如數(shù)據(jù)訪問模板和幫助類）屬于框架，并暴露于應(yīng)用開發(fā)者。相反，EJB 3.0框架與應(yīng)用服務(wù)器則高度整合，并且服務(wù)整合代碼也包裝在一個標(biāo)準(zhǔn)接口后面。

因此，實現(xiàn)EJB 3.0的廠商可以大大優(yōu)化整體性能和提升開發(fā)者的體驗。例如，在JBoss EJB 3.0的實現(xiàn)中，當(dāng)在用Entity Manager持久化一個Entity Bean時，后臺的Hibernate會話事務(wù)已經(jīng)自動地綁定到調(diào)用方法的jta的事務(wù)上，在jta事務(wù)提交的同時，Hibernate會話事務(wù)也提交了。甚至可以使用一個簡單的@persistencecontext注釋（稍候例子演示），將EntityManager及其后臺的Hibernate事務(wù)綁定到一個Stateful Session Bean的應(yīng)用事務(wù)中。在一個會話中應(yīng)用事務(wù)橫跨多個線程，這在事務(wù)性網(wǎng)頁應(yīng)用很有用，例如，多頁面的購物車。

由于高度整合的EJB 3.0的框架使簡單、集成的編程接口成為可能，Oracle EJB 3.0框架及其后臺的toplink持久化服務(wù)也可以同樣程度地整合。

另一個EJB 3.0整合服務(wù)的例子是集群支持。假如在一個服務(wù)器集群上部署了一個EJB 3.0的應(yīng)用，所有容錯（fail-over）、負(fù)載均衡、分布式緩沖和狀態(tài)復(fù)制都已經(jīng)自動為應(yīng)用所獲得。而后臺的集群支持則被隱藏在EJB 3.0的框架后，對EJB 3.0開發(fā)者來說，這些都是完全透明不可見的。

在Spring里，很難優(yōu)化框架和服務(wù)之間的通信。例如，為了使用Spring里的聲明事務(wù)服務(wù)來管理hibernate事務(wù)，必須顯式地在XML文件中配置Spring Transaction Manager和Hibernate Session Factory對象。Spring必須顯式地管理橫跨多個http請求的事務(wù)。除此之外，沒有其他方法能夠均衡Spring應(yīng)用里的集群。

3.服務(wù)組合的彈性

由于Spring的服務(wù)整合代碼作為編程接口的一部分暴露在外，應(yīng)用開發(fā)者有按自己需求裝配服務(wù)的彈性，這個特點使用戶能夠組合自己的輕量級應(yīng)用服務(wù)器。Spring的一個普遍用法就是將Tomcat和Hibernate組合在一起支持?jǐn)?shù)據(jù)庫驅(qū)動的web應(yīng)用，而EJB 3.0應(yīng)用服務(wù)器不提供這種根據(jù)需求任意挑揀服務(wù)的彈性空間。大多數(shù)時間得到的只是一系列包裝好的特性，其中一些可能根本就不需要。但是，如果應(yīng)用服務(wù)器像JBoss一樣提供一個模塊性的內(nèi)部設(shè)計，那么就可以只取其中一部分，而把不必要的部分剝?nèi)?。在任何情況，去自定義一個功能強(qiáng)大的應(yīng)用服務(wù)器那是沒有什么價值的。當(dāng)然，假如應(yīng)用已經(jīng)超過單個點，那么你應(yīng)該加入常用服務(wù)器上的服務(wù)，例如，資源池（resource pooling）、消息隊列（message queuing）和集群（clustering）。就總體資源消耗而言，Spring解決方法和其他EJB 3.0解決方法一樣是重量級的。

在Spring框架里，具有彈性的服務(wù)裝配使得將虛擬對象而不是真正的業(yè)務(wù)對象綁定到應(yīng)用中做脫離容器的單元測試更簡單。在EJB 3.0應(yīng)用中，大多數(shù)組件都是簡單POJO，可以很容易地在容器外被測試。但是，對于與容器服務(wù)相關(guān)的對象（例如持久化實體管理器Entity Manager），建議用容器內(nèi)測試，因為這樣比虛擬對象測試方法更簡單、強(qiáng)壯及準(zhǔn)確。

4.xml vs.注解

從應(yīng)用開發(fā)者的觀點來看，Spring的編程開發(fā)接口主要基于xml配置文件，而EJB 3.0則廣泛地應(yīng)用Java注解。xml可以表達(dá)復(fù)雜的關(guān)系，但是它太冗長且不夠健壯；注解簡單明了，但是很難在其中表達(dá)復(fù)雜或繼承性的關(guān)系。

Spring選擇xml或EJB 3.0選擇注解，都是由他們兩者框架后的體系結(jié)構(gòu)決定的。因為注解只能容納很少的配置信息，只有整合前的框架（重頭戲都在框架里）才可以把廣泛地使用注解作為配置選擇。正如我們所討論過的，EJB 3.0剛好符合這個要求，而Spring作為一個普通的di框架無法滿足該要求。當(dāng)然，EJB 3.0和Spring也相互取長補(bǔ)短，在某種程度上他們都支持xml和注解。例如，在EJB 3.0中，xml配置文件作為一個可選的重載機(jī)制來改變注解的默認(rèn)行為，注解也可以配置一些Spring服務(wù)。

5.聲明性服務(wù)

Spring和EJB 3.0都將運行時服務(wù)（例如事務(wù)、安全、日志和配置服務(wù)）綁定到應(yīng)用，因為這些服務(wù)于應(yīng)用的業(yè)務(wù)邏輯是沒有直接聯(lián)系的，他們只是由應(yīng)用本身管理。換句話說，這些服務(wù)在運行時由容器透明地應(yīng)用到應(yīng)用中。開發(fā)者或是管理者通過配置容器，準(zhǔn)確地告訴它什么時候、怎樣應(yīng)用這些服務(wù)。

EJB 3.0運用java注解來配置聲明性服務(wù)，而Spring使用xml配置文件。在大多數(shù)情況下，EJB 3.0注解方式對于這種服務(wù)更簡單明了。

6.依賴注入（Dependency Injection, DI）

中間件容器的關(guān)鍵好處之一就是它可以讓開發(fā)者建造一個關(guān)系耦合松散的應(yīng)用，服務(wù)端客戶只需知道服務(wù)的接口。容器依據(jù)具體的實現(xiàn)實例化服務(wù)對象，使他們?yōu)榭蛻舳怂?。在不改變接口和客戶端代碼的情況下，使得容器可以在多種服務(wù)之間很容易地實現(xiàn)切換。

依賴注入的模式是實現(xiàn)耦合松散應(yīng)用的方法之一。它簡單易用，比其他方法更加明了，比如通過JNDI依賴性查詢或容器回調(diào)。使用DI，框架就像一個對象工廠，它創(chuàng)建服務(wù)對象，然后按照運行時配置將這些服務(wù)對象注入到應(yīng)用的POJO里。從應(yīng)用開發(fā)者的角度來看，客戶端POJO在被使用時可自動獲得正確的服務(wù)對象。

Spring和EJB 3.0都提供廣泛的DI模式支持，但是他們之間仍存在很大的不同之處。Spring支持一般意義上且復(fù)雜的DI API，其基于xml配置文件，而EJB 3.0支持大多數(shù)普通服務(wù)對象（如EJB及context對象）的注入和任何簡單注解的JDNI。

EJB 3.0注解簡單易用。EJB 3.0標(biāo)準(zhǔn)通過注解可以注入服務(wù)器資源，但是它也支持用戶定義的應(yīng)用POJO之間的相互注入。雖然，Spring里基于xml的依賴注入語法復(fù)雜，但卻功能強(qiáng)大。可以將任何POJO注入到另一個POJO，包括用戶在應(yīng)用定義的POJO。假如想在EJB 3.0應(yīng)用中用Spring的di功能，則可以通過JNDI把一個Spring Bean factory注入到EJB。在一些EJB 3.0的應(yīng)用服務(wù)器里，廠商可能會額外定義非標(biāo)準(zhǔn)的POJO注入api，一個很好的例子就是JBoss Microcontainer，它比Spring更一般化，因為它處理Aspect-Oriented Programming（AOP）的依賴。

Spring和EJB 3.0雖然都是為了向企業(yè)服務(wù)提供耦合松散的POJO，都大量地使用了依賴注入，但是卻使用了不同方法。

對于EJB 3.0，基于標(biāo)準(zhǔn)的方案、注解的廣泛使用、與應(yīng)用服務(wù)器的高度整合都使得EJB 3.0擁有更好的廠商無關(guān)性、更高的開發(fā)效率。依賴注入和集中的xml配置文件協(xié)調(diào)一致的使用，使開發(fā)者能夠構(gòu)建更有彈性的應(yīng)用，并且可以同時與幾個應(yīng)用服務(wù)提供者一起協(xié)作。

1.5.3 使用EJB 3.0簡化EJB開發(fā)

如果用過以前的規(guī)范開發(fā)EJB，就會發(fā)現(xiàn)開發(fā)一個類似于HelloWorldEJB這樣簡單的EJB有多困難。至少需要兩個接口、一個Bean類和一個部署描述符。大多數(shù)開發(fā)人員都在想：我要這些干什么？在Oracle Jdeveloper, Eclipse和XDoclet等IDE中，開發(fā)人員可以輕松地完成這些瑣事，但是，在將EJB部署到所選容器之前，開發(fā)人員仍需負(fù)責(zé)編譯這些類并包裝部署描述符。

EJB 3.0使用以下方法來克服這種復(fù)雜性：

無需使用接口和部署描述符，而是由容器使用元數(shù)據(jù)標(biāo)注生成。

將普通Java類用做EJB，將普通業(yè)務(wù)接口用于EJB。

簡化容器管理的持久性，EJB 3.0對CMP實體Bean進(jìn)行了全面的改革，以吸引開發(fā)人員的注意力。持久性框架（如OracleAS TopLink）、開放源碼的Hibernate已成為開發(fā)J2EE應(yīng)用程序持久性框架的寵兒，而實體Bean由于既復(fù)雜又沉重，已不再受歡迎。EJB 3.0采用了一個類似TopLink和Hibernate的輕量級持久性模型，以簡化容器管理的持久性，而這對開發(fā)人員而言無疑很有誘惑力。我們來簡單了解一下該實體Bean計劃關(guān)于持久性改進(jìn)方面的詳細(xì)內(nèi)容，實體Bean正在作為POJO而重獲新生，也將不再需要組件接口。現(xiàn)在實體Bean將被視為純粹的對象，因為它也將支持繼承性和多態(tài)性。

簡化EJB的客戶端視圖。

使用EJB（即查找和調(diào)用）非常復(fù)雜，即使在應(yīng)用程序中已經(jīng)對其進(jìn)行了配置，J2EE 1.4和EJB 3.0規(guī)范正是要簡化EJB的客戶端視圖。若現(xiàn)在就想使用EJB，則必須在部署描述符中定義ejb-ref或ejb-local-ref，查找EJB然后再調(diào)用。EJB 3.0建議使用另一種方法，即使用setter注入來查找和調(diào)用EJB。

1.6 EJB 3.0應(yīng)用前景

EJB經(jīng)過了長達(dá)8年的臥薪嘗膽，被Sun稱為最簡單的EJB 3.0框架終于在今天正式推出了。也許是Sun意識到了自己的失誤，在制定EJB規(guī)范時將以前煩瑣的部分基本都已經(jīng)去掉了。EJB 3.0看起來就好像新的框架一樣，這一點從它的規(guī)范就可以看出，EJB 3.0的規(guī)范文件比EJB 2.0規(guī)范文件的尺寸小得多。為了使EJB的開發(fā)更加容易，EJB規(guī)范組織作出的努力是有目共睹的。就像他們說的那樣，一切都會變得簡單，但做到這一點并不容易。目前已經(jīng)定義了50個注釋標(biāo)記（還有幾個將在下一個草案中發(fā)布），每一個都有自己的默認(rèn)規(guī)則和其他操作。

EJB 3.0和Java EE 5幾乎是同時發(fā)布的，因此，EJB 3.0中使用了很多Java EE 5的新特性。如EJB 3.0在定義Bean時（包括會話Bean和實體Bean），不再使用各種各樣的接口，而是使用Java EE 5提供的注釋（annotations）進(jìn)行定義，無論什么樣的企業(yè)級Bean只是一個加了相應(yīng)注釋的簡單的Java對象（POJO）。不僅如此，EJB 3.0已經(jīng)全面使用注釋取代了接口，如定義Bean的業(yè)務(wù)接口、O/R映射信息、資源引用信息等都使用注釋進(jìn)行描述。由于Hibernate的創(chuàng)始人Gavin King加入了EJB小組，負(fù)責(zé)制定EJB的O/R映射規(guī)范，因此，EJB 3.0的O/R映射十分類似Hibernate，這使得熟悉Hibernate的開發(fā)人員學(xué)習(xí)EJB 3.0非常容易，這也說明EJB 3.0正在和Hibernate走向溶合。同時，Hibernate也提供了兩套API，一套是Hibernate本身的API，另外一套是和EJB 3.0兼容的API。也就是說，只要使用Hibernate第二套API，就可以很容易地將其使用Hibernate的程序移植到EJB 3.0上。雖然EJB 3.0剛剛發(fā)布，但已經(jīng)有很多EJB服務(wù)器支持它了，其中跟得最緊的是JBoss，之后WebLogic, WebSphere等也隨之跟進(jìn)。因此，各大廠商對EJB 3.0還是非?？春玫?。

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

1.7 小結(jié)

本章首先介紹了EJB的基本概念、基礎(chǔ)結(jié)構(gòu)和體系結(jié)構(gòu)，使讀者對EJB有了基本的了解，討論了EJB和JavaBean的區(qū)別，以及EJB的優(yōu)缺點。然后介紹了EJB 3.0的新規(guī)范，比較了EJB 3.0和以前版本的重要改進(jìn)，比較了EJB 3.0和Spring的優(yōu)缺點，及EJB 3.0如何簡化EJB的開發(fā)過程。最后展望了EJB 3.0的應(yīng)用前景，使讀者對EJB有了更深刻的認(rèn)識。