WEBserver, Application server, httpserver differences

WEBserver, Application server, httpserver differences

What is the difference between WEBserver, application server, Httpserver? What kind of server IIS, Apache, Tomcat, Weblogic, and WebSphere belong to, these problems have been confusing for a long time, and today we finally sorted out:

The basic function of-webserver is to provide web information browsing service. It only needs to support HTTP protocols, HTML document formats, and URLs.

Mates with the client's Web browser. Since webserver is primarily supported by HTTP, Httpserver and webserver are usually equal (there is no webserver that supports protocols other than HTTP, which the author has not verified), and that is one thing.

　　Application Server (Application server), let's look at what Microsoft defines it: "We define application server as the underlying system software that runs a shared business application as a server." Just as file server provides files for very many users, application server enables multiple users to use the application at the same time (typically customer-created applications) "

In layman's parlance, the webserver transfer (serves) page allows the browser to navigate. However, the application server provides a method (methods) that the client application can invoke (call). The exact point. You can say that webserver specifically handles HTTP requests (request), but Application Server provides (serves) business logic for applications through a very many protocol.

In Java EE, for example, webserver primarily handles static page processing and acts as a servlet container, explaining and running servlet/jsp, while application server is running business logic, primarily the Java EE API, such as EJB, Jndi, and JMX APIs. It also includes transactional processing, database connectivity, and so on, in enterprise applications. Application Server provides more powerful features than webserver.

With this definition, IIS, Apache, Tomcat belong to Webserver,weblogic, and WebSphere belongs to Application server.

Apache: In webserver, Apache is a purely webserver, often paired with Tomcat. It has a strong ability to interpret HTML pages. However, the server-side script code (jsp/servlet) within the embedded page cannot be explained.

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. The Tomcat process runs independently of the Apache process. And, 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 pure webserver.

Later, it embeds the ASP engine. The ability to interpret VBScript and Jscriptserver-side code. At this point, it can be used concurrently as an application server.

Of course. It is not comparable to the Java EE Application Server at all, but, functionally speaking, it can barely be called application server. To be exact, it is a bit of a webserver that applies server functionality.

All in all: Apache is pure webserver. While Tomcat and IIS have the ability to interpret running server-side code, they can be called a lightweight application server or a webserver with server functionality. Weblogic, WebSphere can provide a powerful Java EE function. There is no doubt that the absolute application server. For Tomcat in the middle, it can be used with pure webserverapache and can be deployed as an Application server helper with Application server:

• One,tomcat and application Server

  So far, Tomcat has been known to be the Servlet/jsp API's runner, 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 enough, many application servers now often use Tomcat as a container for their servlet and JSP APIs. Because Tomcat agrees that developers will be able to embed Tomcat into their applications simply by adding a line of acknowledgements. It's a pity. Many commercial application servers do not comply with this rule.

  For developers, the assumption is to look for the use of servlet, JSP, Jndi, and JMX Technologies to build Java Web applications. Choosing Tomcat is an excellent solution, but to find support for other Java EE APIs, look for an application server or use Tomcat as an Application server helper. will be a good solution; The third way is to find a separate Java EE API implementation and then combine them with Tomcat. This is the most effective way to do this, although consolidation brings about problems.

  。

