What is a server object extension?

In this topic

About server object extensions

Server object extensions (SOEs) allow you to extend the base functionality of ArcGIS Server. Most SOEs do this by using ArcObjects code to work with geographic information system (GIS) data and maps. ArcObjects are the core components on which ArcGIS is built, and allow you the most flexibility in writing GIS functions.
SOEs are appropriate if you have some well-defined business logic to perform that is not easily accomplished using the ArcGIS APIs. SOEs have the following great advantages:
  • You can expose an SOE as a Representational State Transfer (REST) and/or Simple Object Access Protocol (SOAP) Web service, allowing clients built on top of the ArcGIS application interfaces (APIs), for example, Javascript, Flex, Silverlight, iOS, and so on, to easily invoke them. In fact, your SOEs will be shown in the ArcGIS Services Directory and can expose the typical object types that the ArcGIS APIs understand.
  • When you build an SOE, you’re providing coarse-grained methods that perform work on ArcGIS Server, rather than making a large number of calls from the client to the server. SOEs encapsulate ArcObjects logic very efficiently, providing an ideal environment to execute your calls quickly. 
You might develop an SOE if you wanted to work with dynamic segmentation to retrieve the location of a mile marker, or trace geometric networks for upstream and downstream calculations, and so on. In these cases, SOEs expose functionality that is not available in any other manner (through out-of-the-box geoprocessing tools or ArcGIS Server services), or that need to be executed very fast.
SOEs are for experienced developers and require knowledge of various development platforms. This section of the software development kit (SDK) contains several samples that you can examine. 

Availability of SOEs

You can build an SOE to extend any type of service; however, SOAP and REST Web service SOEs are currently available with map services only.
SOEs that access MSD-based map services ("optimized map services") must avoid using fine-grained objects from the Carto library, which are designed for MXDs. For more information, see Accessing MSD-based map services with SOEs.

What you need to know to develop an SOE

SOE development requires knowledge of ArcObjects, .NET, or Java programming languages and Web service communication technologies such as REST and SOAP. The ArcObjects SDK has several samples that you can examine, both for Java and .NET.
Additionally, to build the optional properties pages for your SOEs, you must have a knowledge of Windows forms development (for ArcCatalog pages) or Web forms development using Hypertext Markup Language (HTML) and JavaScript (for Manager pages).

Do you need an SOE?

SOEs require extensive development, and must be deployed on each server in your configuration. Before you develop a server object extension, you can consider some easier alternatives.

Geoprocessing services as an alternative to SOEs

Some GIS applications run a specific series of geoprocessing tools to perform some business logic. These tools might predict timber yield from a forest, identify suitable sites for a restaurant, or estimate where a toxic cloud could spread. In many cases, these processes can be expressed in ArcGIS ModelBuilder, where you can graphically "chain" tools together. You can expose these models as geoprocessing Web services, to be consumed in your applications.

Benefits of geoprocessing services when compared with SOEs

Using a geoprocessing service can save you a lot of coding, because you’re often just dragging and dropping tools in ModelBuilder. Also, you can leave an asynchronous geoprocessing job running on the server while you do other things, then check later to get the results. Geoprocessing services are handy for long-running and complex processes.
Along with offering hundreds of out-of-the-box tools, ArcGIS geoprocessing allows you to develop custom tools. The simplest way is to write Python scripts that can be run in a stand-alone manner or integrated with other tools within a model. A great example is the arcpy.mapping module which is recommended for creating print-quality maps through the Web.
You can also create custom geoprocessing tools with C#, Visual Basic .NET, or C++. This allows you to embed your own fine-grained ArcObjects logic within your tools and models. You can also re-use these custom tools in non-ArcGIS Server workflows, since they behave like any other tool.

Drawbacks of geoprocessing services

Geoprocessing services have a large memory footprint and often run slower than SOEs. If you’re running a process only a few times a day, this might not be an issue. However, if you are running a process many times a day, or with many concurrent users, it might be worth investing the time to build an SOE.

Considering the geometry service

Before you build a geoprocessing service or an SOE, you can check to see if the geometry service offers the methods that you need. A geometry service can perform basic GIS operations such as buffering, determining spatial relationships, measuring lengths and areas, and so on. Calling a series of methods on a geometry service and combining them with the query capabilities of map services can be simpler and faster than using a geoprocessing service. In one test scenario, the geometry service was able to handle over 98,000 requests per hour for a simple buffer plus selection operation, compared to about 11,000 requests per hour handled by a geoprocessing service.