chorevolution at gssi april-2017

Tools for Software Architecture

Seminar Lectures

GSSI - Center for Advanced Studies

11-12 Apr. 2017 – L’AQUILA (IT)

Marco AutiliUniversity of L’Aquila

in collaboration with Massimo Tivoli

Automatic Synthesis of Adaptable and Evolving Choreography-based

Service-oriented Systems

Where do we come from?

Automated Synthesis of Dynamic and Secured Choreographies

for the Future Internet(H2020 project)

(FP7 project)

(H2020 project)

13/04/17 MarcoAutili- SeminarLectures@GSSI 2

CHOReVOLUTION

• Title: Automated Synthesis of Dynamic and Secured Choreographies for the Future Internet

• Follow up FP7 EU project CHOReOS

• Period: January 2015 - January 2018

• Site: http://www.chorevolution.eu


Outline• (must have) Advanced Software Engineering

ingredients (a quick introduction)

• Setting the context

• Development scenario (high-level view)

• Synthesis process

• CHOReVOLUTION Platform

• CHOReVOLUTION Studio Demo13/04/17 MarcoAutili- SeminarLectures@GSSI 4


ingredients (a quick summary)






Distributed systems• Virtually all large computer-based systems are now

distributed systems• “… a collection of independent computers that appears to

the user as a single coherent system”

• Information processing is distributed over several computers rather than confined to a single machine

• Distributed Software Engineering is therefore very important for enterprise computing systems


Distributed system characteristics• Resource sharing

• Sharing of hardware and software resources

• Openness• Use of equipment and software from different vendors

• Concurrency• Concurrent processing to enhance performance

• Scalability• Increased throughput by adding new resources

• Fault tolerance• The ability to continue in operation after a fault has

occurred


Distributed systems issues• Distributed systems are more complex than

systems that run on a single processor

• Complexity arises because different parts of the system are independently managed as is the network

• There might be no single authority in charge of the system so top-down control is impossible


RPC communication


Message passing• Message-based interaction normally involves one component

creating a message that details the services required from another component

• Through the system middleware, this is sent to the receiving component

• The receiver parses the message, carries out the computations and (if needed) creates a response message for the sending component with the required results

• In a message-based approach, it is not always necessary for the sender and receiver of the message to be aware of each other. They simply communicate with the middleware


Ports and sockets


Synchronous messaging


The evolution of computing paradigms


- Req.mts Change- Dynamisms- Evolution

Components

Services

AbstractionModularity forReuse & ROI

Monolithic

Functions/procedures

Objects

SOC

- Static- Frozen- Frozen Req.mts

Towards Service-oriented Computing (SOC)

Software reuse• Software Engineering has been more focused on

original development but ...

• it is now recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse

• Nowadays, in most engineering disciplines, systems are designed by composing existing “software” that have already been used/experimented in other systems


Software reuse• There has been a major switch to reuse-based development over the

past 10 years.• Indeed, over the past 20 years, many techniques have been developed to

support software reuse

• The move to reuse-based development has been in response to demands for

• lower software production costs

• lower maintenance cost

• faster delivery of systems

• increased software quality

• More and more companies see their software as a valuable asset • Companies are promoting reuse to increase their return on software

investments

• One of the more recent trends is that standards, such as Web Service standards, have made it easier to develop general services and reuse them across a range of applications


Reuse-based software engineeringSoftware units that can be reused may be of radically different sizes

System reuse• Complete systems, which may include several application programs may be reused.

Application reuse• An application may be reused either by incorporating it without change into other or by

developing application families.

Service reuse• Standards, such as Web Service standards, have made it easier to develop general services

and reuse them across a range of applications.

Component reuse• Components of an application from sub-systems to single objects may be reused.

Object and function reuse• Small-scale software components that implement a single well-defined object or function

may be reused. This form of reuse, based around standard libraries, has been common for the past 40 years.


Implementing software reuse


Designpatterns

Architecturalpatterns

Applicationframeworks

Software productlines

Applicationsystem integration ERP systems

Systems ofsystems

Configurableapplication systems

Legacy systemwrapping

Component-basedsoftware engineering

Model-drivenengineering

Service-orientedsystems

Aspect-orientedsoftware engineering

Programgenerators

Programlibraries

The Encyclopedia of SOA FACTS• SOA is being used in the developing world to solve hunger. Entire populations will be fed on

future business value

• SOA can write and compile itself

• SOA is not complex. You are just dumb

• SOA in a Nutshell is 7,351 pages spread over 10 volumes

