"World Leader in
GPS Tracking Software"		  
GEOTelematic® Solutions

GTS System Architecture Overview

The architecture of the GTS system is very modular. The major components fall into the following main categories:
  • Operating System - Provides the machine level interface. Currently supported operating systems include Linux, Mac OS X, OpenBSD, FreeBSD, and Windows.
  • Java JDK - Provides the Java runtime environment for executing the various required processes.
  • MySQL Database - Provides the persistent storage for the Account, User, Device, EventData, and other database records.
  • Tomcat Servlet Container - Runs the various GTS Servlets.
  • Runtime Configuration - A set of ".conf" files providing global system-level settings and configuraton.
  • GTS Libraries - The common set of utilities performing various basic functionality, such as String and Date manipulations, Socket-based connections, Database connections, etc.
  • Device Communication Server (DCS) Modules - Provides the communication interface to remote tracking devices.
  • GTS Track Servlet - The main web-based user interface servlet. This component is further broken down into is constituent components below.
  • Other GTS Web-based Servlets - Other available GTS servlets including the "Events Servlet" (events.war) which provides a web-based method for extracting Device events, and http-based DCS modules (such as gprmc.war and gc101.war).
The following sections will describe each of these in more detail.

Operating System

The Operating System provides the machine level interface on which the Java and MySQL environments can run. Currently the GTS has been successfully run on many different distributions of Linux (Fedora or CentOS preferred), Mac OS X (Leopard, Snow Leopard, and Lion), OpenBSD, FreeBSD, and Windows platforms (WinServer, XP, Vista, Win7, etc).

Java JDK

The Java JDK provides the compiler and runtime environment for running the GTS. It is important to note that the Java "JDK" (Java Developer Kit) installation is required, rather than the "JRE" (Java Runtime Environment). The "JDK" includes the runtime environment, as well as the compiler, which is needed both to compile the GTS code, and by Tomcat to create te dynamic web interface pages (ie. "JSP" Java Server Pages). The "JRE" contains only the runtime environment and is unable to compile any Java code.

MySQL Database

The MySQL database is used as the persisent storage for the Accounts, Users, Devices, Events, and other data types. The complete list of currently configured data tables, along with a list of their contained fields/columns, can be displayed with the following command: 
    cd $GTS_HOME
    bin/dbAdmin.pl -schema
Access to the MySQL database is abstracted through the classes provided in the "org.opengts.dbtools" package. The main class in this package is the "DBProvider" class. This allows unplugging one database provider and plugging in another, such as Microsoft SQL Server or PostgreSQL (partial support is available for both of these alternate DB providers).
When we initially started development of the GTS system (back in 2006), we had started working on using Hibernate as our database access layer. At the time it did not provide the features that we required in the GTS (the GTS relies a lot on metadata provided by the database provider). However, revisiting the integration of Hibernate into the GTS is something that would be very welcome should someone wish to volunteer their expertise in this area.

Tomcat Servlet Container

The Tomcat Servlet container is used to run web-based modules, such as the "track.war", or "Track Servlet" user interface login module. It can also be used to run the M2M "events.war" event retrieval module, as well as various HTTP-based DCS modules, such as "gprmc.war" and "gc101.war" (more information on these modules can be found in the OpenGTS_Config.pdf document).

Runtime Configuration ".conf" files:

Global system-level settings are configured in one of the ".conf" files available in the GTS installation directory. There are several ".conf" files available which are arranged in a hierarchy to allow for having configuration files that seldom change, or other configuration files which may change more often. A property setting may be specified in more than one file, however it will always be the last property setting that "wins". That is, the value assigned to a property will always be the last value assigned in the hierarchy.

The following list describes the configuration files which are loaded, and their hierarchy. The properties defined in the ".conf" files closer to the top of this list have a higher precedent than the same property defined in a file lower in this list. That is, if a property is defined in more than one file, the property setting in the file closer to the top of the list will have precedent (if a config file in this list is not present, it will be skipped):

  • config.conf
    This is the preferred configuration file where all customer specific configuration changes should be placed. By default, all property settings in this file are commented with a prefixing "#" character. When setting a property in this file, the line must first be uncommented (ie. remove the prefixing "#"), then its value should be set according to the custom requirements of the installation.
  • config_old.conf
    This can be a copy of the "config.conf" file from the previous installation of the GTS. This allows more easily porting customer specific changes from a previous version to the current version.
  • custom_gts.conf
    Customer specific changes to the configuration as shipped by GeoTelematic Solutions, Inc.
  • custom.conf
    General custom configurable items. (for most installations, this file should never change).
  • statusCodes.conf
    The configuration file generally used for status code definition overrides. (this file may not be present)
  • system.conf
    The general company name/id configuration.
  • common.conf
    The common/standard configuration for basic GTS features. This file is intended to contain the basic default settings and should file never change. (Changes to the default configuration should be placed into the "config.conf" file)
  • default.conf
    The main loaded config file entry point for non servlet-based processes. (This file should never change)
  • webapp.conf
    The main loaded config file entry point for servlet-based processes.

Most property changes defined in the "private.xml" and/or "private/private_common.xml" file can be overridden with a property configuration setting in the "config.conf" file. When attempting to make a configuration change to the system, first check the "config.conf" file to see if a property override setting is available. If not, then go ahead and modify the "private.xml" and/or "private/private_common.xml" file if necessary.

Here are a few items that can be configured in the "config.conf" file:
  • Additional/Optional table column settings
  • SMTP/Email settings
  • Outbound SMS Gateway settings
  • MapProvider settings
  • ReverseGeocodeProvider settings
  • GeocodeProvider settings
  • MobileLocationProvider settings
  • Date/Time formats
  • Custom Admin page settings
  • Selected Report enabling/disabling
  • Web page banner header images, and colors

