Conventional backup and recovery is disconnected from the way an application works. More frequently,
business entities within an application are deleted and need to be restored. The BOBUP framework
provides the capability to recover a single application entity without affecting any other data.
No, backups using the BOBUP framework complement the backups done in the conventional manner.
You can continue to perform conventional backups of files and databases.
Besides the benefits listed in the overview, the framework is best used
to restore a subset of the application business objects.
It can be also used for disaster recovery where an application server
or database has crashed and needs to be completely restored. BOBUP is not the best solution in this case.
In an enterprise environment, using
the BOBUP framework for a full-system restore will be inefficient compared with a conventional backup.
Restoring one business object at a time is analogous to copying hundreds of small files
across a network one file at a time vs. copying one large zip file containing those
files (try this sometime).
The framework is developed in Java. There are no current plans to port it to other languages. However,
Java can be accessed by other languages and scripting frameworks in indirect ways which are
beyond the scope of this project.
The framework contains interfaces that application objects may subscribe to. It also contains
tools like the Collater, Recoverer, Browser etc. and common implementations of backup strategy. For
complete details see Getting Started and the Javadocs.
The framework refrains from developing into a shrinkwrap offering simply because it is
intended to be integrated into an application, working "under the hood". Applications
and vendors can place value offerings and extensions on top of the framework.
In the early access release, no GUI tools are included in the framework.
The manifest of the backed up business object contains a section describing every constituent part of the business
object. Among other application-specific settings, the name, description and the recovery handler type
are provided. The manifest is the first part of the backed up business object.
No, this is a deliberate architectural detail to prevent deadlock conditions where the nested IBackupPart nests its own parent.
Besides, this also benefits the application by simplifying the generation of constituent parts of a particular business object.
The application can be thorough about backing up and recovering a particular object without having to worry about delegational errors and
nested deadlocks.
If you need to back up more than one type of business entity, consider using the methods outlined in the next FAQ question.
The same IBackupProvider registered with the Collater can source any type of IBackup instance.
Register a separate IBackupProvider per each business entity. This an application separation-of-powers issue and is
not strictly required.
.
In both above situations, backup is performed to the same IBackupConfiguration. Use a different Collater
instance and configuration if the objects have to be backed up to different locations and/or have different strategies.
Bobup is modelled after the Memento design pattern but adds a lot more sophistication.
The Memento pattern is primarily targeted for undo-redo situations where the state of a particular object must be restored to some
previously recorded state.
The memento for Bobup is a business entity rather than just an application object. The difference is subtle, but important. For instance, a memento can
be recorded for the layout of graphical objects in a visual application. Bobup is concerned more with business data, like backup of customer data,
patient data etc..
Nonetheless, the Memento characters are:
An instance of IBackupRecoveryHandler corresponds to the Originator.
The Collater corresponds to the recording aspect of Caretaker.
The Browser and Recoverer correspond to the restoration aspect of Caretaker.
Two reasons: using String makes it more portable between databases if the identifier needs
to be persisted. If you do use
numbers, simply transform to a string object. The other reason is to support the usage of
universal unique identifiers (UUID), which are not numbers.