iTrack is one of the most innovative parts of the entire iServ application suite. The iTrack product acts as an interface between the iServ server and the output mapping software – commonly OziExplorer. This is not anything spectacular – it is just a capability of our flagship OziAPRS software.
What makes iTrack different is that it is just an applet rather than a full application. iServ does most of the processing, with iTrack just acting as a light weight interface. iServ is able to export the latest positions in XML format through the built in Web Server. iTrack periodically connects to iServ and transfers this data to the to be displayed in the mapping software.
Setting up the iTrack software could not be simpler. Just install the software and configure it with the Web server address, and the application will operate automatically. Minimise the table, and the software will live quietly in the system tray, rarely needing to be accessed.
iLog is a very important part of iServ. The iLog program has one job, and is designed to do that job very well. That job is to log any messages coming in through the communications networks into the database.
We are often asked why we have split this into another program. There were a number of reasons for us to split the iLog into a standalone program. One of the main reasons was to allow for disaster recovery if anything goes wrong with the database.
Databases corrupt, and since our product is so reliant on a database, we wanted business operations to be recoverable in case of database failure. The ability to continue operations is thanks to the iServ program creating XML database export files for each message that comes in. The iLog program then reads these files, updates the database, and moves them to a backup directory. If the database fails, these files can be copied to the iLog incoming directory and the database will be repaired almost instantly.
Another reason is that we believe that database writing is the most likely part of our system to fail. If iLog fails, no data is lost. As soon as the problem is repaired, iLog can be restarted and operations will resume.
The last reason is for upgradability. By splitting the database code predominantly into a seperate program, adding support for new databases will be fairly simple, with well defined interfaces.