1. Install ArcGIS Server Web ADF in your development machine.
2. Assuming  Visual Studio 2005 Installed along with Ajax Extension (ASPAJAXExtSetup). This AjaxExtension contains controls like 'Timer', 'Update Panel' , 'Pointer', 'Script Manager', 'Script Manager Proxy' , ' Update Progress'
3. Right Click Project in Solution Explorer and Set 'Add ArcGIS Identity..' if GIS Server is different from development machine.
4. Drag and drop --> Map Resource Manager , Map, TOC controls into Default.aspx Page
5. Set Properties to  MapResourceManager. i.e Add GIS Server, Data etc. You should be added as AGSUSer in GIS Server by the adminstrator.
6. Right Click Map and Set MapResourceManager to 'MapResourceManager1'
7. Right Click TOC control and set Buddy Control to 'Map1'
8. In Web Config Set Debug Option to True
9. Build the site and run the application. You can see Map Service and TOC in the web Browser.

You have successfully developed first sample on your own.

My experiences thus far with the beta and the release candidate have been pretty positive so it'll be good to get the final product.

Who's starting the pool on the when the first service pack will be out? ;)

The ArcGIS 9.3 beta closes on June 30^th, 2008. Here afterwards, ESRI Support Services will provide support for the final release.

We congratulate ESRI efforts on the making this product.

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.

They are available at:
http://resources.esri.com/arcgisserver/index.cfm?fa=JSAPIs

The new resource centers have all of the downloads for the JavaScript API's, Samples, SDK, and documentation.

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.

 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.

'__pendingCallbacks[...].async' is null or not an object

Here is a solution for resolving this issue (click on title) : problem-microsoft-jscript-runtime-error

1. 5th Database supported by enterprise geodatabase (Oracle, SQL, DB2, Informix  where others)
2. No backward compatablity to 9.2
3. Full ArcSDE implementation as equivalent to other DB's
4. Only Enterprise GDB not personal or workgroup ArcSDE
5. Postgre version supported 8.2.4
6. Default vector storage: ST_GEOMETRY
7. PostGIS not distributed with ArcSDE

Here is from Wiki on Dojo Tool kit for first sip

"The Dojo Toolkit is a modular open source JavaScript toolkit (or library), designed to ease the rapid development of JavaScript- or Ajax-based applications and web sites. It was started by Alex Russell in 2004 and is dual-licensed under the BSD License and the Academic Free License. The Dojo Foundation is a non-profit organization designed to promote the adoption of the toolkit"

Its right time to learn Dojo Tool kit for working ArcGIS Server 9.3.  Get ready folks.

...A friend once told me, "PDF is where data goes to die." If that holds true, then geoPDF is where maps go to die...

Word on the street is that ArcGIS 9.3 will natively export to this new Acrobat format. Schweet.

The other neat thing that I'd like to point out is the Flash embed capability for Acrobat. Could the ArcGIS Server 9.3 Flex API be embedded in the PDF for dynamic mapping?

Just forget about workflow for a moment. Is it possible?

Ok, now think of the workflow. Could it have the potential to be another SharePoint-like pain in the butt?

Adobe = Upgrade (with the potential to Fail!)
ESRI = Upgrade!
TerraGo = Fail!

When I heard about the javascript and REST APIs coming in 9.3, I was very excited. I proclaimed the end of all pain in the GIS nerd world, just knowing that these new offerings would not only make my applications better, but they would make me a better person. They would help me easily query my GIS data and teach my kids right from wrong.

My expectations may have been a bit too high.

Here are some things that I didn't know about the VE Adapter. They may be obvious to some, but I was mildly surprised to hear them:

• You HAVE to use a tile cache to use the VE adapter. Yes, I know it isn't that surprising, but I had some hope that we could display live services. Yes, I know it would be slow, but sometimes hope blinds a man...
• You HAVE to use the WGS84 Web Mercator GCS, which is not a requirement of Dave B's tile server (score one for Dave, open source, and little people everywhere)
• The ArcGIS Server REST API supports JSONP out-of-the-box. All you have to do is add a 'callback' parameter to your querystring and it'll return the JSON all nicely wrapped in the javascript function you specify. That is very, very nice.

