Mobile Computational Ambients
Ambit

Mobility

There are two distinct areas of work in mobility: mobile computing, concerning computation that is carried out in mobile devices (laptops, personal digital assistants, etc.), and mobile computation, concerning mobile code that moves between devices (applets, agents, etc.). We aim to describe all these aspects of mobility within a single framework that encompasses mobile agents, the ambients where agents interact and the mobility of the ambients themselves.

The inspiration for this work comes from the potential for mobile computation over the World-Wide Web. The geographic distribution of the Web naturally calls for mobility of computation, as a way of flexibly managing latency and bandwidth. Because of recent advances in networking and language technology, the basic tenets of mobile computation are now technologically realizable. The high-level software architecture potential, however, is still largely unexplored.

Administrative Domains

The main difficulty with mobile computation on the Web is not in mobility per se, but in the handling of administrative domains. In the early days of the Internet one could rely on a flat name space given by IP addresses; knowing the IP address of a computer would very likely allow one to talk to that computer in some way. This is no longer the case: firewalls partition the Internet into administrative domains that are isolated from each other except for rigidly controlled pathways. System administrators enforce policies about what can move through firewalls and how.

Mobility requires more than the traditional notion of authorization to run or to access information in certain domains: it involves the authorization to enter or exit certain domains. In particular, as far as mobile computation is concerned, it is not realistic to imagine that an agent can migrate from any point A to any point B on the Internet. Rather an agent must first exit its administrative domain (obtaining permission to do so), enter someone else's administrative domain (again, obtaining permission to do so) and then enter a protected area of some machine where it is allowed to run (after obtaining permission to do so).

Access to information is controlled at many levels, thus multiple levels of authorization may be involved. Among these levels we have: local computer, local area network, regional area network, wide-area intranet and internet. Mobile programs must be equipped to navigate this hierarchy of administrative domain, at every step obtaining authorization to move further. Laptops must be authorized to access resources depending on their location in the administrative hierarchy. Therefore, at the most fundamental level we need to capture notions of locations, of mobility and of authorization to move.

Ambients

Today, it is very difficult to transport a working environment between two computers, for example, between a laptop and a desktop, or between home and work computers. The working environment might consist of data that has to be copied and of running programs in various stages of active or suspended communication with the network that have to be shut down and restarted. Why can't we just say "move this (part of the) environment to that computer" and carry on? When on a trip, why couldn't we transfer a piece of the desktop environment (for example, a forgotten open document along with its editor) to the laptop over a phone line? We would like to discover techniques to achieve all this easily and reliably.

With these motivations, we adopt a paradigm of mobility where computational ambients are hierarchically structured, where agents are confined to ambients and where ambient move under the control of agents. A novelty of this approach is in allowing the movement of self-contained nested environments that include data and live computation, as opposed to the more common techniques that move single agents or individual objects. Our goal is to make mobile computation scale-up to widely distributed, intermittently connected and well administered computational environments.

Ambient Calculus (Joint work with Andrew D. Gordon)

Encyclopedia entry.

An ambient, in the sense in which we are going to use this word, has the following main characteristics:

An ambient is a bounded placed where computation happens. The interesting property here is the existence of a boundary around an ambient. If we want to move computations easily we must be able to determine what should move; a boundary determines what is inside and what is outside an ambient. Examples of ambients, in this sense, are: a web page (bounded by a file), a virtual address space (bounded by an addressing range), a Unix file system (bounded within a physical volume), a single data object (bounded by "self") and a laptop (bounded by its case and data ports). Non-examples are: threads (the boundary of what is "reachable" is difficult to determine) and logically related collections of objects. We can already see that a boundary implies some flexible addressing scheme that can denote entities across the boundary; examples are symbolic links, Uniform Resource Locators and Remote Procedure Call proxies. Flexible addressing is what enables, or at least facilitates, mobility. It is also, of course, a cause of problems when the links are "broken".

An ambient is something that can be nested within other ambients. As we discussed, administrative domains are (often) organized hierarchically. If we want to move a running application from work to home, the application must be removed from an enclosing (work) ambient and inserted in a different enclosing (home) ambient. A laptop may need a removal pass to leave a workplace, and a government pass to leave or enter a country.

An ambient is something that can be moved as a whole. If we reconnect a laptop to a different network, all the address spaces and file systems within it move accordingly and automatically. If we move an agent from one computer to another, its local data should move accordingly and automatically.

More precisely, we investigate ambients that have the following structure:

  • Each ambient has a name. The name of an ambient is used to control access (entry, exit, communication, etc.). In a realistic situation the true name of an ambient would be guarded very closely, and only specific capabilities would be handed out about how to use the name. In our examples we are usually more liberal in the handling of names, for sake of simplicity.
  • Each ambient has a collection of local agents (a.k.a. threads, processes, etc.). These are the computations that run directly within the ambient and, in a sense, control the ambient. For example, they can instruct the ambient to move.
  • Each ambient has a collection of subambients. Each subambient has its own name, agents, subambients, etc.

In all of this, names are extremely important. A name is:

  • something that can be created, passed around and used to name new ambients.
  • something from which capabilities can be extracted.

Ambient Primitives

The following figures illustrate the essential Ambient Calculus primitives, depicted as operations on "active folders". Active folders may contain nested active folders as well as local "gremlins" (script lines) that instruct folders how to behave. When properly interpreted, these pictures describe the formal semantics of an ambient calculus. The green arrows are state transitions; operations may fire whenever their premises are satisfied, otherwise they remain in a blocked state.

  • Basic operations on active folders. (Together with name-creation, these operations are Turing-complete!)

  • Communication operations, modeled after Post-It notes stuck inside folders. (Together with the above operations and scoping restriction, these can represent standard process calculi.)

Papers
 

Software

Etymology

Ambit comes from the Latin word ambire (ambi-ire, "to go around"). The root ambi has the meanings of "around", "on both sides", and "from side to side"; it is used in the sense of both movement and confinement. From that root we have also:

    Ambient: Something confined by a perimeter.
    (Confinement is indicated by the arcs in the logo.)
    Ambulant: Something that moves from place to place.
    (Movement is indicated by the arrow in the logo.)
    Ambitious: Somebody who gets around.
    (Ambition is indicated by the fact that there is a logo.)

References

Bibliography

  • CUI's Pages on Mobile Object Systems (http://cuiwww.unige.ch/OSG/OSG/Lobby/Languages/Agents.html)

  • Aline Baggio's Bibliography on Mobile Computing (http://www-sor.inria.fr/~aline/mobile/biblio.html)

  • Jeremy Hylton's Mobile Code Bibliography