使用 EJB 組件你需要了解些什么呢？
什么是 EJB 組件？EJB 組件是為企業(yè)級(jí)應(yīng)用設(shè)計(jì)的 java 組件模型。

EJB 組件是基于標(biāo)準(zhǔn)分布式對(duì)象技術(shù)、CORBA 和 RMI 的服務(wù)器端 java 組件。EJB 組件總是分布式的，這是它們與標(biāo)準(zhǔn) JavaBeans 組件最根本的區(qū)別。
EJB 組件提供了應(yīng)用的商務(wù)邏輯部分。由于它們不涉及表示層的問題，因此必須與其它的顯示技術(shù)(如 servlets)，服務(wù)于 HTML 客戶端的 JSP 技術(shù)，或者使用了諸如 AWT、Swing 技術(shù)的 java 應(yīng)用一起使用。
實(shí)現(xiàn)了 EJB 規(guī)范的應(yīng)用服務(wù)器提供了可以解決安全性、資源共享、持續(xù)運(yùn)行、并行處理、事務(wù)完整性等復(fù)雜問題的服務(wù)，從而簡(jiǎn)化了商業(yè)應(yīng)用系統(tǒng)。
Sun 公司制定的 EJB 組件模型要求 EJB 組件運(yùn)行于 EJB 服務(wù)器(通常稱為應(yīng)用服務(wù)器)的環(huán)境下。我們的示例中使用了高級(jí)版 WebSphere 應(yīng)用服務(wù)器，但所討論的功能適用于大多數(shù) EJB 服務(wù)器。

需要考慮的技術(shù)問題
當(dāng)你在決定 EJB 組件是否為適合你的實(shí)際情況的合適技術(shù)時(shí)，不妨先考慮幾個(gè)問題。如果你對(duì)所有這些問題的回答都是肯定的話，那么 EJB 組件就是你可以采用的合適技術(shù)。反之的話，別的技術(shù)可能更適合。

你需要將商務(wù)邏輯組件與面向外界的 Internet 隔離開嗎？
許多公司認(rèn)為他們的應(yīng)用軟件，特別是構(gòu)成商務(wù)邏輯的一些標(biāo)準(zhǔn)和數(shù)據(jù)結(jié)構(gòu)，是極為重要的公司財(cái)產(chǎn)(例如，公司所擁有的分析應(yīng)用工具構(gòu)成了股票交易網(wǎng)站的一部分)。允許外人訪問這些屬于公司資產(chǎn)的原碼和目標(biāo)碼將對(duì)公司產(chǎn)生極大的危害。因此，這些公司十分需要將商務(wù)邏輯置于一套安全防火墻后面(通常稱為無戒備區(qū)，也稱 DMZ)。

在這種情況下，分布式對(duì)象組件體系結(jié)構(gòu)(例如 EJB 技術(shù))允許你將有價(jià)值的公司資產(chǎn)隔離到 DMZ 以內(nèi)，同時(shí)表示層代碼可以訪問 DMZ 內(nèi)的 EJB 服務(wù)器。下圖描述了這種分布式解決方案：

防火墻內(nèi)部的 EJB


這里我們假設(shè)表示層邏輯不如后臺(tái)的商務(wù)邏輯重要。如果不是這樣，那么這種方案的安全性就要下降，整個(gè)系統(tǒng)可能都需要置于 DMZ 之內(nèi)。如果整個(gè)應(yīng)用必須(或者能夠)置于第二層防火墻后面，那么選擇其它技術(shù)(如通過 Java Servlets 發(fā)出 JDBC 請(qǐng)求來直接訪問數(shù)據(jù)庫(kù))就顯得更合理。

