JavaBean(EJB) 3.0 全新體驗

　　引言

　　期待以久的EJB3.0規(guī)范在最近發(fā)布了它的初稿。在本文中將對新的規(guī)范進(jìn)行一個概要性的介紹，包括新增的元數(shù)據(jù)支持，EJBQL的修改，實體Bean模型訪問bean上下文的新方法和運行時環(huán)境等等。作者還討論了EJB在未來要作出的調(diào)整以及EJB3.0與其他開發(fā)規(guī)范之間的關(guān)系。

　　開始

　　無論如何由于EJB的復(fù)雜性使之在J2EE架構(gòu)中的表現(xiàn)一直不是很好。EJB大概是J2EE架構(gòu)中唯一一個沒有兌現(xiàn)其能夠簡單開發(fā)并提高生產(chǎn)力的組建。EJB3.0規(guī)范正嘗試在這方面作出努力以減輕其開發(fā)的復(fù)雜性。EJB3.0減輕了開發(fā)人員進(jìn)行底層開發(fā)的工作量，它取消或最小化了很多（以前這些是必須實現(xiàn)）回調(diào)方法的實現(xiàn)，并且降低了實體Bean及O/R映射模型的復(fù)雜性。

　　在本文中，我首先會介紹EJB3.0中幾個主要的改變。它對進(jìn)一步深入了解EJB3.0是非常重要的。隨后，我會從更高的層面來描述已經(jīng)被提交到EJB3.0規(guī)范中的細(xì)節(jié)，并一個個的講解新的規(guī)范中的改變：實體Bean,O/R映射模型，實體關(guān)系模型和EJB QL(EJB查詢語言)等等。

　　背景

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

　　Java5中的元數(shù)據(jù)工具

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

　　Hibernate

　　目前Hibernate非常受歡迎，它是開發(fā)源代碼的Java O/R映射框架，目的是把開發(fā)人員從繁瑣的數(shù)據(jù)持久化編程中解脫出來。它也有一個標(biāo)準(zhǔn)的HQL（Hibernate 查詢語言）語言，你可以在新的EJB QL中看到它的影子。Hibernate在處理如數(shù)據(jù)查詢、更新、連接池、事務(wù)處理、實體關(guān)系處理等方面非常簡單。

　　概覽
　　
　　在已經(jīng)提交的EJB3.0規(guī)范中主要涉及兩個方面的改變：

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

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

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

　　EJB注釋

　　EJB規(guī)范組織一個重要的目標(biāo)是減輕原始代碼的數(shù)量，并且他們?yōu)榇私o出了一個完美而簡介的辦法。在EJB3.0的里，任何類型的企業(yè)級Bean只是一個加了適當(dāng)注釋的簡單Java對象(POJO)。注釋可以用于定義bean的業(yè)務(wù)接口、O/R映射信息、資源引用信息，效果與在EJB2.1中定義部署描述符和接口是一樣的。在EJB3.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）的手段，意思是你可以為所有的注釋提供一個明確的缺省值，這樣多數(shù)常規(guī)信息就可以據(jù)此推斷得出。

　　新的持久化模型

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

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

　　深入研究

　　現(xiàn)在是時候詳細(xì)了解EJB3.0草案了。讓我們開始探討所有EJB中四種企業(yè)級bean，并看看他們在新的規(guī)范中是什么樣子。

　　無狀態(tài)回話bean

　　在EJB3.0規(guī)范中，寫一個無狀態(tài)回話bean(SLSB)只需要一個簡單的Java文件并在類層加上@Stateless注釋就可以了。這個bean可以擴(kuò)展javax.ejb.SessionBean接口，但這些不是必須的。

　　一個SLSB不再需要home接口，沒有哪類EJB再需要它了。Bean類可以實現(xiàn)業(yè)務(wù)接口也可以不實現(xiàn)它。如果沒有實現(xiàn)任何業(yè)務(wù)接口，業(yè)務(wù)接口會由任意public的方法產(chǎn)生。如果只有幾個業(yè)務(wù)方法會被暴露在業(yè)務(wù)接口中，這些方法可以使用@BusinessMethod注釋。缺省情況下所有產(chǎn)生的接口都是local（本地）接口，你也可以使用@Remote注釋來聲明這個接口為remote（遠(yuǎn)程）接口。

