Software for Composition: CHAIMS
A Position Paper for OMG-DARPA-MCC Workshop on Compositional Architectures
Catherine Tornabene, Pankaj Jain, Gio Wiederhold
Database Group, Computer Science Department
Stanford University, Stanford CA 94305
The objective of our project, Compiling High-level Access Interfaces for
Multi-site Software (CHAIMS), is to develop a novel programming language,
which focuses on large scale composition of legacy and compliant modules.
In the CHAIMS project we are developing both a programming language
and an environment in which such a language could operate. Megaprogramming
is both a process and a technology of programming by composition. Our focus
is the megaprogramming language which is needed to provide the organizational
glue needed to make use of services provided by many remote, heterogeneous,
and often large, software modules. We refer to such modules as megamodules,
as we expect these modules to provide the functionality that large service
organizations such as reservation systems and transportation systems currently
provide.
We consider a megaprogram to be a clearly defined collection
of instructions to control multiple service requests that will execute
on multiple, heterogeneous computers. Such requests are composed to achieve
a common goal. A megaprogram must control not only multiple invocations
but also adapt to diverse client-server interface standards such as CORBA,
DCE, ActiveX/COM, or JavaRMI.
Megaprogramming has become feasible because we now have these interface
standards, so that we do not have to develop a novel language, novel interfaces,
and a novel infrastructure in concert, and hope for a revolutionary adoption.
The CHAIMS approach does require that the megaprogram it compiles must
manage multiple invocations of diverse standards.
Megaprogrammers will specify desired services using the megaprogramming
language, but we neither expect nor require megaprogrammers to be fluent
in traditional programming languages or interface protocols. Megaprogrammers
will only concentrate on how to best to complete the task at hand using
a set of available megamodules. They will specify the composition, not
the computing details.
Given the novel setting of megaprogramming, we have created the CHAIMS
language to be as simple as possible. The language is typeless and solely
compositional. Furthermore, the CHAIMS language is as parallel as possible,
in keeping with our observation that task execution in the real world (versus
the computing world) is often parallel.
One of the means by which the CHAIMS language supports compositional
programming is by decomposing the traditional call statement into more
specific primitives. This decomposition achieves three objectives:
-
it reduces the complexity encountered when remote calls invoke realistic,
large, and complex modules with many parameters, options, and conditions.
-
it increases the flexibility needed to deal with the natural asynchronousness
of the parallel operation in a setting of distributed computations.
-
it greatly reduces the bandwidth requirement incurred in traditional programming
in which every call has to port and receive state information to and from
the remote server module.
In the original definition of the CHAIMS language, the traditional CALL
statement was split into six primitives: SETUP, ESTIMATE, INVOKE, EXAMINE,
EXTRACT, and TERMINATE. We have since discovered that SETUP should be split
yet again, into two statements such as CONNECT and SET_ATTRIBUTES. These
changes may affect other primitives as well, since the reference handles
are now more flexible.
The architecture of CHAIMS is designed to facilitate the asynchronous
composition and reuse of services in a heterogeneous environment. (There
is a diagram of the CHAIMS architecture located at http://www-db.stanford.edu/CHAIMS/slides/chaimsArchDiagram.ps).
The architecture can be loosely divided into four elements:
Service Modules
The service modules available for use exist independently of CHAIMS. Some
are in existence already, motivated by the need to support legacy code.
Others will be developed, some with knowledge of CHAIMS (and thus support
native CHAIMS primitives) and some with no knowledge of CHAIMS. Wrapper
services will provide translation between CHAIMS primitives as specified
by the megaprogrammer and services which do not support native CHAIMS primitives.
We refer to a service as a megamodule, as we expect these services to be
large, typically remote, and operating autonomously.
Wrapper
A wrapper facilitates the translation of messages in the CHAIMS language
to the interface the megamodule provides. Some megamodules may support
only synchronous invocation. In such cases the wrapper also provides the
infrastructure such that the wrapped megamodule appears to support asynchronous
invocation to the outside world.
A wrapper need not reside at the same site as the megamodule. Furthermore,
the distribution layer protocol between the CHAIMS client and the wrapper
and the wrapper and the megamodule will often be different. A single wrapper
can be used for more than one megamodule and in such cases it will provide
a variety of useful mediation services in addition to the functionality
already mentioned above.
Distribution Layer
The distribution layer, which is used to convey the sequence of CHAIMS
primitive messages generated by the CHAIMS compiler to the desired megamodules,
can be one of many possible distribution protocols developed for client-server
systems. Examples include CORBA, DCE, DCOM, JavaRMI, etc. Any distribution
protocol can be used, as long as there is a runtime library which allows
the CHAIMS compiler to create the appropriate interface to the distribution
layer. The distribution layer is of no concern to the megaprogrammer but
is the element of the architecture most critical to distributed computing
and thus forms a major component of the CHAIMS architecture.
Application Megaprogram Written in CHAIMS
The CHAIMS compiler takes the program specified by the megaprogrammer and
generates an appropriate sequence of CHAIMS primitive messages compliant
with the distribution layer being used. The compiler also optimizes the
sequence. Note that the various megamodules may be using different distribution
layer protocols so the messages generated by the CHAIMS compiler may be
in different protocols depending upon which megamodule is involved.
Current Work
Our work has focused on defining the CHAIMS architecture and environment
as well as writing an initial version of the CHAIMS compiler. We have written
a compiler which compiles CHAIMS language megaprograms into IONA CORBA
client code which can then be used to interact with remote CORBA servers.
This compiler is currently being extended to generate DCE interfaces, and
eventually Microsoft COM (Active-X) interfaces as well.
In order to test our compiler, we have also written several sample megamodules
which can successfully interact with the CORBA client code that our compiler
emits. Having the compiler allows us now to experiment with the novel concepts
in CHAIMS, as we are doing with the CALL statement decomposition and the
parallel execution of megamodules.
We have developed a simple output module and have designed mathematics
modules. These will be compliant to the CHAIMS architecture. For data transmission
among megamodules we will use the ASN-1 standard.
We have looked at several component technologies in the past year, including
CORBA, JavaBeans, DCE, and ActiveX/COM. In keeping with our examination
of commonalities between component technologies, we are currently examining
the use and architecture of wrappers which can translate CHAIMS client
code into a variety of server invocations.
Other Work in the Field
Since megaprogramming is a new concept, it is necessary to distinguish
CHAIMS from some of the other work in the field. Though the CHAIMS compiler
generates CORBA stub code, we do not consider CHAIMS to be an effort in
automatic programming. The client code generated is created specifically
for the wrapper and is not optimized for anything other than composition.
We do not generate large programs, only the necessary stub code. CHAIMS
is not an Architecture Definition Language (ADL), even though a CHAIMS
megaprogram can be viewed as an instantiation of an architecture. The task
of inferencing an instantiation from an ADL specification, if any, is the
task of the megaprogrammer, and not automated by us. Finally, CHAIMS sits
above the level of distributed object services such as CORBA. We use the
functionality such services provide without exposing the megaprogrammer
to the details of distributed object programming.
Conclusion
The development of a language for composition brings several novel issues
to the forefront. While CHAIMS is still a programming language, it is intended
for an end user who is not a programmer but rather is a specialist in logistics,
or in emergency rescue planning, etc. It may in fact be unsuitable for
a person trained in conventional programming, since the inherent parallelism
of the real world operations may be natural to a practitioner, but upsetting
to an individual trained in converting the world into a serial sequence
of stops, where an independent event is undesirable.
Our position, as evidenced in our work, is that it is important to develop
and get experience with actual composed software, even if the assembly
is procedural, and limited by available infrastructure resources. This
experience will become the basis of further work in two directions:
-
from the top: improved languages and automated interpretation of specification.
-
at the foundation level: optimization of the execution and dataflow for
distributed composed systems.
We see CHAIMS as potentially providing an infrastructure to move from an
architecture to an executing system. Fundamentally, the CHAIMS project
aims to harness the power of software reuse and composition that distributed
protocols and large modules support.
Acknowledgments and Further Information
The CHAIMS project is supported by DARPA/ROME through the EDCS program,
order number D884, grant number F30602-96-2-0223. The DARPA Program Manager
is John Salasin and our COTR is Roger Dziegel. Some further support is
provided by Siemens Research in Princeton.
More information, including papers and a demo, can be found at http://www-db.stanford.edu/CHAIMS
The CHAIMS group may be reached by sending mail to chaims@db.stanford.edu
References
B. Boehm and B. Scherlis: "Megaprogramming"; Proc. DARPA Software Technology
Conference 1992, Los Angeles CA, April 28-30, Meridien Corp., Arlington
VA 1992.
L. Perrochon, G. Wiederhold, R. Burback: "A Compiler for Composition:
CHAIMS"; Proc. Fifth International Symposium on Assessment of Software
Tools and Technologies 1997, Pittsburgh PA, June 3-5, 1997.
G. Wiederhold, P. Wegner, S. Ceri: "Towards Megaprogramming: A Paradigm
for Component-Based Programming"; Communications of the ACM, 1992(11):
p. 89-99.