Pitney Bowes MapXtreme - Manual (Page 106)

Chapter 6: Understanding State Management
What is State Management?
MapXtreme v7.1 106 Developer Guide
The earlier you identify the number of users your web application will have, the better off you are. If
you develop and test an application with a very small number of users (as a pilot project perhaps),
then later on you might discover that your application does not perform well when there are many
users. In that situation, you may find that you need to change your application architecture - a
change which might require you to rewrite your application. It is far better to plan ahead and
anticipate your user load in advance, so that you can use the appropriate state management
architecture from the beginning.
Known Number of Users
Perhaps you are creating an intranet site where you have a finite, defined list of potential users. For
example, you might be creating a web site to be used by a specific department in your organization.
Perhaps you know the names of everyone who will access your site.
Given such a well-defined and finite number of concurrent users, you can consider using the InProc,
non-pooled development model. It is the easiest model to code, but not an appropriate choice for all
applications, because it places substantial demands on web server resources. It creates one
MapXtreme session instance for each concurrent user. However, if your pool of users is finite and
well-defined, these server requirements might not be a problem.
Unknown Number of Users
The other development model is when you do not know the number of users who will want access to
the site. Perhaps you are hoping or expecting that over time your web site will attract more and more
visitors. In this case, the InProc, non-pooled model would be inappropriate, and you should instead
plan on using a pooled development model where you capture each user’s state manually. In the
pooled development model, you will create a finite number of MapXtreme sessions, and each user
request will be serviced by re-using one of the objects from the pool.
The pooled architecture lets you develop your application for scalability. You may later need to add
more servers to handle additional load; thus your application must understand how to save the users
current state and when and how to apply it when the next request comes in to the server. This may
occur on the same server or a different server in your farm. This scalability leads to many options
and choices you can make about how your system will store state, access data, and respond to
multiple requests. This is why it is important to plan out your application and create a strong
architecture that supports distributed applications.
What Should the Initial Map Look Like?
When you develop an application, you must decide what information remains the same for all users.
This includes map layers, labels, titles, and color-coding or other types of thematic shading. This is
known as the background map.
To set up your background map, run the MapXtreme Workspace Manager (a desktop application
installed with MapXtreme), and save your map as a workspace file (.mws file). See
Chapter 23
Workspace Manager .
Once you have created an .mws file, edit your web application's Web.config file to include a
reference to your .mws file. The following Web.config excerpt shows the syntax:
<configuration>
<appSettings>