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.

Oracle Application server

What is an Application Server?

Think of an application server as a traffic officer for all your enterprise data.
Application servers are the middle ground—the middle tier—between your database
and your software applications, handling all application operations between users and
your organization’s business applications and databases. So an application server is a
central location for developing and deploying business applications—without it, the
software that runs your business lives in isolated silos, making maintenance more
costly, upgrades more complex, and performance much slower.

Key Benefits· Simplify your infrastructure and reduce integration costs by connecting older
and newer applications easily without extensive coding.

Improve reliability and availability of applications while reducing the cost of deployment.
· Reconcile data from multiple systems.
· Scale out your applications to more users without compromising system
performance.
· Reduce costs of systems maintenance and administration.

Requirements Checklist

If your business meets most of these criteria, it’s time to consider a move to an
application server:
· You’re adding more applications and other systems that need to share
information.
· Your IT portfolio is growing, and you need to manage and administer a number
of different applications with limited resources.
· Scalability, reliability, and security are becoming more important as your
business grows.
· You need easier access to basic metrics and corporate-wide information about

Difference between Web server & Application server

A web server is a server designed to communicate with a web browser. Content includes text-based two-way communication with most of the com going from server to client. Data consists of text, formatting, graphics, sounds, and dynamic content.

An application server can be of several designs, but is basically a synchronous two-way sever that provides access to a single application shared among users through web-based or proprietiary methods. The content consists of data types, app commands, system commands, and data of complex types.

Typically, an app server provides a web-based platform for access to a database-driven application.

You could think of a web search engine as a focused application server. It's a web-based platform to access an application that queries a database of websites based on keywords.

An App Server may also use non-web methods to deliver traditional access to applications.

Let's say a company has software with 10 licenses and 100 employees. Well, you can't install 100 copies of the software, nor can you allow 10 employees to use the same computer at the same time.

Therefore, a computer could connect to an app server, get 1 of 10 licenses without violating the law.

You Both are typically accessed via the internet over the http protocol, so from the viewpoint of the client, theres no difference. There tends to be a common understanding, in the Java world, that application servers implements the full Java EE specification, while web servers implements only a subset.

See also.

Common understanding? Not for me anyways. Web servers have nothing to do with Java in my understanding.

I expect a basic web server to be able to serve static resources over http, that's it. I expect an application server to be a deployment platform for applications written in a specific language.

For example, if I extend Apache httpd (which is, in its default configuration, an already very advanced webserver with some application server characteristics) with mod_php, I get a PHP application server.

For Java, I would distinguish between Servlet Containers (like Tomcat, Jetty, etc.) and J(2)EE Application Servers (like JBoss, Websphere, etc). I expect Servlet Containers to be able to handle webapps containing servlets and JSP, while I expect J(2)EE Application Servers to implement the full J(2)EE stack. Because most of these applications are web applications, both Servlet Containers and Application Servers are usually able to act as web servers.

Application Servers Faqs

2) How do I benefit from using the Application Server?

Earlier, the only way to run applications on your home computer was to first "INSTALL" them. To do that, you would need to purchase licensed copies of the software. For applications like CodeWarrior or MATLAB, the cost would be almost $100 each. Earlier students had only two alternatives:

1. Work only on-campus by coming to the ME Learning Resource Center.

OR

2. Spend a load of money to buy the software needed and install it at home.

The Application Server gives you a third alternative. You can now work from home, and run CodeWarrior and MATLAB without having to install it. All you do is login into the ME Application Server, and choose the application you want to run.

3) Sounds great.

4)

5)

6)

7)

8)

9)

10)

11)

What is the difference between an application server and a Web server?

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

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.

Author Bio

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

Application server is a Web server with the notion of logic. In other words, you can host applications there and expose those applications through a Web-based product. Web servers just service up content, HTML pages and other Web-capable files.

What is an Application Server?

To use computers, users need certain software to be present on those computers. These software are known as applications. Common examples of Applications are Microsoft Word, Lotus 1-2-3, CodeWarrior, etc.

A server is a huge, powerful computer into which users can login and access the resources provided by the server.

Thus, an application server is a computer which allows users to login and work with certain applications on the server itself, without having to install those applications on the user's home machine.