這種解決方案也有一些效率方面的缺陷。例如在安裝 WebSphere 時(shí)，如果你將客戶端(servlets 與 JSP文件)與圖示的位于另一個(gè) java 虛擬機(jī)(JVM)中的 EJB 組件分隔開，這種選擇將降低整體性能。與客戶端和 EJB 組件位于同一個(gè) JVM 中的情況相比，這種方式下每一個(gè)需要經(jīng)過防火墻的請(qǐng)求都將增加20%的耗時(shí)。

你需要不止一種類型的客戶端訪問共享數(shù)據(jù)嗎？
通常，一個(gè)應(yīng)用會(huì)有多種類型、需要訪問相同信息的客戶端。例如，一個(gè)應(yīng)用可能會(huì)有供外部客戶訪問的基于 web 的 HTML 前端，以及供內(nèi)部人員使用的更完整的應(yīng)用前端。通常，這個(gè)問題是通過為同一應(yīng)用編寫兩個(gè)共享相同數(shù)據(jù)源(數(shù)據(jù)庫(kù)表)的版本來解決的。但是，這種方法效率不高，無論是從編程時(shí)間還是從同時(shí)發(fā)生多個(gè)數(shù)據(jù)庫(kù)鎖定時(shí)數(shù)據(jù)庫(kù)的利用率來說。

EJB 技術(shù)的解決方案是將共享數(shù)據(jù)和商務(wù)邏輯集成到一套 EJB 組件中，以供不同類型的客戶端(如 servlet/HTML 和 application)訪問。EJB 組件控制著對(duì)后臺(tái)數(shù)據(jù)的訪問，并管理著當(dāng)前事務(wù)以及數(shù)據(jù)庫(kù)的內(nèi)部鎖定。通過去除應(yīng)用中的重復(fù)代碼，減少編寫數(shù)據(jù)庫(kù)控制邏輯的工作，這種方案降低了總的編程量。

在這個(gè)領(lǐng)域還有其它一些解決方案--比如，java 應(yīng)用可以通過 HTTP 訪問 java servlets，同時(shí)瀏覽器也可以通過 HTTP 訪問 java servlets。這些解決方案的問題在于：如果 servlet 是用來在瀏覽器中顯示信息的，它就必須包含一些表示層邏輯，這些表示層邏輯對(duì)于向另一個(gè)程序傳遞信息來說是多余的。因此，你最終不得不采用兩套部分重復(fù)的 servlets 來處理兩種情況。此外，HTTP 不是程序間通訊的效率最高的協(xié)議。你必須設(shè)計(jì)能通過 HTTP 管道進(jìn)行程序間信息傳遞的數(shù)據(jù)格式--這通常或者是基于文本的格式，比如 XML（由接收端進(jìn)行解析，由發(fā)送端生成），或者是基于對(duì)象的格式，比如 java 序列化。兩種格式都需要大量的編程工作，它們都不如本地的 IIOP 速度快。

你是否需要對(duì)共享數(shù)據(jù)同時(shí)進(jìn)行讀和寫操作？
通常，"胖客戶端"解決方案要求應(yīng)用在數(shù)據(jù)庫(kù)級(jí)別上管理對(duì)共享數(shù)據(jù)的訪問。其結(jié)果是：處理數(shù)據(jù)庫(kù)鎖定與同步的方案非常復(fù)雜，若不考慮數(shù)據(jù)庫(kù)鎖定與同步問題又會(huì)失去數(shù)據(jù)的完整性。

EJB 技術(shù)能自動(dòng)處理這些復(fù)雜的共享數(shù)據(jù)同步問題。正如前面提到的那樣，EJB 組件控制著對(duì)后臺(tái)數(shù)據(jù)的訪問，并管理著當(dāng)前事務(wù)和數(shù)據(jù)庫(kù)的內(nèi)部鎖定。這不僅省去了編寫數(shù)據(jù)庫(kù)控制邏輯的工作量，同時(shí)也保證了數(shù)據(jù)的一致性與正確性，從而降低了總的編程量。

