Towards Self-healing Service Compositions

1. Towards Self-healing Service Compositions
Luciano Baresi, Carlo Ghezzi, and Sam Guinea
Presented By:
Md. Mostafijur Rahman

2. Background
 SoA integrates components in unstable and
evolving context.
 Service discovery phase supports flexible and
dynamic components binding.
 Bindings can fail because of dynamicity.
2/2/2015 2

3. Background (cont..)
 components can export the services
 clients can discover the services that fit quality
requirements
 If discovery phase is done at design time, the
designer selects the services by hand, without
any real broker
 In this case, wrong design choices and the
actual availability of selected services are the
only problems.
2/2/2015 3

4. Background (cont..)
 If the discovery phase is done at deployment
time, the service broker is used to configure the
application.
 set of services does not change dynamically and
the binding between service requests and actual
services is done once for ever
 introduces the problems associated with
discovery of services
• discovery phase must be postponed to run-time
2/2/2015 4

5. Research Question
 What are the main faults associated with SoA?
 How to adopt self-healing service composition
in failure or crash of system?
 How to recognize and monitor service
composition according to changing contexts?
2/2/2015 5

6. Contribution
 Identify and classify the main faults.
 Service composition for monitoring and
recognizing according to changing contexts.
 Characterization of the faulty behaviors.
 make designed compositions become self-
healing systems
 reorganized processes locally by exploiting
single and special-purpose rules that split or
merge the single nodes of the process.
2/2/2015 6

7. Methodology
 Runtime error discovery
 Defensive Process Design
 Permit to cope with erroneous behaviors
 Timeout error
 Using clause
 Exception occur
 Service run-time Monitoring
 external monitor-service capable of checking whether
functional and non-functional contracts are violated
 Assertion based (pre, post conditions, invariant)
2/2/2015 7

8. Methodology (cont..)
 Recovery Strategies
 allow a process to continue execution even in case
of faulty behaviors.
 retry
 Rebind (lookup service)
 Restructure (local reorganization)
 the BPEL-like process definition as a direct graph
 graph transformation rules to modify its topology
 predicates on node (invocation) not matched by the
lookup procedure and its neighbors.
2/2/2015 8

9. Limitation
 does not promote Web services substitution as a
potential option. Web service substitution [5] is
the only option when a component Web service
totally fails to respond.
 partially solve the semantic ambiguities that arise
in service-discovery architectures, but do not
address the problem of interoperability with web
services that may expose the same interfaces but
different interaction protocols .
 System was not well evaluated.
2/2/2015 9

10. Conclusion
 Exploit probes to monitor execution of
compositions
 Move towards self-healing
 Perform assessment using a case study
2/2/2015 10

11. References
[1] BEA, IBM, Microsoft, SAP and Siebel. Business Process Execution Language
for Web Services Version 1.1. 2003.
[2] W. Robinson. Monitoring web service requirements. In Proccedings of the
International Conference on Requirements Engineering, 2003.
[3] IBM Corporation. Web Service Level Agreement (WSLA) Language
Specification. 2003.
[4] T. Lehner. Dynamic Reconfiguration of BPEL Processes - Master Thesis -
Politecnico di Milano and Universitat Passau Fakultat fur Mathematik und
Informatik. 2004
[5] Y. Taher, B. Benslimane, M. Fauvet, and Z. Maamar. Towards an Approach
for Web services Substitution. In Proceedings of the 10th International
Database Engineering and Applications Symposium (IDEAS’06), Los Alamitos,
CA, USA, 2006.
2/2/2015 11

12. Any Question?
2/2/2015 12

13. Thank You
2/2/2015 13