You will hear me talk a lot about SOEs this year as the best practice for providing low-level GIS functionality on the web. What are these SOEs and why should you use them? An SOE (Server Object Extension) is a class and a set of methods that are developed to run within the SOC and then can be called by web applications. We just introduced them in Java in ArcGIS Server 9.3.1 and I think they may be the most important thing the Java team worked on at 9.3.1.
What are the advantages of writing an SOE?
- Modularizing your code. SOEs allow you to separate low-level ArcObjects business logic code from presentation code. ArcObjects developers can write SOEs without knowing JSF and JSF developers can create great web applications without knowing ArcObjects.
- Performance. There are several cases where you will see huge performance gains.
- Round-trips. A lot of developers have written code or tasks that take lots of round trips to the Server. In many cases the calls to the server don’t take a lot of processing time but the network overhead is killing their application performance.
- Fine-grained ArcObjects. If you need access to fine-grained ArcObjects you should put that code in an SOE. Fine-grained ArcObjects code almost always requires lots of round-trips. Use an SOE.
- Data Analysis. If you are transferring data to your application for analysis then you should really think about either a Geoprocessing model if possible or an SOE for complex analysis. For example, one developer I met wanted to get the median value of one of the attribute fields. He queried all records and then computed the median in his JSF code. When we moved his code to an SOE there was a 75% performance savings. The only time you should be transferring data from the SOC to the client is to present it to the user.
It’s SOE Easy!
We have put a lot of effort to make the development and deployment of SOEs easy. Take a look at the documentation on SOEs to find out about them.