Components, roles, and ports

1
Components, roles, and ports
FMCO 2004 Leiden, NL

• Marcello Bonsangue
• LIACS Leiden University
• 2 November 2004

2
Collaboration

• This is a Mobi-J work in collaboration with
• Frank de Boer (CWI and LIACS)
• Martin Steffen (Kiel University)
• Erika Abraham (Kiel University)
• originated from discussions with
• Farhad Arbab
• Willem-Paul de Roever
• Jan Rutten

3
Roadmap

• Component-based software
• A role-based calculus
• Full-abstraction

4
Component-based software

• Goals
• Reuse of software
• Evolution of software
• Mechanisms
• Components (encapsulation of implementations)
• Ports (communication points)
• Roles (ways of describing and generating ports)
• Polymorphism
• Late binding
• Metaprogramming

5
Components

• A software component is static abstraction
  subjects to third-party composition with
  contractually specified interfaces and explicit
  context dependencies only
• Components encapsulate their internal structure
• Classes dont (inheritance breaks encapsulation)
• Components do not have run-time identity
• Object do
• Components can be (re-)composed at run-time
• Modules cant

6
Ports and roles

• Ports
• mediate all communications of a component with
  its environment.
• receiving messages from the environment
• sending messages to it
• Roles
• describe a set of valid message exchanges between
  ports (protocol)
• generate new ports subject to the specified
  protocol

7
Example
Main
init
Cln
Client
Server
Srv

• Srv cln??msgcln!ack
• Cln xNew(Srv)x!msgx?ack
• init x New(Cln)y New(Cln)

8
Roadmap

• Component-based software
• A role-based calculus
• Full-abstraction

9
The role calculus

• Similar to CSP
• Port protocols are sequential non-deterministic
  processes
• Port protocols are executed in parallel
• Similar to objects
• port protocols are associated with ports for
  their lifetime
• Variables are local to port protocols
• Similar to classes
• Roles describe generically the protocol of an
  unbounded set of ports
• Static variables are shared among port protocols
  of
• the same role

10
Syntax

• Roles role InitProtocol
• Init Initialization assignments
• Protocol composition of actions with usual
  operators rec
• Actions xn assignment
• n new(role) creation
• n!n send
• n?n receive
• n??n anonymous receive
• Variables x myrole.n n
• Names n

11
Port creation

• No observable event

r
Environment
r
Program
r
i
i
12
Port creation

• Observable event lti,egt

e
r
Environment
r
Program
r
i
i
13
Communication - internal

• No observable event

e
r
Environment
r
Program
r
i
i
14
Communication - external

• Observable event lti,e,ngt

e
r
Environment
r
Program
r
i
i
15
Operational semantics

• A program ? succeeds if it may generate a trace
• ltn0,n1gt ltnk-1,nkgtlti,e,successgt
• Two programs ?1, ?2 are may-equivalent if for any
  other program ?
• ?1,? succeeds if and only if ?2,?

16
Communication traces

• Creation events can be ordered as tree
• Creation events are binders in 2nd argument
• All names but root of tree are bound

e
i
i
lte,igtlte,igtlti,igtlte,i,igt
i
17
Knowledge

• There is no program implementing the
  communication trace
• lte,igtlti,ngtlte,n,igt
• because e cannot know n
• The port e knows n in a trace t iff
• e n
• e received n in a communication
• e is the creator of n
• e knows another e that knows n

18
A note on creation events

• External and internal creation events must be
  observable
• i must have created e
• i must have created e
• but either e created e or
• e created e

lte,egt
lti,e,igtlti,e,igtlte,i,egt
lti,egt
lti,egt
lte,egt
19
Denotational semantics

• A communication trace is executable if ports from
  the environment use only names they knows in a
  communication
• Every executable trace can be implemented by a
  set of roles.
• The semantics given by the set of all executable
  traces of a program is
• compositional
• sound (with respect to may equivalence)

20
Roadmap

• Component-based software
• A role-based calculus
• Full-abstraction

21
Swapping

• r xnew(r1)ynew(r2)x!selfy!self
• r xnew(r1)ynew(r2)y!selfx!self
• They are may-equivalent but
• lti,e1gtlti,e2gtlti,e2,igtlti,e1,igt
• is a trace only of the second role
• The external ports e1 and e2 do not know each
  other and thus cannot synchronize

22
Local renaming

• r DO xnew(r)x!self OD
• r xnew(r) x!self ynew(r)
• The first program generates events of the form
• lti,ek,igt
• The second program generates events of the form
• ltik,ek,ikgt
• An environment cannot observes this difference
  since the ports eks cannot compare their
  knowledge
• They are may-equivalent

23
Creation

• Creation events not bounding any communication
  can be removed
• Order and time of creation events does not matter
• External creator can be replaced by any ports
  with the same knowledge

24
Completeness

• The semantics given by the set of all executable
  traces of a program closed under appropriate
  abstractions for
• swapping,
• local renaming and
• creation
• is
• compositional
• sound (with respect to may equivalence)
• complete (with respect to may equivalence)

25
From traces to roles

• Sequentializing the knowledge cluster
• Passing the baton between ports that knows each
  other to fix the order of their events
• Expressing the port protocol
• Construct a statement for each external port
  involved as sender, receiver or creator in the
  events of the trace
• Defining the roles
• Using static role variables to allow each port to
  select the right statement
• Using a static role variable as a semaphore to
  control shared variable concurrency and an
  initial assignment to set it up at creation time.

26
Conclusion

• Model for component-based software
• Associating protocols to ports
• Allowing dynamic creation of ports
• Fully abstract with respect to may-testing
• why static variables?
• Roles vs. ports as first class structures
• More complex types/interfaces
• Parametric polymorphism, subtyping
• No run-time reconfiguration
• introduce a dynamic borderline between program
  and environment ports