fied so that it may apply the appropriate transformations. Using Clipper, programmers may reason about the evolution of their applications at the configuration level, with confidence that implementation details can be generated automatically. With approaches such as ours, those who deal with distributed systems are able to not only control the evolution of their applications, but also to do so at a reasonable engineering cost.

This paper describes Clipper, along with requirements we had identified that led to its development; it describes how catalyst modules are constructed, and subsequently executed; and it discusses the current state of our overall system and the experiments we are performing with it.

2 Requirements of the Reconfigura-

tion Language

Our formulation of requirements was guided by many general considerations: ease of development, protection of the application state, separation of the application from reconfiguration, and minimizing side effects. As with any language effort, we sought a notation that is both expressive and succinct: detailed enough to support all structural changes to the application without being so complex as to be prone to syntactical errors.

From an engineering point of view, we believed it highly desirable for the language's syntax, scope and control structures to be similar to existing highlevel languages, so as to allow intuitive development of scripts. Much of our choice of syntax is motivated by the need to make interactions with the distributed environment as automated as possible. Unlike the notations found in Durra [?] and Gerel [?], change operations are specified in a central script external to the application. Not only does this simplify the set of reconfiguration commands [?], it enables portability between distributed environments.

Of course, not all types of reconfigurations are appropriate or correct for all applications, and therefore an important requirement of the language and system was to protect against inappropriate operations. Constraints on the set of reconfigurations valid at any give point can be described as arising from two sources. First, some constraints are common to all configurations. For example, since a module cannot not be connected to another module that does not exist, an assertion to this effect must be enforced implicitly by the language across all applications. Other restrictions are particular to a given application as chosen by the

programmer; these rules or constraints reflect design decisions that should be validly reflected in the run time environment.

Another general requirement is one of noninterference, that is, the steady state behavior of a reconfigurable application should not vary significantly from a similarly structured static application. In other words, during the normal operation of the application, users should not loose performance (or for that matter, reliability) due to the presence of any infrastructure (in the run time environment) that would make the application reconfigurable.

Moreover, invocation of any reconfiguration plan or script in our language should generally not consume excessive amounts of time or resources. Though this is not a crisply testable statement of requirements, its expression is intended to reflect a strong sentiment that most reconfigurations (that are not otherwise intended to alter functionality) should not be noticed by the user of the application.

We use a dining philosophers example to illustrate the intended application of a reconfiguration language, and in particular to illustrate how use of such a language would augment the current run-time environments that support dynamic reconfiguration of distributed applications. (This example has been in the past referred to as the uninvited diner" problem.) The initial application consists of four components representing dining philosophers (Figure ??, Left). Each diner module has three possible states: eating, thinking or hungry. An attribute called STATUS is set within each module to differentiate between a dynamically and statically created module. As a reconfiguration operation, we would like to add a new diner to the application (Figure ??, Right). To support this change, the following modifications to the application are necessary: replacing the initial diner module with one that it is capable of transfering its state (necessary to prevent starvation), adding a display (maitre d') module to request reconfiguration information, and adding a reconfiguration module (waiter) to perform application state changes.

This type of reconfiguration was enabled by prior work, such as found within the Conic system [?] or our own Surgeon system [?]. In the terminology of our own platform, the catalyst module for this system would need to be prepared manually; and, more importantly, the programmer must decide what basis would be used to initiate the introduction of a new diner. This is not an insurmountable problem, and indeed we have solved it in the past via manual techniques. Nevertheless, the problem still remains, that