Mobility Support (2)

The VRM service is in charge of maintaining information about the characteristics and current location of available resources/services in the system and exploits proxy-based, discovery and directory naming solutions. This makes possible to all entities (whether mobile or not) to dynamically access registered resources/services. For instance, in case of terminal mobility, the VRM implements the server-side functions to establish dynamic connections between mobile terminals and needed resources, while the MVT provides the client-side ones. In addition, an MA-based implementation of the VRM service achieves the useful side effect of simplifying the duties of administrators in modifying and migrating system resources/services at run-time. Global and open scenarios force the VRM to face resource/service heterogeneity and the service can benefit from any standardization effort. Object techniques and, in particular, distributed object infrastructures, such as CORBA, play an important role in overcoming heterogeneity by encapsulating resources via object-based managers. Resources and services that cannot benefit from the homogeneity provided by the Java Virtual Machine, such as non-Java-based legacy systems, can also be integrated in the SOMA framework via its interoperability service that provides compliance with CORBA and MASIF. The VRM permits system administrators to modify and move system resources in order to achieve even complex management goals. For instance, an administrator can balance the system load via dynamic redistribution of service components, and can optimize system performance by maximizing locality in resource access according to observed traffic of requests. Moreover, the SOMA-based mobility middleware automatically maintains pending bindings to agent-wrapped migrated resources by exploiting the same mechanisms that permit tracing of mobile agents.

 

Costs of Mobility

Here, we report about the costs of the main mechanisms of the mobility service layer that are extensively used for supporting terminal/user mobility and mobile access to resources/services.
The presented costs are measured for two platforms, one cluster of 300-MHz PentiumII PCs with Windows NT, and the other of 120-MHz Sun SPARCstation5 with Solaris 2.6. The mobile place has been hosted by a 233-MHz AMD K6 laptop with Windows 95. The Figure reports the performance of terminal/user mobility, and of resource migration for the two platforms.
The costs of terminal mobility derive from the time for the MVT service to connect a mobile place to a new hosting domain and to rebind the resources needed by the mobile place to the local equivalent ones via the VRM service.
The costs of user mobility stem from the time needed to the support to detect the user reconnection, to obtain the corresponding profile from the directory service, and to provide her the UVE service by configuring the used terminal.
The costs of resource migration measure the migration of database resources of different size, and include the time for de/registration at the discovery service of the leaving/entering domain.

These results demonstrate not only the viability of the SOMA approach but also the good scalability of performances in case of average size entities.


Figure. Performance of the main mechanisms in the
SOMA mobility middleware
(click here for a larger view of the picture)

 
Page updated on
In case of problems, or if you find any bug, please contact us.