Shared Objects System (SOS) for Java®

by Paul Burchard


Shared Objects System (SOS) is a lightwreight form of distributed objects optimized for multiuser, interactive Web applications. Shared objects are essentially ``smart proxies'' that cache most state on participating clients.

More precisely, shared objects appear as ordinary Java objects on the client, with the additional property that synchronized methods will be executed -- and executed in a consistent order -- on all identically-named instances of the same class, across all clients of the same server. Any unsynchronized methods are executed locally on each client. Latency is minimized because clients are only required to obey the ordering constraints for synchronized methods (individually for each client object), not to run in a truly synchronous manner for any call.

By default, the server only functions as a serialization and redistribution center for client-initiated method-call events, maintaining no explicit state (only an ``event history''). In cases where true server-side state is desired, however, the server scripts can easily be customized to intercept and modify the event queue in ways that reflect server state. Because state is automatically cached on the clients unless specifically delegated to the server, bandwidth is minimized for typical multiuser applications.

SOS also differs from standard RPC systems in that additional meta-information (corresponding to the last-invoked synchronized method on this shared instance) is always made available:

Any method that directly changes the state of the object must be declared synchronized, but unsynchronized methods may still change state indirectly by calling synchronized methods. Nested synchronized methods do not cost any extra round trips to the server, but as a result, if the logic of the outer synchronized method depends on local data this may result in different inner calls to synchronized methods.

To allow late-coming clients to cheaply hook into an existing shared object, the server scripts can be modified (on a class-by-class basis) to transmit only the ``important'' parts of the stored history on initialization.

Benefits of Planned Implementation:

Limitations of Planned Implementation:

Paul Burchard <>
Computer Science Dept., Princeton University