CommandLine Application Configuration

The Commmand line Execution Controller is a component that can be used to wrap legacy command line applications in a specialized CEA web service so that it can become part of the VO.

Command Line Application prerequisites

For the CEA Command Line Execution Controller to be able to run an application, it must fit into the model of a commnand line application that the CLEC understands. Amongst other characteristics, it must be possible to run the application to completion with arguments supplied on the command line.

Characteristics of the application that cannot be supported include

  • requiring user input from a GUI
  • requiring a GUI to display results
  • requiring user input of any kind after execution had been stated

The command line application parameters should be specified by one of the "standard" unix methods

  • by position
  • by a switch of the form -param value
  • by a switch of the form param=value

It is possible that an application that does not quite meet these requirements in a small fashion could be acommodated by writing an adapter class so

Configuration File

This file should be of the same form as this example configuration file which has AGApplicationBase.xsd as its schema.

<CommandLineExecutionControllerConfig> that contains <Application> elements (you will have one for each of your scripts) - each of the <Applications> has a set of <Parameters> and one or more <Interfaces>. For this type of CEC we need to define a series of <CmdLineParameterDefn> elements corresponding to each of the command line parameters that there are. For command line applications parameters are typically specified in one of 3 ways under unix and the CEC can cope with any of these (theoretically in any combination, but I have not exhaustively tested this, and I doubt that I have covered everything)

Each <CmdLineParameterDef> has a set of attributes that specify which of the above categories the parameter falls under, as well as some subelements that further specify the parameter.

name - this is the name of the parameter - the default behaviour is that this name is the same as the string that is used to denote the parameter on the command line (if there is one) - however you can give the parameter any name you like (as long as it is unique for a particular application as you can specify the name that is used on the command line using the commandSwitch attribute. Alternatively you can specify the position of the parameter with the commandPosition attribute if there is no switch. type - this specifies what type the parameter is as well as how the CEC should find the parameter - so it might be just string - if the parameter is a string that is passed directly, or MySpace_FileReference if the paramter is actually a reference to a file in MySpace. (Note that the use of this parameter has changed quite a bit in iteration 6 - I am describing the iteration 5 situation). You should look in the schema http://www.astrogrid.org/viewcvs/*checkout*/astrogrid/workflow-objects/schema/AGParameterDefinition.xsd?rev=HEAD&content-type=text/plain at the definition of the parameterTypes simple type for the full list of allowable types - but they are mostly the obvious atomic types as well as a few special types for fetching things from MySpace.

The elements that can occur within the <CmdLineParameterDef/> are

<UI_Name/>
the name that will be used in the portal for the parameter
<UI_Description/>
a description of the parameter that will be used in the portal
<UCD/>
the ucd for the parameter if it has one - at the moment nothing uses this.
<DefaultValue/>
can be used to display a default value in the portal
<Units/>
can be used to specify the units in the portal.

An <Interface> is simply a collection of parameters - you might have a simple interface that consists of only one of the possible parameters and a complex one that consists of all the possible parameters. Each interface consists of a number of <input> and <output> parameters (designated by the pref element that points to the <CmdLineParameterDef> above) - This classification is particularly important in the case of parameters that specify MySpace file references, as this is how CEC knows whether to fetch the values of put them.

Writing a custom adapter class

Global CLEC Configuration

To see information for configuring the CLEC itself see ....