Analyzing Interactions of Asynchronously Communicating Software Components

1. Analyzing Interactions of Asynchronously Communicating Software Components Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan

2. Acknowledgements • Collaborators: • Xiang Fu, Hofstra University, USA • Jianwen Su, University of California, Santa Barbara, USA • Rick Hull, IBM TJ Watson, USA • Aysu Betin Can, Middle East Technical University, Turkey • Zachary Stengel, Microsoft, USA • Chris Ferguson, Active Network, USA • Gwen Salaun, Inria, France • Sylvain Halle, University du Quebec a Chicoutimi, Canada • Samik Basu, Iowa State University, USA • Meriem Ouderni, INP-ENSEEIHT, France

3. Big Picture Motivation • All software is moving to the network • Mobile or Browser-based thin clients combined with servers hosted on the cloud are replacing desktop applications • More things are becoming programmable • Smart-phones and smart-TVs are already common • Smart-glasses, smart watches, programmable cars are soon to follow • More things are moving to the network • Internet of things is becoming a reality • you can control your lights with your smart-phone • Nowadays programmable things come with network connection • It seems like a good time to focus on specification and analysis of interactions of software systems that communicate over a network!

4. Motivation 1: Web Services • Web services support 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

5. 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

6. Orchestration vs Choreography Orchestration: 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 • From atomic services to stateful services • Web Services Business Process Execution Language (WS-BPEL) Choreography: Specify how the individual services should interact with each other. Find or construct individual services that follow this interaction specification • Global specification of interactions among services • Web Services Choreography Description Language (WS-CDL) 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

7. 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

8. Motivation 2: Singularity OS • Experimental OS developed by Microsoft Research to explore new ideas for operating system design • Key design principles: • Dependability • Security • Key architectural decision: • Implement a sealed process system • Software Isolated Processes (SIPs) • Closed code space (no dynamic code loading or code generation) • Closed object space (no shared memory) • Inter-process communication occurs via message passing over channels

9. Singularity Channels • Channels allow 2-Party asynchronous communication via FIFO message queues • Sends are non blocking • Receives block until a message is at the head of a receive queue • Each channel has exactly two endpoints • Type exposed for each endpoint (Exp and Imp) • Each endpoint owned by at most one process at any time • Owner of Exp referred to as Server • Owner of Imp referred to as Client

10. Channel Contracts • Written in Sing # • Contracts specify two things: • The messages that may be sent over a channel • out message are sent from the Server endpoint to the Client endpoint (SC) • in messages are sent from the Client endpoint to the Server endpoint (CS) • The set of allowed message sequences • out message marked with ! • in messages marked with ? publiccontract KeyboardDeviceContract { outmessage AckKey( uint key ); outmessage NakKey(); outmessage Success(); inmessage GetKey(); inmessage PollKey(); state Start { Success! -> Ready; } state Ready { GetKey? -> Waiting; PollKey? -> (AckKey! or NakKey!) -> Ready; } state Waiting { AckKey! -> Ready; NakKey! -> Ready; } }

11. Channel Contracts as State Machines • A contract specifies a finite state machine • Each message causes a deterministic transition from one state to another state KeyboardDeviceContract publiccontract KeyboardDeviceContract { outmessage AckKey( uint key ); outmessage NakKey(); outmessage Success(); inmessage GetKey(); inmessage PollKey(); state Start { Success! -> Ready; } state Ready { GetKey? -> Waiting; PollKey? -> (AckKey! or NakKey!) -> Ready; } state Waiting { AckKey! -> Ready; NakKey! -> Ready; } } Start SC:AckKey SC:AckKey SC:Success Implicit State CS:PollKey CS:GetKey Waiting Ready Ready$0 SC:AckKey SC:NakKey

12. Motivation 3: Erlang and UBF(B) • Erlang is a general purpose programming language developed initially at Ericsson for improving dependability of telephony applications • In Erlang distributed processes do not share memory and only interact with each other via exchanging messages asynchronously • UBF(B) is a language for specifying communication contracts in distributed Erlang programs. • UBF(B) specifications list transitions between states where each transition is identified with a request (the message received) and response (the message sent) +NAME(“IRC SERVER”) ... +STATE start logon() => ok() & active | error() & stop +STATE active ls() => files() & active getFile() => fileSent() & active | noFileErr() & stop ...

13. UBF(B) Specifications as State Machines +NAME(“IRC SERVER”) ... +STATE start logon() => ok() & active | error() & stop +STATE active ls() => files() & active getFile() => fileSent() & active | noFileErr() & stop ... start CS:logon SC:ok SC:error stop active CS:ls CS:getfile SC:noFileErr SC:files SC:fileSent

