QoS management prototype in WS-

DIAMONDLAAS-CNRS

Paris meeting11-12 October 2007

2

• The constituting modules: • Summary

• Details:• Monitoring

• Measurement

• Diagnosis & Planning

• Repair

• Relaxing assumption for:• Summary

• Details:• Local vs global properties

• QoS Manager deployment

Outline

•Provided functions

•Internal architecture

•Associated approach

3

Summary (1/2):characteristics

• QoS degradations are the handled faults. • Their detection is based on statiscal analysis of logged

QoS parameters. • Two models are used: chronicles, and Markovian models.

• Monitoring & repair based on :• Intercepting communication messages between

providers and requesters, • Meta-level communication extending message headers

by metadata describing QoS information.

• Repair by reconfiguration• Is based on class-level substitution and duplication,• Acts by re-routing requests to different services

4

Summary (2/2): Two possible levels for implementation• Level1: Management at the SOAP level• High level programming based on

• Container-provided handlers for interception and standard XML parsing libraries

• Reflexive programming libraries for Java

• Reduced access to information: SOAP envelope• No information about IP address (requester,provider)• Needs manageable WS

• Appropriate for stateless WS but needs more assumption and cooperation to manage statefull WS, asynchronous interaction and global repair

• Level2: Management at the HTTP level• Augmented access to routing-information:

• May handle sessions, may handle asynchronous interactions, useful for stateful services

• Low level programming, Socket-based • HHTP proxies, handling of HTML messages(including SOAP part)

5

Monitoring (1/1):The implemented module• Provided functions: Computes and stores the observed QoS

parameter values. • Internal architecture and implementation: Two interceptors and a

log database: • Requester Side Interceptor:

• Implemented as a handler of the web service requester• Computes QoS values involved in the diagnosis process from the requester

side.• Stores these values in database.

• Provider Side Interceptor: • Implemented as a handler of the web service container• Computes QoS values involved in the diagnosis process from the provider

side• Stores these values in the log database.

• The log database: • Implementation technologies:

• Axis Handlers for the interceptors• MySQL5 for the log database.

6

Measurement (1/5): The approach • Main goal of measurement: detection of QoS

degradation• Approach based on identification of temporal

chronicles as QoS degradation symptoms• Some experimented temporal chronicles:

• Example 1: N “consecutive” Texec greater than the average time : • Texeci>(AVGTexec+delay)

• Example 2: N “consecutive” accelerations of Texeci: (without deceleration between Texeci)• TexecN>TexecN-1> … >Texec2>Texec1

• Example 3: Texec increases abruptly:• Texec2 >> Texec1

7

AVG

AVG+delay

Acceptable values

Measurement (2/5): Chronicles examples (1/3)

Pre-computed average (AVG should be deduced from large scale experiments, AGV=Constant)

Chronicle1 is triggered with N=3: t1,t2,t3>AVG+delay

delay

Chronicle1 not triggered with N=3

Time

Texec

t1t2

t3

- Legend

Monitored Texec

8

AVG

AVG+delay

Acceptable values

Measurement (3/5): Chronicles examples (2/3)

On the fly-computed average (AVG should be deduced from current QoS parameter values)

Chronicle1 is triggered with N=3: t1,t2,t3>AVG+delay

delay

Chronicle1 not triggered with N=3

Time

Texec

t1

t2 t3

- Legend

Monitored TexecReal time computed AVG value

Real time computed AVG+delay value

9

Measurement (4/5): Chronicles examples (3/3)

• Chronicle associated with example 1:• Messages:

• message TexecViolation • message TexecOK

• Triggering time condition: • TexecViolation: Texec>(AVGTexec+delay)• TexecOK: Texec<=(AVGTexec+delay)

• Events: • Event(TexecViolation, t0)• Event(TexecViolation, t1)• Event(TexecViolation, t2)

• No Event of type TexecOK between t0 and t2• NoEvent(TexecOK,(t0,t2))

• Temporal constraints between instants : • t0<t1<t2

10

Measurement (5/5):The implemented module

