计算机 JSP web 外文翻译 外文文献 英文文献.doc

《计算机 JSP web 外文翻译 外文文献 英文文献.doc》由会员分享，可在线阅读，更多相关《计算机 JSP web 外文翻译 外文文献 英文文献.doc（12页珍藏版）》请在三一办公上搜索。

1、外文资料所译外文资料： 作者：Dan Malks 书名：Professional JSP 出版时间: 2000.7.26 所译章节: Chapter 1212.1 IntroductoryGood Web application design tries to separate business objects, presentation, and manipulation of the objects into distinct layers. One benefit of using JavaServer Pages technology is that it allows us to s

2、eparate 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 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 architectur

3、e for your Web application is crucial to this separation.12.2 JSP architectureWe will 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 pr

4、ocess in outline; the individual parts of the diagram will be explained in turn later in this article.JSP architecture:When Sun introduced Java Server Pages, some were quick to claim that servlets had been replaced as the preferred request handling mechanism in Web-enabled enterprise architectures.

5、Although JSP is a key component of the Java 2 Platform Enterprise Edition (J2EE) specification, serving as the preferred request handler and response mechanism, we must investigate further to understand its relationship with servlets. Other sections of Professional JSP explain the implementation det

6、ails 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 stand-alone servlets in our Web-enabled systems? Is there some way to combine servlets

7、 and JSPs? If so, where do we place our Java code? Are there any other components involved in the request processing, such as JavaBeans? If so, where do they fit into the architecture and what type of role do they fulfill? It is important to understand that, although JSP technology will be a powerfu

8、l successor to basic servlets, they have an evolutionary relationship and can be used in a cooperative and complementary manner. 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 JavaBea

9、ns, to create Java-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 of specific architectures, though, we will briefly examine the ne

10、ed to develop a variety of architectures.12.3 Code factoring and role separationOne of the main reasons why the JavaServer Pages technology has evolved into what it is today (and its still evolving) is the overwhelming technical need to simplify application design by separating dynamic content from

11、static template display data. The foundation 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 objects and n-tier architectures, the focus c

12、hanged to separating HTML from Java code, while still maintaining the integrity and flexibility the technology provided. 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 builds o

13、n this idea and tries to separate the objects, the presentation, and the manipulation of the objects into distinct, distinguishable layers. Another benefit of using JSP is that it allows us to more cleanly separate the roles of a Web production/HTML designer individual from a software developer. Rem

14、ember that a common development scenario with servlets was to embed the HTML presentation markup within the Java 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 e

15、ncapsulated within a JSP source page. The question then arises as to how much Java code should remain embedded within our JSP source pages, and if it is taken out of the JSP source page, where should it reside? Lets investigate this further. On any Web-based project, multiple roles and responsibilit

16、ies will exist. For example, an individual who designs HTML pages fulfills a Web production role while someone who writes software in the Java programming language fulfills a software development role. On small-scale projects these roles might be filled by the same individual, or two individuals wor

17、king 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. If code that could be factored out to a mediating servlet is included instead within

18、HTML markup, then the potential exists for individuals in the software development role and those in the Web production 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 co

19、de by other team members become more common. 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 pages, giving our software development team an area of focus that is as

20、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 dependency is reduced, and these pages become the focus of the Web-production team instead. Of course, if the same individual fulfills both roles, as is

21、 typical on a smaller project, such dependencies are not a major concern.So, we should try to minimize the Java code that we include within our JSP page, in order to uphold this cleaner separation of developer roles. As we have discussed, some of this Java code is appropriately factored to a mediati

22、ng servlet. Code that is common to multiple requests, such as authentication, is a good candidate for a mediating servlet. Such code is included in one place, the servlet, instead of potentially being cut and pasted into multiple JSPs. We will also want to remove much of our business logic and data

23、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 of the main JSP, and JavaBeans that sit in back. We refer to this common pattern as Factor F

24、orward - Factor Back, as shown in the figure below:Factor Forward - Factor Back: 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.Rather, the page should communicate our intent b

25、y revealing the delegating messages we send to worker beans, instructing them to get state from a model, or to complete some business processing.12.4 Redirecting and forwardingRedirecting and forwarding requests in JSPs and servlets takes place often, and it is important to understand the subtle dif

