ROS

ROS is a Mobil Agent System (MAS) that was built using the Reactive Synchronous Model (RSM). ROS was implemented using Junior and REJO, two Java-based languajes for programming reactive behaviors. Since the services and the structure of a MAS are similar to those of an Operating System, ROS (Reactive Operating System) was designed as one, e.g. you will find the notions of kernel, services, concurrent entities , shell and GUI. ROS was designed using the philosophy of micro-kernel, i.e. the system is not a big monolythic system but a little and modular kernel.

Two ROS services were built as REJOs applications: Rsh and ROS GUI. These REJO applications facilitate the use of ROS and increase its powerful. Rsh is a Reactive Shell that offers to users the means to interact with the kernel and to make a reactive programming with a shell style, i.e. a interprete language. REJO GUI offers a graphical version of Rsh and a graphical environment to interact with the REJO.

The mobile agents executed by ROS are the Reactive Objects produced with the REJO language. REJO agents may migrate through several ROS sites which offer the services that they need. ROS is a prototype that lacks of some importants services, for example security service and group service, but it is a research project used for testing new ideas.

This page presents the ROS system. The ROS's characteristics are given in the section 1, its architecture as well as some details of its implementation are given in the section 2. The section 3 explains the migration stages and the section 4 explain the two interfaces that has ROS: the user interface(Reactive shell) and the programmers interface. Finally, the section 5 finishes comparing ROS with other platforms, and the section 6 does a resume of the system and describes the set of possible improvements.

1. Introduction

ROS is the evolution of RAMA platform that was created by Navid Nikaein [16] with the objective of test the reactive approach in the construction of mobile agents. The result was a system that showed that the reactive approach is suitable to the construction of MAS. MAS are complex systems that may be studied according to the properties and services offrered [20]. This section presents some of the main properties of MASs and the ROS characteristics according to these properties.

Mobility

When an agent migrates from one site to another it may migrate 3 things: data, code and state of the program. In general it is easier to migrate without the state of the program because it depends of the platform (according to the processor it must be saved the registers, the stack and the program counter). When an agent migrates without the state of the program the migration is called weak mobility and in the other hand strong mobility.

The basis of the RSM is the notion of instant. At the end of a instant, reactive programs achieve stable state where the program can be migrated without problem. In adition, the execution state of Junior programs can be saved without problem because its implementation does not depend on the processor (thanks to Java and to the Junior execution model). In conclusion REJO agents use strong mobility; the migration process is described in section 5.

Routing

The Mobil Agents, as its name says, must have the facility to migrate in an autonomous way from one site to another in order to continue its execution. Hence, an agent have to know the address of its destination node. In order to resolve this problem many approaches have been proposed, the most known are to get the addresses from another agent or to define in the agent a list of sites for visiting. The two algorithms present the problem to become useless because either the service searched is not longer available or the topology have changed.

ROS system does not offer any particular routing algorithm, however agents may implement without problem the routing algorithm of list of sites for visiting which is easy to implement and use. Another possible routing algorithm to implement is the RAMA's routing mechanism, the virtual bi-directional ring.: agents migrate on a virtual network, built by the MASs, which facilitates the migration by building a ring topology and offrering a very simple primitive to migrate to the next noed in the ring. Routing is a delicate field because routhing algrithms must be choosen carefully, e.g. ring routing is a high level migration algorithm that only produce good performaces when the ring is "not to big".

Communication

One of the strategy used for program a system using agents paradigm is the algorithm divide and conker, i.e. the problem is divided to resolved easily. In this type of applications the communication mechanism offrered by the MAS is crucial and that is why MASs offre local, global and group communications.

ROS takes advantages of the instantaneous broadcast that offers the reactive approach to implement local communication. Global communication may be done migrating between the different sites or using the ROS service of remote event generation (in this case de communication in not synchronous). The means of communication of the reactive paradigm, the broadcast, is a transparent synchronous communication that allows agents to receive the same information at each instant.

Naming

Like the mechanism of localization of a MAS, the mechanism of naming is a very important part of a MAS because it allows to resolve many problems. The mechanism of localization is used to communicate agents that are physically in different machines. Once resolved this problem, it exists the problem of identifying if two or more equal agents are in the same machine such as the different clones used to resolve a problem. The only way to resolve this problem is to have a naming mechanism which assign unique names, for instance, a global naming mechanism or a naming mechanism in function of the machine name, user name and a count. Of course each mechanism has its advantages and disadvantages that may be read [20].

