Adaptation Adaptor - Proposal 2

 A higher level of transparency can be achieved by wrapping the procedure of adaptation. Instead of using objects of type IMemory and loading different implementations, a non-adaptable class wraps the adaptable classes and links them with the core.

 

Figure: Adaptation adaptors 

Similar to CORBA's IDL stubs [#!OrHa1998!#], where stubs hide the marshaling and simulate a local method call, little adaptor classes hide the adaptation from the core, and simulate a method invocation in non-adaptable mobile code. To the functionality interface IMemory an adaptor class IMemory_Adaptor which implements IMemory and is used in the mobile code instead of IMemory. The same code as the one above looks with adaptor classes like in figure .

 

Figure: Invocation of getPhysicalMemorySize() in proposal 2  

All interactions between implementation classes and the core are handled by the adaptor classes. They decide when to adapt, hide the dynamic loading mechanism and provide a Java conform class instantiation to the application programmer. The adaptor classes could also be automatically generated at runtime similar to the proxy class in Objectspace Voyager [#!Voy2000!#].

 

Figure: Functionality of adaptor 

The adaptor holds a reference to an object of the class Adaptation (s. section ) and loads via that object the right implementation class. The method invocations from the core are delegated by the adaptor to the implementation class.

The disadvantage of this approach is the compilation of the adaptor classes. It involves an additional tool, the adaptor generator, which must be integral into the compilation procedure, and complicates the maintenence of compilation setup, e.g. Makefiles etc. It also does not offer total transparency as desired, because the application programmer uses the adaptor classes with the class name suffix _Adaptor.