The "config.conf" should be examined to see all of the available property settings that can be configured within this file.

GTS Libraries

The GTS libraries are comprise of lower-level tools and utilities for performing common tasks, such as String or Date/Time manipulation, Base64 encoding, TCP/UDP Socket handling, Database Provider abstraction, etc. These library utilities are built from sources mainly in the following directories:
  • src/org/opengts/util/
  • src/org/opengts/dbtools/
  • src/org/opengts/extra/util/ (if available)
  • src/org/opengts/extra/shapefile/ (if available)

Device Communication Server (DCS) Modules

A Device Communication Server (DCS) is the module that listens for incoming connections from a specific type of remote tracking device and understands how to communication with the device to parse incoming data, and insert the received events into the EventData table. In some cases the DCS will also generate additional events based on changes in the Geozone arrival/departure state, or detected changes in the digital inputs.
There are essentially two types of DCS modules:
  • Those that receive data over a general TCP or UDP connection.
    • Run as a separate process.
    • Configured within the XML files in the "dcservers/" directory.
    • Examples include the "sanav" and "tk10x" DCS modules.
  • Those that receive data over a HTTP connection.
    • Run within the Tomcat servlet container.
    • Configured using the property settings in the "webapps.conf" file.
    • Examples include the "gc101" and "gmprc" DCS modules.
In addition to the above configuration settings specific to the DCS, the various ".conf" files in the GTS installation directory are also used to provide runtime configuration to the DCS process.

GTS Track Servlet (track.war)

The track.war "Track Servlet" is very modular as well, and can be broken down as describe in the following diagram:


private.xml (and "private/private_common.xml"):
The "private.xml" file (or "private/private_common.xml" file) plays an important role in the display of the various web pages to the user. Here are some of the functions performed by the "private.xml" and/or "private/private_common.xml" files:
  • Defines one or more "Domains" to which the specified settings will apply. This feature is used to allow specifying a different set of attributes to different login domain names (such as "taxi.example.com" and "plumbing.example.com"). When used in this manner, the "private.xml" file can include multiple instances of the "private/private_common.xml" and provide overriding property settings for specifying different MapProviders, ReverseGeocodeProviders, login banners, etc.
  • Sets the primary language/localization for the displayed text.
  • Assembles the various pages which will be available for user selection on the main menu, such as which map pages, reports, and administrative pages will be available for user selection.
  • Sets the JSP (Java Server Pages) template which will be used for the display of the various assembled pages.
  • Sets the MapProvider that will be used to display maps, and what features will be available on the map.
  • Sets the GeocodeProvider (turning an address into a latitude/longitude), ReverseGeocodeProvider (turning a latitude/longitude into an address), and MobileLocationProvider (obtaining a latitude/longitude from the serving cell-tower information) that will be used for the Domain.
  • Sets the reports which will be available for user selection on the Report Menus. The reports themselves are defined in the XML file "reports.xml".

JSP Templates:
The JSP (Java Server Pages) template defines the page 'outline' within which the various web pages will be displayed. The "JSPEntries" tag in the "private.xml" and/or "private/private_common.xml" files defines which JSP template file to use. The JSP files themselves usually reside in one of the following directories (before they are built into the "track.war" file:
  • war/track/jsp/
  • war/track/custom/
  • war/track/extra/jsp/
There may be a few additional JSP template used for special purposes, but the following are the main JSP templates used within the GTS:
  • loginSession_sbanner.jsp - A general template which will display a header banner at the top of the page and the page title text centered on top of the banner.
  • loginSession_cbanner.jsp - Similar to "loginSession_sbanner.jsp" above, except that the page title text is not displayed within the banner. This is used when the displayed banner image already contains the company name information.
  • loginSession_wbanner.jsp - Displays a wide header the full width of the browser page frame, with the banner image placed to the left of the header area.
  • emailReport.jsp - This JSP template is used exclusive for the creation of the html when emailing a selected report (via the "EMail" selection from the pull-down option on the various report menus).
The various JSP templates utilize Java "Tag Libraries" for indicating where the various web pages should display their content. You can see the tag-library usage by searching for the tags "gts:var" and "gts:track in the above JSP files.

Web Pages:
The web-pages which will be available to the user are defined in the "WebPages" tag section of the "private.xml" and/or "private/private_common.xml" files. Within this tag section, there will be a "Page" tag definition for each web page that will be made available to the user for selection. The "Page" definition specifies the Java 'class' that is to be used to create the content of the page, and whether the class definition is optional (an optional "Page" definition will not generate an error if the class is missing or not found).

Other GTS Web-based Servlets

The web-based servlets which are part of the GTS (other than the "Track Servlet" described above) include the following:
  • events.war "Events Servlet" - This servlet provides the ability to extract a set of specific Device events in CSV, JSON, or XML format, through a web-based interface.
  • gprmc.war "GPRMC Device Communication Server" - This servlet provides a generic interface for phones or other devices that can send location information to the server. The phone, or other device, typically encodes the location data in a URL which is then sent to the server. This "GPRMC" DCS then receives the data, parses the location information from the URL, and inserts the corresponding events into the EventData table.
  • gc101.war "Sanav GC101 Device Communication Server" - This servlet provides the specific interface for most Sanav devices to receive data from the remote tracking devices in the Sanav event data packet format. Like the gprmc.war DCS, this DCS received location information encoded in the URL, then parses and inserts the events into the EventData table.
In some cases, there may be other servlets as well with may perform a function similar to one of the above.
These various servlets obtain their runtime configuration from a combination of the "private.xml" (or "private/private_common.xml") files, or the various ".conf" files available in the GTS installation directory.
Copyright(C) 2007-2015 GeoTelematic Solutions, Inc., All Rights Reserved