Formal Modeling & Verification of Web Services

1. CS 290C: Formal Models for Web Software Lectures 11 and 12: Formal Modeling and Verification of Web Services, Orchestration and ChoreographyInstructor: Tevfik Bultan

2. Web Revolution • Sharing information using Internet has been a big success • Key components • Internet • Internet protocols such as TCP/IP • WWW and HTTP • HTML format • Web browsers • Sharing information using the http+html+browser framework has been successful in a lot of applications • List your favorite web sites here

3. What Next? • There are applications where http+html+browser framework does not work • Business to business applications • HTML is developed for displaying information in a way that is understandable for humans • HTML is not very useful in helping computers understand the content • Basic Question Can we extend the interaction and sharing that WWW created among humans to interaction and sharing among services where the services share information and collaborate using the Internet?

4. More Questions • What should be the format that the services share the information? • How will the information format be defined? • What protocol will the computers use to send and receive information? • How can a computer find out about the information provided by another computer? • How can we describe the interaction among multiple computers?

5. Some Proposed Answers • What should be the format that the services share the information? • XML • How will the information format be defined? • XML Schema • What protocol will the services use to send and receive information? • SOAP • How can a service find out about the information provided by another service? • WSDL, UDDI • How can we describe the interaction among multiple services? • BPEL, WS-CDL

6. Web Services Standards Stack WS-CDL Choreography WS-BPEL Orchestration WSDL, UDDI Service Implementation Platforms Microsoft .Net, Sun J2EE SOAP Protocol XML Schema Type XML Data Web Service Standards

7. What are Web Services? • Web services can be described as • web accessible software that provide interfaces for • service description, • discovery, and • interaction

8. Web Services: Challenges • Web services implemented using different implementation platforms should be able to interact with each other • There are different implementation platforms such as .Net or J2EE • It should be possible to modify an existing web service without modifying other services that interact with it • Web services should be able tolerate pauses in availability of other services and slow data transmission

9. Web Services: Challenges Can’t we solve these challenges with existing technologies? • Existing technologies for distributed computing such as CORBA and RMI require tight coupling among applications • It is not possible to specify interactions among services using stateless protocols

10. Web Services: Characteristics Web services address these challenges with the following common characteristics: • Standardized data transmission via XML • Loose coupling among interacting web services through standardized interfaces • Message based communication

11. Web Services • The World Wide Web Consortium (W3C) defines a Web service as • "a software system designed to support interoperable machine-to-machine interaction over a network” • The basic architecture Service Broker Search Register Request Service Provider Service Requester Response

12. Web Services Standards Stack Universal Description, Discovery & Integration (UDDI) Registry Service Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Protocol XML Schema (XSD) Type Extensible Markup Language (XML) Data Service Broker UDDI Register Search WSDL WSDL Request Service Provider Service Requester SOAP Response

13. Web Services Characteristics/Goals • Interoperability • Platform independent (.NET, J2EE) • Service interactions across organizational boundaries • Loose coupling • Standardized data transmission via XML • Interaction based on standardized interfaces such as WSDL • Communication via messages • Synchronous and asynchronous messaging

14. Basic Usage of Web Services • What we have so far supports basic client/server style interactions • Example: Amazon E-Commerce Web Service (AWS-ECS) • AWS-ECS WSDL specification lists 40 operations that provide differing ways of browsing Amazon’s product database such as • ItemSearch, CartCreate, CartAdd, CartModify, CartGet, CartClear • Based on the AWS-ECS WSDL specification one can implement clients that interact with AWS-ECS WSDL Request Service Provider Service Requester SOAP Response Server Client

15. Composing Services • Can this framework support more than basic client/server style interactions? • Can we compose a set of services to construct a new service? • For example: • If we are building a bookstore service, we may want to use both Amazon’s service and Barnes & Noble’s service in order to get better prices • Another (well-known) example: • A travel agency service that uses other services (such as flight reservation, hotel reservation, and car rental services) to help customers book their trips

16. Composing Services Two dimensions: • Define an executable process that interacts with existing services and executes them in a particular order and combines the results to achieve a new goal • Orchestration: From atomic services to stateful services • Specify how the individual services should interact with each other. Find or construct individual services that follow this interaction specification • Choreography: Global specification of interactions among services

17. Orchestration vs. Choreography • Orchestration: Central control of the behavior of a distributed system • Like a conductor conducting an orchestra • Conductor is in charge during the performance • Orchestration specifies an executable process, identifying when and how that process should interact with other services • Orchestration is used to specify the control flow of a composite web service (as opposed to an atomic web service that does not interact with any other service)

