In this topic
Local (DCOM) connections are only supported for ArcGIS for Server versions prior to 10.1.
About working with the ArcObjects API
In simple terms, ArcObjects are a set of Component Object Model (COM) components. To work with ArcObjects in the .NET development environment, a collection of .NET primary interop assemblies (PIAs) and COM object libraries have been generated to manage .NET-COM interaction.
ArcObjects components are installed with ArcGIS for Desktop, ArcGIS Engine, or ArcGIS for Server. They can be used locally on any machine where they have been installed. ArcObjects can also be used remotely with ArcGIS for Server via distributed COM or Distributed Component Object Model (DCOM).
ArcGIS for Server provides a remote process in which ArcObjects run locally on the server, and client applications use .NET PIAs 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 Application Developer Framework (ADF), ArcGIS Engine, and the ArcObjects software development kit (SDK) for the Microsoft .NET Framework include the .NET PIAs and ArcObjects proxies required to access 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 for Server, such as map, geocode, and geoprocessing services.
ArcGIS for Server developers can build server applications, such as Web applications, Web services, and desktop client applications that utilize ArcObjects. An ArcGIS for 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 for Server container process (ArcSOC.exe) and clients 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 ArcObjects 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 the following are some additional details and programming guidelines you need to adhere to:
- How to connect to the server
- How to get objects that are running within the server
- How to create objects within the server
- Optimal ways for working with remote ArcObjects (can include solutions discussed in the Extending ArcGIS for Server section in this topic)
A comprehensive discussion of ArcObjects development with ArcGIS for Server is provided in the ArcObjects Help for .NET developers Help system under the following table of contents (TOC) nodes:
- Developing with ArcGIS, Developing with ArcGIS for 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. For more information, see Working with data source specific APIs.
Extending ArcGIS for Server
Extend existing services with custom ArcObjects functionality that runs on the server with the service. This can be accomplished using server object extensions (SOEs). SOEs 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 and shares its context and life cycle.
The following are the main reasons for creating an SOE:
- Reduces 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 geographic information system (GIS) server and made accessible via intuitive public methods.
- Adds custom functionality to an existing service and enables access via Simple Object Access Protocol (SOAP) and/or Representational State Transfer (REST) service endpoints. While the capabilities of service types included with ArcGIS for Server suffice for most applications, additional functionality only available within ArcObjects can be required for comprehensive solutions.
Concepts and samples that show how to create, customize, and deploy SOEs are provided in the ArcObjects Help for .NET developers Help system under the following TOC nodes:
- Developing with ArcGIS, Developing with ArcGIS for Server, Extending ArcGIS for Server, Server object extensions (SOE)
A comprehensive discussion of extending ArcGIS for Server is provided in the ArcObjects Help for .NET developers Help system under the following TOC nodes:
- Developing with ArcGIS, Developing with ArcGIS for Server, Extending ArcGIS for Server