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.


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.


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".


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.


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 REJOs are administered by a table and an unique local identifier that provides a local naming. This identifier is the equivalent of the UNIX PID (Process Id).

Figure 1 ROS Architecture.

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.

Figure 2 Layer models of the systems.

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

executes only the kernel. If the migration service is not launched sucsessfuly this option does not make sens.
executes the REJO graphical interface.
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.

Figure 3 Starting of ROS system.

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.

Figure 4 The ROS shell.

Figure 5 The ROS shell (continuation).

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

Files commands

  List the files in the current directory.
  Change the current directory.
  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.


   A ; B

The instruction ";" executes in secuence the instructions A and B.


   par{ A [|| B]+ }

The instruction par executes in parallel the instructions A and B.

The instruction stop stops the execution, for the current instant, of the branch where it is found.

   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 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  body

The instruction loop g.


   repeat  body

The instruction repeat g.


   if body_1 [else body_2 ]

The instruction if g.


   when event_condition body_1 [else body_2 ]

The instruction when g.


   until string_expression body_1 [ handler body_2 ]

The instruction until g.


   control string_expression body

The instruction control g.


   local string_expression  body

The instruction local g.


Control commands

  Exit from the Rsh but the system runs yet.
  Kill all the rejos and finish the kernel execution.
  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.


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";

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.

Figure 6 Sequence of stages of the migration.



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:


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:

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.


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);

This method load a REJO in the system. The unique condition to load it is that it has the rmain method. This method is used to load the REJOs that arrive from the reactive shell or from another machine (migration). There are two more methods to load an agent specifying the standar output device and/or passing some environment string variables. Thet are:          int load(Agent ro, Output o);          int load(Agent ro, String[] args, Output o); void loadInst(Program i); This method allows to add reactive instructions without the REJO structure, for example, in order to implement a programmable shell as the Reactive Scripts, or simply in order to add instructions that allow to tests the REJOs. void unLoad(Agent ro); This method removes an agent from the system. For removing the agent the system generates the kill event and then removes it from the REJO table. Instruction unLoad(String name); This method allow to remove a frozen reactive program. Name is the name of the event used to freez the instructions. void generate(String name); This method generates an event in the system. This is syntactic facility because the ROS API also implements the machine interface. void generate(String name, Object); This method generates a valued event in the system. int getInstant(); This method returns the number of instants elapsed in the reactive machine. Hashtable getTable(); This method allow to know the REJOs of the system. For security reasons, the method returns a table's copy; this copy is only valid after the invocation.


int lAgent(Agent ag);

This method is invoked by the Send_REJO method that sends a copy of the agent to a remote site. The sent agent must have the signature specified by the Agent interface.

7. Conclusions and future work

The main characteristics of the ROS system are :

ROS system may be improved in the following aspects:

This work was supported by INRIA and CONACYT.
Last updated: January 2002.