Difference between revisions of "Executor"
(→Design) |
(→Design) |
||
| Line 11: | Line 11: | ||
Clients interact instead with either one of two port-types: the <code>Engine</code> and the <code>Task</code>. | 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 | + | The <code>Engine</code> port-type is the point of contact for clients that wish to launch the execution of registered tasks. The port-type is stateful, in that it maintains descriptions of the available tasks in a single resource, the ''engine''. The engine is created at service startup, when it subscribes with the plugin manager to be notified of plugin registration and de-registration events. It is then bound to the port-type into a WS-Resource accessible to clients via the implied resource pattern of WSRF. The task descriptions are modelled as a single Resource Property of the WS-Resource and published in all the scopes of the service instance at regular intervals. |
| + | |||
| + | [[Image:ExecutorDesign2.png]] | ||
| + | |||
The <code>Task</code> port-type is the the point of contacts that wish to monitor the execution of a task. | The <code>Task</code> port-type is the the point of contacts that wish to monitor the execution of a task. | ||
| Line 17: | Line 20: | ||
(in progress) | (in progress) | ||
| − | |||
(in progress) | (in progress) | ||
Revision as of 09:55, 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 registered tasks. The port-type is stateful, in that it maintains descriptions of the available tasks in a single resource, the engine. The engine is created at service startup, when it subscribes with the plugin manager to be notified of plugin registration and de-registration events. It is then bound to the port-type into a WS-Resource accessible to clients via the implied resource pattern of WSRF. The task descriptions are modelled as a single Resource Property of the WS-Resource and published in all the scopes of the service instance at regular intervals.
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)
