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

Roadmap l Stream SCC: syntax and semantics l SSCC vs SCC l A simple type system l Some conclusions

Roadmap l Stream SCC: syntax and semantics l SSCC vs SCC l A simple type system l Some conclusions

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

SSCC syntax s t ream P as f i n Q f ee d v : P f ( x ) : P 9 = ; C oor d i na t i on P :: = P j Q ( ºa ) P 0 rec X : P X 9 > > > > = > > > > ; S t an d ar d opera t ors a ) P a ( P ¾ S erv i ces v : P ( x ) P ¾ C onversa t i ons

SSCC services l Services are defined by their name a and their protocol P l Service definition and service invocation are symmetric l Invocations and definitions interact by producing sessions executing their protocol l Sessions are not available when programming –Only runtime construct a ) P j a ( Q ! ( ºr )( r B P j r C Q )

SSCC conversations l Sessions can exchange information via concretion and abstraction as in SCC l We can imagine to extend conversations with constructs taken from other works on sessions (e.g., choice) ( ºr )( r B v : P j r C ( x ) Q ) ! ( ºr )( r B P j r C Q [ v = x ])

Orchestrating SSCC services l Many services concurrently executing in a system l Data from one service used by other services l Need for inter-service communication primitives l 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 l We propose the stream construct –Induce a clear style of programming s t ream P as f i n Q

l P and Q are concurrently executing l f is the name of a communication stream from P to Q l Two possible semantics: f ordered or unordered l P can feed values inside f (feed v.P’) –Non blocking –Values stored in f l Q can read values from f (f(x).Q’) –Blocking –Reads from stream f –Possible to read from multiple named sources s t ream P as f i n Q

l Q is blocked, P can execute l Now Q can execute too l P 1 is still enabled A working stream s t ream f ee d v : P 1 as f = hi i n f ( x ) : Q 1 s t ream P 1 as f = h v i i n f ( x ) : Q 1 s t ream P 1 as f = hi i n Q 1 [ v = x ]

Some programming patterns P > x > Q, s t ream P as f i nrec X : f ( x )( Q j X ) rep l y P, P > 1 x > x P > n x 1 ::: x n > Q, s t ream P as f i n f ( x 1 ) :::: f ( x n ) : Q ca ll a ( x 1 ;:::; x n ), a ( x 1 ::: x n : ( y ) f ee d y a ¤ ) P, rec X : a ) ( P j X )

Roadmap l Stream SCC: syntax and semantics l SSCC vs SCC l A simple type system l Some conclusions

Chaining services l In SCC if a returns many values then many instances of b are executed –No easy way to avoid this –Full control in SSCC l Also, slightly changing the specific… ca ll a ( v ) > 1 x > ca ll b ( x ) b ( a ( v ca ll a ( v ) > 1 x > ( ca ll b ( x ) j ca ll c ( x )) ( r B a ( v ) j r B ( x )( b ( x j c ( x )

Synchronization (Workflow Pattern 3) l Auxiliary session (or service) required in SCC sync ¤ ) ( a 1 ) ::: ( a n )( ca ll a 1 j ::: j ca ll a n ) > n > un i t sync ) ( a 1 ) ::: ( a n ) ( ºr )( r B ( a 1 ( un i t j ::: j a n ( un i t ) j r B ( x 1 ) ::: ( x n ) re t urn un i t )

While (part of Workflow Pattern 10) l The two definitions of IfSignal are almost identical w h i l e ¤ ) ( c )( a ) ca ll c > 1 b > rep l y ( I f S i gna l ( b ; ca ll a > 1 > ca ll w h i l e ( c ; a ))) w h i l e ) ( c )( a ) ( ºr ) r B c ( un i t r B ( b ) I f S i gna l ( b ; ( ºs ) s B a ( un i t j s B ( x ) w h i l e f ( ¡ ) a : ( z ) re t urn z g ( c )

Asking two services in parallel l Ask for flight and hotel in parallel and give back the flight first and then the hotel l 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 l Naming streams is important b oo k ¤ ) ( s t reamca ll h o t e l as h i nca ll p l ane ) > 1 x > h ( y ) : x : y

Merging two streams l EATCS and EAPLS return streams of conference announcements l I want an for each announcement l The two services (EATCS and EAPLS) have had to be modified to send the results via pub l Recursion is important ( EATCS ( rec X : ( x ) : f ee d x : X j EAPLS ( rec X : ( x ) : f ee d x : X ) > y > ema i l M e ( y ema i l M e fg ( ( pu b ) ( s ) re t urn s j EATCS fg ( pu b j EAPLS fg ( pu b )

Differences l 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 l Other things are less important and orthogonal –Recursion –Persistent vs non-persistent service definitions

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

Roadmap l Stream SCC: syntax and semantics l SSCC vs SCC l A simple type system l Some conclusions

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

Type system l Types for values –Unit, Int, …Basic types –[U]Service types l Protocols: –?T.UInput –!T.UOutput –endEnd of protocol –XVariable –rec X.URecursive types l Processes typed as –Γ set of assumptions, U protocol, T type of the fed stream l Sessions typed as services, and stream as {T} where T is the type of the transmitted values ¡ ` P : ( U ; T )

Typed examples v 1 : T ; v 2 : T ; f : f T g ` s t ream f ee d v 1 : f ee d v 2 as f i n f ( x 1 ) f ( x 2 ) : x 1 : x 2 : ( ! T : ! T : E n d ; T 1 ) a: [ ? T 1 ::::: ? T n : ! T : E n d ] ; x 1 : T 1 ;:::; x n : T n ` a ( x 1 ::: x n : ( y ) f ee d y: ( E n d ; T ) a: [ ? T 1 : ! T 2 : E n d ] ; v: T 1 ; b : [ ? T 2 : ! T 3 : E n d ] ` ca ll a ( v ) > 1 x > ca ll b ( x ) : ( E n d ; T 3 )

Roadmap l Stream SCC: syntax and semantics l SSCC vs SCC l A simple type system l Some conclusions

What else exists on SSCC l Reduction and LTS semantics l Correspondence result l The implementation of all the van der Aalst Workflow Patterns not requiring killing abilities l A subject reduction result for the type system

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

Future work l 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 l Kill primitive –The approach from SCC can be imported –Is it the right one?

End of talk