\section{IMPROVED DATA PROCESSING IN CONTROL-FLOW-ORIENTED WORKFLOWS}
\label{sec:OptDP}


To illustrate our approach, we first sketch the main components of the typical architecture of control-flow-oriented workflow execution environments. Afterwards, we show how this architecture is extended by our approach and introduce various techniques to improve the workflow-internal data processing.% that partition the data processing tasks of workflows between the workflow and database engine.


%Now, we illustrate the approach to improve the local data processing in control-flow-oriented workflows and corresponding workflow execution environments. For that purpose, we first sketch the main components of the typical architecture of such environments. Afterwards, we show how this architecture is extended by our approach and introduce various optimization techniques.% that partition the data processing tasks of workflows between the workflow and database engine.


\subsection{Current Architecture for Local Data Processing in Control-Flow-Oriented Workflows}
\label{sec:OptDP:CurrentApproach}


\begin{figure}[tb]
	\centering
		\includegraphics[width=\textwidth]{OptimizationApproach/Architectures4LocalDataProcessing.pdf}
	\caption{Current architecture for data processing in workflows (a) and architecture for an improved data processing (b).}
	\label{fig:Architecture}
\end{figure}


Figure \ref{fig:Architecture}(a) shows the current architecture for control-flow-oriented workflow execution environments as they are typically used for orchestration workflows. For better readability, we leave out components that are not directly relevant for the workflow-internal data processing, \eg a compiler or deployment component for workflow models. Such environments contain a local database system (DBS). Remark that this is not the type of external database stores a workflow may access via the separate and hybrid cases of data management (see Table \ref{table:DM4Workflows:Dimensions}). In fact, this local DBS supports the integrated case of data management and serves as persistent data store for the workflow-local data in process variables and for metadata such as auditing information. However, it does not process this data, \eg during variable assignments. Instead, the \h{workflow runtime} component itself performs this data processing. For that purpose, it contains a \mbox{\h{pool of variables}} that manages all process variables and their contents, \eg realized as a heap of \mbox{Java objects}, and an \h{expression evaluation engine} that evaluates expressions, \eg XPath expressions, on these variables. A \h{data processing logic} component defines how all data-processing workflow activities and constructs work on the variables and how the expression evaluation engine \mbox{as well as} the pool of variables are employed. For example, this data processing logic controls the data processing for variable assignments, service calls, and control flow decisions.

%Besides external database systems that workflows may access via the separate and hybrid case of data management as depicted in Table \ref{table:DM4Workflows:Dimensions}, such environments contain a local database system (DBS) that supports the integrated case of data management. This local DBS serves as persistent data store for the workflow-local data in process variables and for metadata such as auditing information.

A \h{persistence manager}, \eg a Data Access Object (DAO) layer, negotiates between the runtime and the local DBS and manages the persistence of the workflow-local data, \ie it stores and loads the data in or from the DBS either automatically or when the runtime triggers it. To manage the variable contents, the database contains a \h{pool of variables} as well. The persistence manager provides the mapping between the variables in the pool of the workflow runtime and those in the pool of the database. This way, the runtime is independent from the concrete local DBS, \ie we can exchange this DBS quite easily. The database management system contains a \h{query/expression execution engine}, but this engine is not used to execute the workflow-internal data processing. It just gets simple queries from the persistence manager to load or store whole variable contents.% and answers with the query results or a notification, respectively.


\subsection{A New Architecture for Local Data Processing}
\label{sec:OptDP:NewApproach}


To ensure a reliable and efficient local data processing in data-intensive workflows described in control-flow-oriented languages, we have extended this architecture by components that provide an improved workflow-internal data processing (Figure \ref{fig:Architecture}(b)). The data processing tasks to be performed during workflow execution are partitioned between the workflow runtime and the local DBS in order to exploit their respective capabilities as much as possible. This is transparent to the workflow modeler, \ie it does not change workflow models, but only influences the execution of such models. Beside the persistence manager, the \h{query/expression interface} allows to push down workflow-internal data processing operations from the runtime to the local DBS that finally executes these operations. Using this component, the runtime only issues queries or expressions against the DBS and receives small data items, \eg Boolean values needed for control flow decisions. As the queries to execute the data processing operations may vary between different DBSs, the query/expression interface has to store query templates for concrete DBSs and has to set the necessary parameter values within these query templates. %For example, assume a query template for an SQL INSERT statement that gets an assignment expression from the runtime as parameter and that inserts the result of the expression into a database table for managing process variables.
This way, the workflow runtime is again independent from the concrete local DBS.

The \h{data processing optimizer}, embedded in the workflow runtime, controls the data processing logic and decides whether the workflow-internal data processing operations are assigned to the \mbox{workflow runtime} or to the local DBS and in which of both components the corresponding data is stored. The main goals of this optimization are to decrease the amount of data transfered between the runtime and the DBS as well as to exploit the mature data processing facilities of the DBS and its query/expression execution engine whenever appropriate. %, as well as to discharge the runtime and to provide a more balanced utilization of all involved system components.
The decisions mainly depend on the capabilities of the runtime and the local DBS, the data sizes, and the complexities of the involved queries and expressions. All these optimization criteria are described by metadata the optimizer retrieves from the respective components. The optimizer can make its decisions in several granularities, \eg the same decision for all instances of one workflow model, for individual instances or sets of instances, for single data processing tasks, or for single process variables or sets of variables.% In Section \ref{sec:Evaluation}, we state more detailed examples and suggestions of the optimization decisions based on our evaluation.


