A Lightweight Approach for Specification and Detection of SOAP Anti-Patterns

Web-services have become a governing technology for Service Oriented Architectures due to reusability of services and their dependence on other services. The evolution in service based systems demands frequent changes to provide quality of service to customers. It is realised by different researchers that evolution in service based systems may degrade design and quality of service and may generate poor solutions known as antipatterns. The detection of anti-patterns from web services is an important research realm and it is continuously getting the attention of researchers. There are a number of techniques and tools presented for detection of anti-patterns from object oriented software applications but only few approaches are presented for detection of anti-patterns from SOA. The state of the art anti-pattern detection approaches presented for detection of anti-patterns from SOA are not flexible enough and they are limited to detection of only a few anti-patterns. We present a flexible approach supplemented with a tool support to detect 10 anti-patterns from different SOA-based applications. We compare results of our approach with two representative state of the art approaches. Keywords—SOAP web services; Anti-patterns; Bad smells; SQL


INTRODUCTION
Design patterns suggest viable solutions to the problems that occur again and again in the design of the software [1].Design patterns follow the fundamental design principles for the development of software applications.Anti-patterns violate fundamental design principles and they are poor solutions adopted by developers due to deadline pressure, lack of awareness and time to market constraints.Anti-patterns may have a negative impact on the quality and performance of software applications and their presence may result in degrading the structure of the services [2].The identification of anti-patterns from the web services is a primary step for the removal of anti-patterns from service based systems.It is important to have knowledge about the presence of antipatterns in the software systems because it helps to improve the software at its abstraction level.It is reported through different studies that timely detection and correction of anti-patterns from software systems improve system performance and quality [4,7].This edge motivates researchers to offer assistance for unskilled designers through the detection of antipatterns.
Service Oriented Architecture (SOA) is an arising architecture paradigm that is widely adopted by software industry for the development of distributed and heterogeneous applications.SOA allows the growth of timely, cost effective, flexible, adaptable, reusable, scalable and extendable distributed software applications with enhanced security by composing services through independent, reusable, and platform independent software modules that are easy to get via a network [8].The application of SOA for emerging technologies such as cloud computing, big data and mobile applications is continuously escalating.Web-services have become an important technology for Service Oriented Architectures for the development of Service Based Systems (SBS) such as Amazon, Google, eBay, PayPal, Facebook, Dropbox, etc. Service based systems need to evolve with time to fulfill requirements of users.These systems also evolve to accommodate new execution contexts such as addition of new technologies, devices and products [8].The evolution of service based systems may degrade design and quality of services and it may also cause the appearance of common poor solutions called anti-patterns.These anti-patterns affect the quality of service and can hinder maintenance and evolution.It reflects from state of the art anti-pattern detection techniques that mostly the concentration was on the static analysis of Web-services or on anti-patterns in other Service Oriented Architecture technologies (e.g., Service Component Architecture) [9].
It has been reported that anti-patterns have impact on the progress and maintenance of software systems [10].The motivation for automatic identification of SOA related antipatterns is to improve the quality of service and to make maintenance and evolution easy.Maintaining changes in web services is a common practice to provide quality of services to the users.A study has shown that the software maintenance requires eighty to ninety per cent of the total budget in its whole life cycle [11].Most state of the art techniques focused on detection of anti-patterns from object oriented software applications but these techniques are not capable of detecting anti-patterns from SOA.We identified only a few representative approaches on specification and detection of SOA anti-patterns from Web-services [9,12,13,14,15,16,18].To the best of our knowledge, most authors used different metrics and static/ dynamic analysis methods for the detection of anti-patterns from web-services.The state of the art antipattern detection approaches has some limitations: SODA-W [13] approach detects anti-patterns by just considering interface level metrics and it ignores implementation details.PA-E [14] approach detects anti-patterns from web services by considering their classes as well as implementation details but www.ijacsa.thesai.org it is not capable to identify classes that create a problem at the interface level.Moreover, low cohesion operation and duplicated web service anti-patterns are not detected by this approach.The both approaches are also not able to identify the location of defected code segments that play a major role for interface level implementation.There are also no standard definitions for web-service anti-patterns that are important for their accurate detection.Moreover, there are still no standard benchmark systems for comparing and evaluating results of anti-pattern detection techniques for SOA.
The proposed approach is flexible and extendable to implement code first concept.The presented approach is free from the implementation restrictions of WSDL interface.SOAP services might be implemented by using multiple languages such as C#, Java, Perl etc.The approach may detect anti-patterns from WSDL interface of web services as well as source code due to support of multiple languages.The proposed approach is supplemented with a tool support that is used to detect 10 SOA anti-patterns from different Webservices.The objective of presented approach is to analyse the structure and quality of Web-services and automatically identify anti-patterns that may help the progression and growth of Web-services.The proposed approach is implemented by using C# dot.netFramework.We also focus on improving the accuracy in comparison to existing methods available for the detection of Web-service specific anti-patterns.
Following are the major contributions of our work:  Standardised definitions of 10 Web-services related anti-patterns.
 A flexible and scalable approach supplemented with a tool support for the detection of 10 anti-patterns from different Web-services.
 Evaluation and comparison of the approach by performing experiments on Web-service of two different domains.
