Catalog of Optimization Strategies and Realizations for Composed Integration Patterns

TL;DR

This paper compiles and explains various optimization strategies for composing enterprise integration patterns, addressing the lack of formalization and optimization in integration scenario processes.

Contribution

It provides a catalog of process optimization techniques specifically tailored for composed enterprise integration patterns, filling a gap in formal descriptions.

Findings

Identified key optimization strategies from literature

Categorized optimization techniques for integration scenarios

Facilitates improved composition of integration patterns

Abstract

The discipline of Enterprise Application Integration (EAI) is the centrepiece of current on-premise, cloud and device integration scenarios. However, the building blocks of integration scenarios, i.e., essentially a composition of Enterprise Integration Patterns (EIPs), are only informally described, and thus their composition takes place in an informal, ad-hoc manner. This leads to several issues including a currently missing optimization of application integration scenarios. In this work, we collect and briefly explain the usage of process optimizations from the literature for integration scenario processes as catalog.

Tables

Table 1. Table 1: Optimizations in related domains - horizontal search

Keyword	hits	selected	Selection criteria	Selected Systems
Business Process Optimization	$159$	$3$	data-aware processes	survey [39], optimization patterns [22, 23]
Workflow Optimization	$396$	$6$	data-aware processes	instance scheduling [1, 4, 38], scheduling and partitioning for interaction [2], scheduling and placement [3], operator merge [14]
Data Integration Optimization	$61$	$2$	data-aware processes optimization, (no schema-matching)	instance scheduling, parallelization [42], ordering, materialization, arguments, algebraic [12]
Added	n/a	$9$	expert knowledge	business process [41], workflow survey [18, 19], data integration [8], distributed applications [5, 6], EAI [DBLP:conf/bncod/Ritter15, 29, 28]
Removed	-	$1$		classification only [39]
Overall	$616$	$19$

Table 2. Table 2: Static Control (SCx) and Data Flow (SDx) Optimizations

ID	Optimization	OS1	OS2	OS3	OS4	OS5	other	References
SC1	Redundant Path Removal	$\surd$	-	-	-	-	-	Remove redundant control flow [8]
SC2	Dead Path Removal	$\surd$	-	-	-	-	-	Unreachable Sub-graph Elimination [8]
SC3	Sub-process Inlining	$\surd$	-	-	-	-	-	Local Sub-process Inlining [8]
SC4	Sub-process Generation	$\surd$	-	-	-	$\surd$	($\surd$)	(Work-) flow partitioning [2, 5, 6]
SD1	Resource Squander	-	-	-	-	-	$\surd$	Double Variable Assignment [8]
SD2	Unnecessary Resource Allocation	-	-	-	-	-	$\surd$	Unnecessary Variable Declaration / Assignment [8]; Eliminate-Unused-Variable, SQL simplifications (e.g., Eliminate-Redundant-Attributes, Eliminate-Unused-Attributes, Eliminate-Redundant-Predicates) [40]
SD3	Combine Sibling Patterns	$\surd$	-	-	-	-	-	Two Sibling Translation Operation / Validaton merging [8]; Operator Merge [14]
SD4	Unnecessary conditional fork	$\surd$	-	-	-	($\surd$)	-	Unnecessary Switch-Path [8]; similar to Eliminate-Unused-Partner [40]
SD5	Algebraic	-	-	-	-	-	$\surd$	Algebraic Optimization / Simplification [8, 12, 5, 6]

Table 3. Table 3: Dynamic Control (DCx) and Data Flow (DDx) Optimizations

ID	Optimization	OS1	OS2	OS3	OS4	OS5	other	References
DC1	Message Indexing	-	($\surd$)	-	-	-	$\surd$	2-layer-hash-index [8]; ONC [DBLP:conf/bncod/Ritter15]; Feature Selector [33]; message slices [5, 6]
DC2	Distribute Messages	-	($\surd$)	($\surd$)	-	($\surd$)	-	Heterogeneous load balancing [8]
DC3	Parallel Process Re-Scheduling	-	-	-	-	-	$\surd$	instance scheduling [1, 4, 38]; Rescheduling Start of Parallel Flows [8, 42]
DC4	Sequence to parallel / merge parallel processes	-	-	$\surd$	-	-	-	Rewriting Sequences to Parallel Flows, Merging Parallel Flows [8, 22, 42]; similar to SQL-Parallelization in [40]
DC5	Loop to parallel processes	-	-	$\surd$	-	-	-	Rewriting Iterations to Parallel Flows [8]
DD1	Reordering / Merging Conditional Paths	($\surd$)	-	-	-	-	$\surd$	Reordering / Merging Switch-Paths [8]
DD2	Pushdown to Endpoints	-	-	-	$\surd$	-	-	mentioned in [8]; Web-Service-Pushdown to DB [40]
DD3	Early-Filter	-	$\surd$	-	-	-	-	Early Selection [8, 12, 14, 22]; similar to Predicate-Pushdown in [40]
DD4	Early-Mapping	-	$\surd$	-	-	-	-	Early Projection [8, 12, 14]
DD5	Early-Aggregation	-	$\surd$	-	-	-	-	Early GroupBy [8, 12, 14]
DD6	Claim Check	-	($\surd$)	-	-	-	-	Materialization Point Insertion / Elimination [8, 12]
DD7	Algebraic	-	-	-	-	-	$\surd$	Orderby Insertion / Removal, Join-Type Selection, Join Enumeration [8]; similar to Join-Optimization [40]; message slices [5, 6]
DD8	Process Vectorization	-	-	-	-	-	$\surd$	Setoperation-Type Selection, process vectorization [8, 7]; Tuple-to-Set operations like Insert-Tuple-To-Set, Update-Tuple-To-Set, Delete-Tuple-To-Set [40]; ONC [DBLP:conf/bncod/Ritter15]
DD9	Pattern Split / Merge	$\surd$	-	-	-	-	-	Operator merge [14, 8, 18, 19, 22]; all Activity-Merging optimizations from [40]: Insert-Update and Update-Insert merging on workload, Select-Merging, Select-Into-Merging; Coarse-Grained-Optimierung [20]
DD10	Pre-computation of Values	-	-	-	-	-	$\surd$	[8, 12]; Multi-Query-Optimierung techniques [11, 36, 37, 25, 35]; Detector Region [33]
DD11	Ignore Failing Endpoints	-	-	-	-	$\surd$	-	- (Resilience Patterns [24, 34, 31])
DD12	Reduce Requests	-	($\surd$)	-	-	$\surd$	-	Workflow-Database optimization [41]