• One person successfully described SOA completely, and immediately died

• Another person successfully described SOA completely, and was immediately outsourced

• Larry Ellison once died in a terrible accident, but was quickly given SOA. He came back to life, built a multibillion dollar software company, and now flies fighter jets

• SOA is the only thing Chuck Norris can't kill http://www.guj.com.br/t/soa-facts/6917


Web services• A web service is an instance of a more general (higher

level) notion of a service:• “An act or performance offered by one party to another.

Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production”

• The essence of a service, therefore, is that the provisionof the service is independent of the application using the service

• Service providers can develop specialized services andoffer these to a range of service users from different organizations


Reusable services• In its simplest acceptation (only provider)

• a service is a reusable component that is independent (no required interface) and is loosely coupled

• In its more complex acceptation (prosumer), • a service can also have required interfaces, still being reusable, loosely coupled,

and still keeping independence (e.g., using late binding to “attach” required interfaces)

• Services are platform and implementation-language independent

• A web service is:• A loosely coupled, reusable software component that encapsulates discrete

functionality, which may be geographically distributed and programmatically accessed

• It is a service that is accessed using standard Internet and XML-based protocols


Service-oriented software engineering

• Building applications based on services allows companies and other organizations to cooperateand make use of each other’s business functions

• Service-based applications may be constructed by linking/composing services from various providers using:

• either a standard programming language (e.g., JAVA)• or a specialized workflow language (e.g., WS-BPEL)


Service-oriented architectures• A means of developing distributed systems where the

components are stand-alone services

• Services may execute on different (geographically distributed) computers from different service providers

• Standard protocols have been developed to support service communication (e.g., SOAP) and information exchange (e.g., WSDL)

• Services are platform and implementation-language independent


Service-oriented Interaction Pattern

Serviceregistry

Servicerequestor

Serviceprovider

Service

Find Publish

Bind (SOAP)(WSDL)


Service-oriented Interaction Pattern


Benefits of SOA• Services can be provided locally or outsourced to

external providers• Services are language-independent• Investment in legacy systems can be preserved• Inter-organisational computing is facilitated through

simplified information exchange


Key standards• XML Schema

• A schema describes the structure of an XML document

• SOAP• A message exchange standard that supports service communication

• WSDL (Web Service Definition Language)• This standard allows a service interface and its bindings to be defined

• WS-*• A variety of specifications associated with web services

(e.g., WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust)

• WS-PolicyIt is a specification that allows web services to use XML to advertise their policies (on security, quality of service, etc.) and for web service consumers to specify their policy requirements

• WS-BPEL• A standard for workflow languages used to define service composition


Key Web service standards

Transport (HTTP, HTTPS, SMTP, ...)

Messaging (SOAP)

Service definition (UDDI, WSDL)

Process (WS-BPEL)

Support (WS-Security, WS-Addressing, ...)

XML technologies (XML, XSD, XSLT, ....)


The most important aspects of SOA


Service Implementation and Service Provider

Service Contractual Description

HOW WHAT

Do not worry about HOW …

… only expect that it will

STOP

STOP

STOP

Application context (cont’d)

We are in the Future Internet (FI) era

distributed computing environment

large number of available software systems that

can be composed to meet user needs

* European Commission. Digital Agenda for Europe - Future Internet Research and

Experimentation (FIRE) initiative, 2015 13/04/17 MarcoAutili- SeminarLectures@GSSI 30

dynamic evolution according to...

... changing user preferences

... changing environmental context... new business needs

Application context


Growth of innovative and revolutionary everyday-life scenarios within smart cities

32

Smart Mobility ecosystems

the future smart mobility ecosystem scenario

different usersdifferent environments different stakeholders

fully connectedfully connected

• Dynamism• Heterogeneity• New value added services

e.g., route guidance, speed advisory,parking availability, POI suggestions13/04/17 MarcoAutili- SeminarLectures@GSSI

Composition approaches

Orchestration (centralized) Choreography (fully distributed)

Local centralized view from the perspective of one participant

Global decentralized view from a multi-participant perspective

(albeit without a central controller)


Why choreographies?• Services will be increasingly active software entities

• Communicating in a peer-to-peer style• Autonomously take decisions• Proactively engage in (business) tasks

• Owned by different organizations• It is not possible (or desirable) to centralize responsibilities• Multi-participant specification perspective is more appropriate

• Fully distributed deployment and execution of the composition code

• No single point of information flow • No single point of failure


The need for automated supportBuilding applications by reusing existing (third-party) services

