We created computers and communication technologies to simplify life, didn't we? Although it may not seem so -- after all, these technologies do bring along their own complexities -- they really do make life easier when you consider what they allow you to do.
You can, for example, walk from your breakfast table to the computer in your living room and check out the current weather radar or road conditions, order a new houseplant, balance your checkbook, pay some bills, or do any number of things with a level of effort unimaginable only a few decades ago. This is indeed progress, but it didn't come about without a few bumps in the road.
In the good old days, the World Wide Web was mostly an electronic superhighway where pioneering companies with fancy billboards would present their products in the best-looking way possible at the time. People would blaze those trails and read the billboards, then call the companies for further information about their products and conduct business in the traditional ways: over the phone or in person.
It didn't take long for computer programmers to create a more interactive way for the business of buying and selling to take place on the billboard -- uh, Web site -- itself. Thus were contact us forms, crude shopping carts, and other rudimentary Web applications born.
Before, a Web site only needed to respond to requests for Web pages coded in Hypertext Markup Language (HTML). Now, Web sites must remember information about the visitor -- information necessary for conducting business with that person.
Suddenly, people had to register with a Web site and provide information about who they are, what they want to buy, and how they want to buy it, and Web sites must maintain that information. The Web server can no longer simply answer the caller -- shoot him or her a page and then forget about it. In computer parlance, these tasks are known as issues of state, and they complicate the once-simple paradigm of the request-response behavior that the Web enjoyed in its infancy.
Now, in an age when every company serious about commerce and the survival of its business model in the twenty-first century has a Web site, issues of state are critical. If user 12,317 cannot purchase item 8,945 online from company 1,437, that user will employ a search engine to discover that company 4,783 can sell that item to the user before he or she walks from the living room computer to the kitchen for a snack -- in other words, it's all about convenience.
But making things simple for the user of a product means that someone else must pay the ethereal price for the truism that there is no free lunch. Web servers and Web applications are complex systems involving many individual components that carry their own complexities with them: database engines, security mechanisms, credit card validation engines, and so on.
Easing the burden of IT personnel
The free market, as usual, comes to the rescue. Today's Internet engineers can choose from a plethora of tools and vendor products that allow the wheels of commerce to remain properly greased and humming along. For an industrial-grade solution to issues of state, consider the Java™ 2 Platform, Enterprise Edition (J2EE™) engine, as represented by Apache Geronimo.
In a typical large business installation, individual applications are called upon to respond to an endless series of requests from thousands of anonymous browsers every hour. Of those, a few hundred or so will carry with them information that is familiar to the server software -- those client browsers that entice the company's Web site server with cookies.
The cookies were originally planted on the anonymous user's Web browser so as to identify that user when he or she returned -- it's good business to recognize your regular customers! It's here that one set of client states are stored. The cookie may consist of nothing more than a simple key value that unlocks reams of information about this user stored in the company's databases.
Half the issues of state are solved when a known user returns and the cookie that the user's browser provides is recognized. Instantly, the server software can customize the page with all sorts of helpful information, such as a personalized greeting or a preferred favorite page. A list of products similar to those that the user had purchased in the past could appear coupled with enticing discounts that basically tell the user that he or she is a valued customer and the company is so very glad that the user has come back -- hopefully to purchase more widgets.
The Internet engineer's term for such Web site conversations as occur between a recognized client browser and the server is a session. The state of a session -- the information stored about the customer and his or her buying habits -- is saved outside the realm of the server's Hypertext Transfer Protocol (HTTP), because it is, by definition, a stateless protocol.
The Java servlet technology in Geronimo provides an application programming
interface (API) for creating and managing sessions automatically. The heart of
this functionality resides in the HttpSession object,
and you can access a session with a call to the request object's
getSession() method. This method returns the current
session associated with this request; if there isn't one, the method creates one
automatically and returns the newly created session handle. For more information,
see the Geronimo session examples sidebar.
If cookies are used as the session-tracking mechanism (there are other methods),
the getSession() method in the servlet code can
modify the response header information -- especially by automatically creating
a new session if the request had none already associated with it. Functionality
such as this is amazing. Sessions and all that they entail in being created and
recalled from persistent storage is truly a lifesaving mechanism for
already overworked programmers.
To simplify and automate the carrying of other information that represents the state of this user, you can associate attribute values with a session in a name=value way. The snippet of code in Listing 1 demonstrates this.
Listing 1. The ShoppingCartServlet
public class ShoppingCartServlet extends HttpServlet {
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// Get session and current shopping cart information.
HttpSession theSession = request.getSession();
TheShoppingCart theCart = (TheShoppingCart) session.getAttribute(thecart);
.
.
.
// Calculate the total price of all items in the cart.
double totalPrice = theCart.getTotal();
|
A great deal of processing goes on behind all this in the Geronimo core to maintain those issues of state described earlier, and the Java servlet mechanism hides the details. The information is saved between requests, so you always know the history that a given user has with your company.
An application that implements the HttpSession method of
maintaining client browser state also has significant bonus functionality associated
with its use. Among these other functions is the ability to automatically notify
other objects of the session relationship. Objects can be notified, for example,
that they have been added or removed from a session if they implement the javax.http.HttpSessionBindingListener interface.
If the session with which the object is associated is passivated or activated,
such as when moving between virtual machines (VMs) or persistent storage, the
object can be notified of this change when it implements the javax.http.HttpSessionActivationListener interface.
Notification of events like these allows objects to do things at certain times that are intimately related to the event occurring, such as logging the fact that the session has occurred, which results in more of the user's shopping habits being recorded. All sorts of advanced data-mining rules can be triggered in this way.
Session management on the server involves many tasks that may not be intuitively
obvious. Every session consumes server resources (specifically memory) that must
be reclaimed if the session times out. For example, the timeout value for a
session depends on many factors outside the scope of this article, but you can set
the value with the application's deployment tool. Alternatively, the session
object itself can get or set the timeout value with calls to the
getMaxInactiveInterval() or
setMaxInactiveInterval() method.
Every session has a time-to-live counter associated with it, and it's a good idea to periodically use service methods to access the session, because doing so resets the counter and prevents the session from timing out. (Instantiating and terminating sessions is costly enough in CPU and memory resources that it's a good thing to keep them alive for reasonably long periods of time.)
This is one reason why you should present some sort of Sign out or Log off
button to users and prominently encourage them to use it. When users click the
button and have essentially told the server that the session is over, the session's
invalidate() method can then be called to clean up the
session data on the server and reclaim the aforementioned resources. The code in
Listing 2 illustrates this process.
Listing 2. The FinishServlet
public class FinishServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// Get session and shopping cart information and end the session.
HttpSession theSession = request.getSession();
theSession.invalidate();
|
As mentioned earlier, several methods are available for associating session information with a particular user -- all of which require the passing of some sort of identifier between the client and server computers. One method already mentioned is the cookie approach. Another method is to include the identifier in every subsequent URL sent back to the client's browser. This identifier, most often a database key, can be generated and sent to the client as one of the URL parameters. Most certainly, when you see a URL like the following, you're being tracked: http://www.somedomain.com/applications/thecart?jsessionid=868D6879824E0F3FB499D8146A9EE7F
The hexadecimal number named jsessionid is the key to the Geronimo session handler and provides the system with information about you that at some time in the past you provided. It's a session number, ready to resurrect data about you, held in persistent storage from previous visits to the Web site. Using this method of maintaining state has several advantages, the most notable of which is that it doesn't depend on users having their browser's cookie mechanism turned on (as a lot of people these days do).
The Web application must rewrite every URL sent in a Web page to the user, or else
the session information can be lost. To do this the J2EE way -- and therefore the
Geronimo way -- a call to the response object's encodeURL()
method is made on all URLs that a servlet returns. By doing this, the session ID
is included in the generated URL only if the user's browser has cookie handling
turned off. Otherwise, the browser returns the URL unchanged, for example:
out.println("<a href=\"" +
response.encodeURL(request.getContextPath() +
"/thecart") + "\">Continue Shopping?</a>");
If the user has turned off cookies in the browser, you see something similar to this: http://www.somedomain.com/applications/thecart?jsessionid=868D6879824E0F3FB499D8146A9EE7F.
But if the cookie mechanism is on, you see something similar to this: http://www.somedomain.com/applications/thecart.
The many issues of state that modern Web server applications must maintain are greatly simplified by using state-of-the-art tools, such as Geronimo and the J2EE technology that it implements. If you're the manager of a company who values your sleeping time, rest assured that the Geronimo architecture can help keep your customers happy by providing them with a pleasant experience when they return, and the architecture can keep your programmers happy by providing them with a reliable environment that makes the maintenance of user states easy.
Learn
-
Visit the J2EE site to learn more about the
standard from the company that created it.
-
Read "Dependency injection in Apache Geronimo, Part 1" (developerWorks, February 2006) to learn
more about the important principle of dependency injection in the Geronimo design.
-
Read "Dependency injection in Apache Geronimo, Part 2" (developerWorks, February 2006) to learn
more about using the dependency injection features in Geronimo.
- Check out "J2EE
1.4 eases Web service development" to learn how the J2EE standard makes it
easier to create Web services.
- Visit the Apache Geronimo wiki to learn more about Geronimo and contribute to the public pool of knowledge about
this important technology.
-
Stay current with
developerWorks
technical events and Webcasts.
- Check out the developerWorks Apache Geronimo project area for articles, tutorials, and other resources to help you get started developing with Geronimo today.
- Find helpful resources for beginners and experienced users at the Get started now with Apache Geronimo section of developerWorks.
- Check out the IBM® Support for Apache Geronimo offering, which lets you develop Geronimo applications backed by world-class IBM support.
- Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
- Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
- Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
- Download the latest version of Apache Geronimo.
- Innovate your next open source development project with IBM trial software, available for download or on DVD.
- Download your free copy of IBM WebSphere® Application Server Community Edition V1.0 -- a lightweight J2EE application server built on Apache Geronimo open source technology that is designed to help you accelerate your development and deployment efforts.
Discuss
-
Participate in developerWorks
blogs and get involved in the developerWorks community.
Bill Zimmerly is a knowledge engineer, a low-level systems programmer with expertise in various versions of UNIX® and Microsoft® Windows® software, and a free thinker who worships at the altar of logic. Creating new technologies and writing about them are Bill's passions. He resides in rural Hillsboro, Missouri, where the air is fresh, the views are inspiring, and good wineries are all around.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
