图书管理系统外文翻译

重庆三峡学院

毕业设计(论文)外文资料翻译设计(论文)题目图书管理系统

院系计算机科学与工程学院

专业计算机科学与技术

年级2009级1班

学生学号2008908112

学生姓名管金凤

外文出处CHINA-USA Business Review

Combining JSP and Servlets

The technology of JSP and Servlet is the most important technology which use Java technology to exploit request of server, and it is also the standard which exploit business application .Java developers prefer to use it for a variety of reasons, one of which is already familiar with the Java language for the development of this technology are easy to learn Java to the other is "a preparation, run everywhere" to bring the concept of Web applications, To achieve a "one-prepared everywhere realized." And more importantly, if followed some of the principles of good design, it can be said of separating and content to create high-quality, reusable, easy to maintain and modify the application. For example, if the document in HTML embedded Java code too much (script), will lead the developed application is extremely complex, difficult to read, it is not easy reuse, but also for future maintenance and modification will also cause difficulties. In fact, CSDN the JSP / Servlet forum, can often see some questions, the code is very long, can logic is not very clear, a large number of HTML and Java code mixed together. This is the random development of the defects.

Early dynamic pages mainly CGI (Common Gateway Interface, public Gateway Interface) technology, you can use different languages of the CGI programs, such as VB, C / C + + or Delphi, and so on. Though the technology of CGI is developed and powerful, because of difficulties in programming, and low efficiency, modify complex shortcomings,

it is gradually being replaced by the trend. Of all the new technology, JSP / Servlet with more efficient and easy to program, more powerful, more secure and has a good portability, they have been many people believe that the future is the most dynamic site of the future development of technology.

Similar to CGI, Servlet support request / response model. When a customer submit a request to the server, the server presented the request Servlet, Servlet responsible for handling requests and generate a response, and then gave the server, and then from the server sent to the customer. And the CGI is different, Servlet not generate a new process, but with HTTP Server at the same process. It threads through the use of technology, reduce the server costs. Servlet handling of the request process is this: When received from the client's request, calling service methods, the method of Servlet arrival of the first judgement is what type of request (GET / POST / HEAD…), then calls the appropriate treatment (DoGet / doPost / doHead…) and generate a response.

Although such a complex, in fact, simply said to Servlet is a Java class. And the general category of the difference is that this type operating in a Servlet container, which can provide session management and targeted life-cycle management. So that when you use the Servlet, you can get all the benefits of the Java platform, including the safety of the management, use JDBC access the database and cross-platform capability. Moreover, Servlet using thread, and can develop more efficient Web applications.

JSP technology is a key J2EE technology, it at a higher level of abstraction of a Servlet.

It allows conventional static and dynamic HTML content generated by combining an HTML page looks like, but as a Servlet to run. There are many commercial application server support JSP technology, such as BEA WebLogic, IBM WebSphere, JRun, and so on. JSP and Servlet use more than simple. If you have a JSP support for Web servers, and a JSP document, you can put it Fangdao any static HTML files can be placed, do not have to compile, do not have to pack, do not have to ClassPath settings, you can visit as ordinary Web It did visit, the server will automatically help you to do other work.

JSP document looks like an ordinary static HTML document, but inside contains a number of Java code. It uses. Jsp the suffix, used to tell the server this document in need of special treatment. When we visit a JSP page, the document will first be translated into a JSP engine Java source files, is actually a Servlet, and compiler, and then, like other Servlet, from Servlet engine to handle. Servlet engine of this type loading, handling requests from customers, and the results returned to the customer.

After another visit this page to the customer, as long as the paper there have been no changes, JSP engine has been loaded directly call the Servlet. If you have already been modified, it will be once again the implementation of the above process, translate, compile and load. In fact, this is the so-called "first person to punishment." Because when the first visit to the implementation of a series of the above process, so will spend some time after such a visit would not.

Java servlets offer a powerful API that provides access to all the information about the

