Verification of Web Service Flows with Model-Checking Techniques

Transcription

1 Verification of Web Service Flows with Model-Checking Techniques Shin NAKAJIMA Hosei University and PRESTO, JST Abstract UDDI register Web service is an emerging software technology to use remote services in the Internet. As it becomes pervasive, some language to describe Web service flows is needed to combine existing services flexibly. The flow essentially describes distributed collaborations and is not easy to write and verify, while the fault that the flow description may contain can only be detected at runtime. The faulty flow description is not desirable because a tremendous amount of publicly shared network resources are consumed. The verification of the Web service flow prior to its execution in the Internet is mandatory. This paper proposes to use the software model-checking technology for the verification of the Web service flow descriptions. For a concrete discussion, the paper adapts WSFL (Web Services Flow Language) as the language to describe the Web service flows, and uses the SPIN model-checker for the verification engine. The experiment shows that the software model-checking technology is usable as a basis for the verification of WSFL descriptions. 1 Introduction As using the Internet becomes a part of our daily activities, Web service, a new form of software technology to use remote services, is emerging [1][15]. The Web service is now considered as a new infrastructure for the e-business type applications. Generally, end-users find to use appropriate Web services that are located somewhere in the Internet. Further, it sometimes requires to combine more than one Web services to fulfill their needs. A concept of service aggregation, combining existing Web services easily as our needs change, is one of the key features of the technology. For the service aggregation to be a usable technology, it is apparent that a way of expressing the flow that describes how various Web services are composed is important. Since each Web service is a self-contained software system having its own threads of control, the flow description can be regarded as a kind of distributed collaboration. Unfortunately, lookup Client service interaction... Figure 1. Web Service such a distributed system is not easy to validate its correctness. Further, the faulty behavior that the system might have can only be detected at runtime due to the limitation of the current Web service technology. The faulty flow description is not desirable just seen from a viewpoint of the conventional software engineering. The situation with the Web service flow is worse than that because a tremendous amount of publicly shared network resources are consumed. It is apparent that the verification of the Web service flow prior to its execution in the Internet is mandatory [12]. This paper proposes to use the software model-checking technology [3] for the verification of the Web service flow descriptions. For a concrete discussion, the paper adapts WSFL (Web Services Flow Language) [10] as the language to describe the Web service flows, and uses the SPIN modelchecker [6] for the verification engine. The paper discusses in detail a method of verifying WSFL description by using SPIN. In particular, it presents an encoding method that translates WSFL primitives to Promela, the input specification language of SPIN. The experiment shows that the software model-checking technology is usable as a basis for the verification of WSFL descriptions. 2 Web Service Aggregation As Web service becomes pervasive, an end-user can use various services spread over the Internet [1][15]. It needs standardization for various aspects of the Web services to push the technology for a wide acceptance. Figure 1 illus-

2 trates a typical scenario that involves related technologies. UDDI (Universal Description, Discovery and Integration) [14] is a directory server, which uses [2] to describe properties of the Web services that UDDI manages. A global UDDI has entities, each describing properties of existing Web services (s); the properties are described in. A client searches the UDDI so that he finds appropriate Web services. Then, he initiates the service interactions with them. (Web Service Description Language), standardized by W3C, is a format meant to be used to describe the external interface of Web services, and uses the XML technology for the concrete representation. is essentially an XML document for representing the endpoint interface specification of the service, each of which provides information necessary for users to access. Figure 2 presents an illustration of the Web service aggregation. A typical example of such an aggregation is a travel agency. A travel agency has a variety of business partners such as airline carriers, hotels, rent-a-car agencies or railroad operation companies. The agency accepts requests directly from its customers to make itineraries with related reservations of hotels, airlines etc. When regarding each of its business partner as an independent Web service provider that has a definite for accesses from the outside, the travel agency actually implements a Web service flow as schematically shown in Figure 2. In addition, the travel agency can be a service provider that has its own for the clients to make accesses. The agency also registers itself in some global UDDI server. A concept of service aggregation, combining existing Web services, may be considered unique for the Web service technology. There are a lot of the Web services ready for the clients to use. The clients combine flexibly some of the existing Web services as their own needs change in an ad-hoc manner. The aggregation is essentially making the Web services to collaborate with each other; each of the services are self-contained software systems having its own threads of control. Thus, the description for the aggregation needs an explicit notion of both control and data flows among the Web services, that faithfully reflects the causal structure of the services. The flow essentially describes distributed collaborations. Up to now, two languages, WSFL [10] and XLANG [13], for describing Web service flows have been proposed. The aim of both languages is to augment with the behavioural aspects of the flow. By using one of the languages, end-users can express their own needs as programs or flow descriptions. It, however, needs a great care on submitting the descriptions to execute in the Internet. The flow descriptions may contain bugs because it is probable for end-users to write such flow descriptions in an ad-hoc manner. Buggy flow descriptions are not desirable just seen from Service Aggregation Figure 2. Web Service Aggregation Rollback Fault!! Figure 3. Faulty Flow Rollback a viewpoint of the conventional software engineering. It can, further, be argued that the situation with the Web service is worse than that because of the following reasons. 1. A lot of Web services are invoked before the flow reaches a point where the fault is found. The cost of rollback all the transactions executed within each service provider is high. Figure 3 shows the situation. 2. A lot of network traffic are consumed in order that network Web services are invoked. And all the consumed traffic is turned to be void at the point of the fault. It implies that a careless end-user, executing a buggy flow description, consumes tremendous amount of network resources that are shared publicly. Thus, verifying the Web service flow prior to its execution in the Internet is mandatory [12]. 3 Verification Method This section presents an approach to the verification with the software model checking techniques [3]. In order to make the discussion concrete, this paper adapts WSFL [10] as the flow description language and SPIN [6] as the verification engine. 3.1 Overview of Verification Process WSFL, as will be explained in Section 3.2.1, is essentially a workflow schema description language that is based on the net-oriented specification paradigm. The verification

