IVOA Recommendation: Universal Worker Service Pattern Version 1.0

The Universal Worker Service (UWS) pattern defines how to manage asynchronous execution of jobs on a service. Any application of the pattern defines a family of related services with a common service contract. Possible uses of the pattern are also described.

💡 Research Summary

The IVOA Recommendation “Universal Worker Service (UWS) Pattern Version 1.0” defines a standardized framework for building asynchronous, stateful, job‑oriented web services in the astronomical community. The document begins by contrasting synchronous, stateless services—where the client must remain connected for the entire duration of a request—with the limitations this imposes on long‑running computations, large result sets, and unreliable network conditions. It then motivates the need for a pattern that decouples request submission from execution, allowing jobs to persist across client disconnects and to be managed independently by the service.

The core of the specification is a set of well‑defined objects that together describe a job and its lifecycle. At the top level is the Job List, a collection of Job resources. Each Job contains exactly one Execution Phase, Execution Duration, Destruction Time, Quote, Results List, Owner, and optionally a Run Identifier, Error, and other metadata. Execution Phase implements a finite‑state machine with states such as PENDING, QUEUED, EXECUTING, COMPLETED, ERROR, ABORTED, HELD, SUSPENDED, and UNKNOWN. Clients can transition phases by sending HTTP requests with appropriate parameters (e.g., PHASE=RUN). Execution Duration specifies a real‑time limit in seconds; a value of zero means unlimited. When the limit is exceeded the service must abort the job, preserving any results generated up to that point. Destruction Time is an absolute timestamp after which the service automatically deletes the job, aborts any running computation, and reclaims storage.

All objects are defined in an XML schema (Appendix B) and are exposed via a REST binding. The specification details the URIs for each resource, the representations (XML, possibly other media types), and the HTTP methods used for reading and modifying them. For example, a POST to the Job List creates a new job, a DELETE on a Job resource destroys it, and a PUT on the Execution Duration allows the client to request more CPU time, subject to service policy. The Quote object provides an estimate of required resources before the job is committed, while the Error object conveys structured failure information. Owner and RunId support multi‑user environments by identifying the job’s creator and execution instance.

Security considerations recommend integration with IVOA Single‑Sign‑On (SSO) mechanisms, enabling services to restrict job creation, inspection, and control to authenticated users. This aligns UWS with the broader IVOA architecture, where it serves as an infrastructure standard used by other protocols such as TAP (Table Access Protocol) and VOSpace.

Section 4 illustrates concrete applications: (1) an image‑service that stages large data products in VOSpace, (2) an ADQL service that returns results via a cursor to handle billions of rows, and (3) a generic parameterised‑application service that can execute arbitrary scientific codes using a common Job Description Language (JDL). These examples demonstrate how a single UWS implementation can be reused across diverse scientific use‑cases by swapping only the JDL and associated metadata.

Finally, the document describes how to build a synchronous façade on top of UWS. A client can invoke a traditional synchronous endpoint, which internally creates a UWS job, polls its phase until COMPLETED, and then returns the result. This approach allows legacy tools to benefit from the robustness of asynchronous execution without code changes.

In summary, the UWS pattern provides a normative, REST‑based contract for managing asynchronous jobs, encapsulating lifecycle control, resource limits, result handling, and security. By separating job description (JDL) from execution mechanics, it promotes reuse, simplifies implementation, and supports scalable, interoperable services across the Virtual Observatory ecosystem.