The architecture of the GTS system is very modular. The major components fall into the
following main categories:
The following sections will describe each of these in more detail.
- 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
- 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
- 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
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).
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.
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:
Access to the MySQL database is abstracted through the classes provided in the "
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 "
or "Track Servlet" user interface login module. It can also be used to
run the M2M "
event retrieval module, as well as various HTTP-based DCS modules, such as "
gc101.war" (more information on these modules can be found in the
Runtime Configuration "
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):
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.
This can be a copy of the "
from the previous installation of the GTS. This allows more easily porting customer
specific changes from a previous version to the current version.
Customer specific changes to the configuration as
shipped by GeoTelematic Solutions, Inc.
General custom configurable items. (for most installations,
this file should never change).
The configuration file generally used for status code
definition overrides. (this file may not be present)
The general company name/id configuration.
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 "
The main loaded config file entry point for non servlet-based
processes. (This file should never change)
The main loaded config file entry point for servlet-based
Most property changes defined in the "
private.xml" and/or "
file can be overridden with a property configuration setting in the "
When attempting to make a configuration change to the system, first check the "
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 "
- 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
config.conf" should be examined to see all of the available property
settings that can be configured within this file.
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/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:
In addition to the above configuration settings specific to the DCS, the various "
- Those that receive data over a general TCP or UDP connection.
- Run as a separate process.
- Configured within the XML files in the "
- 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 "
- Examples include the "gc101" and "gmprc" DCS modules.
files in the GTS installation directory are also used to provide runtime configuration to the DCS
GTS Track Servlet (
track.war "Track Servlet" is very modular as well, and can be
broken down as describe in the following diagram:
private.xml (and "
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 "
- 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 "
When used in this manner, the "
file can include multiple instances of the "
provide overriding property settings for specifying different
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 "
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/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 "
There may be a few additional JSP template used for special purposes, but the following
are the main JSP templates used within the GTS:
The various JSP templates utilize Java
for indicating where the various web pages should display their content.
You can see the tag-library usage by searching for the tags "
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 "
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).
gts:var" and "
in the above JSP files.
The web-pages which will be available to the user are defined in the "
section of the "
private.xml" and/or "
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:
In some cases, there may be other servlets as well with may perform a function similar to one
of the above.
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
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
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
this DCS received location information encoded in the URL, then parses and inserts
the events into the EventData table.
These various servlets obtain their runtime configuration from a combination of the
private.xml" (or "
private/private_common.xml") files, or the
.conf" files available in the GTS installation directory.