Executor

From Gcube Wiki
Revision as of 10:29, 26 August 2009 by Fabio.simeoni (Talk | contribs) (Design)

Jump to: navigation, search

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.

ExecutorDesign1.png

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, multi-valued Resource Property (RP) of the WS-Resource and published in all the scopes of the service instance at regular intervals. Task descriptions include the name of the task, a textual description, a set of arbitrary-valued properties, prototypical examples of the task inputs, and prototypical examples of the task outputs. The precise definition of the corresponding RP and the signature of the launch operation can be found in the WSDL of the Engine port-type.

ExecutorDesign2.png


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)