Patterns for Emerging Application Integration Scenarios: A ...€¦ · Patterns for Emerging Application Integration Scenarios: A Survey Daniel Rittera,b, Norman Maya, Stefanie Rinderle-Mab

Patterns for Emerging Application Integration Scenarios: A Survey

Daniel Rittera,b, Norman Maya, Stefanie Rinderle-Mab

aSAP SE, Germany

bUniversity of Vienna, Faculty of Computer Science

Abstract

The discipline of enterprise application integration (EAI) enables the decoupled communication between(business) applications, and thus became a cornerstone of today’s IT architectures. In 2004, the book byHohpe and Woolf on Enterprise Integration Patterns (EIP) provided a fundamental collection of messagingpatterns, denoting the building blocks of many EAI system implementations. Since then, multiple newtrends and a broad range of new application scenarios have emerged, e. g., cloud and mobile computing,multimedia streams. These developments ultimately lead to conceptual changes and challenges such aslarger data volumes (i. e., message sizes), a growing number of messages (i. e., velocity) and communicationpartners, and even more diverse message formats (i. e., variety). However, the research since 2004 focused onisolated EAI solutions, and thus a broader and integrated analysis of solutions and new patterns is missing.In this survey, we summarize new trends and application scenarios which serve as a frame to structure oursurvey of academic research on EIP, existing systems for EAI and also to classify integration patterns fromthese sources. We evaluate recently developed integration solutions and patterns in the context of real-worldintegration scenarios. Finally, we derive and summarize remaining challenges and open research questions.

Keywords: Cloud integration, device integration, enterprise application integration, enterprise integrationpatterns, hybrid integration

1. Introduction

Enterprise Application Integration (EAI) ad-dresses the requirement to integrate independentapplications which need to communicate with eachother [1, 2]. Hence, some middleware is employedto abstract from the details of communication andorchestration of applications. For the purposes ofintegration, a set of core Enterprise Integration Pat-terns (EIP) were documented in [3], which describerecurring scenarios and solutions to realize EAI us-ing messaging.Originally, EAI focused on the integration of ap-

plications within a single organization. However,as hosting (parts of) applications in the cloud be-comes increasingly popular, EAI also needs to ad-dress scenarios where applications that are hostedin the cloud or on-premise (i. e., within company

Email addresses: [email protected] (DanielRitter), [email protected] (Norman May),[email protected] (StefanieRinderle-Ma)

networks) need to be integrated. We refer tosuch scenarios as hybrid applications, following For-rester [4]. Especially hybrid applications requirea stronger decoupling to integrate on-premise withcloud applications, and consequently, hybrid appli-cations prefer to use (asynchronous) message-basedcommunication patterns, while RPC-style integra-tion is still quite common for EAI in on-premisesetups. Most of the current research focuses onRPC-style Service-oriented Architecture (SOA).

1.1. New Challenges for Enterprise Application In-tegration

In this paper we identify further new IT trendsand application scenarios which emerged after theseminal book on EIP by Hophe and Woolf [3]. Someof these changes, e. g., Cloud and Mobile Com-puting, IoT, Microservices, and API Management,were even recently acknowledged by the EIP au-thors [5].

One major source for identifying new trends isthe yearly published “Emerging Technologies Hype

Preprint submitted to Journal of L

AT

E

X Templates March 13, 2017

Figure 1: IT trends since 2005 in the context of application integration.

Cycle” report between 2005 and 2017 by Gartner[6]. We focused on the most relevant trends for ap-plication integration today, i. e., we excluded trendslike machine learning and analytics in the analysispresented in this paper. The results are depictedin Fig. 1. Both our literature review in Sect. 2 andour system review in Sect. 3 are consistent withthe trends identified by the Gartner reports becauseboth academic research as well as concrete systemsaddress these trends.

Broadly speaking, the early years (2005 to2007) are dominated by Service-oriented Architec-ture (SOA) and Event-driven Architecture (EDA)styles. But also related technologies like Microser-vices are mentioned by Gartner in 2017 [6], and APIManagement by Forrester for 2016 to 2018 [7].

The Cloud Computing trend became prominentin 2007 and subsequently led to trends like HybridComputing, i. e., multi-cloud and on-premise appli-cations, from 2013 to 2015 and the move from B2Bto cloud-based business networks. Early develop-ments in the Internet of Things (IoT) became influ-ential even before 2006 to 2008 even though deviceswere not yet a↵ordable and wide spread. However,with the advent of Mobile Computing in 2010, mo-

bile and IoT devices and applications (since 2012)started to play a role for application integration.As countless devices and applications generated anincreasing amount of data, Big Data (from 2011)became influential and a challenge not only for in-tegration systems. Finally, humans increasingly or-ganized themselves in social media with its momen-tum from 2008 to 2012, which evolves to personalcomputing, supported by wearable and mobile de-vices and applications.

In Figure 2 we associate the trends mentionedin Fig. 1 with aspects of application integration.While some of the nodes represent the trends (i. e.,without application and integration system), theedges denote required interaction and (transitive)communication, which also gives hints on existingas well as new integration scenarios for the di↵erentcombinations. Node spanning trends are denotedby “dashed-line” nodes.

It is noteworthy that for hybrid application in-tegration for both on-premise to cloud as well ascloud to cloud communication becomes relevant,e. g., for migration of on-premise applications tothe cloud. This raises technical issues like secu-rity but also robustness in the face of errors or

2

Figure 2: IT trends since 2005 an their relationship to application integration.

unavailable communication partners. Furthermore,cloud, on-premise and mobile applications generatecommunication tra�c of an ever increasing scalewith respect to the amount of data but also thenumber of communication partners. In this cloudsetup organizations replace the bilateral RPC-stylecommunication by asynchronous, message-based in-teractions which are mediated by integration sys-tems. When the applications in an EAI scenarioare partly hosted by cloud providers, monitoringbecomes more challenging because the interfacesavailable for monitoring may be limited. We also re-view these and other non-functional aspects in ourliterature review in Sect. 2, our system review inSect. 3 and in the context of real-world integrationscenarios in Sect. 6.

1.2. Research Method

This survey relies on the design science method-ology [8] as a rigid method to collect and evaluatethe new trends mentioned above, to summarize re-search which adds new patterns to the original EIP,and to evaluate these new patterns in the contextof real world application scenarios. Fig. 3 depictsthe research method applied in this paper, and weuse it to structure this paper.Our fundamental theory and motivation for this

paper is: The original EIP from 2004 do not com-pletely cover new trends in 2016 and beyond. Fromthis we derive hypothesis (H1), i. e., the existingEIP do not su�ce for all application scenarios after

2004. This hypothesis is tested based on two obser-vation artifacts, i. e., a systematic literature reviewin Sect. 2 and a systematic system review in Sect. 3.Based on the literature review we analyze whethernew trends and application scenarios can be seenafter 2004 and which solutions are provided. Thesystem review aims at analyzing available systemsregarding their support for integration. Interpret-ing the literature and system reviews then leads usto the tentative hypothesis (H2) that current sys-tem implementations support patterns beyond EIPwhich results in a strong demand for systematic de-scription. In order to address the detected gapswe propose new pattern categories and patterns.In hypothesis (H3) we argue that some trendsare handled in an (yet) immature and ad-hoc fash-ion, and thus require a structuring in form of pat-terns. These artifacts are then evaluated based ona quantitative analysis of several real-world inte-gration scenarios following the hypothesis (H4)solutions not in EIP can be found in real-world in-tegration scenarios for the trends. Finally, resultingresearch directions are described.

1.3. Contributions and Paper OutlineIn this paper we make the following contribu-

tions:

• A systematic literature review of the trends,e. g., cloud and hybrid application integrationapproaches ( 7! H1), and an analysis of themost influential system implementations of thisdomain ( 7! H2).

3

Figure 3: Design science methodology used in this paper.

• An extended pattern template plus an exam-ple based on descriptions of cross-concern tech-nical qualities (e. g., (stateful) conversation,streaming, security) for a comprehensive cov-erage of new requirements ( 7! H3).

• The evaluation of the found patterns as partof integration scenarios in a well-establishedcloud integration system in form of a quantita-tive analysis based on new monitoring patterns( 7! H4).

The paper is structured as follows. In Sect. 2 theliterature review of approaches that are closely re-lated to application integration and integration pat-terns is conducted by setting them into context tothe new trends since 2004. Section 3 describes thesystem review with focus on non-functional aspects(NFA) – related to the trends – identified during theliterature review, thus leading to a list of potentiallymissing functionality. In Sect. 4, we discuss how tocapture the functionality as patterns, similar to theoriginal EIP, and discuss two patterns in more de-tail Sect. 5. Then we analyze and discuss real-worldintegration scenarios related to the trends and theirusage of the new patterns in Sect. 6. Section 7 con-cludes the paper and states open issues which are

not addressed in existing work.

2. Literature Review

In this section we conduct a literature review inorder to answer the hypothesis H1: existing integra-tion foundations in form of patterns do not su�cefor all application scenarios as set out in Fig. 3.The hypothesis raises two questions to be investi-gated in the literature review, i. e., a) are there anytopics after 2004 not yet covered by the originalEIP? and if yes b) do existing approaches providesolutions to these topics?.

The literature review is based on the guide-lines described in [9]. The primary selectionof references was conducted using google scholar(scholar.google.com) on 2016-10-4. The searchstring was

allintitle: integration patterns

excluding patents and citations. As a generalbaseline, only papers after 2004 are considered asthe main theory behind this study is that the EIPfrom 2004 do not cover trends in 2016. Hence thetime range was set to 2005 – 2016. Overall thisresulted in 525 hits. On these hits, the followingselection criteria were applied:

4

• relation to computer science, enterprise appli-cation integration, service integration, data in-tegration, system integration

• availability of the document

• published in English

• published (excluding Master theses)

Altogether, 52 papers were selected as rele-vant (the primary literature list can be foundhere: http://cs.univie.ac.at/wst/research/

projects/project/infproj/1085/). These 52papers were further analyzed whether they con-tribute as observations to the hypotheses. Thisresulted in removing 23 papers from the primaryliterature list (for example, papers were excludedthat focus on data integration). Then a verticalsearch was conducted in forward and backward di-rection, resulting in 43 papers, including one pa-per that was added based on expert knowledge.After analyzing these papers, 34 were includedin the secondary literature list. Overall, this re-sults in 63 papers for the secondary literature list(to be found at http://cs.univie.ac.at/wst/

research/projects/project/infproj/1085/).

2.1. Processing of selected literature – topics andtrends

At first, all papers from the secondary literaturelist were analyzed with respect to the topics theyare mentioning. Comparing the harvested topicswith the trends identified in the introduction givesan answer to question a) are there any topics af-ter 2004 not yet covered by the EIP?. In this firststep it is su�cient that a topic is mentioned. It wasnot necessary that a solution was provided. As thecollected topics are very fine granular and spreadwidely, they were first grouped according to thetrends mentioned the introduction.Figure 4 depicts the distribution of topic men-

tions along the trend over time. It can be seen thatSOA (i. e., RPC-style integration [3]) plays a dom-inant role, particularly in the years 2005 – 2013.During this period, some topics such as mashups,cloud, and EDA were occasionally mentioned. Inthe last years, i.e., 2014 – 2016 the picture seemsto change, turning away from the strong focus onSOA towards topics such as cloud, hybrid, and IoT.From Fig. 4 it can be concluded that some of the

trends occurred in the literature after 2004 witha dominant occurrence of SOA. Apparently, since2014 SOA loses significance, and other trends such

as IoT and cloud seem to gain more attention. Fromthe dominance of SOA we also conclude that amore fine-grained analysis of the mentioned topicsis meaningful. Hence, in the following, summariesfor the analyzed approaches are provided, orderedby the topics and areas they work on. Subsequently,the list of trends will be complemented with NonFunctional Aspects or requirements (NFA) men-tioned by literature that constitute further impor-tant topics for EAI since 2005. Moreover, if ap-proaches provide solutions with respect to the dif-ferent topics, the type of solution will be collected.

2.2. Literature summaries

This section summarizes the approaches iden-tified in the literature search. We organize thesummaries chronologically by following the time-line from Fig. 1. In the context of EAI, no workwas found on the internet of things, social/personalcomputing, microservices, and API management,which can be seen as successor of the Service-oriented Architecture trend. In addition to thetrends, for each approach we try to derive addi-tional NFA as well as the proposed solutions. Theharvested NFA and solutions are summarized at theend of the section in Tab. 1 and yield the input forthe further analysis.

2.2.1. Service-oriented and Event-driven Architec-tures

According to the timeline, the first EAI solu-tions after 2005 were provided by Service-orientedand Event-driven Architectures representing mostlyRPC-style solutions (i. e., a post shared databaseand file sharing integration style, compared to“messaging” like EIP, according to [3]).

Service-oriented Architecture. Hentrich and Zdunpresent patterns that address data integration is-sues such as incompatible data definitions, incon-sistent data across the enterprise, data redundancy,and update anomalies [10]. It is described howto integrate the application-specific business objectmodels of various external systems into a consis-tent process-driven and service-oriented architec-ture. In summary, the proposed solution combinesSOA with patterns, e. g., refactoring patterns. In[11], the authors propose a pattern language for de-sign issues of business process-driven service orches-trations. The patterns illustrate how these typesof service invocation need to be reflected in processmodels in order to integrate processes with services.

5

Figure 4: Distribution of topics mentioned in literature over time.

Implications regarding the functional architectureare also captured by the patterns. Specifically, thepatterns reflect solutions for general business re-quirements that can be found in SOA engagements.Overall, the paper proposes a solution, more pre-cisely, a pattern language covering, for example,Synchronous Service Activity, Fire Event Activity,and Asynchronous Sub-process Service.

In subsequent work [12] the authors present solu-tions to Process-driven SOA patterns in the senseof a process integration architecture featuring pat-terns at Macro Flow (business process) and MicroFlow level (transaction or human), as well as Inte-gration Adapter, Configurable Dispatcher, and In-tegration Adapter Repository. These patterns cor-respond to the ones proposed in [10]. Furthermorelong-running business processes are distinguishedfrom short-running technical processes. Zdun etal. present a survey of technology-independentpatterns that are relevant for SOA and argue to-wards formalized pattern-based reference architec-ture model to describe SOA concepts [13]. Finally,Zdun describes a federation model to control re-mote objects and proposes a solution based on pat-terns, e. g., broker and software patterns [14].

