Model-Driven 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 ofoperations. • 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 CAISE’01], [Florescu et al. in WWW’02], [Yang et al. in CAISE’02], [Medjahed et al. in VLDB vol. 12] … • Systematic selection of WSs, based on quality criteria. [Zeng et al. in WWW’03] • Qualityanalysis (reliability, availability, performance, etc.) of conventional composite systems. [Zarras et al. in ASE’01 and in LNCS vol. 2677], [Majzik et al. in LNCS vol. 2677],[Rodrigues et al. in WADS’03] …

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 <<flow>> <<link>> <<invoke>> <<invoke>> <<receive>> <<receive>> invAssessor invAssessor rcvCustomer rcvCustomer <<joinCondition>> <<link>> <<joinCondition>> <<invoke>> <<invoke>> <<reply>> <<reply>> check( request ) <<link>> invApprover invApprover rplCustomer rplCustomer request <<joinCondition>> reply <<partnerLink>> <<partnerLink>> assessor customer approve( request ) <<partnerLink>> approver

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 <<flow>> <<link>> <<invoke>> <<invoke>> <<receive>> <<receive>> invAssessor invAssessor rcvCustomer rcvCustomer <<joinCondition>> <<link>> <<joinCondition>> <<invoke>> <<invoke>> <<reply>> <<reply>> check( request ) <<link>> invApprover invApprover rplCustomer rplCustomer request <<joinCondition>> reply <<partnerLink>> <<partnerLink>> assessor customer approve( request ) <<partnerLink>> approver 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 ws’s 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 Johnson’s algorithm [Johnson, 8th AIAA IEEE Digital Avionics Systems Conf.], which then generates complete Markov models.

14. From UML to Markov <<flow>> <<link>> <<invoke>> <<invoke>> <<receive>> <<receive>> invAssessor invAssessor rcvCustomer rcvCustomer <<joinCondition>> <<link>> <<joinCondition>> <<invoke>> <<invoke>> <<reply>> <<reply>> check( request ) <<link>> invApprover invApprover rplCustomer rplCustomer request <<joinCondition>> reply <<partnerLink>> <<partnerLink>> assessor customer approve( request ) <<partnerLink>> approver • 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 <<flow>> <<link>> <<invoke>> <<invoke>> <<receive>> <<receive>> invAssessor invAssessor rcvCustomer rcvCustomer <<joinCondition>> <<link>> <<joinCondition>> <<invoke>> <<invoke>> <<reply>> <<reply>> check( request ) <<link>> invApprover invApprover rplCustomer rplCustomer request <<joinCondition>> reply <<partnerLink>> <<partnerLink>> assessor customer approve( request ) <<partnerLink>> approver • 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 service’s activities. if the activities are not embedded in while activities deathif ( rcvCustomer=3 OR invAssessor=3 OR invApprover=3 OR rplCustomer=3 );

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, approver+1, rcvCustomer, invAssessor, invApprover+2, rplCustomer) by approver_failure_rate; endif; • These transitions are generated by Johnson’s 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 guaranteedependability in the face of mobility.