\subsection{Techniques to Improve Workflow-Internal Data Processing}
\label{sec:OptDP:Techniques}


\begin{figure}[tb]
	\centering
		\includegraphics[width=\textwidth]{OptimizationApproach/OptimizationTechniques.pdf}
	\caption{\ap\ (a), \eep\ (b), and \wsp\ (c). Numbers indicate the orders in which the individual steps are carried out.}
	\label{fig:OptTechniques}
\end{figure}


The data processing optimizer may employ various techniques that partition the workflow-internal data processing operations between the \mbox{workflow runtime} and the local DBS. Some of them are depicted in Figure \ref{fig:OptTechniques}. The \h{\ap}\ shifts the responsibility for executing process variable assignments from the \mbox{workflow runtime} to the DBS. The DBS receives (step 1) and evaluates \mbox{(step 2)} assignment expressions, \eg XPath expressions, and assigns the expression results to the target variables (step 3). Afterwards, the runtime gets a notification whether the assignment has been executed successfully or not (step 4). The \h{\eep}\ is used for control flow decisions, such as transition conditions or loops. It again evaluates expressions within the DBS, but synchronously forwards the expression results back to the runtime for further processing.


%The data processing optimizer may employ various optimization techniques that partition the workflow-internal data processing operations between the workflow runtime and the local DBS. Some of them are depicted in Figure \ref{fig:OptTechniques}. The \h{\ap}\ shifts the responsibility for executing process variable assignments from the workflow runtime to the DBS. The DBS receives (step 1) and evaluates (step 2) corresponding assignment expressions, \eg XPath expressions, and assigns the expression results to the target variables in its pool of variables (step 3). Afterwards, the runtime gets a notification whether the assignment has been executed successfully or not (step 4). The \h{\eep}\ is used for control flow decisions, such as transition conditions, loops, or alarm events. It again evaluates expressions within the DBS, but synchronously forwards the expression results, \eg Boolean or Integer values, back to the runtime that further processes these results.

%The data processing optimizer may employ various optimization techniques that partition the workflow-internal data processing operations between the workflow runtime and the local DBS. %These techniques reflect the data-processing workflow activities and constructs that are controlled by the data processing logic.
%The \h{\ap}\ shifts the responsibility for executing process variable assignments from the workflow runtime to the DBS. The DBS receives and evaluates corresponding assignment expressions, \eg XPath expressions, and assigns the expression results to the specified target variables in its pool of variables (see Figure \ref{fig:OptTechniques}(a)). Afterwards, the runtime gets a notification whether the assignment has been executed successfully or not. Figure \ref{fig:OptTechniques}(b) shows the \h{\eep}\ that is used for control flow decisions, such as transition conditions, alternative branches, loops, or alarm events. It again evaluates expressions within the DBS, but synchronously forwards the expression results, \eg Boolean or Integer values, back to the runtime that further processes these results.


%begin{figure}[tb]
%	\centering
%		\includegraphics[width=0.7\textwidth]{OptimizationApproach/Assignment-ExpressionEvaluationPushdown.pdf}
%	\caption{\ap\ (a) and \eep\ (b).}
%	\label{fig:AP_EEP}
%\end{figure}


%\begin{figure}[tb]
%	\centering
%		\includegraphics[width=0.45\textwidth]{OptimizationApproach/WebServicePushdown.pdf}
%	\caption{\wsp.}
%	\label{fig:WSP}
%\end{figure}

Using these two techniques, the data transferred from the local DBS to the runtime are only small notifications or data items, possibly leading to performance improvements due to reduced costs for data transmission. However, the input data of the corresponding expressions, which may become big in case of data-intensive workflows, should be available in the DBS before the respective variable assignments or control flow decisions are carried out. Otherwise, it would be necessary to transfer these data from the runtime to the DBS via the persistence manager, which might lead to performance degradations. To tackle this problem, we have developed two further techniques.

A control-flow-oriented workflow may get two kinds of data that eventually have to be stored in the local DBS: (1) data as result of a service call or sent by the client and (2) literal values, \eg XML snippets, which are defined in the workflow model and assigned to a process variable during workflow execution. The \h{\wsp}\ deals with the first kind of data. It calls Web Services directly from the DBS instead from the runtime, thereby storing the result data of the service in the database without the indirection over the runtime and the persistence manager (see Figure \ref{fig:OptTechniques}(c)). The same principle can be applied for asynchronous communication, \ie when a workflow sends data to a service or client or when it gets data from them, without expecting any result on either side. The literal values are already known at modeling and deployment time as they are a direct part of the workflow model. The \h{\lip}\ exploits this characteristic and stores such literal values in a designated table in the DBS during the deployment phase of the relevant workflow model (Figure \ref{fig:LiteralPushdown}). Furthermore, it writes a reference into the internal representation of this model or into the contents of the respective variables to refer to the previously stored literal values during workflow execution.% In summary, these two optimization techniques entail that no data needs to be transfered from the runtime to the DBS.


\begin{figure}[tb]
	\centering
		\includegraphics[width=\textwidth]{OptimizationApproach/LiteralPushdown.pdf}
	\caption{\lip.}
	\label{fig:LiteralPushdown}
\end{figure}