CHOReVOLUTION Development Process
Table of content
Introduction
This section describes the CHOReVOLUTION development process by using process diagrams to define the main activities that need to be performed and the artifacts manipulated by these activities.
Before describing the process, we briefly recall the main architectural elements of the CHOReVOLUTION architectural style by exploiting the very simple BPMN2 choreography diagram in Figure 1.
Figure 1 - BPMN2 Choreography Diagram example
The choreography in the figure concerns four sequential tasks, T1, T2, T3 and T4, and four participants, A, B, C, and D. We recall that choreographies are realized by instantiating participant roles with concrete services/things, and the CHOReVOLUTION architectural style distinguishes three different types of participants: consumer, provider, and prosumer (i.e., both consumer and provider). For instance, the consumer participant A might be played by an existing Client App; the provider participant D by an existing Web Service, e.g., Google; B and C might be two prosumers that have to be developed from scratch in order to realize the specified choreography.
Figure below shows the "most general" architectural configuration of the system that realizes the choreography specified in Figure 1, meaning that we consider the introduction into the systems of all the additional software artifacts that can be synthesized by performing the CHOReVOLUTION development process. The additional artifacts are not always required; rather, it depends on the specified choreography and the characteristics (e.g., interaction protocols, interfaces, interaction paradigms, security aspects) of the concrete services/things that have been selected to instantiate the roles of the choreography participants. In the Figure 2, a:A denotes that the role of the consumer participant A is played by a, the Client App in our example; d:D denotes that the role of the provider participant D is played by d, an existing provider service to be reused; whereas, concerning the participant B and C, in the Figure 2 we do not make use of this notation simply to indicate that they have to be built from scratch.
Figure 2 - Architectural Style (a sample instance of)
Briefly, the CHOReVOLUTION additional software artifacts are:
Coordination Delegates (CDs) coordinate the services interaction, in a fully distributed way, according to the collaboration prescribed by the choreography.
Adapter (A) is used to bind a concrete service to a choreography participant when their interfaces mismatch.
Binding Component (BC) bridges the gap between the middleware-level interaction paradigm of a service/thing (e.g., REST or CoAP) and SOAP, which is used by CDs as the middleware-level interaction paradigm.
Security Filter (SF) filters the interaction protocol of participant services with respect to different cross-boundary and multi-organisation security and identity requirements.
Service (S) is a logical representation of a (concrete) repeatable business activity that has a specified outcome and may be composed of other services. In general, it is a “black box” to consumers of the service.
CHOReVOLUTION Service/Thing specification process
The aim of this part is to describe the Design Phase described in Figure 3. The specification process supports the creation of service/thing description models (rounded rectangles in Figure 3) in terms of their interface, interaction protocol, QoS attributes, and security aspects. The process adopts a model-driven engineering approach.
The CHOReVOLUTION Studio offers a set of aptly developed graphical editors that support choreography developers while creating the following service/thing specification models. It is worth to note that, except for the interface description, all the other description models are optional. Clearly, the more description models are provided the more automatic support can be offered to choreography developers for selecting services and things, generating adapters and security filters, as well as reasoning on QoS aspects.
Figure 3 - Design Phase
Interface Specification process
This activity concerns the description of the interfaces exposed by the services to be involved in a choreography and, hence, to be stored into the Inventory. In order to suitably deal with the possible heterogeneity of the involved services, within CHOReVOLUTION, we defined a Generic Interface Description Language (GIDL). GIDL supports interface description for any kind of possible service (e.g., SOAP services, REST services) and thing. Indeed, it is necessary for all services and things that need to be connected to the choreography through a BC, meaning all non-SOAP participants. More generally, GIDL is a uniform description for any service or thing, enabling choreographies with heterogeneous participants. Following the current practice of service interface description, for SOAP services we use the Web Service Description Language (WSDL).
Interaction Protocol Specification
This activity supports the definition of the interaction protocol LTS (ipLTS) model. This model defines the business-level interaction protocol of a service/thing in terms of the observable (from outside) sequences of messages exchanged while interacting with other services/things. When available, the ipLTS enables the automatic selection from the Inventory of those services/things that can be suitably bound to the roles of the choreography participants. Otherwise, this selection must be manually performed by the choreography developer. Moreover, for a given service/thing, the availability of its ipLTS allows to automatically identify possible protocol mismatches with respect to the participant's role to be played and, as such, the introduction of an adapter in the choreographed system might be required.
QoS Specification
For each service/thing, this activity allows developers to specify the offered QoS, such as performance and reliability. The availability of this specification permits to deal with choreography QoS from design time to run time at different levels, from choreography level, to middleware level and cloud level. Concerning the design time, this specification activity allows for defining QoS models that support automated reasoning in order to predict the QoS of a choreography under design. This allows choreography developers for taking design- and synthesis-time decisions concerning the choreography, such as selection of services/things and their middleware protocols, with respect to the choreography QoS requirements. Concerning the runtime, we deploy crosscutting monitoring mechanisms at choreography level, middleware level and Cloud level. These mechanisms enable choreography dynamicity and evolution in that a reaction to, e.g., QoS degradation, can be undertaken by, e.g., substituting a service/thing and/or its associated middleware protocol, and cloning/adding virtual machines at Cloud level.
Security Specification
For each service/thing, this activity allows developers to specify (when needed) security policies. A security policy defines a set of security requirements that must be fulfilled to access a service/thing involved in a choreography. Security policies are then used during the SFs generation step. A security filter applies security interoperability mechanisms by acting as a proxy between a provider and a consumer.
CHOReVOLUTION Synthesis process
The diagram of the CHOReVOLUTION Synthesis process has been split into two parts as shown in Figure 4 - Synthesis Phase - Part 1 and Figure 4 - Synthesis Phase - Part 2.
Synthesis Phase - Part 1
Part 1 - Starting from the choreography specification, given in terms of BPMN2 Choreography Diagram and Messages XML Schema, Part 1 concerns the selection of the services/things from the inventory, and the generation of the Binding Components (BC), Security Filters (SF), Adapters (A), and Coordination Delegates (CD) artifacts.
Figure 4 - Synthesis Phase - Part 1
Validation
The synthesis processor validates the correctness of the choreography specification against the constraints imposed by the BPMN2 Standard Specification. The goal is to check the choreography realizability and its enforceability by the CHOReVOLUTION process. With the term enforceability we mean the ability to externally coordinate, adapt and secure the interaction of a set of possibly existing services so as to fulfill the collaboration prescribed by the choreography specification.
Choreography Projection
Taking as input the BPMN2 Choreography Diagram and Messages XML schema, the processor automatically extracts all the choreography participants and applies a model-to-model (M2M) transformation to derive the related Participant Models, one for each participant. A participant model is itself a BPMN2 Choreography Diagram. It contains only the choreography flows that involve the considered participant. The generated participant models will be then taken as input by the CD Generation activity.
Selection
This activity is about querying the Service Inventory in order to select concrete services/things that can play the roles of the choreography participants. Once the right services have been selected, the related description models will be used by the synthesis processor to generate the BCs, SFs, Adapters, and CDs, as per the following steps.
Binding Component Generation
BCs are generated when the interaction paradigm of a selected service (or thing) is different from SOAP, which is used by CDs as the middleware-level interaction paradigm.
Security Filter Generation
SFs are generated for those (selected) services having security policies associated. SFs filter the services interactions according to the specified security requirements. Each SF has the same implementation, meaning that its logic is parametric with respect to its dynamically interpreted configuration file. Thus, the CHOReVOLUTION Synthesis Processor takes care of generating the SF configuration files out of the specified security policies.
Adapter Generation
When needed, adapters allow to bridge the gap between the interfaces and interaction protocols of the selected services/things and the ones of the (respective) participant roles they have to play, as obtained via projection. Thus, the adapters are automatically synthesized to mediate the interaction Service-to-CD and CD-to-Service, also taking into account possible SFs and BCs in between. In other words, adapters solve possible interoperability issues due to operation names mismatches and I/O data mapping mismatches. The implementation of the adapter generation step will be carried on during the 3rd year of the project.
Coordination Delegate Generation
CDs are in charge of coordinating the interactions among the selected services/things so as to fulfill the global collaboration prescribed by the choreography specification, in a fully distributed way. The new CDs synthesis method fully decouples the coordination logic of the services involved in the choreography from their business logic. Developers can now realize CHOReVOLUTION choreographies by only focusing on the implementation of the internal logic related to single choreography tasks, completely disregarding the handling of messages and the realization of the external choreography flows.
Synthesis Phase - Part 2
Part 2 - Starting from the selected services/things and the generated artifacts, Part 2 concerns the generation of the Choreography Architecture Description and the Choreography Deployment Description.
Figure 4 - Synthesis Phase - Part 2
Choreography Architecture Generation
Considering the selected services/things and the generated BCs, SFs, As, and CDs, an architectural description is automatically generated, and a graphic representation of the choreographed system is provided. The architectural model represents an instance of the CHOReVOLUTION architectural style in which all architectural elements and their interdependencies are represented.
Choreography Deployment Generation
The last activity of the synthesis process concerns the generation of the Choreography Deployment Description (called ChorSpec) out of the Choreography Architecture model. The deployment description will be given as input to the Enactment Engine (via Service Inventory) in order to deploy and enact the realized choreography.