Enterprise JavaBeans 體系結構將處理企業應用程序生命周期中的開發、部署和運行等方面。


Enterprise JavaBeans 體系結構將定義一些約定，這些約定使多個供應商提供的工具能夠開發并部署可在運行時互操作的組件。


Enterprise JavaBeans 體系結構將與現有的服務器平臺兼容。供應商將能夠擴展它們的現有產品，以支持 Enterprise JavaBeans 組件。


Enterprise JavaBeans 體系結構將與 Java 編程語言編寫的其他 API 兼容。


Enterprise JavaBeans 體系結構將提供 EJB 組件和非 Java 編程語言應用程序之間的互操作性。


Enterprise JavaBeans 體系結構將與 CORBA 兼容。
使用 EJB 技術的好處 
這些設計目標會使企業和開發人員得到什么好處呢？下面列出了可望從采用 Enterprise JavaBeans 環境獲得的好處：

EJB 組件使編寫應用程序更為簡單。盡管 EJB 體系結構復雜，但應用程序開發人員一般都不必再編寫用于訪問系統服務的代碼。一種稱為 EJB 容器的系統組件使系統服務可用于 EJB 組件的任務。

服務器端商務邏輯可以移植。除了 Java 語言固有的可移植性外，EJB 體系結構還在 bean 和支持該 bean 的容器之間提供了一套標準化的應用程序編程接口。這使開發人員能夠將 bean 從一種操作環境移植到另一種操作環境，而無須重新編寫其源代碼。

可以從現有的軟件組件裝配出服務器端應用程序，這與從現有的 Java bean 可以裝配出客戶端應用程序一樣，從而使軟件能夠重用。

EJB 體系結構內置了對典型企業級系統服務的支持，包括分布式對象、事務處理、數據庫、安全和全局命名。

多家 IT 供應商都采納 EJB 體系結構，這是由于有這樣的承諾：客戶將能夠從選定的供應商那里選購軟件組件，如 EJB 組件、容器及 EJB 服務器；也由于承諾了不同供應商的產品，只要符合 EJB 體系結構，就都是可互操作的。

用 EJB 組件構建的應用程序可以從一個服務器移植到另一個服務器，從而支持可伸縮性，這是因為在 EJB 模型中，各個軟件組件都是嚴格分離的。

EJB 體系結構能保障原有的 IT 投資，這是通過允許將現有的信息系統和資產“包裹”在這些應用程序中，而不要求客戶更換現有技術。事實上，在關系數據庫中存儲數據的企業已經有了一套已有雛形的實體 bean，正等著通過 EJB 外殼去訪問。

進一步考察 JNDI 
Enterprise JavaBeans 組件使用 Java Naming and Directory Interface (JNDI) 來訪問各種目錄服務。JNDI 分兩部分：應用程序編程接口 (API) 和服務供應商接口 (SPI)：


“JNDI 體系結構由 JNDI API 和 JNDI SPI 組成。JNDI API 允許 Java 應用程序訪問各種命名和目錄服務。JNDI SPI 則是設計來供任意一種服務的供應商（也包括目錄服務供應商）使用。這使得各種各樣的目錄服務和命名服務能夠透明地插入到使用 JNDI API 的 Java 應用程序中。（見 JavaSoft，“JNDI: Java Naming and Directory Interface”）

JNDI API 并不同某種專用的命名技術或目錄技術連在一起，也不同任何供應商的目錄服務連在一起，因此它對 EJB 組件的可移植性有所貢獻。例如，客戶可以從多種不同的技術中選擇，來為其 EJB 應用程序提供目錄服務，這些技術包括：

LDAP：Sun 的 LDAP 服務供應商支持 LDAP 協議的第 2 版和第 3 版。 
NIS：Sun 提供一個 NIS 服務供應商（NIS 即網絡信息服務，以前稱為黃頁）。 
COS 命名：Sun 的 COS 命名服務供應商提供對 CORBA 命名服務的訪問。 
文件系統：Sun 提供一個服務供應商來訪問文件系統。 
RMI 注冊：Sun 為 RMI 注冊提供一個服務供應商。 
Novell：有幾個服務供應商可提供對目錄服務 NDS 的訪問以及 NetWare 3X 連接庫、Novell 文件系統和其他 Novell 服務（如擴展 NCP）的訪問。 
雖然 JNDI 規范對供應商是中立的，但不應認為，實現 JNDI 接口的應用程序服務器一定要能訪問來自多個供應商的服務供應商代碼。

