外文翻譯--j2ee體系結(jié)構(gòu)

1、<p>　　浙江工業(yè)大學(xué)之江學(xué)院</p><p>　　畢業(yè)設(shè)計(jì)（論文）外文翻譯</p><p>　　畢業(yè)設(shè)計(jì)（論文）題目：基于J2EE的企業(yè)電子投票系統(tǒng)開發(fā)與設(shè)計(jì) </p><p>　　外文翻譯（一）題目： J2EE體系結(jié)構(gòu) </p><p

2、>　　外文翻譯（二）題目： J2EE項(xiàng)目的選擇與風(fēng)險(xiǎn) </p><p>　　分院（系）： 信息工程分院 專 業(yè)：計(jì)算機(jī)科學(xué)與技術(shù) </p><p>　　班 級： 姓 名： </p><

3、;p>　　學(xué) 號： 指導(dǎo)教師： </p><p>　　畢業(yè)設(shè)計(jì)（論文）外文翻譯要求</p><p>　　1、畢業(yè)設(shè)計(jì)（論文）外文翻譯應(yīng)有兩篇，總字符數(shù)不少于20000，其文獻(xiàn)來源應(yīng)由指導(dǎo)教師選定后以紙質(zhì)（復(fù)印或打印件）形式隨同畢業(yè)設(shè)計(jì)（論文）任務(wù)書一并發(fā)給學(xué)生。復(fù)印或打印件上應(yīng)有指導(dǎo)教師和專業(yè)教研室主任的簽名和日期。要求每位學(xué)生的外文翻譯內(nèi)容

4、不重復(fù)。</p><p>　　2、翻譯的外文文獻(xiàn)應(yīng)主要選自學(xué)術(shù)期刊、學(xué)術(shù)會議的文章、有關(guān)著作及其他相關(guān)材料，應(yīng)與畢業(yè)論文（設(shè)計(jì)）主題相關(guān)，并列入畢業(yè)論文（設(shè)計(jì)）的參考文獻(xiàn)；在每篇中文譯文首頁“頁腳”處注明原文作者及出處，中文譯文后應(yīng)附外文原文（指導(dǎo)教師提供的原文，論文上應(yīng)有指導(dǎo)教師和教研室主任簽名）。</p><p>　　3、中文譯文的基本撰寫格式為：題目采用三號黑體字居中打印，正文采用宋

5、體小四號字，行間距一般為固定值20磅，標(biāo)準(zhǔn)字符間距。頁邊距為左3 cm，右2.5 cm，上下各2.5 cm，頁面統(tǒng)一采用A4紙。</p><p>　　4、封面上的“外文翻譯題目”指中文譯文的題目；兩篇外文文獻(xiàn)，按“封面、譯文一、外文原文（一）、譯文二、外文原文（二）、外文翻譯評閱表”的順序統(tǒng)一裝訂。</p><p><b>　　譯文一</b></p>&

6、lt;p><b>　　J2EE體系結(jié)構(gòu)</b></p><p>　　在討論了J2EE設(shè)計(jì)中的一些高層次問題之后，現(xiàn)在該來看一看J2EE應(yīng)用的幾個(gè)可選體系結(jié)構(gòu)。</p><p><b>　　常見概念</b></p><p>　　首先，讓我們來看一看所有J2EE體系結(jié)構(gòu)都共有的幾個(gè)概念。</p><p

7、>　　J2EE應(yīng)用中的體系結(jié)構(gòu)層</p><p>　　下面要討論的每個(gè)體系結(jié)構(gòu)都含有三個(gè)主要層，盡管有些體系結(jié)構(gòu)在中間層內(nèi)因如了另外的劃分。</p><p>　　經(jīng)驗(yàn)已經(jīng)證明了將企業(yè)級系統(tǒng)明確地劃分成多個(gè)層的價(jià)值。這確保了責(zé)任的明確劃分。</p><p>　　J2EE的3層體系結(jié)構(gòu)是各類系統(tǒng)中的經(jīng)驗(yàn)結(jié)晶。具有3個(gè)或3個(gè)以上層的系統(tǒng)已經(jīng)證明比其內(nèi)沒有中間層的客戶