You can use the 'cache-on-demand' feature, which is a godsend to those of us who have watched cache generation processes leak into 3 weeks.

So, real quick like, I'll crank out some code that shows you to query the REST API to get all the available map services, add them to your page. Then, just because I am freaking crazy, we'll add the ability to toggle the tile layers on/off on your VE map.

Setup

First, get ArcGIS Server 9.3. Then, publish a couple of map services per the requirements of using the VE adapter. I mention most of it above, but here it is from the horse's mouth. Oh, and it'll help if the map services have data from the same area.

Make a VE Map

Create an HTML file (doesn't even have to be served by a web server, since we're all in javascript) and put in the base structure for a map. Something like:

[sourcecode language='html']

[/sourcecode]

So, a couple of quick comments about this "base" VE map. I have added the script tags to pull in the ESRI VE adapter, as well as Dojo. I am gonna use Dojo for this example because it makes querying a cross-domain REST service easy as 1,2,3. It is likely that your AGS installation will not be on the same server or in the same domain as your web server, so it is nice that AGS 9.3 has JSONP baked right in. Also, in the above code, I create a ESRI layer factory, which is an object that creates tile specifications for Virtual Earth. Finally, I add an unordered list (ul) that will eventually hold my services.

Ideally, we'd like to boogie out and get the list of services that are currently being published by AGS when the page loads. So, lets add a getServices() method and call it from our OnPageLoad...shall we?

[sourcecode language='jscript']

var AGS_SERVER="http://yourserver/arcgis/rest/services";

function getServices(){
dojo.io.script.get({
url:AGS_SERVER,
content:{
f:'json'
},
load:function(resp){
services=resp.services; // Automatically deserialized by dojo. Thanks!
var ulServ=dojo.byId('services');
dojo.forEach(services,function(s){

if (s.type=="MapServer"){
var li = document.createElement("ul");
li.innerHTML=s.name;
ulServ.appendChild(li);
dojo.connect(li,"onclick",dojo.hitch(li,serviceClick));
}
}
);

},
callbackParamName:'callback'

});

}

[/sourcecode]

