QoS global management & integration with functional

managementLAAS-CNRS

Amsterdam meeting19-21 November 2007

• Local management vs. Global management

• Stateless vs. Stateful service management

• Integration of QoS Management and Functional Management

Outline

Local vs. Global (1/4):

• Monitoring & Measurement• Local

• 1Log / Provider & all its Requesters

• Global: • 1Log / workflow

BD1

BD2

WS1 WS2

Asynchronous (one-way)

QoS Manager1

QoS Manager2BD

T1

T2’

T2

T1’WS1 WS2

QoS Manager1

QoS Manager2

T1

T2’

T2

T1’

Asynchronous (one-way)

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

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

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

Local vs. Global (2/4):

• Diagnosis & Repair Planning

Req1 WS1 WS2

Tresp1 Tresp2

Diagnosis-WS1: •(Tresp1>>Tresp1Avg) ==> WS1 QoS degradation

Repair Planning-WS1: •Substitute (WS1,WS1’) [WS1’equivalent to WS1]

Tresp

2

Tresp

1Req1 WS1 WS2

Sequence diagram

• Local: • We consider only Diagnosis of QoS parameter values related to single request/response

Example : interlocked web services

Diagnosis-WS2:•(Tresp2 >> Tresp2Avg) ==> WS2 QoS degradation

Repair Planning-WS2:•Substitute (WS2,WS2’) [WS2’equivalent to WS2]

Local vs. Global (3/4):

• Diagnosis & Repair Planning

Diagnosis-WS1&&WS2: •(Tresp1>>Tresp1Avg) && (Tresp2 >> Tresp2Avg) ==> Error detection

QoS degradation on Interlocked services: WS1 and WS2==> WS2 QoS degradation (WS1 degradation is due to degradation propagation)

Repair Planning-WS1&&WS2: • Substitute(WS2,WS2’) [Where: WS2’equivalent to WS2]

• Global: • We consider 1 Diagnoser and 1 Repair planner for all service in workflow

Chronicles examples for Global Diagnosis

• Messages: • message Tresp1Violation• message Tresp2Violation• message Tresp1OK • message Tresp2OK

• Triggering time condition: • Tresp1Violation : Tresp1>(AVGTresp1+delay)• Tresp2Violation : Tresp2>(AVGTresp2+delay)• Tresp1OK : Tresp1<=(AVGTresp1+delay) • Tresp2OK : Tresp2<=(AVGTresp2+delay)

• Events: • Event(Tresp1Violation, t0)• Event(Tresp2Violation, t1)

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

• Temporal constraints between instants : • t0<t1

Stateless/Stateful (1/2)

• Stateless: does not record previous interactions and each interaction request has to be handled based entirely on information that comes with it.

• Stateful: remembers preceding events in a given sequence of interactions with another service

Stateless/Stateful (2/2)

• BPEL manages states thanks to additional information inserted in the SOAP Header.

• Issues:• When rerouting request, we have to reroute

Header data responsible of managing states (MessageId, RelatedTo, et …)

• When rerouting requests to a new provider, we loss the state made with the pervious provider

SH-BPEL & QoS Manager: Integration

• Possible architectural integrations of the functional healing prototype (the SH-BPEL) and the QoS manager prototype

• Objective:• The simultaneously management of functional

faults and QoS degradation.

• Tow integration types:• Passive: No interactions between them• Active: Exchanging requests to coordinate

healing

QoS Manager reconfiguration assumptions• QoS Manager repair steps

Time

T1Start class

level reconfiguration

T2Start

redeployment

T3Terminate

redeployment

Transitory phase

Permanent phase

T0QoS Degradation

detection

T4Terminate class

level reconfiguration

During this phase, the provider is temporarily Unavailable!!

Passive Integration: I1Transitory phase managed at the behavioral level

SH-BPEL and QoS manager are connected but do not interact directly by exchanging requests (no modifications in API

Functional healing

(including Shop executed within

SH-BPEL)

Client(Shop Client)

QoS Manager(including its own monitoring, diag and class-level substitution)

LocalShop1 Web Service

Class-level substitution

LocalShop2 Web Service

TransitoryLocalShop3 Web Service

Instance-level substitution

Passive Integration: I2Transitory phase managed at the QoS manager itself

SH-BPEL and QoS manager are connected but do not interact directly by exchanging requests (no modifications in API

Functional healing

(including Shop executed within

SH-BPEL)

Client(Shop Client)

QoS Manager(including its own monitoring, diag and class-level substitution)

LocalShop1 Web Service

Class-level substitution

LocalShop2 Web Service

TransitoryLocalShop3 Web Service

Instance-level substitution

Active Integration: I3QoS Manager and SH-BPEL cooperate to exchange information about current repair plan or to ask for reconfiguration.

The QoS Manager asks for instance level reconfiguration during transitory phase The functional level modules ask for class-level repair in case of permanent functional fault

Functional healing

(including Shop executed within

SH-BPEL)

Client(Shop Client)

QoS Manager(including its own monitoring, diag and class-level substitution)

LocalShop1 Web Service

Class-level substitution

LocalShop2 Web Service

TransitoryLocalShop3 Web Service

Instance-level substitution

Permanent functional fault

Manage transitory phase