Check out the new USENIX Web site. next up previous
Next: Motivation and An Example Up: Programming Network Components Previous: Abstract

Introduction

 

NetPebbles is a scripting environment for writing and executing distributed component-based applications. The prominent among its features is the use of transparent program mobility both for accessing remote components and for mobile agent-like behavior. The resulting benefit to the programmer is a great deal of simplicity.

A NetPebbles programmer writes a script by first selecting needed interfaces from a distributed catalog and then invoking interface methods as if the components implementing the interfaces are local. An end user launches such a script into the network, where the NetPebbles runtime dynamically determines the component sites and transparently moves the state of the script to component sites as necessary. Implied in this model is the possibility that a component might be downloaded to the script execution site, and even that both the script and the component might execute at a third site. In a typical scenario, after visiting several component sites, the script terminates by returning to the launching site. However, a NetPebbles script can be programmed to remain forever in a waiting mode listening to asynchronous notifications.

NetPebbles programs are written in a Basic-like typeless scripting language. Interfaces are the same as the interface definitions of the Java language. However, each interface must be registered in a distributed catalog with a globally unique identifier. One or more components may implement each interface. Components also have globally unique identifiers and are also registered in a distributed catalog. Components are medium-to-large grain Java Beans with certain restrictions that make them highly self-contained. For example, in the current implementation, the NetPebbles runtime handles all exceptions thrown by a component and components may not send or receive events. The current NetPebbles implementation consists of an interpreter, a runtime environment, and a library to access a distributed catalog, all written in Java. This allows us to run the NetPebbles environment on all machines supporting the Java environment.

We selected three different applications, representing three different data flow patterns, and implemented them using NetPebbles, Java/RMI, and Aglets. The data flows have the broadcast, two-party interactive, and multi-party synchronization patterns. We used the same components in all three implementations. NetPebbles implementations are significantly smaller than the implementations using Java/RMI and Aglets, and the programming complexity is correspondingly less. For two out of the three applications, the number of network messages are also the fewest with NetPebbles. Within the scope of these experiments, we find it encouraging that NetPebbles is able to deliver on the promise of simplicity without additional network messages.

The NetPebbles project is relatively young at this point. Work is in progress to address many challenges of this approach to distributed component programming. Issues related to using typed components in a typeless language, recovery and transactional issues, and transitive trust requirements are some of the design challenges that are being addressed. We are using system administration for a large network of PCs, workstations and laptops as a real life scenario to validate our approach to simplicity, reuse of existing software, and mobile agent-like behavior. A visual builder is being developed to provide an interactive interface browsing and script development tool.

This paper describes the motivation and the programming model of NetPebbles, practical experiments in understanding the advantages of the NetPebbles model, the current implementation, an ongoing case-study using NetPebbles, and future work.


next up previous
Next: Motivation and An Example Up: Programming Network Components Previous: Abstract

Ajay Mohindra
Mon Mar 16 14:45:01 EST 1998