An Architecture for Restful Web Service Discovery Using Semantic Interfaces

An Architecture for Restful Web Service Discovery Using Semantic Interfaces

José Renato Villela Dantas, Pedro Porfirio Muniz Farias
Copyright: © 2020 |Pages: 24
DOI: 10.4018/IJSWIS.2020010101
(Individual Articles)
No Current Special Offers


In the internet environment, web services based on representational state transfer (REST) have become the de facto standard. The addition of semantics is intended to enhance the description of web services with information that enables automatic agents to understand their data. However, the existence of different languages to semantically describe services makes it difficult to discover and select the service that best meets a requirement. Furthermore, relatively few proposals have a RESTful service semantic description, making the discovery process for RESTful services more difficult. This work proposes a RESTful semantic web service discovery architecture based on semantic interfaces (SERIN). SERIN is an ontology with annotations that semantically describe RESTful web services. This architecture enables software agents to automatically discover and make service calls in order to execute a determined task.
Article Preview

1. Introduction

REST-based (or RESTful) web services (Fielding, 2000) are widely adopted on resource-oriented architectures (ROA). They bring advantages such as scalability and general interfaces, and they separate the server implementation from the client's perception of resources (Richardson & Ruby, 2008). Furthermore, they do not obligate the provider to develop heavy service descriptions, as WSDL does for SOAP services.

Considering the increasing amount of available web services, the discovery of an appropriate one that agrees with the user's requirements is a challenge (Pakari, Kheirkhah, & Jalali, 2014). Web service discovery is the process of identifying the service that best matches some user-provided characteristics.

Most of the web service discovery research has focused on three features (Priyadharshini & Gunasri, 2013; Dong et al., 2013; Patil and Gopal, 2011): (i) matching user requirements with the service description, (ii) the existence of a centralized repository where all service providers must register their services, and (iii) the adoption of semantic web technologies to enrich the web service descriptions.

The service matchmaking (feature (i)) is considered the most complex and difficult task in the discovery process. Moreover, given de dynamic nature of available data, this problem should be solved automatically (Cerón-Figueroa, 2017). The matching task usually considers some degree of matching (Paolucci, Kawamura, Payne, & Sycara, 2002) as an indicator of the similarity between requirements and service descriptors. As discussed by Dong, Hussain, and Chang in their semantic web service matchmakers survey (Dong, Hussain, & Chang, 2013), many researchers have tried to solve the discovery problem by optimizing the matching degree. These methods essentially compute the matching degree by reducing the distance between the user goals and the service descriptions in the minimum computation time. Usually, the service is described as a function of its inputs, outputs, preconditions, effects, and nonfunctional properties. The discovery process usually tries to match the service descriptor with the requirements descriptor. Some approaches propose to use logical reasoning (Fang, 2018) or clustering (Bukhari, 2018) to organize similar web services and, thus, to improve the performance of web service discovery.

The main problem with the matching is that it is always inaccurate. The consumer establishes the minimal degree of matching that is acceptable to the task. However, this degree of matching is not precise and may lead to errors. Finding a service that has the same (or similar to some degree) inputs, outputs, preconditions and effects is not a sufficient condition for selecting a service.

Furthermore, considering the service composition context, the concatenation of services multiplies the imprecision of the matching degree, leading to a very high imprecision at the end of the service chain. For example, consider a chain with five services, each with a matching degree of 95%. The final accumulated matching degree for the whole chain will be IJSWIS.2020010101.m01

The imprecision of the matching also increases when multiple ontologies are used to annotate the user requirements or multiple ontologies are used to describe an existent service. (Fellah, 2016)

The existence of a centralized repository (feature (ii)) clearly contributes to a faster discovery process. In most research, the starting point for discovering a service is a registry server, e.g., a UDDI (OASIS, 2005) server. Nowadays, some web service portals, such as the aforementioned ProgrammableWeb and several open government data portals, like, are being adopted as tools to search for web services and APIs. All of them suffer from the same difficulty: the service provider must register its service to make it known. This obligation limits the discovery process to a single point of search, restricting the discovery process to the registered services in the repository. Such a limitation removes all unregistered web services from the discovery process.

Complete Article List

Search this Journal:
Volume 19: 1 Issue (2023)
Volume 18: 4 Issues (2022): 2 Released, 2 Forthcoming
Volume 17: 4 Issues (2021)
Volume 16: 4 Issues (2020)
Volume 15: 4 Issues (2019)
Volume 14: 4 Issues (2018)
Volume 13: 4 Issues (2017)
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing