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.
Ivory initialization and communication is based on Java servlets;
these servlets are in the 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
We have included a test application in the 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 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 Before you can use the test application, the classes for the data structure must be transformed, as explained in the paper.
The We plan to develop and release more test data structures and applications.
For more information, go to developing
applications.
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.
Use of Web Servers
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.
http://moe.cs.duke.edu:9000/ivory/servlet/InitServlet?service=list
http://curly.cs.duke.edu:9000/ivory/servlet/InitServlet?server=moe&port=9002&service=list
ivoryserv
package.
Example Service Applications
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.
TreeConsistent
interface. Any method that modifies the ConitTree must
be prototyped in an interface that subclasses the
Consistent
interface.
Naming
or the
StateInterface
interfaces.
xform
directory contains the script we used to
transform the test applications.
Sara E. Sprenkle
Last modified: Sat Jun 2 15:55:59 EDT 2001