Objects such as mobile agents [5] may have to move from one address space to another. This may be achieved by creating a replica of the moving object in the target address space, then removing the replica from the source address space.
However, this may be too costly a way to migrate an object. Another, potentially faster, approach is to have a meta-object that stops delivering operations to the object as soon as it decides the object must migrate. Then it marshals the complete internal state of the object and sends it to a remote meta-object that is going to become a member of the migrated object's meta-configuration. It creates a pseudo-object and fills in its fields with the marshaled image of the object. At this point, the original object will have become a proxy object, that simply forwards operations to the migrated object, until the proxy is garbage collected.
If an object migrates many times, an operation may have to flow through several proxies before it reaches the actual object. In this case, it may be useful to have an algorithm that notices whether an object migrated any further, and sets up a short-cut to the most recently known location of the object from then on [17].
We should note that there is some overlap of the migration and the persistence functionalities. After all, a persistent object may be implemented by migrating it to and from a long-running server process. On the other hand, migration could be easily implemented by storing the mobile object in persistent storage, then reincarnating it in another address space.
Instead of implementing one mechanism on top of another, we believe the correct approach is to factor out the common functionality required by both mechanisms, and implement the differences as specializations. Meta-objects that implement caching may also share functionality with these two mechanisms.