(often black-box)

Composing services in a distributed way

Support for automation is needed(time-to-market, correctness by construction,

etc.)

Aiding software producers to realize, deploy, execute, and monitor choreography-based

systems by reusing existing services


Desirable Development Support• Automated tool support for, e.g.,

• making easier the creation of smart apps on top of existing things/services/systems

• “easily” dealing with distributed workflow management

• taking care of service/data binding and protocol adaptation

• enforcing security policies

• ... ... 13/04/17 MarcoAutili- SeminarLectures@GSSI 36

Development scenario (cont’d)

Choreography modelers cooperate each other to set business goals, e.g.,

- assisting travelers from arrival, to staying, to departure



Reserve TaxiFind POI

Reserve Table

Check Flight

… ...

… ...

… ...

Identify tasks and participants required to achieve the goal, e.g.,

- reserving a taxi from the local taxi company,

- purchasing digital tickets at the train station,

- performing transactions through services based on near field communication in a shop



Reserve TaxiFind POI

Reserve Table

Check Flight

… ...

… ...

… ...

Specify how participants must collaborate as admissible workflows of the identified business tasks

Model



Admissible workflows specified as:

- BPMN2 ChoreographyDiagrams

Model

BPMN2 Specification - http://www.omg.org/spec/BPMN/2.0/13/04/17 MarcoAutili- SeminarLectures@GSSI 41

inventory contains services/things published by providers, e.g.,

- transportation companies

- airport retailers


ModelInventory


• Out of the specified business goal, and

• the set of services available in the inventory ...

JANUARY/FEBRUARY 2015 | IEEE SOFTWARE 53

Step 1. Software producers cooperate with domain experts and business managers to

• set the business goal (for exam-ple, assist travellers from arrival, to staying, to departure),

• identify the tasks and partici-pants required to achieve the goal (for example, reserving a taxi from the local taxi com-pany, purchasing digital tickets at the train station, and per-forming transactions through services based on near-fi eld com-munication in a shop), and

• specify how participants must collaborate through a BPMN2 choreography diagram.

To support this step, CHOReOS pro-vides a plug-in that allows importing the goal specifi cation into the Magic-Draw modeling tool (www.nomagic.com) and associates it with BPMN2

constructs and quality-of-service constraints. In particular, CHOReOS uses both the Q4BPMN notation—an extension to BPMN2—to specify nonfunctional properties and dedi-cated automated tools to assess the choreography specifi cation’s quality.

Step 2. MagicDraw exports the mod-eled choreography to CHOReOSynt. CHOReOSynt supports the XML-based encoding of BPMN2 chore-ographies, such as the one of the BPMN2 Modeler.

Step 3. CHOReOSynt queries the reg-istry to discover services suitable for playing the choreography’s roles. The registry contains services published by providers (for example, trans-portation companies and airport re-tailers) that have identifi ed business opportunities in the domain of in-terest. To describe service interfaces, CHOReOSynt uses WSDL (Web

Services Description Language; www.w3.org/TR/wsdl). To describe service interaction behavior, BPEL (Business Process Execution Language) speci-fi es the fl ow of messages exchanged with the environment. The registry also contains the registration of users interested in exploiting the choreog-raphy through their mobile apps.