8、-服務(wù)器系統(tǒng)具有更大的可縮放和靈活性。</p><p>　　在一個(gè)設(shè)計(jì)完備的多層系統(tǒng)中，每一層應(yīng)該只依賴于它下面的那一層。例如，對數(shù)據(jù)庫的更改不應(yīng)該要求對WEB接口的更改。 </p><p>　　每一層所特有的東西應(yīng)該向其他層隱藏起來。例如，WEB應(yīng)用中的WEB層只應(yīng)該依賴于服務(wù)器小程序API，而中間層只應(yīng)該依賴于JDBC之類的企業(yè)資源API。這兩個(gè)原則確保了應(yīng)用修改起來容易，同時(shí)修改又不

9、級聯(lián)到其他層。</p><p>　　下面依次來看典型的J2EE體系結(jié)構(gòu)的每一層。</p><p>　　企業(yè)信息系統(tǒng)（EIS）層</p><p>　　這一層有時(shí)也叫做綜合層（INTEGRATION TIER），由J2EE應(yīng)用完成其工作所必須訪問的企業(yè)資源所組成。這些資源包括數(shù)據(jù)庫管理系統(tǒng)（DBMS）和遺留的主機(jī)應(yīng)用。EIS層資源通常是事務(wù)性的，EIS位于J2EE服務(wù)

10、器的控制之外，盡管該服務(wù)器的確以一種標(biāo)準(zhǔn)方式管理事務(wù)和連接建池。</p><p>　　J2EE設(shè)計(jì)師對EIS層的設(shè)計(jì)與部署將是變化的，視該項(xiàng)目的性質(zhì)（現(xiàn)有服務(wù)的綠色場或集成度）而定。如果該項(xiàng)目包含現(xiàn)有服務(wù)的集成，EIS層資源可能會影響中間層的實(shí)現(xiàn)。</p><p>　　J2EE為與EIS層資源的借口提供了強(qiáng)有力的能力，比如訪問關(guān)系數(shù)據(jù)庫的JDBC API、訪問目錄服務(wù)器的JNDI以及允許連

11、接其他EIS系統(tǒng)的JACA CONNECTOR ARCHITECTURE （JACA連接器體系結(jié)構(gòu)，簡稱JCA）。J2EE服務(wù)器負(fù)責(zé)建立連往EIS資源的連接池、橫跨資源上的事務(wù)管理以及保證J2EE應(yīng)用不危及EIS系統(tǒng)的安全。</p><p><b>　　中間層</b></p><p>　　這一層含有應(yīng)用的業(yè)務(wù)對象，并調(diào)停對EIS層資源的訪問。中間層構(gòu)件主要從事務(wù)管理和

12、連接建池之類的J2EE容器服務(wù)中受益。中間層構(gòu)件獨(dú)立于選定的用戶接口。</p><p>　　如果使用了EJB，我們把中間層分離成兩層：EJB以及使用這些EJB來支持該接口的對象。但是，這種分離不是保證一個(gè)干凈中間層所必須的。</p><p><b>　　用戶接口（UI）層</b></p><p>　　這一層將中間業(yè)務(wù)對象暴露給用戶。在WEB應(yīng)用

13、中，UI層由服務(wù)器小程序所使用的助手類以及諸如JSP頁之類的試圖構(gòu)件所組成。為了清楚起見，我們在討論WEB應(yīng)用時(shí)將把UI層稱做“WEB層”。</p><p><b>　　業(yè)務(wù)接口的重要性</b></p><p>　　許多人將EJB看做J2EE應(yīng)用的核心。從J2EE的EJB中心論角度看，會話EJB將暴露應(yīng)用的業(yè)務(wù)邏輯，而其他對象（比如Business Delegate

14、J2EE設(shè)計(jì)模式中的Web層“業(yè)務(wù)委托”對象）將由他們與EJB的關(guān)系來確定。但是，這種假設(shè)將一種技術(shù)（EJB）抬高到了OO設(shè)計(jì)考慮之上。</p><p>　　EJB不是在J2EE應(yīng)用中實(shí)現(xiàn)中間層的唯一技術(shù)。</p><p>　　正式業(yè)務(wù)接口層的概念體現(xiàn)了一不好的習(xí)慣，不管是不是使用了EJB，我們都應(yīng)該使用這個(gè)概念。在下面將要討論的所有體系結(jié)構(gòu)中，業(yè)務(wù)接后層都有客戶（比如UI層）直接使用的中

