ORCHESTRATION OF SERVICE CHAINS GROUP REPORT ASSIGNMENT 3 IN MODULE 8 GFM-3

Submitted By: Federico Jacoba Jr. Jordi Castells

I. Introduction With today's current technology, Spatial Data Infrastructures (SDIs) provide an easy means by which Geographic Information (GI) can be distributed, accessed, and utilized. This is mainly due to the manner in which distributed systems can interoperate through the implementation of standards and protocols established by consortiums like the OGC, ISO, and W3C. A wealth of GI resources are made available over the web via various interoperable geo-webservices (e.g. WMS, WFS, WCS, WPS, etc.) that are built and designed using the Service Oriented Architecture (SOA). A particular user has numerous options to choose from these available services depending on his/her purpose. II. Composite Services Even with the myriad of resources and services offered by the web, a user will find it almost impossible to find one web service (WS) that will suit all of his/her needs. He/she may need WS-1 for one purpose to extract something, then use WS2 to process the results from WS-1, and thereafter invoke WS-3 to further process the output of WS2, and so forth. In short, the user needs a chain of services to perform his/her task. Various web services are typically independent, and therefore must be chained/linked together to maximize the benefits of many different services. As can be gleaned from the above example, it is obvious that no single service can possibly deliver everything and fully satisfy the users expectations. Chaining is the process of building application from various individual distributed services whose sequence is determined in a coordinated manner. A service chain is defined as a sequence of services where, for each adjacent pair of services, occurrence of the first action is necessary for the occurrence of the second action [Percival, 2002]. Capitalizing on the advantages of distributed applications architecture of SDIs, a limitless combination of numerous services (e.g. WMS, WFS, WPS, WCS, etc.) can be utilized by a user. More importantly, if these chained services would satisfy the requirements of another user, it can be re-used and thus eliminate the need for the other user to start from scratch. III. Orchestration vs. Choreography There are two ways of combining or chaining services together: orchestration or choreography [Juric, 2012]. The fundamental difference between the two approaches is that in orchestration, a central entity (the conductor of the orchestra) which is a service by itself, controls the participating services [Figure 1; Juric, 2012]. The different web services involved are unaware (and does not need to be aware) that they are part of the orchestra. Only the conductor or coordinator knows that the members (i.e., the
1

participating services) that they are playing a part in a business process definition. Thus in this setup, the orchestration is centralized through explicit definitions of operations and the invocation order of the services [Juric, 2012.]

Figure 1. Composition of Web Services by Orchestration [Adapted from Albreshne, 2009]

In contrast, choreography does not require a central orchestrator, with the participating services aware of which service/s to interoperate with, and when to perform their respective tasks [Figure 2; Peltz, 2003]. Furthermore, choreography is rooted on collaboration and mainly used to exchange messages in public business processes [Albreshne, 2009]. All the participating web services that are involved in the choreography must be aware of the business process, operations to execute, messages to exchange, as well as the timing of messages [Juric, 2012].

Figure 2. Composition of Web Services by Choreography [Adapted from Peltz, 2003]

Orchestration provides greater efficiency and flexibility in terms of composition of web services and has the following advantages over choreography [Juric, 2012]: The coordination of component processes is centrally managed by a specific coordinator. Web services can be incorporated without being aware of the fact that they are taking part in a larger business process. Alternative scenarios can be put in place in case faults occur.

IV. Standards used in Orchestration From the previous discussion, it is clear that chains of services are involved in a process; i.e., an ordered activities that has a start and an end. To control the workflows of processes, various standards are proposed by different organizations and consortiums. A couple of these are discussed in this section. BPEL or BPEL4WS Business Process Execution Language (For Web Services) is an OASIS1 standard. It is based on an XML grammar that defines how an orchestration engine has to process different web services. The language provides multiple facilities to orchestrate web services, processing the resulting data. The following list shows the general functionalities offered by BPEL4WS and the corresponding XML tags: Variable definition and modification (<variables>, <assign>) Local variables within scopes (<scope>)
1

Organization for the Advancement of Structured Information Standards. Is a consortium for ebusiness standards.

Structured programming (<if>, <then>, <else>, <while> and <switch>) Batch processing (<sequence> tag) Parallel processing (<flow> tag) Fault handlers (<FaultHandlers>) Calling Web Services (<invoke>)

Different orchestration engines are already implemented to understand the BPEL4WS language, provide the needed execution environment: ActiveVOS, BizTalk Server, iBolt and WebSphere are proprietary solutions, while Apache ODE, OpenESB, OW2 Orchestra and Petals BPEL engine provide the open source environment. WSCI The Web Service Choreography Interface (WSCI) is the XML-based interface description language described by W3C to control the flow of messages of choreographed web services.

VI. Use Case A simple example is given (showcased in Figure 3), of a basic batch web services execution controlled by an orchestration engine. The task is to obtain a list of restaurants along a street and generate a route leading to one of the restaurants, given a position and a street name.

