110 likes | 229 Vues
The Universal Worker Service (UWS) presentation at the IVOA interoperability meeting in Kyoto, May 2005, outlines the WSDL contract and semantics of job-based services. UWS facilitates asynchronous execution of work, utilizing Job-Description Language (JDL) for instructions, thereby ensuring stateful interaction with individual jobs. The presentation discusses the benefits of UWS, such as increased code reuse, improved workflows, and its aptness for long-running processes. Various issues concerning UWS implementation and integration with existing frameworks, including CEA and grid standards, are also examined.
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?