Modeling a Composite RESTful Web Service with UML

Modeling a Composite RESTful Web Service with UML Irum Rauf

Dept. of Information Technologies Abo Akademi University, Turku, Finland

Anna Ruokonen

Dept. of Software Systems Tampere University of Technology, Tampere, Finland

[email protected]

Tarja Systa

Dept. of Software Systems Tampere University of Technology, Tampere, Finland

[email protected] [email protected] Ivan Porres

Dept. of Information Technologies Abo Akademi University, Turku, Finland

[email protected]

ABSTRACT The process of web service composition involves different partner web services that are published over the internet. The Representational-State Transfer (REST) web services adopt different architectural style compared to Remote Procedure Call (RPC) web services. In this paper, we address these differences in the context of web service compositions and motivate the need for new designing techniques that lead to RESTful interfaces. We provide a UML based modeling approach for the composition of RESTful web services that models the composition for its static and behavioral features. These models provide RESTful compositions by construction, serve as a part of specification document, have mapping to several web implementation languages and can also be used to validate a RESTful composition. We illustrate the applicability of the approach with a sample Hotel and Flight booking RESTful composite web service.

1.

INTRODUCTION

A web service provides a remote interface to a software system using standard internet protocols. These interfaces are in a machine-processable format and their functionality can be manipulated by machines without much human intervention. Web services can be developed in a Remote Procedure Call (RPC) manner or as a REpresentational-State Transfer (REST) web service. The RPC-styled web service is operation centric. It exposes its functionality in the operations advertised on its interface. On the other hand, a REST style web service is data-centric and exhibits its functionality in the exposed resources. These resources are much like objects in a class and give information on data that can be manipulated to serve a purpose. A web service composition uses existing web services to provide new functionality built on top of these existing web ser-

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ECSA 2010, August 23-26, 2010, Copenhagen, Denmark. Copyright (c) 2010 ACM 978-1-4503-0179-4/10/08 ...$10.00.

vices. It facilitates reusability of already published web services and combines different services developed by different vendors in different locations into a whole. Service orchestration is a common approach for developing a composite web service. In services orchestration, the involved services are unaware of their participation in the composition process and a central process controls and coordinates the execution of involved web services. For RPC-style web services, different flow composition languages exist like BPEL4WS [3] and WSCI [4]. These define the control and data flow that determine when a certain operation should execute. Business Process Execution Language(BPEL) [3] is one of the composition specification languages that is widely adopted to implement a web service composition. In addition, many modeling approaches have also been been proposed for composition of RPC-styled web services [16] [14]. However, REST web services follow a different architectural style and thus require different design philosophy and techniques. A RESTful web service is designed such that its interface offers addressability, connectivity, uniform interface and statelessness. Thus, a composite RESTful web service is also designed such that it offers these basic features of a REST web service. It should reveal its resources with their addresses and representations, the resources should have connectivity, offer a uniform interface and the outcome of invoking a method in specific resource should be observable. This different design philosophy of REST web services compared to RPC style require new designing techniques. We need to understand how resources and methods of composite REST web service are mapped to resources and methods of partner web services. In this context, we feel the need of a visual representation that facilitate the understanding of how RESTful features are addressed during design phase generating composite RESTful web services. In this paper, we provide a UML based modeling approach to design web services that are RESTful by construction. The use of a modeling approach facilitates the understanding of underlying concept of RESTful architectural style and targets the design requirements independent of the implementation details. We model a composite RESTful web service for its static and dynamic behavior using class diagram, activity diagram and state machine diagrams. The paper encompasses modeling of the composition process and

its refinement to interface implementation. We aim to keep the approach simple to deliver the underlying concepts in a comprehendible manner. The paper is organized as follows: Section 2 provides the background of the presented work and section 3 gives an overview of the approach. Section 4 presents the conceptual resource model followed by behavioral models in section 5 and 6. In section 5, we present the process model and the modeling of composite RESTful interface is detailed in section 6. Section 7 contains the related work and section 8 concludes alongwith the future work.

2.

BACKGROUND