　　下面的幾行代碼就可以定義一個HelloWorldbean了。而在EJB2.1中同樣的bean至少需要兩個接口，一個實現(xiàn)類和幾個空的實現(xiàn)方法，再加上部署描述符。

　　import javax.ejb.*;

　　/**
　　* A stateless session bean requesting that a remote business
　　* interface be generated for it.
　　*/
　　@Stateless
　　@Remote
　　public class HelloWorldBean {
　　public String sayHello() {
　　return "Hello World!!!";
　　}
　　}

　　 有狀態(tài)回話bean

　　除了幾個SFSB的特別說明之外，有狀態(tài)回話bean(SFSB)和SLSB一樣精簡：

　　 一個SFSB應(yīng)該有一個方法來初始化自己（在EJB2.1中是通過ejbCreate()來實現(xiàn)的）。在EJB3.0的規(guī)范中建議這些初始化操作可以通過自定義方法完成，并把他們暴露在業(yè)務(wù)接口中。在使用這個bean之前由客戶端來調(diào)用相應(yīng)的初始化方法。目前規(guī)范組織就是否提供一個注釋來標(biāo)記某個方法用于初始化還存在爭議。

　　 Bean的提供者可以用@Remove注釋來標(biāo)記任何SFSB的方法，以說明這個方法被調(diào)用之后bean的實例將被移除。同樣，規(guī)范組織仍然在討論是否要有一種機(jī)制來處理這種特殊的情況，即當(dāng)這個方法出現(xiàn)異常的情況下bean的實例是否被移除。

　　下面是對以上問題我個人的觀點：

　　1) 是否應(yīng)該有一個注釋來標(biāo)明一個方法進(jìn)行初始化呢？我的觀點是――應(yīng)該有，這樣容器就可以在調(diào)用其他方法之前至少調(diào)用一個方法來進(jìn)行初始化。這不僅可以避免不必要的錯誤(由于沒有調(diào)用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規(guī)范組織只考慮為一個方法提供一個注釋來聲明它是一個初始化方法。

　　2) 對于第二個問題我的觀點也是肯定的。這有利于Bean的提供者合客戶端程序?qū)ζ溥M(jìn)行控制。只有一個遺留的問題：那就是一旦調(diào)用這個方法失敗，是否能移除這個bean 的實例？答案是不能，但是它將會在回話結(jié)束的時候被移除。

　　消息驅(qū)動Bean

　　消息驅(qū)動Bean是唯一一種必須實現(xiàn)一個業(yè)務(wù)接口的Bean。這個接口指出bean支持的是哪一種消息系統(tǒng)。對于以JMS為基礎(chǔ)的MDB來說，這個接口是javax.jms.MessageListener。注意MDB業(yè)務(wù)接口不是一個真正意義上的業(yè)務(wù)接口，它只是一個消息接口。

　　實體Bean

　　 實體Bean使用@Entity注釋來標(biāo)記，所有實體bean中的屬性/字段不必使用@Transient注釋來標(biāo)記。實體bean的持久化字段可以通過JavaBean-style機(jī)制或者聲明為public/protected字段來實現(xiàn)。

　　 實體bean可以使用助手類來描述其狀態(tài)，但是這些類的實例并沒有持久化唯一性（persistent identity）的特性(即，唯一標(biāo)識這個bean的字段等)，實際上這些助手類與他們的實體bean實例是緊密結(jié)合的；并且這些對象還是以非共享方式來訪問實體對象的。

　　實體關(guān)聯(lián)

　　EJB3.0同時支持Bean之間雙向的合單向的關(guān)聯(lián)，它們可以是一對一、一對多、多對一或者是多對多的關(guān)聯(lián)。然而雙向關(guān)聯(lián)的兩端還要分為自身端（owning side）和對方端（inverse side）不同的端。自身端負(fù)責(zé)向數(shù)據(jù)庫通告關(guān)聯(lián)的變更。對于多對多的關(guān)聯(lián)自身端必須明確的聲明。實際上對方端通過isInverse=true進(jìn)行注釋（由此自身端就不必說明了而是由另一段推斷出）�？磥砩厦娴拿枋觯�規(guī)范組織還能說讓EJB變的簡單了嗎？

