Scalable, Distributed Architecture for REST-based Applications
We recently announced the release of Geocortex Essentials 3.1. One of the big changes in this release is the introduction of an architecture which will support distributed deployments of the Geocortex Essentials REST API.
To understand this, let’s take a look at the architecture before 3.1:
NOTE: For simplicity, the relationship with ArcGIS Server is not described in this diagram.
Notice how multiple client applications (such as the Geocortex Viewer for Flex and the Geocortex Viewer for Silverlight) connect to the Geocortex Essentials REST API. From the REST API they learn about the configuration of the site structure that should be used, and they can access server side functionality such as hi-resolution, large-format printing and reporting. The Geocortex Essentials REST API is responsible for managing the content in the Sites Directory.
Now let’s take a look at how things have changed with the introduction of the distributed architecture in Geocortex Essentials 3.1:
Geocortex Essentials now has a new component called Geocortex Application Services. The application services live within Geocortex Agent, which is windows service (the same Geocortex Agent that gets installed with Geocortex Optimizer). Application Services introduces a centralized mechanism to deal with authentication and user management, security tokens, and access to storage (for example, reading/writing site configuration files or print templates).
By creating Application Services and externalizing these functions from the Geocortex Essentials REST API, we can improve the performance of systems under heavy load by distributing the REST APIs across multiple servers. Think cloud deployment: when your application is under heavy load you can respond by standing up more instances of the REST API behind a load balancer.
Having the Application Services centralized means that you only have to configure your sites and security in one single location.