J2EE項(xiàng)目的選擇與風(fēng)險(xiǎn)外文翻譯@中英文翻譯@外文文獻(xiàn)翻譯

浙江工業(yè)大學(xué)之江學(xué)院 畢業(yè)設(shè)計(jì)（論文） 外文翻譯 畢業(yè)設(shè)計(jì)（論文）題目： 基于 J2EE 的企業(yè)電子投票系統(tǒng)開(kāi)發(fā)與設(shè)計(jì) 外文翻譯（一） 題目： J2EE 體系結(jié)構(gòu) 外文翻譯（二） 題目： J2EE 項(xiàng)目的選擇與風(fēng)險(xiǎn) 分院（系）： 信息工程分院 專 業(yè)： 計(jì)算機(jī)科學(xué)與技術(shù) 班 級(jí)： 0402 姓 名： 徐棟杰 學(xué) 號(hào)： 200420100219 指導(dǎo)教師： 馮志林 畢業(yè)設(shè)計(jì)（論文）外文翻譯要求 1、畢業(yè)設(shè)計(jì)（論文）外文翻譯應(yīng)有兩篇，總字符數(shù)不少于 20000，其文獻(xiàn)來(lái)源應(yīng)由指導(dǎo)教師選定后以紙質(zhì)（復(fù)印或打印件）形式隨同畢業(yè)設(shè)計(jì)（論文）任務(wù)書(shū)一并發(fā)給學(xué)生。復(fù)印或打印件上應(yīng)有指導(dǎo)教師和 專業(yè)教研室主任的簽名和日期。要求每位學(xué)生的外文翻譯內(nèi)容不重復(fù)。 2、翻譯的外文文獻(xiàn)應(yīng)主要選自學(xué)術(shù)期刊、學(xué)術(shù)會(huì)議的文章、有關(guān)著作及其他相關(guān)材料，應(yīng)與畢業(yè)論文（設(shè)計(jì)）主題相關(guān)，并列入畢業(yè)論文（設(shè)計(jì)）的參考文獻(xiàn) ； 在每篇中文譯文首頁(yè) “ 頁(yè)腳”處 注明原文作者及出處，中文譯文后應(yīng)附外文原文 （指導(dǎo)教師提供的原文，論文上應(yīng)有指導(dǎo)教師和教研室主任簽名） 。 3、中文譯文的基本撰寫(xiě)格式為 ： 題目采用三號(hào)黑體字居中打印，正文采用宋體小四號(hào)字，行間距一般為固定值 20 磅，標(biāo)準(zhǔn)字符間距。頁(yè)邊距為左 3 cm，右 2.5 cm，上下各 2.5 cm，頁(yè)面統(tǒng)一采用 A4 紙。 4、 封面上的 “外文 翻譯題目” 指中文譯文的題目 ； 兩篇外文文獻(xiàn)， 按“ 封面、譯文一、外文原文 （ 一 ） 、譯文二、外文原文 （ 二 ）、外文翻譯評(píng)閱表 ” 的順序統(tǒng)一裝訂。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 作者： 美 亨特 美 羅夫特斯 來(lái)源： 精通 J2EE(Java 企業(yè)級(jí)應(yīng)用 )， 2004.7： 23-28 譯文一 J2EE體系結(jié)構(gòu) 在討論了 J2EE設(shè)計(jì)中的一些高層次問(wèn)題之后，現(xiàn)在該來(lái)看一看 J2EE應(yīng)用的幾個(gè)可選體系結(jié)構(gòu)。 常見(jiàn)概念 首先，讓我們來(lái)看一看所有 J2EE體系結(jié)構(gòu)都共有的幾個(gè)概念。 J2EE應(yīng)用中的體系結(jié)構(gòu)層 下面要討論的每個(gè)體系結(jié)構(gòu)都含有三個(gè)主要層，盡管有些體系結(jié)構(gòu)在中間層內(nèi)因如了另外的劃分。 經(jīng)驗(yàn)已經(jīng)證明了將企業(yè)級(jí)系統(tǒng)明 確地劃分成多個(gè)層的價(jià)值。這確保了責(zé)任的明確劃分。 J2EE的 3層體系結(jié)構(gòu)是各類系統(tǒng)中的經(jīng)驗(yàn)結(jié)晶。具有 3個(gè)或 3個(gè)以上層的系統(tǒng)已經(jīng)證明比其內(nèi)沒(méi)有中間層的客戶 -服務(wù)器系統(tǒng)具有更大的可縮放和靈活性。 在一個(gè)設(shè)計(jì)完備的多層系統(tǒng)中，每一層應(yīng)該只依賴于它下面的那一層。例如，對(duì)數(shù)據(jù)庫(kù)的更改不應(yīng)該要求對(duì) WEB接口的更改。 每一層所特有的東西應(yīng)該向其他層隱藏起來(lái)。例如， WEB 應(yīng)用中的 WEB 層只應(yīng)該依賴于服務(wù)器小程序 API，而中間層只應(yīng)該依賴于 JDBC 之類的企業(yè)資源 API。這兩個(gè)原則確保了應(yīng)用修改起來(lái)容易，同時(shí)修改又不 級(jí)聯(lián)到其他層。 下面依次來(lái)看典型的 J2EE 體系結(jié)構(gòu)的每一層。 企業(yè)信息系統(tǒng)（ EIS）層 這一層有時(shí)也叫做綜合層（ INTEGRATION TIER），由 J2EE 應(yīng)用完成其工作所必須訪問(wèn)的企業(yè)資源所組成。這些資源包括數(shù)據(jù)庫(kù)管理系統(tǒng)（ DBMS）和遺留的主機(jī)應(yīng)用。EIS 層資源通常是事務(wù)性的， EIS 位于 J2EE 服務(wù)器的控制之外，盡管該服務(wù)器的確以一種標(biāo)準(zhǔn)方式管理事務(wù)和連接建池。 J2EE 設(shè)計(jì)師對(duì) EIS 層的設(shè)計(jì)與部署將是變化的，視該項(xiàng)目的性質(zhì)（現(xiàn)有服務(wù)的綠色場(chǎng)或集成度）而定。如果該項(xiàng)目包含現(xiàn)有服務(wù)的集成， EIS 層資源 可能會(huì)影響中間層的實(shí)現(xiàn)。 J2EE 為與 EIS 層資源的借口提供了強(qiáng)有力的能力，比如訪問(wèn)關(guān)系數(shù)據(jù)庫(kù)的 JDBC API、訪問(wèn)目錄服務(wù)器的 JNDI 以及允許連接其他 EIS 系統(tǒng)的 JACA CONNECTOR ARCHITECTURE （ JACA 連接器體系結(jié)構(gòu)，簡(jiǎn)稱 JCA）。 J2EE 服務(wù)器負(fù)責(zé)建立連往 EIS資源的連接池、橫跨資源上的事務(wù)管理以及保證 J2EE 應(yīng)用不危及 EIS 系統(tǒng)的安全。 中間層 這一層含有應(yīng)用的業(yè)務(wù)對(duì)象，并調(diào)停對(duì) EIS 層資源的訪問(wèn)。中間層構(gòu)件主要從事務(wù)管理和連接建池之類的 J2EE 容器服務(wù)中受益。中間層構(gòu)件獨(dú) 立于選定的用戶接口。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 如果使用了 EJB，我們把中間層分離成兩層： EJB 以及使用這些 EJB 來(lái)支持該接口的對(duì)象。但是，這種分離不是保證一個(gè)干凈中間層所必須的。 用戶接口（ UI）層 這一層將中間業(yè)務(wù)對(duì)象暴露給用戶。在 WEB 應(yīng)用中， UI 層由服務(wù)器小程序所使用的助手類以及諸如 JSP 頁(yè)之類的試圖構(gòu)件所組成。為了清楚起見(jiàn)，我們?cè)谟懻?WEB應(yīng)用時(shí)將把 UI 層稱做“ WEB 層”。 業(yè)務(wù)接口的重要性 許多人將 EJB 看做 J2EE 應(yīng)用的核心。從 J2EE 的 EJB 中心論角度看，會(huì)話 EJB將暴露應(yīng)用的業(yè)務(wù)邏輯，而其他對(duì)象（比如 Business Delegate J2EE 設(shè)計(jì)模式中的Web 層“業(yè)務(wù)委托”對(duì)象）將由他們與 EJB 的關(guān)系來(lái)確定。但是，這種假設(shè)將一種技術(shù)（ EJB）抬高到了 OO 設(shè)計(jì)考慮之上。 EJB 不是在 J2EE 應(yīng)用中實(shí)現(xiàn)中間層的唯一技術(shù)。 正式業(yè)務(wù)接口層的概念體現(xiàn)了一不好的習(xí)慣，不管是不是使用了 EJB，我們都應(yīng)該使用這個(gè)概念。在下面將要討論的所有體系結(jié)構(gòu)中，業(yè)務(wù)接后層都有客戶（比如UI 層）直接使用的中間層接口所組成。業(yè)務(wù)接口層為普通 Java 接口中的中間層定義了聯(lián)系人；因此， EJB 就是一個(gè)實(shí)現(xiàn)策略。如果我們沒(méi)有使用 EJB，業(yè)務(wù)接口的實(shí)現(xiàn)將是運(yùn)行在 J2EE Web 容器中的普通 Java 對(duì)象。當(dāng)使用了 EJB 時(shí)，業(yè)務(wù)接口的實(shí)現(xiàn)將隱藏掉與 EJB 層的交互。 一定要設(shè)計(jì)到 Java 接口，而不要設(shè)計(jì)到具體類，也不要設(shè)計(jì)到技術(shù)。 下面來(lái)看一下滿足不同需求的 4 種 J2EE 體系結(jié)構(gòu)。 非分布式體系結(jié)構(gòu) 下面的這些體系結(jié)構(gòu)適合 Web 應(yīng)用。他們可以把所有應(yīng)用構(gòu)件只運(yùn)行在單個(gè) JVM中。這使他們變得簡(jiǎn)單而有效，但限制了部署的靈活性。 具有業(yè)務(wù)構(gòu)件接口的 Web 應(yīng)用 在大多數(shù)情況下， J2EE 用來(lái)構(gòu)造 Web 應(yīng)用。因此，同一個(gè) J2EE Web 容器可以提供許多應(yīng)用所需要的整個(gè)基礎(chǔ)結(jié) 構(gòu)。 和 EJB 一樣， J2EE Web 應(yīng)用實(shí)際上享有對(duì)企業(yè) API 的相同訪問(wèn)權(quán)。它們受益于J2EE 服務(wù)器的事務(wù)管理和連接池能力，并可以使用 JMS,JDBC 和 Java Connector API之類的企業(yè)服務(wù)。除實(shí)體組件之外的所有數(shù)據(jù)存取技術(shù)都是可以使用的。 Web 應(yīng)用的 Web 層和中間層運(yùn)行在同一個(gè) JVM 中。但是，在邏輯上使他們保持不同是極其重要的。 Web 應(yīng)用中的主要設(shè)計(jì)風(fēng)險(xiǎn)是 UI 構(gòu)件與業(yè)務(wù)邏輯構(gòu)件之間的責(zé)任模糊不清。 業(yè)務(wù)接口層將由普通 Java 類所實(shí)現(xiàn)的 Java 接口來(lái)組成。這是一個(gè)簡(jiǎn)單而又可縮放的體系結(jié)構(gòu)，并且 能滿足大多數(shù)應(yīng)用的需要。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 長(zhǎng)處 這種體系結(jié)構(gòu)具有下列優(yōu)點(diǎn)： 簡(jiǎn)單性。這通常是 Web 應(yīng)用的最簡(jiǎn)單結(jié)構(gòu)。但是，如果事務(wù)管理或線程化問(wèn)題要求開(kāi)發(fā)分復(fù)雜的代碼，使用 EJB 可能將更簡(jiǎn)單。 速度。這樣的體系結(jié)構(gòu)遇到了來(lái)自 J2EE 服務(wù)器的最小系統(tǒng)開(kāi)銷。 OO 設(shè)計(jì)不會(huì)被 J2EE 構(gòu)件問(wèn)題（比如調(diào)用 EJB 的影響）所妨礙。 容易測(cè)試。如果設(shè)計(jì)合理，無(wú)需 Web 層就能夠?qū)I(yè)務(wù)接口進(jìn)行測(cè)試。 我們可以發(fā)揮服務(wù)器的事務(wù)支持。 縮放性很好。如果 Web 接口是無(wú)狀態(tài)的，則根本不需要來(lái)自容器的聚類支持。但是， Web 應(yīng)用可以通過(guò)使用服務(wù)器支持會(huì)話 狀態(tài)復(fù)制來(lái)分布。 弱點(diǎn) 應(yīng)該注意下列這些缺點(diǎn)： 這種體系結(jié)構(gòu)只支持一個(gè) Web 接口。例如，它不能支持獨(dú)立的 GUI 客戶（中間層和這個(gè) Web 接口在同一個(gè) JVM 中）。但是，正如我們稍后將回看到的，可以增加一個(gè) Web 服務(wù)層。 整個(gè)應(yīng)用僅運(yùn)行在單個(gè) JVM 中。雖然這提高了性能，但我們無(wú)法將構(gòu)件自由地分配給不同的物理服務(wù)器。 這種體系結(jié)構(gòu)不能使用 EJB 容器事務(wù)支持。我們將需要在應(yīng)用代碼中創(chuàng)建和管理事務(wù)。 服務(wù)器沒(méi)有提供對(duì)并發(fā)編程的支持。我們必須親自處理線程化問(wèn)題，或使用一個(gè)解決常見(jiàn)問(wèn)題的類庫(kù)，比如 util.concurrent。 將實(shí)體組件用于數(shù)據(jù)存取是不可能的，但可以證明的是，這根本不是什么損失。 訪問(wèn)本地 EJB 的 Web 應(yīng)用 Servlet2.3 規(guī)范（ SRV9.11）可從 /products/servlet/download.html站點(diǎn)上獲得。如果一個(gè)應(yīng)用被部署在一個(gè)集成的 J2EE 應(yīng)用服務(wù)器中且該服務(wù)器運(yùn)行在單個(gè) JVM 中，該規(guī)范通過(guò)本地接口來(lái)保證 EJB 的 Web 層對(duì)象訪問(wèn)。這使我們技能從一個(gè) EJB 容器中得到好處，又不至于招致過(guò)度的復(fù)雜性或把我們的應(yīng)用變成分布式的。 在這種體系結(jié)構(gòu)中， Web 層與剛討論過(guò)繁榮 Web 應(yīng)用體系結(jié)構(gòu)的 Web 層相同。業(yè)務(wù)接口也是相同的；這兩種體系結(jié)構(gòu)的不同之處從它們的出現(xiàn)（ EJB 層）開(kāi)始。因此，中間層被劃分成了兩部分（運(yùn)行在 Web 容器中的業(yè)務(wù)接口和 EJB），但這兩部分運(yùn)行在同一個(gè) JVM 中。 有兩種方法可以用來(lái)實(shí)現(xiàn)業(yè)務(wù)接口： 代理方法。在這種方法中，一個(gè)本地 EJB 直接實(shí)現(xiàn)業(yè)務(wù)接口，而 Web 容器代碼被浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 賦予一個(gè)對(duì)該 EJB 的本地接口的引用，同時(shí) 無(wú)需處理必不可少的 JNDI 查找。 業(yè)務(wù)委托方法。在這種方法中，業(yè)務(wù)接口的 Web 容器實(shí)現(xiàn)明確地托付給相應(yīng)的EJB。這具有允許高速緩存和允許故障操作在適當(dāng)?shù)攸c(diǎn)被重試的優(yōu)點(diǎn)。 我們無(wú)需擔(dān)心上述任一情況中的 java.rmi.RemoteException 捕獲。傳輸錯(cuò)誤不會(huì)出現(xiàn)。 在這種體系結(jié)構(gòu)中，和通過(guò) EJB 來(lái)暴露一個(gè)遠(yuǎn)程接口的體系結(jié)構(gòu)不同， EJB 的使用僅僅是這種體系結(jié)構(gòu)的一個(gè)實(shí)現(xiàn)選擇而已，而不是一個(gè)基本特征。不用改變總體設(shè)計(jì)，也不用 EJB，就可以實(shí)現(xiàn)任何一個(gè)業(yè)務(wù)接口。 長(zhǎng)處 這種體系結(jié)構(gòu)具有如下這些優(yōu)點(diǎn)： 它沒(méi) 有分布式 EJB 應(yīng)用那么復(fù)雜。 EJB使用不更改應(yīng)用的基本設(shè)計(jì)。在這種體系結(jié)構(gòu)中，只使這樣一些對(duì)象成為 EJB：它們需要一個(gè) EJB 容器的那些服務(wù)。 EJB 使用只強(qiáng)加相當(dāng)小的性能開(kāi)銷，因?yàn)闆](méi)有遠(yuǎn)程方法調(diào)用或串行化。 它提供 EJB 容器事務(wù)與線程管理的各種好處。 如果需要，它允許我們使用實(shí)體組件。 弱點(diǎn) 這種體系結(jié)構(gòu)的缺點(diǎn)有如下這些： 它比純 Web 應(yīng)用更復(fù)雜。例如，它遇到 EJB 部署和類裝人復(fù)雜性。 它仍不能支持除一個(gè) Web 接口之外的客戶，除非我們添加一個(gè) Web 服務(wù)層。 整個(gè)應(yīng)用仍運(yùn)行在單個(gè) JVM 中，這意味著所有構(gòu)件都 必須運(yùn)行在同一臺(tái)物理服務(wù)器上。 具有本地接口的 EJB 測(cè)試起來(lái)很困難。我們需要在 J2EE 服務(wù)器內(nèi)運(yùn)行測(cè)試案例（比如用服務(wù)器小程序）。 作為使用 EJB 的結(jié)果，仍存在一些調(diào)整對(duì)象設(shè)計(jì)的誘惑，即使含有本地接口， EJB調(diào)用仍慢于普通的方法調(diào)用，而且這可能會(huì)誘惑我們修改業(yè)務(wù)對(duì)象的自然粒度。 有時(shí)，我們可能會(huì)決定把 EJB 引進(jìn)到一個(gè)沒(méi)有適應(yīng)它的體系結(jié)構(gòu)中。這可能是由“做可能管用的最簡(jiǎn)單事情”的 XP 方法所造成的。例如，最初的需求可能沒(méi)有證明由 EJB引入的復(fù)雜性是值得的，但后來(lái)增加的需求可能會(huì)提出使用 EJB。 如果采用上面描述 的業(yè)務(wù)構(gòu)件接口方法，引進(jìn)具有本地接口的 EJB 將不會(huì)引起問(wèn)題。可以簡(jiǎn)單地選擇應(yīng)該被實(shí)現(xiàn)成具有本地的代理 EJB 的那些業(yè)務(wù)構(gòu)件接口。 引進(jìn)具有遠(yuǎn)程接口的 EJB可能有較大疑問(wèn)，因?yàn)檫@不僅僅是一個(gè)引進(jìn) EJB的問(wèn)題，而且也是一個(gè)從根本上改變了應(yīng)用的性質(zhì)的問(wèn)題。例如，可能需要使業(yè)務(wù)接口粒度變的更粗，以避免“羅嗦的”調(diào)用和實(shí)現(xiàn)足夠的性能。我們還可能需要把所有業(yè)務(wù)邏輯浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 實(shí)現(xiàn)轉(zhuǎn)移到 EJB 容器內(nèi)部。 分布式體系結(jié)構(gòu) 下面這兩種體系結(jié)構(gòu)除了支持 Web 應(yīng)用之外，還支持遠(yuǎn)程客戶。 具有遠(yuǎn)程 EJB 的分布式應(yīng)用 這種體系結(jié)構(gòu)被廣泛地看 做“經(jīng)典的” J2EE 體系結(jié)構(gòu)。它提供了這樣一種能力：通過(guò)給 EJB 及使用 EJB 的構(gòu)件（比如 Web 構(gòu)件）使用不同的 JVM 來(lái)物理和邏輯地劃分中間層。這是一個(gè)復(fù)雜的體系結(jié)構(gòu)，并具有顯著的性能開(kāi)銷。 雖然描述了一個(gè) Web 應(yīng)用，但該體系結(jié)構(gòu)可以支持任一 J2EE 客戶類型。它特別符合獨(dú)立客戶應(yīng)用的需要。 該體系結(jié)構(gòu)在 UI 層（或者說(shuō)其他遠(yuǎn)程客戶）與業(yè)務(wù)對(duì)象之間使用 RMI，而這些業(yè)務(wù)對(duì)象被暴露為 WJB（ RMI 通信的細(xì)節(jié)由 EJB 容器來(lái)隱藏，但我們?nèi)孕枰幚硎褂盟鶐?lái)的影響）。這使遠(yuǎn)程調(diào)用變成了一個(gè)主要的性能決定要素和一個(gè)核心 的設(shè)計(jì)考慮因素。我們必須盡量最大限度的減少遠(yuǎn)程調(diào)用的數(shù)量（避免“羅嗦的”調(diào)用）。在 EJB 與 EJB 客戶層之間傳遞的所有對(duì)象都必須是可串行化的，而且我們必須處理更復(fù)雜的錯(cuò)誤處理需求。 該體系結(jié)構(gòu)中的 WEB 層和上面所討論的那些結(jié)構(gòu)中的 WEB 層相同。但是，業(yè)務(wù)接口的實(shí)現(xiàn)將處理對(duì)（可能是遠(yuǎn)程） EJB 容器中的 EJB 的遠(yuǎn)程訪問(wèn)。在已討論過(guò)的用于本地 EJB 的兩種連通性方法（代理和業(yè)務(wù)委托）中，只有業(yè)務(wù)委托在這里是有用的，因?yàn)?EJB 遠(yuǎn)程接口上的所有方法都拋出 JAVAX。 RMI。 REMOTEEXCEPTION。這是一個(gè)已檢查異 常，否則 REMOTEEXCEPTION 將需要在 UI 層代碼中被捕獲。這把它不正確地束縛到了一個(gè) EJB 實(shí)現(xiàn)上。 EJB 層將單獨(dú)負(fù)責(zé)與 EIS 層資源的通信，而且應(yīng)該含有應(yīng)用的業(yè)務(wù)邏輯。 長(zhǎng)處 這種通信結(jié)構(gòu)具有如下這些特有的優(yōu)點(diǎn) 它可以通過(guò)提供一個(gè)共享的中間層來(lái)支持所有 J2EE 客戶類型 它允許應(yīng)用構(gòu)件在不同物理服務(wù)器上的分布。如果 EJB 層是無(wú)狀態(tài)，這個(gè)特點(diǎn)特別管用，進(jìn)而允許使用無(wú)狀態(tài)的會(huì)話 EJB。含有有狀態(tài) UI 層和無(wú)狀態(tài)中間層的應(yīng)用將會(huì)從這種部署選擇中獲得最大的好處，而且將會(huì)給 J2EE 應(yīng)用實(shí)現(xiàn)盡可能大的縮放性。 弱點(diǎn) 這種體系結(jié)構(gòu)的弱點(diǎn)有如下這些： 這是我們已討論過(guò)的最復(fù)雜的方法，如果這種復(fù)雜性確定是業(yè)務(wù)需求的合理要求，很可能會(huì)導(dǎo)致整個(gè)項(xiàng)目周期內(nèi)的資源浪費(fèi)，并為故障提供一個(gè)滋生地。 它影響性能。遠(yuǎn)程方法調(diào)用會(huì)比使用引用的本地調(diào)用慢數(shù)百倍，總體性能方面的影響結(jié)果取決與必須的遠(yuǎn)程調(diào)用數(shù)量。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 分布式應(yīng)用的測(cè)試和測(cè)試變得很困難。 所有業(yè)務(wù)構(gòu)件都必須進(jìn)行 EJB容器中。雖然這為遠(yuǎn)程客戶提供了一個(gè)綜合性接口，但如果 EJB 不能用來(lái)解決業(yè)務(wù)需求所引起的每個(gè)問(wèn)題，這是有問(wèn)題的。例如，如果 SIN-GLETON 設(shè)計(jì)模式完全適用，用 EJB 滿意地 實(shí)現(xiàn)起來(lái)將會(huì)很困難。 OO 設(shè)計(jì)被 RMI 的集中使用所嚴(yán)重阻礙。 異常處理在分布式系統(tǒng)中變得更復(fù)雜。我們除了必須考慮應(yīng)用故障外，還必須兼顧傳輸故障。 當(dāng)使用這種體系結(jié)構(gòu)，千萬(wàn)不要破壞它。 SUN JAVA CENTER 的 “ FAST LANE READER”J2EE 模式主張從 WEB 層中執(zhí)行只讀 JDBC 訪問(wèn) ， 以便最小化通過(guò) EJB 層進(jìn)行調(diào)用的系統(tǒng)開(kāi)銷。這違背了每個(gè)層只應(yīng)該跟直接位于它下面的那些層進(jìn)行通信的原則，也降低了縫補(bǔ)式體系結(jié)構(gòu)的一個(gè)重要優(yōu)點(diǎn)；部署靈活性?，F(xiàn)在，運(yùn)行 WEB 層的服務(wù)器必須能夠訪問(wèn)數(shù)據(jù)庫(kù)，而這會(huì)使特殊的 防火墻規(guī)則車(chē)工內(nèi)為必須之物。 即使我們使用了遠(yuǎn)程接口，如果 EJB 及使用 EJB 的構(gòu)件被放在了一起，那么大多數(shù) J2EEE 服務(wù)器仍能優(yōu)化遠(yuǎn)程調(diào)用并替換按引用的調(diào)用。這可以極大地減少使用具有遠(yuǎn)程接口的 EJB 所造成的性能影響，但無(wú)法消除遠(yuǎn)程語(yǔ)義所因如的有害影響。這種配置更改了應(yīng)用的語(yǔ)句。要想讓這種配置得到使用，關(guān)鍵是保證 EJB 支持本地調(diào)用（按引用）和遠(yuǎn)程調(diào)用（按值）。否則按引用的調(diào)用者可能會(huì)修改要傳遞其他調(diào)用者的對(duì)象，進(jìn)而產(chǎn)生嚴(yán)重的后果。 不要因?yàn)槭褂昧司哂羞h(yuǎn)程借口的 EJB 導(dǎo)致一個(gè)應(yīng)用變成分布式的，除非業(yè)務(wù)需求明確指 出需要一個(gè)分布式體系結(jié)構(gòu)。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 外文原文 （ 一 ） 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 作者： 王毅 周峰 孫更新 來(lái)源： J2EE 經(jīng)典案例設(shè)計(jì)與實(shí)現(xiàn) ， 2007.4:179-181 譯文二 J2EE 項(xiàng)目的選擇與風(fēng)險(xiǎn) 企業(yè)級(jí)軟件項(xiàng)目通常很大，成本也很高。它們面對(duì)的挑戰(zhàn)可能會(huì)包括： 集成一個(gè)組織內(nèi)的資源。企業(yè)應(yīng)用軟件可能需要使用多種技術(shù)來(lái)訪問(wèn)多個(gè)數(shù)據(jù)源和遺留系統(tǒng)。多種技術(shù)的集成本身就是有風(fēng)險(xiǎn)的。 處理像應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)之類的復(fù)雜產(chǎn)品。 滿足對(duì)服務(wù)、性能和可縮放性質(zhì)量的苛刻期望值。 開(kāi)發(fā)和維護(hù)一個(gè)大型代碼庫(kù)。 給一個(gè)組織引進(jìn)新技術(shù) 例如當(dāng)給一個(gè)遺留應(yīng)用軟件賦予 WEB 能力時(shí)。有時(shí)，這些技術(shù)本身是新的，因而造成了它們可能是不熟悉或不成熟的風(fēng)險(xiǎn)。 具有不同技 能集的開(kāi)發(fā)團(tuán)隊(duì)的成功運(yùn)作。 在一個(gè)競(jìng)爭(zhēng)環(huán)境中實(shí)現(xiàn)快速的時(shí)間到市場(chǎng)。 J2EE 平臺(tái)幫助我們解決了企業(yè)軟件開(kāi)發(fā)的許多問(wèn)題。但是，選擇 J2EE 僅僅是許多選擇中的第一個(gè)。 在開(kāi)發(fā)周期的早期（編寫(xiě)任何代碼之前）所做出的選擇，對(duì)項(xiàng)目的成功與否以及投資的支配方式都有至關(guān)重要的影響。在項(xiàng)目的開(kāi)始階段所采取的決策將決定項(xiàng)目開(kāi)展方式。 對(duì) J2EE 項(xiàng)目中的風(fēng)險(xiǎn)進(jìn)行管理也是十分重要的，尤其是在涉及到集成的地方更是如此。 在本章中，我們除了討論 J2EE 項(xiàng)目中的軟件體系結(jié)構(gòu)之外，還討論部分重要的選擇。在這些選擇中，有許多選擇涉及到將隨 每個(gè)應(yīng)用軟件的需要而變化的折中方案。通常情況下，根本沒(méi)有單一的“正確”答案。我們將盡量涵蓋一些主要的問(wèn)題，并討論決策制定過(guò)程，但具體的選擇將留給讀者自己來(lái)做出。 在有些項(xiàng)目中，這些選擇中的許多選擇將已成為 J2EE 策略的一部分。但是，參與此類項(xiàng)目的設(shè)計(jì)師和開(kāi)發(fā)人員應(yīng)該熟悉本章中所討論的問(wèn)題。 依據(jù)規(guī)范版本開(kāi)發(fā)一個(gè)策略 要做出的第一個(gè)決策是貴組織對(duì)待規(guī)范和語(yǔ)言版本的態(tài)度。使用最新的 J2EE 和J2SE 特性是重要的嗎？這是增強(qiáng)特性集與成熟功能度之間的一個(gè)折中選擇。 決定性的因素將包括： 該應(yīng)用的性質(zhì) 小部分應(yīng)用可能 會(huì)從最新 J2SE 中獲得如此之大的利益，一致沒(méi)有可替代它們的方案。 該項(xiàng)目的期限 對(duì)于大型和期限長(zhǎng)的項(xiàng)目來(lái)說(shuō)，使策略依據(jù)新發(fā)布的特性并把應(yīng)用中需要新浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 特性的那些部分推遲到服務(wù)器支持更成熟之后再實(shí)現(xiàn)是完全可行的。對(duì)于短期項(xiàng)目來(lái)說(shuō)，快速交付一個(gè)使用成熟技術(shù)的解決方案是最重要的。需要注意的是，使用一個(gè)期限長(zhǎng)的項(xiàng)目依據(jù)非定性 J2EE 規(guī)范中的新技術(shù)是非常危險(xiǎn)的，因此是不妥當(dāng)?shù)?，即使在存在“預(yù)覽”實(shí)現(xiàn)時(shí)。例如， EJB2。 0 規(guī)范在后續(xù)的公開(kāi)草案中發(fā)生了根本性的變化。 該組織的性質(zhì) 一種“等到它工作為止”的方法可能適合對(duì)新技 術(shù)非常看重的組織，但可能不適合金融機(jī)構(gòu)或?qū)煽啃砸蠛芨叩钠渌M織。該組織在新技術(shù)方面的技能基礎(chǔ)在這里是另一個(gè)重要的考慮因素。 應(yīng)用服務(wù)器之間的可移植性 越靠后采用規(guī)范版本，可移植性可能回越成問(wèn)題，因?yàn)閷?shí)現(xiàn)相同規(guī)范級(jí)別的可替代服務(wù)器的選擇余地將會(huì)受限制。 版本選擇將既影響應(yīng)用服務(wù)器選擇，又受到應(yīng)用服務(wù)器選擇的影響。 在大型項(xiàng)目開(kāi)發(fā)期間，有新的服務(wù)器或規(guī)范版本發(fā)布是可能的。當(dāng)出現(xiàn)這種情況時(shí)，決定是否升級(jí)也很重要。如果新版本是一個(gè)故障糾正或識(shí)別版本，它可能值得做并且不太貴。如果它是一個(gè)重要升級(jí)，在采用之前應(yīng)該仔 細(xì)考慮，因?yàn)榭赡艽嬖谠S多穩(wěn)情，比如不同的工具需求、新的服務(wù)器故障以及不同支持需求。跟上一個(gè)不斷移動(dòng)的目標(biāo)是很困難的，而且 J2EE 仍然在快速地發(fā)展。 要想最大限度地降低風(fēng)險(xiǎn)，應(yīng)該避開(kāi)未經(jīng)證明的新技術(shù)，即使它們好象很有吸引力。一種安全的策略是在項(xiàng)目初期把 J2SE 和 J2EE 規(guī)范定為目標(biāo)，因?yàn)樗鼈兊玫搅酥髁鲬?yīng)用服務(wù)器開(kāi)發(fā)商的支持，盡管有些項(xiàng)目可能需要考慮未來(lái)的服務(wù)器發(fā)布時(shí)間表。 選擇應(yīng)用服務(wù)器 選擇一個(gè) J2EE 應(yīng)用服務(wù)器是一個(gè)組織將要做出的、最重要的 IT 決策之一。采用J2EE 是一個(gè)戰(zhàn)略性決策，因此怎樣制定該決策將有 一個(gè)長(zhǎng)期的影響。許多應(yīng)用服務(wù)器是很昂貴的，因而對(duì)大型安裝來(lái)說(shuō)，需要很大數(shù)目的許可費(fèi)用。不過(guò)，服務(wù)器的成本只是一部分。即使在選擇一個(gè)像 JBOSS 那樣的免費(fèi)服務(wù)器時(shí)，我們?nèi)猿袚?dān)了很大的責(zé)任。超出許可費(fèi)用或許可費(fèi)用之外的開(kāi)支可能包括： 培訓(xùn)成本。服務(wù)器供應(yīng)商通常提供產(chǎn)品特有的培訓(xùn)，而許多應(yīng)用服務(wù)器復(fù)雜得足以保證為關(guān)鍵職員購(gòu)買(mǎi)培訓(xùn)是值得的。不過(guò)，培訓(xùn)常常是很貴的，除非培訓(xùn)被提供為購(gòu)買(mǎi)許可的一個(gè)激勵(lì)品。 咨詢費(fèi)用。在熟悉應(yīng)用服務(wù)器時(shí)，從服務(wù)器供應(yīng)商或第三方那里購(gòu)買(mǎi)咨詢服務(wù)可能是必不可少的。 任何支持成本。對(duì)于某些供應(yīng) 商，支持需要另外一份合同，并加上許可成本。 熟悉新服務(wù)器時(shí)生產(chǎn)力的損失，以及培訓(xùn)或知道期間開(kāi)發(fā)人員時(shí)間的損失。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 了解服務(wù)器市場(chǎng)定位的好處是不同的服務(wù)器適合不同的需求。產(chǎn)品性能和價(jià)格的比較很快就會(huì)變得過(guò)時(shí)，并容易讓人產(chǎn)生誤解，而且無(wú)法以圖書(shū)的形式保持最新。因此我們?cè)谶@里將只討論做選擇時(shí)需要加以考慮的問(wèn)題，而不是推薦或比較產(chǎn)品。在本節(jié)中，我們將了解如下內(nèi)容： 何時(shí)選擇應(yīng)用服務(wù)器 如何選擇應(yīng)用服務(wù)器 誰(shuí)應(yīng)該選擇應(yīng)用服務(wù)器 需要注意的是，最終目的是整個(gè)組織在一個(gè)同意的應(yīng)用服務(wù)器上的標(biāo)準(zhǔn)化。在整個(gè)軟件周期內(nèi)維護(hù)多個(gè)應(yīng) 用服務(wù)器將會(huì)是十分昂貴的，而且應(yīng)該盡可能地避免。通常情況下，一個(gè)組織內(nèi)使用幾個(gè)不同的應(yīng)用服務(wù)器反映了過(guò)去的事物或缺少一個(gè)連貫的策略。 若一個(gè)組織內(nèi)運(yùn)行了多個(gè)應(yīng)用服務(wù)器，少數(shù)幾個(gè)正當(dāng)?shù)募夹g(shù)原因之一是，幾個(gè)應(yīng)用依賴于某一個(gè)特定的特性，而這個(gè)特性在通常使用的該應(yīng)用服務(wù)器中是不可獲得的。例如，一個(gè)應(yīng)用需要來(lái)自 J2EE 最新版本中的特性，因此它必須運(yùn)行在一個(gè)最近發(fā)布的應(yīng)用服務(wù)器上時(shí)，而大多數(shù)應(yīng)用卻運(yùn)行在一個(gè)已證明的應(yīng)用服務(wù)器上。在這種情況下，長(zhǎng)期目標(biāo)通常將是恢復(fù)到單個(gè)服務(wù)器的使用。 在許多情況下，應(yīng)用服務(wù)器在項(xiàng)目開(kāi)始以 前將已被選定。例如，可能有一個(gè)關(guān)于應(yīng)用服務(wù)器選擇的組織級(jí)策略。在這種情況下，要盡量使用選定的服務(wù)器。不要引進(jìn)另一個(gè)基于你或你的團(tuán)隊(duì)所喜愛(ài)的服務(wù)器，以免使組織的技術(shù)混合變得復(fù)雜。如果選定的產(chǎn)品確實(shí)很次，并且放棄它更有現(xiàn)實(shí)意義，要通過(guò)游說(shuō)來(lái)改變?cè)撨x擇。 浙江工業(yè)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 外文原文（二） 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è)大學(xué)之江學(xué)院畢業(yè)設(shè)計(jì)（論文）外文翻譯 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