　　O/R映射

　　EJB3.0中的O/R映射模型也有了重要的改變，它從原來的abstract-persistence-schema-based變成了現(xiàn)在的Hibernate-inspired模式。盡管目前規(guī)范組織還在就此進(jìn)行討論但是一個明確的模型將會出現(xiàn)在下一個版本的草案中。

　　舉例來說，O/R映射模型將通過bean類中的注釋來聲明。而且此方法還會指出對應(yīng)的具體表和字段。O/R映射模型提供了一套自有的SQL；而且除了提供一些基本的SQL外還支持某些高層開發(fā)的功能。比如，有一個通過@Column注釋聲明的字段columnDefinition，那么可以寫這樣的SQL：columnDefinition="BLOB NOT NULL"

　　客戶端程序模型

　　一個EJB客戶端可以通過@Inject注釋以一種“注入”的方式獲得一個bean的業(yè)務(wù)接口引用。你也可以使用另一個注釋@javax.ejb.EJBContext.lookup()來完成上面的操作，但是規(guī)范中沒有告訴我們一個普通的Java客戶端怎樣獲得一個Bean的實例，因為這個普通的Java客戶端是運行在一個客戶端容器中，它無法訪問@javax.ejb.EJBContex對象�，F(xiàn)在還有另外一種機(jī)制來完成上面的工作那就是使用一個超級上下文環(huán)境對象：@javax.ejb.Context()。但是規(guī)范中沒有指出該如何在客戶端中使用這個對象。

　　EJB QL

　　EJB QL可以通過@NamedQuery來注釋。這個注釋有兩個成員屬性分別是name和queryString.一旦定義了這些屬性，就可以通過EntityManager.createNamedQuery(name)來指向這個查詢。你也可以創(chuàng)建一個標(biāo)準(zhǔn)的JDBC風(fēng)格的查詢并使用EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery(nativeSqlString)(這個方法用于執(zhí)行一個本地查詢)來執(zhí)行查詢。

　　EJB QL有兩個地方可以定義其參數(shù)。javax.ejb.Query接口提供了定義參數(shù)、指向查詢、更新數(shù)據(jù)等等方法。下面是一個EJBQL指向查詢的例子：


　　.. ..
　　@NamedQuery(
　　name="findAllCustomersWithName",
　　queryString="SELECT c FROM Customer c WHERE c.name LIKE :custName"
　　)
　　.. ..
　　@Inject public EntityManager em;
　　customers = em.createNamedQuery("findAllCustomersWithName")
　　.setParameter("custName", "Smith")
　　.listResults();


　　下面列出了一些EJB QL的增強(qiáng)特性：

　　1) 支持批量更新和刪除。

　　2) 直接支持內(nèi)連接和外連接。FETCH JOIN運行你指出關(guān)聯(lián)的實體，Order可以指定只查詢某個字段。

　　3) 查詢語句可以返回一個以上的結(jié)果值。實際上，你可以返回一個依賴的類比如下面這樣：

　　SELECT new CustomerDetails(c.id, c.status, o.count)
　　FROM Customer c JOIN c.orders o
　　WHERE o.count > 100

　　4) 支持group by 和having。

　　5) 支持where子句的嵌套子查詢。

　　在提交的EJB3.0草案中，EJB QL與標(biāo)準(zhǔn)SQL非常的接近。實際上規(guī)范中甚至直接支持本地的SQL(就像我們上面提到的那樣)。這一點對某些程序員來說也許有些不是很清楚，我們將在下面進(jìn)行更詳細(xì)的講解。

　　 　多樣性

　　方法許可(Method permissions)可以通過@MethodPermissions或@Unchecked注釋來聲明；同樣的，事務(wù)屬性也可以通過@TransactionAttribute注釋來聲明。規(guī)范中仍然保留資源引用和資源環(huán)境引用。這些一樣可以通過注釋來聲明，但是有一些細(xì)微的差別。比如，上下文(context)環(huán)境要通過注入工具控制。容器根據(jù)bean對外部環(huán)境引用自動初始化一個適當(dāng)?shù)囊呀?jīng)聲明的實例變量。比如，你可以象下面這樣獲得一個數(shù)據(jù)源（DataSource）：

