EJB
部署分散式應用程序的組件模型
EJB是sun的JavaEE伺服器端組件模型，設計目標與核心應用是部署分散式應用程序。簡單來說就是把已經編寫好的程序（即：類）打包放在伺服器上執行。憑藉java跨平台的優勢，用EJB技術部署的分散式系統可以不限於特定的平台。
EJB(Enterprise JavaBean)是J2EE(javaEE)的一部分，定義了一個用於開發基於組件的企業多重應用程序的標準。其特點包括網路服務中心支持和核心開發工具(SDK)。在J2EE里，Enterprise Java Beans(EJB)稱為Java 企業Bean，是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。在EJB3.0推出以後，實體Bean被單獨分了出來，形成了新的規範JPA。
EJB
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
可擴展(Scalable)
分散式(Distributed)
事務處理(Transactional)
數據存儲(Persistent)
安全性(Secure)
提供一個標準的分佈的、基於OO的組件架構
屏蔽複雜的系統級功能需求
Write once,run anywhere
與非 Java應用之間的互操作能力
兼容CORBA標準
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 javabeans：session beans、entity beans和message-driven beans。
Session bean描述了與客戶端的一個短暫的會話。當客戶端的執行完成後，session bean和
它的數據都將消失；與之相對應的是一個entity bean描述了存儲在資料庫表中的一行持久
穩固的數據，如果客戶端終止或者服務結束，底層的服務會負責entity bean數據的存儲。
Message-driven bean結合了session bean和Java信息服務（JMS）信息監聽者的功能，它允
許一個商業組件非同步地接受JMS消息。
EJB
無論如何由於EJB的複雜性使之在J2EE架構中的表現一直不是很好。EJB大概是J2EE架構中唯一一個沒有兌現其能夠簡單開發並提高生產力承諾的組件。EJB3.0規範正嘗試在這方面作出努力以減輕其開發的複雜性。EJB3.0減輕了開發人員進行底層開發的工作量，它取消或最小化了很多(以前這些是必須實現)回調方法的實現，並且降低了實體Bean及O/R映射模型的複雜性。
在本文中，我首先會介紹EJB3.0中幾個主要的改變。它對進一步深入了解EJB3.0是非常重要的。隨後，我會從更高的層面來描述已經被提交到EJB3.0規範中的細節，並一個個的講解新的規範中的改變：實體Bean，O/R映射模型，實體關係模型和EJB QL(EJB查詢語言)等等。
EJB
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
比如，你可以使用@Stateless註解標記類把Java類聲明為一個無狀態會話bean。對於有狀態會話bean來說，@Remove註釋可以用來標記一個特定的方法，通過這個註解來說明在調用這個方法之後bean的實例將被清除掉。
為了減少描述組件的說明信息，規範組織還採納了由異常進行配置(configuration-by-exception)的手段，意思是你可以為所有的註解提供一個明確的預設值，這樣多數常規信息就可以據此推斷得出。
新的實體bean也是一個加了註釋的簡單Java對象(POJO)。一旦它被EntityManager訪問它就成為了一個持久化對象，並且成為了持久化上下文(context)的一部分。一個持久化上下文與一個事務上下文是松耦合的；嚴格的講，它隱含的與一個事務會話共存。
EJB
深入研究
是時候詳細了解EJB3.0草案了。讓我們開始探討所有EJB中四種企業級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.*;
@Stateless
@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World.";
}
}
除了幾個SFSB的特別說明之外，有狀態會話bean(SFSB)和SLSB一樣精簡：
EJB
Bean的提供者可以用@Remove註釋來標記任何SFSB的方法，以說明這個方法被調用之後bean的實例將被移除。同樣，規範組織仍然在討論是否要有一種機制來處理這種特殊的情況，即當這個方法出現異常的情況下bean的實例是否被移除。
下面是對以上問題我個人的觀點:
是否應該有一個註釋來標明一個方法進行初始化呢？我的觀點是――應該有，這樣容器就可以在調用其他方法之前至少調用一個方法來進行初始化。這不僅可以避免不必要的錯誤(由於沒有調用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規範組織只考慮為一個方法提供一個註釋來聲明它是一個初始化方法。
對於第二個問題我的觀點也是肯定的。這有利於Bean的提供者合客戶端程序對其進行控制。只有一個遺留的問題：那就是一旦調用這個方法失敗，是否能移除這個bean 的實例？答案是不能，但是它將會在會話結束的時候被移除。
消息驅動Bean是唯一一種必須實現一個業務介面的Bean。這個介面指出bean支持的是哪一種消息系統。對於以JMS為基礎的MDB來說，這個介面是javax.jms.MessageListener。注意MDB業務介面不是一個真正意義上的業務介面，它只是一個消息介面。
1．JMS簡介
EJB
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所示。
EJB
與會話Bean和實體Bean不同的是，消息驅動Bean不需要定義遠程介面和Home介面，也不能被客戶端直接調用。
實體Bean使用@Entity註釋來標記，所有實體bean中的屬性/欄位不必使用@Transient註釋來標記。實體bean的持久化欄位可以通過JavaBean-style機制或者聲明為public/protected欄位來實現。
實體bean可以使用助手類來描述其狀態，但是這些類的實例並沒有持久化唯一性(persistent identity)的特性(即，唯一標識這個bean的欄位等)，實際上這些助手類與他們的實體bean實例是緊密結合的；並且這些對象還是以非共享方式來訪問實體對象的。
EJB3.0同時支持Bean之間雙向的和單向的關聯，它們可以是一對一、一對多、多對一或者是多對多的關聯。然而雙向關聯的兩端還要分為自身端(owning side)和對方端(inverse side)不同的端。自身端負責向資料庫通告關聯的變更。對於多對多的關聯自身端必須明確的聲明。實際上對方端通過isInverse=true進行註釋(由此自身端就不必說明了而是由另一段推斷出)。看來上面的描述，規範組織還能說讓EJB變的簡單了嗎?
EJB
舉例來說，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對象。
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 > 100 l支持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有衝突。
對於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過分的耦合。
基本信息
- 中文名
- sun的JavaEE伺服器端組件模型
- 外文名
- Enterprise JavaBean
- 別名
- EJB
- 設計目標
- 是部署分散式應用程序等