2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications;

Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing

Semantic web services discovery adopting SERIN

José Renato Villela Dantas Hermano Albuquerque Lira

Serviço Federal de Processamento de Dados (SERPRO) Serviço Federal de Processamento de Dados (SERPRO)
Av. Pontes Vieira, 832 Av. Pontes Vieira, 832
60.130-240 – Fortaleza – CE – Brasil 60.130-240 – Fortaleza – CE – Brasil
Email: jose.dantas@serpro.gov.br Email: hermano.lira@serpro.gov.br

Bruno de Azevedo Muniz
Universidade de Fortaleza (UNIFOR)
Av. Washington Soares, 1321 J-30
60.811-341 – Fortaleza – CE – Brasil
Email: brunoamuniz@gmail.com
Tadeu Matos Nunes
Universidade de Fortaleza (UNIFOR)
Av. Washington Soares, 1321 J-30
60.811-341 – Fortaleza – CE – Brasil
Email: tadeumatos@gmail.com
Pedro Porfı́rio Muniz Farias
Universidade de Fortaleza (UNIFOR)
Av. Washington Soares, 1321 J-30
60.811-341 – Fortaleza – CE – Brasil
Email: porfirio@unifor.br

Abstract—Service-based architecture (SOA) are extensively
adopted in web applications. In this scenario, REST-based web
services has become a large adopted standard. The addition of
semantics enhances the web services description, which enables
automatic agents to discover them and to make calls. However,
the existence of many different languages to semantically describe
services makes it difficult to discover and to select the service
that best attends a requirement. Furthermore, most of these
languages does not attend to describe RESTful services, making
the discover process even more difficult. This work proposes
a RESTful semantic web service discovery architecture based
on semantic interfaces (SERIN). SERIN intends to semantically
described RESTful web services through an annotated ontology.
We present a study showing that is possible to adopt the proposed
architecture to implement a semantic service-based application,
with minimum development effort, that enables software agents
to automatically discover and to make service calls in order to
execute a determined task.
Index Terms—Semantic Web, web service discovery, semantic
interface, SERIN, RESTful
I. I NTRODUCTION
In the last decade, the popularity of webs services has
raised from day to day. Web services are based on SOA,
Service-Oriented Architecture, which describes means to re-
use and to integrate systems. It allows the interaction between
a service provider and a service consumer.
The arrival of semantic web [1] has provided additional
features to knowledge representation that the web services
provide. The basic technology to make semantic web possible
is the adoption of ontologies. An ontology is an explicit speci-
fication of a shared conceptualization [2]. It defines concepts as
classes, properties, and relationships between them. Ontologies
help to organize the heterogeneous knowledge in the Web.
More recently, OWL (Web Ontology Language) [3] became
the W3C recommended language to represent ontologies.
RDF (Resource Description Framework) [4] is another widely
adopted standard used to represent Web resources.
Semantic web services were introduced by McIlraith [5].
Part of the semantic web vision intends to markup web service
descriptions to make them computer-interpretable. Markup
makes use of ontologies to provide sharing, mapping, and
reuse. They provide semantics for the web service description
and for the data they provide. This allows software agents to
reason about web services to perform operations like automatic
discovery, selection, composition, and execution.
From all these tasks, this present work focus on Web
service discovery. Web service discovery is the process of
identifying the service that best matches some user provided
characteristics. Usually, the service is described as a function
of its inputs, outputs, preconditions, effects, and the non-
functional properties. The discovery process essentially tries
to identify where the web services are published and to
compare the service descriptors against the user requirements
to finally select one or several services that attends user
needs. Despite the efforts to implement languages to describe
web service functional specifications and architectures to find
these services, recent works still consider that the web service
discovery is a complex task.
One cause that hampers the web service discovery is the
heterogeneity of description languages they adopt. There are
many proposals for SOAP/WSDL web service descriptions
based on several languages but they lack a standard language
that is shared among them. The absence of a shared knowledge
makes difficult to identify a service or a resource on the Web.
On the other hand there are only few works that proposes
REST-based web service description.
The present work proposes a web service discovery mecha-
nism based on a single semantic interface. Our proposal adopts
SERIN[6] specification to functionally describe the semantic
web services. SERIN is an annotated ontology that provides a
mechanism to markup web services functionalities and means
to locate service endpoints. As an ontology, by definition, is
a shared knowledge, such interface provides a web service
description that both client agent and service provider know.
Using SERIN specification it is possible to build an ar-
chitecture to discover the web services from providers that
implements one or several semantic interfaces. Basically the
discovery architecture considers the existence of a crawler
agent that searches the Web, it finds the SERIN-based services,
and creates a inverted-index repository with the host addresses

