Differences between WEB servers, application servers, and HTTP servers

Differences between WEB servers, application servers, and HTTP servers

What are the differences between WEB servers, application servers, and HTTP servers? Which server does IIS, Apache, Tomcat, Weblogic, and WebSphere belong to? these problems have been confusing for a long time. Today, we have finally sorted them out:

The basic function of a Web server is to provide Web information browsing services. It only supports the HTTP protocol, HTML document format, and URL. Works with the client's Web browser. Because the main protocol supported by the Web server is HTTP, the HTTP server and the WEB server are usually equal (whether the web server that supports the Protocol other than HTTP has not been verified by the author ), this is one thing.

Application Server (Application Server). Let's take a look at Microsoft's definition: "We define an application server as" underlying System Software for executing shared business applications as a server ". Just as the file server provides files for many users, the application server allows multiple users to use the application at the same time (usually the application created by the customer )"

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 (serves) business logic for applications ).

Taking JavaEE as an example, the Web server mainly processes static pages and serves as a Servlet container to interpret and execute servlet/JSP, while the application server runs the business logic, it is mainly related to J2EEAPI, such as EJB, JNDI, and JMXAPI. It also includes functions such as transaction processing and database connection. Therefore, in enterprise applications, the application server provides more powerful functions than the WEB server.

In this definition, IIS, Apache, and Tomcat can all belong to Web servers, while Weblogic and WebSphere both belong to application servers.

　　Apache: In Web servers, Apache is a pure Web server and is often used together with Tomcat. It has powerful interpretation capabilities for HTML pages, but cannot interpret the server-side script code (JSP/Servlet) embedded in the page ).

　　Tomcat: In the early days, Tomcat was a JSP/Servlet interpretation engine embedded in Apache. Apache + Tomcat is equivalent to IIS + ASP. Later, Tomcat is no longer embedded in Apache, And the Tomcat process runs independently of the Apache process. In addition, Tomcat is an independent Servlet and JSP Container. the business logic layer code and interface interaction layer code can be separated. Therefore, Tomcat is called a lightweight application server.

　　IIS: Microsoft's early IIS is a pure Web server. Later, it was embedded with the ASP engine, which could explain the VBScript and JScript server code. Then, it could be used as an application server. Of course, it cannot be compared with the J2EE application server at all. However, in terms of functionality, in principle, it can barely be called an application server. Specifically, it is a Web server with some application server features.

　　To sum up, Apache is a pure web server, while Tomcat and IIS have the ability to interpret and execute server-side code, which can be called a lightweight application server or a Web server with server functions. Weblogic and WebSphere are definitely Application Servers because they provide powerful J2EE functions. For Tomcat in the middle, it can be used together with Apache, a pure Web server, or deployed together with the application server as an aid of the Application Server:

I. Tomcat and Application Server

So far, Tomcat has been regarded as the Servlet/JSPAPI executor, also known as the Servlet container. However, not only does Tomcat provide this, but it also provides the implementation mechanism of JNDI and JMXAPI. However, Tomcat is still not an application server because it does not support most j2eeapis.

Interestingly, many application servers usually use Tomcat as their Servlet and JSPAPI containers. Tomcat allows developers to embed Tomcat into their applications by adding a line of acknowledgment. Unfortunately, many commercial application servers do not comply with this rule.

For developers, it is an excellent solution to use Servlet, JSP, JNDI, and JMX technologies to generate JavaWeb applications. However, to find other j2eeapis, finding an application server or using Tomcat as an aid to the Application Server is a good solution. The third method is to find an independent J2EEAPI implementation, then combine them with Tomcat. Although integration brings about problems, this method is the most effective ..

Ii. Tomcat and Web Server

Tomcat is a container that supports Servlet and JSP running. Servlet and JSP can generate dynamic web content based on real-time needs. For Web servers, Apache only supports static Web pages, but does not support dynamic Web pages. Tomcat can serve dynamic Web pages and support static Web pages. Although it does not have a common Web server that is fast and features less abundant than the Web server, Tomcat gradually supports constant expansion of static content. Most Web servers use underlying languages such as C and take advantage of the features of the corresponding platform. Therefore, the Tomcat execution speed written in pure Java cannot be compared with those of them.

Generally, a large site combines Tomcat with Apache. Apache is responsible for accepting all HTTP requests from the client, and then forwards Servlets and JSP requests to Tomcat for processing. After Tomcat completes processing, it returns the response to Apache, and finally Apache returns the response to the client.

In addition, to improve performance, you can connect to multiple tomcat servers using one apache server to achieve load balancing.

For more details about the differences between WEB servers and application servers, refer to the following article:

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 (serves) 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. To process a request, the Web server can respond to a static page or image, perform page Jump (redirect), or send a dynamic response (dynamicresponse) to some other programs, such as CGI scripts, JSP (JavaServerPages) scripts, servlets, ASP (ActiveServerPages) 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 transactionprocessing, databaseconnectivity, and messaging.

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

TheApplicationServer)

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 (EnterpriseJavaBean) Component Model Based on J2EE (Java2Platform, EnterpriseEdition) application server. In addition, application servers can manage their own resources, such as gate-keepingduties, including security, transactionprocessing, and resourcepooling ), 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 (flatfile, Translator's note: flatfile 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 (businesslogic) of search pricing on the application server. Due to this change, this script simply calls the lookupservice 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 lookupservice 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, XMLWebServices 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.