ROS naming mechanism provides locally unique identifiers for agents using a combination of the agent's creation name and a number assigned locally and arbitrary. The assignation of global identifiers requires a global name service which is a good option for local networks but not always for WAN networks.

Programming language

In order to create easily an agents, it is necessary a programming language adapted to the agent requirements, for exemple it must have some properties such as portability, robustness, and security. In adition the programming language has to make easily the programming of high level behaviors, and the programming of the interaction among agents (possibly in the same group). Java language provides without problem some of the requirements (it is a quite portable language) but there are others that are not offered at all and the programmer must implemente (high level behavior programming is difficult).

Agent programming languages is a field where researchers are working on(FIPA [21] tries to make a standard); many language has been proposed and some systems propose not only one language but a set of programming language so as to take the advantage of each one. ROS propose the utilisation of REJO language which is a merge of an object-oriented imperative language (Java) and a reactive synchronous language (Junior).

2. Architecture

ROS system is a research project with the goal of applying the RSM in the construction of a MAS. It is not intended to build a big system with the typical MAS services, instead we want to offer the tools to build one taking advantage of RSM properties: dynamic execution, broadcast events and semantics. Since the MAS architecture is similar to that of an Operating System, ROS was built as one. In particular it was built with the philosophie of micro-kernel; the micro-kernel implements the basic functions that agents require and offers the means to add new modules so as to increase its functionalities.

The ROS kernel is based in the Junior execution model which provides reactive instructions executed in a reactive machine. In other words ROS is a layer on top of a Junior reactive machine. ROS is formed by three modules:

• the module Engine Daemon that makes evolve the reactive machine (in other words it activates the reactive instructions),
• the module Migration Daemon that allows the arrive of remote REJOs (agents) in the system, and
• the Kernel that administrates the REJOs.

In order to facilitate the utilization of the system, three interfaces were built: the API_Kernel interface that describes the way of using the system (adding o removing REJOs), the MigrationSrv interface that offers the migration service and the Agent that defines a minimal set of methods which must have the REJOs to be executed.

This architecture can be improved either using other modules or adding agents to the system, like in RAMA, to do administration tasks, for instance, an agent may travel the topology to control its members or to create a members list of a group.

To finish this section, the figure 2 shows the different systems explained using two diagrams (layer diagrams) : one which shows its utilization by the programmer and another by the user.

3. Utilization

In oder to use the ROS system users have two options: 1) to follow the steps to run a Junior program or, 2) to execute the run script so as to launche all the required modules.

If the ROS system is executed using the steps of a Junior program one have to 1) create a Junior reactive machine, 2) create a Junior program, 3) load the Junior program in the reactive machine and 4) activate the reactive machine. Some examples that illustrates these steps may be found here.

If the ROS system is executed using the run script one have to 1) create one or more REJO agents, 2) compile the REJO agents with the REJO compiler, 3) launche ROS using the run script and 4) load REJO agents using the Rsh (Rsh is explained in section 4) or launching ROS with the name of the REJO to execute.

Run script

Using the run script is the easiest way to use ROS system because it creates the reactive machine for you and it uses the correct CLASSPATH to run programs. Run script accepts two modes to be launched: 1) one execute the script with a file name of a REJO and possibly the flag -n or 2) one types no file name and one or two flags. The flags processed are

Flag	Description
-k	executes only the kernel. If the migration service is not launched sucsessfuly this option does not make sens.
-g	executes the REJO graphical interface.
-gt	executes the REJO graphical interface and a Rsh in mode text.
-n str	puts the ROS name to string str.

If the run script is executed without flags it creates the ROS kernel and a Rsh in mode text. If one of the basic kernel modules (the kernel or the machine demon) can not be started, the system stops and returns an error code to the user. The only ROS service that does not stops the start up process is the migration module; in that case the kernel prints an error messages and launch the Rsh.

Finally, ROS may be started inside of other programs (Embedded Systems) without problem because its code is small and it does not impose any graphic interface; the option -k may be used in these cases.

4.Reactive Shell

The Reactive Shell (Rsh) was created with two goals: 1) make easier the execution of REJO programs and 2) have an interpreted language to take advantages of these kind of languages, i.e. to debug reactive programs and to execute quickly littly reactive programs (scripts) to test ideas. Rsh is similar in some aspects to Reactive Scripts [10] but in general they are differents: the set of reactive instructions is smaller in Rsh and mainly the execution model is different,.