978-1-5090-0154-5/15 $31.00 © 2015 IEEE 387

DOI 10.1109/CIT/IUCC/DASC/PICOM.2015.55
that provides the services and the semantic interfaces they
adopt.
The remainder of this article is provided as follow: section
II presents a motivation scenario; section III resumes the
web service discovery process; section IV revisits the SERIN
specification; section V presents our proposal for web service
discovery; section VI analyses the adoption of our proposal in
a study scenario; section VII revisits recent state-of-art works
about RESTful semantic web service discovery. Finally section
VIII presents our conclusions and proposals for future work.

II. S CENARIO AND MOTIVATION

In order to motivate our approach, we present a semantic
web typical scenario involving a person who wants to schedule
a appointment with a medical doctor. A software agent receives
a task to automatically set up this appointment. The human
user provides the software agent some minimum data about
his/her objective, like, for example, medical specialty, date
range, time range, and location. The software agent execute
queries on known clinical servers trying to match their re-
sponses to the user request. Figure 1. Clinic scenario messages exchange.

The user then receives a list with all found options. He

chooses one and he informs the software agent to set up the
appointment to this option. The software agent sends a request
with all necessary data to the selected server which persists the
data and it sends back a response with the appointment data.
The communication between the client agent and the clinic
host needs a shared vocabulary. The Clinic ontology provides
the necessary shared knowledge as it acts as a semantic
interface.
knowledge, even less works pay attention to build a
index for the services.
• Discover which service attends the user needs. Usu-
ally, the user requirements are described by informal
documents and they are implemented hard-coded in a
system that uses the services. The service descriptors
describe its syntax which is not enough to identify the
right service with a high precision level.

The figure 1 presents the sequence of the message exchange
for these steps. Three elements participate in this scenario: a
client, a discovery server, and a service provider. Five steps
resume the basic query operation:
1) The agent sends a request to get a list of available
servers that implements the clinic interface;
2) For each host in the list, the agent sends a request to
get the list of medical doctors;
3) For each medical doctor in the response list, the agent
sends a request to get his/her schedule availability;
4) The user then chooses one or more doctor and sched-
ule date and time;
5) The software agent sends a put request to insert data
to set up an appointment.
This scenario brings the need to seek and find a set of ser-
vices and select from that are relevant to the task execution. In
others standard service-oriented architecture, mainly adopted
in the Web environment, we can identify some difficulties in
each task:
• Find out which providers offer the services. Most
service architectures works with a centralized registry
server (UDDI [7]) where the providers have to explic-
itly register their services. Few other works proposes
a decentralized architecture where there is no need
for a centralized registry server. The services can be
found in peer-to-peer endpoints. For the best of our
• Select the services that best fit the user needs. The
service selection evolves the matching of the service
execution with the non-functional user requirements.
III. S EMANTIC WEB SERVICE DISCOVERY
To achieve the vision of integration between systems, it
is necessary to establish a common architecture based on
some standards. Nowadays two standards are considered. The
first web service architecture is based on SOAP (Simple
Object Address Protocol), WSDL (Web Service Description
Language), and UDDI (Universal Description, Discovery, and
Integration) [7].
The second architecture is based on REST (Representa-
tional State Transfer) standard [8]. REST architectural style
intends to be loose coupled. One of the main REST constraints
considers that all exchanged messages is self-contained, i.e.,
all needed information to execute an operation is embedded
within the message. For this reason, usually this service does
note have a description file.
Web services technology is SOA (Service-oriented archi-
tecture). This architectural style allows re-use and system
integration in order to create new systems [9]. SOA enables
system and resources integration by
• representing each resource as service with a standard-
ized interface;
• enabling a service to exchange structured information;

388
 • coordinating and mediating between services.
