This document was published with ArcGIS 9.3.1.
This topic applies to 9.3.1 and later versions.
| Development licensing | Deployment licensing |
|---|---|
| Server | Server |
Server Object Extensions
A Server Object Extension (SOE), as the name suggests, extends ArcGIS Server objects such as the MapServer object. It is created and initialized at the time the Server Object instance itself is created and is re-used at the request level, like the Server Object itself. So, if the SOE is costly to initialize, that cost is paid only once when the Server Object instance is created. Also, since an instance of a SOE remains alive as long as the Server Object instance, it’s able to cache information that can be re-used from request to request. SOE’s are tied to a particular Server Object configuration or type and can't be used in an ad-hoc fashion like a Utility Object.
If your application makes fine-grained use of ArcObjects, it's not necessary to always extend the server or a Server Object. The decision to extend the server will typically come down to the volume of those 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, you should consider moving some of the code into the server. If you design your application such that large volumes of fine-grained ArcObjects calls are not necessary, and your user interface is designed such that your 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.
SOE’s have the following advantages over creating a Utility objects:
- Developers don't need to explicitly create instances of a SOE in a context. The SOE is created by the GIS server when the Server Object instance itself is created.
- If the functionality that is exposed by the extension requires resources that can be costly to acquire, the initialization cost of the creating the object is paid once when the Server Object and its extensions are initially created.
- If the functionality that is exposed by the extension can benefit from some caching logic, it’s possible to implement such logic because the cache will remain for as long as the Server Object instance itself remains in the pool.
- ArcGIS Server administration applications can be extended to include custom properties dialogs for configuring custom extensions for specific Server Object configurations.
- SOE’s can utilize ArcGIS Server log files to provide status and troubleshooting content, like other ArcGIS Server components.
- SOE’s can be exposed and accessed via SOAP, web access.
As stated above, a SOE extends an ArcGIS Server Object. In addition to creating SOE's to Server Objects, the ArcGIS Server extensibility framework also allows developers to add custom behavior to their SOE at different points in its life cycle such that their SOE:
- Can have custom behavior when a ServerContext is created and released.
- Can have properties which can be modified to change the SOE's runtime behavior. These properties can be modified using ArcCatalog or ArcGIS Manager. For example, the SOE can be configured to work with a different layer in the associated MapServer object.
- Can have functionality declared in custom interfaces creating new ArcObjects types to be implemented by SOE's.
- Can have 'operations' that can be configured for access based on security rules.
- Can log its operations.
In the following sections we will be covering development concepts of SOE's by walking through one of the developer samples. Our intention is to have a working SOE as a business unit and a working client to take advantage of the SOE features while taking you through the development and administrative concepts required for you to go out on your own and develop your own SOE's.
