什麼是 EJB 組件？EJB 組件是為企業級應用設計的 Java 組件模型。
EJB 組件是基於標准分布式對象技術、CORBA 和 RMI 的服務器端 java 組件。EJB 組件總是分布式的，這是它們與標准 JavaBeans 組件最根本的區別。
EJB 組件提供了應用的商務邏輯部分。由於它們不涉及表示層的問題，因此必須與其它的顯示技術(如 servlets)，服務於 Html 客戶端的 JSP 技術，或者使用了諸如 AWT、Swing 技術的 Java 應用一起使用。
實現了 EJB 規范的應用服務器提供了可以解決安全性、資源共享、持續運行、並行處理、事務完整性等復雜問題的服務，從而簡化了商業應用系統。
Sun 公司制定的 EJB 組件模型要求 EJB 組件運行於 EJB 服務器(通常稱為應用服務器)的環境下。我們的示例中使用了高級版 WebSphere 應用服務器，但所討論的功能適用於大多數 EJB 服務器。
需要考慮的技術問題
當你在決定 EJB 組件是否為適合你的實際情況的合適技術時，不妨先考慮幾個問題。如果你對所有這些問題的回答都是肯定的話，那麼 EJB 組件就是你可以采用的合適技術。反之的話，別的技術可能更適合。
你需要將商務邏輯組件與面向外界的 Internet 隔離開嗎？
許多公司認為他們的應用軟件，特別是構成商務邏輯的一些標准和數據結構，是極為重要的公司財產(例如，公司所擁有的分析應用工具構成了股票交易網站的一部分)。允許外人訪問這些屬於公司資產的原碼和目標碼將對公司產生極大的危害。因此，這些公司十分需要將商務邏輯置於一套安全防火牆後面(通常稱為無戒備區，也稱 DMZ)。
在這種情況下，分布式對象組件體系結構(例如 EJB 技術)允許你將有價值的公司資產隔離到 DMZ 以內，同時表示層代碼可以訪問 DMZ 內的 EJB 服務器。下圖描述了這種分布式解決方案：
防火牆內部的 EJB
這裡我們假設表示層邏輯不如後台的商務邏輯重要。如果不是這樣，那麼這種方案的安全性就要下降，整個系統可能都需要置於 DMZ 之內。如果整個應用必須(或者能夠)置於第二層防火牆後面，那麼選擇其它技術(如通過 Java Servlets 發出 JDBC 請求來直接訪問數據庫)就顯得更合理。
這種解決方案也有一些效率方面的缺陷。例如在安裝 WebSphere 時，如果你將客戶端(servlets 與 JSP文件)與圖示的位於另一個 Java 虛擬機(JVM)中的 EJB 組件分隔開，這種選擇將降低整體性能。與客戶端和 EJB 組件位於同一個 JVM 中的情況相比，這種方式下每一個需要經過防火牆的請求都將增加20%的耗時。
你需要不止一種類型的客戶端訪問共享數據嗎？
通常，一個應用會有多種類型、需要訪問相同信息的客戶端。例如，一個應用可能會有供外部客戶訪問的基於 web 的 Html 前端，以及供內部人員使用的更完整的應用前端。通常，這個問題是通過為同一應用編寫兩個共享相同數據源(數據庫表)的版本來解決的。但是，這種方法效率不高，無論是從編程時間還是從同時發生多個數據庫鎖定時數據庫的利用率來說。
EJB 技術的解決方案是將共享數據和商務邏輯集成到一套 EJB 組件中，以供不同類型的客戶端(如 servlet/Html 和 application)訪問。EJB 組件控制著對後台數據的訪問，並管理著當前事務以及數據庫的內部鎖定。通過去除應用中的重復代碼，減少編寫數據庫控制邏輯的工作，這種方案降低了總的編程量。
在這個領域還有其它一些解決方案--比如，java 應用可以通過 HTTP 訪問 java servlets，同時浏覽器也可以通過 HTTP 訪問 java servlets。這些解決方案的問題在於：如果 servlet 是用來在浏覽器中顯示信息的，它就必須包含一些表示層邏輯，這些表示層邏輯對於向另一個程序傳遞信息來說是多余的。因此，你最終不得不采用兩套部分重復的 servlets 來處理兩種情況。此外，HTTP 不是程序間通訊的效率最高的協議。你必須設計能通過 HTTP 管道進行程序間信息傳遞的數據格式--這通常或者是基於文本的格式，比如 XML（由接收端進行解析，由發送端生成），或者是基於對象的格式，比如 Java 序列化。兩種格式都需要大量的編程工作，它們都不如本地的 IIOP 速度快。
你是否需要對共享數據同時進行讀和寫操作？
通常，"胖客戶端"解決方案要求應用在數據庫級別上管理對共享數據的訪問。其結果是：處理數據庫鎖定與同步的方案非常復雜，若不考慮數據庫鎖定與同步問題又會失去數據的完整性。
EJB 技術能自動處理這些復雜的共享數據同步問題。正如前面提到的那樣，EJB 組件控制著對後台數據的訪問，並管理著當前事務和數據庫的內部鎖定。這不僅省去了編寫數據庫控制邏輯的工作量，同時也保證了數據的一致性與正確性，從而降低了總的編程量。
你需要訪問具備事務處理功能的多個異構數據源嗎？
許多應用需要訪問多個數據源。例如，一個應用程序可能既要訪問來自中間層的 Oracle 數據庫，又要通過中間件(如 MQSerIEs)訪問 CICS、IMS 等大型主機系統。問題的關鍵是一些應用要求這種訪問是完全事務化的，並且數據完整性在不同數據源間也能得到保證。例如，某個應用可能要求在處理用戶的訂購信息時，既要在 Oracle 數據庫中存儲詳細的訂購信息，同時又通過 MQSerIEs 在 CICS 系統中存儲一份出貨訂單。無論是數據庫更新或是 MQ 隊列產生錯誤，整個事務都應被取消。
過去，構建這樣的系統的唯一選擇是采用事務監視器，例如 Encina、CICS、Tuxedo，它們使用非標准接口並需要用 COBOL、C、C++ 等語言進行開發。例如，高級版 WebSphere 中的 EJB 容器支持多個並發的事務，具備在多個 DB2 數據源間進行完整的事務提交及事務取消的能力，這些都是在一個完全支持二狀態事務提交的環境中進行的。目前，WebSphere 對其它數據源(如 Oracle, MQSerIEs 和 CICS)只支持單狀態的事務提交。企業版 WebSphere 中的 EJB 容器能對更多的數據源支持二狀態的事務提交。
大多數容器正在支持各種數據源下的二狀態事務提交方面不斷完善。隨著時間的推移，我們將在這一領域看到不斷的進步。
你需要能與 Html 文檔、servlets、JSP 文件、客戶端登錄安全性無縫集成的方法級對象安全性嗎？
某些類型的應用由於其安全性限制，使得以前它們很難通過 Java 應用來實現。例如，某些保險業的應用程序為了滿足管理規定的要求，必須限制對客戶數據的訪問。直到 EJB 技術出現後，才能夠限制特定用戶訪問某個對象或方法。在這之前，可實施的辦法只有：在數據庫級別上限制訪問，並捕獲在 JDBC 層次上拋出的錯誤；或者通過客戶安全密碼在應用層上限制訪問。
EJB 技術可以在任何 EJB 組件或方法上實施方法級的安全策略。創建的用戶和用戶組可以被授予或禁止對任何 EJB 組件或方法的操作權。在 WebSphere 中，用戶組可以被授予或禁止對 web 資源(servlets, JSP 文件和 Html 頁面)的訪問權，用戶的 ID 可以通過底層的安全機制被安全地從 web 資源傳遞到 EJB 組件。
體系結構是否有標准化、輕量化、組件化的需要呢？
對於許多有遠見的公司來說，關鍵問題是要實現平台、銷售商和應用服務器設備間的相互獨立。符合工業標准的 EJB 組件體系結構有助於實現這些目標。為 WebSphere 開發的 EJB 組件通常可以發布到其它類型的應用服務器上使用，反之亦然。盡管這一目標尚未完全實現，但它已成為許多客戶選擇的戰略發展方向。從短期看，利用一些可能優於標准化的特性會更方便、更迅速，但從長遠看標准化具有最大的好處。
你也應當考慮到越來越多的可選工具和 EJB 標准的優化實現手段，這些都是你無法從本地管理對象框架中獲得的。由於大多數公司並不從事中間件業務，將注意力集中在與你的業務更直接相關的活動上會更有效。
你需要多個服務器來滿足系統的吞吐量和有效性需要嗎？
胖客戶端系統顯然不能適應 web 系統可能擁有的成千上萬個用戶。軟件發布方面的問題也要求給胖客戶端減肥。Web 站點的24小時不間斷運行特點也使得時間成為關鍵問題。但並不是每個人都需要24小時不間斷運行，並能同時處理上萬個用戶的系統。你應當能設計這樣的系統：在不增加開發和標准化難度的前提下，實現系統的伸縮性。
因此，你要設法使得編寫的商務邏輯可以進行伸縮來滿足這些需要。EJB 技術為構建這種具有高伸縮性、高利用率的系統提供了骨架。例如，WebSphere 通過以下一些特性幫助開發者構建這類系統。這些特性也適用於其它的 EJB 服務器：
對象緩存與共享。WebSphere 自動在服務器層面上共享無狀態會話 EJB 組件，從而減少了用於創建對象和回收碎片的時間。這將使得更多的處理時間周期可以分配給真正的實際工作。
服務器端的工作量優化。WebSphere 還使得 EJB 服務器具備群管理的特點。在 WebSphere 應用服務器上，你可以創建跨越多個節點的服務器組。除此之外，你可以創建模型(服務器的抽象表述)，並把它們克隆到多個 JVM 中。你可以將克隆的模型配置成運行於組內的任何一台服務器上。另外，一個服務器的多個克隆模型也能運行與一台機子上，充分利用了多處理器的結構特點。同樣，你也可以把所有克隆的模型作為一個組來管理。這就提高了可靠性，避免了個別地方故障時對應用服務器的破壞。
通過克隆可支持自動故障恢復。由於有幾個克隆的服務器可以用來處理請求，故障不太可能破壞系統的吞吐量和可靠性。由於多個節點運行相同的服務，一台整機的故障就不會產生災難性的後果。
所有這些特性都不需要對系統進行特殊的編程。利用這種可伸縮性也無需改動服務器端的代碼。
