Personal tools
  • We're Hiring!

You are here: Home Documentation Previous versions OME Server Developer Remote Framework Remote methods

Remote methods

The most important aspect of the remote framework, clearly, is the set of remote methods which are available to be called. It is these methods which provides access to the underlying metadata in an OME data server. These methods are intended to be easily extensible; it should be straightforward to publish a new Perl server-side method in an existing OME data server.

The remote methods are divided into two main categories: administrative methods and dispatched methods. Each category is described below. The specific methods which are available in the core OME distribution are described in the remote method reference.

Administrative methods

There are currently exactly four adminstrative methods, and this set is unlikely to grow very much. The administrative methods provide the mechanisms for establishing a valid OME remote connection; once this connection is established, all metadata access takes place through dispatched methods. A dispatched method cannot be called without an appropriate connection key.

These methods are implemented in the OME::Remote::Facade class in the OME Perl source tree.

Dispatched methods

The bulk of the metadata access is provided via the dispatched methods. The name of this category comes from the extra layer of dispatching which the Perl server code uses to support the remote framework's extensibility.

These methods are implemented on the OME data server by a series of Perl modules called facades. Each facade is a standard Perl OO class. Any methods which it defines are eligible to be remote dispatched methods. The OME::Remote::Facade class specifies which facade classes are actually published, and contains a dispatch method for finding and executing a dispatched method.

The most important of the dispatched methods are in the Generic Facade. This facade defines methods for retrieving, creating, and updating data objects of any of the OME core types, or any semantic type known to the data server. It also supports retrieving well-defined trees of objects in a single call, to reduce database and network overhead. Many client OME applications will spend the bulk of their time calling Generic Facade methods.

All of the dispatched methods are organized by facade and described thoroughly in the remote method reference.

Currently, the list of facades which the remote framework publishes is hard-coded in a @FACADES array, defined at the top of the OME::Remote::Facade class. We are looking into transitioning this list into a proper configuration variable. For now, programmers who wish to extend the remote framework must modify this array by hand.

Method prototypes

Every method, whether administrative or dispatched, has the following properties:

  1. It has a single string name. There is a single namespace for administrative method names, and another for dispatched method names.

  2. It takes in a list of parameters, expressed as an array in the logical type model. The method will most likely define an implicit prototype for the parameter array, but this prototype is not checked automatically by the dispatch code.

  3. It returns a single value. This value can be of any of the types defined by the logical type model. As with the parameter list, there will most likely be an implicit constraint on the returned value, but this is not checked automatically or enforced.

Document Actions