Autili et al. discuss challenges posed by the het-erogeneity of Future Internet services [15]. Modernservice-oriented applications automatically com-pose and dynamically coordinate software servicesthrough service choreographies described based onBPMN 2.0 Choreography Diagrams. The authorsstate that currently composition and adaptationis often a manual task, Hence, they advocate to-wards the automatic synthesis of choreography-based systems and describes preliminary steps to-wards exploiting Enterprise Integration Patterns todeal with a form of choreography adaptation. Con-cretely, an adapter generator and prototype usingspring integration is presented. Example patternscomprise Message Routing Patterns, namely Mes-sage Filter, Aggregator, Splitter, and Resequencer.Overall, this work bridges SOA to EAI using EIPand protocol adapters for services. Moreover, it isplanned to integrate EIP with security patterns andmessage transformation as future work.

In Gacitua-Decar and Pahl an ontology-basedapproach to capture architecture and process pat-terns is presented [16]. Ontology techniques for pat-tern definition, extension and composition are de-veloped and their applicability in business process-

6

driven application integration is demonstrated.The proposed solution is an architecture frameworkfor SOA-based EAI as well as an ontology-basednotion of patterns to link business processes andservice architectures. This could be seen as a for-malization approach. A SOA service integrationframework with a pattern-based modeling approachis presented by Heller and Allgaier [17]. It featurescontrolled extensibility of enterprise systems for un-foreseen service integration and can be estimated assimilar to related B2B Integration and EnterpriseApplication Integration. The framework leveragesstructural or behavioral interface mediation tech-niques. The modeling approach with adaptationpatterns and runtime support is demonstrated witha UI integration prototype in the automotive do-main. Overall, this work suggests pattern-basedmodeling as solution. Kaneshima and Braga anal-yse whether EAI can be conducted by web ser-vices and SOA or DB sharing [18]. Both solutionsare being adopted by organizations, although theypresent advantages and disadvantages that shouldbe analysed. This work documents these problemsand solutions in the form of patterns like access viaShared Database, direct RPC-style integration viaweb services, Intermediate Duplication with accessvia DB or web services. Hence, the proposed solu-tion is based on SOA and patterns.Umapathy and Purao transform EIP to web ser-

vice implementations using a transformation modelcalled ceipXML [19]. The proposed solution com-prises conversation models that may be used to im-plement interactions among Web services as well asa methodology that generates the design elementsin the form of conversation policies for Web ser-vices. Current integration approaches do not sup-port the end user development requirements for in-frequent, situational or ad-hoc integration and col-laboration as stated by Zheng et al. [20]. Thework di↵erentiates between UI, component, busi-ness logic, resource and data integration. Gierdset al. define an approach for behavioral adaptersbased on domain-specific transformation rules thatreflect the elementary operations that adapters canperform; synthesize complex adapters that adhereto these rules [21]. The proposed solution com-prises a formalization, specification of the elemen-tary activities to model domain knowledge, separat-ing data from control, and a reduction from adaptersynthesis to controller synthesis. An adapter is gen-erated to reconcile mismatches (e. g., incompatibleprotocols) in Sequel et al. [22]. The proposed solu-

tion is constituted by a survey of protocol adaptergeneration (e.g., semi-automated protocol adaptergeneration). Gudivada and Nandigam deal withEAI using extensible Web services [23]. A solu-tion is not directly proposed, but rather a practicalimplementation. Deng et al. combines SOA andWeb service technology to simplify EAI by study-ing the service-oriented software analyzing and de-velopment characteristics [24]. The approach dis-tinguishes between vertical integration within anenterprise while B2B emphasize on the horizontalintegration. Again the paper presents a more prac-tical implementation.

SOA and Mobile Computing. Mauro et al. [25] tar-get design problems of SOA for mobile devices withService Oriented Device Architecture (SODA). Forthis SOA design patterns like Enterprise Inven-tory are analyzed with respect to their applica-bility to SODA, and new pattern candidates likeService Virtualization are identified. From thesecandidates new (device) patterns including Auto-Publishing, Dynamical Adapter, Server Adapter,Integrated Adapter, External Adapter are proposedas solution.

SOA and Mashups. Liu et al. combine severalcommon architecture integration patterns, namelyPipes and Filters, Data Federation, and Model-View-Controller to compose enterprise mashups[26]. Moreover, these patterns are customized forspecific mashup needs. In [27] enterprise architec-ture integration patterns (e. g., Pipes and Filter,Data Federation, Model-View-Controller) are lever-aged in order to compose reusable mashup compo-nents. The authors also present a service orientedarchitecture that addresses reusability and integra-tion needs for building enterprise mashup applica-tions. The proposed solutions focus on SOA andmashups, but no solution to EIP and new trends isprovided. The work by Braga et al. addresses issuesof complexity of service compositions with adequateabstraction to give end users easy-to-use develop-ment environments [28]. Abstract formalisms mustbe equipped with suitable runtime environmentscapable of deriving executable service invocationstrategies. The solution tends towards mashupsand modeling as users declaratively compose ser-vices in a drag-and-drop fashion while low-level im-plementation details are hidden. However, the solu-tion could not be clearly identified and is hence notincluded in Tab. 1. Finally, Cetin et al. chart a road

7

map for migration of legacy software to pervasiveservice-oriented computing [29]. Integration takesplace even at the presentation layer. No solution isprovided for EIP and trends, however, mashups areused as migration strategy to SOA based for theWeb 2.0 integration challenge.

SOA Security. Qu et al. present six bilateral pat-terns (Binding, On-demand, Tailor, Composite,Contract and Migration) and four multilateral pat-terns (Separated, Shared, Mediated and Enhanced)as a solution for integrating new services with Gridsecurity services [30]. For each pattern, the au-thors discuss its intent, applicability, participantsand consequences. Shah and Patel analyse thesecurity requirements for global SOA [31]. Forsecurity concerns, dynamic configuration of han-dlers, sequence, and identification of handlers isproposed as solution. Fisher et al. provide prac-tical implementations in Java and .NET for inter-operable, synchronous, and asynchronous integra-tion [32]. Hence, the proposed solution consists ofimplementation details for SOA, WS security ex-amples, and best practices such as a secure objecthandler adding custom interceptor logic for, e. g.,adding digital signatures.

SOA and Business Processes. Ouyang et al. for-malize process control flows into BPEL processesby an intermediate translation to Petri nets [33].From the same group, Wang et al. construct and in-terface adaptation machine that sits between pairsof services and manipulates the exchanged mes-sages according to a repository of mapping rules.For both approaches, the proposed solution is aformalization. Lohmann et al. analyze the in-teraction between WS-BPEL processes using Petrinets [34]. Again the proposed solution is a formal-ization. With a similar goal, Kumar and Shan aimat simplifying the pattern compatibility based on amatrix and rules that enable the simplification ofchecking compatibility between two or more pro-cesses because these prerequisite rules can be ap-plied to each pattern separately [35]. The proposedsolution is an algorithm and can hence be sub-sumed as formalization. Mismatch patterns thatcapture the possible di↵erences between two ser-vice (business) protocols to adapt and automat-ically generate BPEL adapters are presented byJiang et al. [36]. They introduce several depen-dencies such as transformation dependency (incl.message split), synchronization dependency, choice

dependency (choice among two ore more messages),and priority dependency. The proposed solutionis the formalization of mismatches. Barros et al.propose SOA process interaction patterns includingSend, Receive, Send/Receive, and Racing IncomingMessages [37]. Patterns for synchronization prob-lems in the area of process-driven architectures,e. g., Waiting Activity or Timeout Handler, are in-troduced by Kollmann and Hentrich [38]. Vernadatlooks at architectures and methods to build interop-erable enterprise systems, advocating a mixed ser-vice and process orientation and the classificationof integration levels, physical system, application,business integration, and enumerates SOA concepts[39]. No specific solution is proposed. Grossmannet al. derive integration configurations from under-lying business processes, e. g., activities [40]. Futurework names exception handling as challenge, how-ever no solutions are provided.

Event-driven Architecture (EDA) and SOA. Tayloret al. address the SOA - EDA connection as servicenetwork and provide a reference EDA manual [41].As no solution is provided, the approach is not in-cluded in Tab. 1. A theoretical framework for mod-eling events and semantics of event processing isprovided by Patri et al. [42]. The formal approachenables to model real-world entities and their in-terrelationships and specifies the process of movingfrom data streams to event detection to event-basedgoal planning. Moreover, the model links event de-tection to states, actions, and roles enabling eventnotification, filtering, context awareness, and esca-lation. The proposed solution consists of events andformalization.

2.2.2. Cloud Computing, Business Networks, andHybrid Applications

The successor of grid and cluster computing iscloud computing that extends B2B to businessnetworks, and the coexistence of applications on-premise and in several kinds of cloud platforms ashybrid applications.

Cloud Computing. Asmus et al. focus on the mi-gration of enterprise applications to the cloud [43].Integration is considered a key factor influencingcloud deployment. Several migration patterns aredescribed as a basis for enabling enterprise cloudsolutions. The following challenges are named inthe paper: data volume, network latency, iden-tity and data security management, interoperabil-ity (i. e., supporting the trends big data, security,

8

and variety as in multimedia). Asmus et al. statethat “integration pattern can be a starting point indeciding integration options” [43]. The key areasaddressed in the approach include on premise, o↵-premise private cloud, cloud integration, cloud ser-vice provider, and external users. The integrationpatterns refer to process to process and data inte-gration. Overall, the proposed solutions are “pat-terns and processes-based” methods for an initialevaluation of the risk and e↵ort required to movenew and existing applications to a cloud service.In Ritter and Rinderle-Ma, a collection of integra-tion patterns derived from requirements of hybridand cloud applications is presented [44], thus pro-pose a solution for cloud and patterns. The mainchallenge described by Merkel et al. is a secureintegration [45]. The approach proceeds in a top-down manner by deriving integration patterns fromscenarios and in a bottom-up fashion by derivingpatterns from case study requirements. It identifiesthe need for security (access control, integrity, con-fidentiality) as well as security constraints (e. g., EUData Protection Directive) and presents an evalu-ation based on an architecture with major focuson hybrid and multi-cloud setups. The describedpatterns are cross-cloud ESB, usage of ESBs, aswell as security patterns as architecture compo-nents such as LDAP. The approach only works inprivate clouds. Merkel et al. propose future workon public cloud that involves content encryption,key management, data splitting, computing withencryption functions, anonymization, data mask-ing, and encrypted virtual machines. They men-tion Cross-Cloud Balancer, Cross-Cloud Data Dis-tributor, and replication patterns as further futurework. Other challenges mentioned are cross-cloudmonitoring and cloud management. In summary,the proposed solution are new patterns for SaaS in-tegration and centralized as well as decentralizedmulti-cloud integration.

Business Network. Ritter provides mappings ofEIP integration semantics and patterns to BPMN-based models as well as an implementation of abusiness network scenario example [46, 47]. Bothworks do not directly propose a solution to thetrends depicted in Fig. 4, but introduce modelingas a possible solution in the context of EIP, thusadded as category to Tab. 1.

Hybrid Applications. A major challenge in hybridapplications is the decision where to host parts of

the application. In this regard, Mansor recom-mends to bear in mind the patterns in the envi-sioned process [48]. The work addresses techni-cal challenges when implementing a hybrid archi-tecture. The proposed solution refers to architec-tural patterns. A holistic approach for the devel-opment of a service-oriented enterprise architecturewith custom and standard software packages is pre-sented by Buckow et al. [49]. The system architec-ture to be developed is often based on integrationpatterns for the physical integration of systems. Nosolution is provided in the context of this work.

2.2.3. Internet of Things and Big data

With a↵ordable and widespread mobile sensorsand devices comes the Internet of Things and to-gether with the immense amount of data from cloudand mobile computing comes Big data.

Internet of Things (IoT). Heiss et al. collectchallenges in cyber-physical systems such as com-munication quality, interoperability, and massiveamounts of data [50]. As interesting requirementsthey state “placement” (of integration scenarios),e. g., cloud or on-device, the demand for global op-timization, more intelligent devices, networking andcloud and security including data security and pri-vacy etc., decoupling of layers vs. direct data ac-cess for on-top applications. Rather than proposinga solution, the industrial and business perspectiveson such envisioned platforms are described.

Big data. Ritter and Bross suggest moving-up rela-tional logic programming for implementing the in-tegration semantics within a standard integrationsystem [51]. For this EIP semantics is translated torelational logic. For declarative and more e�cientmiddleware pipeline processing (e. g., parallel exe-cution, set-operations), the patterns are combinedwith Datalog. The expressiveness of the approachis discussed, and a practical realization by exam-ple is provided. Although no direct solution to thetrends is provided the approach directs to “data-aware” integration patterns.

2.2.4. General EAI approaches

From practical EIP implementations to ideas fornew patterns, formalization approaches, enablingtechniques and domain-specific work, this sectionrounds o↵ the literature analysis with further EAIchallenges.

9

Practical Aspects. Scheibler and Leymann presenta framework for configuration capabilities of EIP,specifically for code generation based on a model-driven architecture [52]. In [53], EIP are imple-mented in IBM WebSphere. Again no solution forthe trends is provided, but a solution to the EIPthrough implementation. Thullner et al. analyseEIP coverage in open source tools and implementa sample scenario in Apache Camel and Mule [54].No solution is provided.

EAI Patterns. [55] presents a pattern language forconversations between loosely coupled services, i. e.,patterns are suggested as solution. Gonzales andRuggia deal with response time and service satu-ration issues (more requests than can be handled)using an adaptive ESB infrastructure [56]. Theypropose solutions in the form of strategies, i. e., De-layer, Defer Requests, Load Balancing, and Cache.

