Web service antipatterns

Context. Bad smell detection is an important task in improving source code quality. Bad smells are further classified as code smells, design smells, architectural smells and antipatterns, and they are reported differently in the literature depending on the system under study.

Objectives. This paper investigates the key techniques used to identify bad smells across different domains of software engineering, from object‑oriented software engineering through to service‑based systems. State‑of‑the‑art bad smell techniques are reported and classified, and the smells are divided according to their key characteristics.

Conclusion. Many challenges remain uncovered for service‑based systems, such as the detection of smells that evolve continuously across system versions to affect service performance. There is also a need to check the performance of service‑based systems after the detection and correction of bad smells, and the performance evaluation of different search‑based techniques for bad smell detection in such systems is likewise uncovered.

Service oriented architecture has become a popular architectural style in industry [1]. SOA encourages the development of low‑cost, flexible, distributed and reusable business solutions by combining services that are independent, portable and interoperable program units accessible over the internet. In practice SOA can be analysed using various technologies and architectural styles, including SCA (service component architecture), REST (representational state transfer) and web services.

Web services are the main part of the SOA technologies used today to develop service‑based systems (SBSs) [2]. Amazon, eBay, Google, FedEx, PayPal and many other companies are all influenced by web services. Web services are commonly referred to as SOAP‑based or REST‑based; the main focus of the present research is SOAP‑based web services.

Service‑based systems evolve to meet different user requirements or to adjust to changed execution contexts. These changes may cause design and implementation issues, and often introduce poor practices called antipatterns. It is therefore important to find the antipatterns that affect the quality of services, not only in service‑based systems but also in individual web services. Antipatterns have been shown to negatively affect the quality of services and the maintenance and evolution of software systems [3, 4, 5].

Moving towards a list of antipatterns, J2EE antipatterns were the first discussed in the literature [6]. A major portion of the discussion concerns God Object web services and Fine Grained web services [6]. A God Object web service is one that has a large number of low‑cohesion operations in its interface, relating to different levels of business abstraction; this may cause high response times and reduce the availability of services. A Fine Grained web service, by contrast, has very few cohesive operations, which could be implemented as part of a larger abstraction.

Different techniques have been reported in the literature to help identify and detect antipatterns in web services [7, 8, 9, 10, 11, 12, 13]. These techniques use static analysis of web services through their WSDL (Web Services Description Language) files, but their detection methodologies are not clear with regard to the detection rules for these services; they mostly highlight the definition of web service antipatterns and their possible solution in terms of refactoring techniques. Another important factor is that their detection techniques mostly focus on either code‑first or contract‑first web services, so the results vary depending on how the options are implemented. The tools used for the code‑first approach are Java2WSDL, EasyWSDL and Visual Studio WSDL; the contract‑first tools discussed are highly dependent on generating a WSDL description for the interfaces and implementing them later.

Antipattern detection for SOAP‑based web services using static and dynamic analysis was proposed by Palma et al. [14]. That methodology is based on the underlying SOFA (service oriented framework) with tool support called SODA‑W, and detects ten antipatterns in SOAP‑based web services. Its major focus is the rule‑based detection of the service interface using static source code metrics, and the calculation of dynamic properties of web services such as availability and response time. That research is based on a set of metrics used to identify antipatterns in web services, defined using Backus–Naur Form (BNF) and extensible to new technologies such as SCA and REST. Ouni et al. proposed a search‑based approach for the detection of antipatterns using a genetic algorithm that measures static service interface metrics [32]. This approach was later extended by adding code‑level metrics and measuring the structural properties of SOAP services using both service‑level and code‑level metrics [33]. The fixed‑threshold problem and the pitfalls of the rule‑based technique [14] are overcome with dynamic threshold adaptation after implementing a parallel evolutionary algorithm (PE‑A) [34].

All of the research mentioned above focuses either on SOAP‑based web services or on the WSDL file. The web service description language is a main part of the web service, so it is important to implement an approach that assesses the quality of the WSDL as well as of the web service. Service quality is not addressed properly and the focus remains on the structural properties of the WSDL file. Despite the wide adoption of web service technologies, no methodology or tool support is available that detects both WSDL interface and code‑level antipatterns in order to improve service quality, and there is still a need to check quality‑of‑service issues other than availability and reliability.

Service‑based systems evolve continually to meet rapidly changing user requirements, and there is a need to improve the quality of service for these systems by detecting antipatterns. The present research focuses on quality‑of‑service issues for web services, specifically SOAP‑based services. A detailed review was conducted of the existing studies on web service antipattern detection. We intend to analyse web service antipatterns using both static and dynamic analysis. Different approaches are available for antipattern detection in WSDL and in SOAP, but no approach is available that detects antipatterns across the complete SOA architecture.

A number of antipattern detection approaches exist for web services. A catalogue of web service antipatterns is presented in [7], which also addresses previously identified WSDL antipattern issues such as naming issues [18] and data type definition issues [19]. It is also very difficult to assess the quality of web services affected by non‑representative names and unclear documentation [21]. Several approaches discuss antipattern detection for the WSDL document [7, 8, 9, 10, 11, 12, 13, 22, 23, 30], assisting developers in developing, discovering, publishing and consuming web services; only one approach so far addresses the detection of antipatterns from SOAP‑based services [14].

Most approaches for detecting antipatterns in web services depend on the technique used to make the WSDL file. Two techniques largely govern industry practice: code‑first and contract‑first [7, 8, 9, 10, 11, 12]. Some of the research mentioned above focuses on static analysis of the WSDL document and then suggests the refactoring approaches needed to remove the antipatterns, but it does not clearly state the implementation technique used for detection — only definitions of some antipatterns are reported, along with the relationship between the OO metrics used for detection and the WSDL antipatterns. The table below presents the complete list of antipatterns reported in that research on the basis of static analysis of source code.

Antipattern detection for web services is mainly reported in the literature on the basis of static analysis. SODA‑W was the first to detect antipatterns in SOAP‑based web services by considering the dynamic nature of services [14]. This is examined by measuring the response time and availability of the services over a specific interval of time. Some antipatterns reported in the literature also require dynamic analysis of the WSDL file, by invoking the service directly and measuring the dynamic properties of the web service.

All of the approaches mentioned above analyse the web service on the basis of a set of source code metrics, most of which relate to object‑oriented systems. Mateos also showed that a relationship exists between OO metrics and web service antipatterns, by conducting research analysing the effect of OO metrics on a code‑first web service implementation [30]. However, that approach is biased by the fact that only one code‑first tool was employed, so its generalisability is limited [30]. The study focuses only on the cause and effect of these OO metrics on the WSDL antipattern detection approach, which raises a question mark over the generalisability of the dependent variable. It is also noticeable from that study that increasing or decreasing metric values may increase or decrease the occurrence of antipatterns. Another study describes possible measures to avoid antipatterns in the contract‑first approach [11], and also reports on the use of OOSE metrics for detecting antipatterns in web services [11].

Reviewing the studies above, it is apparent that most of them [7, 8, 9, 10, 11, 12] report antipatterns from the WSDL file after examining the code, and are more focused on approaches such as code‑first or contract‑first. The cause‑and‑effect relationship between web service antipatterns and OOSE metrics is the major focus of that research. Moreover, only one study reports on the dynamic nature of web services [14], and it still fails to detect several antipatterns such as Data Web Service, Duplicated Web Service, God Object Web Service and Maybe It’s Not RPC [14]. Furthermore, the Ambiguous Names antipattern is based only on similarity measures drawn from an English dictionary; there is a need to check these antipatterns against other corpora.