Revision as of 11:05, 11 February 2010

Variables

While in the process of executing an ExecutionPlan, the two main actors, are the elements that represent an execution step, either by controlling the flow of execution or by invoking some processing actor, and the second is the data that are provided to the actors as well as the results produced by these actors. This data is usually also the target of the execution. The data is stored as typed structures using the engine available Data Types.

Wherever a plan element needs to define some association with some data stored in such a Data Type it references it using a unique name. Data Types are generally encapsulated as Named Data Types. This encapsulation provides some additional metadata on the Data Type. This metadata include a unique name by which the data are referenced. Additionally a grouping tag can be applied to a data type which can be used by some Filters that operate on this data. Finally, a flag indicating that the data is available for usage is also included so that while in execution, no element will try to use some data that is not yet available.

Named Data Types are considered as the Variables of a running execution plan. One of the ExecutionPlan's root elements is a collection of Variables. These provide a global placeholder for all Plan Elements to retrieve data from as well as to store data so that they are later on used by either a different Plan Element or to be returned to the client. Access to this global collection is moderately supervised. This means that while the underlying data structures are protected from concurrent modifications, the actual synchronization is performed mainly by the access and timeplan dictated by the ExecutionPlan's execution tree.

This for example means that if two Plan Elements share a variable, having one of the elements produce a value that is placed in the variable and the second element accessing it, the correct access to the variable is mainly enforced by the execution path that connects the two elements. If the the producing element is defined in the plan as a child of a Sequence node, and the consuming element is also a child of this element or some other element that preserves this ordering, the access will be safe. In the case though that for example the two elements are direct children of a Flow element, there is nothing ensuring that the consuming element will access the variable after the producing element. As a last line of defense, the engine provides the above mentioned flag indicating that some variable is initialized and populated. This way some cases of mis-usage can be avoided and the execution stopped before corrupt data are used.

XML definition

<variables>
  <ndt available="..." name="..." token="...">
    <dt .../>
  </ndt>
  ...
</variables>

Parameters

Access to Variables and their underlying Data Types is never performed directly from the Plan Elements. Access is always performed through Parameters. Parameters are distinguished based on their direction and the processing they are performing on the Variable and underlying Data Type before storing or accessing the actual data.

Based on the direction, Parameters can be separated to:

• In parameter

  Data can be retrieved using this parameter

• Out parameter

  Data can be stored using this parameter

• InOut parameter

  Data can be retrieved and stored using this parameter

Based on the processing, Parameters can be separated to:

• Simple

  Direct access to the underlying data is enabled

• Filter

  Before retrieving, or storing, the parameter will apply a number of Filters

Filter parameters contain an ordered list of Filters. Every time such a parameter is requested to retrieve or store some data, it goes through the list of filters. After all the filtering steps are completed, the value is retrieved or stored depending on the parameter direction. At every intermediate filtering step intermediate data are produced which depending on the definition of the filter may also be stored.

XML definition

<param direction="In" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="Out" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="InOut" process="Simple">
  <variable name="variable name"/>
</param>"
...
<param direction="In" process="Filter">
  <filter .../>
  ...
</param>"
...
<param direction="Out" process="Filter">
  <updateVar name="variable name"/>
  <filter .../>
  ...
</param>"
...
<param direction="InOut" process="Filter">
  <updateVar name="variable name"/>
  <filter .../>
  ...
</param>"

Filters

One of the constructs that make the Execution Plan versatile and allows for generic Data Type transformations are the Filters described in this section. These filters can be used to compose filtered input and or output Parameters. This provides for on the fly transformations of Variables to be used by any Plan Element or for bulk "off line" processing using Processing Elements. The available filters come in a long range of complexity and applicability. These filters are presented in this section.

All the filters described bellow offer two common properties other than the additional ones each one of them provide. Firstly, they have the notion of order, in the sence that they can be composed in an ordered list to be sequentially executed. This way two or more filters can be composed to create more complex filters which can be found in filtered Parameters. Secondly, as will become evident from the following listing, in some of the filters, the attributes of Name and Token as presented in Variables and Data Types are utilized during the filtering process. There is an option to override the meaning of some of these Names and Tokens to alter the outcome of these filters. More will be presented in the filters that this feature can be utilized.

XSLT

The XSLT filter is the simpler and most powerful filter offering the possibility to apply a provided XSLT trasnformation on some Variables's payload. The outcome of the transformation is available at runtime and can also be requested to be stored in some Variable.

XML definition

<filter type="XSLT" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable>
  <tokenMap/>
</filter>

XPath

The XPath filter is another simple filter offering the possibility to apply an XPath expression on some Variables's payload. The outcome of the evaluation is available at runtime and can also be requested to be stored in some Variable. The outcome of the evaluation can be declared of being either a primitive value to be interpreted directly as a string literal or an XML fragment which in order to be stored needs to be serialized.

XML definition

<filter type="XPath" order="..." storeOutput="true/false" storeOutputName="...">
  <queryResultType>String/Node</queryResultType>
  <filteredVariable>...</filteredVariable>
  <expressionVariable>...</expressionVariable>
  <tokenMap/>
</filter>

Object Convertable

The Object Convertable filter is applicable only to Variables of Data Type Convertable or Array with a component type of Convertable. In the former case, the respective converter is loaded and the Object that corresponds to the serialization stored in the provided Variable is inflated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the Array Data Type. Every position of the generated array is filled with the Object inflated by the Convertable in the corresponding Array position.

XML definition

<filter type="ObjectConvertable" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <tokenMap/>
</filter>

Object Reflectable

The Object Reflectable filter is applicable only to Variables of Data Type Reflectable or Array with a component type of Reflectable. In the former case, the serialization provided as the values source is processed to be used along with the target Object type that is to be populated with these values. The target Object type is provided also as an input Variable of type String containing the qualified type name. The respective Object is inflated, populated and retrieved. In the later case, an array with a component type of the respective inflated Object is created with as many dimensions as dictated by the Array Data Type. Every position of the generated array is filled with the Object inflated by the Reflectable in the corresponding Array position.

XML definition

<filter type="ObjectReflectable" order="..." storeOutput="true/false" storeOutputName="...">
  <filteredVariable>...</filteredVariable>
  <targetReflectableVariable>...</targetReflectableVariable>
  <tokenMap/>
</filter>

Serialization

Reflectable From Template

Reflectable To Template

XSLT From 1D Array

XSLT To 1D Array

Compose

Decompose

External