1. The Dissertation at a Glance

1.1 Research Contexts

1.2 Problems Identified in the Literature 1.3 The Thesis Statement

A unified approach to assessing the design and quality of service (QoS) of SBSs, supported by a framework for specifying and detecting service antipatterns, can facilitate the maintenance and evolution of SBSs, with the conjecture that service antipatterns may degrade the design and QoS, and hinder the future maintenance and evolution of SBSs.

1.4 Research Questions to Answer 1.5 Main Contributions of this Dissertation
  1. A unified meta-model combining different SBSs technologies and architectural styles showing the differences and commonalities among them (solving Problem 1);
  2. On top of the meta-model, a service DSL to specify service antipatterns regardless of SBSs technologies with higher-level of abstractions (solving Problem 2);
  3. Using the proposed unified meta-model and the service DSL, a unified SODA approach for the specification and automatic detection of service antipatterns in SBSs technologies (solving Problem 3);
  4. An extensive validation of the SODA approach using precision, recall, and F1-measure on the largest SCA system, FraSCAti, more than 120 WS, and 15 well-known REST services (solving Problem 3);
  5. An empirical evidence on the impact of service antipatterns on the maintenance and evolution of SBSs, in particular on SCA systems (solving Problem 4).
1.6 Other Related Contributions
  1. Detection of process antipatterns in business processes;
  2. A taxonomy of service antipatterns.
[Return to top]


2. Background

2.1 Common SBSs Technologies

  1. Service Component Architecture (SCA);
  2. SOAP Web services (WS);
  3. REpresentational State Transfer (REST);


2.2 Comparison among Service Antipatterns in SCA, SOAP Web services, and REST

SCA ∩ REST ∩ WS SCA ∩ WS REST ∩ WS SCA WS REST
Ambiguous Name Multi Service CRUDy Interface Sand Pile Low Cohesive Operations Forgetting Hypermedia
Nobody Home Tiny Service CRUDy URI The Knot May be It's Not RPC Ignoring MIME Types
Bloated Service Data Service God Component Redundant Port-Types Breaking Self-descriptiveness
Chatty service Ignoring Caching
Service Chain Ignorning Status Code
Duplicated Service Misusing Cookies
Stovepipe Service Tunelling Through GET
Bottleneck Service Tunelling Through POST
Amorphous URI
Contextless Resource Names
Non-heirarchical Nodes
Pluralised Nodes


3. The Unified SODA Approach


The Unified Meta-model for WS, SCA, and REST
  1. Step 1: Specification. This step includes performing a thorough domain analysis by studying the definitions and textual descriptions of service antipatterns from the literature to identify relevant static and dynamic properties to specify them. The identified properties represent (1) measurable attributes of the proposed unified abstraction elements and (2) the inter-element relations among them. We use these properties as the basis of the vocabulary to define a common domain specific language (DSL) and formalise antipatterns with rule cards. Rule cards are representation of antipatterns at a high-level of abstraction, which are both machine processable and human understandable. Figure 5.3 shows examples of rule cards for Multi Service and Tiny Service. For REST antipatterns, we define detection heuristics that are applicable on REST requests and responses.
  2. Step 2: Generation. From the rule cards in the previous step, we intend to automatically generate their detection algorithms using a simple template-based technique (for SCA and Web services) or implement the detection algorithms for defined heuristics (for REST). Templates are defined with well-defined tags that can be replaced with values at runtime.
  3. Step 3: Detection. For the detection of antipatterns, we introduce an underlying framework, SOFA (Service Oriented Framework for Antipatterns). The computations of all static and dynamic metrics, i.e., identified relevant properties of antipatterns and related analyses are performed in SOFA framework. It also assists in syntactic and semantic analyses of services interfaces based on WordNet and Stanford CoreNLP. In this step, we apply the detection algorithms automatically generated in the previous step on different SBSs and report suspicious services. Moreover, for REST services, SOFA provides the means to concretely send HTTP requests and to automatically apply the detection algorithms on both HTTP requests and responses.

[Return to top]


