複製鏈接
請複製以下鏈接發送給好友
https://baike.baidu.hk/item/EJB/144195
複製
複製成功

EJB

鎖定
EJB是Enterprise Java Beans技術的簡稱, 又被稱為企業Java Beans。這種技術最早是由美國計算公司研發出來的。EJB技術的誕生標誌着Java Beans的運行正式從客户端領域擴展到服務器領域。在電子商務領域運用EJB技術可以簡化應用系統的開發, 這是由該技術的結構和特點所決定的。 [1] 
中文名
EJB
外文名
Enterprise JavaBean
中文全稱
企業級JavaBean
設計目標
是部署分佈式應用程序等
用    途
構築企業級應用的服務器端
發佈時間
1997年

目錄

  1. 1 EJB概念
  2. 2 EJB歷史
  3. ▪ 從擁抱到拋棄
  4. ▪ 重生
  5. 3 技術特點
  6. 4 EJB組件的體系架構
  1. 5 EJB組件的工作流程
  2. 6 EJB種類
  3. 7 EJB實行
  4. ▪ 遠程通信
  5. ▪ 事務
  1. ▪ 事件
  2. ▪ 命名和目錄服務
  3. ▪ 安全
  4. ▪ 部署EJB
  5. 8 版本變化
  6. ▪ EJB 3.0
  7. ▪ EJB 2.1
  1. ▪ EJB 2.0
  2. ▪ EJB 1.1
  3. ▪ EJB 1.0

EJBEJB概念

EJB (Enterprise Java Beans) 是基於分佈式事務處理的企業級應用程序的組件。Sun公司發佈的文檔中對EJB的定義是：EJB是用於開發和部署多層結構的、分佈式的、面向對象的Java應用系統的跨平台的構件體系結構。 [2] 
在開發分佈式系統時, 採用EJB可以使得開發商業應用系統變得容易, 應用系統可以在一個支持EJB的環境中開發, 開發完之後部署在其它的EJB環境中, 隨着需求的改變, 應用系統可以不加修改地遷移到其它功能更強、更復雜的服務器上。EJB在系統實現業務邏輯層裏面負責表示程序的邏輯和提供訪問數據庫的接口。 [2] 

EJBEJB歷史

EJB從擁抱到拋棄

由於IBM和Sun Microsystems等EJB提倡者力推其前景，起初一些大公司紛紛採用EJB部署他們的系統。然而隨後各種問題便接踵而至，對EJB的惡評短時間內激增。對於初學者，EJB的API顯得太過困難；對於許多程序員來説，書寫那些必須拋出特定異常的接口並將bean類作為抽象類實現的做法既不直觀也不正常。當然，EJB所被賦予的使命，如對象關係映射和事務管理確實有其天然複雜性，但其API之複雜還是令開發人員們覺得望而卻步，一些人開始懷疑EJB除了引入了複雜的實現手段以外似乎並未帶來什麼實際好處。
另外，實際運用中被發現，如果使用EJB來封裝業務邏輯會帶來性能上的下降。這是因為，最早的EJB規範只允許客户端通過特定協議（如CORBA）進行遠程方法調用來調用，即使大部分實際應用根本就不需要分佈式計算。直到EJB 2.0才引入了本地接口，以支持可以開發不通過網絡就能直接本地調用的EJB系統。
儘管如此，EJB的廣泛普及仍然為其複雜度所制約。儘管已經有一些高質量的集成開發工具可以協助開發人員通過自動編碼解決一部分重複作業，但這並不能降低學習此項技術的難度。另一方面，“草根階層”的編程愛好者們發起了一場旨在使用 “輕量級”技術以代替複雜的EJB的運動。這些技術包括Hibernate（用於提供數據持久化和對象-關係映射）及Spring框架（用於封裝業務邏輯）。儘管它們不像EJB那樣有巨頭支持，但其在庶民間卻更加流行，並且也被一些對EJB深感失望的企業所採用。

EJB重生

EJB規範起初的一個主要價值—對分佈式應用進行事務管理—在隨後的實踐中被一致認為幾乎沒能派上用場。對於企業級應用來説，Spring和Hibernate等簡化框架更加實用。因此，EJB 3.0規範（JSR 220）為了迎合這個趨勢相比於其前輩進行了一次激進的大跳躍。受到Spring 影響，EJB 3.0也使用所謂的“傳統簡單Java對象（POJO）”；同時，支持依賴注入來簡化全異系統的集成與配置。Hibernate的創始人Gavin King參與了這一新版規範的制訂，並對EJB大加提倡。Hibernate的許多特性也被引入到Java持久化API當中，從而取代原來的實體bean。EJB 3.0規範大幅採用Java註釋（annotation）來對代碼進行元數據修飾，從而消減了此前EJB編程的冗雜性。
相應地，EJB 3.0幾乎成為了一個全新的API，與此前的數版可謂毫無相似度可言 [3]  。

EJB技術特點

1) 具有可複製性。由於EJB是以組件為基礎的技術模型, 所以在任何一個EJB服務器中都可以隨意部署, 或者將其他模式直接進行移植和複製, 不需要定製專用的EJB服務器系統和容器。EJB之所以能夠被複制, 是因為讓自身的服務器已經定義了一些規範服務, 而這些服務又可以對EJB容器和組件之間的關係進行定義, 即使進行復制也不會破壞其內部結構的穩定性。
2) 具有重複性特點。因為EJB是服務器上運行程序的一個功能片段, 可以進行重新組裝和重新定義, 所以它能夠利用自身的這一特性和其他組間一起組建出符合使用需求的應用系統, 而且可以同時為多個系統提供服務。
3) 具有獨立的平台。和計算機網絡中任何一個特殊平台、Internet協議和中間件或其他基礎設施不同, EJB結構平台完全是獨立的, 具有極強的獨立性。也正是因為如此, 它所開發出來的應用程序才能不進行任何修改, 完全被複制到另外的平台中。
4) 具有廣闊的拓展空間。EJB模型是以多層分佈式體系結構為基礎構建起來的, 因為該系統的多功能, 所以不管是規模較小的應用程序, 還是規模較大的事務處理, 都可以運用高模型。隨着電子信息和通信技術的不斷髮展, 應用程序的需求量不斷增加, 為了讓這些應用程序可以在不改變核心程序的前提下被複制到操作功能更強大、運行環境更先進的系統中, 就可以運用EJB模型來實現。所以, EJB具有極強的擴展性, 而且電子技術的進步會為它的應用提供一個非常廣闊的空間。 [1] 

EJBEJB組件的體系架構

EJB的架構主要包括以下幾方面:
1) Enterprise Java Bean類:包含了組件的實現細節, 是實際完成bean功能的地方。EJB容器根據需要調用這個類對bean進行實例化。
2) EJB對象:在服務器端, 一個EJB對象是一個實現了bean的遠程接口 (具有網絡功能) 的分佈式對象, 它在服務器端上包裝了bean的實例。EJB對象由容器控制在適當的時機調用所需的服務, 這些服務對客户而言是透明的。
3) Remote接口:遵照EJB規範, 所有的Remote接口都必須來源於一個通用的接口, 包含了EJB對象必須實現的方法。
4) Home接口:開發者必須定義home接口, 容器廠商則提供從home接口中產生home對象實現的方法。 [2] 

EJBEJB組件的工作流程

