A lot of views all around the web could be found regarding the discussion on the difference between a Web-server and an Application server. I am compiling this post so that we can try to shed some light on this so as to come up with some understanding of this topic in terms of a layman. I would request the readers of this post to share their views using simple language and without using vague terms. Let's start..
I read an example on some forum which I quite liked. It is stated below.
“Web-server actually processes static content, like when we request to access a webpage like Google, it will go to the web server first and as is expected and the Google home page will be displayed. Now application server comes into the picture. When we enter something in the search box, like something we wanna search, now here application server comes into action as the web server alone cannot take the dynamic request. The web server can employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering but it cannot search the database and do a lot of processing. The application server is actually software.”
This means that the web server accepts requests from the user from a browser using HTTP protocol and then forwards it to the application server for further action. Let's note a point here the capability of the application server is just not limited to accepting requests using HTTP protocol, it can also accept requests using other protocols such as RMI/RPC whereas the web-server just serves the HTTP request.
Eg of webservers: Apache HTTP Server, Sun ONE Web Server, iPlanet Web Server
Web Servers are mostly designed to serve static content. Most of the Web Servers are having plugins to support scripting languages like Perl, PHP, ASP, JSP etc. through which these servers can generate dynamic HTTP content. Most of the application servers have a Web Server as an integral part of them, which means Application Servers are capable of whatever Web Server is capable of. Additionally, an Application Server has components and features to support Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
As web servers are well suited for static content and app servers for dynamic content, most of the production environments have web servers acting as reverse proxy to app servers. The web server resides between the web browser and application server and the request from the user’s browser is first intercepted by the web server and then forwarded to the app server. This means when a page request comes from the user, static contents such as images/static HTML is served by the web server that interprets the request and then using some kind of filtering technique (mostly an extension of the requested resource) web server identifies the dynamic content request and transparently forwards to the app server. Then the application server exposes the application logic for use by client application programs. The application program can use this logic just as it would call a method on an object. In most cases, the app 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.
An example of such a configuration is
Apache HTTP Server and BEA WebLogic Server. Apache HTTP Server is the Web Server and BEA WebLogic is the Application Server.
Apache HTTP Server and Tomcat Server. Apache HTTP Server is the Web Server and Tomcat is the Application Server.
Internet Information Server and SharePoint Server. IIS is a web server; SharePoint is an application server. SharePoint sits “on top” of IIS, executes specific logic, and serves the results via IIS.
So, the question arises When an application server not only hosts an application but also can perform the functions of a web server then whats the need for a webserver? The answer would be that an architect would never choose to expose the server on which his application is hosted, directly to the user's request, keeping security in mind.
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.
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.
Eg: Apache HTTP Server, Sun ONE Web Server, iPlanet Web Server
The application server:
An application server exposes business logic to client applications through various protocols including HTTP, TCP/IP and RMI. 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.
Difference between AppServer and a Web server:
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols. WebServer serves pages for viewing in the web browser, application server exposes business logic for client applications through various protocols.
The WebServer delegation model is fairly simple, when the request comes into the web server, it simply passes the request to the program best able to handle it(Server side program). It does not support transactions and database connection pooling.
The application server is more capable of dynamic behaviour than web server. We can also configure the application server to work as a web server. Simply application server is a superset of the webserver.
WebServer can execute only web applications i.e. servlets and JSPs and has only a single container known as Web container which is used to interpret/execute web applications.
The application server can execute Enterprise application, i,e (servlets, jsps, and EJBs) it has two containers
Web-Container (for interpreting/executing servlets and jsps)
EJB-Container (for executing EJBs). It can perform operations like load balancing, transactions etc