上一章通過開發一個簡單的企業Bean，對EJB有了一個初步的認識，本章進一步討論EJB技術體系的主要幾個方面，闡述諸如EJB組件、EJB角色、EJB類型、持久性、EJB合約等基本概念。使讀者對EJB技術有更加深入的了解。
　　 企業Bean(Enterprise JavaBeans，EJB)規范由SUN公司和其它伙伴公司制訂，1.0版本在1998年3月發布。1.1版本在1999年12月發布。最近的版本是2.0，于2000年10月發布?？梢詮木W址http://java.sun.com/products/ejb/docs.html下載該規范。
　　 本章以Enterprise JavaBeans(EJB)規范2.0版為主要參考，從多個側面介紹EJB的基本概念。

3.1 EJB組件

　　企業Bean技術從本質上說是一個基于組件的分布式計算架構體系規范。企業Bean是分布式的面向業務邏輯的企業應用組件。
　　 基于組件的應用方式是把傳統上的應用系統按一定的目標分成兩個部分：容器和組件。這種劃分更多的是從功能出發的，劃分的原則把底層技術細節與應用邏輯分開。容器部分重點在于解決底層的技術問題，如目錄訪問、分布式事務處理、安全管理、并行訪問、持久性管理、資源池管理、系統管理界面和負載均衡等方面。組件部分重點放在具體的應用邏輯上。同時，這樣劃分也把不同性質的開發工作分離出來。具有不同技術背景的開發人員關注于系統的某一個層面而無需對其他層面深人的了解。一旦這種劃分成為了一個技術標準，那么就形成了相關的技術領域的社會工業。

3.1.1 EJB組件的特性

　　企業Bean的重要特性如下：
　　 ·企業Bean包括操作企業數據的業務邏輯。企業Bean是用來封裝業務邏輯的。
　　 ·企業Bean的實例被容器創建和運行。容器管理EJB。
　　 ·企業Bean在部署的時候通過編輯環境屬性來定制。使用部署描述符是部署EJB的重要環節。
　　 ·不同的服務信息，如事務和安全屬性，從企業Bean類中分離出來。這些通用的服務由容器一次完成。開發不同的應用時，不必再考慮這些瑣碎的細節問題。用一些工具在應用程序裝配和部署過程中管理服務信息。
　　 ·客戶端訪問部署在容器的組件是快速進行的。容器通過使用資源池等手段顯著提高了性能。
　　 ·如果一個企業Bean僅使用EJB規范定義的服務，它能被部署在任何一個兼容的EJB容器中。特定的容器能提供EJB額外的服務。依賴這樣服務的企業Bean只能部署在支持這個服務的容器中。EJB規范是個通用的規范，得到很多廠商的支持，確保了EJB的可移植性。
　　 ·企業Bean能被包含在一個已裝配的應用程序中，而不需源代碼的改變或重新編譯。具有良好的重構性、可升級特征。
　　 ·Bean提供者定義一個企業Bean的客戶端視圖。Bean提供者可以手工定義客戶端視圖或通過程序部署工具自動產生?？蛻舳艘晥D不受Bean部署的容器和服務器的影響。這確保了Bean和它們的客戶端能被部署到多種執行環境中而不需改變或重新編譯。

3.1.2 EJB組件的類型

　　企業Bean架構是靈活的，可以實現下列組件：
　　 ·表示一個無狀態服務的對象。即無狀態會話EJB。
　　 ·表示一個無狀態服務對象且是異步激發的，被Java消息服務(JMS)的消息驅動。即消息驅動Bean。
　　 ·表示一個特定客戶端的會話狀態的對象。如會話對象在客戶端多次調用之間自動維持它們的會話狀態。即有狀態會話Bean。
　　 ·實體對象表示商業邏輯對象，被多個客戶端共享。即實體Bean。實體Beans用來描述較粗糙的邏輯對象(如訂單、雇員記錄等)。不太適合描述較詳細的對象(如訂單上的項、雇員地址等)。
　　 EJB的狀態是個較重要的概念。這里的狀態是在EJB的客戶端視圖定義的，也就是說EJB的狀態指的是EJB呈現的客戶端的狀態，而并不是指EJB本身的生存狀態，這兩者往往并不完全一致。
　　 雖然EJB定義的狀態管理協議簡單，它為開發者提供了一個在管理狀態上的企業Bean極大的靈活性。
3.1.3 企業 Beans組件應用模型
　　 J2EE三層應用架構定義了兩種基于組建的應用模式，即Web應用和EJB應用。如表3-1所示。

