I CONCURSO LATINOAMERICANO DE TESIS DE ...I CONCURSO LATINOAMERICANO DE TESIS DE DOCTORADO, OCTUBRE 2015 1 Dynamic Composition of REST services Jesus Bellido Abstract—Service composition

I CONCURSO LATINOAMERICANO DE TESIS DE DOCTORADO, OCTUBRE 2015 1

Dynamic Composition of REST servicesJesus Bellido

Abstract—Service composition is one of the principles of service-oriented architecture; it enables reuse and allowsdevelopers to combine existing services to create new services. Dynamic composition requires that service componentsare chosen from a set of services with equal or similar functionality at runtime. The adoption of the REST services inthe industry has led to a growing number of services of this type, many with similar functionality. The existing dynamiccomposition techniques are method-oriented whereas REST is resource-oriented, and considers only traditional services.The REST architectural style has attracted a lot of interest from the industry due to the non-functional properties itcontributes to Web-based solutions. In this thesis, we contribute to the area of web service composition in RESTby proposing three techniques oriented to improve static and dynamic composition of this type of service. First weintroduce a technique for static composition proposing a set of fundamental control flow patterns in the context ofdecentralized compositions of REST services. In contrast to current approaches, our proposal is implemented usingthe HTTP protocol and takes into account REST architectural principles. Afterwards, we present a technique to improvethe dynamic composition in security domain extending ReLL to ReLL-S and allowing a machine-client to interact withsecured resources, where security conditions may change dynamically. Finally, we propose SAW-Q, an extension ofSimple Additive Weighting (SAW), as a novel dynamic composition technique that follows the principles of the REST style.SAW-Q models quality attributes, in terms of response time, availability and throughput, as a function of the actual servicedemand instead of the traditional constant values. Our results validate our main hypotheses indicating improvements withrespect to alternative state-of-the-art methods. This also shows that the ideas presented in this thesis represent a relevantcontribution to the state-of-the-art of REST service compositions.

Keywords—SOA, Web Services, Dynamic Compostion, REST, scalable architectures

F

1 INTRODUCTIONWeb services are software entities that providea determined functionality, they are platform-independent and can be described, published andconsumed following a defined set of standards suchas WSDL, UDDI and SOAP. These characteristicsemphasize loose coupling between components andallow designers to develop interoperable, and evolv-ing applications that can be massively distributed.Web services also promote the reuse of software,which reduces development costs, increases main-tainability, and enables organizations to create com-posed services by combining basic and other com-posed services resulting in new software with ag-gregated value [1].

Service composition is performed statically if itoccurs at design-time or dynamically if it occursat runtime. Also, depending on how the composi-tion is made, it can be manual or automatic. The

• J. Bellido is with the Department of Computer Science, PontificalUniversity, Chile.E-mail: [email protected]

Manuscript received April 19, 2005; revised January 11, 2007.

dynamic and automatic service composition is anactive research area due to the benefits of reducedneed for pre-installation and configuration of theservice composition, adaptability to change and con-texts, high decoupling and personalization, smallerdevelopment time, and reuse [1]. However, staticand manual techniques dominate in the industry dueto the complexity of discovering services dynami-cally (WSDL descriptions lack domain semantics)and automatic composition. In addition, virtuallyall research on service composition focuses on theclassic Web services (i.e. based on the WSDL,UDDI and SOAP standards). Currently, emergingservices technology such as REST 1 is becoming analternative to conventional services in the industry.

Unlike classical Web services which arecentralized and operation-centric, the RESTarchitectural style is resource-centric (e.g.www.puc.cl/course/12) that are manipulatedthrough a limited set of standard and knownoperations (e.g.HTTP. GET, POST, PUT, DELETE).REST services are popular because they allow

1. Representational State Transfer.


massive scalability, decoupling, and fault tolerance(e.g. Amazon API, Facebook API, etc.). REST hasattracted the interest of the scientific communityto serve as a supporting framework for definingbusiness processes and service composition. AREST resource should be able to be discoveredby a machine at runtime, and it should be ableto understand the mechanism of interaction withthe resource (e.g. to use GET to read, and to useDELETE to delete it). This property would makepossible to determine at runtime (dynamically) ifthe resource serves the consumer purposes, as wellas to determine the order in which the operations,that change the resource state, should be invoked.Thus, it would be possible to generate workflowsthat implement B2B processes dynamically andautomatically.

Currently, this is not possible because the RESTresources lack a description that encapsulate domainsemantics and can be interpreted by a machine.Moreover, current techniques of service compositionare oriented to classic Web services that invoke anunlimited set of operations, rather than resourceswhose state are transformed by invoking a limitedset of operations. The overall objective of this thesisis to contribute to the state of the art researchon static and dynamic composition of REST ser-vices through the design and implementation ofa dynamic composition model. In particular, wepropose a RESTful decentralized, stateless compo-sition model, a QoS model focused on security inorder to determine the feasibility of service com-position at runtime, and a QoS model focused onscalability, throughput and response time in orderto dynamically select the best service componentautomatically.

2 BACKGROUND

2.1 Service Oriented Architecture

Service orientation has existed for some time andhas been used in various contexts with differentpurposes. The most used form of this term has beento identify approaches that focus on the separationof concerns, which means that the logic requiredto solve a large problem that can be developedand managed, if such logic is decomposed into acollection of related pieces, and each piece gives asolution to a specific part of the problem [2].

This approach transcends technology but whencombined with software architecture, service ori-entation acquires a technical connotation. Service-oriented architecture (SOA) is a model in whichan application’s logic is decomposed into severalsmaller units that together implement a larger pieceof business logic. SOA promotes that these individ-ual units exist independently but not isolated fromeach other, in fact they could be distributed. This re-quires that these units operate on the basis of certainprinciples that allow them to evolve independentlywhile maintaining uniformity and standardizationamong them. In SOA these logical units are knownas services.

Web services encapsulate business logic and canprovide solutions to problems of various sizes. Theservice logic may include the logic provided byother services, in this case, the service is called acomposed service, and the logic providers are calledcomponent services. A component service may beresponsible for a single or a complex task. Webservices interoperate among them due to a commonunderstanding provided by services’ descriptions.The description of a service determines the serviceendpoint, the data received and the expected datareturned by the service through message passing. Inthis way, programs or services use a description anda message channel independent from a protocol tointeract and create a loosely coupled relationship.

In summary, SOA services maintain a relation-ship that minimizes dependencies (loose coupling),adhere to communication agreements (service con-tract), independently manage the logic they encap-sulate (autonomy), hide logic that is not relevant toa determined context (abstraction), separate respon-sibilities in order to promote reuse (reusability), canbe coordinated and assembled to form new services(composability), avoid to retain or store informationspecific to an activity (interaction stateless), and aredesigned to be described so they can be found andexecuted through discovery mechanisms (discover-ability). The collection of services raises an inven-tory of services that can be managed independently[1].

SOA establishes an architectural model that aimsto improve the efficiency, agility and productivitywhen developing software. It places services asfirst-class entities through which the business logicsare implemented in alignment with service-orientedcomputing goals.


2.2 Web servicesAccording to the context in which they are used,Web services may assume different roles: providers,clients and intermediaries. A Web service playsa provider role if it is invoked from an externalsource, and a client role if it invokes a providerservice. Client services look for and evaluate whichis the appropriate service to invoke based on theprovider service description. Intermediary servicesare those which play a role of routing and processingmessages sent between client and provider servicesuntil they reach their destination [1].

Traditional Web ServicesThe platform to implement Web services has beentraditionally defined by a set of industry standards.This platform is divided into two generations, eachassociated with a set of standards and specifications[1]. The first Web services generation is comprisedof the following technologies and specifications:Web Service Description Language (WSDL), XMLSchema Definition Language (XSD), Simple ObjectAccess Protocol (SOAP) and Universal DescriptionDiscovery and Integration (UDDI). These specifi-cations have been widely adopted in the industry;however, they lack information about service quality,which is required to address mission critical func-tionality at production level. The second generationadds extensions (WS-* extensions) to fill the gap,related to service quality, left by the first genera-tion. The main issues addressed by these extensionsare service security, transactions, reliable messagingservices, among others.

A traditional Web service is comprised of [1]:• A service contract that is, a WSDL document

describing the service interface (endpoint, op-erations and parameters) and an XML schemadefinition defining data types.

• The program logic. This logic may be im-plemented by the service itself, or inheritedand wrapped by the service so that the legacyfunctionality can be consumed.

• Message processing logic consists of a set ofparsers, processors and service agents. Theruntime environment generally provides thislogic.

• Software components that implement non-functional requirements defined by the WS-*standards extension.

REST Services

REpresentational State Transfer (REST) [3], [4] isan architectural style that underlies the Web. Thisapproach is another way of implementing a servicethat follows the design constraints and requirementsspecified by this architectural style. Each constraintcan have positive and negative impact on variousnon-functional attributes. The non-functional goalsof REST are: performance, scalability, simplicity,modifiability, visibility, portability and reliability.An architecture that lacks or eliminates one of theREST constraints is usually not considered a RESTarchitecture.

The REST architectural style constraints are:• Client-Server: Enforces separation of respon-

sibilities between two components of the ar-chitecture, the client and the server. Thisestablishes a distributed architecture whereeach component evolves independently. Thisrestriction requires the server to process therequests sent by the client.

• Stateless: Determines that the past communi-cation between the client and the service arenot kept stored on the server-side (service),that is, the interaction state is not rememberedby the service. This implies that each clientrequest must contain all the information nec-essary for the service to process the requestand respond accordingly, without the use ofsession information.

• Cache: Services responses may be temporarilystored in a Web intermediary component (e.g.routers, gateways, proxies, etc.) and thus avoidthe service to process a similar request again,diminishing the workload on the service-side.

• Uniform Interface: This constraint states thatthe architectural components must share asingle interface to communicate, which isdetailed below.

• Layered System. A REST-based solution cancontain multiple architectural layers. Theselayers may be added, modified and rearrangedaccording to the evolvability need of the so-lution.

• Code On Demand: This is an optional restric-tion that allows that some logic is dispatchedfrom the server to the client, to be executedon the client-side. It allows to customize Webapplications


The REST uniform interface is a set of architec-tural constraints that differentiates REST from anyother style:• Resources must be uniquely identified (e.g.

through a URI), and the identifiers must beopaque to prevent coupling, that is, the struc-ture of a URI shall not include any particularmeaning that can be guessed by a customer.

