jsp相關(guān)畢業(yè)設(shè)計(jì)外文翻譯

1、<p><b>　　外文資料</b></p><p><b>　　所譯外文資料：</b></p><p>　　① 作者：Dan Malks</p><p>　?、?書名：Professional JSP</p><p>　?、?出版時間: 2000.7.26</p><

2、p>　?、?所譯章節(jié): Chapter 12</p><p>　　12.1 Introductory</p><p>　　Good Web application design tries to separate business objects, presentation, and manipulation of the objects into distinct layers.

3、One benefit of using JavaServer Pages technology is that it allows us to separate the role of a Web designer more clearly from that of a software developer. While on a small-scale project, one individual may occupy both

4、roles, on a larger project, they are likely to be separate and it is beneficial to separate their workflows as much as possible. Designing the archi</p><p>　　12.2 JSP architecture</p><p>　　We wi

5、ll examine a variety of ways to architect a system with JavaServer Pages, servlets, and JavaBeans. We will see a series of different architectures, each a development of the one before. The diagram below shows this proce

6、ss in outline; the individual parts of the diagram will be explained in turn later in this article.</p><p>　　JSP architecture:</p><p>　　When Sun introduced Java Server Pages, some were quick to

7、claim that servlets had been replaced as the preferred request handling mechanism in Web-enabled enterprise architectures. Although JSP is a key component of the Java 2 Platform Enterprise Edition (J2EE) specification, s

8、erving as the preferred request handler and response mechanism, we must investigate further to understand its relationship with servlets. </p><p>　　Other sections of Professional JSP explain the implementati

9、on details of JSP source translation and compilation into a servlets. Understanding that JSP is built on top of the servlet API, and uses servlet semantics, raises some interesting questions. Should we no longer develop

10、stand-alone servlets in our Web-enabled systems? Is there some way to combine servlets and JSPs? If so, where do we place our Java code? Are there any other components involved in the request processing, such as JavaBean

11、s</p><p>　　It is important to understand that, although JSP technology will be a powerful successor to basic servlets, they have an evolutionary relationship and can be used in a cooperative and complementar

12、y manner. </p><p>　　Given this premise, we will investigate how these two technologies, each a Java Standard Extension, can be used co-operatively along with other components, such as JavaBeans, to create Ja

13、va-based Web-enabled systems. We will examine architectural issues as they relate to JSP and servlets and discuss some effective designs while looking at the tradeoffs of each. Before jumping directly into a discussion o

14、f specific architectures, though, we will briefly examine the need to develop a variety of ar</p><p>　　12.3 Code factoring and role separation</p><p>　　One of the main reasons why the JavaServer

