Exposing ArcGIS Server Object Extensions as a Web Service – Will save you some licenses

What is good about building your application’s features as a Server Object Extension? Here are some

1. Server Objects Extensions run inside the ArcGIS Server Context and lets you avoid those calls that go across processes and sometimes across machines. This can deliver a significant boost to your application’s performance and improve its reliability and scalability.
2. Provides a way to incur some expensive initialization logic just once when the Server Object spins up. Server Object Extensions live and die with the Server Objects.
3. Some caching logic can also be implemented on the Server Object Extensions to eliminate avoidable loads on the ArcGIS Server. Caching here can go a long way in improving the performance of the application.
4. Allows developers to expose coarse-grained functionality by writing straight ArcObjects code. Not all developers fully recognize when to use ‘new’ or ‘CreateObject’ to create ArcObjects classes.

After the Server Object Extension (SOE) has been written, you will want to expose the service to your web applications. If you are writing Web Services to expose the SOE functionalities to your clients, you will still need to use the ‘AGSServerConnection’ or the ‘GISServerConnection’ classes to access the SOE’s methods. This means that the web server machine where you web service is hosted will need an ESRI license. If you want to farm out your web server, you will need an ESRI license for every one of your web servers.

But there is a way around this, your SOEs can be exposed as SOAP web services directly. This means that your clients can access the SOE as web services on the ArcGIS Server machine directly. Or you can build proxy web services or REST services that in turn expose the service to the clients. In order to expose your SOE’s methods as web services, you will need to do two things

1. Create a new WSDL file with the definitions for the methods on the SOE. The name of the WSDL file should be the same as the name with which the SOE was registered with ArcGIS Server referred to as the Extension Type. The file should be saved in the ‘C:\Program Files\ArcGIS\XmlSchema’ folder.
2. Implement the ‘IRequestHandler2’ interface on the Server Object Extension.

Once the above two steps have been accomplished, ArcGIS Server will now publish your SOE’s method as a web service. When the clients request a WSDL from the MapServer, it will serve the updated WSDL with the SOE’s method definitions in it. And when the clients make a request to the SOE’s web service, ArcGIS Server will route the request to the ‘HandleStringRequest’ method on the ‘IRequestHandler2’ interface implemented by the SOE.

The implementation of the ‘HandleStringRequest’ method on the SOE should parse through the SOAP request sent into it and retrieve the input parameters. The input parameters can then be used to execute the request and return the SOAP formatted response. This could be a major pain and I always had a major hang-up with writing code to parse SOAP request messages and form SOAP responses. But I just recently came to know that ESRI has recently exposed some internal classes that did exactly that. This wasn’t available in the 9.2 version and I don’t believe in the 9.3 betas. The ESRI class that would help in doing this is the ‘MessageClass’ class.

Yes, it is a little more work. But once you get the plumbing right once, it is easily repeatable. I believe that the extra effort on the developers part is well worth it in terms of $$$ saved in licensing.