ObjectStore Java Tutorial
Chapter 2

Description of the Personalization Application

This tutorial refers to the Personalization application to help illustrate the key principles of ObjectStore. The following topics describe the Personalization application:

Overview of the Data Model

Description of the UserManager Class

Description of the User and Interest Classes

Overview of the Data Model

Consider the task of personalizing a web site to cater to an individual user's interests and access patterns. A personalized web site delivers customized content to the browser user. To achieve customization, a database of users and their interests must be maintained in the web architecture.

The personalization database tracks user interests so that web content can be generated dynamically based on those interests. Since web sites change rapidly, it must be easy to define new interests to the database. Each user's set of interests is different, and users can change their interests at any time.

The following figure shows the personalization object model with Rumbaugh OMT notation. White classes are transient, that is, they are internal to the application's memory. Shaded classes are persistence-capable, that is, instances can be stored in a ObjectStore database.

Description of the UserManager Class

Clients interface with the UserManager class, which controls access to User and Interest objects in the database. The UserManager also controls user access, registration, and session management. The UserManager might run as an application server that operates behind a web server and provides access to the personalization database.

The UserManager class has a number of static members that keep track of the database that is open, the set of registered users, and the set of interests defined to the database. It also has a number of static methods, each of which executes a transaction in ObjectStore.

The tutorial example reads terminal input to generate requests, but requests can easily be passed by the client by means of Remote Method Interface (RMI), an Object Request Broker (ORB), or as Common Gateway Interface (CGI) environment variables if using Hypertext Transport Protocol (HTTP).

The UserManager class contains most of the database-specific code, such as starting and ending transactions. There are no UserManager objects stored in the database, which means that the UserManager class is not required to be persistence-capable.

Description of the User and Interest Classes

There are two persistence-capable classes in the Personalization application: the User class and the Interest class. Only instances of persistence-capable classes can be stored in a database. Chapter 4, Compiling and Running an ObjectStore Program, describes how you use the postprocessor to make classes persistence-capable.

User objects contain core information about a user, for example, name, email address, and personal identification number (PIN). User objects are an acquaintance of (that is, they are associated with, but do not own) Interest objects. Interest objects contain descriptions of the types of content the associated user is interested in. The Interest's name (for example, "Food") and value ("Pizza") define the interest of the user. Users can change their profile dynamically at run time by adding and removing Interest objects.

You define the User class for persistent use the same way you define it for transient use. The Interest class is also defined just like any other Java class. Other than the import COM.odi.* statement, there is almost no special code for persistent use of the User or Interest class. This is one of the key advantages of the transparent Java language binding that ObjectStore provides.

One special call you might add is to the COM.odi.IPersistent.preDestroyPersistent() method to perform cleanup before you destroy an instance of User or Interest. The complete implementations for the User and Interest classes are in Appendix A.

Adding New Interests

You can create new interests at run time because of the simple "metadata" aspect of the Interest class. That is, an Interest object has a name and a value. The name (for example, "Food") and value ("Pizza") can be defined at run time. New classes are not required to add or change interests.

Adding New User Types

As you define new types of users, you can add them as a specialized type of User. For example, CorporateUser and RetailUser are specializations of the generic User class. These specialized user types can overload and perform various functions. For example, different user classes can apply different heuristics for authentication. For simplicity, the tutorial example implements only the generic User class.

Source Code for the Interest Class

Here is a portion of the source file for the Interest class. Complete source code is in Appendix A, Source Code for Interest.java.

package COM.odi.tutorial;
import COM.odi.*;
/**
 * The Interest class models a particular interest that a user might
 * have. It contains a name and a value. For example, the name of
 * an interest might be "food" and the value might be "pizza".
 */
public class Interest
{
      /* the name of the interest */
      private String name;
      /* the value of the interest */
      private String value;
      /* the user who has this interest */
      private User user;
      /* accessor functions */
      public String getName() { return name; }
      public String getValue() { return value; }
      public void setValue(String value) { this.value = value; }
      public User getUser() { return user; }
      /**
       * Constructs a new interest object given a name and a value
       */
      public Interest(String name, String value, User user)
      {
            this.name = name;
            this.value = value;
            this.user = user;
      }
}

Source Code for the User Class

Here is a portion of the source code for the User class. Complete source code is in Appendix A, Source Code for User.java.

package COM.odi.tutorial;
import java.util.*;
import COM.odi.*;
import COM.odi.util.*;
/**
 * The User class models users. Users have names, email addresses,
 * and PINS. Each user also has a set of interests. The application
 * uses PINs to validate a user's identity.
 */
public
class User {
      /* The name of the user */
      private String name;
      /* The user's email address */
      private String email;
      /* The user's Personal Identification Number */
      private int PIN;
      /* The set of user's interests */
      private OSHashMap interests;
      /* accessors */
      public String getName() { return name; }
      public String getEmail() { return email; }
      public int getPIN() { return PIN; }
      public Map getInterests() { return interests; }
      /**
       * Constructs a user object given the name, email and PIN
       */
      public User(String name, String email, int PIN) {
            this.name = name;
            this.email = email;
            this.PIN = PIN;
            this.interests = new OSHashMap(5); /* initial hash table size */
      }
      /**
       * Add an interest to the User's list of interests.
       *
       * @param interestName the name of the interest
       * @param interestValue the value of the interest
       *
       * @exception PersonalizationException If the interest is
       * already there (the same name as another interest)
       */
      public Interest addInterest(String interestName, String interestValue)
                   throws PersonalizationException {
            // Implementation  ...
      }
      /**
       * Update an interest in the User's list of interests.
       *
       * @param interestName the name of the interest
       * @param interestValue the new value of the interest
       *
       * @exception PersonalizationException is thrown if the interest is
       * already not there.
       */
      public Interest changeInterest(String interestName, String interestValue)
                   throws PersonalizationException      {
            // Implementation ...
      }
      /**
       * Remove an interest from the User's list of interests.
       *
       * @param interestName The name of the Interest to remove.
       *
       * @exception PersonalizationException if the interest is not
       * found in the user's list of interests
       */
      public Interest removeInterest(String interestName)
                   throws PersonalizationException {
            // Implementation ...
      }



[previous] [next]

Copyright © 1998 Object Design, Inc. All rights reserved.

Updated: 10/07/98 07:05:27