The paper is organised as follows.The state of the art is discussed in Section II.In Section III, we present specification of 10 anti-patterns.The concept and architecture of approach used to detect anti-patterns are presented in Section IV.In Section V, the concept of a prototyping tool is discussed.We discuss experimental setup and evaluation of approach in Section VI.The conclusion is presented in Section VII.

II. STAT OF THE ART
The research on bad smells started in 1999 when Fowler first time introduced 22 code smells and guidelines for refactoring smells.Bad smells are later on discovered at design, architecture and requirement levels.Zhang et al. [20] and Rasool et al. [19] presented reviews on code smells.Bad smells at design levels are called design smells or anti-patterns by different authors.A number of design smell detection techniques and tools are presented by different authors [21,22,23,24,25].Anti-patterns and code-smells are often mixed up into one term, the design defects [26].The code smells are fine-grained and strongly connected to the code-level and antipatterns are coarse-grained and are shown at the design level.Code smells are code-level symptoms indicating the expected presence of an anti-pattern (also called ‗Design Flaw' [27]).Architectural bad smells are also presented by different authors [28,29,30].A review on product line based architectural bad smells is presented by Vale et al. [31].The concept of bad smells at requirements level and their detection is presented by Femmer et al. [32].All of the above discussed approaches focused on bad smells for object oriented software applications.The focus of this paper is on bad smells related to service oriented architectures.We discuss in detail the state of the art on bad smells/anti-patterns for service oriented architectures.
A number of books are available on SOA-patterns and principles [8,33,34] that provide guidelines and principles characterizing -good‖ service-oriented designs.These books enable software engineers to manually evaluate the quality of their systems and provide a basis for the enhancement of design and implementation.For example, Rotem-Gal-Oz et-al.[35] suggested 23 SOA-patterns and 4 SOA anti-patterns and they described their effects, causes, and corrections.Erl, in his book [33], presented 80+ SOA design, implementation, security, and governance-related patterns.Kr´al et al. [34] elaborated 7 SOA anti-patterns resulted due to the poor practice of SOA rules.Brown et al. [36] provided the set of 40 anti-patterns.Dudney et al. [37] presented 52 anti-patterns in SOA, and especially in the area of Web-services.
There are few contributions on the identification of patterns from SOA [38,18,39].Upadhyaya et al. [39] presented an approach to detect 9 SOA patterns.Demange et al. [40] presented an approach to detect five SOA patterns from two SOA based systems.It is revealed through the review of literature that the research on Service Oriented Architecture still needs to be explored.Many detection techniques and tools are presented in the literature [21,23,25,26] that focus on specification and detection of OO anti-patterns.These OO based techniques did not give a viable solution for the identification of anti-patterns that are pointed out in webservices.There is a difference between structure of Object Oriented software applications and applications developed using web services.A limited number of approaches are available for the identification of the WS anti-patterns.Moha et al. [9] presented a technique supplemented with a tool SODA to specify and identify the anti-patterns in SCA systems.Authors performed experiments on two different corpora i.e., Home automation system and Frascati service component architecture.Authors apply algorithms that are not generated manually and they performed experiments on a number of SCA systems to gain the best accuracy.Hence, this approach can only tackle the SCA modules build up using the Java language and are not able to tackle the other SOA technologies like J2EE, SOAP and REST.
Rodriguez et al. [41] described EasySOC and provided a set of guidelines for service providers to avoid bad practices during writing WSDLs.Authors identified eight poor practices that are used to form WSDL template for Web-services.These heuristics are the rules that use pattern matching.A toolset is developed that enforces implementation of guidelines.Authors evaluated effectiveness of the toolset by performing www.ijacsa.thesai.orgexperiments.However, authors did not examine the quality related issues in the web service design.
Coscia et al. [42] presented a statistical correlation analysis on the number of traditional OO metrics and WSDL-level service metrics and found a correlation between them.Antipatterns in SOAP based web services and REST are introduced first time in [13,15,18].These authors used natural language processing and source code metrics to detect anti-patterns.Anti-patterns of SOAP based web services are detected with high precision and recall but only for some specific services.The tool SODA-W, an extension of SOFA framework [9] uses already established DSL for the detection of SOAP and REST services.
The state of the art approaches discussed above reflects that a large number of authors focused on the detection of anti-patterns from object oriented software projects.We present summarised information about SOA based anti-pattern detection approaches in Table 1.We also realised that SOA based anti-pattern detection approaches focused towards antipatterns detection for Service oriented architecture specifically for SOAP(Simple Object Access Protocol) based services.We found only three articles on REST APIs anti-patterns detection techniques [15,18,19].The emphasis of above discussed approaches was not on the detection of the anti-patterns in the service interfaces.Sindhgatta et al. [43] presented a comprehensive literature survey on service cohesion, coupling, and reusability metrics, and they come up with five new cohesions and coupling metrics that are set as a new service design requirement. The threshold values of metrics are constant in most cases and they are based on one's experience [49].
 A number of approaches in literature did not mention the accuracy of anti-pattern detection [51,52,53] that is important for the effectiveness of any approach.
 Based on the above mentioned limitations, we propose unification of metrics-based and parsing based techniques that not only improve the scope in order to identify number of anti-patterns but it also improves accuracy.The required metrics are obtained from the SoaML of Enterprise Architecture, in spite of reinventing the wheel and by examining them directly from the source code.

III. SPECIFICATION OF ANTI-PATTERNS
The specification of web services related anti-patterns is primary step for their accurate detection from web services.The specification of anti-patterns in literature is textual that is hard to use and describe.Due to unavailability of standard specification of web service anti-patterns, we present specification of 10 selected anti-patterns in this section.Our specifications contain detailed information that is important to understand and detect these anti-patterns.The specifications are further used by our approach for the detection of these antipatterns.We selected these 10 anti-patterns for the specification and detection due to their common existence in different web services.

1) God Object Anti-Pattern
Name: God Object Web-service Derived from: God Class or Blob in OO Anti-pattern Short Description: An object that contains all the information related to the whole service and this object also has many methods.This makes its role in the source-code -god-like‖.

