ExecutionPlan Variables
Contents
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.
The way the processing is performed to inflate the target Object is sketched at the Data Types section. The token mapping facility is utilized byt this filter ad affects the process described there. The inflation process described finds a member of the inflated object named using the common part of matching getter and setters. If at the populating Variable an item with the respective name is found, that it6em is used to set the respective value. In case a token mapping set is defined, this mapping will be used to replace the name of the Object's member with tha target name defined in the mapping if one exists for that name.
XML definition
<filter type="ObjectReflectable" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <targetReflectableVariable>...</targetReflectableVariable> <tokenMap> <map key="source name" value="target name"/> ... </tokenMap> </filter>
XSLT From 1D Array
The XSLT From 1D Array filter bases its operation in XSLT transformations. A default transformation is available, but it can be overridden to offer different functionality. The default functionality aims at transforming an input Variable of Data Type Array to an xml serialization that can be presented as an array of values with an element name of the set of values as the one provided.
This filter is applicable in the following cases:
- If the default transformation is used and
- Source is array and target is set and not array
- Source is array and target is set and is array
- Source is array and target is not set
- If the default transformation is overridden and
- Source is array and target is set and not array
- Source is array and target is set and is array
- Source is array and target is not set
- Source is not array target is set and is array
In the following cases the filter cannot be applied:
- Source is not array and target is set and is not array
- Source is not array and target is not set
The default XSLT is the following:
<?xml version=\"1.0\" encoding=\"UTF-8\"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:for-each select="dt/value/array/item/dt/value"> <$$tagValue$$><xsl:value-of select="."/><$$tagValue$$> </xsl:for-each> </xsl:template> </xsl:stylesheet>
XML definition
<filter type="XsltFrom1DArray" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <expressionVariable>...</expressionVariable> <!-- optional overriding XSLT --> <valueTagVariableName>...</valueTagVariableName> <tokenMap/> </filter>
XSLT To 1D Array
The XSLT To 1D Array filter bases its operation in XSLT transformations. A default transformation is available, but it can be overridden to offer different functionality. The default functionality aims at transforming an input Variable containing an xml serialization that can be presented as an array of values to a Data Type of type Array. The component type of the target Array cannot be Reflectable while only one dimensional arrays are supported.
This filter is applicable in the following cases:
- If the default transformation is used and
- Source is array and target is set and not array
- Source is array and target is not set
- If the default transformation is overridden and
- Source is array and target is set and not array
- Source is array and target is not set
- Source is array and target is set and is array
- Source is not array and target is set and is array
In the following cases the filter cannot be applied:
- Source is not array and target is set and is not array
- Source is not array and target is not set
The default XSLT is the following:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <dt type="Array+"> <value> <array code="$$target array code$$"> <xsl:for-each select="$$valueIteration$$"> <item> <dt type="$$target array component type$$"> <value> <xsl:value-of select="$$valueSelection$$"/> </value> </dt> </item> </xsl:for-each> </array> </value> </dt> </xsl:template> </xsl:stylesheet>
XML definition
<filter type="XsltT1DoArray" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <expressionVariable>...</expressionVariable> <!-- optional overriding XSLT --> <selectionVariableName>...</selectionVariableName> <iterationVariableName>...</iterationVariableName> <tokenMap/> </filter>
Serialization
The Serialization filter is another simple filter offering the possibility to enrich an already available serialization with additional values based on token replacement. An input Variable acts as the template to enrich and a set of value providers are iterated and their values are used to populate the template based on their tokens. The set of token mappings can be used to override the token values of the value providers so that when they are iterated to match tokens, the target value is used if a mapping exists for their original token value.
XML definition
<filter type="Serialization" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <tokenProviders> <var name="..."/> </tokenProviders> <tokenMap> <map key="initial name" value="target name"/> ... </tokenMap> </filter>
Reflectable To Template
The Reflectable To Template filter can be applied to an input Variable of Data Type Reflectable or a Data Type Array of component type Reflectable. In the former case the Reflectable is processed using the provided template to serialize it in the way the template defines. In the later case, each item stored in the input Array will be processed as before and the results are concatenated.
The template follows a schema that is depicted in the following examples that progresivly become more complicated. Lets assume we have a Web Service with three methods that receive an argument of type TestContainer1, TestContainer2 and TestContainer3 with the following definitions:
public class TestWebService{ ... public void TestMethod1(TestContainer1 value){ ... } ... public void TestMethod2(TestContainer2 value){ ... } ... public void TestMethod3(TestContainer3 value){ ... } }
Lets assume that the definitions of these three types, TestContainer1, TestContainer2 and TestContainer3 are the following:
public class TestContainer1{ private boolean booleanField; private double doubleField; private float floatField; private String stringField; private boolean getBooleanField(){return this.booleanField;} private void setBooleanField(boolean value){this.booleanField=value;} private double getDoubleField(){return this.doubleField;} private void setDoubleField(double value){this.doubleField=value;} private float getFloatField(){return this.floatField;} private void setFloatField(float value){this.floatField=value;} private String getStringField(){return this.stringField;} private void setStringField(String value){this.StringField=value;} }
public class TestContainer2{ private TestContainer1 cont1; private TestContainer1 cont2; private int intPayload; private String stringPayload; private TestContainer1 getCont1(){return this.cont1;} private void setCont1(TestContainer1 value){this.cont1=value;} private TestContainer1 getCont2(){return this.cont2;} private void setCont2(TestContainer1 value){this.cont2=value;} private String getStringPayload(){return this.stringPayload;} private void setStringPayload(String value){this.StringPayload=value;} private int getIntPayload(){return this.intPayload;} private void setIntPayload(int value){this.intPayload=value;} }
public class TestContainer3{ private TestContainer1 cont1; private TestContainer2 cont2; private TestContainer1 []cont3; private String plainStringPayload; private String []stringPayload; private int []intPayload; private TestContainer1 getCont1(){return this.cont1;} private void setCont1(TestContainer1 value){this.cont1=value;} private TestContainer2 getCont2(){return this.cont2;} private void setCont2(TestContainer2 value){this.cont2=value;} private TestContainer1 []getCont3(){return this.cont3;} private void setCont3(TestContainer1 []value){this.cont3=value;} private String getPlainStringPayload(){return this.plainStringPayload;} private void setPlainStringPayload(String value){this.plainStringPayload=value;} private String []getStringPayload(){return this.stringPayload;} private void setStringPayload(String []value){this.stringPayload=value;} private int []getIntPayload(){return this.intPayload;} private void setIntPayload(int []value){this.intPayload=value;} }
The respective templates to be used in this filter in order to generate the serialization from the respective Reflectables stored in the input Variables would be the following for the previous three types.
<refl>" + <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont> </item> </refl>
<refl> <item type="literal" isxml="false"> <ax21:cont xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> </item> <item type="refl" token=\"ContTok1\"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont1> </item> </refl> </item> <item type="refl" token="ContTok2"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont2 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont2> </item> </refl> </item> <item type="literal" isxml="false" tokenSeparator="--" tokens="tok5--tok6"> <ax21:intPayload>tok5</ax21:intPayload> <ax21:stringPayload>tok6</ax21:stringPayload> </ax21:cont> </item> </refl>
<refl> <item type="literal" isxml="false"> <ax21:cont xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer3"> </item> <item type="array" token="tok7"> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok7"> <ax21:stringPayload xmlns:ax21="http://some.namespace.url/xsd">tok7</ax21:stringPayload> </item> </item> <item type="array" token="tok8"> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok8"> <ax21:intPayload xmlns:ax21="http://some.namespace.url/xsd">tok8</ax21:intPayload> </item> </item> <item type="array" token="ContTok3"> <item type="refl" token="ContTok3"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont3 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont3> </item> </refl> </item> </item> <item type="refl" token="ContTok1"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont1> </item> </refl> </item> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok8"> <ax21:plainStringPayload xmlns:ax21="http://some.namespace.url/xsd">tok8</ax21:plainStringPayload> </item> <item type="refl" token="ContTok2"> <refl> <item type="literal" isxml="false"> <ax21:cont2 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer2"> </item> <item type="refl" token="ContTok1"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont1 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont1> </item> </refl> </item> <item type="refl" token="ContTok2"> <refl> <item type="literal" isxml="true" tokenSeparator="--" tokens="tok1--tok2--tok3--tok4"> <ax21:cont2 xmlns:ax21="http://some.namespace.url/xsd" type="some.package.name.TestContainer1"> <ax21:booleanField>tok1</ax21:booleanField> <ax21:doubleField>tok2</ax21:doubleField> <ax21:floatField>tok3</ax21:floatField> <ax21:stringField>tok4</ax21:stringField> </ax21:cont2> </item> </refl> </item> <item type="literal" isxml="false" tokenSeparator="--" tokens="tok5--tok6"> <ax21:intPayload>tok5</ax21:intPayload> <ax21:stringPayload>top6</ax21:stringPayload> </ax21:cont2> </item> </refl> </item> <item type="literal" isxml="false"> </ax21:cont> </item> </refl>
The set of token mappings can be used to override the token values of the input Reflectables so that when they are iterated to match the template, the target value is used if a mapping exists for their original token value.
XML definition
<filter type="ReflectableToTemplate" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <templateVariable>...</templateVariable> <tokenMap> <map key="initial name" value="target name"/> ... </tokenMap> </filter>
Reflectable From Template
The Reflectable From Template filter can be applied to an input Variable of which its string representation is used to populate another inpout value acting as a template. This template infated using these values generate an output which is of Data Type Reflectable or Array of Reflectables.
The template follows a schema that is depicted in the following examples that progressively become more complicated. Lets assume we have a Web Service with three methods that return values of type TestContainer1, TestContainer2 and TestContainer3 with the following definitions:
public class TestWebService{ ... public TestContainer1 TestMethod1(){ ... } ... public TestContainer2 TestMethod2(){ ... } ... public TestContainer3 TestMethod3(){ ... } }
For the sake of brevity, we will assume that the definitions of these types are as the ones described in Reflectable To Template filter example.
The respective templates to be used in this filter in order to inflate the respective Reflectable or Array of Reflectables to be stored in the output Variable would be the following for the previous three types.
The set of token mappings can be used to override the token values of the input serialization so that when they are iterated to match the template, the target value is used if a mapping exists for their original token value.
<refl name=return" ns="http://some.namespace.url"> <item name="booleanField" token="tok1" ns="http://some.namespace.url/xsd\" type="BooleanPrimitive"/> <item name="doubleField" token="tok2" ns="http://some.namespace.url/xsd\" type="DoublePrimitive"/> <item name="floatPField" token="tok3" ns="http://some.namespace.url/xsd\" type="FloatPrimitive"/> <item name="stringField" token="tok4" ns="http://some.namespace.url/xsd\" type="String"/> </refl>
XML definition
<filter type="ReflectableFromTemplate" order="..." storeOutput="true/false" storeOutputName="..."> <filteredVariable>...</filteredVariable> <templateVariable>...</templateVariable> <tokenMap> <map key="initial name" value="target name"/> ... </tokenMap> </filter>