Vishful thinking…

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

Posted in ArcGIS, ESRI, GIS by viswaug on September 30, 2008

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.


12 Responses

Subscribe to comments with RSS.

  1. Bill Thorp said, on November 18, 2008 at 9:50 pm

    Vish, how do you know about these cool things?!
    I’d love it if you posted some example code sometime.

    Also, does WebEnabled have to be set to True in the Extension Info?
    I couldn’t get my SOE working without that.

  2. […] SOE’s without the SOAP Vish recently wrote about calling AGS SOEs via SOAP instead of DCOM.  He doesn’t mention that AGS doesn’t make you use SOAP, nor XML for that […]

  3. prebuf said, on November 28, 2008 at 4:08 pm

    Vish, I have extended the NA Extension of ArcObjects. Now I´m planning to extend the NAServer extension of ArcGIS Server providing the same functionality as the extension I mentioned before. Since I´m planning to extend the naserver I think SOE will be better, but I´m not that sure. Do you suggest me to use the utilities COM object or the SOE? I would appreciate it much any response. Thank you.

  4. viswaug said, on November 28, 2008 at 5:23 pm

    Hi Prebuf,

    Your extension is best developed as a SOE rather than a COM utility object. The reason being that the SOE already has access to the connection to the MapService and it’s network data sources. If you build a COM utility you will most probably end up making a connection to the data sources on every request. SO, SOE is the best solution for your extension. Let me know if you have any other questions…

    Thank You,

  5. Ottar Viken Valvåg said, on January 19, 2009 at 1:48 pm

    This is great stuff, Viswaug.

    Have you got any more details on the Message class? I have no luck trying to use it. Parsing SOAP is indeed tiresome.

    Also, any thoughts on how best to create a REST endpoint? Is there some way of handling all HTTP requests oneself? Does the IRequestHandler interface only handle POST requests?


  6. Ray said, on December 4, 2009 at 8:57 am

    Hi Vish,

    If there were 2 things that you wished ArcGIS 9.3 would do, but doesn’t, what would they be?



  7. Andy said, on February 1, 2010 at 3:19 pm


    Sorry but I think I might be missing something here. I don’t see how this saves you any licenses as the request will still end up @ the SOC on the ArcGIS Server tier?

    Do you mean that you can take some of the load of ArcGIS Server by extracting of the soap/rest bit and putting this on another box e.g. web server thereby saving some extra hardware?


  8. viswaug said, on February 1, 2010 at 6:26 pm

    hi andy,

    the SOE would help u avoid a web adf license on the web server box. which before 9.3.1 used to be a full blown ags license. but after 9.3.1 the web adf runtime is free.

    thank you,

  9. Michael said, on February 2, 2010 at 2:31 pm

    Vish, thanks for this post… have a trouble understanding with the WSDL part. How can I generate the wsdl ? what it should look like if it’s not possible to get it generated for me ?

    also, are there any samples how could I expose the SOE via REST?

    thanks !

  10. Andy said, on February 4, 2010 at 2:38 pm


    I’ve just been watching your presentation Harnessing Server Object Extensions from the dev summit. Please can you explain why you had both SOE’s & GP Services (e.g. for clip etc) for the JS API data editing example you showed?


    • viswaug said, on February 6, 2010 at 4:08 am

      Hi Andy,

      The spatial validation rules that we had to perform before the feature was added to the database was pretty big & complex. So, instead of writing those rules in ArcObjects to be called from the SOEs, we decided to perform the spatial validation in a GPTask and call it from the SOE. The GPTask was pretty well-suited for performing the spatial validations and it was much more effecient to write GPtasks to do it over writing ArcObjects which would have been time-consuming. I would have liked to do it in the SOE if it wasn’t time intensive.

      Thank You,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: