Component-based Development of Complex Applications

Ted Linden
linden@computer.org
MCC
West Coast Labs
2099 Gateway Place, Suite 450
San Jose, CA 95110

Abstract

Simple extensions of current industry trends will not lead to successful component-based development for complex applications which require system-wide qualities like reliability, security, quality of service, manageability, and other "ilities." MCC92s Object Infrastructure Project is prototyping distributed system architectures that support ilities by injecting services into the component communications while keeping the application components largely independent of the component interaction architecture.

Problem Definition

There are active commercial markets for components that extend specific products like Adobe Photoshop, Excel, Web browsers, and Visual Basic. Commercial architectures like ActiveX and Java Beans support simple composition of components97mostly for applications characterized by direct user manipulation of the application objects. But for component-based assembly to succeed for long-lived, distributed applications which are not readily modeled as users accessing generalized documents, I propose that there are five key problem areas, and only the first two are being addressed in the commercial marketplace:
  1. Obtaining appropriate components. Assuming the other problem areas are addressed, it will be useful to continue improving the mechanisms for identifying, certifying, and distributing components. Metadata that helps define the functionality, resource requirements, context assumptions, performance characteristics, and other properties of components can help developers select and compose appropriate components. A thriving marketplace in components will also be facilitated by better methods for protecting components against tampering and for compensating component developers.
  2. Connecting components. Within an application, components interact with each other and may interact directly with a user. Simple scripting of component interactions based on syntactic interfaces is available in many forms in the marketplace. ActiveX, Java Beans, and other products also allow components to share screen space and other resources while interacting directly with a user.
  3. Achieving ilities. System-wide qualities are difficult to achieve when assembling components. This position paper and others at this workshop (e.g. [Filman 98]) propose that many ilities can be achieved by injecting additional functionality pervasively into the communications between components. This requires component connections more sophisticated than what is available in the marketplace.
  4. Debugging and fault isolation. Products assembled from components often rely on beta testers and end users to identify and isolate errors. As we move to use components in applications where users are more removed from direct manipulation of the component functions, this becomes increasingly intolerable. Future components and the component connections will want to include instrumentation that detects and isolates errors during both development and deployment.
  5. Life cycle changes. The most revolutionary effects of component-based development will be seen when maintenance, extension, and scaling of an application can be handled by local changes in components and their connections. Strengthening system-wide qualities or ilities (security, reliability, performance) are usually the hardest extensions. When ilities are supported in the connections between components, it will become important to allow the connections to be modified without simultaneouly changing the application components.
This paper summarizes an approach for dealing with the third through fifth problems. It was developed and is being prototyped as part of MCC92 s Object Infrastructure Project (OIP).

Overview of OIP Approach

OIP assumes that the functional requirements of applications are implemented as a set of interacting distributed components. Ongoing industry trends are making it easier to meet functional requirements by buying or building components and assemblying them within the context of an application development framework. The remaining problems are to deal with the unresolved issues of achieving ilities, dealing with faults, and facilitating life cycle changes.

While OIP assumes that the application components are distributed in the sense that each runs in its own address space, this assumption is not strictly necessary. The assumption is valid for most applications of interest to our participants and includes applications built on CORBA, COM+, and Java RMI. The assumption has the advantage that it eliminates many sources of architectural mismatchs and makes it relatively easy to intercept communications between components. Other than the assumption that we can intercept and usually parse the communications between applications components, we try to minimize the assumptions we make about the application components and their interactions.

A research hypothesis of OIP is that most ilities can be supported by inserting services into the communications between the application components. 

Remainder of paper with more details on approach will be available after release approval which is expected in mid-December.