Most impressive is the level of abstraction in the API, ESRI are really delivering on the sales pitch on this one, its small and powerful – this makes it super quick to develop with, case in hand being the handful of lines required to build a custom identify dialog. In three days last week we went from a handful of Feature Classes to a full-blown web app (and it’s robust). But it’s not just the lean API that makes for rapid development, the close coupling of ArcGIS Server to the Map Document also starts to pay dividends. I’ve always been cautious of MXD driven web services, as its eating up the full set of ArcObjects under the cover, which eats memory on the server, SOC processes rarely start the day on less than 60MBs for breakfast, but the trade off is access to all the goodness of the MXD, in this case some VBScript labelling and scale thresholds – this would be a nightmare and time consuming to code on the client.

Hungry Soc Monsters from Mandy Jouan – helping to make nice web maps =)

From a consultancy perspective, how do you make a business model of delivering JS, Silverlight or Flex based solutions, when the pre-sales associated with securing the work could often be larger than the job itself?

I’m convinced there is a successful business model (somewhere) for someone to build a server farm, install AGS and provide virtual hosting for ESRI customers – who perhaps don’t want the hassle of maintaining an enterprise AGS setup. I know Kirk and Brian have mulled over this situation and touted Amazon EC2 style solutions. Talking with my mate Phil, we pondered exactly what would be required apart from a big expensive pipe in & out.

One thing we decided would require some additional thought is how to manage load balancing of servers. The Server Object Manager (SOM), which spawns the Server Object Containers (SOC’s) – where the work is undertaken for each interaction with the server, will to some degree balance the load between SOC machines, but what happens when you have so many requests being made to the SOM, that one machine can’t handle all of them?

As it happens Ray Echevarria, from ESRI Implementation Services, has looked into such a situation and published his findings in a whitepaper. I’ve copied a diagram from his pdf that illustrates his test configuration:

Ray configured ArcGIS Server 9.1 to work with the Network Load Balancing (NLB) functionality, NLB is included with Windows Server 2003 Standard Edition and is designed to load balance between multiple network nodes. The following tests were performed for an HTML client requesting map services from a pooled AGS object:

• Tested simulated failure of a Web Server to ensure that client requests were re-routed to the surviving Web Server via NLB control logic.
• Tested fail-back after rebooting a Web Server to ensure that client requests were once again load balanced between the two Web Servers via NLB logic.
• Tested simulated failure of a Map Server to ensure that client requests were re-routed to the surviving SOC via SOM logic
• Tested fail-back following a Map Server reboot to ensure that client requests were once again load balanced between the two SOCs via SOM logic.

For more on Rays findings, checkout his document AGS 9.x High-Availability Configuration Testing Using Microsoft Load Balancing.