A RESTful architectural style exhibits a data centric behavior as compared to the RPC-styled web services that are operation-centric. The main features of the RESTful architectural style are: addressability, uniform interface, connectivity, and statelessness. Addressability requires that any relevant information related to the service is exposed as a resource. Each resource has one or more unique addresses and has one or more representations that are accessible remotely. In order to achieve connectivity resource representation should contain links to other resources such that the graph formed by resources and their links is connected. For a uniform interface, all resources are manipulated using the same set of methods. In the case of HTTP web services the methods are GET (HEAD), POST, PUT and DELETE. There is also a standard set of status codes or exceptions to signal the success or failure of a method. The feature of statelessness requires that a method is a function of its input parameters and addressable resources. That is, there is no hidden session or state information. Besides, the effects of the POST, PUT and DELETE operations should be observable in the affected resources. With these features REST web services can play well with the existing tools and infrastructure of the internet.The feature of connectivity and uniform interface allows use of existing tools and infrastructure like web crawlers, curl, caches etc. The addressability requirement (specially when using hierarchical addresses) helps us to create extensible web services. The statelessness requirement simplify the development of systems that can handle many service requests simultaneously facilitating scalability. Currently, REST web services are widely adopted in the web and have numerous users, including enterprizes such as Google, Yahoo, Amazon and Flicker. A web service composition process combines services that may be available on different locations and maybe published by different vendors to provide a new web service, i.e. a composite web service. These web service compositions are often assumed to be driven by a business goal [17] and are described separately in a flow specification language. These composite web services are like a black box to the end user and only advertise the operations through the interface that can be invoked on them. The specification of an interface only contain the syntactic information about the operations that can be invoked on them and the flow in which messages can be exchanged between the services is described

separately in a flow specification [17]. For RPC-styled web services, Web Service Description Languages 2.0 (WSDL)[5] are often used for interface specifications. WSDL provides information on the operations that a service allows and defines the data that is transmitted as messages between service operations. The interface specification language is syntactic and information on the order of method invocation is defined in a flow specification language like BPEL4WS[3]. However, A RESTful composite service must exhibit the features of a RESTful architecture. The following listing presents three possible mechanisms for defining RESTful BPEL processes: 1. WSDL 2.0 for HTTP binding: Using normal BPEL4WS [3] descriptions (e.g. invoke operation1) and funneling invocation through a synthetic WSDL 2.0 description. In WSDL binding, operations are mapped to URIs and HTTP methods (e.g operation1 maps to resource1 and PUT method). 2. REST through adapter: Using RESTful services from a normal BPEL process by generating an artificial WSDL which describes the REST interface and then creating an adapter for communicating with the RESTful service. Some BPEL engines also support interaction through WADL description. 3. BPEL extension for REST: Extending BPEL (and a BPEL engine) for directly supporting RESTful activities (e.g. GET, PUT, POST, and DELETE activities in a scope of a certain resource). Approaches 1 and 2 have advantage of not requiring any modification to BPEL language and current implementations of BPEL engines. On the other hand, WSDL is a description language for operation-oriented web services and it does not fully comply with the semantics of resourceoriented RESTful services. In [12, 10], Pautasso uses the third approach and proposes extensions to BPEL for REST. This approach has several advantages, such as, supporting a late binding and dynamic resources. In traditional BPEL-WS [3] processes, dynamic binding of services is not supported, as service endpoints are predetermined and any changes requires clients to change or update their WSDLs. Thus, this is a significant advantage of the third approach. Here we summarize the main differences in BPEL-WS and BPEL-REST, as proposed by C. Pautasso in [12, 10]. • In BPEL-WS only one invoke type of activity is declared, where as in BPEL-REST for each HTTP operation a distinct invoke activity is defined. • BPEL-REST introduces a resource concept, which allows defining and publishing resources. It defines allowed message handlers, which are available in the scope of the resource. • The internal behavior of a request handler can be specified using the normal BPEL constructs (i.e.,

< sequence >, < if >, < f low >, < while >, etc.). However, control-flow links across activities that belong to different handlers are not allowed.

of specification document of web services and do not require any extra effort from the Composite RESTful Web Service (CRWS) developer.