EJB Component在部署到應用服務器上之後, 客户端就可以調用它來完成各種功能。工作過程如下:
1) 客户端首先通過JNDI服務檢索Home對象。在EJB應用部署到應用服務器上之後, 容器會自動獲得Home對象的信息並將其加入到JNDI中。
2) JNDI服務返回所查找的Home對象的引用。
3) Home對象的創建或者查找EJB對象。
4) Home對象將獲得的EJB對象返回給客户端。
5) 客户端利用獲得的EJB對象引用, 調用業務方法。
6) EJB對象獲得對應bean的一個實例並將相應的業務方法調用傳遞給該實例。
7) Bean實例通過其實現代碼, 完成相應的業務邏輯並將結果返回給EJB對象。
8) EJB對象將方法的結果返回給客户端。 [2] 

EJBEJB種類

EJB容器可以接受三類EJB
  • 會話Bean（Session Beans）
    • 無狀態會話Bean（Stateless Session Beans）
    • 有狀態會話Bean（Stateful Session Beans）
  • 實體Bean（Entity Beans）
  • 消息驅動Bean（Message Driven Beans ，MDBs）
無狀態會話Bean是一類不包含狀態信息的分佈式對象，允許來自數個客户端的併發訪問。實例變量的內容在前後數次呼出中不被保留（確切地説是不保證保留）。由於不必控制與用户間的對話信息而減少了開銷，無狀態會話Bean不像有狀態會話Bean那樣具有資源集約性。舉例來説，一個發送郵件的EJB就可被設計為一個無狀態會話Bean。在整個會話期，用户只向服務器提交一個動作：發送指定郵件到指定地址。（稱為開關行為）
有狀態會話Bean是包含狀態的分佈式對象，即是説，貫穿整個會話它們都要保有客户端信息。舉例而言，在一個網上商店進行實施結賬很可能就需要一個有狀態會話Bean，因為結賬是一個多步動作，服務器端必須可以隨時瞭解到用户已經進行到了哪一步。此外，儘管有狀態會話Bean的狀態信息可被保持，但始終只能是由同一個用户來訪問之。
實體Bean是含有持久化狀態的分佈式對象。這個持久化狀態的管理既可以交給Bean自身（Bean-Managed Persistence，BMP），也可以託付於外部機制（Container-Managed Persistence，CMP）。
消息驅動Bean是支持異步行為的分佈式對象。它們並不對請求進行當即響應。比方説，某網站用户點擊“請通知我更新信息”按鈕，將會觸發某個MDB將這名用户加入到數據庫的希望獲得更新信息用户列表中。這個動作就是一個異步的消息驅動過程，因為用户不必等待當時會返回某個結果。MDB的消息源來自Java消息服務（JMS）提供的消息隊列或消息主題。自EJB 2.0規範起，JMS被加入進來以允許在容器內部實施事件驅動處理。與其他EJB不同，MDB不存在一個用户視圖（如需要用户引用的遠程接口），用户也不能通過資源定位獲得一個MDB實例。MDB只在後台監聽消息源並實施自動處理。
除了上述以外，當前還有一些EJB處於設想階段，如JSR 86提出了用於在Java EE應用中集成多媒體對象的媒體Bean（Enterprise Media Beans）。

EJBEJB實行

EJB部署於應用服務器端的EJB容器中。規範給定了EJB與EJB容器之間，以及用户代碼與EJB/EJB容器之間的交互方式。對於Java EE API，javax.ejb包定義了EJB類，javax.ejb.spi包定義了EJB容器應當實現的各個接口。
在EJB 2.1和以前的版本中，每個EJB都由一個類和兩個接口組成。EJB容器負責創建這個類的實例，接口則供客户端調用。
兩個接口分別被稱為Home接口和組件接口，負責提供各個EJB遠程方法聲明。這些EJB遠程方法可分成兩組：
  • 類方法：由Home接口提供。與特定實例無關，僅負責一些公共內容，比如創建一個新的EJB實例（create方法），或尋找一個已經存在的EJB實例（find方法）等等。
  • 接口方法：由組件接口提供的針對特定實例的業務方法。
