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:
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/Doc/Presentations/chaimsArchDiagram.ps). The architecture can be loosely divided into four elements:
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.
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.
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.
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.
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.
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.
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:
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.
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
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.