Sun Lab's Ron Goldman notes in a recent interview that as applications become more complex, writing bug-free software becomes an increasingly hard task. He also observes that many applications take advantage of only a fraction of available computing resources to perform their requirements. Those available CPU cycles can be dedicated to tasks that support self-monitoring and self-healing. That mimics how biological systems work:

In computing, perhaps 5% of our code deals with exception handling and error correction, which seems like a lot, while 95% tries to get the basic job done. Biology appears to reverse this, with 5% doing the basic metabolism and 95% functioning to make sure that the 5% can do its job. Think about keeping your heart beating -- is that overhead? Or is that a core activity that's part and parcel of who you are? Think of your body doing the work of keeping your mind and brain functioning. That's not overhead.

Likewise, maintaining your computer system's health to make sure that all of its components are functioning is not overhead. That's just what is required to have a robust system.

Goldman notes that automatic garbage collection is already an example that principle:

When John McCarthy was designing the LISP language, one of the programs he wrote was an elegant algorithm to do symbolic differentiation. He recognized that the code would be using up memory and if it wasn't released that memory would eventually run out. And he deliberately decided that he didn't want to mess up his elegant algorithm for differentiation with a lot of record keeping and bookkeeping for memory, which had nothing to do with the problem he really cared about. So he did something that we're considering doing in a number of other places. He accepted the idea that all programs have bugs and created a system that can repair and clean up unused memory and, in a sense, that can recycle it and make it available.

In order to build self-monitoring and self-healing systems, he suggests that blackbox-style component encapsulation sometimes doesn't work, and why it may be advantageous to sometimes be able to "see inside" software:

When we write code we are well advised to follow the principles of encapsulation and information hiding. Otherwise our modules will become very tightly coupled to each other and hard to change. However, when we run a program it can be advantageous to be able to see into it. An obvious example is testing, where the test code may need to check the internal state of a module. We believe that it is important to have visibility into the system in order to assess its health and to make decisions about adjusting it. Visibility consists of continually updated descriptions, for example, of what's inside a system's software components, how a system is currently configured, the overall state of the system, what it's working on, which users use what software in which ways, and so on.

Instead of a rigid, minimalistic API between two modules, [object] [...] can be pattern-recognized or sampled. We are considering shared blackboards with simple textual pattern-matching, extensions of something like Common Lisp's keyword/optional argument lists and calling conventions, or even passing XML documents. The key idea being that, instead of one agent reaching inside another and commanding it to do some function (e.g., a remote procedure call), it instead deposits a request that the second agent can then interpret and deal with as best it can.

Many of Goldman's ideas build on the self-healing notion of distributed systems, such as Jini. For instance, Jini can be used to facilitate dynamic loading of exception handlers to deal with new error types in an application.

Do you see self-monitoring and self-healing taking up increasingly importants parts of your application?