Sometimes the breadth of ArcObjects and the challenge of coding a web service can make server object extensions (SOEs) difficult for beginners. This topic discusses some common web GIS tasks for which developers have traditionally written ArcObjects code and gives alternative approaches that do not require writing an SOE or knowing ArcObjects.
Creating layouts for printing
Many developers have used ArcObjects to access the Layout object of the map service, specifically for putting high quality printing functionality in their web applications. They use ArcObjects to work with maps with quality such as in ArcMap and their surrounding elements, generate printable documents in large formats, and so on.
ArcGIS 10.0 introduced the arcpy.mapping Python module that you can use to script your layout construction and map printing. Then you can expose the script through a geoprocessing service. With arcpy.mapping, you can manipulate map documents to a very fine degree: you can add layers dynamically to the map, update their symbology, and more. You can also access the layout of the map, manipulating elements such as text and images.
In ArcGIS 10.1, arcpy.mapping abilities were enhanced. Specifically, it became easier to dynamically load the contents of a web mapping application (including map services and graphics) into a map document using arcpy.mapping.
Changing symbols and renderers
Another reason developers used ArcObjects in the past was to change the symbology of a particular layer in a map service. This workflow often required the use of nonpooled services, limiting the scalability of applications. Some developers managed to do this with pooled services, although switching the state of a service back and forth to satisfy requests from multiple users often resulted in poor performance and left a great deal of responsibility to the developer to keep a healthy state on the map instance itself.
The ArcGIS Web APIs give you an easy way to symbolize features using a client-side feature layer or graphics layer, whose rendering properties can be changed at any time. The idea is that the geometry and the attributes of visible features are all downloaded to the client, so it's easy for the client to draw the features using any colors, widths, or class breaks defined by the application developer.
The feature layer technique is particularly effective for thematic mapping, interacting with and highlighting features, and so on, but it falls short when you are working with thousands of features or very complex polygon features. In those cases, the best approach is to request symbology changes at the service level and have the map service render the map image. This previously required ArcObjects.
ArcGIS 10.1 enhanced the map service such that you can alter the contents and symbology of the map at run time (like you could with ArcIMS). You no longer need to use nonpooled services and fine-grained ArcObjects to change symbology on your map service layers. Instead, you can decide, on a per request basis, the contents or symbology to be used in the map you want to create.
This enhancement can make your applications significantly more scalable, while simplifying development and maintenance. Defining the symbology of your layers in the map service at run time is done by including the renderer information in your web service request to draw the map, along with the typical information of visibility of layers, extent, and so on. The 3.0 versions of the ArcGIS Web APIs include utility classes so you can easily define content, renderers, class breaks , symbology, and so forth.
To learn more about changing contents and symbology on the fly in a map service, see About dynamic layers.
Web editing
In the early releases of ArcGIS Server, editing data over the web had to be accomplished purely through ArcObjects custom code leveraging local (DCOM) connections. In version 9.2, an Editor Task was introduced in the Web ADF allowing basic editing such as creating, moving, and deleting features. Any customization of this task or the creation of editing tools from scratch still required extensive ArcObjects programming.
The REST-based APIs did not initially expose web editing; however, with the introduction of the feature service in ArcGIS 10, editing became possible through these APIs. Not only is editing possible through REST, it's convenient to customize because many common editing methods, such as cut, trim, extend, autocomplete polygons, and reshape, are exposed through the REST implementation of the geometry service. Finally, when you edit with REST, you can use pooled services. This is a huge boon to performance.
There is one workflow for which support was not continued in ArcGIS 10.1: long transactions. In the Web ADF, you could leverage nonpooled services to perform edits following a long transaction model. In essence, you could start updating features and roll back at any time. With the feature service, all operations are stateless, meaning that you can't roll back at the database level (although you could with business logic in your application). A long transaction model for web editing is one of the few workflows where the new server architecture at ArcGIS 10.1 does not offer alternatives.
It is important to highlight that lack of support for long transactions does not preclude you from implementing undo/redo operations. In fact, in the ArcGIS Web Mapping APIs, undo/redo operations are possible directly from the API at the application level.
Another unique capability that nonpooled services give you is the ability to change versions while editing. This allows, for example, web users to store their changes in different versions that can be reconciled later from ArcGIS for Desktop. ArcGIS 10.1 enhanced feature services so you can efficiently target a version for your edits at run time from any web application.
Performing business logic with geoprocessing
Some GIS applications run a specific series of tools to perform advanced GIS business logic. These tools might predict timber yield from a forest, identify suitable sites for a restaurant, or estimate where a toxic cloud could spread. Many developers have used ArcObjects to accommodate this.
In many cases, these processes can be expressed in ArcGIS ModelBuilder, where you can graphically "chain" tools together. These geoprocessing models can be exposed as web services and consumed from your web applications. The benefits of this are obvious: Using a geoprocessing service can save you a lot of coding. Also, you can take advantage of the asynchronous execution of geoprocessing services, which is challenging to achieve by writing your own ArcObjects code.
Aside from the flexibility of having hundreds of out-of-the-box tools that you can combine in ModelBuilder, geoprocessing gives you the ability to develop custom tools. The simplest way is to create Python scripts that can run either on their own or in combination with other tools within a model. This topic described an example of this earlier with the use of arcpy.mapping to create high-quality maps over the web.
For even further control, you can go beyond Python to create a custom geoprocessing tool with C#, Visual Basic .NET, C++, or Java. This allows you to embed your own fine-grained ArcObjects logic within your models.
Whether you use Python or another language, the advantage of creating custom tools is that you can reuse them in different workflows, since they behave just like any other out-of-the-box tool. Additionally, your ArcObjects or Python code can execute within the asynchronous execution model of geoprocessing services, which is quite handy for long-running processes.
Performing geometric calculations
Geoprocessing services are useful, but just like you should not jump into ArcObjects development when something can be easily achieved with geoprocessing, it's wise to avoid jumping into geoprocessing if out-of-the-box services can do the job. Check to see if the SOAP- or REST-based geometry service offers the methods that you need. A geometry service can perform basic GIS operations such as buffering, determining spatial relationships, and measuring lengths and areas. Calling a series of methods on a geometry service and combining that with the query capabilities of map services and client-side logic can be simpler and faster than using a geoprocessing service.