Formalizing Web Service Choreographies

1. Formalizing Web Service Choreographies Antonio Brogi, Carlos Canal, Ernesto Pimentel, Antonio Vellecillo presented by Axel Polleres http://www.lcc.uma.es/~av/Publicaciones/04/ws-fm04.pdf

2. Overview • Formalizing WSCI descriptions in a process algebra (CCS): • WSCI • CCS • Exemplify how this formalization can be used to prove certain properties such as: • compatibility of services • automatic generation of adaptors • deadlock-freeness • Use for WSMO? • Usability of WSCI for WSMO interface descriptions? • Interesting: suggested algorithm for automatic adaptor generation from a general mapping description.

3. WSCI • Allows to describe more complex interface descriptions on top of WSDL: • Describe message flow from the viewpoint of each web service. • <interface> construct allows to model “externally observable behavior” of the service. • <model> construct: collection of interfaces and links between these interfaces: • allows for combination of two or more interface definitions and modeling their collaboration by linking symmetric WSDL operations of the respective interfaces.

4. WSCI: Constructs • sequence, parallel, choice, switch, loop, activities etc. • exceptions: onFault, onTimeout, onMessage • calling (synchronous) or spawning (asynchronous) named processes

5. TravelAgencyWS Book bookingReq Confirmation bookingAck Refusal bookingConf bookingRef Running Example: <wsdl:portType name=“BStoTraveller”> <wsdl:operation name=“Book”> <wsdl:input message=“bookingReq” /> <wsdl:output message=“bookingAck” /> </wsdl:operation> <wsdl:operation name=“Confirmation”> <wsdl:output message=“bookingConf” /> </wsdl:operation> <wsdl:operation name=“Refusal”> <wsdl:output message=“bookingRef” /> </wsdl:operation> </wsdl:portType> ... <interface name=“BookingService”> <process name=“BookTrip” instantiation=“message”> <sequence> <action name=“ReceiveBooking” operation = “BStoTraveller/Book”/> <switch> <case> <condition>placesAvailable</condition> <action name=“SendConfirmation” operation = “BStoTraveller/Confirmation”/> </case> <default> <action name=“SendRefusal” operation = “BStoTraveller/Refusal”/> </default> </switch> </sequence> </process> </interface> Global Model: <model name=“AirlineTicketing”> <interface ref=“bos:BookingService” /> <interface ref=“tra:Traveller” /> <interface ref=“air:Airline” /> ... <connect operations = “bos:BStoTraveller/Book tra:TravellerToBS/BookFlight” /> ... </model>

6. Formalizing WSCI • CCS (Calculus of Communicating Systems) by Robin Milner • Three kinds of atomic actions α: • internal action … τ • reception via channel a … a?(x) • transmission via channel a … a!(x) • Processes: P ::= 0 | α.P | P + P | P║P | A(x) A(x) = P … process definition, s.t. A(y) behaves like P{x/y}, allows also for recursive definitions • Transition rule for synchronization: a!(x) a?(y) P  P’ Q  Q’ P║Q  P’║Q’{x/y}

7. Translating WSCI to CCS: • Each WSDL message is represented by a CCS channel • Connections between operations in WSCI global model are naturally modelled by putting the corresponding processes in parallel, and linking their channels accordinlgy to what is specified in the global model

8. Translating WSCI to CCS: • [[in port/op/msg]]  port/op/msg?() • [[out port/op/msg]]  port/op/msg!() • [[empty]] τ • [[all P1 P2 … Pn]]  [[P1]] ║ [[P2]] ║ [[Pn]] • Seq = sequence P1 P2 … Pn  [[Seq(sq0, sqn)]] = [[P1 ]](sq0, sq1) || [[P2 ]](sq1, sq2) … [[Pn ]](sqn-1, sqn) where [[P]](begin,end) = begin?().[[P]].end!() Similar translations for switch, choice, (by means of “+”), timeouts, exception handlers (by spawning a parallel Timer process or introducing an extra argument for aborting execution when timeout is reached or an exception is raised)

9. Example: • [[BookTrip]]  BStoTraveller/Book/bookingReq?(). BSToTraveller/Book/bookingAck!(). (τ.BSToTraveller/Confirmation/bookingConf!().0 + τ.BSToTraveller/Refusal/bookingRef!().0) Remark:τin combination + with here models a local choice, only depending on an internal condition of the service which cannot be checked from outside.

10. Checking Web Service Compatibility • A set of interfaces is compatible if the system formed by the several entities always performs a finite number of silent actions τleading to the inaction 0. • In case of infinite loops, we redefine this definition to: system fails, whenever it could get stuck by a finite set of silent actions leading to a process different from 0 which cannot perform any further action by itself. • Weaker def. of compatibility: A system is compatible if it does not fail •  check by recursively matching input and output actions on translated interfaces. For instance: Traveller = TravellerToBS/Book/bookingReq!(). TravellerToBS/Book/bookingAck?(). TravellerToBS/Book/bookingConf?().0 is NOT compatible with BookTrip!

11. Checking Web Service Replacability S1 is replaceable by S2 if • Required services of S2 are a subset of req services for S1 • Behavior of both services ist consistent (behavioral subtyping): • S2 preserves the semantics of WS1 (concerning global choices) • S2 does not extend S1 (i.e. all actions in S2 are also in S1) • WS2 terminates whenever WS1 does. For instance: ImprovedBookTrip = BStoTraveller/Book/bookingReq!(). BStoTraveller/Book/bookingAck?(). BStoTraveller/Confirmation/bookingConf?().0 Is a valid substitute for the original BookTrip. Remark: any behavioral subtype is compatible with more clients thant its supertype.

12. Web Service adaption • Paper provides a notation for mappings of messages beyond simple (one-to-one) WSCI mappings for global model, for instance: S = { request!() <> bookingReq?(), bookingAck!(); reply?(“confirmed”) <> bookingConf!(); reply?(“refused”) <> bookingRef!() } • Paper defines algorithm for incrementally building up an “adapter entity” from such a mapping spec. and the respective interface definitions which successfully establishes a compatible system.

13. Conclusion & Outlook • Authors claim that formalization in a process algebra allows to apply model-checking techniques for checking complex properties (such as compatibility, replacability, and beyond) • Compatibility & Replacebility only sketched but not formally explained here (references to previous work on a formal notion on behavioral compatibility using CORBA given). • Mapping definitions more general than WSCI global model (not only one-to-one message mappings. • “Adapter generation” is more like derivation of the interface of an adaptor, no hints whether this is possible in general. • This is rather checking whether the mapping is feasible than “adaptor generation”: Mapping between messages has to be given beforehand.

14. Use for WSMO • More in-depth study of process algebras (CCS, CSP, etc. and their use for modeling choreographies!) • Use case modeling necessary, the examples here can serve as a starting point • First steps in the direction of process mediation (mediators including dynamics)