• Resources’ state must be manipulated throughoperations defined by standard (or ad-hoc)network protocols. For example, for the caseof HTTP, the operations are POST that initial-ize the state of a resource whose identifier isunknown and could possibly create a subordi-nate resource, GET which obtains a represen-tation including the current state of a resource,PUT that modifies the state of an existingresource, DELETE that indicates a request toeliminate a resource (but could be ignored bythe server). GET, PUT and DELETE opera-tions are idempotent and reliable. The POSToperation allows an unsafe interaction sincethe invocation of this operation may causechanges to the server [3].

• A resource can support multiple representa-tions that encode the state of the resourcein a particular format (e.g. XML denoted byapplication + xml). The format can benegotiated through HTTP headers to facilitateinteroperability between client and server.

• The HATEOAS (Hypermedia as the Engine ofApplication State) property indicates that thestate transitions modeled in a Web application(e.g. buy a book, pay the bill, provide thedeliver address, etc.) are served as hyperlinksthat indicate the user the set of actions avail-able to him or her at a given time (represen-tation).

2.3 Service CompositionSoftware integration involves connecting two ormore applications that may or may not be compati-ble, even when they are not built on the same plat-form or were not designed to interact with one an-other. The growing need for reliable data exchangeis one of the strategic objectives of integration. Webservices are inherently designed to be interoperableand are built with the knowledge that they will haveto interact with a long-range of potential serviceconsumers.

Web service composition is a technique that coor-dinates the combination of service components op-erating within an agnostic business process context.A composed service is comprised of component ser-vices that have been assembled in order to providethe functionality required to automate a task or aspecific business process. These service componentsmay be part of other compositions. The ability of aservice to be naturally and repeatedly composableis essential to achieve the strategic goals of service-oriented computing.

When Web services are composed, the businesslogic of the composed service is implemented byseveral services, which allows the creation of com-plex applications by progressively adding compo-nents.

Service composition is associated with businessprocesses automation. When a business processworkflow is defined, several decision points arecreated in order to define the dataflow and actionsaccording to variables and conditions evaluated atruntime. A business process definition can be donemanually if a person defines the sequence of in-vocations, or automatically if an algorithm definessuch sequence. In addition, service components canbe chosen at design time (static composition) or atruntime (dynamic composition).

Orchestration and ChoreographyIn service composition, the coordination of servicecomponents invocation can follow two styles: or-chestration or choreography. The orchestration isa centralized control of a business processes exe-cution; it defines the business logic and the orderof service invocation and execution. Unlike theorchestration, the choreography has a decentralizedapproach; services collaborate and determine its rolein the interaction.

Orchestration is the process by which variousresources can be coordinated to bring out the logicof a business process. Orchestration technology iscommonly associated with a centralized platformfor activities management [5]. Service orchestrationencapsulates a service business process and otherservices invocations. The most widely used tech-nology in the industry to implement orchestrationsis the Web Service Business Process ExecutionLanguage (WS-BPEL) [6].

REST’s navigational style naturally supports aworkflow style of interaction between components.


However, interaction is decentralized, componentsare loosely coupled and can mutate at any time. Thischaracteristic, called evolvability, poses a challengeto service composition since components (resources)may change unexpectedly. Hence, clients must makefew assumptions about resources and must delaythe binding with the actual resources up to theinvocation-time (dynamic late binding) [7].

REST composition research focuses on orches-tration, with JOpera [7] being the most matureframework. In JOpera, control and data flow arevisually modeled while an engine executes the re-sulting composed service. In [8], control and dataflow is modeled and implemented using a PetriNet whereas interaction and communication withthe resources themselves is mediated by a servicedescription called ReLL [9]. In [10], control flow isspecified in SPARQL and invoked services could beWSDL/SOAP-based endpoints or RESTful services(i.e., resources); from the orchestrator perspective,services are described as graph patterns. In [11]resource’s graph descriptions are publicly available(can be discovered using HTTP OPTIONS). A setof constraints regulates when certain controls canbe executed on resources (e.g., a required state),so that an orchestrator engine could perform acomposition, but no indication is given about how toexpress such constraints. The two former approachessupport dynamic late binding and the hypermediaconstraint. An RDF-based approach for describingRESTful services where descriptions themselves arehyperlinked is proposed in [12]. The approach ispromising for service discovery at a high level ofabstraction; however, no support for dynamic latebinding is provided and the composition strategy isnot detailed.

Choreographies can be described from a globaland local (one party) perspective. WS-CDL [13]is a W3C candidate recommendation that describesglobal collaboration between participants in termsof types of roles, relationships, and channels. WS-CDL defines reactive rules, used by each participantto compute the state of the choreography and deter-mine which message exchange will or can happennext. Stakeholders in a choreography need a globalpicture of the service interaction, but none of themsees all the messages being exchanged even thoughsuch interaction has an impact on related parties[14].

In [15], REST-based service choreography stan-

dards evolution is presented. Business processes,modeled as choreographies, are implemented assingle resources at a higher level. The lower levelcomprises the resources themselves (process in-stances). Although the approach provides processstate visibility, it is not clear whether the higherlevel corresponds to a centralized orchestration orto a partial view of choreography.

2.4 REST services composition

Resources and resource collections are the com-ponents in a RESTful scenario [7], [16]. UnlikeWSDL-based services, REST resources have stan-dardized, few, and well-known assumptions at theapplication level (i.e. the Web) instead of the domainlevel. Resources must be identified with a URI(Universal Resource Identifier) that binds the propersemantics (at the application level) to the resource([3] section 6.2.4), and must be manipulated throughlinks and controls (i.e. an HTML form) embeddedin a resource’s representations (e.g., HTML page).Representations dynamically determine the set ofresource’s state transitions available to consumers(Hypermedia as the engine of application state [3]).

Composition requirements that are specific toREST are dynamic late binding, that is, the URIof the resource to be consumed can be known onlyat runtime; the composed service must also supportthe REST uniform interface; data types are knownat runtime; content negotiation must be allowed; andclients must be able to inspect the composed service[16], [17].

Currently there are no proposals for automaticand dynamic composition of REST services. RESTservices composition research is mainly focusedon static service composition [16], [17]. The mostcomprehensive work in the area is the JOpera project[18] that aims to provide a similar implementationof BPEL for REST. JOpera allows the static com-position of Web services by means of two graphs.The first, Flow Control Dependency Graph (CFDG)describes the sequence of invocation of services, andthe second, the Data Transfer Flow Graph (DFTG)defines the relationship between the data inputsand outputs when invoking the REST components.Unlike BPEL, service composition in JOpera al-lows that the service URI to be invoked is knownat runtime (dynamic late binding), it also suportsthe uniform interface, and content negotiation at


runtime. However, JOpera does not consider theHATEOAS constraint, and the CFDG is performedby a centralized process engine, in a stateful fashionwhich negatively impacts on service scalability.

Similarly, Bite [19] proposed a BPEL-inspiredcomposition language describing data and controlflow. Bite partially supports a uniform interfacebased on HTTP, dynamic data types, and state in-spection (only GET and POST). Regarding dynamiclate binding, Bite can generate URIs to createdresources, but cannot inspect the service’s responsesand find out the links provided by the service(HATEOAS).

Decker [20] presents a formal model for im-plementing REST processes based on Petri nets,they uses PNML (Petri Net Markup Language) as alanguage for specifying the states, transitions and anexecution engine. Decker considers only partial sup-port for dynamic late binding since it can generateURIs for resources created but cannot inspect theresponses and retrieve the embedded links. In thismodel, control flow is driven by the decisions of ahuman user. Guard conditions, such as autenticationare not supported and like others [21] it assumesXML as the content type for representations leavingout REST content negotiation constraint.

Zhao [22] presents an automatic service composi-tion approach for REST typifying and semanticallydescribing the services in three categories accord-ing to the operations that the service can perform(GET, PUT, POST, DELETE). Service compositionis automated by a first-order logic situation calculusrepresenting changes and actions. This approachdoes not consider several of the REST principlessuch as HATEOAS, content negotiation, opaqueURIs, nor dynamic late binding.

2.5 QoSThe quality of service (QoS) is a combination ofseveral qualities or properties of a service [23].Dynamic composition of Web services requires theconsumer to choose the best component servicesthat satisfy the functional and non-functional re-quirements of the composition. Non-functional re-quirements involve attributes of quality of service asresponse time, availability, security and performance[23].

The definition and measurement of these at-tributes of service quality vary by approach. For

example, the response time can be measured asthe average of the results obtained of the last 15minutes, or an average vector of 15-minute intervalsduring the day.

The quality attributes of a service depend onthe load current at which the service is submitted,however the technical description of these qualityattributes of a service are focused on the descriptionof a discrete value associated with each property.

QoS in RESTFor the case of REST, research initiatives on servicecomposition are fairly recent, and interest on QoSproperties have focused mainly on security. Forinstance, in [24] a RESTful service API is defined tosupport service-level agreements based on the WS-Agreement standard. Agreements (and templates)are REST resources encoded in the application/xmlmedia-type, whose life cycle and state is handledby means of HTTP verbs. Graf et al. present aserver-side authorization framework based on rulesthat limit access to the served resources accordingto HTTP operations [25]. In [26] a server-sideobligation framework allows designers to extendedexistent policies with rules regulating users’ infor-mation access. Rules may trigger additional trans-actions (e.g., sending a confirmation e-mail, registerthe information access attempt in a log) or evenmodify the response content or the communicationprotocol (e.g., require HTTPS). Allam [27] aimsto homologate WSDL-based and RESTful servicesby considering them black boxes, where interactionoccurs as simple message passing between clientsand servers. Security policies can be placed when re-ceiving or sending a message as well as locally (e.g.,at the server or client side). This vision does notconsider complex interaction involving third parties(e.g., OAuth), or service’s interface heterogeneity[28], where industry standards are implemented invarious ways. We assume a workflow perspectivewhere data is transformed locally in successive stepsuntil the message constraints required by the serviceprovider are achieved. In addition, clients, servers,and third party services may engage in an interactionthat implements sub-workflows.

3 REST LIMITATIONS

The REST architectural style offers several advan-tages when compared to traditional Web services


