Posts Tagged ‘REST’

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: http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/arcgis/help/jshelp_start.htm#jshelp/ags_proxy.htm. 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).

ArcGIS Server 9.3 titbits

June 20, 2008

Tit bits for ArcGIS Server 9.3 RC

  1. ArcGIS 9.3 with Ajax Control Toolkit Version issue:

Issue: ESRI 9.3 RC has a reference to the AjaxControlToolkit.dll version 1.0.10920.32880 installed with the .NET SDK. Our project is using AjaxControlToolkit.dll version 3.0.20229.20843. When any ESRI map control is added to the project, we get the error: “Microsoft JScript runtime error: Sys.InvalidOperationException: Type AjaxControlToolkit.BoxSide has already been registered. The type may be defined multiple times or the script file that defines it may have already been loaded. A possible cause is a change of settings during a partial update”. We are able to remove the reference to AjaxControlToolkit.dll version 3 and run off of ESRI’s version 1, but then we are dependent on an older version of the library. 

Solution: The Web.config has an assemblyBinding section where you can do some assembly redirection. If you are using the latest version of the toolkit the following dependentAssembly element will work, otherwise you will need to change the version number to match the ajax control toolkit version you are using. 

       <dependentAssembly>
         <assemblyIdentity name=”AjaxControlToolkit” publicKeyToken=”28f01b0e84b6d53e”/>
         <bindingRedirect oldVersion=”1.0.10920.32880″ newVersion=”3.0.20229.20843″/>
      </dependentAssembly>

 Some links from ESRI Forum for chewing

  1. Sequence of Events in life cycle – comparison between 9.2 and 9.3
  2. ArcGIS Server Manager Enhancements going to be come up at final version
  3. Dojo Support for ArcGIS Server JavaScript API discussion
  4. Cannot login to ArcGIS/Rest/admin : ESRI sucks on login. Still many failed at this step. Refer 9.2 forum threads nearly 30+ (may be more) unable to login. ESRI please provide neat answer. Several victims on 9.2 Java ADF.

 

Technology Migration ArcGIS Server 9.2 to 9.3

June 19, 2008

This post higlights some points on technology migration from ArcGIS Server 9.2 to 9.3. Some one might ask, “Hello ..dude..why do you want this so early ?”.  ArcGIS 9.3 is expected to release by this July. So this would be ideal period to discuss on this. This will be helpful for those who wants to develop new application in 9.3 or redevelop/migrate the existing 9.2 application or atleast curious to know about new features in 9.3.

Yet 9.2 Web ADF have not been explored fully, atleast by myself. Now 9.3 is almost ready. I guess 9.2 released in November 2006. With in 2 years ESRI came up with brand new 9.3.  Web ADF in 9.2 has been under lot of critiscm from several folks though used widely. The ADF learning path is bit hard, thats the naked truth thats the reason everyone hate using 9.2 atleast in .NET. On Other hand Java ADF in 9.2 seems good but lacks documentation. I have not heared much annoyance/comments with respect to java.  Server is not so easy as conventional IMS.  ArcGIS Server provides extensive functionalities than IMS product. It all depends on your requirement and bussiness needs.  Lets get into topic without further noise.

In General, 9.3 ADF built on the same framework in 9.2 with a number of technology and performance enhancements have been incorporated in 9.3 to provide comprehensive platform. The core object model has undergone minor (believe so) changes.  ADF (.NET) is hybrid platform- mix of server side and client side development enviroment. Basic web controls like Map, TOC and Overview has been re-engineered and scriptable now.

Your migration options depend on whether you built a Web ADF application using the Web Mapping Application template (includes applications generated by Manager) or you build a custom Web ADF application without the template.  Below matrix explains the possiblities to upgrade.

9.2 to 9.2 Migration

 Key points for developers:

  • Using ASP.NET partial postback pattern instead of client callback. If you might written lot of code for TOC, rendering by now controls will take care of all your needs. Even if required, it will be on client side
  • Customised Web ADF Javascript libraries. Night mare on Javascript is gone. Developer can get full details of script along with neat documentation.
  • Custom tasks uses partial post back
  • Shallow stateful pattern is no longer supported in 9.3.  Developers should be aware of this. Because adding/removing layers done thru pooled server objects using shallow stateful concepts. Here 9.3 HTTP hanlder (ESRI.ArcGIS.ADF.Web.UI.WebControls.MapHandler) responsible for Map draw operations.
  • Understanding of REST or Javascript API is must.

Sailent features in 9.3 :

  1. Ready made utilities for migrating from 9.2
  2. ArcGIS JavaScript Extension for the Google Maps API
  3. ArcGIS JavaScript Extension for Virtual Earth
  4. Javascript is made public, documented, JSON based, and object oriented. Makes life easy for developer.  9.3 ADF will use JSON instead of XML for it’s communications between the client and server – this alone speeds things up ~30%
  5. Integration with other Javascript frameworks – like Dojo or ExtJS. This allows much more control over how the application looks and behaves.
  6. Improved Map Control, TOC and Overview control. Number of callbacks is reduced.
  7. The resource manager can be managed in Javascript, and has lots of configuration – i.e. layer aliases, fields to show, map tips etc.
  8. Results Viewer: bi-directional highlight. The task can have different results behavior (fields, map tips etc). Kudos!
  9. Additional web controls, additional AjaxExtenders – DockExtender, HoverExpandExtender (pin window type of thing)
  10. Use of HTTP Handlers used instead of pages so the page lifecycle is avoided, so it’s faster
  11. Blending at 9.2 used a single tiling scheme. At 9.3 each resource has it’s own tiling scheme, and the “blending has been massively improved”
  12. Javascript intellisense for Visual Studio 2008.
  13. Better templates and utility to convert previous version templates.
  14. Eliminated lots of callbacks, http handlers improve performance because the control tree is not re-created and destroyed
  15. Visual studio 2008 and .NET 3.5 framework supported
  16. Out-of-box printing tool and export using Adobe Acrobat Reader (PDF)
  17. ArcGIS Image Server is now an optional extension to ArcGIS Server
  18. Integration with Arc Web services
  19. ArcSDE is fully integrated with ArcGIS Server. SDE license bundled with Server.
  20. Windows Vista Support
  21. PostgreSQL support
  22. OGC specifications
  23. Much more…..

Hear the  Latest Podcasts on ArcGIS Server 9.3 from ESRI. CLICK HERE 

To summarise ArcGIS Server 9.3 seems improved much quality and performance wise.

  • Those who are new to Server and about to start development in 9.3 then donot look back web ADF at all.
  • If you are graduating from 9.2 and coming out of Web ADF then 9.3 REST/javascript API will be solace.
  • Are you about to migrate to 9.3 then look at both pros and cons. Don’t jump.

I thank fellow bloggers Dave, James Fee, Tom and others who helped me with valuable inputs. I dare to write this post because am NOT in beta evaluation. Hence people like me who look for similar information, this post may help. If there were any mistakes/omissions/additions or want of further details, please do comment or email me.

REST: Simple Explanation

March 19, 2008

We ESRI folks hearing word ‘REST’ often when we discuss about ArcGIS Server. What is REST, how it works, what it does?. Here is a link, which gives great explanation about REST archiecture.  “How I Explained REST to My Wife” by  Ryan Tomayko. This is a wonderful post on REST.  Hope this helps you lot!