Dynamic Evolution Platforms

In this subsection, we describe the different works that provided platforms that may have been used as dynamic evolution platforms. We identify three

2.3. RUNTIME CHANGES 21 types of runtime evolution platforms: programming platforms, component platforms and mobile code platforms. Programming platforms consider the direct evolution of code, whereas component platforms and mobile agent plat-forms consider the composition of code. In the latter case, evolution of code is considered through recomposition and reconfiguration of code connections.

In the following we detail these mechanisms.

Programming Evolution Platforms.

In the past few years, several approaches have been proposed to provide in-frastructures (i.e., runtime platforms) to programmers and system adminis-trators, allowing runtime evolution of applications. In compiled environments the Gupta [70, 71] studies the time points at which on-line software version change may occur depending on the threads execution. This work, however, cannot be applied to object programming [69] because of the many object inter-dependencies that cannot be mapped to newer versions at evolution time.

Hicks [77, 76] proposes an infrastructure for allowing type-safe evolution of applications programmed in a typed C by adding an indirection level for each function call. However, he does not address object-orientation approach, and this solution is not directly applicable to objects (see p. 172 of his PhD thesis [76]). This is due to the fact that in an object-oriented language, it is not sufficient to apply an indirection to method calls, it has to be done to object accesses and method invocations. It does not capture at all the fact that the object structure itself may change. In effect, managing information structures is made by the programmer through on-demand translation only.

In the object-oriented paradigm some approaches like wide classes [150]

or Fickle [41] consider the possibility to change class of instances at runtime.

This is generaly done by migrating instances into type-resemblant classes.

This means that it is possible to move the instance from a class to another similar class (whether it is a child class [150] or a sister class [41]). This is justified by the fact that there is a common basis of class/instances and variables that represent the intrinsic nature of reclassed objects.

More general approaches exist, that allow a larger number of changes. In this category, Dynamic Virtual Machine (DVM) [101], through the use of a custom Java virtual machine, extends the concept of class-loader by adding a replace method. The characteristic of DVM is that it allows to replace a class by another one if the new version conforms to all the types needed by client classes. This restrains a lot the modifications that may be applied to the system because it forbids to change arbitrary classes. It is, for example, impossible to split a class into two others, or unify two classes because of the

22 CHAPTER 2. STATE OF THE ART granularity of changes is the classes.

NeoClasstalk [146] is an extension of Smalltalk that allows to modify classes at runtime and reclass objects. Smalltalk [111] has no such possi-bility as the only evolution operator is the become operator that exchange ojects identities. NeoClasstalk allows programmers to manipulate directly instances (thus classes also) in order to change their code and data struc-ture. The whole system relies on the reification of all accesses on classes and attributes. This means that for each field, a method is responsible for initial-izing it. When an object is reclassed to a new class, new instance variables are initialized, obsolete instance variables may be either dropped or hidden, and instances with the same name are left as they were. This approach is one of the most flexible and complete that is possible to find at the moment, but it works due to the fact that the Smalltalk language is fundamentally un-typed and may support a large variety of changes. In mainstream languages like Java or C#, the accent is put on security of execution guaranteed by a static check on typing. This constitutes a major stop for runtime evolution of code when the loading is designed to ensure this type of consistency.

PJama [38] consists in a modified JVM built to provide persistency to the Java language. This includes the safe evolution of classes and instances.

As a constraint, the PJama conceptors imposed that there would not be any dynamic (on-line) evolution neither core Java classes evolution. The PJama platform provides a way to transfer state of objects through the use of custom methods, and to ensure that the system is in a consistent state after the modification. Nevertheless, the limitation of having no on-line updates implies that there could not be any active thread while updating. Although this may seem to be a simple limitation, it should be pointed out that the only actual safe method to stop active threads in Java 2 is to wait for them to end. This implies that, in a real case, inconsistent states may be reached in order to make an update. Otherwise, in the case of a thread infinitely active, it may be impossible to make an update at all.

Java Hotswap [38, 39] allows to change methods at runtime: new versions of active methods are effectively replaced when the method terminates. Bi-nary compatible changes are also supported at a class level. Once more, this is due to the fact that consistency must be preserved at any cost in a running strongly typed system.

GILGUL [26] is a dialect of Java that allows to replace old objects by new ones at runtime. In a sense it brings to the Java paradigm the facilities offered by Smalltalk with thebecome operator, with the difference that only type-consistant changes may be effected (changes by instances of the same class or subclasses). The old instance may still be used by the new one (when needed) in order to capture specific behavior.

