OCSelot
- A Lightweight Java Middleware

Overview

This page sketches what OCSelot is and how it's used. OCSelot requires little work, both in use and in learning: There's only a few principles to understand and a small number of classes to handle, and you're ready to go.

Proxies and subjects

OCSelot derives its name from Object Client/Server, as it is based on object-to-object communication.

More precisely, OCSelot employs the well-known Proxy design pattern. A proxy is a placeholder for another object called the proxy's subject. Whenever a method is invoked on the proxy, it transparently forwards the call to the associated subject.

In the context of the OCSelot middleware, a proxy is a local representative of a remote subject. In order to transmit the request, the proxy uses a client which communicates with a server hosting the subject, making this communication chain:

Types of proxies

A proxy typically shares the type of the subject, so it can stand in for the subject in any situation, be it assignment, parameter, or return value.
In OCSelot, there are two variants of proxies, "class proxies" and "interface proxies":

Class proxies

are based on their subject's class. A class proxy is an instance of a subclass of the subject class. This subclass overrides every base class method with code that forwards the method invocation to the subject.

Proxy subclasses are made using the OCSClassProxyFactory, which generates source code that needs simply to be compiled and then is ready for use. With the exception of final classes, all classes can be subclassed in this way.

Interface proxies

are based on their subject's interface. An interface proxy implements one or more interfaces which declare methods of the subject class. The proxy implements the interface/s by forwarding method invocations to the subject.

Interface proxies are generated on the fly by the OCSInterfaceProxyFactory. To be used for the creation of interface proxies, an interface does not have to be an official part of the subject's type, it suffices that it has methods matching those of the subject class. Since interfaces fulfilling this relaxed condition can always be created, the use of interface proxies is an option for subjects of all classes.

Client controls server

An important feature of OCSelot is that services are under control of the client.

An OCSelot client is able to install subjects on the server, either by calling server methods from remote (the client has access to objects allowing to invoke both user and administration methods on the server), or, even more elegantly, by simply creating class proxies: When being constructed, a class proxy can attach to an existing subject or create one.

It is of course possible to supply the server with subjects directly, but frequently applications will run an initially empty server and let the clients take full control over the services hosted by the remote process.

A server can be configured to restrict the uses it is put to.

Local and remote versions

Another notable aspect of OCSelot is that it is most easy to turn a local into a remote version and vice versa.

To remote-ify a locally working program, it doesn't take much more than running an empty server, starting the client, and replacing a number of objects with proxies.

The opposite transition is even simpler: you can stick with the proxies and simply turn off the client or reconfigure it a little. In many cases, a different parameter to the client will suffice to switch the mode, and this can be done at runtime.

A local version programmed this way is structurally still a client/server application using proxies communicating with subjects with the help of a client and a server. The only difference is that the client object has a direct link to the server object, so that requests can be forwarded without network.

The API

that an OCSelot user has to deal with, is easily manageable.

Besides three interfaces for the different types of proxies

two interfaces which declare methods of class OCSServer and, with the help of interface proxies returned by OCSClient methods, allow to call an OCSServer instance from the client side and the two exception classes these are the classes with some weight:

Typical workflow

To build a client/server application using OCSelot, these are the typical steps you will take:

Let's say you have a class with the qualified name my.pack.Clazz. You want to have an instance of this in a remote process and invoke it from a client in another process.

To achieve this, you let the OCSClassProxyFactory create a proxy class for my.pack.Clazz, by running

java -cp ocs.jar;ocs-tools.jar;. tw.net.ocs.OCSClassProxyFactory -class my.pack.Clazz

This generates the source file tw/net/ocs/proxy/MyPackClazz.java. You compile this file and make sure the new class tw.net.ocs.proxy.MyPackClazz is in the classpath.

Now prepare the server ... but there's nothing to prepare, you simply start it:

java -cp ocs.jar tw.net.ocs.OCSServer -start -port 12345

And the client-side rest is almost told as quickly:

Create an OCSClient instance which connects to the server:

OCSClient.createInstance(
   "111.22.3.4", // assuming this to be the server's host
   12345, // and this its port,
   null, // no name necessary,
   true // configured for use by subsequently created proxies
);

Then simply allocate an instance of the proxy class and assign it to a variable of the base class.

my.pack.Clazz c = new tw.net.ocs.proxy.MyPackClazz();

That's it!

The proxy construction is accompanied on the server by the construction of a my.pack.Clazz instance which will function as the proxy's subject. Every time you invoke a method on the proxy, the invocation will transparently be forwarded to the remote subject.

Learn more

To really get started, now have a look at the complete code of the examples. The examples use simple classes to illustrate a number of typical client/server scenarios, from elementary to complex. Then browse a little in the API and read the manual!

Last modified Feb 16, 2006