简单的说，Web服务器提供的是在浏览器中浏览的网页，而应用程序服务器提供的是客户端应用可以调用的方法，一个更准确一点说法是：

Web服务器专门处理HTTP请求，而应用服务器可以通过任何协议向应用程序提供商业逻辑处理。

接下来让我们更深入一些。

The Web server
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Web服务器处理HTTP协议。当Web服务器接收到一个HTTP请求时，它会返回一个HTTP响应，比如返回一个HTML页面。对于一个请求，Web服务器可能会返回一个静态的HTML网页、图片、重定向响应或者将动态响应生成委派给诸如CGI脚本、JSP、servlet、ASP等其他服务端程序。无论服务端程序使用哪种技术，他它们最终会生成一个响应，这个响应通常是HTML页面，可以在Web浏览器查看。

Understand that a Web server’s delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn’t provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

Web服务器的委派模型其实相当简单。当一个请求到达Web服务器后，Web服务器就会将该请求传递给相应的程序进行处理。web服务器仅仅提供一个供服务端程序运行和回传响应的环境，除此之外它不会提供任何其他功能。服务端程序通常自己提供食物处理、数据库连接、消息处理等功能。

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

Web服务器虽然可能不支持事务处理或者数据库连接池，但其也有保持容错和可扩展的各种策略，比如负载均衡、缓存和集群。这这些特性一般是应用服务器所应该具有的。

The application server
As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

根据我们的定义，应用程序服务器通过各种协议，可能包括HTTP，向客户端应用程序提供业务逻辑。Web服务器主要用来处理向Web浏览器发送HTML页面，而应用服务器则为客户端程序提供业务逻辑。应用程序可以使用这个逻辑，就像它调用一个对象的方法一样（面向过程的话则好比调用一个函数）。

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

这些应用服务器的客户端可以包括图形用户界面（图形用户界面）在PC，一个Web服务器，甚至其他应用服务器上运行。往来的信息应用程序服务器与其客户端来回，不局限于简单的显示标记。相反，信息是程序逻辑。由于逻辑需要的数据和方法调用的形式，而不是静态HTML，客户端可以采用商业逻辑暴露然而就是了。

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

在大多数情况下，服务器通过组件API对外公开其业务逻辑，例如基于J2EE应用服务器的EJB组件。此外，应用服务器还需要维护自己的资源，比如安全、事务处理、资源池及消息处理等。同web服务器一样，应用服务器也需要使用各种容灾及可扩展策略。

An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I’ll show you one scenario that doesn’t use an application server and another that does. Seeing how these scenarios differ will help you to see the application server’s function.

Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store’s functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.

To summarize, a Web server simply processes HTTP requests by responding with HTML pages.

Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server’s lookup service. The script can then use the service’s result when the script generates its HTML response.

In this scenario, the application server serves the business logic for looking up a product’s pricing information. That functionality doesn’t say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server’s lookup service, the service simply looks up the information and returns it to the client.

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2’s model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Caveats
Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.

Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won’t impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

About the author
Tony Sintes is an independent consultant and founder of First Class Consulting, a consulting firm that specializes in bridging disparate enterprise systems and training. Outside of First Class Consulting, Tony is an active freelance writer, as well as author of Sams Teach Yourself Object-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).

来源：http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html