浙江工業(yè)大學之江學院 畢業(yè)設(shè)計（論文） 外文翻譯 畢業(yè)設(shè)計（論文）題目： 基于 J2EE 的企業(yè)電子投票系統(tǒng)開發(fā)與設(shè)計 外文翻譯（一） 題目： J2EE 體系結(jié)構(gòu) 外文翻譯（二） 題目： J2EE 項目的選擇與風險 分院（系）： 信息工程分院 專 業(yè)： 計算機科學與技術(shù) 班 級： 0402 姓 名： 徐棟杰 學 號： 200420100219 指導教師： 馮志林 畢業(yè)設(shè)計（論文）外文翻譯要求 1、畢業(yè)設(shè)計（論文）外文翻譯應(yīng)有兩篇，總字符數(shù)不少于 20000，其文獻來源應(yīng)由指導教師選定后以紙質(zhì)（復印或打印件）形式隨同畢業(yè)設(shè)計（論文）任務(wù)書一并發(fā)給學生。復印或打印件上應(yīng)有指導教師和 專業(yè)教研室主任的簽名和日期。要求每位學生的外文翻譯內(nèi)容不重復。 2、翻譯的外文文獻應(yīng)主要選自學術(shù)期刊、學術(shù)會議的文章、有關(guān)著作及其他相關(guān)材料，應(yīng)與畢業(yè)論文（設(shè)計）主題相關(guān)，并列入畢業(yè)論文（設(shè)計）的參考文獻 ； 在每篇中文譯文首頁 “ 頁腳”處 注明原文作者及出處，中文譯文后應(yīng)附外文原文 （指導教師提供的原文，論文上應(yīng)有指導教師和教研室主任簽名） 。 3、中文譯文的基本撰寫格式為 ： 題目采用三號黑體字居中打印，正文采用宋體小四號字，行間距一般為固定值 20 磅，標準字符間距。頁邊距為左 3 cm，右 2.5 cm，上下各 2.5 cm，頁面統(tǒng)一采用 A4 紙。 4、 封面上的 “外文 翻譯題目” 指中文譯文的題目 ； 兩篇外文文獻， 按“ 封面、譯文一、外文原文 （ 一 ） 、譯文二、外文原文 （ 二 ）、外文翻譯評閱表 ” 的順序統(tǒng)一裝訂。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 作者： 美 亨特 美 羅夫特斯 來源： 精通 J2EE(Java 企業(yè)級應(yīng)用 )， 2004.7： 23-28 譯文一 J2EE體系結(jié)構(gòu) 在討論了 J2EE設(shè)計中的一些高層次問題之后，現(xiàn)在該來看一看 J2EE應(yīng)用的幾個可選體系結(jié)構(gòu)。 常見概念 首先，讓我們來看一看所有 J2EE體系結(jié)構(gòu)都共有的幾個概念。 J2EE應(yīng)用中的體系結(jié)構(gòu)層 下面要討論的每個體系結(jié)構(gòu)都含有三個主要層，盡管有些體系結(jié)構(gòu)在中間層內(nèi)因如了另外的劃分。 經(jīng)驗已經(jīng)證明了將企業(yè)級系統(tǒng)明 確地劃分成多個層的價值。這確保了責任的明確劃分。 J2EE的 3層體系結(jié)構(gòu)是各類系統(tǒng)中的經(jīng)驗結(jié)晶。具有 3個或 3個以上層的系統(tǒng)已經(jīng)證明比其內(nèi)沒有中間層的客戶 -服務(wù)器系統(tǒng)具有更大的可縮放和靈活性。 在一個設(shè)計完備的多層系統(tǒng)中，每一層應(yīng)該只依賴于它下面的那一層。例如，對數(shù)據(jù)庫的更改不應(yīng)該要求對 WEB接口的更改。 每一層所特有的東西應(yīng)該向其他層隱藏起來。例如， WEB 應(yīng)用中的 WEB 層只應(yīng)該依賴于服務(wù)器小程序 API，而中間層只應(yīng)該依賴于 JDBC 之類的企業(yè)資源 API。這兩個原則確保了應(yīng)用修改起來容易，同時修改又不 級聯(lián)到其他層。 下面依次來看典型的 J2EE 體系結(jié)構(gòu)的每一層。 企業(yè)信息系統(tǒng)（ EIS）層 這一層有時也叫做綜合層（ INTEGRATION TIER），由 J2EE 應(yīng)用完成其工作所必須訪問的企業(yè)資源所組成。這些資源包括數(shù)據(jù)庫管理系統(tǒng)（ DBMS）和遺留的主機應(yīng)用。EIS 層資源通常是事務(wù)性的， EIS 位于 J2EE 服務(wù)器的控制之外，盡管該服務(wù)器的確以一種標準方式管理事務(wù)和連接建池。 J2EE 設(shè)計師對 EIS 層的設(shè)計與部署將是變化的，視該項目的性質(zhì)（現(xiàn)有服務(wù)的綠色場或集成度）而定。如果該項目包含現(xiàn)有服務(wù)的集成， EIS 層資源 可能會影響中間層的實現(xiàn)。 J2EE 為與 EIS 層資源的借口提供了強有力的能力，比如訪問關(guān)系數(shù)據(jù)庫的 JDBC API、訪問目錄服務(wù)器的 JNDI 以及允許連接其他 EIS 系統(tǒng)的 JACA CONNECTOR ARCHITECTURE （ JACA 連接器體系結(jié)構(gòu)，簡稱 JCA）。 J2EE 服務(wù)器負責建立連往 EIS資源的連接池、橫跨資源上的事務(wù)管理以及保證 J2EE 應(yīng)用不危及 EIS 系統(tǒng)的安全。 中間層 這一層含有應(yīng)用的業(yè)務(wù)對象，并調(diào)停對 EIS 層資源的訪問。中間層構(gòu)件主要從事務(wù)管理和連接建池之類的 J2EE 容器服務(wù)中受益。中間層構(gòu)件獨 立于選定的用戶接口。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 如果使用了 EJB，我們把中間層分離成兩層： EJB 以及使用這些 EJB 來支持該接口的對象。但是，這種分離不是保證一個干凈中間層所必須的。 用戶接口（ UI）層 這一層將中間業(yè)務(wù)對象暴露給用戶。在 WEB 應(yīng)用中， UI 層由服務(wù)器小程序所使用的助手類以及諸如 JSP 頁之類的試圖構(gòu)件所組成。為了清楚起見，我們在討論 WEB應(yīng)用時將把 UI 層稱做“ WEB 層”。 業(yè)務(wù)接口的重要性 許多人將 EJB 看做 J2EE 應(yīng)用的核心。從 J2EE 的 EJB 中心論角度看，會話 EJB將暴露應(yīng)用的業(yè)務(wù)邏輯，而其他對象（比如 Business Delegate J2EE 設(shè)計模式中的Web 層“業(yè)務(wù)委托”對象）將由他們與 EJB 的關(guān)系來確定。但是，這種假設(shè)將一種技術(shù)（ EJB）抬高到了 OO 設(shè)計考慮之上。 EJB 不是在 J2EE 應(yīng)用中實現(xiàn)中間層的唯一技術(shù)。 正式業(yè)務(wù)接口層的概念體現(xiàn)了一不好的習慣，不管是不是使用了 EJB，我們都應(yīng)該使用這個概念。在下面將要討論的所有體系結(jié)構(gòu)中，業(yè)務(wù)接后層都有客戶（比如UI 層）直接使用的中間層接口所組成。業(yè)務(wù)接口層為普通 Java 接口中的中間層定義了聯(lián)系人；因此， EJB 就是一個實現(xiàn)策略。如果我們沒有使用 EJB，業(yè)務(wù)接口的實現(xiàn)將是運行在 J2EE Web 容器中的普通 Java 對象。當使用了 EJB 時，業(yè)務(wù)接口的實現(xiàn)將隱藏掉與 EJB 層的交互。 一定要設(shè)計到 Java 接口，而不要設(shè)計到具體類，也不要設(shè)計到技術(shù)。 下面來看一下滿足不同需求的 4 種 J2EE 體系結(jié)構(gòu)。 非分布式體系結(jié)構(gòu) 下面的這些體系結(jié)構(gòu)適合 Web 應(yīng)用。他們可以把所有應(yīng)用構(gòu)件只運行在單個 JVM中。這使他們變得簡單而有效，但限制了部署的靈活性。 具有業(yè)務(wù)構(gòu)件接口的 Web 應(yīng)用 在大多數(shù)情況下， J2EE 用來構(gòu)造 Web 應(yīng)用。因此，同一個 J2EE Web 容器可以提供許多應(yīng)用所需要的整個基礎(chǔ)結(jié) 構(gòu)。 和 EJB 一樣， J2EE Web 應(yīng)用實際上享有對企業(yè) API 的相同訪問權(quán)。它們受益于J2EE 服務(wù)器的事務(wù)管理和連接池能力，并可以使用 JMS,JDBC 和 Java Connector API之類的企業(yè)服務(wù)。除實體組件之外的所有數(shù)據(jù)存取技術(shù)都是可以使用的。 Web 應(yīng)用的 Web 層和中間層運行在同一個 JVM 中。但是，在邏輯上使他們保持不同是極其重要的。 Web 應(yīng)用中的主要設(shè)計風險是 UI 構(gòu)件與業(yè)務(wù)邏輯構(gòu)件之間的責任模糊不清。 業(yè)務(wù)接口層將由普通 Java 類所實現(xiàn)的 Java 接口來組成。這是一個簡單而又可縮放的體系結(jié)構(gòu)，并且 能滿足大多數(shù)應(yīng)用的需要。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 長處 這種體系結(jié)構(gòu)具有下列優(yōu)點： 簡單性。這通常是 Web 應(yīng)用的最簡單結(jié)構(gòu)。但是，如果事務(wù)管理或線程化問題要求開發(fā)分復雜的代碼，使用 EJB 可能將更簡單。 速度。這樣的體系結(jié)構(gòu)遇到了來自 J2EE 服務(wù)器的最小系統(tǒng)開銷。 OO 設(shè)計不會被 J2EE 構(gòu)件問題（比如調(diào)用 EJB 的影響）所妨礙。 容易測試。如果設(shè)計合理，無需 Web 層就能夠?qū)I(yè)務(wù)接口進行測試。 我們可以發(fā)揮服務(wù)器的事務(wù)支持。 縮放性很好。如果 Web 接口是無狀態(tài)的，則根本不需要來自容器的聚類支持。但是， Web 應(yīng)用可以通過使用服務(wù)器支持會話 狀態(tài)復制來分布。 弱點 應(yīng)該注意下列這些缺點： 這種體系結(jié)構(gòu)只支持一個 Web 接口。例如，它不能支持獨立的 GUI 客戶（中間層和這個 Web 接口在同一個 JVM 中）。但是，正如我們稍后將回看到的，可以增加一個 Web 服務(wù)層。 整個應(yīng)用僅運行在單個 JVM 中。雖然這提高了性能，但我們無法將構(gòu)件自由地分配給不同的物理服務(wù)器。 這種體系結(jié)構(gòu)不能使用 EJB 容器事務(wù)支持。我們將需要在應(yīng)用代碼中創(chuàng)建和管理事務(wù)。 服務(wù)器沒有提供對并發(fā)編程的支持。我們必須親自處理線程化問題，或使用一個解決常見問題的類庫，比如 util.concurrent。 將實體組件用于數(shù)據(jù)存取是不可能的，但可以證明的是，這根本不是什么損失。 訪問本地 EJB 的 Web 應(yīng)用 Servlet2.3 規(guī)范（ SRV9.11）可從 /products/servlet/download.html站點上獲得。如果一個應(yīng)用被部署在一個集成的 J2EE 應(yīng)用服務(wù)器中且該服務(wù)器運行在單個 JVM 中，該規(guī)范通過本地接口來保證 EJB 的 Web 層對象訪問。這使我們技能從一個 EJB 容器中得到好處，又不至于招致過度的復雜性或把我們的應(yīng)用變成分布式的。 在這種體系結(jié)構(gòu)中， Web 層與剛討論過繁榮 Web 應(yīng)用體系結(jié)構(gòu)的 Web 層相同。業(yè)務(wù)接口也是相同的；這兩種體系結(jié)構(gòu)的不同之處從它們的出現(xiàn)（ EJB 層）開始。因此，中間層被劃分成了兩部分（運行在 Web 容器中的業(yè)務(wù)接口和 EJB），但這兩部分運行在同一個 JVM 中。 有兩種方法可以用來實現(xiàn)業(yè)務(wù)接口： 代理方法。在這種方法中，一個本地 EJB 直接實現(xiàn)業(yè)務(wù)接口，而 Web 容器代碼被浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 賦予一個對該 EJB 的本地接口的引用，同時 無需處理必不可少的 JNDI 查找。 業(yè)務(wù)委托方法。在這種方法中，業(yè)務(wù)接口的 Web 容器實現(xiàn)明確地托付給相應(yīng)的EJB。這具有允許高速緩存和允許故障操作在適當?shù)攸c被重試的優(yōu)點。 我們無需擔心上述任一情況中的 java.rmi.RemoteException 捕獲。傳輸錯誤不會出現(xiàn)。 在這種體系結(jié)構(gòu)中，和通過 EJB 來暴露一個遠程接口的體系結(jié)構(gòu)不同， EJB 的使用僅僅是這種體系結(jié)構(gòu)的一個實現(xiàn)選擇而已，而不是一個基本特征。不用改變總體設(shè)計，也不用 EJB，就可以實現(xiàn)任何一個業(yè)務(wù)接口。 長處 這種體系結(jié)構(gòu)具有如下這些優(yōu)點： 它沒 有分布式 EJB 應(yīng)用那么復雜。 EJB使用不更改應(yīng)用的基本設(shè)計。在這種體系結(jié)構(gòu)中，只使這樣一些對象成為 EJB：它們需要一個 EJB 容器的那些服務(wù)。 EJB 使用只強加相當小的性能開銷，因為沒有遠程方法調(diào)用或串行化。 它提供 EJB 容器事務(wù)與線程管理的各種好處。 如果需要，它允許我們使用實體組件。 弱點 這種體系結(jié)構(gòu)的缺點有如下這些： 它比純 Web 應(yīng)用更復雜。例如，它遇到 EJB 部署和類裝人復雜性。 它仍不能支持除一個 Web 接口之外的客戶，除非我們添加一個 Web 服務(wù)層。 整個應(yīng)用仍運行在單個 JVM 中，這意味著所有構(gòu)件都 必須運行在同一臺物理服務(wù)器上。 具有本地接口的 EJB 測試起來很困難。我們需要在 J2EE 服務(wù)器內(nèi)運行測試案例（比如用服務(wù)器小程序）。 作為使用 EJB 的結(jié)果，仍存在一些調(diào)整對象設(shè)計的誘惑，即使含有本地接口， EJB調(diào)用仍慢于普通的方法調(diào)用，而且這可能會誘惑我們修改業(yè)務(wù)對象的自然粒度。 有時，我們可能會決定把 EJB 引進到一個沒有適應(yīng)它的體系結(jié)構(gòu)中。這可能是由“做可能管用的最簡單事情”的 XP 方法所造成的。例如，最初的需求可能沒有證明由 EJB引入的復雜性是值得的，但后來增加的需求可能會提出使用 EJB。 如果采用上面描述 的業(yè)務(wù)構(gòu)件接口方法，引進具有本地接口的 EJB 將不會引起問題。可以簡單地選擇應(yīng)該被實現(xiàn)成具有本地的代理 EJB 的那些業(yè)務(wù)構(gòu)件接口。 引進具有遠程接口的 EJB可能有較大疑問，因為這不僅僅是一個引進 EJB的問題，而且也是一個從根本上改變了應(yīng)用的性質(zhì)的問題。例如，可能需要使業(yè)務(wù)接口粒度變的更粗，以避免“羅嗦的”調(diào)用和實現(xiàn)足夠的性能。我們還可能需要把所有業(yè)務(wù)邏輯浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 實現(xiàn)轉(zhuǎn)移到 EJB 容器內(nèi)部。 分布式體系結(jié)構(gòu) 下面這兩種體系結(jié)構(gòu)除了支持 Web 應(yīng)用之外，還支持遠程客戶。 具有遠程 EJB 的分布式應(yīng)用 這種體系結(jié)構(gòu)被廣泛地看 做“經(jīng)典的” J2EE 體系結(jié)構(gòu)。它提供了這樣一種能力：通過給 EJB 及使用 EJB 的構(gòu)件（比如 Web 構(gòu)件）使用不同的 JVM 來物理和邏輯地劃分中間層。這是一個復雜的體系結(jié)構(gòu)，并具有顯著的性能開銷。 雖然描述了一個 Web 應(yīng)用，但該體系結(jié)構(gòu)可以支持任一 J2EE 客戶類型。它特別符合獨立客戶應(yīng)用的需要。 該體系結(jié)構(gòu)在 UI 層（或者說其他遠程客戶）與業(yè)務(wù)對象之間使用 RMI，而這些業(yè)務(wù)對象被暴露為 WJB（ RMI 通信的細節(jié)由 EJB 容器來隱藏，但我們?nèi)孕枰幚硎褂盟鶐淼挠绊懀＿@使遠程調(diào)用變成了一個主要的性能決定要素和一個核心 的設(shè)計考慮因素。我們必須盡量最大限度的減少遠程調(diào)用的數(shù)量（避免“羅嗦的”調(diào)用）。在 EJB 與 EJB 客戶層之間傳遞的所有對象都必須是可串行化的，而且我們必須處理更復雜的錯誤處理需求。 該體系結(jié)構(gòu)中的 WEB 層和上面所討論的那些結(jié)構(gòu)中的 WEB 層相同。但是，業(yè)務(wù)接口的實現(xiàn)將處理對（可能是遠程） EJB 容器中的 EJB 的遠程訪問。在已討論過的用于本地 EJB 的兩種連通性方法（代理和業(yè)務(wù)委托）中，只有業(yè)務(wù)委托在這里是有用的，因為 EJB 遠程接口上的所有方法都拋出 JAVAX。 RMI。 REMOTEEXCEPTION。這是一個已檢查異 常，否則 REMOTEEXCEPTION 將需要在 UI 層代碼中被捕獲。這把它不正確地束縛到了一個 EJB 實現(xiàn)上。 EJB 層將單獨負責與 EIS 層資源的通信，而且應(yīng)該含有應(yīng)用的業(yè)務(wù)邏輯。 長處 這種通信結(jié)構(gòu)具有如下這些特有的優(yōu)點 它可以通過提供一個共享的中間層來支持所有 J2EE 客戶類型 它允許應(yīng)用構(gòu)件在不同物理服務(wù)器上的分布。如果 EJB 層是無狀態(tài)，這個特點特別管用，進而允許使用無狀態(tài)的會話 EJB。含有有狀態(tài) UI 層和無狀態(tài)中間層的應(yīng)用將會從這種部署選擇中獲得最大的好處，而且將會給 J2EE 應(yīng)用實現(xiàn)盡可能大的縮放性。 弱點 這種體系結(jié)構(gòu)的弱點有如下這些： 這是我們已討論過的最復雜的方法，如果這種復雜性確定是業(yè)務(wù)需求的合理要求，很可能會導致整個項目周期內(nèi)的資源浪費，并為故障提供一個滋生地。 它影響性能。遠程方法調(diào)用會比使用引用的本地調(diào)用慢數(shù)百倍，總體性能方面的影響結(jié)果取決與必須的遠程調(diào)用數(shù)量。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 分布式應(yīng)用的測試和測試變得很困難。 所有業(yè)務(wù)構(gòu)件都必須進行 EJB容器中。雖然這為遠程客戶提供了一個綜合性接口，但如果 EJB 不能用來解決業(yè)務(wù)需求所引起的每個問題，這是有問題的。例如，如果 SIN-GLETON 設(shè)計模式完全適用，用 EJB 滿意地 實現(xiàn)起來將會很困難。 OO 設(shè)計被 RMI 的集中使用所嚴重阻礙。 異常處理在分布式系統(tǒng)中變得更復雜。我們除了必須考慮應(yīng)用故障外，還必須兼顧傳輸故障。 當使用這種體系結(jié)構(gòu)，千萬不要破壞它。 SUN JAVA CENTER 的 “ FAST LANE READER”J2EE 模式主張從 WEB 層中執(zhí)行只讀 JDBC 訪問 ， 以便最小化通過 EJB 層進行調(diào)用的系統(tǒng)開銷。這違背了每個層只應(yīng)該跟直接位于它下面的那些層進行通信的原則，也降低了縫補式體系結(jié)構(gòu)的一個重要優(yōu)點；部署靈活性?，F(xiàn)在，運行 WEB 層的服務(wù)器必須能夠訪問數(shù)據(jù)庫，而這會使特殊的 防火墻規(guī)則車工內(nèi)為必須之物。 即使我們使用了遠程接口，如果 EJB 及使用 EJB 的構(gòu)件被放在了一起，那么大多數(shù) J2EEE 服務(wù)器仍能優(yōu)化遠程調(diào)用并替換按引用的調(diào)用。這可以極大地減少使用具有遠程接口的 EJB 所造成的性能影響，但無法消除遠程語義所因如的有害影響。這種配置更改了應(yīng)用的語句。要想讓這種配置得到使用，關(guān)鍵是保證 EJB 支持本地調(diào)用（按引用）和遠程調(diào)用（按值）。否則按引用的調(diào)用者可能會修改要傳遞其他調(diào)用者的對象，進而產(chǎn)生嚴重的后果。 不要因為使用了具有遠程借口的 EJB 導致一個應(yīng)用變成分布式的，除非業(yè)務(wù)需求明確指 出需要一個分布式體系結(jié)構(gòu)。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 外文原文 （ 一 ） J2EE Architectures Now that weve discussed some of the high-level issues in J2EE design, lets look at some alternative architecture for J2EE applications. Common Concepts First, lets consider some concepts shared by all J2EE architectures. Architectural Tiers in J2EE Applications Each of the architectures discussed below involves three major tiers, although some introduce an additional division within the middle tier. Experience has shown the value of cleanly dividing enterprise systems into multiple tiers. This ensures a clean division of responsibility. The three-tier architecture of J2EE reflects experience in a wide range of enterprise systems. Systems with three or more tiers have proven more scalable and flexible than client server systems, in which there is no middle tier. In a well-designed multi-tier system, each tier should depend only on the tier beneath it. For example, changes to the database should not demand changes to the web interface. Concerns that are unique to each tier should be hidden from other tiers. For example, only the web tier in a web application should depend on the servlet API, while only the middle tier should depend on enterprise resource APIs such as JDBC. These two principles ensure that applications are easy to modify without changes cascading into other tiers. Lets look at each tier of a typical J2EE architecture in turn. Enterprise Information System (EIS) Tier Sometimes called the Integration Tier, this tier consists of the enterprise resources that the J2EE application must access to do its work. These include Database Management Systems (DBMSs) and legacy mainframe applications. EIS tier resources are usually transactional. The EIS tier is outside the control of the J2EE server, although the server does manage transactions and connection pooling in a standard way. The J2EE architects control over the design and deployment of the EIS tier will vary depending on the nature of the project (green field or integration of existing services). If the project involves the integration of existing services, the EIS tier resources may impact on the implementation of the middle tier. J2EE provides powerful capabilities for interfacing with EIS-tier resources, such as the JDBC API for accessing relational databases, JNDI for accessing directory servers, and 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 the Java Connector Architecture (JCA) allowing connectivity to other EIS systems. A J2EE server is responsible for the pooling of connections to EIS resources, transaction management across resources, and ensuring that the J2EE application doesnt compromise the security of the EIS system. Middle Tier This tier contains the applications business objects, and mediates access to EIS tier resources. Middle tier components benefit most from J2EE container services such as transaction management and connection pooling. Middle-tier components are independent of the chosen user interface. If we use EJB, we split the middle tier into two: EJBs, and objects that use the EJBs to support the interface. However, this split isnt necessary to ensure a clean middle tier. User Interface (UI) Tier This tier exposes the middle-tier business objects to users. In web applications, the UI tier consists of servlets, helper classes used by servlets, and view components such as JSP pages. For clarity, well refer to the UI tier as the web tier when discussing web applications. The Importance of Business Interfaces Many regard EJBs as the core of a J2EE application. In an EJB-centric view of J2EE, session EJBs will expose the applications business logic, while other objects (such as business delegate objects in the web tier in the Business Delegate J2EE design pattern) will be defined by their relationship to the EJBs. This assumption, however, elevates a technology (EJB) above OO design considerations. Important EJB is not the only technology for implementing the middle tier in J2EE applications. The concept of a formal layer of business interfaces reflects good practice, and we should use it regardless of whether we use EJB. In all the architectures we discuss below, the business interface layer consists of the middle-tier interfaces that clients (such as the UI tier) use directly. The business interface layer defines the contract for the middle tier in ordinary Java interfaces； EJB is thus one implementation strategy. If we dont use EJB, the implementation of the business interfaces will be ordinary Java objects, running in a J2EE web container. When we do use EJBs, the implementations of the business interfaces will conceal interaction with the EJB tier. Important Design to Java interfaces, not concrete classes, and not technologies. Lets now look at four J2EE architectures that satisfy different requirements. Non-distributed Architectures 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 The following architectures are suitable for web applications. They can run all application components in a single JVM. This makes them simple and efficient but limits the flexibility of deployment. Web Application with Business Component Interfaces In most cases, J2EE is used to build web applications. Thus, a J2EE web container can provide the entire infrastructure required by many applications. J2EE web applications enjoy virtually the same access to enterprise APIs as EJBs. They benefit from the J2EE servers transaction management and connection pooling capabilities and can use enterprise services such as JMS, JDBC, JavaMail, and the Java Connector API. All data access technologies are available with the exception of entity beans. The web tier and middle tier of a web application run in the same JVM. However, it is vital that they are kept logically distinct. The main design risk in web applications is that of blurred responsibilities between UI components and business logic components. The business interface layer will consist of Java interfaces implemented by ordinary Java classes. This is a simple yet scalable architecture that meets the needs of most applications. Strengths This architecture has the following strengths: Simplicity. This is usually the simplest architecture for web applications. However, if transaction management or threading issues require the development of unduly complex code, it will probably prove simpler to use EJB. Speed. Such architectures encounter minimal overhead from the J2EE server. OO design isnt hampered by J2EE component issues such as the implications of invoking EJBs. Easy to test. With appropriate design, tests can be run against the business interface without the web tier. We can leverage the servers transaction support. Scales well. If the web interface is stateless, no clustering support is required from the container. However, web applications can be distributed, using server support session state replication. Weaknesses The following drawbacks should be kept in mind: This architecture supports only a web interface. For example, it cannot support 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 standalone GUI clients. (The middle tier is in the same JVM as the web interface.) However, a layer of web services can be added, as we shall see later. The whole application runs within a single JVM. While this boosts performance, we cannot allocate components freely to different physical servers. This architecture cannot use EJB container transaction support. We will need to create and manage transactions in application code. The server provides no support for concurrent programming. We must handle threading issues ourselves or use a class library such as util.concurrent that solves common problems. Its impossible to use entity beans for data access. However, this is arguably no loss. Web Application that Accesses Local EJBs The Servlet 2.3 specification (SRV.9.11), which can be downloaded from /products/servlet/download.html, guarantees web-tier objects access to EJBs via local interfaces if an application is deployed in an integrated J2EE application server running in a single JVM. This enables us to benefit from the services offered by an EJB container, without incurring excessive complexity or making our application distributed. In this architecture, the web tier is identical to that of the web application architecture weve just considered. The business interfaces are also identical； the difference begins with their implementation, which faces the EJB tier. Thus the middle tier is divided into two (business interfaces running in the web container and EJBs), but both parts run within the same JVM. Two approaches can be used to implement the business interfaces: A proxy approach, in which a local EJB implements the business interface directly and web container code is given a reference to the EJBs local interface, without needing to handle the necessary JNDI lookup. A business delegate approach, in which the web-container implementation of the business interfaces explicitly delegates to the appropriate EJB. This has the advantage of permitting caching and allowing failed operations to be retried where appropriate. We dont need to worry about catching java.rmi.RemoteException in either case. Transport errors cannot occur. In this architecture, unlike an architecture exposing a remote interface via EJB, the use of EJB is simply an implementation choice, not a fundamental characteristic of the architecture. Any of the business interfaces can be implemented without using EJB without changing the overall design. 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 Strengths This architecture has the following strengths: Its less complex than a distributed EJB application. EJB use doesnt alter the applications basic design. In this architecture, only make those objects EJBs that need the services of an EJB container. EJB use imposes relatively little performance overhead as there is no remote method invocation or serialization. It offers the benefits of EJB container transaction and thread management. It allows the use of entity beans if desired. Weaknesses Its drawbacks are as follows: Its more complex than a pure web application. For example, it encounters EJB deployment and class loading complexity. It still cannot support clients other than a web interface unless we add a web services layer. The whole application still runs within a single JVM, which means that all components must run on the same physical server. EJBs with local interfaces are hard to test. We need to run test cases within the J2EE server (for example, from servlets). There is still some temptation to tweak object design as a result of using EJB. Even with local interfaces, EJB invocations are slower than ordinary method calls, and this may tempt us to modify the natural granularity of business objects. Note Sometimes we may decide to introduce EJB into an architecture that does not use it. This may result from the XP approach of doing the simplest thing that could possibly work. For example, the initial requirements might not justify the complexity introduced by EJB, but the addition of further requirements might suggest its use. If we adopt the business component interface approach described above, introducing EJBs with local interfaces will not pose a problem. We can simply choose the business component interfaces that should be implemented to proxy EJBs with local interfaces. Introducing EJBs with remote interfaces may be more problematic, as this is not merely a question of introducing EJB, but of fundamentally changing the nature of the application. For example, business interface granularity may need to be made more coarse-grained to avoid chatty calling and achieve adequate performance. We will probably also want to move all business logic implementation inside the EJB container. 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 Distributed Architectures The following two architectures support remote clients as well as web applications. Distributed Application with Remote EJBs This is widely regarded as the classic J2EE architecture. It offers the ability to split the middle tier physically and logically by using different JVMs for EJBs and the components (such as web components) that use them. This is a complex architecture, with significant performance overhead: Although the diagram shows a web application, this architecture can support any J2EE client type. It is particularly suited to the needs of standalone client applications. This architecture uses RMI between the UI tier (or other remote clients) and the business objects, which are exposed as EJBs (the details of RMI communication are concealed by the EJB container, but we still need to deal with the implications of its use). This makes remote invocation a major determinant of performance and a central design consideration. We must strive to minimize the number of remote calls (avoiding chatty calling). All objects passed between the EJB and EJB client tiers must be serializable, and we must deal with more complex error handling requirements. The web tier in this architecture is the same as in the ones weve discussed above. However, the implementations of the business interface will handle remote access to EJBs in the (possibly remote) EJB container. Of the two connectivity approaches we discussed for local EJBs (proxy and business delegate), only the business delegate is useful here, as all methods on EJB remote interfaces throw javax.rmi.RemoteException. This is a checked exception. Unless we use a business delegate to contact EJBs and wrap RMI exceptions as fatal runtime exceptions or application exceptions, RemoteExceptions will need to be caught in UI-tier code. This ties it inappropriately to an EJB implementation. The EJB tier will take sole charge of communication with EIS-tier resources, and should contain the applications business logic. Strengths This architecture has the following unique strengths: It can support all J2EE client types by providing a shared middle tier. It permits the distribution of application components across different physical servers. This works particularly well if the EJB tier is stateless, allowing the use of stateless session EJBs. Applications with stateful UI tiers but stateless middle tiers will benefit most from this deployment option and will achieve the maximum scalability possible for J2EE applications. 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 Weaknesses The weaknesses of this architecture are: This is the most complex approach weve considered. If this complexity isnt warranted by the business requirements, its likely to result in wasted resources throughout the project lifecycle and provide a breeding ground for bugs. It affects performance. Remote method calls can be hundreds of times slower than local calls by reference. The effect on overall performance depends on the number of remote calls necessary. Distributed applications are hard to test and debug. All business components must run in the EJB container. While this offers a comprehensive interface for remote clients, it is problematic if EJB cannot be used to solve every problem posed by the business requirements. For example, if the Singleton design pattern is a good fit, it will be hard to implement satisfactorily using EJB. OO design is severely hampered by the central use of RMI. Exception handling is more complex in distributed systems. We must allow for transport failures as well as application failures. When using this architecture, dont subvert it. For example, Sun Java Centers Fast Lane Reader J2EE pattern advocates performing read-only JDBC access from the web tier so as to minimize the overhead of calling through the EJB tier. This violates the principle that each tier should only communicate with those immediately above on beneath it. It also reduces the deployment flexibility that is a key virtue of the distributed architecture. Now servers running the web tier must be able to access the database, which may necessitate special firewall rules. Note Even if we use remote interfaces, most J2EE servers can optimize out remote invocations and substitute call by reference if EJBs and components that use them are collocated. This may greatly reduce the performance impact of using EJBs with remote interfaces but cannot undo the harmful effects that remote semantics introduce. This configuration changes the semantics of the application. For this configuration to be used, its vital to ensure that the EJBs support local invocation (by reference) and remote invocation (by value). Otherwise, callers by reference may modify objects to be passed to other callers with serious consequences. Important Do not let the use of EJBs with remote interfaces cause an application to be distributed unless business requirements dictate a distributed architecture. 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 作者： 王毅 周峰 孫更新 來源： J2EE 經(jīng)典案例設(shè)計與實現(xiàn) ， 2007.4:179-181 譯文二 J2EE 項目的選擇與風險 企業(yè)級軟件項目通常很大，成本也很高。它們面對的挑戰(zhàn)可能會包括： 集成一個組織內(nèi)的資源。企業(yè)應(yīng)用軟件可能需要使用多種技術(shù)來訪問多個數(shù)據(jù)源和遺留系統(tǒng)。多種技術(shù)的集成本身就是有風險的。 處理像應(yīng)用服務(wù)器和數(shù)據(jù)庫之類的復雜產(chǎn)品。 滿足對服務(wù)、性能和可縮放性質(zhì)量的苛刻期望值。 開發(fā)和維護一個大型代碼庫。 給一個組織引進新技術(shù) 例如當給一個遺留應(yīng)用軟件賦予 WEB 能力時。有時，這些技術(shù)本身是新的，因而造成了它們可能是不熟悉或不成熟的風險。 具有不同技 能集的開發(fā)團隊的成功運作。 在一個競爭環(huán)境中實現(xiàn)快速的時間到市場。 J2EE 平臺幫助我們解決了企業(yè)軟件開發(fā)的許多問題。但是，選擇 J2EE 僅僅是許多選擇中的第一個。 在開發(fā)周期的早期（編寫任何代碼之前）所做出的選擇，對項目的成功與否以及投資的支配方式都有至關(guān)重要的影響。在項目的開始階段所采取的決策將決定項目開展方式。 對 J2EE 項目中的風險進行管理也是十分重要的，尤其是在涉及到集成的地方更是如此。 在本章中，我們除了討論 J2EE 項目中的軟件體系結(jié)構(gòu)之外，還討論部分重要的選擇。在這些選擇中，有許多選擇涉及到將隨 每個應(yīng)用軟件的需要而變化的折中方案。通常情況下，根本沒有單一的“正確”答案。我們將盡量涵蓋一些主要的問題，并討論決策制定過程，但具體的選擇將留給讀者自己來做出。 在有些項目中，這些選擇中的許多選擇將已成為 J2EE 策略的一部分。但是，參與此類項目的設(shè)計師和開發(fā)人員應(yīng)該熟悉本章中所討論的問題。 依據(jù)規(guī)范版本開發(fā)一個策略 要做出的第一個決策是貴組織對待規(guī)范和語言版本的態(tài)度。使用最新的 J2EE 和J2SE 特性是重要的嗎？這是增強特性集與成熟功能度之間的一個折中選擇。 決定性的因素將包括： 該應(yīng)用的性質(zhì) 小部分應(yīng)用可能 會從最新 J2SE 中獲得如此之大的利益，一致沒有可替代它們的方案。 該項目的期限 對于大型和期限長的項目來說，使策略依據(jù)新發(fā)布的特性并把應(yīng)用中需要新浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 特性的那些部分推遲到服務(wù)器支持更成熟之后再實現(xiàn)是完全可行的。對于短期項目來說，快速交付一個使用成熟技術(shù)的解決方案是最重要的。需要注意的是，使用一個期限長的項目依據(jù)非定性 J2EE 規(guī)范中的新技術(shù)是非常危險的，因此是不妥當?shù)模词乖诖嬖凇邦A覽”實現(xiàn)時。例如， EJB2。 0 規(guī)范在后續(xù)的公開草案中發(fā)生了根本性的變化。 該組織的性質(zhì) 一種“等到它工作為止”的方法可能適合對新技 術(shù)非?？粗氐慕M織，但可能不適合金融機構(gòu)或?qū)煽啃砸蠛芨叩钠渌M織。該組織在新技術(shù)方面的技能基礎(chǔ)在這里是另一個重要的考慮因素。 應(yīng)用服務(wù)器之間的可移植性 越靠后采用規(guī)范版本，可移植性可能回越成問題，因為實現(xiàn)相同規(guī)范級別的可替代服務(wù)器的選擇余地將會受限制。 版本選擇將既影響應(yīng)用服務(wù)器選擇，又受到應(yīng)用服務(wù)器選擇的影響。 在大型項目開發(fā)期間，有新的服務(wù)器或規(guī)范版本發(fā)布是可能的。當出現(xiàn)這種情況時，決定是否升級也很重要。如果新版本是一個故障糾正或識別版本，它可能值得做并且不太貴。如果它是一個重要升級，在采用之前應(yīng)該仔 細考慮，因為可能存在許多穩(wěn)情，比如不同的工具需求、新的服務(wù)器故障以及不同支持需求。跟上一個不斷移動的目標是很困難的，而且 J2EE 仍然在快速地發(fā)展。 要想最大限度地降低風險，應(yīng)該避開未經(jīng)證明的新技術(shù)，即使它們好象很有吸引力。一種安全的策略是在項目初期把 J2SE 和 J2EE 規(guī)范定為目標，因為它們得到了主流應(yīng)用服務(wù)器開發(fā)商的支持，盡管有些項目可能需要考慮未來的服務(wù)器發(fā)布時間表。 選擇應(yīng)用服務(wù)器 選擇一個 J2EE 應(yīng)用服務(wù)器是一個組織將要做出的、最重要的 IT 決策之一。采用J2EE 是一個戰(zhàn)略性決策，因此怎樣制定該決策將有 一個長期的影響。許多應(yīng)用服務(wù)器是很昂貴的，因而對大型安裝來說，需要很大數(shù)目的許可費用。不過，服務(wù)器的成本只是一部分。即使在選擇一個像 JBOSS 那樣的免費服務(wù)器時，我們?nèi)猿袚撕艽蟮呢熑?。超出許可費用或許可費用之外的開支可能包括： 培訓成本。服務(wù)器供應(yīng)商通常提供產(chǎn)品特有的培訓，而許多應(yīng)用服務(wù)器復雜得足以保證為關(guān)鍵職員購買培訓是值得的。不過，培訓常常是很貴的，除非培訓被提供為購買許可的一個激勵品。 咨詢費用。在熟悉應(yīng)用服務(wù)器時，從服務(wù)器供應(yīng)商或第三方那里購買咨詢服務(wù)可能是必不可少的。 任何支持成本。對于某些供應(yīng) 商，支持需要另外一份合同，并加上許可成本。 熟悉新服務(wù)器時生產(chǎn)力的損失，以及培訓或知道期間開發(fā)人員時間的損失。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 了解服務(wù)器市場定位的好處是不同的服務(wù)器適合不同的需求。產(chǎn)品性能和價格的比較很快就會變得過時，并容易讓人產(chǎn)生誤解，而且無法以圖書的形式保持最新。因此我們在這里將只討論做選擇時需要加以考慮的問題，而不是推薦或比較產(chǎn)品。在本節(jié)中，我們將了解如下內(nèi)容： 何時選擇應(yīng)用服務(wù)器 如何選擇應(yīng)用服務(wù)器 誰應(yīng)該選擇應(yīng)用服務(wù)器 需要注意的是，最終目的是整個組織在一個同意的應(yīng)用服務(wù)器上的標準化。在整個軟件周期內(nèi)維護多個應(yīng) 用服務(wù)器將會是十分昂貴的，而且應(yīng)該盡可能地避免。通常情況下，一個組織內(nèi)使用幾個不同的應(yīng)用服務(wù)器反映了過去的事物或缺少一個連貫的策略。 若一個組織內(nèi)運行了多個應(yīng)用服務(wù)器，少數(shù)幾個正當?shù)募夹g(shù)原因之一是，幾個應(yīng)用依賴于某一個特定的特性，而這個特性在通常使用的該應(yīng)用服務(wù)器中是不可獲得的。例如，一個應(yīng)用需要來自 J2EE 最新版本中的特性，因此它必須運行在一個最近發(fā)布的應(yīng)用服務(wù)器上時，而大多數(shù)應(yīng)用卻運行在一個已證明的應(yīng)用服務(wù)器上。在這種情況下，長期目標通常將是恢復到單個服務(wù)器的使用。 在許多情況下，應(yīng)用服務(wù)器在項目開始以 前將已被選定。例如，可能有一個關(guān)于應(yīng)用服務(wù)器選擇的組織級策略。在這種情況下，要盡量使用選定的服務(wù)器。不要引進另一個基于你或你的團隊所喜愛的服務(wù)器，以免使組織的技術(shù)混合變得復雜。如果選定的產(chǎn)品確實很次，并且放棄它更有現(xiàn)實意義，要通過游說來改變該選擇。 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 外文原文（二） J2EE Projects Choices and Risks Overview Enterprise software projects are often large and costly. The challenges they face may include: Integrating resources within an organization. Enterprise applications may need to access multiple data sources and legacy systems, using a variety of technologies. Integration of multiple technologies is inherently risky. Working with complex products such as application servers and databases. Meeting demanding expectations of quality of service, performance, and scalability. Developing and maintaining a large codebase. Introducing new technologies to an organization for example, when a legacy application is web-enabled. Sometimes the technologies are themselves new, posing a risk that they may be unfamiliar or immature. Successful running of teams with a disparate skill set. Achieving rapid time-to-market in a competitive environment. The J2EE platform helps us to address many of the problems of enterprise software development. However, choosing J2EE is just the first of many choices. Choices made early in the development lifecycle before any code has been written have a vital influence on the success or failure of projects, and how investment is directed. Decisions taken in the inception phase of a project will determine how it unfolds. It is also vital to manage risk in J2EE projects, especially where integration is involved. In this chapter, we discuss some of the most important choices, besides software architecture, in J2EE projects. Many of these choices involve tradeoffs that will vary with the needs of each application. Often there is no single right answer. We ll try to cover some major issues and discuss the decision making process, though particular choices will be left to the reader. In some projects, many of these choices will have already been made as part of an existing J2EE strategy. However, even architects and developers working on such projects should be familiar with the issues discussed in this chapter. Developing a Policy on Specification Versions The first decision to be made is your organizations attitude towards specification and 浙江工業(yè)大學之江學院畢業(yè)設(shè)計（論文）外文翻譯 language versions. Is it important to use the latest J2EE and J2SE features? This is a tradeoff between enhanced feature sets and proven functionality. Decisive factors will include: The nature of the application A minority of applications may benefit so much from the latest J2SE and J2EE features that there is little alternative to using them. The length of the project For a large and lengthy project, it may be possible to predicate strategy on new, published features and defer the implementation of those parts of the application that need them until server support is more mature. For a short project, it will be most important to deliver a solution quickly using proven technology. Note that predicating even a lengthy project on new features in non-final J2EE specifications is very risky, and therefore inadvisable, even when preview implementations exist. The EJB 2.0 specification, for example, changed radically in successive public drafts. The nature of the organization A wait until it works approach might be appropriate for an organization that prizes technological firsts, but inappropriate for a financial institution or other organization in which reliability is critical. The organizations skill base in the new technologies is another important consideration here. Portability between application servers The later the specification versions adopted, the more problematic portability is likely to prove, as the choice of alternative servers implementing the same specification level will be limited. Version choice will both influence and be influenced by the choice of application server. New server and specification releases are likely during the lifecycle of large projects. Its also important to decide whether to upgrade when this happens. If the new release is a bug fix or point release, it may be a worthwhile and inexpensive undertaking. If its a major upgrade, think carefully before committing, as there may be many implications, such as different tool requirements, new server bugs, and different support requirements. Its difficult to keep up with a moving target, and J2EE is still moving rapidly. Important To minimize risk, steer clear of new, unproven technologies, even