CHOReVOLUTION Enablers - WP3 Service Bus, Security and Cloud

Nikolaos Georgantas Inria 1st Project Review Brussels, Feb. 11, 2016

WP3 Overview

Duration: M1 - M30 (all tasks) Effort: 65 PMs Task 3.1: CHOReVOLUTION Service Bus •  Inria, Softeco, Tirasa, UDA

Task 3.2: Secured Choreographies •  THA, Softeco, Tirasa, UDA

Task 3.3: CHOReVOLUTION Cloud •  CEFRIEL, Inria, Softeco, Tirasa, UDA

11 Feb. 2016 2

WP3 Deliverables

!  D3.1: CHOReVOLUTION Service Bus, Security and Cloud - First outcomes (Inria) - M10

•  D3.2: CHOReVOLUTION Service Bus, Security and Cloud - Intermediate outcomes (Tirasa) - M22

•  D3.3: CHOReVOLUTION Service Bus, Security and Cloud - Final outcomes (THA) - M30

11 Feb. 2016 3

From modeling and synthesis to running choreographies

11 Feb. 2016 4

Thing

choreography

mobile sensor

mobile service

REST service

Web service

!

Secure

Dynamic

Heterogeneous

Middleware enablers for running choreographies

CHOReVOLUTION Cloud

CHOReVOLUTION Service Bus

CHOReVOLUTION Security

5 11 Feb. 2016

Secure

Dynamic

Heterogeneous

CHOReVOLUTION Service Bus (VSB)

features •  Flexible, lightweight bus •  BCs employed only when necessary •  Any bus protocol •  Things as first-class entities •  Support for data stream protocols •  Automated BC synthesis •  Evolution support

Leverage •  Rely on principles, results,

lessons learned •  Completely rethink architecture

and implementation

•  Interoperability for choreography peers with heterogeneous middleware protocols

•  Applies the ESB paradigm •  Protocol adaptation with Binding Components (BCs)

6 11 Feb. 2016

VSB architecture

REST service

REST

Web service

SOAP

Thing

CoAP

Security Filter

SOAP

Adapter

SOAP

Coordination Delegate

SOAP

Binding Component

REST

Security Filter

SOAP

SOAP

Binding Component

SOAP CoAP

7 11 Feb. 2016

!

QoS analysis of VSB interactions

•  Interactions among mobile services/Things

•  Asynchronous, event & data-based •  Subject to intermittent connectivity

•  We model response time with two parameters

•  Lifetime of data: validity and buffering by the middleware protocols

•  Connection/disconnection behavior of data receivers

11 Feb. 2016 8

Design-time evaluation of response times

9

!"#!$$ !"#"#$%&'(#%)#*!"#$%&'%(#%

)*+),"&$-&#(% ./.(-)%'#" ,01))%!""

./.(-)%'#"%

,01))%#

!"#$%"&'#(%

%& !"#"#$%&'(#%)#*

!!""

!# )

!$%

"&

"'

"!""

"#

!!

!"

!#

"!

""

"$

#$%!"#$%"&'#(%

!

!"#$%&'%(#

)*+),"&$-&#(

!

"

! "

!

!"#!$$ !"#"#$%&'(#%)#*

! !"!#$%

!""#$%$&'(

% $%$&'(

"## "&'$()*+!"!#$%

!!""

" #!""

!!""

!# !

$!""

$#

!#

Figure 2.17: ON/OFF queueing center

the following implies:

�o↵ =

(0, during TON intervals1

TON, during TOFF intervals

(2.16)

Hence, during TON, the �off

flow is Poisson with exponentially distributed parameter TON. The average�o↵ rate for both intervals is given by:

�o↵ =TOFF

TON + TOFF0 +

TON

TON + TOFF

1

TON

=1

TON + TOFF(2.17)

Note that the average �o↵ flow is not Poisson: during the TOFF interval no new off event is allowed toarrive. ⌅

With respect to two-class service centers, the ON/OFF queueing center presents the following: i) ser-vice times Dv and Do↵ are exponential, ii) the overall arrival flow �v is Poisson, but �o↵ is not, andiii) the off class has preemptive priority over class v, namely, if an off event arrives and finds a v eventin service, the v event is preempted so the off event can be served immediately. Given the previousobservations, the following theorem exploits the PASTA property, Priority queueing systems and Little’slaw in order to evaluate our qon/o↵ .

