In this topic
- About server object extensions
- Availability of SOEs
- What you need to know to develop an SOE
- Do you need an SOE?
About server object extensions
Server object extensions (SOEs) allow you to extend the base functionality of ArcGIS for 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 application programming interfaces (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 and mobile APIs 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, mostly in JavaScript Object Notation (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 (through out-of-the-box geoprocessing tools or ArcGIS Server services), or that needs to be executed very quickly.
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
SOEs are primarily designed for extending map and image services. SOEs must avoid using ArcObjects from the Carto library that are designed for map document (MXDs) files, such as IMap and ILayer. Instead, SOEs should use ArcObjects designed for working with map services, such as MapServer, ImageServer and related classes. You can use the IMapServerDataAccess interface to access the datasets underlying each layer in the map, and the IImageServerInit3 interface to access the mosaic or raster dataset of the image service.
Image service SOEs are supported starting from 10.2.
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.
Additionally, to build the optional properties pages for your SOEs, 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 extensive development and must go through a deployment process to be made available to your server. Before you develop an SOE, 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 just drag and drop tools in ModelBuilder to create the model, then you publish the model to the server. 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 for Server workflows, since they behave like any other tool.
Drawbacks of geoprocessing services
Geoprocessing services 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.
Considering the geometry service
Before you build a geoprocessing service or an SOE, you can verify 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.