The Programmer Interface

If a programmer wants to add an application that shall be controlled by the execution framework he has to provide an implementation for the task capsule interface. It either comprises the functions that have to be performed in the task or it must contain the communication with an external process that shall now run under the frameworks control. As the prototype system is implemented in C++, the interfaces can be inherited from a class declared in this language (see task capsule interface in figure 56). From the user supplied code an object file is created that can later be loaded dynamically into the framework on each node. Let us now have a closer look at the methods that have to be supplied: preprocess will be invoked before the user supplied body code is executed the first time on the node to which the task has been submitted. Although clones of the task may run on a set of processors, this method is only executed once on the initial site. It can be used to assure that all needed code portions are available and that the parameters are set correctly. Only then, the task will be scheduled locally and to the other specified nodes. Postprocess is performed accordingly, when the task terminates or is terminated from outside. For the body method a polymorphic interface exists. One takes a path to an executable process, the other one takes a pointer to a class member function. The application supplier does not need to provide an implementation for these methods. He uses one of these functions for specifying the body code in the init method. The interface taking a pathname is used when the supplied task should run an external process. In addition to the path to an executable image a handle to which the standard output of this task will be redirected is given. Another handle allows to pass information that is redirected to the processes standard input. If the process expects communication for control through other means, this has to be implemented by the capsule provider. When starting a user supplied function as a thread or a synchronous function call, the interface expecting a pointer to a member function is used. The init method is called on every node on which the task capsule is loaded into the framework. The fini method is invoked, when the task is removed from the system. These methods should be used instead of ordinary constructors or destructors as these do not guarantee that the task capsule is in a consistent state when they are invoked. In fact the capsule can access services provided by the framework, such as the logbook in order to store or retrieve data. However it can only be guaranteed that valid references to these services exist after the capsule has been constructed in the system. At the time at which the init is called it is guaranteed that the references to the execution framework are accessible. The fini is also called before any class destructor, thus assuring that all resources are still available. The suspend and resume methods can be implemented to execute actions when the task is paused or reactivated. This helps to keep the task capsules´ state information while they are suspended from execution. Finally there are two methods dump and stuff to be used for exchanging information between the tasks and the outside world. The user can pass data through the stuff operation to the tasks. It is the capsules responsibility to translate the information that comes in CORBA::Any format into structures that can be understood by the application. It is guaranteed that the data arrive correctly at the local nodes, as they are given in language and platform independent format and transmitted by the component middleware. The implementation of the dump method has to take data from the application and transmit them in a CORBA compliant format back to the operator. The user interface must in this case transform the data into the platform dependent format. As already insinuated, the capsule also has access to the logbook of the system. It can place CORBA::Any data structures in this environment and tag them with with a category identifier. According to the tag the entry is either sent immediately to a data faucet that subscribed to data from a specific task capsule or it is buffered until it is retrieved. In the latter case a data faucet can collect these data when needed. The policy implementations for these push and pull data entities in the logbook can be freely implemented by providing appropriate objects. The current prototyp implementation discards entries in the event that there are no data faucets that have subscribed to information from a specific task. An example is shown in program 57. It represents a system monitoring task. The outlined member function will be registered in the init member of the capsule. It can either run as a thread or as a synchronous function.