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:
-
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.
-
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.