in terms of non-functional attributes, namely, lowlatency (small response time), massive scalability(due mainly to statelessness, cacheability, and Webintermediaries), modifiability, and simplicity, amongothers. However, REST considers humans as itsprincipal consumer and they are expected to driveservice discovery and state transition by under-standing the representation content. The lack of aREST machine-readable description forces serviceproviders to describe their APIs in natural language,which makes difficult to properly design machine-clients that can perform discovery and service com-position in an automated way.

Furthermore, REST has been used in the industryas an infrastructure layer for supporting massiveservice provisioning in the form of Web APIs whichhave given rise to the evolution of applicationecosystems that constitutes simple service compo-sition basically consuming services in a sequentialcontrol-flow pattern. A massively used example ofcomplex control-flow is the OAuth protocol thatconstitutes an orchestration where various partiescooperate through redirections in order to implementa workflow. The control-flow patterns involved inthe OAuth are sequence and conditional execution.Researchers also recognize the lack of a complexservice behavior model in REST as one of thedifficult issues to be addressed in order for REST tosupport rich SOA (Issarny, 2009). Research propos-als for REST service composition focus either onoperation-centric [29], centralized [7], stateful andstatic service composition, violating REST architec-tural constraints.

Traditional Web services dynamic and automaticcomposition focuses on diverse techniques (e.g.planning, graph models, semantic models, QoS con-straints, etc. in order to make possible the automaticor dynamic generation of a composition plan (i.e. aworkflow) and the selection of the services com-ponents [30]. QoS has been a focus of extensiveresearch and is being recently addressed in RESTbut not in its capacity for determining service com-position on runtime. Furthermore, the very nature ofthe non-functional attributes makes it hard to reducethem to uniform representations such as numbers orBoolean values. Security for instance requires notonly a complex combination of algorithms but alsoprotocols (in the case of OAuth a choreography)in order to determine whether a service can becomposed or not. For the case of response time,

availability and throughput, research in Web sitesprovisioning, also known as capacity planning, havedemonstrated the variables such as the user demandand cache policies are relevant to determine thequality of a Web site (equivalent to a single RESTservice). Hence such quality attributes cannot bereduced to simple numeric variables as is the caseof traditional QoS-aware compositions in SOA.

4 GENERAL GOALS

The overall objective of this thesis is to facilitate thedynamic composition of REST services. In particu-lar, we propose:

1) A decentralized RESTful, stateless composi-tion model that places an emphasis on servicebehavior (control-flow),

2) A QoS model focused on security in orderto determine the feasibility of composition atruntime, and

3) A QoS model focused on scalability, through-put and response time in order to select theservice component automatically at runtime.

5 HYPOTHESIS

The main hypothesis of this thesis is related tothe relevance of decentralized service composition,in that "a stateless and decentralized compositiontechnique follows the REST architectural style con-straints and generates a composite service with thesame REST properties whereas a centralized com-position does not". Second, "QoS-based dynamicand automatic RESTful service composition musttake into account the characteristics of the non-functional attributes in order to preserve RESTarchitectural constraints in the composite service".

6 THESIS WORK AND MAIN CONTRI-BUTIONS

The first part of this thesis presents a techniquefor decentralized, hypermedia-centric and statelessREST services composition. The proposed tech-nique models services behavior through a set ofwell-known, simple and complex control-flow pat-terns and focuses on the following REST con-straints, namely, client-server interaction, layeredclient-server, client-stateless-server, and the uniforminterface. The uniform interface (messages betweenserver and client are self-descriptive) was extended


through 300 HTTP redirection codes in order toinclude control-flow information in the message;hypermedia (Web linking) is used as the applicationstate machine. We present the advantages of thisapproach (centralized Vs. decentralized) in terms ofresponse time, availability and throughput, whichare non-functional goals in REST. By definitiona stateful approach is not RESTful so that suchcomparison is left out.

The second part of this thesis describes automaticand dynamic REST services composition based onnon-functional attributes. In this part two QoS do-mains are analyzed, the first corresponds to securityand the proposal is a hybrid between static anddynamic service composition in the sense that aservice description (created at design-time) is usedto determine the feasibility of service composition(at runtime) and actually enforce the composition (atruntime). The environment is decentralized, statelessand promotes the use of hypermedia as a statemachine.

The third part of the thesis focuses on a secondQoS domain considering scalability. That is, thenon-functional attributes: response-time, throughputand availability were used to support automaticand dynamic service composition. In this case, aqueuing theory-based model was used to identifyresponse-time, throughput and availability. Thesemodels were later used in a technique called SAW-Q to identify the compositions with the highestquality. SAW-Q was compared with a well-knowntechnique, SAW (from which SAW-Q was derived)with good results.

Accordingly, the main contributions of this thesisare:

1) Part 1a) A decentralized, stateless, hypermedia-

centric technique for designing com-posed service behavior in REST.

b) A set of control-flow patterns thatimplement decentralized, stateless,hypermedia-centric REST servicecomposition.

These contributions were published in thefollowing journal:J. Bellido, R. Alarcon and C. Pautasso.Control-Flow Patterns for DecentralizedRESTful Service Composition. ACM Trans-actions on the Web 8:1 (5:1âAS5:30). ACM

2013.2) Part 2

a) A centralized, hybrid (design-time andruntime) and manual REST servicecomposition based on the security QoSattribute.

b) A security domain model.c) An extension to ReLL, a hypermedia

REST service description, that consid-ers the security domain model in orderto determine the feasibility of consum-ing a protected service and actuallyexecute the OAuth choreography:

These contributions were published in thefollowing journal:C. Sepulveda, R. Alarcon, and J. Bellido.QoS aware descriptions for RESTful servicecomposition: security domain. World WideWeb 1-28, 2014

3) Part 3a) A decentralized, dynamic REST ser-

vice composition technique based onthe response-time, throughput andavailability QoS attributes.

b) A queuing theory-based REST model.c) A response-time, throughput and avail-

ability models based on the proposedqueuing model.

d) SAW-Q, a refinement of SAW, a tech-nique for scoring service compositionsin terms of various variables such asresponse-time, throughput and avail-ability that is sensible to user demandand service capacity.

These contributions were submitted to thefollowing journal:J. Bellido, R. Alarcon, and C. Pautasso. SAW-Q: An approach for dynamic composition ofREST services. IEEE Transactions on Ser-vices Computing, 2014.

Other articles were also produced during thisinvestigation:• R. Alarcon, E. Wilde and J.Bellido.

Hypermedia-driven RESTful servicecomposition. Service-Oriented Computing.Springer Berlin Heidelberg, 2011. 111- 120.

• J.Bellido, R. Alarcon and C. Sepulveda. WebLinking-based protocols for guiding RESTfulM2M interaction. Current Trends in Web En-


gineering (pp. 74-85). Springer Berlin Heidel-berg, 2012 15

The remainder of this document is organized asfollows: Section 7 presents the journal that sum-marizes the results of the first part of the thesis.Section 3 explores the attributes of service qualityin the RESTful services composition, focused onsecurity. Section 8 presents the dynamic compo-sition approach based on SAW-Q and scalability(response-time, throughput, availability). Section 8presents the main conclusion of this thesis and futureresearch.

7 CONTROL FLOW PATTERNS FOR DE-CENTRALIZED RESTFUL SERVICE COM-POSITIONDescribes a technique for decentralized REST ser-vices composition that takes into account the con-straints of REST architectural style in the compo-sition process. The proposed technique involves thecreation of control-flow patterns that allow seamlessinteraction between the client and the compositeservice and uses hypermedia as a state machine.The main idea is to implement control-flow patternsthrough callbacks and redirections. Finally, we dis-cuss the impact of our design decisions accordingto the architectural principles of REST.

The redirection code (303) was designed to in-form the user agent it must fetch another resource,and it is widely used for services to interact withother services and accomplish business goals. Forexample, OAuth and OpenID are popular authoriza-tion and identity protocols implemented using redi-rection codes; payment entities which offer onlinetransactions are also implemented using redirectioncodes in order to allow e-commerce applications tosell products online in a security context under theircontrol.

Due to constraints on the 303 redirection code,it cannot support complex interaction successfully.For instance, parameters should be serializedin a text format and concatenated to the URI(application/x-www-form-urlencoded),and information that cannot be serialized as plaintext cannot be passed between applications inthe URI parameters (e.g., images, pdf documents,etc). The resulting URI must not exceed thelimit established by the server, otherwise theserver should return a 414 Request-URI

Too Long status code message. In order tosend large quantities of data, the media typemultipart/form-data and the POST methodshall be used for submitting forms that containfiles, non-ASCII data, and binary data. In addition,only the GET HTTP method can be used toautomatically fetch the redirected URI, but as seenin our example, applications may be required tointeract with each other using additional methodswithout requiring end-user confirmation (e.g., POSTand PUT messages 3 and 10 in Figure??).

More importantly, control flow may be morecomplex than sequential invocation of REST re-sources. Business processes also require parallel oralternative invocation as well as determining theconditions for choosing the right response; morecomplex control flows consider the invocation oftwo services in non established order but only one ata time (unordered sequence), or service invocationfor a determined number of times iterator.

Finally, notice that the composed REST ser-vice (PO and /stateN resources) encapsulates theknowledge about which services to invoke (URI),which parameters or state information should be sentand be expected to be received, which methods shallbe used (e.g., GET (7) or POST (12) in Figure ??), aswell as the order of the invocation; that is, they mustknow the service interface of the resource, which inour case is accomplished through ReLL.

7.1 Control flow patternsIn the context of stateless, decentralized composi-tions of services described with ReLL and with theassumption that clients can process the Callbacklink header, in this section we model control-flowpatterns for RESTful service composition and theHTTP protocol. The set of patterns includes se-quence, unordered sequence invocation, alternative,iteration, parallel, discriminator, and selection [31],[32].

Sequence, Unordered SequenceThe sequence pattern is a basic control-flow struc-ture used to define consecutive invocations of ser-vices which are executed one after the other withoutany guard condition associated. As seen in figure ??,this pattern could be implemented using the 303redirection code; however, only automatic redirec-tion of GET messages are allowed by the standard,


making it difficult to update the composed resourcestate (i.e., PUT message of lines 5, 9). In addition,there is no clear indication on how to handle thepayload of the message. We extend the status codeswith a set of codes identified with a two digitprefix: 31x. The sequence pattern is implementedwith a new code: 311 (Sequence) indicating theinvocation of a service without any guard condition(see Figure 1).

