Dealing with REST Services in Model-driven Web ...

Dealing with REST Services in Model-driven Web Engineering Methods Francisco Valverde 1, Oscar Pastor1 1

Centro de Investigación en Métodos de Producción de Software, Universidad Politécnica de Valencia, Spain {fvalverde, opastor}@pros.upv.es

Abstract. A demanded industry requirement is how to integrate the functionality from Web 2.0 applications into their Information Systems (IS). In recent years, Web Engineering has faced this issue defining a set of conceptual models that abstract the communication with external SOAP Web Services. However, Web 2.0 applications usually expose their functionality by means of REST Services. Since this type of services lacks of a formal specification, the integration issues must be manually addressed. The main purpose of this work is to introduce a Model-driven approach for the integration of Web 2.0 functionality implemented as REST Services. To achieve this goal, this works presents a REST Metamodel for specifying these REST Services as conceptual models. It also introduces how the models created using this metamodel, can be used within Model-driven Web Engineering methods. Keywords: REST Services, Model-Driven Development, Web Engineering

1 Introduction In recent years, the development of Web 2.0 Applications [10] has gained relevance. Around this new application paradigm, different concepts such as Social Networks, Rich Internet Applications or REST Services [14] have arisen to support Web 2.0 development. Industry is aware of the great potential of this new tendency and has started to demand Web 2.0 features inside their IS [6]. A recent survey conducted by the McKinsey Company [2], has shown that the Web 2.0 technology most demanded by the interviewed companies is Web Services. The use of Web Services is mainly required for integrating the useful information provided by social Web 2.0 applications [16]. Several organizations have implemented SOAP Web Services as a mechanism to provide the functionality to external partners. Additionally business process languages as BPMN and software as BPEL engines have been used [17] to deal with the external services integration. However, according to the Programmable Web1, REST Services is the preferred choice among Web 2.0 Applications (around a 66%) to expose their functionality. The RESTful paradigm proposed by Fielding [4] has become popular 1

www.programmableweb.com/apis

because is a lightweight approach that does not introduce the information overload of SOAP messages. This technological change has also implied, as Overdick has stated [11], a transition from a Service-oriented Architecture (SOA) to a Resource-oriented Architecture (ROA). One of the main concerns for the Web Engineering [15] community is how to integrate external Web 2.0 functionality into an IS. Web Engineering proposes the use of conceptual models in order to avoid the technological complexity of the Web development. Owing to that, the integration with Web Services is discussed by several authors [1][13]. However, the previously proposed approaches do not fit well with REST Services. The main reason is because these approaches rely on Web Services formally described using a WSDL document. But that is not common regarding REST Services due to they are usually documented as HTML documents. The main purpose of this paper is to present a model-driven approach to integrate the Web 2.0 functionality represented as REST Services. The use of conceptual models to specify REST Services has a two-fold improvement: 1) the abstraction of the technological complexity to analysts, and 2) the introduction of a human readable notation in order to deal with REST Services within the Web Application development. With these goals in mind, section 2 describes the related work and highlights our specific contribution. Next in section 3, a metamodel for specifying REST Services from a ROA point of view is presented. This metamodel provides a formal specification to describe REST Services as conceptual models. Hence, these services can be used in model-driven development approaches. In order to explain the metamodel, the Last.fm REST Service has been chosen as illustrative example. This paper also discusses in section 4, how this metamodel can be used in conjunction with Model-driven Web Engineering methods. Finally, in section 5 the concluding remarks and future works are stated.

2 Related Work WSDL has been the industrial standard in order to describe the interface of SOAP Web Services. The 2.0 version of WSDL has introduced the required support for defining REST Services [9]. To support them the operations defined in the new binding element include which HTTP method (GET, PUT, POST or DELETE) is going to be used by the interface. However, from a Web development perspective, the WSDL 2.0 specification has three drawbacks: 1) currently the technological support is minimum since only the definition of WSDL 1.1 specifications is widely supported by the industrial development tools. As a consequence in practice is a tedious task to define REST Services using a WSDL 2.0 specification; 2) WSDL is a machinereadable language which was not defined to be used by analysts; and 3) WSDL describes the input/output messages using XML Schema elements. Though different content-types can be specified, it is not possible to describe the messages using alternative languages as JSON [3], which is widely used in the REST Services field. Another work from the industrial field is the Web Application Description Language (WADL) [5]. The purpose of this language is to provide a formal

