When a task capsule is created it gets a unique identifier that is
assigned by the execution framework. It consists of the address of
the node to which this command has been issued, a running number that is
created locally and the name of the subsystem, which can be freely
chosen. MAF does not foresee such automatically created unique
identifiers. We need this feature however, as we must avoid the
possibility of having the same task identifier several times. It can
be compared with an operating system process identifier
that has to be unique throughout the whole distributed system.
The 3-tuple
guarantees
this behaviour and is scalable as well.
Although a task capsule may be cloned to several
other nodes, the clones will always have the same local ID, that is
the one provided at the initial node. In order to control a
task, the user has to specify its local ID and a list of nodes on which the
control operation has to be performed. Such a list can also be passed
when the agent is created. The most important parameter, however, that
is passed with the creation of a new task capsule is the
code base. This is the name of the file that contains the actual
application that is started. It may be an executable or an object file
that can be linked dynamically into the framework. The code base also
contains the full path name to the file. Doing this and having a
network file service relieves us of the necessity to install the
programs on the nodes separately or to pass code, as it is proposed
for mobile agent systems. The problem of code transportation is simply
decoupled from the task execution and can be addressed with whatever
means are appropriate. Whether the programs should be copied
to the local disks or started directly from the network can be
implemented in the policy object that starts a task capsule. Depending
on changing requirements and experienced performance we can adapt our
system. MAF forsees to pass a profile containing quality of service parameters
when creating an agent. It contains the language in which the agent
has been written or which type of data serialisation it uses. These
are items that are of minor importance for our system. We therefore
modified this operation and pass the processing type, the task capsules
priority and so called trigger values.
The processing type allows a choice between whether the
task capsule shall either run synchronously or asynchronously, thus
determining if the task capsule represents an ordinary
function or a thread routine. For system commands that require direct access
to framework internal functions it is also
possible to set a privileged mode. It is up to the task capsule creation
policy object to interpret this parameter. Another property that
is passed upon creation is the time trigger. We derived this principle
of time driven invocation from previous work[Gut96] that
has been shown to be useful in real-world distributed
applications[GSHB97]. The trigger contains a start time, a
deadline and an interval time. All time values can be either given in
abosulte or relative values. These time parameters are not only used to specify
when a program has to execute, but they are also used to support
autonomous error detection. If the framework detects that a task is
not running although its start time has already passed, or if it is
still running although its deadline has passed, countermeasures and
error recovery actions can be taken. The interval can be used to
schedule periodic tasks. Each of the methods specified for the
framework interface is capable of raising exceptions for immediate
feedback. They do not necessarily report on the failure of
the call, but rather inform if the command could not be accepted by
the execution environment. Information about errors can be retrieved from the
logbook, when getting information about the framework status on
each node or when requesting information about a specific task
capsule. Creating a task capsule with a list of nodes is a service request that
is accepted by any node in the processing cluster.
For spawning clones of an already existing task capsule on
other cluster members, a separate operation is provided. It accepts the task
identifier tuple as a constant parameter.