Mobile agent projects such as Telescript [9], Aglets [10], Itinerant agents [11], Tacoma [12], Agent Tcl [13], the Mole project [14], The Frankfurt project [15], etc. have investigated issues related to migrating code from machine to machine. These projects cover issues related to transport, state migration, language, security, and navigation. It is beyond the scope of this paper to discuss each of them in detail. Instead, we mention the noteworthy aspects of some projects that have influenced the design of NetPebbles.
The Frankfurt project uses HTTP as a transport protocol and observes that using a generic infrastructure for transport is critical for successful deployment of an agent infrastructure. We take a similar approach in NetPebbles. The Agent Tcl project has perhaps the most comprehensive treatment of security and language issues. They use a public key security infrastructure based on PGP, and have access control mechanisms. Like Telescript they also stress the usefulness of a limited vocabulary scripting language for security. They have influenced the NetPebbles security model. The Aglets and the Mole project use Java for infrastructure to ensure that their infrastructure is generally portable.
Unlike most of the these systems, NetPebbles uses a scripting language leveraging its inherent simplicity. Unlike Agent Tcl (which is a scripting language), NetPebbles supports transparent mobility thus the programmer is not burdened with the task of programming mobility explicitly. We should, however, point out that NetPebbles does not support component-instance mobility and hence the concept of mobility is somewhat simpler in NetPebbles than in some of the other mobile-agent systems.
NetPebbles has similarities to workflow systems in that a NetPebbles script can be thought of as executing workflow ``items'' on different machines. However, the classical workflow systems such as IBM's Flowmark [16] and HP's OpenPM [17] are closed systems controlled by a single workflow server. Thus, they are fundamentally different from the NetPebbles model. New ``WebFlow'' systems [18] are no different than classical workflow systems, except that they have a browser front-end. The COSM project [19] suggests mechanisms that can make programs written in a workflow specification language behave like a mobile agent to carry out workflow functions. Unlike NetPebbles, the focus of the COSM project was to enable workflow using CORBA services.
Work in distributed programming environments (such as Java/RMI, COM/DCOM, DCE, and CORBA) is also pertinent to NetPebbles. Throughout the paper we discussed how NetPebbles relates to these technologies. Unlike these systems, NetPebbles hides the complexities of remote component access from the programmer. It uses transparent program mobility as a single mechanism to address the requirements of both remote component access as well as mobile agent-like behavior.