In the agent pattern we found a suitable means for addressing the requirement of an evolvable system. The task that shall be run in the processing cluster is encapsulated by a narrow interface (see figure 54). This task capsule [Gut99] resembles an agent and has to be provided by the application programmer. Once submitted to the execution environments on the cluster nodes, the specified interface is solely used to control the applications. The environment forms a framework for the task capsules. An instance of the framework is available on each node of the cluster. The operator sends commands to a data faucet object. Data to and from the system runs through this pipe; it serves as the interface to the outside world and takes care of calling the required framework functions on the specified locations. Once a framework receives a command for an application it forwards it to the appropriate task capsule, that can either be a user or a system task. This capsule acts as a proxy for the actual application and there exists one instance per capsule type for each running application. It is not necessary that the application has to run in the scope of the framework process. As the capsule is just a proxy it is quite conceivable that upon creation an external process is started. Commands that shall affect the application must be forwarded to it by the capsule. This is exactly the behaviour that is expected from an agent: transparency of operation through autonomoy. The agent knows how to carry out a task, it is sufficient to trigger this action. The policies that determine how commands are sent from node to node and how they are scheduled or performed shall not be hardcoded[Jar96]. This is a strong requirement that we impose in order to have a framework that we can adapt to the needs of different application scenarios. Thus, the system commands are put into capsules as well. These are scheduled to an active object that executes them. Queueing them to such a scheduling object guarantees local serialisation of the system commands. This eases the task of coping with commands that origin from different sources.
In the current prototype the policies are not exchangeable at runtime. New policies can be provided as object files at linking time. Although the applications that are controlled by the system can either be threads, synchronosly called functions or external processes, the task capsules representing proxies to the actual tasks, are always processed in the context of the execution framework. They are not submitted to the same scheduling object as the system commands in the current prototype design. We did this for two reasons: first, applications can be equipped with quality of service parameters including priority and timing information that are not relevant for system commands. On the contrary, system commands should be executable independently of the applications. Therefore we included two schedulers in the execution framework on each node. Our experience with the prototype however showed that it would be easily possible to collapse the properties of these two different command types and have a single, more powerful scheduler for both task capsules.
The framework makes use of the CORBA distributed componentware in order to achieve platform independence. The OMG alrady proposed an interface for a mobile agent facility [Gro97b]. We adopted this draft specification as a baseline and extended it for our needs. The OMG aimed at an interface for a generic mobile agent facility. We want to provide a task execution framework, thus requiring a slightly different, yet more specific interface. In addition to the execution framework, implementations for the core policies are provided in the prototype. As an example for command distribution we chose a decentralised management scheme that does not rely on a central point of control. Commands can be sent to any node in the system. The responsible policy objects take care of forwarding them to the required destinations. To synchronise tasks in such a fully distributed approach, a synchronisation algorithm that does not need a central locking authority has been developed. It is decribed in section 6.4.3. The structure of the framework on each computing node is shown in figure 55. The core comprises two task execution queue objects. One called method object queue, is used for scheduling policy objects that are created when users request operations. The other deals with the execution of user application of task capsules. This queue is modelled as a timer heap allowing periodic and priority driven invocations. Before a capsule can be started, a policy object that is responsible to perform the insertion into the timer heap has to be created and is submitted to the method object queue. Thus all commands concerning tasks and the functionality of the local framework copy can be serialised. The active object[LS96,Car98] pattern has been applied for this design.
Let us briefly summarise the key issues of the designed protoype task control system:
