Application Architecture
The "Transportation Data Server (TDS)" application is the "wrapper", server-side, application that hosts a number of supporting web services and all of the client-side web applications (which consume those web services) - for example: Road Analyzer (RA), Segment Analyzer (SA), Validation Assistant (VA), HPMS Assistant (HA), Road Video Viewer (RVV), etc.
TDS is typically hosted in a standard enterprise-level IT environment, with supporting LRS transactional components - such as an LRS geodatabase and GIS map services. TDS is compatible with most LRS models and is often used in conjunction with Esri's Roads & Highways product, however Roads & Highways is not required. There are many different infrastructure configurations and environments that TDS can be ran within. Below is a listing of the most common configurations:
Systems Architecture - no load balancing
This option has no load-balancer in either the GIS or web tier. This is a fairly common architecture for Roads and Highways environments. It is not necessarily a big risk in that the most performance intensive component in this stack is ArcGIS Server (which could be setup to use clustering, instead of a load balancer). Most of the "web tier" components are simple HTML/JS/CSS applications that do not drastically benefit from a load balancer (unless you have hundreds of thousands of users).
Pros:
- Simple to configure and understand.
- The GIS tier (ArcGIS Server) can still scale using clustering.
- Uses standard configurations in both web and GIS tiers.
Cons
- The web-tier is not easily scalable.
- The GIS-tier is not easily scalable, from a load balancer standpoint, but could scale via clustering.
Systems Architecture - load balanced GIS tier and non-load balanced web tier
This configuration provides load balancing for the most common "stress-point" - ArcGIS Server. This configuration provides the most benefit with the least amount of work (configuration), if a load balancer is already planned to be used.
Pros:
- Simple web-tier configuration.
- Easily scalable GIS-tier.
- Uses standard configurations in both web and GIS tiers.
Cons
- More complex configuration for GIS-tier.
- Web-tier is not easily scalable (not necessarily a big deal unless you plan on having a very large user group).
Systems Architecture - load balanced GIS tier and load balanced web tier
This option provides the most "scalable" and fail-safe solution, but also requires the most configuration and maintenance.
Pros:
- Completely scalable.
- Ability to do server updates without affecting users.
Cons
- More difficult configuration.
- More difficult troubleshooting and diagnostics (both web and GIS tiers).
- Increased maintenance (more servers to run installations, backups, Event Editor configuration sync, etc).
- Must use a SQL Server database as a configuration database for TDS (which each TDS instance points to).
- Must have shared network folders between TDS instances (if using print or reporting capability within RA).
Heads Up! When placing TDS (the web-tier) behind a load balancer their are several configuration options that must be considered in order to keep the multiple instances in sync. See the "Advanced Configurations" page for details on configuring the application behind a load balancer.
Data Flow and Connections
Data is accessed and consumed in various ways, depending on the particular application running. The two most typical data connection types will read data from a "Map Service" (typically ArcGIS for Server) or by directly connecting to the database from TDS (through a set of secured REST services). TDS can be configured to point to many different data sources, both spatial (geodatabases) and non-spatial (standard RDBMS, no geodatabase).
Heads Up! It is highly recommended that the data source connection to your "Transactional Database" be read-only. You should configure the connection to use an account that has "read-only" access to the data. This will mitigate the risk of accidental edits or loss of important data.