2.3. RUNTIME CHANGES 23 As we have shown in this paragraph, existing platforms do not allow arbitrary changes. There is, however, a strong need in terms of runtime evolution platform for arbitrary changes. The problem is that most of the proposed platforms consider that it is possible to build an evolution platform without modifying the general semantic of the language to which it would be applied. We think differently and, at the moment, prototypes and systems built proove that it is not possible to simply extend an already existing language. This point is argued by Costanza [26] (GILGUL’s conceptor).

In our opinion, it is simply not possible to build an unanticipated dynamic evolution platform without modifying the reference resolution.

On Components Platforms Evolution.

In evolution-oriented components platforms the vocabulary is often compo-sition models ordynamic adaptation, as the component models generaly rely on the puzzle metaphor. The component is generally described by using inputs and outputs (possibly typed). These inputs and outputs may be con-nected or reconcon-nected at will depending on the overall architecture [124, 143].

Inputs and ouputs constitute the real fixed points and the granularity is at a higher level.

In industrial approaches like Enterprise JavaBeans [165] and CORBA [121], services are referenced through a naming service (namely JNDI [94] for Jav-aBeans or the naming and trading services [119] for CORBA) that have mainly the same functionality: a component willing to use another unknown one must make a search through these services and, once found, it has to de-cide if it is the right one, given some specific information and then to use it in a potentially long-term communication process. This has several implica-tions: (1) a programmer should code the part that decides to use one service or not, (2) if the communication process is long enough, the communication itself should be stopped when updated.

However, automating the choice of the code that is effectively called is a possibility still being explored. HydroJ [93] is one of those systems that is a little bit more evolved. HydroJ contains two levels: (1) the intercomponent calls are resolved through the use of a standard service architecture (a yellow page service returns a list of services), (2) a dynamically chosen method.

HydroJ allows to choose which component is called throught the use of a yellow page service. When a call is made on a chosen component the most adapted method is chosen and called. This choice is made through the use of a pattern matching language based on semi-structured data.

Another possibility is to redirect the choice of components. Locators [79], Keris [182], GRUMPS [48] and other works on components evolution

plat-24 CHAPTER 2. STATE OF THE ART forms [86, 149] have in common that, on a first level, arbitrary changes are allowed inside a component as soon as interfaces are still the same. On a second level, the component infrastructure is responsible for redirecting, if necessary, calls to the correct component. The first level may be called the language level. The second level may be called the composition level.

Schematically, the first level is used to define the functionalities, while the second level allows to modify the reference resolutions. In recent systems, the composition level is more and more automated in order to provide com-ponent (functionality) automatic redirection and discovery, thus freeing the programmer from writing the related code. As for evolution oriented pro-gramming platforms, evolution is generally ensured by small additions to components infrastructures that allow the component dynamic linking. This means that the inter-component semantics and type of interfaces are gen-erally preserved. Nevertheless, new types of reference resolutions arise [86]

that allow more flexibility through the use of properties to guide the reference resolution mechanism.

Mobile Code Platforms.

Mobility of programs is probably one of the most interesting techniques that appeared on the Internet in the past few years. This technique is already widely used with Java applets [66]. As technology improves, the challenge is to be able to consider that these object/programs may act disconnected as they go through different administrative domains [17].

In the recent years, mobile code have been widely studied by researchers and many agent platforms like Mole [160], Telescript [92], Ara [136], JavaSeal[174, 173], Safe-Tcl [130] or Lana [15] have been designed in order to realize mo-bility [168]. The choice between strong mobility (moving threads during execution) and weak mobility (moving data and code and restarting compu-tation at checkpoints) [19] is still open as Java-based platforms provide weak mobility features.

As a matter of fact, extending the code of an application can be done using mobile code platforms, primarily used for updating the code of active net-works [166, 139]. A mobile code platform or mobile agent execution platform retains a large number of ”good” properties for evolution, as mobile agents may come and leave the platform anytime. This provides a very flexible in-frastructure for building applications that may evolve at runtime. In order to keep agent respective codes decoupled and still accessible, the inter-agent communication models involved in such platforms often need the addition of a middleware infrastructure. A first collection of examples are coordi-nation media like Jada [22],Klaim [34, 35], X-Klaim [12], JavaSpaces [176],

2.4. SATELLITE MECHANISMS 25