Formalization and Verification. Fahland andGierds present a conceptual translation of EIPinto Colored Petri nets, hence providing a formalmodel based on a system specification using EIP[57, 58]. The Petri net based formalizations canbe used to simulate and conduct model checkingof pattern compositions. Though the formalizationcan be understood as solution, it does not addressany new trends beyond EIP, thus this approach isnot contained in Tab. 1. A semantic representationof EIP for automatic management of messagingresources (e. g., Channels, Filters, Routers) ispresented by Patri et al. [59]. The applicationis to connect mobile customers to Smart PowerGrid companies. Data is accessed in form ofalerts from a complex event processing engineusing SPARQL queries. The proposed solutionis a formalization for resource management ofintegration patterns. Basu and Bultan focus onthe interaction behavior in asynchronously commu-nicating systems resulting in decidable verificationfor a class of these systems [60]. As the proposedsolution (formalization) is not in the context ofthe trends, it is not included in Tab. 1. Mederly etal. generate a sequence of processing steps neededto transform input message flow(s) to specifiedoutput message flow(s) [61, 62]. The work takesinto account requirements such as throughput,availability, service monitoring, message ordering,and message content and format conversions.Additionally, it uses a set of conditions, inputand output messages, and a set of configuration

options. Control flow ordering is formalized. Thework is excluded from Tab. 1 because it providesno solution, but rather creates parts of integrationsolutions from the description of what has to beachieved, not how it should be done.

EAI enabling techniques. The following approachesaddress di↵erent enabling technologies. However,neither are the presented approaches related tothe trends, nor do they propose concrete solutions.Hence they are not included in Tab. 1. Architec-tural patterns (e. g., Remote Process Invocation,Batch Data Synchronization, SOA, Pub/Sub, P2P,Broker, Pipes and Filters, Canonical Data model,Dynamic Router) are contributed by Kazman etal. [63]. This work constitutes a guideline for ITarchitects that combines existing patterns. Landet al. integrate the existing software after restruc-turing or merger, i. e., address the question of howto carry out the integration process [64]. Multiplecase studies and recurring patterns for vision pro-cess and an integration process are provided as well.Basic concepts of enterprise architectures includingintegration and interoperability are summarized byChen et al. [65].

Domain-specific Approaches. Cranefield andRanathunga integrate agents with a variety of ex-ternal resources and services using Apache Cameland the EIP endpoint concept [71]. e-Learning asa growing and expanding area with huge numberof disparate applications and services is addressedby Rajam et al. [68]. The approach redefines theModel-View-Controller pattern. It can be furtherenriched to encapsulate certain non-functional andintegration activities such as security, reliability,scalability, and routing of request. As all theseapproaches do not propose a solution directlyconnected to EIP and the trends, and hence theyare not included in Tab. 1.

EAI Challenges. A survey to motivate some morechallenges in the area of enterprise application inte-gration and to link back to the trends is presentedby He and Xu [69]. Further this work examinesthe architectures and technologies for integratingdistributed enterprise applications, illustrates theirstrengths and weaknesses, and identifies researchtrends and opportunities for horizontal and verti-cal integration. Though no solution is proposed,the discovered trends are strengthened, for exam-ple, SOA, personal, mobile, and IoT. The survey

10

Table 1: Solutions for trends and non-functional aspects (parentheses mean partial solution)Trends Patterns [3] Formalization [5, 66] Modeling [46, 47, 66]Service-oriented Architecture [10, 11, 12, 13, 14, 15, 16, 18, 32,

37, 38], security [30, 31][16], adapters [21, 22, 35, 36, 67],control flow [33], interact. [34]

[17]

Internet of ThingsEvent-driven Architecture [42, 59]Cloud computing [44, 45], (migration [43])B2B/ Business Network (by example [46, 47])Social/ Personal ComputingMobile Computing SOA device patterns [25]Big DataHybrid Computing (migration [43, 48])API Management (for SOA [15])Mashups [26, 27], SOA migration [29]

NFA with evidenceAsynch [3] EIP [3], strategies [56] [57, 58]Security [15, 31, 45, 50, 68, 69] (for SOA [30, 31])Media [6]Synch / Streaming [5]Conversations [5], [6] [55], (for SOA [37]) (for SOA [19, 34])Error Handling [5, 45] (EIP [3, 70])Monitoring [45, 61, 62] ([3])

also addresses NFA, e. g., security, which are col-lected and serve as input for Tab. 1. Another sur-vey by Panetto et al. discusses trends and NFA inenterprise integration [66]. Moreover, modeling andformalization (formal methods such as verification)are proposed as challenges, but no concrete solutionprovided.

2.3. Synthesis and Discussion of Non-functionalAspects

The second aspect of our analysis of trends aretopics that were named by Gartner [6] and Zimmer-mann et al. [5] as relevant or that were identifiedduring the literature review. However, these top-ics have a more cross-cutting quality (i. e., relevantfor several trends). We call them non-functional as-pects or requirements (NFA), which we appended toTab. 1 together with the references that supportedthem as challenges (as evidence). They are set intocontext to important aspects, when working withintegration scenarios, namely patterns, formaliza-tion and modeling. The focus on patterns comesfrom the EIP [3] and supported by many related do-mains, that capture knowledge and best practicesin form of patterns (e. g., SOA, Cloud Computing).Panetto et al. [66] bring up the formalization (sup-ported by [5]) and modeling (supported by [46, 47])as additional relevant topics. We now set these top-ics into context with the references from the litera-ture analysis in Tab. 1.For the EIP, we added asynchronous message

processing as Asynch to cover the solutions in thisspace, e. g., by [3, 56]. For the NFA, solutions inthe area of formalizations are proposed by [57, 58]

for the validation of pattern composition and busi-ness processes. Another NFA is Security, which wasseen as challenge at least by Gartner [6] and in theliterature by [31, 50, 68] (in general), by [69] (per-formance concerns, real-time integration), and by[45] (e. g., safe integration, indications that contentencryption, key management and more is missing).Autili et al. [15] mention the need for security in-tegration patterns. The solutions for patterns arelimited to SOA with patterns like Secure ServiceConsumption or Security Handler Information Ex-change [30, 31].

According to Gartner, multimedia format han-dling and processing can be seen as a non-functionalrequirement [6]. This includes image, video andtext image formats, which are increasingly pro-duced through mobile devices and, e. g., interactedon social media, becoming of increasing interest for(business) applications.

In the context of the big data challenges of in-tegration systems (from Gartner; e. g., volume, ve-locity, stability), (synchronous) streaming protocolsare seen as one possible solution. The authors of [5]mention that patterns as well protocols are cur-rently missing in EAI.

With more and more communication partnersthat result from the trends in Sect. 1.1, (stateful)conversational protocols might be required, accord-ing to [5] and also Gartner (e. g., device meshes).First ideas have been sketched by [55] with an initialcollection of conversation patterns, which should beextended [5]. For SOA web service conversationpolicies [19] and interaction patterns [37] solutionswere provided. Formalizations have been proposed

11

Table 2: System review - horizontal searchCategory hits selected Selection criteria Selected SystemsCommercial 12 7 Gartner and Forrester IPaaS

QuadrantsDell Boomi [72], IBM Cast Iron [73], Informatica[74], Jitterbit [75], MS BizTalk [76], SAP CloudIntegration [77], Oracle [78]

Startup 20 2 cloud/data integration, B2B,API, #followers

Tray.io [79], Zapier [80]

Open Source 13 2 application integration, data in-gestion

Apache Flume [81], Apache Nifi [82]

Wikipedia 34 1 enterprise application integra-tion; non-duplicates

Apache Camel [83]

Added Systems n/a 3 expert knowledge Cloudpipes [84] (startup), Tibco [85], WebMeth-ods [86] (commercial)

Removed Systems - -

Overall 74 15

in [34] for the SOA domain with focus on the con-trollability of a process. The proposed solutions forSOA might be transfered to integration processesas starting point for more general conversation pat-terns.To handle erroneous situations during message

processing, escalate them and make systems morefault-tolerant, error handling is seen as a major as-pect [5, 45]. Hohpe et al. [3, 70] do only coverDead Letter Channel as solution and sketch someideas about the topic. Overall, in the literature, thetopic is neither addressed from a pattern, formaliza-tion, nor modeling perspective. While [5] mentionsmissing patterns and formalization, Merkel et al.[45] lists Balancing and Distribution, as well as [69]mentions Fault-tolerance and Message Schedulingas missing aspects. Similarly, the insight into thecurrent state of a↵airs, called monitoring, for ser-vices and cross-cloud are seen as important topicsin [45, 61, 62].The monitoring of integration processes as well

as cross platform monitoring were only mentioned,however, no solution was provided. The ControlBus, a Wire Tap and the Message History patternsin Hohpe et al. [3] denote partial solutions, whichcan be used to build a monitoring solution on inte-gration process level.

3. System Review

This section reports on the results of a systemreview to answer hypotheses H2 the EIP of the2004 book are all widely used in praxis, and H3 cur-rent system implementations do support more pat-terns as set out in Fig. 3. The system review isbased on the guidelines described in [9] for a hori-zontal search including “well-established” commer-cial application integration systems, more experi-

mental systems from startups, open source systemsand public knowledge in form of a Wikipedia search.The selection of systems was conducted on 2016-10-04, and the results of the horizontal search aresummarized in Tab. 2. The NFA are used to focusthe search in those systems.

First, seven commercial systems were collectedby taking the systems listed in both, the Gart-ner (Leaders, Visionaries, Challengers) [87] and theForrester (Application Integration) IPaaS list [88]– out of 12 systems, leading to the following sys-tems: Dell Boomi [72], IBM Cast Iron [73], Infor-matica [74], Jitterbit Harmony Cloud Integration[75], Microsoft BizTalk [76], SAP Cloud Integra-tion [77], and Oracle Cloud Integration [78]. Wescratched MuleSoft due to its similarity to ApacheCamel [83], which we selected as expert additionfrom Wikipedia (discussed later).

In addition, two startup systems from the top 20overall systems were selected due to their numberof followers on angel.co

1, namely Tray.io [79] andZapier [80]. While the former is striving to buildan “Integration Marketplace” for enterprise appli-cations, Zapier is a cloud integration startup.

Out of 13 open source systems of the GithubHadoop Ecosystem2, we selected Apache Flume [81]and Nifi [82] as data ingestion systems accordingto the selection criteria (cf Tab. 2). We scratchedthe application integration systems Talend (alsolisted as commercial system), Spring Integrationand MuleESB for their similarity to Apache Camelas well as Apache Beam, Apache Sqoop and SpringXD for their similarity to Apache Flume.

1Angel.co, visited 02/2017: https://angel.co/

data-integration2Hadoop Ecosystem on Github, visited 02/2017: https:

//hadoopecosystemtable.github.io/

12

The open source integration system ApacheCamel [83] does not appear in the open source list,however, it was the only non-duplicate from theother lists that has to be selected, since it imple-ments the existing EIP from [70] and is a role modelfor many systems like Spring Integration, or RedHat’s FuseESB.The software systems of Tibco [85] and Software

AG [86] are wide-spread and influencial integrationsystems for on-premise with a cloud integration of-fering and are listed among the top for wide integra-tion and deep integration for traditional on-premiseby Forrester3. Hence we add them as expert se-lected additions. We add Cloudpipes [84] from thestartup list as cloud integration system.That leaves us in total with 15 systems with

a good mix of well-established commercial andstartup products, as well as community projects.Since the main focus lies on commercial systemsthat are known to be less well accessible for asystematic analysis of their features, we focus onthe publicly available material (i. e., without regis-tration or login) and try to get more informationby possibly underlying open source systems, wherepossible.

3.1. Processing of selected systems

3.1.1. EIP Solutions used in System Implementa-tions

We start our system review with an analysis of allselected systems with respect to their implementa-tion of EIP solutions. The EIP describe six patterncategories, namely, Messaging Channels, MessageConstruction, Message Routing, Message Transfor-mation, Messaging Endpoints and System Manage-ment. We focused the analysis on the two patterncategories of message routing and transformation,since they represent the core aspects of integrationsystems. Furthermore we left out composed pat-terns (e. g., composed message processor, scatter-gather), when their single parts were already inthe selection. Table 3 (from Boomi to Oracle) andTab. 4 (from Flume to Webmethods) depict the so-lutions found in the system implementations thatcould be associated to the routing and transforma-tion patterns.The Apache Camel system seems to be specifi-

cally designed around the EIP, thus supports nearlyall EIP and sticks to the original EIP naming for the

3The Forrester Wave: Hybrid2Integration, Q1 2014

respective solutions, which makes it a benchmarkfor the others. Most notable deviations are theEnvelope Wrapper (i. e., wrap application data in-side an envelope, compliant with the messaging in-frastructure) and Message Translator patterns (i. e.,translate one data format into another one; not intransformation patterns). None of them is directlyrepresented in Camel, however, can be implementedusing UDFs (i. e., user-defined functions like CamelProcessor) or scripting (e. g., Camel Script), there-fore marked as partially covered by parentheses.

The most common routing pattern solutions arethe Content-based Router, the Splitter and the Ag-gregator. Since the Message Filter is a special caseof the content-based router and filter can be used toconstruct the latter, not all systems provide imple-mentations for both of them. The splitter is some-times implemented according to the description inthe EIP, however, some vendors decomposed it toits iterative core functionality (e. g., For Each inIBM, Oracle, Cloudpipes). The aggregator showsmany partial solutions that require user-definedfunctions (e. g., Informatica, Oracle, Tray.io), whileonly few provide its EIP functionality (e. g., Aggre-gator in BizTalk, SAP Cloud Integration, Tibco orContentMerge in Apache Nifi).

The transformation patterns seem to play a ma-jor role in the analyzed systems, since most of themare broadly supported. However, there seems to bea tendency to provide UDF capabilities and leavethe burden to the user to deal with the semantics.

Finally, the dynamic routing patterns (e. g., Dy-namic Router), those patterns that contain the re-cipient in their content (e. g., Recipient List, Rout-ing Slip), and the Message Resequencer, e. g., usedfor the exactly-once-in-order service quality [89],were sparsely implemented. This leaves the ques-tion on their relevance or other components thattake over their function.