　　　　　　　　　表3-1 Web應用與EJBs應用對比
　　 ─────────────────────────────────
　　　　　　　　 Web應用　　　　　　EJBs應用
　　 ─────────────────────────────────
　　 組件　　　　Servlets(Jsps)　　　EJBs
　　 容器　　　　包含在Web服務器中　　在應用服務器中
　　 通信協議　　Http　　　　　　　　Java RMI，CORBA IIOP，
　　　　　　　　　　　　　　　　　　 Microsoft DCOM等
　　 ─────────────────────────────────
　　 這里我們考慮EJBS應用的情況(Web應用在第7、8章討論)。
　　 如圖3-1所示是EJB組件運行架構圖。圖中間的部分包括EJB容器和部署在容器中的組件(即EJB)。圖左邊的部分是EJB的客戶端。圖中共示意了四種客戶端。EJB還有一種重要的客戶端類型，就是EJB本身。也就是說，一個EJB組件可以作為另一個EJB組件的客戶端。這種情況在企業級應用中是很常見的。
　　
　　 客戶端也可以簡單的分成兩種：即Java客戶端和非Java客戶端(比如C/C＋＋)。對Java客戶端來說，傳輸協議可以采用 Java遠程方法調用(Java RMI)方式，也可以是IIOP協議，而對非Java客戶端來說，只能采用IIOP協議。

3.2 EJB角色

