1. Two Patterns in Adaptive, Distributed Real-Time, Embedded Middleware
Paul Rubel

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

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

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

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

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

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

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

9. 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?

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

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

12. Other DRE Patterns