GeoServices REST Specification and OGC

So this is what I get for missing the Ignite sessions at WhereCampDC*:

http://twitter.com/#!/spara/status/81369354746331136

*I got to dance with my daughter and help her chase fireflies so I win.

The worst-kept rumor/secret in recent memory is now “out there” so here are my thoughts:
Continue reading “GeoServices REST Specification and OGC”

Crazy Times – Coming Up For Air

It’s been an extremely busy few months, as evidenced by the pace (or lack thereof) of blogging. I have been hopping between customer sites, mainly helping with ArcGIS Server implementations. We’re also re-hosting an ArcIMS site for someone. I expect that to eventually transition as well but we have to get it moved first. I’m also working a pro-bono implementation of PostGIS/GeoServer/OpenLayers for the town of Green Mountain Falls, Colorado. That’s been fun. It’s great to see how a small town can marshall it resources (Boys Scouts with GPS collected trails as an Eagle Scout project) to get things done. The initial implementation will be simple as they are more interested in getting their data out there but then we’ll circle back around to address public-service-type applications after that.

Significant changes are coming for zigGIS. Abe, Paolo and I have been laying out a roadmap for its way ahead. Look for an announcement soon via zigGIS on Twitter.

I have been having a lot of fun with the REST-based APIs from ESRI (Javascript, Flex, Silverlight/WPF). In particular, I’ve been happy with how extensible they are in terms of being able to support new data sources.
OpenLayers 2.8 and GeoExplorer are also on my radar but that radar screen is getting pretty crowded.

All of this with less than a week to go before vacation. Whew!

Dev Summit: Ahhhh, the APIs (and Security)

ArcGIS 9.3 looks really good all the way around. ESRI seems to have really put a lot of work into making this a quality release. Basically, it’s all about consolidating the vision of 9.2 while also improving the execution of that vision. To be sure, there are some new capabilities (PostgreSQL support, Javascript API, REST API, etc.) but there has been a huge effort on shoring up the quality of the product. The ESRI developers themselves seem really excited as well. It seems as if they can’t wait for the beta to get in our collective hands. But, this being the Dev Summit, the real star of the show was the APIs.

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.

Dev Summit REST API Session

I just sat through the first REST API session at the Dev Summit. They had it in a pretty big room and it was packed. There is a lot of interest in it here. Generally, you can walk up to just about any random person and they’ll say they want to learn more about the REST API. The other web APIs (JavaScript, SOAP, etc.) are also generating a lot of interest.

To sum up the REST API in one word: impressive. ESRI is definitely on the right track here. I think this API could end up overshadowing the others over time. After sitting through the session, I have my doubts about whether the API holds up to the strictest definition of REST but I came away unconcerned by that. The simplicity and the power of this API cannot be understated.

All resources (requests, layers, services, etc.) are represented as URLs. This provides the ability to very simply call powerful geoprocessing and analysis services running in ArcGIS Server. The API also supports a myraid of output formats. They demonstrated using Google Earth, Google Maps and Virtual Earth as clients. Also shown was the use of Python and Ruby scripts to call AGS services through the REST API as well as Yahoo Pipes. The output formats specifically discussed were HTML (default), (geo)JSON, KML/KMZ, image, layer (for use by ArcMap clients), NMF (for AGX), Google Maps and Virtual Earth. There’s enough there to pretty much do what you need.

Before anyone asks, no they did not specifically mention OpenLayers nor was it shown but there were numerous examples of GeoJSON output. Based on what I saw, I think it would trivial to integrate with OpenLayers.

The REST API makes diligent use of caching in order to optimize performance. One aspect I was interested in was security. During the plenary, it was mentioned that AGS security can be managed using industry standards such as LDAP and others. While this is not specific to the REST API, it is worth noting that, once security settings are defined, they automatically apply across all of AGS’s supported web interfaces. This will be a huge thing for many of my customers. In addition, security is role-based and can be applied to folders or individual services.

From a developer standpoint, 9.3 could end up being the most important release of ArcGIS in a long time. The JavaScript, SOAP and REST APIs will open up development to a lot of new developers. I think that these APIs will be critical to achieving the goal for ArcGIS articulated at the FedUC for AGS to be the geospatial analysis engine that can feed the visualization client of your choice.

A couple of other minor notes: AGS 9.3 introduces a geometry service that’s not bound to any specific data but exposes geometric opertations to clients. Currently, the REST API only supports simple geometries so parametric types such as arcs and circles are converted to densified lines or polygons.

This was an impressive session. It looks like ESRI is putting a lot of effort into getting the REST API as right as they can this first time out. This session made me eager to get home and get the 9.3 beta running.