What is a server object extension?

Server object extensions (SOEs) allow you to extend the base functionality of ArcGIS Server map and image services. No other service types are supported. Most SOEs do this by using ArcObjects code to work with 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 web APIs. SOEs have the following 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 web APIs to easily invoke them. In fact, your REST SOEs will be shown in the ArcGIS Services Directory and can expose the typical object types that the ArcGIS web APIs understand, mostly in JSON format.

• 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 expose ArcObjects functionality that is not available in any other manner or that needs to be executed very quickly.

SOEs are for experienced developers and require knowledge of various development platforms. The ArcObjects SDKs for Java and the Microsoft .NET Framework contain several SOE samples that you can examine.

What you need to know to develop an SOE

SOE development requires knowledge of ArcObjects use through Java or the .NET programming languages. It also requires an understanding of REST or SOAP principles.

Additionally, if you want to write custom property pages for your SOEs beyond those automatically generated, you must have a knowledge of Windows forms development or Java Swing (for ArcCatalog pages) or web forms development using Hypertext Markup Language (HTML) and JavaScript (for Manager pages).

Do you need an SOE?

SOEs can require knowledge of web service development and ArcObjects and must go through a deployment process to be made available to your server. Before you develop a server object extension, you might consider some easier alternatives.

The simplest alternative to developing an SOE may be to create a geoprocessing model that accomplishes your business logic, then publish it as a service. You can use ModelBuilder to interactively drag, drop, and connect the needed tools instead of writing ArcObjects code. Geoprocessing services also allow for asynchronous execution, allowing you to start a job, do something else, and come back later to check the results.

One drawback of geoprocessing services is that they have a relatively large memory footprint and may 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.

Many developers have written ArcObjects code in the past for various tasks that are now attainable without ArcObjects. For a detailed discussion of ways to approach web mapping challenges without using ArcObjects, see Alternatives to server object extensions.