3 WSFL Description Translation Promela Description SPIN (Model-Checker) Properties in LTL Figure 4. Verification Process OR-join AND-join flowsource flowsink Figure 5. WSFL Basis problem, thus, turns out to be one similar to the verification of workflow or business flow [4][8][11]. Figure 4 shows the verification process. The flow description written in WSFL is translated into Promela, the input specification language of SPIN. The properties to be checked are reachability, deadlock-freedom, or application specific progress properties. The application specific properties are expressed as formulae of LTL (Linear Temporal Logic), which are also fed into SPIN. 3.2 Formalization The formalization mainly concerns with the translation of a WSFL flow model into Promela processes. The Promela processes should faithfully encode the operational semantics of WSFL WSFL WSFL (Web Service Flow Language), proposed by IBM, is a net-oriented specification language, originated from a model of a workflow description language [9]. Each service invocation corresponds to a task of workflow and both control and data flows are represented as arcs relating task nodes. WSFL is meant to be a behavioural extension of, and is equipped with an XML-based concrete syntax. The core part of the behavioural aspect is a WSFL flow model. Figure 5 shows a schematic illustration. The WSFL flow model shows how the description combines the necessary existing Web services. An invocation of Web service, called a flow activity depicted as a circle in Figure 5, corresponds to a workflow node. Each activity may have an event of invoking some external service provider, accepting notification from the outside, or performing an internal action. Here, an internal action is assumed to be implemented in the platform that the flow model is executing. Both control (straight lines) and data (dotted lines) flows between the activities are links in Figure 5. A flow model starts with a single flowsource and ends with a single flowsink. Further, the activity may have join conditions, such as AND-join or OR-join, to express the control flow logically. The logical condition is posed on the input control flows of the activity. The flow model can itself define its own service provider type that can be used from the outside (either other flow model or service provider). The specification document [10] describes the operational semantics of the WSFL flow model. The semantics is based on the PM-flow [9] proposed by the same author as a workflow schema language. In a word, WSFL can be considered as an XML-based workflow schema language following the PM-flow model. The semantics is similar to that of CPN (Coloured Petri Nets) [7]. The operational semantics is essentially given in terms of a set of rules that select activities to be fired. More than one activity are simultaneously able to fire, which is the source of concurrency. WSFL provides a global model in addition to the flow model. The aim of the global model is just to combine more than one flow models to have a large specification. The global model is mostly concerned with a structural aspect, and thus will not be discussed further in the following sections SPIN and Promela SPIN is an automaton-based model-checker developed by G. J. Holzmann [6]. SPIN provides a specification language Promela that describes the target system to be a collection of Promela processes (automata) with channel communications. Figure 6 is an example specification of ABP (Alternating Bit Protocol) written in Promela [5]. The example consists of two Promela processes, Sender and Receiver to have communication by using two Promela channels, sender and receiver, of the buffer size 1 (NBUF), and a special process init to initialize the target system. The message transmitted via the channels is actually a datatype of short, and some values are defined in terms of #define for readability. The 1 The example in Figure 8 actually makes use of the WSFL global model.