Table 4. Table 4: Relevant Optimization Techniques in the Context of the Objectives

ID	Optimization	Throughput	Latency	Resilience	Context	Complexity
SC1	Redundant Path Removal	-	$\surd$	($\surd$)	-	$\surd$
SC2	Dead Path Removal	-	$\surd$	($\surd$)	-	$\surd$
SC3	Sub-process Inlining	-	$\surd$	-	-	($\surd$)
SC4	Sub-process Generation	-	-	-	$\surd$	($\surd$)
SD3	Combine Sibling Patterns	-	$\surd$	($\surd$)	-	$\surd$
SD4	Unnecessary conditional fork	$\surd$	$\surd$	($\surd$)	-	$\surd$
DC2	Distribute Messages	$\surd$	-	($\surd$)	($\surd$)	-
DC6	Sequence to parallel / merge parallel processes	$\surd$	($\surd$)	-	-	-
DD1	Merging of Switch-Paths	-	$\surd$	($\surd$)	-	$\surd$
DD2	Pushdown to Endpoints	$\surd$	($\surd$)	-	$\surd$	$\surd$
DD3	Early-Filter	$\surd$	($\surd$)	-	($\surd$)	-
DD4	Early-Mapping	$\surd$	($\surd$)	-	($\surd$)	-
DD5	Early-Aggregation	$\surd$	($\surd$)	-	($\surd$)	-
DD6	Claim Check
DD9	Splitting / Merging Patterns	$\surd$	$\surd$	-	-	($\surd$)
DD11	Ignore Failing Endpoints	-	($\surd$)	$\surd$	-	-
DD12	Reduce Requests	-	-	$\surd$	-	-

Table 5. Table 5: Optimization Strategies realized by Integration Patterns

Strategy ID	Realization Categories
OS-1	- (structural criteria only)
OS-2	Permanent message removal (cf. Early-Filter messages, Early-Mapping) / temporal message removal (cf. Claim Check), message combination (cf. Early-Aggregation), message content filtering (cf. Early-Filter data) / size reduction (cf. Compression)
OS-3	- (supporting Sequence to Parallel, Merge Parallel through non-conditional forking and joining patterns; Heterogeneous Load Balancing through forking and format handling)
OS-4	cf. OS-2 categories, Early-Quality of Service and Early-Operation (cf. pushdown), Late-Quality of Service and Right-Place (cf. push-back)
OS-5	resilience, tolerance (cf. Ignore Failing Endpoints), filtering and flow control (cf. Reduce Requests), prevention (cf. Distribute Messages)

Full text

In this work, we collect and briefly explain the usage of process optimizations from the literature for integration scenario processes as catalog.

1 Introduction

Although Enterprise Application Integration (EAI) [21] plays an important role in current IT infrastructures, the development of integration scenarios – essentially a composition of the Enterprise Integration Patterns (EIP) [15] and extensions [31] – remains a challenging task for the users. During the modeling of these scenarios, which is currently done with vendor-specific languages and tools, the users have hardly any support or guidance, when it comes to consistency and correction checks of their models, not to mention optimization possibilities [31].

For instance, Fig. 1 shows one possible implementation of the Italy Invoicing Scenario (country-specific), which allows organizations to communicate with the Italian authorities – in Business Process Model and Notation (BPMN) with BPMN Message and BPMN Data Object representing the message data flow [27, 30, 34]. An organization sends the invoice data, e.g., from its ERP system, to the integration process, in which data from the message body $b.x$ to set the required tax data header of the organization required by the governmental authorities using a Content Enricher [15]. Then the invoice data is mapped to the required target format (Message Transformation [15]) by a mapping program that requires the message in a special encoding (Message Encoder [31]). These operations are parallelized by a Multicast [31] and structurally joined by a Join Router [31]. The unnecessary fields of the mapped invoice are removed from the message by a Content Filter [15] resulting to a message content $b.z^{\prime}$. The message is routed to one of two receiving governmental authorities, depending on the type of inquiry, by a Content-based Router [15] or discarded (incl. content enricher). Both governmental authorities require signed messages to verify the authenticity and identity of the sending organization using a Message Signer [31]. Duplicate invoices have to be removed using a (stateful) Idempotent Receiver pattern [15]. The invoice messages are sent to the authority by an External Call [31] pattern and the response is combined with the original message using a content enricher. The combined data $b.a$ is then mapped to the response format of the ERP sender using a message transformation.

