Java中的EJB的介紹

作者：灣仔 2009-06-11 14:25:17

本文先向您介紹Java中的EJB，接著詳細描述了HelloWorldbean的一些代碼。

EJB是sun的服務器端組件模型，***的用處是部署分布式應用程序，類似微軟的.net技術。憑借java跨平臺的優勢，用EJB技術部署的分布式系統可以不限于特定的平臺。

EJB (Enterprise JavaBean)是J2EE的一部分，定義了一個用于開發基于組件的企業多重應用程序的標準。其特點包括網絡服務支持和核心開發工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)稱為Java 企業Bean，是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。

1.Session Bean用于實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個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實際上是一個異步的無狀態Session Bean，客戶端調用MDB后無需等待，立刻返回，MDB將異步處理客戶請求。這適合于需要異步處理請求的場合，比如訂單處理，這樣就能避免客戶端長時間的等待一個方法調用直到返回結果。

EJB實際上是SUN的J2EE中的一套規范,并且規定了一系列的API用來實現把 EJB概念轉換成EJB產品.EJB是BEANS,BEANS是什么概念,那就是得有一個容納她,讓她可勁造騰的地方,就是得有容器.EJB必須生存在 EJB容器中.這個容器可是功能強大之極!她首先要包裝你BEAN,EJB的客戶程序實際上從來就不和你編寫的EJB直接打交道,他們之間是通過 HOME/REMOTE接口來發生關系的.它負責你的BEAN的所有的吃喝拉薩睡,比如BEAN的持續化,安全性,事務管理...

由于EJB2.0的復雜性，在Spring和Hibernate等輕量級框架出現后，大量的用戶轉向了，在大家的呼聲中，EJB3.0規范終于發布了。

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

目前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(遠程)接口。#p#

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

 
    . ..  
 
　　;@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();

在提交的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;
;@Inject public DataSource customerDB;

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

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

　　EJB文件處理模式

在我們結束本節之前，讓我的快速的瀏覽一下容器提供商在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有沖突。

　　結束語

在使EJB的開發變得簡單高效之前，我們還有很長一段路要走。規范組織在降低EJB的開發難度方面起了個好頭。O/R映射模型的提議還處在早期階段，規范組織正在完善它。我希望它不要太復雜也不要與SQL過分的耦合。

【編輯推薦】

Java反編譯的幾種常用方法
有關Java命名慣例相關知識
沒有原生數據類型，Java會更好嗎？
Java applet實例詳解
Java數組聲明、創建、初始化

責任編輯：佚名來源：網易

EJB Java