Mobile networks composed of devices interconnected by wireless communication media frequently suffer from partitions. If mobile devices depend on software services running on remote devices, such partitions may render the software services unavailable. We propose the use of code mobility to mitigate the unavailability of software services in mobile networks. We discuss the issues of existing mobility mechanisms, identify four characteristics necessary to support code mobility in mobile networks, and propose a model for code mobility, the Message-Oriented Mobility (MOM) model, that features such characteristics.
Currently, wireless technology is revolutionising the way software systems serve their users. New visions of computing can be realised where users are continually surrounded with mobile and embedded computing devices. Whereas these scenarios are becoming ever more realistic from a technical point of view, programming such devices remains notoriously difficult due to the limited resources and volatile connections these devices can sustain between each other. Mobile networks composed of such devices frequently suffer from partitions due to the combination of the volatile connections and the physical mobility. If the mobile device depends on software services running on remote devices, such partitions result in those services becoming unavailable.
In this work, we explore the use of code mobility to circumvent the problem
of service unavailability due to network partitions in mobile networks. Software
services provided with the capacity of migrating from one device to another are
less dependent on individual devices - services are not constrained to always run
on the same device - and are consequently less vulnerable to the effects of network
partitions on the availability of these devices . A mobile service can, for instance,
follow its user hopping from one device to another as the user moves about and uses
In the field of programming language research, proactive code mobility schemes
have been traditionally associated with a move instruction that expects e.g. an object
and a location, and which pushes the object towards that location [20, 25]. We argue
in this work that this instruction has the same implications as the goto instruction
in the sixties. We present a list of arguments against move that stem from software
engineering and security concerns, and formulate the need for a more structured
mobility mechanism in order for programmers to be able to track the location of
To achieve proactive mobility of running services in mobile networks, this paper proposes an object-oriented programming language model called the messageoriented mobility (MOM) model. The contributions of this work are threefold:
The paper is structured as follows. Section 2 identifies the requirements of proactive mobility models for mobile networks and the issues of existing code mobility models in this context. Section 3 describes the different components of the messageoriented mobility model. Section 4 evaluates our mobility model with respect to the requirements identified in this paper. Section 5 validates this model by presenting a high level mobility pattern for follow-me services. Before concluding, we describe related work in section 6.
2 MOVING SERVICES IN MOBILE NETWORKS
In this section, we identify the requirements of proactive code mobility models for mobile networks and discuss the issues of existing code mobility models in this context.
Requirement #1: Strong Mobility
As explained in the introduction, we require a service to be moved in order to fully preserve its availability. Moving a running service is a decision that not only concerns the data of the service program, i.e. behaviour and data state, but also the computations in which the running program is involved at the time of the move. This "runtime" state is typically a combination of a heap of data objects and a stack of activation records which traces the service's control flow and represents all unfinished computations. Both have to be moved if the runtime state of the program is to be transferred intact. The type of mobility where data and computations are moved between devices is known as strong mobility .
In the literature, a lot of mobility schemes are described where only data is moved . There are multiple reasons for this choice: the runtime stack of a service is usually not reified in the language, it is not serialisable, and it is tightly bound to the execution platform. These limitations lead to so-called semi-strong mobility schemes requiring programmers to manually encode the runtime state of a service as data upon migration, and to decode this data via a number of branching instructions after migration to get back into the correct computational context where the program was before migration. A semi-strong mobility scheme requires programmers to foresee all possible ways in which a service can be moved. As there is no mechanism which can transparently take care of migrating the service at any point, at any time, all possible states in which a service can be moved have to be statically determined. From a user's point of view, this means that he cannot always move a service from one device to another. However, the effect that we want to achieve is that a service can be migrated as unrestrained as possible e.g. it can be hibernated when placing a device in sleep mode. Thus, we claim there is a need for a strong mobility mechanism that migrates both data and computation and which circumvents the problems of manually serialising the runtime stack of a program.
Requirement #2: Decentralised Network Reconfiguration
Deciding how and what part of the service should migrate from one device to another is not the only issue programmers need to tackle when implementing code mobility. The change of location of the moved service may lead to inconsistencies in the communication between this service and the rest of the services over the network, e.g. references pointing to the old location of the moved service. Early code mobility approaches, mostly developed for load-balancing purposes , avoided this problem by collocating the services that communicate often (services were moved together with all the software resources they needed to operate properly). This technique is no longer applicable, however, because some services cannot, and in some cases should not, be moved, e.g. fixed hardware resources such as screens and speakers, or software containing confidential information such as address books or personal agendas.
In the context of mobile networks, we require an extra step of network reconfiguration in the move process that ensures correct communication with the mobile service at any moment of the move. Such reconfiguration mechanism should be reliable even in the presence of network partitions, which also rules out message forwarding schemes and global reconfiguration strategies (realised by central servers ). In mobile networks, a device cannot rely on another one playing the role of higher authority since there is no certainty that connection with such an authority will continue to be available in the location where the interaction happens. We require a decentralised reconfiguration mechanism similar to the techniques used in peer-to-peer architectures [19, 17].
Requirement #3: Structured Mobility
It is common practice to incorporate mobility in a programming language by explicitly introducing the concept of location and by complementing it with a simple move instruction [8, 20]. We only partially agree with that. Surely, mobile programs are written with the explicit assumption in mind that parts of the program will reside on and move between different locations. However, this does not imply that mobile programming languages should explicitly model the concept of a location. Dealing with absolute locations seems like an unattainable language design choice when one has to deal with mobile networks which are inherently dynamically defined. A more fundamental problem with the move operator is that it bypasses the language's interaction mechanisms (such as message passing, function calling and process spawning) and moves a running process or object to a specified destination device. We argue that such an operator is suspiciously comparable to the goto operator and may be one of the major obstacles for code mobility to be lifted from a technical programming trick to solid engineering levels.
Similar to the goto instruction, a move instruction has a strong tendency to obscure the actual locations of objects. Especially since distributed programs have a vast arsenal of object-oriented programming techniques such as regular control flow instructions (such as while or for), late bound message passing, double dispatch, meta programming and exception handling at their disposal. With only a few lines of code that use this construct, networked object-soups can be created the structure of which cannot be predicted or understood by programmers. Analogous to the case of structured programming, we claim there is a need for structured mobility, i.e., language mechanisms that can help programmers to determine the relative loci of objects by reading the code.
Requirement #4: Secure Mobility
The migration of a service may entail a number of security issues at the devices involved in the move process, i.e. the current and new hosting devices of the mobile service. The migration of a local service without the acknowledgement of the current hosting device (e.g. system's or user's permission) may affect its proper functioning and cause privacy problems (e.g. when moving a database containing confidential information). This is what occurs in mobile agent technologies. In such approaches, agents can autonomously move to new devices (using a move instruction). This property is identified as a security hazard by Vigna and Thorn [20, 25] who state that mobile agents are suspiciously similar to worms that once launched they can be hard or impossible to control.
The arrival of the service to the new hosting device may also produce security issues which are mainly related to resource rebinding. In traditional process migration mechanisms, security problems are mitigated because there is little or no resource rebinding . However, when a mobile service needs access to local file systems, windowing systems, networking interfaces and so on, security problems arise. In order to protect the resources of the devices in mobile networks, we require a mobility mechanism that enables them to autonomously decide what to expose to the moved service. As previously explained in this section, this decision cannot rely on a central server due to the connection volatility that exists between the server and the mobile devices.
We argue that a secure mobility mechanism should be conceived as a two-party contract between the devices involved in the move process, more specifically, the service that is going to be moved and another residing on the device receiving the moving service. Thus, services are neither pulled unilaterally by remote hosts nor pushed unilaterally to a remote host.
In this section, we present a number of requirements to support code mobility in mobile networks. We summarise these criteria as follows:
Strong mobility To preserve service availability, we require a mechanism of strong code mobility that consistently moves both the behaviour and the runtime state of a service without putting extra burden on programmers.
Decentralised network reconfiguration We need a decentralised network reconfiguration mechanism that automatically updates the references to the moved service over the network, and which is resilient to network partitions.
Structured mobility We require a code mobility mechanism that enables programmers to write structured mobile programs and to predict the relative loci of objects by reading the code.
Secure mobility Security should be conceived as a two-party contract between the services involved in the move process. Services should neither be pulled unilaterally by remote hosts nor be pushed unilaterally to a remote host.
While some of the criteria explained above can be observed in other mobility schemes or distributed languages, to the best of our knowledge no single approach exhibits all of them. We further discuss the related work in Section 4.
3 THE MESSAGE-ORIENTED MOBILITY (MOM) MODEL
To address the requirements discussed in the previous section, we introduce the MOM model for code mobility in mobile networks. It extends the actor model  of concurrency and distribution with the notion of move methods which enables programmers to work with strong code mobility in a structured and secure manner. In this section, we describe the three constituent parts of the MOM model: move methods, strong mobility of actors, and decentralised network reconfiguration.
In what follows, we employ an actor language, called AmbientTalk, to illustrate the use of the MOM model. AmbientTalk provides dedicated features for the software development of mobile services, some of which we have used to implement our code mobility model. For the sake of conciseness, we do not present an in-depth discussion of AmbientTalk itself. Instead, we introduce specific features as necessary in the course of this section and refer the reader to dedicated publications [5, 6] for more information about this language.
In the MOM model, services are represented as actors which are also the units of mobility. An actor can declare that it is allowed to be moved by other actors by implementing a new kind of method called a move method. An actor on a remote device can declare that it is willing to receive a mobile actor by sending it a move message, which is any message corresponding to one of the mobile actor's move methods. Upon processing this message, the mobile actor is moved from its current location to the location of the sending actor. In other words, the sender pulls the receiver actor towards its own location.
The following code sample sketches the definition of a mobile game application implemented as an actor in AmbientTalk (see more details of this implementation in Section 5):
AmbientTalk actors (declared using the actor construct) consist of a number of fields and methods which are referred to as the actor's behaviour. As shown in the example above, fields are defined using a name : value syntax while methods are defined using a name(parameters) :: body syntax. Move methods are distinguished from ordinary methods by a move keyword that is prefixed before the method name. In the example, come is a move method. An actor may implement multiple move methods, each with their own distinct name.
The variables of an actor may refer to two kinds of values: regular objects or other actors. When an actor is moved, all regular objects are moved along (i.e. they are transferred by-copy). However, variables that referred to actors at the old location will become remote references at the new location. In other words, acquaintance actors are transferred by-reference.
When one of an actor's move methods is invoked, before executing the body of the move method, the actor is first moved to the location of the object that invoked the method. Only upon arrival at that location is the body of the move method executed. Hence, the body of a move method serves to do "post-move processing". This enables the moved actor, for instance, to rebind services that were left behind at its old host to equivalent services at its new host or to pull acquaintance actors from its old location to its new location. Note that such service rebinding is performed through parameter passing: the actor initiating the move, e.g. the sender of the come message, explicitly passes all (references to) services it wants to share with the moving actor as arguments to the move method, e.g. a guiActor service, and the moved actor receives these parameters once it arrives. In the body of the move method, the moved actor can then choose whether to keep referring to the original service at its old location or to rebind the variable to point to the local service passed to it.
A final aspect of the semantics of move methods is that, when the actor to move is already colocated with the sender actor, the body of the move method is not executed (i.e. the request to move is ignored). Because the actor does not need to be moved, it is not necessary to do any post-move processing.
Strong Mobility of Actors
The MOM model provides a strong code mobility mechanism that moves the data
and computation of a running service without suffering from the problems described
in Section 2 raised by having an implicit runtime stack. We benefit from the eventdriven
nature of actors for this purpose. Actors are structured around an event
loop which responds to incoming events - modelled as messages - and handles one
message at a time by dispatching to the appropriate event handler (method). Parts
of an actor which have to be performed "in the future" are not stored in an implicit
The implementation of strong mobility for actors consists of moving the actor
from one device to another while taking along all messages already sent to it but not
yet processed by it (i.e its queue). Such messages represent the future computational
context of the moving actor, so it is imperative that they are taken along. If this
would not be the case, the actor would lose some of its computational context upon
arrival, resulting in mere semi-strong mobility. Messages sent to an actor while it
is moving should be properly received by that actor. This is made possible because
The semantics of invoking a move method can be described as follows. When
the next message from an actor's message queue is processed, method lookup is first
performed in order to find a method corresponding to the message. If the method
found is a move method, the implementation checks whether the actor that sent the
message is already collocated with the receiver. If this is the case, the message is
further ignored. Otherwise, the move process is initiated and the receiver actor is
moved to the location of the sender. Upon arrival, the method body is executed,
The move process consists of three steps which happen transparently from the point of view of the programmer. This process requires the active participation of the initial host of the mobile actor and the pulling host from which the move message is sent (see the top left quarter of Figure 1). The three steps of the move process are described in detail below:
Figure 1: The move process of an actor.
Decentralised Network Reconfiguration
The move process explained above requires a final network reconfiguration step to ensure proper functioning of the system once the actor has moved. It is a decentralised mechanism that performs a transparent update of references to the moved actor. Three different cases requiring network reconfiguration have to be considered after movement (see Figure 2):
Figure 2: Decentralised network reconfiguration.
Note that in the third case, the reconfiguration mechanism requires the active collaboration of the initial host, which is responsible for updating remote references that previously referred to the moving actor. As explained in the introduction, such collaboration is not always possible in a mobile network, as this device may become unavailable due to a network partition. In order to cope with this problem, we use special remote references found in AmbientTalk called ambient references which, when broken, enter a search mode to rediscover the moved actor via multicasting. For more information about these references, we refer to .
We now evaluate the MOM model in the light of the four criteria for code mobility in mobile networks identified in Section 2.
Strong Mobility The MOM model provides a strong mobility mechanism for actors. This mechanism enables an actor to gradually move (first its behaviour and then its runtime state which is reified as a message queue) while ensuring the availability of its services for other actors over the network. During the move process, none of its incoming messages are lost, such that the actor retains its full computational context upon arrival. It is important to recall from Section 1 that we focus on proactive mobility, i.e. the actor is moved when the connection between its old and new locations is still available. The MOM model does not explicitly deal with disconnection during the move process.
Decentralised network reconfiguration The MOM model proposes a reconfiguration mechanism that prevents the references over the network to the mobile actor from being affected by the move process. The references at the initial and pulling hosts are automatically updated during the move process whereas the references at third-party devices are updated by the initial host via message. In case of disconnection of the initial host upon message reception, the references at the third-party device search for the moved actor via multicasting.
Structured mobility The MOM model presents move methods that cleanly align mobility with the language default interaction mechanism of actors (message sending protocol). As result of the execution of a move method, the actor is collocated with the message sender which means that there is no need to explicit refer to any location. Secure mobility The security issues regarding mobility (at the language-level) are taken care of because move methods enforce a two-party contract: an actor can only be moved if it is implementing a move method and if an actor on a remote host is willing to send a corresponding move message. Moreover, involving the actor located at the destination host in the move process mitigates some of the security problems concerning resource rebinding, since it is this actor that decides on which resources to share with the moved actor. Furthermore, message-oriented mobility only supports pull mobility in which the actor is collocated with the sender actor, which prevents actors to move unexpectedly to other devices. Of course, this language-level security policy can only be enforced when assuming that the language's virtual machine is part of the trusted computing base, i.e. we assume that the VM hosting the actor to move and the VM hosting the actor that requested the move can be trusted.
5 THE FOLLOW-ME PATTERN
To further illustrate the MOM model, we describe how follow-me services can be conceived using this model. We show a mobility pattern where services can be grouped into sessions and where these sessions can be moved towards the user.
As mentioned in the introduction, the main idea of follow-me services is to provide the user with services that "follow" him, hopping from one device to another, adapting themselves to the different contexts found at the places where the user moves. A simple implementation of such a scenario would enable the user to move his services manually between devices, for instance from a fixed workstation to his mobile device (like a PDA). Services can be grouped into sessions, and when a session is moved towards the user, all session services follow.
The MOM model allows the user to logically pull his services from e.g. the workstation to the PDA. We implement a framework for follow-me services using actors. The implementation of the follow-me pattern considers three types of actors: system actors which represent the devices and can discover remote sessions and pull them towards the user, mobile session actors which group services into a single mobile session and mobile service actors which represent any kind of mobile service. Figure 3 shows a sequence diagram of the (purely asynchronous) collaboration between these actors. Dotted arrows represent the movement of an actor to the location of the sender actor. The behaviour of each of the collaborators is described in detail below.
Figure 3: Sequence diagram of the Follow-Me pattern using the MOM model.
A system actor is responsible for finding remote mobile sessions and moving them to its device. This actor encapsulates any local services which the user wants to share with any mobile session pulled towards the device. Mobile sessions are found using a pattern-based discovery mechanism of AmbientTalk which requires that the session actors provide an identification which is broadcast to the network . Once the mobile session with the right identification is discovered, it is pulled towards the system actor when this actor sends it the move message followMe. The following code listing shows the behaviour of the system actor:
The system actor sends an asynchronous followMe message to the session (the # symbol denotes asynchronous message sending in AmbientTalk). The services object is the only reference a mobile session receives when it is asked to move by the system actor. These services are actors that abstract away the direct interaction with hardware and software services (e.g. screen, speakers, databases), similar to environment actors in SALSA . For instance, the screen is a service modelled as an actor. A moved actor that wants access to the screen has to be given a reference to the screen actor explicitly in the services object it receives upon arrival.
Mobile Sessions as Actors
A mobile session actor is a container for a group of services which have to be moved together. These services are stored by this actor in a simple vector. We assume that the mobile sessions are distinguishable across the network via its user identifier. Part of the implementation of the mobile session actors is shown below:
Our focus is on the followMe move method of the mobile session actor, whose
body is executed after the session itself is moved by a system actor. During postmove
processing, the mobile session actor asks its registered services to come to the
new location (by invoking their come move method and passing along the services
it was given by the follow-me actor) only if there is no service at this location that
provides the same functionality. Otherwise, the mobile session rebinds these new
services. This example shows how the MOM model can be used to structurally move
Mobile Services as Actors
A mobile service actor represents any kind of actor that implements a move method named come. Upon arrival to the new location the service has the possibility to reconfigure itself by rebinding services passed as parameters in the come method. As a concrete example, consider the following mobile game actor which represents a (distributed) game application that requires a GUI and speakers to work.
Whenever the actor is moved, it rebinds these services. For the sake of simplicity, we assume that if some service is unavailable the functionality of the actor using such service becomes disabled (unbound). For instance, if the speakers cannot be rebound, the game continues without audio.
The scenario of the follow-me services demonstrates how one can concisely define a mobile service using the MOM model. The example features a simple yet representative mechanism to move running services in mobile networks. Without the MOM model, coding these mobile services requires to manually handle concerns like mobility of computational state, reconfiguration of the network, abstractions for structured mobility and security.
6 RELATED WORK
In the literature, there are an important number of programming languages and
frameworks that have direct support for object mobility like Emerald  and Obliq
, agent mobility like Telescript  and Aglets , and actor mobility like
SALSA , Actor Architecture (AA)  and ProActive . Although these approaches
accomplish some of the four requirements for proactive code mobility in
mobile networks identified in Section 2, to the best of our knowledge none of them
succeed in all of them. In this section, we discuss the solutions and shortcomings of
Strong mobility The mobility of running services have been mainly studied in the context of agents and actors. IBM Aglets  and ProActive  are Java frameworks that support the mobility of living entities (agents and active objects, respectively). Unfortunately, because Java threads are not serialisable, both approaches only supports semi-strong mobility, which as we argued in Section 2 does not suffice for our purposes of proactive service migration. The AA framework  provides a form of strong mobility on actors. Similar to the MOM model, this framework preserves the availability of the actor during the move by putting it in in-transit state. Messages sent to an in-transit actor are delayed in the original host until the actor notifies its arrival at the new location.
Decentralised network reconfiguration In the literature, location updating and message rerouting have been addressed in two different ways: via central servers that keep track of the location of the mobile services, or via forwarding proxies. The AA framework, for instance, implements a centralised network reconfiguration mechanism which is supported by a dedicated entity called the mobility manager. When actors move to another location, they have to update their location in the mobility manager which takes care of message rerouting. Unlike the network reconfiguration mechanism presented in the MOM model, the reconfiguration mechanism of AA is not an automatic mechanism since it requires that actors explicitly register their location each time they migrate to a new host. SALSA  is an actor-based programming language that also uses a naming service in which actors have to register their changes of locations. However, this is a decentralised naming service based on a Chord distributed lookup protocol  which is resilient to the network partitions. The ProActive framework proposes a message rerouting mechanism that is entirely based on forwarding proxies. This framework attempts to keep the chain of forwarding proxies as short as possible by means of active collaboration of the sending host where messages that are forwarded are marked so that the receiving objects knows if the sender has the latest location or another one.
Structured mobility As previously explained, code mobility has is often achieved
by the introduction of move instructions and explicit locations. The Telescript 
programming language, for instance, introduces a move instruction called go which
requires the notion of places. The AA framework has a migrate operator which
receives as parameter absolute locations such as destination host name or IP address.
SALSA provides an migrate method defined upon actors which takes as
parameter a high-level universal description of the new location. The Emerald 
Secure mobility Obliq mitigates the security issues that stem from move instructions by introducing protected objects and the notion of self-inflictedness. Put briefly, no object can move a protected object except for the protected object itself. Obliq provides mobility as the combination of cloning an object on a remote location and aliasing references from the original to the cloned object. Migration to a host requires then the active collaboration of that host as it needs to provide an execution engine, a function responsible for creating the clone of the object that wants to move. Telescript tries to mitigate security issues by providing a security model based on capabilities. These capabilities are used for reconfiguration purposes of agents upon arrival to new locations. Such capability-based security model allows places to restrict the actions a visiting agent can perform. Likewise, SALSA prevents most of the security issues regarding mobility via access control lists . If an actor is not present in the access control list of a remote host, the actor will be rejected upon moving to that host. Similarly, if an actor is not present in the access control list of another actor, it is not allowed to migrate that actor to another host. Unlike the MOM model, this security mechanism explicitly requires programmers to manually deal with these access control lists when developing mobile services.
As said before, none of the code mobility mechanisms described in this section fulfil all the requirements for proactive code mobility in mobile networks. However, some of these mechanisms have significantly influenced the MOM model. For example, our model adopts an Emerald-like use of relative locations for code mobility by means of the move methods. In addition, the MOM model provides a security mechanism for rebinding local resources based on capabilities that is reminiscent of Telescript. Finally, we make use of proxy actors for the decentralised network reconfiguration mechanism which is similar to the concept of forwarding proxies of ProActive.
7 CONCLUSION AND FUTURE WORK
Within the domain of mobile computing, this paper focuses on the use of proactive code mobility to mitigate the unavailability of services due to network partitions. We identify a number of requirements a code mobility mechanism should accomplish in this context. We require a mobility mechanism that (1) does not hamper the availability of the services, (2) ensures the readability and structure of the code, (3) guarantees the security of the devices involved in the move process, and (4) performs a decentralised network reconfiguration after the move. We subsequently propose an event-driven mobility model, called the message-oriented mobility (MOM) model, which exhibits such criteria. The basis of MOM model is the combination of a strong mobility scheme with the actor model. The introduction of an explicit move instruction has been circumvented by providing a new kind of method called move methods. Furthermore, the model transparently ensures that none of the incoming messages are lost such that services retain their full computational context upon arrival. We illustrate our model by implementing a Follow-me service that allows users to pull services from one device to another.
Although the MOM model can help in tackling some of the challenges for code mobility faced in mobile networks, a number of challenging issues needs to be further explored. For instance, in the MOM model we represent mobile services as single actors. We are currently investigating an extension of the model that enables programmers to also deal with services composed of multiple actors. Moving such services, programmers may want to perform different actions on the actor components rather than just moving them (e.g. rebinding or recreating actors upon arrival). A solution for this case is to introduce an annotation system that allows the programmers to declaratively indicate the actions to be executed for every actor of a service when it is requested to move.
In the move process proposed in the MOM model, a proxy is left at the old host of the moved actor to forward local messages (sent from the same proxy's location) and to inform the new location to actors residing in third-party devices. We are currently investigating network reconfiguration techniques of peer-to-peer architectures [19, 17] as more scalable and reliable schemes to avoid chains of forwarding proxies in case of multiple moves of the actor.
The MOM model proposes a two-party contract between the devices involved in a move process as a solution for security at the language-level. This scheme assumes that both devices trust each other. We are currently investigating more advanced security techniques based on capabilities [13, 14] to complement our model. Capabilities allows the mobile service to be sure that only trusted devices can request its move.
1 In AmbientTalk, the result of an asynchronous message can be a future which corresponds to a proxy for a result that is not yet computed. We refer to  for further information about this language abstraction.
 G. Agha. Actors: a Model of Concurrent Computation in Distributed Systems. MIT Press, 1986.
 F. Baude, D. Caromel, F. Huet, and J. Vayssiere. Communicating mobile active objects in java. In HPCN Europe LNCS 1823, pages 633-643, 2000.
 S. Berger, H. Shulzrine, S. Sidiroglou, and X. Wu. Ubiquitous computing using sip. In NOSSDAV 03: Proceedings of the 13th international workshop on Network and operating systems support for digital audio and video, New York, NY, USA, 2003.
 L. Cardelli and A. D. Gordon. Mobile ambients. In Foundations of Software Science and Computation Structures: First International Conference, FOSSACS '98, 1998.
 J. Dedecker. Ambient-Oriented Programming. PhD thesis, Vrije Universiteit Brussel, 2006.
 J. Dedecker and W. Van Belle. Actors for Mobile Ad-hoc Networks. In International Conference on Embedded and Ubiquitous Computing EUC2004, 2004.
 J. Dedecker, T. Van Cutsem, S. Mostinckx, T. D'Hondt, and W. De Meuter. Ambient-Oriented Programming in Ambienttalk. In Proceedings of the 20th European Conference on Object-Oriented Programming (ECOOP), Nantes, France, 2006.
 A. Fuggetta, G. P. Picco, and G. Vigna. Understanding Code Mobility. IEEE Transactions on Software Engineering, 24(5):342-361, 1998.
 M.-W. Jang. The Actor Architecture. Technical report, Department of Computer Science, University of Illinois at Urbana-Champaign, 2004.
 E. Jul, H. Levy, N. Hutchinson, and A. Black. Fine-grained mobility in the Emerald system. ACM Transactions on Computer Systems, 6(1):109-133, February 1988.
 J. A. Landay and G. Borriello. Design patterns for ubiquitous computing. IEEE computer ubicomp, August 2003.
 D. Lange and M. Oshima. Programming and Deploying Java Mobile Agents with Aglets. Addison Wesley, 1998. http://aglets.sourceforge.net.
 H. M. Levy. Capability-Based Computer Systems. Butterworth-Heinemann, Newton, MA, USA, 1984.
 M. Miller, C. Morningstar, and B. Frantz. Capability-based financial instruments. In Proceedings of Financial Cryptography. springer-Verlag, 2000.
 D. S. Milojicic, F. Douglis, and R. G. Wheeler, editors. Mobility: Processes, Computers, and Agents. ISBN: 0-201379-28-7. Addison Wesley and ACM Press, 1999.
 N. B. Priyantha, A. Chakraborty, and H. Balakrishnan. The cricket location-support system. In Mobile Computing and Networking, pages 32-43, 2000.
 A. Rowstron and P. Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), pages 329-350, November 2001.
 I. Satoh. Physical mobility and logical mobility in ubiquitous computing environments. In MA '02: Proceedings of the 6th International Conference on Mobile Agents, pages 186-202, London, UK, 2002. Springer-Verlag.
 I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan. Chord: A scalable Peer-To-Peer lookup service for internet applications. In Proceedings of the 2001 ACM SIGCOMM Conference, pages 149-160, 2001.
 T. Thorn. Programming languages for mobile code. ACM Computing Surveys, 29(3):213-239, 1997.
 R. Toll and C. Varela. Mobility and security in worldwide computing. In Proceedings of the 9th ECOOP Workshop on Mobile Object Systems, Darmstadt, Germany, 2003.
 C. Tolman and C. Varela. A fault-tolerant home-based naming service for mobile agents. In XXXI Conferencia Latinoamericana de Informática, Cali, Colombia, 2005.
 T. Van Cutsem, J. Dedecker, S. Mostinckx, E. Gonzalez, T. D'Hondt, and W. De Meuter. Ambient references: Addressing objects in mobile networks. In Proceedings of the Dynamic Language Symposium - OOPSLA '06, Portland, U.S.A., 2006.
 C. Varela and G. Agha. Programming dynamically reconfigurable open systems with SALSA. SIGPLAN Not., 36(12):20-34, 2001.
 G. Vigna. Mobile agents: Ten reasons for failure. In IEEE International Conference on Mobile Data Management (MDM '04), pages 298-299, January 2004.
 J. E. White. Telescript technology: Mobile agents. Software Agents, 1996.
About the authors
Cite this document as follows: Jorge Vallejos, Tom Van Cutsem, Elisa Gonzalez Boix, Stijn Mostinckx, Wolfgang De Meuter: "The Message-Oriented Mobility Model, in Journal of Object", in Journal of Object Technology, vol. 6, no. 9, Special Issue: TOOLS EUROPE 2007, October 2007, pages 363-382, http://www.jot.fm/issues/issue_2007_10/paper18/