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

2.1 Integration Flows
execution. During execution of these flows, the outbound adapters are used as services
(gateways) in order to actively invoke external systems, where they transform the internal
format back to the proprietary message representations. The inbound and outbound
adapters hide syntactic heterogeneities of external systems, while structural heterogeneities
are addressed by schema transformation as part of the plan execution within the process
engine. Note that each supported proprietary application, data format or standard protocol
requires such specific inbound and outbound adapters. This concept of inbound and
outbound adapters in combination with the common internal message format (in terms
of XML or other tree-structured data representations) is crucial in order to reduce the
complexity of such an execution component for two reasons. First, for n incoming formats
and m outgoing formats, we reduced the number of required transformation services (e.g.,
for transforming an XML message to a binary EDIFACT message) from n · m to n + m
because we only need individual mappings (transformations) between the internal format
and the sets of incoming and outgoing formats. Second, using the common format, all
operators of the process engine need only to be realized once, according to this internal
format, and the specific characteristics of external systems are hidden from the process
engine by a generic outbound adapter interface.
The deployment of integration flows finally combines both the modeling and execution
components. Typically, an XML representation of the modeled integration flow is used
in order to transfer the flow specification to the execution component, where the flow
parser is used in order to create an internal plan of the integration flow. All analysis
and optimization procedures then work on this plan representation. Finally, the plan
is compiled into an executable form. In this context, we distinguish several different
execution models and approaches that we will discuss in detail in Subsection 2.1.4.
As already mentioned, there are plenty of application examples for imperative integration
flows [BH08, CHX08, GGH00, SAP03, MS09, ACG + 08, CEB + 09]. Due to (1) the
high number of heterogeneous systems and applications and (2) the continuous change
of technology that reasons heterogeneity, the need for efficient integration will constantly
remain in the future.
2.1.3 Modeling Integration Flows
With regard to the overall system architecture, one important aspect is how to model integration
flows. Essentially, we classify existing approaches of specification models using the
two criteria (1) flow structure and (2) flow semantics. Figure 2.3 illustrates the resulting
classification of integration flow modeling approaches. In contrast to declarative queries
that are specified with descriptive languages, imperative integration flows are typically
specified using prescriptive languages.
Modeling Integration Flows
Structure
Directed
Graph
Hierarchy of
Sequences
Source
Code
Fixed
Flow
Semantics
data flow control flow data flow control flow control flow control flow
Figure 2.3: Classification of Modeling Approaches for Integration Flows
9