SOA takes two actors. At one side, a service provider
publishes an interface, and defines the execution of a web
service. The client discover available services and consumes
the service.
Cardoso [10] divides the web service discovery process
in several tasks: service advertisement, service mediation,
service storage, service request, service matchmaking, service
negotiation, and service selection. From all these tasks, the
service matchmaking is considered the most complex and
difficult task in the discovery process. Many researches try
to improve performance or to reduce the distance between the
user goals and the service descriptions.
Web service discovery is the process of identifying the
service that best matches some user provided characteristics.
Usually, the service is described in function of its inputs, out-
puts, preconditions, effects, and the non-functional properties.
The discovery process tries to match the service descriptor
with the requirements descriptor. The matching task usually
considers some degree of matching [11] as an indicator of
similarity between requirements and service descriptors.
Figure 2 represents a generic web service discovery archi-
tecture. It considers four actors: a client; a registry server; a
match, mediator, and selector engine; and a service provider.
In a semantic web scenario, a service provider adopts a
description language, like OWL-S and WSMO among others,
and an ontology to provide a service description. Thus, the
provider register this description in a central register server,
like, for example, an UDDI server. For its time, the client
works with the registry server and with the selector engine to
discover and to select the service that best fit the client needs.
The client then requests the selected service to the provider
which sends the response with the desired results.
Considering an automatic discovery, selection and invoca-
tion scenario, the client is a software agent that executes these
operations. It works based on user requirement descriptions.
Figure 2. Generic centralized discovery architecture.
The increasing adoption of web services brings the problem
of locating the appropriate services from the vast number of
available options. Despite different solutions to this problem
have been proposed, Pilioura and Tsalgatidou [12] mention
some reasons that limit the effectiveness of these solutions:
• most of the solutions are syntactic-based;
389
• Most of the solutions are not scalable, meaning they
are not able to consider a large number of services,
service providers, and service requesters;
• Current solutions are incompatible.
Recently, some reviewers have pointed out some challenges
about the whole web service discovery and composition pro-
cess that are still open or barely solved.
Dong et al [13] enumerates some research challenges,
from which we emphasize the lack of means for handling the
heterogeneity of ontologies; the lack of semantic models of
service processes; the lack of matchmakers employing index-
based mechanisms; scalability
Ngan and Kanagasabai [14] also investigates web ser-
vice discovery challenges. They consider some relevant open
researches: RESTful services (or web APIs) need semantic
descriptions to facilitate automated discovery; resolving het-
erogeneity when discovery process involves several description
languages, which pose strong limitations in interoperability;
accuracy, scalability, and delivery of precise discovery results;
As a contribution to solve or, at least, to minimize these
web services issues, the present work proposes the adoption of
Semantic RESTful Interfaces as web service description. The
present architecture intends to
• Define a semantic description for the RESTful web
services, which enables software agents to automati-
cally process the services responses;
• Promote the adoption of semantic interfaces as a
homogeneous option to solve the heterogeneity of
languages and ontologies that exists nowadays for
semantic service descriptions;
• Work on a decentralized architecture which gains
scalability and reduces failure because it reduces de-
pendency from one single centralized server;
• Provide a better accuracy for the service selection
because it reduces the need for service matching.
IV. S EMANTIC R ESTFUL I NTERFACES
Semantic RESTful Interface (SERIN) is basically an an-
notated ontology whose classes and properties characterize
uniquely and semantically available resources.
SERIN specification defines an upper ontology with the
annotation properties, some additional concepts, and their
relationships. Figure 3 shows the SERIN ontology elements.
It presents four annotation properties which represents the
available operations over the services. Further, it presents
a minimal set of concepts necessary for service discovery
process.
Any ontology can import SERIN ontology in order to
create a semantic interface. The ontology builder applies the
SERIN annotations on the ontology classes. The resulting an-
notated ontology is considered a Semantic RESTful Interface.
Four annotations types can be added to an ontology. These
annotations indicate the existence of four web service types,
GET, POST, DELETE, and PUT. The four web service types