While this example is syntactically and semantically correct, it is not optimal with respect its control and data flow. Even with an explicit data flow, it is difficult for the user, e.g., to recognize the redundant control flows and sibling patterns as well as the potential for pattern parallelization or the benefits of pattern re-ordering for the message throughput. Furthermore, the modeling complexity and processing latency reduction potential of $\frac{1}{3}$ of the patterns remains hidden to the user (cf. compare with Fig. 16 in Sect. 5).

In this work, we discuss EAI optimization objectives in Sect. 2 and collect relevant optimization techniques from the literature of related domains of business process, workflow and data integration in an optimization catalog and specify them for EAI processes in Sect. 3. The we discuss the realization of optimization strategies in Sect. 4. Then we show the applicability to an extended scenario Sect. 5 and conclude in Sect. 6.

2 Optimization Objectives and Strategies

In this section we collect and discuss EAI optimization objectives in the context of classical EAI [21, 15] and emerging application integration scenarios [31]. The latter results to new EAI challenges and solutions, which are represented in this work by our studies on “data-aware” message processing solution spaces: dealing with high velocity and increasing message volume through table-centric processing [DBLP:conf/bncod/Ritter15, 28] and streaming on dataflow (hardware) architectures [29], as well as new message format variety aspects in terms of multimedia integration [33]. Figure 2 a high-level view on the classical system architecture (based on [30]), evolved by new components for multimedia integration (from [33]). Subsequently, we define and discuss optimization objectives along the different architectural components.

2.0.1 Message Throughput and Latency

The message throughput and the request-response latency are the most important optimizaton objectives of EAI systems. While the message throughput is the number of messages sent and processed from a sender to a receiver (through the whole system), the latency is the time a sender has to wait until it receives a response from the receiver. We copnsider message throughput and latency on a message processing pattern or a composition of patterns (e.g., including Adapter Runtime, Integration Process Engine). The work on vectorized integration patterns [DBLP:conf/bncod/Ritter15, 28] illustrates the trade-off of immense message throughput gains, when processing sets of messages in contrast to a reduced overall latency (throughput $\mapsto$ Vectorization). Furthermore the message throughput can be increased, through processing messages in multiple parallel sub-processes, e.g., separate hardware resources [29] ($\mapsto$ Parallelization). The message stream [29] and multimedia integration [33] showed decreasing message throughput for inceasing message sizes. While message indexing reached its limits for increasing multimedia data [33], keeping message sizes smaller helped throughout the experiments ($\mapsto$ Data Reduction). This could be achieved through process restructurings. When the structural process changes reduce the number of process elements or complex fork or join patterns, the latency and process complexity could be improved [29] ($\mapsto$ Process Simplification).

2.0.2 Energy Efficiency and Costs

While the objectives of energy effiiciency and costs are out of scope for this work, some of the named solutions can help to improve both. The study on application integration on a dataflow hardware architecture [29] showed the trade-off between message throughput and energy consumption as well as costs. Even in modern data centers with virtualized hardware, the resource and energy costs play a crucial role . While the FPGA hardware reached a high throughput with low energy consumption and costs, the software solutions required more energy on one machine and could only reach the same throughput by adding more computing units, and thus increased the costs ($\mapsto$ Data flow architecture). On the common von Neumann architectures a reduction of message processors can help to improve the energy consumption – in CPU-bound messaging scenarios – which also includes the reduction of parallelized processing units ($\mapsto$ Process Simplification).

2.0.3 Resilience and Robustness

Since integration systems are central infrastructure components in current IT infrastructures, they are realized as distributed, high-available systems. However, as shown in Fig. 2, the dependencies to internal resources (e.g., database, message queuing, machine learning) and the growing number of frequently changing message endpoints (e.g., mobile and cloud endpoints) [31] has to be dealt with during the message processing. Not only because network communication is a little less reliable than process-to-process communication [15], smart network usage and reaction to exceptional situations or unavailabilities are crucial ($\mapsto$ Reduce Interaction).

2.0.4 Context-Awareness and Separation of Duties

While smarter network usage and resilience improves the stability of integration scenarios, even more distributed processing in context-aware scenarios close to the data producers allows for a short circuit procesing and potentially a reduction of message sizes. Furthermore – especially in foreign-hosted, cloud computing environments – the aspect of secure and private execution of integration processes with user defined functions is crucial [31]. For instance, a process of one cooperation must not be able to interfere with one process of another cooperation. This requires an integration process fragmentation and placement on heterogeneous runtime systems – with a focus on reduced interactions ($\mapsto$ Pattern Placement).

2.0.5 Modeling Complexity

As seen in Fig. 1, even moderately simple integration scenarios can become complex. One objective could be to build smarter editors that support the users, during modeling, configuration, navigating and understanding an integration scenario. The understanding and navigating could be approached by simpler integration scenarios ($\mapsto$ Process Simplification) as well as guided modeling ($\mapsto$ Smart Guidance). In addition, the modeling context, e.g., “query by sketch” support on visual queries for multimedia data integration [33], could improve the interaction on the integration process ($\mapsto$ Contextualized Modeling).

2.0.6 Objectives and Strategies Summary

Let us summarize the optimization objectives and strategies relevant for EAI in the context of emerging applications. The objectives are:

• •

Optimization on static design time and dynamic runtime / workload data

• •

Process / Control flow, Data flow and Interaction optimization (not pattern processing efficiency)

• •

Optimization of Message throughput, latency as well as resilience and Separation of Duties (minor focus on energy efficiency and costs)

• •

