Object Migration

One of the properties of objects mentioned in chapter one was that of Activity. Objects can be passive or active, and this is relative to their use. Migration of passive objects is relatively straightforward. It is a generalization of file migration. An object store management system will keep statistics as to accesses and use of passive objects and can decide to re-locate an object closer to clients if necessary. Migration of active objects is a great deal harder. In an Open Distributed System, we have an underlying assumption about the heterogeneous nature of the systems, software and hardware. An active object is instantiated as executing code and associated state. The state is not only private variables, but also outstanding service to clients. Even if the system implements an interpreted pseudo-code for the instructions of the object, it would be extremely complex to ;SPM_quot;re-plug;SPM_quot; all the clients to a re-located object. We would argue for initial process placement as being a more appropriate and technically feasible way of load balancing in Open Systems. This can also be supported by the argument that an Open System may require negotiation be fore placing a process. This overhead may often outweigh the benefit of moving an already active object. Both ANSA and ODP have the concept of relocation, which avoids the problem of having to replug all clients. An Interface reference, contains a sequence of interfaces to relocation servers. The mechanisms moving an object update associated relocation servers. If a client trys to invoke a service which has moved, the infrastructure can consult the relocator (all this can be done transparently to the application). This is discussed in great detail in chapters 7 and 11.