Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

Let's examine each in more detail.

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 scrīpts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side Javascrīpts, 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.

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.
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.

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).

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.

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.

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 scrīpt. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the scrīpt knowing how to look up the data and formulate a response, the scrīpt can simply call the application server's lookup service. The scrīpt can then use the service's result when the scrīpt 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).

我的宝贝、宝贝，给你一点甜甜，让你今夜都好眠。
我的小鬼、小鬼，逗逗你的眉眼，让你喜欢这世界。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。

我的宝贝、宝贝，给你一点甜甜，让你今夜很好眠。
我的小鬼、小鬼，逗逗你的小脸，让你喜欢整个明天。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。

哇啦啦啦啦啦，我的宝贝，孤单时有人把你想念，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。
 

在我还没弄清楚什么是测试职业的时候，我已经被命运安排到这个行业中，就像还不知道爱情为何物，而已经谈上了恋爱。
在不到2年半的毕业时光里，自己经历了人生课堂给予的酸甜苦辣，对比毕业时的心境，现在已然有了奋斗的方向。
方向是一种希望，因为有了希望，使得自己能够从容与淡定。很多时候我会想，如果当初做了那样的决定或者没有做这样的决定，现在的我会是什么样子，更好还是更糟？这样做的结果往往是自寻烦恼。生活是履行蝴蝶效应法则的，所以尽管有时因懒惰而倦怠，因满足而停滞，但还是不断督促自己要更加努力，因为你今天的付出决定你的未来的所得。我记着在《大学生》杂志上看过苹果创始人（他叫什么来的）在斯坦福大学的演讲稿里的一句话，要始终相信时间会把生活的点滴串联起来。
我现在也不敢确定自己是否真的对测试由衷的喜欢，它只是满足了我对工作的几点要求：要有发展，要有成就感，Money。现在看来基本符合。也许随着未来自己会越发的不满足，就像当初毕业时只要找到一份糊口的工作就可以，慢慢希望找个有前\钱途的，然后又希望这份工作能够充实有成就感，人就是这样总会被欲望驱使，不满足-满足-不满足，这样循环着，下次自己会去追求什么，这只能留给以后思考。
新的工作已经近一个月的时间，我不得不承认这是份挑战与机遇并存的工作，我希望我可以做好，我也相信我可以做好。下个月就到25岁生日了，25岁对我来说是个男人分水岭，祝愿自己能够把今后的生活导演的更精彩。