- Where do I start?
See overview and technicals.
- What is different?
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.
- Does this replace conventional backups?
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.
- What are the advantages of the BOBUP framework? Disadvantages?
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).
- What language is the framework implemented?
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.
- What does the framework contain? Any GUI tools?
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 framework is dual-licensed under the GPL and an OEM license. See Licensing.
- What does the backed up business object look like?
The backed up business object is fundamentally a zip archive. See overview and technicals.
- What does the manifest file contain?
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.
- Is the backed up object encrypted?
For the early access release, backed up objects are not encrypted. However, this is a top priority
feature and is actively being worked on.
- Can IBackupPart be nested?
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
If you need to back up more than one type of business entity, consider using the methods outlined in the next FAQ question.
- Can more than one type of business entity be backed up?
Yes, and in various ways:
- 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.
- Isn't Bobup the same as the Memento design pattern?
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.
- The memento itself is the business entity.
- Why do ID methods like getId() return String instead of numbers?
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.