110 likes | 225 Views
Universal Worker Service. Guy Rixon to GWS-WG at IVOA interoperability meeting, Kyoto, May 2005. Definition. UWS defines a WSDL contract and service semantics for job-based services. ‘Job-based’ means that: Service executes work asynchronously, (‘in batch’)
E N D
Universal Worker Service Guy Rixon to GWS-WG at IVOA interoperability meeting, Kyoto, May 2005
Definition • UWS defines a WSDL contract and service semantics for job-based services. ‘Job-based’ means that: • Service executes work asynchronously, (‘in batch’) • Service takes instructions in a Job-Description Language (JDL) document, not like an RPC. • Service is stateful and provides a way to interact with individual jobs.
Why UWS? • More code reuse, because standard WSDL contract • Good for workflows, because job-step defined by a document in a job-description language • Good for long-running activities, because job-steps run asynchronously • Good for connecting to grids, because semantics are inherently grid-like
UWS is abstracted from CEA v1 • Job-description language (JDL) • WSDL contract • Standard semantics for job-based service • IVOA resource schema for job-based services • IVOA resource schema for applications • Application-description schemata (used in JDL, resource schemata and local configuration) UWS is the WSDL, the semantics and maybe the service-resource schema. Part of CEA v2, maybe. It needs a JDL but need not use the one from CEA v1.
Why change CEA v1? • Easier to implement: refactored to use WS-RF • More features in WSDL contract, e.g. run-time estimation, checkpointing/restarting • More flexible: spec’d to work with JDLs other than the CEA one.
Why not use a grid standard? • Good question! • There aren’t any, yet: • OGSA neither finished nor implemented. • Others are de facto, not de jure and not multi-vendor • Grid stuff doesn’t cover all of CEA: • Application registration. • Application description for UI. • Application libraries with mirror servers. • …and we’d like to go on using CEA, please.
UWS issues: shall we proceed? • Do we want any standard for async. Activities? • Would we rather bless CEA v1 without mucking it around? • Do we want some other way of doing this stuff? • If we go ahead with UWS, who wants to work on the prototypes and spec?
UWS issues: operation set • Is the command set in the v0.1 spec. sufficient? • Is it sane? • Is it too much? (Should we make more of it optional?)
UWS issues: pluggable JDL • Is it sensible to have a WSDL that allows any JDL? • Is it better to have one WSDL per JDL, but to keep to a common pattern? • If the latter, should we refactor into a common port-type plus one port-type per JDL.
UWS issues: registration • Is the CEA application/service split OK, or do we need a different arrangement? (Q.v. forthcoming data-model team in Registry-WG) • How do we say “this service is a UWS”? • Do we have a resource type for UWS? • Is this different from ceaApplicationType? • How do we say which JDL a UWS is using? • Do we have one resource type per JDL? • Q.v. one-WSDL-contract-per-JDL idea.
UWS issues: data grid • CEA depends on AstroGrid MySpace. • Should UWS depend on the data grid? • On the VOSpace layer? • On the VOStore layer only? • NB: CEA v2 must handle the data grid. • Is data-grid handling pluggable along with the JDL?