We use the information presented in this section regarding RESTful web service composition to present a modeling approach that simplifies the concept of RESTful web services and their composition process. In the next section, we provide an overview of our modeling approach using UML for designing composite RESTful web services.

We use an example of a composite Hotel and Flight (HF) booking service that uses a room booking RESTful web service and a flight booking RESTful web service. The composite service offers services to book a room and flight in parallel, to take total payment from the user and to provide payment confirmation information. The booking can be canceled except when it is waiting for confirmation from a third party service. A canceled booking can be deleted.

3.

OVERVIEW

In this paper, we provide a modeling approach to support RESTful web service composition. We require that this RESTful web service composition should exhibit features of REST interface, i.e., addressability, connectivity, uniform interface and statelessness. A web service composition in RESTful style differs from traditional web service composition techniques since instead of composing web services from the perspective of operations, RESTful composition focuses on resources [19]. A RESTful web service takes resource as a building block and in a typical REST development environment, new resources are exposed to keep the design simple and to allow maximum decoupling. Thus, a RESTful composite web service must take resources of different partner services into account and how standard methods invoked on composite web service invokes corresponding operations in the partner web services. In our previous work [13], we have provided an approach that models and generates behavioral interface specifications for a RESTful web service. In this article, we extend our work to support composite RESTful web services. We model the static and dynamic features of a composite RESTful web service. Our modeling approach is shown in Figure 1. We start with the conceptual resource model that represents the static structure of a composite RESTful web service. The conceptual resource model is represented by a class diagram where each class represents a resource. This conceptual resource model provides information on the resources that are available, their representation, relative addresses and connectivity. We then use this conceptual resource model to model our composition process. The composite behavior of the RESTful service is first sketched as a sequence diagram and then the process flow is modeled as an activity diagram. The process flow is presented as send messages, send by the process, and receive messages, received by the process. Finally, this process information is refined to a state machine that gives detailed information on how the composition is defined and constraints the implementation and usage of composition to provide RESTful behavior. We assume that partner services are RESTful and their resource models are available or they can be constructed before using them in the composition process. This assumption helps us in providing RESTful interface for composite web service. We consider that this is not a strong assumption since partner services need to be understood first in order to know the functionality they offer and make them a part of the composition process. These models are considered part

In the next section we present the conceptual resource model for a CRWS.

4. CONCEPTUAL RESOURCE MODEL A conceptual resource model of a RESTful web service shows the involved resources, attributes of a resource representation, connection between resources and the navigation path from one resource to another. A UML class diagram is used to model these structural features of a RESTful composite web service. The conceptual model of our HF booking service is shown in Figure 2. It has five resources of its own, namely, bookingsHF, bookingHF, cancelHF, paymentHF and pconfirmationHF, and two resources from partner web services, i.e., bookingHotel and bookingFlight. The associations between resources show connection between the resources. We require that there is no isolated resource in the diagram and all the resources form a connected graph. The association arrow provides navigability direction and association roles define the relative navigation path from one resource to another. E.g., in order to reach resource cancelHF, we will follow the path /bookingsHF/{bid}/cancelHF/. The resources of partner web services can be navigated from the partner resource linked to the CRWS resource, e.g., the payment resource of a Hotel Booking service can be navigated with the path /bookingsHF/{bid}/bookingsF/{bid}/payment/. The collection resource is stereotyped > and contains a list of resources. In Figure 2, bookingsHF resource is a collection resource and a GET method on this resource would return list of all the booking resources (bookingHF ). This resource is considered to be the main resource of our conceptual model as all other resources are navigated through it. In order to combine resources of partner web services, the main resource of composite service is connected to that resource of partner service through which all its other resources are navigated. In Figure 5, bookingHF of CRWS has associations with bookingFlight and bookingHotel resources of partner services Flight Booking and Hotel Booking, respectively. The multiplicity of 1 on association end of partner web services implies that the booking made at HF CRWS must have a booking for both the room and flight. This association with resources of partner web services exhibit the feature of connectivity and addressability in CRWS design. We do not show conceptual resource models of partner web services due to space constraint.

Figure 1: Approach for Model-based RESTful composition In addition to resources of the partner web service, a composite REST web service has its own resources. These resources are also modeled as classes in the conceptual model. The representations of these resources are shown as public attributes. Modeling attributes of a resource as public specify that the representation of a resource is exposed for manipulation.