User Agent

<<callback>>Composed/ <<resource>>

S1/R1<<resource>>

S2/R2

311 (Sequence) Link: </S1/r1/>;method="OP2"

Callback: /Composed/state1payload: state, interface

OP2 /S1/r1payload 200 (Ok)

statePUT /Composed/state1aggregated state

311 (Sequence) Link: </S2/r2>;method="OP3"

Callback: /Composed/state2 payload: state, interfaceOP3 /S2/r2

payload 200 (Ok)state

S1 S2

PUT /Composed/state2aggregated state

200 (OK)Composed service final state

(3)

(7)(8)(9)

(2)

(1)

(4)(5)

(6)

OP1 /Composed/state0

(10)

<<state>>/state1

<<state>>/state2

<<state>>/state0

SEQ

Fig. 1. A sequence control flow pattern imple-mented for REST and HTTP

The server responds with a 311 message includ-ing the component resource address (2, 6) in a Linkheader as well as the HTTP method in a link targetattribute, and a Callback address in an additionalheader indicating the state of the composition. Ad-ditional information such as state (e.g., a digestedvalue) and, depending on the service interface, dataformats or URI schemes to create the request, canbe included in the payload. Actual data values forsuch templates shall be provided by the user agenteither by requesting them to the user through anappropriate interface or retrieving them from thelocal storage. Such process is out of the scope ofthis proposal. The server may close the connectionwith the client after issuing a 311 message unlessmetadata indicating otherwise is included. When auser agent receives this code, it must store locallythe callback address and automatically request thecomponent resource using the indicated method (3,7). Similarly to Figure ??, if additional communi-cation shall occur between the component resourceand the user agent it must be modeled as out-of-bandcommunication and is omitted for readability. Whenthe response is available, the component replies with

a 200 status code. The composed service shall notissue another request until the response has beenpassed by the user agent through a PUT message(5), then the composed service can proceed with thenext component (6 to 9).

Descriptors

User Agent

<<callback>>Composed

<<resource>>S1/R1

<<resource>>S2/R2

311 (Sequence) Link: </S1/r1>;method="OP2"

Callback: /Composed/state1

GET /S1.rell200 ok

<<service>>S1

(3)(2)(1)

(4)

(5)(6)

<<service>>S2

GET /S2.rell200 ok

OP1 /Composed/

Fig. 2. ReLL descriptors are fetched consider-ing the root resource of a service

When all the components have been fetched (i.e.,the final state of the sequence has been reached), theresponse is provided with a 200 status code andthe composed service representation (10). Noticethat the actual HTTP methods to be used wheninvoking component services must be determinedby the composed resource. In order to know howto handle the resources, the composed service pre-fetches the component services descriptors whichdetail the interface of a set of resources at domain-level; the descriptors are themselves REST resources(Figure 2). This phase is omitted in the figuresdetailing the remaining patterns for readability, al-though it is assumed it takes place before invokinga component resource.

S1

S2S1

S2

Fig. 3. Unordered Sequence

For the case of the unordered sequence pattern,it specifies the execution of two or more services inany order but not concurrently (Figure 3). That is,given two services S1 and S2, the services execu-tion can result as S1 followed by S2 or S2 followedby S1. Since the list of services to be invoked isknown by the composed resource and the order isirrelevant, the composed resource (server) has theinformation to decide which service to invoke as partof its own logic. For the user agent, all that mattersis the address of a particular component resource to


be invoked as well as the method; that is, this caseis not different from a sequential invocation.

Alternative, Exclusive choiceThe alternative pattern is a basic control-flow struc-ture that allows the execution of only one of twopossible services. The service to be executed coulddepend on the outcome of preceding service ex-ecution, values of the parameters, or a user de-cision. The 312 (Alternative) status codeis proposed for this pattern. When a composedservice requires executing one of two services, itresponds to the client request with a 312 codedmessage, indicating the list of services to chooseas Link headers, including the HTTP method asan attribute, and a Callback header indicating theconnector state to resume interaction. The messagepayload is a conditional expression to be evaluatedby the user agent, as well as information requiredto build proper request messages (i.e., data formatsor URI schemes).

S1

S2

[Condition]

[else]

User Agent

<<callback>>Composed/

<<resource>>S1/R1

<<resource>>S2/R2

312 (Alternative) Link: </S1/r1>;method="OP2",

</S2/r2>;method="OP3"Callback: /Composed/state1

Conditionpayload: state, interface


state

PUT /Composed/state1aggregated state 200 (OK)

Composed service final state

(4)

(8)(9)

(2)

(1)

(5)

(6)(7)



state

Eval Condition(3)

<<state>>/state1

<<state>>/state0

ALT

Fig. 4. An alternate control flow pattern imple-mented for REST and HTTP

The composed resource closes the connectionafter issuing the response unless otherwise indicatedby additional headers. Link services may differ onthe resources (URIs), or the methods to be used(Figure 4, message 2). Since in REST user agentskeep application-state information [33], they shallhave enough information to perform the evaluation.A good practice is to express the condition inlanguages well-known to the Web, such as XPath,although its format escapes the scope of this thesis.Once the user agent has evaluated the condition itdetermines which link to follow (4 or 6). Again,

additional communication may occur between a useragent and an origin server. Eventually when thecomponent has a final response, it issues a 200coded response including its state in the payload (5or 7). This causes the user-agent to send an updatemessage (PUT) to the composed resource carryingon the received payload (8). Once the interactionfinishes, the composed resource replies with a 200message including the representation of its final state(9).

Iteration, Structured Loop - while variantThis pattern is an advanced control-flow structurethat allows the execution of a service repeatedly,the number of times depending on a fixed num-ber, a time frame, etc. which can be modeledby a conditional expression. We propose the 313(Iteration) status code for representing itera-tions.

LOOP

S1

User Agent

<<callback>>Composed/ <<resource>>

S1/R1

313 (Iteration) Link: </S1/r1>;method="OP2"Callback: /Composed/state1

Condition payload: state, interface


state



(4)

(2)

(1)

(5)

(6)(7)


[Condition]

Eval Condition(3)

<<state>>/state1

<<state>>/state0

Fig. 5. An iterator control flow pattern imple-mented for REST and HTTP

This interaction begins when the composed re-source issues a 313 message (Figure 5, message2) including a Link header with the address ofthe component resource, a Callback header in-dicating the callback connector state address, aconditional expression, and additional informationto create the message request as part of the payload.After evaluating the conditional expression (3) andobtaining positive results, the message is redirectedto the component resource using the indicated op-eration and payload (4). Communication betweenclient and server may include several messagesinterchanged. When a response is available, thecomponent resource will issue a 200 message (5).The condition will then be evaluated again. If itstill holds, the component is invoked again (4);


or a PUT message is sent to the callback addresscarrying along the response content served by thecomponent service aggregated with previous stateinformation (6). Finally, at the end of the interaction,the component replies with a 200 message and therepresentation of the composed resource final state(7).

Parallel Split - Synchronization, Structured Dis-criminator, Structured Partial Join, Local Syn-chronization Merge (Selection)The Parallel Split is a simple pattern that allowsa single thread of execution to be split into twoor more branches invoking services concurrently.The parallel split pattern can be paired with eitherone of four advanced control-flow structures. Underthe paradigm of a composed service - componentservices, it is the former which determines whether itwaits for all the responses (Synchronization, Figure6.a), just one of them (Structured Discriminator,Figure 6.b), or a fixed number (Structured PartialJoin, Figure 6.c). Finally, for the case of Local Syn-chronization Merge (also called Selection, Figure6.d), the composed service shall wait for a numberof responses that cannot be determined with localinformation.

<<state>>/state0

S1

S2

User Agent

<<resource>>S1/R1

<<resource>>S2/R2

317 (Selection) Link: </S1/r1>;method="OP2",

</S2/r2>;method="OP3"Callback: /Composed/state1

payload: state, interface{Condition}

OP2 /S1/r1 payload 200 (Ok)

state



(3)

(2)(1)

(4)

(6)(7)



state

S1

S2

(8)

S1

S2

n

(a) 314 (Synch) (b) 315 (Discriminator)

(c) 316 (PartialJoin)

(5)

<<state>>/state1

<<callback>>Composed/

S1

S2

(d) 317 (Selection)

Eval Condition

(9)

[Condition]OPT

PAR

Fig. 6. A parallel control flow pattern imple-mented for REST and HTTP

In order to avoid violating the REST statelessprinciple, servers do not store information about

how many answers are expected per client, but makeexplicit server’s expectancies through the patternstatus codes, 314 Synch (Synchronization), 315Discriminate (Structured discriminator), 316PartialJoin (Structured Partial Join) and 317Selection (Local Synchronization Merge). Thefour patterns follow the same conversational struc-ture; however, the client’s decision to inform theserver about the availability of a final response isaffected by the corresponding pattern.

Figure 6 shows the details for the pattern. In-teraction starts when the composed resource issueseither a 314, 315, 316 or 317 message (Figure6, message 2). The message includes a list ofLink headers annotated with a method attribute, aCallback header indicating the callback connec-tor state address, and a payload with instructions toformat input data for the operations according ser-vice interface. It may also include state informationsuch as the number of expected service componentsto be addressed by the client for the case of the 316Partial Join pattern.

For the case of a 317 Selection message, aconditional expression must be included. The condi-tion must be evaluated considering application-stateinformation stored locally at the client side (3), andthe result shall be the number of request messagesthe client must issue to service components.

Once the user agent determines how many re-sponses to provide to the composed resource (all,one, n out of m, or n), it invokes all the servicecomponents indicated in the list with the appropriatemethods concurrently (4, 6). In practice the numberof links to be fetched is limited by the number ofconcurrent connections the client is able to maintainwith the servers involved. Again, there may occurseveral messages interchanged between clients andorigin servers as an out-of-band conversation, butonce the final response is available, it is aggregateduntil the number of responses expected to be sentto the composed service is reached. The aggregatedstate is sent as a 200 coded request (8). Thecomposed resource processes the aggregated state(e.g., it could merge the results) and issues a 200coded response with the final state.


