Two Patterns in Adaptive, Distributed Real-Time, Embedded Middleware Paul Rubel prubel@bbn.com

Patterns Presented Snapshot for obtaining a useful approximation of the system state. QoS Contract for managing adaptive decisions and tradeoffs

Snapshot Provide a useful approximation of a consistent view of the system’s state. Especially Useful for facilitating runtime adaptations. Refresh data as it is available under the covers from apps who use the information Easily add new consumers

Problem: Finding Approximately Consistent System State We can trade strict consistency for speed Strict consistency is expensive By using approximations of state we can often get a “good enough” answer faster. Not necessarily totally consistent, approximate

Problem continued For loose coupling, reuse, and location transparency Users of state need not be aware of each other Gathering and aggregating should be disjoint. Promotes loose coupling and reuse Location transparency

Implementation Implement system conditions Wrap lower level state information Place system conditions at points of interest Implement aggregate system conditions Support views at different levels Hide underlying architecture Aggregate, perhaps replicated values

Variations Consistency of system state Reporting of state to consumers Loose, where coherency is best effort but responses can be quicker Consistent, via transactions which may be slow but the results will be internally consistent Reporting of state to consumers Push/Pull Publish/Subscribe Pub sub in here too

QoS Contract The QoS Contract pattern decouples quality of service negotiation, measurement, adaptation, and management from a functional application. Manages change via middleware. Promotes loose coupling of adaptation and functional components. How would you architect an application to meet this goal? Promotes Loose Coupling Managing change via middleware

Problem: Competing Goals We may not be able to provide everyone all the resources they would like. How do we make and manage reasonable tradeoffs?

Trade-off Issues Consider only issues of interest Bandwidth may be important while disk space is not Combinations of competing issues How do we trade off bandwidth versus compression in different situations? Controlling complexity Do all the issues need to interact with one another? Customization for different environments

Implementation Determine regions of concern Define System Conditions What do we do when more CPU is available than bandwidth? Define System Conditions What will we need to measure and control to make our decisions? Create predicates that define regions with respect to system conditions Determine transitions and actions What do we do when we move from one region to the next? Integrate with the application System conditions, automatic and manual for users. Assign QoS requirements in accordance w/ system modes

Other DRE Patterns