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

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.