Self Healing and Dynamic Construction Framework:

1
Self Healing and Dynamic Construction Framework

• Applications of the Software Matrix

Anirudha Krishna Advisor Dr. James Fawcett 9
Dec 2005
2
Goals of the Research

• Exploring ideas to simplify design of complex
  systems
• Reuse
• Configurability
• Automation
• Build a Framework to enable systems to Self Heal
• Explore the usability of the Software Matrix in
  this context

3
Self Healing and Dynamic Construction

• Self Healing System that is able to recover
  from failure without external intervention
• Dynamic Construction System that can add
  functionality to itself at run time
• Software Matrix Cell based development model
  focused on reuse

4
Matrix Framework

• Framework for Reuse
• Integrated Network of Cells
• Dynamic Application Composition
• Mediator based Communication

5
Matrix Framework

• Five Elements of the Software Matrix
• Cell
• Mediator
• Message Passing Support
• Executive
• Network Support

6
Matrix Cell

• Four Components
• Cell ID
• Message Passing Structure
• Capability List
• Processing

7
Matrix Messaging

• Mediator centric Communication
• XML Based Messages
• Synchronous and Asynchronous Message Passing
• Common Local and Network Message Formats

8
Matrix Executive

• Directory Watcher
• Reflection to load Cells
• Common Interface Register Function
• Start Cell Initialization
• Application Startup

9
Additions to the Matrix Network Support

• Replaceable Network Cell
• Provides both Server and Receiver Functions
• Provision for specifying Network Destinations for
  Messages
• Asynchronous and Synchronous communication
• Concept of Matrix Node

10
Self Healing Architecture

• Matrix Style Cell Based Framework
• Recover from Cell / Node Failures
• Three main components
• Default Handler Detect Failures
• Address Server Locate Message Handlers
• Repository Server Restore Failed Cells
• Configurable to required level of functionality

11
(No Transcript)
12
Address Server

• Maintains a Address table of Message Handlers and
  their locations
• Contains logic for evaluating a request as a Cell
  failure or lack of Addressing Information
• Requests reload from Repository and manages
  installation of new Cell
• Provides capability for recovering from
  Repository Server Failures

13
(No Transcript)
14
Default Handler

• Receives Messages from
• Failed deliveries Network / Local
• Destination not specified
• Maintains cache of Network Addresses
• Discovers new Address either from local cache or
  by contacting the Address Server

15
Default Handler

• Forwards the failed message to the new
  destination
• Supports Recovery from Address Server Failures
• Provides information on Message Handling
  capabilities of the node

16
Repository

• Maintains a static store of all Cells used by the
  Application
• Responds to queries requesting Message Handlers
  by identifying and retrieving the required File
• Provides support for runtime startup after Failure

17
(No Transcript)
18
Application Cell Failure

• Failure of Node detected by Network Cell
• Message Forwarded to default handler
• Request to Address Server generates Reload from
  Repository
• Default Handler forwards original message to new
  location

19
Framework Cell Failure

• Applications Restored by Framework
• What if Framework Cell fails ???

20
Restoring Framework Components

• Possibility that Address Server or Repository
  fails
• Two options
• Maintain mirror servers
• Enable framework to heal itself
• Advantages and Disadvantages to each scheme
• Data Restoration on startup

21
Framework Configurability

• Ability to utilize only as much of the Framework
  as required
• Complete Self Healing framework consisting of
  Address Server, Default Handlers, Repository,
  File Handlers and Network Cells
• Minimal system consisting of just a pared-down
  Default Handler

22
Test System Simulated Radar Management

• Three components
• Radar Display
• Data Analysis
• Field Console
• Automating Recovery from Failure
• Failure Test

23
Simulated Radar Management

• Operational Radar System

24
Simulated Radar Management

• Normal Operation on Four Machines
• Failure of the Data Analysis Module repaired by
  the Framework
• Failure of a Framework Component Address Server
• Address Server restored
• Data Analysis restored

25
Timing Test

• Test Results one time recovery delay before
  normal operation resumes

26
Thesis Conclusions

• Key Feature reduce complexity
• Reduction of complexity in application design
  complemented by simplifying tools used
• Raise Abstraction to Cell level through efficient
  reuse of existing Cells
• Use of automation to build more robust
  applications

27
Thesis Conclusions

• Simple Self Healing is possible
• Dynamic Construction over a distributed system
  can work effectively
• Efficient reuse can minimize the coding effort to
  allow applications to be built by putting files
  together

28
Future Work

• Removing the Mediator centric messaging from
  production quality Matrix Applications
• Generic Multithreaded Server Cell design for high
  bandwidth Applications
• Multiple Service Providers
• Adding other automation services self
  configuring, self protecting, self optimizing
• Sophisticated Network Cells

29
Thank You.