• Ii.Tomcat and webserver

  Tomcat is a container that provides support for Servlets and JSPs to run. Servlets and JSPs can be based on real-time needs. Generate Dynamic Web content. and for webserver. Apache only supports static web pages, it is powerless to support dynamic Web pages, and Tomcat can serve dynamic Web pages. Support for static Web pages is also available at the same time. Although it does not have the usual webserver fast, the function is not as rich as webserver, but Tomcat is gradually expanding to support static content. Most webserver are written in the underlying language, such as C. With the features of the corresponding platform, tomcat written in plain Java cannot run at the same speed as they do.

  In general, large sites are the 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. Finally, Apache returns the response to the client.

  And in order to improve performance. A single Apache can connect multiple tomcat for load balancing.

  More specific differences about webserver and application server can be viewed in this article:

  In layman's parlance, the webserver transfer (serves) page allows 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 webserver specifically handles HTTP requests (request), but Application Server provides (serves) business logic for applications through very many protocols.

  Let us come to the following way:

  　　Webserver (Web Server)

  The webserver is able to parse the (handles) HTTP protocol. When an HTTP request (request) is received by webserver, an HTTP response (response) is returned, such as sending back an HTML page. In order to process a request, webserver can respond to a static page or picture (response), making a page jump (redirect). Or response the generation of dynamic responses (delegate) to other programs such as CGI scripts. 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) to allow the browser to navigate.

  You know. Webserver's proxy model (delegation models) is very easy. When a request is sent to webserver, it simply passes the request to a program that can handle the request very well (translator Note: server-side script). Webserver only provides an environment that can run 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 connectivity (DB connectivity), and messages (messaging).

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

  　　Application Server (the application server)

  According to our definition. As an application server. It through various protocols. can include HTTP. Exposing the business logic to the (expose) client application.

  Webserver primarily handles sending HTML to the browser for browsing, and 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, including the graphical user interface (GUI), may run on a PC, a webserver, or even other application servers. The information that travels back and forth between application server and its client (traveling) is not limited to simple display tags.

  Instead, such information is the program logic. It is because of this logic that the (takes) data and method calls (calls) are made in the form of static HTML, so that the client is able to use such exposed business logic freely.

  In most cases, application server exposes the business logic (expose) (to the client application) through the component (component) application interface (API), such as the Java 2 Platform, Enterprise Edition) Application server's EJB (Enterprise JavaBean) component model. In addition, application server can manage its own resources. For example, look at the work of the Gate (gate-keeping duties) includes security, transaction processing (transaction processing). Resource pools (resource pooling), and messages (messaging). Like webserver, application server is configured with a variety of extensible (scalability) and fault tolerant (fault tolerance) technologies.

Example

Like what. Imagine an online store (site) that provides real-time pricing (real-time pricing) and validity (availability) information.

This site is very 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. Sites can have very many ways to implement such a feature. I want to introduce a scenario that does not use Application server and a scenario that uses application server. Looking at the differences between these two scenarios will help you understand the functionality of the application server.

Scenario 1: Webserver without application server

In such a scenario, a webserver independently provides the functionality of an online store.

Webserver obtains your request and then sends it to the server side (Server-side) to process the request. This program is from a database or text file (flat file, translator Note: Flat files are non-binary documents that have no special format.) such as properties and XML files, etc.) to find pricing information. Once found, the server side (Server-side) program represents the resulting information as a (formulate) HTML form. Finally webserver will send it to your Web browser.

In short, webserver is simply a simple response (response) HTML page to handle HTTP requests (request).

Scenario 2: Webserver with Application server

Scenario 2 and Scenario 1 are the same as webserver or the generation of the response (response) is entrusted (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, the script simply invokes the application server's lookup service (lookup services) instead of knowing how to find the data and then represent it as a (formulate) response (response). When the script generates an HTML response (response), it will be able to use the return result of the service.

In this scenario. Application Server provides (serves) the business logic for querying pricing information for a product. Such a feature (functionality) does not indicate details about how the display and client use this information. Instead, client and application server simply transfer data back and forth. When a client invokes the lookup service for Application server, the service simply finds and returns the result to the client.

It is separated from the code that generates the (response-generating) HTML from the response. The pricing (lookup) logic is more reusable in the application. The other client. Like a cash register. It is also possible to 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.

In summary, in the model of Scenario 2, the HTTP request (request) is processed in webserver by responding to an HTML page, while application server is processing the pricing and validity (availability) request (Request) To provide the application logic.

Warning (caveats)

Today, XML Web Services has confused the boundaries of application server and webserver.

By transmitting an XML payload (payload) to Server,webserver today, the ability to process data and responses (response) is much the same as in the previous application server.

Other than that. Today, most application servers also include webserver. This means that webserver can be thought of as a subset of the application Server (subset).

Although application Server includes the functionality of webserver, developers rarely deploy application server (capacity) into such a feature (the translator notes: Such functionality refers to both the functionality of the application server and the Webserver functionality.

Instead, assume that they typically have webserver independently configured, and the application server is a former one. The separation of such features helps improve performance (simple Web requests (request) will not affect application server), separately configured (dedicated webserver. Cluster (clustering) and so on, and give the best product selection leeway.

WEBserver, Application server, httpserver differences