Revision as of 16:17, 10 February 2010

Execution Plan

For a client of the ExecutionEngine to be able to formally describe the plan that he wants to execute, the constructs offered by the Execution Plan are used. These constructs have the following main pillars.

• Configuration

  Every plan is potentially one execution unit for the execution engine. Each plan while executing can request different parametrization.

• Variables

  Tha variables defined in a plan are the common data placeholders through which the elements of the plan exchange data.

  • Data Types

    Each variable is typed and this type describes the different characteristics of the data exchanged.

  • Parameters

    Each variable is accessed through defined parameters. Parameters are distinguished by their direction and processing.

    • Filters

      Each parameter can provide either direct access to its underlying data or perform a number of elaborate filtering tasks before retrieving or storing data to its underlying Parameter and Data Type

• Execution Tree

  The plan hierarchy is composed of a number of elements that control the flow and the actions of the plan

Execution Events

Every plan created and executed, follows a life cycle which in every point is updated and reported to the client through the use of events. These events follow the Observer / Observable pattern and the defined events that are emitted during the execution life cycle are:

• Execution Started

  Event emitted when the execution is initiated

• Execution Completed

  Event emitted when the execution is completed either successfully or not

• Execution Paused

  Event emitted when the execution is paused by the client

• Execution Resumed

  Event emitted when the execution is resumed after being paused by the client

• Execution Canceled

  Event emitted when the execution is canceled by the client

• Progress Report

  Event emitted from internal Plan Elements reporting on the progress of their execution

• External Progress Report

  Event emitted from external invokable which has been invoked by one of Java Object and Web Service reporting on the progress of their execution. This is only feasible if the invoked Java object or Web Service is declared and implemented to use an Execution Context.

• Performance Report

  Event emitted from internal Plan Elements reporting timing andf performance statistics on their operation

The Progress Report and Performance Report events can be requested to be omitted if the client requests using the Plan Configuration

Execution Context

The Execution Engine from the time it receives an Execution Plan and starts execution it, it creates a context within which the whole execution takes place. This context enables monitoring of the execution tree, event propagation and management. Since the execution may have to be moved to multiple execution containers through Boundary Elements this context remains synchronized across multiple hosts through control Channels. Every partial execution instance initialized in every execution container acts as the original context for the specific container, and through the control Channel synchronizes its state with the ones it is paired with.

This scheme works well for the Plan Elements that operate in the context of the engine. But since the context is an internal to the engine structure, it cannot be used by external components such as Java Objects and Web Services invoked through Java Object and Web Service elements respectively. To cover this gap and to allow for external component to offer a more integrated with the engine service, Java Objects and Web Services may also ,with the trade off of being coupled with the execution engine at compile time, receive an execution context construct. Through this they can emit progress events, be notified for execution life cycle, as well as receive parametrized values that they may need during their operation and can be better initialized externally.

For Java objects, which are initialized in the same address space as the one the engine that invokes it, the context kept by the engine is wrapped and passed to it. For Web Services, a new control Channel is initialized in the caller side, an identifier to it is created and passed with the SOAP envelop header with the call made. In the Web Service side, the execution engine provides utilities to retrieve the SOAP envelop piggy bagged information, instantiate en execution context construct, which from then one takes care of synchronizing it self with the caller side.

Invokable Profile