Theorem 2. The average delay Ron/off

s for the qon/o↵ is given by:

Ron/off

s =

T

2OFF

TON + TOFF+ Dv

TON + TOFFTON

1 � �vDvTON + TOFF

TON

(2.18)

Proof. In our queueing center, the off class has preemptive priority over the class v. For such a model,a new arriving off event has to wait for time:

Ro↵ = Do↵ + Qo↵Do↵ (2.19)

where Qo↵ is the number of the off events present in the queue. The off event has priority over the vevents and thus, it has to wait only for preceding off events (if any). On the other hand, a new arrivingv event has to wait for time

Rv = Dv + QvDv + Qpreo↵ Do↵ + Qpost

o↵ Do↵ (2.20)

In this case, despite the fact that a new v event has arrived, there is always the possibility that an offevent can arrive. Thus, an event v must wait for any classes off and v events that are already in thequeue when it arrives, and any class off events that arrive during its residence period. Let Qpre

o↵ be theaverage number of off events found in the queue when the v event arrived and Qpost

o↵ be the average

CHOReVOLUTIONH2020-644178 27

11 Feb. 2016

CHOReVOLUTION Security

Ensures security of choreography interactions

•  Flexible security management based on identity roles of choreography peers

•  Federation of heterogeneous security mechanisms

•  Applies the above via flexible proxying mechanism for choreography peers

10 11 Feb. 2016

Security workflow

Client Service

Federation Server

Security Filter (SF)

Identity Manager

Provide clients and services identity information (credentials, attributes, policies)

Client request with credentials

Validate Client credentials Validate Client authorization

Map Client credentials with credentials required by Service

Forward request to Service with new credentials

Policy decision

Policy enforcement

11 11 Feb. 2016

CHOReVOLUTION Cloud

features •  Multiple heterogeneous cloud underlays,

unifying API •  Dynamic on-demand resource

management for QoS and evolution •  Leverages built-in features of cloud

underlays to best serve choreographies •  Top-down changes in the choreography

structure and requirements •  Bottom-up resource scaling for runtime

evolving needs

Leverage •  Reuse the Cloud Enactment

Engine •  Extend it to support dynamicity,

auto-scaling and run-time control for choreography adaptation

Provision of adequate, elastic resources to choreographies

12 11 Feb. 2016

Cloud architecture

Underlying  Cloud  Layer  (OpenStack,  AWS,  Azure,  Vcloud,  …)  

Cloud  API  (off-­‐the-­‐shelf)  

The  cloud  API  provides  features  

for  resource  control    

VM   VM   VM   VM   VM  

CHOReVOLUTION  Enactment  Engine  

Create/release  VM  Clone/snapshot/restart  

Provisioning  and  automaJon  engine   Cloud  control  engine  

VM  configuraJon  

Run-­‐Jme  API  

VMs  hosJng  the  choreography   RunJme  requests  from  monitoring  of  services  and  VMs  (scale,  replace,  balance,  …)  

Deployment  &  control  API  

Upload  choreography    Upload  deployable  services  

REDIS  

Choreography  status  persistence  

13 11 Feb. 2016

Control  funcJons  (create/stop/start  VM,  etc…)  

OpenStack setup for CHOReVOLUTION Cloud

OpenStack  private  cloud  infrastructure  deployed  at  CEFRIEL  premises  

14 11 Feb. 2016

Summing up

Powerful middleware enablers for heterogeneous, secure, dynamic choreographies

Next steps •  Integrate with the modeling and synthesis enablers

•  Automated BC and SF synthesis •  Full cloud deployment of CHOReVOLUTION artifacts

•  Runtime QoS analysis and assurance

•  At application, middleware and resource layers •  Adaptation for evolving choreographies

15 11 Feb. 2016

Thank you