Interaction between Core and Adaptation Mechanism: R5-R10

If mobile code uses adaptation, one interesting question is: How much does the core (s. section ) have to know about the fact that adaptation is used? The most desirable answer would be: Nothing. That means that the core does not have to worry e.g. when to trigger adaptation, how to handle any faults during adaptation or to care for linking any adaptable parts: full transparency of adaptation. The following requirements build a basic set to get towards full transparency.

R5

As defined in section the mobile code must not be terminated for the adaptation.

R6

Another requirement in order to get more transparency is the demand for minimal impact on the characteristics of the mobile code. E.g. if the adaptation mechanism would strongly rely on a central server, it would loose its autonomy, an important characteristic of mobile code.

R7

The initiation of the adaptation should not be task of the core. The adaptation mechanism must be able to notice itself when it is necessary to reconfigure the mobile code.

R8

This requirement which may overlap with the former is the demand for linking adaptable parts without participation by the core. If the mobile code is being adapted, parts perhaps defined as modules, components, objects or other other kind of units must be exchanged. From where they are loaded, e.g. over the network or from a specific directory, and how they are linked into the running core should not be mixed up with the task of e.g. performing configuration management and executing a specific task.

Method invocation on adaptable mobile code should not differ from standard method calls.

R9

There should be no special syntax required for calling a method offered by an adaptable part.

R10

Also the semantic (R10) of the method must simulate the invocation of a non-adaptable method. In distributed environments, like CORBA [#!OrHa1998!#] or Java RMI [#!Sun1999!#], a similar problem occurs. The handling of remote objects is hidden to the application by local stubs, which encapsulate the communication with the server.

The requirement of the standard syntax used for adaptable method calls overlaps particularly with requirements R1-R4, which concern the programming language and syntax for implementing adaptable mobile code.

After considerations concerning programming effort and transparency the following topic specifies some demands concerning the influence of adaptation on the performance of the mobile code.

 

requirement class requirement acronym

no meta language for adaptation R1

source code overhead R2

[-1.5ex]programming effort integrated solution R3

high error detection during compilation R4

adaptation without termination R5

minimal effect on mobile code semantics R6

interaction between automatic initiation of adaptation R7

core and adaptation automatic linking of parts R8

standard syntax for adaptable methods R9

transparent method call R10

smaller size than monolithic application R11

runtime overhead low time for re-configuration R12

low time for invocation of adaptable methods R13