14. Motivation 4: UML Collaboration Diagrams must precede sequence label :Customer message 1/A1:fligtInquiry :Airline A2,B2/2:reply 1:reserve A2:flightAvailability :TravelAgency 1/B1:roomInquiry :Hotel B2:roomAvailability

15. Motivation 4: Collaboration Diagrams • Messages are ordered based on two rules • Implicit: The sequence labels that have the same prefix must be ordered based on their sequence number • Explicit: The events listed before “/” must precede the current event Initial message 1:reserve 1/A1:flightInquiry 1/B1:roomInquiry B2:roomAvailability A2:flightAvailability A2,B2/2:reply Final message

16. Collaboration Diagrams as State Machines CTA: reserve TA A: flightInquiry TAH: roomInquiry TA A: flightInquiry TAH: roomInquiry ATA: flightAvailability HTA: roomAvailability ATA: flightAvailability HTA: roomAvailability TAH: roomInquiry TA A: flightInquiry HTA: roomAvailability ATA: flightAvailability TAC: reply

17. Common: Specification of Conversations • Specifications of message-based communication • Web Service Choreography Specifications: Global specification of interactions for composition of services • Singularity Channel Contracts: Coordinating inter-process communication in Singularity OS • Erlang Communication Contracts: Coordinating interactions among distributed processes • UML Collaboration diagrams: Specifying interactions among components • All these specifications can be modeled as state machines and they all specify sequences of sent messages (aka, conversations): Conversation: A sequence of messages sent during an execution Conversation Protocol (aka Choreography): A state machine that specifies a set of conversations

18. Common: Asynchronous Messaging • Sender does not have to wait for the receiver • Message is inserted to a message queue • Messaging platform guarantees the delivery of the message • Why support asynchronous messaging? • Otherwise the sender has to block and wait for the receiver • Sender may not need any data to be returned • If the sender needs some data to be returned, it should only wait when it needs to use that data • Asynchronous messaging can alleviate the latency of message transmission through the Internet • Asynchronous messaging can prevent sender from blocking if the receiver service is temporarily unavailable • Rather then creating a thread to handle the send, use asynchronous messaging

19. Example Singularity Channel Contract • Each contract state machine specifies a set of conversations, i.e., it is a conversation protocol: KeyboardDeviceContract Start SC:AckKey SC:AckKey SC:Success CS:PollKey CS:GetKey Waiting Ready Ready$0 SC:NakKey SC:NakKey Conversation set: Success(GetKey(AckKey|NakKey)|PollKey(AckKey|NakKey))*

20. Outline • Motivation • Composition of Web Services • Singularity Channel Contracts • Conversations • Realizability • Synchronizability • Applications • Conclusions

21. Going to Lunch at UCSB • At UCSB Samik, Meriem and I were using the following protocol for going to lunch: • Sometime around noon one of us would call another one by phone and tell him/her where and when we would meet for lunch. • The receiver of this first call would call the remaining peer and pass the information. • Let’s call this protocol the First Caller Decides (FCD) protocol. • At the time we did not have answering machines or voicemail due to budget cuts at UC!

22. FCD Protocol Scenarios • Possible scenario • Tevfik calls Samik with the decision of where and when to eat • Samik calls Meriem and passes the information • Another scenario • Samik calls Tevfik with the decision of where and when to eat • Tevfik calls Meriem and passes the information • Yet another scenario • Tevfik calls Meriem with the decision of where and when to eat • Maybe Samik also calls Meriem at the same time with a different decision. But the phone is busy. • Samik keeps calling. But Meriem is not going to answer because according to the protocol the next thing Meriem has to do is to call Samik. • Meriem calls Samik and passes the information

23. FCD Protocol: Tevfik’s Behavior Let’s look at all possible behaviors of Tevfik based on the FCD protocol Tevfik is hungry Tevfik receives a call from Samik passing him the lunch decision Tevfik calls Samik with the lunch decision Tevfik receives a call from Meriem passing him the lunch decision Tevfik calls Meriem with the lunch decision Tevfik receives a call from Meriem telling him the lunch decision that Tevfik has to pass to Samik

24. FCD Protocol: Tevfik’s Behavior T->S:D Message Labels: Tevfik calls Samik with the lunch decision !send ?receive S->M:P Samik calls Meriem to pass the decision !T->S:D ?S->T:P ?M->T:P !T->M:D ?M->T:D ?S->T:D !T->M:P !T->S:P