15、 Pages technology has evolved into what it is today (and it's still evolving) is the overwhelming technical need to simplify application design by separating dynamic content from static template display data. The fou

16、ndation for JSP was laid down with the initial development of the Java Web Server from Sun, which used page compilation and focused on embedding HTML inside Java code. As applications came to be based more on business ob

17、jects and n-tier archi</p><p>　　In Chapter 5, JSP Sessions, in Professional JSP, we saw how beans and objects can be bound to different contexts just by defining a certain scope. Good application design buil

18、ds on this idea and tries to separate the objects, the presentation, and the manipulation of the objects into distinct, distinguishable layers. </p><p>　　Another benefit of using JSP is that it allows us to

19、more cleanly separate the roles of a Web production/HTML designer individual from a software developer. Remember that a common development scenario with servlets was to embed the HTML presentation markup within the Java

20、code of the servlet itself, which can be troublesome. In our discussion, we will consider the servlet solely as a container for Java code, while our entire HTML presentation template is encapsulated within a JSP source p

21、age. Th</p><p>　　Let's investigate this further. On any Web-based project, multiple roles and responsibilities will exist. For example, an individual who designs HTML pages fulfills a Web production role

22、 while someone who writes software in the Java programming language fulfills a software development role. </p><p>　　On small-scale projects these roles might be filled by the same individual, or two individu

23、als working closely together. On a larger project, they will likely be filled by multiple individuals, who might not have overlapping skill sets, and are less productive if made too dependent on the workflow of the other

24、. </p><p>　　If code that could be factored out to a mediating servlet is included instead within HTML markup, then the potential exists for individuals in the software development role and those in the Web p

25、roduction role to become more dependent than necessary on the progress and workflow of the other. Such dependencies may create a more error-prone environment, where inadvertent changes to code by other team members becom

26、e more common. </p><p>　　This gives us some insight into one reason why we continue to develop basic servlets: they are an appropriate container for our common Java code that has been factored out of our JSP

27、 pages, giving our software development team an area of focus that is as loosely coupled to our JSP pages as possible. Certainly, there will be a need for these same individuals to work with the JSP source pages, but the

28、 dependency is reduced, and these pages become the focus of the Web-production team instead. Of co</p><p>　　So, we should try to minimize the Java code that we include within our JSP page, in order to uphold

29、 this cleaner separation of developer roles. As we have discussed, some of this Java code is appropriately factored to a mediating servlet. Code that is common to multiple requests, such as authentication, is a good cand

30、idate for a mediating servlet. Such code is included in one place, the servlet, instead of potentially being cut and pasted into multiple JSPs. </p><p>　　We will also want to remove much of our business logi

31、c and data access code from our JSP page and encapsulate it within JavaBeans, called worker or helper beans. We start to see a pattern of code movement from our JSP into two areas: a servlet (or JSP) that sits in front o

32、f the main JSP, and JavaBeans that sit in back. We refer to this common pattern as "Factor Forward -- Factor Back," as shown in the figure below:</p><p>　　Factor Forward -- Factor Back: </p>

33、<p>　　Another way to think about what code should be localized and encapsulated is that our JSP page should reveal as little as possible of our Java code implementation details.</p><p>　　Rather, the pa

34、ge should communicate our intent by revealing the delegating messages we send to worker beans, instructing them to get state from a model, or to complete some business processing.</p><p>　　12.4 Redirecting a

35、nd forwarding</p><p>　　Redirecting and forwarding requests in JSPs and servlets takes place often, and it is important to understand the subtle difference between these two mechanisms even though they achiev

36、e the same goal (that is, a client asks for a resource on the server and a different resource is served to it): </p><p>　　When a servlet or JSP resource chooses to redirect the client (using a response.sendR

37、edirect(url)) the request object does not reach the second resource directly since the underlying implementation is an HTTP redirect. The server sends an HTTP 302 message back to the client telling it that the resource h

38、as moved to another URL, and that the client should access it there. The bottom line is that the lifecycle of the initial request object that was accessed in the first JSP terminates with the end</p><p>　　In

39、 a forward mechanism the request object is forwarded to the second resource, thus maintaining any object bindings to the request and its state, without a round trip to the client on the network. This allows the first JSP

40、 to do some work internally and then send information to the second JSP asking it to do its bit. (Servlets used a chaining mechanism to do this). See Chapter 5, JSP Sessions, in Professional JSP to get a clearer picture

41、of scope. JSPs and servlets can use the forwarding mechani</p><p>　　Now, let's investigate how we build these systems.</p><p>　　12.5 Architectures</p><p>　　Before discussing spe

42、cific architectures that we can use to build systems with servlets and JSP, it is worth mentioning two basic ways of using the JSP technology. Each of the architectures discussed in this chapter will be based on one of t

43、hese approaches: </p><p>　　The first method is referred to here as the page-centric (or client-server) approach. This approach involves request invocations being made directly to JSP page. </p><p&

44、gt;　　In the second method, the dispatcher (or n-tier) approach, a basic servlet or JSP acts as a mediator or controller, delegating requests to JSP pages and JavaBeans. </p><p>　　We will examine these approa

45、ches in light of a simple example, which will evolve to satisfy the requirements of various scenarios. The initial scenario involves providing a Web interface for guessing statistics about a soon-to-be-born baby. The gue

46、sses are stored, and can be reviewed later by the parents, to see who has guessed the closest. As the requirement scenarios become more sophisticated, such as adding the desire for a persistence mechanism, the solution s

47、cenarios will become more sophis</p><p>　　12.6 The page-centric approach </p><p>　　Applications built using a client-server approach have been around for some time; they consist of one or more a

48、pplication programs running on client machines and connecting to a server-based application to work. (A good example would be a PowerBuilder or Oracle Forms-based system.) CGIs and pre-servlet applications were generally

49、 based on this simple 2-tier model, and with the introduction of servlets, 2-tier applications could also be created in Java. </p><p>　　This model allows JSPs or servlets direct access to some resource like

50、a database or legacy application to service a client's request: the early JSP specifications termed this a "Model 1" programming approach. The JSP page is where the incoming request is intercepted and proce

51、ssed, and the response is sent back to the client;</p><p>　　JSPs only differed from servlets in this scenario by providing cleaner code and separating code from the content by placing data access in beans. &

52、lt;/p><p>　　Model 1 programming approach: </p><p>　　The advantage of such an approach is that it is siple to program,and allows the page author to Generate dynamic content easily,based upon the re

53、quest and the state resources.</p><p>　　However this architecture does not scale up well for a large number of simultaneous clients since there would be a significant amount of request processing to be perfo

54、rmed,and each request must establish or share a potentially scarce/expensive connection to the resource in question.(A good example would be JDBC connectons in servlets or JSPs and the need for connection pools.)</p&g

55、t;<p>　　Indiscriminate usage of this architecture usually leads to a significant amount of Java code embedded within the JSP page,this may not seem to be much of a problem for Java developers but it is certainly a

56、n issue if the JSP pages are maintained by designers:the code tends to get in the designe’s way,and you run the risk of your code becoming corrupted when others are tweaking the look and feel.</p><p><b&g

57、t;　　譯文</b></p><p><b>　　12.1前言</b></p><p>　　好的Web應(yīng)用設(shè)計(jì)試圖將業(yè)務(wù)對象，簡報(bào)以及操作對象分為不同的層面。采用JSP技術(shù)的一個好處在于它使我們更清楚地把Web設(shè)計(jì)者的作用從一個軟件開發(fā)商中分離出來。在小規(guī)項(xiàng)目中，單個體可能擔(dān)任著著兩個角色，在較大的項(xiàng)目中，他們可能被分開，盡可能地分開他們的工作流程是有好處

58、的，比如有利于自己的工作流程，且你的Web應(yīng)用設(shè)計(jì)結(jié)構(gòu)對這種分離是至關(guān)重要的。</p><p>　　12.2 JSP的結(jié)構(gòu)</p><p>　　我們將研究采取各種方式來設(shè)計(jì)利用關(guān)于JSP的結(jié)構(gòu)層次，還有Servlets以及JavaBeans技術(shù)。我們將看到一系列不同的結(jié)構(gòu)，一個一個地形成。下面的圖示顯示了這一過程，個別圖示將于稍后在這篇文章中作了解釋。</p><p&g

59、t;<b>　　JSP的結(jié)構(gòu)圖:</b></p><p>　　當(dāng)Sun公司引進(jìn)使用JSP時，一些人連忙聲稱JSP己經(jīng)取代Servlet機(jī)制成為網(wǎng)絡(luò)結(jié)構(gòu)中處理機(jī)制的首選。雖然JSP是Java2平臺企業(yè)版規(guī)格的核心部分，但作為首選的管理者和反應(yīng)機(jī)制，我們必須進(jìn)一步調(diào)查，了解JSP與Servlets這間的關(guān)系。</p><p>　　本書的其它部分解釋了JSP將原始資料編譯和

60、匯編成Servlet的執(zhí)行細(xì)節(jié)。JSP的理解是建立在Servlet API的高層基礎(chǔ)上，并使用Servlet語義，引起一些有趣的問題。難道我們就不能在我們的網(wǎng)絡(luò)使用系統(tǒng)中發(fā)展自成一體的Servlet嗎？還有辦法結(jié)合Servlets和JSPs嗎？若如些，我們將如何設(shè)置Java代碼？還有其它部分參與了請求處理，就像JavaBeans?若如此的話，它們是如何融入結(jié)構(gòu)，它們又是充當(dāng)一個什么樣的角色。</p><p>　　

61、必須認(rèn)識到，盡管JSP技術(shù)將會成為基礎(chǔ)Servlets的有力后繼，但是他們有一個漸進(jìn)的關(guān)系，并且可以在合作與互補(bǔ)的方式下使用，認(rèn)識這一點(diǎn)，是很重要的。</p><p>　　在這個前提下，我們要探討研究這兩種技術(shù)，每一個Java標(biāo)準(zhǔn)擴(kuò)展，是如何與其它部分聯(lián)合使用，如JavaBeans技術(shù)，是用來創(chuàng)造一個Java為基礎(chǔ)的Web驅(qū)動系統(tǒng)。我們要調(diào)查研究涉及到JSP和Servlet的結(jié)構(gòu)問題，并在對其權(quán)衡的同時討論一些有

62、效的設(shè)計(jì)。但是，在直接跳入討論這特別結(jié)構(gòu)之前，我們要簡要研究發(fā)展結(jié)構(gòu)多樣性的必要性。</p><p>　　12.3編程要素和角色分離</p><p>　　為什么JSP的技術(shù)演變成今天的樣子（它一直在演變發(fā)展）的一個重要原因是對通過從靜態(tài)演示數(shù)據(jù)中分離動態(tài)展示數(shù)據(jù)來簡化設(shè)計(jì)的技術(shù)需求很大。隨著來自Sun公司的JSP的初步發(fā)展，JSP的基礎(chǔ)得到了初步奠定，它使用于網(wǎng)頁匯編并注重將頁內(nèi)的HTML

63、嵌入Java的代碼中。因?yàn)樯暾垖ο蟾嗍且詷I(yè)務(wù)目標(biāo)或幾層結(jié)構(gòu)為基礎(chǔ)的，重點(diǎn)又將轉(zhuǎn)變成將HTML從Java 代碼中分離出來，同時仍堅(jiān)持技術(shù)所提供的整體性和靈活性。</p><p>　　在本書的第五章JSP部分，我們明白了整體和部分是如何只通過界定某個范圍而愛制于不同環(huán)境。良好的應(yīng)用設(shè)計(jì)就是建立在這個理念上并試著將目標(biāo)對象，簡報(bào)和對象操作分解成壁壘分明有區(qū)別的層次。</p><p>　　使用J

