OpenGTS packages

Before even writing or modifiying a line of code it is always advised to thoroughly analyse the given software. Basically this Website is looking at OpenGTS as a collection of Java packages, which can be combined to a customized Tracking System with different Trackers. Each Tracker Type can transmit via its proprietary Data Protocol into the standardizing Server Database. In addition the system provides a webfrontend with authorization (and roles) to administrate and display and export dedicated stored data.

A Java Programmer can begin the reverse engineering of the architecture on package level.

CodePro dependency analysis

For the following analysis the code was installed in the Eclipse Java EE platform - to be explained later. Additionally CodePro Analytix from the google developers site was installed. Although CodePro  is useful to spontaneously visualize dependencies, it is not really made to work with the visual editor for 40 packages as in this case.

Since you can not store the package arrangements with CodPro this page provides six images to analyze the major package dependencies. A click on any one of these images will open a new target window with one animated gif showing all six dependency graphs (and one more image to show the external Java Packages) of this web page for 10 seconds each. The animation might inspire you for an interactive analysis session with CodePro.

If you would like to have the seven images in full size with a clean typo
you can download them here in one zip archive:

CodePro can also generate the Dependency Analysis in html format,
which you can interactively explore here.

The OpenGTS download archive comes with a number of folders and the installation provides a good understanding of how these directories 'work' together. For a Java Programmer it is a good approach to go to the OpenGTS_2.../src folder and look how the package names are grouped together. The source folder contains 40 org.opengts... packages. 

The major components of the GTS can easily be identified by the package names:

    • four database packages
    • three packages for Cell ID
    • seven packages for different geocoders
    • seven packages for different Device Communication Servers
    • a large number of 'war' packages related to web container deployment
      (to be analyzed later) 


Although the org.opengts.util package does not represent a GTS component the dependency graph reveals that every org.opengts... (except package depends on this util package. Vice versa util does not depend on any other package (making it 'independent' to be replaced).


After clicking through packages the next 'ground layer' can be identified by multi selecting all org.opengts.db... packages. The dependency graph above shows little dependencies FROM the db packages. Besides org.opengts.util these packages depend on the org.opengts.geocoder... and org.opengts.cellid... packages.

This graph shows that obviously all OpenGTS components interact with the database or rather with the packages representing the database structure. While the database has knowledge on Geocoding and Cell IDs.


Multiselecting the org.opengts.servers... packages shows that no other package depends on these. In conclusion 'the servers run on top of the db and util packages'. A peek into the server implementations reveals the identical architecture consisting of four java files and some depend on the org.opengts.servers package. This insight can be used to simplify the image by removing all servers packages exept org.opengts.servers and org.opengts.servers.template. They can represent all other servers in the dependency view.


Every Java Web Developer knows the abbreviation war for a well structured and defined web archive, which can be deployed to a web container like Tomcat. The classes usually depend on the Java Servlet and JavaServer Pages specifications and technologies.

From the dependency graph one can tell that the ..war.. packages have no dependency to the Device Communication Servers (DCS) in the left column. The DC Servers receive remote protocols, chop them into information bits and stores these in the database. While many ..war.. files represent the web frontend to the GTS and have read and write access to the database.


As analysis tools should be used interactively you should click through the packages to get your own impression. For example you can mulitselect the complete left 'column' to see that there are no dependencies to the right column - and vice versa. So the arrangement in left, middle and right layer provides a good initial architectural overview for further planing.

This web page was meant to supply an entry point to the GTS.

The next page will identify the next higher level - the jar files - of the architecture.


 « intro libraries »