Summary. While some of the EIP like Content-based Routing or Message Filter, Splitter and Con-tent Enricher can be found in most of the systems,others are rarely implemented (e. g., Resequencer,Routing Slip). The analysis of these patterns andtheir relevance are left for future work, and thus notanalyzed further.

3.1.2. New Solutions not covered by System Imple-mentations

We now analyzed the collected systems with re-spect to their functionalities according to the har-

13

Table 3: Original EIP used in systems; supportedp, partial (

p), unknown/not supported �

Pattern Boomi IBM Informatica Jitterbit BizTalk SAP OracleContent-based Router

p p- -

p p p

Message Filter -p

- -p

- -Dynamic Router - - - -

p- -

Recipient List - - - - - - -Splitter

p p(p)

p p p p

Resequencer - - - - - -p

Routing Slip - - - - - - -Aggregator - - (

p) -

p p(p)

Envelope Wrapper (p) (

p) (

p) (

p) - - -

Content Enricher (p) - - (

p) (

p)

p-

Content Filter (p) - - (

p) (

p)

p-

Claim Check (p) - - (

p) - (

p) -

Normalizer (p) - (

p)

p(p) (

p) -

Message Translatorp

- (p)

p p p-

Table 4: Original EIP used in systems; supportedp, partial (

p), unknown/not supported �

Pattern Flume Nifi Camel Tray.io Zapier Cloudpipes Tibco WebmethodsContent-based Router (

p)

p p p-

p p p

Message Filterp

-p

-p p

- -Dynamic Router (

p) -

p- - - - -

Recipient List - -p

- - - - -Splitter

p p p-

p p p-

Resequencer - -p

- - - - -Routing Slip - -

p- - - - -

Aggregator (p)

p p(p) - -

p-

Envelope Wrapper - - (p) - - - - -

Content Enricher (p)

p p p(p) (

p)

p p

Content Filter (p)

p p(p) (

p) (

p)

p p

Claim Check - -p

- - - (p) -

Normalizer (p) -

p(p) (

p) (

p)

p p

Message Translator (p)

p(p)

p(p) (

p)

p p

vested NFA from Sect. 2.3), namely security, media,streaming or more abstract “processing”, conversa-tions, error handling, and monitoring. Comparingthe NFA with the collected system functionalities,while neglecting functionalities covered by the EIP,gives an answer to the question which topics arerequired and used in addition. Hereby, the systemfunctionalities represent an implemented solutionas part of an actual integration system.

Figure 5 depicts found solutions not covered bythe EIP by NFA and system vendor. During theanalysis new NFA were identified – not mentionedby Gartner, the EIP authors, or the literature –that seem to play a role in practical terms: statefulintegration processes using storage, (pattern) com-position (mentioned in Zimmermann et al. [5]), andsystem operations. These three new NFA were in-cluded into the analysis of the other systems as well.All non-related topics are collected as miscellaneous(Misc).

Notably, all identified NFA are at least partiallycovered by system implementations, indicating thatsolutions in form of conceptual definitions are re-quired (e. g., as patterns). According to Mule-soft [90], the major challenges in cloud integration

systems are security and management. The man-agement includes error handling and monitoring,which allow to control the behaviour of the integra-tion scenarios.

The classic application integration addresses thevariety problem for textual message formats [2].With the availability of integration systems for “ev-erybody” (e. g., in form of a cloud integration sys-tem) non-textual formats gain importance.

The trade-o↵ between stateful and stateless mes-sage processing is represented by storage capabil-ities in integration systems, for which nearly allvendors propose a solution and conversations. Thestateful approaches could be represented by conver-sational protocols, which allow to move the statefrom the integration systems to the communicationpartners (idea sketched in [55]). Most of the servicequalities (e. g., at-least-once, exactly-once process-ing) [3, 89] require stateful integration processes.Consequently, this would require changes in the ap-plications. Current systems provide only rudimen-tary support, if at all.

Finally, a broad variety of miscellaneous topicswas collected, e. g., sentiment analysis, natural lan-guage translators, but also more general functions

14

Figure 5: Solutions for NFA not covered by the EIP by system vendor.

like sort, loops, as well as explicit format handling,i. e., marshalling and type conversion.

Summary. Notably, security and error handling(and monitoring) capabilities are predominantlyfound. They address the challenges of security andmanagement. Furthermore, solutions for the in-creasing variety of message formats (cf. media) aswell as the volume and velocity handling can befound in the systems are part of new processingtypes. The storage of data and message seman-tics like quality of service are relevant for integra-tion scenarios. This leads to the trade-o↵ betweenstateful vs. stateless integration processes, whichbriefly address in Sect. 5. The (stateful) conversa-tions, which could be part of a solution, are cur-rently under-represented.

3.2. System Summaries along NFA3.2.1. SecurityThe aspect of confidentiality or message privacy

is solved on transport, message and storage lev-els. The transport level channel encryption canmostly be specified in the inbound and outboundadapters in form of the transport protocol (e. g.,HTTPS, SFTP) and guarantees that the messagecannot be read during transmission (e. g., Jitter-bit’s Transmission Protection). Once, the message

is received by the inbound adapter and handed tothe subsequent operation in the integration pro-cess, message privacy can be applied or reversed.Therefore many vendors provide explicit messageencryptors and decryptors (e. g., PGP Encrypt andDecrypt from Dell Boomi, AES ENCRYPT fromInformatica or Encrypt / Decrypt in Apache Nifi),or encrypting adapters (e. g., FileProcessorConnec-tor in Informatica, FileChannel in Apache Flume,WSSProvider in Tibco). The encrypted storage ofmessages helps to protect the message’s privacy inthe store, e. g., can be configured in SAP’s DB-Storage and Persist operations. The configura-tion of the message privacy solutions mostly in-clude encryption algorithms, key lengths and cer-tificates. Similarly, the integrity and authenticityof a message can be ensured on the di↵erent lev-els. Most of the vendors provide configurations forsafe and authenticated transport (e. g., using userand password, certificate or token-based authenti-cation). The transport is considered safe if changesof the message can be recognized by the receiverand the authenticity guarantees that the sender isthe expected one. For instance, most of social me-dia endpoints like Twitter and Facebook use token-based OAuth authentication. In addition, manyvendors provide explicit message signers and signa-

15

ture verifiers (e. g., Digest/Hash function in IBM,Signer and Verifier in SAP Cloud Integration) aswell as safe message storage is provided, e. g., byJitterbit or SAP Cloud Integration. For the stor-age, the authenticity seems to be implied, since thecloud platform message or data store is used. Theavailability of integration scenarios is not only a sta-bility, but also a security concern. Therefore somevendors like IBM, SAP Cloud Integration provideimplicit countermeasures, e. g., redundant messagestores with high availability and disaster recovery,as well as Apache Flume with explicit Morphli-neSolrSinks and Kafka Channel configurations. Fi-nally, changes to the message are tracked for audit-ing purposes. This is made explicit as Audit Trailsin Jitterbit and Oracle or Service Auditing in Web-Methods.

3.2.2. MediaThe literature review in Tab. 1 shows that there

are no solutions for multimedia processing in appli-cation integration or related domains (e. g., SOA,EDA). The system analysis does only provide few,superficial solutions. For instance, textual repre-sentation of binary content is explicitly configurablein most of the systems (e. g., Base64 Encode / De-code in Dell Boomi and IBM, Encoder / Decoderin SAP Cloud Integration). These encodings play amajor role when communicating with remote appli-cations, but also when calling services (e. g., user-defined operations) using textual message proto-cols. In addition, most of the vendors allow user-defined operations in form of scripting capabilities(e. g., Script, Processor in Apache Camel, Expres-sions in Informatica). With that, more complexoperations can be performed like the compressionof – usually bigger – multimedia messages. De-spite that, pre-defined compression operators canbe found in, e. g., Dell Boomi, Jitterbit, ApacheNifi, which allow to configure the compression type(e. g., zip). The explicit support of scripting seemsto be a general trend, when representing transfor-mation patterns (cf. Sect. 3.1.1). This could eithermean that the implementations are too diverse toformulate a general solution or indicate that thetopic was not considered yet. The support of ex-plicit image processing operations seems to be lim-ited to Nifi’s ResizeImage and ExtractImageMeta-data functions as well as IBM’s Read MIME activ-ity. The only real multimedia operation is the im-age resizing, since the metadata simply provide aformat specific capture of the defined image’s meta

tags.

3.2.3. ProcessingWhile the literature review does not show so-

lutions for message processing, especially not for“data-aware” or Big Data processing, the systemsimplement solutions. The canonical solution forprocessing larger amounts of data is to scale-out tomultiple processing units, constituting parallel sub-processes. The parallel processing of one message insubprocesses using a broadcast can be done, e. g., inBizTalk with Create concurrent flows, SAP CloudIntegration Gateways, or Apache Camel Multicast.Furthermore, the explicit configuration of parallelprocessing within an integration process (i. e., notprocess parallelization) is supported by, e. g., DellBoomi using the Flow Control properties, JitterbitParallel Processing, Tibco Non-inline subprocessesand Critical Section, BizTalk Scope batch property.Alternatively, a more data-centric approach, how-ever, impacting the latency of the process, is micro-batching [91]. Vendors like Dell Boomi and Jitter-bit also support batch processing of messages us-ing the Flow Control properties or Chunking con-figurations. The processing of message streams al-lows the system to handle larger amounts of datathan the integration system resources would allow.This more connection oriented approach was iden-tified by Zimmermann et al. [5] as missing pat-tern category in the context of synchronous messageprocessing. An explicit streaming support is pro-vided, e. g., by Jitterbit Streaming Transformationand Apache Camel. However, not all integrationoperations or adapters are (conceptually) capableof streaming.

3.2.4. ConversationsGartner [6] as well as Zimmermann et al. [5] men-

tion the importance of conversations for messaging.These conversations are similar, however, stand incontrast to the choreography (e. g., [92, 15]) and in-teraction patterns for services [37] in SOA becausethey denote more complex tasks than sending andreceiving data or messages. They target complex(stateful) conversations as partially covered in [55].Some of the systems allow a timed redelivery ofmessages in a non-error case (e. g., SAP Cloud In-tegration, Apache Camel). This feature is similar tothe Contingent Requests pattern in [37]. For a con-versation, an acknowledgement mechanism wouldbe required similar to [55]. One technique of re-ducing the number of requests to an endpoint is

16

request caching. In Tibco, request caching can beconfigured by specifying time slices and operationsin the Caching Stage. The SAP Cloud Integrationsystem allows to map synchronous to asynchronouscommunications and vice versa. This becomes nec-essary when the endpoints’ message exchange mech-anisms do not fit.

3.2.5. Error Handling

Error handling is a crucial aspect of integrationscenarios [5] for the control and fault toleranceaspects. In the literature we found solution at-tempts [3, 70] like the Dead Letter Channel pat-tern for the collection of failing messages, while thesystems implement various, more sophisticated so-lutions. The fundamental topic for dealing witherrors in integration scenarios is the handling of ex-ceptions. Therefore, most of the systems providea “catch-all” capability (e. g., Catch All in IBM),which sometimes even come with an exception sub-process for more advanced handling (e. g., Excep-tion Subprocess in SAP Cloud Integration). In ad-dition, vendors like Dell Boomi, IBM, SAP CloudIntegration and Tibco provide more fine-granularscoping of exception handlers, e. g., down to thesingle operation. More advanced topics include es-calation, fault-tolerance and eventually preventiontechniques. Most notably, the systems support es-calation mechanism like (partial) abortion of com-plex processes (e. g., incl. parallel processing) andraising indicators for alerting, as well as messageredelivery on exception for tolerance, and messagevalidation, load balancing (cf. [56]) and flow con-trol to prevent errors. More recent work [93, 94] –not found in the literature review – covers all of thefound system solutions as patterns and shows theircomposition. Furthermore, it introduces the con-cept of compensations (e. g., for undo operations),which was not found within the reviewed systems.

3.2.6. Monitoring

The monitoring of integration scenarios gainsimportance especially within integration platformshosted by a third party and across those platformsin cloud and mobile computing. The major moni-toring aspects found in the systems can be distin-guished into UI components that show importantaspects of the system, called monitors, and a ratherevent-based registration on instance level. For ex-ample, Dell Boomi supports message change eventsby Find Changes, which can be extended to Field

Tracking. Oracle supports the latter with Busi-ness Identifiers. That means, user-defined eventson technical and business level can be tracked viaconditional events. Examples for monitors can befound in most of the systems across all parts of anintegration scenario (i. e., from adapter or channel,over component, down to message monitors). Themonitors can be fed by built-in and user-definedmessage interceptors (e. g., in Apache Flume andCamel), which allow scenario specific monitoring.When integrating hybrid applications, most sys-tems provide central, cloud monitors instead of lo-cal ones.

3.2.7. Storage

An integration system requires persistent storesand queues to be operable, e. g., for system manage-ment and monitoring. In addition, message deliverysemantics (e. g., reliable messaging like “exactly-once-in-order”) [89], secure messaging, and legalaspects (e. g., “Which messages were received andprocessed?”) must be ensured. In the literatureonly simple messaging related storage are men-tioned like the Message Store [3], for storing mes-sages during processing, and the Claim Check [3] tostore (parts of) the message during processing andre-claim them later. Consequently, several systemvendors identified the need for additional storagecapabilities, summarized to data stores and theiraccess (e. g., DB Update in Jitterbit, DBStoragein SAP Cloud Integration), as well as memoizationand caching during one instance of a scenario orbetween them (e. g., Add to Cache in Dell Boomi,Shared Variables in Tibco, Global Variables in Jit-terbit). For secure messaging, security related stor-age like the Key Store (e. g., in Apache Flume,Camel and SAP Cloud Integration), for storing cer-tificates and secure key material, and the SecureStore (e. g., in SAP Cloud Integration), for storingsecure tokens, users, and passwords, can be found.

3.2.8. Composition

