Semantic web services discovery adopting SERIN

Semantic web services discovery adopting SERIN José Renato Villela Dantas Hermano Albuquerque Lira Serviço Federal de Processamento de Dados (SERPRO) Av. Pontes Vieira, 832 60.130-240 – Fortaleza – CE – Brasil Email: [email protected] Serviço Federal de Processamento de Dados (SERPRO) Av. Pontes Vieira, 832 60.130-240 – Fortaleza – CE – Brasil Email: [email protected] Bruno de Azevedo Muniz Tadeu Matos Nunes Pedro Porfı́rio Muniz Farias Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321 J-30 60.811-341 – Fortaleza – CE – Brasil Email: [email protected] Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321 J-30 60.811-341 – Fortaleza – CE – Brasil Email: [email protected] Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321 J-30 60.811-341 – Fortaleza – CE – Brasil Email: [email protected] 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 reuse 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 specification 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 nonfunctional 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 mechanism 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 architecture 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 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 responses to the user request. 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. Figure 1. knowledge, even less works pay attention to build a index for the services. • Discover which service attends the user needs. Usually, 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. • 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. 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. 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) 2) 3) 4) 5) The agent sends a request to get a list of available servers that implements the clinic interface; For each host in the list, the agent sends a request to get the list of medical doctors; For each medical doctor in the response list, the agent sends a request to get his/her schedule availability; The user then chooses one or more doctor and schedule date and time; 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 services 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 explicitly 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 Clinic scenario messages exchange. 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 (Representational 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 architecture). 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 standardized interface; • enabling a service to exchange structured information; • 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. 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. 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, outputs, 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 architecture. 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 invocation scenario, the client is a software agent that executes these operations. It works based on user requirement descriptions. Recently, some reviewers have pointed out some challenges about the whole web service discovery and composition process 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 indexbased mechanisms; scalability Ngan and Kanagasabai [14] also investigates web service discovery challenges. They consider some relevant open researches: RESTful services (or web APIs) need semantic descriptions to facilitate automated discovery; resolving heterogeneity 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 automatically 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 dependency 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 annotated ontology whose classes and properties characterize uniquely and semantically available resources. 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; 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 annotated 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. {resource} - resource identifier. 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 implement 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. 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 exampleA.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 apply 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. 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). 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} 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 semantic interface. • {class} - ontology class identifier. 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 architecture based on a centralized inverted-index which works on a server composed of four components: 1) 2) 3) 4) An index repository that maps semantic interfaces to hosts; A scanning module - a crawler that scans Web contents, updating the index; A manual query module - a site where users can query the index; 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. 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 specification 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. Figure 5. SERIN discovery server architecture. 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. A. Index repository The index repository stores the addresses of service providers, the semantic interfaces, as well as the known relationships 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 > 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 http://{discovery server}/serin.owl/Host http://{discovery server}/ serin.owl/Host/{host id} http://{discovery server}/serin.owl/Interface http://{discovery server}/ serin.owl/Interface/{interface URI} Description Returns the list of all indexed hosts. Returns the list of all interfaces that the host attends. Returns the list of all indexed interfaces. Returns the list of all hosts 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 discovery 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. 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 functional 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/ Figure 6. Clinic ontology classes. The crawler executes the search algorithm, presented in listing 2 starting from a keyword search query. In here, we 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. registry server, there are some decentralized approaches. Decentralized discovery systems are based on distribution technologies 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 indexbased 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) 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 RESToriented 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 RESTDesc [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. 2) 3) 4) 5) 6) OPOSSUM [29] - It is a search engine for web services based on approximation methods based on semantic and procedural similarity. The authors proposes a matching algorithm which is, by definition, inaccurate. 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. 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. 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. Service Search Crawler [34] - It has a crawler that searches for SOAP/WSDL services from UDDI registry server or from within web pages. All found services are semantically enhanced with a OWL-S description. Restler [35] - It is a discovery system with a crawler based on a language called ReLL (Resource Linking Language), an ontology that describes services through RDF triple stores with resources, representations, 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 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. 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 automatically or semi-automatically, making mandatory the user intervention. Despite most works about web service discovery focus on centralized approaches, mainly considering UDDI as a service 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 convention 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. [15] [16] [17] [18] [19] [20] [21] [22] [23] ACKNOWLEDGE Jose Renato V. Dantas and Hermano A. Lira acknowledges SERPRO, Federal Data Processing Service, for supporting this research. [24] [25] R EFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] T. Berners-Lee, J. Hendler, and O. Lassila, “The semantic web,” Scientific American, vol. 284, no. 5, pp. 34–43, 5 2001. T. R. Gruber, “A translation approach to portable ontology specification,” Tech. Rep. {KSL} 92-71, 1993. “Owl 2 web ontology language document overview,” 2009. B. Adida and M. Birbeck, “Rdfa primer,” 2008. S. McIlraith, T. Son, and H. Z. H. Zeng, “Semantic web services,” IEEE Intelligent Systems, vol. 16, no. 2, pp. 46–53, 2001. 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. “Oasis uddi specification tc {\textbar} oasis,” 2005. R. T. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, 2000. H. Nacer and D. Aissani, “Semantic web services: Standards, applications, challenges and solutions,” Journal of Network and Computer Applications, vol. 44, pp. 134–151, 9 2014. J. Cardoso, Semantic Web services - Theory, tools and applications. Information Science Reference, 2009. 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. 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. H. Dong, F. K. Hussain, and E. Chang, “Semantic web service matchmakers: state of the art and challenges,” Concurrency and Computation: Practice and Experience, vol. 25, no. 7, pp. 961–988, 2013. L. D. Ngan and R. Kanagasabai, “Semantic web service discovery: state-of-the-art and research challenges,” Personal and Ubiquitous Computing, vol. 17, no. 8, pp. 1741–1752, 9 2012. [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] 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. 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. N. Z. C. Htoo, T. T. S. Nyunt, and T. T. S. Yangon, “Semantic web services offer discovery using owl-s ide,” in 2nd International Conference on Signal Processing and Communication Systems (ICSPCS), vol. 6. IEEE, 2008, pp. 1–5. 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. 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. “Semantic annotations for wsdl and xml schema,” 2007. 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. R. Akkiraju, J. Farrell, J. Miller, M. Nagarajan, M.-T. Schimidt, A. P. Sheth, and K. Verma, “Web service semantics - wsdl-s,” 2005. R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana, “Web services description language {(wsdl)} version 2.0 part 1: Core language,” 2007. M. Hadley, “Web application description language {(wadl)},” Tech. Rep. TR-2006-153, 2006. D. Roman, J. Kopecký, T. Vitvar, J. Domingue, and D. Fensel, “Wsmolite and hrests: Lightweight semantic annotations for web services and restful apis,” Web Semantics: Science, Services and Agents on the World Wide Web, 2014. J. Kopecký, K. Gomadam, and T. Vitvar, “hrests: An html microformat for describing restful web services,” Proceedings - 2008 IEEE/WIC/ACM International Conference on Web Intelligence, WI 2008, pp. 619–625, 2008. K. Gomadam, A. Ranabahu, and A. Sheth, “Sa-rest: semantic annotation of web resources,” p. 52, 2010. 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,” Proceedings of the 2011 7th International Conference on Next Generation Web Services Practices, NWeSP 2011, pp. 373–379, 10 2011. E. Toch, A. Gal, I. Reinhartz-Berger, and D. Dori, “A semantic approach to approximate service retrieval,” ACM Transactions on Internet Technology, vol. 8, no. 1, pp. 2–es, 2007. 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. 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. ——, “Crawling multiple uddi business registries,” Proceedings of the 16th international conference on World Wide Web - WWW ’07, p. 1255, 2007. 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. V. Kaewmarin, N. Arch-int, and S. Arch-int, “Semantic web service discovery and integration using service search crawler,” 2008 International Conference on Computational Intelligence for Modelling Control & Automation, pp. 884–888, 2008. R. Alarcón and E. Wilde, “Restler: crawling restful services,” Proceedings of the 19th international conference on World wide web, pp. 1051– 1052, 2010.