25. State machines for the FCD Protocol • Three state machines characterizing the behaviors of Tevfik, Meriem and Samik according to the FCD protocol Tevfik Meriem Samik ?T->S:P ?S->T:P !S->T:D ?S->M:P !M->S:D !T->S:D ?T->M:P ?M->T:P !M->T:D !T->M:D ?M->S:P !S->M:D ?M->T:D ?S->M:D ?T->M:D ?S->T:D ?T->S:D ?M->S:D !M->S:P !M->T:P !T->S:P !S->M:P !S->T:P !T->M:P

26. FCD Protocol Has Voicemail Problems • After the economy started to recover, the university installed a voicemail system FCD protocol started causing problems • We were showing up at different restaurants at different times! • Example scenario: • Tevfik calls Meriem with the lunch decision • Samik also calls Meriem with the lunch decision • The phone is busy (Meriem is talking to Tevfik) so Samik leaves a message • Meriem calls Samik passing the lunch decision • Samik does not answer (he already left for lunch) so Meriem leaves a message • Samik shows up at a different restaurant! • Message sequence is: T->M:D S->M:D M->S:P • The messages S->M:D andM->S:P are never consumed • This scenario is not possible without voicemail!

27. A Different Lunch Protocol • To fix this problem, I suggested that we change our lunch protocol as follows: • As the most senior researcher among us I would make the first call to either Meriem or Samik and tell when and where we would meet for lunch. • Then, the receiver of this call would pass the information to the other peer. • Let’s call this protocol the Tevfik Decides (TD) protocol

28. State machines for the TD Protocol • TD protocol works fine with voicemail! Meriem Tevfik Samik ?S->M:P ?M->S:P ?T->M:D ?T->S:D !T->S:D !T->M:D !S->M:P !M->S:P

29. A Model for Composition • A composition of services consists of • a finite set of peers • Lunch example with three peers: T, S, M • and a finite set of messages • Lunch example (TD protocol) with four messages T->S(D), T->M(D), S->M(P), M->S(P) S->M(P) Peer S Peer M M->S(P) T->A(D) T->M(D) Peer T

30. Communication Model • We assume that the messages among the peers are exchanged using reliable and asynchronous messaging • FIFO and unbounded message queues Peer T Peer S T->S(D) T->S(D) • There are existing messaging platforms that support this type of messaging • Java Messaging Service (JMS) • Java API for XML messaging (JAXM) • MSMQ (Microsoft Message Queuing Service)

31. Conversations S->M(P) T->S(D) • Record the messages in the order they are sent Peer S Peer M Generated conversation: T->S(D) S->M(P) Peer T • A conversation is a sequence of messages generated during an execution

32. Properties of Conversations • The notion of conversation enables us to reason about temporal properties of the composite services • LTL framework extends naturally to conversations • LTL temporal operators X (neXt), U (Until), G (Globally), F (Future) • Atomic properties Predicates on message classes (or contents) Example: G ( payment F receipt) • Model checking problem: Given an LTL property, does the conversation set satisfy the property?

33. State machines for the FCD Protocol Tevfik Meriem Samik ?T->S:P ?S->T:P !S->T:D ?S->M:P !M->S:D !T->S:D ?T->M:P ?M->T:P !M->T:D !T->M:D ?M->S:P !S->M:D ?M->T:D ?S->M:D ?T->M:D ?S->T:D ?T->S:D ?M->S:D !M->S:P !M->T:P !T->S:P !S->M:P !S->T:P !T->M:P

34. State machines for the TD Protocol Meriem Tevfik Samik ?S->M:P ?M->S:P ?T->M:D ?T->S:D !T->S:D !T->M:D !S->M:P !M->S:P

35. FCD and TD Conversation Protocols TD Protocol FCD Protocol T->M:D S->M:D T->S:D T->M:D M->S:D M->T:D T->S:D S->T:D S->M:P T->S:P T->M:P S->T:P M->S:P S->M:P M->T:P M->S:P Conversation set: { T->M:D M->S:P, T->S:D S->M:P, M->T:D T->S:P, M->S:D S->T:P, S->T:D T->M:P, S->M:D M->T:P } Conversation set: { T->S:D S->M:P, T->M:D M->S:P }

36. Conversations, Choreography, Orchestration • Peer state machines are orchestrations • A peer state machine can be specified using an orchestration language such as WS-BPEL • One can translate WS-BPEL specifications to peer state machines • A conversation protocol is a choreography specification • A conversation set corresponds to a choreography • A conversation set can be specified using a choreography language such as WS-CDL • One can translate WS-CDL specifications to conversation protocols