Step 4. Starting from the choreogra-phy diagram and the set of discov-ered services, CHOReOSynt syn-thesizes a set of CDs. The synthesis exploits model transformations. The transformations are implemented through ATL (www.eclipse.org/atl), a domain-specifi c language for real-izing model-to-model (M2M) trans-formations. ATL transformations comprise a number of rules, each of which manages a specifi c BPMN2 modeling construct. The current implementation of these transforma-tions in CHOReOSynt (available at

Design time Synthesis time

3

Businessmanager

Softwareengineer

End users

CHOReOSynt

Coordinationdelegates

Enactmentengine

Service providers

Domainexpert

Choreographydiagram

Model refinement

Model transformation

2

1

Execution time

4

1 5

1 6

Running choreography

Cloudmiddleware

Publish

Register

Standard communication (I/O messages)Additional communication (coordination information)

Registry

Services and things

1 5

FIGURE 2. An overview of automatic choreography synthesis, using a scenario involving the coordination of business services, thing-based services, and stakeholders from air transportation, customer relationship management, and intelligent transportation. WSDL stands for Web Services Description Language; BPEL stands for Business Process Execution Language.

s1aut.indd 53 12/9/14 3:02 PM













3

Businessmanager

Softwareengineer

End users

CHOReOSynt


Enactmentengine

Service providers

Domainexpert

Choreographydiagram

Model refinement


2

1

Execution time

4

1 5

1 6


Cloudmiddleware

Publish

Register


Registry

Services and things

1 5


s1aut.indd 53 12/9/14 3:02 PM

SynthesisProcessor













3

Businessmanager

Softwareengineer

End users

CHOReOSynt


Enactmentengine

Service providers

Domainexpert

Choreographydiagram

Model refinement


2

1

Execution time

4

1 5

1 6


Cloudmiddleware

Publish

Register


Registry

Services and things

1 5


s1aut.indd 53 12/9/14 3:02 PM

Choreography developer

Synthesis Processorautomatically produces (if possible) a choreography-

based application achieving the specified goal

Synthesis phaseModelling phase

CHOReVOLUTIONCloud InfrastructureModel

Inventory


BPMN2 Choreography DiagramsProsumer Services Third-party REST Services Third-party SOAP Services

Authenticated transactions


45

SEADA: Choreography diagram

Prosumer services• To integrate core business logic• SEADA-SEARP for route planing• SEADA-SEATSA for eco-evaluation• SEADA-TRAFFIC for traffic information

preparation

Third-party SOAP services• To provide route info• DTS-Google• DTS-Here

Third-party REST services• To get real-time traffic info• DTS-WEATHER• DTS-ACCIDENT• DTS-CONGESTION• DTS-BRIDGE• Need binding components to deal with

service heterogeneity

13/04/17 MarcoAutili- SeminarLectures@GSSI

A Use Case in the Smart Tourism DomainWe started identifying available local and global services in the Smart Tourism Domain in our town (Genoa)...

Then, we designed a choreography using the CHOReVOLUTION Studio

The synthetisedchoreography has been deployed on a OpenStack cloud environment

We built a simple android app to let tourists select POIs in the nearby and get best routes


Main ingredients of our method

Distributed Protocol Adaptation Layer

Distributed Business Logic Layer

Goal specification

S1S2

S4

S3

Existing services selected as good candidates to realize the required business logic

Distributed Protocol Coordination Layer

Goal specification

S1S2

S4

S3

Existing services selected as good candidates to realize the required business logic

GAP

interfaces exposed by concrete

services VS

abstract roles modeled by the choreography specification


Choreography coordination Problem

Automatic enforcement of choreography realizability• How to externally coordinate the interaction of existing services so to fulfill the

global collaboration prescribed by the choreography specification?

AssumptionBPMN2 Choreography Diagrams• A choreography-based specification of the system to be realized

Our solutionAutomated synthesis of Coordination Delegates (CDs)• Automatically produce the code of additional software entities that proxify and

coordinate the services’ interaction so to guarantee the specified global collaboration

FocusAutomatically realizing a choreography by reusing and suitably coordinating third-party services


The In-store Marketing and Sale

Parallelflows- fork- join

Alternativebranches- inclusive- exclusive

When dealing with third-party services, if left uncontrolled, their collaboration can exhibit undesired interactions

a Client is allowed to perform the Add Product task in order to add products to the Smart Cart

However, after the payment has been accomplished and before actually exiting the shop, a “malicious” client may attempt at adding further products, hence avoiding to pay for them

TaskinBPMN2- atomicactivity- twoparticipantroles(oneisinitiating)- XMLSchemausedinternally,e.g.,fordiscoverypurposes

CD2

CD4CD3

CD1

Task1R1 ––m1à R2

Task2R3 ––m2à R4

State machine based specification

S4:R4S3:R3

S1:R1 S2:R2May I?

May I? Yes Yes

YesNoNo

No

R1 ––m1à R2

Yes No

m1 m2Standard Communication

(I/O Messages)

Additional Communication(Coordination Information)

CDiCoordination Delegate

(Service Proxy)

Enforcing choreography realizability

CD2

CD4CD3

CD1

Enforcing choreography realizability

S4: R4S3: R3

S1: R1 S2: R2May I?

May I?Yes Yes

YesNoNo

No

Yes No

m1 m2

Standard Communication(I/O Messages)



(Service Proxy)


Choreography adaptationProblem

Enforcement of service-role bindings

• How to externally adapt the interaction of existing services so to “match” the specification of the choreography roles to be played?

Assumption

LTS-based or BPEL+WSDL-based specification

• A specification of the externally observable behavior of both services and roles in terms of types and sequences of message exchanges

Our solution

(Partially) automated synthesis of Adapters

• Produce adapters that mediate the interaction Service ßà CD

Focus

Realizing correct service-role binding by solving interoperability issues13/04/17 MarcoAutili- SeminarLectures@GSSI 52

CD2

CD4CD3

CD1

Enforcing service-role bindings

S4: R4S3: R3

S1: R1

S2: R2May I?

May I?Yes Yes

YesNoNo

No

Yes No

m1 m2Standard

Communication(I/O Messages)



(Service Proxy)

AAdapter

A

MarcoAutili- SeminarLectures@GSSI 53

m1! m1.1!

LTS-based specifications

R1 S1

m1.2!

m1 is an aggregate of m1.1 and m1.2

Adopted architectural style

S1 S2

S3

CD1.2 A2A1StandardCommunication(e.g.,request/responsemessages)

AdditionalCommunication(coordinationinformationforcoordinationpurposes)

CD ProtocolCoordinationLayer(CDs)

A ProtocolAdaptationLayer(Adapters)

S BusinessLogicLayer(Services)

S4

CD1.3 CD2.3

A3CD2.1

CD3.1CD4.1 A4

A5


Focusing on adapters generation

• We exploit Enterprise Integration Patterns (EIP)

The generated adaptation logic is realized as a composition of Message Routing patterns that realize I/O data mappings

Adapters are able to• map message data types• reorder/merge/split the sequence of operation

calls and/or related I/O messages


Considered EIP: Message Routing patterns


Adapters at work

Adapter1 CDClient_SmartCart

addProduct(product,quantity)

addProduct(product,quantity)

Adapter2

addItem(item)

setAmount(amount)

SmartCart

addProduct(product)

setQuantity(quantity)

setPromotionCode(promotioncode)

Client

Aggregator+Filter Splitter+Resequencer

13/04/17 57

Choreography evolution Problem

Choreography evolution

• How to enable choreography evolution in response to goal and context changes?

Assumption

Specification of variation points in terms of Call Choreographies

• Each variation point specifies behavioral alternatives in term of (set of) sub-choreographies

Our solution

Automated synthesis of autonomic CDs (aCDs)

• Automatically produce the code of CDs that are now are external controllers realizing multiple interacting feedback loops

Focus

Enabling (a form of) choreography evolution to face well-confined goals and context changes


Choreography evolution Variation point

behavioral alternative 1in context x

behavioral alternative 2in context y

behavioral alternative 3in context y and context z13/04/17 MarcoAutili- SeminarLectures@GSSI 59

Adopted architectural style

S1 S2

S3

CD1.2 A2A1StandardCommunication(e.g.,request/responsemessages)

AdditionalCommunication(coordinationinformationforcoordinationpurposes)

CD ProtocolCoordinationLayer(CDs)

A ProtocolAdaptationLayer(Adapters)

S BusinessLogicLayer(Services)

S4

CD1.3 CD2.3

A3CD2.1

CD3.1CD4.1 A4

A5


Goal changesChoreography specification changes

• Source: choreography modelers and service providers

• Changes are restricted to the extent of the already specified variation points (quiescent state)

• the modeler can however add/remove behavioral variations, or modify existing ones at run-time

• Restricting to variations points is a reasonable choice since completely altering the specification may “distort” the business-level goal the choreography was originally specified for:

• a complete alteration of the specification naturally requires to re-synthesize the choreography from scratch


Context changes• Source: the dynamically “sensed” choreography context

• At run time, context changes drive the activation/deactivation of variation points, provided that the specified context conditions are exclusive

• Conditional expressions over “facts” that has to be evaluated at run time

• On the practical side, each Call Choreography requires a suitable context evaluator:

• A message context is described in terms of data contained in the messages exchanged among the involved services up to a given point in time.

• An execution context is described by using information about possible computational resources. Thus, in order to “sense” an execution context, dedicated functionalities should be provided by the needed run-time support.

• A domain/application context is characterized by conditions on the surrounding environment, given that dedicated functionalities (e.g., supported by dedicated sensors) are provided to sense it.


Synthesis Process

Choreography Specification

Validation

ChoreographyProjection

Selection

BCGeneration

SFGeneration

AdapterGeneration

BC

Service/ThingDescription

Inventory

ParticipantModel(BPMN2Choreography

Diagram)

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

ChoreographyArchitectureGeneration

BCService/Thing SF A

ChoreographyDeploymentGeneration

ChoreographyArchitectureDescription

ChoreographyDeploymentDescription

CD

OVERALL GOAL provide automatic support to the realization of choreography-based systems by realizing a synthesis process


Synthesis Process (cont’d)


Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory


Diagram)

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL check the choreography realizabilityand its enforceability by the process