Figure 3. SERIN ontology.
are mapped into the four relative HTTP methods. They define
which RESTful Web Service should be implemented for each
resource.
A set of RDF triples, i.e., an RDF instance, represents each
resource. Each resource has an identifier called {rdfid}. The
RDF instance granularity is to low. So, RDF instances are not
enough to define a business process. Usually, it is necessary a
set of instances to define an business entity.
The GET method requires a key, as a parameter, indicating
a single instance to be recovered. The method returns a list of
all class instances if the requester informs no parameter.
Each host that implements a semantic interface must im-
plement one RESTful web service for each operation, i.e., for
each annotation in a class.
The option to use only four web service types, whose
semantics is pre-defined, makes the SERIN semantics much
simpler than proposals that specify semantics for SOAP/WSDL
web services. Semantic Interface properly establishes resources
semantics. The four possible operation semantics follows
CRUD model (create, Read, Update, Delete) usually associated
with HTTP verbs.
Since this is an interface, the matching is always accurate.
This provides higher scalability proposal to make it more
attractive to the Web environment.
A. Semantic web service addressing
Besides standardize semantics, SERIN contributes with
standardize services URLs. Each service URL is divided into
two parts. The first part identifies the host. The second part
semantically identifies the resource (by using the semantic
interface).
The address convention format is:
h t t p : / / { host }/{ i n t e r f a c e }/{ c l a s s }/{ r e s o u r c e }
where:
• {host} - IP or DNS host address.
• {interface} - ontology URI that represents the seman-
tic interface.
• {class} - ontology class identifier.
390
• {resource} - resource identifier.
Figure 4. URLs of three hosts that implement Doctor resource
Figure 4 is an example of a standardization in which a
patient agent consults a set of agents representing clinics and
doctors. In the example, there are three clinics that respectively
offer their services on hosts: example-A.com, example-B.com,
and example-C.com. All three hosts meet the same semantic
interface, called serin/clinic.owl. According to the interface,
each host possess features that are instances of the Doctor
class.
When the host runs the web service in example-
A.com/serin/clinic.owl/Doctor, it produces, in response to
some patient request, the list of physicians (same as doctor)
available on Medical Clinic A (RDF). Running the relative web
services, for the same interface in the two other hosts, should,
respectively, provide support hours available on Medical Clinic
B and Medical Clinic C.
The adopted convention is particularly simple when it is
applied to RESTful web services. However, it is possible to ap-
ply it to traditional web services. In the case of SOAP/WSDL
architecture, the address composed according to the convention
proposal refers to a WSDL file that describes the service.
Listing 1 presents a grammar that exemplifies the formation
of the web service URL implemented for Figure 4 host C.
Listing 1. Grammar to generate a RESTful web service URL.
{host} : : = example−C . com
{ i n t e r f a c e } : : = e x a m p l e . com / c l i n i c . owl
{class} ::= Clinic
{resource} : : = / s e r i n / { i n t e r f a c e URI } / { c l a s s name}
{ s e r v i c e U R L } : : = { h o s t URL}{ r e s o u r c e URI}
Using the grammar above, a RESTful web service URL
can be easily derived from the ontology URI plus each host
URL. Following the grammar above, a possible resource URI
would be:
{ r e s o u r c e } = / s e r i n / c l i n i c . owl / C l i n i c
and a service URL would be:
{ s e r v i c e U R L } = e x a m p l e . com / s e r i n / c l i n i c . owl / C l i n i c
 V. A RCHITECTURE FOR WEB SERVICE DISCOVERY
The present work proposes a web service discovery archi-
tecture based on a centralized inverted-index which works on
a server composed of four components:
1) An index repository that maps semantic interfaces to
hosts;
2) A scanning module - a crawler that scans Web
contents, updating the index;
3) A manual query module - a site where users can query
the index;
4) An automatic query module - semantic Web services
that automatic agents can request data from the index
repository.
Figure 5 presents all elements from our discovery process.
The gray areas identifies the four main architectural agents
which are the service client, the Host, the service descriptor,
and the discovery server. Domain ontology, using SERIN
ontology annotations, provides the service description. They
act as a service semantic interface. All other elements, i.e.,
the client, the host, and the discovery server, know the same
semantic interface. Sharing this knowledge enables that agents
from both sides execute automatic requests and properly
process the responses. The host acts as a service provider.
It is the data owner. It provides concrete implementations of
the services that the interface describes. The client can act
either as an automatic software agent or as an human user
performing requests to the web services. Finally, the discovery
server crawls the Web trying to find out SERIN semantic
interfaces. It maintains a index repository with found hosts
and found interfaces. Additionally, it provides manual and
automatic query module where users can consult the index
repository.
Figure 5. SERIN discovery server architecture.
A. Index repository
The index repository stores the addresses of service
providers, the semantic interfaces, as well as the known rela-
tionships among them. The repository database is an instance
of SERIN ontology. It is possible, but not mandatory, to stores
hosts and interfaces as RDF triples. The RDF statements are
in the form:
< s e r i n : Host> < s e r i n : i m p l e m e n t s > < s e r i n : I n t e r f a c e >
391
or
< s e r i n : I n t e r f a c e ><s e r i n : i s I m p l e m e n t e d B y ><s e r i n : Host>
Optionally, it is possible to store the index in a relational
database. In such case, SERIN ontology classes Host and
Interface and their relationships works as a database schema.
B. Scanning module
The scanning module (crawler) crawls the Web looking
for hosts that implements semantic interfaces. The discovery
process works in two steps. At first, the crawler identifies a set
of hosts. Secondly, it identifies which interfaces are available
in each host.
There are several alternative processes to identifies the
hosts. The final objective is to discover host addresses that
are candidate to execute a semantic interface inspection. The
host discovery can start with a regular keyword search process.
In this case, the discovery server works with search engine
APIs, like Google Custom Search API1 or Bing Search API2 ,
starting from user-defined keywords. Complementary or as
another possibility, it is possible to execute a web crawling
process, starting from any web page to addresses linked to the
page. It is possible also to inspect all domains related to an
upper domain. For instance, the crawler make requests to all
servers associated to the .gov or the .edu domain.
Once the crawler has identified the hosts, the crawler sends
requests to each host asking which semantic interfaces they
implement. This is a particular service that SERIN speci-
fication provides. Based on SERIN address convention, the
crawler requests the service that calls the data modeled from
the Interface class in the semantic interface that represents
SERIN itself. The address format is
h t t p : / / { h o s t } / s e r i n . owl / I n t e r f a c e
where:
• {host} - IP or DNS host address.
• serin.owl - SERIN ontology.
• Interface - Interface class name.
Excepting for the host part, that varies for each host, all
other address parts are fixed.
The scanning module update the repository of known hosts,
the repository of known semantic interfaces, and the repository
of relationship between each host and each semantic interface.
Alternatively, service providers, who wish their site or their
interface to become part of the index, can spontaneously and
manually publish their services in the index repository.
C. Web service query module
The web service query module have specific web services
to get information about indexed hosts and about indexed
semantic interfaces. It is intentionally designed to provide
information for automatic consultation.
1 https://developers.google.com/custom-search/
2 http://www.bing.com/toolbox/bingsearchapi
 All services attends the SERIN ontology that defines the