describes the interaction between the process and its participants. In conceptual model, defined in Figure 2, all the resources are defined, but here we only model the service interaction. However, from the URI structure, we can see that /paymentHF and /pConfirmationHF are subresources for /bookingsHF. Thus, they are part of the interface provided by the Booking Hotel and Flight service.

The cancelHF, paymentHF and pconfirmationHF keep records of the bookings made via composite service interface. The information on methods that can be invoked on these resources is not shown in conceptual model as we do not consider them necessary here. This is because the standard HTTP methods, GET, PUT, POST and DELETE, can be invoked on every resource.

From the scenario model, we want to create a process description, which implements the Booking Hotel and Flight scenario. We aim at a process model, which is compatible with BPEL-REST process language. To construct the process model, we model BookingsHF service’s view on the conversation. This means messages send and received by the BookingsHF service. Send message events in a sequence diagram present invocations in an activity diagram and receive message events means that the process receives an operation call.

This conceptual model provides structural layout of CRWS. We use this structural model to present our behavioral models in Section 5 and 6. The next section, presents modeling of the RESTful process.

5.

MODELING A RESTFUL PROCESS

The UML activity diagram and BPMN [9] are the common notations used for WS-BEPL process modeling. A proposal for UML Profile for WS-BPEL [2] uses old BPEL 1.0 specification and UML 1.4, but provides guidelines how to map BPEL-WS processes to UML activity diagrams. Also, a UML 2.0 profile for WS-BPEL have been proposed [1]. A previous work by Ruokonen et al., in [15], presents a UML-based approach for creating BPEL-WS flavored activity models, which enable generation of executable BPELWS descriptions. By combining existing works, we aim at proposing modeling constructs, given as UML activity diagram, for BPEL-REST processes. Our target is to model a RESTful process for flight and hotel booking using the resources defined in the conceptual model. The process scenario, Booking Hotel and Flight, is shown in Figure 3. BookingsHF is a process, which is to be implemented as a RESTful composite service. In addition, BookingsHF uses three external RESTful services: BookingsHotel, BookingsFlight, and Payment. The actual resource structure is not shown in the figure, but it only

In Figure 4, a workflow-oriented model for Booking Hotel and Flight process is shown as activity diagram. This follows traditional way of modeling BPEL processes. Conditions under which each operation can be invoked are defined by the workflow description. It is a workflow, which includes user interaction. POST /bookingsHF and POST /bookingsHF/paymentHF are invoked by the user. This means that the process execution waits for user input before it continues. The following listing presents how UML activity model constructs are used to model BPEL-REST processes. BPEL-REST to UML activity diagram mappings 1. HTTP invocations get, put, post, and delete are modelled as a call behavior action (stereotype >, >, >, > respectively) onPut,onGet,onPost, and onDelete activities 2. onPut is modelled as a call behavior action (stereotype >) 3. onGet is modelled as a call behavior action (stereotype >)

Figure 2: Conceptual Model for HF Composite RESTful Web Service : Customer

: BookingsHF

: BookingsFlight

: BookingsHotel

: Payment

1: ("/bookingsHF") 2: ("/bookingsFlight")

3: POST("/bookingsHotel") 4: ("/bookingsHF/paymentHF") 5: ("/paymentF") 6: ("/paymentH") 7: POST("/bookingsHF/pConfirmationHF")

Figure 3: Booking Hotel and Flight scenario 4. onPost is modelled as a call behavior action (stereotype >)

workflow, which results the desired behavior, in the activity diagram.

5. onDelete is modelled as a call behavior action (stereotype >)

For RESTful processes the workflow modeling approach, as done in this Section, does not contain all the information to specify an executable RESTful process descriptions, because it does not define the resources. Also, it does not define all the resource handlers and their internal structures and return values. However, modeling all the possible combinations for invoking the process handlers and their relations becomes too complex. Thus, to keep it simple we only model the desired scenario here.

