Confusion over web server and serverlet container

[Reema Patel]

Hello All,
I'm a bit confused about the basic difference between a web server and a servlet container.

A Servlet Container is a sub-set of a Web Server. A Servlet Container is a separate module; it may run within the web server as a single program (called Standalone, in this case), may run as a different program, but part of the same address space (In-Process), or run in different process-spaces.

If this is correct, then:
Apache + Tomcat = Apache Web Server and Tomcat servlet container
correct?

Any help shall be highly appreciated.

Thanks,
Reema

[William Brogden]

Apache + Tomcat = Apache Web Server and Tomcat servlet container

I think you are confused by the frequent use of the phrase "Apache Tomcat" to mean the Tomcat web server/servlet container that was created as an Apache Software Foundation project. This unfortunate usage got started years ago and keeps haunting us.

You do NOT have to install the Apache web server unless you need some of the highly specialized functions it supports. Tomcat by itself is a perfectly good general web server used by lots of commercial web sites.

Bill

[Reema Patel]

Hi William,
Thanks for the post.

What you said is very apt. Apache is a full blown web server. Tomcat is just a servlet container. But, Tomcat also has the capabilities of a web server. Does this mean that Tomcat runs the HTTPD service? Just wondering, why isn't called HTTP service instead of HTTPD?

Thanks,
Reema

[clive jordan]

Hi Reema,

I think the best way to look at this is to consider a Web Server's 'main' role in life is to serve up static content. So Apache is great at doing this very efficiently, it can serve up static html pages all day over either HTTP or HTTPS, depending how it is configured.

If apache wants to serve up a dynamically created page, it can hand-off to another mechanism (eg mod-perl, CGI, servlet enigine etc) which will generate the active content and apache can then present the final result (as it belives the generated page was a static one).

Tomcat, on the other hand is a web-container. It's main roles in life are to host servlets and JSP pages, namely it can generate dynamic pages within the web-container, without having to fork new processes as we used to do in the bad-old days. However, tomcat has a few more functions in its armoury: It can serve static pages (just like apache) over either HTTP or HTTPS (config) as well has having an internal JNDI server should you wish to use it.

So, tomcat can serve dynamic or static pages over HTTP or HTTPS.
Apache serves static pages over HTTP or HTTPS.

Therefore, you can most things you need in Java with Tomcat alone.

However, using tomcat to serve lots of static pages is really not what it was intended for, once you scale things up, it will probably run out of steam.

For an Enterprise Web-Server, you would typically use Apache to service static pages and get it to hand-off dynatic request to Tomcat servlets to process.

It really depends on the scale of the application you are aiming at.

Cheers,
Clive

[Bear Bibeault]

Originally posted by clive jordan:
Hi Reema,
However, using tomcat to serve lots of static pages is really not what it was intended for, once you scale things up, it will probably run out of steam.

This suppostion is not born out by any evidence that I have seen. Please cite the studies upon which you make this assertion.

[Reema Patel]

Thnaks Clive, for such a simple and helpful explanation.

Highly appreciated.

[Philip Shanks]

Originally posted by Reema Patel:
Hi William,
Thanks for the post.

What you said is very apt. Apache is a full blown web server. Tomcat is just a servlet container. But, Tomcat also has the capabilities of a web server. Does this mean that Tomcat runs the HTTPD service? Just wondering, why isn't called HTTP service instead of HTTPD?

Thanks,
Reema

Hi Reema,

The "D" stands for daemon, and it seems a bit redundant when combined with the word service, which evokes the Windows terminology for daemon.

I used to think about web servers as being programs that just serve static content (and launch CGI processes). But nowadays I find it more useful to think of a web server as a specialized program who's main purpose is to converse with clients using the HTTP protocol (and/or HTTPS as the case may be).

Tomcat's main function is to provide a container in which the servlet and JSP API's are implemented. That it has the ability to also communicate with clients via HTTP is secondary. It could just as well be using the AJP protocol to communicate through a web server intermediary, letting the web server handle all of the HTTP connections and SSL negotiations.

I have not seen any indication that the Tomcat HTTP engine has poorer performance than dedicated web servers like Apache, Sun JES or IIS, but there are other reasons besides performance for putting a web server in between the client and the servlet container.

It may be that an existing web site has dynamic content based on CGI or some other technology, and "bolt-on" Java capability is desired. Or one could have some sort of clustering architecture that recommends using a web server front-end. Or the enterprise security policy may forbid HTTP requests to come in past the DMZ, and we want to keep the application on an internal network close to the data and directory services, etc. This is where the aforementioned AJP protocol might come into play. There are many situations where you might not choose to use the Tomcat HTTP implementation.

So it's good to understand the difference between web server and servlet container, but stay away from the broader generalization that you always (or never) need to use both together.
[ February 14, 2007: Message edited by: Philip Shanks ]