Title: Modeling and Implementing Conversational Web Services using SOAP
1Modeling and Implementing Conversational Web
Services using SOAP
2Two examples
- Airline ticketing
- On-line store
3A conversation is...
- A number of messages sent between the client and
server... - ...where each message depends on the previous,
and - some context is kept during the communication.
4A conversation looks like...
- Requests and responses
- Notifications
- Role reversals
- Polling is inefficient
- Use push
5Difficulties
- If messages depend on each other we must remember
the messages we have seen so far - Cover all valid message sequences
- Reject the rest
- Resource management
- Start and terminate messages
- Use timeouts to avoid resource leaks
- Timeouts are also needed to enforce other
requirements
6First attempt
- if (outgoing)
- // do stuff
- if (messageType REQUEST
- !waitingForReply)
- // stop activity timer
- // start reply timer
- waitingForReply true
- else if (messageType REQUEST)
- // raise an error
-
- // many more message types and cases
-
- if (incoming) / ... /
7Code smells
- Complicated control flow
- Hard to extend
- Is it correct?
- Have we covered all possible cases?
- Are all timers started and stopped correctly?
8Clients state machine
created
(out, start)
(out, request)
waiting
ready
terminated
(out, terminate)
(in, response)
(out, notification)
9Convert to code automatically
- Map each state to a class using the state pattern
- Create one parent class, ConversationState
- Create one child for each state Ready, Waiting,
etc. - Generate two transition functions, one for
incoming and one for outgoing messages
10Converted to state pattern
- class Ready extends ConversationState
- ConversationState outgoing(Message m)
- if (m.isRequest())
- return new Waiting()
- if (m.isNotification())
- return new Ready()
- if (m.isTerminate())
- return new Terminated()
- throw new IllegalStateException()
-
- ConversationState incoming(Message m) / ..
/
11Timers
start t1
stop t1, start t1 (out, start)
stop t1, start t2 (out, request)
stop t1 (out, terminate)
stop t2, start t1 (in, response)
stop t1, start t1 (out, notification)
t1 activity timer t2 reply timer
12Same idea as before
- class Ready extends ConversationState
- ConversationState outgoing(Message m)
- if (m.isRequest())
- stopTimer(ACTIVITY) startTimer(REPLY)
- if (m.isNotification())
- stopTimer(ACTIVITY) startTimer(ACTIVITY)
- if (m.isTerminate())
- stopTimer(ACTIVITY)
- // transitions as before
-
- ConversationState incoming(Message m) / ..
/
13Proving an interesting property
- The model is timer safe if, for all possible
message sequences, all timers are stopped when
the conversation has terminated - Quite easy to convince oneself that this small
example is correct - Real model has 8 states and 17 transitions
14Proving an interesting property
- Idea Keep track of the set of currently running
timers and make sure it is empty in the end - The function a(q,w) is the set of running timers
after starting in state q and reading a sequence
w of messages - Show that a(qstart,w) for all valid message
sequences w
15Proving an interesting property
- a is defined recursively in terms of the timers
that are started and stopped in each transition - The proof is just a few lines for the 8-state
model in my thesis
16Conclusion
- A model allows reasoning about interesting
aspects of a program without having to deal with
implementation details - It can be used to automatically generate code
- Possible to prove interesting properties
17Bonus formal definition