15、間層接口所組成。業(yè)務(wù)接口層為普通Java接口中的中間層定義了聯(lián)系人；因此，EJB就是一個(gè)實(shí)現(xiàn)策略。如果我們沒有使用EJB，業(yè)務(wù)接口的實(shí)現(xiàn)將是運(yùn)行在J2EE Web容器中的普通Java對象。當(dāng)使用了EJB時(shí)，業(yè)務(wù)接口的實(shí)現(xiàn)將隱藏掉與EJB層的交互。</p><p>　　一定要設(shè)計(jì)到Java接口，而不要設(shè)計(jì)到具體類，也不要設(shè)計(jì)到技術(shù)。</p><p>　　下面來看一下滿足不同需求的4種J2EE

16、體系結(jié)構(gòu)。</p><p><b>　　非分布式體系結(jié)構(gòu)</b></p><p>　　下面的這些體系結(jié)構(gòu)適合Web應(yīng)用。他們可以把所有應(yīng)用構(gòu)件只運(yùn)行在單個(gè)JVM中。這使他們變得簡單而有效，但限制了部署的靈活性。</p><p>　　具有業(yè)務(wù)構(gòu)件接口的Web應(yīng)用</p><p>　　在大多數(shù)情況下，J2EE用來構(gòu)造Web應(yīng)

17、用。因此，同一個(gè)J2EE Web容器可以提供許多應(yīng)用所需要的整個(gè)基礎(chǔ)結(jié)構(gòu)。</p><p>　　和EJB一樣，J2EE Web應(yīng)用實(shí)際上享有對企業(yè)API的相同訪問權(quán)。它們受益于J2EE服務(wù)器的事務(wù)管理和連接池能力，并可以使用JMS,JDBC和Java Connector API之類的企業(yè)服務(wù)。除實(shí)體組件之外的所有數(shù)據(jù)存取技術(shù)都是可以使用的。</p><p>　　Web應(yīng)用的Web層和中間層

18、運(yùn)行在同一個(gè)JVM中。但是，在邏輯上使他們保持不同是極其重要的。Web應(yīng)用中的主要設(shè)計(jì)風(fēng)險(xiǎn)是UI構(gòu)件與業(yè)務(wù)邏輯構(gòu)件之間的責(zé)任模糊不清。</p><p>　　業(yè)務(wù)接口層將由普通Java類所實(shí)現(xiàn)的Java接口來組成。這是一個(gè)簡單而又可縮放的體系結(jié)構(gòu)，并且能滿足大多數(shù)應(yīng)用的需要。</p><p><b>　　長處</b></p><p>　　這種體系

19、結(jié)構(gòu)具有下列優(yōu)點(diǎn)：</p><p>　　簡單性。這通常是Web應(yīng)用的最簡單結(jié)構(gòu)。但是，如果事務(wù)管理或線程化問題要求開發(fā)分復(fù)雜的代碼，使用EJB可能將更簡單。</p><p>　　速度。這樣的體系結(jié)構(gòu)遇到了來自J2EE服務(wù)器的最小系統(tǒng)開銷。</p><p>　　OO設(shè)計(jì)不會被J2EE構(gòu)件問題（比如調(diào)用EJB的影響）所妨礙。</p><p>　　

20、容易測試。如果設(shè)計(jì)合理，無需Web層就能夠?qū)I(yè)務(wù)接口進(jìn)行測試。</p><p>　　我們可以發(fā)揮服務(wù)器的事務(wù)支持。</p><p>　　縮放性很好。如果Web接口是無狀態(tài)的，則根本不需要來自容器的聚類支持。但是，Web應(yīng)用可以通過使用服務(wù)器支持會話狀態(tài)復(fù)制來分布。</p><p><b>　　弱點(diǎn)</b></p><p>

21、;　　應(yīng)該注意下列這些缺點(diǎn)：</p><p>　　這種體系結(jié)構(gòu)只支持一個(gè)Web接口。例如，它不能支持獨(dú)立的GUI客戶（中間層和這個(gè)Web接口在同一個(gè)JVM中）。但是，正如我們稍后將回看到的，可以增加一個(gè)Web服務(wù)層。</p><p>　　整個(gè)應(yīng)用僅運(yùn)行在單個(gè)JVM中。雖然這提高了性能，但我們無法將構(gòu)件自由地分配給不同的物理服務(wù)器。</p><p>　　這種體系結(jié)構(gòu)不

