ArcGIS Server: Expose a custom server object extension via SOAP

Extending ArcGIS Server using ArcObjects can take two forms: a utility COM object or a server object extension. A utility COM object is simply a COM component created and managed explicitly in server context. A server object extension (SOE) is coupled with a server object and thus can share initialization, resource utilization, and disposal. Use of a COM utility has been possible since the first version of ArcGIS Server (9.0). Custom SOEs were introduced for ArcGIS Server .NET at version 9.2. ArcGIS Server Java does not offer an SOE solution at the moment, but it is likely forthcoming. The reasons for extending ArcGIS Server and differences between both techniques are available elsewhere so I'll skip that discussion here. I want to discuss exposing ArcObjects logic in a custom server object extension via a prepackaged ArcGIS Server Web service handler. Two major protocols are supported, SOAP and REST. Let's dive in...

The ArcGIS Server SOAP API is implemented at the server object level. This means that SOAP messages are processed directly by a server object or extension (SOE). The ArcGIS Server SOAP Web service handler directs SOAP messages to a server object for you. The ArcGIS Server REST API is not implemented at the server object level. The ArcGIS Server REST Web service handler processes restful requests and (in general) uses the ArcGIS Server SOAP API to communicate with ArcGIS Server. How does this relate to exposing a custom SOE as a Web service? The SOAP Web service handler contains logic to discover custom SOEs with a SOAP interface (see sample and discussion below). The REST Web service handler does not contain the logic to discover custom SOEs at this time. Consequently, to expose a custom SOE as a REST service you’ll need to create your own Web service to handle restful requests and work with the SOE. Unfortunately this means you'll need to work with ArcObjects remotely in the Web service logic, which will require an ArcGIS Server license in the app-tier... a less than optimal solution. The folks at ESRI who work on the REST handler may resolve this in the future.

I've included a sample that illustrates how to expose a custom SOE via the ArcGIS Server SOAP Web service handler. It builds on the current Server SDK sample which shows how to create a simple SOE.

I’ve modified this sample to illustrate how to support exposing a custom SOE using an ArcGIS Server Web service endpoint. The sample is merely instructive, so it just provides the basics of custom SOE development. To expose a WSDL for the custom SOE and make it available via an ArcGIS Server Web service endpoint, create a WSDL and put it in the \XmlSchema folder on the machine where the SOM is running. The name of the registered server object extension and the name of the *.wsdl file must be the same. To process SOAP requests, implement the IRequestHandler and IRequestHandler2 interfaces in the custom SOE class. In this example, the implementation code parses the incoming SOAP request and generates a raw SOAP response string. The response should match the WSDL definition.

Download the sample here.

Everything is pretty raw and simple at the moment, but it works. I’m sure there’s a better way to create the WSDL and generate SOAP responses, but that’ll take some additional research. Once the custom SOE is deployed and enabled on a map service, you can use the following url to get the WSDL: http://localhost/arcgis/services/<service name>/MapServer/SimpleSOE_CSharp?wsdl