Formal Models for Distributed Negotiations From Petri Nets to Join Calculus

1
Formal Models forDistributed NegotiationsFrom
Petri Nets to Join Calculus
XVII Escuela de Ciencias Informaticas (ECI 2003),
Buenos Aires, July 21-26 2003
Roberto Bruni Dipartimento di Informatica
Università di Pisa
2
Petri Net Flavors

• We have already seen that 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 a process calculus

3
Basic Model P/T Petri Nets
b
a
2
3
2
c
d
4
Basic Model P/T Petri Nets
b
a
2
3
2
c
d
5
Colured Nets (also High-Level Nets)
b
a
5
s
1
x
y
x?y
structured data as tokens
yy
x3
6
c
d
6
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
7
Reconfigurable Nets
b
a
a
c
c
d
x
post-sets places depend on fetched values
y
network reconfigurability vs static connectivity
y
x
x
y
8
Reconfigurable Nets
b
a
a
d
x
post-sets places depend on fetched values
y
network reconfigurability vs static connectivity
xc yc
y
x
c
c
x
y
c
9
Dynamic Nets
b
a
a
c
c
d
x
firings can generate new net fragments
y
dynamic control
N(x,y)
10
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 Buscemi, Sassone
  2001
• 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)

11
JOIN-Calculus

• Well-known asynchronous calculus
• continuation passing style
• Distributed implementations
• JoCaml (http//join.inria.fr)
• Polyphonic C
• Analogous to dynamic coloured Petri nets
• Running implementation of Zero-Safe Nets
• CHAM semantics
• soup of molecules
• processes
• definitions

12
Chemical Abstract Machine

• States are called solutions s
• Multisets of molecules m1,,mn
• data and rules (reflexive CHAM)
• Hierarchical structure via membranes
• Group solutions into molecules
• e.g. s1 , s2 , s3, s4
• Evolution (chemical rules)
• Heating / cooling ? (reversible)
• Structural equivalence
• Reactions ?
• Transitions
• Concurrency

multiset union
13
Background the Join Calculus

• 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
patterns
heating and cooling
reaction
14
JOIN An Example
received 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
defined name
membrane
extrusion
15
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)

16
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
• MNv def q?c?p?y? ? c?y,v? in MqNp

17
Example Cell Abstraction
def create?n,c? ? def get?k? s?v? ? k?v?
s?v? ? set?m,k?
s?v? ? k?? s?m?
in s?n? c?get,set?
A message to create triggers the outermost
definition, which in turn defines three fresh
names (get,set,s) with local rules and state get
/ set are sent back on channel c for later access
/ update of cell contents s cannot be extruded
and remains local, it models the cell and its
contents the initial value stored in s is the
parameter n in the message create the rules
guarantee the invariant of the cell in every
configuration there is exactly one message on s,
(with its current value)
18
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

19
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

20
Type System ?0 II
21
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 ?

22
Type System ?1 II
23
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

24
Recap

• We have seen
• Join calculus
• Different flavors of Petri nets
• Corresponding flavors of Join calculus

25
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