Predicting Similarity of Web Services Using WordNet

Introduction

Web Services offer a promise for integrating business applications within or outside an organization. They are based on Service Oriented Architecture (SOA) (Barry, 2003) that provides loose coupling between software components via standard interfaces. Web Services expose their interfaces using Web Service Description Language (WSDL) (Christensen, Curbera, Meredith, & Weerawarana, 2001). WSDL is an XML based language and hence platform independent. A typical WSDL file provides information such as web service description, operations that are offered by a web service, input and output parameters for each web service operation. Web Service providers use a central repository called UDDI (Universal Description, Discovery and Integration) (Clement et al., 2004) to advertise and publish their services. Web Service consumers use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. Users that want to use a web service will utilize this metadata to query the web service using SOAP (Simple Object Access Protocol) (Mitra, 2003). SOAP is a network protocol for exchanging XML messages or data. Since SOAP is based on HTTP/HTTP-S, it can very likely get through network firewalls. The advantages of XML and SOAP give web services their maximum strength.

With web applications and portals getting complex and rich in functionality, many users are interested in finding similar web services. Users might want to compose two operations from different web services to obtain complex functionality. Also, users might be interested in looking at operations that take similar inputs and produce similar outputs. Let us say, web service A has an operation GetCityNameByZip that returns city name by zip code, web service B has an operation GetWeatherByCityName that returns weather by city name and web service C has an operation GetGeographicalLocationBasedOnZip that returns city name, longitude, latitude and altitude of a location by zip code. Operations from web services A and B are related, i.e., output from one operation can be used as an input to another. So, these operations can be composed to obtain weather by city name. Operations from web services A and C are similar. They take similar inputs. Outputs are also similar, i.e., output of operation from web service C is fine grained when compared to output of operation from web service A.

As more and more web services are developed, it is a challenge to find the right or relevant web services quickly and efficiently. Currently, UDDI supports keyword match just based on web service data entries in its registry. This might potentially miss out on some valid matches. For example, searching UDDI with keywords like zip code may not retrieve web service with postal code information.

Semantics of a web service in terms of the requirements and capabilities of a web service can be really helpful for efficient retrieval of web services. WSDL does not have support for semantic specifications. A lot of researches are done on annotating web services through special markup languages to attach semantics to a web service. Akkiraju et al. proposed WSDL-S to annotate web services (Akkiraju et al., 2005). Cardoso and Sheth used DAML-S (Cardoso & Sheth, 2003). DAML-S was used as annotations to compose multiple web services by (Ankolekar, Burstein, Hobbs, Lassila, Martin, McIlraith, Narayanan, Paolucci, Payne, Sycara, & Zeng, 2001). The OWL-S introduced by (Martin et al., 2004) was used by Ganjisaffar et al. as annotations to compute similarity between web services (Ganjisaffar, Abolhassani, Neshati, & Jamali, 2006), and a semantics-based composition-oriented discovery of web services based on OWL-S was introduced in (Brogi, Corfini, & Popescu, 2008). The main challenges of ontology-based approach are that manual annotation is a time consuming task and how to deal with discrepancies between ontologies.