Web server, Application server, HTTP server differences

Web server, Application server, HTTP server differences

What is the difference between a Web server, an application server, and an HTTP server? What kind of server IIS, Apache, Tomcat, Weblogic, WebSphere all belong to, these problems puzzled for a long time, today finally combed clear:

The basic function of-web server is to provide Web information browsing service. It only supports HTTP protocols, HTML document formats, and URLs. Mates with the client's Web browser. Because the Web server mainly supports the protocol is HTTP, so usually the HTTP server and the Web server is equal (there is no support other than HTTP protocol Web server, the author has not verified), said the same thing.

　　Application Server (Application server), let's take a look at Microsoft's definition of it: "We define the application server as the underlying system software that executes the shared business application as a server." Just as file servers provide files for many users, application servers allow multiple users to use the application at the same time (typically customer-created applications) "

In layman's words, Web server delivery (serves) pages allow the browser to browse, whereas the application server provides a method (methods) that the client application can invoke (call). To be exact, you can say that the Web server is dedicated to HTTP requests (request), but the application server is providing (serves) business logic for the application through a number of protocols.

In Java EE, for example, the Web server mainly handles static page processing and acts as a servlet container to interpret and execute servlet/jsp, while the application server runs business logic, primarily the Java EE API, such as EJB, Jndi, and JMX APIs, and includes transactional processing, Database connectivity, the application server provides more power than a Web server in an enterprise-class application.

With this definition, IIS, Apache, and Tomcat can all belong to the Web server, and Weblogic and WebSphere belong to the application server.

Apache: In a Web server, Apache is a purely Web server that is often paired with Tomcat. It has a powerful interpretation of HTML pages, but does not explain the server-side scripting code (Jsp/servlet) within the embedded page.

Tomcat: Early Tomcat was a Jsp/servlet interpretation engine embedded in Apache Apache+tomcat equivalent to iis+asp. Later Tomcat is no longer embedded in Apache, and the Tomcat process runs independently of the Apache process. Furthermore, Tomcat is already a standalone servlet and JSP container, and the business Logic layer code and interface interaction layer code can be separated. So, someone called Tomcat a lightweight application server.

IIS: Microsoft's early IIS is a purely Web server. Later, it embeds an ASP engine that interprets VBScript and JScript server-side code, which can be used concurrently as an application server. Of course, it doesn't compare with the Java EE Application Server at all, but, functionally speaking, it can be called the application server in principle. To be exact, it is a Web server with a bit of application server functionality.

Top: Apache is a purely Web server, and Tomcat and IIS have the ability to interpret server-side code as a lightweight application server or a Web server with server functionality. Weblogic, WebSphere is undoubtedly the absolute application server because it can provide the powerful Java EE function. For Tomcat in the middle, it can be used with a pure Web server Apache, or as an application server to be deployed with the application server:

• One,tomcat and application Server

  So far, Tomcat has been considered the executor of the Servlet/jsp API, as well as the so-called servlet container. However, Tomcat does not only do this, it also provides the implementation mechanism for JNDI and JMX APIs. However, Tomcat is still not an application server because it does not provide support for most of the Java EE APIs.

  Interestingly, many application servers today often use Tomcat as a container for their servlet and JSP APIs. Because Tomcat allows developers to embed tomcat into their applications simply by adding a line of acknowledgements. Unfortunately, many commercial application servers do not comply with this rule.

  For developers, choosing Tomcat is a great solution if you're looking to build Java Web applications using servlet, JSP, Jndi, and JMX Technologies, but to find support for other EE APIs, Finding an application server or using Tomcat as an application server is a good solution, and the third Way is to find a separate Java EE API implementation and then combine them with Tomcat. Although consolidation can bring about problems, this approach is most effective.