22、能使用EJB容器事務(wù)支持。我們將需要在應(yīng)用代碼中創(chuàng)建和管理事務(wù)。</p><p>　　服務(wù)器沒有提供對并發(fā)編程的支持。我們必須親自處理線程化問題，或使用一個(gè)解決常見問題的類庫，比如util.concurrent。</p><p>　　將實(shí)體組件用于數(shù)據(jù)存取是不可能的，但可以證明的是，這根本不是什么損失。</p><p>　　訪問本地EJB的Web應(yīng)用</p&g

23、t;<p>　　Servlet2.3規(guī)范（SRV9.11）可從http://java.sun.com/products/servlet/download.html站點(diǎn)上獲得。如果一個(gè)應(yīng)用被部署在一個(gè)集成的J2EE應(yīng)用服務(wù)器中且該服務(wù)器運(yùn)行在單個(gè)JVM中，該規(guī)范通過本地接口來保證EJB的Web層對象訪問。這使我們技能從一個(gè)EJB容器中得到好處，又不至于招致過度的復(fù)雜性或把我們的應(yīng)用變成分布式的。</p><

24、;p>　　在這種體系結(jié)構(gòu)中，Web層與剛討論過繁榮Web應(yīng)用體系結(jié)構(gòu)的Web層相同。業(yè)務(wù)接口也是相同的；這兩種體系結(jié)構(gòu)的不同之處從它們的出現(xiàn)（EJB層）開始。因此，中間層被劃分成了兩部分（運(yùn)行在Web容器中的業(yè)務(wù)接口和EJB），但這兩部分運(yùn)行在同一個(gè)JVM中。</p><p>　　有兩種方法可以用來實(shí)現(xiàn)業(yè)務(wù)接口：</p><p>　　代理方法。在這種方法中，一個(gè)本地EJB直接實(shí)現(xiàn)業(yè)務(wù)

25、接口，而Web容器代碼被賦予一個(gè)對該EJB的本地接口的引用，同時(shí)無需處理必不可少的JNDI查找。</p><p>　　業(yè)務(wù)委托方法。在這種方法中，業(yè)務(wù)接口的Web容器實(shí)現(xiàn)明確地托付給相應(yīng)的EJB。這具有允許高速緩存和允許故障操作在適當(dāng)?shù)攸c(diǎn)被重試的優(yōu)點(diǎn)。</p><p>　　我們無需擔(dān)心上述任一情況中的java.rmi.RemoteException捕獲。傳輸錯(cuò)誤不會出現(xiàn)。</p>

26、;<p>　　在這種體系結(jié)構(gòu)中，和通過EJB來暴露一個(gè)遠(yuǎn)程接口的體系結(jié)構(gòu)不同，EJB的使用僅僅是這種體系結(jié)構(gòu)的一個(gè)實(shí)現(xiàn)選擇而已，而不是一個(gè)基本特征。不用改變總體設(shè)計(jì)，也不用EJB，就可以實(shí)現(xiàn)任何一個(gè)業(yè)務(wù)接口。</p><p><b>　　長處</b></p><p>　　這種體系結(jié)構(gòu)具有如下這些優(yōu)點(diǎn)：</p><p>　　它沒有分

27、布式EJB應(yīng)用那么復(fù)雜。</p><p>　　EJB使用不更改應(yīng)用的基本設(shè)計(jì)。在這種體系結(jié)構(gòu)中，只使這樣一些對象成為EJB：它們需要一個(gè)EJB容器的那些服務(wù)。</p><p>　　EJB使用只強(qiáng)加相當(dāng)小的性能開銷，因?yàn)闆]有遠(yuǎn)程方法調(diào)用或串行化。</p><p>　　它提供EJB容器事務(wù)與線程管理的各種好處。</p><p>　　如果需要，它允

28、許我們使用實(shí)體組件。</p><p><b>　　弱點(diǎn)</b></p><p>　　這種體系結(jié)構(gòu)的缺點(diǎn)有如下這些：</p><p>　　它比純Web應(yīng)用更復(fù)雜。例如，它遇到EJB部署和類裝人復(fù)雜性。</p><p>　　它仍不能支持除一個(gè)Web接口之外的客戶，除非我們添加一個(gè)Web服務(wù)層。</p><

