使用 EJB 組件你需要了解些什么呢？
什么是 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 組件通�？梢园l布到其它類型的應用服務器上使用，反之亦然。盡管這一目標尚未完全實現，但它已成為許多客戶選擇的戰略發展方向。從短期看，利用一些可能優于標準化的特性會更方便、更迅速，但從長遠看標準化具有最大的好處。

你也應當考慮到越來越多的可選工具和 EJB 標準的優化實現手段，這些都是你無法從本地管理對象框架中獲得的。由于大多數公司并不從事中間件業務，將注意力集中在與你的業務更直接相關的活動上會更有效。


你需要多個服務器來滿足系統的吞吐量和有效性需要嗎？
胖客戶端系統顯然不能適應 web 系統可能擁有的成千上萬個用戶。軟件發布方面的問題也要求給胖客戶端減肥。Web 站點的24小時不間斷運行特點也使得時間成為關鍵問題。但并不是每個人都需要24小時不間斷運行，并能同時處理上萬個用戶的系統。你應當能設計這樣的系統：在不增加開發和標準化難度的前提下，實現系統的伸縮性。

因此，你要設法使得編寫的商務邏輯可以進行伸縮來滿足這些需要。EJB 技術為構建這種具有高伸縮性、高利用率的系統提供了骨架。例如，WebSphere 通過以下一些特性幫助開發者構建這類系統。這些特性也適用于其它的 EJB 服務器：

對象緩存與共享。WebSphere 自動在服務器層面上共享無狀態會話 EJB 組件，從而減少了用于創建對象和回收碎片的時間。這將使得更多的處理時間周期可以分配給真正的實際工作。
服務器端的工作量優化。WebSphere 還使得 EJB 服務器具備群管理的特點。在 WebSphere 應用服務器上，你可以創建跨越多個節點的服務器組。除此之外，你可以創建模型(服務器的抽象表述)，并把它們克隆到多個 JVM 中。你可以將克隆的模型配置成運行于組內的任何一臺服務器上。另外，一個服務器的多個克隆模型也能運行與一臺機子上，充分利用了多處理器的結構特點。同樣，你也可以把所有克隆的模型作為一個組來管理。這就提高了可靠性，避免了個別地方故障時對應用服務器的破壞。
通過克隆可支持自動故障恢復。由于有幾個克隆的服務器可以用來處理請求，故障不太可能破壞系統的吞吐量和可靠性。由于多個節點運行相同的服務，一臺整機的故障就不會產生災難性的后果。
所有這些特性都不需要對系統進行特殊的編程。利用這種可伸縮性也無需改動服務器端的代碼。

WebSphere 支持其它服務器端 java 技術(如 java servlets，JSP文件)的發布、克隆和自動故障恢復。但是，這些更面向表示層的技術與其說是 EJB 組件的競爭對手，不如說是對其的補充。當總體時間和可伸縮性是問題的關鍵時，整體解決方案中應包括 EJB 組件。


關于兩個方案的描述，或者說是關于正確使用 EJB 組件的描述
現在你已經了解了一些評估一個應用是否適合使用 EJB 技術的辦法，下面我們來比較兩個使用了 EJB 組件的應用，看看 EJB 技術究竟是幫助還是阻礙了開發者達到目標。在一個例子中 EJB 組件的正確使用使得代碼更簡潔、更易懂。在另一個例子中，使用 EJB 組件使得系統過于復雜，性能也不好。

這兩個應用都是綜合了多個其它應用的例子，而不是來自于某個單一的公司或方案小組。

一個使用 EJB 技術失敗的例子
作為一個被授權評估新技術的高級技術小組的成員，某個方案小組最初設計了這個方案。該方案具有如下體系結構(每個方框代表運行于各自硬件上的不同程序)：

不可取的 EJB 體系結構


該體系結構的一些具體設計使得 EJB 組件的使用不如它初看起來那么有吸引力：

