1 / 18

The Component Interaction Domain: Modeling Event-Driven and Demand-Driven Applications

The Component Interaction Domain: Modeling Event-Driven and Demand-Driven Applications. Xiaojun Liu Yang Zhao. Outline. Interaction between Software Components Software Framework Examples The CORBA Event Service The Click Modular Router The Component Interaction (CI) Domain Demonstration

makara
Download Presentation

The Component Interaction Domain: Modeling Event-Driven and Demand-Driven Applications

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. The Component Interaction Domain: Modeling Event-Driven and Demand-Driven Applications Xiaojun Liu Yang Zhao

  2. Outline • Interaction between Software Components • Software Framework Examples • The CORBA Event Service • The Click Modular Router • The Component Interaction (CI) Domain • Demonstration • Current Status and Future Work

  3. Aspects of Component Interaction • Making sense of the information exchanged • E.g. a pure event notification, or an array of floating-point numbers • Managed by the type system • The communication protocol • E.g. rendezvous, or read from/write to a FIFO queue • Managed by a model of computation

  4. Aspects of Component Interaction • Initiation • Which participant initiates the interaction? • What components can initiate interaction? • Control flow • How do interacting components obtain the execution context? • Timing…

  5. The CORBA Event Service • Support asynchronous, decoupled communication between objects

  6. The Push Model Consumer push() Supplier push() Event Channel push() Consumer Supplier push() push() Consumer • The supplier initiates the transfer of data • The consumer reacts to supplied data • The event channel provides the execution context for the consumer

  7. The consumer initiates the transfer of data The supplier reacts to demand of data The event channel provides the execution context for the supplier The Pull Model Consumer pull() Supplier pull() Event Channel pull() Consumer Supplier pull() pull() Consumer

  8. Mixed Models • Push supplier and pull consumer • The event channel acts as an event queue • Pull supplier and push consumer • The event channel must act as an active mediator for any interaction to take place Event Channel Supplier Consumer push() pull() Event Channel Supplier Consumer pull() push()

  9. Complex Mixture Consumer pull() pull() Event Channel Supplier push() Event Channel Consumer push() push() pull() Supplier/ Consumer push() pull() Supplier/ Consumer Supplier/ Consumer pull() pull() Event Channel Supplier Supplier/ Consumer Event Channel push() push() push() pull() pull() Supplier Consumer

  10. The Click Modular Router • Elements are C++ objects that interact by making method calls • Packets are passed as method argument or return value • Flexible, configurable, and highly efficient routers have been built with this software architecture E. Kohler et al., “The Click Modular Router,” ACM Transactions on Computer Systems, 18(3), August 2000, pages 263-297.

  11. The Component Interaction Domain • Push/pull interaction • Active/passive actors • Multi-threaded execution

  12. Push/Pull Interaction • Push model • Event-driven applications • Pull model • Demand-driven applications

  13. Active Actors • Active actors initiate all computation in the model • Source actors with push output • Sink actors with pull input • Actors with pull input and push output

  14. Passive Actors • Passive actors react to pushed event or pull demand

  15. Multi-Threaded Execution • Each active actor has its own execution thread • Passive actors share the same execution thread as the director

  16. A Router Model in the CI Domain

  17. CI vs. the Click Router Architecture • Click is a specialized, highly efficient, runtime software architecture based on object-oriented programming. Router elements interact by making method calls. The control flow is fixed once the router is built. • The CI domain provides a more general model architecture based on actor-oriented programming. Actor interaction is mediated by the director, so is more decoupled. The director (or code generator) can partition a model and choose a different analysis/scheduling strategy for each part.

  18. Current Status and Future Work • Current status • A preliminary implementation is included in the current release • Future work • Design the infrastructure for building actors with mixed push/pull input ports and output ports • Partitioning of CI models for scheduling and allocating execution threads • Explore the relation to dynamic dataflow that uses both data-driven and demand-driven execution strategies

More Related