Here is where using Dojo (or any javascript framework that will handle JSONP requests easily) really pays off. The getServices method is simply issuing an AJAX request to our AGS REST Service Catalog. The response is automatically deserialized into JSON and fed to our 'load' function. The load function then loops over each service (the response has folders in it too, but we are ignoring those today) and adds a list item to our services list for each MapServer. A click handler is added to each list item to call our serviceClick function (we haven't added that yet). Side note: Using dojo.hitch here forces the serviceClick method to be called in the context of the list item that is clicked. In other words, when serviceClick is called, the 'this' keyword will refer to the list item. A whole lotta stuff happening on one line of code, which is one place where I think Dojo shines.

So, let's quickly add the serviceClick (and some other) function:

[sourcecode language='jscript']

function serviceClick(){
var lyr= map.GetTileLayerByID(this.innerHTML);
if (lyr==null)
{
addLayer(this.innerHTML);
}
else
{
toggleLayer(this.innerHTML);
}

}
function addLayer(lyrName){

layerFactory.CreateLayer(AGS_SERVER+"/"+lyrName+"/MapServer", lyrName,GetMap);

}
function toggleLayer(lyrName){

var lyr=map.GetTileLayerByID(lyrName);
if (lyr.IsVisible)
map.HideTileLayer(lyrName);
else
map.ShowTileLayer(lyrName);

}
function GetMap(tileSourceSpec, resourceInfo) {

map.AddTileLayer(tileSourceSpec,true);

}

[/sourcecode]

So, the serviceClick function gets the innerHTML from the list item clicked, which in this case is the name of the AGS service. It then checks our Virtual Earth map to see if that layer has been added. If the layer has not been added, we use the layer factory created on page load to create a tile specification for that service. The layer factory actually issues an AJAX request, which is why we have to specify a callback method (GetMap). GetMap adds the created tile spec to the map, and our layer is visible. Clicking on the service name in the list again will toggle that layer off. So, with very little code, we've created a pretty functional map with a nice VE interface and a poor man's table-of-contents. Not bad for a few minutes work.

As usual, this post has gone on longer than I'd hoped.  If you want the not-split-up-by-the-blog-post HTML file, just drop me a comment.  Also, drop a comment if you have a question or think I am wrong/high/crazy.

Did you ever install ArcGIS Server Java first and then go ahead and change the host name of the machine only to realize now the you will have to either re-install or run post install or contact support to fix ArcGIS Server.

Did you ever have an disk image with ArcGIS Server Java installed and configured, then you go ahead and ghost the image on many machines only to realize that all the hostnames are the same.

Don't worry, In this post you will find information on what files has got the entries of the host name and for what purpose. This will also give you a good understanding of how ArcGIS Server Manager and Web Services Handler uses these configuration files.

Note: These files are for version 9.2, I will update the post shortly after the 9.3 is released.

The five files of concern are:

C:\Program Files\ArcGIS\server\system\Server.dat
C:\Program Files\ArcGIS\java\manager\service\tomcat\managerserver\webapps\arcgismanager\WEB-INF\classes\manager_client.properties
C:\Program Files\ArcGIS\java\web_output\services\WEB-INF\classes\arcgis_wshandler.properties
C:\Program Files\ArcGIS\java\manager\service\lib\manager_config.properties
C:\Program Files\ArcGIS\java\manager\config\applications\build\build.properties

1.  <ArcGIS Install Dir>\server\system\Server.dat

This files stores the actual name of the machine where the SOM is running. Also here the URL's to the virtual directories such as the arcgisjobs, arcgisoutput and arcgiscache is set. If your ArcGIS Services are not previewing correctly in ArcCatalog or if the web service end point url's are shown incorrectly than you should check this file. You can edit this file in any text editor, but once you make any changes to this file be sure to restart the ArcGIS Server processes (both ArcGIS Server Manager and  ArcGIS Server Object Manager).

2. <ArcGIS Install Dir>\java\manager\service\tomcat\managerserver\webapps\arcgismanager\WEB-INF\classes\manager_client.properties

I am not sure on the importance/functionality of this file, but this file has one hostname attribute to startup the manager web application with the correct host name.

3. <ArcGIS Install Dir>\java\web_output\services\WEB-INF\classes\arcgis_wshandler.properties

This is a pretty important configuration file. This file has all the details needed including the hostname of where the SOM is installed for the Web Services handler to initialize. So if you are unable to log into manager and also get an HTTP 503 error when you access the services wsdl (http://machinename:8399/arcgis/services?wsdl) then you need to make sure this file has the right entries. There is nice knowledge base article on this issue and here is the link.

4. <ArcGIS Install Dir>\java\manager\service\lib\manager_config.properties

This file defines a host name parameter to indicate to the manager tomcat instance as to where to start the new tomcat instance to host all the webapps (port 8399)

5. <ArcGIS Install Dir>\java\manager\config\applications\build\build.properties

This file both a URL and SERVER properties which has a hostname entry primarily used by the manager web application to deploy the web application.

Few tips to make your life easier:

• If you are creating an image to ghost then instead of using the machinename try using localhost both during the install and post-install of ArcGIS Server. This way the image is portable and no changes are needed
• If you are using Windows XP then make sure you have turned the built in firewall off (this prevents the DCOM from making the necessary connections) and also make sure the Simple File Sharing is turned off. This is enabled by default and you will have to manually turn this off, its best done i nthe image so that you will not have to do this for every ghosted machine. (How: My Computer -> Tools -> Folder Options -> View -> Advanced Settings -> All the way to the bottom)

Here is the listing of YSlow 13 performance rules along with the ratings given to the default web mapping application template.

1. Make Fewer HTTP requests (F)
2. Use a CDN (F)
3. Add an Expires header (F)
4. Gzip components (F)
5. Put CSS at the top (B)
6. Move scripts to the bottom (C)
7. Avoid CSS expressions (A)
8. Make JS and CSS external (-)
9. Reduce DNS lookups (A)
10. Minify JS (A)
11. Avoid redirects (A)
12. Remove duplicate scripts (A)
13. Configure ETags (A)

Now lets analyze a few rules and its ratings to see where we as web developers or front end engineers can contribute to improve the performance of the web mapping application.

1. Make Fewer HTTP requests (F)

The tools measures this with respect to how many http requests the application makes while loading in the browser. From a web mapping application perspective this cannot be controlled easily since the web mapping application downloads around 16 Javascript files and 2 css files which the YSlow does not like. Its hard to modify this since the Javascript files are injected to the html at initialization by the XSL files and you will have to modify a lot of XSL to reduce this. Not recommended.

2. Use a CDN (F)

CDN stands for Content Delivery/Distribution Network. Its not practical/economical for small scale web applications with less than 10,000 hits a day to be served from CDN.

3. Add an Expires header (F)

Here is where it gets interesting. This rule is suggesting that any web resource transported to the browser  for example images, javascript, css, html files can be and shoud be cached by the browser.

Oh well, what can we as Front End Engineers or Web Developers do to improve the grade and get a better performance and user experience. In the web application we can add custom headers such as "Expires" and "Cache-Control" to these resources so that the browser will download it once and until the user clears the browser cache the files are reused. A big performance gain and potentially saves lots of bandwidth.

Here is a snippet from web.xml where I have declared a filter to do the job.

<filter>
<filter-name>ResponseHeaderFilter</filter-name>
<filter-class>
com.esri.sample.ResponseHeaderFilter
</filter-class>
<init-param>
<param-name>Cache-Control</param-name>
<param-value>max-age=3600</param-value>
</init-param>
<init-param>
<param-name>Expires</param-name>
<param-value>Thu, 14 Aug 2008 12:00:00 GMT</param-value>
</init-param>
</filter>

Here is the actual implementation - "ReponseHeaderFilter.java"
[code='java']
package sample;

import java.io.IOException;
import java.util.Enumeration;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

public class ResponseHeaderFilter implements Filter {
FilterConfig fc;

public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain)
throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;

// set the provided HTTP response parameters
for (Enumeration e=fc.getInitParameterNames();e.hasMoreElements()) {
String headerName = (String)e.nextElement();
response.addHeader(headerName, fc.getInitParameter(headerName));
}

// pass the request/response on
chain.doFilter(req, response);
}

public void init(FilterConfig filterConfig) {
this.fc = filterConfig;
}

public void destroy() {
this.fc = null;
}
}
[/code]

