By "execution configuration," we mean the set of computation nodes involved in a program's execution and how the tasks in a program are distributed among these nodes. The simplest form of execution configuration for a program is a single node that runs the given program. A slightly more sophisticated form is the client-server model, where the client makes a request and the server responds with the result after performing the requested service. In conventional distributed computing models, the execution configuration of application program is largely static. The only exception is those systems that provide process migration. However, even in these systems, the only "dynamic" part of the execution configuration is the choice of nodes. Dynamic execution configuration provides a powerful mechanism for mobile applications to adapt to the computational and communications resource available in a given environment. For example, consider a mobile application that needs to access a database and filter the returned results. One possibility is to retrieve all the data back to the mobile terminal and filter them locally. This is actually a bad choice because all the data returned from the database will have to cross the presumably low-bandwidth links, and the terminal's CPU and thus battery usage is high since all the filter processing is done on the terminal. Moreover, these two effects combined means that the overall performance will not be too good.
The other alternative is to spawn multiple processes on the surrounding desktops, which access the database and filter the database results in parallel, and finally return the filtered results back to the mobile terminal. This approach is preferable because almost all processing is done at desktops and only the portion of the data that is actually needed gets shipped across the wireless links. Although it is clear that the second approach is better, it is not always possible to take the second approach, for example, when there is only one base station and it refuses to provide computation service because of heavy load. So what we need is the ability to dynamically change the execution configurations of mobile applications to optimize certain criterion (e.g., performance or cost) by effectively exploiting the resources from the infrastructure. Moreover, the customization of execution configurations should be transparent to both users and programmers of the mobile applications. Programmer transparency is important because there is no way for them to anticipate the resources in the environments in which the applications are going to run.
We assume mobile applications are written in a script language such as Tcl (Tool Command Language). The smallest granularity of task allocation is a Tcl procedure. Writing mobile applications in a script language has the following three advantages. First, moving applications around the network is possible because the programs can always be interpreted by a high-level interpreter. Second, fewer security problems would arise when executing applications remotely since critical system resources are less likely to be compromised. Third, it is more compact to store an application in the form of script code than compiled binaries. Mercury supports dynamic execution configuration by first constructing an execution engine that consists of a set of Tcl interpreters, one on each machine in the environment that is available for providing computation service. Then Mercury partitions the application and maps the computation to the interpreters according to a given optimization criterion. Finally Mercury physically spreads the computation to the nodes to execute the program. Note that during the life time of a program run, the execution configuration may change multiple times because the mobile terminal moves. Therefore the execution engine supported by Mercury is "elastic."