Simulation
WST: a tool supporting timed composite Web Services Model transformation
Simulation: Transactions of the Society for Modeling and Simulation International 88(3) 349–364 Ó The Author(s) 2012 Reprints and permissions: sagepub.co.uk/journalsPermissions.nav DOI: 10.1177/0037549710372098 sim.sagepub.com
M Emilia Cambronero1, Gregorio Dı´az1, Enrique Martı´nez2, Valentı´n Valero3 and Llanos Tobarra4
Abstract In this paper we introduce a tool called the Web Service Translation tool (WST), which we are developing to implement a methodology for the design, validation and verification of Web Services with timed restrictions. This methodology works by making several translations, from phase to phase in the software development life cycle, where the system is represented at each phase by XML models. We use XSL Transformations (XSLT), which is a language for transforming XML documents. The purpose of these translations is to generate XML code automatically for a Web Service system and to obtain Web Services description models with Timed Automata for validating and verifying composite Web Services with time restrictions.
Keywords Web Services, Web Service composition, verification, choreography, modeling, real-time systems
‘Web Services mean many things to many people. In the end, there will be a set of standards which allow us to do things we could not do before, but in the meantime different people and companies approach them from different positions, and with different expectations.’ (Tim Berners-Lee)
1. Motivation In recent years, research in the field of Web applications has gathered pace. In this area we can find different languages, methods, tools and design patterns for Web modeling. Several languages for designing and implementing business processes have appeared, such as the Web Services Business Process Execution Language (WS-BPEL),1 which allows existing Web Services to be orchestrated into composite services, or the Web Services-Choreography Description Language (WS-CDL),2 which goes a step further and describes the relationships between these composite services in a peer-to-peer environment. Our tool focuses on the choreography layer, which describes, from a global viewpoint, the common and complementary observable behavior of all of the parties involved.
The motivation for developing this tool stems from the following problems: . The development of composite Web Services is still an emerging technique, so there is a need for effective and efficient means to abstract, compose, analyze, and evolve Web Services within an appropriate time frame.3 . The analysis of Web Services Coordination and, specifically, the timed restrictions that must be enforced in Web Services for which timed aspects are crucial
1 Associate Professor at the University of Castilla-La Mancha, Department of Computer Science, Albacete, Spain. 2 PhD Student at the University of Castilla-La Mancha, Department of Computer Science, Albacete, Spain. 3 Full Professor at the University of Castilla-La Mancha, Department of Computer Science, Albacete, Spain. 4 Postdoc Researcher at the University of Castilla-La Mancha, Department of Computer Science, Albacete, Spain.
Corresponding author: M Emilia Cambronero, Associate Professor at the University of Castilla-La Mancha, Department of Computer Science, Albacete, Spain Email:
[email protected]
350
Simulation: Transactions of the Society for Modeling and Simulation International 88(3)
for a correct functionality. This point can be covered by using the so-called choreographies, which describe the composition of several existing Web Services in order to provide a Composite Web Service. However, there is as yet no clear solution to this problem, and, in general, the existing techniques do not take into account the timed aspects of composite Web Services. . The use of formal techniques bring rigor and consistency to system specification and implementation. Web Services systems can also be described, analyzed and implemented by using formal techniques. They allow us to have unambiguous Web Services descriptions, which can later be checked to detect errors or can be used to prove that some properties of interest hold. The main goal of this work, therefore, is to present a tool based on a model-driven methodology, which allows us to deal with these problems. The WST tool covers different methodological phases for the design and verification of Composite Web Services, following the software life cycle: design and verification of choreographies with timed restrictions, and their validation. In the design phase we use the Unified Modelling Language (UML 2.0),4 in order to model the system conforming to the initial analysis requirements in a proper way. Thus, WST supports the modeling phase by means of a UML sequence diagram editor. Web Services choreographies are first described as UML 2.0 sequence diagrams, after which, we can automatically translate these UML 2.0 sequence diagrams into WS-CDL documents. The part of WS-CDL that we cover includes the activity constructions, variables, error handling, and time-out interactions, so it is rich enough to describe the main aspects of timed composite Web Services. Then, in a second step these WS-CDL documents are translated into a network of Timed Automata,5 which allows us to validate and ensure the correctness of systems with time constraints. They are supported by some well-known tools, such as KRONOS6 and UPPAAL.7 In particular, WST invokes the simulator and the verifier of UPPAAL in order to accomplish this phase. This paper is structured as follows. A discussion of related work is shown in Section 2, and a background on the techniques that we use is given in Section 3. In Section 4 the WST tool is presented. Section 5 explains the application of the WST tool. Finally, conclusions and future work are presented in Section 6.
2. Related work In the market we can find different Web Services tools. For instance, Foster et al.8 show the design
and implementation of a tool, called WS-Engineer, for a model-based approach to verifying compositions of Web Services implementations. This tool supports verification of properties created from design specifications and implementation models to confirm expected results from the viewpoints of both the designer and implementer. Risco-Martı` n and Mittal9 presented a mapping of UML 2.0 state machine diagrams into a formalism called the Discrete Event System Specification (DEVS) for simulation and testing purposes. They have developed the XFD-DEVS tool, which provides a template-based state requirement definition process. The DEVS formalism supports different features, such as the support of hierarchical models and, furthermore, the capability to define time structures. This tool can be used together with the methodology DEVS/SOA in order to deal with service-oriented architectures (SOAs). One of its main advantages is the possibility of generating executable code in different programming languages, which allows us to execute some UML models. Another related work10 proposes a tool-equipped methodology for the formal modeling and analysis of Web Services written in WS-BPEL. This methodology includes the definition of a formal semantics of WS-BPEL taking into account discrete-timing aspects, the automated translation of WS-BPEL specifications into DTLTSSs (discrete-time labeled transition systems) by means of the WSMOD tool, and the analysis of the resulting models by using the CADP toolbox. This toolbox allows us to verify some discrete-time properties once the model has been obtained, such as safety and liveness properties. Xiang Fu et al.11 present a tool, called WSAT, for analyzing and verifying composite Web Services specifications by using model checking techniques. In this case the specifications are written in WS-BPEL, and are translated to Guarded Finite State Automata (GFSA). Promela12 and the model checker SPIN13 are then used to analyze and verify the system. Another tool for the analysis of Web Services systems is EA4B,14 which defines an execution log for WS-BPEL. The execution log can then be read for post-execution debugging or for near real-time monitoring. This tool can be integrated with static analysis tools such as WSAT, so error traces generated by WSAT can be translated into log files and displayed visually. There is another tool, called WS-VERIFY,15 intended for the analysis of WS-BPEL specifications by using the NuSMV model checker.16 The specifications written in WS-BPEL are translated into a formalism called WSTTS (Web Services Timed State Transition Systems), which are similar to Timed Automata.
Execution analysis No WS-BPEL Implement and debug
No
Declare processes Simulation (LTL) No No Service flows No DTLTSSs WS-BPEL Real-time system
Simulation GFSA WS-BPEL Static analysis of services
Simulation STS WS-BPEL Real-time system
UML state charts Simulation Timed automata No Component-based distributed systems No No No
No No No No No No
Simulation FSP WS-CDL Service composition and implementation models
UML (MSCs)
Supported by the method. UML 2.0 state machine Simulation No Code generation Code migration and distributed simulation No
Validation Verification Implement Domain
Design
Supported by the method. UML 2.0 sequence Simulation Timed automata WS-CDL Real-time systems Analysis
Declare Baresi’s tool WSAT WS-Verify WSMod XFD-DEVS WS-Engineer WST
Table 1. Comparison of tools
Dong et al.17 proposed a translation from a programming model called Orc18 (supporting orchestrating Web Services) into UPPAAL Timed Automata, in order to check the models. These Orc models include concurrent communications, timeouts, etc. An experimental program for this translation is also provided to automate this approach. Another work presenting a translation from WS-BPEL to Timed Automata is that of Nakajima,19 and these Timed Automata are also translated to Promela code, thus allowing the use of the SPIN model checker. However, these works focus on orchestrations, whereas our tool takes a choreographic viewpoint. van der Aalst and Pesic20 presented a declarative service flow language (DecSerFlow), which is used for monitoring purposes. In that work process mining techniques are used to check the conformance of service flows by comparing the specification written in DecSerFlow with reality. A tool supporting this language (Declare) was presented by Pesic et al.21 There are also architecture-based approaches: Baresi et al.22 tackled the modeling and validation of component-based distributed systems at the architectural level. In that paper the publish/subscribe component model is considered, the modeling phase being made by means of UML statecharts, whereas validation is accomplished by model checking techniques (SPIN). Our work focuses on the choreography layer of Web Services systems. In this context, we can find the Pi4soa tools suite,23 which includes a choreography description editor and a choreography simulator. In contrast to Pi4soa, our tool, WST, implements a model-driven approach to the generation and verification of Web Services with time restrictions. In WST we move at the choreography level, the tool permitting us to contribute to different methodological phases of the software life cycle: analysis, design, implementation, validation and verification of Web Services. Our tool is recommended for an understanding of Web Service system behavior and to verify that it satisfies the initial requirements, above all in those WS systems with time restrictions. Table 1 shows a comparison between the main tools related with this work, taking into account their support for the different phases of the life-cycle and their application domain. The analysis phase is not covered by any of these. However, XFD-DEVS is included in a methodology where, for instance, use case diagrams can be used in the analysis phase. Our WST tool also follows a methodology that starts by using the KAOS goal model technique in order to gather the system requirements. Furthermore, only WS-Engineer and WST tackle the design, implementation, validation and verification
351
EA4B
Cambronero et al.
352
Simulation: Transactions of the Society for Modeling and Simulation International 88(3)
phases, and both use WS-CDL as a language for the description of Composite Web Services. In WST, however, we are able to model, simulate and check Web Services systems with time requirements. As far as the application domain is concerned, WS-Engineer, Baresi et al.’s tool and WSAT cannot manage time information. DECLARE uses a constraint-based process modeling language for the development of declarative models describing loosely structured processes. EA4B is a specific tool for implementation and debugging issues, but timed aspects are likewise not considered.
3. State of the art: Background In this section we describe the techniques, models and tools that we use in the WST tool, namely, the extended KAOS goal model for the requirements elicitation phase, UML 2.0 sequence diagrams for the design phase, WS-CDL for the composite Web Services description, and UPPAAL (supporting timed automata) for the validation and verification phase.
3.1. Extended KAOS goal model The KAOS goal model24 allows analysts and specifiers to gather the requirements of software systems in a hierarchical order, i.e. from general and strategic goals to concrete requirements. Goals are objectives the system under construction must achieve, and with the KAOS technique a structured goal model is constructed as an AND-OR graph (see Figure 1). Thus, goals are organized in AND/OR refinement-abstraction hierarchies, where higher-level goals are in general strategic, coarse-grained and involve multiple roles, whereas lower-level goals are in general technical, and involve fewer roles. In such structures, AND-refinement links relate a goal to a set of subgoals possibly conjoined with domain properties; this means that satisfying all subgoals in the refinement is a sufficient condition in the domain for satisfying the goal. OR-refinement links may relate a goal to a set of
alternative refinements and, in this case, it is enough to satisfy just one of the subgoals. In the analysis phase, for instance, we gather the time requirements, such as deadlines, time-outs and any other constraints where time plays a crucial role. Once the requirements have been gathered, this technique establishes an underlying temporal logic in order to formally define the leaf goals. The original logic and the goal-model have been extended with some new notions in order to fix the gap between the temporal logic used by KAOS and the one used by UPPAAL. Therefore, in our previous work,25 we introduced new notions, such as different types of goals and the inheritance capability types from goals to their subgoals. Keywords such as Achieve (reachability), Avoid (not safety), Maintain (safety), possibly always, inevitably and unbounded response, are used to name goals according to the temporal behavior pattern they prescribe. These patterns are depicted in Table 2.
3.2. UML 2.0 sequence diagrams A sequence diagram of UML 2.0 depicts the sequence of actions that occur in a dynamical system (see Figure 2).4 The invocation of methods of each object, and the order in which the invocation occurs, is captured by a sequence diagram. This makes the sequence diagram a very useful tool to represent the dynamic behavior of a system in a simple way. Furthermore, we use frames, which are a key element of sequence diagrams, and extend their functionality by adding some new capabilities to them, such as the possibility of labeling, nesting and modeling of control structures. Frames are defined as units of behavior, and contain, among other things, the set of objects that are in relation, and the sequence of messages between these objects. They can show different kinds of structure: alternative alt, optional behaviors opt, repetitive loop and parallel par. These structures also consist of clauses where designers can establish the conditions under with they are performed. Conditions can state information comparisons and time restrictions.
Requirement
Requirement
And-refinement Or-refinement SubReq1
SubReq2
Figure 1. And-refinement and Or-refinement goal models.
SubReq1
SubReq2
Cambronero et al.
353
Figure 2 shows an example of a hotel reservation scenario modeled by means of a sequence diagram where we can see five objects: Window, aChain, aHotel, aReservation and aNotice, which are instances of the classes User Interface, Hotel Chain, Hotel, Reservation and Confirmation, respectively. This
Table 2. Temporal behavior patterns Temporal behavior
Artifact
Maintain (Safety) A [ ] ’
Achieve (Reachability) E ’
Possibly Always E [ ] ’
scenario works as follows. If the login has been successfully performed, then the Window object sends the message makeReservation():void to the aChain object, that is, it invokes the make reservation operation. Afterwards, the aChain object re-sends it to the aHotel object, which checks if there is an available room for each day of the reservation. If this is the case, then the aHotel object invokes the creation of a reservation, which invokes the creation of a notification. This example ends when the send statement invocation reaches the aChain object, which invokes the statement showing through the user interface window. This last communication is not immediate: in fact, there is a temporal frame of 10 minutes to accomplish it. In this example, we have established three opt frames to show three different conditions: the necessity of being logged in, the condition of an available room to perform the reservation, and a time restriction that establishes a timeout of 10 minutes to accomplish the behavior.
Inevitably A ’
3.3. Web service choreography description language WS-CDL Unbounded Response ’– –>
Figure 2. Example of a UML sequence diagram.
A WS-CDL document2 basically consists of parties, roles, the exchanged information description,
354
Simulation: Transactions of the Society for Modeling and Simulation International 88(3)
choreographies, channels and activities. Parties and roles are used respectively to specify the collaborating entities and the different types of behavior of these entities, although, for simplicity, we use parties and roles indistinctly. Choreographies are the main elements of a WS-CDL description. In general, a WS-CDL document contains a hierarchy of choreographies, one of them being the root choreography, while the others are performed by explicit invocation. However, in this paper we only consider plain WS-CDL documents, which have only the root choreography. A choreography has three main parts: the life-line, the exception block, and the finalizer blocks. The lifeline contains the activities performed by the choreography in normal conditions. In the event of a failure, the control flow is transferred to the exception block (or the exception is propagated to the enclosing choreography when the exception cannot be handled in its exception block). A finalizer block in a choreography is always associated to an immediately enclosed choreography, and can only be executed (by explicit invocation) when its corresponding choreography has successfully completed its execution. Obviously, the root choreography will not have any finalizer blocks, so we will omit them in our meta-model. Channels are used to establish where and how the information is exchanged, but they are unimportant for our purposes, so we abstract them in our metamodel. The collaborative behavior of the participants in a choreography is described by means of activities. These are the lowest level components of a choreography, and are divided into three groups: basic activities, ordering structures and workunits. The basic activities are used to establish the variable values (assign), to indicate some inner action of a specific participant (silent_action), or that a participant does not perform any action (noaction), and also to establish an exchange of messages between two participants (interaction). An interaction can be assigned a time-out, i.e. a time to be completed. When this time expires (after the interaction was initiated), if the interaction has not completed, the timeout occurs and the interaction finishes abnormally, causing an exception block to be executed in the choreography. The ordering structures are used to combine activities with other ordering structures in a nested structure to express the ordering conditions under which information within the choreography is exchanged. The ordering structures are sequence, choice and parallel, with the usual interpretation. Finally, workunits are used to allow the execution of some activities when a certain condition holds. Thus, a workunit encapsulates one activity, which can only be executed if the corresponding guard is evaluated to true. Furthermore, there is another guard in the workunits in order to allow the iteration of the enclosed activity.
3.4. UPPAAL UPPAAL7 is a tool for modeling, validation and verification of real-time systems. This tool is in a very mature state of development, the last version being 4.0.26 Furthermore, there is a wide variety of derived tools such as UPPAAL-Tiga, UPPAAL-CORA, UPPAALTRON, UPPAAL-COVER and UPPAAL-PORT. In UPPAAL V. 4.0, the validation part is performed by graphical simulations and the verification part by Model-Checking means. A system in UPPAAL consists of a network of concurrent processes, each of them modeled as a timed automaton. This is called Network of Timed Automata (NTA). Timed Automata in UPPAAL are extended with bounded integer variables, which can be read or written by means of expressions labeling the edges, and can be tested in guard conditions. A state of a NTA in UPPAAL is then defined by the locations of all of the automata, and the clock and variable valuation. Another important feature of UPPAAL that we use are templates, which are parameterized generic declarations of timed automata, which can later be instantiated. The simulation step in UPPAAL consists of running the system to check that it works in a proper way under normal conditions. Since simulation does not guarantee the system correctness completely, we must use the verifier tool to check some properties of the system that are of interest, and that should be ensured in all conditions. For instance, we can check reachability properties, i.e. if a certain state is reachable or not. This is called Model-Checking and it is basically an exhaustive search that covers all possible dynamic behaviors of the system.
4. Web Services Translation tool WST is an integrated environment for translating UML 2.0 sequence diagrams into WS-CDL specification documents and, in turn, the WS-CDL specifications are translated into Timed Automata, which are then used to simulate and verify the system behavior. This tool is available from http://www.dsi.uclm.es/retics/WST/, where the tool and the XSL files can be downloaded, the transformation rules being defined in the folder called XSLFiles Moreover, we also provide a folder of examples in the Documentation section. In the generation of Web Services, as in the generation of any software system, it is necessary to apply a methodology contributing to some phases of the life cycle. WST implements part of a top-down methodology, which consists of the following phases: 1. Analysis phase: In the analysis phase we use a technology based on goal models performing requirement
Cambronero et al.
2.
3.
4.
5.
engineering called KAOS24 in order to capture the requirements that the system must fulfill. Design phase: In the design phase we use UML 2.04 and, specifically, sequence diagrams including some new capabilities, as the possibility of nesting frames to model the time restrictions of a system. We also use the UML Profile for Schedulability, Performance, and Time (RT-UML)27 in order to capture the time analysis requirements of systems in a proper way. Choreography phase: We automatically translate the UML sequence diagrams into WS-CDL documents. Validation of Choreography phase: The generated WS-CDL documents are translated into Timed Automata, which are used in UPPAAL to simulate the system, by running it and checking that it works in a proper way under normal conditions. Verification of Choreography phase: The obtained Timed Automata are then used to verify some properties of interest by using the UPPAAL tool. The properties to check are those that we have established in the first phase. If we detect some failures here, we return to the second phase.
The requirements gathered in the analysis are used during the verification as the properties that the model should satisfy. They are also used to identify the entities and the functionalities of the system, so they are taken into account in the design phase. During the verification process, if any of the properties are violated, then a counterexample is generated. With this crucial information, it is possible to identify the exact point and time where the error occurs in the timed automata model by means of simulation in UPPAAL. This point also corresponds to a certain point in the sequence diagram that can be obtained by following the trace generated by the automated translations applied in the choreography and validation phases. Thus, with the information about the violated property corresponding to a requirement, which identifies the entity of the UML diagram and the functionality that is not satisfied, and the exact point in the sequence diagram where the error occurs, the designers can modify the sequence diagram to fix the error. Currently, the choreography phase and the translation of the choreography model into Timed Automata are covered by the WST tool. The tool applies several XSL Style sheets to an initial XML document to obtain another XML document; for instance, we create three XSL Style sheets in order to translate an initial WS-CDL document into another XML document representing the Timed Automata system. Let us now see in greater detail each one of the translations supported by the WST tool.
355
4.1. Obtaining WS-CDL documents from UML 2.0 sequence diagrams WST translates a real-time Web Service description written in a UML sequence diagram into a more commonly used language for Web Services choreographies description, WS-CDL. The steps that the WST tool follows for this translation are similar to those used in the next translation (from WS-CDL to Timed Automata). The UML file is structured in different sections, from which we obtain the elements that compose the WSCDL document. A description of the translation follows for the key elements of sequence diagrams: . Objects: The objects in UML Sequence diagrams correspond to the role types of WS-CDL, which are used to describe the behavior of each class of party that we are using in the choreography. Thus, this definition matches the definition of an object in UML sequence diagram terminology. In these diagrams, the names of the objects are underlined to distinguish them from classes. The object name is also separated from the class name by a colon. . Messages: We consider request, answer and request/ answer messages in UML, and these messages are translated into WS-CDL by means of channels, relation types (which define the communication between two roles and the channels used for that communication), and interactions (the basic element of WS-CDL). Messages in UML sequence diagrams correspond to Relation types, which are used to define the communication between two roles (interactions in WS-CDL), and the channels needed for this communication. . Labels and time constraints: These are easily translated, as time variables, time-outs, information types or expressions in WS-CDL. In addition, as indicated above, we use frames to model the main control structures, specifically, we consider UML frames labeled with alt (choice), opt (guarded action), par (parallel) and loop (iteration): . UML Frames labeled with ‘par’ are translated as parallel ordering structures, indicating the activities that are made in parallel. An ordering structure contains one or more Activity-Notations that are enabled concurrently once the parallel activity is reached. . UML Frames labeled with ‘loop’ can be translated as workunit ordering structures, indicating iterative computations. The optional attribute ‘guard’ specifies the guard condition of a workunit, and the optional attribute ‘repeat’ specifies the repetition condition of a workunit.
356
Simulation: Transactions of the Society for Modeling and Simulation International 88(3)
. UML Frames labeled with ‘opt’ are translated as workunit ordering structures. In the same way, the UML frames labeled with ‘alt’ are translated by using choice and workunit ordering structures. Choice ordering structures capture that only one of two or more activities should be performed. Inside the choice we include two workunits with guard conditions, which capture the ‘if-else’ structure (corresponding to alt frames), the first workunit that matches the guard condition is selected and the other workunit is disabled. Table 3 contains a scheme illustrating how the main elements of UML are translated into WS-CDL (for more details see Cambronero et al.28).
4.2. Obtaining timed automata documents from WS-CDL specifications WST translates a Web Service system specification into an NTA. The obtained NTA allows us to validate and verify the expected requirements of the system. The steps that WST follows to translate a WS-CDL document into a Timed Automata system are shown in detail in Cambronero et al.29 Here we give a brief description of how this translation works. In the Timed Automata model that we consider, we have non-negative integer variables and urgent edges. The variables can be assigned a value when executing an edge, and their values can be checked in the guards
and invariants. Urgent edges inhibit time elapsing when they are enabled. A function ’ is first defined which associates an NTA to every activity of WS-CDL, where ’ : Activities x Pf ðCÞ x N NTA x Pf ðCÞ. The main argument of this function is the activity for which the translation is made, but it has two additional arguments: one set of clocks ðPf ðCÞÞ and one location (N). The set of clocks indicates a set of clocks that must be reset just before finishing the execution of the generated timed automata (for compositional purposes). The location is used to transfer the control flow there in the event of a failure, explained in Section 3.3. We denote by ’1 ðA,C,l Þ the first projection of ’, i.e. the obtained NTA, and by ’2 ðA,C,l Þ its second projection, i.e. the set of clocks that should be reset when using this NTA compositionally. A choreography is now defined as a pair ðA1 ,A2 Þ, where A1 and A2 are activities. Here A1 is the activity of the life-line of the choreography and A2 is the activity of its exception block, which can be empty (denoted by ), because the exception block is optional. Thus, given a choreography C ¼ ðA1 ,A2 Þ, we define its associated NTA as follows (Figure 3): . We first create a location ‘de’, which we call the ‘double exception location’, which is used as the location to which the control flow is transferred in the event of a failure within the exception activity A2 . We then generate ’ðA2 ,,deÞ.
Table 3. UML 2.0 to WS-CDL mapping rules Object
!
Role
Message Label and Time Constraint Frame ‘alt’ Frame ‘opt’ Frame ‘loop’ Frame ‘par’
! ! ! ! ! !
Relationship Type & Channelþ & Interaction Time Variable & Information Type & Expression Choice Workunit (without repeat condition) Workunit (with a repeat condition) Parallel
Symbol þ is BNF notation, and & is used to join information.
(True, T, ϕ2(A2, ∅, de)) e
de
A= init A 1
end A ϕ1(A1,∅,e)
Figure 3. From WS-CDL to NTA (I).
1
init A
endA
2
2
ϕ1(A2,∅,de)
Cambronero et al.
357 Furthermore, we can see that according to the previous description, in the event of a failure, all of these constructions transfer the control flow to a location, which is indicated as a parameter in the function u, and reset the clocks indicated as parameter in all the edges reaching the final location.
. We now create the exception location ‘e’, where the control flow is transfer in the event of failure in A1 , and then we generate ’ðA2 ,,eÞ. . We connect the exception location ‘e’ with the initial location of ’1 ðA2 ,,deÞ by means of an urgent edge, which must reset all of the clocks in ’2 ðA2 ,,deÞ.
5. Application: an internet purchase process
Figures 4 and 5 show how the function ’ is defined for the different activities, where we can observe that all of the obtained automata have both one initial and one final location, this property being preserved by all of the constructions. As can be seen in these figures, we use urgent edges, which are graphically distinguished because they have their arrowhead painted in white. Urgent edges are top priority when they are enabled.
Throughout the Internet, we can see a wide variety of Web Services where time restrictions play crucial roles. Perhaps, the most common of them and those with which we must deal almost every day are the ‘deadlines’. Clear examples are the maximum delay between two actions. For instance, we can think about the delay
ϕ1(A,C,l)
Term noaction(r)
ϕ2(A,C,l)
(True,noaction(r),C) init
∅
endnoact
noact
fail
