ICSOC12.ppt

transcript

Specification and Detection of SOA Antipatterns

Francis Palma1,2

In collaboration with

Naouel Moha1, Mathieu Nayrolles1, Benjamin Joyen Conseil1, Yann-Gaël Guéhéneuc2.

1 LATECE , Département d'informatique, Université du Québec à Montréal, Canada2 Ptidej Team, DGIGL, École Polytechnique de Montréal, Canada

Problem Context (1/3)

HTTP, SOAP, WSDL, UDDI, WS-Technologies

Service Based Systems (SBSs) evolve to fit new user requirements, execution contexts:

- may degrade design and quality of service (QoS)- may cause the appearance of common poor solutions:

Antipatterns

- Antipatterns hinder the future maintenance and evolution of SBSsFrancis Palma, Specification and Detection of SOA Antipatterns

Service Requester

Service Provider

Service-based System

Examples of SOA Antipatterns:

Tiny Service: Small service with few methods which requires several coupled services to complete an abstraction

Multiservice: Implements a multitude of methods, is not easily reusable because of low cohesion of its methods, is often unavailable due to overload

Tiny ServiceMultiservice

Francis Palma, Specification and Detection of SOA Antipatterns

results

Service-based (or any) Systems with Antipatterns

Thus, automatic detection of SOA Antipatterns in SBSs requires special attention

Outline

- Introduction

- Related Work

- Approach

- Experiments/Results

- Conclusion

Introduction: Contribution

With the goal to assess the design and QoS of SBSs:

- SODA (Service Oriented Detection for Antipatterns), a novel and

innovative approach

- SOFA (Service Oriented Framework for Antipatterns), a framework,

- to specify SOA antipatterns and detect them automatically

- to perform static and dynamic analysis

Outline

- Introduction

- Related Work

- Approach

- Conclusion

Related Work (1/2)

• Only 2 books: Dudney 2003, Rotem-Gal-

Oz 2012

• Several books:

Brown 1998, Fowler 1999Books

• Still in their infancy:

Kral 2008

• Numerous mature methods: Munro 2005, Lanza 2006,

Moha 2010, Kessentini 2010,

Settas 2011

Detection Methods

• Many Web sites of SOA

practitioners

• Web sites, courses,

magazines, journals etc.

Other references

Related Work (2/2)

• OO style design in SOA

system

• Procedural design style

in OO systemRoot cause

• Services• ClassesFirst class entities

• Highly dynamic• Mainly staticAnalysis

Related Work (2/2)

è OO detection methods, tools cannot be directly applied to SOA

è However, they form a sound basis of expertise and knowledge for building methods for the detection of SOA antipatterns

• OO style design in SOA

system

• Procedural design style

in OO systemRoot cause

• Services• ClassesFirst class entities

• Highly dynamic• Mainly staticAnalysis

Outline

- Introduction

- Related Work

- Approach

- Conclusion

Approach (1/9): SODA

SODA: Service Oriented Detection for Antipatterns

Textual Description of Antipatterns

Rule Card

Detection algorithm

Suspicious Services

Approach (2/9): Specification

Rule Card

Detection algorithm

Suspicious Services1. Specify SOA

Antipatterns

Domain Analysis

Domain Specific Language

Rule Cards of Antipatterns

“Multi Service also known as God Object

corresponds to a service that implements a multitude

of methods related to different business and technical

abstractions . This aggregates too much into a single

service, such a service is not easily reusable because

of the low cohesion of its methods and is often

unavailable to end -users because of its overload ,

which may induce a high response time”

Approach (3/9): Domain Specific Language

Rule Card

Detection algorithm

Suspicious Services

Approach (4/9): Example Rule Cards

Tiny Service

Multi Service

Rule Card

Detection algorithm

Suspicious Services

1 RULE CARD: TinyService {2 RULE: TinyService { INTER FewMethod HighCoupling };3 RULE: FewMethod { NMD VERY LOW };4 RULE: HighCoupling { CPL HIGH };5 };

1 RULE CARD: MultiService {2 RULE: MultiService { INTER MultiMethod HighResponse LowAvailability LowCohesion };3 RULE: MultiMethod { NMD VERY HIGH };4 RULE: HighResponse { RT VERY HIGH };5 RULE: LowAvailability { A LOW };6 RULE: LowCohesion { COH LOW };7 };

Approach (5/9): Generation

Rule Card

Detection algorithm

Suspicious Services

Approach (6/9): Detection

SOFA Framework

Rule Card