8 QOS AWARE DESCRIPTIONS FORRESTFUL SERVICE COMPOSITIONWe explore QoS aware RESTful services compo-sition, which is characterized by a decentralized,stateless and hypermedia-driven environment. Wefocus particularly on the security domain sincecurrent security practices on the Web illustrate thedifferences between both the centralized, function-based approach and the decentralized, hypermediaand resource-based approach. We rely on ReLL (aREST service description) that can be processedby machine-clients in order to interact with REST-ful services. Our approach identifies key securitydomain elements as an ontology. Elements serveto model hypermedia-based, decentralized securitydescriptions supporting simple and complex interac-tion such as protocols and callbacks. In this paper,we propose an extension to ReLL that considerssecurity constraints (ReLL-S) and allows a machine-client to interact with secured resources, wheresecurity conditions may change dynamically. A casestudy illustrates our approach.

8.1 ReLL-S security descriptionCompared to traditional services, security is ad-dressed in a different way on the Web. InMaleshkova et al. [34] a review of the self-declared REST Web APIs corresponding to the Pro-grammableWeb site 2 was analyzed regarding theirsupport of security mechanisms. The Maleshkovaet al. study analyzes a Web site that is a well-known repository for services (including WSDL,REST, XML-based, Web APIs, etc.). They picked222 services from the RESTful service category(18%) covering the 51 service categories (e.g.,search, geolocalization, etc.) available. The securitymechanisms found range from very simple practices(the majority), to the W3C standards on security onthe Web. For instance, 38% uses API Keys whilstthe OAuth protocol is used by 6% of the reportedservice. Notice that mainstream so-called REST ser-vices (e.g., Facebook, Twitter, Google, etc.) supportand require OAuth authentication. Therefore, webelieve the study is representative from a practical(and informal) and a theoretical (standards) point ofview. In this section we present ReLL-S descriptionssupporting each of the security mechanisms identi-fied in the Maleshkova et al. survey.

2. http://www.programmableweb.com

8.2 OAuthOAuth [35] is an Open Authorization protocol thatallows a third-party application - a client application- to access resources provided by a service - resourceserver - and owned by a user. The user has toauthorize the third-party application to access theresources stored by the resource server, withoutexposing his or her authentication credentials, tothe third-party application. The authorization grantis represented as a token.

OAuth defines four grant types: authorizationcode, implicit, resource owner password credentials,and client credentials; and provides an extensionmechanism for defining additional grant types. Theprotocol flow is flexible and depends on the type ofauthorization that is going to be granted. So in theflow shown in Figure 7, up to four parties could beinvolved: the resource owner, the resource server,the authorization server, and the client. The resultof the protocol is an access token that representsthe authorization granted by the resource owner andthat is sent later by the client to the resource serverto access the restricted resources.

What is interesting about this protocol is thatit involves more than two entities that can com-municate using a protocol that has been designedfor client-server communication, as it is HTTP, ina stateless one-to-one conversation. However, thischaracteristic presents particular issues to deal with,which makes it really interesting to describe in moredetail.

Resource

ServerClient Auth

Server

(A)

GET http://[AuthServer]

Payload: Credentials, requestToken, callback

POST http://[AuthServer]]

200 Ok

Payload: access_token

(B)

GET http://[callback]/?authorization_code

Resource

Owner

grant access

Payload: Credentials, authorization_code

(F)

(G)

GET http://[ResourceServerUri]/[resource]

20X Ok

Payload: representation of resource

302 Redirect [Location]

GET http://[Location]

(D)

(E)

(C)

Fig. 7. Abstract OAuth interaction between fourparties

Once the client has required the access grant, the


authorization server starts a conversation with theresource owner that, from the client’s perspective,occurs completely out of its control. This conversa-tion’s goal is asking the user to give authorizationto access the resources. It could be implementedmany ways; the authorization server could send anemail to the user, an SMS, or any other kind of con-versation. In most implementations the conversationoccurs synchronously by redirecting the user-agentfrom the client domain to the authorization serverdomain. So that, to restore the interaction betweenuser and client, the authorization server must alsoredirect the user-agent to the client. If the usergrants access rights to the client, such redirectionmessage will contain an authorization grant. Thisconversation implements an asynchronous conver-sation through a callback connector provided by theclient, which becomes the target of the redirection.

Once the client has the authorization grant, it canuse it to retrieve an access token from the server.The client sends its credentials and the authorizationgrant, representing the permissions granted by theuser, to the server. The server verifies the permissionand generates a final token (access token, or oathtoken) to be used in future calls, so that the resourceserver allows access to restricted resources. It couldhave an expiration time and some authorizationservers provide the feature to refresh or renew thetoken.

Listing 1. An authorization constraint specifica-tion (OAuth)<scope resource="restrictedResources">

<constraint id="oauthAuth"type="Authorization">

<accessToken><query_param name="auth_token"

select="$auth_token||wl:OAuth"/></accessToken>

</constraint></scope>

<protocol name="wl:OAuth"><invoke

url="http://www.authserver.com/oauth"pre="not($auth_code)">

<query_param select="$state"name="extra"/>

<query_param select="$callback"name="callback"/>

</invoke><invoke

url="http://api.service.com/getToken"pre="$auth_code">

<query_param select="$auth_code"name="auth_code"/>

<store selector="token"persist="auth_token"/>

</invoke></protocol>

In this case the client makes two calls to getauthorization to the user’s restricted resources. Thefirst one could include the callback address andalso a parameter, named state, that must be sentback by the authorization server when issuing thecallback request to the client. The client can usethe parameter to keep the flow state. The callbackcall will include also the authorization code usedby the client to get the final authorization tokenduring a second call. The order of both calls isdefined by their preconditions (i.e. they play theroles of guard conditions). That is, when the clientruns the protocol, it will invoke the first call initiallybecause it doesn’t have the auth_code storedlocally. Once the request is issued, the client blocksitself waiting for an answer. When the callbackarrives, the client is restarted and since its currentcondition has changed (i.e., it has the code) then itwill make the second call (the condition is met) tofinally resolve the authorization constraint.

9 SAW-Q: AN APPROACH FOR DY-NAMIC COMPOSITION OF REST SER-VICES

SAW-Q: An approach for dynamic composition ofREST services: We propose SAW-Q an extensionof SAW, as a technique of dynamic compositionaccording to the principles of the REST style andconsidering quality attributes modeled as a demandfunction instead of the traditional constant values.Our model is much more accurate when compared toreal implementation, positively improving dynamiccomposition.

9.1 Modeling REST QoS service usingQueue ModelsThere are multiple ways to measure the performanceof a service. The most common metrics are responsetime, availability and throughput. A service responsetime is the time interval from the request arrivalto the server until the response is received by the


client and is determined by two factors: the networklatency and bandwidth and the service capacity. Theway a REST service processes requests and repliescan be modeled using queuing theory. The clientrequests follow the Poisson distribution [36], [37]and are randomly distributed over a period of time.The generalized queuing model considers the long-term behavior of the queue or steady state, reachedafter the system has been running for a sufficientlylong period of time.

Performance measures of a queue are based onthe probability that a certain number of requests mayexist in a system at a given time (pn). For instance,p0 would represent the probability of a minimalwaiting time due to an empty queue (0). Morein detail, useful performance measures are[37]: theexpected amount of requests in the system (Ls),which includes the expected number of requestsfrom customers in the queue (Lq), the waiting timeof a request to be processed by the service (Ws) andthe waiting time of the request in the queue (Wq).

Some specializations of the generalized queuesystem that calculates performance measures havebeen proposed and proved. The specialized queuemodel corresponding to a REST service isM/M/C : GD/N/INF , where N ≥ C asdescribed before. The corresponding performancemeasure formulas originally defined in [37] aredescribed below.

Given the estimated rate of requests (λ) that arriveat the system (S), the rate of denied request dependson the rate of arrival at a given time (Formula 1).The higher the arrival, the higher the probability ofdenied requests.

λlost = λ · pN (1)

The effective rate of arrival is the difference be-tween the arrived requests minus the denied requests(Formula 2)

λeff = λ− λlost = (1− pN) · λ (2)

The rate between arrival (λ) and processed re-quests rate of the system (µ) is defined by ρ = λ/µ.It is possible to calculate the expected number ofrequests waiting in the queue Lq(s) using Formula3 [37] , and the expected number of requests in theLs(s) system using Formula 4.

Lq(s) =ρc+1

(c− 1)!(c− ρ)2

{1−

(ρc

)N−c+1

− (N − c+ 1)(1− ρ

c

)(ρc

)N−c}p0

(3)

Ls(s) = Lq(S) + ρ (4)

The processing time for a REST service is definedas a rate between the number of processed requestand the effective arrival rate of requests (Formula5).

Ws(s) =Ls(s)

λeff(5)

The waiting time in the waiting queue for arequest in a REST system is defined as a ratebetween the number of requests waiting in the queueand the effective arrival rate of requests (Formula 6).

Wq(s) =Lq(s)

λeff(6)

The average service response timeQResponseT ime(s) is calculated as the sum ofthe processing time of the services (Ws) andthe waiting time in the queue of requests (Wq),as seen in Formula 7. We are not consideringnetwork latency since this is out of the scope ofresponsibility and control of the service.

QResponseT ime(s) = Ws(s)+Wq(s) =Lq(s)

λeff+Ls(s)

λeff(7)

Replacing the factors in the formula in order toreflect the clients demand dependency, we obtain thefollowing Formula 8.

QResponseT ime(s) =Lq(s)

(1− pN)λ+

Ls(s)

(1− pN)λ(8)

Service processing capacity is defined as thenumber of requests that a system (the whole numberof service replicas) can process at a given time.The service availability QAvailability(s) is usuallymeasured as the percentage of time that the serviceis ready to be consumed at a period of time [37].However, the availability of a service depends on thenumber of customers attempting to access a service.If the number of requests (n) exceeds the capacityof the service (C ≤ n < N ), the availability isdowngraded because many request try to accessand compete for the service resources, hence the


probability of being served is reduced. Otherwise,if the number of requests (n) falls below the servicecapacity (0 ≤ n < C), the availability of theservice grows. Service availability is calculated asthe probability that n requests exist in the system(pn). Service availability is calculated using Formula9.

QAvailability(S) =

ρn

n!p0, 0 ≤ n < c

ρn

c!cn−cp0, c ≤ n < N(9)

The service throughput QThroughput(s) is the num-ber of requests that the service can process in aunit of time (i.e. seconds). If QResponseT ime is thefunction to calculate the time that takes a requestto be processed by the service, then the quantityof requests that can be processed by the service inone second is calculated as the inverse function ofQResponseT ime, as seen in Formula 10 .