In Zimmermann et al. [5] the composition of EIPis mentioned as one of the missing pieces. Manysystem vendors, e. g., Dell Boomi, IBM, BizTalk,SAP Cloud Integration, allow subprocess modelingas well as delegation from the main integration pro-cess. One important solution are integration pro-cess templates, which are configurable re-use pro-cesses. Many of the vendors support them, how-ever, under di↵erent names, e. g., Template inte-

17

gration process in IBM, Snapshot of Jitterpack inJitterbit, Blueprint in Cloudpipes.

3.2.9. Miscellaneous

The most notable, specific features are explicit orimplicit loops, keyword search and replace as well ascontent sort and format handling. The implicit loopconfigurations include While Loop activity, e. g., inIBM, Looping in BizTalk, and the Loop Collectionconnector in Tray.io. Explicit loops are possiblein most of the systems by back-references in theprocess. Dedicated search and replace functional-ity is provided, e. g., in Dell Boomi, Jitterbit, andApache Nifi. While most type converters are im-plicit in most systems, marshalling support is madeexcplicit, e. g., in Jitterbit, SAP Cloud Integration,and Apache Nifi. More “exotic” functions are textsentiment analysis in Cloudpipes, an Archiving ac-tivity in IBM, and a Yandex language translator inApache Nifi.

4. Design of Pattern Catalog

This section summarizes the findings of the lit-erature and system reviews in form of a patterncatalog, capturing and describing the found ad-hocsolutions and functionalities as new patterns. Thesepatterns can be seen as the starting point of a con-tinuation of the EIP, but also recent trends to ex-press domain knowledge as patterns [95]. In doingso, hypothesis H3 “Some trends are handled inan (yet) immature and ad-hoc fashion” is targeted.The design goals for the pattern catalog are:

1. Comprehensiveness, i. e., coverage of systemimplementations that are not in the literature

2. Novelty, i. e., literature coverage of the missingor only partial pattern definitions for NFA

The proposed pattern catalog is summarized inTabs. 5 and 6 categorizing the patterns by NFA asCategory. The patterns in column Pattern Nameare further grouped by sub-categories as Scope. Dueto lack of space, the descriptions of all patterns con-tained in the catalog are provided as supplementarymaterial [44] and two of them are introduced in de-tail in Sect. 5. While in this section we focus onpatterns, the supplementary material illustrates themodeling of the new patterns for two integrationscenarios from the quantitative analysis in Sect. 6.

4.1. Goal 1 (Comprehensiveness): System Imple-mentation Coverage

In detail, comprehensiveness is evaluated by com-paring the coverage of patterns with the NFA thatare not or only partly covered by patterns in the lit-erature, represented by the combination of columnsCategory and Scope. The coverage of system imple-mentations reflected by column System Exampleswas chosen in order to provide pattern definitionsreferring to examples (but not all) of the corre-sponding system implementations (if at least onevendor supported them). Subsequently, we referonly to the categories that have a special relevancefor the comprehensiveness of our analysis.

Security. Take, for example, NFA Security in com-bination with scope Confentiality (cf. Tab. 5), forwhich no comprehensive pattern is provided in theliterature on the one side, but system implementa-tions by, for example, Dell Boomi [72], Informatica[74], or Apache Nifi [82] exist. Addressing designgoals 1) and 2) led to the set of suggested patternsMessage Encryptor, Message Decryptor and En-crypting Endpoint. Message Encryptor, for exam-ple, covers the system implementations PGP En-crypt / Decrypt, AES ENCRYPT, and Encrypt /Decrypt.

Media. Besides formatting patterns for structuredmessage content, the media specific patterns for un-structured content are under-represented in currentsystem implementations, since there is only one pat-tern with direct relation to multimedia processing(e. g., Image Resizer [82]). Although there are func-tionalities for the work on the structured multime-dia metadata (e. g., Metadata Extractor), furtherresearch should target the unstructured multime-dia data and processing (e. g., in the context of syn-chronous, streaming protocols).

Summary – Comprehensiveness. With the patterncatalog we address 94.74% of the NFA scopes orsubcategories (i. e., all but 1 out of 19) derived fromsystem implementations. A synch / streaming pat-tern elicitation – as also mentioned by [5] – wasnot conducted in the context of this work, since thesystem review did not lead to pattern changes ornew patterns, but only adds an additional process-ing style. However, we consider this an interestingtopic especially in the context of the Media and BigData trends, and propose a separate study for thiscurrent gap.

18

Table 5: New integration patterns for NFA in the context of system implementations from security to processing withoutpattern solutions already covered by literature

Category Scope Pattern Name System ExamplesSecurity Confidentiality,

PrivacyMessage Encryptor,Message Decryptor,Encrypted Message

PGP Encrypt / Decrypt [72], AES ENCRYPT[74], Encrypt / Decrypt [82]

Encrypting Endpoint /Adapter

FileProcessorConnector [74], FileChannel [81],WSSProvider [85]

Authenticity,Identity

Message Signer, Signa-ture Verifier, Signed /Verified Message

Digest/Hash [73], Signer, Verifier [77]

Storage Encrypted / EncryptingStore

DBStorage, Persist [77]

Safe Store Most of the vendorsRedundant Store MorphlineSolrSinks [81], implicit [73, 77]

Transmission Encrypted Channel Transmission Protection [75]Safe, AuthenticatedChannel

Password, certificate, token-based (Most of thevendors)

Audit Log Audit Trails [75, 78], Service Auditing [86]Media Format Type Converter Type Converter [83, 79, 80]

Encoder, Decoder Base64 Encode / Decode [72, 73], Encoder / De-coder [77]

Marshaller, Unmarshaller “Data Format” [83], “ConvertJSONToSQL” [82],“JsonXMLConverter” [77]

Compress Content, De-compress Content

implicit [72, 75], Compress Content [82]

Custom Script Script, Processor [83], Expression [74]Metadata Extractor Read MIME activity [73], ExtractImageMeta-

data, ExtractMediaMetadata [82]Unstructured Image Resizer Image Resizer [82]

Processing Synch / Stream-ing

- Streaming transformations [75], partially [77],streaming [83]

Parallel Parallel Multi-cast, SequentialMulticast

[76, 86, 77]

Join Router implicit [83], join [77]Other Delegate Process Call [77], Direct-VM [83]

Loop Loop Activity [73], Looping [76]Find and Replace Search/Replace [72], Control Character Replacer

[75], Scan Content [82]Content Sort Sort [83]

4.2. Goal 2 (Novelty): Literature Coverage

Now, we set the pattern findings from the litera-ture review for the NFA – summarized in Tab. 1 –into context with the new pattern proposals derivedfrom the system analysis. We exclude the solu-tions from the original EIP [3], and Media, Synch /Streaming and Composition (not in NFA, however,came up during system analysis and mentioned in[5]), for which no solutions were found in the lit-erature. In addition, we excluded Error Handling,since it is comprehensively covered from a patternperspective and compared to system implementa-tions in prior work [93, 94] (not found in the liter-ature review).

Security. Although some security patterns wereproposed in the SOA domain [30, 31], they onlyprovide partial solutions with respect to the NFAand no solution in the context of the system review.

Conversations, Processing. In terms of conversa-tion patterns, the system implementations onlyshowed basic support (cf. Tab. 6), however, some

more can be found in the literature, showing thatthis is an area for integration systems to add morefeatures. Although, Barros et al. [37] mostly reiter-ate the original EIP, there are few patterns that arenew in the context of the system implementations.In the category of multi-lateral communication, theOne-from-many pattern [37] is a special case of ourmore general Join Router that we found in the sys-tem implementations (e. g., Apache Camel, SAPCloud Integration). The One-to-many send pattern[37] is similar to the (parallel) Multicast – found inthe systems (e. g., Apache Camel, SAP Cloud Inte-gration), however, some systems have variants thatwe captured as Sequential Multicast, which routesmessages of the same type to multiple receivers insequence to guarantee the successful delivery to allrecipients.

Summary – Novelty. From the functionality re-quired by system implementations, 59 distinct, newpatterns are derived that were not found in theanalyzed literature. However, for 5 out of 7 NFA(compare to Tab. 1), the literature indicates missing

19

Table 6: New integration patterns for NFA in the context of system implementations from conversations to composition withoutpattern solutions already covered by literature

Category Scope Pattern Name System ExamplesConversations Endpoint Commutative Receiver -

Timed Redelivery untilAcknowledge

-

Fault tolerant Timeout synchronous re-quest

-

Failover Request Handler Failover Client [81]Resources Request Collapsing -

Request Partitioning -Monitoring Processing Message Cancellation [76, 82]

Usage Statistics [77, 78]ImmediateInsights

Raise Indicator [72, 75, 76, 77]

Detect [76, 82]Message Interceptor [81, 83], implicit [77]

Monitors Component Monitor [77, 84]Channel Monitor [77, 78, 80, 84, 85]Message Monitor [77, 78, 79]Resource Monitor [77, 85]Circuit Breaker [83]Hybrid Monitor [77]

Storage Data, Variable Data Store [73, 75, 77]Store Accessor DB Update [75], DBStorage [77]Transient Store Add to Cache [72], Shared Variables [85], Global

Variables [75]Security Key Store, Trust Store,

Secure Store[81, 83, 77]

Composition Integration Subprocess [72, 73, 76, 77]Integration Pro-cess Template

Template Integration Process [73], Snapshot [75],Blueprint [84]

patterns as research challenge (cf. Sect. 2.3), thussupporting the extension of the integration patterncatalog for security ([15, 31, 45, 50, 68, 69]), multi-media ([6]), synch / streaming ([5]), conversations([5], [6]), monitoring ([45, 61, 62]), and pattern com-position (from system review Sect. 3, [5]). In addi-tion, the system review raises a demand for storagepatterns that was not mentioned in the literature.

4.3. Solutions for Future Challenges

We propose several new conversation patterns,of which none was found in the system implemen-tations. The proposed endpoint-specific patternsCommutative Receiver and Timed Redelivery Un-til Acknowledgement (similar to the Contingent re-quests pattern in [37, 55]) – that together denotea solution for a critical trade-o↵ for scalability in-spired by [95] – are discussed in detail in Sect. 5.The other patterns are further discussed in the sup-plementary material [44], and target the additionalconversation scopes: Fault tolerance and Resources.The multi-tenant processing, conversation patterns(e. g., Cross Scenario and Cross Tenant) patternsthat are mostly required in hybrid and cloud com-puting setups, are already covered by prior work[89], thus not shown.Toward a more stable system, the Timeout Syn-

chronous Request and Failover Request Handler

patterns are improving the fault-tolerance of themessaging. Especially in the Big Data context,the resources of an integration scenario or platformbecome crucial for their stability. Therefore, theRequest Collapsing pattern reduces the number ofrequests within a conversation. In addition, theRequest Caching reduces the amount of duplicaterequests to the same endpoint, while Request Par-titioning optimizes requests to endpoints and con-fines errors to one request aspect. Together withother patterns from the literature review and theproposed patterns in this work, we see a clear ev-idence for further research required. Since none ofthe patterns was found during the system reviewthis indicates potential for current integration sys-tem and application endpoint implementations.

The monitoring of integration scenarios reachesfrom real-time, scenario-specific processing to near-real time monitors. One further challenge – alsoidentified by [45] and partially covered by the sys-tems with mixed on-premise and cloud integration– is the monitoring across di↵erent platforms (e. g.,cross-cloud, across on-premise and cloud).

5. Example Integration Pattern Realization

As example from the catalog, we selected pat-terns related to the non-trivial trade-o↵ between

20

stateful and stateless integration processes (inspiredby cloud computing challenges [95]). Especiallythe system review shows that all vendors provideextensive storage capabilities – beyond the EIP,leading to stateful processes. However, the under-represented conversation patterns could o↵er analternative, thus allowing for stateless processes.While stateless processes have scalability benefits,they come with some drawbacks that have to beconsidered. We selected this trade-o↵ due to itsrelevance in the context of Big Data, its relevancefor Cloud Computing, and because it addresses onewell-represented (i. e., storage) and the currentlyunder-represented, but important area of (stateful)conversations. Subsequently, we describe the trade-o↵ as problem description, discuss a suitable pat-tern format and conclude with two pattern descrip-tions and their realization.

5.1. Problem Description: Stateful vs. Stateless In-tegration Processes

Operating an integration system requires persis-tent stores and queues, e. g., monitoring, key orsecure store to achive security, or auditing for le-gal reasons. In addition, transactional messageprocessing (e. g., aggregator pattern) as well asmessage delivery semantics (e. g., reliable messag-ing like “exactly-once-in-order”) [89] require somepersistent state. While the system operabilityavoids influencing the message processing by notusing shared states between integration scenario in-stances, the transactional processing and messagedelivery semantics of the stateful message proces-sors (i. e., patterns) usually require shared states.For example, when a stateful aggregator – as partof a scenario instance – processes a sequence of mes-sages, a second scenario instance could be used todistribute the load. However, in the absence of“process stickiness” (i. e., messages of one sequenceare only sent to one instance), the stateful aggrega-tor in the second instance has to be able to completea sequence the other instance started, thus sharedstate. Hence, the shared states imply complex statehandling across integration processes in computeclusters or cloud environments, and this may havea negative impact on their scalability. Alternatively– following the ideas on (stateful) conversation pat-terns from Hohpe [55] – some of the discussed mes-saging related storage and message delivery seman-tics could be moved to “smart” message endpoints(i. e., applications), which already have a persistent

state, thus making the integration processes state-less.

For example, Fig. 6 illustrates the trade-o↵ be-tween Exactly-once In Order (EOIO) delivery se-mantics within the integration scenario (i. e., re-quires a stateful Message Store, Resequencer andIdempotent Receiver [3], and transactional MessageRedelivery on Exception [94]) in Fig. 6(a) and as a(stateful) conversational approach in Fig. 6(b). Theintegration processes are represented in BPMN 2.0similar to [46]. An EOIO delivery requires a trans-actional redelivery in case of an exception, a mes-sage ordering step according to a sequence of mes-sages in form of a Resequencer and an IdempotentReceiver, which is able to deduplicate the messages.Figure 6(a) depicts the instance spanning state forthe retry and the resequencing. To avoid statefulintegration process, both capabilities can be movedto the endpoints (cf. Fig. 6(b)). While this will notwork for legacy, packaged applications, it resultsinto an improved scalability within the integrationprocess and moves the resequencing decision to thereceiver. To eventually stop sending, the sender –redelivering the message periodically – requires astop event (i. e., an acknowledgement) from the re-ceiver.

