EJB:服務器組件模型-中文百科頻道

簡介

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是一種描述了構建應用組件要解決的标準：

可擴展(Scalable)

分布式(Distributed)

事務處理(Transactional)

數據存儲(Persistent)

安全性 (Secure)

期望

提供一個标準的分布的、基于OO的組件架構

屏蔽複雜的系統級功能需求

Write once, run anywhere

與非 Java應用之間的互操作能力

兼容CORBA标準

選擇EJB

EJB服務器完成"繁雜"的工作：應用開發人員關注于業務邏輯的實現而不是底層的實現機制(類似于4GL語言設計的目标)

支持事務處理

多個業務操作同時成功，或全部失敗

可以通過在代碼外的描述來定義事務處理級别

可擴展性

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

由于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查詢語言)等等。

背景

EJB3.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模型。

注解

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

;@Remove

public class HelloWorldBean {

public String sayHello() {

return "Hello World!!!";

}

有狀态會話

除了幾個SFSB的特别說明之外，有狀态會話bean(SFSB)和SLSB一樣精簡：

一個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簡介

JMS是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所示。

MDB被部署為總是充當消息消費者的角色，并且與特定的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映射

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對象。

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草案中，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注釋就可以這樣寫:

查看

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有沖突。