　　圍繞EJB應用(包括組件和容器)的開發和部署周期，EJB規范為EJB架構定義了七個角色，每個角色由不同的單位承擔。EJB規范通過定義角色者之間的“合約”，來確保角色間的正確協作。在某些時候，某個組織可以同時具有多個角色。比如某個公司會提供包含EJB服務器和容器的產品，那么它同時充當著EJB服務器提供者和容器提供者兩種角色。因此，這種角色劃分并不是絕對的。
　　 以下是EJB規范2.0中定義的EJB角色。
　　 1．EJB提供者
　　 EJB提供者，即EJB的開發者。對于多數企業級應用開發者來說，都屬于這個角色。EJB提供者的產品是個包含一個或多個EJB的打包文件(即ejb-jar文件)。EJB提供者負責業務邏輯方法的 Java語言實現；定義EJB的遠程和主接口方法和EJB的部署描述符。部署描述符包括EJB的結構信息(如EJB類的名字)和EJB用到的其它所用資源的描述信息。
　　 EJB提供者是個應用領域的專家。負責開發實現業務任務和邏輯實體的可重用的EJB。不必是系統級的程序專家，也不必考慮程序的事務并發性、安全性、分布性等問題，這些問題都是由容器解決的。
　　 2. EJB應用裝配者
　　 應用裝配者把EJB裝配成更大的可部署的應用單元。有時這個工作也由EJB提供者完成。EJB裝配者的輸入是EJB提供者生產的一個或多個ejb-jar文件，輸出是一個或多個包含EJB和應用裝配信息的ejb-jar文件。前者ejb-jar文件的擴展名一般是JAR(Java Archive)，后者ejb-jar文件的擴展名可以是WAR(Web Application Archive)或EAR(Enterprise Application Archive)。應用裝配者把應用裝配信息插入到部署描述符中。
　　 應用裝配者也可以把其它應用類型的組件(如JSP，JavaServerPage)裝配到EJB應用中(這就象在PetStore例子中看到的那樣)。
　　 應用裝配者工作的對象是EJB部署描述符和EJB客戶端視圖合約。雖然他必須熟悉EJB的遠程接口和主接口，但他不必具有任何實現EJB開發的知識。
　　 3．EJB部署者
　　 部署者把從EJB提供者和應用裝配者那里獲取的一個或多個ejb-jar文件中EJB部署到一個指定的環境。有時這個工作也由EJB提供者完成。這個環境包括特定的EJB服務器和容器。
　　 部署者通常會使用EJB容器提供者提供的部署工具(如 WebLogic Server提供的weblogic.ejbc工具)，來為EJB提供需要的外部資源并綁定這些資源，同時必須符合應用裝配者定義的指令。
　　 部署者的產品是定制到特定環境的EJB，這個產品只能被部署在那個特定的容其中。也就是說，EJB的部署是與服務器平臺相關的。
　　 部署者是應用環境的操作專家，負責與EJB部署相關的工作。如：他負責把應用裝配者定義的安全角色和EJB部署環境中的用戶組及賬號對應起來，實現它們的映射。
　　 EJB容器提供者提供的部署工具用來完成部署工作，這個過程分兩個階段：
　　 (1)部署者首先生成附加類和接口，確保容器能管理EJB的運行。這些附加的類是和特定容器相關的。
　　 (2)部署者完成EJB和附加類及附加接口的安裝。
　　 4. EJB服務器提供者
　　 EJB服務器提供者，即生產EJB服務器的廠家。目前符合EJB規范的服務器產品有十幾種，如 WebLogic Server，Websphere，iPlanet等。EJB服務器提供者是分布式事務、分布式對象和其它低級系統級服務的專家。一個典型的EJB服務器提供者可能是操作系統生產者、中間件生產者或數據庫生產者。
　　 目前EJB架構假定EJB服務器提供者和EJB容器提供者是同一個生產者，因此沒有定義EJB服務器提供者的任何接口需求。
　　 5. EJB容器提供者
　　 容器提供者提供了：
　　 (1)部署EJB需要的部署工具。
　　 (2)EJB的運行環境。
　　 從EJB的角度看，容器是EJB的運行環境。容器為EJB提供了事務管理、安全管理。分布式網絡管理、資源管理等服務。
　　 EJB架構定義的EJB容器提供者負責EJB容器和EJB服務器的實現。EJB規范沒有定義EJB容器和服務器之間的接口，由廠家來實現EJB容器和服務器的劃分。
　　 容器提供者需要系統級的編程，容器提供者的重點是開發出可伸縮的、安全的、事務處理的容器，并把它集成到EJB服務器中。容器提供者把EJB和EJB服務器分離開，并在EJB和容器之間提供了簡單、標準的API。這個API就是EJB的容器合約。
　　 容器提供者通常會提供允許系統管理員監視和管理容器和運行在容器中的EJB的工具。
　　 通常把具有EJB容器、EJB服務器和Web服務器功能的產品叫做應用服務器。它為開發企業級應用提供了一個完整的平臺。
　　 6. 管理器提供者
　　 在EJB的使用和開發中，經常會遇到持久性的概念。所謂持久性，是指通過輔助的永久性的存儲設備，如數據庫或文件等，把Java對象的狀態和對應的存儲設備映射起來，當Java對象的狀態發生改變時，存儲的映射也隨之改變。即使在Java對象消失后，存儲設備中依舊保存著Java對象的狀態。當這個Java對象重新實例后，它就會依然保持以前的狀態，這就是Java對象的持久性。
　　 在EJB規范中定義了具有持久性的EJB——實體EJB。根據對持久性管理方式的不同，又把實體 EJB分成容器管理持久性的 EJB(CMP EJB)和Bean管理持久性的EJB(BMP EJB)。
　　 一般情況下，持久性管理器包含在容器管理器中。對于EJB提供者來說，不必了解它的細節。
　　 對于容器管理持久性的實體EJB來說，持久性管理器負責安裝在容器內的實體EJB的持久性管理。在部署階段使用持久性管理器提供者的工具，可以生成代碼，實現數據從實體EJB到數據庫和應用程序的轉換。
　　 容器管理器管理實體Bean及其用到的對象的持久性和這些對象引用的完整性。容器管理器負責容器管理持久性實體EJB的finder方法和select方法的執行。
　　 目前的EJB架構中沒有完整定義容器和持久管理器間的接口，由廠家來自行定義。
　　 7．管理者
　　 系統管理者負責配置、企業級計算、包括EJB服務器和容器的網絡設施的系統管理。同時，系統管理者監視部署在容器中的EJB的運行。
　　 EJB架構沒有為系統管理定義合約。系統管理通常使用EJB服務器和容器提供者提供監視管理工具來完成這些工作。
　　 通常，應用服務器會提供系統管理的控制臺工具(如 WebLogic Server中的 Console)。

3.3 EJB合約