The solution’s trade-o↵ are the several messagesthat are sent by the receiver until an acknowledge-ment is received, while being able to process allmessages in parallel using stateless integration pro-cess instances. In other words, the performance im-provements gained through better scalability andlower latency of the conversational approach – bynot waiting for the failure of a sent message – iscontrasted by the more resources overall requiredin case of many failures.

5.2. Patterns and Pattern Formats

To formalize the new challenges and the result-ing, required capabilities within an integration sys-tem, thus coming to less immature and ad-hoc solu-tions (cf. H3), we propose to express them as pat-terns. Similarly, expert knowledge and best prac-tices were already collected for software design byGamma et al. [96], EIP by Hohpe et al. [3], and re-cently for cloud computing patterns by Fehling etal. [95]. For a suitable pattern representation, wecompare their pattern formats in Tab. 7, and selectcommon categories for our proposal.

From the analysis of several known pattern for-mats in Tab. 7, we selected: name, icon, drivingquestion, context, solution, results, and known uses

21

(a) Stateful EOIO (b) Stateless EOIO

Figure 6: Conversational approach for Exactly Once in Order (EOIO).

Table 7: Common pattern formats: Enterprise Integration Patterns (EIP) [3], Cloud Computing Patterns (CCP) [95], DesignPatterns (DP) [96]

Categories Description EIP CCP DPName pattern identifier

p p p

Icon visual representationp p

-Problem / Driving Question / Motivation di�culty as question

p p p

Intent statement about design issue - -p

Also known as other pattern names - -p

Context / Motivation introduces problem domainp p p

Forces, Appilcability problem constraintsp

-p

Solution how to solve the problemp p

-Sketch, Structure illustrate solution

p-

p

Participants, Collaborations participants, responsibilities - -p

Results / Consequences how to apply the solutionp p p

Next / Related Patterns related patterns, di↵erencesp

-p

Sidebars / Implementation / Code pattern variationsp

-p

Examples / Known Uses real system examplesp p p

to round-o↵ the description. We leave out the sepa-rate categories of forces (i. e., problem constraints)and implementation (i. e., pattern variants), whichwe include into the selected context and known usescategories, respectively. The pattern descriptionsin the supplementary material [44], add a Data As-pects category (not further discussed here), whichgives even more insight into the configuration of thepattern solutions.

5.3. Pattern Examples and Realization

From the problem description we take three ca-pabilities that are required to represent an EOIO,while keeping the integration processes stateless.We summarize the capabilities to the following

two patterns, for which we explain the realization:Commutative Receiver and Timed Redelivery un-til Acknowledge. In addition, we require the QuickAcknowledgement pattern from [55].

Commutative Receiver. The commutative receiveraccounts for two tasks: message deduplication andout-of-order handling. Therefore, the application’sstate is re-used, hence no additional state in theintegration process is required.

How to ensure idempotent, in-ordermessage processing without inter-mediate state in form of persistentintegration scenarios?

22

(Icon: the icon uses the icon notation from [3],combining the in-order sequencing as well as theidempotent storage.)Context: Out-of-order communication withendpoints/applications.Solution: Guarantee that endpoint/applicationhandle arriving out-of-order messages will be storedwithin their sequence and only then processed, ifthe sequence is (partially) complete and in thecorrect order.Result: This solution handles out of ordermessages and applies them in-order within theapplication endpoint.Relations to other patterns: This pattern is anextension of the Idempotent Receiver from [3] withadditional Message Sequence handling.Known uses: not found in literature or systemreview, however, Microsoft advices developers toimplement commutative endpoints in the contextof micro services4.

Timed Redelivery until Acknowledge. The com-mutative receiver moves the message redeliveryon exception from the integration process to thesender application, while conducting an asyn-chronous communication. Hence, no exceptionsare propagated back to the sender, however,the redeliveries are stopped by asynchronouslyreceived Acknowledgements from the receiver (viathe integration system). Until then, the messagesare resent with increasing delay to reduce the loadof duplicate messages.

How to ensure that a message will bereceived without intermediate stor-age, e. g., in form of Redelivery onException [94]?

(Icon: the icon uses the icon notation from [3],combining delayed message send with asynchronousreception of acknowledgments using a transactionalstore.)Context: This pattern is used for asynchronouscommunication with message delivery guaranteesSolution: Instead of relying on intermediate stor-age and retry within the integration system, theapplication sends multiple instances of the samemessage with configurable timings until the actualreceiver endpoint acknowledgements (e. g., Quick

4Designing Services, visited 02/2017: https://msdn.

microsoft.com/en-us/library/ee658114.aspx.

Acknowledgement [55]) reach the sender. Requiresan Idempotent [3] or Commutative Receiver forcertain message delivery semantics [89]Result: Send copies of the same message asyn-chronously until the receiver’s acknowledgementreaches the sender.Relations to other patterns: This pattern is anextension of the Retry pattern in [55], and relatedto the Redelivery on Exception pattern in [94].Known uses: - (not found in literature or systemreview).

Solution Summary. As an extension a Timed Rede-livery until Acknowledge pattern would be requiredthat makes multiple attempts to deliver a message(potentially with exponential back-o↵ delay). Thatmight result to duplicate message instances, sent tothe receiver. Assuming a stateless integration pro-cess, an idempotent receiver [3] is required to detectand handle the duplicates. The sketched conversa-tion works fine for exactly-once processing seman-tics [89]. However, for ensuring in-order messageprocessing (e. g., create sales order, before update),it would not be su�cient. A stateless integrationprocess cannot reliably re-order the incoming mes-sages, delegating this task to the receiver applica-tion. The receiving application has to handle in-coming messages in an associative and commuta-tive way (e. g., handle update, before create). Animplementation of this Commutative Receiver pat-tern can be found in the microservice context (e. g.,service applications). When the receiver got allmessages belonging to one message sequence (i. e.,without duplicates), it sends an Acknowledgementmessage that is asynchronously processed by thesender, which stops redelivering corresponding mes-sages immediately.

6. Quantitative Analysis

In this section we conduct a quantitative anal-ysis of integration scenarios to study the usage oforiginal EIP and the new patterns from the patterncatalog in Sect. 4. We selected the SAP Cloud In-tegration system from the review (cf. Sect. 3), forwhich we found “real-world” examples of all sce-narios from Fig. 2. With over 1, 000 customers andseveral hundred integration scenarios delivered asstandard content SAP Cloud Integration representsa cloud integration system for application and dataintegration. The analysis targets the hypotheses“The original EIP of the 2004 book are all widely

23

used in praxis” and “H4: Solutions not in EIP canbe found in real-world integration scenarios for thetrends”. Therefore, we firstly select several scenar-ios along the identified trends and briefly describethem. Secondly, we evaluate found original EIP andnew solutions.

6.1. Integration Scenarios

The new trends – set into context denoted byedges via the integration system node in Fig. 2 – canbe summarized to integration the scenario domains:

• On-Premise to Cloud: Most organizations pro-ductively run on packaged, on-premise appli-cations. They need to connect these applica-tions with cloud applications for various rea-sons, e. g., extensions for legal reasons or newfunctionality, to connect with business part-ners. This integration domain is called hybridintegration [4].

• Cloud to Cloud or Business Network (in-cluding social): Native cloud applications orcloud integrated on-premise applications in-teract with business partners in business net-works (e. g., payment, financial, supplier rela-tionships), connect to social networks (e. g.,social marketing) or consume cloud services(e. g., machine learning).

• Device to Cloud (including mobile and per-sonal computing): What starts with businessapplications on “bring your own device” formobility, extends to intelligence brought to ma-chines (e. g., sensors and actuators in smartlogistics or production) and eventually comesdown to sensors and devices for personal com-puting.

We left out the conventional On-Premise to On-Premise application integration and other varia-tions due to our focus on new trends. For thequantitative analysis, we selected one applicationintegration solution for each of the new scenariodomains, and we added one for cloud to cloud andbusiness networks due to the slight focus on thesedomains. The solutions can be visited as SAPCloud Integration standard content [97].

SAP Cloud for Customer (C4C). The C4C solu-tions for the communication with on-premise En-terprise Resource Planning (ERP) and CustomerRelationship Management (CRM) applications, ab-breviated c4c-erp and c4c-crm, can be considered

typical hybrid corporate to cloud application in-tegration [97]. The dominant integration styles –according to the classification in [2] – are processinvocation and data movement. The state changes(e. g., create, update) of business objects (e. g., busi-ness partner, opportunity, activity) as well as mas-ter data in the cloud or corporate applications (e. g.,ERP, CRM) are exchanged with each other.

SAP Financial Services Network (FSN). In con-trast to C4C, FSN [98], abbreviated fsn, is a cloud-based, business network that connects banks andother financial institutes with their corporate cus-tomers (e. g., for payments, bank account manage-ment). The integration style is mostly process in-vocation [2]. Besides reliability, the major focus lieson secure message exchange.

SAP Cloud Integration eDocument/Electronic In-voicing (eDocument). The SAP Cloud IntegrationeDocument/Electronic Invoicing is a solution forcountry-specific electronic document management[97]. The edocuments solution helps cooperationsto interact with legal authorities (e. g., implementthe new EU Data Protection Regulation5).

SAP Predictive Maintenance and Service (PdMS).In PdMS

[97], machine data is collected using an Internetof Things (IoT) platform and enriched with busi-ness information coming from, e. g., SAP BusinessSuite. This allows real time monitoring of the ma-chine that triggers alerts resulting in service ticketsin SAP CRM or ERP. Based on that any unusualtrends or behavior becomes visible and appropri-ate action, potentially avoiding unnecessary servicecosts, can be taken.

6.2. Scenario Analysis

For the analysis of the SAP delivered standardcontent in this paper, we prototypically imple-mented data discovery and mining capabilities intothe SAP Cloud Integration system, which identifieda total of 154 distinct integration scenarios (c4c-erp:42, c4c-crm: 37, fsn: 56, edocument: 13, pdms: 6).

The total number of patterns for all scenariosis 1501 (w/o adapters, endpoints). For the more“classical” integration scenarios in c4c-erp and c4c-crm nearly all integration patterns could be covered

5EU – General Data Protection Regulation: http://goo.gl/Ru0slz.

24

Figure 7: Scenarios using original EIP

by original EIP from [3] (apart from second levelconfiguration on monitoring and exception han-dling). For the cloud integration scenarios fsn andeDocument as well as for the pdms IoT scenario,466 new requirements (and 597 complementing, sec-ond level configurations) were needed in total, outof which 66% are covered by existing EIP (i. e., 1025capabilities in total). This means that for these in-tegration scenarios approximately 1

3 of the requiredpatterns are not covered by the original EIP.

Pattern Solutions covered by the EIP. The distri-bution of patterns covered by original EIP is de-picted in Fig. 7. Not all EIP were required inthe scenarios of the integration solutions, however,nearly all of them facilitate the tasks of (i) Mes-sage Construction: solutions Document Messageand Request-Reply ; (ii) Messaging Channels: so-lution P2P Channel ; (iii) Message Routing: solu-tions Content-based Router, Splitter, and Aggrega-tor ; (iv) Message Transformation: solutions Con-tent Enricher, Content Filter, and Message Trans-lator.

New Pattern Solutions. Additional pattern solu-tions are covered by integration capabilities, de-picted in Fig. 8. We grouped the new solutionsaccording to the pattern catalog from Sect. 4 andadded the corresponding pattern proposals for eachof them. While approximately half of the new pat-terns from the catalog are used in the real-worldscenarios, the new conversation patterns, are notyet used in any of the scenarios. For example, theconfidentiality requirements covered message con-fidentiality or privacy patterns (Message Encryp-tor, Message Decryptor, Encrypted Message, En-crypting Endpoint, Encrypting Adapter) are calledMsg. Privacy, and the authenticity and integrityrequirements (Message Signer, Signature Verifier,Signed / Verified Message) are summarized to Msg.Auth.. Thereby the message confidentiality is ex-clusively required for the communication within theFSN business network, while message authenticityis also used for exchanging eDocuments with thelegal authorities and for PdMS.

In the category multimedia, currently no realmedia format handlers (Type Converter, Encoder,

25

Figure 8: New capability categorization.

Decoder) are used (e. g., image, video). However,we grouped the used functionality into three pat-terns. The Encoder and Decoder patterns repre-sent the handling of binary message content, exclu-sively used in FSN and eDocument scenarios. Thisis due to the various communication partners, usingdi↵erent encodings, as well as third party services(e. g., financial document mapping engines), whichrequires special encodings. The Custom Script al-lows to add versatile User-defined Functions, whichare mostly used as auxiliary in FSN scenarios. Thecompression algorithms (Compress Content, De-compress Content), which would be immensely rel-evant in real multimedia scenarios, are used in FSNscenarios due to larger messages sizes (e. g., aggre-gated FSN payment details). Finally, marshalling(Marshaller, Unmarshaller) support is required inFSN scenarios, since some communication partnersrequire JSON to XML conversion and vice versa.

The processing of messages is mostly done bymoving messages through the pipeline. However,especially the FSN and CRM integration requirestreaming and parallel processing. This is againdue to scenarios with larger messages to be pro-cessed (e. g., IDoc segments in CRM) and stream-based splitting in PdMS. The Multicast pattern is

used as Sequential Multicast in FSN to allow guar-anteed rollback for all branches in case of an errorand as Parallel Multicast in PdMS for parallel pro-cessing purpose.

This behaviour is complemented by a Stop Allsetting in the FSN, PdMS and partially CRM sce-narios, consequently stopping the message process-ing in all parallel instances of the integration sce-nario. Another error handling functionality is theRethrow, which allows to (re-) throw exceptions.The Rethrow is mainly used in eDocument, FSN,PdMS and CRM scenarios to indicate that a situ-ation is still unresolved. Especially in FSN, PdMSand eDocument scenarios, it is important to informa business expert or administrator about erroneoussituations. The Raise Indicator is used for this pur-pose. To prevent from unconrollable behaviour andto customize the information returned in case of anerror in synchronous scenarios, a Catch-all excep-tion process (with several steps) is used in FSN andeDocument scenarios.