request, the session, and the application. combining JSP with servlets lets you clearly separate the application logic from the presentation of the application; in other words, it lets you use the most appropriate component type for the roles of Model, View and Controller.

Servlets, Filters, and Listeners

A servlet is a Java class that extends a server with functionality for processing a request and producing a response. It's implemented using the classes and interfaces defined by the Servlet API. The API consists of two packages: the javax.servlet package contains classes and interfaces that are protocol-independent, while the javax.servlet.http package provides HTTP-specific extensions and utility classes.

What makes a servlet a servlet is that the class implements an interface named javax.servlet.Servlet, either directly or by extending one of the support classes. This interface defines the methods used by the web container to manage and interact with the servlet. A servlet for processing HTTP requests typically extends the javax.servlet.http.HttpServlet class. This class implements the Servlet interface and provides additional methods suitable for HTTP processing.

Servlet Lifecycle

The web container manages all aspects of the servlet's lifecycle. It creates an instance of the servlet class when needed, passes requests to the instance for processing, and eventually removes the instance. For an HttpServlet, the container calls the following

methods at the appropriate times in the servlet lifecycle.

Besides the doGet( ) and doPost( ) methods, there are methods corresponding to the other HTTP methods: doDelete( ), doHead( ), doOptions( ), doPut( ), and doTrace( ). Typically you don't implement these methods; the HttpServlet class already takes care of HEAD, OPTIONS, and TRACE requests in a way that's suitable for most servlets, and the DELETE and PUT HTTP methods are rarely used in a web application.

It's important to realize that the container creates only one instance of each servlet. This means that the servlet must be thread safe -- able to handle multiple requests at the same time, each executing as a separate thread through the servlet code. Without getting lost in details, you satisfy this requirement with regards to instance variables if you modify the referenced objects only in the init( ) and destroy( ) methods, and just read them in the request processing methods.

Compiling and Installing a Servlet

To compile a servlet, you must first ensure that you have the JAR file containing all Servlet API classes in the CLASSPATH environment variable. The JAR file is distributed with all web containers. Tomcat includes it in a file called servlet.jar, located in the common/lib directory. On a Windows platform, you include the JAR file in the CLASSPATH.

. Reading a Request

One of the arguments passed to the doGet( ) and doPost( ) methods is an object that implements the HttpServletRequest interface. This interface defines methods that provide access to a wealth of information about the request.

Generating a Response

Besides the request object, the container passes an object that implements the HttpServletResponse interface as an argument to the doGet( ) and doPost( ) methods. This interface defines methods for getting a writer or stream for the response body. It also defines methods for setting the response status code and headers.

Using Filters and Listeners

The servlet specification defines two component types beside servlets: filters and listeners. These two types were introduced in the Servlet 2.3 specification, so if you're using a container that doesn't yet support this version of the specification, I'm afraid you're out of luck.

Filters

A filter is a component that can intercept a request targeted for a servlet, JSP page, or static page, as well as the response before it's sent to the client. This makes it easy to centralize tasks that apply to all requests, such as access control, logging, and charging for the content or the services offered by the application. A filter has full access to the body

and headers of the request and response, so it can also perform various transformations. One example is compressing the response body if the Accept-Language request header indicates that the client can handle a compressed response.

A filter can be applied to either a specific servlet or to all requests matching a URL pattern, such as URLs starting with the same path elements or having the same extension. Listeners

Listeners allow your application to react to certain events. Prior to Servlet 2.3, you could handle only session attribute binding events (triggered when an object was added or removed from a session). You could do this by letting the object saved as a sessionattribute(using the HttpSession.setAttribute() method)implement the HttpSessionBindingListener interface. With the new interfaces introduced in the 2.3 version of the specification, you can create listeners for servlet context and session lifecycle events as well as session activation and passivation events (used by a container that temporarily saves session state to disk or migrates a session to another server). A new session attribute event listener also makes it possible to deal with attribute binding events for all sessions in one place, instead of placing individual listener objects in each session.

