Welcome to JavaRanch! "Apache" is the name of a foundation that write open-source software. Apache HTTPD is a web server written in portable C (when people say "Apache", they usually mean Apache HTTPD.) It mostly serves static content by itself, but there are many add-on modules (some of which come with Apache itself) that let it modify the content and also serve dynamic content written in Perl, PHP, Python, Ruby, or other languages.
Tomcat is primarily a servlet/JSP container. It's written in Java. It can serve static content, too, but its main purpose is to host servlets and JSPs. Although it's possible to get Tomcat to run Perl scripts and the like, you wouldn't use Tomcat unless most of your content was Java.
It's actually possible to use both Apache and Tomcat together, so that Apache serves the static content, and Tomcat the Servlets and JSPs. Depending on various factors, this may or may not be a good idea.
An "application server" is a fuzzy concept. Really, it just means software that hosts pluggable application code. You could call Apache and Tomcat application servers and not really be wrong. But usually when you say "application server" you mean more than that. For example, a Java application server usually hosts EJBs as well as servlets and JSPs, and it usually has fancy tools for deploying and configuring applications that go way beyond what Apache or Tomcat have.
You can't run servlets/JSPs with Apache HTTPD, no. Probably someone, somewhere, has written a module that lets you do this, but I'm not aware of one, and even if it exists, it's not widely used. That's what Tomcat is for -- or another servlet container.
A "Web server" is anything that serves files via the HTTP protocol. You can write a very simple one in Java in a dozen lines of code (a server that serves a single fixed file, for example.) It's very easy to write one, so there are many thousands in existence.
What are other commonly used ones? There are many. After Apache, I think the next most "popular" is IIS, Microsoft's Internet Information Server, just because it's the default on that platform. Then there are hundreds more.
The folks at Netcraft keep track of this stuff. You can see that after Apache and IIS, everything else is pretty much in the noise.
Originally posted by Ernest Friedman-Hill: You can't run servlets/JSPs with Apache HTTPD, no. Probably someone, somewhere, has written a module that lets you do this, but I'm not aware of one, and even if it exists, it's not widely used. That's what Tomcat is for -- or another servlet container.
The predecessor to Tomcat was called "JServ" and was a module for Apache HTTPD. The project is, for the most part, dead. You can integrate Tomcat with HTTPD if you really need to.
A lot of us are just using Tomcat as a standalone server.
The predecessor to Tomcat was called "JServ" and was a module for Apache HTTPD.
Shudder I must have blocked that out. Used to use it myself. Not entirely sure which was more frustrating, Apache JServ or... shudder... JWS 1.0 . It's a wonder anyone ever started using servlets at all...
A lot of us are just using Tomcat as a standalone server.
Including me -- I made the switch from JK2 to standalone Tomcat last week! So far, system load has stayed lower than the old average, and response times are down too.
If your primary business was running Perl CGIs, or PHP, or Ruby on Rails, or basically anything other than Servlets/JSPs, then using Apache is definitely preferable. Tomcat can do these things (or some of them, with a little work) but with Apache it'll be easier to set up and much more efficient.
Apache can do all sorts of fabulous stuff with URL rewriting, and proxying, and other industrial-strength stuff that Tomcat has, so if you're an ISP hosting lots of sites on one box, Apache is definitely going to make your life easier.
When does it make sense to use them both? Well, if you need to run Servlets, but need some of these other things, too. But my primary web site is fairly modest, with moderate traffic, and all JSP/Servlet/static HTML, and Tomcat works great for it.
If you have a real lot of static content. Apache HTTP (which I'll refer to as Apache) can serve it up quicker than Tomcat. Also, Tomcat has a CGI servlet but you're better off using Apache if you have to integrate with anything but a trivial amount of Perl or PHP. I've also seen articles that show how to use Apache as a load balancer for several Tomcat instances. Tomcat, on it's own can't bind to ports below 1024 on Unix systems unless it's run as root. Apache binds to ports 80 and 443 as root and then downgrades itself to a user with lesser privileges. A lot of people have integrated the two just so they could run on port 80 without Tomcat running as root. There are other options now (such as http://jakarta.apache.org/commons/daemon).
A couple things to keep in mind: Several years ago the performance difference between Apache and Tomcat significantly greater than it was now. Both Tomcat and the Java JVM have come a long way and the gap has narrowed quite a bit. However there are still a lot of links out there to articles that (rightly at the time) stated that Tomcat alone wasn't sufficient for a real production app. Consider the date of the article if you run across one of these.
When looking at your costs, don't marginalize maintenance. Apache is written in C. Tomcat is written in Java. The connectors are written with a combination of the two. The people writing the connectors generally have to play catch up whenever either Tomcat or Apache roll out new releases. Keeping all three up to date can involve a lot of work and headaches. Figure that cost in up front and decide if the performance increase (if there is one at all for your app) that you get by connecting the two is worth the extra effort.
Consider your application. If the majority of pages are dynamically built Servlets or JSP pages then the overhead involved with passing the requests to and from Apache could actually cost you more in performance that you'll gain by having Apache serve up your static resources or by having Apache handle all of your SSL encryption. On the other hand if you only have a handful of dynamic pages and lots of static ones, having Apache do the lion share of the work may be more efficient.
I would start out developing with Tomcat as a standalone. When you get to the point in your project where you can load test and profile the app to find it's bottlenecks, THEN look at all of your options for improving performance (if it's even necessary). Fronting the app with Apache is one, better hardware is another, clustering, more DB licenses, etc.... Don't just assume that your app will run faster with Tocmat running behind Apache. Also, don't assume the benefits (if any) will outweigh the maintenance costs.
author and iconoclast
Tomcat, on it's own can't bind to ports below 1024 on Unix systems unless it's run as root. Apache binds to ports 80 and 443 as root and then downgrades itself to a user with lesser privileges. A lot of people have integrated the two just so they could run on port 80 without Tomcat running as root. There are other options now (such as http://jakarta.apache.org/commons/daemon).
One really clever option -- which I'm using, but didn't invent -- is to run Tomcat on a non-privileged port as an ordinary user, but use iptables to forward port 80 traffic to that non-privileged port inside the kernel. It's easy to set up and works like a champ!
[ EFH: Fixed formatting. ] [ July 12, 2005: Message edited by: Ernest Friedman-Hill ]