3.1 The Domain Specification Language (DSL)

  1. rule_card ::= RULE_CARD: rule_cardName { (rule)+ };
  2. rule ::= RULE : ruleName { content_rule };

  3. content_rule ::= metric | relationship | operator ruleType (ruleType)+ | RULE_CARD : rule_cardName
  4. ruleType ::= ruleName | rule_cardName

  5. operator ::= INTER | UNION | DIFF | INCL | NEG
  6. metric ::= id_metric ordi_value | id_metric comparator num_value

  7. id_metric ::= ALS | ANAM/ANAO | ANIM | ANP | ANPT | ARIM | ARIO | ARIP | COH | CPL | NCO | NI | NIR | NMD/NOD | NOPT | NOR | NPT | NSE | NUM | NVMS | NVOS | RGTS | TNP | A | NMI | NTMI | RT

  8. ordi_value ::= VERY HIGH | HIGH | MEDIUM | LOW | VERY LOW
  9. comparator ::= < | ≤ | = | ≥ | >

  10. relationship ::= relationType FROM ruleName cardinality TO ruleName cardinality
  11. relationType ::= ASSOC | COMPOS
  12. cardinality ::= ONE | MANY | ONE_OR_MANY | num_value NUMBER_OR_MANY

  13. rule_cardName, ruleName, ruleClass ∈ string
  14. num_value ∈ double


3.2 List of 27 Service Metrics for Specifying Service Antipatterns

 List of 27 Service Metrics for Specifying Service Antipatterns

[Return to top]


3.3 The SOFA Framework

The SOFA Framework

SOFA has eight modules, programmatically each of which represents a component providing a stand-alone service. The components include:

[Return to top]


4. Validation

4.1 Assumptions
  1. A1. Generality Our DSL allows the specification of different service antipatterns, from simple to more complex ones, in various SBSs technologies using the proposed unified meta-model.
  2. A2. Accuracy Our automatically generated (or implemented) detection algorithms have a precision and recall of greater than 75%, i.e., more than three-quarters of detected antipatterns are true positive and more than three-quarters of all existing antipatterns are detected, respectively.
  3. A3. Extensibility Our DSL and the proposed framework, SOFA is extensible for adding new service metrics and technology-specific or technology-neutral antipatterns.
  4. A4. Performance The computation time required for the detection of service antipatterns using the generated (or implemented) algorithms is reasonably very low, i.e., in the order of seconds in various technologies.


4.2 Experimental Objects

  1. FraSCAti and Home-Automation Demo SCA systems
  2. 122 SOAP Web services
  3. 15 REST APIs


4.3 Measurement of Detection Accuracy


5. Experimental Results

5.1 Detection of Antipatterns Common in SCA, WS, and REST

Detection Results of the three service antipatterns: Ambiguous Name, Bloated Service, and Nobody Home commonly found in the three SBSs Implementation Technologies SCA, Web services, and REST.


5.2 Detection of Antipatterns Common in SCA and WS

Detection Results of the eight service antipatterns commonly found in the two SBSs Implementation Technologies SCA and Web services.


5.3 Detection of Antipatterns Common in WS and REST

Detection Results of the two service antipatterns: CRUDy Interface and CRUDy URI commonly found in the two SBSs Implementation Technologies Web services and REST.


5.4 Detection of SCA-specific Antipatterns

Detection Results of the three service antipatterns: God Component, Sand Pile, and The Knot commonly found in SCA.


5.5 Detection of WS-specific Antipatterns

Detection Results of the three service antipatterns: Low Cohesive Operations, May be It’s Not RPC, and Redundant PortTypes commonly found in Web services.


5.6 Detection of REST-specific Antipatterns

The Mapping between REST Antipatterns and Patterns


5.7 Overview on the Detection Results of REST Request/Response Syntactic Antipatterns.
[BSD - Breaking Self-descriptiveness; FH - Forgetting Hypermedia; EL - Entity Linking; IC - Ignoring Caching; RC - Response Caching; IMT - Ignoring MIME Types; CN - Content Negotiation; ISC - Ignoring Status Code; MC - Misusing Cookies; TTG - Tunnelling Through GET; TTP - Tunnelling Through POST; EPR - End-point Redirection; EE - Entity Endpoint.]