應用的主體部分是信息的顯示，這部分由 java servlets 實現。EJB 組件只用來獲取、更新數據。
方案小組在后臺主機的事務處理中使用的數據連接不包括遵從擴充體系結構(XA)標準的數據源。事務不能被成批取消或提交，對每個主機的訪問都是一個獨立的請求。
由于不能區分用戶是來自 web 還是來自后臺主機，EJB 技術的安全特性在此沒有得到利用。
servlet 對 EJB 組件的每一次訪問都是一個網絡請求。組件的探測方法和 ejbLoad() 方法的內部邏輯執行了真正的主機請求，但這之后 EJB 組件僅僅進行數據緩存，直到事務提交后才由 ejbStore() 方法將信息回傳給主機。直到事務提交前的每一次數據訪問和更新都導致了大量的網絡開銷。
該方案小組僅僅把 EJB 組件用作主機數據與 servlets 間的數據映射機制，這不是 EJB 技術的有效使用方法。本例中的應用沒有利用以下一些特性：

EJB 組件的事務處理特性
EJB 組件的方法級安全性
EJB 組件的伸縮性與分布式特點(該方案小組僅使用了一個 EJB 服務器)
多種類型客戶端間的商務邏輯共享
具備容器管理持久性(CMP)的 EJB 組件的自動數據映射功能

如果直接由和 java servlets 處于同一 JVM 中的 JavaBeans 組件來實現數據映射功能，系統的速度將比使用 EJB 組件快得多，同時避免了大量的網絡開銷。該系統還變得不必要的復雜(因為需要本地和遠程接口，以及分布代碼)。事實上，該方案后來被廢棄并以不使用 EJB 組件的方式進行了重新設計，其中的數據映射由一套被 servlets 使用的標準 JavaBeans 組件實現。這使得最后的系統變得更簡單、更快速。

一個成功使用EJB技術的例子
一個金融機構的方案小組設計了這套方案，最初使用了 java 和 RMI 技術。其系統體系結構如下：

RMI服務器體系結構


除了多種類型的客戶端，方案小組還在系統內構建了以下兩個框架單元，在本圖中未畫出來：

一個數據庫映射層，通過 RMI 服務器上的 JDBC 將其 Oracle 數據表映射成 java 類，或者反過來。
一個用戶安全框架單元，用于驗證來自瀏覽器或應用客戶端的用戶，并進而決定用戶是否有權進行 RMI 和數據庫請求。
由于他們的應用需求與 EJB 技術的目標緊密相連，該方案小組得以很快將其設計方案轉變為以下體系結構：


新的 EJB 體系結構


通過使用容器管理持久性(CMP)，EJB 組件使得方案小組可以拋棄數據庫映射框架，轉而利用 WebSphere 和 VisualAge for Java 中完整高效的實現機制。通過利用 EJB 技術的安全性，方案小組得以在應用中保留方法級安全性的同時，拋棄了他們的用戶安全框架。結果，由于需要維護的代碼量減少了，他們的應用變得更為簡單。

簡單地說，該應用的以下特點使得它適合使用 EJB 技術：

具有共享相同商務邏輯的多種類型客戶端
使用了事務處理
需要通過 CMP 組件來實現與對象有關的映射
需要方法級的安全性

由于系統的設計目標是通過使用與實體同時發布的會話級 EJB 組件來實現最小的網絡流量，該系統最終的體系結構很好地使用了 EJB 組件。對于前一種體系結構，由于客戶端需要發出大量的請求，很可能會增加網絡負擔，另外由于要求客戶端進行事務的啟動、提交、取消，使得系統復雜化。

總結
構建一個可能使用 EJB 組件的新系統時，做出正確決定的第一步是要懂得如何確定 EJB 技術是否適合于該應用，包括選擇 EJB 組件作為一種實現手段所帶來的正面和負面影響。

來源：IBM DW