Jess Holle wrote:
Robin Wilson wrote:
For the record, my answer was neither stupid or reflexive. I simply pointed out
why someone might want 2 layers of servers (httpd and tomcat). And certainly,
my rationale is both sound and arguable at the same time.
As for your assertion that 2 layers of security is just complexity and not more
secure - you obviously haven't run many enterprise production systems. Security
in an enterprise system is all about 'layers' of protection. And sure, if they
hack one layer - they are probably good enough to hack the next layer. But
that's where intrusion detection and a variety of other system come into play.
It's all about slowing down the advance of the attack until you can do
something about it.
As for performance, have you run any load testing against tomcat vs. apache -
especially on static files? Apache exceeds tomcat in performance by a large
margin. When you are serving millions of pages a day, and tens of millions of
static files (images, css, js, videos, audios, etc.), that makes a significant
difference in the amount of hardware you have to throw at the problem.
So you may be absolutely correct - it is not 'necessary' in a lot of cases. But
in many production - enterprise - deployments, it can be useful to have a layer
of web servers and a separately managed layer of application servers - and that
same model works just fine with Apache and Tomcat.
I think the Tomcat folk would dispute your assertion on performance --
in particular when Tomcat is used with native APR.
That said, the biggest reason I know of for Apache fronting Tomcat is
load balancing across Tomcats.
If you have a hardware load balancer doing that, then there are lesser
reasons, e.g.:
* there are more security plug-ins for Apache (e.g. SiteMinder and
the like),
* multi-LDAP authentication support is built into Apache,
It is my understanding that the next Tomcat release will provide
multi-LDAP authentication support, by the way.
* various existing Apache modules (e.g. mod_redirect) allow some
classes of problems to be solved by configuration that would
require coding in Tomcat.
On this last note, however, I'd say that writing necessary
filter/listener/handler code for Tomcat can generally be done in a
manner that is portable to any up-to-date servlet engine, is /far/
easier than writing code for Apache modules, and is sometimes even
easier than achieving the same end by configuring modules in Apache
(where that is approach is sufficient).