5.8 Summary of the Detection Results on 12 REST APIs

The table below presents the summary on the results for the detection of 8 REST antipatterns and 5 REST patterns:

[Return to top]



5.9 Detailed Detection Results

The table below presents the detailed detection results for the 14 REST patterns and antipatterns for 12 REST APIs along with the detailed detection logs:

[Return to top]




5.10 Linguistic (anti)patterns detected in each REST API



5.10 Detection results of the four REST linguistic antipatterns related to the semantic design of REST URIs obtained by applying detection algorithms on the 15 REST APIs (numbers in the parentheses show total test methods for each API). The detection time excludes the execution time, i.e., sending requests and receiving responses.



5.11 Detection results of the five REST patterns related to the syntactic design of REST requests/responses obtained by applying detection algorithms on the 12 REST APIs (numbers in the parentheses show total test methods for each API).



5.12 Detection results of the five REST linguistic patterns related to the semantic design of REST URIs obtained by applying detection algorithms on the 15 REST APIs (numbers in the parentheses show total test methods for each API). The detection time excludes the execution time, i.e., sending requests and receiving responses.



5.13 Detailed Detection Results for all Request URIs

The following data-set contains all results for all request URIs from all the RESTful APIs we syntactically and semantically analysed:

1. Alchemy
2. Bestbuy
3. Bitly
4. Charlieharvey
5. Dropbox
6. Externalip
7. Facebook
8. Instagram
9. Musicgraph
10. Ohloh
11. Stackexchange
12. Teamviewer
13. Twitter
14. Toutube
15. Zappos


5.14 Complete validation results on Dropbox (Validation 1) and partial validation results on Facebook, Dropbox, Twitter, and YouTube (Validation 2). 'P' represents the numbers of detected positives and 'TP' the numbers of true positives.


5.15 Average Precision, Recall, and F1-measure for the Different Antipatterns Groups


5.16 Average Detection Times for the Different Antipatterns Groups


6. Investigating the Maintenance Cost of SOA Patterns and Antipatterns

In this empirical study, we relate some service patterns and antipatterns with the change-proneness of services. We proposed a four-step approach to conduct our study:

Step 1. Collecting Mailing Data: The first step consists in mining change data information from the complete FraSCAti-commits mailing list archives. The FraSCAticommits mailing list archive is available online at http://mail-archive.ow2.org/.

Step 2. Extracting Source Code Changes and Code Churns: The second step involves the extraction of the number of changes made and the number of code churns for a certain service artefact.

Step 3. Service-oriented Patterns and Antipatterns Detection: The third step in our approach involves detecting service patterns and antipatterns in FraSCAti. This detection is done on the client-side artefacts, i.e., analysing services composition, system design, and the quality of service (QoS). We perform the detection of service antipatterns using the SODA. We also used the SODOP proposed by Demange et al. to perform the detection of SO design patterns.

Step 4. Data Preparation: Once we extracted the changes and code churns and performed the detection of service patterns and antipatterns, in this last step of our approach, we grouped the source code changes and code churns to link them with the detected patterns and antipatterns.


6.1 Service Antipatterns

The set of service antipatterns that we considered in this study are the subset of the antipatterns described and specified using a domain specific language here.

6.2 Service Patterns

Also, the set of service patterns that we considered in this study are the subset of the patterns described and specified here.


6.3 Study Materials
  1. You can have the the complete "frascati-commits mailing list archives" from here.
  2. Download the complete list of changes and code churns extracted from the entire FraSCAti commits from here.
  3. Download the related list of Java classes for the services detected as patterns and antipatterns (with the changed lines of code and code churns) extracted from the entire FraSCAti commits from here.
  4. Download the complete list of Java classes with any kinds of code smells detected by the PMD tool from here.
  5. Download the aggregated list of smells for each Java classes from the entire FraSCAti from here.

6.4 Study Results
6.4.1 Research Questions

