最近項目中接觸到EJB，但對EJB不是很了解，於是網上找了些資料參考，下面這篇是個人感覺講的比較清晰的，遂轉載一起參考,文章轉自https://www.cnblogs.com/strugglion/p/6027318.html。
EJB到底是什么？
1. 我們不禁要問，什么是"服務集群"？什么是"企業級開發"？
既然說了EJB 是為了"服務集群"和"企業級開發"，那么，總得說說什么是所謂的"服務集群"和"企業級開發"吧！這個問題其實挺關鍵的，因為J2EE 中並沒有說明白，也沒有具體的指標或者事例告訴廣大程序員什么時候用EJB 什么時候不用。於是大家都產生一些聯想，認為EJB"分布式運算"指得是"負載均衡"提高系統的運行效率。然而，估計很多人都搞錯了，這個"服務群集"和"分布式運算"並沒有根本解決運行負載的問題，尤其是針對數據庫的應用系統。
為什么？
我們先把EJB 打回原形給大家來慢慢分析。
2. 把EJB 掰開了揉碎了
我們把EJB 的概念好好的分析一下，看看能發現些什么蛛絲馬跡。
3.1 EJB 概念的剖析
我們先看一下，EJB 的官方解釋：
商務軟件的核心部分是它的業務邏輯。業務邏輯抽象了整個商務過程的流程，並使用計算機語言將他們實現。
……
J2EE 對於這個問題的處理方法是將業務邏輯從客戶端軟件中抽取出來，封裝在一個組件中。這個組件運行在一個獨立的服務器上，客戶端軟件通過網絡調用組件提供的服務以實現業務邏輯，而客戶端軟件的功能單純到只負責發送調用請求和顯示處理結果。在J2EE 中，這個運行在一個獨立的服務器上，並封裝了業務邏輯的組件就是EJB（Enterprise JavaBean）組件。這其中我們主要關注這么幾點，我們來逐條剖析：
剖析1：所謂："業務邏輯"
我們注意到在EJB 的概念中主要提到的就是"業務邏輯"的封裝，而這個業務邏輯到底是什么？說的那么懸乎，其實這個所謂的"業務邏輯"我們完全可以理解成執行特定任務的"類"。
剖析2：所謂："將業務邏輯從客戶端軟件中抽取出來，封裝在組件中……運行在一個服務器上"
既然我們知道了"業務邏輯"的概念就是執行特定任務的"類"，那么，什么叫"從客戶端軟件中抽取出來"？其實，這個就是把原來放到客戶端的"類"，拿出來不放到客戶端了，放到一個組件中，並將這個組件放到一個服務器上去運行。
3.2 把EJB 這個概念變成大白話
變成大白話就是，"把你編寫的軟件中那些需要執行制定的任務的類，不放到客戶端軟件上了，而是給他打成包放到一個服務器上了"。
3.3 發現問題了
不管是用"八股文"說，還是用大白話說這個EJB 概念都提到了一個詞--"客戶端軟件"。
"客戶端軟件"？難道EJB 的概念中說的是C/S 軟件？
是的，沒錯！
EJB 就是將那些"類"放到一個服務器上，用C/S 形式的軟件客戶端對服務器上的"類"進行調用。
快崩潰了吧！
EJB 和JSP 有什么關系？EJB 和JSP 有關系，但是關系還真不怎么大，至多是在JSP 的服務器端調用遠端服務上的EJB 類，僅此而已。
4 .1 EJB 的最底層究竟是什么
我們揭開了EJB"八股"概念的真諦，那么，再來分析EJB 的底層實現技術，通過底層實
現技術來分析EJB 的工作方式。
4.2 EJB 的實現技術
EJB 是運行在獨立服務器上的組件，客戶端是通過網絡對EJB 對象進行調用的。在Java中，能夠實現遠程對象調用的技術是RMI，而EJB 技術基礎正是RMI。通過RMI 技術，J2EE將EJB 組件創建為遠程對象，客戶端就可以通過網絡調用EJB 對象了。
4.3 看看RMI 是什么東東
在說RMI 之前，需要理解兩個名詞：
對象的序列化
分布式計算與RPC
名詞1：對象的序列化
對象的序列化概念：對象的序列化過程就是將對象狀態轉換成字節流和從字節流恢復對象。將對象狀態轉換成字節流之后，可以用java.io 包中的各種字節流類將其保存到文件中，或者通過網絡連接將對象數據發送到另一個主機。
上面的說法有點"八股"，我們不妨再用白話解釋一下：對象的序列化就是將你程序中實例化的某個類的對象，比如，你自定一個類MyClass，或者任何一個類的對象，將它轉換成字節數組，也就是說可以放到一個byte 數組中，這時候，你既然已經把一個對象放到了byte數組中，那么你當然就可以隨便處置了它了，用得最多的就是把他發送到網絡上遠程的計算機上了。如圖2 11所示。
名詞2：分布式計算與RPC
RPC 並不是一個純粹的Java 概念，因為在Java 誕生之前就已經有了RPC 的這個概念，RPC是"Remote Procedure Call"的縮寫，也就是"遠程過程調用"。在Java 之前的大多數編程語言，如，Fortran、C、COBOL 等等，都是過程性的語言，而不是面向對象的。所以，這些編程語言很自然地用過程表示工作，如，函數或子程序，讓其在網絡上另一台機器上執行。說白了，就是本地計算機調用遠程計算機上的一個函數。如圖2 12所示。
名詞3：二者結合就是RMI
RMI 英文全稱是"Remote Method Invocation"，它的中文名稱是"遠程方法調用"，它就是利用Java 對象序列化的機制實現分布式計算，實現遠程類對象的實例化以及調用的方法。說的更清楚些，就是利用對象序列化來實現遠程調用，也就是上面兩個概念的結合體，利用這個方法來調用遠程的類的時候，就不需要編寫Socket 程序了，也不需要把對象進行序列化操作，直接調用就行了非常方便。
遠程方法調用是一種計算機之間對象互相調用對方函數，啟動對方進程的一種機制，使用這種機制，某一台計算機上的對象在調用另外一台計算機上的方法時，使用的程序語法規則和在本地機上對象間的方法調用的語法規則一樣。如圖2 13所示。
4.4 優點
這種機制給分布計算的系統設計、編程都帶來了極大的方便。只要按照RMI 規則設計程序，可以不必再過問在RMI 之下的網絡細節了，如：TCP 和Socket 等等。任意兩台計算機之間的通訊完全由RMI 負責。調用遠程計算機上的對象就像本地對象一樣方便。RMI 可將完整的對象作為參數和返回值進行傳遞，而不僅僅是預定義的數據類型。也就是說，可以將類似Java 哈西表這樣的復雜類型作為一個參數進行傳遞。
4.5 缺點
如果是較為簡單的方法調用，其執行效率也許會比本地執行慢很多，即使和遠程Socket機制的簡單數據返回的應用相比，也會慢一些，原因是，其在網絡間需要傳遞的信息不僅僅包含該函數的返回值信息，還會包含該對象序列化后的字節內容。
4.6 EJB 是以RMI 為基礎的
通過RMI 技術，J2EE 將EJB 組件創建為遠程對象，EJB 雖然用了RMI 技術，但是卻只需要定義遠程接口而無需生成他們的實現類，這樣就將RMI 技術中的一些細節問題屏蔽了。但不管怎么說，EJB 的基礎仍然是RMI，所以，如果你想了解EJB 的原理，只要把RMI的原理搞清楚就行了。你也就弄清楚了什么時候用EJB 什么時候不需要用EJB 了。
5. EJB 中所謂的"服務群集"
既然已經知道了，RMI 是將各種任務與功能的類放到不同的服務器上，然后通過各個服務器間建立的調用規則實現分布式的運算，也就明白EJB 所謂的"服務群集"的概念。就是將原來在一個計算機上運算的幾個類，分別放到其他計算機上去運行，以便分擔運行這幾個類所需要占用的CPU 和內存資源。同時，也可以將不同的軟件功能模塊放到不同的服務器上，當需要修改某些功能的時候直接修改這些服務器上的類就行了，修改以后所有客戶端的軟件都被修改了。如圖2 14所示。
6. 這種部署難道是無懈可擊
圖2 14所示的這個"服務群集"看似"無懈可擊"，其實是它這個圖沒有畫完整，我們來把這個圖畫完整，再來看看有什么問題沒有。
6.1 瓶頸在數據庫端
仔細觀察之后，發現這種配置是有瓶頸的，如圖2 15所示。
我們看看圖2 15的結構圖，現在如果想實現各個服務器針對同一個數據庫的查詢，那么，不管你部署多少個功能服務器，都需要針對一個數據庫服務器進行查詢操作。也就是說，不管你的"計算"有多么"分布"也同樣需要從一台服務器中取得數據。雖然，看起來將各個功能模塊分布在不同的服務器上從而分擔了各個主計算機的CPU 資源，然而，真正的瓶頸並不在這里，而是，數據庫服務器那里。數據庫服務器都會非常忙的應付各個服務器的查詢及操作請求。
因此，通過這個結構圖使我們了解到了EJB 根本不能完全解決負載的問題，因為，瓶頸並不在功能模塊的所在位置，而是在數據庫服務器這里。
6.2 假如分開數據庫，數據共享怎么辦
有的讀者一定會想到下面的這個應用結構，如圖2 16所示。
就是把每一個功能服務器后面都部署一個數據庫，這樣不就解決了上節所說的問題了嗎？是的解決了數據庫查詢負載的問題，然而又出現了新的問題，就是"數據共享"的問題就又不容易解決了。
6.3 網絡面臨較大壓力，讓你的應用慢如老牛
我們再向前翻看看如圖2 15所示的這種架構中存在兩個網絡，一個是"A 網"一個是"B網"，這兩個網絡是不同的。"B 網"往往是局域網，一般帶寬是10M/100M，速度較快，因此到還好說，然而，"A 網"往往是互聯網或者是利用電信網絡互聯VPN 網或稱廣域網。"A 網"的特點是帶寬一般較窄，如ADSL 的網絡僅僅有512K-2M 的帶寬，由於廣域網互聯的成本較高，所以一般不會有較高的帶寬。而在這個網絡上恰恰跑的是功能模塊和客戶端軟件之間交換的數據，而這部分數據恰恰優勢非常占用帶寬的。因此，這個應用架構其運行速度可以想見是多么的慢了。說句不誇張的話，有點想老牛拉破車一樣的慢。一個如老牛的系統：目前在中國互聯網做運營商網絡管理系統的一個大公司，它的一個早期的網管軟件就是采用了這種架構來做的C/S 結構的應用系統。有一次，我作為評估者來對其應用系統進行評估，將其部署到一個非運營商大型的網絡中的時候，便出現了我們上述描述的情況，速度已經到了難以忍受的地步，打開一個流量圖，有時候需要用15分鍾的時間才能呈現完整。然而，該系統在開發階段並沒有發現這個問題，為什么呢？因為，他們沒有考慮到應用的實際用戶連接網絡的復雜性，從而給該公司造成較大損失，以至於，這個開發架構被最終遺棄。
7. EJB 活學活用，J2EE 不是必須使用EJB
通過上面小節的講解似乎好像EJB 和開發Web 應用的B/S 結構的系統關系並不大，其實倒也不然。我們如果把"客戶端程序"理解成某一台服務器，這樣也是可以被應用的，而且，如果是服務器互相之間做EJB 的調用的話，也就不存在廣域網帶寬限制的問題了。
但是，如下情況盡量就不要使用EJB 了：
1、較為簡單的純Web 應用開發，不需要用EJB。
2、需要與其他服務程序配合使用的應用，但調用或返回的自定義的網絡協議可以解決的應用程序,不需要使用EJB。
3、較多人並發訪問的C/S 結構的應用程序，盡量不要使用EJB。
總結：
a.EJB實現原理： 就是把原來放到客戶端實現的代碼放到服務器端，並依靠RMI進行通信。
b.RMI實現原理 ：就是通過Java對象可序列化機制實現分布計算。
c.服務器集群： 就是通過RMI的通信，連接不同功能模塊的服務器，以實現一個完整的功能。
Java使用EJB容器的詳細概述
Java EJB的體系結構：
EJB的上層的分布式應用程序是基於對象組件模型的，低層的事務服務用了API技術。EJB技術簡化了用 JAVA語言編寫的企業應用系統的開發，配置，和執行。EJB的體系結構的規范由Sun Microsystems公司制定。 Inprise的EJB容器是基於1.1版的規范。
EJB技術定義了一組可重用的組件：Enterprise Beans。你可以利用這些組件，象搭積木一樣的建立你的分布式應用程序。當你把代碼寫好之后，這些組件就被組合到特定的文件中去。每個文件有一個或多個 Enterprise Beans，在加上一些配置參數。最后，這些Enterprise Beans被配置到一個裝了EJB容器的平台上。客戶能夠通過這些Beans的home接口，定位到某個beans，並產生這個beans的一個實例。這樣，客戶就能夠調用Beans的應用方法和遠程接口。
EJB服務器作為容器和低層平台的橋梁管理着EJB容器和函數。它向EJB容器提供了訪問系統服務的能力。 例如：數據庫的管理和事務的管理，或者對於其它的Enterprise的應用服務器。
所有的EJB 實例都運行在EJB容器中。容器提供了系統級的服務，控制了EJB的生命周期。因為容器掌握了絕大多數系統級的issues(呵呵，不知道怎么翻譯)。Enterprise Beans 的開發者不需要應用邏輯考慮進來。通常來說，EJB容器掌握了以下的系統級issues.
1、Security–配置描述器（The Deployment descriptor）定義了客戶能夠訪問的不同的應用函數。容器 通過只允許授權的客戶訪問這些函數來達到這個效果。
2、Remote Connectivity–容器為遠程鏈接管理着低層的通信issues，而且對Enterprise Beas的開發者和客戶都隱藏了通信issues.Enterprise Beans的開發者在編寫應用方法的時候，就象是在條用本地的平台一樣的。客戶也不清楚他們調用的方法可能是在遠程被處理的。
3、Life Cycle managment–客戶簡單的創建一個Enterprise beans的實例，並通常取消一個實例。而容器管理着Enterprise Beans的實例，使Enterprise Beans實現最大的效能和內存利用率。容器能夠這樣來激活和去活Enterprise Beans，保持眾多客戶共享的實例池。等等。
4、Trasction management—配置描述器定義了Enterprise beans 的事務處理的需求。容器管理着那些管理分布式事務處理的復雜的issues。這些事務可能要在不同的平台之間更新數據庫。容器使這些事務之間互相獨立，互不干擾。保證所有的更新數據庫都是成功發生的，否者，就回滾到事務處理之前的狀態。
Enterprise Beans 組件：
Enterprise Beans 是基於分布式事務處理的企業級應用程序的組件。所有的Enterprise beans都有如下 的特點：
Enterprise beans包含了處理企業數據的應用邏輯。
Enterprise beans provider定義了Enterprise beans的客戶界面（Enterprise beans 的遠程界面）。這樣的界面不受容器和服務器的影響。於是，當一個 Enterprise beans被集合到一個應用程序中去時，不用更改代碼和重新編譯。
Enterprise beans能夠被 定制
各種系統級的服務，例如安全和事務處理的特性，都不是屬於Enterprise beans class的。而是由 配置和組裝應用程序的工具來實現。
有兩種類型的Enterprise beans: Session beans 和 entity beans.
Session beans:
Session beans 是一種作為單個的client執行的對象。作為對遠程的任務請求的相應，容器產生一個 Session beans 的實例。一個Session beans有一個client.從某種程度上來說，一個Session bean 對於服務器來說就代表了它的那個client.Session beans 也能用於事務，它能夠更新共享的數據，但它不直接描繪這 些共享的數據。
Session beans 的生命周期是相對較短的。典型的是，只有當client保持會話的時候，Session beans 才是活着的。一旦client退出了，Session beans 就不再與client相聯系了。Session beans被看成是瞬時的，因為如果容器崩潰了，那么client必須重新建立一個新的Session對象來繼續會話。
一個Session bean典型的聲明了與client的互操作或者會話。也就是說，Session bean了在客戶會話期間，通過方法的調用，掌握Client的信息。一個具有狀態的Session bean稱為有狀態的Session bean.當client 終止與Session beans互操作的時候.會話終止了，而且，bean 也不再擁有狀態值。
一個Session bean也可能是一個無狀態的 session bean.無狀態的Session beans並不掌握它的客戶的信息或者狀態。Client能夠調用beans的方法來完成一些操作。但是，beans只是在方法調用的時候才知道 client的參數變量。當方法調用完成以后，beans並不繼續保持這些參數變量。這樣，所有的無狀態的 session beans的實例都是相同的，除非它正在方法調用期間。這樣，無狀態的Session beans就能夠支持多個client.容器能夠聲明一個無狀態的Session beans.能夠將任何Session beans指定給任何client.
Entity Beans:
Entity Beans對數據庫中的數據提供了一種對象的視圖。例如：一個Entity bean能夠模擬數據庫表中一行相關的數據。多個client能夠共享訪問同一個Entity bean.多個client也能夠同時的訪問同一個Entity bean.Entity beans通過事務的上下文來訪問或更新下層的數據。這樣，數據的完整性就能夠被保證。
Entity Beans能存活相對教長的時間，並且狀態是持續的。只要數據庫中的數據存在，Entity beans就一直存活。而不是按照應用程序或者服務進程來說的。即使EJB容器崩潰了，Entity beans也是存活的。Entity Beans生命周期能夠被容器或者 Beans自己管理。如果由容器控制着保證 Entity beans持續的issus。如果由 Beans自己管理，就必須寫Entity beans的代碼，包括訪問數據庫的調用。
Entity Beans是由主鍵（primary key 一種唯一的對象標識符）標識的。通常，主鍵與標識數據庫中的一 塊數據，例如一個表中的一行，的主鍵是相同的。主鍵是client能夠定位特定的數據塊。
EJB roles:
EJB體系結構通過把編程的過程分為6個不同的角色而使開發復雜的的應用系統變的簡單。6個不同的角色 ，每個都有特定的任務。6個角色包括下層的服務，應用程序的開發，配置和操作說明（issues）
EJB體系結構能夠簡化應用程序開發人員的工作。在EJB體系結構中，容器和代理服務承擔了很多在其他環 境中又程序設計人員承擔的工作。這樣的代理提供了很多原來需要程序設計人員編寫代碼的系統級的服務。
Infrastructure roles;（下層構造角色）
EJB Server Providor服務提供者是典型的提供分布式低層服務的代理。EJB服務提供者提供了一個分布式 應用程序開發者需要的平台和設施。也提供了分布式程序的運行時環境。
EJB Container Providor 容器提供者是分布式系統，事務處理，安全方面的專家容器提供者提供了一個 EJB的配置工具，和這些配置實例的運行時支持。
一個容器對一個或多個EJB來說，是一個運行時系統。它將Enterprise Beans和EJB服務，包括事務服務，安全服務，分布式網絡管理等膠合在一起。容器是既是一個定制的代碼和對特定的 Enterprise beans產生詳細代碼的工具。容器也提供了一個配置Enterprise beans的工具和管理監視應用程序的方法。
Application roles：（應用角色）
Enterprise beans Provider:Beans提供者在應用領域方面是專家。例如：Beans提供者可能是金融或電信方面的專家。Beans提供者提供了業務 tasks，Enterprise beans的業務方法，定義了beans的romote和home接口，還定義了beans的配置描述器。因為容器管理着系統級的任務，所以，Beans 提供者便不需要關心分布處理，事務處理，安全性能等從應用方面看來沒什么關系的方面。
Application Assembler程序組裝器:
這是一個將定制的Enterprise beans和其它的組件，例如，GUI client,applet,Servelet等組裝成一個完整的應用程序的行家。在Enterprise的配置器下，組裝器在組裝成一個應用程序的時候，只關心beans的接口，包括romote接口和home接口。而不關心這些接口是怎么實現的。組裝的結果就是一個一個的應用程序，或者由多個 Enterprise beans組合成的一個比較復雜的Enterprise beans.
Deployment and Operate roles配置和操作角色
配置器為特定的Enterprise beans配置特殊的操作環境。配置器為了適應應用程序，將多個Enerprise beans 組合起來，通過修改Enterprise beans 的屬性來達到配置相應的操作環境。例如，配置器通過設置配置描述符的相應的屬性來設置事務和安全方針。配置器的另一個任務是將應用程序與現有的 Enterprise管理軟件結合起來。
System Administrator系統管理者；
是與配置應用有關的。管理者配置個管理Enterprise計算和網絡服務的低層，包括EJB服務和容器。管理員監視着應用服務器的運行狀況，當應用服務器不正常運行是就采取相應的措施。典型的說，管理員使用Enterprise管理工具來與應用程序打交道，通過由容器提供的hooks來配置。
傳統的應用程序開發者現在是Enterprise beans的提供者。也可能是應用程序的裝配者。這樣能使他們將主要精力放在應用問題或者應用邏輯上面。當安裝Enterprise beans時，配置器定義了一系列的配置方針。機制的復雜性和執行配置的方針就交給了專門的代理。雖然分布式的應用程序還是比較復雜，可是，應用程序設計者的工作卻變的簡單了，因為所有復雜的工作都交給了EJB服務器和容器提供者了。
通過大量的設計之前的定義和命名約定，EJB達到了前面提到的目的。這樣的編程體系結構限制了一定的自由，但是，允許EJB服務器和容器提供者假定應用程序的設計，並以一種行之有效的方式來支持他們。
EJB的設計模式和命名約定：
有三種途徑來建立一個基於對象的，多層的，分布式的系統：無狀態服務的途徑，基於會話的途徑和持續對象的途徑。
無狀態的服務是通過對象的操作提供一種功能的函數，但是，不保持會話的狀態。當一個客戶使用無狀態的對象時，客戶不能夠提供上一次操作的信息。
基於會話的設計產生了一個中間層的對象，稱為一個會話（Session）。這個會話可以看成是這個客戶的代理。典型的，會話的生命是由客戶和所在的服務程序決定的。客戶如果完成了會話就可以將對象移走。如果服務終止了，會話對象就會超時。會話對象就會變的無效了。
持續對象設計模式綁定了存在數據庫中的一塊數據。提供了操作這塊數據的一些個操作。持續對象是由多個客戶共享的。起生命期是由存儲數據的庫所決定的。
EJB規范中將這些分別稱做：stateless Session, stateful Session, Entiry Beans.Session Beans模式就是基於會話的設計模式。Entiry Beans模式就是持續對象設計模式。每種模式都定義了一些接口和命名約定。
Enterprise JavaBeans infrastruct （EJB的基礎結構）
容器和服務提供者實現了EJB的基礎構造。這些基礎構造處理了EJB的分布式方面，事務管理，安全性方面。EJB規范定義了基礎構造和J ava API的為了適應各種情況的要求。而沒有去指定用什么技術，平台，協議來實現他們。
Enterprise beans, container, server說明了EJB基礎結構的要求，EJB基礎結構必須提供客戶和Enterprise beans通信的通道。雖然這不是EJB規范所定義的。但保證通道的安全也是很重要的。特別是當客戶通過internet訪問遠程的Enterprise beans時。EJB基礎結構也必須能夠加強Enterprise beans 的訪問控制。
Enterprise beans所有的數據的持續性必須被保證。EJB的低層結構必須提供在企業級的計算環境中與現存系統的結合能力。Beans的所有通信都是分布式事務的一部分，需要由EJB低層結構來管理對於一個成功的配置，EJB低層必須提供分布式應用管理工具的鈎子（hooks）
Container
容器可能是EJB里面最重要的概念。因為它向程序開發人員提供了最大程度的方便。基於對象的中間層軟件平台如CORBA或者遠過程調用RMI是程序開發者從網絡傳輸中解放出來，通過提供對象定位機制，數據重組機制等等。容器的概念則走的更遠一點。通過簡化分布式應用程序的那些復雜的方面，如：安全性，事務協調性，數據持久性。
一旦Enterprise Beans准備好了可以配置了。就被打包成一個標准的JAVA文件，ejb-jar文件。一個ejb-jar文件可以包括一個或多個的 Enterprise Beans。對每一個Enterprise beans，都由它的接口，類，和配置描述器。
Enterprise Beans Provider提供如下東西給ejb-jar 文件：
Enterprise Beans 的remote 接口，接口說明了Client端能調用的函數。
Enterprise Beans 的home 接口，home接口使客戶生成和定位一個Enterprise Beans的實例。
Enterprise 類本身，實現了Enterprise beans 的語義。
Deploy Descripot配置描述器，deployer通過利用配置描述器來提供沒有在代碼中申明的信息。例如方針和屬性。EJB的1.0規范把配置描述器定義為javax.ejb.deployment. SessionDescriptor類或者javax.ejb.deployment.EntityDescriptor的一個實例，但是在1.1版本中不贊成這樣做。而是用XML來定義配置描述器。
配置一個Enterprise Beans 意味着將一個Enterprise Bean安裝到容器中去。安裝過程包括了如下幾個方面：
保證不同的Enterprise beans能夠工作在一起。用名字服務來注冊一個Enterprise Bean。通過EJB服務的通信系統提供訪問EJB的入口。
執行事務管理和安全方針。在一個EJB容器中可以又任意多個Enterprise beans.除了安裝和執行以外，容器也提供了配置Enterprise beans的工具。為什么用Inprise的EJB 容器？Inprise EJB容器提供的完全的服務完全支持EJB1。1規范。一個有效的運行和管理EJBs的容器。提供命名服務，事務服務，植入Java RDBMS的內部。編程，配置簡單充分的例子來演示怎樣使用EJBs和EJB容器。對於Enterprise beans的開發者來說，EJB 容器是一個高級Enterprise類產品。因為它有如下優點：完整的，靈活的運行時環境：EJB容器完全實現了EJB1。1的規范，包括了它的所有功能。
每一個由工具產生的Enterprise bean都同時是Enterprise bean 對象和CORBA對象。
EJB容器能夠進行單獨配置，100%的純JAVA服務，或者作為完全的分布式的配置。這樣的靈活性意味着你能夠根據你的要求調整你的應用程序。
與其它的EJB服務不一樣，Inprise 的EJB容器服務並沒有限制一定要分開。而是任意個數的Enterprise beans可以放在任意個數的容器中，這些容器也可以放在任意個數機器上。並且支持分布式的事務協議，允許Enterprise beans的分別裁定。允許部分的配置你的應用，而將你的性能配置成最優化。
Inprise 的EJB是建立在Vbroker和RMI—IIOP之上的。
EJB容器是建立在Inprise的Vbbroker之上的。VisBroker是已經被證明的在各種條件下都是ORB的領導角色。無論在各大公司的聯合測試下，或者在實際的應用環境中。VisiBroker提供了一個很好的的運行時的任務的完成。
為了更好的性能，Vbroker使用了大量的運行時優化，高級的多路鏈接，鏈接池和管理，線程池和管理。
客戶和Enterprise beans,Enterprise benas之間，Enterprise beans 和其它的CORBA對象之間的通信都是通過用VisiBroker的IIOP方式進行的。VisiBroker完全適應CORBA2。3規范，RMI— IIOP通過值傳遞的方式來實現。這意味着，復雜的JAVA數據類型能夠用新的IDL值類型寫到IIOP里面去。就象在CORBA2。3規范中一樣。數據和服務之間相互協調怎樣傳送復雜的數據類型是很重要的。否則，協同能力就會受到危及。EJB容器能夠與其他的所有支持RMI-over-IIOP的進行協同工作。
安全特性是可由VisiBroker所有的。保證信用是從客戶傳象服務。
事務上下文也是由visibroker所有的。保證當CORBA客戶開始一個事務時，並且訪問EJB容器的服務時。事務上下文被傳向服務，當服務需要調用環境中的各項資源時，就要使用事務上下文。
事務的兩段提交是由Inprise的ITS管理的。如果JDBC支持兩階段提交協議，EJB就支持兩階段提交協議。當時，如果JDBC不支持兩階段提交，兩階段提交就不能被完成。
Enterprise的EJB容器是一個CORBA對象：
Inprise 的java2iiop編譯器和EJB容器一樣，都是與CORBA兼容的。EJB容器能夠理解RMI調用，但是，它用IDL來存放接口定義。雖然 Java2iiop編譯器從java接口產生了stub 和skeleton.也能夠從java接口中產生IDL。然后在其他語言里面用。對於一個CORBA客戶端，EJB容器是一個CORBA服務，EJB容器工具就是與控制EJB的功能相同的CORBA工具。
EJB容器是建立在JNDI和CosNaming，JTS/OTS基礎山的。他們都是完全支持CORBA的。
容器對不同的Enterprise beans 的支持：
EJB容器的主要的特征就是它提供對各種各樣的Enterprise beans的管理和支持。包括：
有狀態或無狀態的Session Enterprise beans.
Entiry beans包括container-manager和beans-manager的持續性。
EJB容器可以包括一個或多個的jar文件。每一個jar文件又能夠包括多個的Enterprise beans。每個Enterprise bean都包括一個配置描述器。一個EJBhome接口，一個EJBremote接口，還有Enterprise bean的實現代碼。
使Inprise 的EJB容器不同的是：它支持許多當前的客戶，包括如下兩個方面：
VisiBroler提供了連接管理，允許一個服務同時支持比TCP連接數多的客戶連接。用最近最少使用算法來關閉連接。
對於客戶來說，容器本身是無狀態的。意味着容器並沒有為每一個新的Enterprise bean會話分配內存。這樣，容器就能夠支持任意多的無狀態的Session Enterprise beans.
配置的支持：
Inprise 容器提供了產生代碼的編譯器。也提供了一個驗證的工具來在配置之前檢查你的Enterprise beans.支持EJB1。1的JNDI命名基於XML的配置描述器。
事務管理者：
事務管理者提供了事務管理的手段。包括分布式的兩段提交的支持。遵從最新的SUN公司JTS規范。也支持最新的OMG的OTS規范。在開發時盡量少用JTS而在配置時使用健壯的ITS。
JDBC鏈接池和事務綜合：
所有JDBC訪問數據庫都是通過DataSource對象的實現來完成的。DataSource對象與數據庫的池鏈接還有JTS管理的全局的事務處理和用JDBC管理的數據庫事務處理。
命名服務：
命名服務提供了分布式的命名管理。服務遵從JAVA的命名和目錄規范（JNDS）。也遵從OMG的cosNaming規范。與事務服務類似，在配置的時候，你可以用JNS，也可以用更健壯的INS。JNDI提供的容器能夠運行在其他的JNDI實現之上。這樣就能夠使用其他的命名服務，例如：LDAP。
安全性的支持：
在CORBA之上的Inprise 的安全服務是附加的。
JAVA數據庫：
Java數據庫提供了一個全關系型的高性能的數據庫來存儲Enterprise beans的狀態。
JAVA數據庫既可以運行在同一個進程的容器中，或者，為了提高性能，也可以運行在一個單獨的進程中。實際上，JAVA 數據庫是即插即用的。意味着終端用戶能夠用一個另外的實現就取代了所有的JAVA版本。例如，能夠實現一個用別的數據庫來存儲會話狀態和Entiry Data的后台存儲。
容器管理的Entity beans的持久性：
Inprise 提供了一個CMP（Container-Managed Persistence）引擎來提供透明的對象關系映射和在純JDBC上的持續框架。更進一步，第三方的工具可以通過開放的API插進來。
EJB與其他組件的結合：
在配置環境的真實世界里，EJB的四個模式能夠與以下的組件工作在一起：
client鏈接到Enterprise beans對象。Clients可以由java Enterprise bean接口的EJB對象，或者IDL接口的CORBA對象。在Inprise 的EJB容器服務中，每一個Enterprise bean都同時是EJB對象也是CORBA對象。CORBA客戶能夠用所有支持CORBA的語言來實現，包括C++，Java,Delphi.
從Enterprise bean的數據庫訪問。典型的，Enterprise beans對象是Entity beans對象，或者是beans-managed,或者是container-managed.
后端服務：CORBA服務，用C++，Java ,Delphi實現，運行在任何兼容CORBA的ORB中。EJB服務，包括所有其他的inprise的服務，或者其他支持IIOP的代理商的服務。其它原來的服務，包括ERP系統，main-frame程序。等等。
轉：https://blog.csdn.net/holandstone/article/details/21003053