Here is the filter mapping in web.xml to identify the type of resources to add the headers

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>*.js</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>*.css</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>*.gif</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>*.png</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>*.jpg</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/tile/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/mimedata/*</url-pattern>
</filter-mapping>

4. Gzip components (F)

The time to send response from your application/web server across the network back to the browser can be significantly reduced by compressing certain types of responses. If you want to learn more on this for all the goodness and benefits of Compression, click here. You will have to rely on the web server to provide this functionality for you and here is an example of modifying tomcat's configuration file to compress different types of responses based on their mime-type.

Note: In this case we are configuring the server.xml file of Tomcat (6.0.14 version) to compress using the GZip compression type for the following mime-types: text/html,text/xml,text/javascript,text/image,text/css

We are not compressing any image formats here since compression on image or pdf formats is not recommended since it is already in a compressed format.

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"
compression="on"
compressionMinSize="512"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/javascript,text/image,text/css"/>


The server.xml can be found under the "{tomcat installationfolder}/conf" folder and by default will not have the compression turned on. Open the server.xml file in any text editor and find the and add the compression attributes as shown above. In my example, I have asked Tomcat to compress any html, text, xml, javascript or css files which is over 512 bytes.

This change will significantly boost the performance of your application both at start up follwed by every AJAX call made to the server since the Java ADF uses XML to send responses back to the calling web application. Also this change changes the YSlow grade of F to A for this category.

6. Move scripts to the bottom (C)

This is pretty simple change. YSlow checks to see if there are any external Javascripts files in the page and if yes then is it at the end of the body rather than at the head. The web mapping application has a few script tags in the mapviewer.jsp at the head. You can move them all the way to the end of the page before the html tag ends. This will imporive the loading of the page and also please the YSlow rating.

10. Minify JS (A)

Wanted to make a small comment here. In version 0.9.x YSlow gives grade A for this rule when the Javascript libraries of the Web Mapping application is not minified. This might be a bug with the YSlow plugin, anyways we should aim to minify the JS libraries as it will imporove the transport speed of the files and remember there are atleast 16 Javascript files transported in the web mapping application, so we should revisit this topic seperately. Its worth a post of its own.

So here it is folks, after making all these changes here is final screenshot of the new Yslow rating :

We can see a significant improvement in rating (from F to B), performance and responsiveness of the application by just following a few simple rules. If you try this out, please share the performance metrics so that others can comment on it.

You may (or may not) know that I am one of the authors of the ArcDeveloper REST API, which is an open source REST API for ArcGIS Server that can be used against ArcGIS Server (AGS) 9.2, right now, free to all comers, no waiting, etc.  If you know that, you probably know that ESRI is releasing it's own REST API for AGS at 9.3, due out later this year.  So, I thought I'd take a few posts to show you how the REST API (in beta) is looking.  For the impatient, it looks great.  For others that may not have the beta, read on.

So, first off, we are just gonna check out the very basics of the REST API.  When you install 9.3, there is no real indication of anything all that different.  The AGS Service Properties dialogs look (basically) the same, except for some (hugely exciting, but beyond the scope of this article) changes to the Caching tab.  The real excitement comes when you start messing around with URLs against your map server.  BTW, I am using Fiddler2 with the JSON Viewer plug-in to send requests to the server and look at the results.

AGS 9.0 and later have always exposed a SOAP endpoint for each service it publishes as well as service catalog.  There is a whole SOAP API, which is my preferred method to interact with AGS services, and the URL to the SOAP service catalog looks like:

http://server/arcgis/services

Following this pattern, the REST API brings along a similar service catalog endpoint:

http://server/arcgis/rest/services

The new-kid-on-the-block REST URL is even cooler, though, as it formats the results into a cool "ArcGIS Service Explorer" that looks like:

Which allows you to look at metadata about your services, view them in Google Earth (how cool is that?), ArcMap, ArcGIS Explorer, or the new ArcGIS Javascript API (a subject of posts to come).  Also, you can drill-down into your service and get layer info, spatial reference, unit info, and tiling information.  In fact, on the tiling information, you can actually LOOK at some of the tiles.  Other information includes supported operations that you can execute within the Explorer, like Export Map or Identify.  Here's a picture of the service page:

Another item the Service page has is a "Supported Interfaces" section, which I would call supported formats.   The ones listed out of the box are REST and SOAP.  Clicking on the REST link will give you all (well, most of) the information just mentioned, but in JSON format .   Here, lemme show you:

The only difference between the URL to get to the cool HTML Services Explorer page and the URL that spits out JSON is the addition of a 'f' (for 'format') querystring parameter, like so:

http://server/arcgis/rest/services/ServiceName/MapServer?f=json

MMMMM....now, THAT's some good REST.

There is similar love for supported operations, allowing you to crank out a quick image or perform a Find and look at the results.   Also, the (impressively comprehensive) API reference is linked on the Services Explorer pages, which, oh by-the-way, takes you here.

Finally, the last thing I want to cover in this post is the REST admin inteface.  If you go to the following URL in your browser:

http://server/arcgis/rest/admin

you'll be hit with a login screen for the ArcGIS REST API Admin application.  It's pretty sparse right now, not even meriting a screen shot.  Currently, you can use the admin site to tell AGS when to recycle the cached service responses and to turn on the REST Services Catalog.  Now, that second option was nowhere to be found in my admin app, but the docs assure me it's there.

So far, the only disappointment I have had is that ESRI has chosen not to use GeoJSON as their format to return features in (or, for that matter, even as an option).  I don't profess to know why, but I'll try to float that to one of my contacts on the mother ship soon.

Summing up, the AGS REST API looks great before you even show a map on a site.  I am hoping to go that in future posts.

I am trying connect to external database (simple standalone DBF) to one of layer dynamically using ADF. I wrote a method to connect to database and return the fields. I can able to join with database but retrieving fields seems bit tough!. The RelQueryTable class has method  getFields() which returns  IFields objects . How to convert to IFields to Fields object in com.esri.arcgisws which has getFieldArray() to obtain fields list.

Can anyone ping me or give me any clues? 

private Fields JoinTable(IServerContext pSC, IFeatureClass pFeatclass){

try{                

ShapefileWorkspaceFactory filefactory = (ShapefileWorkspaceFactory)pSC.createObject(ShapefileWorkspaceFactory.getClsid());

Workspace ws = (Workspace) filefactory.openFromFile("C:/test/", 0);

IRelationshipClass pRelationshipClass ;              

ITable table = ws.openTable("1Z.dbf");

factory = (MemoryRelationshipClassFactory)pSC.createObject(MemoryRelationshipClassFactory.getClsid());

MemoryRelationshipClass rclass = (MemoryRelationshipClass)factory.open("test", pFeatclass, "ZONENO", new ObjectClass(table),"ZONENO", "forward", "backward", esriRelCardinality.esriRelCardinalityOneToOne);                     

RelQueryTableFactory relQueryTableFact = (RelQueryTableFactory)pSC.createObject(RelQueryTableFactory.getClsid());

RelQueryTable relQueryTab = (RelQueryTable) relQueryTableFact.open (rclass, true, null, null, "", true, true);

System.out.println("After Joining total Field count::::::"+ relQueryTab.getFields().getFieldCount())                        

return  relQueryTab.getFields();        

 }

catch(Exception ex){

System.out.println("ERROR in JOINTable Method"+ ex.toString());

return null;

}

} 

Install ArcGIS RAD plug-in

Developing ArcGIS portlet Applications in RAD

Will ESRI upload these plug-in s as zip file who don't have internet connection. ESRI please awake!

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 com.esri.adf.web.data.renderer 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.

Answer (from ESRI Support )

Build 535 = ArcGIS Desktop 9.0 final
Build 550 = ArcGIS Desktop 9.0 Service Pack 1
Build 560 = ArcGIS Desktop 9.0 Service Pack 2
Build 580 = ArcGIS Desktop 9.0 Service Pack 3
Build 589 = ArcGIS Desktop 9.0 Service Pack 3 + ArcGIS Desktop 9.0 Map Document Performance Patch

Build 722 = ArcGIS Desktop 9.1 final
Build 750 = ArcGIS Desktop 9.1 Service Pack 1
Build 780 = ArcGIS Desktop 9.1 Service Pack 2

 ArcGIS Desktop 9.1 Service Pack 2 displays as build 766 from ArcMap Help > About ArcMap.

Build 1324 = ArcGIS Desktop 9.2 final
Build 1332 = ArcGIS Desktop 9.2 Service Pack 1

 ArcGIS Desktop 9.2 Service Pack 1 displays as build 1324 from ArcMap and ArcCatalog Help > About ArcMap/ArcCatalog.

Build 1350 = ArcGIS 9.2 Service Pack 2

 ArcGIS Desktop 9.2 Service Pack 2 displays as build 1324 from ArcCatalog Help > About ArcCatalog.

Build 1380 = ArcGIS Desktop 9.2 Service Pack 3
Build 1420 = ArcGIS Desktop 9.2 Service Pack 4
Build 1450 = ArcGIS Desktop 9.2 Service Pack 5

 ArcGIS Desktop 9.2 Service Pack 5 still displays as build 1420 from ArcCatalog Help > About ArcCatalog.

Finally ESRI has made Eclipse plug-in for debugging ArcObjects Code. This is great news for java devlopers who uses print line statements.  One of the most important aspect of any tool is debugging.I strongly feel that Mircosoft products brings great developer productivity.  This is also one of  reasons why many huge fans for MS products than java.  Its better late than never, ESRI shown some concern to java developers!. Kudos ESRI :)

About the plug-in

One of the most valuable tools that developers have at their disposal is a debugger through which they can step through code one statement at a time and inspect objects in the application. As many of you may already know, Java classes in the ArcObjects API are really only proxies to underlying COM ArcObjects. As a result, examining these proxies in the debugger only reveals their internal details and not the state of the ArcObjects. This makes it difficult to find out information such as the coordinates of a geometry, or the layers in a map service. Consequently, developers have to sprinkle their code with System.out.printlns and analyze traces on the console to get this information. This approach can be inconvenient and time consuming.

With this new Eclipse plug-in, Java developers can examine the state of the underlying ArcObjects right in Eclipse IDE's Debug Perspective by enabling the "Show Logical Structure" option on the Expression and Variables window. Here's an example of a Point object without the "Show Logical Structure" option enabled.

This information provides little insight into the underlying ArcObject and is not helpful in reasoning through a workflow while debugging. Now here's the logical representation of the same object with the "Show Logical Structure" option enabled.

The logical representation presents more comprehensible information about the underlying ArcObject's state. This state is defined by the no-argument getter methods on it. You might sometimes see exception messages like "Exception Occurred: com.sun.jdi.InvocationException occurred invoking method" in the logical representation. This is normal and happens when some property of the ArcObject is not valid in the current context of the application.

The underlying ArcObjects could be running remotely in a separate process as in the case of ArcGIS Server web applications, or in the same process like in ArcGIS Engine applications. Thus, both Engine and Server developers can take advantage of this plug-in to debug their applications.

How to get the plug-in

Follow these steps to download and install the plug-in from the EDN Website:

1. In the Eclipse workbench, go to Help > Software Updates > Find and Install
2. Select Search for new features to install, and click Next
3. Create a New Remote Site for the URL "http://downloads.esri.com/EDN/java/plugins/eclipse"
4. Enable this remote site and click Finish.
5. Expand the EDN tree in Search Results, and select the ArcGIS Debug feature.
6. Proceed to install the plug-in, and restart the workbench when prompted.

I didn't attend anything on the Java ADF or the Flex API. Neither of those are things I'll be using anytime soon so I didn't check them out but Fantom Planet did attend the Flex API session and seemed duly impressed. So, if you want details on that, you should probably nag him. ;)

I sat in on a session about the .Net Web ADF. I've already read Dave's post on the same session and his notes read almost exactly like the ones I have in my notebook so, rather than retype my notes (which would essentially duplicate Dave's post), I'll refer you there. BTW, congrats Dave!

The .Net Web ADF definitely seems to have a lot of improvements. The things I'm most excited about are a) all of the web controls being scriptable, b) the client-side JavaScript now being exposed, documented and supported, c) the re-engineering to use ASP.NET AJAX and d) resource-level tiling. ESRI put a lot of focus on reducing the number of server round-trips and reducing the need to execute the full page life-cycle. This will speed things up a lot. All of the items I just listed will have direct, immediate benefits on our Server projects. Oh yeah, using JSON to serialize their objects is cool as well. Additionally, the ADF is designed to use .Net 3.5 but you can toggle back to 2.0 if you need to. I see SilverLight in my future.

I've already talked a little about the REST API. I think that one is going to be huge. It really expands the scope of potential clients for ArcGIS Server services to just about anything. As I said, they even hit services from Ruby and Python during the session. "Everything is a URL" was the big take-away from that session. So, pretty much anything that can call a URL and understand the response can be a client. A lot of my clients have standardized on SOAP web services (didn't get to anything about the SOAP API but I'll catch up on that during the beta) but I plan on leveraging the REST API as much as I can outside of those areas.

The JavaScript API looks pretty good too. Using this, developers will be able to integrate ArcGIS Server services into Virtual Earth and Google Maps and other mashups. Mandown has an good summary of the session. Most of my customers will not be able to take advantage of ESRI hosting the API but that shouldn't be a huge issue. However, it (along with the SOAP and REST APIs) fit in well with the mobile code policies we have to adhere to.

When I went to the FedUC, Jack articulated a vision of ArcGIS providing advanced GIS analysis to whatever client you wanted to use. The Dev Summit really brought that home in a way that you could see it. The various APIs give lots of options that should fit into any environment.

Lastly, I attended the session on securing .Net web applications. The security model is essentially an extension of what we did at 9.2 but a whole lot easier to administer. They generally follow the ASP.NET model (OS security, Forms, custom provider). That'll make it easier to to get systems accredited. However, with regard to AGS web services, they've made one significant change for the better (IMHO). Security for web services is now managed by the SOM rather than being defined in the web.config. This has one huge advantage in that security is now applied consistently to web services regardless of which API you are using to access the services. This means that whether you use the Java ADF, .NET ADF, REST API, JavaScript API, SOAP API or whatever, web service security will be the same. I'll need to educate some of the security types I deal with on the SOM (and they'll want to red-team it, I'm sure) but I think it'll end up being an easy sell.

So, this'll be an exciting release for developers. I think it could be as significant as when we were all introduced to ArcObjects at 8.0. Now, I've just got to get into the office and set up the beta....

UPDATE: James raises a good point about the demos. They do make it look like you can do really cool stuff with just a little bit of code. It's important to remember that calling the service from the API is just one part. You'll still need to implement your complex logic in the service. Also, more sophisticated behaviors on the client will require more code there. It's important not to get caught up in the sales hype. 9.3 will offer some powerful options but it's important to keep the total level of effort in mind. The new APIs give you more options for developing your applications, but they don't obviate the need to actually write the code.

First I'd like to note that I'm a geographer, not really a programmer, but... I learned a lot at the DevSummit and I got a lot of crazy ideas for my post-Redlands life. I did realize that to understand the mechanism that is ESRI GIS you can be a dope like me, but to develop the mechanism it's hard work. I guess any development is really. Putting up with the client/user's griping and complaining, their clueless ideas and so on. I commend a lot of developers for putting up with that crap, and most other geographers should too.

So, yes, my first DevSummit opened up a new world to me. One that f'in nuts! Still, I like building things, designing things, seeing the happy smiles of users. So, I think I'll not only keep up with the tech and the processes that are new in buttonology, but also keep up with the tech that makes working with GIS "so fun."

Bottom line: ArcGIS Server 9.3... F'in rocks. It's off the hook, fool.

Side notes:

1) Jeremey B. said he should have made a "HTTP Goodness" t-shirt. I mentioned they would probably sell like hot cakes at the UC or next year's DevSummit. I also recommended that he make "GET" and "POST" shirts too.

2) I spent the afternoon in the Microsoft Lounge charging my laptop, doing some homework, and found myself consulting with Ed Katibah and a Redlands alumn from back East. I tell you, that Ed sure is awesome. Always fun to chat with, always a ball of energy. Though I felt kind of bad about holding him up from his FAQ work that he did for the Microsoft SIG. I told him though that he's lucky he hasn't suffered from "Adult Onset Internet ADD" like I have. That's what GIS and blogging will do to you.

3) The Flex API for AGS was "demonstrated today. Slick, slick, slick. In the three weeks that they've worked on it, it has some great visualization capabilities in the browser. The interesting thing is that you can not only build web RIAs but you can also export your work to Adobe Air for a light weight desktop app. Licensing? No clue. It's built to mimic the AGS 9.3 JavaScript API, so any changes to either one, the other should be updated as well. So, a pretty nice presentation layer for the Flex/Flash folks. BTW: The Flex API isn't in beta yet. Notice I said they worked on it for three weeks? So, Flex and AWX devs/designers will have to wait.

4) Congrats to Dave Bouwman. He won second place in the Code Challenge. Just think if he would have reminded us to vote for him?