Saturday, November 18, 2006
Posted on Saturday, November 18, 2006 1:52:41 PM (Mountain Standard Time, UTC-07:00)  Comments [5] | 
Categories: ArcGIS Server | ESRI

[Update: Once James Fee linked to this blog, the comments started to pile up over at his site. Here's a link to them.]

[DISCLAIMER: I do not work for ESRI, not do I represent any official stance on licensing. This is how I understand things from talking with ESRI. I'm fully willing to ammend this posting if ESRI has substantially changed their policy from what is described here.]


Ok - I'm not the first one to post the "reported" price for ArcGIS Server - someone else did in comments on James Fee's blog. Anyhow, I've been looking around the ESRI ArcGIS Server pages for the list pricing, and have not found anything. So, for this post, lets use $XX,XXX instead of specifics. The actual dollar price is not my point here. Suffice to say that ArcGIS Server is not cheap, but the devil is in the details.

The other thing I've been looking for on-line is the actual licensing breakdown for the ArcGIS Server components. Since the server has multiple components (SDE, SOC, SOM and ADF), I want to know how those pieces are licensed, and how I should expect to configure a system.

In particular I want to know how the pricing changes if you run ArcSDE on a separate machine, and the ADF on a separate web server. I'm not sure about how you do things, but typically when I'm building a web application, I assume it's going to be running on a web server. The geodatabase will be on a separate DBMS box, and (for server) the SOM/SOC is on a dedicated server. This is what we've been instructed to do in the past, so I'd assume this is the model to move forward with.

First, ArcSDE. The deal is that while you "get" ArcSDE with ArcGIS Server, if you want to run the ArcSDE "service", the DBMS and the service must be on the ArcGIS Server box. If it's not on that server, then you must pay full per-socket pricing for the DBMS server. Ok - this is pretty much how the ArcSDE pricing model went. If you choose to use 'direct connect' then you leave the "licenses" on the ArcGIS Server machine, and simply connect to the DBMS server - at no additional cost.

Conclusion: Direct connect is gonna get a whole lot more common.

Next up - the Web ADF. Since the Web ADF has all kinds of cool functionality, I was really interested to see if there was a licensing fee for deploying it. At ArcGIS Server 9.1, you had the ADF Runtime that you could install on the target webserver - there was no separate licinsing for this component. So, I had high hopes. But, what I've come to learn (by talking with ESRI because it's not published anywhere I can find) is that the ADF is licensed at 9.2. And it's not just a little run-time cost. It's the full per-socket price of the server. That's right - if you want to run your web site on a different system from your SOC's, you need to fully licence that machine - at the same level as the SOC's it talks to.

Here are my concerns:
Security. Assuming you got with the all-on-one box model - where are you going put it? On the LAN? Then you need to open ports from the internet onto your LAN - not exacly something your security admin will like doing. If not the LAN, then in the DMZ? How many security admins are gonna let you put your enterprise dbms in the DMZ?? Thus, it would seem to me that for anything other than intranet apps, you're looking at a 2x price bump simply because you need to put the ADF on a separate web server.

In my discussions with ESRI on this, they said that because the ADF now handles the tile cache, it actually off-loads much of the map making work from the SOCs, which means it should carry the same licensing. While it's true that a tile cache saves a lot of work, is true it's not exactly a compelling argument. Creating a tile cache is not magic that can only be done by ESRI. Brian Flood has implemented this in the next version of Arc2Earth (pro edition costs $299). Slap OpenLayers (free) in front of that, and you've got the same thing running for a tiny fraction of the cost. So telling me that I should pony up twice the money for server because of a tile cache is not compelling at all.

So - where are we. If you want to design a system the way you have it running today - you're looking a 3 times the base pricing for server - this will get you ArcSDE running as a service on a separate DBMS (assuming 2 sockets) and the web ADF running on it's own server (also 2 sockets).

Anyhow, I just wanted to post the details as I understand them since ESRI (at this point) has not posted anything related to this, and I know there are a lot of people who are excited about the web ADF, and this is going to come as a big suprise.
Saturday, November 18, 2006 3:53:42 PM (Mountain Standard Time, UTC-07:00)
Not to toot my own horn too much here, but depending on what you do, you might want to just use TileCache as a tile caching engine. If you have a WMS instance at the backend, setting it up is as easy as changing two lines of a configuration file, and gives you speeds of several hundred requests/second. TileCache is BSD licensed Python code, released by MetaCarta Labs. (Disclaimer: I work for MetaCarta.)

It's ideally suited for use between OpenLayers and any slow WMS service you might have. You can see it in action in the demo.

I'm not sure if this solves your problem, because I don't know about any of these acronyms. Essentially, what TileCache wants is a WMS service -- I think this means you need ArcSDE at the backend as a database, and something to generate the WMS tiles. I think that 'something' is 'SOC' as described in your post? If your need is to serve tiles to a web mapping client like OpenLayers, (and my assumption about how things work is correct) then you could skip the ADF cost entirely...

Of course, if you wanted to take that a step farther, you could start using Mapserver's ArcSDE support, and generate your maps using Mapserver.

Once you go that far, you might even be willing to pull your data out of ArcSDE and go into PostGIS...

Okay, so I have a feeling that there is a level of support there that is not quite to the level that most people using COTS software have come to depend on. However, it is useful to at least look at what options there are to wander down the stack, moving into the Open Source world one piece at a time.

Good luck with ESRI, and if you're ready to come into the Open Source world, we'll be waiting :)
Saturday, November 18, 2006 8:12:25 PM (Mountain Standard Time, UTC-07:00)
Dave,