4 Promela process uses a syntax similar to Hoare s CSP for the message send and receive. The! syntax such as in receiver!msg1 depicts a send action, while the? as in sender?ack1 is a receive action. The Promela processes are translated into a (product of) Büchi automaton. SPIN uses the internal representation in the form of LTS (Labeled Transition System) to find some faulty situations such as deadlocks. Further, SPIN allows to express various properties such as application specific progress properties in terms of LTL. The LTL formula is automatically translated by SPIN into Büchi automaton and thus is checked against the target system automaton. An LTL formula can have [] (always), <> (eventually) and U (strong until) as the temporal operators Translation Templates The translation templates assume a framework of the representation in Promela as follows; mapping a WSFL activity to a Promela process, mapping control and data links to Promela channels. First, a WSFL datalink has a unique name (name) and both the source and destination activities (source and target) as its attributes. <datalink name=... source=... target=... /> Second, a WSFL control link has further two attributes in addition to the attributes that a datalink has. A transitioncondition is a logical formula that controls when the transition fires. And result has a pattern of a message to fire the transition. When its source activity generates a message that matches with the specified pattern, the control link is marked as fire. <controllink name=... source=... target=... transitioncondition=... result=... /> Third, a WSFL activity has a name (name) and a termination condition (exitcondition) as its attributes, and has many kinds of component members; the input data (input) and output data (output), the join condition (join condition), the entity of the service provider (performedby), and the data conversion format (materialize). A concrete representation concerning with the invocation of the service provider is specified as <implement>...</implement>. The exitcondition may need a further explanation. After the service provider returns some result, the condition is checked. And when the condition is not satisfied, the #define NBUF 1 #define MSG0 10 #define MSG1 11 #define ACK0 12 #define ACK1 13 chan sender =[NBUF] of { short }; chan receiver =[NBUF] of { short }; proctype Sender() { short any; again: do :: receiver!msg1 -> if :: sender?ack1 -> break :: sender?any :: timeout fi od; do :: receiver!msg0 -> if :: sender?ack0 -> break :: sender?any :: timeout fi od; goto again } proctype Receiver() { short any; again: do :: receiver?msg1 -> sender!ack1; break :: receiver?msg0 -> sender!ack0 :: receiver?any od; P0: do :: receiver?msg0 -> sender!ack0; break :: receiver?msg1 -> sender!ack1 :: receiver?any od; P1: goto again } init { atomic { run Sender(); run Receiver() } } Figure 6. Promela Example

5 provider is executed again with possibly different input parameters. Otherwise the repetition is terminated. In sum, the exitcondition provides a mechanism for looping. <activity name=... exitcondition=... > <input name= /> <join condition= /> <materialize... /> <performedby... /> <implement>... </implement> <output name= /> </activity> According to the translation framework mentioned early, a link is mapped into a Promela channel. In the current encoding, a channel has two parameters; the first carrying a value to be transmitted, and the second referring to an identity of the sender activity 2. chan <CName> = [NBUF] of { short, short }; The Promela process corresponding to a WSFL activity takes a skeleton form below. proctype <Name> (<Formal Parameters>) { <Wait Loop> <Join Step> <Materialize Step> <Perform Step> <Call Exit Step> <Control Step> <Propagate Step> } A Promela process has formal parameters that correspond to all the input and output channels. Thus, when writing a Promela process, it is not necessary to worry about the concrete names of the linked flows. This is in accordance with the fact that the control and data link carry names of linked activities, but the activity does not. It is also expected to increase a reusability of the process description. It, however, requires to explicitly instantiate appropriate channels as the actual parameters when initializing the processes in init. In other word, the topology, reflecting how the activities are related with the control and data links, is described in the initialization process. It can increase the readability of the Promela specification text. init { atomic{ run <AName>(<CName>,...);... } } The explanations of each fragment in a Promela process description come in order. 2 The second parameter is not necessary, but added to be a help in debugging the translated Promela processes. <Wait Loop> It checks all the channels of the incoming control flows, and waits until all the channels have definite values. <Join Step> It reads out all the (logical) values from the control channels, and evaluates the join condition by using the extracted values. When the condition turns false, <Materialize Step> <Perform Step> and <Call Exit Step> are skipped. <Materialize Step> It extracts, from the input data links, the data necessary for the service provider to execute. <Perform Step> It kicks the service provider entity. It sends the required information to the service provider via an appropriate channel, or receives some notification information from a channel. It varies according to the way the original WSFL description specifies. <Call Exit Step> It evaluates the exit condition of the WSFL activity, and decides whether the <Perform Step> is executed again or not. <Control Step> It computes the information that will flow along the output control links. It also does some evaluation relating to the transitioncondition and result of the control links. <Propagate Step> It propagates the informations along all the output links of both control and data. In the case that <performedby... /> specifies an outside service provider, the <Perform Step> in the Promela process is responsible for dealing with a call and return. A WSFL service provider has several ports, each of which in turn has more than one operations. The Promela counterpart should have means to identify which operation is involved in each Promela channel send or receive action. The current encoding defines a channel to have three parameters; the first carrying a value to be transmitted, the second having an encoding of the operation and port information, and third referring to an identity of the sender activity 3. chan <ChName> = [NBUF] of { short, short, short }; 3 The third parameter is not necessary, but added for a debugging purpose.

