Summary and Future Work

 

In this paper, we described NetPebbles, a script-based programming environment for composing and executing distributed component-based applications. NetPebbles uses program mobility to support both remote component access as well as mobile agent-like behavior. Furthermore, since NetPebbles programmers use components as if they were local and write programs in a scripting language, they find that there is a great deal of simplicity in using NetPebbles. Typically, a NetPebbles programmer selects needed interfaces from a component catalog and writes a script invoking methods on components implementing the interfaces. The components are highly self-contained Java Beans with globally unique identifiers.

We implemented three examples with different information flow patterns using three different technologies: NetPebbles, Java/RMI, and Aglets, and analyzed the implementation complexity and the number of messages used. Results show that NetPebbles indeed offers a significant amount of simplicity, as seen in the number of lines of code as well as in the programming effort needed. In addition, NetPebbles also requires the smallest number of network messages in most cases. However, to understand how NetPebbles extends to more realistic scenarios, we are developing NetPebbles scripts to manage a large network of PCs, workstations, and laptops.

Since NetPebbles is a relatively young project, we recognize many technical challenges that need to be addressed. The following is an incomplete list of issues we are working on.

1. Recovery: As a NetPebbles script travels through the network, there are many opportunities for failures, such as hardware, software, and communication failures. There must be mechanisms in NetPebbles runtime or in the infrastructure it uses to handle such events. Recoverable messaging mechanisms such as the IBM MQ Series are being investigated as a way to address this need.
2. Transactional Support: Should there be transactional mechanisms in the NetPebbles language? Transactional mechanisms can help multi-server updates such as a travel reservation involving hotel, airline, and car, but it can also increase the programming complexity.
3. Exceptions, Events, and Data Pipes: What are the ways in which components should be allowed to interact with each other and with the NetPebbles script? Should we allow a component to throw an exception that can be handled by the script writer? What about Java-style events? Is there a need to connect components to form a pipeline for data to flow?
4. Business Model: How will script users pay for component use and resource consumption of other machines? The Tacoma project [12] considers an ecash approach where a mobile agent starts out with a certain amount of ecash and spends it along its way. For intranets and extranets, such a scheme may be an overkill.
5. Transitive Trust Issues: As NetPebbles travels through the network, it becomes necessary for each server to verify that the preceding servers in the path have not introduced security violations (either maliciously or otherwise) into the program state.
6. The Scripting Language Issues: Using typed components in a typeless language raises several composability issues. In addition, introducing a new language is always a difficult marketing challenge. We would like to be able to provide the necessary NetPebbles mechanism in an existing scripting language while being able to implement program mobility in an efficient manner.

In spite of many remaining challenges, the NetPebbles programming environment has been successful in showing that the complexities of remote component access and mobile agent-like behavior can be hidden from the programmer. It also shows that scripting languages can be used for distributed component programming while retaining the simplicity inherent in such languages. This work suggests how the Java Beans style component model can be used to encourage large-scale reuse of network resources rather than just GUI programs.

Acknowledgement: The authors gratefully acknowledge the feedback provided by the anonymous reviewers of the COOTS '98 program committee and the Adventurous Systems and Software Research projects review committee in IBM Research. We especially thank our colleague Sandra J. Baylor for her input on the presentation of this final version, she nearly re-wrote the abstract for us.