Explicit Adaptation - Proposal 1

 The first concept assumes that there is an object m_adaptation in the mobile code available. Its method loadImplementationClass() takes the name of the functionality interface and returns the right implementation class. In the example the mobile agent would hold a reference to an object of type IMemory. The mobile agent loads if necessary the class Memory_AIX_PPC, Memory_WINNT_X86 or Memory_LINUX_X86 from the adaptation mechanism specifying the functionality interface IMemory. The same applies to the IHarddisk and IConfiguration implementation group. In this proposal m_adaptation acts as an explicit broker which is fully visible for other objects.

 

Figure: Invocation of getPhysicalMemorySize() in proposal 1  

Figure shows a code example for the invocation of a method of the class Memory. Before the method invocation the class must be loaded and instantiated explicitly through the adaptation mechanism m_adaptation.

The member variable m_adaptation holds a reference to an object of the class Adaptation. The class Adaptation provides a method loadImplementationClass(String) which returns the appropriate class for the environment.

When the agent migrates to a new host, it drops the implementation class and re-creates an implementation class in the new environment. The mobile code does not carry the implementation class to the new environment for the case that the implementation class is not needed on the new host. Figure shows this concept where on every host the implementation classes must be explicitly re-created by the mobile agent.

 

Figure: Explicit adaptation 

This solution would implicate that adaptation is not transparent for the core:

1.

the application programmer must determine when to adapt classes (disagrees with R7)

2.

the procedure of class instantiation of adaptable classes differs from the instantiation of non-adaptable classes (disagrees with R9)

3.

method calls are not checked against type errors at compilation time, which is required by R4

A second disadvantage is the loading of the implementation class by specifying the functionality interface during runtime as a string. If a non-existing interface name is specified, the error can only be detected during runtime. This is contradictory the requirement R4. An improved level of transparency can be achieved by the following approach.