Up until 10.1 we had an implementation that worked quite well. We had a single class library. It had the handler for the tools (GPFunction), the individual definitions for parameter info et. al., and our main business logic which each defintion.Execute method would call. For whatever reason we were able to publish this to the ArcServer and the server was able to pull out the SOAP parameters and everything functioned fine without inheriting any server components or using Service.EnterpriseServices. Maybe because the tool used SOAP to pass the parameters or whatever this worked for us just fine.
Now that we are on 10.1 we're told we need to wrap our services as SOE services and deploy that. In fact ESRI says we are violating ArcObjects licensing agreement in the way we have our services pushed out! So now I'm learning about all of this and wanted to know this:
If i have our new library definition:
Server.dll (holds the code and tool interfacing--this orginally was all we published)
Interfaces.DLL (holds the interfaces for the objects and services)
SOEServer.dll (Holds the SOAP front end for all services and then calls into the code in Server.dll)
I assume that this isolation between server and tool code should allow us to still continue to deploy the code as a tool in ArcMap and for those who need it we can deploy the server code. Based on what I've read so far, then, the client needs to change so that it uses the interfaces to call the services on the server? Is this correct? Currently the client calls the service in the same way as if it was calling a tool except that it is doing a SubmitJob(); I'm not sure exactly how that changes the client call??? Do we do the same tool-like call or do we need to now make a more specific server call??? I'm lost here. New to ArcObjects and the guys that originally wrote all this code don't work here anymore. 🙂