64、SP的另一個好處是，它讓我們更清楚的區(qū)分網(wǎng)頁制作角色或編程設(shè)計(jì)師與軟件開發(fā)商。記住，JSP與Servlet的共同發(fā)展局面是它們將在Servlet本身的Java代碼內(nèi)嵌入HTML標(biāo)記。在我們的討論中，我們將Serlet純粹當(dāng)作是Java代碼的集裝箱，盡管在此同時，我們的整個HTML的顯示平臺是封裝在一個JSP源網(wǎng)頁里，那么接下來引發(fā)的問題是多少Java代碼可以保留在我們的JSP源網(wǎng)頁里，如果Java代碼從JSP源網(wǎng)頁中取出，將會在哪存放。

65、</p><p>　　讓我們進(jìn)一步對這個進(jìn)行探討研究。任何網(wǎng)上項(xiàng)目中，多角色和多責(zé)任是明顯存在的。例如， 一個程序員在網(wǎng)頁制作時將充分發(fā)揮網(wǎng)頁創(chuàng)作的角色（地位），同時即在Java編程語言中編寫軟件的過程中沒有發(fā)揮出軟件開發(fā)的作用。</p><p>　　對于小型項(xiàng)目，這兩個角色可能由同一個人或兩個人密切配合完成，一個較大的項(xiàng)目將會由多個人完成，這些可能沒有重疊技巧，而且如果過于依賴其它流程的

