In this topic
About ArcGIS Server and fine-grained ArcObjects
ArcGIS Server uses the same ArcObjects that ArcGIS Engine and ArcGIS Desktop use, so if your server application includes geographic information system (GIS) functionality that performs poorly in an ArcGIS Engine or ArcGIS Desktop deployment, that same functionality will likely perform poorly in your server deployments. Conversely, if that GIS functionality performs well in an ArcGIS Engine or Desktop deployment, it will also perform well in server deployments if the application is properly tuned with respect to how it uses ArcObjects in the server.
Coarse-grained calls to remote ArcObjects, such as the methods on MapServer, GeocodeServer, GeodataServer, GPServer, GlobeServer, or any of their extensions, as well as fine-grained calls to remote ArcObjects, such as looping through the vertices of a polygon, are exposed through the ArcGIS Server API and can be used in your application. However, it is important to note that when making a call from your application against an object running on the server, you are making that call across processes. For example, in the case of a Web application, the Web server is running in one process, while the object is running in another process.
Calls to objects across processes are slower than calls to objects in the same process. If your Web application is running on a Web server that is not the machine running the object, calls are not only cross process, they are also cross machine. This performance difference on the scale of a single call or a few tens of calls is not significant in terms of the overall performance of your application. However, if your application is making thousands of fine-grained ArcObjects calls across process or machine to the server, there can be a performance impact on the application.
Most developers extend the GIS server to optimize the performance of their application. The goal of extending the server is to minimize the number of ArcObjects calls between the client application and the GIS server by encapsulating functionality in server-side components and exposing coarse-grained methods for client applications to call. The following two strategies extend the GIS server for this purpose:
-
Creating utility COM objects—Extending the GIS server with Component Object Model (COM) objects allows you to share your components across ArcGIS Server, ArcGIS Desktop, and ArcGIS Engine customizations. These utility COM objects do not need to be tied to any particular server object configuration or type and can be used in an empty server context. This strategy does have limitations however. When extending the GIS server with a utility COM object, the object must be created at each request made on a particular server object or server context. This means that for pooled server objects, each time a request is made on a server object, the utility COM object must be created. If the COM object has a high initialization cost, this continual creation of the object can be prohibitive. Because the COM object is created for each request, you cannot use it to cache information as it is used. For more information, see the sample Server spatial query COM utility.
- Creating server object extensions—A server object extension (SOE) is created and initialized at the time the server object instance is created and is re-used at the request level, similar to the server object. Consequently, if the SOE is costly to initialize, that cost is paid only once when the server object instance is created. Also, since an SOE instance remains alive as long as the server object instance it is extending is alive, it can cache information that can be re-used from request to request. SOEs are tied to a particular server object configuration or type and cannot be used in an add hoc fashion like a utility COM object.
See the Extending ArcGIS Server topic for more information.
If your application uses fine-grained ArcObjects, it is not necessary to extend the server or a server object. As previously discussed, it depends on the volume of calls that your application makes. If your application is written in such a way that it makes thousands of fine-grained ArcObjects calls, or the number of fined-grained calls is indeterminate based on user interaction with the application, consider moving some of the code to the server. If you design your application so that large volumes of fine-grained ArcObjects calls are not necessary, and your user interface (UI) is designed so that users cannot make requests that result in a large volume of fine-grained ArcObjects calls, then extending the server using either of these techniques is not necessary.