Establishing System-Wide Properties of Component-Based Systems --- A Case for Tiered Component Frameworks Clemens Szyperski c.szyperski@qut.edu.au School of Computing Science Queensland University of Technology Brisbane, Australia Rudi Vernik rudi.vernik@dsto.defence.gov.au Software Engineering Group Defence Science and Technology Organisation Salisbury, South Australia Position Statement submitted to the OMG-DARPA-MCC Workshop on Compositional Software Architectures As outlined in the call for position papers, component software technology is a rapidly emerging field. As with previous developments in software, the practical availability of fundamental technologies tends to preceed efforts aimed at effectively augmenting and applying the approaches. For example, various standards and technologies at the "wiring" or "plumbing" level are now available to support component-based development, with three main competing approaches gaining prominence: Sun's Java(Beans), Microsoft's COM/COM+/DCOM/ACTIVEX/etc, and OMG's CORBA/OMA. Each of these approaches has its home field and all try to expand into each others areas. Picking the right technology seems to be the major concern of many these days. However, far more pressing issues are lurking behind the scenes, such as: how do we actually architect, design, engineer, deploy, maintain, and evolve component software systems. Of particular concern is the development of component-based systems which exhibit required system-wide properties such as reliability, availability, maintainability, security, responsiveness, manageability, and scaleability (i.e. the "ilities" problem described in the call for papers). Clearly, it does not seem reasonable to expect conglomerates of wired components to have any system-wide properties (ilities) at all! We hardly understand how to specify such properties, let alone how to verify individual components against such specifications. Expecting that arbitrary compositions retain such properties is even more demanding. We thus believe that properties expected invariantly from composites will require dedicated support outside of the participating components. As such, we propose the notion of component frameworks as providing the basis for component-based development (i.e. blackbox frameworks that accept "plug-in" components). Critical properties of a system built using these frameworks and a set of components can then be enforced by the framework implementation. By supporting "plug-in" into the blackbox component framework - rather than modifications to the framework, as is commonly the case with application (or whitebox) frameworks - a component framework can enforce critical system-wide properties. To avoid the immediate trap of frameworks insisting on overall control, the architecture can be extended recursively: a component framework itself can slot into a higher tier framework that regulates interaction. (Naturally, a component can then interact with and through multiple component frameworks, where this is useful.) A second-tier component framework might suffice in many cases and thus form the hard backbone of a Component System Architecture. Considering such a tiered approach to component frameworks from the beginning seems essential. The problems of non-interoperation of current application frameworks directly contradicts the promises of component software: gradual and localized evolution via composition of independently sourced components. While there have been initial attempts at developing components frameworks (OpenDoc and the BlackBox Component Framework are examples from the domain of visual components), little is known about the tiered approach described above. (For a first abstract introduction as well as an overview over the current state of component software cf. the forthcoming book by the first author.) Before moving on, let us briefly review one exemplary mechanisms used in OpenDoc and BlackBox, respectively. OpenDoc is structured using a blackbox component framework as its foundation and a selection of whitebox "part frameworks" to aid in constructing specific OpenDoc parts, i.e., components. The blackbox framework forms the heart of OpenDoc and rigidly controls certain resources. For example, a two-phase commit protocol is used to coordinate requests for resources issued by parts. This logically centralized mechanism ensures that parts asking for exclusive use of, say, the mouse and the keyboard focus, cannot deadlock each other. In BlackBox a mechanism called "cascaded guarded multicast" is used in the component framework to prevent nested multicasts from happening that would lead to unexpected and apparently non-causal arrival of notification mechanisms at views. Since BlackBox supports a generalized hierarchical model view controller approach, this particular framework facility is fundamental to guarantee consistency even in the presence of malfunctioning components. In both cases, the focus control in OpenDoc and the multicast control in BlackBox, the component framework insists on controlling and coordinating certain component interactions and thereby establishes and enforces framework-wide properties. Obviously, such properties are not "system-wide", unless the particular component framework forms the top tier of a tiered approach. Despite these successful attempts at defining and maintaining properties across wide ranges of component configurations, many problems remain open. However, it seems possible to address the majority if not all of the practically relevant "ilities" by means of component frameworks and a tiered framework architecture. In fact, it would seem that system-wide properties that cannot be established using our proposed approach would probably outright contradict a component approach anyway. (Obviously, we are not claiming that our approach is the only one possible.) A range of fundamental questions need to be addressed to successfully exploit the vast potential of component software. Among the more pressing are: How do we design component frameworks such that they fulfill both of their roles: integrating the components slotted into the framework and ensuring interoperation with related frameworks (via a higher-tier framework)? How do we define Component System Architectures which might comprise a number of frameworks, rules which govern the integration/interaction of frameworks, and a set of system-wide properties? How do we most effectively develop component-based systems? Component software development is fundamentally driven by a mixture of bottom-up approaches, catering for available or expected components and frameworks, and top-down approaches, linking actual requirements to the emerging architecture, design, and implementation. How can we evolve component frameworks and component-based systems so that the essential system-wide properties are preserved? How, in the first place, do we define and specify such essential system-wide properties as invariants over "correct" configurations? About the authors: Dr. Clemens Szyperski is Associate Professor in the School of Computing Science, Queensland Unversity of Technology, Brisbane, where he heads the research concentration on programming languages and systems. He is also a cofounder and Director of Research of the Swiss Oberon microsystems, Inc., one of the first companies fully dedicated to component software technology and support. His primary research interests are in the areas of component technology and programming languages and systems support for adaptive and extensible programming. His new book "Component Software - Beyond Object-Oriented Programming" will be published by Addison-Wesley in December (in the USA; January 98 elsewhere). He has written and presented numerous papers in the area of component software and actively participated in a large number of workshops. He actively contributed to various OCs and PCs of several national and international workshops. In particular, he organized the so far two International Workshops on Component-Oriented Programming (WCOP'96, WCOP'97) in conjunction with ECOOP, the premier Europe-based international conference on object-oriented programming. (WCOP'98 is currently being proposed to the ECOOP'98 organisers.) Dr. Rudi Vernik is a Senior Research Scientist at the Defence Science and Technology Organisation (DSTO) which is the research arm of the Australian Department of Defence. He leads a team which is investigating how component technologies and approaches might be used as the basis for future Defence Command and Control Information Systems. His interests lie in a range of software engineering issues associated with component-based systems including lifecycle processes, Component System Architectures, and tool support. Some of his previous work involved the use of computer-based visualisation techniques for supporting the development of large homogeneous software systems. He is currently exploring how these techniques might be used to provide visibility of large heterogeneous component-based systems.