　　這里的合約是指不同EJB角色合作的約定，也是不同角色的開發者開發的產品要遵守的約定。對于EJB提供者即開發者來說，要遵守客戶端視圖合約；對于EJB容器的開發者和使用者來說，要遵守組件和約。本節對這兩個合約進行討論。
　　 在EJB開發過程中，這些合約的體現是EJB開發接口和一些EJB內部對象。
　　 1. 客戶端視圖合約
　　 是客戶端與容器之間的合約?？蛻舳艘晥D合約為使用企業Beans作為組件開發應用程序提供一個統一的開發模式。這個統一的模型使使用高級的開發工具成為可能，并實現組件重用。企業Bean客戶端視圖是基于遠程訪問的，它允許本地和遠程對象采用統一的方式進行訪問。
　　 一個企業Bean的客戶端可能是部署在同一個或不同容器的另一個企業Bean。也可以是任何一個Java程序，如應用程序、Applet或Servlet。一個企業Bean的客戶端視圖也可以被映射到非Java客戶端，如CORBA客戶端。它不是由JavaTM編程語言寫的。企業Bean提供者和容器提供者一同提供企業Bean的客戶端視圖?？蛻舳艘晥D包括：
　　 ·主程接口(Home Interface)
　　 ·遠程接口(Remote Interface)
　　 ·對象識別(Object Identity)
　　 ·元數據接口(Metadata Interface)
　　 ·句柄(Handle)
　　 主接口(Home Interface)：定義創建、刪除和查找同類 EJB對象的方法(即它們由同一個企業Bean實現)和主業務邏輯方法(即不是特定某個Bean實例的方法)。主接口由Bean提供者制訂；容器創建一個類來實現主接口。主接口繼承javax.ejb.EJBHome接口。
　　 客戶端通過標準的Java名稱和目錄接口(Java Naming and Directory Interface TM，JNDI)API定義企業Bean主接口。
　　 EJB對象是通過遠程接口(Remote Interface)來訪問的。遠程接口定義了客戶端調用的業務邏輯方法。遠程接口由Bean提供者制定；容器創建一個類來實現遠程接口。遠程接口繼承了javax.ejb.EJBObject接口。javax.ejb.EJBObject接口定義了允許客戶端訪EJB對象標識和EJB對象創建一個持久性句柄的操作。
　　 每個EJB對象在主域里存活，并有一個惟一的標識。對 Session Beans來說，容器負責為每個Session對象產生新的惟一標識。這個標識并沒有暴露給客戶端。然而，客戶端可以測試兩個對象引用是否指向同一個Session對象。對實體EJB來說，Bean提供者負責在Entity對象創建的時候提供一個主鍵；容器使用主鍵來在主域中標識實體對象?？蛻酎c可以通過javax.ejb.EJBObject接口獲取一個實體對象的主鍵?？蛻舳艘部梢詼y試兩個對象引用是否指向同一個實體對象。
　　 客戶端也可以獲取企業Bean的元數據接口?？蛻舳耸褂迷獢祿涌谥饕迷趫绦衅髽IBean的動態調用上。(提供客戶端視圖的類不可用的時候需要動態調用)。
　　 消息驅動Beans沒有Home和Remote接口，因此它沒有客戶端視圖?？蛻舳丝梢酝ㄟ^標準JNDI API定位發到消息驅動Bean的消息所在的JMS目標。
　　 2. 組件合約
　　 這部分描述企業Bean和它的容器之間的合約，以及在容器管理持久性的企業Bean情況下，企業Bean和它的持久管理器之間的合約。主要的合約如下(部分)：
　　 ·需要Bean提供者實現企業Bean類中的業務方法。需要容器提供者提供客戶端調用這些方法的代理。
　　 ·對于消息驅動Beans來說，需要Bean提供者實現企業Bean類中的onMessage方法。需要容器提供者調用這些方法。
　　 ·如果Bean是實體并且是Bean管理持久性(BMP)的，需要Bean提供者實現ejbCreate方法ejbPostCreate方法、ejbRemove方法和ejbFind方法。需要容器提供者在EJB對象的創建、刪除和查詢的過程中調用這些方法。
　　 ·對于容器管理的持久性，需要Bean提供者為持久屬性提供抽象的訪問方法和一個實體與容器管理持久性的關系。需要持久管理提供者提供這些方法的實現。
　　 ·需要Bean提供者提供持久性管理器實現的關系描述。
　　 ·需要Bean提供者定義企業Bean的主接口和遠程接口，如果是實體Bean或Session Bean，需要Container提供者提供實現這些接口的類。
　　 ·對會話來說，需要Bean提供實現javax.ejb.SessionBean接口或在javax.ejb.SessionSynchronization接口中定義的容器回調。需要容器管理者在適當的時候調用這些回調。
　　 ·對消息驅動Beans來說，需要Bean提供者實現定義在接口javax.ejb.MessageDrivenBean中的容器回調。
　　 ·對實體EJB來說，需要Bean提供者實現定義在javax.ejb.EntityBean中的容器回調。需要容器在適當的時候調用這些回調。
　　 ·需要持久管理器提供者實現實體Beans的持久性。
　　 ·需要容器提供者為會話bean實例提供javax.ejb.SessionContext接口，為實體bean實例提供javax.ejb.EntityContext接口，為消息驅動bean實例提供javax.ejb.MessageDrivenContext接口。上下文接口允許實例獲取容器的信息。
　　 ·需要容器為Bean實例提供JNDI上下文，它包含企業Bean的環境信息。
　　 ·需要容器為企業Bean實例管理事務、安全和異常。
　　 ·需要Bean提供者避免程序影響企業Bean實例的容器運行時管理。
　　 3. ejb-jar文件
　　 一個ejb-jar文件具有標準的格式。EJB工具用它來作為描述性的語言打包企業Beans。ejb-jar文件用來執行程序的裝配和部署。
　　 ejb-jar文件包括：
　　 ·企業Beans的Java類文件和它們的遠程和主接口。
　　 ·XML部署描述符。部署描述符提供關于在ejb-jar文件中的企業Beans的結構和裝配信息。
　　 4. 合約總結
　　 如圖3-2描述了EJB的合約。
　　
　　 注意 圖3-2只顯示遠程客戶端運行在Container外的情況，客戶端視圖API也可以用在同一個容器中的企業Beans。