(Multi-objective optimization)

We do not focus on the objectives of pattern solution efficiency, energy efficiency and costs. Some parts of the reduce modeling complexity objective will be indirectly addressed, due to our focus on integration process related optimizations. The resulting solution optimization strategies (OSx) that we want to consider are:

• •

OS1: Process simplification

• •

OS2: Data reduction

• •

OS3: Parallelization

• •

OS4: Pattern placement

• •

OS5: Reduce interacton

We do not consider Vectorization, the architecture shift to Data flow architectures, since they partially target the pattern solution efficiency and we already addressed them in the context of EAI in our recent work [DBLP:conf/bncod/Ritter15, 28, 29]. Furthermore, we consider smart guidance and contextualized modeling out of scope, due to our focus on integration process optimizations.

Subsequently, we collect optimizations from related domains, classify them according to our objectives and check, whether they help to realize the optimization strategies.

3 Optimization Catalog

In this section we collect relevant optimization techniques for EAI processes from related domains. Therefore we briefly discuss the selected domains and literature and then list the derived optimization techniques again with brief descriptions. Furthermore, we discuss the significance of each technique in the context of the optimization objectives from Sect. 2.

3.1 Domain and Literature Selection

For EAI, the domains of business processes, workflow management and data integration are of particular interest. Therefore, we conducted a study based on [17] using scholar.google.com with the following keywords: business process optimization, workflow optimization, data integration optimization (allintitle, no patents, accessible, from $2004$ as the EIPs [15]).

3.2 Optimization Approach Summaries

We summarize and classify the found optimization techniques along the objectives of control and data flow as well as design time (static) and runtime or workload (dynamic) optimizations (similar to [8]). Furthermore, we rate these techniques accourding to their relevance for the introduced system imprlementations in the context of emerging application integration.

3.2.1 Design Time Optimizations

The design time optimizations denote process improvement techniques that can be identified only on “static” process models. Subsequently, we summarize the found static optimization techniques listed in Tab. 2 and discuss them in the context of the objectives and strategies.

The static control (SCx) optimization techniques mostly support the optimization strategy of process simplification (cf. OS1). Thereby Redundant Path Removal and Dead Path Removal techniques identify and remove identical, redundant and non-reachable branches in an integration process. The Sub-process Inlining technique helps to simplify modular processes and reduce the number of sub-process calls, however, reduces modularization and fragmentation. In contrast Sub-process Generation allows for the partitioning of a process, which could simplify the main process, helps to place patterns (cf. OS4), while reducing the need for communications (cf. OS5).

The techniques from the static data (SDx) optimizations relevant for integration processes Combine Sibling Patterns and Unnecessary conditional fork again mostly support the optimization strategy of process simplification (cf. OS1). Thereby (redundant) sibling patterns and unnecessary conditional fork require additional data to decide that the processed elements are the same, the conditional fork statistics indicate no usage, respectively. The latter can occur in the variant Eliminate-Unused-Partner, which even reduces the interaction with message endpoints (cf. OS5). The found techniques in the areas of Resource Squander and Unnecessary Resource Allocation target the resource consumption on a “source code” and not process level. Hence, they will not be further considered in the context of this work. Similarly, the Algebraic optimizations and simplifications focus on the integration process configuration or the communication between the integration process pipeline and other integration system resources (e.g., datastore).

3.2.2 Runtime Optimizations

The runtime optimizations denote process improvement techniques that require (continuous) runtime / workload data. However, in some cases, abstract costs or experimentally collected runtime data is sufficient, e.g., latency, message throughput. Subsequently, we summarize the found static optimization techniques listed in Tab. 3 and discuss them in the context of the objectives and strategies.

The dynamic control (DCx) optimization techniques mostly support process parallelization (cf. OS3) and data reduction (cf. OS2). The most important one is Sequence to parallel / merge parallel processes, which can be considered as technique that elastically scales and reduces parallel patterns or sub-processes. However, the Distribute Message technique can help to reduce interaction with a specific endpoint. The Message Indexing can help to reduce the data, however, rather targets more efficient access data access and the Parallel Process Re-Scheduling allows for a different start order of integration processes. Due to our focus on integration process optimization and our recent work [DBLP:conf/bncod/Ritter15, 33], these techniques are not further considered. The same applies to Loop to parallel processes, since unfoldable loops are considered a special case in integration processes that would mostly impact patterns like Message Redelivery on Exception [34].

The dynamic data (DDx) optimization techniques mostly target data reduction (cf. OS2), e.g., Early-Filter, Early-Mapping, Early-Aggregation, and reduced interaction (cf. OS5), e.g., Ignore Failing Endpoints and Reduce Requests. The data reducing optimizations go along with a process re-ordering, which can even lead to an off-loading to a message endpoint, e.g., Execution Pushdown to Endpoints (cf. OS-4). The interactions can be reduced, e.g., by ignoring unreachable, non-responsive endpoints or frequently failing endpoints, as well as reducing the number of requests.

3.3 Optimizations Relevant for Application Integration

In this section, we assess the practical relevance or the found optimizations for EAI. We select only those optimizations contributing to strategies OS1–5, which makes the analysis comprehensive only for optimizations on processes (not “other”). Then we conduct an impact analysis of the selected optimizations by setting them into context of the objectives as depicted in Tab. 4.

