Qnav Object Extensibility

Extensibility of Java representations of OME objects has been a persistent concern in OME Java clients. Ideally, we would like Java clients to have the flexibility to extend OME classes as needed, adding additional state and logic to handle the needs of user interfaces, remote analysis, whatever.

Unfortunately, this need poses a challenge for both clients and servers. From a client viewpoint, it would be ideal if the server were to return instances of the exact class that the client needs. Unfortunately, this turns out to be a fairly difficult goal to achieve, as the server would need to have some way of determining which class the client wanted an instance of. It is theoretically possible to build server infrastructure that would maintain a registry of specific classes to use for different clients, but this would require substantial run-time configuration, raising questions about state management, transfer of class files, etc. A server that only deals with one basic class for any given OME object type is much simpler to consider.

This leaves the client with the job of designing and managing an alternative scheme for extendin OME Classes. The original shoola handles this difficulty through copying: remote objects of a base class are copied bit-by-bit into an appropriate client class, which includes the necessary extensions, and can be subclassed if needed. This approach has the benefit of simplicity, with the cost of the time and (potential) memory overhead associated with the copying. The extent of the memory overhead is not clear, as it is largely determined by the treatment of the server object and the garbage collector.

Qnav takes a different approach to client extensibility. In essence, server objects are transparently wrapped with client-side objects that provide direct access to all data in the server object, along with extensions appropriate for client use.

The key to this approach is to the the extension mechanism that is defined in the OMEObject interface. By allowing the storage of key value pairs in any base OME object, this mechanism gives us a hook for associating an object of a client class with a given server object. This can then be used to set up a two-way path between a server object and a backing client object.

In the quasi-hierarchical client, all objects retrieved from the server by an ObjectAdapterEngine. This call creates an instance of a client side class to act as a wrapper for the object returned by the server. These client classes will subclass of OMEObjectAdapter, and implement one of the interfaces that define individual OME objects. These classes maintain pointers to the client object, which will provide functionality via simple pass through calls. Of course, these client classes will also add new functionality as needed.

The object adapter engine also sets an extension in the server object to point to the client wrapper, allowing bi-directional access as is sometimes necessary. For example, if a client wants to access the dataset associated with a chain execution, this is done by examining the server object for the chain execution, accessing its dataset (which is a server object), and then using the extension field to find a client dataset object for that server dataset.

Examples of these classes and their operations can be found in org.openmicroscopy.qnav.client.navigator.data.

The selection of specific client classes to use for creation of wrapper objects is configured via  Spring configuration of the ObjectAdapterEngine class, allowing for straightforward injection of alternative client classes.

There are some drawbacks and inefficiencies to this approach as well. The creation of the object adapter does take some time and memory, although presumably not as much as time as copying an entire object. However, both client and server objects must be kept in memory. Member fields consisting of lists of objects - such as the datasets for a project - are often kept in a separate list in each client object. Thus, each client project (for example) will have a list of datasets that parallels the list of datasets in the server project object. This is intended to be an optimization, but further study would be needed to determine if this scheme provides any savings. In any case, the use of the extension field in the server object (and the local cache ) guarantees that there will be only one instance of a client object for any given ome object.

Further study would clearly be needed to conclusively evaluate the performance of this approach relative to the copying originally used in shoola.