　　@Resource(name="myDataSource") //Type is inferred from variable
　　public DataSource customerDB;

　　在上面的例子中如果你不指定引用資源的名稱(name)那么其中的customerDB會被認(rèn)為是默認(rèn)值。當(dāng)所有的引用屬性都可得到時，@Injec注釋就可以這樣寫：

　　@Inject public DataSource customerDB;

　　容器負(fù)責(zé)在運行時初始化customerDB數(shù)據(jù)源實例。部署人員必須在此之前在容器中定義好這些資源屬性。

　　更好的消息是：那些以前必須檢測的異常將一去不復(fù)返。你可以聲明任意的應(yīng)用程序異常，而不必在再拋出或捕獲其他類似CreateException和FinderException這樣的異常。容器會拋出封裝在javax.ejb.EJBException中的系統(tǒng)級異常或者只在必要時候拋出IllegalArgumentException或IllegalStateException異常。

　　EJB文件處理模式

　　在我們結(jié)束本節(jié)之前，讓我的快速的瀏覽一下容器提供商在EJB處理模式方面可能的變更。規(guī)范中對此并沒有明確的表態(tài)，但我可以想到至少兩種模式。

　　 一種辦法是首先利用EJB文件生成類似于EJB2.1部署模式的文件（包括必要的接口和部署描述符）然后再用類似于EJB2.1的方式來部署這個EJB組件。當(dāng)然，這樣產(chǎn)生的部署描述符可能并不標(biāo)準(zhǔn)但是它可以解決同一個容器對EJB2.1和EJB3.0兼容的問題。下面這幅圖描述了這一過程。

　　 另一種方法是一種類似于JSP托放的部署模式。你可以把一個EJB文件放到一個預(yù)先定義的目錄下，然后容器會識別這個EJB并處理它，然后部署并使之可以使用。這種方法可以建立于上面那種方法之上，在支持反復(fù)部署時有很大的幫助。考慮到部署的簡單性也是EJB3.0規(guī)范的目的之一，我真誠的希望在下一個草案出來時能夠確定一個模式(至少能有一個非正式的)。

　　你有什么想法？

　　EJB3.0規(guī)范的制定正在有序的進(jìn)行，為了使EJB的開發(fā)變得更加容易，EJB規(guī)范組織作出的努力是有目共睹的。就像他們說的那樣，一切對會變得簡單，但做到這一點并不容易。目前已經(jīng)定義了50個注釋標(biāo)記(還有幾個將在下一個草案中發(fā)布)，每一個都有自己的缺省規(guī)則和其他的操作。當(dāng)然，我真的不希望EJB3.0變成EJB2.1的一個翻版"EJB 3.0 = EJB 2.1 for dummies"（希望這個等式不要成立）。最后，我還是忍不住要提一些我自己的觀點：

　　1) 首先，規(guī)范確實使反復(fù)部署變得容易了，并且有一個簡單的模式來訪問運行時環(huán)境。我還是覺得home接口應(yīng)該放棄。

　　2) 在早期的EJB規(guī)范中，實體bean用于映射一個持久化存儲。理論上(也許只是理論上)可能需要把實體bean映射到一個遺留的EIS(enterprise information system)系統(tǒng)中。出于將來擴(kuò)展的考慮這樣作是有好處的，并且可以使更多的業(yè)務(wù)數(shù)據(jù)模型采用實體bean。也因此其伴隨的復(fù)雜性使得實體bean不被看好。在本次提交的草案中，一個實體bean只是一個數(shù)據(jù)庫的映射。并且是基于非抽象持久化模式和簡單的數(shù)據(jù)訪問模式的更加簡單開發(fā)。

　　3) 我對模型變更持保留態(tài)度，我認(rèn)為在EJB中包含SQL腳本片斷并不是個好注意。一些開發(fā)人員完全反對包含某些“SQL片段（SQLness）”（比如@Table 和 @Column注釋）。我的觀點是這些SQLness是好的，據(jù)此我們可以清楚的知道我們到底要數(shù)據(jù)庫作些什么。但是某些SQL段我看來并不是很好，比如columnDefinition="BLOB NOT NULL"，這使得EJB代碼和SQL之間的耦合太過緊密了。

