Difference between revisions of "Executor"

From Gcube Wiki
Jump to: navigation, search
(New page: The Executor acts as a container for '''gCube Tasks''', i.e. functionally unconstrained bodies of code that lack a network interface but are designed and packaged to be executed by the ser...)
 
Line 1: Line 1:
The Executor acts as a container for '''gCube Tasks''', i.e. functionally unconstrained bodies of code that lack a network interface but are designed and packaged to be executed by the service and to be dynamically deployed as the payload of its plugins.  
+
The Executor acts as a container for '''gCube tasks''', i.e. functionally unconstrained bodies of code that lack a network interface but can be dynamically deployed into the service and executed through its interface. In particular, gCube tasks are designed, packaged, and deployed as ''plugins'' of the Executor service.  
In essence, the service publishes descriptive information about dynamically acquired tasks, can execute them on demand on behalf of clients, and can inform clients on the state of their execution.
+
  
Clients may interact with the Executor service through a library of high-level facilities that subsume standard service stubs to simplify the discovery of service instances and the execution of tasks through those instances.
+
An instance of the Executor publishes descriptive information about the co-deployed tasks, can execute them on demand on behalf of clients, and can inform clients on the state of their execution. Clients may interact with the Executor service through a library of high-level facilities that subsume standard service stubs to simplify the discovery of service instances and the execution of tasks through those instances.
 
+
=== Functionality ===
+
 
+
The functionality of the service comprises the static and the dynamic management of tasks:
+
 
+
(in progress)
+
  
 
=== Design ===
 
=== Design ===

Revision as of 20:12, 25 August 2009

The Executor acts as a container for gCube tasks, i.e. functionally unconstrained bodies of code that lack a network interface but can be dynamically deployed into the service and executed through its interface. In particular, gCube tasks are designed, packaged, and deployed as plugins of the Executor service.

An instance of the Executor publishes descriptive information about the co-deployed tasks, can execute them on demand on behalf of clients, and can inform clients on the state of their execution. Clients may interact with the Executor service through a library of high-level facilities that subsume standard service stubs to simplify the discovery of service instances and the execution of tasks through those instances.

Design

The design of the service is distributed across two port-types: the Engine and the Task.

(in progress)

The Engine

(in progress)

Tasks

(in progress)

Sample Usage

(in progress)

Sample Task Development

(in progress)