Modeling and Implementing Conversational Web Services using SOAP - PowerPoint PPT Presentation

1 / 17
About This Presentation
Title:

Modeling and Implementing Conversational Web Services using SOAP

Description:

A number of messages sent between the client and server... If messages depend on each other we must remember the messages we have seen so far ... – PowerPoint PPT presentation

Number of Views:20
Avg rating:3.0/5.0
Slides: 18
Provided by: johant2
Category:

less

Transcript and Presenter's Notes

Title: Modeling and Implementing Conversational Web Services using SOAP


1
Modeling and Implementing Conversational Web
Services using SOAP
  • Johan Tibell

2
Two examples
  • Airline ticketing
  • On-line store

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

4
A conversation looks like...
  • Requests and responses
  • Notifications
  • Role reversals
  • Polling is inefficient
  • Use push

5
Difficulties
  • 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

6
First 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) / ... /

7
Code smells
  • Complicated control flow
  • Hard to extend
  • Is it correct?
  • Have we covered all possible cases?
  • Are all timers started and stopped correctly?

8
Clients state machine
created
(out, start)
(out, request)
waiting
ready
terminated
(out, terminate)
(in, response)
(out, notification)
9
Convert 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

10
Converted 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) / ..
    /

11
Timers
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
12
Same 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) / ..
    /

13
Proving 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

14
Proving 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

15
Proving 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

16
Conclusion
  • 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

17
Bonus formal definition
Write a Comment
User Comments (0)
About PowerShow.com