　　4) 盡管對于本地SQL的支持看似很誘人，其實在EJB代碼中嵌入SQL是一個非常糟糕的主意。當(dāng)然，有些辦法可以避免在EJB中硬編碼SQL，但是這應(yīng)該在規(guī)范中說明，而不能是某些開發(fā)人員自己定義的模式。

　　5) 假設(shè)@Table注釋只用于類。在運行時通過@Table注釋的name屬性定義的表名稱將必須對應(yīng)一個實際的數(shù)據(jù)庫表。規(guī)范對此應(yīng)該給予清楚的說明和一致的模式。

　　6) 規(guī)范還需要更清楚的說明客戶端編程模型，尤其是普通java客戶端。規(guī)范中所有的參考都假設(shè)或者隱含的使用EJB客戶端。而且規(guī)范中對客戶端的向后兼容方面也沒有給出明確的說法。

　　7) Transient注釋應(yīng)該重新命名以避免和已有的transient關(guān)鍵字發(fā)生沖突。事實上，在這一點上我們更樂于稍微的背離一下configuration-by-exception原則并且定義一個@Persistent注釋來明確的定義持久化字段。@Persistent注釋可以僅僅是一個標(biāo)記注釋或者它可以有幾個屬性來關(guān)聯(lián)O/R映射注釋。

　　與其他規(guī)范的關(guān)聯(lián)

　　目前可能影響到EJB3.0的JSR有JSR175（java語言元數(shù)據(jù)工具）和JSR181（Java Web服務(wù)元數(shù)據(jù)）

　　JSR175已經(jīng)初步完成并且不會和EJB3.0有太大的沖突；但是JSR181與EJB3.0有兩個關(guān)聯(lián)的地方：

　　1) Web service接口：EJB規(guī)范將采用一種機(jī)制適應(yīng)JSR181以便可以把一個bean實現(xiàn)為一個Web service并告訴Web service如何被客戶端調(diào)用。

　　2) JSR 181計劃采用不同的機(jī)制來處理安全問題。在早期的規(guī)范中EJB建議使用一個一致的機(jī)制（MethodPermissions），但是JSR 181計劃使用一個稍微不同的方式（SecurityRoles和SecurityIdentity注釋）。同樣的RunAs注釋的定義也存在這些許差別。這一問題還在解決中最終會在J2EE層的規(guī)范中維持其一致性。

　　在J2EE 1.5中的一些開發(fā)規(guī)范可能與EJB3.0有關(guān)聯(lián)。除了上面說到的幾個關(guān)聯(lián)之外現(xiàn)在沒有其他的開發(fā)規(guī)范與EJB3.0有沖突。

　　結(jié)束語

　　在使EJB的開發(fā)變得簡單高效之前，我們還有很長一段路要走。規(guī)范組織在降低EJB的開發(fā)難度方面起了個好頭。O/R映射模型的提議還處在早期階段，規(guī)范組織正在完善它。我希望它不要太復(fù)雜也不要與SQL過分的耦合。讓我們不要只是停留在期望、希望、思考和請求中：提出你的想法并把你的建議發(fā)送給規(guī)范組織ejb3-feedback@sun.com。JCP并不是很民主的組織，但是你的建議一定是有價值的。

　　本文的觀點是作者的個人主張與作者所在的公司沒有任何關(guān)系。作者非常感謝Hemant Khandelwal對發(fā)表此文的幫助。

　　提供下載的代碼是EJB3.0草案的示例代碼。由于沒有工具和環(huán)境的支持這個例子是沒有經(jīng)過驗證的。這些代碼只是示例了未來的EJB3.0大概的樣子。

　　Anil Sharma是BEA System公司開發(fā)Weblogic Integration產(chǎn)品的資深程序員。在加入BEA之前曾就職于Oracle 和 Pramati，并一直致力于研究J2EE技術(shù)。在業(yè)余時間它喜歡聽音樂看電影；他還參加一些開源項目的開發(fā)工作。