Formal Models for Distributed Negotiations: Transactions

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

• Introduction
• Join calculus Examples
• Join and ?
• Join as Petri nets

3
Contents

• Introduction
• Join calculus Examples
• Join and ?
• Join as Petri nets

4
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

5
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

6
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 ( http//join.inria.fr ), Polyphonic C

7
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)

8
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

9
Contents

• Introduction
• Join calculus Examples
• Join and ?
• Join as Petri nets

10
Chemical Abstract MachineMolecules and Membranes

• States are called solutions s
• Multisets of molecules m1,,mn
• data and rules (reflexive CHAM)
• Hierarchical structure via membranes
• group solutions into molecules
• allow nesting
• e.g. s1 , s2 , s3, s4

multiset union
11
Chemical Abstract MachineChemical Rules

• Evolution (chemical rules)

12
Chemical Abstract MachineChemical Rules

• Evolution (chemical rules)
• Heating / cooling ? (reversible)
• Structural equivalence

13
Chemical Abstract MachineChemical Rules

• Evolution (chemical rules)
• Heating / cooling ? (reversible)
• Structural equivalence
• Reactions ?
• Transitions

14
Chemical Abstract MachineChemical Rules

• Evolution (chemical rules)
• Heating / cooling ? (reversible)
• Structural equivalence
• Reactions ?
• Transitions

15
Join Calculus in One Slide

• Syntax
• P,Q 0 x?y? def D in P PQ
• D,E J? P D?E
• J,K x?y? JK
• Operational semantics (CHAM Style)
• 0 ?
• PQ ? 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?

processes
definitions
resembles funct. prog. let f(x)E in F (same
scoping discipline)
patterns
heating and cooling
reaction
16
JOIN An Example
defined name

• 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
free name
free name
bound name
received name
membrane
extrusion
17
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
• Mv 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)

18
Continuation Passing Style II

• Call-by-name
• xv v?x?
• ?x.Mv def k?x,w? ? Mw in v?k?
• MNv def y?p? ? Np
• in def q?c? ? c?y,v? in Mq
• Parallel call-by-value
• xv v?x?
• ?x.Mv def k?x,w? ? Mw in v?k?
• MNv def q?c?p?y? ? c?y,v? in MqNp

19
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)
• xv x?v?
• ?x.Mv def k?x,w? ? Mw in v?k?
• MNv def y?p? ? Np
• in def q?c? ? c?y,v? in Mq

20
Call-by-Name Example

• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in ?x.Mq
• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in q?k?
• (?x.M)Nv ? def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in k?y,v?
• (?x.M)Nv ? def y?p? ? Np
  in def q?c? ? c?y,v?
  in def k?x,w? ? Mw in My/xv

21
Call-by-Name Example

• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in ?x.Mq
• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in q?k?
• (?x.M)Nv ? def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in k?y,v?
• (?x.M)Nv ? def y?p? ? Np
  in def q?c? ? c?y,v?
  in def k?x,w? ? Mw in My/xv

22
Call-by-Name Example

• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in ?x.Mq
• (?x.M)Nv def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in q?k?
• (?x.M)Nv ? def y?p? ? Np
  in def q?c? ? c?y,v? in
  def k?x,w? ? Mw in k?y,v?
• (?x.M)Nv ? def x?p? ? Np
  in Mv

23
Parallel Call-by-Value

• Strategy again no reduction under ?, but in
  (TU), T and U can be evaluated in parallel
• Confluent, but non deterministic
• xv v?x?
• ?x.Mv def k?x,w? ? Mw in v?k?
• MNv def q?c?p?y? ? c?y,v? in MqNp

24
Call-by-Value Example

• (?x.M)Nv def q?c?p?y? ? c?y,v? in ?x.Mq
  Np
• (?x.M)Nv def q?c?p?y? ? c?y,v?
  in Np def k?x,w? ? Mw
  in q?k?
• (?x.M)Nv ? def q?c?p?y? ? c?y,v?
  in p?z? def k?x,w? ? Mw
  in q?k?
• (?x.M)Nv ? def q?c?p?y? ? c?y,v?
  in def k?x,w? ? Mw
  in k?z,v?
• (?x.M)Nv ? def q?c?p?y? ? c?y,v?
  in def k?x,w? ? Mw
  in Mz/xv

25
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

26
Example Cell Abstraction
get?k? s?v? ? k?v? s?v?
set?m,k? s?v? ? k?? s?m?

• 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)

27
Example Cell Abstraction
get?k? s?v? ? k?v? s?v?
def ? in s?n?
set?m,k? s?v? ? k?? s?m?

• 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)

28
Example Cell Abstraction
get?k? s?v? ? k?v? s?v?
def ? in s?n? c?get,set?
set?m,k? s?v? ? k?? s?m?

