The NetPebbles design is motivated by three goals: (1) Enable large-scale software reuse in developing distributed applications; (2) Simplify distributed programming for rapid development and deployment; (3) Provide mobile agent-like behavior without the extra cost of programming complexity.
The enormous interest and early successes of the Java Beans and ActiveX component technologies indicate that future software development will increasingly center around creating and reusing software components. We envision that this paradigm will extend well beyond today's user interface development. There will be components that provide access to enterprise data, platform-specific legacy software, system information, expert analysis tools, centralized information collection points, and even administrative APIs of printers and so on. Not only will there be a multitude of components in a network, there will also be many components providing the same function. We may assume that the functionality is captured through Java-style interface definitions, and that an interface may be implemented by one or more components. It is also likely that there will be a distributed catalog providing descriptions of such interfaces and components. The NetPebbles goal is to leverage such a scenario.
Ousterhout [1] suggests that application development using scripting languages (such as Tcl and Perl) is inherently simpler than using systems programming languages (such as C and Java). Part of the simplicity is derived from the fact that the scripting languages make it easy to invoke powerful pre-existing programs and compose several such components to provide more complex logic. In the NetPebbles design, we take this idea one step further by treating network components as if they were local. In most cases, programmers have to worry little about where components are instantiated. Method invocation on components is uniformly simple. By hiding the complexity of accessing remote components, the NetPebbles goal is to simplify distributed programming and thus allow for rapid application development and deployment.
Mobile agent-like behavior can be valuable in scenarios where a user-specific task needs to execute asynchronously in a network of servers. For example, a mobile agent can be launched from a palmtop device using wireless communication and results can be retrieved later perhaps at a different physical location. In another example, a mobile agent can be installed at a server in the network to wait for an unusual event and then respond to it in a certain programmed manner. The NetPebbles design allows for such programs to be written with little or no additional complexity over single-system programs. The key function provided in NetPebbles to support mobile agents is the transparent program mobility, which allows a programmer to specify where a component should be instantiated (and hence where its invocation should occur) either abstractly (through a set of attributes) or concretely.