Projection of "Tourist Agent" participant


Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory


Diagram)

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL derive a (sub-) BPMN2 Choreography Diagram that contains only

the choreography flows involving the considered participant



Service/Thing specification process


Diagram)


Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

InterfaceSpecification

InterfaceDescription

Interaction ProtocolSpecification

InteractionProtocol

Description

QoSSpecification

QoSDescription

SecuritySpecification

SecurityDescription

Inventory

GOAL querying the Service Inventory in order to select concrete services (or things) that can

play the roles of the choreography participant




Diagram)


Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL generate BCs when the interaction style (e.g., REST) of a selected service (or

thing) is different from SOAP

S1 S2

CD1 CD2

BC1 BC2




Diagram)


Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL generate SFs to filter the services interactions according to the specified

security requirements (e.g., different authentication & authorization attributes)

S1 S2

CD1 CD2

BC1 BC2

SF1 SF2




Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory


Diagram)

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL generate adapters that bridge the gap between the abstract interface and concrete

interface of a selected service (or thing)

S1 S2

BC1 BC2

SF1 SF2

CD1 CD2

A1 A2




Validation


Selection

BCGeneration

SFGeneration

AdapterGeneration

BC


Inventory


Diagram)

SF

A

CDGeneration

CD

BPMN2Choreography

Diagram