Metrics rule:
God object exists if the service contains: Violated Principle of Abstraction: This anti-pattern occurs when a class is used as a holder for data without any method of operating on it.

Metrics rule:
Data Web service exists if the service contains: High accessor operations with few parameters and has high cohesion and high primitive parameters where, Accessor Operations > 50 < 73 and with few parameters and lcom3<=0 and primitive parameters >100 3) Fine Grained WS Anti-pattern Name: Fine Grained Web-service Short Description: Fine-grained web-service description regards tiny services out of which the larger ones are composed.That larger one needs to have many coupled webservices.Therefore, it gives rise to higher development complexity, reduced usability.Individual Web-service is less cohesive due to related operations that spread across services of an abstraction.

Metrics rule:
This anti-pattern exists if a service contains: Few operations and has low cohesion and has very high coupling where, Operations >=1 And <=2, Low Cohesion >=1 And <=2, Coupling >=1 And <=4 4) Ambiguous Name WS Anti-pattern Name: Ambiguous Name Short Description: When the developers use the key terms like Port-Types, operation, and message that contains too short and long, or too general terms, or even show the improper use of verbs.And ARIO is calculated as all meaningless operations name having length less than 3 and greater than 30.

6) LowCohesiveOperations in the Same Port-Type Antipattern
Derived from: Metric Cohesion Short Description: Many unrelated operations in one port type.

