Structure of an Adaptor

Figure shows the adaptor class for the functionality interface IMemory. The adaptor class implements the Serializable interface which enables the serialization of the adaptor class. This is necessary for moving the adaptor class with the mobile code.

 

Figure: Adaptor class for IMemory  

Through the object m_adaptation an adaptor can load the right implementation class for the current environment. The member variable m_adaptation is marked as transient. Though the adaptor class is serialized for migration to another host, the m_adaptation object is dropped and recreated after de-serialization. This reduces the size of code that moves over the network.

The implementation of the interface IMemory enables the core to use the adaptor class IMemory_Adaptor like a non-adaptable conventional implementation of IMemory without any considerations about adaptation.

The member variable m_iimplementation holds a reference to an object of the implementation class, which is suitable for the current environment. It is also marked as transient, since the implementation class may become obsolete, when the mobile code leaves the current environment.

The generic part of the adaptor classes, printed in boldface in figure , consists of the implementation of the interface Serializable, the member variable m_adaptation and the method createAdaptation(). The method createAdaptation() recreates the dropped adaptation object after the migration to a new environment.

 

Figure: Generic part of the adaptor class for IMemory  

The interface dependent part, printed in boldface in figure , consists of the method implementations defined in the functionality interface - in this case the implementation of the method getPhysicalMemory() - and the object m_implementation of implementing the functionality interface.

 

Figure: Example for interface dependent part of the adaptor class for IMemory  

The adaptor classes provide the skeleton to delegate the method invocations from the core, e.g. getPhysicalMemory (s. figure ), to the implementation class and return the result to the core.

 

Figure: Delegation of method call to implementation  

Exceptions that are thrown during adaptation are caught by the adaptor class. Two kind of exceptions can be thrown because of adaptation:

• the repository is unreachable for the mobile code
• no profile matches, i.e. there is no suitable implementation class for the environment,
  in which the mobile code is running at present

These two kinds of exceptions are both mapped onto a class not found exception, which is the consequence for the non-adaptable core: a necessary class can not be loaded.