OneCompute Concepts
This page explains the core concepts that are specific to OneCompute and necessary to understand in order to use OneCompute.
Flow Model
To perform computational work in an efficient manner, the work load typically needs to be decomposed into individual pieces of computational work that can be performed independently. Subsequent execution of these pieces may require some orchestration, both to ensure that work is performed in the correct order, but also ensuring that work that can be done in parallel is executed in parallel when computational resources are available. This logic, which is application specific, is referred to as the workflow semantics.
The purpose of the OneCompute Flow Model is to enable the client application to model its computational work load (including its work flow semantics) in such a way that allows it to be executed autonomously by an external, general-purpose Back End service.
Job
The Flow Model construct representing the entire work load is the Job. The Job can be decomposed into constituent units, referred to as Work Items, that can be executed individually. In many cases, there will be dependencies between work items, i.e. some items cannot execute until other items have completed. In general, these work items form a directed graph, where each node in the graph, here referred to as a Work Unit, corresponds to a particular computation to be done. Represented this way, the Job contains sufficient information to allow the One Compute Job Scheduler to orchestrate the execution of individual Work Items on the Back End platform.
Work Item
Work Item is an abstract concept that has several specializations known as Work Item types. The different work item types allow the application defining the job to express the workflow semantics of the job, such as work item dependencies. When one work item A depends on another work item B, it expresses that A can only execute after B has completed successfully.
The current OneCompute Flow Model allows composite work flows to be modelled using the following Work Item types:
| Work Item Type | Description |
|---|---|
| WorkUnit | An atomic unit of computational work. |
| ParallelWork | A collection of work items that can be processed independently. |
| SequentialWork | A collection of work items that must be processed in a strict, ordered sequence. |
| FlowGraph | A Directed Acyclic Graph (DAG) of WorkUnits with explicit dependencies. |
A Work Unit can carry arbitrary application data (which must be serializable to JSON) through its Data container.
A Work Item can be in one of several states:
| Work Item State | Description |
|---|---|
| Pending | The work unit has not executed yet. |
| Executing | The work unit is currently executing. |
| Completed | The work unit has executed and completed successfully. |
| Faulted | The work unit has executed and completed with a failure. |
| Aborted | The work unit started execution, but execution was cancelled by the user. |
The Completed, Faulted and Aborted states are referred to as terminal states, meaning they represent the state of an activity that has been terminated.
Result
The Result is a "sibling" of the Work Unit. It wraps application specific output data from the Worker in its Data container. When the Worker completes processing the Work Unit, it returns a Result.
Actors
The main actors in the performance of computational workflows (jobs) are
- The client application initiating the job
- The OneCompute job scheduler orchestrating the execution of the job
- The application worker executing the application specific computational work prescribed by the job
A few supporting actors are needed:
- The computational backend, which is a service that provides computational resources and activates the application worker on request by the job scheduler
- Worker Host: An adapter between the Computational Backend and the Application Worker, activating the worker with designated computational work
- Permanent File Store: The service providing permanent file storage for file-based work
- File Transfer Service: The service orchestrating transfers of files between the actors
Client Application
The client application initiates a job and obtains its results. A client application in this context can be
- A native application (desktop, mobile, console)
- A web application
- An application service
- A Python script
Job Scheduler
The OneCompute JobScheduler is a core component of OneCompute that supports scheduling and monitoring computational work defined using the Flow Model. After receiving a job submitted by a client application, it schedules the execution on the Back End service and monitors the status of the individual work items during execution. For complex workflows with dependencies between the work items, the job scheduler will ensure that the work items are scheduled in the correct order (see Job Orchestration).
Job Orchestration
Job orchestration means controlling the execution of work units in ways that preserve the logical work flow constraints expressed in the job:
- Work units in a SequentialWork must be executed in sequence.
- A work unit with explicit dependencies to other work units cannot execute until all dependencies have executed successfully (Status = Completed).
Computational Backend
The OneCompute back end refers to the services that process the work units and run the computations. See Back End Platforms for more details on the back end environments that are currently supported by OneCompute.
Application Worker
The Worker is an application component that runs on the Computational Back End and processes Work Units. See the Architectural Overview for more information. The Worker is invoked by a OneCompute Worker Host. Upon execution, it receives a WorkUnit as input and may return an application object containing result information. The Worker is agnostic about the environment it runs in and is portable across different Back End platforms.
Worker Host
The Worker Host is a OneCompute component that runs on the Back End. It acts as an adapter between the Computational Backend and the Application Worker. Its responsibilities are:
- Upon request, retrieve the WorkUnit from storage.
- Download any files specified as input to the work unit from permanent file storage using the designated File Transfer Service
- Load the Worker.
- Let the Worker process the Work Unit.
- Capture status and progress information from the worker and record it.
- If the Worker returns a result, wrap it in a Result object and store it.
- Upload any files defined as output files by the work unit to permanent file storage using the designated File Transfer Service
The WorkerHost is specific to a particular Computational Back End platform. The separation of responsibility between the WorkerHost and Worker enables platform dependencies to be handled by the WorkerHost, making the Worker portable across different Computational Back End platforms.
Permanent File Store
The Permanent File Store provides storage resources for permanent storage of files. In a cloud environment, such as Azure, it would be a blob storage service. In an on-premise environment, it would typically be a network file store.
File Transfer Service
The File Transfer Service orchestrates efficient transfer of files between the actors, more specifically between:
- The client application and the permanent file store
- The application worker and the permanent file store