Articles Index
Backstage at the JDC: Session Management
By Tony Squier and Mary Aline
(November 1997)
There have been many requests to look behind the scenes of the
JavaSM Developer
ConnectionSM (JDC) and learn how
the JDC uses Java technology and the JavaTM
Web ServerTM to run the web site.
Many engineering subsytems make up the whole of the JDC system. Access
management, registration, page generation, database access, and session
management are just a few of them. Each of these is an interesting
exercise in web engineering, and merits an article in its own right.
The first piece of web engineering, underlying the rest of the engineering
backstage, is session management. This is the front door, or in keeping with
the backstage analogy, the JDC "box office." This article describes how JDC
session management works behind the scenes, and how it also enables other
JDC applets or tools such as the fishFinder. This article is accompanied by
session-management sample code.
One of the keys to the JDC session-management process, and where members take
part, is the login procedure. Each time you visit the JDC web site, you're
asked to log in before you browse the JDC web pages. A login is required, not
only for managing each member's session, but also to enable such features as
Chat, Bug Voting, the Duke Dollars newsgroups, and so on.
To understand how member sessions are implemented and managed, you need to
know a little about the Java Web Server (JWS) and servlets, because they play
a key role in session management. The JDC uses the JWS to enable many features
on the web site. The JWS provides an API for invoking server-based programs
known as servlets. Servlets are to servers what applets are to browsers. If
you want to know more about servlets and their function, see the JWS technology
articles under
Java In-Depth.
For the JDC, a new rule was added to the rules.properties file in the
/developer
directory. The developer directory contains all the
site content, which requires logging in before you view it. This part of
the web server's document tree is handled by the SessionServlet. If you
want more information about the Java Web Server, see the
JavaServerTM product group
web
page.
Note: If you are interested in how the hardware is
configured, see "System Hardware".
A Typical Session
The following event diagram shows the life cycle and typical sequence of
events when a JDC member accesses the JDC web site.
With this diagram you can begin to make sense of the code and see what is
happening backstage.
The SessionServlet
The SessionServlet has two main responsibilities: to authenticate users and
to restrict access. The session-management system comprises three important
classes: SessionServlet, SessionCache, and Session; and one interface:
Authenticator.
-
SessionServlet--grants access and tracks sessions for
a protected area.
-
SessionCache--tracks active sessions.
-
Session--keeps information about a client's activity on
the site.
-
Authenticator--an interface that authenticates a user
based on a unique id and password.
Using Booch notation, the above class diagram shows the relationships
between the four major classes. For those not familiar with Booch notation,
here's a brief overview. The clouds represent classes, the lines represent
relationships between the classes, solid circles represent "has a"
relationship, and open circles represent "uses a" relationship.
The inverted triangle denotes an abstract class, or in Java programming it
can also be an interface. The n between the SessionCache and Session
relationship denotes cardinality, which in this case is unlimited. This
allows the JDC site to scale to however many users are on the site. If you
want to know more about Booch notation, see Object Solutions
by Grady Booch, published by Addison-Wesley Publishing Company, Inc.
So what goes on in the SessionServlet? The SessionServlet's main
responsibilities include serving files and checking access. To use
the SessionServlet a set of configuration parameters are required:
- auth
- loginFirst
- loginInvalid
- home
- domain
- flush
- cookieTimeout
Each of these is explained in the next four paragraphs.
When configured, the SessionServlet expects a fully qualified class name
for an Authenticator, such as jdc.registry.MyAuthenticator
, and
must implement the isAuthorized
method. The JDC uses an Oracle
database to hold all member information. The convenient thing about passing
the class name to the SessionServlet is that different Authenticator
instances can be used without having to recompile the code. During the
initial development of the JDC web site, because the database wasn't always
available, this feature was used a lot. The SessionServlet's
init
method shows how
the instance is created.
The next three parameters specify what files to show and where to redirect
a user during login. The parameters loginFirst and loginInvalid are the
pages shown when a user logs into the site:
-
loginFirst--the first page you see when accessing the JDC.
Currently, it's the Home Page with the login box at the top.
-
loginInvalid--the page shown to the user if they provide
invalid login information.
Each of these pages are shown depending on the type of request made by
your browser. If no session is valid, meaning that the browser didn't
send a cookie or the session id in the cookie doesn't exist, the user
is shown loginFirst. The parameter home is used to tell the
SessionServlet what page to show following a valid login, that is:
/developer/index.html
The last three parameters control which domain the cookie is valid for,
how long a session lasts, and when to flush the cookie cache. The JDC
uses the following values:
-
domain--the domain for which the cookie is sent to the
web server. For the JDC it's .javasoft.com
-
flush--how often to flush the cookie cache. Typically this
is set to be about half the value of the cookieTimeout.
-
cookieTimeout--the life of a session, in milliseconds. A
typical JDC session is set to about an hour (Note: a new feature
(not discussed in this article), has been added that uses the
cookieTimeout value as an inactivity timer. With this feature,
a session doesn't expire unless the user is inactive for the
time specified in cookieTimeout).
The JDC doesn't use browser timeouts because of problems with
timezone, and so on, so the SessionCache expires cookies.
Examining the Code
Now that you've seen the basic life cycle of a typical JDC member's
session while visiting the JDC web site, take a look at the
sample code for more detail.
Once you are logged into the JDC, a unique session id is created and
stored in the user's browser via a nonpersistent cookie. You may be
thinking, "Why cookies? They are bad because, amongst
other things, they allow access to my machine's hard disk."
This might be a good opportunity to dispel some of the myths about
cookies, and why, if used properly, they can be a good thing.
Cookies are just information that is stored in your browser. That
information is sent back to a web site when a page request is made.
Simply put, cookies cannot interact with a user's hard disk. The JDC
uses the value stored in the cookie to help with navigation through
the web site. Cookies allow a straightforward way of authenticating
users only once. Session-tracking information is used only to gather
information so that it can provide members with the information they
are seeking. Now, on to the really interesting stuff--how does the
code work?
Each time the servlet is invoked, its service method is run. This is
handled by the Java Web Server. (These details are explained in the
Servlet API distributed with the product.) When a user first visits
the web site, the SessionServlet checks via the service
method
to see if they have a valid session; see the
service
method in
the SessionServlet code.
If the value returned from the
_validateSession
isn't
null, then it is considered valid. There are only two conditions when a
null value is returned from the
_validateSession
method:
either no session was found for the session id passed in the cookie, or no
cookie was sent. For now, assume the value returned is valid. To see what
happens next, take a look at the
_performAction
method in
the SessionServlet code.
Basically the _performAction
method begins exploring what to do next. If this is a user's first visit to
the web site, that is, they have an invalid or no session,
the JDC redirects the browser to the SessionServlet. As part of the redirect,
the session servlet sets the action parameter of the http query string (query
string is ? at the end of the url).
Some examples of the action parameter can be: showLogin, showInvalid,
login, or logout. If a user is submitting their login information, which
is done via a form and setting the query parameter to action=login
,
the JDC authorizes, creates a new session, and sends them on their way.
But, if the user has a valid session, the JDC invokes the serveRequest
method.
The interesting thing about serving pages with the SessionServlet is
that it doesn't actually serve the requested file, because when the
SessionServlet starts, it gets a reference to the Java Web Server
FileServlet and Server Side Includes (SSIncludes) servlets. The servlet's
init
method gets the
reference to both servlets.
So, serving a file is really just a matter of passing the request, with
a little change, along to either of these two servlets--if it's .shtml,
it is sent to the SSIncludeServlet, otherwise the FileServlet deals with
the request. The advantage of using these two servlets is that they perform
page caching and inline servlet including. Also, this is the object-oriented
way of writing programs.
Enabling Other Applets
H
Because JDC session information resides within the SessionServlet
in a hashtable, getting accurate information is not very difficult.
See the _performAction
method in the SessionServlet code.
So as not to slow down normal web site access, the thread is made
a low priority, and periodically yields control to other threads. That's
all there is to it.
Downloading the Sample Code
As with much of the JDC sample code, you can download the entire
SessionServlet classes and use them for your
web site--but be sure to purchase the Java Web Server, or some other
servlet-compatible product first.
Note: The Session Management servlet code runs with
JWS 1.0.x. If you are using JWS 1.1 Beta it may not work. You can download
a copy of JWS 1.0.3 at
http://java.sun.com/products/java-server/webserver/index.html
System Hardware
To give you a broader picture it might help to know how the JDC system is
configured to run the web site. The JDC web site runs on a single Ultra1
SparcserverTM with one CPU, six gigabytes
of disk space, and 128 megabytes of RAM. The Oracle database, Java Web
Server, and the other server processes that handle chat, discussion groups,
and so on, run on this machine.
The web site handles an average of about five to eight HTTP operations
per second (peaking at 25-30), and between 300,000 and 500,000 hits per
day. Currently the JDC has over 150,000 registrations, and averages well
over 3,000 logins per day. To the best of everyone's memory on the JDC
engineering team, the machine has only been rebooted at most, five times
since it was set up in April this year, and at least one of those occasions
was to add more disk space. Yes, this is all running on that single Ultra
1 Sparcserver. Achieving that level of stability on another operating
system and hardware platform would be a challenge! (Note: The Ultra 1 has
been replaced by an Ultra 2 just as this story was posted.)
Tony Squier is a JDC tools engineer. He developed the JDC
session-management code. He invites any feedback you have about
the article or the code, such as enhancements or potential bugs.
If you have comments please send them to:
Tony Squier