66、話，創(chuàng)造性將會小一些。</p><p>　　如果代碼可以計(jì)算出一個包含Servlet而不是HTML標(biāo)記，然后在軟件開發(fā)角色個人的潛力存在和在網(wǎng)頁制作角色中變得更加依賴于必要的工作進(jìn)展和其它的，類似這種依賴可能造成更多的錯誤傾向環(huán)境，而這種事情被其它認(rèn)員無意識的改變的環(huán)境變得更加普遍。</p><p>　　這使我們更好觀察到我們?yōu)槭裁蠢^續(xù)開發(fā)基本Servlet的原因：它們是適當(dāng)?shù)谋阌谄毡榈募?/p>

67、經(jīng)計(jì)算出JSP頁面的Java代碼的集裝箱，提供了把盡可能松散連接我們的JSP頁面作為我們軟件開發(fā)小組這一領(lǐng)域的焦點(diǎn)。當(dāng)然，這將需要一個同樣由個人來完成JSP來源頁面，但是這種依賴減少，而這些頁面變成制作團(tuán)隊(duì)的焦點(diǎn)。當(dāng)然，如果同一個人完成兩種角色工作，作為一個典型小型項(xiàng)目，類似這種依賴就不是最主要的關(guān)注。</p><p>　　所以，我們應(yīng)該盡量把包含我們的JSP頁面的Java代碼降為最低，為了維持這種發(fā)展角色間的清