3.4 會話、實體和消息驅動Bean對象

　　 EJB架構定義了三種類型的企業Bean對象：
　　 ·會話對象(Session Obect)
　　 ·實體對象(Entity Obect)
　　 ·消息驅動對象(Message-Driven Object)
　　 1. 會話對象(Session)
　　 一個典型的會話對象具有如下特征：
　　 ·由一個客戶端執行。
　　 ·自動事務感知。
　　 ·在一個潛在的數據庫中更新共享數據。
　　 ·不直接表示數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·相對來說是短命的。
　　 ·當EJB容器停止后被清除掉?？蛻糁荒苤匦陆⑿碌膶ο髞砝^續計算。
　　 一個典型的EJB Containe提供一個靈活的運行環境來并發的執行大量的會話對象。
　　 會話Beans是有狀態的。同時EJB規范也支持無狀態會話Bean作為一個特殊的情況。有狀態(正常)會話Beans和無狀態會話Bean的API有很小的差別。
　　 2. 實體對象(Entity)
　　 一個典型的實體對象有如下特征；
　　 ·提供一個數據庫的數據視圖。
　　 ·允許多個用戶共享訪問。
　　 ·存活時間長(和數據庫中的數據一樣)。
　　 ·實體，主鍵和遠程引用可以在EJB容器停止后存活。如果實體的狀態被事務更新，同時容器停止，實體的狀態自動地重新置為最后一次觸發事務的狀態。停止對于客戶端來說不是完全透明的，在它調用一個實體容器崩潰的時候，客戶端可能會收到一個異常。
　　 特殊的EJB容器和服務器為多個并發的實體對象提供一個可變的運行時環境。
　　 3. 消息驅動對象
　　 一個典型的消息驅動對象具有如下特征：
　　 ·收到某個客戶端消息時執行。
　　 ·自動事務感知。
　　 ·自動更新共享數據。
　　 ·不直接代表數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·生命短。
　　 ·無狀態。
　　 ·EJB容器崩潰時被刪除。容器不得不重新建立新的消息驅動對象來繼續計算。
　　 一個典型的EJB容器提供一個靈活的運行環境來同時執行多個消息驅動對象。

3.4 會話、實體和消息驅動Bean對象

