Apache and Tomcat questions

[Karim Kiswarday]

Hello,
I'm studing the Java Enterprise and I have two questions about the servers.

1)
Why the Apache server (the HTTP Server) can manage php/perl/CGI by plug-in instead we need to use Tomcat for Servlet/JSp?
Why there isn't a plugin for that in Apache?

2)
I know Apache has an engine for the static contents, but in some projects Apache manages static pages and Tomcat manages the Servlet/JSP.
Why they aren't merged? (e.g. Tomcat with the Apache engine to manage the static pages)

Thanks
KK

[Tim Holloway]

Karim Kiswarday wrote:Hello,
I'm studing the Java Enterprise and I have two questions about the servers.

1)
Why the Apache server (the HTTP Server) can manage php/perl/CGI by plug-in instead we need to use Tomcat for Servlet/JSp?
Why there isn't a plugin for that in Apache?

2)
I know Apache has an engine for the static contents, but in some projects Apache manages static pages and Tomcat manages the Servlet/JSP.
Why they aren't merged? (e.g. Tomcat with the Apache engine to manage the static pages)

Thanks
KK

1. J2EE is a heavyweight framework. Although back in the early days, I see to recall some plugin capabilities for Apache-like webservers to run servlets (JSPs hadn't been invented yet), the complexity of modern-day J2EE servers means that it's no longer feasible. One of the things that distinguishes J2EE from CGI is that in CGI, you either have a lightweight scripting language or directly-executable binaries. Java requires firing up a JVM .

Apache is all about fast page service, with fairly light processing requirements. J2EE is more for heavy processing requirements.

2. In the early days, Apache often served up the static content because it could do so much faster than J2EE servers like Tomcat. That hasn't been true for a long, long time. Now Tomcat can serve up static content rapidly, so there's no longer any real need to have Apache do it.

There are still plenty of reason why Apache+Tomcat is common. One of which has to do with Apache's ability to serve up low-numbered tcp/ip ports (80 and 443) without running them under weakened security (root user). Another is to allow one server to be the "go to" point for both J2EE and non-J2EE (cgi/PHP, etc.) applications. There are other possible reasons as well.