CHOReVOLUTION WP3 Enablers

  • View
    143

  • Download
    0

Embed Size (px)

Text of CHOReVOLUTION WP3 Enablers

  • 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 averageo rate for both intervals is given by:

    o =TOFF

    TON + TOFF0 +

    TONTON + 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 Littleslaw in order to evaluate our qon/o .

    Theorem 2. The average delay Ron/offs for the qon/o is given by:

    Ron/offs =

    T

    2OFF

    TON + TOFF+ Dv

    TON + TOFFTON

    1 vDv TON + TOFFTON

    (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 + QoDo (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 + Q

    posto 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 Qpreo be theaverage number of off events found in the queue when the v event arrived and Qposto 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