原文鏈接http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html
譯者語：
翻譯完這篇文章之后，感覺EJB3.0確實有了很大的改進，尤其在降低開發難度方面，個人認為EJB3.0采用注釋的方式來簡化開發確實是一個很好的注意。以前用過XDoclet或者BEA公司的WeblogicWorkShop（它的jws就是一個加了注釋的java）的朋友對于這一技術應該不是很陌生。本文的作者是BEA公司的資深程序員他不僅向我們描述了最新的EJB3.0技術，而且提出了他個人的一些觀點，非常值得我們參考，作者還在文末倡議大家一起參加到EJB3.0規范的制定中來。希望通過閱讀本文能使你一窺EJB3.0的冰山一角。
對于本文的中文翻譯，作者保留其一切權利，如需轉載需要經過譯者的同意。謝謝Email:wafd@hotmail.com.
引言
期待以久的EJB3.0規范在最近發布了它的初稿。在本文中將對新的規范進行一個概要性的介紹，包括新增的元數據支持，EJBQL的修改，實體Bean模型訪問bean上下文的新方法和運行時環境等等。作者還討論了EJB在未來要作出的調整以及EJB3.0與其他開發規范之間的關系。
開始
無論如何由于EJB的復雜性使之在J2EE架構中的表現一直不是很好。EJB大概是J2EE架構中唯一一個沒有兌現其能夠簡單開發并提高生產力的組建。EJB3.0規范正嘗試在這方面作出努力以減輕其開發的復雜性。EJB3.0減輕了開發人員進行底層開發的工作量，它取消或最小化了很多（以前這些是必須實現）回調方法的實現，并且降低了實體Bean及O/R映射模型的復雜性。
在本文中，我首先會介紹EJB3.0中幾個主要的改變。它對進一步深入了解EJB3.0是非常重要的。隨后，我會從更高的層面來描述已經被提交到EJB3.0規范中的細節，并一個個的講解新的規范中的改變：實體Bean,O/R映射模型，實體關系模型和EJB QL(EJB查詢語言)等等。
背景
EJB3.0中兩個重要的變更分別是：使用了Java5中的程序注釋工具和基于Hibernate的O/R映射模型。
Java5中的元數據工具。
Java5（以前叫J2SE1.5或Tiger）中加入了一種新的程序注釋工具。通過這個工具你可以自定義注釋標記，通過這些自定義標記來注釋字段、方法、類等等。這些注釋并不會影響程序的語義，但是可以通過工具（編譯時或運行時）來解釋這些標記并產生附加的內容（比如部署描述文件），或者強制某些必須的運行時行為（比如EJB組件的狀態特性）。注釋的解析可以通過源文件的解析（比如編譯器或這IDE工具）或者使用Java5中的APIs反射機制。注釋只能被定義在源代碼層。由于所有被提交到EJB3.0草案中的注釋標記都有一個運行時的RetentionPolicy，因此會增加類文件占用的存儲空間，但這卻給容器制造商和工具制造商帶來了方便。
Hibernate
目前Hibernate非常受歡迎，它是開發源代碼的Java O/R映射框架，目的是把開發人員從繁瑣的數據持久化編程中解脫出來。它也有一個標準的HQL（Hibernate 查詢語言）語言，你可以在新的EJB QL中看到它的影子。Hibernate在處理如數據查詢、更新、連接池、事務處理、實體關系處理等方面非常簡單。
概覽
在已經提交的EJB3.0規范中主要涉及兩個方面的改變：
1.???????? 一套以注釋為基礎的EJB編程模型，再加上EJB2.1中定義的通過部署描述符和幾個接口定義的應用程序行為。
2.???????? 新的實體Bean持久化模型，EJBQL也有許多重要的改變。
還有一些有關上述的提議，比如：一個新的客戶端編程模型，業務接口的使用以及實體Bean的生命周期。請注意EJB2.1編程模型（包括部署描述符和home/remote接口）仍然是有效的。新的簡化模型并沒有完全取代EJB2.1模型。
EJB注釋
EJB規范組織一個重要的目標是減輕原始代碼的數量，并且他們為此給出了一個完美而簡介的辦法。在EJB3.0的里，任何類型的企業級Bean只是一個加了適當注釋的簡單Java對象(POJO)。注釋可以用于定義bean的業務接口、O/R映射信息、資源引用信息，效果與在EJB2.1中定義部署描述符和接口是一樣的。在EJB3.0中部署描述符不再是必須的了；home接口也沒有了，你也不必實現業務接口（容器可以為你完成這些事情）。
比如，你可以使用@Stateless注釋標記類把Java類聲明為一個無狀態回話bean。對于有狀態回話bean來說，@Remove注釋可以用來標記一個特定的方法，通過這個注釋來說明在調用這個方法之后bean的實例將被清除掉。
為了減少描述組件的說明信息，規范組織還采納了由異常進行配置（configuration-by-exception）的手段，意思是你可以為所有的注釋提供一個明確的缺省值，這樣多數常規信息就可以據此推斷得出。
新的持久化模型
新的實體bean也是一個加了注釋的簡單Java對象(POJO)。一旦它被EntityManager訪問它就成為了一個持久化對象，并且成為了持久化上下文（context）的一部分。一個持久化上下文與一個事務上下文是松耦合的；嚴格的講，它隱含的與一個事務會話共存。
實體關系也是通過注釋來定義的，O/R映射也是，并提供幾種不同的數據庫規范操作，在EJB2.1中這些要通過開發人員自己的設計模式或者其它技術來完成的（比如，自增長主鍵策略）。
深入研究
現在是時候詳細了解EJB3.0草案了。讓我們開始探討所有EJB中四種企業級bean，并看看他們在新的規范中是什么樣子。
無狀態回話bean
在EJB3.0規范中，寫一個無狀態回話bean(SLSB)只需要一個簡單的Java文件并在類層加上@Stateless注釋就可以了。這個bean可以擴展javax.ejb.SessionBean接口，但這些不是必須的。
一個SLSB不再需要home接口，沒有哪類EJB再需要它了。Bean類可以實現業務接口也可以不實現它。如果沒有實現任何業務接口，業務接口會由任意public的方法產生。如果只有幾個業務方法會被暴露在業務接口中，這些方法可以使用@BusinessMethod注釋。缺省情況下所有產生的接口都是local（本地）接口，你也可以使用@Remote注釋來聲明這個接口為remote（遠程）接口。
下面的幾行代碼就可以定義一個HelloWorldbean了。而在EJB2.1中同樣的bean至少需要兩個接口，一個實現類和幾個空的實現方法，再加上部署描述符。
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!!!";
?? }
}
有狀態回話bean
除了幾個SFSB的特別說明之外，有狀態回話bean(SFSB)和SLSB一樣精簡：
l???????? 一個SFSB應該有一個方法來初始化自己（在EJB2.1中是通過ejbCreate()來實現的）。在EJB3.0的規范中建議這些初始化操作可以通過自定義方法完成，并把他們暴露在業務接口中。在使用這個bean之前由客戶端來調用相應的初始化方法。目前規范組織就是否提供一個注釋來標記某個方法用于初始化還存在爭議。
l???????? Bean的提供者可以用@Remove注釋來標記任何SFSB的方法，以說明這個方法被調用之后bean的實例將被移除。同樣，規范組織仍然在討論是否要有一種機制來處理這種特殊的情況，即當這個方法出現異常的情況下bean的實例是否被移除。
下面是對以上問題我個人的觀點：
l???????? 是否應該有一個注釋來標明一個方法進行初始化呢？我的觀點是――應該有，這樣容器就可以在調用其他方法之前至少調用一個方法來進行初始化。這不僅可以避免不必要的錯誤(由于沒有調用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規范組織只考慮為一個方法提供一個注釋來聲明它是一個初始化方法。
l???????? 對于第二個問題我的觀點也是肯定的。這有利于Bean的提供者合客戶端程序對其進行控制。只有一個遺留的問題：那就是一旦調用這個方法失敗，是否能移除這個bean 的實例？答案是不能，但是它將會在回話結束的時候被移除。
消息驅動Bean
消息驅動Bean是唯一一種必須實現一個業務接口的Bean。這個接口指出bean支持的是哪一種消息系統。對于以JMS為基礎的MDB來說，這個接口是javax.jms.MessageListener。注意MDB業務接口不是一個真正意義上的業務接口，它只是一個消息接口。
實體Bean
l???????? 實體Bean使用@Entity注釋來標記，所有實體bean中的屬性/字段不必使用@Transient注釋來標記。實體bean的持久化字段可以通過JavaBean-style機制或者聲明為public/protected字段來實現。
l???????? 實體bean可以使用助手類來描述其狀態，但是這些類的實例并沒有持久化唯一性（persistent identity）的特性(即，唯一標識這個bean的字段等)，實際上這些助手類與他們的實體bean實例是緊密結合的；并且這些對象還是以非共享方式來訪問實體對象的。
實體關聯
EJB3.0同時支持Bean之間雙向的合單向的關聯，它們可以是一對一、一對多、多對一或者是多對多的關聯。然而雙向關聯的兩端還要分為自身端（owning side）和對方端（inverse side）不同的端。自身端負責向數據庫通告關聯的變更。對于多對多的關聯自身端必須明確的聲明。實際上對方端通過isInverse=true進行注釋（由此自身端就不必說明了而是由另一段推斷出）。看來上面的描述，規范組織還能說讓EJB變的簡單了嗎？
O/R映射
EJB3.0中的O/R映射模型也有了重要的改變，它從原來的abstract-persistence-schema-based變成了現在的Hibernate-inspired模式。盡管目前規范組織還在就此進行討論但是一個明確的模型將會出現在下一個版本的草案中。
舉例來說，O/R映射模型將通過bean類中的注釋來聲明。而且此方法還會指出對應的具體表和字段。O/R映射模型提供了一套自有的SQL；而且除了提供一些基本的SQL外還支持某些高層開發的功能。比如，有一個通過@Column注釋聲明的字段columnDefinition，那么可以寫這樣的SQL：columnDefinition="BLOB NOT NULL"
客戶端程序模型
一個EJB客戶端可以通過@Inject注釋以一種“注入”的方式獲得一個bean的業務接口引用。你也可以使用另一個注釋@javax.ejb.EJBContext.lookup()來完成上面的操作，但是規范中沒有告訴我們一個普通的Java客戶端怎樣獲得一個Bean的實例，因為這個普通的Java客戶端是運行在一個客戶端容器中，它無法訪問@javax.ejb.EJBContex對象。現在還有另外一種機制來完成上面的工作那就是使用一個超級上下文環境對象：@javax.ejb.Context()。但是規范中沒有指出該如何在客戶端中使用這個對象。
EJB QL
EJB QL可以通過@NamedQuery來注釋。這個注釋有兩個成員屬性分別是name和queryString.一旦定義了這些屬性，就可以通過EntityManager.createNamedQuery(name)來指向這個查詢。你也可以創建一個標準的JDBC風格的查詢并使用EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery(nativeSqlString)(這個方法用于執行一個本地查詢)來執行查詢。
EJB QL有兩個地方可以定義其參數。javax.ejb.Query接口提供了定義參數、指向查詢、更新數據等等方法。下面是一個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的增強特性：
l???????? 支持批量更新和刪除。
l???????? 直接支持內連接和外連接。FETCH JOIN運行你指出關聯的實體，Order可以指定只查詢某個字段。
l???????? 查詢語句可以返回一個以上的結果值。實際上，你可以返回一個依賴的類比如下面這樣：SELECT new CustomerDetails(c.id, c.status, o.count)
??????FROM Customer c JOIN c.orders o
??????WHERE o.count > 100
l???????? 支持group by 和having。
l???????? 支持where子句的嵌套子查詢。
在提交的EJB3.0草案中，EJB QL與標準SQL非常的接近。實際上規范中甚至直接支持本地的SQL(就像我們上面提到的那樣)。這一點對某些程序員來說也許有些不是很清楚，我們將在下面進行更詳細的講解。
多樣性
方法許可(Method permissions)可以通過@MethodPermissions或@Unchecked注釋來聲明；同樣的，事務屬性也可以通過@TransactionAttribute注釋來聲明。規范中仍然保留資源引用和資源環境引用。這些一樣可以通過注釋來聲明，但是有一些細微的差別。比如，上下文(context)環境要通過注入工具控制。容器根據bean對外部環境引用自動初始化一個適當的已經聲明的實例變量。比如，你可以象下面這樣獲得一個數據源（DataSource）：
@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;
在上面的例子中如果你不指定引用資源的名稱(name)那么其中的customerDB會被認為是默認值。當所有的引用屬性都可得到時，@Injec注釋就可以這樣寫：
@Inject public DataSource customerDB;
容器負責在運行時初始化customerDB數據源實例。部署人員必須在此之前在容器中定義好這些資源屬性。
更好的消息是：那些以前必須檢測的異常將一去不復返。你可以聲明任意的應用程序異常，而不必在再拋出或捕獲其他類似CreateException和FinderException這樣的異常。容器會拋出封裝在javax.ejb.EJBException中的系統級異常或者只在必要時候拋出IllegalArgumentException或IllegalStateException異常。
EJB文件處理模式
在我們結束本節之前，讓我的快速的瀏覽一下容器提供商在EJB處理模式方面可能的變更。規范中對此并沒有明確的表態，但我可以想到至少兩種模式。
l???????? 一種辦法是首先利用EJB文件生成類似于EJB2.1部署模式的文件（包括必要的接口和部署描述符）然后再用類似于EJB2.1的方式來部署這個EJB組件。當然，這樣產生的部署描述