　　 EJB架構定義了三種類型的企業Bean對象：
　　 ·會話對象(Session Obect)
　　 ·實體對象(Entity Obect)
　　 ·消息驅動對象(Message-Driven Object)
　　 1. 會話對象(Session)
　　 一個典型的會話對象具有如下特征：
　　 ·由一個客戶端執行。
　　 ·自動事務感知。
　　 ·在一個潛在的數據庫中更新共享數據。
　　 ·不直接表示數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·相對來說是短命的。
　　 ·當EJB容器停止后被清除掉?？蛻糁荒苤匦陆⑿碌膶ο髞砝^續計算。
　　 一個典型的EJB Containe提供一個靈活的運行環境來并發的執行大量的會話對象。
　　 會話Beans是有狀態的。同時EJB規范也支持無狀態會話Bean作為一個特殊的情況。有狀態(正常)會話Beans和無狀態會話Bean的API有很小的差別。
　　 2. 實體對象(Entity)
　　 一個典型的實體對象有如下特征；
　　 ·提供一個數據庫的數據視圖。
　　 ·允許多個用戶共享訪問。
　　 ·存活時間長(和數據庫中的數據一樣)。
　　 ·實體，主鍵和遠程引用可以在EJB容器停止后存活。如果實體的狀態被事務更新，同時容器停止，實體的狀態自動地重新置為最后一次觸發事務的狀態。停止對于客戶端來說不是完全透明的，在它調用一個實體容器崩潰的時候，客戶端可能會收到一個異常。
　　 特殊的EJB容器和服務器為多個并發的實體對象提供一個可變的運行時環境。
　　 3. 消息驅動對象
　　 一個典型的消息驅動對象具有如下特征：
　　 ·收到某個客戶端消息時執行。
　　 ·自動事務感知。
　　 ·自動更新共享數據。
　　 ·不直接代表數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·生命短。
　　 ·無狀態。
　　 ·EJB容器崩潰時被刪除。容器不得不重新建立新的消息驅動對象來繼續計算。
　　 一個典型的EJB容器提供一個靈活的運行環境來同時執行多個消息驅動對象。

3.4 會話、實體和消息驅動Bean對象

　　 EJB架構定義了三種類型的企業Bean對象：
　　 ·會話對象(Session Obect)
　　 ·實體對象(Entity Obect)
　　 ·消息驅動對象(Message-Driven Object)
　　 1. 會話對象(Session)
　　 一個典型的會話對象具有如下特征：
　　 ·由一個客戶端執行。
　　 ·自動事務感知。
　　 ·在一個潛在的數據庫中更新共享數據。
　　 ·不直接表示數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·相對來說是短命的。
　　 ·當EJB容器停止后被清除掉?？蛻糁荒苤匦陆⑿碌膶ο髞砝^續計算。
　　 一個典型的EJB Containe提供一個靈活的運行環境來并發的執行大量的會話對象。
　　 會話Beans是有狀態的。同時EJB規范也支持無狀態會話Bean作為一個特殊的情況。有狀態(正常)會話Beans和無狀態會話Bean的API有很小的差別。
　　 2. 實體對象(Entity)
　　 一個典型的實體對象有如下特征；
　　 ·提供一個數據庫的數據視圖。
　　 ·允許多個用戶共享訪問。
　　 ·存活時間長(和數據庫中的數據一樣)。
　　 ·實體，主鍵和遠程引用可以在EJB容器停止后存活。如果實體的狀態被事務更新，同時容器停止，實體的狀態自動地重新置為最后一次觸發事務的狀態。停止對于客戶端來說不是完全透明的，在它調用一個實體容器崩潰的時候，客戶端可能會收到一個異常。
　　 特殊的EJB容器和服務器為多個并發的實體對象提供一個可變的運行時環境。
　　 3. 消息驅動對象
　　 一個典型的消息驅動對象具有如下特征：
　　 ·收到某個客戶端消息時執行。
　　 ·自動事務感知。
　　 ·自動更新共享數據。
　　 ·不直接代表數據庫中的共享數據，雖然它可以訪問和更新這些數據。
　　 ·生命短。
　　 ·無狀態。
　　 ·EJB容器崩潰時被刪除。容器不得不重新建立新的消息驅動對象來繼續計算。
　　 一個典型的EJB容器提供一個靈活的運行環境來同時執行多個消息驅動對象。

3.5 CORBA協議的標準映射

　　為了實現不同系統的EJB環境間的協作，EJB 2.0規范需要會話Beans和實體Beans的J2EE客戶調用端支持基于CORBA/IIOP協議兼容的實現。

3.6 本章小結

　　對于本章闡述的概念，讀者不可能在看過一次后完全領會。本書后面幾章提供了大量的EJB應用的實例，讀者在實際操作完這些例子后再重新理解這些概念會取得更好的效果。
　　 下一章討論會話EJB的特征、編程模型和實例開發。