The Correlate project is already ongoing for several years. In this page, we give a small overview of the Correlate history and how the different versions have evolved.
The XENOOPS project (1990-1995) was the precursor to Correlate. XENOOPS stands for an eXecution EnviroNment for Object-Oriented Parallel Systems. In this project, we tried to build a set of class libraries that made it easier to develop parallel programs for distributed memory architectures.
XENOOPS supported single parallel applications designed according to an object-oriented approach. The environment was based on a global object space; application objects can interact by means of location independent object invocations. The programming paradigm is called Object Parallelism. This paradigm unifies both data and functional parallelism by encapsulating data and operations into a single active object. Such an object --called a Work Unit-- is an abstraction of a fraction of the work that must be performed by the application. All work units reside in the global object space. XENOOPS maked the global object space efficient through dynamic load balancing.
XENOOPS provided a generic environment: an application writer was able
to refine, adapt, augment XENOOPS to the specificities of his application.
This gave an application writer the possibility to realise high performance.
XENOOPS achieved this property through an object-oriented architecture
based on a class hierarchy.
A prototype of XENOOPS has been implemented in C++ on a cluster of
DEC Alpha workstations on top of the Mach microkernel (a port exists on
a transputer system (Helios) and on Sun Sparc workstations).
One of the main differences between Correlate and XENOOPS is that Correlate takes a language-based approach. Instead of offering the application programmer a class library, a language extension is presented that integrates object-orientation and concurrency in a concurrent object-oriented language.
Correlate 1.0 mainly concentrated on the language aspect. C++ was extended with a set of keywords (very much akin to the current set) to integrate concurrency with the language. A prototype parser that automatically translated Correlate to C++ was developed in Tcl. The complexity of C++ resulted in a far from trivial parser that was very hard to maintain. In addition, many programming conventions needed to be adhered to by application programmers in order not to break the model.
The execution environment supported distributed execution on a cluster of workstations. A migration mechanism was implemented that allowed active objects to migrate. The execution environment was closed; open implementation techniques and metaobject protocols were not yet implemented. The prototype was written in C++ for DEC Alpha workstations on top of Mach and for Sun Sparc workstations running Solaris.
Correlate 2.0 featured a more uniform language (for instance synchronization for construction and destruction of objects) and had explicit support for distribution. The new operator had an additional parameter that indicated on which host the new object should be allocated. A migrate operator was defined that when called migrated an object from one host to another.
The translator was completely rewritten. A frontend parsed the Correlate source files and generated C++ source code together with a symbol table. The symbol table was used by the backend to generate the rest of the C++ source code. The frontend, which was by far the most complex, was developed in C++ based on an automatically generated parser skeleton. This skeleton was generated using the Purdue Compiler Construction Tool Set (PCCTS). The backend was still in Tcl. The new parser eliminated the need for many of the programming conventions but could not hide all.
The execution environment was opened and supported a metaobject protocol for behavioural reflection. The MOP defined a default MetaObject class that could be redefined by the application programmer. The MOP allowed a number of interesting application specific policies to be inserted in the execution environment. For instance a checkpointing algorithm and a simple message encryption protocol were implemented. However, many decisions were still locked up inside the default MetaObject class and could not be changed. A replication algorithm was for instance almost impossible to implement. In addition, support for multi-level reflection was lacking.
In Correlate 3.0, a transition was made from C++ to Java. The Correlate language syntax was adapted to get a better integration with the Java syntax. A new parser was developed completely in Java based on the JavaCC parser generator. The life of the application programmer improved dramatically as many intricate aspects related to C++ disappeared.
The language was also simplified and all explicit notions of distribution were eliminated. In our view, distribution aspects should be treated strictly separated from the logical model of the application. Explicit language support for object allocation and migration leads to a mix of these aspects with the conceptual application code and is therefore not appropriate in this approach. Allocation and migration is done by a specialized metalevel that implements the distributed environment.
The metaobject protocol is much improved. The notion of a default MetaObject class that can be refined using inheritance was discarded. Instead, the metalevel programmer is offered a set of simple metaobjects that need to be composed instead of extended. As a result, the metalevel programmer has much more freedom and is much less constrained by the default implementation. Reflection on multiple metalevels is also supported.
This version adds the ability to provide application-specific information to the meta-level with the use of property templates and policies. The details are described in a paper that was presented at the Reflection'99 conference (see the publications section).
The general idea here is to divide the task of creating a distributed application into three subtasks. One task will just write the application purely based functional requirements. In a second task, one or more meta-levels are developed that address non-functional requirements. This task also involves the definition of a template, describing what policy-decisions an application still can take. The last task will combine the results of the two previous tasks. This involves setting of specific policy requirements for the application objects, providing a glue between the base-level and the meta-level.
This version of correlate has two new tools to compile template and policy files, and adds a small interface to the meta-level for obtaining policies for a specific base-class.