Reference Library

 

MapDotNet Server is built on a highly scalable web services architecture. The MDNS Web Services are stateless; therefore any particular request from an application may be serviced by any process running the web services. The services may be installed on multiple servers running in a web farm and across multiple processes running in a web garden.  Your application can load-balance its map and feature requests easily in this environment. All web service endpoints (URLs) in your request must have the MapID and corresponding map configuration file defined in its MapID List.

 

 

If you have deployed your MDNS Web Services to a multi-processor server, you should take advantage of the web garden support in IIS6 and up. Make sure your MDNS web service is running in its own application pool (do not place any other web applications or the Map File Generator in this pool.) Then increase the web garden process count up to match the number of processors on your server.

 

This web method available on the MapService retrieves the baseline map state of a given map configuration. This baseline state is stored in the application state of the MapService and is refreshed if its associated MapFile changes (assuming the <mapdotnet.mapservicesettings> CheckMapFileTimeStamp is set to true - otherwise you must recycle your application pool on a MapFile change.) The baseline state is also cached on the application side in Application state and used by the MapControlBridge to factory a new MapRequest. MapRequests are then modified to alter the map from its baseline state. Every call to the MapService for drawing serializes and optionally compresses the MapRequest using an MDNSerializer.

 

Feature requests and updates do not use the map rendering engine at all. Spatial and attribute queries go directly to the geo-databases bypassing the map rendering engine for greater performance. Other GIS architectures often make use of the connection and layer abstraction mechanism available in the renderer. MDNS has custom .NET connectors outside of the rendering core to perform query and update requests through the FeatureService and FeatureUpdateService respectively. This allows for a much lighter weight instantiation of query, transform and editing components in a stateless environment. It also allows for optimal use of spatial extensions for the supported back-ends. All of this is abstracted from the end-user so developers need only use the proper MDNS request objects irrespective of the back-end geo-database.