web服务器 和 应用服务器
关键字: tomcat, iis, apache
首先我们应该对应用服务器和web服务器有一个清晰的概念。所谓的应用服务器，就是提供应用的服务器，这里的应用有很多，比如java应用，ruby 应用，或者 c#应用。
那么什么是web服务器呢？就是提供了web功能的服务器，主要就是http服务，包括图片的下载，等等一系列和web相关的。
好吧，你会问为什么我们不能直接使用应用服务器呢？应用服务器也提供了http服务，比如tomcat。
那么我们从实际出发。当你浏览一个网页的时候，什么情况下你会觉得速度很慢？我们仅仅考虑页面本身。那当然是图片越多显示得越慢。
好吧，我们至少认识到一点，一些静态资源，例如图片，会严重影响页面打开的速度。当然，这仅仅是一个方面。
那么web服务器有什么用呢？web服务器一个优点就是在处理静态信息上。例如一些静态的html，图片，等等其他静态的东西。
那为什么tomcat不能具备这些优点？这个问题我们可以换一个说法：为什么会计不能做市场营销呢？
所以嘛，大家要分工明确，应用服务器就做好它该做的：如何解释一个jsp，如何处理java文件等等，做好这一点就足够了。而web服务器也做好它该做的：如何快速向浏览器传递信息，如何快速地让浏览器下载图片。
那你又问了，那为啥tomcat还提供一个http服务？那不是让你开发方便嘛！千万别把tomcat的http服务当成是一个web服务器。
说了这么多，那么我们对应用服务器和web服务器的整合也应该心里有数了。就拿tomcat和iis整合来说事吧！
我们到底想干什么呢？很明显，我们想让tomcat 处理对 java应用的请求，而iis应该处理图片，css 等等其他静态资源的事情。
具体的细节不谈了，无非就是配置 ispai_redirect 这个东东。因为我们主要说的分工问题，所以还是说说这个 uriworkermap.properties 文件。
这个文件就是处理分工的用的。例如我定义成如下这个样子：
/www.abc.com/eshop/*.do=ajp13
/www.abc.com/eshop/dwr/interface/*=ajp13
/www.abc.com/eshop/dwr/*=ajp13
/www.abc.com/eshop/js/*=ajp13
那么就告诉了 isapi_redirect , 以上4种请求，都交给tomcat处理。
那么其他的请求呢？当然是交给 iis了。
如果我定义成这个样子：
/* = ajp13
这下可惨了，iis被你浪费了，就好像你招聘了一个会计和一个推销的人员，但是让会计干财务的活之外，还干了推销。而推销人员给闲置了。
------------------------------------------------------------
通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说:Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。
web服务器(web server)
web服务器可以解析(handles)http协议。当web服务器接收到一个http请求(request)，会返回一个http响应 (response)，例如送回一个html页面。为了处理一个请求(request)，web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如cgi脚本，jsp(javaserver pages)脚本，servlets，asp(active server pages)脚本，服务器端(server-side)javascript，或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个html的响应(response)来让浏览器可以浏览。
要知道，web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。
虽然web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
应用程序服务器(the application server)
根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括http，把商业逻辑暴露给(expose)客户端应用程序。web服务器主要是处理向浏览器发送html以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(gui)的)可能会运行在一台pc、一个web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态html，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(api)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于j2ee(java 2 platform, enterprise edition)应用程序服务器的ejb(enterprise javabean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。
一个例子
例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在html页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。
情景1:不带应用程序服务器的web服务器
在此种情景下，一个web服务器独立提供在线商店的功能。web服务器获得你的请求(request)，然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注:flat file是指没有特殊格式的非二进制的文件，如properties和xml文件等)中查找定价信息。一旦找到，服务器端(server-side)程序把结果信息表示成(formulate)html形式，最后web服务器把会它发送到你的web浏览器。
简而言之，web服务器只是简单的通过响应(response)html页面来处理http请求(request)。
情景2:带应用程序服务器的web服务器
情景2和情景1相同的是web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server -side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生html响应(response)时就可以使用该服务的返回结果了。
在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。
通过从响应产生(response-generating)html的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在 html页中了。
总而言之，在情景2的模型中，在web服务器通过回应html页面来处理http请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。
警告(caveats)
现在，xml web services已经使应用程序服务器和web服务器的界线混淆了。通过传送一个xml有效载荷(payload)给服务器，web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。
另外，现在大多数应用程序服务器也包含了web服务器，这就意味着可以把web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有web服务器的功能)。相反，如果需要，他们通常会把web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的web请求(request)就不会影响应用程序服务器了)，分开配置(专门的web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地
-----------------------------------------------
文章分类:Java编程
参考：
http://dawanghai.iteye.com/blog/663927
What is the difference between an application server and a Web server?
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 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.
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.
How do Web and application servers fit into the enterprise?
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.
Tomcat Tomcat严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的 Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，数据库连接池，用户事务 处理等等。
web服务器：Tomcat
应用服务器：IBM Websphere,BEA WebLogic,RedHat JBoss
首先我们应该对应用服务器和web服务器有一个清晰的概念。所谓的应用服务器，就是提供应用的服务器，这里的应用有很多，比如java应用，ruby 应用，或者 c#应用。
那么什么是web服务器呢？就是提供了web功能的服务器，主要就是http服务，包括图片的下载，等等一系列和web相关的。
好吧，你会问为什么我们不能直接使用应用服务器呢？应用服务器也提供了http服务，比如tomcat。
那么我们从实际出发。当你浏览一个网页的时候，什么情况下你会觉得速度很慢？我们仅仅考虑页面本身。那当然是图片越多显示得越慢。
好吧，我们至少认识到一点，一些静态资源，例如图片，会严重影响页面打开的速度。当然，这仅仅是一个方面。
那么web服务器有什么用呢？web服务器一个优点就是在处理静态信息上。例如一些静态的html，图片，等等其他静态的东西。
那为什么tomcat不能具备这些优点？这个问题我们可以换一个说法：为什么会计不能做市场营销呢？
所以嘛，大家要分工明确，应用服务器就做好它该做的：如何解释一个jsp，如何处理java文件等等，做好这一点就足够了。而web服务器也做好它该做的：如何快速向浏览器传递信息，如何快速地让浏览器下载图片。
那你又问了，那为啥tomcat还提供一个http服务？那不是让你开发方便嘛！千万别把tomcat的http服务当成是一个web服务器。
说了这么多，那么我们对应用服务器和web服务器的整合也应该心里有数了。就拿tomcat和iis整合来说事吧！
我们到底想干什么呢？很明显，我们想让tomcat 处理对 java应用的请求，而iis应该处理图片，css 等等其他静态资源的事情。
具体的细节不谈了，无非就是配置 ispai_redirect 这个东东。因为我们主要说的分工问题，所以还是说说这个 uriworkermap.properties 文件。
这个文件就是处理分工的用的。例如我定义成如下这个样子：
/www.abc.com/eshop/*.do=ajp13
/www.abc.com/eshop/dwr/interface/*=ajp13
/www.abc.com/eshop/dwr/*=ajp13
/www.abc.com/eshop/js/*=ajp13
那么就告诉了 isapi_redirect , 以上4种请求，都交给tomcat处理。
那么其他的请求呢？当然是交给 iis了。
如果我定义成这个样子：
/* = ajp13
这下可惨了，iis被你浪费了，就好像你招聘了一个会计和一个推销的人员，但是让会计干财务的活之外，还干了推销。而推销人员给闲置了。
------------------------------------------------------------
通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说:Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。
web服务器(web server)
web服务器可以解析(handles)http协议。当web服务器接收到一个http请求(request)，会返回一个http响应 (response)，例如送回一个html页面。为了处理一个请求(request)，web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如cgi脚本，jsp(javaserver pages)脚本，servlets，asp(active server pages)脚本，服务器端(server-side)javascript，或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个html的响应(response)来让浏览器可以浏览。
要知道，web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。
虽然web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
应用程序服务器(the application server)
根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括http，把商业逻辑暴露给(expose)客户端应用程序。web服务器主要是处理向浏览器发送html以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(gui)的)可能会运行在一台pc、一个web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态html，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(api)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于j2ee(java 2 platform, enterprise edition)应用程序服务器的ejb(enterprise javabean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。
一个例子
例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在html页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。
情景1:不带应用程序服务器的web服务器
在此种情景下，一个web服务器独立提供在线商店的功能。web服务器获得你的请求(request)，然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注:flat file是指没有特殊格式的非二进制的文件，如properties和xml文件等)中查找定价信息。一旦找到，服务器端(server-side)程序把结果信息表示成(formulate)html形式，最后web服务器把会它发送到你的web浏览器。
简而言之，web服务器只是简单的通过响应(response)html页面来处理http请求(request)。
情景2:带应用程序服务器的web服务器
情景2和情景1相同的是web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server -side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生html响应(response)时就可以使用该服务的返回结果了。
在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。
通过从响应产生(response-generating)html的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在 html页中了。
总而言之，在情景2的模型中，在web服务器通过回应html页面来处理http请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。
警告(caveats)
现在，xml web services已经使应用程序服务器和web服务器的界线混淆了。通过传送一个xml有效载荷(payload)给服务器，web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。
另外，现在大多数应用程序服务器也包含了web服务器，这就意味着可以把web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有web服务器的功能)。相反，如果需要，他们通常会把web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的web请求(request)就不会影响应用程序服务器了)，分开配置(专门的web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地
-----------------------------------------------
文章分类:Java编程
参考：
http://dawanghai.iteye.com/blog/663927
What is the difference between an application server and a Web server?
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 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.
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.
How do Web and application servers fit into the enterprise?
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.
Tomcat Tomcat严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的 Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，数据库连接池，用户事务 处理等等。
web服务器：Tomcat
应用服务器：IBM Websphere,BEA WebLogic,RedHat JBoss