As a Service Cache

 Ivory | Download | Java Docs | Developing Applications
Service Cache | Web Servers | Example Service

Service Caching Framework Built on Ivory

Service caches are used to scale dynamic services by replicating the Java code and data used to generate dynamic content. These caches should produce correct results, as would be produced by the server--within some application-appropriate margin of error. We want consistent copies of the code and data, while keeping the client-perceived latency low, and we want to minimize the cost of managing state. We implemented a simplified service cache using Ivory. The service cache framework can be used as is or modified to create other caches.

A service cache is associated with a service. For our purposes, a service is a group of applications that execute on the same set of data objects. As shown in the figure, application threads, which run in the context of a service, are transformed to make calls into the Ivory infrastructure to access and modify data objects.

The implemented service cache is simply a thin layer around Ivory. The service cache is not fully-functional and lacks features such as restricting the amount of space available for the cache or a replacement policy for evicting conits. However, the service cache is a good example application that uses Ivory and is sufficient for testing and evaluating Ivory.

Use of Web Servers

Ivory initialization and communication is based on Java servlets; these servlets are in the ivoryserv directory. Therefore, the primary server and the replicas must be run using web servers. In the development environment, we use Java's web server, but we believe any web server will work. (We plan to try IBM's WebSphere soon.) The servlets should be placed in the appropriate directory for the web server.

Currently, Ivory is implemented as a very simple, not fully-functional service cache. The cache for each service must be initialized.

Example Initialization:

You should not have to directly invoke any of the other servlets included in the ivoryserv package.

Example Service Applications

We have included a test application in the testapp directory. This directory includes the Java classes for a simple linked-list/tree structure (in the list package) and the servlets that operate on the data structure (in the listserv package). To understand the test application, you should be familiar with conits and their use in Ivory and refer to the Java Docs.

Data Structure: As shown in the figure, the data structure is a linked-list/tree structure and is made up of two classes: ConitTree and ListItem. ConitTree inherits from the ConitRoot class, while ListItem inherits from the ConitObject class. ConitTree has a reference to a ListItem, which contains an int and a reference to a ListItem, and a reference to the next "branch" of the tree, which is another ConitTree.

Each ConitTree can either begin a new conit or attach to an existing conit. Before the tree object is replicated, it must be a member of a conit.

ConitTree also implements the TreeConsistent interface. Any method that modifies the ConitTree must be prototyped in an interface that subclasses the Consistent interface.

Service Applications: Several servlets were written to test Ivory in the service cache environment. These servlets build, print, and modify lists that are identified by symbolic names.

The servlets must "enter a service" so that the StateManager knows which service a thread is operating in. The service can be entered through the Naming or the StateInterface interfaces.

Before you can use the test application, the classes for the data structure must be transformed, as explained in the paper. The xform directory contains the script we used to transform the test applications.

We plan to develop and release more test data structures and applications.

For more information, go to developing applications.

Sara E. Sprenkle
Last modified: Sat Jun 2 15:55:59 EDT 2001