簡介
1.SessionBean用於實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個Session
Bean來為客戶端服務。Session Bean可以直接訪問資料庫，但更多時候，它會通過Entity Bean實現數據訪問。
2.Entity Bean是域模型
對象，用於實現O/R映射，負責將資料庫中的表記錄映射為記憶體中的Entity對象，事實上，創建一個Entity Bean對象相當於新建一條記錄，刪除一個Entity Bean會同時從資料庫中刪除對應記錄，修改一個Entity Bean時，容器會自動將Entity Bean的狀態和資料庫同步。
3.MessageDriven Bean是EJB2.0中引入的新的企業Bean，它基於JMS訊息，只能接收客戶端傳送的JMS訊息然後處理。MDB實際上是一個異步的無狀態SessionBean，客戶端調用MDB後無需等待，立刻返回，MDB將異步處理客戶請求。這適合於需要異步處理請求的場合，比如訂單處理，這樣就能避免客戶端長時間的等待一個方法調用直到返回結果。
EJB實際上是SUN的J2EE中的一套規範,並且規定了一系列的API用來實現把EJB概念轉換成EJB產品。
EJB
EJB一個技術規範：EJB 從技術上而言不是一種"產品"
,EJB 是一種描述了構建套用組件要解決的標準：
可擴展 (Scalable)
分散式 (Distributed)
事務處理(Transactional)
數據存儲(Persistent)
安全性 (Secure)
期望
提供一個標準的分布的、基於OO的組件架構
禁止複雜的系統級功能需求
Write once, run anywhere
與非 Java套用之間的互操作能力
兼容CORBA標準
選擇EJB
EJB 伺服器完成"繁雜"的工作：套用開發人員關注於業務邏輯的實現而不是底層的實現機制(類似於4GL語言設計的目標)
支持事務處理
多個業務操作同時成功，或全部失敗
EJB可以通過在代碼外的描述來定義事務處理級別
可擴展性
EJB 可以根據您套用的增長而擴展
EJB 伺服器往往還提供了負載均衡
安全性：由 EJB 伺服器提供資源的訪問許可權控制
EJB架構
為了滿足架構的目標，規範中描述了
伺服器 (Server)
容器(Container)
類 (Class) 和實例 (Instance)
Home 和 Remote 接口
客戶端(Client)
編程模型
關注於業務邏輯實現：EJB 負責生命周期 (lifecycle),數據存儲(persistence), 事務處理語義 (transactional semantic), 安全(security), ...
通用的編程模型：各種服務的高層API
Java 是其編程語言
EJB( 業務邏輯代碼 ) 表示了與特定商業領域（例如銀行、零售等行業）相適應的邏輯。它由
運行在業務邏輯層的 enterprise bean 處理。一個 enterprisebean 可以從客戶端接受數據，對
它進行處理，並將其傳送到企業信息系統層以作存儲；同時它也可以從存儲器獲取數據，
處理後將其傳送到客戶端應用程式。
有三種類型的 enterprise beans：session beans、entity beans 和 message-driven beans。
Session bean 描述了與客戶端的一個短暫的會話。當客戶端的執行完成後，session bean 和
它的數據都將消失；與之相對應的是一個 entity bean 描述了存儲在資料庫表中的一行持久
穩固的數據，如果客戶端終止或者服務結束，底層的服務會負責 entity bean 數據的存儲。
Message-driven bean 結合了 session bean 和 Java信息服務（JMS）信息監聽者的功能，它允
許一個商業組件異步地接受 JMS訊息。
EJB3.0
EJB由於EJB2.0的複雜性，在Spring和Hibernate
等輕量級框架出現後，大量的用戶轉向了，在大家的呼聲中，
期待已久的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查詢語言)等等。
背景
EJBEJB3.0中兩個重要的變更分別是：使用了Java5中的程式注釋工具和基於Hibernate的O/R映射模型。
Java5中的元數據工具
Java5(以前叫J2SE1.5或Tiger) 中加入了一種新的程式註解工具。通過這個工具你可以自定義註解標記，通過這些自定義標記來註解欄位、方法、類等等。這些註解並不會影響程式的語義，但是可以通過工具(編譯時或運行時)來解釋這些標記並產生附加的內容(比如部署描述檔案)，或者強制某些必須的運行時行為(比如EJB組件的狀態特性)。註解的解析可以通過源檔案的解析(比如編譯器或這IDE工具)或者使用Java5中的APIs反射機制。註解只能被定義在原始碼層。由於所有被提交到 EJB3.0草案中的註解標記都有一個運行時的RetentionPolicy，因此會增加類檔案占用的存儲空間，但這卻給容器製造商和工具製造商帶來了方便。
Hibernate
框架，目的是把開發人員從繁瑣的數據持久化編程中解脫出來。它也有一個標準的HQL(Hibernate 查詢語言)語言，你可以在新的EJB QL中看到它的影子。Hibernate在處理如數據查詢、更新、連線池、事務處理、實體關係處理等方面非常簡單。
概覽
在已經提交的EJB3.0規範中主要涉及兩個方面的改變：
1. 一套以注釋為基礎的EJB編程模型，再加上EJB2.1中定義的通過部署描述符和幾個接口定義的應用程式行為。
2. 新的實體Bean持久化模型，EJBQL也有許多重要的改變。
還有一些有關上述的提議，比如:一個新的客戶端編程模型，業務接口的使用以及實體Bean的生命周期。請注意EJB2.1編程模型(包括部署描述符和home/remote接口)仍然是有效的。新的簡化模型並沒有完全取代EJB2.1模型。
註解
EJBEJB規範組織一個重要的目標是減輕原始代碼的數量，並且他們為此給出了一個完美而簡潔的辦法。在
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)的一部分。一個持久化上下文與一個事務上下文是松耦合的;嚴格的講，它隱含的與一個事務會話共存。
EJB實體關係也是通過注釋來定義的，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
;@Remove
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}
有狀態會話
除了幾個SFSB的特別說明之外，有狀態會話bean(SFSB)和SLSB一樣精簡：
EJB一個SFSB應該有一個方法來初始化自己(在EJB2.1中是通過ejbCreate()來實現的)。在EJB3.0的規範中建議這些初始化操作可以通過自定義方法完成，並把他們暴露在業務接口中。在使用這個bean之前由客戶端來調用相應的初始化方法。規範組織就是否提供一個注釋來標記某個方法用於初始化還存在爭議。
Bean的提供者可以用@Remove注釋來標記任何SFSB的方法，以說明這個方法被調用之後bean的實例將被移除。同樣，規範組織仍然在討論是否要有一種機制來處理這種特殊的情況，即當這個方法出現異常的情況下bean的實例是否被移除。
下面是對以上問題我個人的觀點:
是否應該有一個注釋來標明一個方法進行初始化呢?我的觀點是――應該有，這樣容器就可以在調用其他方法之前至少調用一個方法來進行初始化。這不僅可以避免不必要的錯誤(由於沒有調用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規範組織只考慮為一個方法提供一個注釋來聲明它是一個初始化方法。
對於第二個問題我的觀點也是肯定的。這有利於Bean的提供者合客戶端程式對其進行控制。只有一個遺留的問題:那就是一旦調用這個方法失敗，是否能移除這個bean 的實例?答案是不能，但是它將會在會話結束的時候被移除。
訊息驅動
訊息驅動Bean是唯一一種必須實現一個業務接口的Bean。這個接口指出bean支持的是哪一種訊息系統。對於以JMS為基礎的MDB來說，這個接口是javax.jms.MessageListener。注意MDB業務接口不是一個真正意義上的業務接口，它只是一個訊息接口。
JMS綜述
1．JMS簡介
EJBJMS是Java訊息服務（Java Message Ser
vice）的簡寫，是由SUN公司開發的一個開放性的套用編程接口（API），包含在javax.jms.*包中。
JMS對象模型如圖所示。
JMS對象模型包含如下幾個要素：
1）連線工廠。連線工廠（ConnectionFactory）是由管理員創建，並綁定到JNDI樹中。客戶端使用JNDI查找連線工廠，然後利用連線工廠創建一個JMS連線。
2）JMS連線。JMS連線（Connection）表示JMS客戶端和伺服器端之間的一個活動的連線，是由客戶端通過調用連線工廠的方法建立的。
3）JMS會話。JMS會話（Session）表示JMS客戶與JMS伺服器之間的會話狀態。JMS會話建立在JMS連線上，表示客戶與伺服器之間的一個會話執行緒。
4）JMS目的。JMS目的（Destination），又稱為訊息佇列，是實際的訊息源。
5）JMS生產者和消費者。生產者（Message Producer）和消費者（Message Consumer）對象由Session對象創建，用於傳送和接收訊息。
6）JMS訊息通常有兩種類型：
① 點對點（Point-to-Point）。在點對點的訊息系統中，訊息分發給一個單獨的使用者。點對點訊息往往與佇列（javax.jms.Queue）相關聯。
② 發布/訂閱（Publish/Subscribe）。發布/訂閱訊息系統支持一個事件驅動模型，訊息生產者和消費者都參與訊息的傳遞。生產者發布事件，而使用者訂閱感興趣的事件，並使用事件。該類型訊息一般與特定的主題（javax.jms.Topic）關聯。
2．訊息驅動Bean簡介
訊息驅動Bean MDB（Message Driven Bean）是EJB 2.0規範中添加的EJB組件規範，它兼備EJB和JMS的功能。JMS和訊息Bean的調用關係如圖26-23所示。
EJBMDB被部署為總是充當訊息消費者的角色，並且與特定的JMS目的相關聯，MDB從JMS目的（佇列或主題）接收訊息生產者傳送的訊息。
與會話Bean和實體Bean不同的是，訊息驅動Bean不需要定義遠程接口和Home接口，也不能被客戶端直接調用。
實體Bean
實體Bean使用@Entity注釋來標記，所有實體bean中的屬性/欄位不必使用@Transient注釋來標記。實體bean的持久化欄位可以通過JavaBean-style機制或者聲明為public/protected欄位來實現。
實體bean可以使用助手類來描述其狀態，但是這些類的實例並沒有持久化唯一性(persistent identity)的特性(即，唯一標識這個bean的欄位等)，實際上這些助手類與他們的實體bean實例是緊密結合的;並且這些對象還是以非共享方式來訪問實體對象的。
實體關聯
EJB3.0同時支持Bean之間雙向的和單向的關聯，它們可以是一對一、一對多、多對一或者是多對多的關聯。然而雙向關聯的兩端還要分為自身端 (owning side)和對方端(inverse side)不同的端。自身端負責向資料庫通告關聯的變更。對於多對多的關聯自身端必須明確的聲明。實際上對方端通過isInverse=true進行注釋 (由此自身端就不必說明了而是由另一段推斷出)。看來上面的描述，規範組織還能說讓EJB變的簡單了嗎?
O/R映射
EJBEJB3.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對象。
EJBQL
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的增強特性:
支持批量更新和刪除。
直接支持內連線和外連線。FETCH JOIN運行你指出關聯的實體，Order可以指定只查詢某個欄位。
查詢語句可以返回一個以上的結果值。實際上，你可以返回一個依賴的類比如下面這樣:
SELECT new CustomerDetails(c id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100l 支持group by 和having。
子查詢
在提交的EJB3.0草案中，EJBQL與標準SQL非常的接近。實際上規範中甚至直接支持本地的SQL(就像我們上面提到的那樣)。這一點對某些程式設計師來說也許有些不是很清楚，我們將在下面進行更詳細的講解。多樣性
方法許可(Method permissions)可以通過@MethodPermissions和@Unchecked注釋來聲明;同樣的，事務屬性也可以通過 @TransactionAttribute注釋來聲明。規範中仍然保留資源引用和資源環境引用。這些一樣可以通過注釋來聲明，但是有一些細微的差別。比如，上下文(context)環境要通過注入工具控制。容器根據bean對外部環境引用自動初始化一個適當的已經聲明的實例變數。比如，你可以像下面這樣獲得一個數據源(DataSource):
;@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;
在上面的例子中如果你不指定引用資源的名稱(name)那么其中的customerDB會被認為是默認值。當所有的引用屬性都可得到時候@Injec注釋就可以這樣寫:
查看
1. ;@Inject public DataSource customerDB;
;@Inject public DataSource customerDB;
容器負責在運行時初始化customerDB數據源實例。部署人員必須在此之前在容器中定義好這些資源屬性。
更好的訊息是:那些以前必須檢測的異常將一去不復返。你可以聲明任意的應用程式異常，而不必在再拋出或捕獲其他類似 CreateException和FinderException這樣的異常。容器會拋出封裝在javax.ejb.EJBException中的系統級異常或者只在必要時候拋出IllegalArgumentException或IllegalStateException異常。
處理模式
在我們結束本節之前，讓我的快速的瀏覽一下容器提供商在EJB處理模式方面可能的變更。規範中對此並沒有明確的表態，但我可以想到至少兩種模式。
一種辦法是首先利用EJB檔案生成類似於EJB2.1部署模式的檔案(包括必要的接口和部署描述符)然後再用類似於EJB2.1的方式來部署這個EJB組件。當然，這樣產生的部署描述符可能並不標準但是它可以解決同一個容器對EJB2.1和EJB3.0兼容的問題。下面這幅圖描述了這一過程。
另一種方法是一種類似於JSP托放的部署模式。你可以把一個EJB檔案放到一個預先定義的目錄下，然後容器會識別這個EJB並處理它，然後部署並使之可以使用。這種方法可以建立於上面那種方法之上，在支持反覆部署時有很大的幫助。考慮到部署的簡單性也是EJB3.0規範的目的之一，我真誠的希望在下一個草案出來時能夠確定一個模式(至少能有一個非正式的)。
你有什麼想法?
EJB3.0規範的制定正在有序的進行，為了使EJB的開發變得更加容易，EJB規範組織作出的努力是有目共睹的。就像他們說的那樣，一切對會變得簡單，但做到這一點並不容易。已經定義了50個注釋標記(還有幾個將在下一個草案中發布)，每一個都有自己的預設規則和其他的操作。當然，我真的不希望EJB3.0變成EJB2.1的一個翻版"EJB 3.0 = EJB 2.1 for dummies"(希望這個等式不要成立)。最後，我還是忍不住要提一些我自己的觀點:
首先，規範確實使反覆部署變得容易了，並且有一個簡單的模式來訪問運行時環境。我還是覺得home接口應該放棄。
在早期的EJB規範中，實體bean用於映射一個持久化存儲。理論上(也許只是理論上)可能需要把實體bean映射到一個遺留的EIS (enterprise information system)系統中。出於將來擴展的考慮這樣作是有好處的，並且可以使更多的業務數據模型採用實體bean。也因此其伴隨的複雜性使得實體bean不被看好。在本次提交的草案中，一個實體bean只是一個資料庫的映射。並且是基於非抽象持久化模式和簡單的數據訪問模式的更加簡單開發。
我對模型變更持保留態度，我認為在EJB中包含SQL腳本片斷並不是個好注意。一些開發人員完全反對包含某些“SQL片段 (SQLness)”(比如@Table 和 @Column注釋)。我的觀點是這些SQLness是好的，據此我們可以清楚的知道我們到底要資料庫作些什麼。但是某些SQL段我看來並不是很好，比如 columnDefinition="BLOB NOT NULL"，這使得EJB代碼和SQL之間的耦合太過緊密了。
儘管對於本地SQL的支持看似很誘人，其實在EJB代碼中嵌入SQL是一個非常糟糕的主意。當然，有些辦法可以避免在EJB中硬編碼SQL，但是這應該在規範中說明，而不能是某些開發人員自己定義的模式。
假設@Table注釋只用於類。在運行時通過@Table注釋的name屬性定義的表名稱將必須對應一個實際的資料庫表。規範對此應該給予清楚的說明和一致的模式。
規範還需要更清楚的說明客戶端編程模型，尤其是普通java客戶端。規範中所有的參考都假設或者隱含的使用EJB客戶端。而且規範中對客戶端的向後兼容方面也沒有給出明確的說法。
Transient注釋應該重新命名以避免和已有的transient關鍵字發生衝突。事實上，在這一點上我們更樂於稍微的背離一下 configuration-by-exception原則並且定義一個@Persistent注釋來明確的定義持久化欄位 @Persistent注釋 可以僅僅是一個標記注釋或者它可以有幾個屬性來關聯O/R映射注釋。
關聯
可能影響到EJB3.0的JSR有JSR175(java語言元數據工具)和JSR181(Java Web服務元數據)
JSR175已經初步完成並且不會和EJB3.0有太大的衝突;但是JSR181與EJB3.0有兩個關聯的地方:
Web service接口:EJB規範將採用一種機制適應JSR181以便可以把一個bean實現為一個Web service並告訴Web service如何被客戶端調用。
JSR 181計畫採用不同的機制來處理安全問題。在早期的規範中EJB建議使用一個一致的機制(MethodPermissions)，但是JSR 181計畫使用一個稍微不同的方式(SecurityRoles和SecurityIdentity注釋)。同樣的RunAs注釋的定義也存在這些許差別。這一問題還在解決中最終會在J2EE層的規範中維持其一致性。
在J2EE 1.5中的一些開發規範可能與EJB3.0有關聯。除了上面說到的幾個關聯之外現在沒有其他的開發規範與EJB3.0有衝突。
EJB3.1
對於EJB，優先考慮的就是全部重建。“我們只有先清空杯子裡的水，才能接納新的東西”。杯子已經清空了，這對我們來說是非常有利的，而且還可以沒有包袱的大膽前進。
EJB3.1 又一次引入了一系列新的特性，傾向於挖掘技術的潛力。依我來看，EJB3.1絕對是一個重要的發布版本，它將那些長期讓人渴望的特性帶到開發者面前，更加能夠滿足最新的企業應用程式開發，同時對EJB再次被人們採納將做出巨大的貢獻。
EJB 3.1 最終發行版已經發布了。
EJB3.1架構模式相對於舊的架構模式有如下的一些擴展和針對API的一些簡化：
· 簡化的本地模式讓去除了本地的商務接口一樣可達到session bean
· 直接用war檔案打包一個ejb組件不需要一個ejb-jar
· 在Java SE環境中嵌入API執行EJB
· 引入了可以提供簡單的共享套用數據和支持一致性訪問的Singleton session bean組件
· 自動創建EJB定時器
· 基於EJB定時表達式的日程表
· 異步session bean調用
· 對於一個EJB輕量子集的定義，這個子集可以提供一些Java EE文檔 (EJB lite)
· 一個用來查詢ejb組件的Global JNDInames( 統一的 全局 JNDI 命名 ) 規則
結束語
在使EJB的開發變得簡單高效之前，我們還有很長一段路要走。規範組織在降低EJB的開發難度方面起了個好頭。O/R映射模型的提議還處在早期階段，規範組織正在完善它。我希望它不要太複雜也不要與SQL過分的耦合。