In summary, the static control flow optimization techniques act as Process Simplification (cf. OS1), which improves the latency and reduce the modeling complexity. The sub-process generation technique allows for a more optimal separation of duties. The static data flow optimization techniques are useful to reduce the latency and modeling complexity. The dynamic control flow optimization techniques are part of the parallelization strategy (cf. OS3) and vastly impact the message throughput. Finally, the dynamic data flow optimization techniques are data reducing (cf. OS2), and thus mostly increase the message throughput. Some of the optimizations might improve the latency and the modeling complexity. The ignore failing endpoints and reduce requests optimizations improve the resilience of the integration process.

4 Realization of Optimization Strategies

In this section, we show the realization of the optimizations strategies by discussing the integration patterns that can be used for realizing them. We also discuss the execution order of the optimization strategies and a decision tree that helps to identify the fitting strategy as practical aspects of the realization.

4.1 Realization of Optimization Strategies

In this section we formally define the optimization techniques from the different identified optimization strategies OS1–OS5 in the form of a rule-based graph rewriting system. We begin by describing the graph rewriting framework, and subsequently apply it to define the optimizations.

4.1.1 Graph Rewriting

Graph rewriting provides a visual framework for transforming graphs in a rule-based fashion. A graph rewriting rule is given by two embeddings of graphs $L\hookleftarrow K\hookrightarrow R$, where $L$ represents the left hand side of the rewrite rule, $R$ the right hand side, and $K$ their intersection (the parts of the graph that should be preserved by the rule). A rewrite rule can be applied to a graph $G$ after a match of $L$ in $G$ has been given as an embedding $L\hookrightarrow G$; this replaces the match of $L$ in $G$ by $R$. The application of a rule is potentially non-deterministic: several distinct matches can be possible [9]. Visually, we represent a rewrite rule by a left hand side and a right hand side graph colored green and red: green parts are shared and represent $K$, while the red parts are to be deleted in the left hand side, and inserted in the right hand side respectively. For instance, the following rewrite rule replaces forks with straight edges:

Formally, the rewritten graph is constructed using a double-pushout (DPO) [10] from category theory. We use DPO rewriting since rule applications are side-effect free (e.g., no “dangling” edges) and local (i.e., all graph changes are described by the rules). We additionally use Habel and Plump’s relabelling DPO extension [13] to facilitate the relabelling of nodes in partially labelled graphs. A relabelling is shown in the example, where a property $p$ is rewritten to $p^{\prime}$.

In addition, we also consider rewrite rules parameterised by graphs, where we draw the parameter graph as a cloud (see e.g. Fig. 3(a) for an example). A cloud represents any graph, sometimes with some side-conditions that are stated together with the rule. When looking for a match in a given graph $G$, it is of course sufficient to instantiate clouds with subgraphs of $G$ — this way, we can reduce the infinite number of rules that a parameterised rewrite rule represents to a finite number. Parameterised rewrite rules can formally be represented using substitution of hypergraphs [26] or by !-boxes in open graphs [16]. Since we will describe optimisation strategies as graph rewrite rules, we can be flexible with when and in what order we apply the strategies. We apply the rules repeatedly until a fixed point is reach, i.e., when no further changes are possible. Methodologically, the rules are specified in a pattern-like formalsim with pre-conditions, change primitives, post-conditions and an optimization effect. The pre- and post conditions are part of the re-writing rule representation.

4.1.2 OS-1: Process Simplification

We first consider the process simplification optimization strategies from Sect. 2 that mainly strive to reduce the model complexity and latency.

Redundant sub-process

This optimisation removes redundant copies of the same sub-process within a process.

Change primitives: The rewriting is given by the rule in Fig. 3(a), where $SG1$ and $SG2$ are isomorphic pattern graphs with in-degree $n$ and out-degree $m$. In the right hand side of the rule, the $CE$ nodes add the context of the predecessor node to the message in the form of a content enricher pattern, and the $CBR$ nodes are content-based routers that route the message to the correct recipient based on the context introduced by $CE$. The graph $SG^{\prime}_{1}$ is the same as $SG_{1}$, but with the context introduced by $CE$ copied along everywhere.

Effect: The optimization is beneficial for model complexity when the isomorphic subgraphs contain more than $n+m$ nodes, where $n$ is the in-degree and $m$ the out-degree of the isomorphic subgraphs. The latency reduction is by the factor of subgraphs minus the latency introduced by the $n$ extra nodes $CE$ and $m$ extra nodes $CBR$.

Combine sibling patterns

Sibling patterns have the same parent node in the pattern graph (e.g., they follow a non-conditional forking pattern) with implied channel cardinality of $1$:$1$.

Change primitives: The rule is given in Fig. 3(b), where $SG_{1}$ and $SG_{2}$ are isomorphic pattern graphs that are side-effect free, and $F$ is an unconditional fork.

Effect: The model complexity and latency are reduced by the model complexity and latency of $SG_{2}$.

Unnecessary Fork Paths

A fork path is unnecessary, if the patterns on the path are side-effect free without a transitive connection to a message endpoint, or additionally read-only, when transitively connected to an endpoint.

Change primitives: The rules are given in Fig. 4, where $SG_{2}$ denotes a side-effect free and read-only subgraph, and $JR$ is a join router.

Effect: The model complexity and latency are reduced by the number and costs of the patterns in the subgraph.

4.1.3 OS-2: Data Reduction, OS-4: Pattern Placement

Now, we consider data reduction optimization strategies, which mainly target improvements of the message throughput (incl. reducing element cardinalities). These optimizations require that pattern input and output contracts are regularly updated with snapshots of element data sets $EL_{iC}$ and $EL_{oC}$ from live runtime systems, e.g., from experimental measurements through benchmarks [32].

