Package org.apache.taverna.workflowmodel.processor.dispatch

Definition and support classes for the Dispatch Stack.

See: Description

Interface Summary

Interface	Description
DispatchLayer<ConfigurationType>	Layers within the dispatch stack define a control flow to handle dispatch of jobs from a queue (generated by the iteration system) to appropriate activities.
DispatchLayerFactory	Factory for creating DispatchLayer instances.
DispatchStack	The dispatch stack is responsible for consuming a queue of jobs from the iteration strategy and dispatching those jobs through a stack based control flow to an appropriate invocation target.
NotifiableLayer	If a layer requires notification of the arrival of new items to the event queues within the dispatcher it should implement this interface.
PropertyContributingDispatchLayer<ConfigType>	Used by dispatch layers which can contribute property information to their parent processor instance.

Class Summary

Class	Description
AbstractDispatchLayer<ConfigurationType>	Convenience abstract implementation of DispatchLayer
AbstractErrorHandlerLayer<ConfigurationType>	Superclass of error handling dispatch layers (for example retry and failover).

Package org.apache.taverna.workflowmodel.processor.dispatch Description

Definition and support classes for the Dispatch Stack. Each processor in a workflow contains a stack of dispatch layers with each layer being responsible for a particular aspect of the invocation. At a high level the stack consumes a queue of events from the iteration system along with an initial set of service proxy objects and is repsonsible for taking jobs from the queue and matching them to appropriate invocation targets.

Taverna 1 has in effect a single hardcoded dispatch stack for each processor with little control over it aside from a few basic properties. To replicate the same behaviour within Taverna 2 there are dispatch layers for parallelism, retry, failover and invocation. As the dispatch layer is an extension point we or others can provide other aspects such as recursive invocation and dynamic (runtime) binding from abstract service proxies to concrete instances. The last is possible because the service list is passed through the stack along with the queue or individual job events and can be rewritten or filtered by dispatch layer implementations.