Service Oriented Framework For Analysis



SODA-W (Service Oriented Detection for Antipatterns in Web Services)

We proposed a three-step approach, named SODA-W, for the specification and detection of SOA antipatterns in Web services.

Step 1. Specification of SOA Antipatterns: We identify the relevant properties of Web service-specific antipatterns that we use to extend our previous domain-specific language (DSL). We then use this DSL to specify antipatterns for Web services.

Step 2. Generation of Detection Algorithms: This step involves the generation of detection algorithms from the specifications in the former step. At present, we performed this step manually by implementing concretely the algorithms in conformance with the rules specified in Step 1. We plan to automate this step.

Step 3. Detection of SOA Antipatterns: We apply the detection algorithms on a set of real Web services to detect antipatterns.

approach


Despite of SODA, which aims at specifying and detecting SOA antipatterns in SCA applications, SODA-W was required and interesting due to:

<1> The architectural difference between SCA components and Web services, which implies that building blocks for SCA applications are components whereas for Web services they are services; components are coarsergrained and services are finer-grained. Thus, there will be more Web services than components in an SBS and the interactions among services are primordial;

<2> Composites, written in SCDL (Service Component Definition Language), provide components' orchestration and implementation details, whereas Web services use WSDL to describe their operations and parameters. Thus, the orchestration among services is implicit and must be inferred from the interactions among services;

<3> An SCA composite is defined for a single vendor, i.e., all the components in a composite run in a single vendor's environment; whereas Web services are completely distributed and are vendor-neutral;

<4> An SCA component implements only one interface; whereas Web services may have multiple service interfaces defined as PortTypes in their WSDL files;

<5> Within the SCA composites, the implementation details of components are defined concretely; whereas for Web services, the WSDL files hide all the implementation details.



SOA Antipatterns in Web services

The Web service-specific SOA antipatterns that are specified and detected are described here.


List of Web services

All the Web services that we experimented with are listed here.


Results

We perform the experiments on two different set of Web services: (i) a set of 13 Weather-related Web services and (ii) a set of 109 Finance-related Web services


Results on 13 Web services

The table below presents the results for the detection of the 10 Web service-specific SOA antipatterns on 13 weather-related Web services

results

[top]


Results on 109 Web services

The table below presents the results for the detection of the 10 Web service-specific SOA antipatterns on 109 finance-related Web services.

results


Detection Tool

We provide a GUI-based tool for the detection of SOA antipatterns in Web services. The users can search SOAP services using a dedicated Web services search engine www.programmableweb.com and can 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.html page.


Download ZIP

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

Download WAR

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

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



[top]



Logo Logo