All of the data reduction optimizations discussed in this section can also be applied as OS-4 pattern placement strategies (“Pushdown to Endpoint”), by extending the placement to the message endpoints. Due to our focus on integration processes, we will not further elaborate on this here.

Early-Filter

A filter pattern can be moved to or inserted prior to some of its successors to reduce the data to be processed. The following types of filters have to be differentiated:

• •

A message filter removes messages with invalid or incomplete content. It can be used to prevent exceptional situations, and thus improves stability.

• •

A content filter removes elements from messages. It can be used to reduce the amount of data passed to subsequent patterns.

Change primitives: The rule is given in Fig. 5(a), where $C/MF$ is either a content or message filter matching the output contracts of $SG_{1}$ and the input contracts of $P_{1}$, and filtering out the data not used by $P_{1}$.

Effect: The message throughput increases by the ratio of the number of reduced data elements that are processed per second, if not limited by the throughput of the additional pattern.

Early-Mapping

A mapping that reduces the number of elements in a message can increase the message throughput.

Change primitives: The rule is given in Fig. 5(b), where $P_{1}$ is an element reducing message mapping compatible with both $SG_{2}$, $SG_{3}$, and $SG_{1}$, $SG_{2}$, and where no pattern in $SG_{3}$ modifies the elements mentioned in the output contract of $P_{1}$. Furthermore $P_{2}$ is a content filter, which ensures that the input contracts of the subsequent patterns in $SG_{3}$ are satisfied.

Effect: The message throughput for the subgraph subsequent to the mapping increases by the ratio of the number of unnecessary data elements that have to be processed.

Early-Aggregation

A micro-batch processing region is a subgraph which contains patterns that are able to process multiple messages combined to a multi-message [28] or one message with multiple segments with an increased message throughput. The optimal number of aggregated messages is determined by the highest batch-size for the throughput ratio of the pattern with the lowest throughput, if latency is not considered.

Change primitives: The rule is given in Fig. 6(a), where $SG_{2}$ is a micro-batch processing region, $P_{1}$ an aggregator, $P_{2}$ a splitter which separates the batch entries to distinct messages to reverse the aggregation, and $SG^{\prime}_{2}$ finally is $SG_{2}$ modified to process micro-batched messages.

Effect: The message throughput is the minimal pattern throughput of all patterns in the micro-batch processing region. If the region is followed by patterns with less throughput, only the overall latency might be improved.

Early-Claim Check

If a subgraph does not contain a pattern with message access, the message payload can be stored intermediately persistently or transiently (depending on the quality of service level) and not moved through the subgraph. For instance, this applies to subgraphs consisting of data independent control-flow logic only, or those that operate entirely on the message header (e.g., header routing).

Change primitives: The rule is given in Fig. 6(b), where $SG_{2}$ is a message access-free subgraph, $P_{1}$ a claim check that stores the message payload and adds a claim to the message properties (and possibly routing information to the message header), and $P_{2}$ a content enricher that adds the original payload to the message.

Effect: The main memory consumption and CPU load decreases, which could increase the message throughput of $SG_{2}$, if the claim check and content enricher pattern throughput is greater than or equal to the improved throughput of each of the patterns in the subgraph.

Early-Splitter

Messages with many segments can be reduced to several messages with fewer segments, reducing complexity. Given scenario workload statistics $ws_{k}$ for scenarios $k$, and an assignment $M(p,ts)$ of number of segments for each process $p$ and throughput statistics $ts$, a segment bottleneck subsequence consists of a set of adjacent patterns $\{p_{1},\ldots,p_{m}\}$ such that their $ws_{k}$ is signinficantly lower than of their preceding and succeeding patterns. The patterns in the sequence must have a similar optimal segment size. Algorithmically, bottlenecks could be found using max flow-min cut techniques.

Change primitives: The rule is given in Fig. 7, where $SSQ_{1}$ is a segment bottleneck sub-sequence. If $SSQ_{1}$ already has an adjacent splitter, Fig. 7(a) applies, otherwise Fig. 7(b). In the latter case, $SP$ is a splitter and $P_{2}$ is an aggregator that re-builds the required segments for the successor in $SG_{2}$. For an already existing splitter $P_{1}$ in Fig. 7(a), the split condition has to be adjusted to the elements required by the input contract of the subsequent pattern in $SSQ_{1}$. In both cases we assume that the patterns in $SSQ_{1}$ deal with single- and multi-segment messages; otherwise all patterns have to be adjusted as well.

Effect: The message throughput increases by the ratio of increased throughput on less message segments minus, if the throughput of the moved or added splitter (and aggregator) $\geq$ message throughput of each of the patterns in the segment bottleneck sub-sequence after the segment reduction.

4.1.4 OS-3: Parallelization

Parallelization optimization strategies increase message throughput. Again, these optimizations are not completely decidable on static integration scenarios according to Sect. 2 but require experimentally measured message throughput statistics $MT_{c}$ (e.g., benchmarks [cs4681]).

Sequence to parallel

A bottleneck sub-sequence with channel cardinality 1:1 can also be handled by parallelizing it. The parallelization factor is the average message throughput of the predecessor and successor of the sequence divided by two, which denotes the improvement potential of the bottleneck sub-sequence. The goal is to not overachieve the mean of predecessor and successor message throughput with the improvement to avoid iterative re-optimization.

