2. Component Composition: Reo

3. © Arbab, de Boer, Bonsangue O2C: From Objects to Components2 Composition  Composition of “black-box” component instances into a (sub)system is realized by some “glue-code” connectors that:  Enable inter-component instance communication.  Enforce exogenous coordination patterns.  Have well-defined semantics independent of component instances.  Are themselves compositionally constructed out of simpler connectors.

4. © Arbab, de Boer, Bonsangue O2C: From Objects to Components3 Ordering of Writers  Example of coordinated composition:  Glue these three component instances together such that R alternately reads items produced by W1 and W2.  A system consists of three component instances: two writers, W1 and W2, and a reader, R. R W1W2

5. © Arbab, de Boer, Bonsangue O2C: From Objects to Components4 Method Invocation  Message passing in OO invokes a method to perform an ADT operation.  The semantics of method invocation is heavy and non-trivial:  The caller must know the callee.  The caller must know the method.  The callee must (pretend) to interpret the message.  The caller suspends while the callee (pretends to) perform the method.  The caller resumes when the callee returns a result.

6. © Arbab, de Boer, Bonsangue O2C: From Objects to Components5 Operational Interface  The operations/methods provided by an ADT/class-interface impose a tight semantic binding.  The resulting relationship among subjects and objects of operations is sometimes desirable among intra-component entities.  At the inter-component level, this relationship  Weaken independence of components.  Contributes to breaking of encapsulation.  Tightens component inter-dependence.

7. © Arbab, de Boer, Bonsangue O2C: From Objects to Components6 Components OO Style  Components are fortified (collections of) objects.  Inter-component communication is through messages that invoke remote methods.  Messages may be intercepted by connectors to:  Provide services (e.g., binding and name servers)  Enforce imposed constraints  Ensure protocols  Perform assigned roles

8. © Arbab, de Boer, Bonsangue O2C: From Objects to Components7 Passive Messages  Message passing without the method invocation semantics is a more abstract and more flexible mechanism.  The sender does not suspend waiting for a result.  The receiver need not interpret the message as an operation it must perform.  The receiver is not obligated to reply.

9. © Arbab, de Boer, Bonsangue O2C: From Objects to Components8 Message Passing  Whether messages are active or passive, the send primitive is inherently targeted.  The knowledge of who the receiver is, or how it can be identified, is contained in the sender.  This makes the sender semantically dependent on (the scheme used to identify) the receiver.  This semantic dependency weakens exogenous coordination.  Third parties cannot coordinate interactions between senders and receivers of their own choice.

10. © Arbab, de Boer, Bonsangue O2C: From Objects to Components9 Anonymous Communication  Entities that communicate with each other need not know each other.  An entity exchanges identifiable sequences of passive messages with its environment only.  Inherently amenable to exogenous coordination.  Highly flexible composition possibilities.

11. © Arbab, de Boer, Bonsangue O2C: From Objects to Components10 Behavior  Operations only indirectly, implicitly, and reactively represent behavior.  Behavior can be represented, e.g., as:  Sequences of operations  Sequences of state charts  Input/output relationships  Operation sequences are too concrete and too detailed representation of behavior.  Input/output relationships more directly and abstractly represent behavior.

12. © Arbab, de Boer, Bonsangue O2C: From Objects to Components11 Abstract Behavior Type  An ABT defines an abstract behavior without specifying any detail about:  the operations that may be used to implement such behavior.  the data types they may manipulate for its realization.  An ABT is a (maximal) relation among a set of timed-data-streams.

13. © Arbab, de Boer, Bonsangue O2C: From Objects to Components12 Connectors  Connectors comprise the “glue code” that makes components interact.  Enforce policies  Mediate interactions  Coordinate activities  Currently, glue code is the most rigid, component specific, and special purpose software in component based systems.  Wish list:  No programming  Well-defined semantics, independent of components  Compositional connectors

