Many fundamental challenges exist when developing software applications
from components, among them:
1. REUSABILITY - How can components be developed for reuse?
2. COMPOSITION - How can new components be assembled from existing
components?
3. CORRECTNESS - How can the behavior of components and the composed
system be specified and guaranteed?
Many members of software community have been researching solutions to
address these challenges. Among these efforts:
1. The Open Systems Laboratory [1] uses the Actors model to define a
system of connectors for managing the protocols and resources needed in
composing reusable components [2].
2. A formal description language can help detect mismatches of
architechtural features when connecting components [3].
3. The Infospheres Project [4] uses temporal logic to reason about the
interactions between the dynamically reconfigurable components
communicating through RPC, messaging, and event-oriented middleware [5].
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 reasoning models in furninshing
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 Matlab, 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/
----
adam@cs.caltech.edu
Forget REUSE. Just aim for USE.
-- Marty Tenenbaum, CommerceNet