To remember parts of a message or additionalinformation generated by adapters or message pro-cessors, a Transient Store (cf [56]) is used in FSN.The Store Accessor, used by FSN and eDocument,is mostly used for stateful pattern compositions and

26

for legal reasons (Data Store, Audit Log). Espe-cially in FSN, most of the message stores are en-crypting (Encrypting Store), which means that themessages are stored confidentially.The composition in terms of the Integra-

tion Subprocess pattern (excluding the exceptionsub-processes) indicates complex processing logic,which can mostly be found in FSN, PdMS andeDocument scenarios. Sometimes composition isused for re-usable process parts.In summary, the analysis shows the need for new

patterns and solutions as seen in the system review.While the hybrid integration scenarios simply ex-tend the on-premise integration into the cloud re-lying on transport level security, all other new inte-gration scenario domains require more on securityand control over the message processing in form oferror handling. This becomes more obvious, themore exclusively the integration scenarios are run-ning in the cloud. For example, the small amountof device integration scenarios still relies on inte-gration logic on the devices, thus show only fewsecurity, error handling and processing capabilities.The scenarios are less complex – compared to thecloud to cloud cases, hence require limited compo-sition options. Furthermore, with increasing cloudfocus, the trade-o↵ between more complex, but ex-pressive, stateful and simpler, better scalable, state-less message processing seems to lean towards theinteraction with storage currently. The conversa-tion patterns – including stateful conversations –are still mostly unexplored. The same is true forthe increasingly important topic of multimedia pro-cessing, which will give a new edge to the varietyand interoperability problems in EAI [2].

7. Challenges, Limitations, Impact

The literature (cf. [5]) and the quantitative anal-ysis of real-world integration scenarios (cf. Figure7) show that some of the enterprise integration pat-terns (EIP) described by [3] in 2004 are still widelyused, thus denote best-practices in the area of ap-plication integration. This supports the assumptionof the EIP authors that the patterns are still prac-tically relevant [5]. Literature and system reviewsalso reveal that since 2005 several new trends andnon-functional aspects (NFA) for enterprise appli-cation integration have appeared that are not cov-ered by the EIP from 2004. Literature as well assystems partly o↵er solutions to these new trends

and NFA where the systems provide a more compre-hensive support. Solutions mentioned in the liter-ature comprise patterns, formalization, and model-ing, covering the spectrum from a more abstract de-scription as patterns (cf. Sect. 5) to the implemen-tation and execution as well as towards the user’spoint of view. For this reason, patterns are regardedas the “glue” for which a comprehensive descrip-tion is required first. Hence, this work (togetherwith the supplementary material [44]) aimed at fill-ing the gaps in existing patterns for new integra-tion trends and NFA (cf. Sect. 5): security, (ideason) conversation, monitoring, storage. Nonetheless,the di↵erent reviews and analyses conducted in thiswork indicate open research challenges. These aresubsequently summarized and discussed.

7.1. Research Challenges

The literature review shows that for the trendsand NFA di↵erent solutions have been proposed,mainly patterns, formalization, and modeling.

7.1.1. Patterns

Patterns are the predominant solution proposedin literature (cf. Tab. 1). Moreover, this workhas closed gaps by providing patterns for NFA notpresent so far. Still pattern descriptions would benecessary in the context of the following trendsand NFA. At first, multimedia functions are under-represented. Due to the access to the end user, mul-timedia becomes more and more interesting for allkinds of applications (e. g., sentiment analysis, mon-itoring in di↵erent domains like medicine or agricul-ture). For application integration, this targets thevolume, variety and interoperability problems. Theresulting increase of heterogeneity of media formatsand communication partners (e. g., cloud applica-tions, mobile devices, camera phones) demands forrevisiting the EIP in the context of multimedia op-erations and their semantic aspects. Consequently,the increasing message sizes require the evaluationof optimization techniques (e. g., message indexing),and more e�cient processing styles like stream-ing, which the EIP authors also acknowledge [5],or data-aware integration pattern solutions (e. g.,[91]). In general, to address the Big Data chal-lenges of volume and velocity requires correspond-ing benchmarks for pattern (e. g., EIPBench [99])as well as for end-to-end system implementations,which are currently missing. As additional NFA,only few of the conversation patterns are supported.

27

For instance, Sect. 5 showed that conversation pat-terns can provide alternatives to improve the cur-rent processing and might become useful in morecomplex application or device interactions (e. g., de-vice mesh [6]). The monitoring of integration sce-narios across multiple platforms (e. g., mobile, on-premise, cloud) – including aspects like raising in-dicators in case of an event – remains a challenge.This also hints on further work required for MobileComputing and Internet of Things, e. g., standard-ized protocols, conversation or interaction patterns(incl. data collection, device reconfiguration), en-ergy e�ciency. Finally, as new trends and NFAmight constantly arise, their analysis with respectto pattern support becomes a continuous task.

7.1.2. FormalizationStarting from the pattern view, formalization is

an important step to precisely specify the seman-tics of the pattern realizations, i. e., formalizationconstitutes an important step towards the imple-mentation and execution of the patterns in integra-tion scenarios. As shown in Tab. 1 formalizationapproaches have been predominantly proposed inthe context of service oriented architectures (SOA)for validating and optimizing compositions by, forexample, mapping them to Petri nets. Notably, amore formal definition of integration pattern com-position (also suggested by the EIP authors [5]) isrequired not only for structural validations usingPetri nets – as in the literature review, but also se-mantic, runtime validations and optimizations onstatic scenario as well as dynamic, workload datais missing. First work on the latter was conductedby [100], however, has to be revisited in the contextof the trends and NFA as well as new technical ca-pabilities (e. g., machine learning of / for workloadpatterns, routing conditions, condition orderings).Furthermore, cloud, mobile and device computingraise new questions about optimal runtime place-ments of integration processes. In general, there isstill an enormous potential for elaborating formal-izations for both, trends and NFA, specifically, as amore or less comprehensive set of patterns has beenproposed by now. A follow-up research question ishow to implement patterns and pattern composi-tions in solutions using formal models.

7.1.3. ModelingExcept few works in the SOA domain provid-

ing modeling support for compositions, no attentionhas been paid to model integration-specific aspects

so far. For compositions, business process modelingnotations such as business process model and nota-tion (BPMN) can be used, however, the integration-specific aspects exceed the modeling capabilities.However, conveying information on the integrationscenarios to users is of utmost importance for, e. g.,maintenance and adaptations of these scenarios.Also here patterns might help to form the basisfor di↵erent modeling and visualization proposals.It could be envisioned to base integration flows onexisting business process modeling languages (e. g.,BPMN) in order to keep the mental map of users,but to enhance them with integration-specific icons.In [44], a first idea of equipping BPMN with integra-tion icons is depicted for the SAP Cloud IntegrationeDocument use case (due to lack of space we referto the technical report). In general, NFA like se-curity and multimedia have to be further analyzed.Therefore, new visual configuration editors, e. g.,allowing to “query by sketch” conditions, for inte-gration scenarios would provide a more adequate,non-textual configuration. In addition, editors andvisual data science (incl. machine learning) toolsfor scenario-based, runtime monitoring, which arecapable of dealing with large amounts of data, couldlead to smarter (cross-) integration platform admin-istration of integration scenarios. In this context,the development of visual modeling notations, neweditors together with extensive user studies becomenecessary.

7.2. Limitations

Limitations of the work concern the literatureand the system review. For both the searches wereled by the selection of keywords and criteria due tothe vast amount of existing work and in order tonot loose focus of this study. Nonetheless, conduct-ing further vertical searches and expert additionsthat were not found based on the keywords couldbe included in the analysis. The selection of repre-sentative systems is supposed to reflect the currentsystem o↵ering. Di↵erent types of systems (opensource, commercial, and startup) were considered.In summary, both reviews were envisioned to becomprehensive, but not complete. The quantitativeanalysis aims at covering a broad range of applica-tions based on five use cases. One might argue thatthe use cases are all provided by the same organiza-tion. However, this provides the chance to analyzereal-world scenarios instead of toy examples.

28

7.3. Impact

The impact of a continuous analysis of integra-tion trends and NFA on research and practice isenormous. The impact on research is reflected inthe open research challenges stated in Section 7.1.In order to address these challenges, a plethora ofnew approaches is necessary. The importance ofthe topic from a practical perspective is alreadyparamount as the system and scenario analyses ofthis paper show. Facing new trends that often stemfrom practice will perpetuate the importance of thiswork in the future. Putting the focus on the hu-man aspect in addition to a more technical treat-ment of the topic will also lead to a multitude ofnew research questions and practical implications.While the original EIP from 2004 are still relevantfor many of the new trends in 2016 and beyond,new capabilities are required to address require-ments (e. g., non-functional aspects) resulting fromthese trends (cf. hypothesis H1).

References

[1] S. Conrad, W. Hasselbring, A. Koschel, R. Tritsch, En-terprise Application Integration, Spektrum Akademis-cher Verlag, 2005.

[2] D. S. Linthicum, Enterprise Application Integration,Addison-Wesley Longman Ltd., 2000.

[3] G. Hohpe, B. Woolf, Enterprise integration patterns:Designing, building, and deploying messaging solu-tions, Addison-Wesley Professional, 2004.

[4] Forrester Research, Inc., The Forrester Wave: Hy-brid Integration For Enterprises, Q4 2016, https:

//www.forrester.com/report/The+Forrester+Wave+

Hybrid+Integration+For+Enterprises+Q4+2016/-/

E-RES131101 (2016).[5] O. Zimmermann, C. Pautasso, G. Hohpe, B. Woolf,

A decade of enterprise integration patterns: A conver-sation with the authors, IEEE Software 33 (1) (2016)13–19.

[6] Gartner, Inc., Gartner Newsroom Emerg-ing Technologies from 2005 To 2017, http:

//www.gartner.com/newsroom/id/492152,http://www.gartner.com/newsroom/id/495475,http://www.slideshare.net/dinhledat/

dinh-ledat-top-10-technology-trends-20072014-gartner,http://www.gartner.com/newsroom/id/530109,http://www.gartner.com/newsroom/id/777212,http://www.gartner.com/newsroom/id/1210613,http://www.gartner.com/newsroom/id/1454221,http://www.gartner.com/newsroom/id/1826214,http://www.gartner.com/newsroom/id/2209615,http://www.gartner.com/newsroom/id/2603623,http://www.gartner.com/newsroom/id/2867917,http://www.gartner.com/newsroom/id/3143521,http://www.gartner.com/newsroom/id/3482617

(2017).[7] Forrester Research, Inc., The Top 10 Technology

Trends To Watch: 2016 To 2018, https://www.

forrester.com/report/The+Top+10+Technology+

Trends+To+Watch+2016+To+2018/-/E-RES120075

(2016).[8] R. Wieringa, Design Science Methodology for Infor-

mation Systems and Software Engineering, Springer,2014.

[9] B. Kitchenham, Procedures for performing systematicreviews, Tech. Rep. TR/SE-0401, Keele University,Keele, UK (2004).

[10] C. Hentrich, U. Zdun, Patterns for business ob-ject model integration in process-driven and service-oriented architectures, in: Proceedings of the 2006conference on Pattern languages of programs, 2006,p. 23.

[11] C. Hentrich, U. Zdun, Service integration patterns forinvoking services from business processes., in: Euro-PLoP, 2007, pp. 235–278.

[12] C. Hentrich, U. Zdun, A pattern language for processexecution and integration design in service-oriented ar-chitectures, in: Transactions on Pattern Languages ofProgramming I, Springer, 2009, pp. 136–191.

[13] U. Zdun, C. Hentrich, W. M. Van Der Aalst, A surveyof patterns for service-oriented architectures, Interna-tional journal of Internet protocol technology 1 (3)(2006) 132–143.

[14] U. Zdun, Pattern-based design of a service-orientedmiddleware for remote object federations, ACM Trans-actions on Internet Technology (TOIT) 8 (3) (2008)15.

[15] M. Autili, A. Di Salle, A. Perucci, M. Tivoli, Onthe automated synthesis of enterprise integration pat-terns to adapt choreography-based distributed sys-tems, ArXiv e-printsarXiv:1512.07682.

[16] V. Gacitua-Decar, C. Pahl, Ontology-based patternsfor the integration of business processes and enterpriseapplication architectures, Semantic Enterprise Appli-cation Integration for Business Processes: Service-Oriented Frameworks, IGI Publishers, Hershey, PA(2009) 36–60.

[17] M. Heller, M. Allgaier, Model-based service integra-tion for extensible enterprise systems with adaptationpatterns, in: e-Business (ICE-B), Proceedings of the2010 International Conference on, 2010, pp. 1–6.

[18] E. Kaneshima, R. T. V. Braga, Patterns for enter-prise application integration, in: Proceedings of the9th Latin-American Conference on Pattern Languagesof Programming, 2012, p. 2.

[19] K. Umapathy, S. Purao, Designing enterprise solu-tions with web services and integration patterns, in:IEEE International Conference on Services Comput-ing (SCC’06), 2006, pp. 111–118.

[20] Y. Zheng, H. Cai, L. Jiang, Application integrationpatterns based on open resource-based integrated pro-cess platform, in: International Conference on Infor-mation Computing and Applications, 2011, pp. 577–584.

[21] C. Gierds, A. J. Mooij, K. Wolf, Reducing adaptersynthesis to controller synthesis, IEEE Trans. Serv.Comput. 5 (1) (2012) 72–85.

[22] R. Seguel, R. Eshuis, P. Grefen, An overview on proto-col adaptors for service component integration, Tech.rep., Technische Universiteit Eindhoven (2008).

[23] V. N. Gudivada, J. Nandigam, Enterprise applicationintegration using extensible web services, in: IEEE In-ternational Conference on Web Services (ICWS’05),

29

2005, pp. 41–48.[24] W. Deng, X. Yang, H. Zhao, D. Lei, H. Li, Study