Change primitives: The rule is given in Fig. 8(a), where $SSQ_{1}$ is a bottleneck sub-sequence, $P_{2}$ a fork node, $P_{3}$ a join router, and each $SSQ^{\prime}_{k}$ is a copy of $SSQ_{1}$, for $1\leq k\leq n$. The parallelization factor $n$ is a parameter of the rule.

Effect: The message throughput improvement rate depends on the parallelization factor $n$, and the message throughput of the balancing fork and join router on the runtime. For a measured throughput $t$ of the identified bottleneck sub-sequences, the message throughput can be improved to $n\times t\leq$ average sum of predecessor and successor throughput, while limited by upper boundary of balancing fork or join router.

Merge parallel

The balancing fork and join router realizations can limit the throughput in some runtime systems, so that a parallelization decreases the throughput. This is called a limiting parallelization, and is defined as when a fork or a join has smaller throughput than a pattern in the following sub-sequence.

Change primitives: The rule is given in Fig. 8(b), where $P_{3}$ and $P_{4}$ limit the message throughput of each of the $n$ sub-sequence copies $SSQ^{\prime}_{1}$, …, $SSQ^{\prime}_{n}$ of $SSQ_{1}$.

Effect: The model complexity is reduced $(n-1)k-2$, where each $SSQ^{\prime}_{i}$ contains $k$ nodes. The message throughput might improve, since the transformation lifts the limiting upper boundary of a badly performing balancing fork or join router implementations to the lowest pattern throughput in the bottleneck sub-sequence.

4.1.5 Heterogeneous Parallelization

A heterogeneous parallelization consists of parallel sub-sequences that are not isomorphic. In general, two subsequent patterns $P_{i}$ and $P_{j}$ can be parallelized, if the predecessor pattern of $P_{i}$ fulfills the input contract of $P_{j}$, $P_{i}$ behaves read-only with respect to the data element set of $P_{j}$, and the combined outbound contract of $P_{i}$ and $P_{j}$ fulfill the input contract of the successor pattern of $P_{j}$.

Change primitives: The rule is given in Fig. 9(a), where the sequential sub-sequence parts $SSQ_{1}$, .., $SSQ_{n}$ can be parallelized, $P_{3}$ is a parallel fork, $P_{4}$ is a join router, and $P_{5}$ is an an aggregator that waits for messages from all sub-sequence part branches before emitting a combined message that fulfills the input contract of $P_{2}$. Similarly a rule for a heterogeneous merge is given in Fig. 9(b) (see Merge parallel above).

Effect: Synchronization latency can be improved, but the model complexity increases by 3. The latency improves from the sum of the sequential pattern latencies to the maximal latency of all sub-sequence parts plus the fork, join, and aggregator latencies.

4.1.6 OS-5: Reduce Interaction

Optimization strategies that reduce interactions target a more resilient behavior of an integration process.

Ignore Failing Endpoints

When endpoints fail, different exceptional situations have to be handled on the caller side. In addition, this can come with long timeouts, which can block the caller and increase latency. Knowing that an endpoint is unreliable can speed up processing, by immediately falling back to alternative.

Change primitives: The rule is given in Fig. 10(a), where $SG_{ext}$ is a failing endpoint, $SG_{1}$ and $SG_{2}$ subgraphs, and $P_{1}$ is a service call or message send pattern with configuration $cf$. This specifies the collected number of subsequently failed delivery attempts to the endpoint or a configurable time interval. If one of these thresholds is reached, the process stops calling $SG_{ext}$ and does not continue with the usual processing in $SG_{1}$, however, invokes an alternative processing or exception handling in $SG_{2}$.

Effect: Besides and improved latency (i.e., average time to response from endpoint in case of failure), the integration process behaves more stable due to immediate alternative processing. To not exclude the remote endpoint forever, the rule in Fig. 10(b) is scheduled for execution after a period of time to try whether the endpoint is still failing. If not, the configuration is updated to $cf^{\prime}$ to avoid the execution of Fig. 10(a). The retry time is adjusted depending on experienced values (e.g., endpoint is down every two hours for ten minutes).

Reduce Requests

A message limited endpoint, i.e., an endpoint that is not able to handle a high rate of requests, can get unresponsive or fail. To avoid this, the caller can notice this (e.g., by TCP back-pressure) and react by reducing the number or frequency of requests. This can be done be employing a throttling or even sampling pattern [34], which removes messages. An aggregator can also help to combine messages to multi-messages [28].

Change primitives: The rewriting is given by the rule in Fig. 11(a), where $P_{1}$ is a service call or message send pattern, $SG_{ext}$ a message limited external endpoint, $SG_{2}$ a subgraph with $SG^{\prime}_{2}$ a re-configured copy of $SG_{2}$ (e.g., for vectorized message processing [28]), and $SG_{cs}$ a subgraph that reduce the pace, or number of messages sent.

Effect: Latency and message throughput might improve, but this optimization mainly targets stability of communication. This is improved by configuring the caller to a message rate or number of requests that the receiver can handle.

4.2 Realization by Patterns

One way of realizing the optimization strategies is to use the integration patterns themselves. The patterns denote general categories of solutions for message processing, and thus cover a large solution space for the realization of optimizations. Subsequently, we assign and discuss the applicability of integration patterns to realize optimization strategies denoted in Sect. 2.

