Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The Future Internet promotes a distributed computing environment that will be increasingly surrounded by a large number of software services, which can be composed to meet user needs. The Future Internet of Services paradigm emerges from the convergence of the Future Internet (FI) and the Service-Oriented Computing (SOC) paradigm [1]. Services play a central role in this vision as effective means to achieve interoperability between heterogeneous parties of a business process, and new value added service-based systems can be built as a choreography of services available in the FI. Service choreography is a decentralized approach, which provides a loose way to design service composition by specifying the participants (i.e., roles) and the (message-based) interaction protocol between them, by decoupling the participant tasks from the services that only later will be bound to the specified roles.

The need for service choreography was recognized in the Business Process Modeling Notation version 2.0Footnote 1 (BPMN2), which introduced Choreography Diagrams to offer choreography-specific modeling constructs. A choreography diagram models peer-to-peer communication by defining a multi-party protocol that, when put in place by the cooperating parties, will permit to reach the overall choreography objectives in a fully distributed way. In this sense, service choreographies are quite different from service orchestrations in which a single stakeholder centrally plans and decides how an objective should be reached through the cooperation with other services.

In this paper we leverage the experience on choreography development that we have been doing so far within the EU CHOReOS projectFootnote 2. Then, being supported by the EU CHOReVOLUTION (follow-up) projectFootnote 3, we report on the novel idea we are currently investigating to achieve choreography adaptation and evolution to face the challenges posed by the heterogeneity of FI services.

In this direction, we propose a way to enhance the previous CHOReOS approach to the automatic synthesis of choreography-based systems [2–5], and describes the preliminary steps we are undertaking within CHOReVOLUTION towards exploiting Enterprise Integration Patterns (EIP) so as to deal with a form of choreography adaptation. The novel contributions can be summarized as follow: (i) adoption of EIP to deal with a form of adaptation for choreography-based systems; (ii) enhancement of our synthesis process by introducing an adapters generator; (iii) enhancement of the architectural style for including adapters.

The paper is structured as follow. Section 2 sets the context of our work, and Sect. 3 introduces an explanatory example. Then, Sect. 4 describes how the synthesis process can be enhanced to deal with choreography adaptation and evolution through protocol coordination, protocol adaptation and related complex data mappings, and Sect. 5 describes the proposed enhancement at work on the explanatory example. Related work is discussed in Sect. 6, and conclusions are given in Sect. 7.

2 Setting the Context

This section sets the context of our work by describing the problem we want to address in Sect. 2.1, and the idea underlying the proposed solution in Sect. 2.2. Then, Sect. 2.3 provides basic notions of the Enterprise Integration Patterns (EIP) [6] that we propose to exploit to deal with adaptation issues.

2.1 The Problem Space

When considering choreography-based service-oriented systems, the following problems are mainly considered:

  1. (i)

    realizability check - checks whether the choreography can be realized by implementing each participant so that it conforms to the played role;

  2. (ii)

    conformance check - checks whether the set of services satisfies the choreography specification;

  3. (iii)

    automatic realizability enforcement - given a choreography specification and a set of existing services, externally coordinate and adapt their interaction so as to fulfill the collaboration prescribed by the choreography specification.

In the literature, the approaches proposed in [7–19] address the problems (i) and (ii); the approaches proposed in [2, 3, 5, 20] address the problem (iii). In this paper we concentrate on the automatic realizability enforcement problem. Specifically, starting from previous work in [2–5], we propose the following enhancement to deal with a form of choreography adaptation that exploits EIP to built service adapters.

2.2 The Solution Space

Addressing the automatic realizability enforcement problem calls for solving both coordination issues and adaptation issues.

Coordination issues are addressed in previous work [2, 5], where we propose an automatic approach to synthesize the global coordination logic to be then distributed and enforced among the considered services. Preliminary ideas towards addressing adaptation issues are described in [3, 4], where we propose the use of adapters for solving interaction protocol mismatches deriving from the heterogeneity of services not born to be directly composed together.

In this paper we describe the initial steps we have done towards exploiting Enterprise Integration Patterns so as to deal with a form of choreography adaptation that, in addition to interaction protocol mismatches, also account for I/O data mismatches. Our mid-term goal within the CHOReVOLUTION project is to achieve automated data-flow coordination and adaptation, which means effectively coping with heterogeneous service interfaces and dealing with as much EIPs [6] as possible in a automatic way. In particular, the idea is to automatically generate adapters by combining different EIPs based on a notion of protocol mediation and data similarity.

