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

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.
Difference between Database Server and Application Server
An application server has applications installed on it which users on the network can then run as if they were installed on the workstation they are using.
A database server has programs installed that allow it to provide database services over a network. The data, queries, report generatores
[or]
An application server has applications installed on it which users on the network can then run as if they were installed on the workstation they are using.

A database server has programs installed that allow it to provide database services over a network. The data, queries, report generatores, etc are all stored on the server, while the client machines use a front end to access those services.
[or]
Whats the difference between an Application Server and a Web Server?
So an app Server handles the middle-tier business logic and the web
server only handles the web requests. Is that right?. So is Apache
TomCat a Web Server or a an App Server?..coz Apache has what they call
an HTTP Server, which im presuming is a Web Server, so then whats the
difference between Tomcat and the Apache HTTP Server ?. The definition
for Tomcat says it is a servlet container which confuses me even more..
is this a third category altogether or is it a polite way of saying "App
Server for J2EE" ?
Also, I know for a fact that Sybase's EAServer is both App Server and
Web Server combined. What about IBM Websphere? Is it App or Web or both
or neither ? And what App servers are usually used with IIS?..Is that

Difference between TOMCAT server and WEBLOGIC server
1. Tomcat is an webserver it only runs Servlets ans jsp but in case of Weblogic server is an App server it can run EJBs also
2. Servlets are pure java class jsp
Abstract
The corporate databases can be linked to the Web in a manner that allows clients or employees to access to corporate data through a Web browser. This paper first describes the bridge between the Web and corporate databases and discusses a series of related concepts. Secondly, a number of linking methods and their analysis are presented. Thirdly, an example web-based application developed using different linking methods is described. Finally, application architecture analysis and preliminary performance measurement results are reported.
Keywords
World Wide Web (Web), Database connectivity, Performance Measurement
Introduction
The World Wide Web (known as "WWW" or "Web") is growing at a phenomenal rate. The current Web is largely based on file system technology, which can deal well with the resources that are primarily static. However, with the unprecedented growth of resources, it is no longer adequate to rely on this conventional file technology for organising, storing and accessing large amount of information on the Web. Thus, many large Web sites today are turning to database technology to keep track of the increasing amount of data. Database technology has played a critical role in the information management field during the past years. It is believed that the integration of the Web and database technology will bring many opportunities for creating advanced information management applications (Feng and Lu 1998).
With the increasing popularity and advancement of Web technology, many organisations want to Web-enable their existing applications and databases without having to modify existing host-based applications. This not only gives all of the existing applications a common, modern look and feel but also can deploy them on corporate Intranets, the public Internet, and newer Extranets (Lu et al.1998).
Taking simple data from a database and placing it on the Web is a relatively simple task. However, in most cases, the corporate data is maintained in a variety of sources, including legacy, relational, and object databases. It is much more complicated when these diverse data sources must be queried or updated (Carriere and Kazman1997). The methods, techniques, and tools are in great demand to bridge the gap between the Web and database applications so that smooth, interactive, and integrated Web-to-database applications are made possible (Frey 1996).
There are many players in the industry taking this challenge. These include major database vendors, mainframe vendors, third party software firms, Web browser vendors, and Web server vendors. A wide range of tools and philosophies has been proposed for connecting and integrating the Web and databases (Kim 1997). In last paper (Lu et al. 1998), we presented a formal specification of web-to-database interfacing models. It is believed that web-based application architecture using different interfacing and integrating methods has much impact on the application's performance (Lazar and Holfelder 1997). This paper is to present our study on this issue.
This paper discusses the approaches and models in Web-to-database connecting technologies based on some results of the last paper. The remainder of the paper is organised in four sections. Section 2 describes the bridge between the Web and corporate databases and gives related concepts used. A number of linking methods and their analysis are provided in Section 3. An example web-based application is described in Section 4. Application architecture analysis and preliminary performance measurement results are also presented in Section 4. Conclusions and future work are reported in Section 5.
The Bridge Between The Web And Databases
Delivering data over the Web is cost effective and fast, and gives Internet users easy access to databases from any locations. Users hope to access databases via Web browsers with the same functions as provided by normal database application software. Businesses want to provide their users or customers various functions such as purchasing goods, tracking orders, searching through catalogues, receiving customised content, and viewing interesting graphics. The Web-to-database integration has become central to the jobs of corporate information systems construction.
Making database information available to Web users requires converting it from the database format to a markup language such as HTML or XML. Database packages store information in files optimised for quick access by front-end programs. When the Web server sends information to a client, the internal database format must be converted to HTML so that it is displayed correctly (Reichard 1996). A bridge between the Web and databases needs to be built. This bridge lets the Web browser replace the front-end program normally used to access the corporate databases.
Web-to-database connecting technology
To build a bridge between Web and enterprise database, a number of alternative technologies and architectures have been available. These include:
• CGI (Common Gateway Interface) is a Web standard for accessing external programs, to integrate databases with Web servers. The CGI dynamically generates HTML documents from back-end databases;
• Web server APIs, such as Microsoft's Information Server API (ISAPI), Netscape API (NSAPI), are invoked by third party software to access remote databases;
• Web-ODBC (Open Database Connectivity) gateways rely on an open API (Application Programming Interface) to access to database systems;
• Vendor-specific Web browser/data warehousing interfaces are in response to the inherent advantages of the two technologies;
• JDBC (Java Database Connectivity) is used in its Java programming language to program Java applets to access back-end databases.
Each of the above technologies has strengths and weaknesses. Several factors should be considered when making selections. These include the complexity of data, the speed of deployment, the expected number of simultaneous users, and the frequency of database updates. However, new technology is emerging and several tools are already available that make this Web-to-database access optimised for improved performance (Carriere and Kazman 1997).
Database middleware
Generally, middleware can be said to be the glue (or logic) that lies between clients and servers. It deals with all the "grim stuff" of incompatible operating systems and file structures (Bernstein 1996). Programmers on both client and server ends use APIs for requesting or receiving services and data. Middleware is used to connect diverse products that do not have a common language. There are five different kinds of middleware: object request brokers (ORB), message-oriented middleware (MOM), database middleware, transaction-processing (TP) monitors middleware, and remote procedure call (RPC) middleware (Lu et al. 1998).
Middleware technology is becoming popular to connect databases with the Web. Middleware is in the midst of an evolutionary growth spurt. As it relates to the Web, the middle tier will evolve to play an important role in things such as enabling advanced multitier-application deployment, using the Web for distributed transactional systems, managing multiple execution environments with Java, C++, and ActiveX, and providing the links to existing mission-critical information resources.
Analysis of Different Connecting Methods
CGI
CGI is a standard for interfacing external programs with Web servers. The server submits client requests encoded in URLs to the appropriate registered CGI program, which executes and returns results encoded as MIME messages back to the server. CGI's openness avoids the need to extend HTTP. Most vendors of Web server extension tools continue to support CGI even as more advanced APIs have been added. This is due to the fact that many prewritten scripts are freely available for a variety of platforms and most of the popular Web servers.
CGI programs are executable programs that run on the Web server. They can be written in any scripting language (interpreted) or programming language (must be compiled first) available to be executed on a Web server, including C, C++, Fortran, PERL, TCL, Unix shells, Visual Basic, Applescript, and others. Arguments to CGI programs are transmitted from client to server via environment variables encoded in URLs. The CGI program typically returns HTML pages on the fly (Deep and Holfelder 1996). CGI lets Webmasters add common features, such as counters and date/time displays, on-line order forms, chat pages and search engines.
CGI also has several drawbacks. Each time a CGI script is spawned, it creates an additional process on the server machine, slowing the server's response time. Also, if the CGI script is not set up correctly, security holes can occur on the server, rendering the Web site vulnerable to attacks by hackers. Another problem is that it is difficult to maintain state - that is, to preserve information about the client from one HTTP request to the next (Deep and Holfelder 1996).
CGI is an early Web-to-database integration mechanism that is being replaced by more complex software programs that lie between the Web and database servers.
Server API
An alternative to modifying or extending the abilities of the server is to use its API. APIs allow the developer to modify the server's default behaviour and give it new capabilities. In addition to addressing some of the drawbacks of CGI, the use of an API offers other features and benefits, such as the ability to share data and communications resources with a server, the ability to share function libraries, and additional capabilities in authentication and error handling. Because an API application remains in memory between client requests, information about a client can be stored and used again when the client makes another request (Frey 1996).
There are, however, some drawbacks to this approach. Unlike CGI, API functions are server-specific, because each server has a different API. Buggy API code can crash a server. And more complexity is involved in developing the code, which must manage multiple process threads and clean up memory after it is run.
ODBC and JDBC
ODBC and JDBC are types of database access middleware. ODBC is, by far, the most popular database access middleware in use today. Vendor support for ODBC is pervasive. JDBC support isn't quite at the level of ODBC support, but JDBC is growing and flourishing. Database vendors and several third-party software houses offer ODBC and JDBC drivers for a variety of databases and operating environments.
From a network administrator's point of view, they consist of client and server driver software (i.e., program files). From a programmer's point of view, they are APIs that the programmer inserts in his or her software to store and retrieve database content. While a system analyst perceives ODBC or JDBC as a conceptual connection between the application and the database, database vendors regard ODBC and JDBC as ways to entice customers who say they want to use industry standard interfaces rather than proprietary ones. And managers of data processing department view ODBC and JDBC as insurance interfaces that offer managers some measure of flexibility should they find it necessary to replace one database product with another (Wong 1997).
ODBC technology now allows Web servers to be used to directly connect with databases, rather than using third party solutions. JDBC can also directly access server ODBC drivers through a JDBC/ODBC Bridge driver, available from SunSoft. ODBC driver vendors are also building bridges from ODBC to JDBC. JDBC is intended for developing client/server applications to access a wide range of backend database resources.
As more and more web-based applications are built by using different bridging methods as discussed above, it is significant to investigate how to measure the performance of each method in a consistent and fair manner. Next section will describe an application implemented by using three main bridging methods discussed in this section.