The basic characteristics of pattern compositions (i.e., soundness and reachability) as well as process simplifications (cf. OS-1) denote structural criteria on the pattern graph, and thus do not require patterns for their realization. There are 16 out of 153 patterns with potential of data reduction (cf. OS-2) can be categorized along message and message content reducing patterns. The message reducing patterns, reduce the amount of data through their potential to remove messages permanently (e.g., Content-Based Router, Message Filter, Selective Consumer, Idempotent Receiver, Channel Purger from [15], Message Cancellation, Message Expiration, Validate Message, Message Sampler from [31]) or temporarily (e.g., Claim Check [15]), combine messages (e.g., Aggregator, Composed Msg. Processor from [15]), or reduce their message content by filtering (e.g., Splitter, Content Filter from [15]), or data size reduction (e.g., Compress Content, Image Resizer from [31]).

Furthermore, there are 6 out of 153 patterns supporting the parallelization of the control flow (cf. OS-3). The realization of parallel patterns and sequences, requires non-conditional forking (e.g., Multicast [31], Scatter-Gather, Wire Tap from [15]) and joining (e.g., Join Router [31]) patterns. In addition, heterogeneous load balancing can be realized structurally by a Load Balancer [31] and content-wise by an Aggregator pattern.

Since the pattern placement (cf. OS-4) denotes an extension of OS-2, all OS-2 patterns are applicable as well (i.e., 16+12 out of 153). The patterns that can be additionally pushed-down to the sender are categorized as early-quality of service (e.g., Guaranteed Delivery [15]) and Early-Operation (e.g., Adapter Flow, Content Sort, Custom Script, Find and Replace, Language Translator, Message Interceptor, Type Converter from [31]). The patterns for push-back are according to their categories right-place (e.g., Content Enricher [15]) and late-quality of service (e.g., Idempotent Receiver, Resequencer from [15], Commutative Endpoint [31]).

The reduction of interactions between endpoints (cf. OS-5), for which 13 out of 153 patterns can be used, can be categorized into flow control (e.g., Back Pressure, Message Sampler, Message Throttler, Pause Operation, Timeout from [31]), resilience (e.g., Circuit Breaker [31]), prevention (e.g., Load Balancer), tolerance (e.g., Delayed Redelivery, Failover Request Handler from [31]), filtering (e.g., Request Collapsing, Request Caching, Request Partitioning from [31], Aggregator). Thereby most of the patterns from the flow control category reduce the number of requests per time, but not the general number of messages that lead to requests.

4.3 Pattern Stratification

The catalog of optimization strategies from Sect. 2 contains optimizations that have a similar effect, revert, support or inhibit each other. Hence, we analzyed the dependencies between the optimizations and propose an order of their execution.

Figure 12 shows the order, in which the optimization strategies can be executed. The order is determined based on the conditions and impact of the optimization strategies. According to that DC6 might lead to SC1, while SC1 might revert DC6, hence SC1 before DC6. The dynamic control optimizations DC6 and DC8 revert each other, and thus require an order. This order implicitly comes from the observation that DC8, SC1, SD4,5 have a similar effect, and are thus related. Since we know that SC1 comes before DC6, optimizations {SC1, SD4,5, DC8} have to be executed before DC6 DC6 should be executed before SD4,5, since it might produce SD4,5. The static data optimization SD4,5 might inhibit DC8 in some cases, hence DC8 before SD4,5. As an intermediate summary, we can formulate the general rule “structure before data”: strategies OS-1 and OS-3, before OS-2.

Now, the data reduction strategy optimizations DD6, DD4 have a similar effect, and thus can be applied in arbitrary order. The same is valid for DD14, DD4. Since DD14 might work on too many messages, DD6 should be before DD14 to reduce the number of messages.

The pattern placement strategy OS-4 might extend the reach of OS-2, hence OS-2 before OS-4.

The pattern placement strategy OS-4 might extend the reach of OS-2, hence OS-2 before OS-4. The OS-5 strategies profit from all previous strategies and thus come last.

5 Case Study: Italy Invoice Scenario (revisited)

In this section, we study the application of the optimization strategies to the case of our motivating scenario. Thereby the strategies are applied iteratively according to the sequence from Fig. 12, unntil no further graph re-writing can be found.

5.0.1 Simplify the Integration Process

The algorithm starts on the integration process Fig. 1 by matching and applying the process simplification (OS-1) optimizations, whose sequence can be arbitrary. For example, first, the redundant control flows (cf. SC1) starting from Encode Message for transformation and ending with Map to target format are identified and rewritten to a sequence without the multicast and join router patterns. Then the dead paths (SC2) Content Enricher to End Event is removed. And finally, the sibling patterns Sign Invoice and Ensure no duplicate invoices are identified and merged. They are placed before the Content-based Router, thus pulled out of the conditional fork! The resulting integration process is shown in Fig. 13. The original modeling complexity of $15$ patterns was reduced to $10$ patterns.

5.0.2 Scale the Sub-Processes of the Integration Process

Now the OS3 parallelzation strategies are applied on Fig. 13.

• transformed sequence to parallel

5.0.3 Place Integration Sub-process to where they belong

Figure 16 shows the original integration process from Fig. 1 after the application of strategies OS-1 to 4 in the order denoted in Fig. 12. Notably, the Message Filter could be pushed down to the sender, which sends only relevant data for the receiver plus the data needed by the integration process. The combination of Encode Message and Message Transformation can be executed in parallel to the Content Enricher. Then the invoice is signed and sent to the authorities, which recognize duplicates and discard them. Further OS-5 strategies could be applied, if necessary.

6 Discussion

In this work we collect and briefly explain a catalog of optimizations techniques from related domains that we transfered to EAI optimization strategies. We formalize these optimizations and discuss their stratification as well as show the applicability for an extended scenario.