Extensible Realm Interfaces 1

Transcription

1 Extensible Realm Interfaces 1 UT-ADAGE Don Batory Department of Computer Sciences The University of Texas Austin, Texas Abstract The synthesis of avionics software depends critically on components that import and export standardized interfaces. For reasons of practicality and performance, components must be allowed to export operations that only they understand. Thus, the concept of standardized interfaces seems to be at odds with the need for components to export nonstandard operations. In this paper, we show how this apparent conflict has been resolved in four implemented software system generators. We also present a model that explains how the general ideas embodied in these generators apply to ADAGE. 1 Introduction The interface of a realm is a programming interface to a fundamental abstraction of a domain. The composibility of components in ADAGE relies on realms having standardized interfaces. However, standardized interfaces have traditionally meant a cast-in-concrete set of classes and operations that all layers must export. This cannot be the case for generators that have any intension of being realistic; performance and extensibility considerations demand more flexibility. For example, every layer of a system adds new functionality; additional (layer-specific) operations and classes may need to be exported so that higher layers can exploit this functionality. In this paper, we review engineered solutions for realm interface extensibility in four software system generators that conform to the GenVoca model [Bat92]. The exemplars are Genesis (the database domain [Bat92]), Avoca (the network domain [OMa92]), Ficus (the file system domain [Hei93]), and Predator (the data structure domain [Bat93]). We then present an abstract model of extensible realm interfaces that unifies the designs of these solutions and that shows traditional notions of subclassing and subtyping are inadequate to express a fundamental relationship between realms and their components. 2 Exemplars Genesis demonstrated that customized database management systems (DBMSs) could be assembled by composing prewritten layers with standardized interfaces. Genesis relied on a rather rigid (and in hindsight) inflexible way of accommodating interface changes; realm interfaces evolved as new components were written. Thus if a component added an operation O(), then all components of that realm were required to export O(). This did not mean that every component of a realm had to implement O(); implementations were provided only for those components where it made sense to do so. In the case that a com- 1. This research was sponsored, in part, by the U.S. Department of Defense Advanced Research Projects Agency in cooperation with the U.S. Air Force Wright Laboratory Avionics Directorate under contract F C

2 ponent K did not implement O(), the Genesis layout editor DaTE (which corresponds to the ADAGE Architecture Knowledge Representation Language [McA93]) was informed of K s limitation. In this way, DaTE precluded component K from being used in systems that required implementations of O(). This solution was adequate for two reasons. First, components of realms were initially selected on their perceived ability to stress that realm s interface as much as possible. Thus, after a few components were implemented, realm interfaces reached a steady state so that further component additions rarely required interface modifications. Second, the primary goal of Genesis was to demonstrate that software synthesis by layer composition was feasible; performance wasn t an issue and a large user community was not envisioned. Consequently, there was no motivation for having a more scalable means of interface evolution. Avoca was a project that demonstrated that highly layered communications protocols could be more efficient and more extensible than monolithic protocols. Avoca realm interfaces were rigid sets of operations. Microprotocols, the name given to Avoca components, implemented a fixed-set of basic operations for transmitting messages and opening and closing sessions. However, there was one additional operation control(), whose function was much like the Unix ioctl()[bac86]. Every microprotocol could export zero or more control functions that only it understood. Calls to these functions were made through the control() operation which took a standard pair of arguments - a control function name and a pointer to the control function s argument list. The method of a control() operation was basically a switch statement; there was one case for each of the microprotocol s control functions, and a default case for transmitting the control operation to the next lower microprotocol. The advantage of this solution was its generality; it could accommodate any number of control functions per microprotocol and it satisfied - at least syntactically - the requirement for standardized (cast-in-concrete) interfaces. Ficus is an ongoing project at UCLA whose goal is to develop a scalable distributed file system. A key innovation of Ficus is to describe file system implementations as a (nonlinear) stack of plug-compatible layers. Ficus realm interfaces are determined at run-time. All Ficus layers support a fixed-set of core operations. In addition, each layer can export any number of additional operations. The reliance of Ficus on the Unix vnode facility encouraged a uniform treatment of core and layer-specific operations. At run-time, a file system is configured by polling each one of its layers for the set of operations that it exports. The union of all operations from all layers in the file system defined the interface to that file system. (Since Ficus supports only a single realm, all layers of a file system have their realm interface adjusted to the union interface). Since it is not possible to anticipate what operations would be provided by other (possibly yet-to-bewritten) layers, each layer provides (or is automatically provided) a bypass() operation, which simply transmits calls of unrecognized operations to the next lower layer. It appears to be possible that bypass operations can have nondefault methods (i.e., something more than simple transmission is possible). Predator is an ongoing project at the University of Texas to develop a generator for high-performance data structures. Predator realm interfaces are extended at compile-time. A Predator layer is viewed as a transformation between export and import virtual machine interfaces; only those operations for which non-identity mappings are performed need to be defined. Operations that are defined can be core or layer-specific. When Predator is compiled, the union of the interfaces of all layers is taken. Each layer is automatically extended to support the union interface. Operations that are unrecognized by a layer are (in effect) supplied default bodies which transmit the operation to the next lower layer. Default methods can be overridden on a per class basis. 2