The new types of listeners follow the standard Java event model. In other words, a listener is a class that implements one or more of the listener interfaces. The interfaces define methods that correspond to events. The listener class is registered with the container when the application starts, and the container then calls the event methods at the

appropriate times.

Initializing Shared Resources Using a Listener

Beans like this typically need to be initialized before they can be used. For instance, they may need a reference to a database or some other external data source and may create an initial information cache in memory to provide fast access even to the first request for data. You can include code for initialization of the shared resources in the servlet and JSP pages that need them, but a more modular approach is to place all this code in one place and let the other parts of the application work on the assumption that the resources are already initialized and available. An application lifecycle listener is a perfect tool for this type of resource initialization. This type of listener implements the javax.servlet.ServletContextListener interface, with methods called by the container when the application starts and when it shuts down.

Picking the Right Component Type for Each Task

The Project Billboard application introduced is a fairly complex application. Half the pages are pure controller and business logic processing, it accesses a database to authenticate users, and most pages require access control. In real life, it would likely contain even more pages, for instance, pages for access to a shared document archive, time schedules, and a set of pages for administration. As the application evolves, it may become hard to maintain as a pure JSP application. It's easy to forget to include the access control code in new pages.

This is clearly an application that can benefit from using a combination of JSP pages and the component types defined by the servlet specification for the MVC roles. Let's look at the main requirements and see how we can map them to appropriate component types:

●Database access should be abstracted, to avoid knowledge of a specific data

schema or database engine in more than one part of the application: beans in the

role of Model can be used to accomplish this.

●The database access beans must be made available to all other parts of the

application when it starts: an application lifecycle event listener is the perfect

component type for this task.

●Only authenticated users must be allowed to use the application: a filter can

perform access control to satisfy this requirement.

●Request processing is best done with Java code: a servlet, acting as the Controller,

fits the bill.

●It must be easy to change the presentation: this is where JSP shines, acting as the

View.

Adding servlets, listeners, and filters to the mix minimizes the need for complex logic in the JSP pages. Placing all this code in Java classes instead makes it possible to use a regular Java compiler and debugger to fix potential problems.

Centralized Request Processing Using a Servlet

over the page flow of the application. The servlet can decide which type of response to generate depending on the outcome of the requested action, such as returning a common error page for all requests that fail, or different responses depending on the type of client making the request. With the help from some utility classes, it can also provide services such as input validation, I18N preparations, and in general, encourage a more streamlined approach to request handling.

When you use a servlet as a Controller, you must deal with the following basic requirements:

●All requests for processing must be passed to the single Controller servlet.

●The servlet must be able to distinguish requests for different types of processing.

Here are other features you will want support for, even though they may not be requirements for all applications:

● A strategy for extending the application to support new types of processing

requests in a flexible manner.

● A mechanism for changing the page flow of the application without modifying

code.

Mapping Application Requests to the Servlet

The first requirement for using a Controller servlet is that all requests must pass through it. This can be satisfied in many ways. If you have played around a bit with

/myApp/servlet. This is a convention introduced by Suns Java Web Server (JWS), the first product to support servlets before the API was standardized. Most servlet containers support this convention today, even though it's not formally defined in the servlet specification.

将Servlet和JSP组合使用

Servlet和JSP技术是用Java开发服务器端应用的主要技术，是开发商务应用表示端的标准。Java开发者喜欢使用它有多种原因，其一是对于已经熟悉Java语言的开发者来说这个技术容易学习；其二是Java把“一次编写，到处运行”的理念带入到Web应用中，实现了“一次编写，到处实现”。而且更为重要的是，如果遵循一些良好的设计原则的话，就可以把表示和内容相分离，创造出高质量的、可以复用的、易于维护和修改的应用程序。比方说，在HTML文档中如果嵌入过多的Java代码（scriptlet），就会导致开发出来的应用非常复杂、难以阅读、不容易复用，而且对以后的维护和修改也会造成困难。事实上，在CSDN的JSP/Servlet论坛中，经常可以看到一些提问，代码很长，可以逻辑却不是很清晰，大量的HTML和Java代码混杂在一起，让人看得一头雾水。这就是随意开发的弊端。

