This rather complex demo illustrates the code migration capabilities of SugarCubes. It shows how to use the ability to freeze some components of a program at the end of an instant (when the reactive system is known to have reach a consistent state). It also shows how the support of the serialization mechanism of Java in SugarCubes provides a powerfull mean to marshall, to communicate and then to unmarshall programs very easly using RMI. Finally, it demonstrates the use and the flexibility of hierarchical constructions made of Cubes and reactive machines (which are particular kind of Cubes in SugarCubes), to implement migration of a group of components without loosing synchronization among components of the group.

In this demonstration, one uses RMI as the network communication mechanism between reactive sites. This provides very simple mechanism to implement code migration. Most of the migration examples presented in the demo are what one calls objective migration examples. That is to say the user of the demo decides when and where some executing code (Cubes) should be frozen and migrated to another location. On the other hand, subjective migration (a piece of code decides to migrate itself to another location according to its own behavior) can also be exibited in the demo.

This demo provides a basic architecture allowing one to create reactive sites. A reactive site is a simple process that handles a reactive machine. Basically this reactive machine only contains a halt instruction to avoid termination of the reactive machine. This reactive machine can receive new program from the network asynchronously using a dedicated rmi server (when received programs are added in parallel in the reactive machine, between two instants).
The user can start many reactive sites on different computers or even on the same if they have different names. Reactive sites are identified by the name of the host machine and a name of the site, which should be unique.

On the top of that network of reactive sites, one builds an application demo, which is made of a reactive machine (not a the same as the reactive machines used by reactive sites), which encapsulates some reactive programs. One calls this applicative reactive machine the "Agent Sin/Cos Demo". Remember that a reactive machine is also a reactive program so we have made a tool that can send a new instantiation of the "Agent Sin/Cos Demo" to a reactive site.
The applicative machine is added into a reactive site as any other reactive program (because in SugarCubes a Reactive Machine is also a program as any other instructions). When executed on reactive site, an applicative reactive machine executes its own program, which process the reactive objects it encapsulates.

As a reactive machine is a Cube, it has an associated Java object that in the case of the Agent Sin/Cos Demo is a Java Frame. This window contains a panel (Workspace) in which graphical objects are displayed (Icobjs). And a row of three button with which the user can generate events in the applicative reactive machine:

• The event "cos", to trig the periodic movement (cosinus) of an Icobj on the horizontal axe.
• The event "sin" , to trig the periodic movement (sinus) of an Icobj on the vertical axe.
• The event "sin" and the event "cos" at the same instant to trig the two previous behaviors simultaneously.

Main Window associated to the applicative reactive machine.

In addition to the main window, applicative reactive machines also have a controller window containing 4 buttons:

• The first button allows one to create new Icobjs (displayed in the workspace of the main window).
• The second button allows one to create group object (described later).
• The third button allows one to display the migration controller associated to the applicative reactive machine (described later).
• The fourth button allows one to generate the "migrate all" event in the applicative reactive machine.

Here, Icobjs are made of two simple behaviors run in parallel:

• The first one awaits for the event "cos" (generated when the user clicks on the cos button or on the sin & cos button) and then execute cyclically an horizontal movement according to a displacement following a cosines function.
• The second one waits for the event "sin" (generated when the user clicks on the sin button or on the sin & cos button) and then execute cyclically an vertical movement according to a sinusoidal displacement.

Group objects are special reactive objects added in the applicative reactive machine by the user (when one clicks on New Group), which is used to implement groups of objects. As a Cube can be enriched dynamically, by new reactive programs executed in parallel, a group objects can receive other objects to add them in parallel to its own body. A group is represented in our system by a special control window like this:

The first label of this window indicates the object in which this group is encapsulated (in this example this is the applicative reactive machine toto). the label on the second line of components indicates the name of the group (which is also indicated in the title of the window) using the color associated to the group (green in this case). Then a text field allow the user to type the name of a new object to add to the group (in this case the Icobj named toto_icobj_0) and finally the button "move in" validate the operation and take the indicated object in the reactive machine and adds it into the group to be executed in parallel with other components of the group. When added to a group, an Icobj gets a mark of the color of the group.