你需要訪問具備事務(wù)處理功能的多個(gè)異構(gòu)數(shù)據(jù)源嗎？
許多應(yīng)用需要訪問多個(gè)數(shù)據(jù)源。例如，一個(gè)應(yīng)用程序可能既要訪問來自中間層的 Oracle 數(shù)據(jù)庫(kù)，又要通過中間件(如 MQSeries)訪問 CICS、IMS 等大型主機(jī)系統(tǒng)。問題的關(guān)鍵是一些應(yīng)用要求這種訪問是完全事務(wù)化的，并且數(shù)據(jù)完整性在不同數(shù)據(jù)源間也能得到保證。例如，某個(gè)應(yīng)用可能要求在處理用戶的訂購(gòu)信息時(shí)，既要在 Oracle 數(shù)據(jù)庫(kù)中存儲(chǔ)詳細(xì)的訂購(gòu)信息，同時(shí)又通過 MQSeries 在 CICS 系統(tǒng)中存儲(chǔ)一份出貨訂單。無論是數(shù)據(jù)庫(kù)更新或是 MQ 隊(duì)列產(chǎn)生錯(cuò)誤，整個(gè)事務(wù)都應(yīng)被取消。

過去，構(gòu)建這樣的系統(tǒng)的唯一選擇是采用事務(wù)監(jiān)視器，例如 Encina、CICS、Tuxedo，它們使用非標(biāo)準(zhǔn)接口并需要用 COBOL、C、C++ 等語言進(jìn)行開發(fā)。例如，高級(jí)版 WebSphere 中的 EJB 容器支持多個(gè)并發(fā)的事務(wù)，具備在多個(gè) DB2 數(shù)據(jù)源間進(jìn)行完整的事務(wù)提交及事務(wù)取消的能力，這些都是在一個(gè)完全支持二狀態(tài)事務(wù)提交的環(huán)境中進(jìn)行的。目前，WebSphere 對(duì)其它數(shù)據(jù)源(如 Oracle, MQSeries 和 CICS)只支持單狀態(tài)的事務(wù)提交。企業(yè)版 WebSphere 中的 EJB 容器能對(duì)更多的數(shù)據(jù)源支持二狀態(tài)的事務(wù)提交。

大多數(shù)容器正在支持各種數(shù)據(jù)源下的二狀態(tài)事務(wù)提交方面不斷完善。隨著時(shí)間的推移，我們將在這一領(lǐng)域看到不斷的進(jìn)步。


你需要能與 HTML 文檔、servlets、JSP 文件、客戶端登錄安全性無縫集成的方法級(jí)對(duì)象安全性嗎？
某些類型的應(yīng)用由于其安全性限制，使得以前它們很難通過 java 應(yīng)用來實(shí)現(xiàn)。例如，某些保險(xiǎn)業(yè)的應(yīng)用程序?yàn)榱藵M足管理規(guī)定的要求，必須限制對(duì)客戶數(shù)據(jù)的訪問。直到 EJB 技術(shù)出現(xiàn)后，才能夠限制特定用戶訪問某個(gè)對(duì)象或方法。在這之前，可實(shí)施的辦法只有：在數(shù)據(jù)庫(kù)級(jí)別上限制訪問，并捕獲在 JDBC 層次上拋出的錯(cuò)誤；或者通過客戶安全密碼在應(yīng)用層上限制訪問。

EJB 技術(shù)可以在任何 EJB 組件或方法上實(shí)施方法級(jí)的安全策略。創(chuàng)建的用戶和用戶組可以被授予或禁止對(duì)任何 EJB 組件或方法的操作權(quán)。在 WebSphere 中，用戶組可以被授予或禁止對(duì) web 資源(servlets, JSP 文件和 HTML 頁面)的訪問權(quán)，用戶的 ID 可以通過底層的安全機(jī)制被安全地從 web 資源傳遞到 EJB 組件。


