關(guān)于構(gòu)建一個(gè)使用EJB組件的新系統(tǒng)

2019-11-18 12:34:53

字體：大中小

供稿：網(wǎng)友

　　什么是 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)站的一部分)。答應(yīng)外人訪問這些屬于公司資產(chǎn)的原碼和目標(biāo)碼將對(duì)公司產(chǎn)生極大的危害。因此，這些公司十分需要將商務(wù)邏輯置于一套安全防火墻后面(通常稱為無戒備區(qū)，也稱 DMZ)。
　　
　　在這種情況下，分布式對(duì)象組件體系結(jié)構(gòu)(例如 EJB 技術(shù))答應(yīng)你將有價(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ù)庫)就顯得更合理。
　　
　　這種解決方案也有一些效率方面的缺陷。例如在安裝 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ù)庫表)的版本來解決的。但是，這種方法效率不高，無論是從編程時(shí)間還是從同時(shí)發(fā)生多個(gè)數(shù)據(jù)庫鎖定時(shí)數(shù)據(jù)庫的利用率來說。
　　
　　EJB 技術(shù)的解決方案是將共享數(shù)據(jù)和商務(wù)邏輯集成到一套 EJB 組件中，以供不同類型的客戶端(如 servlet/HTML 和 application)訪問。EJB 組件控制著對(duì)后臺(tái)數(shù)據(jù)的訪問，并治理著當(dāng)前事務(wù)以及數(shù)據(jù)庫的內(nèi)部鎖定。通過去除應(yīng)用中的重復(fù)代碼，減少編寫數(shù)據(jù)庫控制邏輯的工作，這種方案降低了總的編程量。
　　
　　在這個(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ù)庫級(jí)別上治理對(duì)共享數(shù)據(jù)的訪問。其結(jié)果是：處理數(shù)據(jù)庫鎖定與同步的方案非常復(fù)雜，若不考慮數(shù)據(jù)庫鎖定與同步問題又會(huì)失去數(shù)據(jù)的完整性。
　　
　　EJB 技術(shù)能自動(dòng)處理這些復(fù)雜的共享數(shù)據(jù)同步問題。正如前面提到的那樣，EJB 組件控制著對(duì)后臺(tái)數(shù)據(jù)的訪問，并治理著當(dāng)前事務(wù)和數(shù)據(jù)庫的內(nèi)部鎖定。這不僅省去了編寫數(shù)據(jù)庫控制邏輯的工作量，同時(shí)也保證了數(shù)據(jù)的一致性與正確性，從而降低了總的編程量。
　　
　　你需要訪問具備事務(wù)處理功能的多個(gè)異構(gòu)數(shù)據(jù)源嗎？
　　許多應(yīng)用需要訪問多個(gè)數(shù)據(jù)源。例如，一個(gè)應(yīng)用程序可能既要訪問來自中間層的 Oracle 數(shù)據(jù)庫，又要通過中間件(如 MQSeries)訪問 CICS、IMS 等大型主機(jī)系統(tǒng)。問題的要害是一些應(yīng)用要求這種訪問是完全事務(wù)化的，并且數(shù)據(jù)完整性在不同數(shù)據(jù)源間也能得到保證。例如，某個(gè)應(yīng)用可能要求在處理用戶的訂購信息時(shí)，既要在 Oracle 數(shù)據(jù)庫中存儲(chǔ)具體的訂購信息，同時(shí)又通過 MQSeries 在 CICS 系統(tǒng)中存儲(chǔ)一份出貨訂單。無論是數(shù)據(jù)庫更新或是 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ù)庫級(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)見的公司來說，要害問題是要實(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 組件通常可以發(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í)間成為要害問題。但并不是每個(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ù)(

上一篇：漫談EJB——Enterprise JavaBeans（一）

下一篇：EJB——Enterprise JavaBeans技術(shù)及應(yīng)用