The difference between APP server and Web server

Original: http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html

Simply put, the Web server provides the page to the browser, and the app server provides the interface that the client can invoke. Specifically, we can say:

The Web server handles HTTP requests, and the app server handles the logic of the application based on a number of different protocols.

The differences between them are described in detail below.

Web server

The Web server handles the HTTP protocol. When an HTTP request is received, the Web server returns an HTTP response, such as an HTML page. In order to process the request, it may respond to a static HTML page, picture, redirect, or other dynamic response of the agent (delegate). These dynamic responses can be generated by other programs, including CGI scripts, Jsps,servlets,asps, server-side JavaScript, or other server-side technologies. These server-side programs respond most of the time to HTML pages for browser access.

Understanding the proxy model of a Web server (delegate models) is relatively straightforward. When a Web server receives a request, it simply gives the request to the optimal program to process the request. In addition to providing a simple running environment for a server program (where a server program can run and return a generated response), the Web server does not provide any functionality. Server programs generally handle Exchange (transaction), database connections, message distribution, and so on.

Although the Web server does not provide the above services, it generally provides scalability such as fault tolerance, load balancing, caching, clustering, and so on. The latter, in general, should not be deployed on a Web server, but on an app server!

App Server

According to our definition, an app server can provide application logic processing for client programs based on a variety of protocols, which may contain HTTP protocols. Unlike Web servers that are primarily sent to display HTML pages on a browser, the app server handles application logic issues for the client program. Applications use these logic as simple as invoking an object's method (or for a function in procedural programming).

These applications may include GUI processes running on a PC, Web servers, and even other app servers. The communication between the app server and the client is not limited to the simple display tag, but can be by the program logic, such as data form, method call, rather than static HTML, so that the client program can be used on demand!

In most cases, the app server provides application logic through component APIs, such as EJBS based on the Java EE app server. In many cases, the app server manages its own resources. These responsibilities (gate-keeping) include security, process interaction, resource pooling, message distribution, and so on. Like Web servers, app servers may require a variety of extensibility and fault tolerance mechanisms.

An example

As an example of an online store that provides real-time pricing and related information, it is highly likely to provide a form that allows users to select different products and query them. It will look up and display the results via HTML pages. This website may have many ways to implement this function, below we will give two opposite examples, one does not use the app server, and the other uses. With these two examples, you can help you understand the functionality of the app server.

Scenario 1:web server, not app server

In this scenario, the Web server alone provides the functionality of the online store. It accepts the user's request and gives it to the server-side program for processing. The server-side program finds the price information through a database, or plain text, and then generates an HTML response that is returned to the user's browser through the Web server.

In summary, the Web server only needs to accept HTTP requests and respond to HTML pages.

Scene 2:web server + app Server

As with scenario 1, the Web server still proxies the response generated by the script. But you can deploy the business logic on the app server. In this way, the script does not need to pay attention to how to query and generate the response, but only need to invoke the app server to provide the query service, so that it generates its HTML response.

In this example, the app server provides the business logic for price queries. This logic should not include how to display or force the client to use the data. Instead, the client interacts with the app server, and the service finds the information and returns only when the client invokes the price lookup service for the app server.

The reusability of the price query logic has improved after leaving the raw components of the HTML code. Another client, such as a cash register, can also call this interface. In Scenario 1, the price lookup service is difficult to reuse because it is closely linked to HTML pages.

As a summary, in the second scenario, the Web server processes the HTTP request and returns an HTML page, while the app server processes the business logic.

Precautions

Recently, XML Web servers have blurred the boundaries of app servers and Web servers. Send an XML request to the Web server, and the Web server can process the data and return the response just like the previous app server.

Also, many app servers contain Web servers, which means you can think of a Web server as a subset of your app servers. Although the app server contains the functionality of a Web server, developers rarely publish an app server as such. They usually leave the Web server and the app server separated, if needed. The goal is that performance (simple Web requests do not affect the performance of the app server), Release configurations (dedicated web servers, clusters, etc.), and better vendor selection.