18. Orchestration vs. Choreography • Choreography: Specification of the behavior of a distributed system without centralized control • Choreographer specifies the behavior of the dancing team • Choreographer is not present during the execution • A choreography specifies how the services should interact • It specifies the legal sequences of messages exchanged among individual services (peers) • It is not necessarily executable • A choreography can be realized by writing an orchestration for each peer involved in the choreography • Choreography as global behavior specification • Orchestration as local behavior specification that realizes the global specification

19. Orchestration with WS-BPEL • Web Services Business Process Execution Language (WS-BPEL) is an orchestration language • A WS-BPEL specification describes the execution logic using basic and structured activities • Basic activities: RECEIVE, REPLY, INVOKE, ASSIGN, THROW, TERMINATE, WAIT, EMPTY RECEIVE, REPLY, INVOKE • Structured activities: SEQUENCE, SWITCH, WHILE, PICK, FLOW, SCOPE, COMPENSATE • WS-BPEL supports messaging (RECEIVE, REPLY, INVOKE) and multi-threading (FLOW)

20. Choreography with WS-CDL • Web Services Choreography Description Language (WS-CDL) • WS-CDL specifications describe ``peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.'' • A WS-CDL specification describes the interaction ordering among a set of peers using basic and structured activities • Basic activities: INTERACTION, PERFORM, ASSIGN, SILENT ACTION, NO ACTION • Structured activities: SEQUENCE, PARALLEL, CHOICE, PICK, FLOW, SCOPE, COMPENSATE

21. Web Services Standards Stack Web Services Choreography Description Language (WS-CDL) Choreography Web Services Business Process Execution Language (WS-BPEL) Orchestration Service Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Protocol Type XML Schema (XSD) Extensible Markup Language (XML) Data WSDL WS-BPEL SOAP Atomic Service Orchestrated Service WS-CDL SOAP SOAP WS-BPEL WSDL Orchestrated Service SOAP Atomic Service SOAP

22. An Example: Stock Analysis Service The stock analysis service involves: • three peers Investor, Stock Broker Firm, and Research Department Here is how the stock analysis service operates: • Investor initiates the stock analysis service by sending a register message to the Stock Broker Firm • The Stock Broker Firm may accept or reject the registration • If the registration is accepted, the Stock Broker Firm sends an analysis request to the Research Department

23. An Example: Stock Analysis Service • Research Department sends the results of the analysis directly to the Investor as a report • After receiving a report the Investor can either send an ack to the Stock Broker Firm or cancel the service • Then, the Stock Broker Firm either sends the bill for the services to the Investor, or continues the service with another analysis request

24. An Example: Stock Analysis Service (SAS) • SAS is a composite service that contains three individual services register ack, cancel Investor (Inv) Stock Broker (SB) accept, reject, bill report request, terminate Research Dept. (RD)

25. Stock Analysis Service Data port report() Investor Stock Broker Firm <invoke> IBlink: register() <receive> IBlink: register() Callback port Service Port <On Message> IBlink: accept() <invoke> IBlink: accept() reject() IBlink <invoke> IBlink: reject() <invoke> IBlink: ack() <invoke> BRlink: request() <On Message> IBlink: reject() register() accept() <receive> RIlink: report() cancel() <receive> IBlink: ack() <receive> RIlink: bill() <invoke> RIlink: bill() bill() ack() <receive> IBlink: cancel() <invoke> IBlink: cancel() <invoke> RIlink: bill() <receive> RIlink: bill() Delegate Port Research Dept. RIlink BRlink Output Port Service Port <receive> BRlink: request() request() <invoke> RIlink: report()

26. Stock Analysis Service • In the following slides I will discuss how different parts of the stock analysis service can be described using emerging web service standards • Message contents: XML • Message type: XML Schema • Message ports: WSDL • Behavior: BPEL

27. XML (eXtensible Markup Language) • XML is a markup language like HTML • Similar to HTML, XML tags are written as <tag> followed by </tag> • HTML vs. XML • In HTML, tags are used to describe the appearance of the data <b> </b> <i> </i> <br> <p> ... • In XML, tags are used to describe the content of the data rather than the appearance <date> </date> <address> </address> • XML documents can be modeled as trees where each internal node corresponds to a tag and leaf nodes correspond to basic types

28. An XML Document and Its Tree Register requestList investorID payment 1234 stockID stockID accountNum AAAA BBBB 56 <Register> <investorID> 1234 </investorID> <requestList> <stockID> AAAA </stockID> <stockID> BBBB </stockID> </requestList> <payment> <accountNum> 56 </accountNum> </payment> </Register>

