CHOReVOLUTION at GSSI April-2017

Tools for Software
Architecture
Seminar Lectures
GSSI - Center for Advanced Studies
11-12 Apr. 2017 – L’AQUILA (IT)
Marco Autili
University 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 Marco Autili - Seminar Lectures @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 Demo

Outline
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
Abstraction
Modularity for
Reuse & 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 engineering
Software 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
Design
patterns
Architectural
patterns
Application
frameworks
Software product
lines
Application
system integration
ERP systems
Systems of
systems
Configurable
application systems
Legacy system
wrapping
Component-based
software engineering
Model-driven
engineering
Service-oriented
systems
Aspect-oriented
software engineering
Program
generators
Program
libraries

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 provision
of the service is independent of the application using
the service
• Service providers can develop specialized services and
offer 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 cooperate
and 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
Service
registry
Service
requestor
Service
provider
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-Policy
It 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

Outline

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, 201513/04/17 Marco Autili - Seminar Lectures @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 users
different environments different stakeholders
fully connected
fully connected
• Dynamism
• Heterogeneity
• New value added services
e.g., route guidance, speed advisory,
parking availability, POI suggestions13/04/17 Marco Autili - Seminar Lectures @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 support
Building 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
• ... ...

Outline

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 Choreography
Diagrams
Model
BPMN2 Specification - http://www.omg.org/spec/BPMN/2.0/13/04/17 Marco Autili - Seminar Lectures @GSSI 41

inventory contains services/things
published by providers, e.g.,
- transportation companies
- airport retailers
Model
Inventory

