Back to index
CPAM, A Protocol for Software Composition
L. Melloul, D. Beringer, N. Sample, G. Wiederhold,
Stanford CHAIMS project
Composition-only language for composing "autonomous software
megamodules" (think: wide-area web services). Specifies ASN.1-based
data interchange representation and an RPC protocol; noncompliant
modules must be "wrapped". A client-side compiler takes the composition
language (CLAM) as input and generates a stub with all the right magic
to invoke, schedule, monitor, etc. the interaction of the remote
- Scheduling: support provided (at "compile time") for intelligent
scheduling of megamodules based on dataflow analysis and the
assumption that an asynchronous (nonblocking) invocation exists.
Some support for wrapping this around blocking services is
provided in the current toolkit.
- Stub generation is interesting but seems like a lose to require
"recompiling" when service-side interfaces/semantics change. A
versioning/verification scheme, such as used in HTTP, might be
- Don't assume CPAM compliance as the normal case and stub
generation as the intermediate/exceptional case! Stub generation
is precisely one of the hard problems. By assuming it out of
existence, CPAM diminishes its own potential impact.
- Need to compare to other approaches. In particular: the data
and protocol heterogeneity handling in CPAM are just a
reimplementation of RMI/CORBA/your favorite RPC.
- The interesting parts are the scheduling/monitoring parts. It
would be cool to build a "CPAM on TACC" module: Perl is already a
big superset of CLAM, so should be "easy" to provide the CLAM
primitives as TACC library functions. The interesting part is to
automate stub creation so that stubs for data interchange,
parameter mapping, etc. are either built on the fly, or pulled
from a library that maps servers to generic stub types (for
example, WIDL-compliant servers could all be handled by a single
stub). In this scenario, rather than using full-blown Perl as
"composition language", you'd use the (mostly declarative?) CLAM
and get the benefit of reasonable scheduling. All the machinery
for doing asynchronous requests, timing them out, etc. already
exists in TACC.
Back to index