外文资料

所译外文资料：

① 作者：Dan Malks

② 书名：Professional JSP

③ 出版时间: 2000.7.26

④ 所译章节: Chapter 12

12.1 Introductory

Good 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 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 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 architecture for your Web application is crucial to this separation.

12.2 JSP architecture

We 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 process 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. 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 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 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 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 powerful 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 JavaBeans, 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 need to develop a variety of architectures.

12.3 Code factoring and role separation

One 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 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 changed 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 on 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. Remember 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 encapsulated 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 responsibilities 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 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.

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 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 code 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 loosely coupled to our JSP pages as possible. Certainly, th

剩余内容已隐藏，支付完成后下载完整资料

译文

12.1前言

好的Web应用设计试图将业务对象，简报以及操作对象分为不同的层面。采用JSP技术的一个好处在于它使我们更清楚地把Web设计者的作用从一个软件开发商中分离出来。在小规项目中，单个体可能担任着着两个角色，在较大的项目中，他们可能被分开，尽可能地分开他们的工作流程是有好处的，比如有利于自己的工作流程，且你的Web应用设计结构对这种分离是至关重要的。

12.2 JSP的结构

我们将研究采取各种方式来设计利用关于JSP的结构层次，还有Servlets以及JavaBeans技术。我们将看到一系列不同的结构，一个一个地形成。下面的图示显示了这一过程，个别图示将于稍后在这篇文章中作了解释。

JSP的结构图:

当Sun公司引进使用JSP时，一些人连忙声称JSP己经取代Servlet机制成为网络结构中处理机制的首选。虽然JSP是Java2平台企业版规格的核心部分，但作为首选的管理者和反应机制，我们必须进一步调查，了解JSP与Servlets这间的关系。

本书的其它部分解释了JSP将原始资料编译和汇编成Servlet的执行细节。JSP的理解是建立在Servlet API的高层基础上，并使用Servlet语义，引起一些有趣的问题。难道我们就不能在我们的网络使用系统中发展自成一体的Servlet吗？还有办法结合Servlets和JSPs吗？若如些，我们将如何设置Java代码？还有其它部分参与了请求处理，就像JavaBeans?若如此的话，它们是如何融入结构，它们又是充当一个什么样的角色。

必须认识到，尽管JSP技术将会成为基础Servlets的有力后继，但是他们有一个渐进的关系，并且可以在合作与互补的方式下使用，认识这一点，是很重要的。

在这个前提下，我们要探讨研究这两种技术，每一个Java标准扩展，是如何与其它部分联合使用，如JavaBeans技术，是用来创造一个Java为基础的Web驱动系统。我们要调查研究涉及到JSP和Servlet的结构问题，并在对其权衡的同时讨论一些有效的设计。但是，在直接跳入讨论这特别结构之前，我们要简要研究发展结构多样性的必要性。

12.3编程要素和角色分离

为什么JSP的技术演变成今天的样子（它一直在演变发展）的一个重要原因是对通过从静态演示数据中分离动态展示数据来简化设计的技术需求很大。随着来自Sun公司的JSP的初步发展，JSP的基础得到了初步奠定，它使用于网页汇编并注重将页内的HTML嵌入Java的代码中。因为申请对象更多是以业务目标或几层结构为基础的，重点又将转变成将HTML从Java 代码中分离出来，同时仍坚持技术所提供的整体性和灵活性。

在本书的第五章JSP部分，我们明白了整体和部分是如何只通过界定某个范围而爱制于不同环境。良好的应用设计就是建立在这个理念上并试着将目标对象，简报和对象操作分解成壁垒分明有区别的层次。

使用JSP的另一个好处是，它让我们更清楚的区分网页制作角色或编程设计师与软件开发商。记住，JSP与Servlet的共同发展局面是它们将在Servlet本身的Java代码内嵌入HTML标记。在我们的讨论中，我们将Serlet纯粹当作是Java代码的集装箱，尽管在此同时，我们的整个HTML的显示平台是封装在一个JSP源网页里，那么接下来引发的问题是多少Java代码可以保留在我们的JSP源网页里，如果Java代码从JSP源网页中取出，将会在哪存放。

让我们进一步对这个进行探讨研究。任何网上项目中，多角色和多责任是明显存在的。例如， 一个程序员在网页制作时将充分发挥网页创作的角色（地位），同时即在Java编程语言中编写软件的过程中没有发挥出软件开发的作用。

对于小型项目，这两个角色可能由同一个人或两个人密切配合完成，一个较大的项目将会由多个人完成，这些可能没有重叠技巧，而且如果过于依赖其它流程的话，创造性将会小一些。

如果代码可以计算出一个包含Servlet而不是HTML标记，然后在软件开发角色个人的潜力存在和在网页制作角色中变得更加依赖于必要的工作进展和其它的，类似这种依赖可能造成更多的错误倾向环境，而这种事情被其它认员无意识的改变的环境变得更加普遍。