體系結(jié)構(gòu)是否有標(biāo)準(zhǔn)化、輕量化、組件化的需要呢？
對(duì)于許多有遠(yuǎn)見的公司來說，關(guān)鍵問題是要實(shí)現(xiàn)平臺(tái)、銷售商和應(yīng)用服務(wù)器設(shè)備間的相互獨(dú)立。符合工業(yè)標(biāo)準(zhǔn)的 EJB 組件體系結(jié)構(gòu)有助于實(shí)現(xiàn)這些目標(biāo)。為 WebSphere 開發(fā)的 EJB 組件通�？梢园l(fā)布到其它類型的應(yīng)用服務(wù)器上使用，反之亦然。盡管這一目標(biāo)尚未完全實(shí)現(xiàn)，但它已成為許多客戶選擇的戰(zhàn)略發(fā)展方向。從短期看，利用一些可能優(yōu)于標(biāo)準(zhǔn)化的特性會(huì)更方便、更迅速，但從長(zhǎng)遠(yuǎn)看標(biāo)準(zhǔn)化具有最大的好處。

你也應(yīng)當(dāng)考慮到越來越多的可選工具和 EJB 標(biāo)準(zhǔn)的優(yōu)化實(shí)現(xiàn)手段，這些都是你無法從本地管理對(duì)象框架中獲得的。由于大多數(shù)公司并不從事中間件業(yè)務(wù)，將注意力集中在與你的業(yè)務(wù)更直接相關(guān)的活動(dòng)上會(huì)更有效。


你需要多個(gè)服務(wù)器來滿足系統(tǒng)的吞吐量和有效性需要嗎？
胖客戶端系統(tǒng)顯然不能適應(yīng) web 系統(tǒng)可能擁有的成千上萬個(gè)用戶。軟件發(fā)布方面的問題也要求給胖客戶端減肥。Web 站點(diǎn)的24小時(shí)不間斷運(yùn)行特點(diǎn)也使得時(shí)間成為關(guān)鍵問題。但并不是每個(gè)人都需要24小時(shí)不間斷運(yùn)行，并能同時(shí)處理上萬個(gè)用戶的系統(tǒng)。你應(yīng)當(dāng)能設(shè)計(jì)這樣的系統(tǒng)：在不增加開發(fā)和標(biāo)準(zhǔn)化難度的前提下，實(shí)現(xiàn)系統(tǒng)的伸縮性。

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

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

WebSphere 支持其它服務(wù)器端 java 技術(shù)(如 java servlets，JSP文件)的發(fā)布、克隆和自動(dòng)故障恢復(fù)。但是，這些更面向表示層的技術(shù)與其說是 EJB 組件的競(jìng)爭(zhēng)對(duì)手，不如說是對(duì)其的補(bǔ)充。當(dāng)總體時(shí)間和可伸縮性是問題的關(guān)鍵時(shí)，整體解決方案中應(yīng)包括 EJB 組件。


關(guān)于兩個(gè)方案的描述，或者說是關(guān)于正確使用 EJB 組件的描述
現(xiàn)在你已經(jīng)了解了一些評(píng)估一個(gè)應(yīng)用是否適合使用 EJB 技術(shù)的辦法，下面我們來比較兩個(gè)使用了 EJB 組件的應(yīng)用，看看 EJB 技術(shù)究竟是幫助還是阻礙了開發(fā)者達(dá)到目標(biāo)。在一個(gè)例子中 EJB 組件的正確使用使得代碼更簡(jiǎn)潔、更易懂。在另一個(gè)例子中，使用 EJB 組件使得系統(tǒng)過于復(fù)雜，性能也不好。

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

一個(gè)使用 EJB 技術(shù)失敗的例子
作為一個(gè)被授權(quán)評(píng)估新技術(shù)的高級(jí)技術(shù)小組的成員，某個(gè)方案小組最初設(shè)計(jì)了這個(gè)方案。該方案具有如下體系結(jié)構(gòu)(每個(gè)方框代表運(yùn)行于各自硬件上的不同程序)：