• Out of the specified business goal, and
• the set of services available in the
inventory ...
ime Synthesis time
3
s
r
Software
engineer
End users
CHOReOSynt
Coordination
delegates
Enactment
engine
Service providers
Model refi
nement
Model trans
formation
2
Execution time
4
1
5
1
6
Running choreography
Cloud
middleware
Publish
Register
Standard communication (I/O messages)
Additional communication (coordination informa
Registry
Services and things
1
5
ime Synthesis time
3
s
r
Software
engineer
End users
CHOReOSynt
Coordination
delegates
Enactment
engine
Service providers
Model refi
nement
Model trans
formation
2
Execution time
4
1
5
1
6
Running choreography
Cloud
middleware
Publish
Register
Additional communication (coordination information)
Registry
Services and things
1
5
erview of automatic choreography synthesis, using a scenario involving the coordination of business services,
s, and stakeholders from air transportation, customer relationship management, and intelligent transportation.
eb Services Description Language; BPEL stands for Business Process Execution Language.
Synthesis
Processor
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
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 specification’s quality.
Step 2. MagicDraw exports the mod-
Services Description Langu
w3.org/TR/wsdl). To desc
interaction behavior, BPE
Process Execution Langu
fies the flow of messages
with the environment. T
also contains the registrat
interested in exploiting th
raphy through their mobil
Design time Synthesis time
3
Business
manager
Software
engineer
End users
CHOReOSynt
Coordination
delegates
Enactment
engine
Service providers
Domain
expert
Choreography
diagram
Model refi
nement
Model trans
formation
2
1
Execution time
4
1
5
1
6
Running choreo
Cloud
middlewar
Publish
Register
Additional communication (coordination
Registry
Services and things
1
5
FIGURE 2. An overview of automatic choreography synthesis, using a scenario involving the coordination of business s
thing-based services, and stakeholders from air transportation, customer relationship management, and intelligent transp
WSDL stands for Web Services Description Language; BPEL stands for Business Process Execution Language.
Choreography
developer
Synthesis Processor
automatically produces (if
possible) a choreography-
based application achieving
the specified goal
Synthesis phaseModelling phase
CHOReVOLUTION
Cloud Infrastructure
Model
Inventory

BPMN2 Choreography Diagrams
Prosumer 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 Marco Autili - Seminar Lectures @GSSI

A Use Case in the Smart Tourism Domain
We 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 synthetised
choreography 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
S1
S2
S4
S3
Existing services selected as
good candidates to realize the
required business logic
Distributed Protocol Coordination Layer
Goal specification
S1
S2
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?
Assumption
BPMN2 Choreography Diagrams
• A choreography-based specification of the system to be realized
Our solution
Automated 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
Focus
Automatically realizing a choreography by reusing and suitably coordinating third-
party services

The In-store Marketing and Sale
Parallel flows
- fork
- join
Alternative branches
- 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
Task in BPMN2
- atomic activity
- two participant roles (one is initiating)
- XML Schema used internally, e.g.,
for discovery purposes

CD2
CD4CD3
CD1
Task1
R1 ––m1à R2
Task2
R3 ––m2à R4
State machine based specification
S4: R4S3: R3
S1: R1 S2: R2
May
I?
May
I? Yes Yes
YesNo
No
No
R1 ––m1à R2
Yes No
m1 m2
Standard Communication
(I/O Messages)
Additional Communication
(Coordination Information)
CDi
Coordination Delegate
(Service Proxy)
Enforcing choreography realizability

CD2
CD4CD3
CD1
Enforcing choreography realizability
S4: R4S3: R3
S1: R1 S2: R2
May I?
May I?
Yes Yes
YesNo
No
No
Yes No
m1 m2
Standard
Communication
(I/O Messages)
CDi
(Service Proxy)

Choreography adaptation
Problem
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 issues

CD2
CD4CD3
CD1
Enforcing service-role bindings
S4: R4S3: R3
S1: R1
S2: R2
May I?
May I?
Yes Yes
YesNo
No
No
Yes No
m1 m2
Standard
Communication
(I/O Messages)
CDi
(Service Proxy)
A
Adapter
A
Marco Autili - Seminar Lectures @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 A2A1
Standard
Communication (e.g.,
request/response
messages)
Additional
Communication
(coordination
information
for coordination
purposes)
CD Protocol Coordination Layer
(CDs)
A
Protocol Adaptation Layer
(Adapters)
S
Business Logic Layer
(Services)
S4
CD1.3 CD2.3
A3CD2.1
CD3.1
CD4.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
• 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

Variation point
behavioral alternative 1
in context x
in context y
in context y and context z13/04/17 Marco Autili - Seminar Lectures @GSSI 59

Adopted architectural style
S1 S2
S3
CD1.2 A2A1
Standard
Communication (e.g.,
request/response
messages)
Additional
Communication
(coordination
information
for coordination
purposes)
CD Protocol Coordination Layer
(CDs)
A
Protocol Adaptation Layer
(Adapters)
S
Business Logic Layer
(Services)
S4
CD1.3 CD2.3
A3CD2.1
CD3.1
CD4.1 A4
A5

Goal changes
Choreography 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.

Outline

Synthesis Process
Choreography Specification
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
Participant Model
(BPMN2 Choreography
Diagram)
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
Choreography
Architecture Generation
BCService/Thing SF A
Choreography
Deployment Generation
Choreography
Architecture
Description
Choreography
Deployment
Description
CD
OVERALL GOAL provide automatic support to the
realization of choreography-based systems by
realizing a synthesis process

Synthesis Process (cont’d)
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
Participant Model
(BPMN2 Choreography
Diagram)
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
GOAL check the choreography realizability
and its enforceability by the process

Projection of "Tourist Agent" participant
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
Participant Model
(BPMN2 Choreography
Diagram)
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
GOAL derive a (sub-) BPMN2
Choreography Diagram that contains only
the choreography flows involving the
considered participant

Service/Thing specification process
Participant Model
(BPMN2 Choreography
Diagram)
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
Interface
Specification
Interface
Description
Interaction Protocol
Specification
Interaction
Protocol
Description
QoS
Specification
QoS
Description
Security
Specification
Security
Description
Inventory
GOAL querying the Service Inventory in order
to select concrete services (or things) that can
play the roles of the choreography participant

Participant Model
(BPMN2 Choreography
Diagram)
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
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

Participant Model
(BPMN2 Choreography
Diagram)
Validation
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
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
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
Participant Model
(BPMN2 Choreography
Diagram)
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
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
Choreography
Projection
Selection
BC Generation
SF Generation
Adapter
Generation
BC
Service/Thing
Description
Inventory
Participant Model
(BPMN2 Choreography
Diagram)
SF
A
CD Generation
CD
BPMN2
Choreography
Diagram
Messages XML
Schema
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
Choreography
Choreography
Choreography
Architecture
Description
Choreography
Deployment
Description
CD

Synthesis Process
Choreography Deployment Description of the use case
Choreography
Choreography
Choreography
Architecture
Description
Choreography
Deployment
Description
CD
GOAL generate the Choreography Deployment
Description

Outline

CHOReVOLUTION platform
CHOReVOLUTION Front-end provides
1. CHOReVOLUTION Studio
• design a choreography with BPMN2
• guide the generation of the additional
artifacts exploiting the Synthesis Processor
2. CHOReVOLUTION Console
• manage running services and
choreographies
• monitor the execution of the choreography
• monitor the resources of the cloud
infrastructure

CHOReVOLUTION 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)

Execution 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

Outline

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
• Twitter
https://twitter.com/CHOR_eVOLUTION
• Source Code (GIT repositories)
https://goo.gl/kQUXgk
• OW2 JIRA
https://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

CHOReVOLUTION at GSSI April-2017

Recommended

Recommended

More Related Content

Similar to CHOReVOLUTION at GSSI April-2017

Similar to CHOReVOLUTION at GSSI April-2017 (20)

More from CHOReVOLUTION

More from CHOReVOLUTION (13)

Recently uploaded

Recently uploaded (20)

CHOReVOLUTION at GSSI April-2017