In simple terms, ArcObjects are a set of COM components. To work with ArcObjects in the .NET development environment, a collection of .NET primary interop assemblies and COM object libraries have been generated to manage .NET-COM interaction. ArcObjects components are installed with the ArcGIS Desktop, ArcGIS Engine, or ArcGIS Server products. They can be used locally on any machine where they've been installed. ArcObjects can also used remotely with ArcGIS Server via distributed COM or DCOM. ArcGIS Server provides a remote process in which ArcObject run locally on the server, and client applications use .NET primary interop assemblies and COM object libraries to work with them remotely. Basically, the COM object libraries act as proxies to ArcObjects components on a remote server. The Web ADF, ArcGIS Engine, and the ArcObjects SDK for the Microsoft .NET Framework include the .NET primary interop assemblies and ArcObjects proxies required to access to ArcObjects remotely.
ArcObjects provides a set of libraries that include comprehensive, rich geospatial functionality. Much of that functionality is available in standard service types included with ArcGIS Server, such as map, geocode, and geoprocessing services. ArcGIS Server developers can build server applications, such as Web applications, Web services, and desktop client applications that utilize ArcObjects. An ArcGIS Server developer can utilize ArcObjects in a service via remote access or extend a service with custom ArcObjects logic attached to a service.
Remote access
Client applications can use ArcObjects COM proxies to remotely access coarse and fine grained functionality packaged with services. Services represent server objects in the ArcGIS Server container process (ArcSOC.exe) and client work with server objects in an explicit server context. Coarse grained interfaces on the server object provide stateless access to service contents. Fine-grained functionality is usually associated with stateful access to objects and components in the service. In addition, just about any ArcObject coclass can be created and used in server context. Basically programming ArcObjects remotely is the same as programming ArcObjects for use in desktop applications, but there are some additional details and programming guidelines you need to follow. You need to understand:
- How to connect to the server
- How to get objects that are running within the server
- How to create new objects within the server
- Optimal ways for working with remote ArcObjects, which may include solutions presented in the next section on extending ArcGIS Server
A comprehensive discussion of ArcObjects development with ArcGIS Server is provided in the ArcObjects SDK for Microsoft .NET under the topic Developing with ArcGIS > Developing with ArcGIS Server. In addition, the Web ADF includes the ArcObjects COM proxies and a local data source implementation that enables remote access to ArcObjects on the server. See the section titled Access a data source specific API for more information.
Extending ArcGIS Server
Extend existing services with custom ArcObjects functionality that runs on the server, with the service. This can be accomplished using Server Object Extensions, also referred to as SOEs. Server Object Extensions are significantly different than client APIs and frameworks because they enable a developer to add functionality to an existing service locally, meaning on the server. A developer can create custom logic in ArcObjects that utilizes service contents and attach it to a specific server object. The extension executes in process with the service itself and shares its context and lifecycle. There are two main reasons for creating a SOE:
Extend existing services with custom ArcObjects functionality that runs on the server, with the service. This can be accomplished using Server Object Extensions, also referred to as SOEs. Server Object Extensions are significantly different than client APIs and frameworks because they enable a developer to add functionality to an existing service locally, meaning on the server. A developer can create custom logic in ArcObjects that utilizes service contents and attach it to a specific server object. The extension executes in process with the service itself and shares its context and lifecycle. There are two main reasons for creating a SOE:
- Reduce the number of remote, fine-grained requests in server context. ArcObjects logic that resides in a client application and requires many fine grained calls to objects in server context over DCOM can be very expensive. In most cases, intensive ArcObjects logic should be hosted locally on the GIS Server and made accessible via intuitive public methods.
- Add custom functionality to an existing service and enable access via SOAP and/or REST service endpoints. While the capabilities of service types included with ArcGIS Server suffice for most applications, additional functionality only available within ArcObjects may be required for comprehensive solutions.
Concepts and samples that show how to create, customize, and deploy Server Object Extensions are provided in the ArcObjects SDK for Microsoft .NET. A comprehensive discussion of extending ArcGIS Server is provided under the topic Developing with ArcGIS > Developing with ArcGIS Server > Extending ArcGIS Server.