Use Case Descriptions

Figure 53 gives an overview of the most important use cases in a distributed application control system. For finding a general architecture, we abstracted already away from concrete operations on programs and reduced them to control, configuration and information request commands. A detailed design document for an application control system would list all possible operations separately. An overview such as we present is adaptable to a broader spectrum of systems that are not only limited to data acquisition. Indeed we see that a system management tool for a distributed data acquisition system can be used in any kind of distributed system. The converse however is not true, as the requirements are normally not that demanding in other domains. So we see another advantage of not having hardcoded rules: if we encapsulate the implementation of a command in an object that can be provided to the system at run-time, an application steering framework can be tailored to fit the problem domain under investigation.

• Control tasks is probably the most important use case in the system. An operator issues commands to the application control system. These may affect the system itself or the tasks that run in the processing cluster. The commands have to be translated into the correct internal calls by the user-interface. Examples for application commands are a start of a new process or a suspend operation. A command that concerns the system is e.g. to register a new processing node with the cluster.

• Get information is used to retrieve information about tasks. This command can be routed either to the user application tasks or to system internal tasks. The former flow is observed if the operator wants to inspect some log data that have been written by an application. If information about the system´s operational status is required the second flow is taken. As for this split of functionality different attributes might be of importance, this use case is internally split up into two later. It is the data faucet´s responsibility to prepare the obtained information in a system independent way. The user interface will pick this data set up and render it according to its functionality.

• Configure system affects only the framework in which the applications run. System policies, i.e. privileged task capsules, can be downloaded and registered with the system. The system will make use of these policy objects to perform its application steering tasks. An example is the way in which commands that affect applications are distributed among the computing nodes. Sometimes a centralised approach may be used, but in order to study alternative solutions one would also like to implement a complete distributed approach. To do this, only the objects that contain the knowledge on how to transmit commands have to be exchanged.

• Encode information into system commands. This use case of the data faucet is invoked whenever the operator interacts with the user interface in order to perform an action. The user interface has to translate the operator commands into language that is understood by the data faucet. In order to cover a wide range of different platforms and implementation languages for user interfaces, the system interaction language shall follow a widely accepted standard and be platform and language independent

• Display Information is dual to the previous use case. It translates data coming from the application control system into a format that the user interface can interpret.

• Create/destroy data faucet. This use case is invoked when an operator establishes information with the control system or when he quits working with it. In the beginning a data faucet is created at some computing node in the cluster. From now on an association between an operator and the cluster is established. The data faucet is location transparent, i.e. the operator can not determine on which node of the cluster it is created. It might also migrate to another node if the initial one fails. As the system allows for disconnected operation, the data faucets can be destroyed each time the operator disconnects from the cluster.

• Send command to task capsule. This use case invokes one of the operations offered by task capsule. The commands are predefined and only a small set exists. It comprises commands that affect the execution of the task, such as suspend and resume. The command will be issued only to one node. It must hosts a copy of the affected task capsule. How the commands are then distributed to the other copies is defined in core policy objects that have to be loaded into the system before. Appropriate feedback about success or failure shall be given.

• Send system command. This is a command to the interface that is exhibited by the application control system. It is used for registering new task capsules, shuting down the whole system or the like. Internally the commands are forwarded to task capsules, just like user applications, but with special access rights. A minimal set of system commands shall be defined by a system interface. For the sake of extensibility a more general interface for accepting a system command that activates the specified system task capsule shall be provided.

• Deliver a report is used whenever a task or the system has to provide information to the operator. These contain status reports about the systems operation and buffered task capsule output.

• Access logbook is used by the task capsules and the data faucet. tasks, i.e.: applications or system core policy objects write information to it that shall be made persistent in order to keep track of the system´s operation. The data faucet uses it to read this information upon an operator information request.

The following use cases are the ones that can be invoked by task capsules in order to perform functions on behalf of the user. Some will not be caused directly, but due to the implementation of special policies. An example is the distribution of a task capsule start. The user will invoke a start once. The task capsule that is responsible for implementing this policy will subsequently cause the invocation of system control operations on other nodes in the cluster. These will again trigger the activation of a local start task capsule.

• System control operation is a use case which may invoke several system internal functions. It does not affect a running application, but the application steering system itself. Through this use case it can be configurated. Adding nodes, new policy objects are some examples for this.

• Task control operation affects the applications. This also includes the creation of new processes or application threads on single farm nodes. The task control operations are executed in policy objects.

• System information request can be issued to get information about the status of applications on a node or a computing nodes configuration.

• Task information request is targeted at a specific application task capsule that is active in the cluster. The policy object forwards the request to the application that has to provide the information.

The requirements derived from these use cases can be summarised as follows: (i) The system must be configurable so that software modules (applications or system commands) can be added and removed at any given time. (ii) It must be possible to control and monitor applications at any time. (iii) The system must allow disconnected operations. This involves the timed execution of commands as well as the capability of reacting autonomously in erroneous situations. (iv) The system has to be scalable, both in terms of tasks running in the system and the number of participating cluster nodes. (v) In order to be independent of user interface technologies we also require the system to support a system independent interface.