早期的动态网页主要采用CGI（Common Gateway Interface，公共网关接口）技术，你可以使用不同的语言编写CGI程序，如VB、C/C++或Delphi等。虽然CGI技术发展成熟且功能强大，但由于编程困难、效率低下、修改复杂等缺点，所以有逐渐被取代的趋势。在所有的新技术中，JSP/Servlet具备更高效、更容易编程、功能更强、更安全和具有良好的可移植性，因而被许多人认为是未来最有发展前途的动态网站技术。

与CGI相似，Servlet支持请求/响应模型。当一个客户向服务器递交一个请求时，服务器把请求送给Servlet，Servlet负责处理请求并生成响应，然后送给服务器，再由服务器发送给客户。与CGI不同的是，Servlet没有生成新的进程，而是与HTTP Server处于同一进程中。它通过使用线程技术，减小了服务器的开销。Servlet处理请求的过程是这样的：当收到来自客户端的请求后，调用service方法，该方法中Servlet 先判断到来的请求是什么类型的（GET/POST/HEAD…），然后调用相应的处理方法（doGet/doPost/doHead…）并生成响应。

别看这么复杂，其实简单说来Servlet就是一个Java类。与一般类的不同之处是，这个类运行在一个Servlet容器内，可以提供session管理和对象生命周期管理。因而当你使用Servlet的时候，你可以得到Java平台的所有好处，包括安全性管理、使用JDBC访问数据库以及跨平台的能力。而且，Servlet使用线程，因而可以开发出效率更高的Web应用。

JSP技术是J2EE的一个关键技术，它在更高一级的层次上抽象Servlet。它可以让常规静态HTML与动态产生的内容相结合，看起来像一个HTML网页，却作为Servlet来运行。现在有许多商业应用服务器支持JSP技术，比如BEA WebLogic、IBM WebSphere、JRun等等。使用JSP比用Servlet更简单。如果你有一个支持JSP的Web服务器，并且有一个JSP文件，你可以把它放倒任何静态HTML文件可以放置的位置，不用编译，不用打包，也不用进行ClassPath的设置，就可以像访问普通网页那样访问它，服务器会自动帮你做好其他的工作。

JSP 文件看起来就像一个普通静态HTML文件，只不过里面包含了一些Java代码。它使用.jsp的后缀，用来告诉服务器这个文件需要特殊的处理。当我们访问一个JSP页面的时候，这个文件首先会被JSP引擎翻译为一个Java源文件，其实就是一个Servlet，并进行编译，然后像其他Servlet一样，由Servlet引擎来处理。Servlet引擎装载这个类，处理来自客户的请求，并把结果返回给客户。

以后再有客户访问这个页面的时候，只要该文件没有发生过更改，JSP引擎就直接调用已经装载的Servlet。如果已经做过修改的话，那就会再次执行以上过程，翻译、编译并装载。其实这就是所谓的“第一人惩罚”。因为首次访问的时候要执行一系列以上的过程，所以会耗费一些时间；以后的访问就不会这样了。

Java servlet提供了一种强有力的API，用这个API可以访问关于请求、会话和应用程序的所有信息。将servlet和JSP页面组合起来使用，可以把应用程序的逻辑部分和外观呈现部分清楚地分开；换句话，利用这个方式可以对模型、视图和控制器这三种角色分别使用最合适的组件类型。

Servlet、过滤器和监听器

Servlet是一种Java类，它使得服务器的功能可扩展至处理请求和生成应答。它是用Servlet API定义的类和接口实现的。API由两个程序包组成：jvavax.servlet程序包包含独立于协议的类和接口，而javax.servlet.http程序包则提供HTTP特定的扩展的实用程序类。

Servlet的实质是实现了接口javax.servlet.Servlet的类，实现是直接完成或通过扩展某个支持类来完成的。该接口定义了Web容器用来管理servlet和与之交互的方法。用于处理HTTP请求的servlet一般情况下都会扩展javax.servlet.http.HttpServlet类。该类实现了Servlet接口，并提供了使用HTTP处理的附加方法。

Servlet的生命周期

Web容器管理servlet生命周期的所有方面。它根据需要创建servlet类的实例、将请求传递给实例进行处理，最终删除实例。对于HttpServlet来说，容器会在servlet 生命周期的适当时间调用方法。

除了doGet（）和doPost（）方法之外，还有一些对应于其他HTTP方法的方法：doDelete（）、doHead（）、doOptiongs（）、doPut（）和doTrace（）。一般情况下不用实现这些方法，因为HttpServlet类已经用适用于大多数servlet的方法考虑到了HEAD、OPTIONS和TRACE请求，而且DELETE和PUT这两种HTTP方法很少用在Web应用程序中。

容器只为每个Servlet创建一个实例非常重要。这意味着servlet必须是线程安全的—即，能够同时处理多个请求，每个处理都通过servlet代码作为单独的线程来执行。如果只在init（）和destroy（）方法中修改参考的对象，而且只在请求处理方法中读取他们，那么不用丧失任何细节就可以满足关于实例变量的这个要求。

编译和安装servlet

要编译servlet，必须首先确保JAR文件包含着CLASSPATH环境变量中所有Servlet API类。该JAR文件将随所有的Web容器一起发布。Tomcat中包含了一个名为servlet.jar的JAR文件，位于common/lib目录中。在Windows平台中，应在

CLASSPATH中包含JAR文件。

读取请求

传递到doGet（）和doPost（）方法的参数之一是实现了HttpServletRequest接口的对象。该接口定义的方法可提供对关于请求的许多信息的访问。

生成应答

除应答对象之外，容器还将实现HttpServletRequest接口的对象作为icanshu传递给doGet（）和doPost（）方法。该接口定义了为应答行为体获取数序程序或流的方法。它还定义了设置应答状态代码和首部的方法。

使用过滤器和监听器

Servlet规范servlet内定义了两种组件类型：过滤器和监听器。这两种类型是在Servlet 2.3规范中引入的，因此，如果你使用的是不支持该版本规范的容器，恐怕就不能继续学习了。

过滤器

过滤器是一种组件，可以解释对servlet、JSP页面或静态页面的请求以及发送给客户端之前的应答。这样可以很容易地将应用于所有请求的任务集中在一起，例如访问控制、登录和内容的开销或应用提供的服务等。过滤器对请求与应答的行为体和首部具有完全访问权限，因此还可以执行各种转换。例如，如果Accept-Language请求首部指出客户端可以处理压缩的应答，那么过滤器就可以压缩应答的行为体。

过滤器可以应用在特定servlet上，或匹配某种URL模式的所有请求上，例如以相同的路径元素开头或具有相同扩展名的URL。

监听器

监听器允许应用程序对特定事件做出回应。Servlet 2.3之前，只能处理会话属性绑定事件（在添加对象或从会话中删除对象时）。实现监听器的方式是用保存为会话属性（使用HttpSession.setAttribute()方法）的对象实现HttpSessionBinding-Listener接口。随着Servlet规范的2.3版本中新接口的引入，可以为servlet环境和会话生命周

期事件以及激活和钝化事件（容器用来暂时将会话状态保存在磁盘上或将会话移植到另一个服务器上）创建监听器。使用新的会话属性事件监听器还可以在一个位置上处理所有会话的属性绑定事件，而不是在每个会话中防止单独的监听器对象。