Impacted quality attributes: Flexibility and Effectiveness
Violated Principle: The modularity of a system is composed of a set of cohesive and loosely coupled modules

Violated Principle: Violation of coupling and cohesion
Issues: Difficult to infer the order of invocation gives rise to maintenance issues.

Metrics Rule:
Chatty Web-service exists if service contains:

Low Cohesion with High Accessor Methods And Has Low Availability And High Response Time And Many Methods.
Where Low Cohesion >0 And Accessor Methods >=101 And Many Methods >70

9) CRUDy Web-Service Anti-pattern Derived from: Chatty Interface anti-pattern
Short Description: A web-service design that contains CRUD-type operations, e.g., create (), ready (), delete (), update ().Interfaces designed may have several methods need to be called to accomplish a goal which makes it chatty.
Violated Principle: This web service may violate share only schema and well-defined boundaries tenets that are important for composition of web services

Metric Rule:
A web-service is Chatty if it contains: Many CRUD-type operations and LOW cohesion and high accessor operations and high procedures LCOM3 <=0 and accessor operations>100 and procedures >70 Crudy Operations>1 Where CRUD-type operations >1

10) Loosey Goosey Web Service Anti-pattern Name: Loosey Goosey Web Service
Short Description: Services are designed in a complex way that creates problems for further service extensibility and www.ijacsa.thesai.orgfunctionality.Services are tightly coupled and not able to answer the user request.

Metris Rule:
A web service is Loosey goosey if the service interface implementation is single tier and services are loosely coupled And less cohesive

DIT<1 AND AND CBO>1 AND LCOM3>0
Where DIT: Depth of inheritance

IV. DETECTION APPROACH
The motivation of our proposed approach stems from our previous work [49] presented for the detection of code smells from different open source software projects.We used the concept of contract first approaches for the implementation of our approach.Contract-first approaches focus on WSDL document to design first and then write that contract by using any programming language.Mostly, web designers and developers prefer this schema as WSDL schema is far richer as compared to the code you designed in any programming language.In different implementation scenarios, XML schema restricts the size of string and can apply different patterns to use contract detail like the use of regular expressions.Moreover, different tools can be used to convert schema file into HTML documentation.The architecture of proposed approach is presented in Figure 1.We input standard definitions of web services discussed in the previous section.The definitions include static and dynamic properties of web services.The static properties include static features of web services such as number of operations, number of port types, number of parameters etc.The dynamic properties include features such as response time and availability.The metric rules are composed based on the static and dynamic properties of web services.The approach applies these metric rules for the detection of a specific anti-pattern.Our detection algorithms use the metrics (i.e.SoA Modelling Language) / SoAML generated by Enterprise Architect.The approach follows three steps process as shown in Figure 1.

Step1
 The interfaces of web services are reverse engineered using JAVA2WSDL 1 tool based on the contract first concept.
 Dynamic properties of web services are measured using SAAJ 2 and SOAP UI 3 tools.
Step 2  The source code is reverse engineered into an intermediate form using Sparx System Enterprise Architect tool.
Step 3  Anti-pattern detection engine is developed based on the static and dynamic properties of each anti-pattern obtained from steps 1&2.
We discuss EA data model, SQL queries and limitations of approach in the following subsections:

