Can you summarize the following document?
        
  

  由於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規範起初的一個主要價值—對分散式應用進行事務管理—在隨後的實踐中被一致認為幾乎沒能派上用場。對於企業級應用來說,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,與此前的數版可謂毫無相似度可言。

  EJB容器可以接受三類EJB  無狀態會話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)。

  EJB部署於應用伺服器端的EJB容器中。規範給定了EJB與EJB容器之間,以及使用者程式碼與EJB/EJB容器之間的互動方式。對於Java EE API,javax.ejb包定義了EJB類,javax.ejb.spi包定義了EJB容器應當實現的各個介面。  在EJB 2.1和以前的版本中,每個EJB都由一個類和兩個介面組成。EJB容器負責建立這個類的例項,介面則供客戶端呼叫。  兩個介面分別被稱為Home介面和元件介面,負責提供各個EJB遠端方法宣告。這些EJB遠端方法可分成兩組:  EJB容器將為這些介面提供對應的實現類以充當客戶遠端代理,當客戶端呼叫這個生成的代理類的某個方法時,代理類內部會將此呼叫的方法和引數封裝成一個訊息傳送給伺服器。伺服器收到訊息後在轉發給真實的EJB例項,後者負責執行真正的業務邏輯。

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

  EJB容器必須支援符合ACID(原子性/一致性/獨立性/永續性)特性的容器級事務管理,以及bean內部事務管理。容器級事務需在部署描述符中(EJB應用的配置檔案)進行宣告。

  EJB使用JMS向客戶物件傳送訊息,客戶則可以非同步地接受這些訊息。MDB則接受來自客戶端的訊息。

  EJB客戶端使用JNDI或CORBA名字服務定位Home介面實現 物件。通過此Home介面,使用者還可以尋找,建立或刪除實體物件。

  EJB容器對客戶端的訪問許可權負責。

  EJB規範還定義了一個跨平臺的統一部署機制。部署描述符中定義了關於EJB應用的一切相關內容。檔名通常為ejb-jar.xml。  部署描述符是一個XML文件,負責為該EJB應用中的每一個EJB定義入口。部署描述符的主要內容包括:  通常EJB容器提供者還定義了一些額外的XML或其他格式描述檔案來強化其容器的功能。他們還同時提供這些描述檔案的解讀工具類和對Home介面的自動實現類生成。  EJB3.0起開始廣泛使用Java註釋替代傳統的部署描述符ejb-jar.xml。但後者仍然有效。

  

  2006年5月2日釋出,JSR 220定義。

  2003年11月24日釋出,JSR 153定義。

  2001年8月22日釋出,JSR 19 定義。

  1999年12月17日釋出。

  1998年3月24日釋出。
企業級JavaBean(Enterprise JavaBean, EJB)是一個用來構築企業級應用的伺服器端可被管理元件。