Thanks for the link! The idea of direct connects not tying up a license seems to make the most sense, I’m just extremely nervous about getting a quad-core DBMS server when all we’re licensed for is four cores. My company is small with an even smaller budget, and a non-existent budget when it comes to GIS technology, so a bad recommendation would really put me in the dog house.

I’ve also found AGX to be extremely slow. When you add layers from a FGDB, its works pretty well. Once you add a map service though, it’s like a dial-up all over again. With that kind of performance, we’ll have to stick with a web application.

http://blog.davebouwman.net/2006/11/18/ArcGISServerLicensingTheFinePrint.aspx

Again, I guess only ESRI has the final knowledge. Hopefully you can make some headway on that front.

On another topic, I was able to bring my project to life – a desktop WMS server that uses the HttpListener capabilities of .NET 2.0 and the Open Source MapServer to dynamically serve layers from ArcSDE without requiring them to be set as services in ArcGIS Server.

On the upside, this tool worked great in Google Earth. On the downside, it worked not very well in AGX. Google Earth behaves as I would expect – each time you move the globe, GE sends one request for the WMS image of the current extent. AGX tries to be smart and create caches (even when I thought I set it not to). The result was very inconsistent performance. When a position change in AGX caused it to build a cache, everything came to a grinding halt as it pelted the WMS server with image requests. Then you’d get good performance as AGX used the cached images, but I never knew for certain whether changing position would be fast as cached images were used or really slow as new images were added to the cache. In addition, AGX seems to be slow in rendering the images.

I wish AGX would go to the “dumb” model of just making a fresh WMS request each time the globe was moved or would quickly update the visible portion of the screen and do the caching in the background.

Your long but enjoyable post begs to me ask this beat to death question here….

Currently we have two servers supporting our GIS, a box with AGS installed on it, it hosts all of our services and our websites. Then we have our database box running SQL Server. We use direct connects to the database. We’re licensed for four cores. Our AGS box has two, and I believe our SQL box has two. Since we’re using direct connects, do the cores on our database box count against our license limits?

I realize this is a bit off topic, however everyone I talk to at ESRI, including the technical PM’s down in Charlotte, tells me something different. Just seeing if anyone has any similar situations in which they found the answer out the hard way.

When you’re talking about environments such as Google Earth or AGX, I think there is value to moving as much work as possible to the client. The ability to pan and zoom in a very dynamic fashion in these environments mean they can make many more requests and put a lot more strain on your server. Add to that the fact that I don’t find AGS to be particularly zippy, and, IMO, the ability to directly open layers from the SDS in AGX without going through AGS would be a valuable addition.

In regards to AGS just “sitting there”, that doesn’t negate the fact there is a cost involved with publishing layers. This change in 9.3 seems to mean that we’ll get one additional installation of the full AGS product. When we upgrade the server that runs the SDE process (which is currently how we connect), that server will now be a full-fledged AGS server instead of just an SDE server. However, that box is also our RDBMS box, and that is one server that I definitely cannot devote RAM and CPU cycles towards running AGS map services. That server will still just run the SDE process, meaning the extra AGS capabilities will go to waste. I suspect that we won’t be the only organization who faces that situation, especially among smaller organizations.

Theoretically, if we configured our ArcMap users to connect to the SDS using direct connect, we would no longer have to run the SDE process on our RDBMS box. That would free up the AGS license to run on another box (assuming we had a spare server), but if the 9.3 licensing is like the 9.2 licensing, the AGS license will transfer to the existing hardware as it is currently configured. That means we can’t take that license that is currently only running the SDE process and move it to another server that we’re more comfortable using as a full-blown AGS server. I’m not sure how strict ESRI is in terms of the moving licenses, but, per the licensing summary that was linked to from this blog, the 9.2 license agreement does specify that it transfers to the existing hardware as configured at the time of the upgrade.

Most of our SDS rasters and feature classes are not available as services in AGS, and the nature of AGS seems to hinder our ability to make them available. Most of our data is not organized as one big feature class, but a number of regional classes. To publish a complete raster or vector dataset, we need to create an MXD that has 10-20 layers instead of one, and the more layers in an MXD, the more memory AGS seems to use.

In the end, I would just reiterate that the ability for any user in our organization to open up AGX and browse to a layer on our SDS without me having to use time or server resources to publish the layer (because most of our SDS feature classes are available via AGS) would be a welcome addition. Either that, or slim down AGS and make it more memory efficient and faster.

Because of how AGX works, you can’t consume vector layers natively at all so it makes no sense to me to bother with local connections when AGS is just sitting there waiting to be used.

In ArcGIS 9.2, if you have ArcMap and AGS and want to view a layer in your SDS, you have the following options:

1. Connect via an “SDE” process (i.e. giomgr.exe(?)) running on a server (usually the same server as the RDBMS).

2. Use the “direct connect” option in ArcMap, possible because ESRI has built much of the logic that used to be only the SDE process directly into ArcMap.

3. Publish the layer as a service in AGS (i.e. a SOC.exe process) and add it as a GIS server connection.

In Explorer, you have this option:

3. Publish the layer as a service in AGS and add it as a GIS server connection.

The “direct connect” option has distinct advantages in terms of end-user flexibility and conservation of server resources over publishing layers as AGS services. Given a choice, I would tend to think this would be the preferred option for internal use.

The data is available sitting there in the Spatial DataStore – why should we have to jump through another hoop of publishing it via AGS to make it viewable in AGX? Why make me publish additional MXDs and take up additional server resources?

I don’t want to complain too much, because I do think it’s a nice product, but if I could just open up AGX and pick layers off the SDS and pull them in without having to publish them in AGX, that would be a real win and (even with view-only capability), I bet that AGX would be one of the most popular apps in my organization.