A. EA Data Model
Our approach depends on Sparx System Enterprise Architect data model that is directly generated from source code.Sparx System Enterprise Architect 11 has the ability to generate data model of different languages directly from the source code.Instead of reinventing the wheel, we relied on the use of metrics i.e., SOA data model to extract relevant features related to any given anti-pattern.
We used SOAP-UI for parsing the code and SQL to extract the required data for the detection of Web-service related antipatterns from the Service Oriented Modelling Framework of Enterprise Architect.We selected Enterprise Architect tool due to its ability to generate well structured, self-explanatory and detailed (metrics) data model from the source code of 13 programming languages.

B. Structured Query Language
Our approach is based on SQL to extract data from the data model of Sparx System Enterprise Architect.Structured Query Language is very useful database Query language capable of extracting any required data from the Database model.SQL is having enough types and clauses through which we can extract (delete or alter) any required data (if present) from the SQL database.SQL Queries are useful to retrieve huge amount of data and records from database effectively and efficiently.SQL based databases established standards that is adopted by ANSI & ISO.The syntax of SQL commands is simple like English statements.
Examples of SQL commands that we used in our prototype for extracting data from the data model of Enterprise Architect Modelling tool are given below:

C. Limitations of Approach
To detect any given anti-pattern, our approach depends on the metrics i.e., data model of Enterprise Architect.One should have prior knowledge about internal structure of database model created by Sparx System Enterprise Architect to write SQL queries.However, the data model is created only once by reverse engineering source code and it is updatable.A second limitation of our approach is that when we publish contract first then it is harder to change that contract.

V. PROTOTYPING TOOL
A prototyping tool is developed to realise concept of approach called Specifying Web-service related anti-patterns and Detection approach named as SWAD.SWAD is an Enterprise Architect plug-in developed using C# language of dot.Net Framework 4.5.The prototype tool is platform independent and it can be integrated with other tools such as IBM Rational Rose, Borland Together and IBM Rhapsody.We selected Enterprise Architect due to our prior experience of using this tool for different other projects [17,49].Enterprise Architect has very rich modelling and reverse engineering features for different programming languages.It is easily extendable for multiple languages due to the support of reverse engineering source code of 13+ programming languages.It also generates metrics for the source code written in multiple languages and these metrics are used for the detection of antipatterns.It directly reverse engineers source code of web services into SOA data model.A screenshot for the user interface of prototyping tool is given in Figure 2.

Intermediate representation of Source Code
DataBase Anti-patterns Detection Engine Step 3 www.ijacsa.thesai.orgTo demonstrate that SWAD has few distinct features, we compared it with existing state of the art tools SODA-W [13] and P.E.Algo [14].Table 2 presents a comparison of the different features of SWAD with the two other tools available in the literature.SWAD prototyping tool has a number of features that makes it unique to other two tools.SWAD is scalable and flexible due to the support of Enterprise Architect for generating metrics from various languages.

VI. EVALUATION OF APPROACH
Evaluation of an approach is required to measure its quality, accuracy and effectiveness.To evaluate our approach, we applied SWAD on two distinct sets of WSs i.e., 7 weather related web-services and 60 finance related web-services.These sets of web services are selected due to the availability of their results.We compare our results with two existing state of the art techniques [13,14] used for detection of anti-patterns from web services.Table 3 shows the statistics of examined web services extracted using CLOC 4 tool available freely on the web.