68、楚分離。正如我們曾討論，許多這種Java代碼是一個調(diào)處Servlet的合適適當(dāng)?shù)囊蛩?。代碼是一種很常見的多樣要求，例如認(rèn)證，是為了一個調(diào)處Servlet的最佳選擇。類似代碼包含在一個地方，這些Servlet而不是潛在被切掉和粘貼成多樣化的JSPs.</p><p>　　我們還將要消除我們很多從JSP頁面來的商業(yè)邏輯和數(shù)據(jù)訪問代碼和概括的內(nèi)頁JavaBeans,所謂工人或Beans幫手，我們開始看到一種從我們JSP

69、代碼活動中出來的模式的兩個方面，一個是Servlet（或JSP技術(shù)），因?yàn)镴SP主要在前面，而JavaBeans總是在后面的。我們稱這種常見的模式為“前沿因子—因子后端”。類似的數(shù)字如下：</p><p>　　“前沿因子—因子后端”:</p><p>　　從另一種方式考慮我們所要要限制和封裝的代碼，也說是我們的JSP網(wǎng)頁應(yīng)該盡可能少地顯示出Java代碼的實(shí)施細(xì)節(jié)。</p>&

70、lt;p>　　相反，多數(shù)網(wǎng)頁都應(yīng)該傳送我們的意圖，即顯示我們傳統(tǒng)技術(shù)具有代表性的信息，指導(dǎo)他的從模型中獲得狀態(tài)指示或調(diào)去完成一些業(yè)務(wù)處理。</p><p><b>　　12.4轉(zhuǎn)移和發(fā)送</b></p><p>　　在JSP和Servlet方面，轉(zhuǎn)移與發(fā)送通常要求同時進(jìn)行，即使這兩個機(jī)制達(dá)到同一目標(biāo)（即客戶需求服務(wù)器上的資源和一個所服務(wù)于它的不同資源），但了解這

71、兩個機(jī)制的微妙差別是很重要的：</p><p>　　當(dāng)一個Servlet或JSP資源重新選擇客戶時（使用respone.sendRedirect程序ur1）,自從內(nèi)部操作是一個Http接續(xù)后，它的要求對象沒有直接到喧第二資源。服務(wù)器傳送一個Http302信息回客戶，并告訴它這個資源己經(jīng)轉(zhuǎn)移到另一個URL上了，客戶應(yīng)該進(jìn)入里內(nèi)。最后也就是最初要求對象所需物體的生命線己進(jìn)入第一個JSP，并以服務(wù)方式的結(jié)束或來自服務(wù)器

72、的回應(yīng)而終止。</p><p>　　在一個發(fā)送機(jī)制里，要求所需對象被發(fā)送到第二資源，從而保持任何物體反應(yīng)的要求以及 它的指示上，沒有來回的網(wǎng)絡(luò)客戶。這就允許第一個JSP做內(nèi)部動轉(zhuǎn)，然后發(fā)送信息到第二個JSP。（Servlets使用一個會連接機(jī)制物體），可以回頭看看本書第五章的JSP時段，從本書中可以看到更清晰的圖形。</p><p>　　在分離動靜容量的過程中，JSPs和Ser

