The adoption of REST - an architectural paradigm focusing on resources - by various providers like Google, Facebook and Yahoo strongly in uences traditional Business Process design approaches layered atop of Web service description language (WSDL) and SOAP based Web services. Beside the architectural di erences manifested in integration challenges for existing business process environments this new paradigm eases service development and enables lightweight integration in Web-oriented architectures. This paper introduces a model-driven approach to integrate di erent domains into Service Mashups: a) Orchestration information derived from WS-BPEL processes, b) Coequal integration of RESTful Web services and WS-* Web services and c) Role-based collaboration of process participants. The introduced concepts are implemented as a platform to enable collaborative Service Mashup design. The prototype is realized as a Rich Internet Application to maximize design performance and user experience.
The emergence of Web services adhering to the REST (Representational State Transfer) paradigm - referred as RESTful Web services - and the widespread adoption and dispersion by di erent providers1 strongly in uences traditional business process environments. The bene t of the exposed services for individual business needs evolved over time from general services like for example the Google Search to specialized services like access to Social Network portals - refer to the Facebook services2 as an example - or commercial services like Amazon's Web services. Beside the increasing number of services the ease of integration and the exibility to changes awakes the interest to integrate these services into existing business process management approaches. The architectural di erences between established Service Oriented Architectures and newly emerging lightweight resource oriented architectures complicate this endeavor.
Di erent approaches [
The work is organized as follows: Section 1.1 tries to clarify the de nition of Service Mashups by providing existing de nitions and relating akin appellations like Mashups and Business processes. Section 2 summarizes existing approaches and relates them to the approach introduced in this paper. Section 3 introduces collaborative service orchestration based on a generic role model derived from BPEL4People, a established speci cation in Web service environments. Section 4 motivates the need for collaborative Service Mashup design approaches on the basis of a well-known process scenario. The combination of orchestration information, service integration information and collaboration information resulted in the Service Mashup Abstraction described in Section 5. This abstraction is realized in a framework which is implemented as a Web-based prototype and deploys a Rich Internet Application. Finally Section 6 concludes the paper and gives an outlook of the Future Work. 3 http://www.opensocial.org, last accessed on April 2009 1.1
The increasing number and diversity of RESTful Web services exposed on the
internet blurs an adequate classi cation of orchestration paradigms. In the
domain of Web applications lightweight integration approaches - summarized as
RESTful Web services - dominate the service infrastructure. In the domain of
Enterprise Computing the "Big" Web service technology stack (SOAP, WSDL,
WS-* speci cations, WSBPEL, etc.) delivers interoperability for heterogeneous
service infrastructures. The architectural di erences of these two worlds result
in challenging combination e orts (outlined by Pautasso et al. [
Hoyer et al. [
Swashup DSL introduced by Maximilien et al. [
HOBBES [
Tran et al. [
With the increasing number of services exposed by di erent providers on the internet the combination of these services to Service Mashups gains popularity. The broadening of functionality enables the recombination of Services to advanced Service Mashups orchestrating services from di erent domains. This trend leads to increasing specialization of Mashups and requires know-how from di erent domains: For example HousingMaps.com4 combines data from craigslist.org5 with Google Maps6. This Mashup requires knowledge in the domain of real estate markets and web application development. The trend to interdisciplinary combination of Services is encouraged by the e ort to coequal integration of RESTful Web services and WS-* Web services as exempli ed in the sample process scenario in the next section. This evolution of process environments from closed company-intern systems to open Web service environments crossing organizational boundaries requires the collaboration of di erent experts on the design of Service Mashups. Existing platforms to administrate Mashups currently lack support for this endeavor. Even simple role models are not supported.
The importance of role models in collaborative environments was depicted by
Ellis et al. [
The role model covers the whole business process lifecycle from design time to runtime issues. To continue the combination of Service Oriented Architecture principles with REST based web application paradigms the approach presented 4 http://www.housingmaps.com/, last accessed on April 2009 5 http://www.craigslist.org, last accessed on April 2009 6 http://maps.google.com, last accessed on April 2009 7 WS-BPEL Extension for People, BPEL4People in this paper introduces a role model derived from the BPEL4People roles. In contrast to BPEL4People the role model introduced in this paper covers design time issues only as the integration of runtime issues is part of the future work described in section 6. The derived role model consists of the following roles: { Creator - the Creator is determined automatically by the infrastructure during design time and refers to the participant creating the initial Service Mashup design { Stakeholder - the Stakeholder may in uence the progress of the Mashup design by adding attachments, process notes or forwarding tasks but has no privileges to change the Mashup design { Administrator - the Administrator is allowed to perform administrative actions on the Mashup design. In addition to the privileges granted to Stakeholders Administrators are able to change the Service Mashup design Beside the role model the visibility and propagation of changes to the instance edited by di erent members is crucial in collaborative service orchestration. In contrast to real-time collaboration systems enabling the concurrent editing and session sharing between members the approach introduced in this work is realized regarding relaxed WYSIWIS (What-You-See-Is-What-I-See). A Service Mashup instance is locked exclusively by the member editing the instance. After propagating all changes to the server the instance is released and the involved members are able to check changes by loading the instance. This roundtrip approach adheres to the REST paradigms as Service Mashups are exposed as resources by the server. By updating the changes of the process model only, the introduced architecture minimizes server processing load. The disadvantages of late propagation of changes is compensated by full access to the Mashup design by the processing member. 4
The coequal integration of RESTful Web services and WS-* Web services into established business process environments neglects the di erent underlying architectures of these two concepts. The growing interest and the low integration hurdles of RESTful Web services result in the dispersion into non-technical domains. This trend ampli es the coequal integration of mostly publicly available RESTful Web services and existing company-internal WS-* Web services into daily business processes.
To exemplify the previously stated assumptions we introduce a sample process scenario illustrated in gure 1. The process executes a revisited example of a travel agency using existing Web 2.0 services: A user submits a holiday request through the Web frontend containing details of the start date, the end date and the destination. This order is submitted automatically to the agency-internal Order Processing Web service to track incoming orders. After the successful completion of this Web service operation the order is assigned to a responsible travel agent by the agency-internal HR Service. This service administrates all travel agents and automatically assigns the appropriate travel agent to the user request on the basis of the agent's expertise. The assigned travel agent prepares the user order. This is modeled in a separate process administrated by the travel agent. The travel agent searches for the best photos of the destination, plans onsite trips and searches for the cheapest hotels. After the travel agent arranged the on-site trip details and ordered them he assembles all details into the resulting trip. This step concludes the Process Order under his responsibility. He propagates the package containing the order details to the main process. The Order Manager responsible for the main process publishes the trip and responds to the user request.
The Web Application Expert is responsible for the appropriate execution of the process. He maps the service requirements de ned by the travel agent and the Order Manager to available Web services. As already mentioned the task Assemble Order is performed by the Order Service. The assignment of the order request to an adequate travel agent is done by the HR service. Both services are company-internal WS-* Web services hosted on the Travel Agency servers. To enable the search for the best photos of the destination the Web Application expert decides to integrate the Flickr Web service. To plan on-site trips and calculate the distances he decides to use the Google Maps Web service. The search for the cheapest hotels is enabled by the Hotels Combined Web service. All of these services expose their APIs as RESTful Web services.
Incoming User Request Assemble Order Assign Order Prepare Order Publish Trip
Outgoing User
Response Order Manager
WSDL Process Order Service Search Locations
Order Trips Assemble Trip
HR Service WSDL Flickr Service REST
Service Mashup
Google Maps + Flickr Travel Agent
Web Application Expert
As a special service for the customer all on-site trips packaged in the resulting trip are exposed to the travel agency web site. The user is able to retrace the arranged trips on-site by the combinatorial use of Google Maps and Flickr. This Service Mashup was created by the travel agency to present a reproducible booking process to the customer. Before the user starts his trip he may familiarize with local details of the desired destination.
The process outlined in gure 1 exempli es the coequal consumption of RESTful Web services and WS-* Web services. In the following section the abstraction is outlined to examine both Web service concepts coequally and motivate the use of role-based collaboration in the design of Service Mashups. 5
The scenario illustrated in the previous section outlines the blur of distinction of service integration into conventional process environments. Beside the coequal integration of RESTful Web services and WS-* based Web services the demand of human participant integration rises complexity of the process landscapes. In the SOA paradigm BPEL4People shape up as an accepted approach to introduce generic role models to structure human participant integration. As until now in the domain of Mashups no comparable approach is widely accepted this work proposes a role model derived from the BPEL4People model as introduced in section 3. Beside the two mentioned domains (Service Integration and Participant Integration) the integration of orchestration information into Service Mashups is of vital interest.
Orchestration view
CompositeActivity AtomicActivity
MessagingActivity core meta-model OrchestrationElement * * *
* CollaborationElement
IntegrationElement Participant
Role * * Collaboration view
Service
Resource 0..* 0..*
Integration view Fig. 2. The Service Mashup Meta-Model
In the WS-* based Web service environment WS-BPEL is the standard to
describe and design the orchestration of Web services. WS-BPEL is layered atop
of WSDL and decouples the orchestration logic from the service invocation logic
by the use of Partner Links. The consequent separation of invocation details
is re ected in the use of basic activities which refer to Partner Links and hide
the concrete invocation mechanisms from the process de nition. The Service
Mashup Abstraction continues this separation of invocation details and extends
the approach introduced by Tran et al. [
The Service Mashup Abstraction emerges from the model-based integration of di erent domains into one model. Figure 2 illustrates the underlying metamodel.
Role -name : String -type : String Participant +name : String +role : Role Participant Classes
Copy +from : Assignment +to : Assignment
Assignment +name : String +type : String +location : String +creator : Participant +accessor : Participant +creationTime : Date +accessTime : Date Core Classes
Activity +name : String +type : String +previous : Activity +next : Activity +participant : Participant +delay : Date
Receive Invoke +assignment : Assignment +input : Assignment
+output : Assignment
Service +name : String
Resource
WSDL +url : String +timestamp : Date +publish : Boolean +username : Participant +wsdl : WSDL
WADL +url : String +timestamp : Date +publish : Boolean +username : Participant +wadl : WADL
Message +message : String +sender : Activity +receiver : MessageHandler MessageHandler +name : String +type : String
CompositeActivity +isExecuting : Boolean Parallel
If -expression : String
ParallelBranch Core Composite Classes
Case -match : String
Default
Switch +expression : String
Scope -handler : MessageHandler
IfBranch -rule : String
ElseBranch
The core meta-model consists of three elements each representing the base element for the particular view. This language design relates the views and enables a exible combination of di erent views. Consider a combination of an Orchestration element like an Activity with a Collaboration Element like a Participant. As Orchestration Element is the parent of each Activity and is related to the Collaboration Element which represents the basis for Participant, each Activity might have one or more Participants. The Integration Element is not directly connected to the Collaboration Element as the Service Mashup Abstraction reects the decoupling principle of WS-BPEL to hide invocation details. The relation of Collaboration Elements with Service Invocations is achieved by linking elements of Orchestration Elements. A detailed class structure of the emerging Service Mashup Abstraction is illustrated in gure 3.
Order Manager
Listing 1.1. Web Application Expert Process
Applying Service Mashup Abstraction on the process scenario introduced in section 4 results in the models illustrated in gure 4. The Order Manager orchestrates two WS-* Web services and refers to the Travel Agent process. The Travel agent models the abstract actions Search Location, Order Trips and Assemble Trip. After modeling this sequence she adds the Web application expert as Business Administrator to the Service Mashup. The Web Application Expert has now full access to the Service Mashups and re nes the abstract activities by the according Service invocation elements. The resulting Service Mashup is depicted in listing 1.1. The process model is exposed by the prototype as a resource and might by accessed by HTTP GET operations. 5.1
The abstraction of Service descriptions comes with a risk to neglect the original Service integration paradigm. This might lead to a ippant orchestration of Web services. To prevent misleading orchestrations of Web services this work introduces pitfalls occurring in the coequal integration of RESTful Web services and WS-* Web services.
REST Service enforcement According to Fielding [
The trend to enforce a remote procedure call alike behavior by exposing RESTful Web services must be kept in mind during the design of Service Mashups consuming REST APIs. 8 f.e. ickr services http://www.flickr.com/services/api/, last accessed on April 2009 GET /photos/getNextList?
List of Photos a) Stateful GET /photos/?list=2
List of Photos b) Stateless
previousList++;
nextList = previousList;
return nextList;
Protocol neglect HTTP provides di erent methods for requests9. To minimize
integration hurdles existing RESTful Web services tend to reduce the HTTP
protocol method support to GET and POST requests only. This results in exposing
functions like sending a POST request to a RESTful Web service to delete an
existing resource. Pautasso et al. [
Concerning Service Mashup design Hi-REST architectures ease the integration of RESTful Web services by adhering stricter to the REST paradigm. The support for PUT and DELETE verbs indicate more clearly the operation on the resource and therefore the implications on the overall Service Mashup. RESTful Web services adhering to the Lo-REST architecture do not provide transparent access to the resources and therefore bear the risk to misleading orchestrations in Service Mashups.
These Service Integration pitfalls might be expanded to a collection of
Antipatterns [
This work introduces a model-driven integration approach towards: a) coequal integration of RESTful Web services and WS-* Web services, b) coequal Web service orchestration and c) collaborative Service design of Service Mashups. The approach derives concepts from established standards and provides an emerged Service Mashup Abstraction. The approach is exempli ed in a web-based prototype. The implementation enables the asynchronous design of Service Mashups by implementing a Rich Internet Application. The prototype is reachable under http://www.expressflow.com.
Section 3 introduces the role model derived from BPEL4People. This role model is currently limited to design time issues of collaborative Service Mashup design. The expansion of this role model to runtime issues is planned for future work. 9 For an exhaustive list of methods the interested reader may refer to RFC 2616
Section 5 introduces the Service Mashup Abstraction from the consequent model-driven abstraction of di erent Web service domains. Whereas the WSBPEL based business process abstraction seems to be straight forward the coequal integration of WS-* Web services and RESTful Web services comes with diverse risks. The pitfalls described in this work might be expanded to the de nition of Antipatterns as part of the future work.