An Open Framework for Dynamic Reconfiguration

1
An Open Framework for Dynamic Reconfiguration

• Reviewed by
• Yu Ping, Lau
• AmitPal Singh

2
Introduction

• OpenRec is an open framework for managing dynamic
  reconfiguration
• measure costs of particular run-time changes
• support multiple reconfiguration algorithms to be
  modeled, implemented and compared

3
Motivation

• Adaptability
• System must adaptable to unpredictable
  environments
• E.g. mobile device
• High availability
• System must be available during modifying
• E.g. Space station control system

4
General Approaches

• Ad hoc approaches
• Tends to be system specific
• Change management systems
• Operate on component-based system
• With single and fixed reconfiguration algorithms

5
Key Issues

• Support for multiple extensible reconfiguration
  algorithms
• New algorithm can be added to the managing system
• Each algorithm has its own characteristic and
  constraints at run-time, i.e. not best fitted
  with all given application

6
Key Issues

• Support for measuring the cost of reconfiguration
• Non-functional attributes
• Availability, response-time, and throughput
• Quantifiable attributes
• Time taken for reconfiguration
• The degree of disruption

7
Key Issues

• Support dynamic reconfiguration framework
• Management system should be separated from its
  managing application
• E.g. dynamics changing of reconfiguration
  algorithms

8
Core technologies

• The underlying technologies of OpenRec
• Components
• Reflection
• Dynamic reconfiguration

9
Components

• Component is a service provider with
• A set of rule performs application logic
• Interfaces define services to others
• Encapsulated state
• Components vs. Object
• Explicit required interfaces
• Interconnection independence
• Conformance to a binary standard

10
Components

• Component framework - collection of rules and
  interfaces that govern the interaction of a set
  of components plugged into them
• Architectural properties such as constraints on
  components, connectors and connectivity

11
Components in reconfiguration systems

• Configuration independence means
• Components are loosely connected
• Components dependencies are explicit and they can
  be modified at runtime
• Adding new components
• Removing components
• Replacing components
• Changing connectivity

12
Reflection

• Reflection is the ability for a system to reason
  about and act upon itself
• The aim is to promote openness and flexibility
• Base level
• Corresponds to application components with
  argument from meta level interface
• Meta level
• Can be invoked in run-time

13
Reflection

• Structural reflection
• Discover neighbors and corresponded information
  by inspecting interface, such as encapsulated
  state
• Modeling structure of components and connectors
  which can be modified
• Behavioral reflection
• Monitoring inter-component communications with
  interceptors

14
Dynamic reconfiguration

• Issues on preserving system integrity during
  reconfiguration
• Synchronizing change with the executing system
• Preserving persistent state

15
Dynamic reconfiguration

• Maintain system integrity can be achieved by
  using reconfiguration algorithms
• Examines changes
• Identify a related components
• Direct to safe state
• Perform changes
• Preserve persistent state
• Assuem

16
Dynamic reconfiguration

• Reconfiguration algorithms
• Approach to reaching the safe state
• Static use knowledge of configuration
• Dynamic use run-time information
• Unit of disturbance
• Halt components
• Connector-blocking

17
Dynamic reconfiguration

• Common constraint on algorithms
• Prescribed communication paradigms
• Need for components to implement a correct change
  management interface
• Prerequisite knowledge of component properties

18
Architecture

• There are 3 conceptual layers
• Change Driver
• Reconfiguration Manager
• Application
• - Each layer is constructed using OpenRec
  reflective component model.

19
Component model
20
Functioning of different layers

• Change Driver
• Highly available system
• Change request are submitted in the form of
  OpenRecML script to the change driver.
• Adaptive system
• Change driver determines if and when change is
  necessary.
• Reconfiguration Manager
• Responsible for changing the running application
  using a reconfiguration algorithm.
• Application layer
• Comprises the configuration of components and
  connectors that comprise the application.
• Provides a point for plugging in monitoring
  components.

21
Support for Multiple algorithms

