CORK Concepts

Replicated Objects

A replicated object is an object that can be replicated across multiple Java VM's. CORK attempts to place as few restrictions as possible on the kinds of objects that can be replicated. There is, for example NOT a ReplicatedObject superclass
or interface. In general there are only three requirements for replicated objects:

1. The object must be serializable. CORK uses Java Object serialization for replica retrieval.
2. The object fires an event for each "interesting" modification to its state. It must be possible to attach CORK-based listeners to the object to detect when a local change has been made.
3. For each event fired, the object must provide some mechanism for programmatically reproducing the modification that triggered the event. CORK-based listeners must be able to construct a message

(see Change below) that knows how to reproduce the modification. Note that the mechanism for reproducing the change can be arbitrarily complex -- it need not, for example, be a single method.
In practice, many JavaBeans can be easily replicated. Model objects from the Swing user interface library (and similar libraries that based on the Model-View-Controller architecture) can also be replicated
Objects which meet requirement (1), but not (2) or (3) can still often be replicated in a somewhat less flexible way by wrapping the object such that only one client at a time has permission to edit the object, and then passing the entire object state "in bulk" when a client gives up control.

CORK Server

CORK uses a central server for authentication, access control, and persistence, as well as for serialization of messages describing modification. (Ongoing work is developing extensions that will allow multiple CORK servers to be linked together.) In the current implementation, clients can connect to the CORK server via TCP or HTTP. The server is designed to be generic: the same basic server components will allow replication of any object which meets the requirements for replicability and for which CORK-based listeners have been written (see "Listeners and Replicators" below). The CORK server supports pluggable authentication and storage mechanisms, described in more detail below.

edu.vt.cs.collab.cork.ReplicatedObjectClient

Client-side components use a ReplicatedObjectClient to query for existing replicas, create new repicated objects, and retrieve and modify existing replicated objects. ReplicatedObjectClient is an interface, with implementations potentially providing different low-level mechanisms for communicating with the CORK server. Currently the edu.vt.cs.collab.cork.impl.inet.InetClient class provides an implementation of ReplicatedObjectClient that communicates via HTTP or TCP (sockets).

edu.vt.cs.collab.cork.ObjectID

ObjectID objects uniquely identify a replicated object. The query operations provided in the ReplicatedObjectClient will return ObjectIDs, which can then be used to retrieve object replicas. ReplicatedObjectClient also includes support for finding the ObjectID for a given replica.

edu.vt.cs.collab.cork.Change

Classes that implement the Change object provide the logic for reproducing a modification detected (by a listener) on one replica on replicas in other virtual machines. When a listener detects a modification, it constructs an appropriate Change object and sends it to the CORK server using the ReplicatedObjectClient's broadcastChange(...) method. When the server recieves the change, it first ensures that the user has permission to make the change (see below) and then invokes the Change's applyChange(...) method, passing in the "master" replica of the object. The Change is then sent to all other active clients who have replicas of the modified object. Each of these invokes applyChange(...), passing in their local replica.

Listeners and Replicators

In order to propagate modifications made on one replica to replicas in other virtual machines, replicated objects must fire events describing
local changes. Listeners are objects that implement the necessary interfaces for recieving these events. Listeners and Events were introduced throughout the core Java Libraries as part of the "delegation event model" introduced in Java 1.1. JavaBeans, user interface widgets, and many other classes fire events and define listener interfaces.

Replicators are objects that know how to attach appropriate CORK-based listeners to a replicated object. Note that while listeners are needed, replicators that encapsulate listener attachment logic are not. It is perfectly acceptible for a CORK-based application to construct and attach listeners at any place or time. CORK does, however, provide classes to support management of replicators. A concrete implementation of the edu.vt.cs.collab.cork.Replicator interface can be written for any replicated object, and the edu.vt.cs.collab.cork.ReplicationManager class provides a registry mechanism for starting and stopping replication on a given object retrieved from the CORK server

edu.vt.cs.collab.cork.security.Permissions

Instances of classes that implement the Permissions interface control access to replicated objects. A Permissions can be provided when a new object is created or (if permissions allow) can be set on an existing object. The Permissions object can determine whether a given user can see and retrieve a replicated object, modify the object, delete the object, or change the permissions on the object. While these decisions are typically made based on user identity, they could also be based on other data such as time-of-day, server load, or client IP address.
Permissions objects work in a fashion similar to the standard java.lang.SecurityManager class. A method with void return type is defined for each potentially-restricted operation. If the operation is not allowed, the method throws a security exception.
In the edu.vt.cs.collab.cork.security package, NullPermissions implements a "free access" policy and UserListPermissions restricts access to a particular list of users.

edu.vt.cs.collab.cork.search.SetCriteria

SetCriteria objects implement a method that match replicated objects against a given criteria. These objects are used to query the CORK server (via the ReplicatedObjectClient's getIdentifiers(SetCriteria crit)
method. For example, instances of the edu.vt.cs.collab.cork.search.RetrievableCriteria class are often used to retrieve the id's of all replicated instances of a given class that can be retrieved by a given user.

The SetCriteria/getIdentifiers mechanism is currently under review, with changes to improve performance and security likely in the future.

edu.vt.cs.collab.security.Authenticator

The CORK server supports pluggable user authentication mechanisms through the Authenticator interface. Classes which implement this interface can be registered with the server object and will be consulted when a user attempts to connect. Current implementations (all in the edu.vt.cs.collab.security package) include:

• NullAuthenticator, which accepts any user id and password pair
• LDAPAuthenticator, which consults an LDAP server for password checking
• UNIXCryptAuthenticator, an abstract superclass for authenticators that need to check against unix-style crypt()'d passwords
• CompositeAuthenticator, which allows multiple authenticators to be queried

edu.vt.cs.collab.cork.storage.StorageHandler

The CORK server currently defaults to using a file-based storage mechanism for object persistence. By default, this storage mechanism uses Java Object Serialization to read objects from and write objects to files. While object serialization is convenient, it has a number of drawbacks. It is "brittle", in that if the implementation of the object's class changes even slightly, the serialized objects may no longer be compatible. It also produces a binary file, making (hopefully rarely-needed) manual edits nearly impossible. Developers of replicated objects can provide more flexible and convient alternatives to serialization by creating helper classes for their replicated objects that implement the StorageHandler interface.

When the CORK server needs to read or write an object, it first checks to see if there is a StorageHandler for the object's class. If there is, the StorageHandler object is used to read or write the object's state. If no StorageHandler is found, serialization is used. StorageHandler classes may be explicitly registered, or can be implicitly defined by class name: If no StorageHandler has be explicitly registered, the storage mechanism will append the string "StorageHandler" to the end of the name of the object's class and see if such a class exists.

StorageHandler objects typically use an XML format for storing object state. In the future we will likely provide a more complete set of utility classes to help standardize these formats.