SERIN semantic interface itself. Table I presents available
methods.
Table I. AVAILABLE WEB SERVICES FOR THE DISCOVERY SERVER .
Method Description
http://{discovery server}/serin.owl/Host Returns the list of all indexed
hosts.
http://{discovery server}/
serin.owl/Host/{host id}
Returns the list of all inter-
faces that the host attends.
http://{discovery server}/serin.owl/Interface Returns the list of all indexed
interfaces.
http://{discovery server}/
Returns the list of all hosts
serin.owl/Interface/{interface URI}
that attends the interface.
Each web services responses RDF triples with the desired
data. These methods are essentially for automatic agents use.
D. Manual query module
The manual query module is an endpoint where human
users can execute queries to get the index repository data. The
manual endpoint acts as an SPARQL query engine. The user
may either write a web service URL or a SPARQL query.
It is desirable that the manual module display the responses
in a human readable format. The endpoint default result format
is a table, which is more user-friendly format. If the user
prefers, he can change the default format to RDF triples.
VI. A RCHITECTURE ANALYSIS AND RESULTS
Back to the motivation scenario, presented in section II, we
have implemented an SOA application that work as the client
agent and a server application. The whole idea is to investigate
how the SERIN architecture implementation can represent the
execution of the described scenario.
Before the scenario implementation, it is necessary to
prepare a framework where client and service provider are
going to exchange information. This framework consists of
an ontology representing the semantic interface and the dis-
covery server, both elements are precondition to the scenario
execution. In our analysis platform, the semantic interface has
classes representing medical concepts, as shown in figure 6.
In the discovery server, we have build the crawler, the index
repository, and the web services module.
Figure 6. Clinic ontology classes.
The crawler executes the search algorithm, presented in
listing 2 starting from a keyword search query. In here, we
392
have started searching using the Google Web Search API3 .
The initial keyword expression was ”medical clinic” and
”physician”.
The algorithm splits each search result to get the server
address. After, it builds the web service address based on
the SERIN address convention. Then it checks if the server
responds to the requests that verify the semantic interfaces.
Finally, if the server responses with a positive answer, the
crawler saves the results in the index repository.
Listing 2. Crawler web service search algorithm
keyword <− ” ( p h y s i c i a n ) o r ( m e d i c a l and c l i n i c ) ”
s e r v e r s <− L i s t <n i l l >
r e s u l t <− L i s t <G o o g l e R e s u l t s . R e s u l t ( keyword)>
f o r each r e s u l t
s e r v e r . i p <− s p l i t r e s u l t . u r l
u r l <− s e r v e r . i p + ” s e r i n . owl / I n t e r f a c e ”
r e s p o n s e <− r e q u e s t ( u r l )
i f r e s p o n s e = S t a t u s .OK
then
f o r each response . i n t e r f a c e
save i n t e r f a c e
Having set the discovery server, the client agent starts the
task of scheduling an appointment. The client sends a request
to the discovery server which host attends the clinic interface.
GET http://example.com/serin/serin.owl/Host
The discovery server sends a response that is a RDF with
a set of hosts.
The client agent selects a set of hosts from this list to
request for the available physicians. For example, if the client
wants to get the list of cardiologists from clinic A, it sends
the following request:
GET http://clinic-A.com/serin/clinic.owl/Cardiologist
The client does the same request to the other hosts in
the host list. Based on SERIN address convention, all URL
requests have the same syntax except for the host address part.
Each host respond with its own RDF list of cardiologists.
The following step is the selection of the physician to set
the appointment. The client agent can filter some physicians
by requesting their available schedules. It sends a GET request
like the following example. The number 1 in the URI is the
ID that identifies an individual cardiologist.
GET http://clinic-A.com/serin/clinic.owl/Cardiologist/1
Having the list of all the physician schedules, the client
selects the one it The selection criteria are based on non func-
tional requirements like, for example, geographical location,
date and time, physicians rank, and others. This selection is
not described in the present work.
Once the client has selected the physician schedule, it sends
a POST request with the appointment data. The request URL
is as follow.
POST http://clinic-A.com/serin/clinic.owl/Appointment/
The request body contain appointment data in a RDF
format. The data model is based on the clinic ontology.
3 https://developers.google.com/web-search/docs/
However it is important, the data consistency validation is not
considered here, being subject for another work.
As seen in this section, it is possible to execute all the
scheduling process automatically. SERIN offers a semantic
web service architecture which is very simple to implement
and to execute. The effort to build the framework concentrates
on building the domain ontology. The ontology annotation
process can be done in a semi-automatic manner.
Besides, the addiction of semantics for the web services
contributes to enable the automatic execution by client agents.
Semantic interfaces are essentially ontologies which are, by
definition, shared conceptualizations. The shared knowledge
enables the resource interoperability.
VII. R ELATED W ORK
The core of the present proposal is based on a language
to semantically describe the RESTful web services and on a
decentralized discovery approach.
Recent works about Semantic web service description
languages are mostly focused on SOAP/WSDL architecture.
The efforts are for semantic enrichment of WSDL service
descriptors. Most common solutions adopts OWL-S [15], like
OWLS-MX [16], OWL-S IDE [17], and WSMO [18], like
WSMO-MX [19]. Some works also adopt SAWSDL [20],
WSMO-lite [21], or WSDL-S [22].
On the other hand, we have found less solutions for
formally describing RESTful web services. Recent WSDL
2.0 specification [23] enables RESTful services description.
However it is necessary to map REST resources in operations,
inputs, and outputs to fit in a WSDL file. A more REST-
oriented specification is WADL (Web Application Description
Language) [24]. Both languages lack of semantics.
Some RESTful web services descriptions enhanced with
semantics are hRESTs [25], [26], SA-REST [27], and REST-
Desc [28]. All these proposals adds semantics to web services.
However they do not have a standard language. They also
demands a high effort to build an ontology and to annotate
the web services descriptions or the web pages that describe
the services.
The major volume of solutions for web service discovery
focuses on the matching task. Paolucci[11] has presented
a seminal work about matching where he had introduced
a degree of matching (DoM), that is a value of proximity
between the user requirements and the web service . After,
many authors have presented proposals to maximize the DoM.
The problem about matching is that it is always inaccurate,
i.e., it is very difficult to obtain a 100% degree of matching.
For the best of our knowledge, we have found no work that
gain this DoM value. This way, it always have a degree of
uncertainty or error about the selected web service.
We can avoid the problems about DoM by using a semantic
interface. This semantic interface acts as a contract where both
producer and consumer know exactly which service fits the
user requirements in a given situation.
Despite most works about web service discovery focus on
centralized approaches, mainly considering UDDI as a service
393
registry server, there are some decentralized approaches. De-
centralized discovery systems are based on distribution tech-
nologies like, e.g., peer-to-peer, to publish services descriptions
in a network.
As mentioned before, Dong et al [13] has noticed that
inside the semantic web service field very little work in the area
of index-based service discovery has been undertaken. This
area is provided mainly by some non-specialized crawlers and
index-based systems, like web page search engines or index-
based systems for non-semantic SOAP/WSDL web services.
In the present research, we have found only a few works
Semantic Web service discovery based on web crawlers:
1) OPOSSUM [29] - It is a search engine for web
services based on approximation methods based on
semantic and procedural similarity. The authors pro-
poses a matching algorithm which is, by definition,
inaccurate.
2) WESS [30] - It is a search engine for web service
descriptions, semantic or non-semantic (WSDL). It
does not considers RESTful web services because
they do not comply to a description standard.
3) WSCE [31], [32] - This work presents a discovery
model (WSCE) in a decentralized way. Their work
uses a crawler to extract web services description
from several UBR, which are local UDDI servers,
to create an index for the services.
4) Multicrawler [33] - It is more of a conventional
web crawler, searching for data in HTML pages.
The proposal enhances the search with semantic web
resource crawling and indexing.
5) Service Search Crawler [34] - It has a crawler that
searches for SOAP/WSDL services from UDDI reg-
istry server or from within web pages. All found
services are semantically enhanced with a OWL-S
description.
6) Restler [35] - It is a discovery system with a crawler
based on a language called ReLL (Resource Link-
ing Language), an ontology that describes services
through RDF triple stores with resources, representa-
tions, and links.
The advantages about a crawler-based approach is that the
service providers no longer need to register their services. The
crawler takes the responsibility for finding out the services and
for indexing them. This eliminates the need for centralized
registry servers or web service portals which are frequently
outdated.
VIII. C ONCLUSIONS
Nowadays, the RESTful web services discovery remains a
difficult task. The lack of appropriate language for description
of REST-based services complicates the identification and
selection of the best service that attends some user requirement
to execute a task. Furthermore the lack of semantics in the
description hampers software agents to execute the task au-
tomatically or semi-automatically, making mandatory the user
intervention.
In this sense, the SERIN semantic interfaces contribute to
fill these gaps providing resources to define RESTful semantic
web service descriptions. One advantage of this approach is
that SERIN is an interface. By definition, it provides a shared
description that both client and service provider know and
agree. It adopts an annotated ontology based on common and
standard languages. This makes the interface building process
very simple.
The existence of a shared ontology and an address conven-
tion enables the implementation of a discovery architecture
that is decentralized, based on a crawler that navigates the
web indexing the web services and their provider. The search
algorithm complexity is low considering that it makes direct
calls to the services that attend an interface. The crawler
eliminates the necessity of registering the services in a UDDI
server or in any other service index.
As future work, we intend to implement decision criteria
for service selection based on non functional requirements.
The verification of data integrity in the persistence operations
are a second focus in our work. Additionally, the service
composition based on this discovery architecture added to
BPMN process is subject for future research.
ACKNOWLEDGE
Jose Renato V. Dantas and Hermano A. Lira acknowledges
SERPRO, Federal Data Processing Service, for supporting this
research.
R EFERENCES
[1] T. Berners-Lee, J. Hendler, and O. Lassila, “The semantic web,”
Scientific American, vol. 284, no. 5, pp. 34–43, 5 2001.
[2] T. R. Gruber, “A translation approach to portable ontology specifica-
tion,” Tech. Rep. {KSL} 92-71, 1993.
[3] “Owl 2 web ontology language document overview,” 2009.
[4] B. Adida and M. Birbeck, “Rdfa primer,” 2008.
[5] S. McIlraith, T. Son, and H. Z. H. Zeng, “Semantic web services,” IEEE
Intelligent Systems, vol. 16, no. 2, pp. 46–53, 2001.
[6] B. d. A. Muniz, L. M. Chaves, H. A. Lira, J. R. V. Dantas, and P. P. M.
Farias, “Serin - an aproach to specify semantic abstract interfaces in the
context of restful web services,” Proceedings of the IADIS International
Conference on WWW/Internet, pp. 187–194, 2013.
[7] “Oasis uddi specification tc {\textbar} oasis,” 2005.
[8] R. T. Fielding, “Architectural styles and the design of network-based
software architectures,” Ph.D. dissertation, 2000.
[9] H. Nacer and D. Aissani, “Semantic web services: Standards, appli-
cations, challenges and solutions,” Journal of Network and Computer
Applications, vol. 44, pp. 134–151, 9 2014.
[10] J. Cardoso, Semantic Web services - Theory, tools and applications.
Information Science Reference, 2009.
[11] M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara, “Semantic
matching of web services capabilities,” in The Semantic Web —
{ISWC} 2002, ser. Lecture Notes in Computer Science, I. Horrocks
and J. Hendler, Eds. Springer Berlin / Heidelberg, 2002, vol. 2342,
pp. 333–347.
[12] T. Pilioura and A. Tsalgatidou, “Unified publication and discovery of
semantic web services,” ACM Transactions on the Web, vol. 3, no. 3,
pp. 1–44, 2009.
[13] H. Dong, F. K. Hussain, and E. Chang, “Semantic web service match-
makers: state of the art and challenges,” Concurrency and Computation:
Practice and Experience, vol. 25, no. 7, pp. 961–988, 2013.
[14] L. D. Ngan and R. Kanagasabai, “Semantic web service discovery:
state-of-the-art and research challenges,” Personal and Ubiquitous Com-
puting, vol. 17, no. 8, pp. 1741–1752, 9 2012.
394
[15] D. Martin, M. Burstein, D. Mcdermott, S. Mcilraith, M. Paolucci,
K. Sycara, D. L. Mcguinness, E. Sirin, and N. Srinivasan, “Bringing
semantics to web services with owl-s,” World Wide Web, vol. 10, no. 3,
pp. 243–277, 2007.
[16] M. Klusch, B. Fries, and K. Sycara, “Owls-mx: A hybrid semantic
web service matchmaker for owl-s services,” Web Semantics: Science,
Services and Agents on the World Wide Web, vol. 7, no. 2, pp. 121–133,
4 2009.
[17] N. Z. C. Htoo, T. T. S. Nyunt, and T. T. S. Yangon, “Semantic web ser-
vices offer discovery using owl-s ide,” in 2nd International Conference
on Signal Processing and Communication Systems (ICSPCS), vol. 6.
IEEE, 2008, pp. 1–5.
[18] U. Keller, H. Lausen, D. Fensel, R. Lara, H. Lausen, and D. Fensel,
“Semantic web service discovery in the wsmo framework,” Semantic
Web Services: Theory, Tools and Applications, no. April, pp. 1–44,
2006.
[19] M. Klusch and F. Kaufer, “Wsmo-mx: A hybrid semantic web service
matchmaker,” Web Intelligence and Agent Systems, vol. 7, no. 1, pp.
23–42, 2009.
[20] “Semantic annotations for wsdl and xml schema,” 2007.
[21] T. Vitvar, J. Kopeck, J. Viskova, and D. Fensel, “Wsmo-lite annotations
for web services,” in 5th European Semantic Web Conference, ESWC
2008, 2008, pp. 674–689.
[22] R. Akkiraju, J. Farrell, J. Miller, M. Nagarajan, M.-T. Schimidt, A. P.
Sheth, and K. Verma, “Web service semantics - wsdl-s,” 2005.
[23] R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana, “Web ser-
vices description language {(wsdl)} version 2.0 part 1: Core language,”
2007.
[24] M. Hadley, “Web application description language {(wadl)},” Tech.
Rep. TR-2006-153, 2006.
[25] D. Roman, J. Kopecký, T. Vitvar, J. Domingue, and D. Fensel, “Wsmo-
lite and hrests: Lightweight semantic annotations for web services and
restful apis,” Web Semantics: Science, Services and Agents on the World
Wide Web, 2014.
[26] J. Kopecký, K. Gomadam, and T. Vitvar, “hrests: An html mi-
croformat for describing restful web services,” Proceedings - 2008
IEEE/WIC/ACM International Conference on Web Intelligence, WI
2008, pp. 619–625, 2008.
[27] K. Gomadam, A. Ranabahu, and A. Sheth, “Sa-rest: semantic annotation
of web resources,” p. 52, 2010.
[28] R. Verborgh, T. Steiner, D. Van Deursen, R. Van De Walle, J. G. Valles,
D. V. Deursen, R. V. D. Walle, and J. G. Valles, “Efficient runtime
service discovery and consumption with hyperlinked restdesc,” Pro-
ceedings of the 2011 7th International Conference on Next Generation
Web Services Practices, NWeSP 2011, pp. 373–379, 10 2011.
[29] E. Toch, A. Gal, I. Reinhartz-Berger, and D. Dori, “A semantic ap-
proach to approximate service retrieval,” ACM Transactions on Internet
Technology, vol. 8, no. 1, pp. 2–es, 2007.
[30] O. Hatzi, G. Batistatos, M. Nikolaidou, and D. Anagnostopoulos, “A
specialized search engine for web service discovery,” 2012 IEEE 19th
International Conference on Web Services, pp. 448–455, 2012.
[31] E. Al-Masri and Q. H. Mahmoud, “Investigating web services on the
world wide web,” Proceeding of the 17th international conference on
World Wide Web WWW 08, vol. 32, p. 795, 2008.
[32] ——, “Crawling multiple uddi business registries,” Proceedings of the
16th international conference on World Wide Web - WWW ’07, p. 1255,
2007.
[33] A. Harth and S. Decker, “Multicrawler : A pipelined architecture for
crawling and indexing semantic web data,” The Semantic Web, vol.
4273, pp. 258–271, 2006.
[34] V. Kaewmarin, N. Arch-int, and S. Arch-int, “Semantic web service
discovery and integration using service search crawler,” 2008 Interna-
tional Conference on Computational Intelligence for Modelling Control
& Automation, pp. 884–888, 2008.
[35] R. Alarcón and E. Wilde, “Restler: crawling restful services,” Proceed-
ings of the 19th international conference on World wide web, pp. 1051–
1052, 2010.