1. CEA Experiences
Paul Harrison ESO

2. What is CEA? Common Execution Architecture
Way of describing how to run an “Application”
Web service interface
Application parameter model
Used to invoke
Used to describe application in Registry
A Specification and an implementation
Victoria IVOA Interoperability Meeting
06 May 2019

3. Why CEA?
Original motivation was to be able to run legacy applications in a workflow - e.g Sextractor - lead to following requirements
SOAP web service - provides widespread interoperability
Asynchronous - single execution longer than typical http protocol timeout.
Callback mechanism
“Job” Identifier
Provide standard mechanism for redirecting results to VOSpace
Victoria IVOA Interoperability Meeting
06 May 2019

4. Why not something else? Wanted to add astronomical semantics
Have possibility for parameter types that are part of the Data Models.
Wanted more sophisticated Parameter model
Outputs
Indirection to/from VOSpace
Wanted to create a façade on top of general computer science standards to protect upper software layers from change.
Victoria IVOA Interoperability Meeting
06 May 2019

5. Common Execution Architecture
Single contract to run all applications
Actually 3 WSDL interfaces
CommonExecutionConnector (server implements)
Initialize job
Set callbacks
Execute job
(optionally) get Job status
(optionally) get results
LogListener (client implements)
ResultsListener (client implements)
Unified description of application and parameters
Simplifies programmers job
Caller has only understand one set of WSDL
To publish an application only one description need be created - can potentially be re-used in many ways.
Victoria IVOA Interoperability Meeting
06 May 2019

6. Common Execution Architecture
1.Initialize
2. Register Listeners
3. Execute
JobID
Indirect
Log Monitor
The client can be workflow engine, workbench etc.
Results monitor and log monitor could be the same - are web services
VOStore
Results Monitor
Victoria IVOA Interoperability Meeting
06 May 2019

7. Common Execution Architecture
Can be used to build things in a VO compliant fashion
CEA servers
“commandline” - for VO enabling legacy commandline applications
http - to act as a proxy in front of legacy http get/post applications
Database - connects to databases - ADQL queries
Java - contains the mechanics of CEA to enable you to write pure java app.
Clients
Workflow
Workbench
Add links…
Workbench means that can run remote application from scripted commandline….
Victoria IVOA Interoperability Meeting
06 May 2019

8. Deployment Interface & schema stable > 18 months
Installed base of 50 CEA servers
UK, France, Russia,
~ 70 applications available
Datasets – FIRST, INT-WFS, Ledas, SDSS,
Images – GOODS, HST-UDF, SDSS, XMM, Merlin
Legacy applications – SExtractor, HyperZ, Galaxev, Pegase, BPZ, Swarp, GNUPlot, R
New applications – solar movie maker
VOTechBroker, developed within VOTech project, distributes CEA style requests onto “big” grid systems - Globus, Condor.
Victoria IVOA Interoperability Meeting
06 May 2019

9. Relationship to UWS Latest UWS (0.2) document makes this clear
Follows the UWS pattern closely
Asynchronous
Stateful
But does not use all the WS-Resource infrastructure for job identifiers, and does not use WS-Notify for callbacks
There is an upgrade path that would keep all of the schema that make up the application model, but would require new WSDL to comply with WS-Notify and WS-Resource
Victoria IVOA Interoperability Meeting
06 May 2019

10. New developments Add Synchronous execute Add “session” concept
State saved over several execute cycles - needed to wrap legacy applications suites like IRAF or AIPS - or indeed the ADQL with cursor user case
Parameter model extensions
Vector parameters
Repeating parameter groups
Constant parameters
Would be good to have a new type of CEA server implementation that could submit to Grid engines
Victoria IVOA Interoperability Meeting
06 May 2019