The Interpretation of Service Interfaces
Elements of Design
Elements of Design
  Contents

PDF version   PostScript version

Reflection as the Basis of Dynamic Proxies

We introduced in Section the concept of computational reflection and its partial support in the Java language. In the next two sections, we present two elements of XMLbroker that rely on the Java reflection facilities: the implementation of stubs as dynamic proxies and the semantic extension of the Java method signature.

Traditionally, the data encoding/decoding (also called marshalling/unmarshalling) logic specific to a particular distributed object's interface is built into the client and server stubs--each materialised by a class file, generated by a dedicated compiler. In Java, this may be achieved by first creating a source code tree, serialising it into a character stream, and then invoking the java compiler via the sun.tools.javac package.
Java however offers a more elegant solution by the means of reflection. At the root of the inheritance tree is the java.lang.Object, containing the getClass() method--returning an instance of the java.lang.Class meta-class. Given any object or interface name, it is therefore possible to obtain an instance of the meta-class, and discover all the visible properties of the object. In the example given in Listing , the return type of a service method is checked. In our model, output parameters are supported, rendering returned values non-necessary and therefore not supported. This example is adapted from the validate() method of the JavaInterpreter class.

It is also possible to call a method from its meta-method object. This feature is utilised in the Linker class to build and then invoke the service method on the servant object. Listing presents a simple example of such a method invocation mechanism.