The migration controller of an applicative reactive machine is a window, which provides an interface to migrate objects in an applicative reactive machine to other sites across the network where other applicative reactive machines are run. The window looks like this:

First one gives the name of the target host (or the IP address) where the target applicative reactive machine running. In the next text field, the user enters the name of the target reactive machine (in this example: titi). Finally, the last text field should contain the name of the object to migrate (for example in this case the Icobj toto_icobj_0). The user validates the action by clicking the button "OK". Then, the Icobj is frozen and extracted from the current reactive machine (toto) and then sent across the network to the distant applicative reactive machine (titi), where, if it can retrieve an execution environment, it will be executed. Groups of objects can be migrated also.

On important feature here is that as reactive machine are also reactive instructions and more precisely cubes. They also can be migrated from site to site. But here you cannot use the migration controller attached to the machine itself but the one attached to the machine, which encapsulates it. So in our case every reactive site have a also a migration controller attached to :

which can be used to migrate applicative reactive machine from reactive site to reactive site. The first text field of this window should contain the name of the target host (or the IP address). The second field should contain the name of the target machine (which can be a reactive site or an applicative reactive machine). Finally, the last text field should contain the name of the applicative reactive machine to migrate. By clicking on the button "OK", the user validates the action and trigs the migration of the applicative reactive machine with all the reactive objects it encapsulates.

The jar file contains sources and compiled classes. To execute migration demo you must add the SugarCubesv3.0.3.jar package, the experimental package ReactiveKit.jar and the migration.jar package in your CLASSPATH.

You access to source files just by typing jar xvf migration.jar

To execute the demo you have to start some reactive sites other the network. As the demos uses RMI mechanism, users of Java 2 environment must define a security policy file. The simplest way to do that is to create a simple text file called 'policy', with the following content:

    grant {
        permission java.security.AllPermission;
    };

To start a reactive site, just enter the following command:

        java -classpath SugarCubesv3.0.3.jar:ReactiveKit.jar:migration.jar
                -Djava.security.policy=policy demos.migration.RSite
                                        'name of the reactive site'

Reactive sites are simple reactive processes with a reactive execution machine which can be populated with reactive programs sent through the network using RMI.
A Reactive Site presents a window wich allows the user to request migration of components present on this site.

If you have a running rmiregistry on port 1099, be sure that the ReactiveKit.jar package is in its CLASSPATH. If you don't have a rmiregistry running, starting a reactive site, will automatically start a registry for you.

Example:

java -classpath SugarCubesv3.0.3.jar:ReactiveKit.jar:migration.jar -Djava.security.policy=policy demos.migration.RSite R1 &

If you have a rmiregistry running (with the proper CLASSPATH set) or you have already started another reactive site on the same computer you probably will see a message like the following on the console :

Cannot create Rmi registry, perhaps it already exists:
java.rmi.server.ExportException: Port already in use: 1099; nested exception is: 
        java.net.BindException: Address already in use
building server R2 on the registry macaroni
building
done

This is ok. The exeception displayed here only indicates that a rmiregistry already exists on the port 1099.

Then you can download the demo on the various Reactive Site using the following command:

        java -classpath SugarCubesv3.0.3.jar:ReactiveKit.jar:migration.jar
                -Djava.security.policy=policy demos.migration.AgentSinCos
                        'name of the host of the target reactive site'
                        'name of the new application'
                        'name of the target reactive site'

This command will instanciate the reactive program of the demo application and send it as an agent through the network to the targeted reactive site.

Example:

java -classpath SugarCubesv3.0.3.jar:ReactiveKit.jar:migration.jar -Djava.security.policy=policy demos.migration.AgentSinCos macaroni toto R1

After execution of the previous command, the targeted reactive site is populated with a new reactive program (obtained through the network) which is a nested reactive machine which executes the Agent SinCos demo. This nested machine is bound to a Java Frame titled "Agent Sin/Cos Demo: toto" which has a reference to another Frame acting as a Control panel with a set of buttons (This Frame is titled "Controller toto").