Figure 3. An example of of Web Service Composition by Orchestration

It is assumed that the three Web Services listed below already exist: WS1: Geocoding web service (address latitude,longitude) WS2: Points of Interest given a radius distance (p1,radius List of POI) WS3: Routing webservice (p1,p2 Vector) In the above example, the orchestration engine has to execute the web services sequentially because the result of one web service is the input of the next. The BPEL4WS code configuration for this example is represented on Figure 4. Note that some parts of the code contain a [CODE] tag in a comment. This tag is added so that the reader would know that in between these comments, more code is needed for it to work correctly. For the sake of simplicity, this code is omitted and only the basic code to illustrate the example is written. The same holds true with the parameters of the tag. Ellipses are written in red to represent the missing parameters.

1. <process name="RestaurantsRoute" (...)> <partnerLinks> 2. <!-- [CODE] The declaration of partner links --> 3. </partnerLinks> 4. 5. <variables> 6. <!-- [CODE] Variables used in the process --> 7. </variables> 8. <!-- [CODE] Execute in sequence --> 9. <sequence> 10. <receive partnerLink="client" 11. (...) 12. operation="RestaurantsListAndRoute" 13. variable="inputparamaters" 14. createInstance="yes" /> 15. <!-- Assign the variables properly for a call--> 16. <assign> 17. <copy> 18. <from variable="inputparamaters" part="lat"/> 19. <to variable="ws1INPUT" part="lat"/> 20. </copy> 21. <copy> 22. <from variable="inputparamaters" part="lon"/> 23. <to variable="ws1INPUT" part="lon"/> 24. </copy> 25. </assign> 26. <!-- Synchronously invoke the WS1 --> 27. <invoke partnerLink="WS1-geocoding" 28. (...) 29. operation="GeocodeAddress" 30. inputVariable="ws1INPUT" 31. outputVariable="latlon" /> 32. <!-- [CODE] Assign variables properly --> 33. <!-- Synchronously invoke the WS2 --> 34. <invoke partnerLink="WS2-POI List" 35. (...) 36. operation="GetRestaurants" 37. inputVariable="ws2INPUT" 38. outputVariable="poilist" /> 39. <!-- [CODE] Assign variables properly --> 40. <!-- Synchronously invoke the WS3 --> 41. <invoke partnerLink="WS3-Routing" 42. (...) 43. operation="RouteTwoPoints" 44. inputVariable="ws3Input" 45. outputVariable="route" /> 46. <!-- [CODE] assign all the results to responsedata--> 47. <reply partner=client (...) operation=response container=responsedata/> 48. </sequence> 49. 50. </process>

Figure 4.Code Example for Figure 3 Orchestration process

VI. Summary Given the variety of webservices published over the web, a user can certainly find a service that will aptly suit his/her needs. The proliferation of numerous services has been facilitated by the Service Oriented Architecture. But for more complex tasks, a user will require composite or chained services. Putting various web services to work together can be done in two ways: orchestration or choreography. The main difference between the two is that the former have a central controller while the latter does not. Orchestration is the more preferred way as it has several advantages over choreography. These include: coordination of components is centrally managed; participating services are oblivious to the fact that they are taking part; and ease of identifying fault/s since the execution is controlled. Chains of services are involved in a process; an ordered set of activities that has a start and an end. Various standards (e.g. BPEL, WSCI) proposed by different organizations (W3C, OGC, OASIS), are currently utilized to control the workflows. As exemplified from the simple use case presented, a task like finding a route to restaurants using someones present position (street name and coordinates) can be orchestrated. This could be further applied and extended to more complex tasks and processes. VII. References Albreshne, A., Fuhrer, P., & Paquier, J. (2009). Web services orchestration and composition: Case study of web services composition A working paper. http:// diuf.unifr.ch/drupal/softeng/sites/diuf.unifr.ch.drupal.softeng/files/file/publications/ internal/WP09-03.pdf. Accessed March 25, 2012. Business Process Execution Language for Web Services 1.1 http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf/ Accessed March 26, 2012. Daniel, F. & Pernici, B. (2006). Insights into Web Service Orchestration and Choreography. International Journal of E-Business Research, 2(1), 58-77. (Note: not directly referenced in the text but ideas in the article helped the authors in the understanding of concepts of orchestration & choreography) Juric, M. A hands-on introduction to BPEL. htttp://www.oracle.com/technetwork/ articles/matjaz-bpel1-090575.html. Accessed March 25, 2012. Percival, G. (2002). ISO 19119 and OGC service architecture, FIG XXII International Congress Washington, D.C. USA (April 19-26 2002) Peltz, C. (2003). Web services orchestration - A review of emerging technologies, tools, and standards. Hewlett Packard, Co. W3C. Web service choreography interface (WSCI) 1.0. W3C Note 8 August 2002. http://www.w3.org/TR/wsci/. Accessed March 25, 2012.