Overall DR-EA-M Architecture

• User A does not wish to use the DREAM for conducting experiments, but simply wishes to donate their spare CPU time or monitor the experiments of others. This type of user, interacts with the DREAM only through the Console, other types of user use the console and (normally) one other user entry point.

• User B is either not an experienced programmer or wishes to rapidly prototype a system without the need for textural programming. This type of user interacts with the GUIDE layer which allows distributed evolutionary algorithms to be defined using a fully graphical interface. The GUIDE interfaces with the EASEA layer through the use of the EASEA language.

• User C programs the system through the EASEA layer, which provides a high level textural language in which to program distributed evolutionary algorithms. This layer produces Java code through a compiler. The code it produces uses the objects and methods of the JEO (Java Evolutionary Object) library.

• User D programs directly in Java and makes use of the JEO library. The library not only provides useful objects and methods for evolutionary computing, but also provides an API (Application Programming Interface) to the DRM (Distributed Resource Machine) core layer.

• User E is an expert user, who programs using the DRM API directly. This level of user can use the DRM for many useful distributed processing purposes beyond evolutionary computing, but is not fully protected from the complexities of this type of programming.

EASEA Screenshot

Collective Model

The collective model defines quite clearly what kind of applications the DRM is good for, what are the limitations the application has to tolerate and what is the overall component structure the application must have, The basic concepts of the model are illustrated below.

Note that it is not the model of the DRM, it is the model of an application that can be run on a DRM, this is what the DRM is designed for. The basic idea is that the application consists of a set of contributors that work to reach a goal and produce some sort of contributions in order to make it happen. Contributions are stored in a contribution repository. This repository can be read by the contributors. A contributor can use others’ contributions to produce higher quality contributions. The repository can also be written: when a contribution is ready, it can be submitted to the repository. The contributors that work on reaching a goal, form (or connected to) a collective. It is the collective that works as an interface for the read and write operations. In other words a contributor has to be a member of a collective to be able to read/write the contribution repository of that collective. Through the collective, a contributor can also read a command database which contains commands issued by the controller of the computation. The contributor is supposed to execute these commands. A collective can have two other types of members. The observer can only read the contributions and commands but it is not allowed to submit anything. The controller is the only entity that is allowed to write to the command database.