EJB容器將為這些接口提供對應的實現類以充當客户遠程代理，當客户端調用這個生成的代理類的某個方法時，代理類內部會將此調用的方法和參數封裝成一個消息發送給服務器。服務器收到消息後在轉發給真實的EJB實例，後者負責執行真正的業務邏輯。

EJB遠程通信

EJB規範要求EJB容器能夠支持基於RMI-IIOP的EJB訪問。EJB既可被任何CORBA應用訪問，也能提供Web服務。

EJB事務

EJB容器必須支持符合ACID（原子性/一致性/獨立性/持久性）特性的容器級事務管理，以及bean內部事務管理。容器級事務需在部署描述符中（EJB應用的配置文件）進行聲明。

EJB事件

EJB使用JMS向客户對象發送消息，客户則可以異步地接受這些消息。MDB則接受來自客户端的消息。

EJB命名和目錄服務

EJB客户端使用JNDI或CORBA名字服務定位Home接口實現 對象。通過此Home接口，用户還可以尋找，創建或刪除實體對象。

EJB安全

EJB容器對客户端的訪問權限負責。

EJB部署EJB

EJB規範還定義了一個跨平台的統一部署機制。部署描述符中定義了關於EJB應用的一切相關內容。文件名通常為ejb-jar.xml。
部署描述符是一個XML文檔，負責為該EJB應用中的每一個EJB定義入口。部署描述符的主要內容包括：
  • Home接口名
  • Bean的Java類名
  • Home接口的Java接口名
  • 組件接口的Java接口名
  • 持久化存儲（針對實體Bean）
  • 安全策略和角色分配
通常EJB容器提供者還定義了一些額外的XML或其他格式描述文件來強化其容器的功能。他們還同時提供這些描述文件的解讀工具類和對Home接口的自動實現類生成。
EJB3.0起開始廣泛使用Java註釋替代傳統的部署描述符ejb-jar.xml。但後者仍然有效。

EJB版本變化

EJBEJB 3.0

2006年5月2日發佈，JSR 220定義。
  • 全面採用Java註釋代替部署描述符。（後者仍可使用，並且具有更高優先級）
  • 把2.X版的EntityBean改為由JPA支持。

EJBEJB 2.1

2003年11月24日發佈，JSR 153定義。
  • Web服務：可將無狀態會話bean暴露為Web服務；EJB可通過引用訪問Web服務。
  • EJB定時器服務：提供一種新的基於定時器的事件驅動方式。可供消息驅動bean作為消息源使用。
  • 增加了消息目的地。
  • 進一步豐富了EJB查詢語言，支持ORDER BY, AVG, MIN, MAX, SUM, COUNT和MOD。
  • 使用XML schema代替DTD以定義部署描述符。

EJBEJB 2.0

2001年8月22日發佈，JSR 19 定義。
  • 制定了構建面向對象商務應用的標準組建結構。
  • 支持構築使用不同開發工具所開發之組件的聯合應用部署。
  • 在多線程，連接池，事務管理等方面對用户透明化。
  • 使符合“一次寫成，多次運行”的Java思想。
  • 關注企業級應用生命期間的開發，部署，運行等動作。
  • 定義了不同開發工具所需遵守的契約，以便其產品能夠在運行期交互。
  • 支持與現行系統兼容，開發者可以擴展現有產品以使之支持EJB。
  • 與其他Java API兼容。
  • 支持EJB與Java2平台企業版或者其他非Java應用程序之間的互操作性。
  • 支持與CORBA兼容的RMI-IIOP。

EJBEJB 1.1

1999年12月17日發佈。
  • 開始採用XML部署描述符，默認的JNDI上下文以及可支持IIOP的RMI。
  • 安全機制由角色（Role）驅動，而非方法。
  • 支持實體類，且必須在應用中實現。

EJBEJB 1.0

1998年3月24日發佈。
  • 定義了EJB和EJB容器的作用，實現與互動。
  • 提供了最早的開發者與用户視圖。
參考資料