新类型的监听器遵循的是标准Java事件模型。换句话说，监听器是实现了一个或多个监听器接口的类。接口定义的是事件相应的方法。当应用程序启动是，容易会注册监听器类，然后该容器会在合适的事件调用那些事件方法。

使用监听器初始化共享资源

Bean一般都有需要在使用之前进行初始化。例如，它们可能需要对数据库或某些其他外部数据源的引用，还可能在内存中创建一个初始消息缓存，以便即使是第一个请求数据也可以提供更快的访问。可以在需要共享资源的servlet和JSP页面中包含初始化共享资源的代码，但是更标准的方法是在一个位置放置所有这些代码，并在假设资源已经初始化和可用的情况下，使应用程序的其他部分可以正常工作。应用程序生命周期监听器是此类资源初始化的绝好工具。此类监听器实现了javax.servlet.ServletContextListener接口，当应用程序启动和关闭时会由容器调用该接口的方法。

为每个任务选择正确的组件类型

在之前介绍的项目公告牌应用程序是相当复杂的应用程序。页面的一般都是纯粹的控制器和商务逻辑处理，它访问数据库以对用户进行身份验证，而且多数页面都需要访问控制。在现实生活中，它可能会包含更多的页面，例如，用于访问共享文档档案、事件表的页面和用于管理的一组页面等。由于应用程序在不断地发展变化，因此可能变得很难作为纯JSP应用程序来维护。例如，很容易忘记在新页面中包含访问控制代码。

很明显，这种应用程序可以从使用JSP页面与组件类型的组合中受益，其中组件类型由用于MVC角色的servlet规范所定义。下面看一下主要的要求，并了解如何将他们映射到适当的组件类型上：

数据库访问应该是抽象的，从而避免料接应用程序中多个部分的特定数据模式或数据库引擎：模型角色中的bean可以用来完成这种认知。

●数据库访问bean必须在应用程序启动时可用于所有其他的部分：应用程序

生命周期时间监听器是用了该任务的完美的组件类型。

●只有通过验证的用户才允许使用应用程序：过滤器可以完成访问控制以满足

该要求。

●用Java代码进行请求处理效果最佳：servlet作为控制器正符合需要。

●必须很容易改编外观呈现：这正是JSP的反光点，也就是作为视图。

将servlet、监听器和过滤器混合起来，就将JSP页面对复杂逻辑的需求降到了最低。将这些代码放置到Java类中后，就可以使用普通的Java编译程序和调试程序来修复潜在的问题。

使用servlet集中处理请求

将servlet作为所有应用程序请求的公共入口时，可以获得对应用程序页面流的整体控制。Servlet可以根据所请求行为的结果来决定要生成的应答类型，例如，为所有失败的请求返回公共的错误页面，或者根据发出请求的客户端返回不同的应答等。在某些使用程序类的帮助下，servlet还可以提供诸如输入验证、J18N准备之类的服务，而且通常会鼓励使用更有效率的方法来请求处理。

当使用servlet作为控制器时，必须处理下列基本要求：

●所有处理请求必须传递到单独的控制器servlet中。

●Servlet必须能够区分请求，以便进行不同类型的处理。

下面是其他一些你可能希望支持的功能，即使并非所有应用程序都要求：

●扩展应用程序以便以更灵活的方式支持新类型的请求处理。

●在不修改代码的情况下改变应用程序页面流的机制。

当然，你可以自己开发满足这些要求的servlet，但是已经有开源式servlet了，他们可以满足所有这些要求，甚至还有更多的功能。

将应用程序请求映射到servlet

使用控制器servlet的第一个要求是所有请求必须都经过该servlet。该要求可以通

过多种方式来满足。如果你以前曾经使用过servlet，那么你可能习惯于用以/myApp/servlet开头的URI来调用servlet。这是由Sun公司的Java Web Server（JWS）所引入的一个约定，JWS是在推出标准API之前第一个支持servlet的产品。今天，大部分servlet容器都支持这个约定，即使servlet规范中并没有正式的定义。