• Provided functions: • Extracts data logged by the monitoring module in the

Log database• Detects misbehaviors (QoS degradation) • Approach based on statistical functions and elementary

temporal chronicles detection • Sends alarms to the diagnosis and repair planning

module.

• Internal architecture and implementation: a single web service

11

Diagnosis & planning (1/2): The approaches• Focuses on a local diagnosis related to a single service• Main goal: Identify QoS degradation source

• Discriminating faults of the communication and processing levels

• Approach based on reasoning about execution and response times• Degradation(response time) & not Degradation (execution time)

==> communication level problem• Degradation(response time) & Degradation (execution time)

==> processing level problem

• Considered plans:• Communication problem: service substitution• Processing problem: service duplication

12

Diagnosis & planning (2/2): The implemented module

•Provided functions:• A diagnosis by reasoning about the alarms received

from the measurement module

• Generates the repair plan to be performed by the reconfiguration execution module

• Internal architecture and implementation: a single web service

13

Repair(1/2):The approach

• Main goal: eliminate source of detected QoS degradation

• Approach based on architectural reconfiguration targeting class-level repair

• Considered elementary reconfiguration actions:• Service substitution• Service duplication

14

Repair(2/2): The implemented module• Provided functions:

• Performs architectural reconfiguration using dynamically bound connectors between requesters and providers• Service substitution based on 1 to 1 equivalence specified

in a predefined list

• Internal architecture and implementation: • Two web services:

• One for the automated dynamic code generation of the new connector

• The second redeploys the new connector

• Implementation technologies:• Java Reflection, Java Runtime Compilation, WSDL Runtime

Compilation, XML Parsing

15

Validation & experiments• First validation :

• Prototype acting on a simple web service implementing arithmetic functions.

• Delays are added in the web service itself to trigger QoS degradation • Current validation: FoodShop

• Windows Version provided by POLIMI• The FoodShop simulator has been ported on Linux and deployed

successfully on Grid5000 with provider-side interceptors and connectors• Current possible invocations through the SOAP User Interface• A non-interactive Java client is required to deal with QoS monitoring and

measurement at the requester-side• Next: Fault Injector of POLIMI may be used at the SOAP level for

triggering QoS degradation• Experiments:

• Will be conducted on the Grid5000 for hundreds of requests to extract significant chronicles for the FoodShop example under critical utilization conditions.

• We will rely on first developments and experiments with another toy example of collaborative activities.

Relaxing assumptions on local and global properties of monitoring, measurement,

diagnosis & planning and repair

WS-Diamond reviewLAAS-CNRS

September 2007

17

Summary for Relaxing assumption for QoS

• Only non orchestrated services• Black box assumptions:

• Only WSDL is known• Messages are intercepted,

extended, rerouted• Deployment assumptions

• Simple services: N requester, 1 provider

• Class-level, Local diagnosis & repair with simple model

• Experiments:• Scalability on Grid5000• Simple application• SOAP level handling

• Study of integration with process-level functional self-healing modules

• All kind of services• Black box assumptions:

• WSDL is known• Global knowledge on the

interdependencies between services• Messages are intercepted, extended,

rerouted• Deployment assumptions

• Complex services• Class-level, Global diagnosis & repair

with formal models (chronicles, Markov)

• Experiments:

• Foodhop application

• HTTP&SOAP level handling

• Implementing integration with process-level functional self-healing modules

18

Architecture (1/4):

• Monitoring• Distributed & Local

• Storage: 1DB/Provider & all its Requesters

• Next: • Distributed & global

Req1

Req2

WS1

WS2

BD1

BD2

I I

II I

QoS Manager1 QoS Manager2

WS1 WS2

Asynchronous (one-way)

QoS Manager1

QoS Manager2BD

Global Monitoring

T1

T2’

T2

T1’

Local Monitoring

19

Architecture (2/4):

• Measurement• Distributed & Local

• Local Measurement: • We consider only QoS parameters related to single request/response

•Next: •Distributed & global

Req1

Req2

WS1

WS2

BD1

BD2

I I

II I

Measurement1

