1 / 37

Behavioural Theory at Work: Program Transformations in a Service-centred Calculus

Behavioural Theory at Work: Program Transformations in a Service-centred Calculus. Ivan Lanese Computer Science Department Univers ity of Bologna Italy. Joint work with Luis Cruz-Filipe, Francisco Martins, Antonio Ravara and Vasco Vasconcelos Univerisities of Lisbon, Portugal. Roadmap.

lmelvin
Download Presentation

Behavioural Theory at Work: Program Transformations in a Service-centred Calculus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Behavioural Theory at Work:Program Transformations in a Service-centred Calculus Ivan Lanese Computer Science Department University of Bologna Italy Joint work with Luis Cruz-Filipe, Francisco Martins, Antonio Ravara and Vasco Vasconcelos Univerisities of Lisbon, Portugal

  2. Roadmap • A Service-Centred Calculus • Behavioral theory • Program transformations • Conclusions

  3. Roadmap • A Service-centred Calculus • Behavioural theory • Program transformations • Conclusions

  4. Service Oriented Computing (SOC) • SOC is a main paradigm to program distributed applications • Based on the composition of dynamically discovered services • Allows integration of services from different companies • Has to deal with interoperability, dynamicity, security, Quality of Service, reconfiguration…

  5. Why a Service-Centred Calculus? • Formal methods are necessary to master the complexity of SOC • Process calculi allow to easily experiment with different primitives… • To find out the best ways to manage services • … and formally prove results about systems • E.g. that service compositions behave as expected • Important to have services as first-level entities • For a direct modelling • For a direct exploitation of analysis results

  6. Stream-based Service Centred Calculus • There is no agreement on which is the best set of primitives to model SOC • We propose SSCC, a calculus based on sessions and streams • Strongly related to CaSPiS [talk from Bruni] • SSCC provides operators for • Defining and invoking services • Describing conversations (sessions) between services • Orchestrating complex service systems

  7. 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 h P O i t t > : S C i i º a e e v r c e s r 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

  8. 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 • Invocation and definition interact creating two session endpoints executing their respective protocols • Sessions are not available when programming • Only runtime construct

  9. ( ) ( 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 input and output • We can imagine to extend conversations with all the typical session constructs (e.g., choice)

  10. f P Q i t s r e a m a s n Orchestrating SSCC services • We propose the stream construct • Induces a clear style of programming • Good tradeoff between expressive power and structured communication • P and Q are concurrently executing • f is a communication stream (i.e., a queue) from P to Q • P can feed values inside f (feed v.P’) • Non blocking • Values stored in the nearest stream (anonymous) • Q can read values from f (f(x).Q’) • Blocking • Reads from stream f

  11. 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 r e a s s m r r e e a a e m m e a a s s a s n n n v v x x x ! ! = = = : : : A stream at work

  12. ( ( ) ) j ( ( ) ) f d b f d t s r e a m e e e e a x x y y ( ( h i ( ) ( ) ( ) f f f f d i t t a s n e e z w c z w = ( : : : : Orchestrating 3 services • Invoke services a and b and use their results to invoke c

  13. , b * P v : ( ) b f d f f P i t s r e a m e e ² a s n v z ( : : , ( ) b + P x ( ) ( ) b f d f f P i t s r e a m e e a s n z z x ) : : Useful macros • Direct communications

  14. Roadmap • A Service-centred Calculus • Behavioural theory • Program transformations • Conclusions

  15. Why a behavioural theory? • To understand the relationships between the different operators • To be able to reason axiomatically on systems • To be able to prove the correctness of program transformations and optimizations

  16. Which behavioural theory? ≡ ' • We consider the classic bisimilarity approach • We have an LTS semantics • Processes should be able to mimik each other labelled transitions • We choose full (substitution-closed) bisimilarity • Strong bisimilarity ~f for more basic transformations • Weak bisimilarity ≈f allows optimizations • Abstracts away internal actions

  17. A compositionality result • Strong and weak full bisimilarity are congruences • Capture the corresponding contextual equivalences • Axioms can be applied to subterms • Transformations can be applied to arbitrarily complex systems • The congruence result does not hold for strong/weak plain bisimilarity (as for π) • We will present some useful axioms • We are not interested in a complete axiomatization

  18. ( ) ( ) ( ) ~ ~ f f P Q P Q i i ( ) ( ) ( ) t t P P ´ s r e a m a s n s r e a m a s n º a v º a v = = . . ´ r º a º a r = ( ) ( ) ~ f f Q S i t [ 2 a n e v ( ) ( ) ( ) ~ ~ f f P Q P Q i i t t ´ s r e a m a s n s r e a m a s n v º a º a v = = = ( ) ( ) ~ f f P S i t [ 2 a n e v Structural congruence is a bisimulation • Standard rules for parallel composition, restriction and recursion • Additional scope extension rules

  19. ( ) [ [ ] ] [ [ ] ] f d b d D D D i i 0 0 0 0 t . / r r r º o e s n o n r » f ; ; ( j ) j Q P Q P f 6 i . . . . r s s r s r » = f Session axioms • Different sessions are independent • Terminated sessions can be garbage collected

  20. 0 ( j ) f P Q Q i j t f f f f d P P Q P P Q P i i i i 0 t s r e a m a s n t t » f s s r r e e a a m m a a s s n n o e s n o o c c u r n » » f f 0 0 ( ) j = ( ) f f f f P Q Q Q i i = ( ) t f f f d d f d 2 Q P i i t t s r e a m a s n n 2 e e n a n o e s n o c o n a n Stream axioms (1) • Stream = parallel composition + communication • Terminated streams can be garbage collected

  21. 0 f P P Q i i t t s r e a m a s n s r e a m a s n g » f 0 f f f 6 P P Q i i i f g t t f f d P P Q Q i 0 s r e a m a s n s r e a m a s n g g t = ¼ s r e a m a s n e e v ! f : Stream axioms (2) • Uncatched feeds are τ steps • Different streams are independent

  22. ( ( j j j ) j ) j j j j f d f f f d f f Q R P P P P Q Q Q P R P P P Q Q i i i i t t t t . . . . s s r r e e a a m m e e a a s s n n e e s s r e r a e m a m a s a s n n r r v v r v v r » » » » f f f f / f f f d Q R i i i i i i t t t t t c c o o n n a a n n s s n n o o s e e e s s s o n n p u o u p u Sessions vs streams • Feeds are unaffected by sessions • Session outputs are unaffected by streams • More in general

  23. Roadmap • A Service-centred Calculus • Behavioural theory • Program transformations • Conclusions

  24. Object-oriented interaction pattern • UML sequence diagrams show the exchange of messages among components of a complex system… • …but have no session information

  25. Session-oriented interaction pattern • There are two sessions: • r between A and B • s between B and C • There are local communications in B

  26. , , ( ) ( ) ( j ) A b B b b B B P w y º ( 1 2 1 2 : ; , , , ( ) C S ( ( ) ) ( j j ( ) ) B S C b b b * A b B + C Q c x v ) º x c x y y ) 1 1 2 : ; : : , ( ) ( ) B b + b * R c x x y y ( 2 1 2 : : : The session-oriented pattern in SSCC • The pattern can be implemented in SSCC • Communications between different sessions in B exploit auxiliary services

  27. Optimization: using a subsession

  28. , , 0 ( ( ) ( ) ( ) ( j j ( ) ) j ( ) ) E b b b A E C b * b + S C R Q º x c º c x y y y y ) ( 1 1 1 ; : : : The subsession pattern in SSCC • Now the SSCC implementation is: • A and C are as before • Two auxiliary communications have been eliminated • Two are still used

  29. Is the program transformation correct? • The two diagrams can be proved full weak bisimilar • The proof exploits: • Standard coinductive techniques • Congruence • Some axioms (session independence, garbage collection) • Since full weak bisimilarity is a congruence the optimization can be applied in any context

  30. , , ( ) 0 G b ( ) ( j j ) b A G C S C x ) º c ; ( ) ( ) f d f f R Q i t s r e a m e e a s n c x y y y y ( : : : : Introducing streams • We can use a stream to avoid the remaining auxiliary communications • Correctness proof similar to the previous one

  31. Breaking sessions • Current technologies (e.g. WSDL, BPEL) does not provide sessions • Only request and request/response primitives • Correspond to sessions with fixed protocol • Useful to break sessions in smaller pieces • A long session may correspond to a sequence of request/responses • Next request/response name sent as continuation

  32. Breaking sessions example Request-response

  33. Breaking sessions correctness • Arbitrary sessions can not be broken preserving the semantics • Difficult to deal with parallel composition • Sequential conversations can be broken • The transformation is correct w.r.t. weak full bisimilarity • We have a type system ensuring sequentiality

  34. Roadmap • A Service-centred Calculus • Behavioural theory • Program transformations • Conclusions

  35. Conclusions • SSCC can model session-based communication patterns • Behavioural theory allows to work axiomatically on patterns • Complex program transformations can be specified and proved correct

  36. Future work • On program transformations • Develop a methodology to drive the application of transformations • Apply them to more complex case studies • On SSCC • Further understand its behavioral theory • Add kill and compensation primitives • On types for SSCC • Type systems for deadlock freedom and progress • Type systems for termination

  37. ( ) f d f i i t t s r e a m e e a s v a n q u e s o n x x ( : : ( ) f h k i i t n x n : End of talk Thanks!

More Related