37. Observations & Questions • The implementation of the FCD protocol behaves differently with synchronous and asynchronous communication whereas the implementation of the TD protocol behaves the same. • Can we find a way to identify such implementations? • The implementation of the FCD protocol does not obey the FCD protocol if asynchronous communication is used whereas the implementation of the JD protocol obeys the JD protocol even if asynchronous communication used. • Given a conversation protocol can we figure out if there is an implementation which generates the same conversation set?

38. Bottom-Up vs. Top-Down Bottom-up approach • Specify the behavior of each peer • For example using an orchestration language such as WS-BPEL • The global communication behavior (conversation set) is implicitly defined based on the composed behavior of the peers • Global communication behavior is hard to understand and analyze Top-down approach • Specify the global communication behavior (conversation set) explicitly as a protocol • For example using a choreography language such as WS-CDL • Ensure that the conversations generated by the peers obey the protocol

39. Top-Down vs. Bottom-Up Verification T->S:D T->M:D Conversation Protocol (Choreography Specification) LTL property ? F(S->M:P  M->S:P) S->M:P M->S:P Peer T Peer X Peer J Input Queue !T->S:D ?M->S:P ?S->M:P ?T->M:D ?T->S:D !T->M:D !S->M:P !M->S:P ... ? Conversation F(S->M:P  M->S:P) LTL property

40. Outline • Motivation • Composition of Web Services • Singularity Channel Contracts • Conversations • Realizability • Synchronizability • Applications • Conclusions

41. Realizability • Conversation protocols identify the global communication behavior • How do we implement processes that conform to the conversation protocol? • Realizability question: • Given a conversation protocol, are there processes whose communication behavior in terms of conversations (i.e., send sequences) is equal to the set of conversations (i.e., send sequences) specified by the conversation protocol? • The FCD protocol is unrealizable • The TD protocol is realizable ? Conversations specified by the conversation protocol Conversations generated by some processes 

42. Unrealizable Conversation Protocols • Three unrealizable conversation protocols: BA:m2 AB:m1 AB: m1 AB: m1 BA:m2 AB:m1 CD: m2 CA: m2 AC:m3

43. Unrealizable Examples • This protocol is unrealizable both for synchronous and asynchronous communication! AB: m1 !m2 ?m2 ?m1 !m1 CD: m2 Peer A Peer B Peer C Peer D Conversation protocol Projections of the protocol to the processes Conversation “m2 m1” will be generated by all implementations which follow the protocol

44. Unrealizable Examples • This protocol is realizable with synchronous communication but unrealizable with asynchronous communication! AB: m1 !m1 !m2 ?m1 CA: m2 ?m2 Peer B Peer C Conversation protocol Peer A Projections of the protocol to the processes Conversation “m2 m1” will be generated by all implementations which follow the protocol

45. Unrealizable Examples Conversation: A B A, C m2 m2 m1 BA:m2 AB:m1 m3 B m1 BA:m2 C m3 AB:m1 AC:m3 m2 m1 m3 Generated conversation:

46. Challenges • Finite state processes that communicate with FIFO message queues can simulate Turing Machines • In general analyzing properties of asynchronously communicating finite state machines is undecidable • For example, checking conformance to a conversation protocol is undecidable

47. Sufficient Conditions for Realizability Three conditions • Lossless join • Synchronous compatible • Autonomous Together they are sufficient conditions for realizability

48. Sufficient Conditions for Realizability • Lossless join • Conversation set should be equivalent to the join of its projections to each peer Conversation set: {m1m2} Projection to A: {!m1} Projection to B: {?m1} Projection to C: {!m2} Projection to D: {?m2} Join of the projections: {m1m2, m2m1} Not equal to the conversation set! AB: m1 CD: m2 This protocol is not lossless join

49. Sufficient Conditions for Realizability • Synchronous compatible • When the projections are composed synchronously, there should not be a state where a peer is ready to send a message while the corresponding receiver is not ready to receive C is ready to send but A is not ready to receive !m1 AB: m1 !m2 ?m1 ?m2 CA: m2 Peer B Peer C Peer A Conversation protocol This protocol is not synchronous compatiable

50. Sufficient Conditions for Realizability • Autonomous • At any state, each peer should be able to do only one of the following: send, receive or terminate (a peer can still choose among multiple messages) A has both a send and a receive transition from this state (B also has both send and receive transitions) BA:m2 AB:m1 BA:m2 AB:m1 AC:m3 This protocol is not autonomous