In this topic
About SOEs
All interaction with data in ArcGIS for Server occurs through coarse-grained objects called server objects. These server objects provide methods to access, manipulate, analyze and display data that reside in an instance of ArcGIS for Server. For example, access to a map's contents is provided through the map server object, the functionality of a locator is exposed through the geocode server object, a geoprocessing tool can be accessed via the geoprocessor server object, and so on. These server objects in turn power geographic information system (GIS) services such as map services, geocode services, and geoprocessing services.
It is impractical for ArcGIS for Server to provide solutions for all possible GIS workflows via the out-of-the-box server objects. ArcGIS for Server, therefore, provides an extensibility framework that allows you to create extensions to its server objects and build custom solutions. Such extensions are called server object extensions (SOEs). Only map services can be extended using such SOEs at ArcGIS 10.1.
An SOE is created and initialized at the time the server object instance is created, and is re-used at the request level the same way as the server object. 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 an SOE remains alive as long as the server object instance does, it’s able to cache information that can be re-used from request to request. Further, SOEs can utilize ArcGIS for Server log files to provide status and troubleshooting content, like other ArcGIS for Server components, and can be exposed as SOAP and REST web services.
The ArcGIS for Server extensibility framework also allows you to add behavior to your SOE at different points in its life cycle so that the SOE can have the following:
- Custom behavior every time a request is made to the SOE via SOAP or REST.
- Properties to dictate the SOE's runtime behavior. These properties can be modified using ArcGIS Manager or the Service Editor dialog box in ArcGIS for Desktop.
- "Capabilities" that can be configured for access based on security rules.
SOEs as web services
Server object extensions at ArcGIS 10.1 are web services that can be accessed via REST or SOAP. This section briefly introduces the REST and SOAP web service technologies and how they relate to SOEs.
Representational state transfer (REST) is a pattern that takes advantage of a stateless client-server architecture whereby web services are resources and can be consumed by their URLs. The design for REST is intended to simplify the web service architecture by implementing constraints in parallel with the HTTP protocol.
SOAP, on the other hand, is a means of building web services that communicate through XML. The things that the web service can do are described in an XML document called a web service description language (WSDL). Exposing your Java SOE as SOAP web services allows your SOE to be self-contained and self-described. It also allows your SOE’s functionality to be interoperable among various consumers. Just as your map service has a WSDL endpoint for SOAP access, your SOAP SOE exposed as a web service will have a WSDL endpoint.
Choosing between REST and SOAP web services
The following considerations will help you understand whether your SOE should be implemented with REST, SOAP, or both:
- REST
- You intend for your web service to be consumed by the ArcGIS web application programming interfaces (APIs), for example, JavaScript or Flex.
- The SOE service and client have a shared understanding of the context and content being exchanged. Since there is no formal web service interface description, both clients and servers must understand the data being exchanged.
- Your web service is intended to be delivered into an existing web site. REST web services allow for easy integration using technologies such as asynchronous JavaScript and XML (AJAX) to consume the service.
- SOAP
- A formal contract must be defined for consumers. SOAP web services have WSDL endpoints that describe messages, operations, bindings, and the location of the web service.
- You intend for your web service to interact in a SOAP-based enterprise-level distributed computing system.
The remaining topics in this section of the Help describe development, deployment, debugging, and other aspects related to SOEs.
| Development licensing | Deployment licensing |
|---|---|
| Server | Server |