Web services are self-descriptive software components which can automatically ... The underlying business component of a web service usually re- alizes some ..... specification obtained from an activity diagram, a business pro- cess instance ...
Towards Consistency of Web Service Architectures Reiko HECKEL and Hendrik VOIGT Department of Computer Science, University of Paderborn, 33098 Paderborn, Germany ¨ Jochen KUSTER Department of Computer Science, University of Paderborn / C-LAB 33102 Paderborn, Germany ¨ Sebastian THONE International Graduate School of Dynamic Intelligent Systems, University of Paderborn 33098 Paderborn, Germany ABSTRACT Web services are self-descriptive software components which can automatically be discovered and engaged, together with other web components, to complete tasks over the Internet. The integration of Web services entails consistency problems which can best be solved at the level of models. In this paper, we discuss an approach to model-based consistency management for component-based architectures and its application to Web service architectures. 1. INTRODUCTION Web services are used to expose dedicated software functionality to external clients. Conceptually, they represent interfaces of the underlying software systems which can be accessed over the Internet by other components which can, in turn, provide their own Web services. This way, web service architectures enable sophisticated electronic business-to-business collaborations. The underlying business component of a web service usually realizes some dedicated business process which has to be composed with the processes executed by its clients. This composition, which may be done at development time or at runtime, is called orchestration. In order to ensure the correct execution of the orchestrated Web services, the processes of all participating services have to be consistent. This means that, e.g., the protocol performed by a used Web service is respected by another Web service. Otherwise, the Web service may fail to deliver the expected service and the overall composed Web service may fail. By providing a UML model of the Web service architecture, the consistency services can be discussed at a high level of abstraction, independently of the specific XML languages used at the implementation level. However, so far there is little support for the software engineer to detect possible consistency problems at the level of models. In this paper we propose to apply a general methodology for specifying and analyzing consistency of object-oriented models [4] to UML models of Web service architectures. The methodology supports the identification of consistency problems in a
model-based development method and allows to define a consistency condition either at the syntactic level of the modeling language, or by means of a translation of models into a semantic domain which provides support for the automated analysis of models. For example, processes of web services may be modeled by UML activity diagrams which can be translated into CSP to be analyzed for deadlock freedom, protocol consistency, etc. Below, we start discussing the XML languages used for describing Web service architectures at the implementation level. Then, in Section 3 we present our approach to the modeling of these architectures based on the UML. Our approach to consistency management is presented in Section 4 and Section 5 concludes the paper. 2. WEB SERVICE ARCHITECTURES Web services are self-descriptive software components which can automatically be discovered and engaged, together with other web components, to complete tasks over the Internet. They enable seamless application integration over the network regardless of programming language or operating environment. Conceptually, Web services encapsulate existing business components under Web-accessible interfaces and enable remote calls to these applications by other components [1, 6]. These components can in turn provide own Web services to their interaction partners. This way, Web service architectures enable sophisticated business-to-business collaborations in the area of electronic business. The underlying business component of a Web service usually realizes some dedicated business process. The operations which the Web service provides to its partners and the operations which it requires from other Web services have to be orchestrated according to the underlying business process. The operations can therefore be called in a specific order only, and the interaction protocols of the collaborating Web services have to be compliant with each other. The specification of Web service architectures consists of two parts: a structural part for the description of the services and their interfaces (in order to make them addressable via the Internet) and a behavioral part for the interaction protocol of each service with its partners. The current notational standard for these parts
are XML-based, low-level specification languages which are introduced in the subsequent paragraphs. For the static part, the Web Service Description Language (WSDL [7]) is the current standard. A WSDL document describes the provided interfaces of a Web service (the required interfaces are not described). Each interface (also called Port) has got a Port Type. Each Port Type contains a set of operations with input and output messages. The types of these messages are defined as XML messages, since the communication with Web services is based on an exchange of such XML messages. If the input message is given only, an operation is called a one-way operation. But in most cases Web services support both input and output messages and realize request-response operations, which correspond particularly nice to the HTTP request-response model. There are several proposals of specification languages for the dynamic part of a Web service architecture (XLANG [2], WSFL [8], WSCI [5], BPEL4WS [3]). They all describe the control- and message-flow between Web Services participating in choreographed interactions with other services. In this paper, we want to exemplify our approach using the Business Process Execution Language for Web Services (BPEL4WS [3]). The BPEL4WS specification supports the following scenario: Assuming that an enterprise wants to automate one of its business processes with the help of own and third-party Web services, then it has to assign these Web services to the individual activities of the process. This can be done by defining an executable BPEL4WS process. The resulting process can then be encapsulated as a new, advanced Web service which is exposed to customers and trading partners. If somebody requested this advanced Web service after its deployment, a process engine could execute the BPEL4WS process specification, run a new instance of the process, and coordinate all the necessary interactions with the external Web services during the process activities.
• In which order is it done? In addition to the above mentioned actions related to the interaction with other services, each BPEL4WS process contains control-flow constructs, e.g., for sequential, conditional, and concurrent execution of the interaction activities. The following section deals with the question how such Web service architectures can be specified and modeled on higher, more abstract level using the visual modeling language UML. 3. UML MODELS In this section, we describe how UML diagrams can be used to model Web service architectures. We put special emphasis on the visual modeling of the behavioral part as given by BPEL4WS process interactions. As already discussed in [11], visual and more high-level modeling languages like UML have important advantages in comparison to low-level XML-based specification languages. Among others, they allow a better abstraction from implementation details and are therefore better understandable. In particular UML use case-, component-, class-, and activity diagrams are suitable for the modeling of Web service architectures in the context of business processes. In the following, we will demonstrate this by using the scenario of an electronic auction house as example. Use case diagrams are used to describe the business segment. As shown in Figure 1, the use case itself symbolizes the business process, in this case the auction service provided by the auction house. The participants involved in the use case represent the roles of the partners that interact with the provided business process. In the example, a buyer and a seller interact with the auction service.
A process-oriented Web service orchestration as given by a BPEL4WS document mainly contains three different types of elements. These can be summarized under the following questions: • Who is involved in the process? The partner elements declare which partner services the process wants to interact with and which Port Types it requires from these partners. Likewise, it is defined which Port Types are provided by the process to the partners. • What is done during the process? Each BPEL4WS process contains a set of activities defining the interactions with the partner services. There are three different kinds of activities: A receive action causes a pause of the process execution until a message from a certain partner is received at a certain port. A reply action is used to send an XML message to one of the partners as response to a previous receipt. An invoke action is used to call one of the operations of the external partners. An invoke action always requires an input message to be sent to the receiver. It will return an output message, if the invoked operation of the partner Port Type is defined as request-response operation in its WSDL definition.
Figure 1: Use Case Diagram Component diagrams are used to refine the dependencies described in the use case diagrams. In doing so, the component symbol is used for depicting a Web service. Both, the participants of the business process and the business process itself are modeled as Web services (see Figure 2). In order to establish possible points of interactions, Port Types are added to the diagram as interfaces (the circular symbols, PT is used as short form for Port Type). If a Web service has to provide a Port Type, the interface is connected to the component symbol. If a Web service requires a certain Port Type, then this is modeled as a dashed arrow to the corresponding interface (UML use-dependency). SellerPT
BuyerPT
Auction House
Seller SellerAnswerPT
Buyer BuyerAnswerPT
Figure 2: Component Diagram
For example in Figure 2, the Auction House service provides the two Port Types SellerPT and BuyerPT and requires the corresponding answer Port Types SellerAnswerPT and BuyerAnswerPT for a later response to any incoming request. Class diagrams are used to provide further details of the different Port Types by defining their operations and involved messages and parameters. In Figure 3, the four Port Types from the component diagram are refined this way. In this simplified example, each Port Type provides only one operation which is mainly used to submit the necessary data to the partner.
Figure 3: Class Diagram The interaction protocols and business processes for the Web services are modeled with activity diagrams. Besides control-flow elements (decision, fork, join, etc.), the activity diagrams contain the necessary activities for interacting with the partner services. The activities are stereotyped as receive, reply, or invoke depending on the underlying function as defined in Section 2. A triplet consisting of partner, Port Type and operation follows the stereotype. This triplet assigns one of the available Port Type operations to each activity.
Figure 4: Activity Diagram: Auction House
Figure 4 shows the process of the auction service. The first part is used to accept an offer provided by the Seller and a bid provided by the Buyer through the SellerPT and BuyerPT respectively. After the data has been received, the auction process has to decide whether the auction has succeeded or failed. In order to simplify the example, we omitted the details of this step. Because the processing time of the business process is lengthy, the auction service responds to the Seller and Buyer through appropriate answer Port Types SellerAnswerPT and BuyerAnswerPT. The interaction protocols of the partners are modeled with activity diagrams, too. This step is essential for further analysis, because inconsistencies between the several participants have to be discovered to achieve a correct execution of the service interactions. Therefore, the following two activity diagrams in Figure 5 represent the processes on the Seller and Buyer side respectively. A comparison of the activities of the Buyer and Seller with the activities of the Auction House shows that the processes logically fit together. For more complex interaction processes, the consistency of all involved partner processes cannot always be checked as easily as in the previous example. For this reason, the subsequent section discusses more advanced, formal methods which are required to maintain certain consistency properties.
Figure 5: Activity Diagram: Seller and Buyer
4. CONSISTENCY IN THE DEVELOPMENT PROCESS In this section, we first introduce basic concepts of consistency that are necessary for establishing consistency in a development process. Then we focus on the identification of consistency problems in the development process introduced above. Basic Concepts of Consistency When defining a UML-based development process for Web service architectures, consistency of the models must be ensured. For dealing with consistency in UML-based development processes, we have recently developed a general methodology for specifying and analyzing consistency [4]. In short, the methodology consists of the following steps: 1. consistency problems must be identified in a given UMLbased development process, documented and categorized. 2. for each semantic consistency problem, a suitable semantic domain must be chosen, a partial formalization must be designed by mapping UML models into the semantic domain and consistency conditions must be stated. 3. for each consistency problem, a consistency check must be defined. 4. consistency checks must be integrated into an existing development process. Consistency management in a UML-based development process is a difficult task. For defining a consistency concept, one approach is to define an integration of all submodel types into a formal semantic domain. As this is rather difficult for a semi-formal modeling language as the UML, our methodology favors the idea of constructing partial formalizations of several submodel types. Such a partial formalization, represented by a mapping into the formal semantic domain, together with a set of consistency conditions, can then be considered as a consistency concept. A consistency condition restricts the set of all valid models to those ones that conform to the consistency condition and can be considered informally as a selector for those models that are meaningful. Our idea of a consistency concept is illustrated in Figure 6.
consistency problem types. A syntactic consistency condition is formulated directly on the syntax (i. e. the metamodel) of the submodel types whereas a semantic consistency condition is expressed on submodel types after their mapping into a semantic domain. A further characterization of consistency problem types can be obtained when considering the underlying consistency property that gives rise to the need for a consistency concept. General consistency properties are syntactic correctness and existence of an implementation, specific application or development process specific properties include deadlock freedom. With respect to the property of syntactic correctness, we need to come up with a consistency concept in order to be able to study this property at the model level. If there is no consistency concept, we simply cannot decide whether or not the model induces a syntactically correct application or not. A similar argument can be constructed for other consistency properties. Identification of Consistency Problems Within consistency problem identification, it is the task of the software engineer to detect those submodel configurations that are not meaningful, and formally express this information by providing a textual notion of the consistency condition. In this task, the software engineer can be supported by a list of consistency properties to be supported. We will now start with the identification of consistency problem types in the sample process, taking into account the property of syntactic correctness. At first, we consider the submodel types component diagram and class diagram. We clearly identify a consistency problem type that occurs whenever a Port Type is used within a component diagram that is not declared in the class diagram. This consistency problem type can be considered syntactic because a syntactic consistency condition can be formulated using OCL, requiring that each Port Type used is declared in the class diagram. With regard to the submodel types of activity diagrams and class diagram, a similar consistency problem type can be detected, illustrated in Figure 7: An activity contains the partner, the Port Type and the corresponding operation. These three elements must fit to each other. Regarding the Class Diagram it is obvious, that the SellerPT does not support a provide operation, giving rise to another syntactic consistency problem.
Consistency Concept Submodel 1
m1
Semantic Domain
… mn Submodel n Consistency conditions c1
…
cm
Figure 6: The notion of consistency concept In our terms, a consistency problem type consists of a set of submodel types that give rise to the violation of a consistency condition. Depending on the abstraction layer submodel types belong to, we can distinguish between horizontal and vertical consistency problem types. Additionally, depending on the consistency condition, we can distinguish between syntactic and semantic
Figure 7: Activity Diagram: Syntactic consistency problem When modeling Web service architectures, we also have to take into account specific consistency properties: In a BPEL4WS
specification obtained from an activity diagram, a business process instance must not simultaneously enable two receive actions for the same partner, Port Type, and operation. If two receive actions for the same partner, Port Type, and operation are in fact simultaneously enabled during execution of a business process instance, then the standard fault bpws:conflictingReceive will be thrown by a compliant implementation. In such a case, the processing of the current scope is terminated. Possible subsequent scenarios are the impact of compensation mechanisms (if during the process defined) or also the abort of the entire process. In any case, the probability of a successful completion of the process sinks. In order to avoid such a conflict at model level, we can provide a consistency concept for activity diagrams that provides consistency conditions for not allowing such a submodel configuration. Another approach to this consistency problem type is providing a diagram pattern as illustrated in Figure 8.
verification of consistency conditions by a model checker and an interpretation of the results. Informally, the specification of such a consistency check can be visualized by an activity diagram extended by mechanisms for modeling object flow. In the following, we will sketch the definition of a consistency check for the consistency problem type of activity diagrams, ensuring their deadlock freedom. In Figure 10, the consistency check for activity diagrams is shown (with object flow visualized by dotted arrows). Within the first activity, a UML localization pattern is used for locating and identifying, within a larger UML model, those activity diagrams relevant for the consistency check. These are then given to the translation activities. Within the translation activities, the partial translation to CSP is performed. Resulting CSP files are then assembled to a single file which can be handed over directly to the model checker.
Matching of Localisation Pattern for Consistency Problem Activity Diagrams
Translation of Activity Diagrams to CSP
CSP Files
Preparation Of Input for Model Checker Adding Consistency Conditions
Figure 8: Conflict potentials in parallel sections
CSP File
Verification of Consistency Conditions and Interpretation of Results
Figure 10: A sample consistency check 5. CONCLUSIONS AND FUTURE WORK
Figure 9: A deadlock situation Concerning the property of deadlock freedom, we need to provide a consistency concept for activity diagrams. As an example, consider the modified activity diagram of the Seller and the one of the Auction House, illustrated in Figure 9. Both processes expect a signal from each other which gives rise to a deadlock. A consistency concept for the property of deadlock freedom will require to formalize activity diagrams in a suitable formal method, such as CSP [9], and to formalize the consistency condition of deadlock freedom. A translation of activity diagrams to CSP can be based on our existing work of translation of statecharts to CSP [10], possibly with several adaptations, and is currently being investigated. Defining Consistency Checks On the basis of a consistency concept, consistency checks can be defined in order to validate that a model is consistent. A consistency check must therefore validate the consistency conditions of a consistency concept. Within our approach, such a check may involve the translation of a model into a semantic domain, the
With the wide integration of Web services into software development, modeling of Web service architectures is gaining increasing importance. In order to be beneficial, a modeling approach should take into account the characteristics of Web service architectures. Currently, the Unified Modeling Language is the accepted industrial standard for modeling object-oriented systems. In this paper, we have discussed how the UML can be applied for modeling Web service architectures. After a brief discussion of the characteristics of Web service architectures, we have introduced several UML models for suitable abstractions of both structure and behavior of Web service architectures. We have then focused on consistency of these models. As consistency is not established by the language definition of UML, it must be ensured by the software engineer applying UML for modeling Web service architectures. Consistency ensures that code generated from models is syntactically correct and that the existence of an implementation is guaranteed already at the model level. By applying a general methodology for consistency management, we have identified several consistency problem types and sketched how consistency checks can be defined by activity diagrams. Future work includes the definition of a development process for Web service architectures and the elaboration of consistency
management within this development process. For that purpose, we must formally define the translation of UML models into a semantic domain such as CSP and automate this translation process. Currently, we are developing tool support for this task in a form of a consistency workbench. This consistency workbench is to allow the software engineer to define translations of UML models into a semantic domain and define consistency checks as workflows as visualized in Figure 10.
REFERENCES [1] B. Benatallah, M. Dumas, M.C. Fauvet, and F. Rabhi. Towards Patterns of Web Services Composition. Technical Report UNSW-CSE-0111, The University of New South Wales, Sydney, Australia, November 2001. [2] S. Thatte (Microsoft Corporation). XLANG, Web Services for Business Process Design, 2001. http://www.gotdotnet.com/team/xml_ wsspecs/xlang-c/. [3] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana. Business Process Execution Language for Web Services, Version 1.0, July 2002. http://www-106.ibm.com/developerworks/ webservices/library/ws-bpel/. [4] G. Engels, J. M. K¨uster, L. Groenewegen, and R. Heckel. A methodology for specifying and analyzing consistency of object-oriented behavioral models. In Volker Gruhn, editor, Proceedings of the 8th European Software Engineering Conference (ESEC), pages 186–195. ACM Press, 2001. [5] A. Arkin et.al. Web Service Choreography Interface (WSCI), Version 1.0, August 2002. http://www.w3.org/TR/wsci/. [6] B. Benatallah et.al. Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Services. In Proc. 18th International Conference on Data Engineering (ICDE’02), San Jose, California, 2002. IEEE Computer Society Press. [7] E. Christensen et.al. Web Service Description Language 1.1, 2001. http://www.w3.org/TR/wsdl. [8] F. Leymann (IBM Software Group). Web Service Flow Language 1.0, 2001. http://www-4.ibm.com/software/ solutions/webservices/pdf/WSFL.pdf. [9] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. [10] J. Stehr. Semantische Konsistenzpr¨ufung von UML-Verhaltensdiagrammen zur Modellierung von eingebetteten Systemen. Diploma thesis, University of Paderborn, 2003. [11] S.Th¨one, R.Depke, and G.Engels. Process-Oriented, Flexible Composition of Web Services with UML. In Proc. of ER-Workshop on Conceptual Modeling Approaches for e-Business (eCOMO 2002); Tampere, Finland. LNCS, 2002.
