Personal tools
  • We're Hiring!

You are here: Home Documentation Previous versions OME Server Developer Remote Framework Network Transfer Protocol

Network Transfer Protocol

Of course, none of this would be useful without a way to actually transmit the method calls and return values. This is where the network transfer protocol comes in. Any network transfer protocol can be used, as long as it satisfies the following properties:

  1. It must be able to represent the values defined by the logical type model. It is possible for the protocol to place extra constraints on the size of values which can be expressed, but this will limit the set of remote methods which can be called.

  2. It must be able to represent arbitrary function calls and return values. It must allow both administrative and dispatched methods to be called, and must be able to handle exception results in addition to the standard

The default network transfer protocol is currently XML-RPC. All of the values in the logical type model (except for the null value, which must be handled specially) can be represented directly in the XML-RPC schema. Further, it provides standardized request and response document types to represent function calls and return values. This means that most of the work of the network transfer protocol is taken care of automatically by whichever XML-RPC library is used. There are of course, disadvantages to using XML-RPC. The XML-RPC transport protocol is described in more detail here.

Java client code

Most of the omejava library is designed and written in such a way that it is independent of which particular network transfer protocol is used. In terms of the code, the RemoteCaller interface defines the operations which any protocol must provide; the other classes in the library are defined to work with any implementation of this class. The DataServer class defines the logic for retrieving an instance of the default implementation, XmlRpcCaller.

To use a different network transfer protocol, all that is needed is to write a new implementation of the RemoteCaller interface. The application code which initializes the DataServer object would then provide an instance of this new class, instead of relying on the default instantiation code.

The omejava libary is also responsible for taking the flat namespace of dispatched methods available in the remote framework, and casting them into a more Java-like organization and design. Programmers who are writing Java applications, and who do not care about the underlying RPC mechanism being used to satisfy their data server requests, will probably find the Java API reference more useful.

Perl server code

On the server side, the independence from the network transfer protocol is implemented differently. Rather than working with a drop-in instance of a protocol interface, like the Java client code, the Perl server code implements the remote methods as regular methods in a Perl class. (This includes a method for executing dispatched methods without having to know the appropriate method body is found.) The network transfer protocol code is then responsible only for the connection and serialization logic; it can call the appropriate Perl functions to actually execute each remote method.

Document Actions