moved temporarily to peg auxiliary or back to peg source . The goal is to
transfer all the discs using the smallest number of moves possible.
The test application displays the puzzle in a graphical user interface and
allows the user to click and drag one disc at a time with the mouse in order
to move it from one peg to another. The application must be recoverable, i.e.
it should be possible to save its state (the position of every disc) and any
state change (the user's moves), and to reconstruct the current state after a
According to mythology, in the distant past, there were three pegs in
Hanoi. In the very beginning, there were 64 discs of different sizes stacked
on the peg source . By the time that all 64 discs are moved to peg destination ,
the world will end.
Architecture and planning
At this stage we envisage the RECAP framework as a service component that
sits between the recoverable application and persistent storage, e.g. the file
system. The component offers methods to record the application's state and
the sequence of state changes of the file system. In the case of application
recovery, the service component loads the saved information from the file
system and rebuilds the last image of the application state before the crash.
The system architecture is made up of three main subsystems as shown in
Application . This represents the generic application that needs to be
recoverable. It maintains the state of the application and implements the
control and information flow.
Tracker . This is an application-independent component and represents
the core of the RECAP framework. It offers functionalities that allow the
software developer to make applications recoverable.
Console . This is an application-independent graphical user interface that
allows the user to manage application recovery and undo
The development process of the RECAP framework is organized into two
phases that produce two prototypes.
Figure 18.1 The main components of a recoverable application