6. respond is modelled as a call behavior action (stereotype >) 7. sequence is modelled as a control flow Unlike onMessage activities in BPEL-WS, RESTful message handlers can have internal structure and thus they could be also modeled as structured activities, which contain a respond activity and possibly some other if-else structures. On the other hand, onPut and respond could be modeled as a pair of simple activities, which has a potential sequence of activities between them. The same applies of course to other message handlers. As a modeling restriction, links across activities, which belong to different message handlers are not allowed. A resource in an activity model, would be modeled as a structured activity, which contains all the message handlers it supports. However, our target is to simply model the

A service composition, i.e. a composite service, is a slightly different view point than a BPEL process as a composite service. For example, an approach is somewhat different if we want to build a Booking Hotel and Flight process, or a composite service for the same purpose. Most notably, a different modeling approaches will be used. A BPEL process describes the conversation from the perspective of one of the participants, i.e. the process itself. Here, we made a decision to only model a pure workfow in the activity diagram. To

/bookingsFlight /bookingsHF

/paymentH /bookingsHF/pConfirmationHF

/paymentHF /bookingsHotel

/paymentF

Figure 4: Booking Hotel and Flight process make the process model complete, modeling of the resource structure is considered in Section 6.

6.

MODELING COMPOSITE RESTFUL INTERFACE

We model the behavioral model of CRWS using a UML state machine. It provides the behavioral interface specifications of a web service and defines the right sequence of method invocations, the conditions under which these methods should be invoked and the expected conditions for these methods. The process model, shown in previous sections, provides information about flow of activities in the RESTful composition process. In this section, we refine the activity diagram to a state machine. In the refinement step, a send message (the process makes an invocation) is mapped to an entry action in a state machine. A receive message in an activity diagram (the process receives a message) is mapped to a state transition in a state machine. We require that each state has a boolean function, i.e., a state invariant which is true when a given state is active and false otherwise. Transitions cause a change in the state of the system and are represented as arrows and method calls are represented as triggers on the transitions. The conditions that should be met before invoking the transition are labeled on the arrows as guards and the expected conditions after firing a transition are annotated as effect on the transition. Previously [13], we have used a UML protocol state machine to represent the behavioral interface of individual web services. We now extend our state machines with actions and resource information of partner resources to represent the implementation of behavioral interface of a composite RESTful web service. Figure 5 shows behavioral model for our HF booking composite service. The state machine has one normal state, CancelHF, and one composite state, Booking, at the highest level of state hierarchy. The state machine is initiated with the POST method on resource bookingsHF targeted to state Booking. The composite state, Booking, is further composed of three composed states, namely reserve and pay, waiting f or pconf irmation and pconf irmation inf o. The reservation and payment for hotel room and flight is done in parallel. This is shown by orthogonal states in the state reserve and pay and waiting f or pconf irmation. This implies that third party service is invoked for payment confirmation only if payment is done for both the services. The confirmation of payment is taken from the individual payment services of partner services. A booking can be canceled from any state except when it is waiting for confirmation from the third party service. When a canceled booking is deleted, it also deletes respective records in the hotel booking and flight booking services.

Each state of behavioral model contains a state invariant. The state invariants of our state machine are boolean expressions that also consider the response codes of HTTP methods. When we invoke an HTTP method on a resource, it is returned with a response code. This response code informs the sender whether the request was successful or it failed. The response code of 200 specifies that method invocation was successful and response code of 404 specifies that method invocation was not successful and no such resource exists. The state invariants of our behavioral model are based on comparison of response codes of GET methods on a resource with the expected response codes. OK(r) represents a response code of 200 for GET on resource r and NOT FOUND(r) represents a response code of 404 for GET on resource r. As an example, lets consider the state invariant of composite state Booking as shown in Figure 5, i.e., OK(bHF )&&OK(bF )&&OK(bH)&&OK(r) &&OK(f ) &&N OT F OU N D(cHF ). It is a boolean expression consisting of OK(r) and NOT FOUND(r) functions on resources of HF composite service and the involved partner web services. The state machine in Figure 5 can be in state Booking only if the above boolean expression evaluates to true. The state invariant of a substate is given by conjuncture of state invariants of the substate with the state invariant of all the states that contain it. For example, the state invariant NOT FOUND(pcHF)&& NOT FOUND(pcF) of substate reserverd not paid is conjuncted with the state invariants of all its containing super states to get the state invariant of reserverd not paid. The invocation of methods in behavioral model describe the sequence in which methods should be called to get the required functionality. This constraints the implementation of our CRWS to provide required functionality. For example, as shown in Figure 5, a POST on pconfirmation resource cannot be invoked unless a POST on payment resource has been done. Also, in our conceptual model we did not include the information of methods that can be invoked on resources since a RESTful web service provides a uniform interface and every resource is manipulated using standard HTTP methods of GET, PUT, POST, DELETE. We now address the allowable methods on resources with our behavioral model. The allowable methods on a resource are shown in the behavioral model and also the conditions under which these methods can be invoked. For example, we cannot DELETE a booking unless a cancelHF resource has been created. Thus, we can say that our behavioral model not only constraints the implementation of a composite RESTful web service but also constraints the usage of the service. We require that a GET method can be invoked on each resource. The methods invoked on a composite REST web service trig-