2.3 Exploiting Enterprise Integration Patterns

From a technical point of view, achieving the above calls for dealing with mismatching service signatures and interaction protocols. In particular, to achieve adaptation, the operations signature and the interaction protocol of the concrete services may need to be adapted to the roles to be played in the input choreography model. This requires to implement a suitable notion of matching between protocols by means of complex data mappings over both operation names and I/O messages. Protocol refinement techniques must be developed to bridge the gap between the abstract protocol of the choreography participant roles and the protocol of the concrete services. These techniques, together with the ability of dealing with, e.g., appearing and disappearing services at run-time, would permit to achieve evolution through on-the-fly service binding.

EIPs offer more than one approach for integrating applications, i.e., File Transfer, Shared Database, Remote Procedure Invocation, and Messaging [6]. We focus on the Messaging approach since we consider Web Services (WSs) as possible choreography participants, and WSs communicate through messages passing (e.g., request/response or one-way operation types).

The Messaging approach uses the “pipes-and-filters” architectural style [21] as base for connecting applications. The Endpoints (Filters) are connected with one another via Channels (Pipes). The producing endpoint sends messages to the channel, and the messages are retrieved by the consuming endpoint. There are different types of pipes and filters patterns, each one of them dedicated to solve a particular integration aspect.

For the purposes of this paper, we consider: Message Transformation that converts a message from a format to another one; Message Aggregator that receives multiple messages and combines them into a single message.

3 Explanatory Example

The explanatory example introduced in this section is a very small portion of an In-store Marketing and Sale choreography that was used by the EU CHOReOS project to demonstrate an Adaptive Customer Relationship Booster system. The whole choreography was aimed at monitoring the activity of a client inside the shop in order to propose him/her tailored shopping offers and/or advertisements according to the user information (preferences, current shopping list, etc.) held by a shopping assistant application service.

Fig. 1.
figure 1

In-store marketing and sale choreography

Full size image

Figure 1 reports a simplified choreography diagram realized by using the Eclipse BPMN2 modeler pluginFootnote 4. The diagrams also shows the input and output messages of each choreography task. Within the Eclipse BPMN2 modeler, messages are specified by using the XML schema, which is the default language for specifying BPMN2 messages.

The choreography is triggered by the Client entering the shop. A Shop Entrance service (not shown in the figure) detects the presence of a specific Client inside the store and assigns him a virtual cart. Once subscribed to the cart, the Client can add and remove products to and from it. Once the Client finishes shopping, the Smart Cart service allows for executing the payment by interacting with the a Self Check-out Machine.

4 Method Description

In this section we describe the proposed method by distinguishing between protocol coordination and protocol adaptation.

Protocol coordination allows for preventing undesired interactions among (possibly adapted) services. That is, interactions not allowed by the choreography specification can happen when the services collaborate in an uncontrolled way. To deal with this problem, additional software entities, called Coordination Delegates (CDs), are generated and interposed among the services participating in the specified choreography in order to prevent possible undesired interactions. Thus, the intent of CDs is to coordinate the interaction of the participant services in a way that the resulting collaboration correctly realizes the specified choreography. For instance, the Client is allowed to perform the Add Product task to add products to the Smart Cart (see the top of the Fig. 1). However, after paying and before check-out, an undesired interaction can happen since the Client might try to add products (see the top-most tasks just before the End Event), thus avoiding paying for them.

Protocol adaptation allows for dealing with services that do not exactly fit the choreography roles. That is, adapters are automatically synthesized to mediate the interaction service-to-CD and CD-to-service according to the choreography roles (see Fig. 2). Each Adapter is generated so as to bridge/mediate the concrete service interaction protocol in order to exactly match the abstract participant interaction protocol. In other words, Adapters realize correct service-role binding by solving possible interoperability issues (e.g., signature and protocol mismatches) between concrete services and abstract participants. By leveraging a sufficiently accurate notion of behavioral interface refinement, Adapters enforce service-role similarity, hence binding the concrete services to the abstract roles defined by the choreography. The synthesized Adapters enforce exact similarity through complex data mappings and complex protocol mediation patterns. For instance, Adapters are able to map message data types, or reorder/merge/split the sequence of operation calls and/or related I/O messages.

Fig. 2.
figure 2

Architectural style with adapters

Full size image

Coordination and adaptation software entities are synthesized in order to proxify and control the participant services’ interaction. When interposed among the services, according to the architectural style shown in Fig. 2, coordination entities still guarantee the collaboration specified by the choreography specification through protocol coordination; adaptation entities mediate the interaction of the participant services so as to fit the choreography roles.