Detection algorithm

Suspicious Services

Approach (7/9): Underlying Framework

18Francis Palma, Specification and Detection of SOA Antipatterns

Main Components:

(1) Automated generation of detection algorithms

(2) Computation of static and dynamic metrics

(3) Specification of rules

Main Components:

(3) Specification of rules

Main Components:

(3) Specification of rules20

Outline

- Introduction

- Related Work

- Approach

- Conclusion

Experiments (1/5): Setup

Purpose: To validate the effectiveness of generated detection algorithms and the usefulness of SODA

Expected Results:§ DSL allows us to specify SOA antipatterns§ Detection algorithms have a recall of 100% and an accuracy more than 75%§ The detection times are the order of few seconds

Subjects: 10 SOA antipatterns

Objects: 2 versions of Home-Automation

Process: Precision and recall on Home-Automation (v1.0 and v1.1)

Experiments (2/5): Assumptions

A1. Completeness: The DSL allows the specification of many different SOA antipatterns, from simple to more complex ones

A2. Accuracy: The generated detection algorithms have a recall of 100%, and a precision greater than 75%

A3. Extensibility: The DSL and the SOFA framework are extensible for adding new SOA antipatterns

A4. Performance: The computation time required for the detection of antipatterns using the generated algorithms is reasonably very low (few seconds)

Experiments (3/5): Subjects- Apply SODA using SOFA framework to specify 10 SOA antipatterns

- 7 SOA antipatterns from literature, 3 newly defined

Bottleneck Service

The Knot

Service Chain

Experiments (4/5): Objects

Two different versions of Home-Automation: - Original version with 13 services - A version modified by adding & modifying services to inject Antipatterns

Experiments (5/5):Process

1. Use SOFA to generate detection algorithms for corresponding rule cards

2. Apply these algorithms on Home-Automation

3. Validate detection results by analyzing the suspicious services manually:

- Validate Suspicious Services as True Positives (TP)

- Identify False Negatives (FN)

q Use Precision (P) and Recall (R) for accuracy measurement

Outline

- Introduction

- Related Work

- Approach

- Conclusion

Results (1/8): DetectionDetection of Bottleneck Service: Mediator and Patient DAO

Results (2/8): DetectionDetection of Duplicated Service: Mediator and Communication

Results (3/8): DetectionDetection of Multiservice: Mediator

Results (4/8): Assumption A1A1. Completeness: The DSL allows the specification of many different SOA antipatterns, from simple to more complex ones.

Bottleneck Service

The Knot Sand Pile

Results (4/8): Assumption A1A1. Completeness: The DSL allows the specification of many different SOA antipatterns, from simple to more complex ones.

Therefore, any SOA antipattern from simpler to more complex ones can be

defined using our DSL

Results (5/8): Assumption A2A2. Accuracy: The generated detection algorithms have a recall of 100%, i.e., all existing antipatterns are detected, and a precision greater than 75%.

Our detection algorithms have high Precision and Recall…

Results (6/8): Assumption A3A3. Extensibility: The DSL and the SOFA framework are extensible for adding new SOA antipatterns.

Our DSL and SOFA framework are extensible for new SOA antipatterns…

Results (7/8): Assumption A4A4. Performance: The computation time required for the detection of antipatterns using the generated algorithms is reasonably very low.

Computation time required for detection using our generated algorithms is reasonably low…

Results (8/8): Summary

q Specify and generate detection algorithms for 10 SOA antipatterns

q Detect 10 SOA antipatterns in Home-Automation

q Including 2 SOA antipatterns in modified version

q Precision of our detection algorithms is 92.5%, and Recall is 100%

q Detail results and more materials on sofa.uqam.ca

Threats to Validity

Ø External Validity

Ø Internal Validity: Detection depends on services provided by SOFA ,

experiment on a representative set of antipatterns

Ø Construct Validity: Subjective nature, define rule cards based on

literature review & domain analysis

Ø Reliability Validity: Automate the generation of detection algorithm;

subsequent detection produce consistent sets of results

Outline

- Introduction

- Related Work

- Approach

- Conclusion

Conclusion

Future Works: Part 1

- Add more SOA antipatterns to SOFA

- Replicate SODA approach on other SBSs

- Using industrial setup

- Increase the precision

- Introduce refactoring module within SOFA

Future Works: Part 2

- Association rules on execution traces

- Machine learning technique…

- Semantic analysis

Thank You

Questions ?

Algorithm Generation

ICSOC12.ppt

Technology