The Rsh implements 3 types of commands: 1) reactive instructions translated in Junior instructions, 2) some file commands and 3) some control commands to interact with agents ans the system. When Rsh starts it prints a prompt and then waits for commands:

<RosName | path> command return
    output of the command or error message

where the string <RosName | Path> is the prompt. For example you can run a REJO programm called HelloWorld as follows

<Ros1 | ~> hello
hello world
<Ros1 | ~>

The figures 4 and 5 show a Rsh running in a terminal.

The following subsection present the list of commands implemented in Rsh as well as a little description.

Files commands

Command	Description
ls	List the files in the current directory.
cd	Change the current directory.
cat	Show the content of a file.

These instruction are atomic actions implemented with the file operations offered by Java (Readers, file Reader).

Reactive instructions

Rsh provides a set of reactive instructions for programming reactive behaviors. The reactive instructions are implemented by Junior reactive instructions and that is why they have the same semantics but a particular sintax described in the following table.

Instruction	Description
;	SINTAX    A ; B The instruction ";" executes in secuence the instructions A and B.
par	SINTAX    par{ A [|| B]+ } The instruction par executes in parallel the instructions A and B.
stop	The instruction stop stops the execution, for the current instant, of the branch where it is found.
gen	SINTAX    gen string_expression The instruction gen generates an event in the reactive machine using. The event is defined by the string expression and it can be expressed as constant ("cte") or a variable name.
wait	SINTAX    wait event_condition The instruction wait waits for an event condition. Event conditions are formed by one or more events (defined by a constant or a variable) related by the operators AND(&) and/or ,OR(|).
loop	SINTAX    loop  body The instruction loop g.
repeat	SINTAX    repeat  body The instruction repeat g.
if	SINTAX    if body_1 [else body_2 ] The instruction if g.
when	SINTAX    when event_condition body_1 [else body_2 ] The instruction when g.
until	SINTAX    until string_expression body_1 [ handler body_2 ] The instruction until g.
control	SINTAX    control string_expression body The instruction control g.
local	SINTAX    local string_expression  body The instruction local g.

Control commands

Command	Description
exit	Exit from the Rsh but the system runs yet.
logout	Kill all the rejos and finish the kernel execution.
ps	Show the rejos and reactive scripts running.

The convention to kill a REJO is to generate an event composed by the local name plus the suffix !kill.

Scripts

Rsh allows users to store commands in a file to execute them later, i.e. Rsh have the ability to execute reactive scripts. Reactive scripts must be saved in a file with the extention rs and they may be executed using the run script or a Rsh running in ROS. A little exemple of a Rsh reactive script is the following program:

wait "e";
ls

this program waits for an event "e" and then prints the list of files in the current directory.

5. Migration

ROS offers a few primitives to administrate agents; in particular ROS allows programmers to create, destroy and migrate agents. To create an agent you create a REJO agent. To destroy an agent (its reactive behavior) or migrate it one uses the communication mechanism offered by the RSM, events. To destroy an agent one uses the convention of generating an event composed by the local name plus the suffix !kill. To migrate an agent one use the convention of generating a valued event putting in the data field the target address. In fact the migration is started by the generation of two valued events which have as identifier the name of the Agent plus the string "!migra" and as data the machine address and a ROS identifier.

The general steps to migrate an agent are: 1) to stop the execution of an agent, 2) to remove the agent code from the machine, 3) to try to migrate the agent sending a copy of its data and code, and 4) according to the state of the migration the agents is loaded either in the local machine (if the migration fails) or in the remote machine (if the migration is succesful).
All this steps depende on the platform, for exemple to implement strong migration it is necessary to stop the agent and to get the value of CPU registers; to send a copy of an agent it is important to know which format is used and usually this depends on the network protocol used.

REJO/ROS migration mechanism is implemented as follows:

1. Stoping the agent execution: REJO agents stop its execution at the end of an instant in a natual way. Therefore the only problem that exists is to be able to remove the code from the machine to avoid its execution at the next instants.
2. Removing the agent from the machine. Junior provides a reactive instruction to remove a reactive program: the freezable instruction. The freezable instruction detects the presence of an event and if the event is present it extracts the reactive program from the machine and stores it in the machine enviroment, otherwise it continues its execution. The freezable instruction is used in conjuntion with the Program getFrozenInstruction(String); Junior method to obtain the frozen reactive instructions from the machine environment at the next instant.
   REJO agent structure contains a frezzable instruction to remove the reactive code from the reactive machine. The event used to remove the code is a string formed by the name of the agent plus the string "!migra".
3. Trying to migrate the agent: To migrate an agent ROS uses the RMI services, i.e. ROS sends a copy of the agent to the remote ROS using a Remote Method Invocation. The agent is sent as a parameter in the invocation of the remote methode int Agent(Agent ag); which is processed by the migration service (daemon migration).
4. Loading the agent in the machine: If the remote migration daemon accepts the execution of the agent, the daemon charges it in the remote ROS using the ROS API, in particular the int load(Agent); method is used. Otherwise the agent is reloaded in the local machine. To reload an agent in the local machine REJO uses the Run reactive instruction.

Another important aspect in the migration mechanism is the way of it is implemented in the RSM. The reactive instructions that implement the migration may be programmed in two ways: 1) they are added in the machine at run time (in a particular instant) or, 2) they are coded in the agent. In both cases the migration is started by the generation of an event because of freezable instruction. In the first case the migration takes two instants and it is less depended on the agent structure. In the second case the migration takes one instant and it is more depended on the agent structure.
REJO agents use the second implementation, i.e. they contain the migration code in the REJO strucuture.

The figure 6 shows the sequence of steps done by the reactive code to migrate an agent.

6.ROS API

ROS uses three interfaces to define the interaction with agents (Agent interface), with the ROS kernel (API_Kernel) and Migration service (MigrationSrv), their descriptions follow:

Agent

This interface allows programmers, and in particular ROS system, to interact with agents. Although there are several methods defined in this interface, the programmer usually use only two:

Program rmain(String[] args);
public String   locName();

When the ROS system loads a REJO, it must know which method will be executed in the first place. The rmain method is the only agent method executed by ROS and thus it must generate the reactive instructions (Junior instructions) to be executed. The locName method returns the agent local name.

The others methods are used by specialized programs which manipulate the execution of agents i.e. the reactive shell and the migration service. Most specialized methods and variables contained in an agent are stored in the AgentData class. All agents has an object of this type and the interface offers twho methods to read and write this object. Similarly there is an API_kernel varibale that allows.

public void setRos(API_kernel Ros);
public API_kernel getRos();


public AgentData getDataAg();
public void setDataAg(AgentData da);

API_Kernel

This interface get access to the ROS System Calls. ROS system offers 3 type of services: load/unload agents and reactive instructions, generate events and, get information about machine and agents. These methods may be used by the agents, however they are usually used by the applications that react directly with the kernel (such as the reactive shell), in particular when an application must generate an external event.

void load(Agent ro);

MigrationSrv

int lAgent(Agent ag);

7. Conclusions and future work

The main characteristics of the ROS system are :

• Concurrency: Agents run concurrently thanks to the Junior Par reactive instrucion that does not use Java threads. Agents are programmed in a cooperative style.
• Interactivity: Agent behaviors may interact using events and reactive instructions that allows programmers to describe high level behaviors.
• Reactivity: Agent's behaviors are reactive because of the use of reactive instruction, i.e. reactive instructions are triggered by the presence of events.
• Mobility: Agents can migrate using the ROS migration service. Migration is strong and agents may decide if they migrate or not, i.e. they may be autonomous agents.
• Dynamicity: There are three types of dinamicity: 1) agents may be charged and removed from the ROS system, 2) agent behavior may be modified and 3) the topology f the network formed among ROS systems may be modified at run time.
• Multi-platform: Thanks to the portability of Java, agents may be run and migrate in ROS systems that run on a large variety of operating systems and machines.

ROS system may be improved in the following aspects:

• Adding the property of persistence to the agents. This property allows to restart the execution of an agent in some points of its execution, in presence of fails. Thanks of freezing mechanism of reactive instructions, this property may be added naturally.
• Adding to ROS the possibility of synchronized with other ROS sites. This property is easy to implement: one just change the Engine Daemon module which does evolve the machine and to implement the two phase commit protocol. The concept of distributed reactive machines that share the same instants is not new but this allow to continue it in the framework of mobile agents in order to make the synchronous migration.
• Creating automatically the automate equivalent to the reactive part of a REJO program. This automate would allow to check and to validate properties of agents before to be loaded, i.e. to make a kind of QoS (Quality of Service).
• Adding other properties to ROS such as security (to protect the agents from the system or other agents) or the communication (do the inter-group communication).