Workshop on Compositional Software Architectures

Workshop Report
 
Monterey, California
January 6-8, 1998
 
Editor:  Craig Thompson
 
February 15, 1998
 
[Workshop homepage:  http://www.objs.com/workshops/ws9801/index.html]

Contents

Sponsors and Organizers

       

Workshop Committee

Objectives of the Workshop

The workshop focused on: Fundamental concerns face organizations developing and maintaining large, enterprise-critical, distributed applications. Component software did not exactly set the world on fire five years ago. Now we have new languages, maturing visions of compositional architectures (CORBA, WWW, ActiveX, ....), the web as a distributed system with a low-entry barrier, and emerging middleware service architectures. Do we have the critical mass to jump start the component software cottage industry? Even if the technology enablers are there, what is needed to establish an effective component software market?  What are the remaining barriers?

The objective of the workshop is to bring together a mix of leading industry, government, and university software architects, component software framework developers, researchers, standards developers, vendors, and large application customers to do the following:

Workshop Focus

The workshop consisted of a set of invited presentations and topic-centered breakout sessions.  Topics of interest listed in the Call for Participation included (but were not limited to):

Planned Outcomes and Benefits

The explicit planned outcome of the workshop included position papers and this workshop report, which summarizes the breakout sessions.  Implicit benefits of the workshop are:

Position Papers

Position papers (mostly around three pages long) on a topic related to the workshop theme were solicited by November 21, 1997.   Generally, an accepted position paper was a prerequisite for attending the workshop except for a small number of invited talks. The position papers were made web-accessible by December 7, 1997, in various widely used formats (.html, .doc, .ps, .pdf, .txt) -- see the List of Position Papers arranged in the order received.

We originally expected around 40 position papers but received 112 and accepted 93.  This was a first indication that the workshop theme was of broader interest than we originally expected.  We decided to scale up the workshop rather than severely restrict participation.  We solved the scaling problem by adding extra parallel breakout sessions.

Workshop Structure - Presentations and Breakout Sessions

The workshop consisted of presentations and breakout sessions.

Most presentations were based on position papers but a few were invited talks (so there is no corresponding position paper for these).  Several invited talks were scheduled the first morning to get many of the workshop ideas exposed early.  Other talks were scheduled for presentation in relevant breakout sessions to get the conversation going.  Because of time limitations, we could not schedule all position papers for invited talks.  We did our best at matchmaking.

Breakout sessions were two-to-three hour working sessions focused on a topic, led by a moderator and recorded by a scribe.  Most breakout sessions started with summaries of a few relevant position papers skewed toward helping to introduce the session's topic.  Following a breakout session, in a plenary session, the moderator present a summary of the breakout session and some discussion occurred.  The scribes were responsible for sending a summary of their breakout sessions to the editor of the workshop report by January 16, 1998, for assembly into a draft report.

There were four sets of half-day breakout sessions (I-IV), each containing four parallel breakout sessions (1-4).  In order to partition the workshop into breakout sessions, we completed a poor-man's Topic Analysis on the workshop papers.  This really just consisted of keeping track of several topics per position paper and then making a large outline of all the topics.  The topic analysis was useful for several purposes.  As an outline for the many topics covered by the position papers, it provides a way to scope and structure the topics covered.  To a lesser extent, it provided a way to locate (some) papers based on topics (though it is pretty incomplete if used this way).  Finally, it provide the basis for partitioning the workshop into a collection of breakout sessions.

The last step was to pre-plan the breakout session topics.  This involved identifying for each breakout session the title, topic description, moderator, and relevant presentations (this was done before the workshop).  This information appears in the breakout session summaries below.  In addition, we did late binding in selecting scribes at the beginning of each breakout session.  And scribes authored the breakout session descriptions, which is the main body of the breakout session descriptions below.

Opening Session:  Problem Domain and Workshop Goals

[Thanks to Robert Seacord (SEI/CMU) for notes on these presentations.]

This half hour session consisted of presentations by

Presentations

Breakout Sessions

Breakout Session Rationale

Breakout sessions were organized to encourage effective discussions in a cross-disciplinary workshop where the attendees are coming in with very different backgrounds, viewpoints, terminology and interests. Seen from another vantage point, there were collections of sometimes sequenced sessions that covered:

Breakout Session Structure

Each breakout session description has the format:

I-1 Problem Definition by Application Architects

Moderator:  Craig Thompson, Object Services and Consulting (OBJS)

Scribe: [notetaker, please contact report editor]

Topics:  From the large application builder's perspective, component software is an enticing vision but there are roadblocks in the way of realizing the benefits.  Large application architects and enterprise software architects will identify the critical shortcomings they see in current technology, develop a vision for future component-based development of enterprise-wide applications, and identify key architectural concepts, tools, and processes needed to realize their vision.

Papers

Discussion

The purpose of this session was to look at the world of middleware choices from the point of view of large application architects and to understand their requirements and experiences to date with using component-based middleware.

There were three presentations.

Louis Coker - DARPA AITS Architecture

Louis Coker talked about the DARPA AITS architecture, especially the experiences of the JTF-ATD command and control team in being early ORB adopters who have evolved their application in parallel with CORBA and the World Wide Web.  Their problem involves users collaborating in developing situation representations and in planning courses of action.  Some limitations of today's ORBs are:

These lessons learned are not getting out widely to the OMG community.  Vendors do not seem to be addressing the needs of the Wide Area Net (WAN) community.

Colin Ashford - The TINA Service Composition Architecture

TINA is a consortium of telecommunication providers, manufacturers, and researchers.  Their mission is to develop an architecture for distributed telco applications that is bandwidth sensitive and supports multimedia.  Colin Ashford talked about service composition in TINA.  You can create a service by combining service components or in a temporary merger in a session, e.g., a teleconferencing session. Service composition may be static or dynamic.  Services can be composed in parallel or series (he did not mention weaving).  The TINA architecture is based on OMG's but has richer ORB+ capabilities, administration and management services, and network resources, and it has a session model.  The business model is to allow retailers to re-sell services to customers that the retailer has composed from more primitive services supplied by third party providers, that run on an infrastructure provided by a communication infrastructure provider, possible with an RM-ODP-like broker in the picture to locate services.  They need algebras for specifying composition, scripting languages, and toolkits to make composition easier to perform.

Gabor Seymour - Compositional Software Architecture "ilities" for Wireless Networks

Motorola careabouts include mobility and wireless communication.  Mobility impacts the ilities.  Cellular topologies require smarter cell-sites.  The physical environment and geography forces quality concerns.  There is a need for object migration at runtime and a desire to migrate functionality to cell-sites not keep it central.  With respect to reliability, availability is location-dependent and replication varies by site driven by cost.  With respect to scalability, they need upward scalability (LAN to WAN) and downward to move objects from large central sites to less capable distributed sites.  Network management must work in the present of external events and providers.  They need change management and performance.  They need graceful degradation.

Discussion covered the following topics:

We asked why there are so many technology floors to stand on -- OMG, ActiveX, the web, Java, other middleware, etc.  One reason is that there are so many dimensions of requirements, for instance, the need for static versus dynamic solutions, the need for LAN-based and WAN-based solutions, the wide variety of needs for thin or thick security solutions, the degree of support provided by COTS technologies, their openness, granularity, time scales (relative speed of change), and many more.  Some felt that the variety is needed because the solutions for the different combinations require different mechanisms to be integrated.  Others felt that maybe over time we will be able to see how to untangle this so that not every system is some unique manually coded combination of functions and non-functional qualities (what DoD calls stovepipes).  That is the promise of open middleware, after all.

We briefly considered the distinction between applications and infrastructure.  This line is gray today because applications must reach down to meet the middleware floors they are built on, and there is a gap in the form of missing middleware (missing standards and missing implementations).  Also, even when there is less gap, applications often encode controls over middleware policies; and sometimes quality considerations reach up into applications.  The move by OMG (and PDES and SEMATECH) to standardize some domains mean standards that reach into traditional application areas.  We still do not have a good way to insulate applications from their middleware choices.

We discussed designing with evolution and adaptability in mind.  Craig Thompson mentioned that when one designs to meet requirements, it is a good idea to distinguish different kinds of requirements:

What would be nice is to somehow guard against this final category of requirements.  Perhaps we do this by modularizing designs so cross-cutting requirements only affect some portions of the design.  In addition, maybe we can learn how to add or change the binding glue and insert new capabilities into systems via wrappers or other mechanisms that can side-effect the communication paths.  This would leave expansion slots for various kinds of adapters.  This would take us from a view of systems-as-designed to a view of systems-as-continuously-evolving.  In some sense, expansion joints mean looser coupling though performance might be optimized back in.  To some extent, market conditions drive ility needs and change rates.  This also argues to avoid monolithic middleware, though there is a tendency in the vendor community to produce just that -- today's ORB vendor services lock you to a particular vendor; you can't often port services to another ORB implementations.  Rather, we want to compose middleware components for a specific problem and then evolve the solution.  There is unlikely to be a "one size fits all architecture" at least as concretely implemented (though there might be an abstract model like OMA possibly augmented with an abstract ility architecture framework, which might be used to generate and evolve specific concrete architectures.)

Todd Carrico showed a slide of a fat application containing many encapsulated services on the left and a thin application dependent on many explicit middleware services on the right.  One way to interpret the picture is to imagine that we are evolving toward thin applications and richer available middleware so it is easier to build applications based on tried-and-true middleware components and to mix-and-match lighter or heavier weight services and ilities.  Another interpretation of the picture is that it would be nicest to be able to move up and down the spectrum of thick and thin applications without redesigning systems.

We discussed some roadblocks.

I-2 Extending Current Middleware Architectures

Moderator:  Ted Linden, Microelectronics and Computer Technology Corporation

Scribe:  Diana Lee, Microelectronics and Computer Technology Corporation

Topics:  From the viewpoint of middleware architects, where are the critical shortcomings in current technology, what kinds of component-based development can be supported in the future, and what are the additional key architectural concepts, tools, and processes needed to realize this vision. Current middleware architectures like CORBA and COM+ are a step toward compositional architectures, but they do not fully support component-based development and maintenance of large applications. Are current middleware architectures from OMG and Microsoft steps in the right directions? What are the roadblocks in the way of realizing greater benefits?  Problem areas for discussion may include:

Papers

Discussion

This session identified requirements for middleware architectures capable of fully supporting component-based development.  The three introductory papers approached the problem from complementary viewpoints and envisioned similarly strong requirements for middleware architectures: These presentations and the discussions argued that support for component-based development requires more than methods for developing, exchanging, marketing, and composing components. We also need well worked out methods to: Relation between Architecture and Components

Which comes first, architecture or components? Currently components fit within an architecture such as those defined by Java Beans, COM+, or a browser or other product for its plug-ins. Architecture first is consistent with the traditional approach of architecting a system before writing components. However, component technology will be more economical if components can be developed and used in multiple architectures. The ability to wrap a CORBA object, Java Bean, or COM+ object so it can appear in one or the other architectures means that a component does not have to be totally dependent on an architecture. There was a surprising amount of consensus that components should not have to be strongly dependent on a specific architecture. Components are written first, then architectures tie them together. An application that uses components will have an architecture—especially to the extent that the application must support ilities, dynamic debugging, and dynamic reconfiguration. Specific components may interoperate more or less easily within a given architecture; i.e., the wrapping necessary to make a component work within an architecture may be more or less easy.

We asked whether there is a minimum common architecture that can be developed as a way to facilitate reuse of components. Components developed to this minimum common architecture could then be used in a variety of specific architectures. We concluded that it is unrealistic to search for a "minimum common architecture." There are multiple dimensions involved in interoperation, and no one dimension is always most significant. One increases interoperability by increasing architectural specifications. The question "what is the minimal architecture" is better described as "how interoperable do you want the component to be?" and "how much wrapping or rewriting will be needed to make it interoperate within a specific architecture."

Levels of Interoperability:

Compositional Software Architectures must deal with component interoperability at several levels. Interoperability at all levels is especially important for developers of large, long-lived applications that grow incrementally. Development of new products and technologies may, over time, necessitate:

While there are many interoperability requirements, the answer is not in the direction of complex middleware architectures. In fact, there is a desire to make the middleware as transparent to the application as possible. A paper at the workshop, Middleware as Underwear: Toward a More Mature Approach to Compositional Software Development [Wileden and Kaplan], states that middleware "... should be kept hidden from public view ... It should never dictate, limit or prevent changes in what is publicly visible... In most circumstances, it should be as simple as possible." But how does this apply to different middleware products being interchangeable? Is it possible to change middleware in a transparent fashion? Using the underwear analogy, one attendee rephrased the problem "transparent, yes, but it is awfully hard to change your underwear without removing your clothes."

Solutions Toward Interoperability proposed and discussed include:

Obstacles to Component Technology: Other Relevant Issues:

I-3 Challenging Problems in Middleware Development

Moderator:  Bob Balzer, USC/ISI

Scribe:  Kevin Sullivan, University of Virginia

Topics:  This session views component composition from the point of view of middleware developers and system programmers.  The approach is to select one or two interesting system software component composition challenge problems that can be used to identify component software strengths and weaknesses.   Hopefully the challenge problem can be reconsidered from other perspectives in later sessions of the workshop.  Sample challenge problems:

Papers

Discussion

This session focused on the use of composition enablers and inhibitors in the design of middleware systems.  The questions that we addressed included the following: What distributed middleware would be useful for component-based system development?  What information and mechanisms are necessary to enable composition of components into systems, the automation of such composition, and reasoning about such systems?

At a more detailed level, the questions we addressed included the following:

Much of the discussion centered on the issue of metadata as a composition enabler.  Metadata is machine-readable, descriptive information associated with components, connectors, and systems.  A simple example of metadata is the type library information that is often associated with COM components. Such metadata describes component interfaces at a syntactic level. An extension of that kind of metadata might include descriptions of what interfaces are required and provided by a component, and how it expects to interact with its environment. Metadata can be used by programs to reason about composition, properties of components, and even about middleware itself.  What kinds of reasoning and manipulation are supported by various metadata types?

In that dimension, we discussed the following specific issues.  First, the position was taken that we need precise semantics for metadata.  Second, we might use metadata to describe component and system provisions and requirements, e.g., what a component needs in the security area, and what a system needs in the reliability area.  It was noted that security, reliability, etc. cannot be bound to individual objects.  One reason is that desired properties often change as knowledge is acquired over time.  Another reason is that opinions might differ as to when given qualities are good enough.  Third, it was observed that metadata can be attached at many levels of a system.  There is no particular place where metadata annotations necessarily go.  However, there has to be a mechanism to propagate information, so as to enable desired or required levels of control.  Fourth, it was suggested that metadata can be organized through views of complex systems, e.g., a security view, a reliability view, etc.  Fifth, it was suggested that automated "composers" (e.g., class factories, the Software Dock of Heimbigner and Wolf) might use metadata such as figures of merit to compose components to meet given specifications.  Sixth, we discussed the need for type and constraint systems to enable automated reasoning about and systems and compositions from parts.  For example, it can be necessary to reason about which combinations of actions and components are acceptable, and to have ways to name them. For example, there are cryptographically insecure combinations of secure algorithms and techniques. Another example is that adverse interactions at the level of mechanism can have unintended semantic consequences, e.g., pinging for fault detection can interfere with aging-based garbage collection in Internet-scale distributed systems.  We might also want to enable the automatic selection of alternative abstractions and implementations, e.g., in the context of management of quality of service. Finally, it was observed that it is critical to detect mismatches between components and systems and their environments and that metadata might facilitate detection and reasoning about such mismatches.

We also discussed relevant properties of both middleware and systems based on it, although the discussion remained abstract in this area.  One middleware property that we discussed was usability. What can we do to make the middleware itself easier to use?  For example, what middleware metadata would make it easier for developers or tools to understand and evolve systems?

We also discussed inhibitors of composition in component-based systems.  First, it was suggested that we lack fundamental knowledge of what is useful, not just in terms of the metadata descriptions of systems, but even in what basic system properties are important.  For example, what are the key, distinct levels of security in a system?  One person said we have almost no engineering knowledge of what parameters and parameter values are important.  We lack clear definitions of key terms.  Much work in this area is vague and general, and people have inconsistent views of what terms mean.  Second, it was said that most engineering advances are made when failures are analyzed and understood , but that in software engineering failures tend to be hidden, and not analyzed. Third, one person noted that there is little discussion of analysis and formal foundations in this area.  It was noted that Sullivan’s work on formal modeling and analysis of compositionality problems in Microsoft’s COM represents progress in the areas of failure analysis (of sorts) and the formal foundations of component-based software development.  Fourth, it was noted that
although the notion of decomposing systems into functional components and ility aspects is seductive, it might not be possible to effect desired behavioral enhancements without changes to functional components of a system.  Fifth, the competency  of people using components and middleware is (it was said) often questionable or poor.  That idea led to the suggestion that competency requirements for component use might be attached to components as metadata?   Sixth, computational complexity is an inherent impediment whenever semantically rich metadata have to be processed.    Seventh, it was noted that computers are so much more capable than they used to be, and they’re going to get even more powerful, so we need to find ways to control complexity growth. A key strategy, it was said, is to make systems simple so that they work.  Finally, the issue of the diversity of approaches in practice was raised as a practical impediment to the use of metadata.

The participants also discussed the issue of where standards (e.g., for components and metadata) will come from: whether from de jure or de facto standardization? We also discussed some key ways in which software engineering is similar to or different from more traditional engineering disciplines, such as the bridge building.  In particular, we discussed whether the notion of tolerances (close enough), which is critical in the design of physical artifacts, has an analog in the software realm.  Good points were made on both sides of this issue.

We ended the session with a discussion of quality of service.  First, it was noted that discovery of key properties happens at both design and run time.  Second, it was observed that it’s important to avoid a combinatorial explosion in interface types, and so interfaces types are used to discriminate objects down to a certain level of granularity in Microsoft’s COM, below which properties are used as a mechanism for manipulating quality of service parameters (in OLE DB).  Second, QoS specifications can differ, even for a single component.  Third, there need to be generic services for invoking components that provide services.

I-4 Software Architecture and Composition

Moderator:  Gul Agha, University of Illinois at Urbana Champaign

Scribe: Adam Rifkin, CALTECH

Topics:  What is the vision of component composition from the software architecture perspective?  What does software architecture explain and what does it not yet address?

Papers

Discussion

Many fundamental challenges exist when developing software applications from components, among them: Many members of software community have been researching solutions to address these challenges.  Among these efforts: What these systems and others have in common is the meta-model:  customizable components as actors running in given contexts (such as environments with real-time scheduling and fairness constraints), interacting via connectors, which themselves are also first-class actors.  Constraints can be imposed on components, on connectors, and on contexts as well.  As system designers, we can specify protocols over the connectors' interactions with components, and we can specify policies managing the deployment of resources.

As first-class actors, components and connectors are dynamically reconfigurable, and they manifest observable behaviors (such as replication or encryption); a component in isolation in a certain context has an observable behavior that may differ from its behavior when it is composed into a new environment.  This may have a significant impact on the software "ilities" such as quality of service (performance), reliability, and survivability.  However, the lesson of aspect-oriented programming is that some ilities cannot be encapsulated entirely within connectors because they by nature cut across components [6].

It would be ideal to have modular ility first-class connectors that transparently provide appropriate behaviors for interacting components assembled by application developers.  In some cases, this is feasible (for example, the addition of a transaction server to a system designed to accommodate transactions); in other cases, it is not (for example, building recovery into a system not designed to accommodate fault tolerance).

Ultimately, the software component architecture vision is to build a notion of "compliance" on a component so it can work with arbitrary connectors and behave as promised.  Then, compliant components can be plugged together using connectors to achieve a desired (feasible) ility.  For example, under compliance assumptions, a connector can provide a property like passive replication.

The research challenge, then, is to provide formal methods and reasoning models for making clear the semantics of the components both in isolation and interacting through connectors, and for making clear the properties of the aggregate system.  In addition, developers can use tools for performance modeling, runtime monitoring, system configuration, and component feedback cycle tweaking.

We have already witnessed the utility of reasoning models in furnishing specific ilities to specific applications.  For databases, performance is the desired ility (for example, "What will be the size of the query result?"), and research has led to reasoning models for concurrency control and transaction management to address that ility.  On the other hand, for Mathlab, accuracy is a desirable ility (for example, "How much error exists in the answer?"), and research has led to reasoning models of composable algebraic matrix operations for predicting the accuracy of results.

These models and others -- such as atomicity precedence constraints [7] and modular interaction specifications [8] -- demonstrate that research can provide useful models for distributed component software architects. They also indicate that much more research needs to be done -- for example, in the automatic checking of compliance for component validation [9].  When CORBA-compliance alone is not enough to guarantee an ility, solutions can be custom-made; for example, a consortium is working on an object framework for payments [10].  Furthermore, distributed object communities continue to work on the problem of common ontologies to pave the way toward common solutions [11].

In short, the challenges to software component architectures have no generic solutions; however, the abstractions and models developed by specific efforts have led to considerable gains in understanding and guaranteeing properties of systems and their components.
 
[1] http://www-osl.cs.uiuc.edu/
[2] http://www.objs.com/workshops/ws9801/papers/paper023.ps
[3] http://www.objs.com/workshops/ws9801/papers/paper050.html
[4] http://www.infospheres.caltech.edu/
[5] http://www.objs.com/workshops/ws9801/papers/paper082.html
[6] http://www.parc.xerox.com/spl/projects/aop/default.shtml
[7] Svend Frolund, Coordinating Distributed Objects, MIT Press, 1997.
[8] Daniel Sturman, Modular Specification of Interaction in Distributed Computing, available at http://www-osl.cs.uiuc.edu/
[9] Paolo Sivilotti, Specification, Composition, and Validiation of Distributed Components, abstracts available at http://www.cs.caltech.edu/~adam/papers/distributed-components.html
[10] http://www.objs.com/workshops/ws9801/papers/paper021.pdf
[11] http://www.infospheres.caltech.edu/mailing_lists/dist-obj/

II-1 Economy of Component Software

Moderator:  Jay M. Tenenbaum, CommerceNet

Scribe:  Catherine Tornabene, Stanford

Topics:  The purpose of this session is to develop a framework for thinking about what it will take to build an economy of component software.  Why?  to accelerate coming economy of components and possibly to level the playing field for multiple vendors [avoid CORBA vs. DCOM as the central debate]

Papers/Talks

Discussion

See session summary slides (.ppt4).

In this workshop session, the participants examined the issues surrounding the development of an economy of component software.

The session had three presentations:

Robert Seacord - Duke ORB Walker

Robert Seacord's work on the Duke ORB Walker is based on a model of the component software economy that was widely accepted by session participants; namely, a marketplace which will house many heterogeneous components, some publicly available, and some behind corporate firewalls. The Duke ORB Walker is an automated Internet search engine that walks through this marketplace to collect information about software components that are ORB compliant. It is analogous to how current Internet search engines collect information about web pages and web content. Questions to answer regarding the Duke ORB Walker revolve around mechanisms for searching for other component technologies such as COM, JavaBeans, etc. as well as whether the ORB walker will need to rely on an implementation repository to find ORB compliant components.

This talk led to further discussion regarding the essential infrastructure of a software component market. Session participants considered a simple method of finding usable components as a necessary part of the infrastructure of a component-based software market.

Anup Ghosh - Certifying Security of Components used in Electronic Commerce

Anup Ghosh's work examines a method of providing software certification for software components. The underlying assumption of his work with regards to a software component marketplace is that consumer confidence in the -ilities of a software component is necessary to the widespread adoption of the component marketplace. He examines the use of certification as a viable business model for providing security assurance for software components. Under this model, a potential component is put through a series of pre-planned tests. If the component passes these tests, then it is considered security-certified, and thus can be considered ready for the component marketplace.

This talk led to a further discussion of what sort of certification services might exist in a component-based software market. It was largely agreed that not only would certification of a component's -ilities would be essential, but that further semantic certification would be necessary as well. There was great interest displayed in services that might test a component's semantic correctness.

Martin Bichler - Object Frameworks for Electronic Commerce Using Distributed Objects for Brokerage on the Web

Martin Bichler discussed the OFFER project, which is a CORBA-based object framework for electronic (e) commerce. One of OFFER's key components is the e-broker, which acts as an intermediary for e-procurement. The OFFER e-broker assists consumers as they peruse heterogeneous e-catalogs and also acts as a price negotiator using auction mechanisms. The OFFER group is also studying what other functionality might be needed in an e-broker.

This talk led to a discussion about the research question the OFFER group is studying regarding what features might be necessary in an e-broker. Since OFFER is CORBA and Java compliant, there was discussion as to whether the e-broker should be extended to COM, and whether that would be feasible.

Discussion covered these topics:

Market Issues

The fundamental issues surrounding a component software market were effectively reduced to one question: what will people pay for? This question established a framework for our discussion of market issues:

Conceptual Issues & Barriers

After the discussion about the market issues, we then turned to broader issues in the development of a component market that are not purely marketing issues. (Some of the marketing issues were subsumed under these conceptual issues.) We had originally intended to talk about barriers to the component market as a seperate discussion, but that discussion ended up merging with conceptual issues, so they are listed here together.

Good quote:  "Forget REUSE.  Just aim for USE." -- Marty Tenenbaum, CommerceNet

II-2 Component Model Representation and Composition

Moderator: Umesh Bellur, Oracle

Scribe:  Kevin Sullivan, University of Virginia

Topics:  Component models expose information about how a thing is constructed, which is needed for replacing parts and for providing higher order services.  What information should be exposed?  What is the nature of the glue? We are not there yet with respect to mix-and-match, plug-and-play, or best-of-breed.  Give technical reasons why not?  One is that encapsulation hides implementations (which components need to do) but component models expose some information about how a thing is constructed, which is needed for replacing parts.  Component models are just now coming on the scene.

Papers

Discussion

This session focused on what components are, how they are changed, and how they can be designed to ease the evolution of component-based systems.  It was proposed that we discuss what a component is in terms of a programming model (how it is used in implementations), meta-information model (how it is described in machine-readable form), and rules of composition.  It was emphasized that meta-information should be "reified" so as to be machine-usable at runtime.  It was also suggested that we consider the issue in terms of the model of system evolution implicit in the definition of a component.

By way of scoping, it was also noted that composition is not always merely a question of gluing components together; it requires reasoning about system configurations.  We distinguished between design and execution time.  We also asked whether substitutability fits under the component model.

A significant part of the discussion focused on the question, What is a component? Many useful definitions were offered.  It was clear that the question is one for which no single answer (other than it depends) could suffice.  The notion was offered that a component is something that satisfies a given component standard, that there is no one useful standard, that the purpose of a standard is to provide certain defined assurances about the properties of  components that actually conform to the standard, and that the right question is, What assurances do you want from components and systems from built from them to have, and what rules must a standard impose in order to ensure that such properties are obtained?

Among the answers to the question What is a component question were the following: a reusable package of functionality; a unit of manufacture; a unit of distribution; a unit of standardization; a reusable specification/implementation pair (emphasizing the provision of a semantically rich specification along with an implementation); and a unit of software obtained elsewhere (emphasizing that a central purpose of component approaches is to enable construction of systems from parts whose designs are not themselves controlled  by the system designer).

The discussion then turned to the categorization (in terms of programming model, meta-model and composition model, primarily) of concrete aspects of the modern concept of what a component is.

Next we discussed the connection between components and objects.  Is every component an object?  Is every object a component?  If not, then what is it that you have to add to an object to make it a component?  Finally, if a component has to do with packaging, then what is it that’s inside the packaging—an object, or something else, e.g., something more complex than an object?

II-3 System-wide Properties or Ilities

Moderator:  Robert Filman, Microelectronics and Computer Technology Corporation

Scribe:  Diana Lee, Microelectronics and Computer Technology Corporation

Topics:  How does one achieve system-wide properties when composing components. How can we separate application logic from -ility implementation

Papers

Discussion

The Problem: How does one achieve system-wide properties (also known as: ilities, system qualities, qualities of service, and non-functional requirements) when composing components? How can we separate application logic from ility implementation and then weave them together to make a complete system?

Proposals:

Discussion:

What makes an ility?

Ilities have in common the property that they are not achievable by any individual component. It is not possible to achieve an ility internally within a component.

A Partial List of Ilities:

Reliability, security, manageability, administrability, evolvability flexibility, affordability, usability, understandability, availability, scalability, performance, deployability, configurability, adaptability, mobility, responsiveness, interoperability, maintainability, degradability, durability, accessibility, accountability, accuracy, demonstrability, footprint, simplicity, stability, fault tolerant, timeliness, schedulability.  See also Workshop Topics - Ilities.

Which ilities can be achieved in a component system? What makes some harder to achieve than others?

There are some properties of ilities that impact how easily the ility is achieved in a composed system. For example, a security policy for mandatory access-control (which is transitive) is easy to compose. However, security based on discretionary access control uses a user or group id (which is not transitive) and is more difficult.

Composability of policy, where implementation and system architecture are dependent on one another, will also determine if ilities are composable

How do we go from the customer’s high-level description of an ility to specifications that can be mapped to code? Are we really achieving the ilities? For example how do we go from a requirement that a system be "secure" to a code specification for 64-bit encryption? Is this 64-bit encryption really what is meant by "security"?  Conclusions:

Managing compatibility: Can we support hard real-time Quality of Service?

There seem to be two communities interested in hard real time:

Enabling hard real time:  Tools such as Doug Schmidt’s TAO and OMG’s Real Time RFP.  There is a need to guarantee that components obey certain rules that allow for things such as scheduling of services and resources.

Some Other Related Papers:

II-4 How do these fit in?

Moderator:  Gio Wiederhold, Stanford

Scribe:  Craig Thompson, OBJS

Topics:  Few position papers covered the following topics directly but they are challenging, and we'll need to understand them to fully understand architectures and component technology.

Papers

Discussion

We only discussed the first two topics listed above:  modularity and views.

Aloysius Mok - The Objectization Problem

The presentation by Al Mok covered what he called the objectivization problem, that objects effectively set up encapsulation boundaries but that different ilities tradeoff differently, which can often lead to different object decompositions, so that there is not always one best decomposition, or object factoring.

Mok described a problem in real-time scheduling of AIMS Boeing 777 data , which includes process, rate, duration, and latency bounds. There were 155 application tasks and 950 communication tasks. The hardware architecture is a bus plus 4 task processors and a spare, 4 I/O processors and a spare. Such systems are built using repetitive Cyclic Executive processes. The FAA likes this proven technique for building certified systems. Process timings are rounded off. The problem is represented as inequalities and many disjunctions representing many scenarios or choices.  A paper in the RTSS'96 proceedings describes the work.  We noted similar problems in other domains:  In A7 aircraft, every unit is different and can require constant reprogramming. Bill Janssen mentioned that the largest Xerox copier has 23 processors and 3 ethernets with many paper paths to coordinate.

Why show this? You can't solve these sorts of problems by adding more processors. To add a new function to the above system, we need to recompute schedules and possibly even rework the hardware architecture. We want to make it much easier to build, maintain, and validate such systems! Object technology is attractive because of the small address spaces per object, with limited interactions walled off by encapsulation and methods. But tasks participate in other ways than to send messages; they share resources to insure performance.

Mok's work indicates that requirements precede design and are not themselves objectified though design is.  There seems to be a different view for each ility.

Mok showed a use of objects as a unit for resource allocation, integrity management, and task requirements capture. These three roles require different granularities. We need the system to provide these views and automate consistency maintenance among them. The three types of ilities conflict: resource vs. tasks, integrity vs. task, resource vs. integrity.

Favoring different ilities lead to different object decomposition schemes.  One scheme is more amenable to incremental modification, another is more resource efficient, another is more robust against object failures. There is no best scheme due to tradeoffs. Now, when one objectifies a certain solution, then a change in system decomposition is needed to optimize for another purpose. A conclusion is that OO technology makes choices up front regarding ility tradeoffs. Sometimes we take objects too seriously.

Discussion followed the talk.

We seem to agree that the right way to view a system is from the vantage of multiple views (aspects), not a single view.  The power is being able to separate the views when you want to.  A key advantage is separation of concerns.  This leads to a series of puzzles:

In practice today, much of this is manual but it can be automated by UML-like notations, compiler-like technology, and other mechanisms.  One of the promises of middleware today is to use object wrappers around legacy code to turn legacy code into an object.  There are several problems:  it is difficult to make sure there are no interactions, internal modularity that may be present may not be exposed, it is difficult to know the metadata component properties of the opaque legacy code if that code was not built to expose such information (which it was not, almost by definition), and the legacy code does not make or expose explicit guarantees. Still, there can be value in walling off in a standard way the parts of the system, even if only to provide a place to hang metadata.

We are searching for ways to glue parts together that will result in systems that are easy to maintain, more fault tolerant, etc. But the search will likely require going beyond a black box components view of compositional middleware to say more about aspects of the glue, that is, treating the connectors and constraints as first class so we can reason about them.  Today this glueing is mostly done with scripting languages.   Applying this to middleware, what concrete things to we need to do to augment the OMG OMA architecture? Add ilities via implicit invocation. The end result is a pretty tightly coupled system. One comment was to treat views as a constraint satisfaction system, and let the ultimate compiler put them together.  Another comment was that reflection is important. Connectors are meta objects. An architecture is more than nodes and links; it should also be reflective and connectors have state. Andrew Barry mentioned he is working on a connector language where connectors enforce these constraints and might reify the events into methods.

We discussed static versus dynamic aspects of systems.  It is easier to build static systems versus dynamic ones but the latter is the goal. In the firm real time approach, you budget everything you do and know where you are in the budget. Failure in hard real-time systems does not mean the whole system collapses but that some constraints are missed. You want to insure traceability. If you have done analysis at compile time, you don't have to make decisions at run time.

But in several kinds of systems, we also need to accommodate evolution.  In the automobile industry, design lifetime is relatively well understood.  Car designers put in well-defined change points for upgrading to the next model year. Malleability should be a design view. You construct your software so what must be changed should be visible. This is predicated on the assumption that subsystems will be stable. Gio Wiederhold noted that universities do not teach design for maintenance yet the military budget is 70% maintenance, industry is 85%. Thompson referenced his point made in session I-1 that system design is protected against known and foreseen requirements but some unforeseen ones which can cause radical redesign.  One hope is that modularizing a system's functionality and ility aspects can often make future systems more evolvable and adaptable.

III-1 Scaling component software architectures

Moderator: Stephen Milligan, GTE/BBN Technologies

Scribe: John Sebes, Trusted Information Systems

Topics:  What family of design patterns and mechanisms can be used to scale component software -- federation, decentralized or autonomous control, metadata, caching, traders, repositories, negotiation, etc. in this environment.   What will break as we move from ORBs in LANs to ORBs on 40M desktops?  We'll have to replicate services and connect 1000's of data sources, cache at intermediate nodes, federate services, federate schemas, and worry about end-to-end QoS.  What can we say about federation, decentralized or autonomous control, metadata, caching, traders, repositories, negotiation, etc. in this environment.  And don't forget that when we scale across organization boundaries, we have security and firewalls to contend with.

Papers

Discussion

We started by having each person describe their definition of and interest in scalability, which included design scalability, operational scalability, number of components (as software grows in the maintenance cycle), amount of capacity (as number of transactions grow at runtime), control scalability, network management, and survivability.

There were two presentations.

John Sebes - Collaborative Computing, Virtual Enterprises, and Component Software

John Sebes addressed the combination of security and scalability in the context of distributed applications operating between multiple enterprises. He asserted that the scaling factor of number of enterprises has a significant potential for breaking other system properties. He described a technique for cross-enterprise distributed object security, and asserted that component software techniques (especially composability) are required for ordinary mortal programmers to be able to integrate distributed security functions into applications that require them. Scale factors include: number of applications with security requirements, number of users with access privileges to applications, number of rules relating users and privileges to applications, and number of system elements (application servers, firewalls, etc.) that must enforce security constraints.

In discussion, various respondents described related scalability factors:

Electronic commerce was identified as an area of new software development where rapid scale-up will occur quickly in the software lifecycle.

Pitfalls include bad individual components, bad integration of components:  you can break the system at any level. We also discussed that in scaling a component, one must also address the interrelationships (reuse) of that component by other components, and the effect scaling will have on components using the scaled component, resource utilization requirements and the impact on the configuration of the system. There is a general issue of whether components themselves should be responsible for scaling

Venu Vasudevan, Trading-Based Composition for Component-Based Systems

Venu Vasudevan addressed scalability in the context of dynamic service location:  scalability of number of service instances, where there are multiple instances in order to provide service distribution, availability and reliability.  His example was annotation of World Wide Web documents.  Service discovery in this example is discovering services that store and provide annotations to URLs. Multiple repositories might publish information about the annotations that each has, so that other repositories and/or users can find them.  Federations of annotation repositories would be related by a "trading service" (in the CORBA sense of the term, which itself is based on the trader standard from Reference Model for Open Distributed Processing (RM-ODP)) that allows users to find annotations throughout the federation of annotation services.  There are multiple possible approaches to implementing such a trader.  Some solutions are so simple as to be scalable, but also not useful in large-scale systems.  For example, a pure registry-based trader is stateless (and hence does not have to store progressively larger state as transaction scale grows) but can't refine previous request/results because it doesn't remember them.

Discussion followed.

Object composition/delegations was also identified as a scale factor in terms of performance. If an object is composed of multiple other first-class objects, this is inherently higher overhead than an object being composed of components that are "mixed-in" to form the object, but which are not objects themselves. Hence, component composition (in one object, rather than componentified objects calling on componentified objects) may be a promising way to increase the scale of software reuse without getting an exponential growth of objects.

We also discussed scaling issues related to federation. One sense of federation was explored in more detail than some others -- that of linking together organizations/domains in ways so that resources are shared while still retaining the autonomy of the domains system (without relinquishing control over the resources). A definition was "A community of autonomous, freely cooperating sub-communities. Within a federation, one sub-community is not forced to perform an activity for another. Each community in a federation determines resources it will share with its peers, resources offered by its peers, how to combine information from other communities with its own, and resources it will keep private." Autonomous control implies fairly fine grained control over what is shared and what is not, and with who, e.g., dynamically enabling a domain to offer resources for sharing, and to relinquish those resources from sharing, as well as to enter or leave the federation.  Federations allow interfacing for resource sharing among organizations in a way that can slow the growth of combinatorial explosion that would apply with the N-squared bilateral relationships that would apply without federating (a more brittle, complex system of systems). The work currently being done by the Defense Modeling and Simulation Office (DMSO) on their High Level Architecture addresses federation among environments of models; the work of NIIIP addresses federation among Virtual Enterprises; the work of the Advanced Logistics Program on clusters addresses federation of logistics domains.

One of the challenges of trading/brokering/warehousing is the desire to centralize (or to create central repositories) in order to "scale up" the amount of data that can be consistently stored and analyzed. However, this should be virtualized and the ability to migrate (one more ility) from a central repository to a distributed repository should be transparent to the accessing component. When composing components, you don't want to be faced with the choice of relying on centralized control or implementing scalable consistency. Perhaps some part of the glue between components can provide some of the scalability so that component composers don't have to.

Metadata is critical to writing evolvable/scalable components. A component should describe what it wants to use (from other components) rather than referring to what it needs. This seems counter-intuitive (why would I look up my friends phone number every time I call?) but it is an isolation principle that is needed as systems get larger and change. Connectors and their resultant interfacing mechanisms, along with the metadata about components, is the key to enable scalability. But in order to do this effectively, the connectors between components must be defined well enough to include not only syntax, parameters, naming, but also semantics, reusability, side-effects, and other components upon which they are dependent. Further, connectors must be efficient enough to find what is described very quickly in the 99 times out of a 100 when the answer is always the same. Hence, component connectors seem to be critical in terms of making components general enough to be scalable. Here we arrive at the idea of connectors as first class objects. Caching and related techniques/issues (consistency cache invalidation etc.) then become critical infrastructure parts of the glue between components.

III-2 Adaptivity of component software architectures

Moderator: Bob Balzer, USC/ISI

Scribe:  Kevin Sullivan, University of Virginia

Topics:  Is there a common component software framework that allows us to build software that is

P