specification in order to access programmatically to the data from HTTP-based applications. WADL is based on concepts more related to REST Services such as resources or representations. Therefore is a suitable language for describing REST Services. A WADL specification is also machine-readable and implemented using XML. But this language introduces a lot of HTTP details that should be avoided from a non-implementation perspective. Moreover, excluding Java environments, there is a lack of tool support to build the specifications. Some academic works have been also proposed approaches for formally describing REST Services that are textually specified by means of HTML documents. For instance, SA-REST [8] introduces semantic annotations, which are based on the RDFa ontology language, inside the meta or container HTML elements (span, div, etc.) from a REST Service specification. These annotations characterize the different services, operations, messages, etc. those are textually described in the specification. Hence, the relevant textual fragments are related to an ontology for describing the REST Services domain. In the same reasoning line, Kopecky et al. [7] define the hRESTS HTML microformat for this task. This microformat represents a functional model of a REST Service that is specified using the class and rel HTML elements. This approach also reuses the SA-REST notation for describing the different data formats supported by the REST Service. The main advantage of both approaches is the reuse of the current textual services specification in order to make them machine-readable. Furthermore, since REST Services are described in terms of an ontology, they can be mapped to different technological languages. However, to provide embedded annotations in HTML documents, which can include redundant information, style elements or even scripts, is not a straightforward task without a suitable tool support. Our main contribution is to provide a human-readable mechanism to describe REST Services instead of the machine-readable notations mentioned above. Hence the analysts can model the functionality provided by the REST Services within a Web Engineering method. Instead of dealing with XML files, we propose the use of conceptual models for gathering the service specification. These models are easier to define and maintain than a XML specification because of the model-driven support tools available in the market. Furthermore, as these models are not linked to a specific technology, they can be used to generate a default WADL or WSDL 2.0 specification by means of a model to code transformation rules. As a consequence a machinereadable specification can be provided as well.

3 A REST Metamodel for integrating Web 2.0 functionality Web Engineering methods have mainly rely on model-driven principles to provide a systematic development. In order to be consistent with these principles, conceptual models that abstract REST Services must be introduced inside these methods. The first step to achieve this goal is to abstract the concepts that describe REST Services as a metamodel. This work proposes a REST metamodel that can be used to model the different resources provided by a REST Service. This ROA vision is suitable for

modeling REST Services, because it is focus on the functionality or data provided by the service (i.e. the resources) and not in the service communication interface. In order to define the expressivity that the metamodel must support, previous works related to the description of REST Services [14][5] have been taken into account. The different entities that make up the REST metamodel are briefly summarized in Figure 1. To facilitate the explanation, the Last.fm services API2 is used as example to introduce the different entities of the metamodel. Last.fm is a popular Web 2.0 application where users can find new music according to their personal preferences. A REST Service is defined as an aggregation of different Resources that can be reached from a base URI. A Resource represents an entity from the real world whose state is exposed and can be changed accessing to an URI (Universal Resource Identifier). As the illustrative example is related with the music domain, some resources available are Album, Artist, Track or Playlist. The base URI of the Last.fm example is http://ws.audioscrobbler.com/2.0, whereas the Album Resource URI is “/?method=albums”, so for accessing to the resources, HTTP messages must be sent to the composition of both URIs.

Fig. 1. The REST Metamodel

Usually, REST Services include global arguments that must be always specified in the requests (for instance, the authentication key for identifying the client that is performing the request). To define this type of arguments the REST Service entity can be associated to several Parameters. This Parameter entity is defined by a Data type (int, string, float, etc.), a Boolean attribute to set if it is required or not, a default value 2

www.lastfm.com/api

to be sent, and a Boolean attribute to set if the parameter value is sent to the Resource encoded in the URI query string. For example, all the requests to Last.fm must include the ‘api_key’ parameter to identify univocally the developer that is requesting the data. A Representation is the description of the messages sent or received from a Resource in terms of a technological language. Currently XML and JSON are the most popular languages for describing these messages. Therefore a Representation is defined in the metamodel as an abstract entity that is generalized in the different types of Representations according with its media-type. In our example, the different Representations are described as XML documents. In order to define an XML representation, an XML Schema, which defines the Representation syntax, must be referenced. Next, an XML element from this schema is used to describe a specific Resource representation. For instance the next XML elements describes an excerpt of the data of an Album Resource:

