architecture. We present an execution model, the. Reflective Graph and Event Model, and demonstrate its use in Legion, an object-oriented metasystem project.
Extending Metasystem Functionality Using Reflection Anh Nguyen-Tuong, Steve J. Chapin, and Andrew S. Grimshaw University of Virginia, Department of Computer Science Email: {nguyen | chapin | grimshaw}@virginia.edu http://legion.virginia.edu Abstract To support a vast set of user requirements, flexibility and extensibility are essential features of a metasystem architecture. We present an execution model, the Reflective Graph and Event Model, and demonstrate its use in Legion, an object-oriented metasystem project. Reflective features of the model are key in meeting our design goals of flexibility and extensibility.
1. Introduction The advent of gigabit networks and the wide availability of computing resources enable the construction of virtual machines, or metasystems [1][2], that will harness resources on a national scale and provide the illusion of a unified computing platform to end users. We believe that for metasystems to be successful, they must accommodate a vast set of user requirements in many dimensions, including performance, security, faulttolerance, site autonomy, and resource management. No single policy or set of static policies will satisfy every user, thus a metasystem architecture should be designed to be flexible—able to accommodate a vast range of user requirements—, and extensible—able to augment the functionality of the system easily. To meet our goals of flexibility and extensibility, we have borrowed the notion of reflection from the programming language community [4]. A reflective system is one that has two principal properties: introspection—it has a representation of itself that it can observe and manipulate, and causality—modifying this selfrepresentation has a direct impact on the behavior of the system. We will use these properties as the basis for both flexibility and extensibility by modifying and transforming the system’s self-representation. In addition, another benefit of using a reflective architecture is that it promotes the writing of generic, hence reusable, components. These components are reusable because they express a given functionality in terms of generic transformations on the underlying self-representation.
2. Reflective Graph and Event Model We have developed and deployed the Reflective Graph and Event (RGE) [5] model within Legion, an object-oriented metasystem architecture. In Legion, the fundamental unit of computation is the object. It has its own thread(s) of control and address space. RGE provides an execution model that supports interobject communication—communication between objects, as well as intraobject communication—communication inside objects. Program graphs describe interobject interactions while events describe intraobjects interactions. The salient feature of RGE graphs and events is their reflective nature: it provides a representation of the computation (introspection) and modifying or transforming this representation is the basis for extensibility and flexibility (causality). The advantages of using the event paradigm are well known: communication between parties is decoupled both temporally and spatially. The protocol stack of Legion objects is composed of components that interact via events. To extend the functionality of Legion objects, one simply needs to write a new component that interacts with other components via events [6]. While events capture interactions between components inside of an object, graphs capture intraobject interactions by describing the sequence of method invocations between objects as well as their data dependencies [3]. Graphs are first-class entities; they may be passed as arguments to objects, transformed, and executed anywhere within Legion. RGE further supports extending functionality by associating events with graphs. A graph can be executed as an event handler. Associations between events and graphs may be made and modified dynamically at run-time. Thus, policy decisions may be deferred until after the object is built. This is an important feature, as designers need not, and cannot, anticipate all future uses of their objects. For example, one can write a daemon object that monitors the health of other objects. What should happen when the daemon detects the death of another object? This is a policy question and using our techniques this question does not have to be answered at design time. Instead, different
policies may be enforced at run-time by registering the appropriate program graphs. The RGE model is targeted primarily at system builders, e.g., compiler writers and library designers. End users and programmers need not be exposed to RGE. Instead, system builders can choose to either hide the RGE model or expose it to end users using an API specific to the programming environment at hand. To illustrate this point, we have re-targeted the PVM and MPI message passing libraries for use with Legion. PVM and MPI users are not directly exposed to the RGE model, however they reap the benefits. For example, when a security component is written to encrypt/decrypt and sign/authenticate messages, PVM and MPI users can use it automatically.
3. Example Applications In Figure 1, we show the implementation of a Legion object using RGE. Events and their handlers form the object’s protocol stack and perform such functions as parameter marshalling, method invocation, etc. Thus, we can extend the functionality of a Legion object simply by adding events and event handlers. For example, to add encryption and signing for security purposes, library writers only need to register with the MessageSend event and add handlers to perform encryption and signing. Further, the object may raise a Security Violation exception. Who should be notified of this exception? Using RGE, several policies may be encapsulated within a program graph, e.g. notifying an Application Monitor or a Security Monitor. The power of the RGE model is that designers of components need only insert the code to raise exceptions; they need not be concerned with the recipient of these exceptions.
The above applications of the RGE model are just a few of many. To date we have applied the model for the following: • To implement a flexible protocol stack for Legion objects [6]. • To implement the propagation of exceptions in Mentat, an object-based parallel programming language. • To implement a generic Application Monitor. When an object is created or deleted, or when an exception occurs, an event is relayed to the Application Monitor automatically. • To implement security-related functions such as sign/authenticate, encrypt/decrypt. • To implement a bag-of-task scheduler. • To implement watchdog daemons to monitor the health of Legion applications. • To implement message logging for both debugging and as a fault-tolerance mechanism.
4. Conclusion Flexibility and extensibility are essential to supporting the vast set of user requirements in metasystems. We have described a reflective execution model, the Reflective Graph and Event Model (RGE). RGE has been implemented and is deployed currently in the Legion metacomputing project. It provides an execution model and a mechanism for supporting our design goals of flexibility and extensibility. Further, it promotes the writing and reuse of generic components and objects; policy and functionality may be dynamically set at run-time instead of compile-time.
5. References Method 1
Method 3
Method 2
Method 4
"Event" Graph
"Event"
Handlers "Event"
Graph
Handlers "Event"
Anatomy of a Legion Object
Figure 1. The protocol stack of Legion objects is assembled using events and event handlers. RGE allows events to be associated dynamically with executable program graphs for flexibility and extensibility.
[1] I. Foster and C. Kesselman, “Globus: A metacomputing infrastructure toolkit”, International Journal of Supercomputing Applications, 1997. [2] A. S. Grimshaw, “The Legion vision of a worldwide virtual computer”, Comm. of the ACM, 40:1, pp. 39-45, January 1997. [3] A. S. Grimshaw, J. B. Weissman and T. Strayer, “Portable Run-Time Support for Dynamic Object-Oriented Parallel Processing”, ACM Transactions on Computer Systems, Vol. 14, Num. 2, 1996. [4] P. Maes, “Concepts and Experiments in Computational Reflection”, Proceedings of the ACM Conference on ObjectOriented Programming Systems, Languages and Applications (OOPSLA), pp. 147-55, October 1987. [5] A. Nguyen-Tuong and A. S. Grimshaw, “Building Robust Distributed Applications with Reflective Transformations”, Technical Report CS-97-26, University of Virginia, 1997. [6] C. L. Viles et. al., “Enabling Flexibility in the Legion RunTime Library”, International Conference on Parallel and Distributed Processing Techniques (PDPTA ’97), Las Vegas, NV, 1997.