Figure 5: Behavioral Model for HF Composite RESTful Web Service gers corresponding method on the resources of the partner web services. We model the method invocations on partner web services by entry actions or as effects of transitions. The entry actions are added in the states are the behaviors that are executed whenever a state is entered [18]. In Figure 5, whenever POST is called on bookingHF and the state Booking is entered, the transitions POST(bH ) and POST(bF) are also invoked. Also, the transitions that are triggered on partner web services as a result of method calls on composite web service can also be labeled as effect on the transition, such as, in case the target state is a final state and does not contain entry actions. In Figure 5 the trigger method DELETE(bHF) has an effect of calling methods DELETE(bH) and DELETE(bF) on partner web services Hotel Booking and Flight Booking, respectively.

RESTful web service interface. We are of the view that use of different elements of state machine can provide rich behavioral information for the interface. This behavioral model that is rich in behavioral information can serve as a specification document and guide the composite web service developer in implementing the interface. This enriched behavioral model can also be used to generate contracts and machine-processable interface specifications.

Different elements of state machines can be used to represent the behavior exhibited by the CRWS. A join transition between sates reserve and pay and waiting for confirmation show that target state waiting for confirmation cannot be entered until payment is made for both the room and flight service. Similarly, a choice node in state pconfirmation info, invokes the target state depending on the guard condition on the transitions.

7.

We can use different elements of state machine like fork transition, self transition, high-level transition etc to provide behaviorally enriched specifications of the composite

Our conceptual resource model and behavioral models have direct mapping to web service implementation languages like BPEL-REST [10], WADL [6], Django framework [7] and Ruby on Rails. In [13], we have discussed mapping to implementation languages.

RELATED WORK

The composition of RESTful web services is a relatively less explored area. However, we found works of Pautasso [12] [10] and Zhao and Doshi [19] noteworthy. In [19], Zhao and Doshi discuss the challenges faced in composition of RESTful web services and propose a formal model for classifying and describing RESTful web services. They present a situation calculus based state transitions system for automating the composition process of RESTful web services. In [11], Pautasso identifies set of requirements that should be satisfied by languages for RESTful service composition. A detailed case study is presented to understand this set of

requirements and implemented with JOpera. In [12] [10], Pautasso present REST extensions for BPEL. These extensions aim to support the process of REST composition using the same process-oriented service composition language that supports traditional web services. The work also demonstrates how a RESTful API can be implemented using BPEL with the proposed declarative constructs by exposing selected parts of its execution state. The role of contracts for validating a composite web service is also less explored. In terms of using contracts for web service composition, we found the work of Milanovic [8]. In [8], Milanovic present a contract-based web service composition approach. In this work, he presents specifications of nonfunctional properties of a service with contract-based framework for service descriptions. The work is supported with enhanced directory capabilities, web service design patterns and verification of service compositions by the introduction of formal composition language and verification criteria.

8.

[4]

[5]

[6] [7]

[8] [9]

CONCLUSION AND FUTURE WORK