29. XML Schema • XML provides a standard way to exchange data over the internet. • However, the parties which exchange XML documents still have to agree on the type of the data • what are the tags that will appear in the document, in what order, etc. • XML Schema is a language for defining XML data types

30. MSL (Model Schema Language) • MSL (Model Schema Language) is a compact formal model language which captures most features of XML Schema • Basic MSL syntax g  | b | t[g ] | g{m ,n } | g,g | g&g | g|g g is an XML type (i.e., an MSL type expression)  is the empty sequence b is a basic type such as string, boolean, int, etc. t is a tag m and n are positive integers [ ] { } & , | are MSL type constructors

31. MSL Semantics • t[g ] denotes a type with root node labeled t with children of type g • g{m ,n } denotes a sequence of size at least m and at most n where each member is of type g • g1,g2 denotes an ordered sequence where the first member is of type g1 and the second member is of type g2 • g1&g2 denotes an unordered sequence where one member is of type g1 and the other member is of type g2 • g|g denotes a choice between type g1 and type g2, i.e., either type g1 or type g2, but not both

32. An MSL Type Declaration and an Instance <Register> <investorID> 1234 </investorID> <requestList> <stockID> AAAA </stockID> <stockID> BBBB </stockID> </requestList> <payment> <accountNum> 56 </accountNum> </payment> </Register> Register[ investorID[xsd:int] & requestList[ stockID[xsd:string]{1,50} ] & payment[ creditCardNum[xsd:int] | accountNum[xsd:int] ] ]

33. An MSL Type Declaration and an Instance Register requestList investorID payment 1234 stockID stockID accountNum AAAA BBBB 56 MSL can also be used as a compact language for specifying data instances Register[ investorID[1234] & requestList[ stockID[AAAA] , stockID[BBBB] ] & payment[ accountNum[56] ] ]

34. XPath • In order to write specifications or programs that manipulate XML documents we need: • an expression language to access values and nodes in XML documents • XPath is a language for writing expressions (queries) that navigate through XML trees and return a set of answer nodes • An XPath query defines a function which • takes and XML tree and a context node (in the same tree) as input and • returns a set of nodes (in the same tree) as output

35. XPath Syntax Basic XPath syntax: q . | .. | b | t | * | /q | //q | q/q | q//q | q [ q ] | q [exp] q is an XPath query exp denotes a predicate on basic types, i.e., on the leaf nodes of the XML tree b denotes a basic type such as string, boolean, int, etc. t denotes a tag

36. XPath Semantics Given an XML tree and a node n as a context node . returns n ..returns the parent of n Given an XML tree and a set of nodes * returns all the nodes b returns the nodes that are of basic type b t returns the nodes which are labeled with tag t

37. XPath Semantics Contd. Starting at the context node • /q returns the nodes that match q • //q returns the nodes that match q starting at any descendant • q1/q2 returns each node which matches q2 starting at a child of a node which matches q1 • q1//q2 returns each node which matches q2 starting at a descendant of a node which matches q1 • q1[ q2] applies q2 to the children of the nodes which match q1 • q [exp] returns the nodes that match q and for children of which the expression exp evaluates to true

38. Example XPath Queries Register requestList investorID payment 1234 stockID stockID accountNum AAAA BBBB 56 //payment/* returns the node labeled accountNum /Register/requestList/stockID/string returns the nodes labeledAAAA and BBBB //stockID[string=AAAA]/string returns the node labeled AAAA //*[int>100]/int returns the node labeled 1234

39. WSDL (Web Services Description Language) • WSDL is an XML-based language used to declare and publish the public interfaces of Web services • With the WSDL description, the invoker of a particular web service can learn about • the web service location • the calls supported by the web service • the format of the messages to place a call • WSDL uses XML Schema to define message types • Contents of the messages are XML documents • WSDL specifications declare message ports • input ports, output ports etc.

40. WSDL Example: Declaring Message Types <definitions targetNamesspace = "http://..." xmlns:broker = "http://.../broker/broker.xsd"> <message name = "Register"> <part name = "investorID" type="xsd:int"/> <part name = "requestList" type ="broker:RequestList"> <part name = "payment" type="broker:Payment"> </message> <message name = "Accept"> <part name = "investorID" type="xsd:string"/> <part name = "registerID" type="xsd:int"/> </message> <message name = "Request"> <part name = "investorID" type="xsd:string"/> <part name = "registerID" type ="xsd:int"/> <part name = "stockID" type ="xsd:string"/> </message> ...

