Web services composition using UML-S: a case study Christophe Dumez, Jaafar Gaber and Maxime Wack SeT Laboratory, Belfort, France Emails: {christophe.dumez, gaber, maxime.wack}@utbm.fr
Abstract—As Web services composition arouses a growing interest, most research works address implementation and execution issues. As a consequence, many composition languages (BPEL, XLANG, WSFL, WSCI, to name a few of them) have been proposed in the past few years. However, a weakness of these languages is that they are difficult to use in early stages of development, such as specification. UML-S is an extension to UML 2.0 that was introduced to address this issue. UML-S allows for a Model Driven Engineering (MDE) of Web services and their interactions. In this paper, composite Web service development using UML-S will be described through a case study.
I. I NTRODUCTION Many companies are now using the Web as a platform to communicate with their partners. The Web and its technologies allows them to provide Web services to individuals as well as other businesses. The main challenges in the Web services paradigm are their discovery and their composition. In other words, one must be able to find a suitable Web service for a given task. This process is called the discovery [1], [2], [3]. The second challenge is the one that is addressed in this paper. It is known as Web services composition [4], [5], [6], [7]. In Web services composition, already defined services are used together to achieve a larger task, resulting in a new composite and valueadded Web service. To accomplish this purpose, a common approach is to allow the Web services to interact in a scenario through the use of messaging mechanisms. Although a lot of research works deal with Web services interactions, most of them address language, implementation or application issues, neglecting early stages of the development process, such as specification. To address this issue, an extension to UML 2.0 called ”UML-S: UML for Services” is introduced. UML-S allows for modeling Web services as well as their interactions. The Unified Modeling Language (UML) has been defined by the Object Management Group (OMG) [8] to express graphically system development models. UML provides a key foundation for OMG’s Model Driven Architecture (MDA) [9]. MDA supports Model-Driven Engineering [10] of complex software systems, and allows for producing code from humanelaborated specifications. UML-S enables the developers to build composite Web services by following the principles of the Model-Driven Architecture (MDA). As a consequence, it is possible to generate platform-specific code from high-level UML-S models.
This paper is structured as follows. Section II provides a survey of existing approaches to model Web services interactions. In section III, the stages of development of a composite Web service using UML-S framework are presented. The scenario studied in this paper is given in section IV. The scenario is then modeled using UML-S in section V. After that, the BPEL code generation from the given models is addressed in section VI. Finally, section VII draws the conclusions and presents future work. cdumez July 17, 2008 II. R ELATED W ORK The Business Process Management Initiative (BPMI) has developed the Business Process Modeling Notation (BPMN). This notation is particularly useful to visualize BPEL processes. BPMN [11] is now maintained by the OMG. Unfortunately, one could reproach to BPMN its lack of formalism, as explained by Wohed et at. in [12]. Although BPMN is an interesting solution, we preferred to extend UML 2.0 to achieve the same purpose. Indeed, UML was already used as a Process Modeling Language (PML) [13], [14], [15]. As a matter of fact, UML has some very interesting features as a PML: it is standard, graphical, popular and it contains several diagrams which allows to model different views of a system. UML was already considered to describe Web services composition. In [16], an approach using UML activity diagrams to do so was presented by Skogan et al. They provide a way to model the coordination and the sequencing of the interactions between Web services. They also explain how UML activity diagrams can be converted into BPEL [17] or in WorkSCo [18]. However, in this approach, methods input/output and data transformation are modeled in notes (i.e. comments) on the side of the workflow, which can get quite confusing when the composition flow gets complex. Chunming Gao et al. also present in [19] a non-graphical way to model Web services composition with some mobility and time constraint. To do so, they introduce Discrete Time Mobile Ambient calculus (DTMA), an extension to the formal model called Mobile ambients calculus [20]. Using DTMA, they focus on modeling BPEL operations. Due to their nongraphical nature, languages such as DTMA are less userfriendly than graphical like UML. Another approach to Web services composition modeling was proposed by De Castro et al. in [21]. In their work, they
make use of the behavior modeling method of MIDAS, a Model-Driven Architecture (MDA) framework [22]. MIDAS is a model-driven methodology for the development of Web Information Systems (WIS) based on the MDA [9], proposed by the OMG [8]. They introduced Web services composition through UML activity diagrams in their paper. However, the model is not detailed as much as necessary to allow code generation as BPEL. Some features could also be added such as data transformation and flow control mechanisms. Marcos et al. present in [23] how Web services can be represented in UML through a case study. They extend UML class diagrams by adding new stereotypes in order to model Web services described using WSDL. Their proposal is integrated in MIDAS [22] framework. In [24], Hamadi et al. put forwards Petri nets [25] based algebra for composing Web services. Petri nets are a well-known process modeling technique. The pros of using such Petri net based algebra is that it allows the verification of properties and the detection of inconsistencies. However, Web services need to be expressed using algebra constructs before being translated into a Petri net representation, adding consequently another necessary stage in the process. IBM [26] developed an Eclipse [27] plug-in for generating BPEL documents from UML models. This tool called ws-uml2bpel is part of the Emerging Technologies Toolkit (ETTK) [28]. Ws-uml2bpel takes in input UML class and activity diagrams in XMI, which is the industry standard file format for exchange of UML models. IBM proposes a UML 1.4 profile with a mapping to BPEL. The profile identifies the UML stereotypes used for representing concepts in BPEL. However, their profile only provides mapping rules for the few basic flow control patterns that are already supported by standard UML. Many of the patterns identified by Aalst [29] are unsupported. In [30], Wohed et al. proposed a pattern based analysis of BPEL4WS [31]. The main purpose of this paper was to evaluate the capabilities and limitations of BPEL4WS. They studied how the main flow control patterns could be expressed in BPEL. Unfortunately, they reported that some patterns such as Multiple merge, Discriminator and its generalization, the N-out-of-M Join are unsupported by BPEL and most of the implementation solutions provided require editing to be correct in latest WS-BPEL 2.0. UML-S was initially introduced by Dumez et al. in [32]. Dumez et al. also provided UML-S transformation rules from WSDL 2.0 to UML-S and from UML-S to WS-BPEL 2.0 in [33]. UML-S verification and validation using Petri nets was also studied by Nait-Sidi-Moh et al. in [34]. III. C OMPOSITE W EB SERVICE
DEVELOPMENT PROCESS
The stages involved in the development of a composite Web service using UML-S are presented in figure 1. The steps identified by a grey background in the figure correspond to actions expected from the developer. The remaining actions are automated thanks to UML-S and require no input from the developer.
Fig. 1.
Development process
As presented in the figure, the specifier should import first the Web services he wants to compose by providing their WSDL file’s URL. From these WSDLs, the UML-S framework is able to generate a class diagram presenting the interfaces of the Web services involved as well as the complex data types they use. After that, he should define the interface of the composite service he wishes to create by adding a ≪WebService≫ class to the diagram and by defining the methods provided by this service. If the composite Web service methods input or output use new complex data types, he should also add the necessary classes and link them to the WebService class using a one-way association (from the service to the data class). It is not rare that the composite Web service uses the same complex data types as Web services it uses. In this case, he should simply add a one-way association from the WebService class to the already existing data class. Once the UML-S class diagram is complete, the developer should create one UML-S activity diagram per method of the composite Web service in order to define their internal behavior. UML-S extends UML 2.0 activity diagrams to support 11 flow control patterns (most of them identified by Aalst in [29]) instead of the 5 basic ones. They also allow to model calls to other Web services as well as the data transformation which may be required between the invocations. Finally, the UML-S framework is able to generate lowlevel code such as BPEL from high-level UML-S models. Indeed, contribution was required in this part because Wohed et al. were not able to provide BPEL transformation rules for some of the flow-control patterns supported by UML-S (i.e. discriminator and N-out-of-M join). These development stages will be applied in the following sections, through a case study. IV. S CENARIO
DESCRIPTION
The chosen scenario, we have four available Web services are involved. The Hospital service provides a method called bookNearestHospital() which takes the location of the emergency in parameters, book a bed in the nearest hospital and returns the coordinates of the chosen hospital. Another service is called AmbulanceDispatch and it has a sendNearestAmbulance(emergLoc, hosp) method that takes in parameter the location of the emergency and the location of the destination hospital. It sends the nearest ambulance to the scene and
Fig. 2.
UML-S class diagram
returns the original coordinates of the ambulance. The last two services are identical services from different providers. They are called ItineraryA and ItineraryB and they both provide a computeItineraryETA() method. This method computes the best itinerary between two locations passed as parameters, calculates the estimated time of arrival to the destination (called ETA from now on) and returns it. Two similar services are used although only one is needed because of time constraints involved in emergency services and unreliability induced by Web services. It is supposed that the specifier wants to compose the previously stated Web services in order to create a composite service called Emergency. The emergency service should provide a sendAmbulance() method taking the location of the emergency situation as a parameter and returns the ambulance ETA. The Emergency service should call the Hospital first in order to book a bed in the nearest hospital. Then, it should contact the AmbulanceDispatch service in order to ask an ambulance to bring the victim to the hospital. After that, it should call the two Itinerary services in parallel to compute the ambulance ETA. The Emergency service requires only one response from those two Web services. Therefore, it will wait for one of them to finish, return the ETA to the user and ignore the other Web service’s response.
its methods and the complex types involved. In the WSDL file, the complex types used by the Web service are expressed using XML schema. First of all, the WSDL parser should
Fig. 3.
V. S CENARIO
Class diagram generation from WSDL 2.0
MODELING
Section V-A provides and explains the resulting UML-S class diagram. After that, the resulting activity diagram is studied in section V-B. A. UML-S class diagram Web Service Description Language (WSDL) [35] is an XML based language, recommended by W3C, that provides a model to describe Web services. The WSDL description of a Web services presents its methods, its messages and the complex types involved. As mentioned before, it is worth noting that UML-S class diagrams can directly be generated from the Web services’ WSDL, as presented in figure 3. Indeed, a UML-S class diagram can be considered as a user-friendly mean for representing the Web services’ WSDLs. Both the WSDL file of a Web service and its UML-S class diagram contain its name,
locate the service section. It indicates the name of the service that will be used to name the WebService class, as well as the name of the interface (it was called portType in WSDL 1.1). Once the interface’s name is known, the parser to find it in the WSDL file. The interface section allows to fill part of the Webservice class’ methods. Indeed, it mention the name of the methods provided by the Web service using operation tags. The parser is also able to retrieve from the operation parts the names of the methods’ input/output messages. Once the names of the input / outputs messages are known, the parser can find their definition in the types section of the WSDL. Indeed, since WSDL 2.0, messages are defined using XML schema in the types section, with the other complex types, instead of using separate message sections. Messages are defined using an element tag, from which, the parser is able to retrieve the names of the parameters (or output if it is an
Fig. 4.
UML-S activity diagram
output message) as well as their type (complex or not). At this stage, it is possible to generate the whole WebService class. The only missing things are the classes corresponding to the complex types handled by the Web service and the association links between the Web service and the said classes. In element tags, simple types are prefixed by a xsd namespace. The ones using a different namespace are complex types. They should be represented as classes in the UML-S diagram (without any stereotype) and an association should be added between the WebService class and the complex type class. Complex types are also defined in the types section of the WSDL, using XML schema. From the XML definition of the complex type, it is possible to fill the content of the UML-S class, that is to say its properties (names and types). At this point, the parser is thus able to generate the whole class diagram corresponding the imported Web service’s WSDL. Converting a WSDL document to a class diagram is straightforward given the similarity of both models. However, UML-S class diagram is a lot more user-friendly than WSDL and allows for a better understanding of the Web service. As explained in section III, the specifier now has to define the interface of the composite Web service he wishes to create by adding the right classes to the generated class diagram. The resulting UML-S class diagram is given in figure 2. The part that was not automatically generated and that was defined by the developer is identified by a gray background. B. UML-S Activity diagram Now that the class diagram was completed, the specifier needs to define the UML-S activity diagram for his new composite Web service’s method (i.e. sendAmbulance()). The framework is already able to generate part of the activity diagram, that is to say the initial and final pseudo states, the Input object with the location parameter as tagged value, the Output object with a default output variable name. The specifier is then advised to rename the output variable to something more explicit (e.g. ETA in this example). The resulting activity diagram is presented in figure 4. Note that the discriminator flow control pattern was used to
wait only for the fastest Itinerary service to complete before executing the subsequent tasks. The AmbulanceDispatch and the Hospital services are called sequentially. Finally, the Transformation state is used to assign variables and make basic data type transformations before calling the Itinerary services. This UML-S activity diagram defines the internal behavior of the new sendAmbulance() method, which composes 4 external Web services, that is to say Hospital, AmbulanceDispatch, ItineraryA and itineraryB. In next section, we will see that the framework allows the specifier to generate code such as BPEL from the UML-S model. No further programming is required because the composite Web service simply makes use of already programmed Web services and allows them interact. VI. BPEL CODE GENERATION In this section, the BPEL code generation from the previous UML-S diagrams is studied. One shall see that the provided models provide all data required to allow such code generation and how to proceed. From the class diagram (CD from now on) in figure 2 and the activity diagram in figure 4 (AD from now on), the UMLS framework is able to generate the BPEL code provided in listing 1. First of all, the framework has to fill in the partnerLinks section. From the AD, the framework knows which Web services are involved in the composition. Therefore, it can import the Web services WSDLs and write the partnerLinks part of the BPEL process. After that, the framework has to write the variables section. Variables definitions can be written directly from the AD. Indeed, the variables names are provided in the diagram. For Web services invocations where the method takes more than one parameter, a variable has to be defined with the message type required by the method and containing the parameters. As a convention, we name this kind of variable by appending ”In” to the method name (e.g. calculateItineraryIn). Note that we need to use BPEL assign activities whenever we want to translate an UML-S AD transformation note (i.e.
one assign activity per line in the transformation note). We also need to use assign activities before Web services invocations (using BPEL invoke activity) whenever the method takes more than one parameter in input. Indeed, a variable was declared by the framework to refer to this input message (containing the parameters) and we have to provide the matching between the message properties (parameters) and previously declared variables. To translate flow control patterns supported by UML-S into WS-BPEL 2.0, one can refer to the transformation rules provided by Dumez et al. in [33]. The translation of basic patterns is straightforward, but more complex ones are not directly supported by BPEL and require the use of workarounds (e.g. the discriminator).
. . . < / pa r tne r L i nks > . . . < / v a r i a b l e s > $ s e n d A mb u l a n c e In / emergLoc $ s e n d A mb u l a n c e In / hosp c o m p u t e I t i n e r a r y E T A I n / s t a r t c o m p u t e I t i n e r a r y E T A I n / end c a l c u l a t e I t i n e r a r y I n / s t a r t X c a l c u l a t e I t i n e r a r y I n / s t a r t Y c a l c u l a t e I t i n e r a r y I n / endX c a l c u l a t e I t i n e r a r y I n / endY
Listing 1.
Generated BPEL code
The content of variables tag is was stripped from the code to make it more readable and also because its generation is straightforward. Variables names are provided by the developer in the UML-S AD and their type is defined in the CD. When calling an external Web service method taking several parameters in input, a variable is defined for the input message (containing the parameters). As explained previously, the framework names the variable by appending ”In” to the method name (provided in the AD). The content of partnerLinks was also stripped from the code. Partner links correspond to references to external Web services that the composite service is interacting with. Partner links are named by the framework by appending ”PL” to the Web service name (e.g. HospitalPL). The framework has the import first the Web services WSDLs using BPEL import activity, after downloading them from their URL provided in the AD. Import activity takes 3 parameters: the namespace, the location of the WSDL and its importType (i.e. http://schemas.xmlsoap.org/wsdl/ in this case). As one can see, UML-S class and activity diagrams contain all required information to allow code generation such as BPEL orchestration language. VII. C ONCLUSION Composite Web services building lacks sufficient support for traditional workflow modeling. Thus, some needs were identified and UML-S extended UML 2.0 class and activity diagrams to meet these needs. In this paper, we described the model-driven engineering of a composite Web service using UML-S though a realistic case study. The studied scenario involves business processes and Business-to-Business (B2B) relationships, which is a challenging research topic. Future work will involve Max-plus algebra based analysis and evaluation as well as dynamic composition. Development issues will also be addressed and a fully functional UML-S framework is currently under development. ACKNOWLEDGMENT This work is supported by the EU project ASSET (Advanced Safety and Driver Support for Essential Road Transport, 2008-2011).
R EFERENCES [1] S. Ran, “A model for web services discovery with qos,” SIGecom Exch., vol. 4, no. 1, pp. 1–10, 2003. [2] C. Schmidt and M. Parashar, “A peer-to-peer approach to web service discovery,” World Wide Web, vol. 7, no. 2, p. 211, 2004. [3] B. Benatallah, M.-S. Hacid, A. Leger, C. Rey, and F. Toumani, “On automating web services discovery,” The VLDB Journal, vol. 14, no. 1, p. 84, 2005. [4] M. Bakhouya and J. Gaber, “Service composition approaches for ubiquitous and pervasive computing environments: A survey,” Agent Systems in Electronic Business, Ed. Eldon Li and Soe-Tsyr Yuan, IGI Global, no. 978-1-59904-588-7, pp. 323–350, 2007. [5] D. Fensel and C. Bussler, “The web service modeling framework wsmf,” Electronic Commerce Research and Applications, vol. 1, no. 2, p. 113, 2002. [6] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau, “Automating daml-s web services composition using shop2,” The SemanticWeb - ISWC 2003, vol. 2870/2003, pp. 195–210, 2003. [7] S. B. Mokhtar, N. Georgantas, and V. Issarny, “Cocoa : Conversationbased service composition for pervasive computing environments,” in Pervasive Services, 2006 ACS/IEEE International Conference on, 2006, pp. 29–38. [8] “Object management group (omg),” http://www.omg.org. [9] R. Soley, “Model driven architecture, white paper,” http://www.omg.com/mda, 2001. [10] D. C. Schmidt, “Guest editor’s introduction: Model-driven engineering,” Computer, vol. 39, no. 2, pp. 25–31, 2006. [11] S. A. White, “Business process modeling notation (bpmn), v1.1,” http://www.omg.org/spec/BPMN/1.1, 2008. [12] P. Wohed, W. van der Aalst, M. Dumas, A. ter Hofstede, and N. Russell, “On the suitability of bpmn for business process modelling,” Process Models and Languages, Springer, vol. 4102/2006, pp. 161–176, 2006. [13] H. Eriksson and M. Penker, “Business modeling with uml,” Wiley Computing Publishing, 2000. [14] D. jager, A. Schleicher, and B. Westfechtel, “Using uml for software process modeling,” in LNCS 1687. Springer, 1999. [15] E. D. Nitto, L. Lavazza, M. Schiavoni, E. Tracanella, and M. Trombetta, “Deriving executable process descriptions from uml,” Proceedings of the 24th International Conference on Software Engineering, pp. 155–165, 2002. [16] D. Skogan, R. Groenmo, and I. Solheim, “Web service composition in uml,” in Proceedings. Eighth IEEE International Enterprise Distributed Object Computing Conference, 2004. EDOC 2004., 2004, pp. 47–57. [17] “Business process execution language (bpel), oasis,,” http://docs.oasisopen.org/wsbpel/2.0/wsbpel-v2.0.html. [18] “Workflow with separation of concerns (worksco),” http://worksco.sf.net. [19] C. Gao, Y. Li, and H. Chen, “Services composition modeling with mobility and time,” services, vol. 00, pp. 316–323, 2007. [20] L. Cadelli and A. Gordon, “Mobile ambients,” FOSSACS’98, LNCS, vol. 1378, pp. 140–155, 1998. [21] V. D. Castro, E. Marcos, and M. L. Sanz, “A model driven method for service composition modelling: a case study,” International Journal of Web Engineering and Technology, vol. 2, no. 4, pp. 335–353, 2006. [22] E. Marcos, P. C´aceres, B. Vela, and J. M. Cavero, “Midas/bd: A methodological framework for web database design,” Conceptual Modeling for New Information Systems Technologies, vol. 2465, p. 227, 2006. [23] E. Marcos, V. de Castro, and B. Vela, “Representing web services with uml: A case study,” Lecture Notes in Computer Science, vol. 2910/2003, pp. 17–27, 2003. [24] R. Hamadi and B. Benatallah, “A petri net-based model for web service composition,” in ADC ’03: Proceedings of the 14th Australasian database conference, 2003, pp. 191–200. [25] J. Peterson, Petri Net Theory and the Modeling of Systems. Prentice Hall, Englewood Cliffs, 1981. [26] “Ibm (international business machines corporation),” http://www.ibm.com. [27] “Eclipse integrated development environment,” http://www.eclipse.org. [28] “Emerging technologies toolkit (ettk),” http://www.alphaworks.ibm.com/tech/ettk. [29] W. van der Aalst, “Don’t go with the flow: Web services composition standards exposed,” IEEE Intelligent Systems, vol. 18, pp. 72–76, 2003.
[30] P. Wohed, W. M. P. v. d. Aalst, M. Dumas, and A. H. M. t. Hofstede, “Pattern based analysis of bpel4ws,” QUT Technical report, FIT-TR-2002-04, Queensland University of Technology, Brisbane, 2002. [Online]. Available: citeseer.ist.psu.edu/556822.html [31] F. Curbera, Y. Goland, J. Klein, F. Leymann, and D. Rolle, “Business process execution language for web services (bpel4ws) 1.1,” http://www106.ibm.com/developerworks/webservices/library/ws-bpel, 2003. [32] C. Dumez, A. Nait-Sidi-Moh, J. Gaber, and M. Wack, “Modeling and specification of web services composition using uml-s,” Submitted to the 4th International Conference on Next Generation Web Services (NWeSP’08), 2008. [33] ——, “Model-driven engineering of composite web services using umls,” Submitted to the 10th International Conference on Information Integration and Web-based Applications & Services (iiWAS 2008), July 2008. [34] A. Nait-Sidi-Moh, C. Dumez, J. Gaber, and M. Wack, “Petri net based verification and validation of uml-s models,” Submitted to Web Intelligence (WI’08), july 2008. [35] R. Chinnici and S. Weerawarana, “Web services description language (wsdl) version 2.0,” http://www.w3.org/TR/wsdl20, 2004.
