Talk about the difference between an Web server and an application server

  • 2020-05-06 12:00:31
  • OfStack

In layman's terms, the Web server delivers (serves) pages that the browser can browse, whereas the application server provides methods that the client application can invoke (call) (methods). To be exact, you can say: the Web server specializes in handling HTTP requests (request), but the application server provides (serves) business logic (business logic) to the application through a number of protocols.  

Here's how:  

Web server (Web Server)

The Web server can resolve the (handles)HTTP protocol. When an Web server receives an HTTP request (request), it returns an HTTP response (response), such as an HTML page. In order to process a request (request), Web server can respond to (response) a static page or picture, page jump (redirect), or the dynamic response (dynamic response) generation delegate (delegate) to some other programs such as CGI script, JSP(JavaServer Pages) script, servlets, ASP(Active Server Pages) script, Server-side (server-side)JavaScript, or some other server-side (server-side) technology. Regardless of their purpose, these server-side (server-side) programs typically produce an HTML response (response) for the browser to browse.  

Remember, the proxy model for the Web server (delegation model) is very simple. When a request (request) is sent to the Web server, it simply passes the request (request) to a program that handles the request (request) well. The Web server only provides an environment where server-side (server-side) programs can be executed and responses (response) can be returned (response) without going beyond the scope of the function. Server-side (server-side) programs typically have transaction processing (transaction processing), database connections (database connectivity), and messaging (messaging).  

Although the Web server does not support transaction processing or database connection pooling, it can configure (employ) various policies (strategies) to achieve fault tolerance (fault tolerance) and scalability (scalability), such as load balancing (load balancing) and buffering (caching). Cluster characteristics (clustering -- features) are often mistaken for features that are only proprietary to the application server.  

application server (The Application Server)  
According to our definition, as an application server, it can include HTTP through various protocols, exposing business logic to (expose) client applications. The Web server primarily handles sending HTML to the browser for browsing, while the application server provides access to business logic for use by client applications. Applications use this business logic as if you were calling a method of an object (or a function in a procedural language).  

The client side of the application server (which contains the graphical user interface (GUI)) may run on an PC server, an Web server, or even another application server. The information shuttling between the application server and its clients (traveling) is not limited to simple display tags. Instead, this information is program logic (program logic). Because this logic takes the form of (takes) data and method calls (calls) rather than static HTML, the client can use the exposed business logic at will.  

In most cases, the application server exposes the business logic (expose)(to the client application) through the application programming interface (API) of the component (component), such as the EJB(Enterprise JavaBean) component model based on the J2EE(Java 2 Platform, Enterprise Edition) application server. In addition, the application server can manage its own resources, such as gate jobs (gate-keeping duties), including security (security), transaction processing (transaction processing), resource pools (resource pooling), and messages (messaging). Just like the Web server, the application server is configured with a variety of extensible (scalability) and fault-tolerant (fault tolerance) technologies.  

An example is  
For example, imagine an online store (website) that provides real-time pricing (real-time pricing) and availability (availability) information. This site (site) will probably provide a form (form) for you to select products. When you submit a query (query), the site looks it up (lookup) and returns the result embedded in the HTML page. Websites can do this in a number of ways. I'll describe a scenario where the application server is not used and a scenario where the application server is used. Observing the difference between the two scenarios will help you understand the functionality of the application server.  

scenario 1 : Web





In this scenario, an Web server independently provides the functionality of an online store. The Web server gets your request (request) and sends it to the server (server-side) to process the request (request). This program looks up pricing information from a database or text file (flat file) that is not a binary file in a particular format, such as properties, XML, etc.). Once found, the server-side (server-side) program represents the resulting information as (formulate)HTML, and finally the Web server sends it to your Web browser.  

In short, the Web server simply handles HTTP requests (request) by responding to (response)HTML pages.  

scenario 2 : Web server with application server
Scenario 2 is identical to scenario 1 in that the Web server still delegates the generation of the response (response) to the script (delegates). However, you can put the business logic of finding pricing (business logic) on the application server. Because of this change, the script simply calls the lookup service of the application server (lookup service), rather than already knowing how to find the data and then presenting it as (formulate) a response (response). This is when the script produces an HTML response (response) and the return result of the service can be used.  

In this scenario, the application server provides (serves) the business logic for querying the pricing information for the product. This functionality (functionality) does not specify the details of how this information is displayed and used by the client, instead the client and the application server simply send the data back and forth. When a client invokes the application server's lookup service (lookup service), the service simply looks up and returns the result to the client.  

This pricing (find) logic is more reusable in the application by being separated from the code for response generation (response-generating)HTML. Other clients, such as cash registers, can also call the same service (service) to checkout customers as a clerk. In contrast, the pricing lookup service in scenario 1 is not reusable because the information is embedded in HTML.  

In summary, in the scenario 2 model, the Web server handles the HTTP request (request) by responding to the HTML page, while the application server provides the application logic by processing the pricing and availability (availability) request (request).  

Warning (Caveats)  
Now, XML Web Services has confused the boundaries between the application server and the Web server. By passing an XML payload (payload) to the server, the Web server can now handle as much data and response (response) as the previous application server.  

In addition, most application servers now include Web servers, which means that Web servers can be considered a subset of application servers (subset). Although the application server includes the functionality of the Web server, developers rarely deploy the application server (deploy) as such (capacity). Instead, they typically configure the Web server separately from the application server if needed. This separation of functionality helps improve performance (simple Web requests (request) do not affect the application server), separates configuration (dedicated Web servers, clusters (clustering), and so on), and leaves room for selection of the best products.