A. Experimental Results
We selected 60 weather and 7 finance related web services to evaluate our approach and recovered 10 anti-patterns.We selected these datasets due to their free availability and comparison of our results with state of the art approaches.We combine SQL queries and source code parsing methods and these methods work parallel to detect anti-patterns with better accuracy.The reason for their selection is that SQL queries are easy to customise for recovering anti-patterns with slight variations.Secondly, we have very limited number of approaches available for the identification of web-services related anti-patterns.6 and 7 shows the comparison of the detection results of the anti-patterns related to the web-services using Parallel Evolutionary Algorithm (P.E.Algo) and our approach i.e., specifying Web-service related anti-patterns and Detection approach.Both tables listed few web-services on which detection have been performed to assess how efficiently the number of WS-related anti-patterns identified in each given web-service.It can be seen from Table 8 that only one or two WS-related anti-patterns are detected in each web-service.For instance, in the web-service named xOutlook only two antipatterns have been detected using P.E Algo approach.Similarly, Data Web Service and Cruddy Web Service antipatterns are detected from xMaster web-service using P.E Algo technique.We can see that our approach is capable of detecting a large number of anti-patterns from different web services as Many methods and has very low cohesion, high responsetime and low-availability where, Many Methods >=10, Cohesion >= 1, High Response-Time >=12) Data Web-service Anti-pattern Name: Data Web-service Derived from: Data Class in OO anti-patternsAlso known as: -Data class‖ -record [class]‖ -no-command classes‖Variants: -Data clumps‖, -data container‖ Short Description: A web-service that performs information retrieval tasks in a distributed environment through accessor operations, like getters and setters.
Principle: This anti-pattern arises when the class name has a verb only and hold one method with the same name as the class and class has no inheritance www.ijacsa.thesai.orgAlso known as: -Operation-class‖, -method turned into class‖, -single-routine-classes‖ Metris Rule: A service contains: Too long or too short signatures and has too many general terms in operations where, COUNT [Operations signature length<3 or Operations Signature length > 30] >1 or Ambiguous operations name should have any one ( arg, var, obj, foo, param, in, out, str ) >1 5) Duplicated Service Name: Duplicated Web-service Derived from: Duplicated class in OO anti-pattern following silo approach Short Description: Duplicated Web-service contains identical-operations with the similar names and message parameters.Violated Design Principle: This anti-pattern occurs when two or more abstractions are identical sharing commonalities with their improper use in the design Metrics Rule: A web-service having Identical Operations and Identical Port-Types where, ARIP > 1 And ARIO>1 ARIP= Average Ratio of Identical Port-Types, ARIO= Avg.Ratio of Identical Operations where, ARIP count all ambiguous names starting from (arg, var, obj, foo) The service contains: Many methods and has very low cohesion NOD >=1 and <= 70 And ARAO <=27 ARAO= Average ratio of accessor operations, NOD= Number of operations declared 7) Redundant Port-Types Anti-pattern Name: Redundant Port-Types Derived from: Data Replication Enterprise SOA Antipattern Also known as: -Similar Signature Class‖, -split-identity‖, -redundant-classes‖, etc.Short Description: When a WS contains multitude Port-Types and is composed of a number of redundant operations handling the same messages.Variants: -Duplicate-design-artifacts‖ Violated Principle: This anti-pattern arises when two or more classes have split-identity Metris Rule: Web-service contains: Many operations and has many porttypes resulting in high cohesion where, NOPT>1 And NPT >1 NOPT = Num of Operations in Port-Types, NPT= Number of Port-types 8) Chatty Web-service Anti-pattern Short Description: Chatty-WS is an anti-pattern in which numerous attribute-level operations like getters and setters exist in order to complete an abstraction.

Fig. 2 .
Fig. 2. User Interface for detection of Anti-patterns

TABLE I .
SUMMARISED INFORMATION ABOUT SOA ANTI-PATTERN DETECTION TECHNIQUES It is observed that many techniques have used metrics for the identification of the anti-patterns. Different approaches applied source-code parsing techniques to identify the anti-patterns.Source code parsing techniques include the statistical collection of data like counting Lines of Code, measuring Switch Statement Cases and matching or finding other syntax etc. [49].

TABLE II .
COMPARISON OF SWAD WITH SODA-W AND P.E.ALGO TOOLS

TABLE III .
STATISTICS OF EXAMINED WEB SERVICES

TABLE VI .
COMPARISON OF RESULTS FOR WEATHER RELATED SERVICES

TABLE VII .
COMPARISON OF RESULTS FOR FINANCE RELATED WEB-SERVICESB.Comparison of Results with P.E AlgorithmTables www.ijacsa.thesai.orgcompared to other two state of the art approaches.Figure3shows the variation of results by three different approaches on

TABLE VIII .
COMPARISON OF RESULTS GENERATED BY SWAD