JDC and Session Management

Print-friendly Version

Articles Index

There have been many requests to look behind the scenes of the Java Developer Connection (JDC) and learn how the JDC uses Java technology and the Java Web Server 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 JavaServer 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/

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 Sparcserver 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