An important aspect here is that the coordination logic performed by the CDs is service-independent since it is based on the expected behavior of the participants as specified by the choreography, rather than on the actual concrete services to be binded and coordinated. In this way separation of concerns is realized by separating pure coordination issues (i.e., undesired interactions) from adaptation/mediation ones (e.g., operation signature mismatches and data incompatibilities at the service interface level, and behavior mismatches). For example, the latter can arise whenever a service discovered as a participant does not exactly match the role to be played.

In order to automatically synthesize adaptation software entities we propose an extension of our CHOReOSynt tool [22] introducing a new RESTful service called Synthesis Adapter Generator (see Fig. 3).

Fig. 3.
figure 3

REST architecture of the extended synthesis processor

Full size image

By taking as input a BPMN 2.0 specification of the choreography, the extension we propose allows for deriving service Adapters in addition to CDs (Fig. 3). To this end, model transformations are employed and interoperation with the Service Discovery is required (out of the scope of this paper). Both CDs and Adapters, when deployed by the Enactment Engine (out of the scope of this paper), allow for enacting the choreography by realizing the distributed coordination logic between the discovered services.

The tool consists of the following RESTful services, and a set of Eclipse plugins that have been developed to interact with such services.

M2M Transformator – The Model-to-Model (M2M) Transformator offers a set of model transformations.

Synthesis Discovery Manager – The Synthesis process and the Discovery process interact each other to retrieve, from the service base, those candidate services that are suitable for playing the participant roles required by the choreography specification, and hence, those services whose (offered and required) operations and behavior are compatible with the expected behavior as extracted from the choreography through projection.

Behavior Simulator – Once a set of concrete candidate services has been discovered, the synthesis process has to select them by checking, for each participant, if its expected behavior can be simulated by some candidate service. Note that, for a given participant, behavioral simulation is required since, although the discovered candidate services for it are able to offer and require (at least) the operations needed to play the role of the participant, one cannot be sure that the candidate services are able to support the operations flow as expected by the choreography.

Coordination Delegate and Adapter Generators – Once the services have been selected for all the choreography participants, the synthesis processor can generate the needed CDs and Adapters through the operations generateCD() and generateAdapter(), respectively.

In the following we introduce an example in the marketing and sale domain that will be then used in Sect. 5 to describe our method at work.

5 Method at Work

This section describes the proposed enhancement at work on the explanatory example introduced in Sect. 3. There are several frameworks and/or systems that implement/use EIPs in order to integrate applications. We have chosen Spring Integration frameworkFootnote 5 since it implements most of the EIPs, and it is well integrated with the Spring ecosystem. In particular, it is integrated with the Spring Web Services projectFootnote 6.

Fig. 4.
figure 4

Adapter architecture

Full size image

Figure 4 describes the architecture of the generated adapters by using Spring Web Services and Spring Integration. In particular, the Spring Web Services Endpoint is the Web Service that mediates the interaction of the Service S1 and the Service S2. When the Service S1 calls an operation op1 by sending a message m1, the Endpoint receives the operation and put the message into the input channel by using Inbound Web Service Gateways. The chain of EIPs, from the Input Channel to the Output Channel, is generated by the synthesis processor depending of the found interoperability issues (e.g., signature and protocol mismatches). The chain is made of one or more EIPs handlers to, e.g., Message Transformers, used to convert a message from one format to another one; Message Routers, used to decouple a message source from the ultimate destination of the message, and so on. Message Routers patterns can be, e.g., Splitter, Aggregator, Resequencer [6].

Referring to the explanatory example in Fig. 1, we focus on the Subscribe User Cart and Add Product Choreography Tasks.

Fig. 5.
figure 5

Adapter example

Full size image

Concerning Subscribe User Cart choreography task, let us suppose that the Client service is able to invoke a subscribeUserCart operation expecting as input message three string elements, one for name, one for surname, and one for email. The XSD schema codifying the input message is shown in Listing 1.1. Let us also suppose that the SmartCart service offers a subscribeUserCart operation expecting as input message only one User element. As shown in Listing 1.2, this element is a complex type encapsulating the following string elements: firstname, lastname, and mail.

In order to let the Client and the SmartCart services to communicate, the processor generates an adapter that offers the operation subscribeUserCart (name, surname, email) so that when the Client invokes subscribeUserCart (name, surname, email) operation, the adapter transforms the first message (Listing 1.1) into the second one (Listing 1.2). This is done by generating an ad-hoc Message Transformer handler and adding it to the chain. At the end, the adapter invokes the subscribeUserCart(User) operation offered by the Smart Cart service. This behavior is shown in Fig. 5a.

