Web server and app Server

Web server and APP Server
In general, Web server transfer (serves) pages allow browsers to browse. However, the application server provides client applications with the call method ). Specifically, you can say that the Web server specifically processes HTTP requests, but the application server uses many protocols to provide business logic for applications ).

Let's take a closer look:

Web Server)
The Web server can parse the HTTP protocol (handles. When the Web server receives an HTTP request, it returns an HTTP response (response), for example, sending back an HTML page. In order to process a request, the Web server can respond to a static page or image, perform a page Jump (redirect), or send a dynamic response (dynamic response) to some other programs, such as CGI scripts, JSP (assumerver Pages) scripts, servlets, ASP (Active Server Pages) scripts, server-side) javaScript, or some other server-side technologies. Regardless of their purpose, these server-side programs usually generate an HTML response (response) for browsers to browse.

You know, the Web server's proxy model is very simple. When a request is sent to the Web server, it simply passes the request to a program that can process the request well: server scripts ). The Web server only provides an environment that can execute the server-side program and the response generated by the program. Server-side programs generally have functions such as transaction processing, database connectivity, and messaging.

Although the Web server does not support transaction processing or database connection pools, it can configure various strategies to implement fault tolerance and scalability ), for example, load balancing and caching ). Cluster Features (fetering-features) are often mistaken for only the proprietary features of application servers.

The Application Server)
According to our definition, as an application server, it exposes business logic to (expose) client applications through various protocols, including HTTP. The Web server mainly processes HTML sent to the browser for browsing, and the application server provides a way to access the business logic for the client application to use. An application uses this business logic just like calling a method of an object (or a function in a procedural language.

The client of the Application Server (including a graphical user interface (GUI) may run on a PC, a Web server, or even other application servers. The information that shuttles back and forth between the application server and its client is not limited to simple display tags. On the contrary, this information is the program logic ). It is precisely because this logic has obtained the form of (takes) data and method calls (CILS) rather than static html, so the client can use this exposed business logic as desired.

In most cases, the application server exposes the business logic (expose) to the client application through the application interface (API) of the component (component, for example, the EJB (Enterprise JavaBean) Component Model Based on J2EE (Java 2 platform, Enterprise Edition) application server. In addition, application servers can manage their own resources, such as gate-keeping duties, including security, transaction processing ), resource pooling and messaging ). Like web servers, application servers are configured with a variety of scalability and fault tolerance technologies.

Example
For example, imagine an online store (website) providing real-time pricing and availability information. This site may provide a form for you to select a product. After you submit a query, the website will perform lookup and embed the result into the HTML page to return it. Websites can be implemented in many ways. I want to introduce a scenario where no application server is used and a scenario where the application server is used. Observing the differences between the two scenarios will help you understand the functions of the application server.

Scenario 1: Web servers without application servers

In this scenario, a Web server independently provides the online store function. The Web server obtains your request and sends it to the server-side program that can process the request. This program searches for pricing information from a database or text file (flat file, Translator's note: flat file is a non-binary file without special formats, such as properties and XML files. Once found, the server-side program expresses the result information as (formulate) HTML, and finally the Web server sends it to your Web browser.

In short, the Web server simply processes HTTP requests through response HTML pages ).

Scenario 2: Web servers with Application Servers

Scenario 2 is the same as scenario 1: whether the Web server delegates response generation (delegates) to the script (Note: server-side ). However, you can place the business logic of pricing search on the application server. Due to this change, this script simply calls the lookup service of the application server, instead of knowing how to find the data and then representing it as a response (response ). In this case, when the script program generates an HTML response (response), the returned results of the service can be used.

In this scenario, the application server provides the business logic for querying the pricing information of the product. Functionality does not specify details about how to display and use this information on the client. On the contrary, the client and Application Server only send data back and forth. When a client calls the lookup service of the application server, this service simply finds and returns the result to the client.

By separating the response generation (response-generating) HTML code, the pricing (Search) logic is more reusable in applications. Other clients, such as cash registers, can also call the same service as a clerk to settle bills for the customer. On the contrary, the pricing search service in scenario 1 cannot be reused because the information is embedded in the HTML page.

All in all, in the scenario 2 model, the Web server processes HTTP requests by responding to HTML pages, while the application server processes pricing and validity (availability) request to provide application logic.

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

In addition, most application servers now include Web servers, which means that the Web server can be considered as a subset of the Application Server (subset ). Although the application server contains the functions of the Web server, developers seldom deploy the application server into a capacity: this function refers to the functions of both application servers and Web servers ). On the contrary, if needed, they usually configure the Web server independently, before and after the application server. This feature separation helps improve performance (Simple Web requests won't affect application servers), separate configurations (dedicated Web servers, clusters (clustering), and so on ), in addition, there is room for selection of the best products.