The AmbIcobjs Demo
Ambient Programming in Icobjs



Recommendation: This page is better viewed with Mozilla (you may also try Netscape or IE with an up-to-date Java plugin). Otherwise you might prefer to download the .jar archive and use it as a stand-alone application.

What, Where and Why ?

This page describes the work done by Damien Pous (http://www.ens-lyon.fr/~dpous/), from ENS Lyon, France, during a summer internship in our project (see [1]). The aim was to use the Icobjs programming platform developped here to design a new and graphical implementation for the ambient calculus.

Reactive programming (see [2]) is a method of distributed programming, based on immediate broadcasting of messages: time is sliced into instants during which messages can be generated and detected by different processes interacting in parallel. There is also a dynamical aspect: processes can be added or withdrawn from the system (quite) at any time.

Icobjs are created by associating a graphical icon to a behaviour (that is a reactive program). Placed together (in parallel) in a reactive machine, they interact while being displayed at each instant in a window. Examples of possible classical behaviour are: inertia, collision, gravitation, prey-predator...

Ambient calculus (see [3]) is a form of notation devised by Luca Cardelli and Andy Gordon and used to describe and theorise about mobile systems. It is useful to model interactions in such systems as the Internet. The ambient model is elegant and powerful. The three basic ambient primitives, namely in, out, and open are expressive enough to simulate name-passing channels in the pi-calculus. As a theoretical model, it is very interesting to explore the various properties behind this small calculus. During the years, many variants and dialects have been proposed: the original mobile ambients (see[4]), safe ambients (see [5]), robust ambients (see [6]) and controlled ambients (see [7]).


Implementing the Calculus

Some implementations had been proposed in the past, but they were all textual only and were suffering from a complex and costly mechanism of lock acquiring and releasing, with difficult theoretical problems to ensure that no deadlock could occur.

The current challenge was to design a completely graphical implementation where one could "see" the boundaries of an ambient. Moreover, we wanted to benefit from the reactive approach and the natural "atomicity" of operations induced by the physical simulation to get rid of these locking problems. The result is a Java program and applet which is able to "physically" simulate any ambient expression in any of the four dialects mentioned above, and see them evolve on the screen.

To get to some more concrete stuff, here is for example how the process a[ b[] | in c ] is graphically represented:



Each ambient is represented by a named and colored circle, whose size depends on its contents, and whose limits act as real boundaries for what is inside. The capability in c consists of different parts: an anchor which remains in the ambient, an arrow outside which is physically attracted by any ambient with name c, and an elastic linking both parts. When the arrow finds an ambient c, it locks and the elastic shrinks until both ambients a and c get in contact. Then, ambient a is entirely moved inside c.
A capability out c behaves quite the same way, except that the head searches for a surrounding ambient.
A capability open c is represented as a small square trying to find an ambient of the same name. If it does, the boundaries are dissolved and consequently the contents of that ambient are released.

This is the way mobile ambients react. Concerning the other models with co-capabilities (especially safe ambients), the co-capabilities are represented by "doors" moving around the boundaries of the ambient, which attract the corresponding capabilities.

(Note that any icobj can be moved by dragging it with the left mouse-button.)


First Example: Taxis

This example models a city with different sites, cabs and clients willing to go from one site to another. The complete protocol was presented in [7]. This demo is first initialized with three different sites a, b and c, two cabs available in the city, and three clients willing to go repeatedly back and forth from a to b, a to c, and b to c respectively. You can add more clients or cabs by left-clicking on the corresponding constructors on the left.



Click here to start the demo


Another Example: Encoding Pi-Calculus in Pure Safe Ambients

This example comes from [8], where the encoding is extensively developped. In this demo, you can create channels of name n, outputs and inputs on these channels, and even more complex recursive pi-processes. The corresponding translation in pure ambients is then released and you can let the system evolve.



Click here to start the demo


General Ambient Factory

This applet provides general constructors for four different dialects of ambients: mobile ambients, safe ambients, robust ambients and controlled ambients. Left-clicking on the hand pops up a window asking for an ambient term. A second window asks for a name for the constructor. If the term is valid, a new constructor is created, and by left-clicking on it, we can launch the corresponding ambient as many times as we want.

Below are a few examples to familiarize with the syntax. The best way is to start the applet (it will start in another window) and simply perform copy-and-paste between the examples and the applet.



Click here to start the demo (in another window)


Syntax

In any of the 4 models, ambients are written a[...], the parallel composition is written |, creating a new name n is written nu n, recursion is rec X, sleep n waits for n 10th of seconds and the dot . separates sequences of instructions. Concerning capabilities, they depend on the model you use:
As a first example, simply start the following two (mobile ambients) expressions in different corners and see how they react:

a[in b.sleep 100.out b]                  b[]

Then, try to release many copies of the same processes at the same time. See how capabilities are attracted by different ambients concurrently and how the first ambient encountered wins (this, combined with the randomness of shocks between ambients and walls, provides the non-determinism of the system). Finally, try to release processes open a or open b.

Another example to see recursion in action; an infinite number of ambients named x are released:
 
x[rec X.x[out x.X]]

The following process creates a new private name n (which should appear in the form "n#10"), creates some intricate ambients named n and an ambient a which has the capabilities to enter or exit n at any time. Theoretically, you should see the ambient a moving around inside and outside any combination of n, and thus indefinitely.

nu n.(a[rec X.in n.sleep 10.X | rec X.out n.sleep 10.X] | n[n[] | n[]] | n[n[n[]] | n[]])


This time in safe ambients, in the following process, b gets out of a, a gets in b and finally a is opened (in fact, this is how one would encode a renaming operation):

a[ sleep 50.out_ a.in b.open_ a | b[ out a.in_ b.open a] ]

And a last example (always in safe ambients), to test the robustness of the implementation:

  x[ rec X.out_ x.X | rec X.in_ x.X
   | rec Z.sleep 10.open n.( n[out x.in y.open_ n]
                           | n[out x.in y.open_ n]
                           | Z)]
| y[ rec X.out_ y.X | rec X.in_ y.X
   | rec Z.sleep 10.open n.( n[out y.in x.open_ n]
                           | n[out y.in x.open_ n]
                           | Z)]
| n[in x.open_ n]
Two ambients x and y contain the same program: each time they encounter an ambient n, they open it, replace it with two fresh ambients n and send them to the other one. An initial n starts the process. The result is that x and y start exchanging an increasing number of ambients n.

Here is what you may get after a few hours... ;-)