14. © Arbab, de Boer, Bonsangue O2C: From Objects to Components13 ABT Implementation  The implementation of an ABT is a set of process specifications  Its instantiation is a set of processes communicating with the environment only through read and write operations on the channel ends according to the behavior specified by the ABT

15. © Arbab, de Boer, Bonsangue O2C: From Objects to Components14 Mobile Channels  Mobile channels  The identity of a channel end can be passed around as any data item, and be known to many ABT instances  The connection of a channel end can move from one component instance to another, without affecting the knowledge of the other end of the same channel  Why?  To describe dynamic interfaces  To describe dynamic networks of communicating ABT instances

16. Reo A Calculus for Composition of Connectors Mobile channels as primitive connectors Construction of complex connectors Semantic independence of connectors Expressiveness of composition Visual composition

17. © Arbab, de Boer, Bonsangue O2C: From Objects to Components16 Reo  Reo is based on a calculus for compositional construction of component connectors.  Both components and connectors in Reo are distributed and mobile.  Reo connectors are dynamically reconfigurable.  Both components and connectors are uniformly represented as ABTs.  A component is any general ABT.  A connector is any ABT that can be constructed out of a user- defined set of primitive connectors (channels).  [Dynamic Kahn networks, mobile channels, Broy’s timed dataflow]

18. © Arbab, de Boer, Bonsangue O2C: From Objects to Components17 Channels  Atomic connectors in Reo are called channels.  A channel is an ABT defined as a binary relationship between two timed-data streams.  Channel in Reo is a generalization of its common notion:  Always has two ends  Two types of channel ends  Source: data enters into the channel  Sink: data leaves the channel  A channel can have two sources or two sinks

19. © Arbab, de Boer, Bonsangue O2C: From Objects to Components18 A Sample of Channels  Synchronous channel  write/take  Synchronous drain: two sources  write/write  Synchronous spout: two sinks  take/take  Lossy synchronous channel  Asynchronous FIFO1 channel  write/take

20. © Arbab, de Boer, Bonsangue O2C: From Objects to Components19  Flow through  Merge + replication combo  Non-deterministic merge  Replication Join a b a c c b a bc

21. © Arbab, de Boer, Bonsangue O2C: From Objects to Components20 !x? ? ? ac b Regulated Reads (TC)  With a synchronous channel on b, takes from c produce successive values of a.  Values pass through the junction only whenever something is taken from b.  A take from b, then, is the cue for the completion of a write-take pair on a and c.  We express this as c = (b:a)*.  Symmetrically, we have b = (c:a)*. !xx x

22. © Arbab, de Boer, Bonsangue O2C: From Objects to Components21 Regulated Reads (WC)  With a synchronous drain, takes from c produce successive values of a.  Values pass through the junction only whenever something is written to b.  A write on b, then, is the cue for the completion of a write-take pair on a and c.  We express this as c = (b/a)*. ac b

23. © Arbab, de Boer, Bonsangue O2C: From Objects to Components22 Flow Synchronization  If all channels are synchronous, takes from c and d are synchronized: barrier synchronization.  If only the drain is asynchronous, no simultaneous takes are possible on c and d. a b c d !x ? ? ? !y ? ? x y

24. © Arbab, de Boer, Bonsangue O2C: From Objects to Components23 !1 !2 ? 2 1!3 !42 1!1 !2 Order a And b  Subsequent takes from c retrieve the elements of the stream (ab)*  Both a and b must be present before a pair can go through. a b c 4,3,2,1 4 ?3,2,1 4 !3 !4 ?2,1!3 !4 2,1!3 !42 ?1!3 2 1

25. © Arbab, de Boer, Bonsangue O2C: From Objects to Components24 Order a, b, And c  Subsequent takes from z retrieve the elements of the stream (abc)*  All three must be present before a triplet can go through. a b c z

26. © Arbab, de Boer, Bonsangue O2C: From Objects to Components25 Take a when b or c  A take from d succeeds only if there is a value written to b or c.  The values taken from d are elements of the stream a*  We have d = ((b|c)/a)* a bc d

27. © Arbab, de Boer, Bonsangue O2C: From Objects to Components26 ab c d Sequencer  Writes to a, b, c, and d will succeed cyclically and in that order. o !1 oo !2 o !3!1!2 o !1!2 o o !4!2 o o

28. © Arbab, de Boer, Bonsangue O2C: From Objects to Components27 Expressiveness  What ABTs can be produced by composition of a given set of channels?  With a small set of 5 channel types, the equivalent of regular expressions can be constructed.  Turing equivalence is possible with the above set of channel types, plus unbounded FIFO.

29. © Arbab, de Boer, Bonsangue O2C: From Objects to Components28 Another c = (ab)*  An a can pass through even if its pairing b is not yet available. sequencer b a c

30. © Arbab, de Boer, Bonsangue O2C: From Objects to Components29 c = (aab)* sequencer b a c

31. © Arbab, de Boer, Bonsangue O2C: From Objects to Components30 Inhibitor  All values flow from d to c until a value is written to i.  A write to i inhibits (i.e., blocks) further writes to both d and i. o dc i

32. © Arbab, de Boer, Bonsangue O2C: From Objects to Components31 C = a* | b*  The drain is asynchronous; dashed arrows show synchronous lossy channels; all other channels are synchronous. Inhibitor 2 d i b a Inhibitor 1 i d c

33. © Arbab, de Boer, Bonsangue O2C: From Objects to Components32 Asynchronous Drain zAn AsyncDrain can be composed out of a SyncDrain and 3 (or 2) Sync channels.

34. © Arbab, de Boer, Bonsangue O2C: From Objects to Components33 Exclusive Router  A value written to a flows through to either b or c, but never to both. a b c

35. © Arbab, de Boer, Bonsangue O2C: From Objects to Components34 Inclusive Router  A value written to a flows through to either b or c, or to both. a bc

36. © Arbab, de Boer, Bonsangue O2C: From Objects to Components35 Overflow Lossy FIFO1 zA FIFO1 channel that accepts but loses new incoming values if its buffer is full.

37. © Arbab, de Boer, Bonsangue O2C: From Objects to Components36 Shift Lossy FIFO1  A FIFO1 channel that loses its old buffer contents, if necessary, to make room for new incoming values. o XRouter

38. © Arbab, de Boer, Bonsangue O2C: From Objects to Components37 Sequencer With Reset  Same as a simple sequencer, except that a write to reset forces the sequencer to start over with a. XRouter o d c b a reset

39. © Arbab, de Boer, Bonsangue O2C: From Objects to Components38 NS Ticket Vending Machine

40. © Arbab, de Boer, Bonsangue O2C: From Objects to Components39 Ticket Machine Components  We assume the following components are available:  Destination: Get user’s destination code  Type: Get user’s ticket type  Price: Find the price of the ticket  Payment: Handle user’s payment  Print: Print and dispense the ticket  Clock: Periodically emit date and time  Cancel: Produce a token whenever Cancel is pressed

41. © Arbab, de Boer, Bonsangue O2C: From Objects to Components40 Get-Destination Component  Destination has two input and one output ports:  trigger: input  cancel: input  dest: output  When triggered by a token on its trigger port, it:  interacts with the user through numeric keypad (2) and display to obtain the destination code  produces the destination code on its dest port  A token on its cancel port resets the component

42. © Arbab, de Boer, Bonsangue O2C: From Objects to Components41 Get-Type Component  Type has two input and one output ports:  trigger: input  cancel: input  type: output  When triggered by a token on its trigger port, it:  interacts with the user through special keypad (3) to obtain the ticket type  produces the ticket type code on its type port  A token on its cancel port resets the component

43. © Arbab, de Boer, Bonsangue O2C: From Objects to Components42 Lookup-Price Component  Price has 4 input and one output ports:  here: input  dest: input  type: input  time: input  price: output  When all of its input ports have values, it  looks up the price if the specified ticket in its database  produces the ticket price on its price port

44. © Arbab, de Boer, Bonsangue O2C: From Objects to Components43 Payment Component  Payment has two input and two output ports:  price: input  cancel: input  yes: output  no: output  When triggered by a value on its price port, it:  interacts with the user to obtain the proper payment  produces a token on its yes or no port to indicate whether the full payment was made or not  A token on its cancel port resets the component

45. © Arbab, de Boer, Bonsangue O2C: From Objects to Components44 Print Component  Print has 6 input and one output ports:  here: input  dest: input  type: input  time: input  price: input  done: output  When all of its input ports have values, it  Prints and dispenses the ticket  produces a token on its done port

46. © Arbab, de Boer, Bonsangue O2C: From Objects to Components45 Ticket Machine Composition Here XRouter Print Payment Price Clock Type Destination XRouter Cancel Sequencer with Reset

47. © Arbab, de Boer, Bonsangue O2C: From Objects to Components46 Reo  A compositional paradigm for coordination of mobile components, based on mobile channels.  Provides a set of operations for components to:  Create and compose channels into complex connectors.  Perform I/O operations on connectors, as a result of which the participating components are coordinated.  The semantics of connectors are independent of components.

48. © Arbab, de Boer, Bonsangue O2C: From Objects to Components47 Beyond Channels createconnectdisconnectreadtakewritewaitforgetmovejoinsplit _create_connect_disconnect_read_take_write_wait_forget Reo Component instances Channels Channels and Channel-ends Nodes and Connectors _move hide

49. © Arbab, de Boer, Bonsangue O2C: From Objects to Components48 Common Behavior All channels in Reo must implement the following set of operations with the “same” semantics:  Simple topological operations  Dynamic channel creation and (dis)connection of channel ends from/to component instances.  Input/Output operations  Reading/writing of data items from/to channel ends.  Inquiry operations  Checking for conditions of interest.

50. © Arbab, de Boer, Bonsangue O2C: From Objects to Components49 Topological Operations  _create(type [, filter])  Returns a pair of channel ends for a new channel of the specified type with its associated filter.  _connect([t,] cev)  Waits (indefinitely or for the specified time-out, t) to connect the specified channel end, cev, to the component instance.  _disconnect(cev)  Disconnects the specified channel end, cev, from the component instance.  _forget(cev)  The component performing this operation loses all its references to the specified channel end, cev.

51. © Arbab, de Boer, Bonsangue O2C: From Objects to Components50 Input/Output Operations  _read([t,] inp[, v [, pat]])  Suspends the active entity that performs it (indefinitely or for the specified time-out, t) waiting for a value (that matches with pat) to become available for reading from the sink channel end inp into the variable v. The value item is not removed from the channel.  _take([t,] inp[, v [, pat]])  Removes a value from inp and behaves analogous to read.  _write([t,] outp, v)  Suspends the active entity that performs it (indefinitely or for the specified time-out, t) until it succeeds to write the contents of the variable v into the source channel end outp.

52. © Arbab, de Boer, Bonsangue O2C: From Objects to Components51 Inquiry Operations  _wait([t,] conds)  Suspends the active entity that performs it (indefinitely or for the specified time-out, t) waiting for the specified conditions to become true.  The argument conds is a boolean combination of a set of predefined primitive wait conditions on a channel end, cev, which includes: connected(cev) disconnected(cev) empty(cev) full(cev) etc.

53. © Arbab, de Boer, Bonsangue O2C: From Objects to Components52 Connectors  A connector consists of a set of channels organized in a graph of nodes and edges where:  Zero or more channel ends coincide on every node.  There is an edge between two (not necessarily distinct) nodes iff there is a channel whose ends coincide on those nodes.  Every channel “is” a (simple) connector.