41. WSDL Example: Declaring Message Types The following is a paragraph taken from broker.xsd used in the Register declaration in the previous slide <xsd:schema xmlns:xsd = "http://.../XMLSchema"> <xsd:complexType name = "RequestList"> <xsd:element name = "stockid" type="string" minOccurs="1" maxOccurs="10"/> </xsd:complexType>

42. WSDL Example: Declaring Message Ports <portType name = "BrokerService"> <operation name = "register"> <input message = "Register"> </operation> <operation name = "cancel"> <input message = "Cancel"> </operation> <operation name = "ack"> <input message = “Ack"> </operation> </portType> ... <binding name = "brokerServiceBinding" type="BrokerService"> <soap:binding stype="document" /> </binding> <service name= "StockBroker"> <port name = "toInvestor" binding = "brokerServiceBinding"> <soap:address location="http://broker.com/register"/> </port> </service>

43. Stock Analysis Service Data port report() Investor Stock Broker Firm <invoke> IBlink: register() <receive> IBlink: register() Callback port Service Port <On Message> IBlink: accept() <invoke> IBlink: accept() reject() IBlink <invoke> IBlink: reject() <invoke> IBlink: ack() <invoke> BRlink: request() <On Message> IBlink: reject() register() accept() <receive> RIlink: report() cancel() <receive> IBlink: ack() <receive> RIlink: bill() <invoke> RIlink: bill() bill() ack() <receive> IBlink: cancel() <invoke> IBlink: cancel() <invoke> RIlink: bill() <receive> RIlink: bill() Delegate Port Research Dept. RIlink BRlink Output Port Service Port <receive> BRlink: request() request() <invoke> RIlink: report()

44. BPEL (Business Process Execution Language) • The simple function call model employed by WSDL makes it hard to capture long running complex composite web services such as the stock analysis service • the ordering between the calls can not be expressed • The control flow (i.e., the behavior) of the peers of the stock analysis service can be specified using BPEL

45. BPEL: Partner Links • In the BPEL specification, first a set of partner-links are declared • The partner links for the example in the stock analysis service are named IBLink, BRLink and RLink • Each partner link connects a pair of port declared in the WSDL specification • After the declaration of the partner links, BPEL specification for each peer includes the control flow of the corresponding peer with the associated receive and send operations through the partner links and WSDL ports

46. BPEL: Partner Links <process name = "StockBrokerFirm"> <partnerlinks> <partnerlink name = "IBlink" ... /> <partnerlink name = "BRlink" ... /> <partnerlinks> <variables> <variable name = "registerVar" messageType = "Register"/> ... </variables>

47. BPEL: Control Flow • BPEL borrows many control structures from common programming languages, such as • sequence, while, switch, etc. • The atomic operations in BPEL are • invoke, receive, and reply • used for sending and receiving messages; and • assign • used for updating values of the variables. • Since assignments are conducted on complex type variables (WSDL messages declared as XML Schema types), BPEL supports XPath expressions to identify the sources and the destinations of the assignments statements.

48. BPEL: Control Flow <sequence> <receive partnerlink = "IBlink“ operation = "register“ variable = "registerVar"> </receive> <assign> <copy> <from variable = "registerVar“ part = "investorID"/> <to variable = "acceptVar“ query = "//investorID"/> </copy> </assign> <switch> <case condition = "opaque"> ... </case> ... <while condition = "bCond"> <invoke partnerlink = "BRlink" operation = "request“ variable = "requestVar" > </invoke> </while> ... </switch> ... </sequence>

49. Formal Modeling and Verification of Web services • There has been a lot of work on modeling and verification of web services • These efforts mostly focused on analyzing composite services specified using orchestration and choreography languages • For example, can we formally model a given BPEL specification and automatically verify its properties • I will give an overview of a tool we built for BPEL verification called Web Service Analysis Tool (WSAT)

50. Web Service Analysis Tool (WSAT) Verification Languages WebServices Front End Analysis Back End Intermediate Representation GFSA to Promela (synchronous communication) success BPEL to GFSA SynchronizabilityAnalysis Guarded automata BPEL fail (bottom-up) GFSA to Promela (bounded queue) Promela skip GFSA parser Conversation Protocol Guarded automaton success GFSA to Promela(single process, no communication) Realizability Analysis (top-down) fail http://www.cs.ucsb.edu/~su/WSAT/ [Fu, Bultan, Su CAV’04]