This document is intended to give our MicroStrategy customers a brief overview of the multiple modes of the Visual Crossing server capabilities and how to decide which mode is best for them. We will start with a description of the modes:
Plugin mode is the default mode for trial downloads that you will see from Visual Crossing. On MicroStrategy it is a widget plugin that is entirely deployed within the MicroStrategy Web deployment. These plugins are all full-featured with server-level performance due to the Visual Crossing 4 architecture. These plugins are designed to fit into the MicroStrategy Architecture and as such, their communications, security, actions and overall capabilities are governed by the supporting platform.
How do I install the plugin? The system administrator simply runs the installer or copies the plugin into the MicroStrategy Web deployment. The next step is to copy the metadata template to a file location that is accessible from the web server. The final step is use the MicroStrategy Administrator preferences page to assign the metadata location to that plugin.
How does the plug-in work? There are two tasks the plug-in mode has to accomplish: First it acts as the integration into MicroStrategy and pulls data from the MicroStrategy system and provides mapping display technology. Second is the fact that it acts as a server and completes the full spectrum of GIS tasks, the most important of which is that it loads layers from metadata, transforms them into Map Tiles. It manages all features that exist on top of the Visual Crossing Metadata. Security, User Administration, Object Management, Data Management and of course GIS level calculations such as distance, drive-time and more.
Standalone mode is a separate architecture from plug-in mode where the map server functionality is resident as a standalone web server application running on a Tomcat instance. It is delivered in the form of a WAR file and the instance is managed entirely by the administrator.
How do I install the standalone server? The system administrator will copy the WAR file into the webapps location of a Tomcat (or other java based servlet engine). The user must also tell the WAR file how to communicate with the Visual Crossing Metadata. (refer to the documentation on how to do this) To communicate to the server, you must also still install plugins into each running instance of MicroStrategy Web. In this mode, the plugin is still server-capable but it will be set in the preferences to run in standalone mode where it uses the standalone server for all o f its server actions. Instead of defining the metadata location for the plugin, the administrator must provide a location to the standalone server on each of these instances.
How does the standalone mode work? With the plugin installed in every web instance, it intelligently asks the server for metadata queries, data tiles as well as GIS functions. The server is the sole communication vehicle for the metadata rather than having all of the plugins accessing it directly.
Clustering of MSTR Web Servers
One common question from MicroStrategy customers is how do they get maps onto clustered environments? Both modes can support clustered environments but the architectures vary. In Plugin Mode the system will require that all of the installed plugins write to a shared metadata space. This may require the administrator to create an NFS Share and have all instances of the cluster point to the same location. In addition to the share, the administrator must ensure that the clustering software maintains a sticky IP setting to ensure that user sessions are maintained by a single web server.
In Standalone Mode, the server manages a single connection to the metadata there is no need to have an NFS Share. The clustered plugins simply point to the same standalone map server as normal.
Both modes are accessible but from support's experience, the standalone server has fewer incidences of failure due to configuration and administrator actions. NFS Shares can have a whole host of settings that are not well-understood by administrators and these issues are challenging to debug. Visual Crossing Support is typically unable to help resolve many of these issues and they must be handled by the customers administrator.
Visual Crossing's version 4 architecture was designed to be highly performing, even on a busy server without creating a lot of additional work by the web server CPU. For 95% of customers, the performance of the Plug-in Mode is more than adequate. But let's discuss how layers are loaded and the performance hit that may be required by the server code.
Let's start with something like a US States layer... It is small in size (50+ shapes) and the boundaries of which don't change. There is no reason for a system to request new States data unless there is additional attribute data (populations, etc...) that is included in the layer. When States are first loaded into the system, the Visual Crossing 4 architecture asks the server to process the layer into Vector Map Tiles. These Tiles are a fast cache of data that provides the system with the great performance that it delivers. The Tile Generation task is intensive on both memory and CPU. They key to this layer is that it is both small and it will only generate tiles a few times over its lifetime. The administrator can ask for the tile generation in off-hours and it only takes a few minutes. No harm to the system.
Let's consider another layer such as property lots. This layer can have millions of polygons and they can change frequently. Loading a layer like this will take a long time and you will have to repeat this task frequently. This will produce a greater risk of bogging down the web server that would typically be responding to your MSTR Web users. Once cached, the concerns can go away.
We recommend that customers move to standalone for performance reasons after they have confirmed that it will be an issue for them. Typically, the plug-in architecture is higher performing than expected. Our support team can help give you guidance if you can provide them with descriptions of your layers, make sure to include size of file, number of polygons and the frequency of change.
Currently there are only two major features that require standalone server: Drive-time/Routing and JDBC Datasource Access. Drive-time features load in a massive roads layer into memory and creates complex calculation tables so that it can do thousands of route estimations per second. This creates a large disk, high memory and a strong CPU requirement. The second additional feature is to have direct access to layer data via JDBC Datasource. The plugin architecture simply doesn't allow this type of access. If you are considering either pieces of functionality it is required that you install the standalone server.
Another reason to consider the standalone server is the ability to share the map server across projects and platforms. You may have a combination of MicroStrategy projects, Mobile Deployments, Custom Map Applications, Excel deployments and perhaps SAP integrations all in the same enterprise. All of these projects would like to reuse the same metadata and layer data. You wouldn't want to have multiple copies of layers for each of these deployments nor would you want to manage a map system for each of these individually. Standalone allows you to share a single running map server instance with a single metadata repository.
As you can see, there are some pretty clear cases when you should choose to upgrade to the standalone server mode of Visual Crossing. In some cases, clarity of architecture alone is a good reason to upgrade for many administrators. We advise that most users start with the plugin mode and determine what their use-case and performance needs are first. Please contact email@example.com for additional advice or help.