26、ference between these two mechanisms even though they achieve the same goal (that is, a client asks for a resource on the server and a different resource is served to it): l When a servlet or JSP resource chooses to redirect the client (using a response.sendRedirect(url) the request object does not

27、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 has moved to another URL, and that the client should access it there. The bottom line is that the lifecycle of the initial

28、request object that was accessed in the first JSP terminates with the end of the service method in the first JSP, or with the reply from the server. l In a forward mechanism the request object is forwarded to the second resource, thus maintaining any object bindings to the request and its state, wit

29、hout a round trip to the client on the network. This allows the first JSP 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 of scop

30、e. JSPs and servlets can use the forwarding mechanism to delegate tasks among themselves, in the process of separating dynamic and static content.Now, lets investigate how we build these systems.12.5 ArchitecturesBefore discussing specific architectures that we can use to build systems with servlets

31、 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 these approaches: l The first method is referred to here as the page-centric (or client-server) approach. This approach involves request invocation

32、s being made directly to JSP page. l 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. We will examine these approaches in light of a simple example, which will evolve to satisfy the req

33、uirements of various scenarios. The initial scenario involves providing a Web interface for guessing statistics about a soon-to-be-born baby. The guesses are stored, and can be reviewed later by the parents, to see who has guessed the closest. As the requirement scenarios become more sophisticated,

34、such as adding the desire for a persistence mechanism, the solution scenarios will become more sophisticated, as well. Thus, our example will evolve and we will gain an understanding of how the various architectures that we discuss will help us build a system that satisfies these requirements in an

35、elegant and effective manner. 12.6 The page-centric approach Applications built using a client-server approach have been around for some time; they consist of one or more application programs running on client machines and connecting to a server-based application to work. (A good example would be a

36、PowerBuilder or Oracle Forms-based system.) CGIs and pre-servlet applications were generally based on this simple 2-tier model, and with the introduction of servlets, 2-tier applications could also be created in Java. This model allows JSPs or servlets direct access to some resource like a database

37、or legacy application to service a clients request: the early JSP specifications termed this a Model 1 programming approach. The JSP page is where the incoming request is intercepted and processed, and the response is sent back to the client; JSPs only differed from servlets in this scenario by prov

38、iding cleaner code and separating code from the content by placing data access in beans. Model 1 programming approach: 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 request and the state resources.However

39、 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 performed,and each request must establish or share a potentially scarce/expensive connection to the resource in question.(A good example would be

40、 JDBC connectons in servlets or JSPs and the need for connection pools.)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 an issue if the JSP page

41、s are maintained by designers:the code tends to get in the designes way,and you run the risk of your code becoming corrupted when others are tweaking the look and feel.译文12.1前言好的Web应用设计试图将业务对象，简报以及操作对象分为不同的层面。采用JSP技术的一个好处在于它使我们更清楚地把Web设计者的作用从一个软件开发商中分离出来。在小规项目中，单个体可能担任着着两个角色，在较大的项目中，他们可能被分开，尽可能地分开他们

42、的工作流程是有好处的，比如有利于自己的工作流程，且你的Web应用设计结构对这种分离是至关重要的。12.2 JSP的结构我们将研究采取各种方式来设计利用关于JSP的结构层次，还有Servlets以及JavaBeans技术。我们将看到一系列不同的结构，一个一个地形成。下面的图示显示了这一过程，个别图示将于稍后在这篇文章中作了解释。JSP的结构图:当Sun公司引进使用JSP时，一些人连忙声称JSP己经取代Servlet机制成为网络结构中处理机制的首选。虽然JSP是Java2平台企业版规格的核心部分，但作为首选的管理者和反应机制，我们必须进一步调查，了解JSP与Servlets这间的关系。本书的其它部

43、分解释了JSP将原始资料编译和汇编成Servlet的执行细节。JSP的理解是建立在Servlet API的高层基础上，并使用Servlet语义，引起一些有趣的问题。难道我们就不能在我们的网络使用系统中发展自成一体的Servlet吗？还有办法结合Servlets和JSPs吗？若如些，我们将如何设置Java代码？还有其它部分参与了请求处理，就像JavaBeans?若如此的话，它们是如何融入结构，它们又是充当一个什么样的角色。必须认识到，尽管JSP技术将会成为基础Servlets的有力后继，但是他们有一个渐进的关系，并且可以在合作与互补的方式下使用，认识这一点，是很重要的。在这个前提下，我们要探讨研

44、究这两种技术，每一个Java标准扩展，是如何与其它部分联合使用，如JavaBeans技术，是用来创造一个Java为基础的Web驱动系统。我们要调查研究涉及到JSP和Servlet的结构问题，并在对其权衡的同时讨论一些有效的设计。但是，在直接跳入讨论这特别结构之前，我们要简要研究发展结构多样性的必要性。12.3编程要素和角色分离为什么JSP的技术演变成今天的样子（它一直在演变发展）的一个重要原因是对通过从静态演示数据中分离动态展示数据来简化设计的技术需求很大。随着来自Sun公司的JSP的初步发展，JSP的基础得到了初步奠定，它使用于网页汇编并注重将页内的HTML嵌入Java的代码中。因为申请对象

45、更多是以业务目标或几层结构为基础的，重点又将转变成将HTML从Java 代码中分离出来，同时仍坚持技术所提供的整体性和灵活性。在本书的第五章JSP部分，我们明白了整体和部分是如何只通过界定某个范围而爱制于不同环境。良好的应用设计就是建立在这个理念上并试着将目标对象，简报和对象操作分解成壁垒分明有区别的层次。使用JSP的另一个好处是，它让我们更清楚的区分网页制作角色或编程设计师与软件开发商。记住，JSP与Servlet的共同发展局面是它们将在Servlet本身的Java代码内嵌入HTML标记。在我们的讨论中，我们将Serlet纯粹当作是Java代码的集装箱，尽管在此同时，我们的整个HTML的显示

46、平台是封装在一个JSP源网页里，那么接下来引发的问题是多少Java代码可以保留在我们的JSP源网页里，如果Java代码从JSP源网页中取出，将会在哪存放。让我们进一步对这个进行探讨研究。任何网上项目中，多角色和多责任是明显存在的。例如， 一个程序员在网页制作时将充分发挥网页创作的角色（地位），同时即在Java编程语言中编写软件的过程中没有发挥出软件开发的作用。对于小型项目，这两个角色可能由同一个人或两个人密切配合完成，一个较大的项目将会由多个人完成，这些可能没有重叠技巧，而且如果过于依赖其它流程的话，创造性将会小一些。如果代码可以计算出一个包含Servlet而不是HTML标记，然后在软件开发角

47、色个人的潜力存在和在网页制作角色中变得更加依赖于必要的工作进展和其它的，类似这种依赖可能造成更多的错误倾向环境，而这种事情被其它认员无意识的改变的环境变得更加普遍。这使我们更好观察到我们为什么继续开发基本Servlet的原因：它们是适当的便于普遍的己经计算出JSP页面的Java代码的集装箱，提供了把尽可能松散连接我们的JSP页面作为我们软件开发小组这一领域的焦点。当然，这将需要一个同样由个人来完成JSP来源页面，但是这种依赖减少，而这些页面变成制作团队的焦点。当然，如果同一个人完成两种角色工作，作为一个典型小型项目，类似这种依赖就不是最主要的关注。所以，我们应该尽量把包含我们的JSP页面的Ja

48、va代码降为最低，为了维持这种发展角色间的清楚分离。正如我们曾讨论，许多这种Java代码是一个调处Servlet的合适适当的因素。代码是一种很常见的多样要求，例如认证，是为了一个调处Servlet的最佳选择。类似代码包含在一个地方，这些Servlet而不是潜在被切掉和粘贴成多样化的JSPs.我们还将要消除我们很多从JSP页面来的商业逻辑和数据访问代码和概括的内页JavaBeans,所谓工人或Beans帮手，我们开始看到一种从我们JSP代码活动中出来的模式的两个方面，一个是Servlet（或JSP技术），因为JSP主要在前面，而JavaBeans总是在后面的。我们称这种常见的模式为“前沿因子因子

49、后端”。类似的数字如下：“前沿因子因子后端”:从另一种方式考虑我们所要要限制和封装的代码，也说是我们的JSP网页应该尽可能少地显示出Java代码的实施细节。相反，多数网页都应该传送我们的意图，即显示我们传统技术具有代表性的信息，指导他的从模型中获得状态指示或调去完成一些业务处理。12.4转移和发送在JSP和Servlet方面，转移与发送通常要求同时进行，即使这两个机制达到同一目标（即客户需求服务器上的资源和一个所服务于它的不同资源），但了解这两个机制的微妙差别是很重要的：l 当一个Servlet或JSP资源重新选择客户时（使用respone.sendRedirect程序ur1）,自从内部操作是一个Http接续后，它的要求对象没有直接到喧第二资源。服务器传送一个Http302信息回客户，并告诉它这个资源己经转移到另一个URL上了，客户应该进入里内。最后也就是最初要求对象所需物体的生命线己进入第一个JSP，并以服务方式的结束或来自服务器