Two Patterns in Adaptive, Distributed RealTime, Embedded Middleware

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

• Paul Rubel
• prubel_at_bbn.com

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 systems state.
• Especially Useful for facilitating runtime
  adaptations.

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.

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.

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

7
Variations

• Consistency of system state
• 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

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.

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

12
Other DRE Patterns