这使我们更好观察到我们为什么继续开发基本Servlet的原因：它们是适当的便于普遍的己经计算出JSP页面的Java代码的集装箱，提供了把尽可能松散连接我们的JSP页面作为我们软件开发小组这一领域的焦点。当然，这将需要一个同样由个人来完成JSP来源页面，但是这种依赖减少，而这些页面变成制作团队的焦点。当然，如果同一个人完成两种角色工作，作为一个典型小型项目，类似这种依赖就不是最主要的关注。

所以，我们应该尽量把包含我们的JSP页面的Java代码降为最低，为了维持这种发展角色间的清楚分离。正如我们曾讨论，许多这种Java代码是一个调处Servlet的合适适当的因素。代码是一种很常见的多样要求，例如认证，是为了一个调处Servlet的最佳选择。类似代码包含在一个地方，这些Servlet而不是潜在被切掉和粘贴成多样化的JSPs.

我们还将要消除我们很多从JSP页面来的商业逻辑和数据访问代码和概括的内页JavaBeans,所谓工人或Beans帮手，我们开始看到一种从我们JSP代码活动中出来的模式的两个方面，一个是Servlet（或JSP技术），因为JSP主要在前面，而JavaBeans总是在后面的。我们称这种常见的模式为“前沿因子—因子后端”。类似的数字如下：

“前沿因子—因子后端”:

从另一种方式考虑我们所要要限制和封装的代码，也说是我们的JSP网页应该尽可能少地显示出Java代码的实施细节。

相反，多数网页都应该传送我们的意图，即显示我们传统技术具有代表性的信息，指导他的从模型中获得状态指示或调去完成一些业务处理。

12.4转移和发送

在JSP和Servlet方面，转移与发送通常要求同时进行，即使这两个机制达到同一目标（即客户需求服务器上的资源和一个所服务于它的不同资源），但了解这两个机制的微妙差别是很重要的：

• 当一个Servlet或JSP资源重新选择客户时（使用respone.sendRedirect程序ur1）,自从内部操作是一个Http接续后，它的要求对象没有直接到喧第二资源。服务器传送一个Http302信息回客户，并告诉它这个资源己经转移到另一个URL上了，客户应该进入里内。最后也就是最初要求对象所需物体的生命线己进入第一个JSP，并以服务方式的结束或来自服务器的回应而终止。
• 在一个发送机制里，要求所需对象被发送到第二资源，从而保持任何物体反应的要求以及 它的指示上，没有来回的网络客户。这就允许第一个JSP做内部动转，然后发送信息到第二个JSP。（Servlets使用一个会连接机制物体），可以回头看看本书第五章的JSP时段，从本书中可以看到更清晰的图形。

在分离动静容量的过程中，JSPs和Servlets能使用发送机制在他们之间执行任务。

现在，让我们探讨如何建立这些系统。

12.5结构

在讨论具体的结构之前，我们可以利用所建造Servlets和JSPs的系统，值得提的是使用JSP技术的两个基本方法，在这一章里被讨论到的每个结构将建立在诸多方法之一的基础上：

• 第一种方法是这里所指的网页中心（或客户服务器）的方式，且这种方式涉及到直接作用于JSP网页的指令缓助。
• 第二种方法，发送员（或几层）方法，一个基本的Servlet或JSP充当调解员或操作员，发送指令给JSP网页和JavaBeans网页。

我们将给出一个简单的例子来检测这些方法，这将展开来满足不同情况的要求。初步设想涉及到向网页界面提供不久将要出现的数字估计统计，它的臆测被保留着，并可以由另方法证实，看看谁猜测得最接近。当所要求情况变得更加复杂时，例如加入了持久机制的这一想法，那么解决方案也效变得更加复杂，我们用简洁而有准备的方式来展开讨论，以此来帮助我们建立满足这些要求的系统。

12.6网页探讨中心

使用客户服务器方式的值用结构己得到运用，他们包含一个或多个在客户机制上动行的应用程序，并连接到服务器运用的运转（PowerBuilder或Oracle Forms-based系统就是最好的例子）。CGIs和pre-servlt应用一般是建立在适全的简单的2层模式上，并随着Servlets的引入，2层应用也能在Java上产生。

这种模式使JSPs或Servlets直接获取一些资源，如数据库遗留应用或用以服务客户的要求。早期的JSP规格称这种模式为“型号1”的编程方法。JSP页拦截并处理即将到来的请求服务，并把听应反馈给客户。不同于Servlet的这一情景，JSPs只是提供纯代码和从内容中分离代码放置在数据存取beans中，这一方体现在以下图表中。

型号1的编程方法:

这种方法的优点是，它是siple编程，创造者容易根据请求和资源状态允许生成动态页面。

不过这种结构并不能同时响应大批客户同时发送的大量的请求和进行处理，所以要求每一个客户必须建立或者共享一个潜在稀少/昂贵的资源方面的问题。（比如连接JDBC就是一个很好的例子，不论是Servlets还是JSPs的连接都需要连接池）。

通常使用的结构中不加于区别导致了大量的JSP网页中嵌入了Java的代码，这可能不是最大的问题，但肯定是Java编程者的问题。如果JSP的页面一般由嵌入设计师完成,一般人是看不到的：使用趋向的方法设计出代码，你现在所写的你的代码，都是由其他人观看的。

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[20055]，资料为PDF文档或Word文档，PDF文档可免费转换为Word