3 3 Synthesis There are three striking features that all exemplars share: (1) realm interfaces are inherently open-ended. A realm interface exports a set of core operations plus a configuration-dependent set of layer-specific operations. (2) Component interfaces are inherently elastic; they are automatically extended to match whatever realm interface needs to be supported. (3) Default methods are provided for unanticipated operations. Our goal of this section is to abstract these engineering solutions to expose a critical feature of realms and their components. Let s first consider how realm interfaces are determined. Exemplar generators use a realm (subtyping) lattice like Figure 1a. The top of the lattice is a core realm, which defines the basic classes and operations of a domain abstraction. A subrealm of core has additional classes and/or operations that define a particular specialization, denoted delta. The realm that is used to configure the interface of all components is the (multiple-subtyping) union of all these realms, denoted bottom. Thus, all components are declared to be members of the bottom realm; there are no components that export only the core or delta realms. Figure 1b illustrates these ideas by showing the realm lattice for Predator s DS realm. The size_of_delta subrealm refines the DS_core with the addition of the size_of() operation on containers (i.e., an operation that returns the number of objects in a container). The time_stamp_- delta refines DS_core with the operation that returns the time-stamp that has been assigned to an object by a time-stamping layer. core DS_core delta_1... delta_n size_of_delta time_stamp_delta bottom DS Figure 1a and 1b. Realm lattices Now consider how component implementations are determined. Typically a component provides explicit implementations for only a subset of the operations (and classes) of the bottom realm; the methods of the remaining operations are defined by implicit or explicit defaults. The implicit default is by-pass, meaning that the method for an unanticipated operation is simply to transmit the call verbatim to the next lower layer. Explicit defaults, in general, need to be provided on a per-class basis. As an illustration of the need for per-class defaults, Figure 2 shows a realm and component declaration in P++ [Sin93]. Figure 2a shows how the realm lattice of Figure 1b is declared. Realm DS_core exports two different classes (container and cursor). Realm DS is the subtyping (union) of the DS_core, size_of_delta, and time_stamp_delta realms. Figure 2b shows the monitor component of DS. A monitor is used in concurrent applications [Boo87]; only one task can be executing a monitor operation at a given time. To achieve this, the method of each operation of a monitor is within critical section; to enter a critical section (i.e., to execute monitor operations serially), the calling task must gain access to the monitor s semaphore. The keyword others(...) is a special feature of P++. It pattern-matches with any operation that is not explicitly defined by the enclosing class. In Figure 2a, since no operation is explicitly defined in the container class, others(...) pattern-matches with every operation exported by container. What happens next is that each call to a container operation is wrapped inside a critical region, i.e., a wait() 3

4 is performed on the container semaphore, followed by a call to the actual operation, followed by a signal() on the container operation. In this way, the execution of operations on containers are serialized. Exactly the same happens for operations on the cursor class. Although the methods for others() in both the cursor and container classes look similar (i.e., both wrap wait() and signal() around their lower-level calls), note that the container semaphore is accessed directly in container::others() and indirectly in cursor::others(). It is for this reason that per-class defaults are needed. realm DS_core <class e> class container container (); ; class cursor container cont(); cursor (container *c); void move_to_start (); void advance (); void insert( e& obj ); void remove (); bool end_of_container ();... ; realm size_of_delta : realm DS_core <class e>... realm time_stamp_delta : realm DS_core <class e>... realm DS : realm size_of_delta, time_stamp_delta, DS_core <class e>; component monitor <DS x> : realm DS <class e> class container semaphore S; // add semaphore to container wait()... ; // P and V operations signal()... ; others(...) // default mapping wait(); x::container::others(...); signal(); class cursor others(...) // default mapping cont().wait(); // wait on container semaphore x::cursor::others(...); cont().signal(); Figure 2a and 2b: P++ Definitions The three key features exhibited in exemplar generators can be seen here. (1) Components can export whatever operations they need, in addition to core operations. (2) The presence of the others(...) keyword allows components to automatically adjust their implementation at configuration time to whatever realm interface needs to be supported. Thus, component interfaces and implementations are inherently elastic. (3) The bottom realm, where all components reside as members, defines the standard interface that components must adhere to. Consequently, realm interfaces are inherently open-ended, but are fixed at configuration time. This also means that the software that defines a particular instance of a component is not known until configuration time. The significance of this solution is that the key advantage of standardized interfaces - that is, providing a simple conceptual means by which components can be composed - has not been sacrificed. It is possible to have extensible, configuration-dependent interfaces prior to configuration and after configuration have interfaces standardized. 4