29、p>　　整個(gè)應(yīng)用仍運(yùn)行在單個(gè)JVM中，這意味著所有構(gòu)件都必須運(yùn)行在同一臺物理服務(wù)器上。</p><p>　　具有本地接口的EJB測試起來很困難。我們需要在J2EE服務(wù)器內(nèi)運(yùn)行測試案例（比如用服務(wù)器小程序）。</p><p>　　作為使用EJB的結(jié)果，仍存在一些調(diào)整對象設(shè)計(jì)的誘惑，即使含有本地接口，EJB調(diào)用仍慢于普通的方法調(diào)用，而且這可能會誘惑我們修改業(yè)務(wù)對象的自然粒度。</p

30、><p>　　有時(shí)，我們可能會決定把EJB引進(jìn)到一個(gè)沒有適應(yīng)它的體系結(jié)構(gòu)中。這可能是由“做可能管用的最簡單事情”的XP方法所造成的。例如，最初的需求可能沒有證明由EJB引入的復(fù)雜性是值得的，但后來增加的需求可能會提出使用EJB。</p><p>　　如果采用上面描述的業(yè)務(wù)構(gòu)件接口方法，引進(jìn)具有本地接口的EJB將不會引起問題。可以簡單地選擇應(yīng)該被實(shí)現(xiàn)成具有本地的代理EJB的那些業(yè)務(wù)構(gòu)件接口。&l

31、t;/p><p>　　引進(jìn)具有遠(yuǎn)程接口的EJB可能有較大疑問，因?yàn)檫@不僅僅是一個(gè)引進(jìn)EJB的問題，而且也是一個(gè)從根本上改變了應(yīng)用的性質(zhì)的問題。例如，可能需要使業(yè)務(wù)接口粒度變的更粗，以避免“羅嗦的”調(diào)用和實(shí)現(xiàn)足夠的性能。我們還可能需要把所有業(yè)務(wù)邏輯實(shí)現(xiàn)轉(zhuǎn)移到EJB容器內(nèi)部。</p><p><b>　　分布式體系結(jié)構(gòu)</b></p><p>　　下面

32、這兩種體系結(jié)構(gòu)除了支持Web應(yīng)用之外，還支持遠(yuǎn)程客戶。</p><p>　　具有遠(yuǎn)程EJB的分布式應(yīng)用</p><p>　　這種體系結(jié)構(gòu)被廣泛地看做“經(jīng)典的”J2EE體系結(jié)構(gòu)。它提供了這樣一種能力：通過給EJB及使用EJB的構(gòu)件（比如 Web構(gòu)件）使用不同的JVM來物理和邏輯地劃分中間層。這是一個(gè)復(fù)雜的體系結(jié)構(gòu)，并具有顯著的性能開銷。</p><p>　　雖然描述了

33、一個(gè)Web應(yīng)用，但該體系結(jié)構(gòu)可以支持任一J2EE客戶類型。它特別符合獨(dú)立客戶應(yīng)用的需要。</p><p>　　該體系結(jié)構(gòu)在UI層（或者說其他遠(yuǎn)程客戶）與業(yè)務(wù)對象之間使用RMI，而這些業(yè)務(wù)對象被暴露為WJB（RMI通信的細(xì)節(jié)由EJB容器來隱藏，但我們?nèi)孕枰幚硎褂盟鶐淼挠绊懀＿@使遠(yuǎn)程調(diào)用變成了一個(gè)主要的性能決定要素和一個(gè)核心的設(shè)計(jì)考慮因素。我們必須盡量最大限度的減少遠(yuǎn)程調(diào)用的數(shù)量（避免“羅嗦的”調(diào)用）。在EJ

34、B與EJB客戶層之間傳遞的所有對象都必須是可串行化的，而且我們必須處理更復(fù)雜的錯(cuò)誤處理需求。</p><p>　　該體系結(jié)構(gòu)中的WEB層和上面所討論的那些結(jié)構(gòu)中的WEB層相同。但是，業(yè)務(wù)接口的實(shí)現(xiàn)將處理對（可能是遠(yuǎn)程）EJB容器中的EJB的遠(yuǎn)程訪問。在已討論過的用于本地EJB的兩種連通性方法（代理和業(yè)務(wù)委托）中，只有業(yè)務(wù)委托在這里是有用的，因?yàn)镋JB遠(yuǎn)程接口上的所有方法都拋出JAVAX。RMI。REMOTEEXC

