Tell me more ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.
up vote 8 down vote favorite

I get this question a lot from web developers, and would like to have a short concise answer for them ...

Why do I need ArcGIS Server just to host ArcObjects in a web service?

share|improve this question

2 Answers

up vote 4 down vote accepted

You can use the ArcObjects SDK to build your own services without a problem on a server as long as you have a appropriate license. I have a number of services we use that do not use the SOC/SOM services in AGS but are still ArcObjects consumers.

The reason you need AGS is a license issue; you are right you could use the ArcEngine runtime to do what you need but that is not acceptable.

share|improve this answer
Thanks @DEWright. So are you saying I can start up a thread from my web service, set the thread's apartment state to STA, then initialize the license to server and then use arcobjects? – Kirk Kuykendall May 25 '11 at 16:50
That is correct; just as you can with any ArcGIS Desktop extension; you just use the ArcGIS Server option for the license and you get access to the appropriate API level. We do this alot talking to the GeoDatabse classes as well as other functions in our webservices. – D.E.Wright May 25 '11 at 17:15
up vote 3 down vote

AFAIK. Because ESRI licensing don't allow you to install Desktop/Engine ArcObjects and run it as a Server. (Need to find a reference to a licensing agreement, stating that...)

share|improve this answer
Yup I read that also. – Donny V. May 25 '11 at 15:14
But even if I am licensed to use ArcGIS server, I thought there was also some issue related to the threading model that prevents using arcobjects when implementing, for example, a WCF REST service with no SOC involved. – Kirk Kuykendall May 25 '11 at 15:29
@Kirk-Kuykendall That's true the Server APIs are made for running on a server and the design of the server make it easier to build and scale the solution with more SOCs etc, without dealing with threading issues. The main problem is probably that the APIs in the desktop products are not made for running on a server and have hooks to GUI stuff and to support running in a non-GUI environment ESRI would have to document exactly what APIs that can be used or separate the core APIs and GUI even more. If people like that idea it's possible to make an idea on ideas.arcgis.com and vote for it... – MathiasWestin May 25 '11 at 16:10
The SDK actually has many of the APIs broken down between UI and the supporting classes; you just need to make sure you step through them properly. The biggest thing I have seen is making sure you handle you memory and objects properly on the server side; the AppPools need to support a single instance; you start trying to run multiple instances of the ArcObj libraries and I saw explosive crashes. – D.E.Wright May 25 '11 at 17:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.