In the current implementation, the runtime is deployed as a Java servlet under a web server at all machines that host NetPebbles. The NetPebbles runtime consists of a script execution engine and necessary data structures to keep keep track of active NetPebbles. The runtime uses HTTP for communication. A user initiates execution of a NetPebbles script using a Java program called launchpad. Lauchpad takes in as arguments the name of the file containing the NetPebbles script and the name of the home server machine where the script should start executing. Launchpad first checks the script for any syntax errors. If there are no syntax errors then it constructs a NetPebbles message containing the script and sends it to the web server using the HTTP POST command.
After receiving the NetPebbles message, the NetPebbles runtime initializes some data structures and starts executing the script. The script and its associated program state (program counter, stack and data heap) is transferred to other NetPebbles runtimes as needed. When the script completes execution, it returns to the home server, which then sends out cleanup messages to all runtimes visited by the script. These messages are needed to cleanup any persistent component instances and data structures created by the script.
A NetPebbles script need not migrate from one host to another. Instead, it might download required components. Optionally, if a location is specified by the programmer using the at keyword, the runtime migrates the script to the specified location and also downloads the component to that location. For example in the Lunch application, to find members of the group the script can either migrate to the database server where the component is located, or the component can be downloaded to the current script location. However because of the at keyword, to display the lunch message the script migrates to and the component is downloaded to the specified user's machine. In the absence of the at keyword, the runtime makes the decision based on the server affinity attribute of a component published in the catalog. The actual classname to instantiate the component is also obtained from the catalog. All component instances accessed by a script are managed by a private instance manager. When asked to create an instance of a component, the instance manager searches through its classpath to locate the appropriate class to instantiate. Instead of returning the actual instance to the script, the instance manager generates and returns a unique handle (consisting of the server IP address and a GUID). The instance manager uses this handle to invoke any methods on the component instance. The handle is also used by the runtime to determine if it needs to migrate to another site before making a method invocation. We consider script mobility as a valuable feature to support in the NetPebbles environment. With mobility a NetPebbles script becomes a mobile agent. It preserves network bandwidth by data forwarding, naturally supports disconnected operations, allows for very thin clients, and prevents component piracy. The NetPebbles environment supports script mobility and accordingly deals with its implications on issues such as security, monitoring, and state migration.
Due to the use of servlets, all NetPebbles scripts run on the same underlying Java virtual machine. However, each script runs in a separate context with its own execution thread, state and instance manager. This separation prevents scripts from inadvertently accessing/manipulating component instances created by other scripts. We are currently working on defining a more detailed security model for NetPebbles.