• get, set are extruded on public channel c
• But c should be known only by the owner of the
  cell

29
Example Cell Abstraction
def create?n,c? ?

in
get?k? s?v? ? k?v? s?v?
def ? in s?n? c?get,set?
set?m,k? s?v? ? k?? s?m?

• 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

30
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?? ? Pc?? in Qc??

31
Contents

• Introduction
• Join calculus Examples
• Join and ?
• Join as Petri nets

32
Core Join Calculus

• Syntax
• a unique syntactic category
• P,Q x?u? def x?u?y?v? ? Q in P PQ
• 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

33
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 P2?1 ?1 Q2?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)

34
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)

35
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?

36
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)

37
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)

38
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)

39
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. PR ? QR)

40
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

41
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 Jb?ã,b'? ? Qb?ã,b'?
  in Pb?ã,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

42
Asynchronous ?

• Syntax
• P,Q x?u? x(u).P ?u.P !x(u).P PQ
• Abstract semantics
• asynchronous barbed congruence
• ex. x(u).x?u? ? 0
• ex. equator EQ(x,y) ? !x(u).y?u? !y(v).x?v?
• Px/y ? Qx/y implies EQ(x,y)P ? EQ(x,y)Q

processes
43
Naïve Encoding Join in ?

• x?v?j?? x?v?
• PQj?? Pj?? Qj??
• def x?u?y?v? ? Q in Pj??
  ?x.?y.(!x(u).y(v). Qj?? Pj?? )
• 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

44
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 )

45
Some kind of Firewall

• Instead of extruding defined names, we extrude
  dummy synonyms, setting up appropriate relays
• Rx, xe !x(v).?w.(r?w,v? xe?w?)
• If x is a free name of P, then we must embed P in
  the firewall for x, defined as
• Fx. ? ?r.!r(y,ye).Ry,ye ?x.(Rx,xe .j??)

46
Naïve Encoding ? in Join

• Each ?-channel x is simulated by two ports
• xo for output (where emitters send values)
• xi for input (the receiver defines a name k for
  its continuation and sends it as a reception
  offer on xi)
• x?v???j xo?vo,vi?
• x(u).P??j def k?vo,vi? ? P??j in xi?k?
• ?x.P??j def xo?vo,vi?xi?k? ? k?vo,vi? in
  P??j
• !x(u).P??j def k?vo,vi? ? xi?k? P??j in
  xi?k?
• PQ??j P??j Q??j
• Not closed under Join contexts!!!
• problems with free names and input barbs

47
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 xi that reveals the presence
  of an input on x
• A context could provide messages with arbitrary
  i/o-pairs
• ex. mismatched order xo?vi,vo?
• ex. mismatched names xo?vo,wi?

48
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

49
Implementability

• Uniqueness of receptors favour distributed
  implementation of Join

50
Contents

• Introduction
• Join calculus Examples
• Join and ?
• Join as Petri nets

51
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

52
Basic Model P/T Petri Nets
b
a
2
3
2
c
d
53
Basic Model P/T Petri Nets
b
a
2
3
2
c
d
54
Colured Nets (also High-Level Nets)
b
a
5
s
1
x
y
x?y
structured data as tokens
yy
x3
6
c
d
55
Coloured Nets (also High-Level Nets)
b
a
5
x
y
x1 ys
x?y
structured data as tokens
yy
x3
4
ss
6
c
d
56
Reconfigurable Nets
network reconfigurability vs static connectivity
b
a
a
c
c
d
x
y
post-sets places depend on fetched values
y
x
x
y
c
d
57
Reconfigurable Nets
network reconfigurability vs static connectivity
b
a
a
d
x
y
post-sets places depend on fetched values
xc yc
y
x
c
c
x
y
c
d
58
Reconfigurable Nets
network reconfigurability vs static connectivity
b
a
d
x
y
post-sets places depend on fetched values
xd ya
y
x
c
c
a
x
y
c
d
59
Dynamic Nets
b
a
a
c
c
d
x
firings can generate new net fragments
y
dynamic control
c
d
N(x,y)
60
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)

61
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

62
Type System ?0 I

• 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

63
Type System ?0 II
64
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 ?

65
Type System ?1 II
66
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

67
SEVENTH HOMEWORK

• Define the type system ?2 that characterizes all
  those terms of the join-calculus that correspond
  to reconfigurable nets

68
References

• The reflexive chemical abstract machine and the
  Join calculus (Proc. POPL96, ACM, pp. 372-385)
• C. Fournet, G. Gonthier
• High-level Petri nets as type theories in the
  Join-calculus (Proc. FoSSaCS01, LNCS 2030, pp.
  104-120)
• M. Buscemi, V. Sassone