Enterprise JavaBean有大量的設計命名約定。這樣的編程體系結構雖然有一定的限制。這樣的話，雖然還沒有應用程序，但為EJB服務器和容器提供了虛擬的應用程序。

可以通過三種途徑來建立一個基于對象的，多層體系結構的分布式系統，每種模式都定義了一些接口和命名約定。

1. 無狀態服務途徑（無狀態會話Bean：stateless Session Bean）。

無狀態的服務途徑是通過Bean對象的操作向客戶提供一種功能函數。但不保持會話的狀態。當客戶使用無狀態的Bean對象時，客戶無法提供上一次操作的信息。

2. 基于會話途徑（有狀態會話Bean：stateful Session Bean）

基于會話途徑產生了一個中間層的對象，稱為會話（Session）。這個會話可以看成是客戶的代理。會話（Session）的生命是由客戶和所在的服務程序共同決定的。會話完成后，客戶就可以把會話對象刪除。或者服務終止，會話對象將會超時。對象變成無效狀態。

3. 持續對象途徑（實體Bean：Entity Bean）

持續對象設計模式是將Enterprise Bean與存儲數據庫中的一塊數據綁定。提供了操作這塊數據的一些方法。持續對象由多個客戶共享的。其生命期是由存儲數據的數據庫決定的。

EJB的底層結構（Enterprise JavaBeans infrastruct）

容器（Container）和服務提供者（Server Provider）實現了EJB的底層結構。底層結構處理EJB的分布式任務，事務處理，安全性方面的功能。EJB規范定義了底層結構和Java API適應各種情況的要求。沒有去指定用什么技術，平臺或協議來實現。

Enterprise beans, 容器（container）,服務器（server）展示了EJB底層結構的要求，EJB底層結構必須提供客戶和Enterprise beans通信的通道。雖然EJB規范沒有規定，但保證通道的安全也是很重要的。特別是當客戶通過internet訪問遠程的Enterprise beans時，通信安全尤其重要。EJB底成結構也必須能夠對加強Enterprise beans 的訪問控制。

必須保證Enterprise beans所有數據的持久性。EJB的底層結構必須提供在企業級的計算環境中與現存系統的相結合能力。Beans的所有的通信都是分布式事務的一部分，需要由EJB底層結構來管理。對于一個的配置，EJB底層必須對提供鉤子（hooks）來管理分 接τ謾?/p>

容器（Container）

容器是EJB里面最重要的概念。因為它最大程度的向程序開發人員提供了方便。通過提供對象定位機制，數據重組機制等，基于對象的中間層軟件平臺如CORBA或者遠過程調用RMI是把程序開發人員從網絡傳輸中解放出來。容器的概念則更進一步，簡化了分布式應用程序那些復雜的方面，如：安全性，事務協調性，數據持久性等。

一旦Enterprise Beans準備好可以配置了。就將Enterprise Bean打包成一個標準的JAVA文件（ejb-jar文件）。一個ejb-jar文件可以包含一個或多個的Enterprise Beans。對每一個Enterprise bean，都由它自己的接口，類，和配置描述器。

Enterprise Bean提供者（Enterprise Beans Provider）提供如下信息給ejb-jar 文件：

1. Enterprise Beans 的遠程接口，遠程接口說明了客戶端能調用的函數。
2. Enterprise Beans 的本地接口，本地接口定義了使客戶生成和定位一個Enterprise Beans的實例的方法。
3. Enterprise 類本身，實現了Enterprise beans 的語義。
4. Deploy Descripor配置描述器，配置器通過利用配置描述器來提供沒有在源代碼中聲明的信息。例如方針和屬性。EJB的1.0規范把配置描述器定義為javax.ejb.deployment，SessionDescriptor類或者javax.ejb.deployment.EntityDescriptor類的一個實例，但是在1.1版本中不這樣做。而是用XML來定義配置描述器。

配置一個Enterprise Bean 就是將一個Enterprise Bean安裝到容器中去。安裝過程包括了如下幾個方面：

1. 保證不同的Enterprise beans能夠協同在一起工作。
2. 用名字服務來注冊一個Enterprise Bean
3. 通過EJB服務的通信系統提供訪問EJB的入口。
4. 執行事務管理和安全方針。

在一個EJB容器中可以又任意多個Enterprise beans。除了安裝和執行以外，容器還提供了配置Enterprise beans的工具。

為什么要使用Inprise的EJB 容器？

Inprise EJB容器提供了如下的完全服務：

1. 完全支持EJB1。1規范。
2. 一個有效的運行和管理EJBs的容器。
3. 提供命名服務，事務服務，植入Java RDBMS的內部。編程，配置簡單。
4. 充分的例子來演示怎樣使用EJBs和EJB容器。

對于Enterprise beans的開發者來說，EJB 容器是一個高級Enterprise類產品。它有如下優點：

完整的，靈活的運行時環境：

1. EJB容器完全實現了EJB1。1的規范，包括了它的所有功能。
2. 每一個由Inprise提供的工具產生的Enterprise bean都既是Enterprise bean 對象又是CORBA對象。
3. EJB容器能夠進行單獨配置，100%的純JAVA的服務。也可以作為完全的分布式的配置。這樣的靈活性意味著你能夠根據你的要求調整你的應用程序。
4. 與其它的EJB服務不一樣，Inprise 的EJB容器服務并沒有限制一定要分開。可以將任意個數的Enterprise beans放在任意個數的容器中，這些容器也可以放在任意個數主機上。并且支持分布式的事務協議，允許Enterprise beans的分別裁定。允許先部分的配置你的應用程序。而達到最優化的配置性能。