73、vlets能使用發(fā)送機(jī)制在他們之間執(zhí)行任務(wù)。</p><p>　　現(xiàn)在，讓我們探討如何建立這些系統(tǒng)。</p><p><b>　　12.5結(jié)構(gòu)</b></p><p>　　在討論具體的結(jié)構(gòu)之前，我們可以利用所建造Servlets和JSPs的系統(tǒng)，值得提的是使用JSP技術(shù)的兩個基本方法，在這一章里被討論到的每個結(jié)構(gòu)將建立在諸多方法之一的基礎(chǔ)上：&

74、lt;/p><p>　　第一種方法是這里所指的網(wǎng)頁中心（或客戶服務(wù)器）的方式，且這種方式涉及到直接作用于JSP網(wǎng)頁的指令緩助。</p><p>　　第二種方法，發(fā)送員（或幾層）方法，一個基本的Servlet或JSP充當(dāng)調(diào)解員或操作員，發(fā)送指令給JSP網(wǎng)頁和JavaBeans網(wǎng)頁。</p><p>　　我們將給出一個簡單的例子來檢測這些方法，這將展開來滿足不同情況的要求。

75、初步設(shè)想涉及到向網(wǎng)頁界面提供不久將要出現(xiàn)的數(shù)字估計(jì)統(tǒng)計(jì)，它的臆測被保留著，并可以由另方法證實(shí)，看看誰猜測得最接近。當(dāng)所要求情況變得更加復(fù)雜時，例如加入了持久機(jī)制的這一想法，那么解決方案也效變得更加復(fù)雜，我們用簡潔而有準(zhǔn)備的方式來展開討論，以此來幫助我們建立滿足這些要求的系統(tǒng)。</p><p>　　12.6網(wǎng)頁探討中心</p><p>　　使用客戶服務(wù)器方式的值用結(jié)構(gòu)己得到運(yùn)用，他們包含一個

76、或多個在客戶機(jī)制上動行的應(yīng)用程序，并連接到服務(wù)器運(yùn)用的運(yùn)轉(zhuǎn)（PowerBuilder或Oracle Forms-based系統(tǒng)就是最好的例子）。CGIs和pre-servlt應(yīng)用一般是建立在適全的簡單的2層模式上，并隨著Servlets的引入，2層應(yīng)用也能在Java上產(chǎn)生。</p><p>　　這種模式使JSPs或Servlets直接獲取一些資源，如數(shù)據(jù)庫遺留應(yīng)用或用以服務(wù)客戶的要求。早期的JSP規(guī)格稱這種模式為

77、“型號1”的編程方法。JSP頁攔截并處理即將到來的請求服務(wù)，并把聽?wèi)?yīng)反饋給客戶。不同于Servlet的這一情景，JSPs只是提供純代碼和從內(nèi)容中分離代碼放置在數(shù)據(jù)存取beans中，這一方體現(xiàn)在以下圖表中。</p><p><b>　　型號1的編程方法:</b></p><p>　　這種方法的優(yōu)點(diǎn)是，它是siple編程，創(chuàng)造者容易根據(jù)請求和資源狀態(tài)允許生成動態(tài)頁面。&l

78、t;/p><p>　　不過這種結(jié)構(gòu)并不能同時響應(yīng)大批客戶同時發(fā)送的大量的請求和進(jìn)行處理，所以要求每一個客戶必須建立或者共享一個潛在稀少/昂貴的資源方面的問題。（比如連接JDBC就是一個很好的例子，不論是Servlets還是JSPs的連接都需要連接池）。</p><p>　　通常使用的結(jié)構(gòu)中不加于區(qū)別導(dǎo)致了大量的JSP網(wǎng)頁中嵌入了Java的代碼，這可能不是最大的問題，但肯定是Java編程者的問題