A Study on the Taxonomy of Service Antipatterns Francis Palma *† and Naouel Moha † * Ptidej Team, DGIGL, ´ Ecole Polytechnique de Montr´ eal, Canada. Email: francis.palma@polymtl.ca † D´ epartement d’informatique, Universit´ e du Qu´ ebec ` a Montr´ eal, Canada. Email: moha.naouel@uqam.ca Abstract—Antipatterns in Service-based Systems (SBSs)— service antipatterns—represent “bad” solutions to recurring de- sign problems. In opposition to design patterns, which are good so- lutions, antipatterns should be avoided by the engineers. Antipat- terns may also be introduced due to diverse changes performed against new user requirements and execution contexts. Service antipatterns may degrade the quality of design and may hinder the future maintenance and evolution of SBSs. The detection of service antipatterns is important to improve the design quality of SBSs and to ease their maintenance. A better understanding of service antipatterns is a must prerequisite to perform their detection. This paper presents a taxonomy of service antipatterns in Web services and SCA (Service Component Architecture), the two common SBSs implementation technologies. The presented taxonomy will facilitate engineers their understanding on service antipatterns. Other substantial benefits of the presented taxonomy include: (1) assisting in the specification and detection of service antipatterns, (2) revealing the relationships among various groups of service antipatterns, (3) grouping together antipatterns that are fundamentally related, and (4) providing an overview of various system-level design problems ensemble. Keywords—Antipatterns, Taxonomy, Service-based systems I. I NTRODUCTION Service Oriented Architecture (SOA), as an architectural style, is now broadly adopted in the industry because it allows the development of low-cost, flexible, and scalable distributed systems by composing autonomous, reusable, and platform-independent software units—services—which can be consumed over the Internet [1]. In practice, SOA can be realised using various technologies and architectural styles including SCA (Service Component Architecture) [2] and Web services. Google Maps, Amazon, eBay, PayPal, and FedEx are well-known examples of service-based systems (SBSs). However, the emergence of SBSs raises several software engineering challenges. Indeed, like any other complex soft- ware systems, SBSs must evolve to fit new user requirements and to cope with new execution contexts, such as changes in technologies or protocols. All these changes, over the time, may degrade the design and quality of service (QoS) of SBSs and may often result in the appearance of common poor solutions to recurring problems—antipatterns—by opposition to design patterns, i.e., good solutions to recurring design problems. Multi Service [3] and Tiny Service [3] are two common antipatterns in SBSs. Multi Service is an antipattern that represents a service implementing a multitude of operations related to different business and technical abstractions. Such a service is not easily reusable because of the low cohesion among its operations and is often unavailable to end-users because it is overloaded [3]. Conversely, Tiny Service is a service with just a few operations, which only implements part of an abstraction. Such service often requires several coupled services to be used together, leading to higher development complexity and reduced flexibility [3]. Therefore, the detection of such antipatterns is an important activity to assess the design and QoS of SBSs and to ease their maintenance and evolution. To perform the detection of service antipatterns, their in- depth understanding and relationships among them is the first and crucial step. To ease their understanding, this paper as its main contribution proposes the first classification of service antipatterns. In the following sections, we define what we mean by service antipattern and propose a taxonomy of service antipatterns. The presented taxonomy, we believe, will facilitate engineers their understanding of service antipatterns. The taxonomy will also (1) assist in the specification and detection of service antipatterns, (2) reveal the relationships among various groups of service antipatterns, (3) group to- gether antipatterns that are fundamentally related, and (4) provide an overview of various system-level design problems. In the remainder of this paper, Section II highlights existing contributions in the literature. Section III presents the cata- logue and taxonomy of service antipatterns with their detailed classifications. Finally, Section IV concludes the paper. II. RELATED WORK In object-oriented (OO) systems, a code (or design) smell is a symptom in the source code (or program) indicating auxiliary problems. As Fowler mentioned: “a code smell is a surface indication that usually corresponds to a deeper problem in the system” [4]. A number of contributions exist in the literature that classified object-oriented (OO) code- and design-level smells, including [5]–[7]. M¨ antyl¨ a et al. [6] performed an empirical study on OO code smells and presented a subjective taxonomy that cate- gorises similar smells and showed that the taxonomy for the smells facilitates explaining the identified correlations between the subjective evaluations of the smells. Moha et al. [5] presented the classification of ten OO smells and proposed an approach for the specification and automated detection of OO smells in the source code. Such classification was carried out after a thorough domain analysis of OO design and code smells. However, the authors’ main interest in [5] was the automatic detection of OO smells. Ganesh et al. [7] proposed an approach to classify and catalog 31 new OO design smells based on how they break the key OO design principles [8]. The significant contribution of this work was the empirical validation of design smells with real system architects. However, all these works addressed OO code and– or design smells. In the service domain, service smell holds the same notion, instead, at the service-level, which is coarser-grained and at