Difference between revisions of "Executor"
(→Design) |
(→Design) |
||
| Line 5: | Line 5: | ||
=== Design === | === Design === | ||
| − | Like all services that can be dynamically extended with plugins, the Executor has a '''plugin manager''' that accepts requests to register or deregister tasks. The requests are not issued by service clients, however. They are issued by | + | Like all services that can be dynamically extended with plugins, the Executor has a '''plugin manager''' that accepts requests to register or deregister plugins with gCube tasks. The requests are not issued by service clients, however. They are issued by the [[Deployer]] in response to the availability of tasks in the infrastructure. The manager persists plugin profiles to autonomically re-register them at each container restarts. |
| − | + | ||
| − | + | ||
[[Image:ExecutorDesign1.png]] | [[Image:ExecutorDesign1.png]] | ||
| + | |||
| + | Clients interact instead with either one of two port-types: the <code>Engine</code> and the <code>Task</code>. | ||
The <code>Engine</code> port-type is the point of contact for clients that wish to launch the execution of a registered task. The port-type is stateful, in that it maintains descriptions of the available tasks. The information is grouped into a single resource, the ''engine'', which is bound to the port-type in line with the implied resource pattern of WSRF. In particular, the pairing of the <code>Engine</code> port-type and the engine resource identifies a singleton WS-Resources. | The <code>Engine</code> port-type is the point of contact for clients that wish to launch the execution of a registered task. The port-type is stateful, in that it maintains descriptions of the available tasks. The information is grouped into a single resource, the ''engine'', which is bound to the port-type in line with the implied resource pattern of WSRF. In particular, the pairing of the <code>Engine</code> port-type and the engine resource identifies a singleton WS-Resources. | ||
Revision as of 09:47, 26 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
Like all services that can be dynamically extended with plugins, the Executor has a plugin manager that accepts requests to register or deregister plugins with gCube tasks. The requests are not issued by service clients, however. They are issued by the Deployer in response to the availability of tasks in the infrastructure. The manager persists plugin profiles to autonomically re-register them at each container restarts.
Clients interact instead with either one of two port-types: the Engine and the Task.
The Engine port-type is the point of contact for clients that wish to launch the execution of a registered task. The port-type is stateful, in that it maintains descriptions of the available tasks. The information is grouped into a single resource, the engine, which is bound to the port-type in line with the implied resource pattern of WSRF. In particular, the pairing of the Engine port-type and the engine resource identifies a singleton WS-Resources.
The Task port-type is the the point of contacts that wish to monitor the execution of a task.
(in progress)
(in progress)
Sample Usage
(in progress)
Sample Task Development
(in progress)
