# A Choreography-Based and Collaborative Road Mobility System for L'Aquila City
## 3 Chorevolution Approach  
This section introduces the CHOReVOLUTION approach to address the automatic realizability enforcement problem in the context of choreography-based service-oriented systems by reusing third-party services. When considering choreography-based service-oriented systems, the following two problems are usually considered: (i) _realizability check_--checks whether the choreography can be realized by implementing each participant so that it conforms to the played role; and (ii) _conformance check_--checks whether the set of services satisfies the choreography specification. In the literature, many approaches have been proposed to address these problems, e.g., [13; 27; 34; 35; 36; 37; 38; 39; 40]. However, to put choreographies into practice, we must consider realizing choreography-based service-oriented systems by reusing third-party services. This leads to a further problem: the _automatic realizability enforcement_. It can be informally phrased as follows: _given a choreography specification and a set of existing services, externally **coordinate** and **adapt** their interaction so to fulfill the collaboration prescribed by the choreography specification_. In our previous works [18; 20; 41; 42; 13], we describe how additional software entities--called **Coordination Delegates** (CDs)--can be automatically synthesized to proxify and coordinate the participants' interaction. When needed, CDs are interposed among the participant services according to a suitably generated architecture description. CDs enforce the collaboration prescribed by the choreography and they do not require any effort to developers concerning coordination issues. Our approach spares developers from writing code that goes beyond the realization of the business logic internal to those (single) choreography tasks for which no existing applications or services can be reused. Developers just need to fill-in-the-blank of automatically generated code templates. For what concerns adapting the interaction among the participant services (if needed), in our previous works [16; 21; 43], we describe how other additional software entities--called **Adapters (As)**--are automatically synthesized to solve possible interaction protocol mismatches between the interaction protocol of the abstract participant services, as described by the choreography specification, and the interaction protocol of the existing concrete services that are bound to the abstract ones. The Adapters are generated by exploiting a representation of the \"gap\" between the protocol of the abstract participants and the one of the concrete participants given in terms of (possibly complex) data mappings over both operation names and I/O messages, and their flows. Figure 1 shows a simple example of a BPMN2 choreography diagram, the standard de facto for specifying choreographies. Choreography diagrams define the way business participants coordinate their interactions. The focus is on the exchange of messages among the involved participants. A choreography diagram models a distributed process specifying activity flows where each activity represents a message exchange between two participants. Graphically, a choreography task is denoted by a rounded-corner box. The two bands, one at the top and one at the bottom, represent the participants involved in the interaction captured by the task. A white band is used for the participant initiating the task that sends the initiating message to the receiving participant in the dark band that can optionally send back the return message. The choreography in Figure 1 involves four participants, A, B, C, and D, for the execution of four sequential tasks, T1, T2, T3 and T4. Specifically, [PERSON] sends the message M1 to [PERSON], enabling it for the execution of T1. After that, [PERSON] replies to [PERSON] by sending the message M2.