6 A p D q B r C OR-join Traveler Agent Airline Plan Trip Submit to Travel Agent Receive Ticket Get Trip Order Select Legs Order Ticket Get Confirmation Generate Itinerary Get Ticket Order Reserve Seats Charge Credit Card Confirm Flights Figure 7. Dead-Path Elimination Receive Itinerary Issue Itinerary Issue etickets Figure 8. Ticket Order Example Dead-Path Elimination The operational semantics of WSFL is somewhat complicated due to Dead-Path Elimination (DPE). Figure 7, extracted from the specification document [10], explains why DPE is needed. In Figure 7, the activity A has its result p to be true and the r of the activity B false. Since r is false, the activity C will never be executed. Therefore, the join condition of the activity D will also be never evaluated. The activity D, however, can in principle be executed because its join condition is OR and one of its input control link p is already known to be true. In a word, the activity D can be executed logically, but its join condition will never be evaluated in the naive semantics of WSFL. The DPE of WSFL provides a means to resolve such pseudo faulty situations. DPE starts its execution when a join condition becomes false, or when there is an activity having only a single input control link with false. DPE traverses the flow model downward to eliminate the pseudo faulty situations by forcing the related join condition to be evaluated. DPE uses false values when it needs logical calculation in the evaluation process. In order to introduce DPE, the Promela model extends the logical values consulted in the evaluation of the join conditions to have forced. The forced value is generated and flowed downward exactly when the above mentioned DPE starts, and is interpreted as false in the evaluation of the join conditions. The Promela process needs some modifications to include DPE in the <Join Step> and <Control Step>. 3.3 Property Checking Examples This section uses a concrete example to explain how the property checking is conducted. Figure 8 is a schematic illustration of the example derived from the specification document [10]. The example has three WSFL flow models, Traveler, Agent, and AirLine. The Promela description is obtained by following the translation template method discussed in Section The code size is about 700 lines of Promela source text. The experiment adapts a verification method consisting of two steps. 1. Individual Flow Check The first step checks Promela description for each flow model individually. The description consists of the flow model itself and an environment model that provides information necessary to check the flow. For the case of Traveler, the environment should accepts a request (Submit to Travel Agent), and generates two notifications (Itinerary and Ticket) afterwards. The checks conducted in this step mostly concerns with the reachability and deadlock freedom. The progress property is trivial because the flows are almost sequential. 2. Aggregate Flow Check The second step deals with the whole flow model. The three constituent flow models exchange informations that are depicted as dotted lines in Figure 8. The checks concern with the reachability and deadlock freedom. And some application specific properties, expressed as LTL formulae, are also checked. In order to show the effectiveness of the model-checking technique, a first version of Agent is assumed to have an error behaviour in that it does not return Itinerary to the caller Traveler. This error may not be uncovered by the individual flow check of Agent. It is because whether generating Itinerary or not does not make effect on the correctness of the internal behaviour of Agent. The error can be discovered by the aggregate flow check where all the WSFL flow descriptions are merged. The aggregate model results in a deadlock because Traveler waits indefinitely for Itinerary delivered by Agent. After the verification, one may remedy Agent to show correct behaviour.

