ModelDriven Dependability Analysis of Web Services

1
Model-Driven Dependability Analysis of Web
Services

• Apostolos Zarras
• Computer Science Department
• University of Ioannina, Greece
• http//www.cs.uoi.gr/zarras
• in Collaboration with Panos Vassiliadis and
  Valerie Issarny.

2
Context

• Web Services Architecture.
• Software entities over the Web communicating
  through SOAP messages.
• They provide ports, of a specific port type,
  which defines a set of operations.
• WSDL for the specification for basic Web
  Services.
• BPEL, WSFL for the specification of composite Web
  Services.

3
BPEL

• Workflow-like specifications.
• Composite Web service ? BPEL process.
• BPEL process consists of
• Partners, i.e., basic Web services.
• Basic activities.
• Invoking partner operations (invoke activities).
• Reception/sending of SOAP messages (receive,
  reply activities).
• Structured activities, consisting of other
  activities that execute
• Sequentially (sequence activities).
• Concurrently (flow activities).
• Repeatedly (while activities).
• Upon an event (switch activities).
• Upon a condition (pick activities).

4
Current Status

• Systematic composition of WSs (signature matching
  and mapping).
• Casati et al. in CAISE01, Florescu et al. in
  WWW02,
• Yang et al. in CAISE02, Medjahed et al. in
  VLDB vol. 12
• Systematic selection of WSs, based on quality
  criteria.
• Zeng et al. in WWW03
• Quality analysis (reliability, availability,
  performance, etc.) of conventional composite
  systems.
• Zarras et al. in ASE01 and in LNCS vol. 2677,
• Majzik et al. in LNCS vol. 2677,Rodrigues et
  al. in WADS03

5
Objective

• A principled methodology for the dependability
  analysis of composite Web services.
• Map BPEL specs in UML models.
• Extend the UML models with properties for the
  dependability analysis.
• Generate dependability analysis models that serve
  as input to traditional analysis techniques.
• Block Diagrams (BDs).
• Fault Trees (not addressed but similar to BDs)
• Markov Models.

6
Map BPEL 2 UML
7
Properties for Dependability Analysis
8
Example
9
From UML to Block Diagrams

• How do we model composite Web service with BDs?
• A BD graphically represents a constrain for
  correctly providing a Web Service.
• It consists of
• Blocks representing partners.
• Serial connections between blocks.
• Parallel connections between blocks that
  represent partners, which constitute a redundancy
  schema.

10
Example
if approver is fault tolerant with no-partners
2 and no-failures 1
11
From UML to Markov

• How can we model composite Web Services using
  Markov ???
• A Markov model for a composite Web Service ws is
  a set of transitions between wss states.
• A state represents a situation where either the
  service is correctly provided, or not (i.e. a
  death state).
• A state is a composition of sub-states
  representing the situation of
• Each partner.
• Each basic activity.
• Structured activities are used to determine the
  transitions.

12
From UML to Markov

• The state of a partner depends on the kind of
  faults of the partner and its redundancy
  properties.
• e.g., a redundancy schema with 2 partners may be
  in states where both are operational, 1 is
  failed, both are failed.
• The state of a basic activity depends on whether
  it is embedded in a while activity or not.
• In the former case the activity may be inactive,
  active, complete, or failed.
• In the later case the activity is reactivated
  more than once.
• Different kinds of transitions modeling
• Partner failures.
• Partner recovery.
• Activity activation.
• Activity completion
• Activity failure (caused by a partner failure).

13
From UML to Markov

• In our approach we DO NOT generate states and
  transitions because we can do something easier
  !!!
• We can generate input for Johnsons algorithm
  Johnson, 8th AIAA IEEE Digital Avionics Systems
  Conf., which then generates complete Markov
  models.

14
From UML to Markov

• Definition of the range of states that constitute
  the Markov model.
• We generate a tuple of integer variables, each
  one representing the range of situations for a
  partner or a basic activity.

if the all partners are not fault tolerant and
have permanent or transient faults
space ( customer 0..1, assessor 0..1,
approver 0..1, rcvCustomer 0..3, invAssessor
0..3, invApprover 0..3, rplCustomer 0..3 )
15
From UML to Markov

• Definition of a death-state constraint on the
  space variables, which evaluates to true in
  states where the composite service is failed.
• We generate a logical expression, consisting of
  the disjunction of Boolean expressions, involving
  the state range variables that represent the
  situation of the services activities.

if the activities are not embedded in while
activities
deathif ( rcvCustomer3 OR invAssessor3 OR
invApprover3 OR rplCustomer3 )
16
From UML to Markov

• Definition of a set of transition rules.
• A rule has a conditional statement, defined on
  the space variables. It identifies a set of
  source states with common features.
• if approver 0 and invApprover 1 then
• For all these source states there should be
  transitions to corresponding target states that
  also have common features.
• tranto
• (customer, assessor, approver1,
• rcvCustomer, invAssessor, invApprover2,
  rplCustomer) by
• approver_failure_rate
• endif
• These transitions are generated by Johnsons
  algorithm.

17
From UML to Markov

• We generate transition rules for
• Partner failure.
• Partner recovery.
• Activity activation.
• Activity completion.
• Activity failure.

18
Assessment

• Results showed that
• BDs are easier to specify and faster to compute.
• Markov are more precise but complex to specify
  and time consuming.
• In both cases, we alleviate the problem of the
  specification complexity.

19
Conclusion

• A methodology for the dependability analysis of
  Web services.
• Mapping BPEL to UML models.
• Introduce dependability properties in the models.
• Generate BDs and Markov models.
• Future goals
• A service that applies the methodology at
  runtime.
• Emphasize on other qualities.
• Identify dependability measures wrt mobility.
• Identify properties characterizing mobility.
• Identify techniques that assess the impact of
  mobility in the overall dependability of
  composite WSs.
• Identify techniques that guarantee dependability
  in the face of mobility.