Posts Tagged ‘Web ADF’

ArcGIS Web ADF, JavaScript, and REST

September 25, 2009

Repost from Rex Blog

Currently the Web ADF does not include an ArcGIS Server data source that supports consuming ArcGIS Server services via REST. Instead, the pre-packaged ArcGIS Server Internet data source uses the SOAP API to consume ArcGIS Server services. From a platform perspective, this makes sense because the Web ADF is founded in a rich, server-side ASP.NET development environment where SOAP provides some clear benefits. Let’s look at this topic in more detail…

REST is a lightweight, non-standard format which can be used to request data over HTTP. REST is especially attractive to browser developers because it can be leveraged with JavaScript, JSON, and HTML to create an efficient, pure client solution – namely one that uses only browser logic and can initiate cross-domain requests for data. In general, requests contain a manually concatenated string of argument-value pairs and responses consist of standard content types, such as JSON (text) and images. While the benefits of using REST in a browser context with JavaScript are clear, other application environments present some hurdles. Since REST is not founded on a public standard, a developer needs documentation to learn how to interact with a REST service. This may suffice when working with client script, but developers working in an IDE with object-oriented languages like C#, VB.NET and Java often demand more. Why parse strings when you can work with explicit service types, discover parameters using intellisense, and utilize a proxy to manage requests\responses? This is where SOAP comes into the picture. SOAP is a standard W3C procotol which defines the XML message format for requests to and responses from a SOAP service. WSDL, another W3C standard language, provides the contract for how a consumer can interact with a SOAP service. While a SOAP message is an XML formatted string, a developer does not need to construct and parse it manually. Since SOAP is based on standard protocols and languages, toolkits for specific development environments are available to automatically construct native types. More specifically, the WSDL is used to construct a proxy class and a set of supporting types for use in an specific object-oriented environment. The proxy class exposes a set of operations (methods) which initiate Web requests. The supporting types are used to define inputs as value objects (termed ‘value objects’ because they only store values), which the proxy uses to construct a SOAP message. The response from a service can be deserialized by the proxy into one or more value objects. The benefit here is clear; a developer is able to use complex service-specific types native to their development environment to interact with a service.

The key difference between the use of REST and SOAP lies in the WSDL. The WSDL provides a central, language agnostic means for defining how to interact with a SOAP service. Different development environments can use the WSDL to construct the same set of types on-the-fly using a SOAP toolkit. REST does not define a compliment to the WSDL. As a result, documentation must be used to determine request and response content. Technically, you can manually construct a proxy and set of types to interact with a REST service, but without a central definition or standard (provided by a WSDL) the API structure will likely differ between developers.

So where does it make sense to leverage REST services in the Web ADF? REST services should be utilized in the browser, thus integrated with the Web ADF using the ADF JavaScript library. In this capacity, REST services may be used to enhance Web ADF application behavior and performance. One such area involves simply adding non-cached map services using pure client logic, something the Web ADF does not provide out-of-the-box. Currently non-cached map services use the AdfMapHandler class in ADF JavaScript to generate dynamic map images. This class requires Web-tier components; namely a map resource associated with a MapResourceManager and Map server control. It uses the ADF MapHandler to generate dynamic maps. The same applies for the Toc; it still relies heavily on Web-tier manipulation. You can, however, extend the ADF JavaScript DynamicLayer class to work with a non-cached service via REST.

The sample is available here.

There are a few caveats:

1) The layer (i.e. resource) is only available on the client; server components do not know about it. As a result, any requests to the server that work with map resources will not include this layer. In addition, most ADF controls require modification on the server to change their rendered content. This includes the Toc, so if you want the pure client layer to show up in an ADF Toc, you’ll need to customize Toc content using code on the server.

2) Using services secured with token-based authentication requires a proxy. Here’s a link to step on how to set this up: Using a proxy is a popular solution for working around cross-site scripting restrictions in a browser. Abe Fettig has researched a number of these solutions and presented them in a blog post. Note, you can use a proxy even if authentication is not required.

