We illustrate with a simple example how the Spatial Logic Model Checker can be used to check choreography conformance propertie

Caires, Luis

Tavares Sousa, David

Torres Vieira, Hugo

IMT Institutional Repository

Checking choreography conformance using SLMCLu´ıs Caires, David Tavares Sousa, Hugo Torres VieiraOctober 16, 2007AbstractWe illustrate with a simple example how the Spatial Logic ModelChecker can be used to check choreography conformance properties.1 IntroductionSpatial Logics [4, 3, 5, 2] have proven their adequacy to express prop-erties of distributed systems. Distributed processes run, communicate,access resources, and so on, in a distributed structured space, whichmakes them natural candidates for the specification of properties usingspatial logics that are specially equipped with structural observations.One example of a distributed model is service oriented computing, aparadigm of gaining importance given its widespread application. Thepurpose of a service relationship is to allow the incorporation of certainactivities in a given system, without having to engage local resourcesand capabilities to support or implement such activities. By delegatingactivities to an external service provider, that will perform them usingits own remote resources and capabilities, a computing system mayconcentrate on those tasks for which it may autonomously provideconvenient solutions. Thus, the notion of service makes particularsense when the service provider and the service client are separateentities, with access to separate sets of resources and capabilities. Thisunderstanding of the service relationship between provider and clientassumes an underlying distributed computational model, where clientand server are located at least in distinct (operating system) processes,more frequently in distinct sites of a network.As services collaborate to reach a determined goal, an importantaspect subject to verification is that the protocols of interaction aredesigned correctly, i.e., in accordance to an interaction specification.The idea is that one can statically set the rules of interaction in achoreography plan and check that interacting partners conform to sucha specification. Furthermore it might be interesting to verify that suchinteractions do not cause systems to get stuck, and other liveness andalso safety properties.We illustrate here with a familiar example a natural specificationof a choreography conformance property using spatial logics, and wedemonstrate the verification of such property using the SLMC tool [9,11], that uses pi-calculus [8] to specify systems and the spatial logicsof [2] to describe the properties.2 Buyer Seller Shipper revisitedWe consider the Buyer, Seller, Shipper pattern. Our system will bebuilt out of three distinct parts, each one representing a separate entity:either the Buyer, or the Seller or finally the Shipper. For the sake ofsimplicity each one of these participants will be identified by a name.The top level system description will then look like:defproc System = Buyer(bu) | Seller(se) | Shipper(sh);The names given as arguments will function as the identifiers. Thegeneral idea is that the Buyer is going to try to buy something off theSeller, deciding upon the price requested, being that in a successfulpurchase the Seller interacts with the Shipper to obtain the deliverydetails, which are then sent back to the Buyer. We turn to the defini-tion of the Buyer:defproc Buyer(buyer) =new session in (quoteCh!(session,buyer).session?(quote).select {session!(accept).session?(deliverydetails).Buyer(buyer);session!(reject).Buyer(buyer)});The behaviour of the Buyer can be described as: first tries to com-municate with the Seller using channel quoteCh, and establishes a ses-sion by emitting the private name session. The Buyer then expectsa message indicating the price on session, depending on which thedecision to purchase is made. If the Buyer decides to purchase thenit will inform the Seller, sending accept on session, and expects theSeller to inform on the delivery details. At the end of each run, bothin a successful purchase or not, the Buyer returns to the initial state.We now turn to the description of the Seller:defproc Seller(seller) =quoteCh?(session,bu).session!(price).session?(choice).select {[choice=accept].new t in (deliveryCh!(t,seller).2t?(deliverydetails,sh).session!(deliverydetails).Seller(seller));[choice=reject].Seller(seller)};The Seller will start by following the interaction described for theBuyer: first expects a request for a price and replies informing on theprice on a received name session, afterwards expecting a decision onthe purchase. In the case of acceptance by the Buyer, signalled bythe matching of the received name and accept, the Seller will place arequest to the Shipper to obtain the delivery details. After receivingthe delivery details from the Shipper, the Seller forwards them to theBuyer and returns to the initial state. In the case of rejection of thepurchase the Seller directly returns to the initial state.Finally we have the Shipper description, that expects requests fordelivery details, post replies to these requests and returns to the initialstate:defproc Shipper(shipper) =deliveryCh?(t,se).t!(deliverydetails,shipper).Shipper(shipper);3 ChoreographyWe start with the specification of a message link or connection, i.e., twoparts of a system are linked or connected if they hold dual capabilitiesof a channel. We also specify and identify the source or sender and thedestination or receiver:defprop sArrow(message,src,dst) =inside((1 and @src and <message!>true)| (1 and @dst and <message?>true ) | true);The property sArrow here specified states that opening up all re-stricted names, that can bind parts of the system, the system can bebroken down into three parts |, two that are indivisible 1, and anotherthat can be anything true. The two indivisible parts hold occurrencesof the names src and dst that identify them as sender and receiver, re-spectively, being that the sender must exhibit an output ! on messagewhile the receiver must exhibit the input ?, being the continuationsspecified as any possible state.Using this predicate sArrow we can then be more specific of thelinks we intend to describe:defprop sBuyer2Seller(message) = sArrow(message,bu,se);defprop sSeller2Buyer(message) = sArrow(message,se,bu);defprop sShipper2Seller(message) = sArrow(message,sh,se);defprop sSeller2Shipper(message) = sArrow(message,se,sh);3We can express that the Buyer is able to send a message to theSeller that is in turn able to receive that message sBuyer2Seller.We can express the same property reverting the communication rolessSeller2Buyer. We can express that the Shipper and Seller can beconnected both ways: either sShipper2Seller or sSeller2Shipper.Let us now describe the initial interaction between Buyer and Seller:defprop buyerSellerInteraction(session, A) =sBuyer2Seller(quoteCh) and[] ( sSeller2Buyer(session) and[]( sBuyer2Seller(session) and[][]( A )));We have that initially Buyer and Seller can communicate on mes-sage quoteCh, corresponding to the price request, and also any pos-sible evolution of the system [ ] will lead to a state where Seller isconnected to Buyer on the parametered name session, correspondingto the reply to the price request. After any possible evolution Buyeris connected to Seller again on the channel given by session, to in-form on the decision taken. After two steps, involving the decisionprocedure, the system is in a state specified by the parameter A.We turn to the description of the interaction between Seller andShipper:defprop sellerShipperInteraction(A) =sSeller2Shipper(deliveryCh) and[] hidden t.( sShipper2Seller(t) and[] ( A ));Property sellerShipperInteraction specifies that at starting point,Seller is connected to Shipper in channel deliveryCh, correspondingto the request for delivery details. Also, after one step, there is a re-stricted name t under which Shipper is connected to Seller, where thedelivery details will be passed along. Afterwards Seller is connected tobuyer, corresponding to the forwarding of the delivery details. Finally,after one step, the system is in a state specified by the parameter A.We are at this point able to devise a specification that expressesthe overall behaviour of a run of this protocol between Buyer, Sellerand Shipper:defprop sGlobalDescription =maxfix X.(hidden session.buyerSellerInteraction(session,XorsellerShipperInteraction(sSeller2Buyer(session) and []X)));So, recalling that the interaction properties require an argumentthat specifies the final state of the interaction we have that: We start4by revealing the restricted name session and then we proceed to specifythat the interaction between Buyer and Seller takes place using thatname. Afterwards the system either returns to the initial state or theinteraction between Seller and Shipper takes place. If the interactionbetween Seller and Shipper occurs, at the end of it the Seller is onceagain connected to the Buyer, in channel session, after which anypossible evolution leads back to the initial state.3.1 Checking choreography conformanceAfter loading the example on the SLMC tool one can write:check System |= sGlobalDescription;to which the tool will reply with:* Process System satisfies the formula sGlobalDescription *thus giving our intended assertion.3.2 Checking other propertiesOther interesting properties include liveness, which can be writen as:defprop aLive = always (<tau>true);Property aLive specifies that a system in every possible state canalways perform an internal action tau, hence the system never getsstuck.Also we may consider of interest to check safety properties like, forinstance, the existence of races. We start by specifying that a writer isan indivisible process that can perform an output on a given channel.defprop write(x) = (1 and < x! >true);We characterize a reader similarly, being the channel capability theinput:defprop read(x) = (1 and < x? >true);We can now express that a configuration that holds a race is onewhere there exists a channel where two distinct components are tryingto write to and there is one other trying to read from:defprop hasRace =inside (exists x.( write(x) | write(x) | read(x) | true));Finally we can state that a race free system is a system that inevery possible configuration holds no races.defprop raceFree = always (not hasRace);Once again we load the example in the SLMC tool:check System |= raceFree;5to which the tool will reply with:* Process System satisfies the formula raceFree *thus giving our intended assertion.4 Concluding remarksWe have shown by means of a simple example how one can use theSLMC tool to check for choreography conformance. We presenteda simple specification of the familiar buyer shipper seller pattern inpi-calculus, and showed a natural description of the choreography ofinteraction using spatial logics.An interesting follow up to this illuminating exercise would be touse an analogous approach considering service-world languages, suchas WS-BPEL [6] to provide system specification and WS-CDL [7] to givethe choreography plan.References[1] Spatial logic model checker. http://www-ctp.di.fct.unl.pt/SLMC/.[2] L. Caires. Behavioral and Spatial Properties in a Logic for thePi-Calculus. In Igor Walukiwicz, editor, Proc. of Foundations ofSoftware Science and Computation Structures’2004, number 2987in Lecture Notes in Computer Science. Springer Verlag, 2004.[3] L. Caires and L. Cardelli. A Spatial Logic for Concurrency (PartII). In CONCUR 2002 (13th International Conference), LectureNotes in Computer Science. Springer-Verlag, 2002.[4] L. Caires and L. Cardelli. A Spatial Logic for Concurrency (PartI). Information and Computation, 186(2):194–235, 2003.[5] L. Cardelli and A. D. Gordon. Anytime, Anywhere. Modal Log-ics for Mobile Ambients. In 27th ACM Symp. on Principles ofProgramming Languages, pages 365–377. ACM, 2000.[6] A. Alves et al. Web Services Business Process Execution LanguageVersion 2.0. Technical report, OASIS, 2006.[7] N. Kavantzas et al. Web Services Choreography Description Lan-guage Version 1.0. Technical report, W3C Working Draft, 2005.[8] D. Sangiorgi and D. Walker. The pi-calculus: A Theory of MobileProcesses. Cambridge University Press, 2001.[9] H. Vieira and L. Caires. Spatial logic model checker user’s guide.Technical Report TR-DI/FCT/UNL-03/2004, DI/FCT Universi-dade Nova de Lisboa, 2004.6

Checking for choreography conformance using spatial logic model-checking

Abstract

Similar works

Full text

Available Versions

IMT Institutional Repository