Tasks
ACS provides support for tasks.
- A task is a concise program which starts up, performs some processing, and
then shuts down.
- A task may or may not require other more advanced ACS services, depending
on context. Tasks are specifically intended to address the needs of the Offline
team, which needs to be able to implement concise, stand-alone programs which
perform some offline data processing or manipulation.
- It is expected that tasks will often be run from the Unix command prompt
by typing a simple command (task name) plus some additional information describing
the data to be used by the task.
- It is desirable, therefore, that a complete ACS startup scenario not be
required in order to run a task; rather, the running of a task should simply
involve typing a single command at the unix command prompt.
In order to facilitate the requirement of a simple execution mechanism (i.e.
no complete ACS startup required), ACS provides a task mechanism that is able
to run either with or without ACS services being up and running.
In addition, a special "static container" has been developed which allows
the functionality for the ACS container to be linked in directly with the task
executable at compile/link time.
- The static container functionality allows the Task mechanism to adhere fully
to the ACS component-container model while still requiring no complete startup
(e.g. no explicit starting of a C++ container is necessary).
- In the event that ACS services are available, the Task component, using
the linked-in static container, will be capable of operating like a full-fledged
ACS component.
Tasks will often require parameters (see Parameter section), so two primary
types of tasks are provided.
A generic Task interface is provided which defines only a single method, run(),
which must be implemented by the task developer.
A specialization of this generic Task is also provided, ParameterTask, which
extends the basic task interface and allows for both a run()
and a go() method.
In ParameterTask, the run()
method is implemented by ACS and provides support for defining/parsing parameters
passed in via the unix command line, converting the command line parameters
to XML in order to construct a ParameterSet object, and then calling the go()
method (which will be implemented by the task developer).
Architecture and design
The Task architecture is very straightforward.
Two IDL interfaces are defined by ACS: Task, the generic task base class, and
a specialization of the Task base class which adds command-line parameter handling,
ParameterTask.
Both of these types extend from ACSComponent, making them full-fledged Components
in the ACS Component-Container model.
Figure 3.15: Task Component Architecture