不可取的 EJB 體系結(jié)構(gòu)


該體系結(jié)構(gòu)的一些具體設(shè)計(jì)使得 EJB 組件的使用不如它初看起來那么有吸引力：

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

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

如果直接由和 java servlets 處于同一 JVM 中的 JavaBeans 組件來實(shí)現(xiàn)數(shù)據(jù)映射功能，系統(tǒng)的速度將比使用 EJB 組件快得多，同時(shí)避免了大量的網(wǎng)絡(luò)開銷。該系統(tǒng)還變得不必要的復(fù)雜(因?yàn)樾枰�本地和遠(yuǎn)程接口，以及分布代碼)。事實(shí)上，該方案后來被廢棄并以不使用 EJB 組件的方式進(jìn)行了重新設(shè)計(jì)，其中的數(shù)據(jù)映射由一套被 servlets 使用的標(biāo)準(zhǔn) JavaBeans 組件實(shí)現(xiàn)。這使得最后的系統(tǒng)變得更簡(jiǎn)單、更快速。

一個(gè)成功使用EJB技術(shù)的例子
一個(gè)金融機(jī)構(gòu)的方案小組設(shè)計(jì)了這套方案，最初使用了 java 和 RMI 技術(shù)。其系統(tǒng)體系結(jié)構(gòu)如下：

RMI服務(wù)器體系結(jié)構(gòu)


除了多種類型的客戶端，方案小組還在系統(tǒng)內(nèi)構(gòu)建了以下兩個(gè)框架單元，在本圖中未畫出來：

一個(gè)數(shù)據(jù)庫(kù)映射層，通過 RMI 服務(wù)器上的 JDBC 將其 Oracle 數(shù)據(jù)表映射成 java 類，或者反過來。
一個(gè)用戶安全框架單元，用于驗(yàn)證來自瀏覽器或應(yīng)用客戶端的用戶，并進(jìn)而決定用戶是否有權(quán)進(jìn)行 RMI 和數(shù)據(jù)庫(kù)請(qǐng)求。
由于他們的應(yīng)用需求與 EJB 技術(shù)的目標(biāo)緊密相連，該方案小組得以很快將其設(shè)計(jì)方案轉(zhuǎn)變?yōu)橐韵麦w系結(jié)構(gòu)：


新的 EJB 體系結(jié)構(gòu)


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

簡(jiǎn)單地說，該應(yīng)用的以下特點(diǎn)使得它適合使用 EJB 技術(shù)：

具有共享相同商務(wù)邏輯的多種類型客戶端
使用了事務(wù)處理
需要通過 CMP 組件來實(shí)現(xiàn)與對(duì)象有關(guān)的映射
需要方法級(jí)的安全性

由于系統(tǒng)的設(shè)計(jì)目標(biāo)是通過使用與實(shí)體同時(shí)發(fā)布的會(huì)話級(jí) EJB 組件來實(shí)現(xiàn)最小的網(wǎng)絡(luò)流量，該系統(tǒng)最終的體系結(jié)構(gòu)很好地使用了 EJB 組件。對(duì)于前一種體系結(jié)構(gòu)，由于客戶端需要發(fā)出大量的請(qǐng)求，很可能會(huì)增加網(wǎng)絡(luò)負(fù)擔(dān)，另外由于要求客戶端進(jìn)行事務(wù)的啟動(dòng)、提交、取消，使得系統(tǒng)復(fù)雜化。

總結(jié)
構(gòu)建一個(gè)可能使用 EJB 組件的新系統(tǒng)時(shí)，做出正確決定的第一步是要懂得如何確定 EJB 技術(shù)是否適合于該應(yīng)用，包括選擇 EJB 組件作為一種實(shí)現(xiàn)手段所帶來的正面和負(fù)面影響。

來源：IBM DW