QThroughput(S) =(1− pN)λ

Lq(S) + Ls(S)(10)

9.2 Applying the Queue Model in a real sce-narioWe implemented a REST service as a Python scriptrunning on a Apache Web server. The experimentwas performed locally, in order to discard the effectof network latency, on an Intel PC with 4GB RAM,and 4 cores. We also modeled response time, avail-ability and throughput using the equations proposedin section 3.4. The implemented service is charac-terized as Ws = (1, 20, 50) where each instance isable to process one request per second, the serviceis replicated 20 times and there may be up to 50requests in the system at a given time. The responsetime was calculated using the proposed formulasand we obtained the experimental results from thestress tests using Apache JMeter, the tests were run10 times automatically and averaged, in order toeliminate external factors. For each scenario, resultsbetween the models and the experiments are verysimilar, for the case of response time the resultsshow that when the number of requests exceeds theprocessing capacity of the service, the response timeincreases until the requests are denied (Figure 8(a));service availability decreases exponentially (Figure8(b) ), and throughput remains constant once theservice reaches the maximum capacity (Figure 8(c)).

1000 10 20 30 40 50 60 70 80 90

3

0

0,5

1

1,5

2

2,5

Workload (req/s)

Resp

onse

Tim

e (s

)

(a) Response Time

1000 10 20 30 40 50 60 70 80 90

1,1

00,10,20,30,40,50,60,70,80,9

1

Workload (req/s)

Avai

labi

lity

(%)

(b) Availability

1000 10 20 30 40 50 60 70 80 90

21

02468

1012141618

Workload (req/s)

Thro

ughp

ut (r

eq/s

)(c) Throughput

Fig. 8. Comparison between estimated (con-tinuous line), using the proposed formulas, andactual (shown as dots) behavior of a service indifferent scenarios. (a) The average responsetime of a service increases when the workloadexceeds the capacity of the service (20 req/s);(b) service availability is reduced when the ser-vice is unable to process more requests (20req/s); (c) and service throughput grows accord-ing to the workload until reaches its maximumcapacity (20 req/s).

9.3 Dynamic Composition based in QoS us-ing Queue Model

In order to compose a service dynamically andbased on the quality attributes, we need to selectthe service components as late as possible (dynamiclate binding) and at runtime. In this paper wepropose a strategy of hybrid dynamic compositionthat combines the techniques of workflow drivencomposition and declarative composition. Compo-sition techniques guided by a workflow define anabstract process model for the composed service and


later each activity of the model is bound to a par-ticular service. Declarative composition techniques,on the other hand, use customer-defined rules andconstraints to determine if the resulting compositeservice meets customer expectations. In this case,service selection will depend on the fulfillment ofeach user-defined condition. Quality attributes ofthe resulting concrete service composition can beevaluated using a utility function using global andlocal optimization techniques [38].

On the other hand, the workflow can be seenas an arrangement of control-flow operators (e.g.sequence, conditional, parallel, etc.) that impact theutility function defined in a declarative technique.For example, the response time of a composedservice that includes the sequential invocation ofservice components, results in the sum of the re-sponse time of the service components. If the serviceinvocation happens in parallel, the response timeof the composed service is the maximum value ofthe response time of the invoked services. Whenthe invocation occurs within a loop, the composedservice response time is the product of servicecomponent response time and the times that it isinvoked. For the case of the conditional control-flowpattern, the response time of the composed service,in the worst case, is the maximum response timeof the components to be chosen by the alternativecondition. In [38], the influence of control-flow op-erators in the quality attributes of composed servicesare defined as aggregation functions.

A typical example of service composition is theTravel Planner. In this composite service, the searchof places for entertainment (Attraction search) isperformed in parallel with the reservation serviceand an airline reservation service of a hotel. Then,the distance between the place of entertainmentand the hotel is calculated and depending on theoutcome, a car rental or a bike rental service maybe chosen. The abstract process of this compositeservice can be seen in Figure 9.

According to the algebra of service composition[39], the Travel Planner service is defined byWtp = {(AttractionSearch‖(TicketBooking �Hotelbooking)) � DriveT imeCalculation �(BikeRental � CarRental)}. In the notation,control-flow dependencies are denoted by symbols,for instance ‖ defines parallel invocation, � definessequential invocation, and � defines a conditionalinvocation. Each task of an abstract process can be

implemented using one of many existing services,which results in a composite service that shouldmeet the user expectations. The number of possibleways for composing this Travel Planner servicedepends on the number of service candidates foreach task. That is, if each task in the abstractprocess has two service candidates, then thereare 26 different ways to implement the compositeservice. The objective of dynamic composition isto find the combination that gives the user thegreatest benefits. In the remainder of this section weintroduce SAW, which proposes a utility functionthat identifies the best combination according tomultiple criteria.

Ticket Booking

Attraction Search

Driving Time Calculation

Hotel Booking

Bike Rental

CarRental

Fig. 9. Abstract BPMN model of the compositeservice travel planner

Simple Additive Weighting (SAW)One way to assign a score to each possible ser-vice combination is by using the Simple AdditiveWeighting (SAW) utility function defined by For-mula 13 [40]. The SAW technique consists of aprocess of assigning scores to each combinationthrough two phases: scaling and aggregation orweighting. At the stage of scaling the values of thequality attributes of the candidate services are nor-malized between 0 and 1 by a comparison betweenthe maximum and minimum values. Then, duringthe aggregation phase the following formulas areused to calculate the score of a composite service.

To define a particular composed service, we con-sider an abstract model CSabstract = S1, S2, ..., Sn,restricted by customer defined constraintsQoSconstraints = C1, C2, ..., Cm. The processthat assigns a score for each combination ofservices CSx = s1, s2, ..., sn of the abstractmodel works as follows: the quality attributes ofeach candidate service s is represented by thefeature vector q(s) = q1, q2, ..., qk, therefore qk(s)represents the k-quality attribute value for service s.Thus, Qmin(j, k) and Qmax(j, k) defined in Formula11 represent the minimum and maximum value ofthe k quality attribute for the service candidates toimplement a service Sj task.


Qmin(j, k) = min∀s∈Sj

qk(s)

Qmax(j, k) = max∀s∈Sj

qk(s)(11)

Then Q′min(k) and Q′max(k) defined in Formula12 calculate the minimum and maximum value ofthe k quality attribute for the abstract model usingthe aggregation functions F , defined in Table ?? foreach operator of the model.

Q′min(k) = Fknj=1(Qmin(j, k))

Q′max(k) = Fknj=1(Qmax(j, k))

(12)

Finally, the utility function assigns a score to thecomposite service CSx, calculated by Formula 13where the scores obtained for each quality attributek, are weighted by the user preferences W =(w1, w2, . . . , wk)

U ′(CSx) =r∑

k=1

(Q′max(k)− q′k(CSx)Q′max(k)−Q′min(k)

· wk) (13)

Simple Additive Weighting using Queue Model(SAW-Q)

Since dynamic composition aims to find the bestservice for each task at runtime, the time requiredto meet this objective has an important role. Itis for this reason that techniques such as integerprogramming, dynamic programming, heuristic anddistributed processing are mainly used in order toreduce the time service selection. However, mosttechniques ignore service demand while evaluatingquality scores, which causes that the resulting com-position may not be the most useful in practice.Hence, we modify the SAW technique to take intoaccount the expected customer demand.

Unlike the previous model, in this model eachservice candidate s is defined by the vector of qual-ity attributes q(s, λ) = qrt(s, λ), qav(s, λ), qth(s, λ).That is, by modeling REST services as a queuingsystem, we can calculate the quality attributes of aservice according to the expected customer demandfor the composite service (λ), using the formulas 8,9 and 10 (Section 9.1). Hence, the SAW formulaspresented before are modified introducing the userdemand:

Qmin(j, k, λ) = min∀s∈Sj

qk(s, λ)

Qmax(j, k, λ) = max∀s∈Sj

qk(s, λ)(14)

Q′min(k, λ) = Fknj=1(Qmin(j, k, λ))

Q′max(k, λ) = Fknj=1(Qmax(j, k, λ))

(15)

The proposed utility function including clients’demand, SAW-Q, is defined by Formula 16:

U ′(CS, λ) =r∑

k=1

Q′max(k, λ)− q′k(CS, λ)Q′max(k, λ)−Q′min(k, λ)

· wk

(16)The component services are selected according to

the values obtained from SAW-Q for each abstractworkflow. There are four factors that determine suchvalue: the number of tasks the abstract model ofthe composite service; the number of candidates ofthe composite service services; quality constraintsdefined by the customer; and the control-flow pat-terns used in the abstract model. The control-flowpatterns determine the execution path of a compositeservice. Depending on this, the component servicescan be invoked in sequence, in parallel, iteratively,or following alternative conditional execution paths.The quality attributes of a composite service aredetermined by the aggregate functions in Table??. The utility value ranks an implementation (ofall possible) by calculating the expected behaviorfor each quality constraint. Therefore, since eachcontrol-flow pattern influences the utility functionin various ways, the number and variety of control-flow patterns of an abstract model influence thechoice of the best implementation and the bestservice for each task. As implementation optionsgrow, the utility function becomes more importantin the decision process to choose the best servicefor a task component.

9.4 Implementation and EvaluationImplementationOur principal hypothesis is that a dynamic com-position approach based on quality restrictions thatdoes not considers the user demand leads to im-plementations that can be erroneous in practice. Inthis section, we describe the implementation of aREST service composer based on SAW-Q, which is


$_Request Receiver

WS Data

QoS API

Optimizer

Queue Model

WS Composer Service

App Service

WS Data

App Logic

WS Orchestrator

Ochestration Engine

Invocation Handler

Control flow handler

(redirect)

Client

Fig. 10. Prototype architecture for dynamiccomposition using SAW-Q

a prototype that allows us to illustrate our resultsexperimentally.

