1 Ivan Lanese Computer Science Department University of Bologna Italy Streaming Services in SSCC...
-
date post
15-Jan-2016 -
Category
Documents
-
view
223 -
download
0
Transcript of 1 Ivan Lanese Computer Science Department University of Bologna Italy Streaming Services in SSCC...
1
Ivan LaneseComputer Science Department
University of BolognaItaly
Streaming Services in SSCC
Joint work with Francisco Martins, Vasco Vasconcelos and Antonio RavaraUniverisities of Lisbon, Portugal
Roadmap
Stream SCC: syntax and semantics
SSCC vs SCC
A simple type system
Some conclusions
Roadmap
Stream SCC: syntax and semantics
SSCC vs SCC
A simple type system
Some conclusions
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
SSCC syntax
streamP asf inQfeedv:Pf (x):P
9=
;Coordination
P ::= P jQ(ºa)P0recX :PX
9>>>>=
>>>>;
Standard operators
a ) Pa ( P
¾
Services
v:P(x)P
¾Conversations
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
a ) P ja ( Q ! (ºr)(r B P jr C Q)
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)
(ºr)(r B v:P jr C (x)Q) ! (ºr)(r B P jr C Q[v=x])
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» π-calculus channels not structured enough
We propose the stream construct– Induce a clear style of programming
streamP asf inQ
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
streamP asf inQ
Q is blocked, P can execute
Now Q can execute too P1 is still enabled
A working stream
streamfeedv:P1asf = hi inf (x):Q1
streamP1asf = hvi inf (x):Q1
streamP1asf = hi inQ1[v=x]
Some programming patterns
P >x>Q , streamP asf inrecX:f (x)(QjX)
replyP , P >1x>x
P >n x1:::xn >Q , streamPasf inf (x1)::::f (xn):Q
calla(x1; :::;xn) , a ( x1:::xn :(y)feedy
a¤) P , recX :a ) (P jX )
Roadmap
Stream SCC: syntax and semantics
SSCC vs SCC
A simple type system
Some conclusions
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…
calla(v) >1 x > callb(x)b( a ( v
calla(v) >1 x > (callb(x)j callc(x))
(r B a ( v)jr B (x)(b( xjc ( x)
Synchronization (Workflow Pattern 3)
Auxiliary session (or service) required in SCC
sync¤) (a1) : : :(an)(calla1j : : : j callan) >n> unit
sync ) (a1) : : : (an)
(ºr)(r B (a1 ( unitj : : : jan ( unit)j
r B (x1) : : :(xn) returnunit)
While (part of Workflow Pattern 10)
The two definitions of IfSignal are almost identical
while¤) (c)(a) callc>1 b>reply(I f Signal(b;calla>1> callwhile(c;a)))
while) (c)(a)(ºr)r B c ( unit
r B (b)I f Signal(b;(ºs)s B a ( unit
j s B (x)whilef (¡ )a:(z) returnzg ( c)
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
book¤) (streamcallhotel ash in callplane)>1 x > h(y):x:y
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
(EATCS ( recX :(x):feedx:X jEAP LS ( recX :(x):feedx:X )> y > emailM e( y
emailM efg( (pub) (s) returnsjEATCSfg( pubjEAPLSfg( pub)
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
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
Roadmap
Stream SCC: syntax and semantics
SSCC vs SCC
A simple type system
Some conclusions
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
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– Γ 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
¡ ` P : (U;T)
Typed examples
v1 : T;v2 : T;f : f Tg` streamfeedv1:feedv2asf inf (x1)f (x2):x1:x2: (!T:!T:End;T1)
a : [?T1: : : : :?Tn :!T:End];x1 : T1; : : : ;xn : Tn` a ( x1:::xn :(y)feedy : (End;T)
a : [?T1:!T2:End];v : T1;b: [?T2:!T3:End]` calla(v) >1 x > callb(x) : (End;T3)
Roadmap
Stream SCC: syntax and semantics
SSCC vs SCC
A simple type system
Some conclusions
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
Conclusions
We think that SSCC is an improvement w.r.t. SCC from the usability point of view
SSCC deals with services + conversations + coordination
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?
End of talk