Components, roles, and ports

1. FMCO 2004 – Leiden, NL Components, roles, and ports 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 Components, roles, and ports

3. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

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 Components, roles, and ports

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 don’t (inheritance breaks encapsulation) • Components do not have run-time identity • Object do • Components can be (re-)composed at run-time • Modules can’t Components, roles, and ports

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 Components, roles, and ports

7. Example • Srv == cln??msg;cln!ack • Cln == x:=New(Srv);x!msg;x?ack • init == x:= New(Cln);y:= New(Cln) Main init Cln Client Server Srv Components, roles, and ports

8. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

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 Components, roles, and ports

10. Syntax • Roles role == Init;Protocol • Init Initialization assignments • Protocol composition of actions with usual operators ; + rec • Actions x:=n assignment n:= new(role) creation n!n send n?n receive n??n anonymous receive • Variables x::= myrole.n | n • Names n Components, roles, and ports

11. Port creation • No observable event r’’ Environment r’ Program r i i’ Components, roles, and ports

12. Port creation • Observable event <i,e> e r’’ Environment r’ Program r i i’ Components, roles, and ports

13. Communication - internal • No observable event e r’’ Environment r’ Program r i i’ Components, roles, and ports

14. Communication - external • Observable event <i,e,n> e r’’ Environment r’ Program r i i’ Components, roles, and ports

15. Operational semantics • A program  succeeds if it may generate a trace <n0,n1> …<nk-1,nk><i,e,success> • Two programs 1, 2 are may-equivalent if for any other program  1, succeeds if and only if 2, Components, roles, and ports

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’ <e,i><e,i’><i,i’’><e,i’,i> i’’ Components, roles, and ports

17. Knowledge • There is no program implementing the communication trace <e,i><i,n><e,n,i> 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 Components, roles, and ports

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’’ <e’,e’’> <i,e’> <i,e> <i,e,i><i,e’,i><e’’,i,e’’> <e,e’’> Components, roles, and ports

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) Components, roles, and ports

20. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

21. Swapping r == x:=new(r1);y:=new(r2);x!self;y!self r == … + x:=new(r1);y:=new(r2);y!self;x!self • They are may-equivalent but <i,e1><i,e2><i,e2,i><i,e1,i> is a trace only of the second role • The external ports e1 and e2 do not know each other and thus cannot synchronize Components, roles, and ports

22. Local renaming r == DO x:=new(r’);x!self OD r == x:=new(r’); x!self; y:=new(r) • The first program generates events of the form <i,ek,i> • The second program generates events of the form <ik,ek,ik> • An environment cannot observes this difference since the ports ek’s cannot compare their knowledge • They are may-equivalent Components, roles, and ports

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 Components, roles, and ports

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) Components, roles, and ports

25. From traces to roles • Sequentializing the knowledge cluster • Passing the baton between ports that knows each other to fix the orderof 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. Components, roles, and ports

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 Components, roles, and ports