Figure 10 describes the prototype architecture.The module Receiver accepts the arriving requests($_Request); it is responsible for recording ser-vice access and delivering the message to the nextcomponent. The App Logic module handles therequest and determines its purpose in order to createa new instance of an existing composed service(e.g. POST) or to update the status of an existingone (e.g. PUT). When a new instance is requested,the WS Composer Service module determines theservice components for the abstract process (CSx).It accomplishes this task by invoking the Opti-mizer component which runs either SAW or SAW-Q in order to determine the utility values for thecombination of service candidates. The Optimizeruses the Queue model library to perform equations8, 9, and 10 (Section 9.1 ). The WS ComposerService defines the service invocation plan to follow.On the other hand, if the application intends toupdate the status of an existing composed service,then the request is derived to the WS Orchestratormodule (Orchestrator Engine) that is responsible forexecuting the composition plan.

The Orchestrator Engine chooses at runtime thenext service candidate with the highest score accord-ing the utility function determined by the WS Com-poser (Invocation Handles), and finally the Control-flow Handler executes the composition plan (i.e.prepares the HTTP request messages to be sent).

Control-flow patterns were implemented consid-ering REST architectural constraints as proposedin [41]. Hence, we use redirections in order to

keep application state on the client. The Control-flow Handler module extends the service responsewith header metadata corresponding to control-flowpatterns as defined. This allows us to implementservice compositions that are fully decentralized andstateless.

Services were implemented similarly to thoseof section 3.5, that is, as Python scripts (Django)running on an Apache Web server with PostgreSQLpersistence. The experiment was performed online,the client run on an Intel PC with 4GB RAM,and 4 cores, the server (Ubuntu) runs on a virtualmachine with 4 cores, 3GB RAM. Each servicecandidate was replicated up to 10 times in a LANconfiguration.

Evaluation

In order to validate the obtained results empirically,we implemented both techniques SAW and SAW-Q to choose at runtime the best service candidatesusing the previously described prototype. Servicesworkload (requests/second) analysis was performedusing the load-testing tool JMeter, for a time longenough to obtain stable results. The results obtainedin this experiment confirms that SAW-Q’s rankingsfit better the experimental results.

Our experimental scenario comprehends a datasetof 6 tasks corresponding to the abstract BPMNmodel shown in Figure 9. For each task in the busi-ness process we implemented 2 alternative services,that is, we implemented 12 services which werecharacterized with a random arrival rate between4 to 10 requests per second, with random replicas(between 1 to 5) and a random capacity for eachreplica of 10 to 40 services in the waiting queue.

The response time is a quality attribute that neg-atively affects the quality of service when it grows.In this experiment the average response time fora service following SAW is higher than the oneobtained using SAW-Q when the user demand istaken into account. Figure 13 shows the impact ofchanges in the demand from 1 to 19 requests persecond on SAW and SAW-Q. For each value of thedemand, we considered the average response timeof the composed service with the highest score forSAW and SAW-Q (Figure 11(a)). The differencesbetween both techniques can be appreciated whenthe demand scales up to 8 requests per second, fromthen, the services with the highest score according to


200 2 4 6 8 10 12 14 16 18

7000

0

1000

2000

3000

4000

5000

6000

Workload (request/s)

Resp

onse

Tim

e (m

s)

SAW

SAW-Q

(a) Response Timeaccording SAW andSAW-Q

200 2 4 6 8 10 12 14 16 18

110

0

10

20

30

40

50

60

70

80

90

100


Avai

labi

lity

(%)

SAW-Q

SAW

(b) Availability accord-ing SAW and SAW-Q

200 2 4 6 8 10 12 14 16 18

550

0

50

100

150

200

250

300

350

400

450

500


Thro

ughp

ut (r

eq/m

in)

SAW-Q

SAW

(c) Throughput accord-ing SAW and SAW-Q

Fig. 11. SAW/SAW-Q comparison.

SAW obtains a higher response time when comparedto the top score services obtained by SAW-Q, hencequality of the services selected by SAW is worst thanthose services selected by SAW-Q.Figure 11(b) andFigure 11(c) shows the impact of SAW and SAW-Q selections on the availability and throughput ofthe services with highest score. Again the differencebetween both techniques appears since the workloadis 9 requests per second.

In Figure 12 we go further analyzing the situationwhen the demand reaches 8 requests per second.(λ = 8req/s). The dots represent the obtained re-sults and the continuous line, the average. Note thatin the composition proposed by SAW the standarddeviation is bigger than the composition using SAW-Q.

The availability of the services composed usingSAW-Q, on average, is greater than the compositionsobtained using SAW. Figure 13 shows the availabil-ity of both services when the demand is 8req/s. Thedots are the obtained results an the continuous lineshows, the measures average.

Composite service throughput using SAW-Q isslightly higher than the one using SAW which meansthat the SAW-Q composite service has the capacityto serve more requests per minute than the SAWcomposite service. Figure 14 shows the results of

120.0000 20.000 40.000 60.000 80.000 100.000

1200

400

500

600

700

800

900

1000

1100

Time (ms)

Resp

onse

Tim

e (m

s)

(a) Response Time SAW

120.0000 20.000 40.000 60.000 80.000 100.000

1200

400

500

600

700

800

900

1000

1100

Time (ms)

Resp

onse

Tim

e (m

s)

(b) Response Time SAW-Q

Fig. 12. SAW/SAW-Q comparison: Composedservice response time.

120.0000 20.000 40.000 60.000 80.000 100.000

100

60

65

70

75

80

85

90

95

Time (ms)

Avai

labi

lity

(%)

(a) Availability SAW

120.0000 20.000 40.000 60.000 80.000 100.000

100

60

65

70

75

80

85

90

95

Time (ms)

Avai

labi

lity

(%)

Label

(b) Availability SAW-Q

Fig. 13. Availability comparison between bothtechniques of composition.

both services when the demand is 8 requests per


second. Again, the dots are the obtained results andthe continuous line shows the average.

120.0000 20.000 40.000 60.000 80.000 100.000

500

0

50

100

150

200

250

300

350

400

450

Time (ms)

Thou

ghpu

t (re

ques

t/m

in)

(a) Throughput SAW

120.0000 20.000 40.000 60.000 80.000 100.000

500

0

50

100

150

200

250

300

350

400

450

Time (ms)

Thro

ughp

ut (r

eque

st/m

in)

(b) Throughput SAW-Q

Fig. 14. Throughput comparison between SAWand SAW-Q.

10 CONCLUSIONS

10.1 Regarding Decentralized, stateless,complex service behavior in RESTIn Section 7 a proposal for the design and imple-mentation of complex composed service behavior ispresented. This proposal places emphasis on RESTarchitectural constraints, having as goal to achievescalability and statelessness for the composed ser-vice behavior. With these considerations in mind,a set of well-known control-flow patterns that areused to implement simple and complex behavior intraditional Web services were recreated.

The main conclusion from the experience isthat a decentralized, stateless implementation of acomposed service satisfies REST architectural con-straints and provides significant improvements re-garding throughput and availability, which are non-functional goals of REST.

Second, when following REST architectural con-straints and a decentralized, stateless approachwhere the client (User Agent) shares the interaction

responsibility with the server, control-flow patternsdesign in REST differ from those in SOA wherestate (information interaction) is kept in a central-ized component (the orchestrator).

Third, one of the extensibility mechanisms ofHTTP, namely status codes, was used to implementthe presented approach. Other alternatives could beused, such as link headers, or ad-hoc media types(e.g. a specialized JSON document). However, theprecedence for link processing indicates that suchmessages must be processed after the representationis fully received and processed by the client and afterusers have performed the actions they required (e.g.click on buttons, or run javascript controls), whichintroduces not only delays but also security risks.

Finally, the presented approach requires that theclient knows in advance how to process the mes-sages, so that, it shall be a process-oriented UserAgent. In addition, this design choice also includesthe typical vulnerabilities of nowadays User Agents.Additional measures such as digital signatures mustbe included in order to guarantee a safe interactionbetween services (mediated by the User Agent).

10.2 Regarding hybrid (static and dynamic)service composition in RESTIn Section 8 a technique that exploits hypermedia-centric REST service descriptions (defined at designtime) is used at runtime to determine the feasibil-ity of service composition and actually enacting acomposition with an authentication service based onOAuth. Again a decentralized approach, a choreog-raphy, was followed.

The main conclusion from this approach is thathypermedia-centric REST service descriptions canactually serve as a basis for a well-behaved UserAgent traverses complex paths on the Web of ser-vices. However, since such descriptions are createdat design-time, dynamic changes on the service pro-vision (e.g. changes on the service interface) couldnot be reflected on the descriptions. Descriptionsthat are out of sync with the service implementationsmay impede the User Agent to continue its work,although a good service description can provide in-formation to the client developer so that the changescan be easily noticed.

Second, a QoS domain (security) is addressedin this section not only because an important au-thorization technique (OAuth) is an example of a


highly scalable and well-known choreography, butalso because QoS-aware service composition is afield that have been extensible studied in order tosupport automatic and dynamic service composition.QoS attributes, particularly security are playing amajor role in the current Web due to the massivescale, performance, availability and evolvability re-quirements that pervade modern Web applications.However, most techniques reduce QoS complexityto single values (e.g. booleans or numbers) when inpractice some, such as security, shall be representedas a combination of diverse algorithms and protocolsthat could be available or not, or even worst shall betried to follow in order to discover the feasibility ofchoosing a service as a component for a composedservice.

10.3 Regarding dynamic service composi-tion in RESTIn Section 9, SAW-Q (an extension of SAW) isproposed as a novel dynamic composition techniquethat follows the principles of the REST style. SAW-Q models quality attributes as a function of theactual service demand instead of the traditionalconstant values.

The main conclusion is obtained when comparingboth techniques SAW-Q is much more accuratethan SAW when compared to real implementations,positively improving the quality of dynamic servicecompositions. Quality attributes of a REST servicesuch as, availability, response time and throughputcan be modeled with better accuracy using queuingtheory since it considers implementation details thatare particularly relevant for service architecture,such as the processing time of the application,the number of times the service is replicated, themaximum number of clients that can be handled byeach service replica at a given time and the requestthat remain in the waiting queue.

Second, choosing the right candidate service indynamic composition is a critical task. Differentways of measuring the quality of a service canlead to errors. The dynamic composition techniqueproposed, SAW-Q, considers the attributes of servicequality as a function of the demand for requests thusobtained composed services that behave better thanthose determined by SAW.

Finally, the present approach contributes a deeperanalysis on the scalability related attributes. Con-sidering the request demand or workload when

modeling services and composed services is crit-ical particularly to certain quality attributes suchas throughput, response time, and availability butalso fault tolerance and even price, which are notconsidered in our study.

REFERENCES