RQ1 : What is the relation between service patterns and change-proneness?
H101: there is no difference between the total number of changes experienced by files involved in the implementation of a service pattern and other files.
H201: there is no difference between the total number of code churns experienced by files involved in the implementation of a service pattern and other files.

Findings : Services involved in service patterns are less change-prone than other services; the total number of source code changes and code churns performed during the maintenance and evolution of services involved in a service pattern is lower than the total number of source code changes and code churns performed on other services. However, this difference is not statistically significant.

RQ2 : What is the relation between service antipatterns and change-proneness?
H102: there is no difference between the total number of changes experienced by files involved in the implementation of a service antipattern and other files.
H202: there is no difference between the total number of code churns experienced by files involved in the implementation of a service antipattern and other files.

Findings : Services involved in service antipatterns are more change-prone than the services that are not involved in any service antipattern. The total number of source code changes and code churns performed during the maintenance and evolution of services involved in a service antipattern is higher than the total number of source code changes and code churns performed on other services. The difference is statistically significant.

RQ3 : What is the relation between particular kinds of service antipatterns and change-proneness?
H103: there is no difference between the total number of changes experienced by files from eight groups of antipatterns and and non-antipatterns group.
H203: there is no difference between the total number of code churns experienced by files from eight groups of antipatterns and non-antipatterns group.

Findings : Services involved in God Component, Multi service, and Service Chain antipatterns more change-prone than services involved in other kinds of service antipatterns. The difference is statistically significant.


To answer above questions, we mainly use three tests:

Mann-Whitney U or Wilcoxon rank-sum test is a non-parametric test of the null hypothesis that two populations are the same against an alternative hypothesis, especially that a particular population tends to have larger values than the other.

Kruskal-Wallis one-way analysis of variance is a non-parametric method for testing whether samples originate from the same distribution. It is used for comparing more than two samples that are independent, or not related.

Cliff's Delta is a non-parametric effect size measure that quantifies the amount of difference between two groups of observations beyond p-values interpretation. This measure can be understood as a useful complementary analysis for the corresponding hypothesis testing.


6.5 Results on FraSCAti services RQ1: Services involved in service patterns are less change-prone than the services not involved in any service pattern.
results

results

results


results


results


RQ2: Services involved in service antipatterns are more change-prone than the services that are not involved in any service antipattern.
results

results


results


results


RQ3: Services involved in God Component, Multi service, and Service Chain service antipatterns more change-prone in the server-side than services involved in other service antipatterns. Therefore, the eight kinds of antipatterns investigated in this study are not equally change-prone.
results

results


results


7. Detection Tools

Detection tools related to SOAP services:

We provided a GUI-based tool for the detection of service antipatterns in SOAP Web services. The users could search SOAP services using a dedicated Web services search engine www.programmableweb.com and could choose to analyse any number of service interfaces from the list returned by the search engine. The WAR file of the tool is available for download from the link below. Users can deploy it in Tomcat 6.x and test with the localhost from the localhost:8080/soda-w/Applicationclient/index.htmlpage.

ZIP Download:
Please download the ZIP of the soda-w tool from here. You do not need to deploy it.

WAR Download:
Please download the WAR of the soda-w tool from here. You need to deploy it in the Tomcat 6.0.37.

Download of the SOAP Web service project with 9 weather-related SOAP services (to be analysed): Please download the ZIP of the SOAP Web service project with 9 weather-related SOAP services from here.

Download of the SOAP Web service project with 99 financial-related SOAP services (to be analysed): Please download the ZIP of the SOAP Web service project with 99 financial-related SOAP services from here.

Download of the tool to analyse above two SOAP services projects:
Please download the ZIP of the SoaAntiPatternsToolStatic_1.4 project from here.

Currently, we have integrated four Web service-specific service antipatterns in the tool. Addition of the rest are in progress.

Detection tool related to RESTful APIs:
Please download the ZIP of the DOLAR tool from here.

Detection tool related to SCA:
Please download the ZIP of the SODA tool from here.

The FraSCAti runtime download:
We provide here the FraSCAti runtime libraries the tools might need:
Please download the FraSCAti runtime version 1.4 from here.
Please download the FraSCAti runtime version 1.6 from here.