Escolar Documentos
Profissional Documentos
Cultura Documentos
The Apache Jakarta Project creates and maintains open source solutions on the
Java platform for distribution to the public at no charge. Apache Jakarta Tomcator just Tomcat--is one of those projects
Tomcat is a container for servlets. Tomcat can act as a simple standalone
server for Web applications that use HTML, servlets, and JSP. Apache is an
industrial-strength, highly optimized server that can be extended with Tomcat
If you want to get Tomcat, one reasonable download site is
http://mirrors.xtria.com/apache/jakarta/tomcat-5/v5.0.29/bin/
A web application is basically a web site that:
- Knows who you are-it doesnt just give you static pages, it interacts with
you
- Can permanently change data (such as in a database)
- A web application can consist of multiple pieces
- Static web pages (possibly containing forms)
- Servlets
- JSP
- Tomcat organizes all these parts into a single directory structure for each
web application
To create servlets, you really should have two directory structures:
- Development directory, in which you can write and partially debug your code
- Deployment directory, in which you put live code
Tomcat requires a particular set of directories for your web application
Flow
1. The user submits an HTML form
2. Tomcat finds the servlet based on the URL and the deployment descriptor
(web.xml) and passes the request to the servlet
3. The servlet computes a response
4. Either: The servlet writes an HTML page containing the response
Or: The servlet forwards the response to the JSP
5. The JSP embeds the response in an HTML page
6. Tomcat returns the HTML page to the user
Alternatives to Tomcat
Suns Java Web Server
Old, no longer being developed, all in Java
Java Web Server Development Kit (JWSDK)
Official reference implementation
Difficult to install and configure
JBoss
Open source
Opinions vary on how easy it is to install
Comes with built-in database
Many CGI replacements have been built on top of the Apache Web server
(http://www.apache.org) because of Apache's popular modular API. This
allows developers to extend Apache's functionality with persistent programs
and thus is ideal for creating programs for handling dynamic content. Apache
loads modules into its memory when it starts and passes the appropriate
HTTP requests to them as appropriate. It then passes the HTTP responses
back out to the browser once the modules have processed the requests. As
the modules are already in the server's memory, the cost of loading an
interpreter is removed and scripts can execute faster.
Microsoft provides an interface to its Internet Information Server (IIS) Web
server, called the Internet Server Application Programming Interface (ISAPI).
This hasn't got the following that Apache's API has because of its complexity,
but it's nevertheless a high-performance API. However, the IIS Web server is
used widely, mainly because it comes as part of many versions of Windows.
Later in the book you will configure Tomcat to work with IIS to combine the
best features of both.
Microsoft also developed the Active Server Pages (ASP) technology, which
lets you embed scripts, typically VBScript, into standard HTML pages. This
model has proved extremely successful and was the catalyst for Java Web
technology, which we'll discuss shortly.To the reviewer: is this still the case for
ASP? Not sure what ASP.Net has added.
Introducing Java on the Web
Java applets never really caught on to any degree and other technologies,
such as Macromedia Flash, became more popular ways of creating interactive
Web sites. However, Java isn't just for writing applets: you can also use it to
create stand-alone platform-independent applications. Java applications
haven't really caught on yet either probably because Java's support for
creating GUI applications has until recently been quite poor. This situation is
changing, and in fact today's versions of Java do enable developers to create
cutting-edge GUI applications.
The main contribution of Java to the Web is servlets, which are another
alternative technology to CGI. Just as CGI and its other alternatives are not
stand-alone programs, a web server, in this case it is called a servlet
container, must load servlets into memory. The servlet container then receives
HTTP requests from browsers and passes them to servlets that generate the
response. The servlet container can also integrate with other Web servers to
use their more efficient static file abilities while continuing to produce the
dynamic content. An example of this is found later in the book when you will
integrate Tomcat with Apache.
One major practical difference between servlets and JSP pages is that
servlets are provided in compiled form and JSP pages are often not (although
Servlet Containers
JSP and servlets require a servlet container to operate at all it is the
reference implementation (RI) servlet container, which means that Tomcat's
first priority is to be fully compliant with the Servlet and JSP Specifications
published by Sun. However, this isn't to say that it's not worthy of use in
production systems. Indeed, many commercial installations use Tomcat.
Looking at Tomcat
Tomcat has its origins in the earliest days of the servlet technology. Sun
created the first servlet container, called the Java Web Server, which
demonstrated the technology but it wasn't terribly robust. At the same time,
the Apache Software Foundation (ASF) created JServ, a servlet engine that
integrated with the Apache web server.
In 1999, Sun donated the Java Web Server code to the ASF and the two
projects were merged to create Tomcat. Version 3.x was the first version of
Tomcat and was directly descended from the original code that Sun provided
to the ASF. It is still available and is the RI of the Servlet 2.2 and JSP 1.1
Specifications.
Tomcat 5.0.x is the current Tomcat version and is the RI of the Servlet 2.4
and JSP 2.0 Specifications. As such, this is the version of Tomcat that we will
use in this book.
Tomcat's Architecture
The ASF completely remodeled Tomcat's architecture in Tomcat 4.x and
rebuilt it from the ground up. As a result, a heated discussion about whether
this was actually necessary began. Those who disagreed took the 3.3 code
base and branched it from the main development tree to continue refactoring
the old code base. Tomcat 3.3 supports Servlet 2.2 and JSP 1.1. This left
Tomcat 4.x to become the main focus of the project. However, Tomcat 4.0.x is
now only receiving security fixes and Tomcat 4.1.x is only receiving new
enhancements periodically. Tomcat 4.x supports the Servlet 2.3 and JSP 1.2
Specifications.
The latest version of Tomcat is 5.0.x, which supports the Servlet 2.4 and
JSP 2.0 specifications. It consists of a nested hierarchy of components:
a. Top-level components exist at the top of the configuration
hierarchy in a rigid relationship with one another
b. Connectors connect the servlet container to the Web browser
making requests
c. Container components contain a collection of other components
d. Nested components can reside in containers, but cannot contain
other components
When configuring Tomcat, some of these objects may be removed without
affecting the server. Notably, the engine and host may be unnecessary if you
are using a web server such as Apache.
This allows you to configure a convenient destination for all logging events
for those components that are not configured to generate their own logs.
The Manager Component
The manager component represents a session manager for working with
user sessions in a web application. As such, it can only be included in a
context container. A default manager component is used if you do not specify
an alternative and, like the loader component above, you will find that the
default is perfectly good.
The Realm Component
The realm for an engine manages user authentication and authorization.
As part of the configuration of an application you set the roles that are allowed
for each resource or group of resources and the realm is used to enforce this
policy.
Realms can authenticate against text files, database tables, LDAP servers,
and the Windows network identity of the user.
A realm applies across the entire container component in which it is
included and so applications within a container share authentication
resources. By default, a user must still authenticate separately to each web
application on the server (this is called single sign-on). We will see how this
can be changed later in the book.
The Resources Component
The resources component can be added to a context component. It
represents the static resources in a web application and allows them to be
stored in alternative formats such as compressed files. The default is more
than sufficient for most needs.
The Valve Component
You can use valve components to intercept a request and process it before
it reaches its destination. Valves are analogous to filters as defined in the
Servlet Specification, without the response post-processing abilities. They
aren't in the JSP or Servlet Specifications. You may place valve components
in any container component.
Valves are commonly used to log requests, client IP addresses, and server
usage. This technique is known as request dumping and a request dumper
valve records the HTTP header information and any cookies sent with the
request. Response dumping logs the response headers and cookies (if set) to
a file.
There are other useful facilities, such as listeners, that you can use when
configuring Tomcat. However, they are not defined as components. We will
deal with them later in the chapter.