The Common Execution Architecture (CEA) is an attempt to create a reasonably small set of interfaces and schema to model how to execute a typical Astronomical application within the Virtual Observatory (VO). In this context an application can be any process that consumes or produces data.
The CEA has been primarily designed to work within a web services calling mechanism, although it is possible to have specific language bindings using the same interfaces. For example Astrogrid has a java implementation of the interfaces that can be called directly from a java executable.
The primary motivating factors behind creating this architecture are;
The design for this architecture was started as part of the Workflow/Job Execution System within astogrid
The astrogrid implementation is discussed here
The above sequence diagram illustrates how the various components of the CEA system interact when an application is executed. This is initiated by the
Some point of note;
This is the main interface that is used to communicate with the application. The main methods of are (please note that there are some extra methods defined in the WSDL that are defined for experimental purposes)
The WSDL definition of this interface is stored in cvs at http://www.astrogrid.org/viewcvs/*checkout*/astrogrid/workflow-objects/wsdl/CommonExecutionConnnector.wsdl?rev=HEAD
The WSDL definition of this interface is stored in cvs at http://www.astrogrid.org/viewcvs/*checkout*/astrogrid/workflow-objects/wsdl/JobMonitor.wsdl?rev=HEAD
As this model depicts an application in CEA is really quite a simple entity consisting of 1 or more interfaces that consist of 0 or more input parameters and 0 or more output parameters.
The schema representation is shown below, and is essentially a representation of the UML model that has been coded to recognise that the same parameter can occur in several interfaces.
The description of the parameters and the parameter values are probably the heart of the CEA. It is the model for the parameters that allow us to add semantic meaning, and to give the flexibility in how the parameters are transported. The implementation is still in its infancy, but it is hoped that the parameter definition will be extented to encompass any data models that the VO produces.
The basic parameter definition from the schema is shown below
The parameterValue model is simple but powerful the parameterValue element has 3 attributes
Note that the current implementation has the type and transport attributes combined as one - so that there can be a type of MySpace_VOTableReference for instance - the full implemnentation will have them separated as described above for more flexibility.
The schema associated with the CEA fall into two categories
These schema are strongly interelated, which aids programming with automated object generation tools. The schema associated with CEA are described below with links to their documentation
|Filename (with cvs link)||Description||Documentation|
|AGApplicationBase.xsd||This schema defines most of the basic CEA objects that are imported into both the WSDL and the Registry Schema||Documentation|
|VOCEA.xsd||This defines the VOResource extensions of CeaApplication and CeaService that are used in the registry||Documentation|
|AGParameterDefinition.xsd||Contains the basic parameter definition and parameter value elements used in the other schema||Documentation|
|Workflow.xsd||This schema actually describes an astrogrid workflow document in full, but as part of this is the tool element that is passed in as a parameter to the execute method in the CommonExecutionConnector method. This tool element will be factored out into its own CEA specific schema in future||Documentation|
This deployment shows some of the features of using the CEA