With a centralised manager approach there exists one computing node in the cluster that is initially elected to be the coordinator. Any command that affects the applications or the execution framework copies in the cluster has to be issued to this manager. It will serialise the requests, check if they are consistent with each other and forward them to all nodes on which the operation should be performed. This manager does not only serve as a unique portal to the system, but also takes care of handling errors that appear in the computing cluster software and cannot be resolved by the applications themselves. Such an approach has several advantages. Due to the implicit serialisation of all requests at a single point, no synchronisation problems occur. If two operators want to issue control operations to the same task, they will not interfere with each other. The result of the operation sequence is not predictable, as it is not defined which operation will be executed first. There is only an agreement upon an order among all participants in the distributed system, as required in [Lam78]. Since all information about the tasks in the distributed system is collected at the manager site, it is possible to check if an operation can at all be performed on a given task. The memory requirement on each node for this approach is low as no state information about applications has to be kept on computers other than the centralised manager. However these benefits come with a list of severe disadvantages, the most serious of which is, that the centralised manager represents a single point of failure in the system. It is not necessarily a hardware failure that paralyses the system and prevents further access to the cluster services: erroneous behaviour on the part of the execution environment software at this site would be sufficient. In this case all information about the cluster´s state, including the registered applications, is lost. Therefore operation cannot be continued without complete reinitialisation. If this includes a survey of the state of the applications in the cluster, the downtime could increase substantially. A countermeasure to this problem can be seen in making the state information on the manager node persistent. This, on the other hand introduces additional processing overhead on the manager. The problems of a centralised manager approach in application control have been mentioned in previous projects for application control in computing clusters[HM96]. It is noted that a centralised approach would not scale to the cluster size needed in our environment. For this we cannot find evidence. It is rather the single point of failure that drives us to find an alternative. So, in order to be capable of reacting to changing requirements or scalability problems, the possiblity of freely choosing implementations for policy objects has to be supported.