EJB3.1計劃中的特性

 EJB3.1專家組通過JCP釋出了該規範的早期草案 。EJB的新版本期望作為2008年底釋出的Java EE 6規範的一部分，它主要面向如下兩個方面：簡化工作（從EJB3開始）以及增加Java企業社群要求的新特性。主要改變如下：

1. 一個簡化的本地檢視，無需單獨的本地業務介面就可提供session bean的訪問。通過這種方式，開發人員僅僅使用一個bean類就能實現一個元件。
2. 一 個單例session bean元件：在應用所執行的JVM上，針對每個應用僅例項化一次，該單例session bean元件的目的是為應用提供一個快取狀態的簡單方法。作為一個EJB，該單例可以訪問標準的EJB中介軟體服務集——事務管理、安全、遠端、依賴注入等 等。當容器呼叫session bean類的newInstance方法時該單例啟動。預設情況下，由容器負責決定何時生成一個例項，然而開發者可以通過使用@Startup註解或者相 應的部署描述符讓例項在容器啟動時就例項化。一個單例可能依賴另一個單例（通過@DependsOn註解標明），在這種情況下被依賴的單例就需要先例項 化。單例session bean的生命週期與建立它的容器保持一致，但是其狀態會因為JVM的停止或崩潰而喪失。因為其意在共享，所以它支援併發訪問，這可由容器管理或者在每個 bean中由開發者管理。
3. 基於日曆的EJB定時器表示式和自動建立的定時器：定時器服務可以通過使用類似於UNIX cron工具的基於日曆的語法來表示定時器回撥時間表。例如下面的時間表代表了“每週一、週三和週五的3：15”：@Schedule（minute= “15”, hour=”3”, dayOfWeek=”Mon,Wed,Fri”）。定時器服務也支援通過bean的後設資料或者部署描述符自動建立定時器。自動建立的定時器是在應用部署 時由容器建立的。
4. 非同步的session bean呼叫：預設情況下session bean在其呼叫期內會阻塞客戶端。通過一個非同步的方法呼叫，容器將控制權返還給客戶端並且在一個單獨的執行緒上繼續處理該呼叫。一個非同步方法能返回一個 Future物件，該物件使得客戶端可以獲得一個結果值、檢查異常或者嘗試取消正在進行中的呼叫。
5. 對於 Enterprise JavaBeans功能的一個輕量級子集的定義，它們能夠在Java EE Profiles內（如Java EE Web Profile）被提供，該子集將支援EJB3.1 APIs的如下部分：無狀態、有狀態以及單例session beans、本地業務檢視與非介面檢視（no-interface view）、同步方法呼叫、攔截器、宣告式安全、容器管理的事務（CMT）劃分、bean管理的事務（BMT）劃分、企業bean環境、Java Persistence 2.0 API、JTA1.1的使用者事務介面、Common Annotations 1.0以及由基本的Java SE 6平臺（JDBC、RMI-IIOP、JNDI、JAXP、Java IDL及JAAS）所支援的企業APIs。輕量級的EJB容器必須向企業bean例項提供一個JNDI API名稱空間。打包的要求也得到了簡化以便EJB元件可以直接打包到.war檔案中——在這種情況下，EJB就駐留在WEB-INF/classes目 錄下而不再需要ejb-jar。其可選的ejb-jar.xml部署描述符放置在WEB-INF中。

規範的領導者Ken Saks已經開始撰寫博文以提供更多的關於專家組工作情況的資訊，包括對通用EJB元件對映的支援：

“對開發者來說造成挫敗的一個共同的源泉就是用來解析和查詢EJB引用的對映資訊（如全域性JNDI名）的不可移植性。我們不斷探索以將該資訊標準化使得應用無需特定於廠商的EJB元件對映就可以部署”

專家組仍處在定義EJB3.1過程的早期階段，所以上面列出來的特性有可能發生變化。這也是我們通過郵件向專家組提供反饋資訊來參與到下一版規範的制定工作中去的絕佳機會。

注：以上內容來自網路，本人不承擔任何連帶責任

文章轉自：http://www.infoq.com/cn/news/2008/03/ejb31draft