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