Projects:Backup Tool/Technical Specification
Contents |
Introduction
This document will analyse the different options to implement the backup tool, and compare them.
Options analisys
Models
Model 1
In this model the backup tool consists of three parts: the code itself and two web interfaces to access the functions, one inside Openbravo and other a web page external to Openbravo.
The three components:
- The code (webservice): is in a different tomcat context (java) or in the web server (python/php) and that provides all the backup and restore functionality.
- Web UI : an external tool in a different tomcat context (java) or in the web server (python/php) that allow to connect to the webservice to execute backups/restorers although Openbravo application is down.
- Module of Openbravo: a module that provides a Openbravo web interface to use the functionality provide by the webservice when Openbravo application is up.
All the functionality should be in the webservice. The external UI and the module UI don’t implement nothing except to call webservice external functions and display its results.
This model require an authentication for users using the web page external to Openbravo.
Model 2
This model is based on a Command Line Interface tool that can be called directly and has all the functionality inside. Also has a module inside Openbravo that can access to its functionality.
- The CLI tool: Is a program that can be executed directly from the command line. This tool should perform all the backup functionalities.
- The module: Is an Openbravo module that call the tool with different parameters.
Programming language
In both models all the files are shipped inside an Openbravo module. The part of Openbravo GUI will be done in Openbravo standard way of do windows (WAD or manual).
And the common part for the functionality of the backups is where can be many options:
The external part is where can be many options:
Bash
This option is more compatible with the model 2, since with bash generate html pages is not very usual.
Pros:
- Fit the requisite of be platform independent (cygwin).
- The backup has some similarities with the promote testing to production tool, and this tool is in bash.
- The backup will be performed by a system administrator, and Linux/Unix administrators are very used to work with bash, so if they have to customize any thing of the code it will be more easy if is in this language.
- Fits perfect for use in command line.
- In Linux/Unix systems don't need another application installed to compile or execute the script.
- Easily can be moved to another machine to execute remote backups.
Cons:
- Not intended for very long programs (in principle the backup will be a short program).
- Add support for other file systems can be difficult than with other languages.
- Error management is not such advanced than in Java.
- Not intended for provide a webservice for the Model 1.
Java
Is the language used in Openbravo and this add these extra features:
- The Java compiler and runner are already installed in the host.
- Openbravo developers are used to work in Java. (In any case the backup tool is intended for system administrators that maybe are not use to Java).
Pros:
- Fits with the multi platform requisite.
- One of the more extended languages, lots of functions and code examples, implementations for support many file systems.
- Fits for booth models (webservice and command line)
- Good error management.
Cons:
- Need Java installed to compile and execute.
- Easy tasks can be more complex than in other languages.
Python
Pros:
- Fits the requirements of multi platform, also don't need to be compiled.
- Lots of libraries, and easiness of use.
- Fits with both models (webservice and command line).
- Like bash fits very well for command line usage.
- Clean and powerful language, mercurial has lot of its code in python and the integration with it is very natural.
Cons:
- Need to be installed Python in the machine.
Options chosen
Model
The model chosen is the second: the Openbravo module with the option of use from the command line.
This model is very much simpler than the other and also system administrators will not have any issue with use the command line instead of a web page.
This model don't need to implement a authentication method for the users that access to the external web/webservice when Openbravo is not available.
The determinating point here is that the tool is intended to be used always from inside of Openbravo, and when Openbravo host has a not recoverable issue, then make a clean install of Openbravo in another host and restore the last backup from Openbravo interface. Taking into account this, the easier way is to put all the functionality inside the Openbravo module and allow the command line interface to access directly to the functionality inside the module.
Programing languages
The natural choice is Java since is an Openbravo module. But always having a separation between functionality and interface in order to allow the command line to use its methods.
The use of Java provides its error control and the ability to run it in all the platforms that run Openbravo without needed to install anything.
The use of Java is more oriented to the use of the tool from the Openbravo interface to call the methods. In the other hand, this makes the call from the command line more tricky.
Another advantage of use Java is that there are a lot of libraries and we think that will be someone to support to write into different file systems without the need to mount it at operating system level.
In any case it's not a definitive election, since it is possible that the implementation of the backup (list directories, create a zip, uncompress the zip, restart tomcat/apache, make a dump of the db and restore the dump) probably are easier to implement in bash.