Datasheet

Apache and Jakarta Tomcat
11
Pick and Choose
However, not all developers want to create the kinds of distributed systems that the entire collection of
J2EE APIs are designed to support. Fortunately, it is possible to pick and choose those APIs that are
necessary for your projects. For example, if all you need to do is write a GUI LDAP client, the JNDI
API is the only J2EE API you'll need to use.
If you want to create a dynamic web site but don't need the additional J2EE APIs, the Servlet and JSP
APIs may be all you'll want. As was mentioned earlier in this chapter, a servlet plugs in to a special
server called a servlet container (and JSP is an alternative way of writing a servlet). The J2EE app server
contains a servlet container, but if all you want to is write servlets/JSP, then you don't need the full app
server – you just need a servlet container.
Tomcat is just such a servlet container. As a servlet container, Tomcat is only required to implement the
Servlet and JSP APIs, and thus is not considered a J2EE app server. However, as J2EE app servers must
themselves contain a servlet container to support the servlet/JSP APIs, J2EE app servers can embed
Tomcat into their code to provide support for the Servlet and JSP APIs. One example of just such an
application server is the popular open source JBoss J2EE app server (http://www.jboss.org/).
For more information on J2EE and its various APIs, visit http://java.sun.com/j2ee/.
Using Tomcat with the Apache Web Server
Tomcat's purpose is to provide standards-compliant support for servlets and JSP pages. The purpose of
servlets and JSP pages is to generate web content such as HTML files or GIF files on demand using
changing data. Web content that is generated on demand is said to be dynamic. On the other hand, web
content that never changes and is served up as-is is called static. Web applications commonly include a
great deal of static content, such as images or Cascading Style Sheets (CSS).
While Tomcat is capable of serving both dynamic and static content, it is not as fast or feature-rich as
the Apache web server with regard to static content. While it would be possible for Tomcat to be
extended to support the same features that Apache does for serving up static content, it would take a
great deal of time; Apache has been under development for many years. Also, because Apache is
written entirely in C and takes advantage of platform-specific features, it is unlikely that Tomcat, a 100%
Java application, could ever perform well as Apache.
Recognizing that the advantages of Apache would complement the advantages of Tomcat, the earliest
versions of Tomcat included a connector that enabled Tomcat and Apache to work together. In this
arrangement, Apache receives all of the HTTP requests made to the web application. Apache then
recognizes which requests are intended for servlets/JSP pages, and passes these requests to Tomcat.
Tomcat fulfils the request and passes the response back to Apache, which then returns the response to
the requestor.
The Apache connector was initially crucial to the Tomcat 3.x series, because its support for both static
content and its implementation of the HTTP protocol were somewhat limited.