Messages XMLSchema

GOAL generate CDs that coordinate the interactions among the selected services (or

things) in order to fulfill the global collaboration prescribed by the choreography specification, in a fully distributed way

S1 S2

BC1 BC2

SF1 SF2

CD1 CD2

A1 A2



Architectural description of the use case

GOAL generate an architectural description of the choreographed system






CD


Synthesis Process

Choreography Deployment Description of the use case






CD

GOAL generate the Choreography Deployment Description


CHOReVOLUTION platformCHOReVOLUTION Front-end provides

1. CHOReVOLUTION Studio

• design a choreography with BPMN2

• guide the generation of the additionalartifacts exploiting the Synthesis Processor

2. CHOReVOLUTION Console

• manage running services and choreographies

• monitor the execution of the choreography

• monitor the resources of the cloudinfrastructure


CHOReVOLUTION platformCHOReVOLUTION Back-end

• Generation of the Concrete Choreography specification and all the required BCs, As, CDs, SFs (Synthesis Processor)

• Deployment, configuration and control of BCs, As, CDs, SFs on the CHOReVOLUTION cloud infrastructure (Enactment Engine)

• Management of authentication and authorization for those services that, at run-time, use different security mechanisms at protocol level (Identity Manager)

• Propagation/synchronization of service/user profiles to/from external resources and provision of managed services (Federation Server)


CHOReVOLUTION platformExecution on the CHOReVOLUTION cloud

• Running different choreographies

• Running different instances of a choreography, each having its own execution states

• A set of virtual machines executing a custom-tailored mix of services and middleware components to serve different parts of the choreography


CHOReVOLUTION Studio


Conclusions

üPut the bases to support dynamic choreography evolution in response of goal and context changes

• Separation of concerns between application, coordination, and adaptation logic

• Adapters as a composition of different EIP depending on a notion of I/O data mappings inference

(Message Filter, Aggregator, Splitter, and Resequencer)

üRelevance of exploiting EIP• Modular adapters• Dynamic evolution• Automatic generation and easier maintenance of adapters’ code


Future research directions

üExtension of the approach to deal with governance issues• Multiple systems belonging to different security

domains/federations governed by different authorities• Usage of different identity attributes that are utilized in their access

control polices

üHow to support dynamic evolution via the automated and on-the-fly synthesis of, e.g., more complex adapters realized by combining additional classes of EIP, e.g.,

• Message Transformation Patterns such as Content Enricher, Content Filter, and Transformer

• Semantic interoperability• Enabling a finer form of adaptation concerning mismatches at the

level of the semantics of the exchanged messages


References• Web Site

http://www.chorevolution.eu

• Twitterhttps://twitter.com/CHOR_eVOLUTION

• Source Code (GIT repositories)https://goo.gl/kQUXgk

• OW2 JIRAhttps://goo.gl/9FxVSj

• Useful text books• Software Engineering, 10th Edition, Ian Sommerville• Web Services & SOA, Principles and Technology, 2nd

Edition, Michael P. Papazoglou


THANK


YOU