Tag Archives: Java

Not long ago, we published an early deprecation notice announcing upcoming changes to ArcGIS Server in its 10.1 release. Reading between the lines, many of you realized that in the future, ArcGIS Server will become purely a server of GIS Web services. This is an architecture that has many advantages, but considering the code you may be accustomed to writing on top of local (DCOM) connections,it will bring significant changes to the way you think about developing with ArcGIS Server. Particularly, the 10.1 changes affect applications built with the Web ADF that make use of ArcObjects and nonpooled services.

This post is an early discussion of the path to move to a pure Web services pattern for communicating with ArcGIS Server. We will also disclose some additional information regarding our ArcGIS 10.1 plans so you have a better context to some of the changes in the deprecation notice. The intent of this post is not only to help you evaluate the impact of ArcGIS 10.1 on your existing applications, but also to outline and promote a Web services pattern in your development that aligns with the ArcGIS Server road map.

When ArcGIS Server first hit the market, we provided two hooks into it: you could access its Web services through HTTP, and you could also use local connections over DCOM. Local connections were handy when out-of-the-box Web services did not give you all the functionality you needed. In fact, through local connections, you could execute ArcObjects code on your server that your Web application could use. While the concept of executing ArcObjects logic in the server remains a powerful concept, the way in which this happens is changing.

At ArcGIS Server 9.3, we introduced new APIs for the development of Web applications. These APIs (for Flex, Javascript and Silverlight) did not use local connections at all. Instead, their only hook into the server was Web services. All these APIs invoked GIS functions through stateless REST-ful Web services.

This new Web services architecture is a simpler one. It results in easier-to-maintain applications, and faster and more scalable deployments. As of today, most ArcGIS Server development is happening through these APIs.

A particular point of concern for many developers revolves around ArcObjects access. The pattern for accessing ArcObjects functionality in the Web ADFs is widely known, but how do you get to ArcObjects from the ArcGIS Web Mapping APIs? And how will ArcObjects access occur in ArcGIS 10.1 with the deprecation of local connections?

In this post we’ll describe specific scenarios where Web ADF developers have traditionally used ArcObjects programming and local connections to ArcGIS Server. For some of these scenarios, we’ll describe how you might accomplish the same thing using alternative techniques. Where appropriate, we’ll also describe how you could address these scenarios using a Web services programming pattern with ArcObjects.

Reasons people use ArcGIS Server local connections…and some alternatives

As we browse the user forums and attend Esri conferences, we hear several common reasons that developers still use local connections in their Web applications. Here are a few of those reasons, accompanied by some alternatives.

Creating layouts for printing

We’ve met some developers who 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 ArcMap-quality maps and their surrounding elements, generate printable documents in large formats, and so on.

At ArcGIS 10.0, we recommend you use the arcpy.mapping Python module to script your layout construction and map printing. Then, 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.

See this blog post for a brief introduction to the arcpy.mapping module and its use within ArcGIS Server.

As we move on to ArcGIS Server 10.1, keep in mind that we will enhance the arcpy.mapping capabilities. Specifically, we plan to make it very easy 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 use local connections is to change the symbology of a particular layer in a map service. This workflow often required the use of non-pooled services, limiting the scalability of your 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 in the developer to keep a healthy state on the map instance itself. Let’s discuss a couple of alternatives here.

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 currently requires ArcObjects.

ArcGIS Server 10.1 will enhance the map service such that you can alter the contents and symbology of the map at runtime (like you could with ArcIMS). You will no longer need to use nonpooled services and fine grained ArcObjects to change symbology on your map service layers. Instead, you will be able to decide, on a per request basis, the contents or symbology to be used in the map you want to create.

This enhancement will make your applications significantly more scalable, while simplifying development and maintenance. Defining the symbology of your layers in the map service at runtime will be done by including the renderer information in your Web service request to draw the map, along with the typical information such as visibility of layers, extent, and so on. All the Web Mapping APIs will include utility classes so you can esily define content, renderers, class breaks , symbology, and so forth.

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 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 at ArcGIS Server 10.0, editing is now 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, auto-complete 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.

To get an idea of how Web editing works through REST, we recommend this article on editing using the ArcGIS API for JavaScript. Most of the concepts also apply to the ArcGIS API for Flex and the ArcGIS API for Silverlight/WPF.

There is one workflow for which support will not be continued in ArcGIS 10.1: long transactions. In the Web ADF, you can leverage nonpooled services to perform edits following a long transaction model. In essence, you can start updating features and roll back at any time. With the feature service, all operations are stateless, meaning that you can’t really 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 very few workflows where the new architecture of ArcGIS Server 10.1 will 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 2.2 version of the ArcGIS Web APIs, undo-redo operations are possible right 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 Desktop. While feature services support editing on versioned data (as well as non-versioned), it is not possible to switch the version at runtime in ArcGIS Server 10.0. That is, the only version that Web clients can edit through a feature service is the one that was used when authoring the map service itself. For the 10.1 release, we are aiming to enhance feature services so you can efficiently target a version for your edits at runtime from any web application.

