CEA Experiences

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

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

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.

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.

6
Common Execution Architecture
Indirect
VOStore
Results Monitor
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

8
Deployment

• Interface schema stable gt 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.

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

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