Measurement2

WS1 WS2

Asynchronous (one-way)

QoS Manager1

QoS Manager2BD

Global Measurement

T1

T2’

T2

T1’

Local Measurement

• Global Measurement: • We consider QoS parameters involving several requests/responses in the same work flow:

•Response time= T2’-T1, Execution time= T1’-T2, etc…

Measurement

20

Architecture (3/4):

• Diagnosis & Repair Planning• Distributed • Local• Next:

• Distributed global

• Why Global Diagnosis?• Example : interlocked web services

Req1 WS1 WS2

Tresp1 Tresp2

•(Tresp1>>Tresp1Avg) && (Tresp2 >> Tresp2Avg) ==> Error detection•If Diag_Local(WS1)==> WS1 QoS degradation

• Substitute (WS1,WS1’) [WS1’equivalent to WS1]•If Diag_Global(WS1,WS2)==> WS2 QoS degradation

• Local Repair: Substitute(WS1,WS1”) [Where: WS1” Not_Connected_to WS2]• Global Repair: Substitute(WS2,WS2’) [Where: WS2’equivalent to WS2]

Tresp

2

Tresp

1Req1 WS1 WS2

Sequence diagram

21

Architecture (4/4):

• Repair Enforcement• Distributed • Local (1 ReconfMgr/provider and all its requesters)• Next:

• Global : Enable coordination between reconfiguration actions in order to avoid looping and to cooperate simultaneous reconfiguration process.

• Replace (ws1 U ws2) by (ws3 u ws4) where • (ws1 U ws2) == (ws3 U ws4) • ws1 != ws3 and ws2 != ws4

Req1

WS1

WS2

Fg

hi

Req1

WS3

WS4

Fgh

i

22

Possible applications of QoS management to the FoodShop

QoS Manager1

QoS Manager4

QoS Manager3

QoS Manager2

Client

Shop

BPEL

WH

BPEL

SH-BPEL

LocalShop WS

Local Sup2 WS

Local Sup1 WS

Local WH WS

Sup2

BPEL

Sup1

BPEL

Report “Integration and consistency

problems”: is being completed

Assumption on QoS Manager deployment

WS-Diamond reviewLAAS-CNRS

September 2007

24

Assumption on QoS Manager deployment

(1/4)• First case: Pair of WS-Requester (WS-R)

and WS-Provider (WS-P) without BPEL on the both sides. (Requester may be a simple client…)• Deployment possibilities:

• Modifying requester code to send requests to the FS (Require access to the requester code), OR

• Placing the FS in the URL of the initial WS-P (Require access privileges to the Provider-side to deploy directory)

WS-R WS-P

25

Assumption on QoS Manager deployment

(2/4)• Second case: With PBEL on the left side (Requester-

side)

• Loss of communication-related errors, no request-side interception for standard BPEL. • May be possible for SH-BPEL which may provide QoS values of

requester-side.

• Deployment possibilities:• Modifying BPEL code to send requests to the FS (Require

access to BPEL code), OR

• Placing the FS in the URL of the initial WS-P (Require access privileges to the Provider-side to deploy directory)

BPEL-R WS-P

26

Assumption on QoS Manager deployment

(3/4)• Third case: With PBEL on the right side

(Provider-side)

• Monitoring is Ok.

• Repair by class-level substitution is OK: • We can maintain the session information which is

saved in the request SOAP Header (RelatesTo, MessageID, etc.)

• Deployment possibilities:• Modifying WS-R code to send requests to the FS

(Require access to WS-R code)

WS-R BPEL-P

27

Assumption on QoS Manager deployment

(4/4)• Fourth case: With PBEL on the both sides

• Loss of communication-related errors, no request-side interception for standard BPEL. • May be possible for SH-BPEL which may provide QoS values

of requester-side.

• Repair by class-level substitution is OK: • We can maintain the session information which is saved in

the request SOAP Header (RelatesTo, MessageID, etc.)

• Deployment possibilities:• Modifying BPEL code to send requests to the FS (Require

access to BPEL code)

BPEL-R BPEL-P