In defence of the Web ADF.

If, like me, you have been developing internet mapping and GIS applications for a few years (twelve odd in my case) you can see how easy it can be to develop applications to do exactly what you want to do. You can design, architect and deploy all sorts of solutions to fit into you business or integrate into your enterprise systems.

It should be understood though that in the world of GIS (can we still call it that in this neo world?) most people aren’t developers or architects, they are analysts or planners or engineers that might want to share the information and maps are creating in their desktop application or capturing in the field, they want to do this with the minimum of fuss with a set of tools that do a straight forward job.

They also want to do it now, not in six month time at the end of a project, and also they might want to do it tomorrow with the need for a change request to be placed in the system.

UX is an important thing, but it isn’t the only thing.

In the world of Flash, Silverlight and JavaScript libraries it is easy to forget that many people just want to get a job done. In the world of techno-geeks and geo-nerds (I’m a mixture of both if you want to know) it is easy to overrate the shiny-ness of technologies in the actual usefulness of a solution to get a person’s job done.

Often development and implementation is a trade off in available resources, time and knowledge. Given infinite time and resources of course it is possible to build anything (ok almost anything, don’t get picky). But we often don’t have the luxury of either. A product and client like the the Web Mapping Application, available in ArcGIS Server 9.3.1, is a technology that is currently the only way for non-developers to get web based applications out for use within an organisation. It is also currently the only option with a task framework which can easily consume geo-processing tasks and edit data in the browser, using just standard out of the box tasks. This is still as powerful a tool as it was when it was first released.

Although web development technologies have moved on since the WebADF was first developed, the power and integration possibilities with ArcGIS are still unmatched. Whilst it might be possible to develop and architect a new solution platform using the REST API the WebADF currently does much of the heavy lifting for you. The framework it provides allows for the development of true Web GIS applications, the sort of applications that many professional GIS users actually want. In the new time of lightweight solutions the Web GIS platform of the WebADF’s time might be around the corner.

With great power comes great responsibility

As with anything that has a possibility of being tightly integrated with the server the WebADF has big implications with respect to performance, especially with the fact that you can tie the development to the non-pooled services. This does throw up some architectural challenges when moving such applications from the development stage to the production stage, but certain design decisions can help with performance and a testing regime throughout the project will allow for any problems to be caught before they become an issue.

A starter for ten.

It seems in this increasingly twitter fuelled world that anyone starting a blog must be certified. Surely the world can’t read more than 140 characters anymore, why bother making them? Well always one to buck the trend, I thought it might be a good time to start a blog.

Hmm a blog, what should it be on? ArcGIS, nope plenty of those, Programming, nope loads of those also. GeoNerdRage? Nope I can name a few of those also 🙂

So in order to start this blog I decided on the theme of performance and scalability, the architecture of such and the technologies that can help people design and develop solutions for performance and analyze the problems when things go wrong.

The need for performance

To me this is an increasingly important topic as a lot of spatial systems beyond simple mapping sites to solutions that integrate into key business applications within an organisation. Microsoft, SAP and Oracle all provide the big systems that power enterprises and GI is often stored within them or integrated alongside them to provide information the organisations use to make business decisions. In the past it has often just been a challenge to get the systems to work together at all, but with the move towards SOA and recently REST based services, it is increasingly easy to call systems and tie services together to improve the decision making process. In order for this process to be seamless they system also must be quick and perform under load and continue to perform even when the system grows with greater capacity.

The quandary is that as systems become more complex and solutions integrate together the design choices become increasingly important. The solutions we could get away with in the past with simple mapping applications become more challenging when integrating SOAP services with SAP, or scaling an editing application up to hundreds of concurrent web users. It can be done and that is where a constant approach for working performance into any design and monitoring the performance of any system at a variety of levels throughout the development process and into deployment stages.

How you do that and how you monitor it I’ll leave to future posts but much of the process can be found at a high level in the following documents:

Performance-Driven Software Development – Carey Schwaber (Forrester report can be found elsewhere on the internet for free if you register)

And the excellent

Performance Testing Guidance for Web Applications – Microsoft Patterns and Practices

Enjoy the ride…..