Inprise 的EJB是建立在Visibroker和RMI—IIOP之上的。

1. EJB容器是建立在Inprise的Visibroker之上的。VisiBroker已經被證明的在各種條件下都是ORB的領導角色。無論在各大公司的聯合測試下，或者在實際的應用環境中。VisiBroker都提供了一個很好的的運行時性能。
2. 為了更好的性能，Visibroker使用了大量的運行時優化，高級的多路鏈接，鏈接池管理，線程池管理。
3. 客戶和Enterprise beans，多個Enterprise benas之間，Enterprise beans 和其它的CORBA對象之間的通信都是通過用VisiBroker的IIOP方式進行的。VisiBroker完全支持CORBA2.3規范，RMI—IIOP通過值傳遞的方式來實現。這意味著，就象在CORBA2.3規范中一樣，復雜的Java數據類型能夠用新的IDL值類型寫到IIOP里面去。數據和服務之間怎樣相互協調傳送復雜的數據類型是很重要的。否則，就會危及協同能力。EJB容器能夠與其他所有支持RMI-over-IIOP協議的對象的進行協同工作。
4. 安全特性是由VisiBroker所有的。保證信用是從客戶傳向服務。
5. 事務上下文也是由Visibroker所有。保證當CORBA客戶開始一個事務時或者訪問EJB容器的服務時，把事務上下文傳向服務。當服務需要調用環境中的各項資源時，就要使用到事務上下文。
6. 事務的兩階段提交是由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的管理和支持。包括：

1. 有狀態或無狀態的會話 Enterprise beans。
2. 實體beans。包括容器管理持久性（container-manager）和Bean管理（beans-manager）的持久性。

EJB容器可以包括一個或多個的jar文件。每一個jar文件又能夠包括多個的Enterprise beans。每個Enterprise bean都包含一個配置描述器，一個本地（EBJHome）接口，一個遠程（EJBremote）接口和還有Enterprise bean的實現代碼。

Inprise 的EJB容器支持多個當前客戶，包括如下兩個方面：

1. VisiBroker提供了連接管理，允許一個服務同時支持多于TCP連接數的客戶連接。用最近最少使用算法來關閉連接。
2. 對于客戶來說，容器本身是無狀態的。意味著容器并沒有為每一個新的Enterprise bean會話分配內存。這樣，容器就能夠支持任意多的無狀態的會話Enterprise beans。

支持配置：

Inprise 容器提供了產生代碼的編譯器。也提供了一個驗證的工具，用來在配置之前檢查Enterprise beans支持EJB1.1的JNDI命名是否是基于XML的配置描述器。

事務管理者：

事務管理者提供了事務管理的手段。包括分布式的兩段提交協議的支持。遵從最新的SUN公司JTS規范。也支持最新的OMG的OTS規范。在開發時盡量少用JTS而在配置時使用相對健壯的ITS。

JDBC鏈接池和事務綜合：

所有JDBC訪問數據庫都是通過DataSource對象的實現來完成的。

命名服務：

命名服務提供了分布式的命名管理。命名服務遵從Java的命名和目錄規范（JNDS）。也遵從OMG的cosNaming規范。與事務服務類似，在配置的時候，你可以使用JNS，也可以用更健壯的INS。JNDI提供的容器能夠運行在其他的JNDI實現之上。這樣就能夠使用其他的命名服務（例如：LDAP）。

安全性的支持：

在CORBA之上的Inprise 的安全服務是附加上去的。

Java數據庫：

Java數據庫提供了一個全關系型的高性能的數據庫來存儲Enterprise beans的狀態。Java數據庫可以運行在同一個進程容器中。為了提高性能，也可以運行在一個單獨的進程中。實際上，Java 數據庫是即插即用的。意味著終端用戶能夠用一個另外的實現就取代了所有的JAVA版本。例如，能夠實現一個用別的數據庫來存儲會話狀態和實體數據的后臺存儲。

容器管理的Entity beans的持久性：

Inprise 提供了一個容器管理持久性（Container-Managed Persistence）引擎來提供透明的對象關系映射以及在純JDBC上的持久性框架。進一步，第三方的工具可以通過開放的API插進來。

與其他組件的結合：

在配置環境的真實條件里，EJB的四個模式能夠與以下的組件工作在一起：

1. 客戶鏈接到Enterprise beans對象組件。客戶可以是有java Enterprise bean接口的EJB對象，或者有IDL接口的CORBA對象。在Inprise 的EJB容器服務中，每一個Enterprise bean都同時是EJB對象也是CORBA對象。CORBA客戶能夠用所有支持CORBA的程序設計語言來實現，包括C++，Java，Delphi。
2. 從Enterprise bean的數據庫訪問組件。Enterprise beans對象是容器管理（container-managed）或者Bean管理（beans-managed）的實體bean對象。
3. 后端服務：CORBA服務，用C++，Java或Delphi實現，運行在任何兼容CORBA的ORB中。EJB服務，包括所有其他的Inprise的服務，或者其他支持IIOP的代理商的服務。系統原來的服務，包括ERP系統，main-frame程序等等。

下篇介紹：介紹了Inprise EJB系統所帶的一些例子，運行這些例子的參數。