Performing business logic

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 went the ArcObjects route to accommodate this.

In many cases, these processes can be expressed in ArcGIS Model Builder, where you can graphically “chain” tools together. These geoprocessing models can be exposed as Web services and consumed from your Web applications. Go here for a quick introduction to geoprocessing in ArcGIS Server. 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.

Custom geoprocessing tools

Aside from the flexibility of having hundreds of out of the box tools that you can combine in Model Builder, geoprocessing gives you the ability to develop custom tools. The simplest way is to create Python scripts that can either run on their own, or in combination with other tools within a model. We described an example of this earlier with the use of arcpy.mapping to create high quality maps over the Web. For general guidance on building python script tools for the geoprocessing environment, go here.

For even further control, you can go beyond Python to create a custom geoprocessing tool with C#, VB.Net or C++. This allows you to embed your own fine-grained ArcObjects logic within your models. Here is a help topic with details on how to create a custom geoprocessing tool with C#.

Whether you use Python or another language, the advantage of creating custom tools is that you can reuse them in different workflows, since they will 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-time running processes.

The geometry service

Geoprocessing services are handy, 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 already do the job. You may 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, measuring lengths and areas, and so on. 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. In this white paper we explore a scenario comparing the use of the Geometry service versus a geoprocessing service for solving a simple selection by distance problem.

For simple problems, geoprocessing and ArcObjects are too heavy-handed of a solution. You might save yourself some work by studying and understanding what is possible with map service queries, geometry service calls and so on.

Geoprocessing models are generally appropriate for long running and complex processes. As a developer you can always extend this framework with Python and custom ArcObjects geoprocessing tools to face the most challenging problems. In the next section we discuss yet another alternative, which may be the way to go for tasks that need to run very quick.

Server object extensions

If you have well-defined business logic that you want to execute quickly, an alternative approach is to develop a server object extension (SOE). SOEs are an advanced developer option that allow you to expand the base functionality of ArcGIS Server services. SOEs have two great advantages:

1. SOEs can be exposed as SOAP or REST Web services, allowing clients built with the ArcGIS Web APIs (for JavaScript, Flex, Silverlight, iOS, etc.) to easily invoke them. In fact, your SOEs will appear in the ArcGIS Services Directory and can expose the typical object types that the ArcGIS APIs understand such as feature sets, primitive types etc.
2. SOEs encapsulate ArcObjects efficiently, and provide an ideal environment to execute your calls very quickly.

You might build an SOE to extract an elevation profile from a raster, or work with dynamic segmentation to get the location of a mile marker. In these cases, SOEs expose functionality that is either not available through any other means (through out of the box geoprocessing tools or other ArcGIS Server services) or functionality that needs to be executed quickly.

Here is an example showing an SOE being used from an ArcGIS API for Flex application. This SOE uses the 3D Extension libraries in ArcGIS Server to perform a quick terrain profile. In this particular scenario, we did not find geoprocessing tools that could help us with the profile generation, so we knew we were going to write our logic in ArcObjects. Given that this is a very quick operation not requiring asynchronous execution, we decided to use an SOE.

SOE development requires knowledge of ArcObjects,.NET or Java, and Web service communication technologies such as REST and SOAP. The ArcObjects SDK has several samples that you can examine, both for Java and .NET.

If you plan on developing new SOEs, keep in mind that in ArcGIS Server 10.1 you will be required to analyze your map documents before publishing them and fix any errors that appear. Thus, one of the things you can do to get your SOE’s ready for 10.1 is to make sure they work against MSDs at 10.0. Building SOE’s on top of MSD based map services with ArcGIS Server 10.0 is perfectly possible. The biggest requirement is that you avoid using MXD-specific interfaces (such as IMap, ILayer, anything to do with page layouts, and so on). Here is a blog post describing how you can use IMapServerDataAccess to get to the data sources of an MSD-based map service.

We realize that accessing layers and layouts is handy when you want to do some of the things we described earlier, like changing the symbology of layers, high quality printing, and so on. Much of the new functionality in 10.1 will help you through the places where it’s currently challenging to make an MSD-compliant SOE. By looking at some of the scenarios described in this post such as map printing through the arcpy.mapping module and changing the symbology of layers, you will begin to understand how to properly address your workflows at 10.1.

Conclusion

This post offers important direction for ArcGIS Server developers as you make plans for current and future releases. Information provided is based on the current status of our 10.1 work and is subject to adjustment during the 10.1 beta cycle. We look forward to communicating with you further on these and other topics of interest to Server developers. Please use the comments section of this blog post to leave questions.

Contributed by Ismael Chivite of Esri Product Management and Sterling Quinn of the ArcGIS Server development team