Thanks for the heads up on the ADF licensing! I'll be following that up ASAP.

Recent discussions with the local ESRI crew about high availability architectures didn't surface the ADF licence issue. The fact that the SOM and SOCs now had to run on licensed CPU sockets was raised. As was the direct connect issue, and the "included" ArcSDE which also has to run on the same box as the ArcGIS Server licensed components.

The tile cache argument does not seem compelling. If anything, I would have expected the reasoning to be due to the added functionality in the ADF, not just the tile cache.

Generating a tile cache is not something that I'd want to do on a production server. I wonder if there are licensing implications for using a dev or test server to do that work.

Andrew
Sunday, November 19, 2006 8:29:14 AM (Mountain Standard Time, UTC-07:00)
FWIW, I have heard from the geodatabase team at ESRI that Direct Connect is the preferred technique rather than using the ArcSDE application server- for performance reasons. I don't have any data to back that up, though.
Rich Ruh
Tuesday, November 21, 2006 8:15:17 AM (Mountain Standard Time, UTC-07:00)
Dave,

I know you might be sick of this discussion, but I'd really like you help clarifying what you said in the sentence below, if you'd be so kind.

"First, ArcSDE. The deal is that while you "get" ArcSDE with ArcGIS Server, if you want to run the ArcSDE "service", the DBMS and the service must be on the ArcGIS Server box."

When you say "if you want to run the ArcSDE 'service'...", what do you mean. Is the service you mention somehow different than normal ArcSDE features... data loading and consumption through ArcGIS desktop? For some reason I'm getting the impression that you may be referring to some sort of ArcSDE web service or something. Could you help me grok? Thanks.

Tuesday, November 21, 2006 10:05:53 PM (Mountain Standard Time, UTC-07:00)
The service I'm referring to is the actual ArcSDE windows service - the giomgr.exe process. This is the traditional method of connecting to ArcSDE. The other option is "Direct Connect", where the client - ArcMap/ArcIMS/ArcGIS Server actually takes on all the processing load the giomgr.exe process used to handle.
The upside of the new model is that you have have the "SDE" license running anywhere, and then use direct connect to access spatial databases on as many servers as you like (or so it was explained to me). Thus, going "direct connect" allows you more flexibility than before.

Cheers,

Dave
Dave
Comments are closed.