• Ii.Tomcat vs. Web server

  Tomcat is a container that provides support for Servlets and JSPs to run. Servlets and JSPs can generate dynamic Web content based on real-time needs. For Web servers, Apache only supports static web pages, and it is powerless to support dynamic Web pages, while Tomcat can serve dynamic Web pages and support static Web pages. Although it is not as fast as the usual Web server, it is not as rich as the Web server, but Tomcat is gradually expanding to support static content. Most Web servers are written in the underlying language, such as C, and take advantage of the features of the corresponding platform, so Tomcat execution speed written in plain Java is unlikely to be comparable to them.

  In general, the large site is a combination of Tomcat and Apache, Apache is responsible for accepting all HTTP requests from the client, and then forwarding Servlets and JSP requests to Tomcat for processing. After Tomcat finishes processing, the response is passed back to Apache, and the final Apache returns the response to the client.

  and to improve performance, a single Apache can connect multiple tomcat for load balancing.

  For a more detailed distinction between Web servers and application servers, refer to this article:

  In layman's words, Web server delivery (serves) pages allow the browser to browse, whereas the application server provides a method (methods) that the client application can invoke (call). To be exact, you can say that the Web server is dedicated to HTTP requests (request), but the application server is providing (serves) business logic for the application through a number of protocols.

  Let us come to the following way:

  　　Web servers (Web server)

  The Web server can parse the (handles) HTTP protocol. When the Web server receives an HTTP request (request), it returns an HTTP response (response), such as sending back an HTML page. In order to process a request, the Web server can respond (response) to a static page or picture, perform a page jump (redirect), or delegate the generation of dynamic Responses (response) (delegate) Give some other programs such as CGI scripts, JSP (JavaServer Pages) scripts, servlets,asp (Active server Pages) scripts, server-side (server-side) JavaScript, or some other server-side (server-side) technology. These server-side (server-side) programs typically produce an HTML response (response) to allow the browser to navigate, regardless of the purpose of their (translator's note: script).

  You know, the Web server's proxy model (delegation models) is very simple. When a request is sent to the Web server, it simply passes the request to the program that can handle the request (the Translator note: server-side script). The Web server simply provides an environment that can perform server-side (server-side) programs and return (program-generated) responses (response) without exceeding the scope of the function. Server-side (server-side) programs typically have features such as transaction processing (transaction processing), database connection (DB connectivity), and messages (messaging).

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

  　　Application Server (the application server)

  According to our definition, as an application server, it exposes commercial logic to (expose) client applications through various protocols that can include HTTP. The Web server primarily handles sending HTML to the browser for browsing, and the application server provides access to business logic for use by client applications. The application uses this business logic just as you would call a method of an object (or a function in a procedural language).

  The client of the application server (which contains a graphical user interface (GUI)) may run on a PC, a Web server, or even other application servers. The information that travels back and forth between the application server and its clients (traveling) is not limited to simple display tags. Instead, this information is the program logic. It is this logic that makes the takes data and method calls (calls) rather than static HTML, so that the client can use the exposed business logic as it pleases.

  In most cases, the application server exposes the business logic (expose) (to the client application) through the component (component) application interface (API), for example, based on the Java 2 Platform, Enterprise Edition ) The EJB (Enterprise JavaBean) component model of the application server. In addition, the application server can manage its own resources, such as looking at the work of the Gate (gate-keeping duties) including security, transaction processing (transaction processing), resource pool (resource pooling ), and messages (messaging). Like Web servers, application servers are configured with a variety of extensible (scalability) and fault tolerant (fault tolerance) technologies.

An example

For example, imagine an online store (website) that provides real-time pricing (real-time pricing) and validity (availability) information. This site is likely to provide a form that allows you to select products. When you submit a query, the site searches (lookup) and returns the results inline in an HTML page. Web sites can be implemented in a number of ways. I want to describe a scenario that does not use an application server and a scenario that uses an application server. Looking at the differences between the two scenarios will help you understand the functionality of the application server.

Scenario 1: A Web server without an application server

In such a scenario, a Web server independently provides the functionality of the online store. The Web server obtains your request and then sends it to the server-side (server-side) program that can process the request. This program looks for pricing information from a database or text file (flat file, translator Note: Flat files refers to non-binary documents that have no special format, such as properties and XML files, etc.). Once found, the server-side (server-side) program represents the resulting information in the form of (formulate) HTML, and the last Web server sends it to your Web browser.

In short, the Web server simply handles HTTP requests (request) via the response (response) HTML page.

Scenario 2: A Web server with an application server

Scenario 2 and Scenario 1 are the same as a Web server or a response (response) generation Delegate (delegates) to the script (translator Note: server-side (server-side) program). However, you can put the business logic of the lookup pricing on the application server. Because of this change, this script simply invokes the application server's lookup service (lookup services) instead of knowing how to find the data and then represent (formulate) a response (response). When the script generates an HTML response (response), it can use the return result of the service.

In this scenario, the application server provides (serves) the business logic for querying the pricing information for the product. This feature (functionality) does not indicate details about how the display and the client can use this information, whereas the client and application servers simply send data back and forth. When a client invokes the lookup service of an application server, the service simply finds and returns results to the client.

The pricing (lookup) logic is more reusable in the application by separating it from the code that generates (response-generating) HTML. Other clients, such as the cash register, can also call the same service to checkout the customer as a clerk. Instead, the pricing lookup service in Scenario 1 is not reusable because the information is embedded in the HTML page.

All in all, in the model of Scenario 2, the Web server handles HTTP requests (request) by responding to HTML pages, while the application server provides application logic by processing pricing and validity (availability) requests (request).

Warning (caveats)

Now, XML Web Services has confused the boundaries of application servers and WEB servers. By transmitting an XML payload (payload) to the server, the Web server can now handle data and response (response) as much as the previous application server.

In addition, most application servers now contain Web servers, which means that Web servers can be treated as a subset of application servers (subset). Although the application server contains the functionality of the Web server, developers rarely deploy the application server (deploy) to this function (capacity) (Translator Note: This function refers to both the functionality of the application server and the functionality of the Web server). Conversely, if required, they will typically have a Web server configured independently, and the application server is one after the other. This separation of functionality helps improve performance (simple Web requests (request) Do not affect application servers), separate configurations (dedicated Web servers, clusters (clustering), and so on), and give the best product selection leeway.

Web server, Application server, HTTP server differences