54. © Arbab, de Boer, Bonsangue O2C: From Objects to Components53 Node Types  A node is called a  source node, if it has no coincident sink channel ends.  sink node, if it has no coincident source channel ends.  mixed node, otherwise.

55. © Arbab, de Boer, Bonsangue O2C: From Objects to Components54 Node Operations  The Reo operations on nodes can be divided into three categories:  Topological and inquiry operations  I/O operations  Composition and abstraction operations

56. © Arbab, de Boer, Bonsangue O2C: From Objects to Components55 Node Topology Operations Reo defines the following topological operations on a node N:  create(type [, filter])  Performs a _create(type [, filter]) and returns a pair of nodes for the resulting channels ends.  connect([t,] N)  If N is not a mixed node, atomically performs _connect([t,] x),.  disconnect(N)  Atomically performs _disconnect([t,] x),.  forget(N)  Atomically performs _forget([t,] x),.

57. © Arbab, de Boer, Bonsangue O2C: From Objects to Components56 Node Inquiry Operations  wait([t,] nconds)  Suspends the active entity that performs it (indefinitely or for the specified time-out, t) waiting for the specified conditions to become true.  The argument nconds is a boolean combination of a set of predefined primitive wait conditions on nodes: connected(N), connectedAll(N) disconnected(N), disconnectedAll(N) empty(N), emptyAll(N) full(N), fullAll(N) etc.

58. © Arbab, de Boer, Bonsangue O2C: From Objects to Components57 Node I/O Operations  read([t,] N[, v [, pat]])  If N is a sink node connected to the component instance performing this operation, this operation succeeds when a value compatible with pat is non-deterministically read from some channel end into the variable v.  take([t,] N[, v [, pat]])  Similar to read, but the value is also removed from the channel.  write([t,] N, v)  If N is a source node connected to the component instance performing this operation, this operation succeeds when a copy of the value in v is written to every channel end.

59. © Arbab, de Boer, Bonsangue O2C: From Objects to Components58 Node Composition  join(N1, N2)  If at least one of the nodes N1 and N2 is connected to the component instance performing this operation, it produces a new node that results from the destructive merge of N1 and N2.  split(N[, quoin])  Produces a new node N’ and splits the channels ends that coincide on N between N and N’.  hide(N)  Hides the node N such that it cannot be used in any other node operation.

60. © Arbab, de Boer, Bonsangue O2C: From Objects to Components59 Writing to a Node  A write(t, N, d) where, remains pending on the node N until either:  Its time-out expires; or  accepts(N,d) becomes true, and:  the set of operations _write(0, xc, d), for all channel ends for which takes(xc, d) is true, is performed atomically.

61. © Arbab, de Boer, Bonsangue O2C: From Objects to Components60 Taking from a Node  A take(t, N, v, p) remains pending on the node N until either:  Its time-out expires; or  and:  a channel end is selected non- deterministically such that and the operation _take(0, x, v, p) is performed.

62. © Arbab, de Boer, Bonsangue O2C: From Objects to Components61 Semantics of Mixed Nodes  Mixed nodes cannot be connected to components.  No read, take, or write operations can be performed on mixed nodes.  A mixed node automatically transfers all eligible data items from its coincident sinks to its coincident sources.  The multi-set of data items that are eligible for transfer at a mixed node is defined as:

63. © Arbab, de Boer, Bonsangue O2C: From Objects to Components62 Flow Through Mixed Nodes while (true) do suspend until for each do select a _take(0, y, v, d) for each do if (takes(x, d)) then _write(0, x, d) done

64. © Arbab, de Boer, Bonsangue O2C: From Objects to Components63 Summary of Reo RReo is a powerful expressive coordination language. CComplex connectors can be built compositionally out of simpler ones. SSemantics of connectors is independent of the components/entities that use them. MMobility (of components and connectors) is inherent and implicit in Reo.