1 Nominal Calculi for Transactions: JOIN Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and Orchestration IMT- Institutions Markets Technologies - Alti Studi Lucca

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 2 Models and Languages for Coordination and Orchestration Contents Introduction Join calculus + Examples Join and  Join as Petri nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 3 Models and Languages for Coordination and Orchestration Contents Introduction Join calculus + Examples Join and  Join as Petri nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 4 Models and Languages for Coordination and Orchestration Motivation (back to 1995) Mismatch concurrent process calculi CCS,  -calculus: few constructs, based on rendez-vous (atomic non-local interactions) programming languages for distributed and mobile systems Actors, Obliq: separate primitives for transmission and synchronization (RPC and semaphores) and a much larger set of constructs (imperative primitives) Join calculus has been devised to bridge this gap process calculus presentation basis for a practical programming language design

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 5 Models and Languages for Coordination and Orchestration Features (as process calculus) Based on an elementary model of concurrency reflexive chemical abstract machine = generic CHAM + imposing locality + adding reflection locality: only linear reaction patterns allowed each molecule or reaction rule is associated to a single reaction site reflection: reactions can generate new kinds of molecules together with their defining reaction rules computational completeness of the model more effective than generic CHAM molecules travel to their reaction site, instead of having to blindly mix and match -calculus as sequential deterministic subset

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 6 Models and Languages for Coordination and Orchestration Features (as distributed programming language) Extends a higher-order functional language parallelism in expressions (fork calls) parallelism in function patterns (join patterns) jointly defined function provide the same capabilities as synchronous channels or concurrent objects join patterns are more consistent with lexical scope static binding of function calls to the code as opposed to dynamic binding of messages to receptors Distributed implementations JoCaml ( ), Polyphonic C#

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 7 Models and Languages for Coordination and Orchestration Join calculus vs.  calculus Join is essentially  with restrictions on communication patterns Join combines restriction, reception and replication in a single receptor definition not available separately asynchronous calculus, continuation passing style asynchrony forces one to create and send continuations Nevertheless, join and  have the same expressive power demonstrated by fully abstract encodings in each direction (up to weak barbed congruence)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 8 Models and Languages for Coordination and Orchestration Join Calculus vs Petri Nets We shall see that the join-calculus is the natural higher order extension of Petri nets places as ports / channels tokens carry values names of places are also admissible values firing can generate fresh pieces of nets new places new transitions

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 9 Models and Languages for Coordination and Orchestration Contents Introduction Join calculus + Examples Join and  Join as Petri nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 10 Models and Languages for Coordination and Orchestration Chemical Abstract Machine: Molecules and Membranes States are called solutions s Multisets of molecules m 1,…,m n data and rules (reflexive CHAM) Hierarchical structure via membranes group solutions into molecules allow nesting e.g. {[ s 1, {[ s 2 ]}, {[ s 3, {[ s 4 ]} ]} ]} multiset union

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 11 Models and Languages for Coordination and Orchestration Chemical Abstract Machine: Chemical Rules Evolution (chemical rules)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 12 Models and Languages for Coordination and Orchestration Chemical Abstract Machine: Chemical Rules Evolution (chemical rules) Heating / cooling  (reversible) Structural equivalence

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 13 Models and Languages for Coordination and Orchestration Chemical Abstract Machine: Chemical Rules Evolution (chemical rules) Heating / cooling  (reversible) Structural equivalence Reactions  Transitions

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 14 Models and Languages for Coordination and Orchestration Chemical Abstract Machine: Chemical Rules Evolution (chemical rules) Heating / cooling  (reversible) Structural equivalence Reactions  Transitions

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 15 Models and Languages for Coordination and Orchestration Join Calculus in One Slide Syntax P,Q::=0 | x  ŷ  | def D in P | P|Q D,E::=J  P | D  E J,K::= x  ŷ  | J|K Operational semantics (CHAM Style) 0  P|Q  P,Q D  E  D,E def D in P  D  dn(D), P  dn(D) ( range  dn(D) “globally fresh”) J  P, J   J  P, P  heating and cooling reaction processes definitions patterns resembles funct. prog. let f(x)=E in F (same scoping discipline)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 16 Models and Languages for Coordination and Orchestration JOIN: An Example A process P P  z  x,z  | def x  y   z  y,x  in x  v  P as a solution {[ z  x,z , w  y   z  y,w , w  v  ]} A reaction {[ z  x,z , w  y   z  y,w , w  v  ]}  {[ z  x,z , w  y   z  y,w , z  v,w  ]} bound name extrusion defined name received name free name membrane bound name free name

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 17 Models and Languages for Coordination and Orchestration Continuation Passing Style I The form of definitions resembles very much let f(x)=E in E’ (typical of functional programming) e.g. same scoping discipline Asynchrony forces us to create and send continuations in join e.g. encoding untyped -calculus [M] v sends the value of M on v a value is a process serving requests a request must supply two names x (channel for requests for the value of the argument) w (to eventually return a value)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 18 Models and Languages for Coordination and Orchestration Continuation Passing Style II Call-by-name [x] v = v  x  [ x.M] v = def k  x,w   [M] w in v  k  [MN] v = def y  p   [N] p in def q  c   c  y,v  in [M] q Parallel call-by-value [x] v = v  x  [ x.M] v = def k  x,w   [M] w in v  k  [MN] v = def q  c  |p  y   c  y,v  in [M] q |[N] p

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 19 Models and Languages for Coordination and Orchestration Call-by-Name Strategy: leftmost order, no reduction under Reductions are entirely sequential The image of the translation is exactly the deterministic subset of Join (no parallel composition, no conjunction) [x] v = x  v  [ x.M] v = def k  x,w   [M] w in v  k  [MN] v = def y  p   [N] p in def q  c   c  y,v  in [M] q

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 20 Models and Languages for Coordination and Orchestration Call-by-Name: Example [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in [ x.M] q [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in q  k  [( x.M)N] v  def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in k  y,v  [( x.M)N] v  * def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in [M[y/x]] v

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 21 Models and Languages for Coordination and Orchestration Call-by-Name: Example [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in [ x.M] q [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in q  k  [( x.M)N] v  def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in k  y,v  [( x.M)N] v  * def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in [M[y/x]] v

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 22 Models and Languages for Coordination and Orchestration Call-by-Name: Example [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in [ x.M] q [( x.M)N] v = def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in q  k  [( x.M)N] v  def y  p   [N] p in def q  c   c  y,v  in def k  x,w   [M] w in k  y,v  [( x.M)N] v  * def x  p   [N] p in [M] v

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 23 Models and Languages for Coordination and Orchestration Parallel Call-by-Value Strategy: again no reduction under, but in (TU), T and U can be evaluated in parallel Confluent, but non deterministic [x] v = v  x  [ x.M] v = def k  x,w   [M] w in v  k  [MN] v = def q  c  |p  y   c  y,v  in [M] q |[N] p

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 24 Models and Languages for Coordination and Orchestration Call-by-Value: Example [( x.M)N] v = def q  c  |p  y   c  y,v  in [ x.M] q | [N] p [( x.M)N] v = def q  c  |p  y   c  y,v  in [N] p | def k  x,w   [M] w in q  k  [( x.M)N] v  * def q  c  |p  y   c  y,v  in p  z  | def k  x,w   [M] w in q  k  [( x.M)N] v  def q  c  |p  y   c  y,v  in def k  x,w   [M] w in k  z,v  [( x.M)N] v  def q  c  |p  y   c  y,v  in def k  x,w   [M] w in [M[z/x]] v

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 25 Models and Languages for Coordination and Orchestration Example: Cell Abstraction get  k  | s  v   k  v  | s  v  A cell s contains the value v To get the value: send a message on port get the parameter k is the return address, where the value v will be sent to

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 26 Models and Languages for Coordination and Orchestration Example: Cell Abstraction get  k  | s  v   k  v  | s  v  A cell s contains the value v To set the value: send a message on port set the parameter m is the new value for s k is the return address (for confirmation) set  m,k  | s  v   k  | s  m 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 27 Models and Languages for Coordination and Orchestration Example: Cell Abstraction get  k  | s  v   k  v  | s  v  The initial value in s is n But get, set and s are locally bound by def get and set must be extruded, otherwise no one can use them instead, s is kept private (encapsulation) set  m,k  | s  v   k  | s  m  def  in s  n 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 28 Models and Languages for Coordination and Orchestration Example: Cell Abstraction get  k  | s  v   k  v  | s  v  get, set are extruded on public channel c But c should be known only by the owner of the cell… set  m,k  | s  v   k  | s  m  def  in s  n  | c  get,set 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 29 Models and Languages for Coordination and Orchestration Example: Cell Abstraction get  k  | s  v   k  v  | s  v  A message to create triggers the outermost def: Three fresh names for s, get and set are allocated the initial value of s is the first parameter n get and set are sent back to the second argument c instead s will never be extruded Invariant in every configuration there is exactly one message on s set  m,k  | s  v   k  | s  m  def  in s  n  | c  get,set  def create  n,c   in …

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 30 Models and Languages for Coordination and Orchestration SIXTH HOMEWORK Guess the meaning of: def x  u   y  u  in P def y  u   x  u  in def x  u   y  u  in P def s   P  s   Q in s  def c   P|c  in Q|c 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 31 Models and Languages for Coordination and Orchestration Contents Introduction Join calculus + Examples Join and  Join as Petri nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 32 Models and Languages for Coordination and Orchestration Core Join Calculus Syntax a unique syntactic category P,Q::=x  u  | def x  u  |y  v   Q in P | P|Q Operational semantics CHAM Style (but also LTS is defined) The core join calculus has the same expressive power as the full join-calculus via a fully-abstract encoding

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 33 Models and Languages for Coordination and Orchestration Full abstraction Two process calculi with equivalences  1 and  2 The first is more expressive than the second if we can find a fully abstract encoding [.] 2  1 i.e. an encoding such that P  2 Q iff [P] 2  1  1 [Q] 2  1 The two calculi have the same expressive power if each one is more expressive than the other (If one is a sub-calculus of the other, then one implication is obvious)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 34 Models and Languages for Coordination and Orchestration What is Observable? Communication on internal names (no) on free names (yes) Internal steps countable: strong semantics (no) immaterial: weak semantics (yes) Equivalence reflexive, symmetric and transitive (yes) closed under contexts: congruence (yes)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 35 Models and Languages for Coordination and Orchestration Basic Observations Processes interact with the outside by extruding names on free ports by waiting for answers (via enclosed definitions) Processes are distinguished on the basis of their ability to emit messages on their free ports weak asynchronous output barb  x P  x iff x is a free name in P and  u such that P  * Q,x  u 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 36 Models and Languages for Coordination and Orchestration Remarks on Barbs Two processes P and Q such that  u with P  x but  (Q  x ) cannot be reasonably identified! Barbs are just elementary experiments barbs do not count reductions (ok) barbs do not observe branching (uhm) barbs do not observe message reception (uhm)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 37 Models and Languages for Coordination and Orchestration Closure Under Reductions Reductions are mute transitions i.e. only trivial labels are present P  P' can be read as P  P' In ordinary (strong) bisimulation if P  Q and P  P', then  Q'  P' s.t. Q  Q' (and vice versa) In weak bisimulation if P  Q and P  * P', then  Q'  P' s.t. Q  * Q' (and vice versa)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 38 Models and Languages for Coordination and Orchestration Closure Under Contexts If P  Q we expect that P and Q can be used interchangeably in any larger process but P  a  b  and Q  a  c  look equivalent when taken in isolation no reduction, a unique barb  a however, they are not equivalent in the context def a  x   x  in [.] as in fact def a  x   x  in P  b  (i.e. def a  x   x  in P  b ) def a  x   x  in Q  c  (i.e. def a  x   x  in Q  c )

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 39 Models and Languages for Coordination and Orchestration The Observational Congruence We take the largest equivalence relation  that is a refinement of output barbs if P  Q then (  x. P  x iff Q  x ) is closed under weak reduction if P  Q and P  * P', then  Q'  P' s.t. Q  * Q' is a congruence w.r.t. definitions and parallel if P  Q then (  D. def D in P  def D in Q) if P  Q then (  R. P|R  Q|R)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 40 Models and Languages for Coordination and Orchestration Observational Congruence: Examples If fn(P)=  then P  0 If P  Q then P  Q a  u   b  u  a  b   a  c  a  b   def c  x   b  x  in a  c  it is not possible to distinguish between different names that exhibit the same external behaviour

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 41 Models and Languages for Coordination and Orchestration Core Join vs Full Join Expressiveness-preserving simplification of syntax recursive binding shift binding variables from definition to reception def J  Q in P becomes def J|b  ã,b'   Q|b  ã,b'  in P|b  ã,b  where ã is the vector of variables in fn(Q)  dn(J) complex definitions n-way join patterns and multiple clauses connected by  as sequences joining two atoms at most polyadic messages name tuples are communicated by using auxiliary private names

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 42 Models and Languages for Coordination and Orchestration Asynchronous  Syntax P,Q::=x  u  | x(u).P | u.P | !x(u).P | P|Q Abstract semantics asynchronous barbed congruence ex. x(u).x  u   0 ex. equator EQ(x,y)  !x(u).y  u  | !y(v).x  v  P{x/y}  Q{x/y} implies EQ(x,y)|P  EQ(x,y)|Q processes

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 43 Models and Languages for Coordination and Orchestration Naïve Encoding: Join in  [x  v  ] j  = x  v  [P|Q] j  = [P] j  | [Q] j  [def x  u  |y  v   Q in P] j  = x. y.(!x(u).y(v). [Q] j  | [P] j  ) In the translation we loose the symmetry between x and y the atomicity of their joint reduction it does not matter, because x and y are restricted Not closed under  contexts!!! if x or y are extruded, then new receptors could appear

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 44 Models and Languages for Coordination and Orchestration Problems with Full Abstraction of Join in  : Example Let P  [ def x   0 in a  x  | x  ] j  and Q  [ def y   0 in a  y  ] j  the two encoded processes are equivalent P and Q are not Take the  -context a.( a(u).u().b  | [.] ) then a.( a(u).u().b  | P )  b while  ( a.( a(u).u().b  | Q )  b )

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 45 Models and Languages for Coordination and Orchestration Some kind of Firewall Instead of extruding defined names, we extrude dummy synonyms, setting up appropriate relays: R x, x e = !x(v). w.(r  w,v  | x e  w  ) If x is a free name of P, then we must embed P in the firewall for x, defined as F x [.] =  r.!r(y,y e ).R y,y e | x.(R x,x e | [.] j  )

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 46 Models and Languages for Coordination and Orchestration Naïve Encoding:  in Join Each  -channel x is simulated by two ports x o for output (where emitters send values) x i for input (the receiver defines a name k for its continuation and sends it as a reception offer on x i ) [x  v  ]  j = x o  v o,v i  [x(u).P]  j = def k  v o,v i   [P]  j in x i  k  [ x.P]  j = def x o  v o,v i  |x i  k   k  v o,v i  in [P]  j [!x(u).P]  j = def k  v o,v i   x i  k  | [P]  j in x i  k  [P|Q]  j = [P]  j | [Q]  j Not closed under Join contexts!!! problems with free names and input barbs

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 47 Models and Languages for Coordination and Orchestration Problems with Full Abstraction of  in Join: Examples [ x  a  | x  b  | x(u).y  u  ]  j cannot reduce because there is no englobing x [ x(u).x  u  ]  j exhibits a barb on x i that reveals the presence of an input on x A context could provide messages with arbitrary i/o-pairs ex. mismatched order: x o  v i,v o  ex. mismatched names: x o  v o,w i 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 48 Models and Languages for Coordination and Orchestration Proxies and Firewall A much more complicated notion of firewall is needed (omitted here) several pairs can exist for the same channel x any two pairs are interchangeable (message merging) a new proxy pair is created whenever a pair of names is received from the outside (and they are merged); the new pair will be transmitted in place of the old one whenever a pair of names is sent to the outside, a new firewall is inserted for setting up proxies for future incoming messages on this pair

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 49 Models and Languages for Coordination and Orchestration Implementability Uniqueness of receptors favour distributed implementation of Join y Join y y  y

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 50 Models and Languages for Coordination and Orchestration Contents Introduction Join calculus + Examples Join and  Join as Petri nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 51 Models and Languages for Coordination and Orchestration Petri Net Flavors The basic net model can be extended in many ways to model interesting features e.g. read arcs to increase expressiveness e.g. inhibitor arcs Many other variations have been proposed in the literature (stochastic, priorities, time, …) We survey some of them, as incremental extensions (bottom-up), showing that they can also be recovered in the other way round (top-down) starting from Join

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 52 Models and Languages for Coordination and Orchestration Basic Model: P/T Petri Nets ba cd 2 3 2

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 53 Models and Languages for Coordination and Orchestration Basic Model: P/T Petri Nets ba cd 2 3 2

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 54 Models and Languages for Coordination and Orchestration Colured Nets (also High-Level Nets) ba cd y y::y x  |y| x “s” x 6 structured data as tokens

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 55 Models and Languages for Coordination and Orchestration Coloured Nets (also High-Level Nets) ba cd y y::y x  |y| x x 6 structured data as tokens x=1 y=“s” “ss”

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 56 Models and Languages for Coordination and Orchestration Reconfigurable Nets ba xy y y x c d a x c network reconfigurability vs static connectivity cd post-sets places depend on fetched values

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 57 Models and Languages for Coordination and Orchestration Reconfigurable Nets ba xy y y x d a x x=c y=c c c c network reconfigurability vs static connectivity d post-sets places depend on fetched values

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 58 Models and Languages for Coordination and Orchestration Reconfigurable Nets ba xy y y x d x post-sets places depend on fetched values x=d y=a c c c network reconfigurability vs static connectivity d a

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 59 Models and Languages for Coordination and Orchestration Dynamic Nets ba y c d a x firings can generate new net fragments c dynamic control N(x,y) cd

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 60 Models and Languages for Coordination and Orchestration From Petri Nets to Dynamic Nets and Back via JOIN The join-calculus is the natural higher order extension of Petri nets more and more restrictive type systems recover all kinds of nets we have seen Dynamic nets (no restriction) Reconfigurable nets (no definitions inside definitions) High level nets (no channel names as messages) Place/Transition nets (no values in messages)

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 61 Models and Languages for Coordination and Orchestration Nets as Join Terms Roughly places are channels transitions are definitions tokens are message values nets are join processes different classes of nets corresponds to different classes of terms Note that in general a definition can contain another definition a reduction will release fresh places and transitions fresh transitions can release tokens in previously existing places, but they cannot fetch tokens from them

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 62 Models and Languages for Coordination and Orchestration Aim: To identify terms that correspond to P/T Petri nets Three kinds of judgements |- P :  P is ok and contains no def_in_ |- P :  P is ok |- D :  D is ok Type System  0 I

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 63 Models and Languages for Coordination and Orchestration Type System  0 II |- 0 :  |- x  :  |- P|Q :  |- P :  |- Q :  |- P :  |- P :  |- def D in P :  |- D :  |- P :  |- J  P :  |- P :  rn(J) = {  } |- D  D’ :  |- D :  |- D’ : 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 64 Models and Languages for Coordination and Orchestration Type System  1 Aim: To identify terms that correspond to coloured Petri nets Three kinds of judgements (as before) Type environments needed Channels must be kept distinct from messages  set of channel names  set of messages  and  must be disjoint in  ;  |- P : 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 65 Models and Languages for Coordination and Orchestration Type System  1 II  ;  |- 0 :   ;  |- P|Q :   ;  |- P :  ;  |- Q :   ;  |- P :   ;  |- P :   ;  |- def D in P :  ,dn(D);  |- D : ,dn(D);  |- P :   ;  |- J  P :   ; ,rn(J) |- P :   ;  |- D  D’ :   ;  |- D :  ;  |- D’ :   ;  |- x  y  :  y  x 

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 66 Models and Languages for Coordination and Orchestration Results  0 characterizes terms that correspond to P/T Petri nets  1 characterizes terms that correspond to Coloured nets A third type system  2 characterizes terms that correspond to reconfigurable nets A trivial type system  3 characterizes terms that correspond to dynamic nets All type systems enjoy subject reduction allow the definition of a behaviour preserving isomorphism between typeable terms and (the corresponding kind of) nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 67 Models and Languages for Coordination and Orchestration SEVENTH HOMEWORK Define the type system  2 that characterizes all those terms of the join-calculus that correspond to reconfigurable nets

Roberto IMT Lucca 13 April 2005 Institutions Markets Technologies IMT 68 Models and Languages for Coordination and Orchestration References The reflexive chemical abstract machine and the Join calculus (Proc. POPL’96, ACM, pp ) C. Fournet, G. Gonthier High-level Petri nets as type theories in the Join-calculus (Proc. FoSSaCS’01, LNCS 2030, pp ) M. Buscemi, V. Sassone