For accessing or modifying a Resource, several Methods can be defined. A Method abstracts the sending of a request-response message using a HTTP method (GET, POST, PUT or DELETE). If the isDefaultInvoke attribute is set to true, that method will be performed by default when the resource is accessed and no method information is provided. A Method is made up of a least one Request and optionally several Response messages. The Request can include a set of additional Parameters to be sent to the resource. For instance, in our example the method “addTags” sends a POST Request to the Album resource to add a new tag. This request provides three parameters: the album name, the artist and a set of tags delimited by commas. If more complex data structures must be sent, the Request parameters can be described using a Representation. A Response message is always linked with a Representation that returns the state of the resource after a method invocation. For describing faulty responses (incorrect parameters, server errors, etc.), the entity ErrorResponse is introduced because in that case a resource representation is not returned.

4 Integration into Model-driven Web Engineering Methods Web Engineering methods have proposed a set of models to deal with different concerns related to the development of Web applications. A conceptual model with similar semantics that is shared among them is the domain model. The task of this model is to describe the domain entities that represent the data and the functionality used by the Web Application. Following the apporaches proposed by the Software

Engineering discipline, Entity-Relationship diagrams, UML Class diagrams or similar notations, have been used to define this model. Later, the domain model is transformed to the programming classes that implement both the business logic and the data layer. In the context of Web Engineering methods, REST Services provide a set of domain entities, the resources, that are not explicitly implemented inside the IS. Therefore, a reasonable approach is to represent these resources as entities of the domain model. Our proposal is the use of Legacy Views in order to integrate the REST Service resources inside a specific domain model. The Legacy View concept is very close to the class definition because denotes a structural and behavioral abstraction by means of a set of attributes, services and relationships between Legacy Views (see Figure 2). The main difference is that a Legacy View represents an external software component previously implemented. This concept is not novel because it has been successfully applied in the OO-Method model-driven method [12]. Legacy Views are generic enough to be seamlessly introduced into the domain model of different Web Engineering methods. For instance, the same model notation used to describe the domain entities can be reused using stereotypes. The difference is that for each Legacy View, it must be also modeled the external functionality represented. In the context of this work a model of a REST Service, which conforms with the metamodel proposed, performs this task. When the analyst introduces into the domain model a Legacy View, it must be also associated to a REST Service model. This association is performed between the different properties of the Legacy View (attributes, services and relationships) and a resource method from the REST Service model. However some constraints must be satisfied: • Legacy View attributes must be associated to methods that have as response a resource representation. The different elements of the representation provide the attribute values. • Legacy View services must be associated to methods that modify the state of a resource. The different parameters of the method represent the arguments of the service. • Legacy View relationships are associated to methods that receive as parameter a resource identifier, and whose response is a set of the representation of the related resources. Figure 2 shows an example of the Legacy View that corresponds to the Album resource. UML classes stereotyped with the word ‘legacy’ have been chosen to represent the Legacy Views. Two associations with resource methods from the Last.fm service model are also highlighted. First, for providing the attribute data for the Legacy View ‘Album’ the method ‘getInfo’ is used. The response of this method is the Album XML Representation described in the previous section. Secondly, the relationship ‘albumTags’ is related to the method ‘getTags’. In this case, the method returns the representation of the Tags entities related to an Album resource. For that reason, the Legacy View ‘Tag’ is also introduced into the Domain model. Finally, similar method associations have been defined for the ‘AddTags’, ‘RemoveTag’ and ‘Search’ services.

Fig. 2. Legacy Views for the Album Resource