35、EPTION。這是一個(gè)已檢查異常，否則REMOTEEXCEPTION將需要在UI層代碼中被捕獲。這把它不正確地束縛到了一個(gè)EJB實(shí)現(xiàn)上。</p><p>　　EJB層將單獨(dú)負(fù)責(zé)與EIS層資源的通信，而且應(yīng)該含有應(yīng)用的業(yè)務(wù)邏輯。</p><p><b>　　長處</b></p><p>　　這種通信結(jié)構(gòu)具有如下這些特有的優(yōu)點(diǎn)</p>

36、<p>　　它可以通過提供一個(gè)共享的中間層來支持所有J2EE客戶類型</p><p>　　它允許應(yīng)用構(gòu)件在不同物理服務(wù)器上的分布。如果EJB層是無狀態(tài)，這個(gè)特點(diǎn)特別管用，進(jìn)而允許使用無狀態(tài)的會話EJB。含有有狀態(tài)UI層和無狀態(tài)中間層的應(yīng)用將會從這種部署選擇中獲得最大的好處，而且將會給J2EE應(yīng)用實(shí)現(xiàn)盡可能大的縮放性。</p><p><b>　　弱點(diǎn)</b>

37、;</p><p>　　這種體系結(jié)構(gòu)的弱點(diǎn)有如下這些：</p><p>　　這是我們已討論過的最復(fù)雜的方法，如果這種復(fù)雜性確定是業(yè)務(wù)需求的合理要求，很可能會導(dǎo)致整個(gè)項(xiàng)目周期內(nèi)的資源浪費(fèi)，并為故障提供一個(gè)滋生地。</p><p>　　它影響性能。遠(yuǎn)程方法調(diào)用會比使用引用的本地調(diào)用慢數(shù)百倍，總體性能方面的影響結(jié)果取決與必須的遠(yuǎn)程調(diào)用數(shù)量。</p><

38、p>　　分布式應(yīng)用的測試和測試變得很困難。</p><p>　　所有業(yè)務(wù)構(gòu)件都必須進(jìn)行EJB容器中。雖然這為遠(yuǎn)程客戶提供了一個(gè)綜合性接口，但如果EJB不能用來解決業(yè)務(wù)需求所引起的每個(gè)問題，這是有問題的。例如，如果SIN-GLETON設(shè)計(jì)模式完全適用，用EJB滿意地實(shí)現(xiàn)起來將會很困難。</p><p>　　OO設(shè)計(jì)被RMI的集中使用所嚴(yán)重阻礙。</p><p>

39、　　異常處理在分布式系統(tǒng)中變得更復(fù)雜。我們除了必須考慮應(yīng)用故障外，還必須兼顧傳輸故障。</p><p>　　當(dāng)使用這種體系結(jié)構(gòu)，千萬不要破壞它。SUN JAVA CENTER的“FAST LANE READER”J2EE模式主張從WEB層中執(zhí)行只讀JDBC訪問，以便最小化通過EJB層進(jìn)行調(diào)用的系統(tǒng)開銷。這違背了每個(gè)層只應(yīng)該跟直接位于它下面的那些層進(jìn)行通信的原則，也降低了縫補(bǔ)式體系結(jié)構(gòu)的一個(gè)重要優(yōu)點(diǎn)；部署靈活性。現(xiàn)

40、在，運(yùn)行WEB層的服務(wù)器必須能夠訪問數(shù)據(jù)庫，而這會使特殊的防火墻規(guī)則車工內(nèi)為必須之物。</p><p>　　即使我們使用了遠(yuǎn)程接口，如果EJB及使用EJB的構(gòu)件被放在了一起，那么大多數(shù)J2EEE服務(wù)器仍能優(yōu)化遠(yuǎn)程調(diào)用并替換按引用的調(diào)用。這可以極大地減少使用具有遠(yuǎn)程接口的EJB所造成的性能影響，但無法消除遠(yuǎn)程語義所因如的有害影響。這種配置更改了應(yīng)用的語句。要想讓這種配置得到使用，關(guān)鍵是保證EJB支持本地調(diào)用（按引用