JNDI 命名體系結構的關鍵概念包括： 

對象和名稱之間的綁定。 
若干稱為命名上下文的綁定集。 
命名系統，即若干組命名上下文。 
命名空間，指一個命名系統中的所有名稱。 
名稱分類為原子名稱、復合名稱和合成名稱。原子名稱是不可分割的，可以綁定到一個對象上。復合名稱是原子名稱的組合，而合成名稱則跨越多個命名系統。

命名上下文特別重要：所有的命名操作均是在上下文對象上進行的，并且名稱解析過程總是從最初的命名上下文開始。

EJB 應用程序是如何使用 JNDI 的呢？JNDI 的主要用途是檢索對 EJB 組件的引用。因為 EJB 框架是一個分布式對象框架，所以 EJB 應用程序不應當假定 EJB 組件的位置。JNDI 就是獲取對 bean 的起始引用的一種機制。當一個 bean 安裝到一個 enterprise bean 服務器上時，一個被稱為 EJB 容器的軟件組件就負責創建各個名稱-對象綁定，使所需的 Java 類文件能使用這個 bean。應用程序使用 JNDI 的查找方法來檢索對象引用，如下例所示：

Context initialContext = new InitialContext( );
CartHome cartHome = javax.rmi.PortableRemoteObject.narrow( 
initialContext.lookup("applications/shopping_cart"), CartHome.class);
 

應用程序有責任知道外部名稱，應用程序就是通過這個名稱才得以引用一個 enterprise bean，并通過 JNDI 來獲取對該 bean 的引用的。

進一步考察 JTA 
除 JNDI 以外，Enterprise JavaBeans 體系結構還使用 Java Transaction API (JTA)。因為事務對維護數據完整性和可靠性很重要，所以支持事務處理是 EJB 體系結構的一個基本部分。如果企業應用程序是分布式的，事務處理就會更加重要：


“事務的概念是一個重要的編程范例，其目的在于簡化既要求可靠性又要求可用性的應用程序結構，特別是那些需要同時訪問共享數據的應用程序。事務的概念最早是用在商務運作的應用程序中，其中它被用于保護集中式數據庫中的數據。后來，事務的概念已擴展到分布式計算的更廣泛的環境中。今天，事務是構建可靠的分布式應用程序的關鍵，這一點已得到廣泛承認。”（見對象管理組的“Transaction Service Specification”）

有時將事務描述為具有下列特征的工作單元： 

原子性 — 如果因故障而中斷，所有結果均撤銷 
一致性 — 事務的結果保留不變的特性 
孤立性 — 中間狀態對其他事務是不可見的 
持久性 — 已完成的事務的結果是持久的 
事務的終止有兩種方式：提交一個事務會使其所有的更改永久不變，而回滾 (rolling back) 一個事務則撤銷其所有的更改。

對象管理組織 (OMG) 為一種面向對象的事務服務，即對象事務服務 (OTS)，創建了一種規范。OTS 是 EJB 體系結構內的事務服務的基礎。下列事務規范就是為 enterprise bean 所采用的事務模型而設：

OMG 的對象事務服務 (OTS) 
Sun Microsystems 的 Transaction Service (JTS) 
Sun Microsystems 的 Java Transaction API (JTA) 
開放組 (X/Open) 的 XA 接口
這種與語言無關的對象事務服務，為一個強健的分布式事務服務提供了基本概念、定義和功能。

Java Transaction Service 是 OTS 的 Java 映射，在 org.omg.CosTransactions 和 org.omg.CosTSPortability 這兩個包中定義。JTS 對事務分界和事務環境的傳播之類的服務提供支持。JTS 功能由應用程序通過 Java Transaction API 訪問。 

Java Transaction API 指定事務管理器與分布式事務中涉及的其他系統組件之間的各種高級接口，這些系統組件有應用程序、應用程序服務器和資源管理器等。JTA 功能允許事務由應用程序本身、由應用程序服務器或由一個外部事務管理器來管理。JTA 接口包含在 javax.transaction 和 javax.transaction.xa 這兩個包中。

XA 接口定義了資源管理器和分布式事務環境中外部事務管理器之間的約定。外部事務管理器可以跨多個資源協調事務。XA 的 Java 映射包含在 Java Transaction API 中。