Mashups allowed a significant advance in the automation of interactions between applications and Web resources. In particular, the combination of Web APIs is seen as a strength, which can meet the complex needs by combining the functionality and data from multiple services within a single Mashup application. Automating the process of building Mashup based mainly on the Semantics Web APIs facilitate to the developer their selection and matching. In this paper, we propose SAWADL (Semantic Annotation for Web Application Description Language), an extension of the WADL language that allows the semantization of the REST Web Service. We introduce a reference architecture with five layers representing the main functional blocks for annotating and combining web APIs, and therefore make the engineering process of Mashup applications more agile and more flexible.
is undergoing an evolution from a static environment to a dynamic world in which
mashups will play a central role. The Mashups are web applications developed by the
combination of data, business logic, and/or user interfaces of web sources published
and reused via APIs [
vention of the developer which needs not only programming skills but also to understand the structure and semantics of APIs that wants to integrate. Currently, several tools Mashup (e.g. IBM WebSphere1, Yahoo-pipes2, etc.) are used by end-users (i.e. with less programming skills) to facilitate the building of Mashup applications. However, the intervention of the professional developer is required when the application
creating Mashups, So that end users can build an application with a tool Mashup that guarantees the discovery, selection, and automatic or dynamic superposition of APIs based on the semantic approach, the so-called ‘‘Semantic Mashups’’. The semantic
tic layer that allows to select and compose them in an automatic way (unambiguous).
with a semantic layer that allows the discovery and automatic superposition of APIs
in order to automatically build Mashup applications. SAWADL is more flexible and
adaptive with respect to other approaches of semantization such as SAWSDL [
tic Mashup, and presents some related work for the semantization of REST web services. In Section 3, we introduce SAWADL, a semantic annotation language for
2
Web services enable applications to call remote procedures and to exchange data by passing well-defined messages. This can easily be used for Mashup application as a way to orchestrate different web applications. For instance, Amazon Web Service5 allows users to access most of the features of Amazon.com by using SOAP-based web services and REST-based web services. The semantic Mashup is Mashup whose combined APIs are annotated by a semantic layer that allows to select and compose them in an automatic way. In order to build an automatic Mashup, it is necessary to semanticize these APIs.
classified in two approaches. The first approach consists of developing an ontology that describes the REST-based Web services and their semantics in a single block.
• SOOWL-S advertisements (a social-oriented version of OWL-S advertisements)
ties of a Web service (using the service-Profile module of the OWL-S ontology).
• SA-REST(semantic annotation for REST)
According to J. Lathem [
mantics of RESTful web services. The approach enables both the creation of
machine-readable RESTful service descriptions using the hRESTS (HTML for
RESTful Services) Microformat [
ing mashups, and invoking them.
Table 1. shows a comparison between the different approaches of semantics REST web services.
in Mashups applications.
SAWADL, the extension of WADL language that we propose is part of those approaches that add semantic annotations above the service description while most approaches are based on a semantic annotation above a description based on HTML which gives less homogeneity between semanticized REST web services. SAWADL does not specify a language for representation of semantic models. Rather, it provides mechanisms for referencing ontological concepts defined in the external of WADL document.
modelReference and SchemesMapping. This is done by the attribute "sawadl" followed by the appropriate extension.
ModelReference attribute used to associate a WADL's component to a concept of a semantic model. The items annotated a REST web service described by WADL description are the methods (<method id="method1" name="GET">) and parameters of input / output (<param name = "name" type="xsdtype"/>) of the service. The semantic concept (ontological) associated to elements of WADL through the modelReference attribute is represented by zero or more URLs separated by spaces, which are references to ontological concepts.
The mechanism of schemesMapping is achieved through two other attributes liftingSchemesMapping and loweringSchemesMapping. These attributes are used to specify the mappings between semantic data and WADL elements. The mechanism of schemaMapping is very interesting to understand. In fact, we employ the loweringSchemesMapping attribute when an element annotated in the WADL description matches more than one ontological concepts, and the URIs of the loweringSchemesMapping attribute point to files containing SPARQL7 queries and XSLT8 transformations. While we use liftingSchemesMapping when several elements annotated in the WADL description represent a single ontological concept, and URIs can point to files that contain XQuery9 queries or XSLT transformations. 3.1
Annotation of methods
illustrate these mechanisms, we use a domain ontology of tourism TravelOnto (which we implemented in OWL) to annotate the BookFlight operation of Flight
an operation, a simple semantic annotation can be helpful. Thus we will annotate the
3.2
Annotation of Inputs/Outputs parameters
Internal Annotation. This annotation consists in associating each parameter input/output “<param…>”of a method to a concept in an ontology. This supposes that for each parameter input/output of a method there exist a corresponding concept in the ontology. For example, the input of the operation BookFlight is composed of name and age of the passenger, and the number and class of Flight. We suppose that for each attribute, there exists a concept that corresponds to it in the TravelOnto ontology. In the case where there is no match, the semantics of the input/output parameters is not specified. Figure 2 show an example of internal annotation.
1 <resources base="http://localhost/ApiRest/Flight"> 2 <method id="BookFlight" name="GET" 3 sawadl:modelReference=TravelOnto#BookFlight"> 4 <request> 5 <param name="la_Name" type="xsd:string"/> 6 <param name="fi_name" type="xsd:string"/> 7 <param name="Age" type="xsd:int"/>…… 1 <resources base=" http://localhost/ApiRest/Flight "> 2 <method id="BookFlight" name="GET"> 3 <request> 4 <param name="la_name" type="xsd:string" sawadl:modelReference=”TravelOnto#LastName"/> 5 <param name="fi_name" type="xsd:string" sawadl:modelReference="TravelOnto#FirstName"/> 6 <param name="Age" type="xsd:int" sawadl:modelReference=”TravelOnto#Age"/> 7 <param name="NFlight" type="xsd:string" sawadl:modelReference=” TravelOnto#Flight" /> 8 <param name="Class" type="xsd:String" sawadl:modelReference=”TravelOnto#ClassType"/> 9 </request>…
tag ‘‘<request>’’, however, it must create a schémaMaping for specifying the transformation rules between the input’s/output’s parameters and the domain ontology.
correspondence for the two attributes last_name and first_name. However, the Owner concept of ontology is the merger of these two attributes. To establish the correspondence between the inputs of the credit card API and CreditCard concept, it must first associate using sawadl:modleReference and then define a transformation scheme using an XSL style sheet via the attribute sawadl:liftingSchemaMapping (see Figure 4).
1 <resources base="http://localhost/ApiRest/Billet"> 2 <method id="buyBilletOp " name="GET"> 3 <request sawadl:modelReference=TravelOnto#CreditCard" 4 sawadl:liftingSchemaMapping=http://localhost/Mapping.xsl/> 6 <param name="La_name" type="xsd:string"/> 7 <param name="Fi_name" type="xsd:string/> 8 <param name="Number"
type="xsd:int"/> 9 <param name="Type"
type="xsd:string"/> 10<param name="ExpirDate" type="xsd:date"/> <xsl:transform version="2.0" xmlns:Travel=http://localhost/ApiRest/Billet# xmlns:TravelOnto="http://localhost/TavelOnto#> <xsl:output method="xml" version="1.0" encoding="iso-8859-1" indent="yes"/> <xsl:template match="/"> <rdf:RDF> <TravelOnto:CreditCard> <hasOwner rdf:resource="#Owner"> <hasCardNumber rdf:datatype="xs:Int"><xsl:value-of select="Travel:./param[@name='Number']"> </hasCardNumber> <hasType rdf:datatype="xs:string"> <xsl:value-of select="Travel:./param[@name='Type']"> </hasType> <hasExpritionDate rdf:datatype="xs:Date"> <xsl:value-of select="Travel:./param[@name='ExpirDate']"> </hasExpritiondate> </TravelOnto:CreditCard> </rdf:RDF> </xsl:template> </xsl:transform>
top of APIs (web services). As the dynamic composition of standard web services, the semantic Mashup allows a more rapid development and transparent composition to the user. But unlike to that of traditional web services, the Mashups are composed of
Figure 5 shows reference architecture for Semantic Mashup. This architecture consists of five layers. The layers represent the main functional blocks for automatic generation of Mashup. The ontology is used to enrich the engineering process by a semantic layer that allows him an automatic selection and a combination of APIs included in the Mashup application.
4.2
Description Layer:
4.3
Annotation Layer:
guages of web services annotation are considered at this level. In particular,
input/output of WSDL file with ontological concepts. This layer will be used in the automatic construction of Mashups, by allowing discovery, selection and combination of unambiguous way of the various APIs. 4.4
Matching Layer:
layer. In the following, we propose four rules to match SAWSDL and SAWADL annotation languages.
resource "<resource>" of a SAWADL file corresponds to an operation described by the tag "<operation>" of a SAWSDL file.
of a SAWADL file corresponds to an entry described in the web service’s XML schema by the tag "<element> " of a "<complexType>" of an operation's Input described in SAWSDL file.
Rules4. The "modelReference", "liftingSchemaMapping", "loweringSchemaMappin" attributes of a SAWADL file correspond to the "modelReference", "liftingSchemaMapping", "loweringSchemaMapping" attributes of a SAWSDL file.
which allows calculating a distance between the ontological concepts of Input/Output.
could be combined with another or not.
The matching score between a pair of matching services using the following formula: is calculated , ∑ , / and
Where is the number of query attributes of the service And is the number of annotated attributes present in service , is the number of annotated attributes of services that have been matched out of , and finally , is the ontological distance score between the jth term in service and a corresponding query term. 4.5
Mashup Layer
5
es, and/or user interfaces of web sources published and reused via APIs. Thus,
cessed data and seize their significance in an automatic way in order to automate the selection and combination of APIs used to build the Mashup application.
scription of RESTful APIs. However, they did not give a great success and are not simple to implement. For example, SA-REST and SWEET approaches require an
chine readable description to add semantic annotations. One thing that is not always true and that makes it more difficult especially if the REST API does not have a web page that describes it. In order to respond to these problems, that we conducted our research. Our work focuses on the semantics, and more particularly towards a proposal for an annotation language for semantic REST Web services. Our language
vice description. Unlike approaches that annotate on top of an HTML description, we use the WADL description which is used to describe syntactically REST web services. Semantization APIs is not sufficient to design and implement an automatic
the different APIs, and to discover automatically the Mashable components followed the needs of users.
Finally, several perspectives can be considered in order to contribute more to the agility and flexibility of the semantic Mashup building. We cite as an examples: • The Semantization of other Web APIs such as javascript or RSS / ATOM that represent Mashable components widely used in the development of Mashups. However, the absence of a structured and modular description of these APIs makes this task a big challenge. • The use of ontological resource and service like OWL-S and WSMO. • The use of the semantic approach in the construction of process-oriented enterprise