41、）和遠(yuǎn)程調(diào)用（按值）。否則按引用的調(diào)用者可能會修改要傳遞其他調(diào)用者的對象，進(jìn)而產(chǎn)生嚴(yán)重的后果。</p><p>　　不要因?yàn)槭褂昧司哂羞h(yuǎn)程借口的EJB導(dǎo)致一個(gè)應(yīng)用變成分布式的，除非業(yè)務(wù)需求明確指出需要一個(gè)分布式體系結(jié)構(gòu)。</p><p><b>　　外文原文（一）</b></p><p>　　J2EE Architectures</p&g

42、t;<p>　　Now that we've discussed some of the high-level issues in J2EE design, let's look at some alternative architecture for J2EE applications.</p><p>　　Common Concepts</p><p>　

43、　First, let's consider some concepts shared by all J2EE architectures.</p><p>　　Architectural Tiers in J2EE Applications</p><p>　　Each of the architectures discussed below involves three maj

44、or tiers, although some introduce an additional division within the middle tier.</p><p>　　Experience has shown the value of cleanly dividing enterprise systems into multiple tiers. This ensures a clean divis

45、ion of responsibility.</p><p>　　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 cli

46、ent server systems, in which there is no middle tier.</p><p>　　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 deman

47、d changes to the web interface.</p><p>　　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 o

48、nly 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.</p><p>　　Let's loo

49、k at each tier of a typical J2EE architecture in turn.</p><p>　　Enterprise Information System (EIS) Tier</p><p>　　Sometimes called the Integration Tier, this tier consists of the enterprise reso

50、urces 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 c

51、ontrol of the J2EE server, although the server does manage transactions and connection pooling in a standard way.</p><p>　　The J2EE architect's control over the design and deployment of the EIS tier will

52、 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

53、 middle tier.</p><p>　　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 the Java

54、 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

55、application doesn't compromise the security of the EIS system.</p><p>　　Middle Tier</p><p>　　This tier contains the application's business objects, and mediates access to EIS tier resour

56、ces. 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 th

57、e middle tier into two: EJBs, and objects that use the EJBs to support the interface. However, this split isn't necessary to ensure a clean middle tier.</p><p>　　User Interface (UI) Tier</p><p

58、>　　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, we'll ref

59、er to the UI tier as the "web tier" when discussing web applications.</p><p>　　The Importance of Business Interfaces</p><p>　　Many regard EJBs as the core of a J2EE application. In an

60、EJB-centric view of J2EE, session EJBs will expose the application's business logic, while other objects (such as "business delegate" objects in the web tier in the Business Delegate J2EE design pattern) wi

61、ll be defined by their relationship to the EJBs. This assumption, however, elevates a technology (EJB) above OO design considerations.</p><p>　　Important EJB is not the only technology for implementing the

62、middle tier in J2EE applications.</p><p>　　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 disc

63、uss 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 inter

64、faces; EJB is thus one implementation strategy. If we don't use EJB, the implementation of the business interfaces w</p><p>　　Important Design to Java interfaces, not concrete classes, and not technolog

65、ies.</p><p>　　Let's now look at four J2EE architectures that satisfy different requirements.</p><p>　　Non-distributed Architectures</p><p>　　The following architectures are suit

66、able 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.</p><p>　　Web Application with Business Compo

67、nent Interfaces</p><p>　　In most cases, J2EE is used to build web applications. Thus, a J2EE web container can provide the entire infrastructure required by many applications.</p><p>　　J2EE web

68、applications enjoy virtually the same access to enterprise APIs as EJBs. They benefit from the J2EE server's transaction management and connection pooling capabilities and can use enterprise services such as JMS, JDB

69、C, JavaMail, and the Java Connector API. All data access technologies are available with the exception of entity beans.</p><p>　　The web tier and middle tier of a web application run in the same JVM. However

70、, 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.</p><p>　　The business in

71、terface layer will consist of Java interfaces implemented by ordinary Java classes.</p><p>　　This is a simple yet scalable architecture that meets the needs of most applications.</p><p><b>

