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

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

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

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.