Streaming Services in SSCC

1
Streaming Services in SSCC
Ivan Lanese Computer Science Department University
of Bologna Italy
Joint work with Francisco Martins, Vasco
Vasconcelos and Antonio Ravara Univerisities of
Lisbon, Portugal
2
Roadmap

• Stream SCC syntax and semantics
• SSCC vs SCC
• A simple type system
• Some conclusions

3
Roadmap

• Stream SCC syntax and semantics
• SSCC vs SCC
• A simple type system
• Some conclusions

4
Idea of the calculus

• SCC not easy to use
• Main problems related to interactions among
  different services
• Looking for a simpler to use variant
• Main idea adding a dedicated construct (stream)
  for orchestrating different services
• Should be general enough to program different
  interactions
• Allows to simplify service invocation
• No more need for a process producing values
• Other differences non persistent service
  definitions
• Recursion to make them persistent

5
SSCC syntax
6
SSCC services

• Services are defined by their name a and their
  protocol P
• Service definition and service invocation are
  symmetric
• Invocations and definitions interact by producing
  sessions executing their protocol
• Sessions are not available when programming
• Only runtime construct

7
SSCC conversations

• Sessions can exchange information via concretion
  and abstraction as in SCC
• We can imagine to extend conversations with
  constructs taken from other works on sessions
  (e.g., choice)

8
Orchestrating SSCC services

• Many services concurrently executing in a system
• Data from one service used by other services
• Need for inter-service communication primitives
• Difficult tradeoff
• Expressive primitives for modeling different
  coordination patterns
• SCC return not expressive enough
• Constrained primitives to induce a structured
  form of programming and help typing and analysis
• p-calculus channels not structured enough
• We propose the stream construct
• Induce a clear style of programming

9

• P and Q are concurrently executing
• f is the name of a communication stream from P to
  Q
• Two possible semantics f ordered or unordered
• P can feed values inside f (feed v.P)
• Non blocking
• Values stored in f
• Q can read values from f (f(x).Q)
• Blocking
• Reads from stream f
• Possible to read from multiple named sources

10
A working stream

• Q is blocked, P can execute
• Now Q can execute too
• P1 is still enabled

11
Some programming patterns
12
Roadmap

• Stream SCC syntax and semantics
• SSCC vs SCC
• A simple type system
• Some conclusions

13
Chaining services

• In SCC if a returns many values then many
  instances of b are executed
• No easy way to avoid this
• Full control in SSCC
• Also, slightly changing the specific

14
Synchronization (Workflow Pattern 3)

• Auxiliary session (or service) required in SCC

15
While (part of Workflow Pattern 10)

• The two definitions of IfSignal are almost
  identical

16
Asking two services in parallel

• Ask for flight and hotel in parallel and give
  back the flight first and then the hotel
• In SCC the two values are obtained in different
  subsessions
• Returning them would mix the two
• Either add some information to the value
• Or synchronize the two sessions
• I have no idea about other solutions
• Naming streams is important

17
Merging two streams

• EATCS and EAPLS return streams
• of conference announcements
• I want an email for each announcement
• The two services (EATCS and EAPLS) have had to be
  modified to send the results via pub
• Recursion is important

18
Differences

• Main difference stream vs return
• Stream is orthogonal w.r.t. the session structure
  (which becomes transparent)
• Values returned where they are needed
• More compositional (more easy to add macros)
• Streams have a name
• Different sources of data can be distinguished
• Other things are less important and orthogonal
• Recursion
• Persistent vs non-persistent service definitions

19
Expressiveness issues

• Most of the things can be expressed in both the
  formalisms
• Some complex examples in SCC are not manageable
• SSCC allows a more clear programming style
• No auxiliary sessions or services

20
Roadmap

• Stream SCC syntax and semantics
• SSCC vs SCC
• A simple type system
• Some conclusions

21
Idea of the type system

• Simple type system
• Checks that data are used in the right way
• Integer output never matched by unit input
• Checks protocol compatibility
• For each input there is the corresponding output
• Ensures that protocols are sequential
• Good progamming style
• Facilitates the checking for protocol
  compatibility

22
Type system

• Types for values
• Unit, Int, Basic types
• U Service types
• Protocols
• ?T.U Input
• !T.U Output
• end End of protocol
• X Variable
• rec X.U Recursive types
• Processes typed as
• G set of assumptions, U protocol, T type of the
  fed stream
• Sessions typed as services, and stream as T
  where T is the type of the transmitted values

23
Typed examples
24
Roadmap

• Stream SCC syntax and semantics
• SSCC vs SCC
• A simple type system
• Some conclusions

25
What else exists on SSCC

• Reduction and LTS semantics
• Correspondence result
• The implementation of all the van der Aalst
  Workflow Patterns not requiring killing abilities
• A subject reduction result for the type system

26
Conclusions

• We think that SSCC is an improvement w.r.t. SCC
  from the usability point of view
• SSCC deals with services conversations
  coordination

27
Future work

• More complex type systems
• Deadlock avoidance
• Many possible causes of deadlock
• Protocols not compatible
• Empty stream
• Service not available (or not invoked)
• Mix of previous reasons
• Kill primitive
• The approach from SCC can be imported
• Is it the right one?

28
End of talk

• Thanks!

• Questions?