5 Concluding Remarks This paper has briefly presented a metamodel and an approach for integrating REST Services within Model-driven Web Engineering methods. The use of conceptual models provides a useful abstraction to analysts for introducing REST Services in their development approaches. From this work two main lessons have been learned: 1) Since currently there is not an accepted standard for describing REST Services, this metamodel provides a generic mechanism to create formal specifications. Afterward, the conceptual models created can be used for generating machinereadable specifications or the integration code by means of the corresponding transformation rules. 2) Legacy View is a suitable concept to represent abstractly the resources of a REST Service. Furthermore they can be easily introduced into the current domain models. For validation purposes, several API based on REST Services from Web 2.0 applications have been analyzed in order to check if the expressivity provided by the metamodel is enough. Though some aspects related to the authentication and the relationships between resources are not fully supported, the core communication with a REST Service can be specified using this metamodel. Moreover in order to apply the contribution in a Web Engineering method, the OOWS [18] method has been extended with both the REST metamodel and the Legacy View mechanism. Future works will focus on how to automatically generate from the OOWS models the required integration code. Hence a Web Application, whose functionality is provided by external REST Services, will be specified from a Model-driven development perspective. Acknowledgments. This research work has been developed with the support MEC under the project SESAMO TIN2007-62894 and the FPU grant AP2005-1590

References 1. Bongio, A., Brambilla, M., Ceri, S., Fraternali, P.: Model-driven Design of Service-enabled Web Applications. 24th ACM SIGMOD International Conference on Management of Data ACM, Baltimore, Maryland (2005) 2. Bughin, J., Manyika, J.: How Businesses are using Web 2.0: A McKinsey Global Survey. (2007) 3. Crockford, D., JSON, The Fat-Free Alternative to XML. In: XML Conference, Boston, USA (2006). 4. Fielding, R. T. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, Irvine, University of California (2000). 5. Hadley, M.J. Web Application Description Language, Sun Microsystems Inc. (2006) 6. Hoegg, R., Martignoni, R., Meckel, M. and Stanoevska-Slabeva, K.: Overview of Business Models for Web 2.0 Communitiers. In: Gemeinschafen in Neuen Medien, pp. 23--37. Technische Univesität Dresden, Germany (2006) 7. Kopecky, J., Gomadam, K., Vitvar, T.: hRESTS: An HTML Microformat for Describing RESTful Web Services. Web Intelligence and Intelligent Agent Technology, 2008. WI-IAT '08. IEEE/WIC/ACM International Conference on, Vol. 1 (2008) 619-625 8. Lathem, J., Gomadam, K., Sheth, A.P.: SA-REST and (S)mashups : Adding Semantics to RESTful Services. Semantic Computing, 2007. ICSC 2007. International Conference on (2007) 469-476 9. Mandel, L.: Describe REST Web Services with WSDL 2.0. IBM Corporation (2008) 10. Murugesan, S.: Understanding Web 2.0. IT Professional. 9, 4, 34--41 (2007) 11. Overdick, H.: The Resource-Oriented Architecture. In: IEEE Congress on Services, pp. 340-347. IEEE Computer Society Press, Salt Lake, Utah (2007) 12. Pastor, O. and Molina, J. C. Model-Driven Architecture in Practice. A Software Production Environment Based on Conceptual Modelling. Springer-Verlag, Berlin Heildeberg (2007) 13. Quintero, R., Torres, V., Ruiz, M., Pelechano, V.: A conceptual modeling approach for the design of web applications based on services. Proceedings of the 44th annual Southeast regional conference. ACM, Melbourne, Florida (2006) 14. Richardson, L. and Ruby, S. RESTful Web Services. O'Reilly Media, Inc. (2007) 15. Rossi, G., Pastor, O., Schwabe, D. and Olsina, L. (eds.): Web Application Development: Challenges and the Role of Web Engineering. Web Engineering: Modelling and Implementing Web Applications, Springer. (2008) 16. Schroth, C. and Janner, T.: Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services. IT Professional. 9, 3, 36--41 (2007) 17. Torres, V. and Pelechano, V.: Building Business Process Driven Web Applications. In: S. Dustdar, J. L. Fiadeiro and A. P. Sheth (eds). Business Process Management. LNCS, 4102, pp 322--337. Springer, Heidelberg (2006) 18. Valverde, F., Valderas, P., Fons, J., Pastor, O.: A MDA-Based Environment for Web Applications Development: From Conceptual Models to Code. In: Brambilla, M., Mendes, E. (eds.): 6th International Workshop on Web-Oriented Software Technologies (IWWOST). Dipartimento di Elettronica e Informazione, Politecnico di Milano, Italy, Como, Italy (2007) 164-178