figure a
figure b

Concerning the Add Product choreography task let us suppose that the Client service invokes two operations, addProduct(product) and setQuantity (quantity). Let us also suppose that the SmartCart service offers a addProduct (product,quantity) operation. Differently from the previous case, the adapter is now generated by using the Message Router Aggregator pattern. This pattern allows for accumulating the two messages (i.e., product and quantity) received from the Client, and subsequently invokes the addProduct (product, quantity) operation offered by SmartCart (as shown in the Fig. 5b).

The method for generating adapters exemplified above requires automated synthesis of I/O data mappings. To this end, the idea is to exploits a slightly modified version of the Strawberry tool [23] that allows for automatically inferring data mappings between different messages of two different Web services, i.e., Client and SmartCart in our case. Strawberry exploits (i) static data type analysis to analyze the type structureFootnote 7 of the two different messages; (ii) testing check if the two messages are also semantically correlated (since in general, considering the messages’ type structure only is not sufficient). Efforts in this direction will be part of future work.

6 Related Work

The mediation/adaptation of protocols have received attention since the early days of networking. Indeed many efforts have been done in several directions including for example formal approaches to protocol conversion, like in [24, 25].

Recently, with the emergence of web services and advocated universal interoperability, the research community has been studying solutions to the automatic mediation of business processes [26, 27]. However, most solutions are discussed informally, making it difficult to assess their respective advantages and drawbacks.

Spitznagel and Garlan present an approach for formally specifying adapter wrappers as protocol transformations, modularizing them, and reasoning about their properties, with the aim to resolve component mismatches [28]. Although this formalizations supports modularization, automated synthesis is not treated at all hence keeping the focus only on adapter design and specification.

Passerone et al. use a game theoretic approach for checking whether incompatible component interfaces can be made compatible by inserting a converter between them which satisfies specified requirements. This approach is able to automatically synthesize the converter [29]. In contrast to our method, their method needs as input a deadlock-free specification of the requirements that should be satisfied by the adapter, hence delegating to the user a non-trivial specification task.

Recently, Bennaceur and Issarny presented an approach that, exploiting ontology reasoning and constraint programming, allows for automatically inferring mappings between components interfaces [30]. Importantly, these mappings guarantee semantic compatibility between the operations and data.

Rahm et al. propose a catalog of criteria for documenting the evaluations of schema matching systems [31]. In particular, the authors discuss various aspects that contribute to the match quality obtained as the result of an evaluation. In [32, 33] the authors present a generic schema match system called COMA, which provides an extensible library of simple and hybrid match algorithms and supports a powerful framework for combining match results. This framework can be used for systematically evaluate different aspects of match processing, match direction, match candidate selection, and computation of combined similarity, and different matcher usages.

Paolucci et al. propose a base algorithm [34] for semantic matching between service advertisements and service requests based on DAML-S, a DAML-based language for service description. The algorithm proposed differentiate between four degrees of matching and can be used for automatic dynamic discovery, selection and inter-operation of web services.

7 Conclusion and Future Works

In this paper, we propose a way to enhance the previous CHOReOS approach to the automatic synthesis of choreography-based systems, and we report on the novel idea we are currently investigating within CHOReVOLUTION to achieve choreography adaptation and evolution. In particular, the idea is to automatically generate adapters by combining different EIPs depending on a notion of protocol mediation and data similarity. In order to automatically synthesize the adapters we propose an extension to our CHOReOSynt tool by introducing a new RESTful service called Synthesis Adapter Generator. Furthermore, we propose a pipe-and-filter-based architecture of the generated adapters by using Spring Web Services and Spring Integration frameworks.

An explanatory example has been used to show two types of adaptation based on the Message Transformation pattern and the Message Aggregator pattern. The former plays a very important role by allowing the mediation of loose-coupling Message Producers and Message Consumers, which do not agree on a common data format. The latter is a type of Message Endpoint that receives multiple Messages and combines them into a single Message.

As future work, our plan is to fully implement the proposed extension and validate it on the case studies of the CHOReVOLUTION project.

Moreover, in order to achieve even more ambitious objectives within the CHOReVOLUTION project and to improve the applicability of the approach, we plan to extend it so as to deal with security aspects of the choreographies. This would allow for dealing with multiple services that belong to different security domains governed by different authorities, and use different identity attributes. This can be achieved by integrating EIPs with Security Patterns [35].