• allows developers to add more than one
  reconfiguration algorithm.
• able to observe the behavior of algorithms and
  cost associated in using them.
• Works like

22
Support for multiple algorithm (cont)

• Based on this knowledge when start method is
  called, the algorithm is aware of which
  components are involved in reconfiguration.
• The algorithm then exploit the self awareness
  property of application component using the
  meta-level interface.
• For example implementation of Kramer Magees
  uses each component metaDataManager to determine
  whether its component implements the required
  change management interface.
• Connection block method allows the pending
  request to be aborted or queued.

23
Algorithm behavior and the cost

• Provides an API for two kinds of monitoring
• System monitoring
• Through connection Plugin interface, plugin can
  receive events related to configuration level
  changes.
• These plugin helps in notifying the structural
  changes such as component being added, removed,
  connector blocking etc.
• Local monitoring
• Implementation of interaction Plugin interface is
  registered with particular component and thus
  receive events from a specified subset of the
  configuration.
• For calculating the cost
• instrumentation and visualization tools are used

24
Openness

• OpenRec offers 3 distinct type of openness
• Reconfiguration management
• Allows deployment time configuration and run
  time reconfiguration of the change driver and
  reconfiguration manager layer.
• Application component
• Have an open implementation which facilitates
  their dynamic reconfiguration.
• Plugins
• Developers are free to write their own plugin
  component and register them with OpenRec.
• Can be configured with an extensible set of
  reconfiguration algorithm.
• Enables the developers to create new algorithm as
  new application emerges with properties not
  readily suited to existed algorithm.

25
Mitchells algorithm

• Creates a chain of replacement processing
  components.
• Breaks the connection between the source and the
  first processing component of the original chain.
• Connect the source to the first component of the
  replacement chain.
• Since original chain is no longer being fed for
  the source, it will exhaust stress data to
  process.
• The algorithm switches the connection b/w the
  destination component and the last processing
  component of original chain to the last component
  of the replacement chain.

26
Mitchells algorithm (cont)

• Mitchell algorithm is fundamentally different
  from general algorithm which requires that the
  safe state be reached and maintained for the
  duration of the change.
• It uses redundancy to exploit the stateless
  property of the component and relaxes the
  accepted definition of safe state.
• The algorithm can be used to reduce the
  reconfiguration cost below those that would be
  experienced using more general algorithms.
• A variation of Mitchells algorithm could be used
  to reconfigure a pipe and filter module.

27
Degree of separation

• Two important degree of separation
• Change driver/ Reconfiguration manager
• Change driver communicates the change request
  using OpenRecML, to the current reconfiguration
  manager.
• The effect of this separation is that algorithm
  component need only be concerned with
  implementing a particular reconfiguration
  algorithm.
• Reconfiguration Manager/ Application
• Reconfiguration manager is independent of any
  particular application.
• This separation simplifies development since
  developers can work at the application level
  without regards to specific reconfiguration
  algorithm and vice versa.
• Promote reuse of component within the layer.

28
Example

• Simple EPOS (electronic point of sale)
  simulation is described using openRec.
• The simulation comprise 3 kind of components
• EPOS terminal
• Collator
• Report generator
• Works
• Whenever the sale is made at an EPOS component,
  it sends the details of the sale to the collator
  which acts as a persistent repository for sales
  data.
• The collator is also connected to a single report
  generator to which it periodically send processed
  data.
• Each component type is implemented using
  OpenRecs component model, specifically
  inheriting from the component and all
  communication is handled by explicit invocation
  connector.

29
Example (cont)

• The initial configuration constitutes 5 epos
  components, 1 collator, 1 report generator.
• Required interfaces that are connected to a
  component to be replaced are blocked and any
  invocation sent on those interface are queued
  during reconfiguration.
• A component which is to be replaced is
  synchronized when it has completed processing any
  incoming requests on its provided interfaces and
  when any invocation made on its required
  interfaces have completed.

30
Visualization and reconfiguration tool
31
Question

• ?