72、;　　Strengths</b></p><p>　　This architecture has the following strengths:</p><p>　　Simplicity. This is usually the simplest architecture for web applications. However, if transaction manage

73、ment or threading issues require the development of unduly complex code, it will probably prove simpler to use EJB.</p><p>　　Speed. Such architectures encounter minimal overhead from the J2EE server.</p&g

74、t;<p>　　OO design isn't hampered by J2EE component issues such as the implications of invoking EJBs.</p><p>　　Easy to test. With appropriate design, tests can be run against the business interface

75、 without the web tier.</p><p>　　We can leverage the server's transaction support.</p><p>　　Scales well. If the web interface is stateless, no clustering support is required from the containe

76、r. However, web applications can be distributed, using server support session state replication.</p><p>　　Weaknesses</p><p>　　The following drawbacks should be kept in mind:</p><p>

77、　　This architecture supports only a web interface. For example, it cannot support 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 sh

78、all see later.</p><p>　　The whole application runs within a single JVM. While this boosts performance, we cannot allocate components freely to different physical servers.</p><p>　　This architect

79、ure cannot use EJB container transaction support. We will need to create and manage transactions in application code.</p><p>　　The server provides no support for concurrent programming. We must handle thread

80、ing issues ourselves or use a class library such as util.concurrent that solves common problems.</p><p>　　It's impossible to use entity beans for data access. However, this is arguably no loss.</p>

81、<p>　　Web Application that Accesses Local EJBs</p><p>　　The Servlet 2.3 specification (SRV.9.11), which can be downloaded from http://java.sun.com/products/servlet/download.html, guarantees web-tier o

82、bjects 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

83、 incurring excessive complexity or making our application distributed.</p><p>　　In this architecture, the web tier is identical to that of the web application architecture we've just considered. The busi

84、ness 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 bot

85、h parts run within the same JVM.</p><p>　　Two approaches can be used to implement the business interfaces:</p><p>　　A proxy approach, in which a local EJB implements the business interface direc

86、tly and web container code is given a reference to the EJB's local interface, without needing to handle the necessary JNDI lookup.</p><p>　　A business delegate approach, in which the web-container implem

87、entation 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.</p><p>　　We don&#

88、39;t need to worry about catching java.rmi.RemoteException in either case. Transport errors cannot occur.</p><p>　　In this architecture, unlike an architecture exposing a remote interface via EJB, the use of

89、 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.</p><p>

90、<b>　　Strengths</b></p><p>　　This architecture has the following strengths:</p><p>　　It's less complex than a distributed EJB application.</p><p>　　EJB use doesn'

91、t alter the application's basic design. In this architecture, only make those objects EJBs that need the services of an EJB container.</p><p>　　EJB use imposes relatively little performance overhead as t

92、here is no remote method invocation or serialization.</p><p>　　It offers the benefits of EJB container transaction and thread management.</p><p>　　It allows the use of entity beans if desired.&l

93、t;/p><p>　　Weaknesses</p><p>　　Its drawbacks are as follows:</p><p>　　It's more complex than a pure web application. For example, it encounters EJB deployment and class loading com

94、plexity.</p><p>　　It still cannot support clients other than a web interface unless we add a web services layer.</p><p>　　The whole application still runs within a single JVM, which means that a

95、ll components must run on the same physical server.</p><p>　　EJBs with local interfaces are hard to test. We need to run test cases within the J2EE server (for example, from servlets).</p><p>　　

96、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 o

97、f business objects.</p><p>　　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 possib

98、ly work". For example, the initial requirements might not justify the complexity introduced by EJB, but the addition of further requirements might suggest its use.</p><p>　　If we adopt the business comp

99、onent 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 interfa

100、ces.</p><p>　　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, b

101、usiness 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

102、EJB container.</p><p>　　Distributed Architectures</p><p>　　The following two architectures support remote clients as well as web applications.</p><p>　　Distributed Application with

103、Remote EJBs</p><p>　　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 com

104、ponents (such as web components) that use them. This is a complex architecture, with significant performance overhead:</p><p>　　Although the diagram shows a web application, this architecture can support any

105、 J2EE client type. It is particularly suited to the needs of standalone client applications.</p><p>　　This architecture uses RMI between the UI tier (or other remote clients) and the business objects, which

106、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