In the sample I provided, if a proxy (via the proxyUrl property) is defined when creating a new DynamicRestLayer, the proxy will be used. In this case, a POST request is always generated to guarantee that all the input arguments are passed to the remote site. The response is JSON and contains the properties of the generated map image, including the url and extent. If no proxy is specified for the DynamicRestLayer, a simple GET request for a map image is made via a dynamic image tag. The image tag source is not subject to cross-site scripting restrictions in the browser, so we don’t need a proxy. Both IE7 and FireFox 2+ work great with the no proxy solution. Unfortunately IE6 is somewhat problematic (e.g. triggers erroneous requests). If you need to support IE6, you may want to go the proxy route.

This brings up an interesting point – the ADF JavaScript Map component is designed to render and blend maps using dynamic image tags. The image tag source is not subject to cross-site scripting restrictions. Since a REST map service can return the raw map image, the sample included with this post merely builds on REST capabilities and ADF JavaScript architecture. Another option involves using dynamic script tags whose source references a REST endpoint that generates JSON. The data returned from the REST service is evaluated as a JavaScript object when the tag is loaded or inserted in the page. This could also work with ADF JavaScript, but would require more implementation code. Interestingly, dynamic script tags are leveraged by the ArcGIS JavaScript API.

Note, the sample also shows how to use REST to access tiles in a cached map service with a pure client layer. It may be of interest since the url is standard across sites (e.g. you don’t need to know the virtual cache directory).


Chart Renderering using Web ADF

April 8, 2008


These are days am working with ArcGIS Server [9.2+SP3]- Java edition. I’ve started with ESRI samples and grown up to creating tasks for my application. Task framework is handy to create our own custom business logic with rich UI. I’m trying to recreate or mimic ‘Charts’ functionality similar to Arc Map.  User can select a layer (yet to code), field(s) and chart type to draw charts.   User has option to prevent overlap, change map base symbol color, field(s) color also. It works fine. No harm, charts draws fine. 


While I try to remove the rendering, I couldn’t do so. Later, When I investigated, chart rendering has been applied to the map service (i.e. on server objects) since it is pooled one. I have searched in forum/developers help, I learnt that package has ONLY five classes WebClassBreakInfo, WebClassBreaksRenderer, WebSimpleRenderer, WebUniqueValueInfo, and WebUniqueValueRenderer.  The Chart Rendering option is NOT available with the web ADF.  My senior colleague who attended Dev Summit has explained me that only ArcIMS has this functionality through ArcXML using Chart Symbol Object and not in 9.2. ESRI will incorporate in 9.3 ;adding charts in graphics layer or from other source. This helps me that am working in right direction.


As a developer, you should not expect that everything can only done thru available methods/properties, sometimes we may need to use reverse logic to obtain desired result. One of my fellow colleague suggested that before applying chart rendering to layer object, feature renderer of the layer is stored temporarily once chart renderer is applied , web context is refreshed. Then now apply the feature renderer stored in temporary object to server object so that user can see the charts whereas a server object doesn’t get changed. This is simple and better idea for time being. 


There are several other interesting learning’s/findings in creating this task. I’ve used custom xsl from Daniel Garcia Roman Class break rendering. 


I’m facing some problems like how to update overview map dynamically when rendering type is changed, while changing radio events are not firing properly (I’ve to click twice). Yet to implement normalization, exclusions, orientation, size etc. For a developer who is fairly having good understanding of ArcObjects doing task is not so tough. Here, we are working with ArcObjects remotely. I always use VBA help to understand methods/properties of classes. Then try to migrate to java. Proper casting, creating objects in server context, error handling, using appropriate packages are very vital in server app development. I strongly feel that lack of samples in Developer help for Java as in .NET is a big handicap. We have depend on forums/experts  to understand certain basic issues.



Building JAVA Applications Using the ArcGIS Server Web ADF and AJAX (Dev Summit ’08)

February 28, 2008

Listen podcast from Jayant Sai, Developer, and Antony Jayaprakash, Product Engineer, ESRI on ArcGIS Server Web ADF intro

Listen here