And now ?

Now it is your turn to play and invent new systems... Be creative ! ;-)


Download Area

ambicobj.jar (1056k)

This file contains all the necessary Java classes to use the demo either as a stand-alone application or as an applet. To launch it alone, use the command: "java -jar ambicobj.jar [demo]"
where demo can be any of the following:

References:

[1] Damien Pous, Les Mobile Ambients en Icobj, internship report (in French)
[2] Reactive Programming and Icobjs, web page.
[3] Ambient Calculus, web page.
[4] Luca Cardelli and Andy Gordon, Mobile Ambients, FOSSACS 1998, European Joint Conference on Theoretical Aspects of Computer Science (1998).
[5] Francesca Levi and Davide Sangiorgi, Controlling Interference in Ambients, Symposium on Principles of Programming Languages (2000).
[6] Xudong Guan, Yiling Yang and Jinyuan You, Making Ambients more Robust, International Conference on Software: Theory and Practice (2000).
[7] David Teller, Pascal Zimmer and Daniel Hirschkoff,Using Ambients to Control Resources, CONCUR 2002, 19th International Conference on Concurrency Theory (2002).
[8] Pascal Zimmer, On the Expressiveness of Pure Mobile Ambients, EXPRESS'00, the 7th International Workshop on Expressiveness in Concurrency, part of CONCUR 2000.

Pascal Zimmer, October 2nd, 2002