In this paper we propose a modeling approach for web service compositions that are RESTful by construction. The static structure of the composition is modeled as a conceptual resource model. We use sequence diagram, activity diagram and state machines to represent the behavior of a composite RESTful web service. The sequence diagram models process scenario, activity diagram shows the process flow and the state machine represents the behavioral information in detail with state invariants and the effects of PUT, POST and DELETE methods on resources. The RESTful architectural style departs from the manner in which web services are usually designed and constructed by the developers. In this context, the designing of RESTful web services and compositions is considered a challenge. The presented work aims to facilitate the designing of RESTful compositions. These models also serve as part of specification document and can also be used in the testing phase to validate the implementation of a service against its expected behavior.

[10]

[11]

[12]

[13]

[14]

[15] The presented approach is an initial effort in providing a detailed modeling approach for composing a RESTful web service. The developed models have clear mapping to implementation languages like BPEL-REST, Django web framework, Ruby on Rails etc. We are currently working on maturing our approach and applying it on a detailed case study. We also plan to work on automation of the approach so that implementation stubs can be directly generated from these models.

9.

REFERENCES

[16]

[17]

[1] Thomas Amb¨ uhler. UML 2.0 Profile for WS-BPEL with Mapping to WS-BPEL. Universit¨ at Stuttgart, 2005. [18] [2] J Amsden, T Gardner, C Griffin, and S Iyengar. Draft UML 1.4 profile for automated business processes with [19] a mapping to BPEL 1.0. version 1.1, April 2004. http://www128.ibm.com/developerworks/rational/library/. [3] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business

Process Execution Language for Web Services Version 1.1. May 2003. http://www.ibm.com/developerworks/. A. Arkin, S. Askary, S. Fordin, S. Fordin, K. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer, S. Struble, P. Takacsi-Nagy, I. Trickovic, and S. Zimek. Web services choreography interface WSCI. August 2002. www.w3.org/TR/wsci/. R. Chinnici, J.J. Moreau, A. Ryman, and S. Weerawarana. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. 2007. www.w3.org/TR/wsdl20/. M. J. Hadley. WADL specifications. 2006. http://www.w3.org/Submission/wadl/. A. Holovaty and J. Kaplan-Moss. The Definitive Guide to Django: Web Development Done Right. Apress, 2007. N. Milanovic. Contract-based Web Service Composition. 2006. HU Berlin. M. Owen and J. Raj. BPMN and Business Process Management: An Introduction to the New Business Process Modelling Standard. Business Process Trends. www.bptrends.com. C. Pautasso. BPEL for REST. Proceedings of the 7th International Conference on Business Process Management (BPM08), pages 278–293, 2008. C. Pautasso. Composing RESTful services with JOpera. Proceedings of the 8th International Conference on Software Composition, pages 142–159, 2009. C. Pautasso. RESTful Web service composition with BPEL for REST. Data & Knowledge Engineering 68 ˝ (2009), page 851U866, 2009. I. Porres and I. Rauf. Modeling behavioral restful web service interfaces with uml. Accepted for publication in IEEE SERVICES 2010 Plenary Poster Session, 2010. I. Rauf, M.Z. Iqbal, and Z.I. Malik. UML Based Modeling of Web Service Composition-A Survey. Proceedings of the 2008 Sixth International Conference on Software Engineering Research, Management and Applications, pages 301–307, 2008. A. Ruokonen, L. Pajunen, and T. Systa. Scenario-Driven Approach for Business Process Modeling. Proceedings of the IEEE 7th International Conference on Web Services (ICWS 2009), pages 1–1, 2009. Q.Z. Sheng, B. Benatallah, M. Dumas, and E.O.Y. Mak. SELF-SERV: a platform for rapid composition of web services in a peer-to-peer environment. Proceedings of the 28th international conference on Very Large Data Bases, pages 1051–1054, 2002. B. Srivastava and J. Koehler. Web service composition-current solutions and open problems. Proceedings of ICAPS 2003 Workshop on Planning for Web Services, pages 28–35, 2003. OMG UML. 2.2 Superstructure Specification. OMG ed, 2009. http://www.omg.org/spec/UML/2.2/. H. Zhao and P. Doshi. Towards Automated RESTful Web Service Composition. Proceedings of the 2009 IEEE International Conference on Web Services, pages 189–196, 2009.