CPAM, A Protocol for Software Composition

One-line summary: 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 megamodules.

Overview/Main Points

• 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 preferable.

Relevance/Commentary

• 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 the TACC "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.