Cost-Based Optimization of Integration Flows - Datenbanken ...

2.3 Integration Flow Meta Model
Flow Meta Model
According to our classification of integration flows, our flow meta model defines a plan P
of an integration flow as a hierarchy of sequences with control-flow semantics that uses
instance-local, materialized intermediates.
In detail, the flow meta model exhibits an instance-based execution model, which means
that each incoming message m i or scheduled time event e i (in case of plans that are initiated
by an internal scheduler) conceptually initiates a new instance p i of a plan P .
This instance is then executed within a single master thread (except for modeled parallel
subflows) such that no queues between operators are required. As a consequence of this execution
model, a plan instance p i has a local state, while a plan P is stateless by definition,
which stands in contrast to standing queries in DSMS. With these control-flow semantics,
both the data flow and the control flow can be appropriately described because data dependencies
as well as temporal dependencies are expressible. The single operators use
local messages as variables (data dependencies), while edges between operators describe
the temporal order of these operators. Similar types of instance-based process models are
typical for workflow-based integration systems [BPA06, OAS06, WfM05]. Putting it all
together, a plan of an integration flow is defined as follows:
Definition 2.1 (Plan). A plan P of an integration flow is defined with P = (o, c, s) as
a 3-tuple representation. Let o = {o 1 , o 2 . . . , o m } denote a sequence of operators, let c
denote the context of P as a set of local message variables, and let s denote a set of
services s = {s 1 , s 2 . . . , s l } that represent outbound adapters. An instance p i of a plan
P , with P ⇒ p i , executes the sequence of operators exactly once. Each operator o j has a
specific type as well as a unique node identifier nid. We distinguish between atomic and
complex operators, where complex operators recursively contain sequences of operators with
o j = {o j,1 , o j,2 . . . , o j,m ′}. A single operator can have multiple input variables and multiple
output variables. Each service s i contains a type, a configuration and a set of operations.
Our flow meta model includes specific operator types for integration flows in order
to describe local processing steps and the interaction with external systems. In detail,
this flow meta model defines a set of interaction-, control-flow-, and data-flow-oriented
operators by combining common process description languages with the relational algebra.
We use the min-max notation [KE09] to describe the minimal and maximal number of
input and output messages of each specific operator type. In addition, we identify complex
operators that recursively contain arbitrary other operators.
The interaction-oriented operators describe the interaction between the integration platform
and the external systems. These operators use adapters in order to encapsulate the
Table 2.1: Interaction-Oriented Operators
Name Description Input Output Complex
Invoke
Receive
Reply
Actively write/read data to/from
external systems
Passively receive a message from an
invoking client system (listener)
Send a result to the invoking client
system
(0,1) (0,1) No
(0,0) (1,1) No
(1,1) (0,0) No
23