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