5 4 Relationship to Subtyping and Subclassing The configuration-dependent elasticity of realm and component interfaces is not quite subtyping and not quite subclassing; it is a peculiar generalization of both. In this section, we explain how subtyping and subclassing are not the features that one needs to support realms and components. Not subtyping. Subtyping is sufficient to explain the realm lattice of Figure 1a. For each class of a core realm, there will occur a subtyping lattice akin to Figure 1a. The union of the bottom-most classes of these lattices defines the bottom realm of Figure 1a. In programming languages with subtyping, modules that implement a type are obligated to provide explicit implementations of each operation of that type; that is, there is no ability of modules to appeal to an implicit or explicit default method for operations that might be added after the module is written (i.e., what we have called unanticipated operations). So, subtyping offers only one part of the solution: it explains elastic interfaces but fails to capture elastic implementations. Not subclassing. Subclassing is different than subtyping because it allows methods to be inherited. We have seen that subtyping explains configuration-dependent interfaces, and it follows that subclassing can also explain configuration-dependent interfaces in the same manner. The question is whether subclassing is sufficient to explain the elasticity of component implementations. Unfortunately, subclassing is incapable of expressing default methods for unanticipated operations; there is no way to express in programming languages with subclassing the pattern-matching concept of the P++ others(...) feature. Even to explain how methods could be inherited (assuming that default methods are simply by-pass ) requires considerable contortion. In particular, a common feature of components is that they have unique implementations of core operations. This implies that core of Figure 1a must represent an abstract or virtual class; no methods for core operations are supplied (since none are shared). Instead, each delta inherits core operations and supplies the methods that are specific to a particular component. The bottom realm merges the interfaces and implementations of the core and delta realms by multiple inheritance. While the resulting interface is correct, the implementations are not. First, each delta may contribute a method for each core operation. However, only one will be chosen automatically by multiple inheritance; whatever choice is made will be correct for one component, and wrong for the remaining. Thus, a straightforward inheritance lattice fails to explain the simplest case of component implementation. The only schemes that we have been able to construct that can actually work are horrendously complicated. Even in the limiting case where bypass methods are used, subclassing offers no significant advantage over subtyping in capturing the elasticity of component implementations. 5 ADAGE Considerations The automatic configuration of realm interfaces and component implementations is fundamental to software system generators. With no exceptions known to date, the relationships between realms and their components have been achieved through ad hoc means in prototype generators. (That is, none implement the specific P++ extension of others(...) that we have described in full generality). Because ADAGE has considerably more realms (~40) than databases (~20), data structures (~5), file systems (~2), and networks (~3), the need for a general reconfiguration mechanism will be important. It is possible that LILEANNA [Tra93] has some of the features needed to support reconfiguration easily (e.g., adding operations, etc.). 5

6 6 Conclusions Standardized interfaces is the key to component composition in hierarchical architectures. Such interfaces have been achieved in prototype software system generators by automatically reconfiguring the definition of realm interfaces to match the layers that are present, and to automatically adapt component implementations to the adjusted interface. Default methods, as well as override methods, are needed for elastic implementations of components. The meaning of component memberships within realms is central to reconfiguration processes. Realm lattices and realm membership do not fit the traditional notions of subtyping and subclassing. Attempts to force-fit realm-component relationships into subclassing or subtyping hierarchies succeed only by fixing the set of components in a generator (or generated system) or by casting interfaces in concrete. Both are obstacles to reconfiguration and scalability. 7 References [Bac86] M.J. Bach, The Design of the Unix Operating System, Prentice Hall, [Bat92] [Bat93] [Boo87] [Hei93] D. Batory and S. O Malley, The Design and Implementation of Hierarchical Software Systems with Reusable Components, ACM Transactions on Software Engineering and Methodology, October D. Batory, V. Singhal, M. Sirkin, and J. Thomas, Scalable Software Libraries, ACM SIGSOFT G. Booch, Software Components with Ada: Structures, Tools, and Subsystems, Benjamin- Cummings, J.S. Heidemann and G.J. Popek, File System Development with Stackable Layers, to appear in ACM Transactions on Computer Systems. [McA93] D. McAllester, DSSA-ADAGE Avionics/Architecture Knowledge Representation Language, ADAGE-MIT [Sin93] [Tra93] V. Singhal and D. Batory, P++: A Language for Large-Scale Reusable Software Components, University of Texas at Austin, W. Tracz, LILEANNA: A Parameterized Programming Language, Advances in Software Reuse, Lucca,