Difference between Tomcat and my JSP/Servlet app?

Question

I'm learning about JSP and Servlet and I'm a beginner. I try to understand the difference between server, application server, Tomcat and my Servlet app.

For example I have found this information on a tutorial: "A web browser may be the client, and an application on a computer that hosts a web site may be the server. A client (browser) submits an HTTP request to the server; then the server returns a response to the client."

Who exactly is the server? Tomcat is the server? Or my Servlet/JSP app is the server? I know that my JSP/Servlet app send the response back to the client, then I thnk it is server... And who is Tomcat and what exactly does it do?

Thanks in advance!

Answer 1

In the real world, the server (called also web server) and the application server are two distinct things but work together :

• the (web) server processes incoming network requests over the HTTP protocol. Httpd Apache, IIS and nginx are web servers.
• the application server is a software framework that provides both facilities to create web applications and a server environment to run them.

About Servlet/JSP, these are neither servers nor web applications. These are elementary parts of a web application (WAR file or exploded WAR in a directory).

The web applications (a WAR in Java) are deployed on an application server (Servlet Container in Java). Tomcat and Jetty represent this kind of server. These servers rely generally on a web server for multiple reasons : serve HTTP static resources (images, css, js...), proxy benefits, SSL and so for...

Here is schema of how a request and its response are transmitted through the different nodes (the numbers between parenthesis represent the order in the sequence) :

                  Web browser  |  Web server  |   Tomcat   | web app targeted
http request  :     req (1)   ->    req (2)  ->  req (3)  ->   req (4) 
http response :     res (8)   <-    res (7)  <-  res (6)  <-   res (5) 

Note that in local environments, you may not have a web server configured with the tomcat. So you can consider this node as optional in the schema.

As a side note, in the Java world, you have also the Java EE servers that are really another thing. They have to implement the JEE server standards. JBoss, Glassfish or Weblogic are examples of them.
These are an alternative to Servlet Container but are less and less used as heavier.

Answer 2

A server is a program that serves up responses when called. Tomcat is a server, it listens for http requests, routes them to the responsible application, then when the application has processed a response the server sends it back to the client.

Tomcat is called a servlet container because it provides a place where servlets can run; it provides the infrastructure that the applications need in order to do their work. It listens for requests on a specific socket and handles the I/O required to communicate with the client. Web applications implement specified interfaces so that the servlet container can know to call into them. A web application typically would have a servlet as part of whatever web framework that it uses, where the servlet dispatches requests to controller objects that handle the requests. It should be rare to have to write your own servlet for anything.

JSP is a legacy technology for creating views that has been obsolete for years.

Answer 3

A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology.

Answer 4

Tomcat is basically a servlet container and a web server (since it able to processing HTTP-requests using its internal Coyote HTTP server).

That means it manages your servlets, JSF and JSPs (the latter are also implicitly converting to the servlets). It implements Java Servlet API but also can be used as the HTTP-server to process calls to static WEB-pages.

By deploying your servlets on Tomcat you're putting them at the container, which then will manage all edges of their functionality, including the lifecycle. Both Tomcat and your app can be considered as a 'server' in the context of your question.

Tomcat is also used as the reference servlet container in JBoss and GlassFish application servers.

The real-life scenario which possibly could make it more clear:

You've bought a DVD and want to watch it. The DVD (a servlet) itself can't be used to watch the movie directly (it hasn't a display, speakers or whatever, it is only a data carrier). Thus you need a suitable DVD-player (a container in terms of our context) to play it. You're inserting the DVD in your player (deploying your servlet) and watching the movie (use your web application). In this case you're not worry about how it works, just putting the disk inside the player and let it takes care of the rest.