on EAI based on web services and SOA, in: Interna-tional Symposium on Electronic Commerce and Secu-rity, 2008, pp. 95–98.

[25] C. Mauro, J. M. Leimeister, H. Krcmar, Service ori-ented device integration-an analysis of SOA designpatterns, in: 43rd Hawaii International Conference onSystem Sciences (HICSS), 2010, pp. 1–10.

[26] Y. Liu, X. Liang, L. Xu, M. Staples, L. Zhu, Using ar-chitecture integration patterns to compose enterprisemashups, in: Software Architecture & European Con-ference on Software Architecture, 2009, pp. 111–120.

[27] Y. Liu, X. Liang, L. Xu, M. Staples, L. Zhu, Compos-ing enterprise mashup components and services usingarchitecture integration patterns, Journal of Systemsand Software 84 (9) (2011) 1436–1446.

[28] D. Braga, S. Ceri, F. Daniel, D. Martinenghi, Mashingup search services, IEEE Internet Computing 12 (5)(2008) 16–23.

[29] S. Cetin, N. I. Altintas, H. Oguztuzun, A. H. Dogru,O. Tufekci, S. Suloglu, A mashup-based strategy formigration to service-oriented computing., in: Interna-tional Conference on Pervasive Service, 2007, pp. 169–172.

[30] X. Qu, X. Yang, J. Zhong, X. Lv, Integration patternsof grid security service, in: Sixth International Con-ference on Parallel and Distributed Computing Appli-cations and Technologies (PDCAT’05), 2005, pp. 524–528.

[31] D. Shah, D. Patel, Dynamic and ubiquitous securityarchitecture for global SOA, in: The Second Interna-tional Conference on Mobile Ubiquitous Computing,Systems, Services and Technologies, UBICOMM’08.,2008, pp. 482–487.

[32] M. Fisher, S. Sharma, R. Lai, L. Moroney, Java EEand. Net Interoperability: Integration Strategies, Pat-terns, and Best Practices, Prentice Hall Professional,2006.

[33] C. Ouyang, E. Verbeek, W. M. Van Der Aalst, S. Breu-tel, M. Dumas, A. H. Ter Hofstede, Formal semanticsand analysis of control flow in WS-BPEL, Science ofComputer Programming 67 (2) (2007) 162–198.

[34] N. Lohmann, P. Massuthe, C. Stahl, D. Weinberg,Analyzing interacting WS-BPEL processes using flexi-ble model generation, Data & Knowledge Engineering64 (1) (2008) 38–54.

[35] A. Kumar, Z. Shan, Algorithms based on pattern anal-ysis for verification and adapter creation for businessprocess composition, in: OTM Confederated Interna-tional Conferences, 2008, pp. 120–138.

[36] J.-m. Jiang, S. Zhang, P. Gong, Z. Hong, Mes-sage dependency-based adaptation of services, in:IEEE Asia-Pacific Services Computing Conference(APSCC), 2011, pp. 442–449.

[37] A. Barros, M. Dumas, A. H. Ter Hofstede, Serviceinteraction patterns, in: International Conference onBusiness Process Management, 2005, pp. 302–318.

[38] T. Kollmann, C. Hentrich, Synchronization patternsfor process-driven and service-oriented architectures.,in: EuroPLoP, 2006, pp. 199–228.

[39] F. B. Vernadat, Interoperable enterprise systems:Principles, concepts, and methods, Annual reviews inControl 31 (1) (2007) 137–145.

[40] G. Grossmann, M. Schrefl, M. Stumptner, Exploit-

ing semantics of inter-process dependencies to instan-tiate predefined integration patterns, in: Proc. of the26th international conference on Conceptual modeling,2007, pp. 155–160.

[41] H. Taylor, A. Yochem, L. Phillips, F. Martinez, Event-driven architecture: How SOA enables the real-timeenterprise, Pearson Education, 2009.

[42] O. P. Patri, V. S. Sorathia, A. V. Panangadan, V. K.Prasanna, The process-oriented event model (PoEM):A conceptual model for industrial events, in: Inter-national Conference on Distributed Event-Based Sys-tems, 2014, pp. 154–165.

[43] S. Asmus, A. Fattah, C. Pavlovski, Enterprise clouddeployment: Integration patterns and assessmentmodel, IEEE Cloud Computing 3 (1) (2016) 32–41.

[44] D. Ritter, S. Rinderle-Ma, Toward a collection of cloudintegration patterns, arXiv preprint arXiv:1511.09250.

[45] D. Merkel, F. Santas, A. Heberle, T. Ploom, Cloudintegration patterns, in: European Conference onService-Oriented and Cloud Computing, 2015, pp.199–213.

[46] D. Ritter, Experiences with business process modeland notation for modeling integration patterns, in:European Conference on Modelling Foundations andApplications, 2014, pp. 254–266.

[47] D. Ritter, Towards more data-aware application inte-gration (extended version), CoRR abs/1504.05707.URL http://arxiv.org/abs/1504.05707

[48] D. Mansor, Moving to the cloud: Patterns, integrationchallenges and opportunities, in: Proceedings of the7th International Conference on Advances in MobileComputing and Multimedia, 2009, pp. 9–9.

[49] H. Buckow, H.-J. Groß, G. Piller, K. Prott,J. Willkomm, A. Zimmermann, Integration strategiesand patterns for SOA and standard platforms, in: GIJahrestagung (1), 2010, pp. 398–403.

[50] M. Heiss, A. Oertl, M. Sturm, P. Palensky, S. Vielguth,F. Nadler, Platforms for industrial cyber-physicalsystems integration: contradicting requirements asdrivers for innovation, in: Modeling and Simulationof Cyber-Physical Energy Systems, 2015, pp. 1–8.

[51] D. Ritter, J. Bross, Datalogblocks: relational logicintegration patterns, in: International Conference onDatabase and Expert Systems Applications, 2014, pp.318–325.

[52] T. Scheibler, F. Leymann, A framework for executableenterprise application integration patterns, in: Enter-prise Interoperability III, Springer, 2008, pp. 485–497.

[53] T. Scheibler, F. Leymann, Realizing enterprise inte-gration patterns in WebSphere, Tech. rep., Universityof Stuttgart (2005).URL http://dx.doi.org/10.18419/opus-2563

[54] R. Thullner, A. Schatten, J. Schiefer, Implement-ing enterprise integration patterns using open sourceframeworks, Software Engineering Techniques inProgress (2008) 111–124.

[55] G. Hohpe, Conversation patterns, in: The Role ofBusiness Processes in Service Oriented Architectures,no. 06291 in Dagstuhl Seminar Proceedings, 2006, p. 7.

[56] L. Gonzalez, R. Ruggia, Addressing QoS issues in ser-vice based systems through an adaptive ESB infras-tructure, in: Proceedings of the 6th Workshop on Mid-dleware for Service Oriented Computing, 2011, p. 4.

[57] D. Fahland, C. Gierds, Using petri nets for modelingenterprise integration patterns, Tech. rep., bpmcen-

30

ter.org (2012).[58] D. Fahland, C. Gierds, Analyzing and completing

middleware designs for enterprise integration usingcoloured petri nets, in: International Conference onAdvanced Information Systems Engineering, 2013, pp.400–416.

[59] O. P. Patri, A. V. Panangadan, V. S. Sorathia, V. K.Prasanna, Semantic management of enterprise integra-tion patterns: A use case in smart grids, in: DataEngineering Workshops (ICDEW), 2014, pp. 50–55.

[60] S. Basu, T. Bultan, Automatic verification of in-teractions in asynchronous systems with unboundedbu↵ers, in: International conference on Automatedsoftware engineering, 2014, pp. 743–754.

[61] P. Mederly, M. Lekavy, M. Zavodsky, P. Navrat, Con-struction of messaging-based enterprise integration so-lutions using AI planning, in: IFIP Central and EastEuropean Conference on Software Engineering Tech-niques, 2009, pp. 16–29.

[62] P. Mederly, P. Navrat, Construction of messaging-based integration solutions using constraint program-ming, in: East European Conference on Advances inDatabases and Information Systems, 2010, pp. 579–582.

[63] R. Kazman, K. Schmid, C. B. Nielsen, J. Klein, Un-derstanding patterns for system of systems integration,in: System of Systems Engineering, 2013, pp. 141–146.

[64] R. Land, I. Crnkovic, S. Larsson, Process patternsfor software systems in-house integration and merge-experiences from industry, in: Conference on Soft-ware Engineering and Advanced Applications, 2005,pp. 180–187.

[65] D. Chen, G. Doumeingts, F. Vernadat, Architecturesfor enterprise integration and interoperability: Past,present and future, Computers in industry 59 (7)(2008) 647–659.

[66] H. Panetto, R. Jardim-Goncalves, A. Molina, Enter-prise integration and networking: theory and practice,Annual Reviews in Control 36 (2) (2012) 284–290.

[67] K. Wang, M. Dumas, C. Ouyang, J. Vayssiere, Theservice adaptation machine, in: European Conferenceon Web Services, 2008, pp. 145–154.

[68] S. Rajam, R. Cortez, A. Vazhenin, S. Bhalla, De-sign patterns in enterprise application integration fore-learning arena, in: International Conference on Hu-mans and Computers, 2010, pp. 81–88.

[69] W. He, L. Da Xu, Integration of distributed enterpriseapplications: a survey, IEEE Transactions on Indus-trial Informatics 10 (1) (2014) 35–42.

[70] G. Hohpe, Your co↵ee shop doesn’t use two-phasecommit, IEEE Softw. 22 (2) (2005) 64–66.

[71] S. Cranefield, S. Ranathunga, Embedding agents inbusiness processes using enterprise integration pat-terns, in: International Workshop on EngineeringMulti-Agent Systems, 2013, pp. 97–116.

[72] DELL Boomi, AtomSphere User Guide,http://help.boomi.com/atomsphere/

GUID-A98714FA-9EAB-4B69-BCC8-7D8984F0B0EC.html

(2017).[73] IBM, WebSphere Cast Iron Cloud integration, https:

//www.ibm.com/support/knowledgecenter/SSGR73

(2017).[74] Informatica, Cloud-Integration, https://www.

informatica.com/de/products/cloud-integration.

html (2017).

[75] Jitterbit, Harmony Cloud Integration, https://www.jitterbit.com/harmony/ (2017).

[76] Microsoft, BizTalk Server, https://msdn.microsoft.com/en-us/library/dd547397(v=bts.10).aspx

(2017).[77] SAP SE, SAP HANA Cloud Integration, http:

//www.sap.com/product/technology-platform/

hana-cloud-integration.html (2017).[78] Oracle, BEA WebLogic Integration, https://docs.

oracle.com/cd/E13214_01/wli/docs81/index.html

(2017).[79] Tray.io, Tray.io Docs, http://docs.tray.io/ (2017).[80] Zapier, Zapier v2 Documentation, https://zapier.

com/developer/documentation/v2/reference/

(2017).[81] Apache Foundation, Apache Flume, https://flume.

apache.org/ (2017).[82] Apache Foundation, Apache Nifi, https://nifi.

apache.org/ (2017).[83] C. Ibsen, J. Anstey, Camel in Action, 1st Edition,

Manning Publications Co., 2010.[84] Cloudpipes, Cloudpipes Documentation, https://

docs.cloudpipes.com/ (2017).[85] Tibco, Tibco Cloud Integration Documentation,

https://integration.cloud.tibco.com/docs/

index.html (2017).[86] Software AG, Webmethods Integration Cloud,

http://www.softwareag.com/corporate/products/

cloud/integration/default.asp (2017).[87] Gartner, Inc., Magic Quadrant for Enterprise

Integration Platform as a Service, World-wide, https://www.gartner.com/doc/3263719/

magic-quadrant-enterprise-integration-platform

(2016).[88] Forrester Research, Inc., The Forrester Wave: iPaaS

For Dynamic Integration, Q3 2016, https://www.

forrester.com/report/The+Forrester+Wave+iPaaS+

For+Dynamic+Integration+Q3+2016/-/E-RES115619

(2016).[89] D. Ritter, M. Holzleitner, Integration adapter model-

ing, in: Conference on Advanced Information SystemsEngineering, 2015, pp. 468–482.

[90] MuleSoft, Integration: The cloud’s big challenge,accessed: 01/2017 (2017).URL https://www.mulesoft.com/resources/

cloudhub/integration-clouds-big-challenge

[91] D. Ritter, Towards more data-aware application in-tegration, in: British International Conference onDatabases, 2015, pp. 16–28.

[92] C. Peltz, Web services orchestration and choreography,IEEE Computer 36 (10) (2003) 46–52.

[93] D. Ritter, J. Sosulski, Modeling exception flows in in-tegration systems, in: Enterprise Distributed ObjectComputing Conference, 2014, pp. 12–21.

[94] D. Ritter, J. Sosulski, Exception handling in message-based integration systems and modeling using BPMN,Int. J. Cooperative Inf. Syst. 25 (2) (2016) 1–38.

[95] C. Fehling, F. Leymann, R. Retter, W. Schupeck,P. Arbitter, Cloud Computing Patterns - Fundamen-tals to Design, Build, and Manage Cloud Applications,Springer, 2014.

[96] E. Gamma, R. Helm, R. Johnson, J. Vlissides, DesignPatterns: Elements of Reusable Object-oriented Soft-ware, Addison-Wesley Longman Publishing Co., Inc.,1995.

31

[97] SAP SE, SAP HANA Cloud Integration - Prepack-aged Content, https://cloudintegration.hana.

ondemand.com/ (2017).[98] SAP SE, SAP Financial Services Network,

http://www.sap.com/product/financial-mgmt/

financial-services-network.html (2017).[99] D. Ritter, N. May, K. Sachs, S. Rinderle-Ma, Bench-

marking integration pattern implementations, in: In-ternational Conference on Distributed and Event-Based Systems, 2016, pp. 125–136.

[100] M. Bohm, D. Habich, S. Preissler, W. Lehner,U. Wloka, Cost-based vectorization of instance-basedintegration processes, Inf. Syst. 36 (1) (2011) 3–29.

32