[1] T. Erl, Soa: principles of service design. Prentice Hall UpperSaddle River, 2008, vol. 1.

[2] ——, Service-oriented architecture: concepts, technology, anddesign. Pearson Education India, 2005.

[3] R. T. Fielding, “Architectural styles and the design ofnetwork-based software architectures,” Ph.D. dissertation,University of California, Irvine, 2000. [Online]. Available:http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm

[4] T. Erl, B. Carlyle, C. Pautasso, and R. Balasubramanian, SOAwith REST: Principles, Patterns &Constraints for BuildingEnterprise Solutions with REST, 1st ed. Upper Saddle River,NJ, USA: Prentice Hall Press, 2012.

[5] J. Mendling and M. Hafner, “From ws-cdl choreography tobpel process orchestration,” Journal of Enterprise InformationManagement, vol. 21, no. 5, pp. 525–542, 2008. [Online].Available: http://dx.doi.org/10.1108/17410390810904274"

[6] D. Jordan, J. Evdemon, A. Alves, A. Arkin, S. Askary,C. Barreto, B. Bloch, F. Curbera, M. Ford, Y. Goland et al.,“Web services business process execution language version2.0,” OASIS standard, vol. 11, p. 11, 2007.

[7] C. Pautasso, “Composing restful services with jopera,” inSoftware Composition, ser. Lecture Notes in Computer Science,A. Bergel and J. Fabry, Eds. Springer Berlin Heidelberg, 2009,vol. 5634, pp. 142–159.

[8] R. Alarcón, E. Wilde, and J. Bellido, “Hypermedia-drivenrestful service composition,” in 6th Workshop on EngineeringService-Oriented Applications (WESOA 2010). Springer, 2010.

[9] R. Alarcon and E. Wilde, “Linking data from restful services,”in Third Workshop on Linked Data on the Web, Raleigh, NorthCarolina (April 2010), 2010.

[10] R. Krummenacher, B. Norton, and A. Marte, “Towards linkedopen services and processes,” in Future Internet - FIS 2010,ser. Lecture Notes in Computer Science, A. Berre, A. GÃsmez-PÃl’rez, K. Tutschku, and D. Fensel, Eds. Springer BerlinHeidelberg, 2010, vol. 6369, pp. 68–77.

[11] S. Stadtmüller and A. Harth, “Towards data-driven program-ming for restful linked data,” in Workshop on Programmingthe Semantic Web (ISWCâAZ12), 2012.

[12] R. Verborgh, T. Steiner, D. Deursen, R. Van de Walle, andJ. Valles, “Efficient runtime service discovery and consumptionwith hyperlinked restdesc,” in Next Generation Web ServicesPractices (NWeSP), 2011 7th International Conference on, oct.2011, pp. 373 –379.

[13] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon,and C. Barreto, “Web services choreography description lan-guage version 1.0,” W3C candidate recommendation, vol. 9,2005.

[14] G. Decker, “Process choreographies in service-oriented envi-ronments,” Ph.D. dissertation, Masters thesis, Hasso PlattnerInstitute at University of Potsdam, 2006.


[15] M. zur Muehlen, J. V. Nickerson, and K. D. Swenson,“Developing web services choreography standardsâATthecase of {REST} vs. {SOAP},” Decision SupportSystems, vol. 40, no. 1, pp. 9 – 29, 2005, webservices and process management. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S0167923604000612

[16] C. Pautasso, “Restful web service composition withbpel for rest,” Data Knowl. Eng., vol. 68, no. 9,pp. 851–866, September 2009. [Online]. Available:http://dl.acm.org/citation.cfm?id=1550965.1551240

[17] O. Nierstrasz and T. D. Meijler, “Requirements for a composi-tion language,” Lecture Notes in Computer Science, vol. 924,pp. 147–161, 1995.

[18] C. Pautasso and G. Alonso, “The {JOpera} visualcomposition language,” Journal of Visual Languagesand Computing, vol. 16, no. 1âAS2, pp. 119 – 152,2005, 2003 {IEEE} Symposium on Human CentricComputing Languages and Environments. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S1045926X04000400

[19] F. Rosenberg, F. Curbera, M. Duftler, and R. Khalaf, “Compos-ing restful services and collaborative workflows: A lightweightapproach,” Internet Computing, IEEE, vol. 12, no. 5, pp. 24–31, Sept 2008.

[20] G. Decker, A. Lüders, H. Overdick, K. Schlichting, andM. Weske, “Restful petri net execution,” in WS-FM, 2008, pp.73–87.

[21] X. Xu, L. Zhu, Y. Liu, and M. Staples, “Resource-orientedarchitecture for business processes,” in Software EngineeringConference, 2008. APSEC ’08. 15th Asia-Pacific, Dec 2008,pp. 395–402.

[22] H. Zhao and P. Doshi, “Towards automated restful web ser-vice composition,” in Web Services, 2009. ICWS 2009. IEEEInternational Conference on, July 2009, pp. 189–196.

[23] D. Menasce, “Qos issues in web services,” Internet Computing,IEEE, vol. 6, no. 6, pp. 72 – 75, nov/dec 2002.

[24] R. Kübert, G. Katsaros, and T. Wang, “A restfulimplementation of the ws-agreement specification,” inProceedings of the Second International Workshop onRESTful Design, ser. WS-REST ’11. New York, NY,USA: ACM, 2011, pp. 67–72. [Online]. Available:http://doi.acm.org/10.1145/1967428.1967444

[25] S. Graf, V. Zholudev, L. Lewandowski, and M. Waldvogel,“Hecate, managing authorization with restful xml,” inProceedings of the Second International Workshop onRESTful Design, ser. WS-REST ’11. New York, NY,USA: ACM, 2011, pp. 51–58. [Online]. Available:http://doi.acm.org/10.1145/1967428.1967442

[26] J. P. Field, S. G. Graham, and T. Maguire, “Aframework for obligation fulfillment in rest services,”in Proceedings of the Second International Workshopon RESTful Design, ser. WS-REST ’11. New York,NY, USA: ACM, 2011, pp. 59–66. [Online]. Available:http://doi.acm.org/10.1145/1967428.1967443

[27] D. Allam, “A unified formal model for service orientedarchitecture to enforce security contracts,” in Proceedings ofthe 11th Annual International Conference on Aspect-orientedSoftware Development Companion, ser. AOSD Companion’12. New York, NY, USA: ACM, 2012, pp. 9–10. [Online].Available: http://doi.acm.org/10.1145/2162110.2162120

[28] J. Hongbin, Z. Fengyu, and X. Tao, “Security policyconfiguration analysis for web services on heterogeneousplatforms,” Physics Procedia, vol. 24, Part B, no. 0, pp.

1422 – 1430, 2012, international Conference on AppliedPhysics and Industrial Engineering 2012. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S1875389212002544

[29] F. Rosenberg, F. Curbera, M. J. Duftler, and R. Khalaf,“Composing RESTful services and collaborative workflows:A lightweight approach,” IEEE Internet Computing,vol. 12, no. 5, pp. 24–31, 2008. [Online]. Available:http://doi.ieeecomputersociety.org/10.1109/MIC.2008.98

[30] D. DâAZMello, V. Ananthanarayana, and S. Salian, “A reviewof dynamic web service composition techniques,” in AdvancedComputing, ser. Communications in Computer and InformationScience, N. Meghanathan, B. Kaushik, and D. Nagamalai, Eds.Springer Berlin Heidelberg, 2011, vol. 133, pp. 85–97.

[31] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kie-puszewski, and A. P. Barros, “Workflow patterns,” Distributedand Parallel Databases, vol. 14, no. 1, pp. 5–51, 2003.

[32] N. Russell, Arthur, W. M. P. van der Aalst, and N. Mulyar,“Workflow control-flow patterns a revised view,” BPMcen-ter.org, New York, NY, USA, Tech. Rep. BPM-06-22, 2006.

[33] G. D. Ivan Zuzak, Ivan Budiselic, “A finite-state machineapproach for modeling and analyzing restful systems,” WebEngineering, vol. 10, no. 4, pp. 353–390, 2011.

[34] M. Maleshkova, C. Pedrinaci, J. Domingue, G. Alvaro, andI. Martinez, “Using semantics for automating the authenticationof web apis,” in The Semantic Web - ISWC 2010, ser. LectureNotes in Computer Science, P. Patel-Schneider, Y. Pan, P. Hit-zler, P. Mika, L. Zhang, J. Pan, I. Horrocks, and B. Glimm, Eds.Springer Berlin / Heidelberg, 2010, vol. 6496, pp. 534–549.

[35] E. Hammer-Lahav, “The oauth 1.0 protocol,” 2010.[36] Q. Tao, H. you Chang, C. qin Gu, and Y. Yi,

“A novel prediction approach for trustworthy qosof web services,” Expert Systems with Applications,vol. 39, no. 3, pp. 3676 – 3681, 2012. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S0957417411013698

[37] H. A. Taha, Operations research: an introduction. Pearson-/Prentice Hall, 2007.

[38] M. Alrifai, T. Risse, and W. Nejdl, “A hybrid approachfor efficient web service composition with end-to-end qoSconstraints,” TWEB, vol. 6, no. 2, p. 7, 2012. [Online].Available: http://doi.acm.org/10.1145/2180861.2180864

[39] R. Hamadi and B. Benatallah, “A petri net-basedmodel for web service composition,” in FourteenthAustralasian Database Conference (ADC2003), ser. CRPIT,K.-D. Schewe and X. Zhou, Eds., vol. 17. Adelaide,Australia: ACS, 2003, pp. 191–200. [Online]. Available:"http://crpit.com/confpapers/CRPITV17Hamadi.pdf"

[40] M. Zeleny and J. L. Cochrane, Multiple criteria decisionmaking. McGraw-Hill New York, 1982, vol. 25.

[41] J. Bellido, R. Alarcón, and C. Pautasso, “Control-flow patternsfor decentralized restful service composition,” ACM Trans.Web, vol. 8, no. 1, pp. 5:1–5:30, December 2013. [Online].Available: http://doi.acm.org/10.1145/2535911

Documents

I CONCURSO LATINOAMERICANO DE TESIS DE ...I CONCURSO LATINOAMERICANO DE TESIS DE DOCTORADO, OCTUBRE 2015 1 Dynamic Composition of REST services Jesus Bellido Abstract—Service composition