1 / 63

Component Composition: Reo

Component Composition: Reo. 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.

orien
Download Presentation

Component Composition: Reo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component Composition: Reo

  2. 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. O2C: From Objects to Components

  3. 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. W1 W2 R O2C: From Objects to Components

  4. 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. O2C: From Objects to Components

  5. 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. O2C: From Objects to Components

  6. 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 O2C: From Objects to Components

  7. 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. O2C: From Objects to Components

  8. 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. O2C: From Objects to Components

  9. 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. O2C: From Objects to Components

  10. 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. O2C: From Objects to Components

  11. 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. O2C: From Objects to Components

  12. 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 O2C: From Objects to Components

  13. 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 O2C: From Objects to Components

  14. 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 O2C: From Objects to Components

  15. 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

  16. 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] O2C: From Objects to Components

  17. 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: dataleaves the channel • A channel can have two sources or two sinks O2C: From Objects to Components

  18. 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 O2C: From Objects to Components

  19. Join • Flow through • Merge + replication combo • Non-deterministic merge • Replication a b c a b c b a c O2C: From Objects to Components

  20. a c x !x !x ? ? b x ? 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)*. !x O2C: From Objects to Components

  21. a c b 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)*. O2C: From Objects to Components

  22. a c !x !x !x ? ? ? d x b !y ? ? y 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. !x O2C: From Objects to Components

  23. a c !1 !3 !3 !3 !3 !1 !3 ? ? ? ? 3,2,1 2,1 2,1 3,2,1 1 1 1 1 b !4 !4 !4 !2 !4 !2 4 2 2 4 2 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. !1 4,3,2,1 O2C: From Objects to Components

  24. 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 z b c O2C: From Objects to Components

  25. a d b c 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)* O2C: From Objects to Components

  26. c a b d !3 !1 !1 !1 !1 !4 !2 !2 !2 !2 !2 !2 o o o o o o o Sequencer • Writes to a, b, c, and d will succeed cyclically and in that order. o o O2C: From Objects to Components

  27. 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. O2C: From Objects to Components

  28. b c a sequencer Another c = (ab)* • An a can pass through even if its pairing b is not yet available. O2C: From Objects to Components

  29. c = (aab)* c b a sequencer O2C: From Objects to Components

  30. o 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. d c i O2C: From Objects to Components

  31. C = a* | b* • The drain is asynchronous; dashed arrows show synchronous lossy channels; all other channels are synchronous. a d Inhibitor1 i c i Inhibitor2 b d O2C: From Objects to Components

  32. Asynchronous Drain • An AsyncDrain can be composed out of a SyncDrain and 3 (or 2) Sync channels. O2C: From Objects to Components

  33. a b c Exclusive Router • A value written to a flows through to either b or c, but never to both. O2C: From Objects to Components

  34. Inclusive Router • A value written to a flows through to either b or c, or to both. a b c O2C: From Objects to Components

  35. Overflow Lossy FIFO1 • A FIFO1 channel that accepts but loses new incoming values if its buffer is full. O2C: From Objects to Components

  36. XRouter Shift Lossy FIFO1 • A FIFO1 channel that loses its old buffer contents, if necessary, to make room for new incoming values. o O2C: From Objects to Components

  37. XRouter XRouter XRouter XRouter Sequencer With Reset • Same as a simple sequencer, except that a write to reset forces the sequencer to start over with a. c b d a o reset O2C: From Objects to Components

  38. NS Ticket Vending Machine O2C: From Objects to Components

  39. 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 O2C: From Objects to Components

  40. 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 O2C: From Objects to Components

  41. 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 O2C: From Objects to Components

  42. 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 O2C: From Objects to Components

  43. 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 O2C: From Objects to Components

  44. 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 O2C: From Objects to Components

  45. Print Payment Price Clock Type Destination Ticket Machine Composition Cancel Here XRouter XRouter Sequencer with Reset O2C: From Objects to Components

  46. 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. O2C: From Objects to Components

  47. Beyond Channels Component instances create forget connect disconnect read take write wait move join split hide Nodes and Connectors Reo _create _forget _connect _disconnect _read _take _write _wait _move Channels and Channel-ends Channels O2C: From Objects to Components

  48. 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. O2C: From Objects to Components

  49. 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. O2C: From Objects to Components

  50. 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. O2C: From Objects to Components

More Related