280 likes | 294 Views
Explore Stream SCC, a variant simplifying service invocation & interaction among different services. Introduces a new construct for orchestrating services efficiently.
E N D
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
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
9 9 j P P Q f P i Q t : : s r e a m a s n = ¾ ¾ P P > = v a > ) ( ) P f d d P C i i t > : S C i i º a e e v o o r n a o n t > e o r n v v c e e r s s a o n s : = ( ) P P ( ) a x d d f S P ( 0 t t ; a n a r o p e r a o r s x : X P > r e c > : > > X ; SSCC syntax
j ( ) ( j ) P Q P Q B C a a º r r r ) ( ! 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
( ) ( j ( ) ) ( ) ( j [ = ] ) P Q P Q v B C B C º r r v r x º r r r x ! : 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)
f P Q i t s r e a m a s n 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
f P Q i t s r e a m a s n • 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
h h i i h i ( [ = ) ] ( ) f d f f f f f P P P Q Q Q i i i v t t t s s s r r r e e e a a a m m m e e a a s s a s n n n v v x x x = = = 1 1 1 1 1 1 : : : A working stream • Q is blocked, P can execute • Now Q can execute too • P1 is still enabled
, , ( j ) P X P X ( ) ( ) l l f d ¤ r e c , , , a a ) ) c a e e a x x a x x y y 1 ( ( ( ) ( ) j ) ( ) 1 1 l f f f f f P P P Q P Q P P X Q X Q i i n : n n t t > > > > > > ; : : : ; : : : : r e p y s r e a m s r a e s a m n r a e s c n x x x x x x x x 1 1 n n : : : : : : : : : Some programming patterns
Roadmap • Stream SCC: syntax and semantics • SSCC vs SCC • A simple type system • Some conclusions
1 1 ( ( ( ) ) ) j ( ( ) ( ( ( ) ) j j ( ) ) ) b l l l l l l l l b b b l l B B > > > > c c a a c c a a c a r a a a a v v v v x x r x x x x c c x x ( ( ( ( ( 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…
( ) ( ) ( ) ( ) ( j j ) l l l l n i t s y n c a a > > ) ¤ c a c a s y n c a a a a u n 1 ) 1 1 n : : : n n : : : : : : ( ) ( ( j j ) j i i t t B º r r a u n a u n ( ( 1 n : : : ( ) ( ) ) i t t B r e u r n r x x u n 1 n : : : Synchronization (Workflow Pattern 3) • Auxiliary session (or service) required in SCC
( ) ( ) h l 1 i ( ) ( ) h l l l b i w e c a > > ) ¤ c a w e c a c ) ( ) 1 i t ( ( ( ) ) ) B l f l b l l l l h l I S i i º r r c u n > > ( r e p y c a c a g n a a w e c a ; ; ( ) ( b f l b I S i B r g n a ; ( ) i t B º s s a u n ( j ( ) f ( ) ( ) g ) h l i ¡ t B r e u r n s x w e a z z c ( : While (part of Workflow Pattern 10) • The two definitions of IfSignal are almost identical
( ) b k l l h l h l l l i t t ¤ s r e a m c a a s n c a o o o e p a n e ) 1 ( ) h > > x y x y : : 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
( ( ) j ( ) ) f d f d E A T C S X X E A P L S X X r e c e e r e c e e x x x x ( ( : : : : : : l M i f g ( ( ) > > l b M i y e m a e y t ( r e u r n e m a e p u s s ( ) j f g j f g ) b b E A T C S E A P L S p u p u ( ( 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
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
( ) ` ¡ P U T : ; 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
f g f T T T [ ] ? ? ! E d T T T T T v : v : : n a : x : x : 1 2 [ ] [ ] 1 1 1 ? ! E d b ? ! E d T T T T T ; ; n n n : : : : : : : ; ; : : : ; n n a : v : : 1 2 1 2 3 ( ) ( ) : : ; ; : : ` f d f d f f f i ( ) ( ) t ` f d E d T s r e a m e e e e a s n v v x x x x e e n 1 2 1 2 1 2 a x x y y : ( 1 1 ( ) ( ) ( ) : : : ` l l l l b E d T n : : : : ; > > c a c a n a v x x : 3 ( ) ! ! E d T T T ; n : 1 : : ; Typed examples
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 Thanks! Questions?