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