What is the difference between Web Server and Application Server?

An application server is simply a server, in the sense of client-server architecture: a process that serves one or more client applications that send requests to it. Put in order to run a process that opens a port to meet TCP or UDP connections, and voilà! , you have an application server.

In our Web world we need several types of servers. One that understands requests made in the HTTP protocol, for example, to communicate with clients scattered over the Internet. Minimally this server may be able to serve static data such as static HTML pages, files and images. It's called "Web Server". Example: the "Apache HTTP Server" or simply Apache.

But that alone is not enough. It is common for us to require that it serve dynamic data such as custom HTML pages, byte strings, files, and even images constructed on the basis of variable information such as the parameters of the request itself or the result of a query to a database an application server too, as @bigown said, specializing in storing data).

One way to resolve this is to deploy a Web server that has dynamic behavior. It is not very practical: depending on the size of the services that he proposes to provide, we will have to dedicate ourselves to implementing a lot of logic, let's say "infrastructure" to build it, such as separating requests into threads to save resources and improve performance, logic (ie, based on for example a text file that someone can modify without having to recompile the server's entire code), filtering behavior of requests (for example, the behavior of always authenticating logging , the very logic of interpreting a dynamic page and generating HTML (that's all I'm blatantly taking from the Head First book Servlets & JSP which explains why you should do it differently by using a Container).

Another way to do this is to delegate the dynamic part to scripts written in Perl, PHP or some other language. It may also hit some of the limitations listed above, including opening a separate process for each request, which is more costly than using threads.

Another way is to use a Container (also called Web Container or Servlet Container ), which is the solution proposed by Java technologies that I know best. It is also a server, which receives requests from an HTTP server (commonly referred to as a Web server), and takes care of all the previously mentioned infrastructure logic, leaving you free to implement only the business logic that matters to your specific application. Container passes requests to Servlets, which are basically Java classes, and each Servlet executes the request on a thread. You can schedule a Servlet to service login requests, another to include items in an order, another to delete orders, and so on.

This is also often called "Application Server" in the sense that I believe you had in mind when you asked your question. It consists of a Web server, and also an extra server, the Container, which is responsible for generating dynamic content. So we can say that in this second application server definition, the application server contains a web server.

(Note that this combined architecture does not have to be a Web server, nor that the protocol is HTTP, but it is the most common in the Web world.)

Application server example: Apache Tomcat (Apache web server + servlet container). Note: Tomcat also has an alternate HTTP server called "Apache Tomcat HTTP Server".

In Java, an application destined to run in a container (usually called a "web application") is a .WAR (short for "Web ARchive") file that is basically composed of the Servlets that the container will execute some more static content (images, configuration files, etc.).

A web server is an application server to meet web needs. For example, contrary to what many people think, Microsoft IIS is an application server , one of its functions is to serve web.

An application server "hosts" processes on a system that allow clients to make requests and receive responses.

It is obvious that the web server needs to work with HTTP protocols and derivatives. It has some predefined functions that just do, or at least make a lot of sense for the normal flow of web solutions. In general, several of the tasks that a web server needs are the same as any other type of server application, including database access activities and / or delegating part of the task to an off-site engine itself (called a executable or script ).

You can have a web server that delegates the specific processing to an application server without specialization (or not) that delegates the manipulation and storage of data to > database server .

So some people can use the term application server only for the host of business logic (runs the application environment in general). Some will then consider that every web server is an application server in this sense, as it performs business logic through scripts . >

Others consider that only static content is what the web server handles and any dynamic content is part of the application server.

People forget that HTTP is an application with specific rules.

It's basically this. I know some technology stacks prefer to use their own definitions, but I find them restrictive. Learning the way technology presents is to follow the cake recipe imposed and some people stick to it. In some cases I see the term application server being used for a set of available services. That's right, that's an app server with some defined functions.

I do not like, for example, OS settings . They stick to specific technologies, consider the term how the market uses and not as the computation as a whole suggests.

You can write an application server with a few lines of code. It depends on the requirements. A web server, for example, is not so simple anymore. There are definite requirements that are not simple at all. But I also do not say it's so hard to write one.

As a complement we can say that a database server is a specific application server to give access to the stored data.

And so on. One is specialization of the other.