7 SPIN shows that the corrected version does not have any deadlock state by searching the whole state space. As an example of application-specific progress properties, the formula below for the case of Traveler is checked. It says that it is always ([]) the case that if there is an event of SubmitToTravelAgent then eventually (<>) ReceiveTicket and ReceiveItinerary are followed. [](SubmitToTravelAgent -> (<>ReceiveTicket && <>ReceiveItinerary) The aggregate flow turns to be a large transition system with about 280 thousands of states and about 470 thousands of transitions. It is because three flow models are analyzed as they execute concurrently, while each flow executes almost sequentially as Figure 8 suggests. Actually the size of each flow model is small. Airline, for example, has only 201 states and 586 transitions. 3.4 Discussions A large part of the WSFL specification document [10] concerns with the relationship between and messages in WSFL. This paper only considers behavioural aspects of WSFL flow model, which focuses on the information flowing along the control and data links. It does not deal with any check relating to the actual values that the service providers generate nor anything similar to typechecking. It is because the behavioural aspect is more important for distributed systems than the type or value checking. The present technique should be combined with other approaches if one wants to conduct the type or value checking. It is sometimes argued that the translation approach, such as the one in the present paper, has disadvantage that the outcome of the analysis is not easy to feedback on the input specification descriptions. In the present approach, one can obtain fault traces from SPIN if some faulty behaviour exist in the Promela description. It should find WSFL counter parts that are the source of the fault. As shown in Section 3.2.3, the translation is almost straight-forward. Further, most of the possible faults can be detected as a deadlock situation, in which a certain Promela process waits for values from its incoming channels. Since the correspondence between WSFL links and Promela channels and those of WSFL activities and Promela processes are clear, it is not difficult to locate faulty points in the WSFL descriptions. It is also not hard to formulate another set of templates that translate the Promela description back to the WSFL descriptions. This paper deals with WSFL as the specification language for Web service flow descriptions. XLANG [13], coming from Microsoft, is another language for describing Web service flows. It is expression-oriented and has a set of concurrency primitives. For example, all executes each of the specified sub-processes (blocks) concurrently. Unfortunately, it is not clear from the specification document [13] whether XLANG has precise semantics or not. Further, since XLANG is based on the computational model quite different from that of WSFL, it is not easy to apply the technique presented in the paper to XLANG. 4 Conclusion This paper first presented a discussion on the importance of verifying Web service flows. It then proposed to apply the software model-checking techniques to the subject matter. The paper used WSFL as the Web service flow language and SPIN as the model-checker. In order to model-check the WSFL descriptions, the paper formulated a set of translation templates that provided means to translate WSFL primitives into Promela, the input specification language of SPIN. It also presented simple examples in that some nontrivial faulty behaviors can be detected with SPIN. We currently work on the development of an integrated verification environment which hides the details of Promela/SPIN from the users of the tool. References [1] M. Aoyama. Introduction to Software Service Technologies (in Japanese). In IPSJ Magazine, Vol. 42, No. 9, pages , September [2] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Service Description Language (). W3C Web Site, [3] E. Clarke, O. Grumberg, and D. Peled. Model Checking. The MIT Press, [4] H. Eertink, W. Janssen, P.O. Luttighuis, W. Teeuw, and C. Vissers. A Business Process Design Language, In Proc. FME FM 99, pages 76 95, September [5] G.J. Holzmann. Design and Validation of Computer Protocols. Prentice Hall, [6] G.J. Holzmann. The Model Checker SPIN. IEEE Trans. Soft. Engin., Vol.23, No.5, pages , May [7] K. Jensen. Coloured Petri Nets 1. Springer-Verlag, [8] C. Karamanolis, D. Giannakopoulou, J. Magee, and S.M. Wheater. Model Checking of Workflow Schemas. In Proc. IEEE EDOC 2000, pages , September 2000.

8 [9] F. Leymann and W. Altenhuber. Managing Business Processes as an Information Resource. IBM System Journal, vol.33, no.2, pages , [10] F. Leymann. Web Services Flow Language (WSFL 1.0). IBM Corporation, May [11] S. Nakajima. Verifying Business Flow Diagrams with CCS (in Japanese). In Proc. 1st JSSST Workshop on FOSE, pages , December [12] S. Nakajima. On Verifying Web Service Flows. In Proc. SAINT 2002 Workshop, pages , January Presented at WebSE 2002 [15]. [13] S. Thatte. XLANG Web Services for Business Process Design. Microsoft Corporation, May [14] UDDI Web Site. UDDI Technical White Paper. September [15] WebSE International Workshop on Web Service Engineering. Nara, February 2002.