Overview of extending ArcGIS Server

Most developers will extend the GIS server to optimize the performance of their application. The goal of these extensions is to minimize the number of ArcObjects calls between the client application and the GIS server by encapsulating functionality in server-side components and exposing coarse-grained methods for client applications to call. There are two strategies for extending the GIS server for this purpose:

1. Create utility COM objects

   Extending the GIS server with COM objects allows you as a developer to easily share your components across ArcGIS Server, ArcGIS Desktop and ArcGIS Engine customizations. These utility COM objects do not need to be tied to any particular server object configuration or type, and may even be used in an empty server context. This strategy does have some limitations. When extending the GIS server with a utility COM object, the object must be created new for each request made on a particular server object or server context. This means that for pooled server objects, each time a request is made on a server object, the utility COM object must be created. If the COM object has a high initialization cost, this continual creation of the object may be prohibitive. Because the COM object is created for each request, you can't use it to cache information as its used.
   
   Samples: ArcGIS_Spatial_Query_COM_Utility

2. Create server object extensions

   A server object extension is created and initialized at the time the server object instance itself is created and is re-used at the request level, like the server object itself. So, if the server object extension is costly to initialize, that cost is paid only once when the server object instance is created. Also, since an instance of a server object extension remains alive as long as the server object instance its extending is alive, its able to cache information that can be re-used from request to request. Server object extensions are tied to a particular server object configuration or type and can't be used in an add-hoc fashion like a utility COM object.
   
   Samples: ArcGIS_Spatial_Query_Server_Object_Extension, ArcGIS_Simple_Server_Object_Extension
   Scenarios: Creating a Server Object Extension 

The GIS server can easily be extended to use application-specific COM objects that a developer can write in VB, C++, or .NET. If these COM components are installed on the server object container machines on which your server objects are hosted, then they can be used to do work for your application.

Note: If your application makes fine-grained use of ArcObjects, it's not necessary to always extend the server or a server object. As discussed above, it comes down to the volume of those calls that your application will make. If your application is written in such a way that it always makes thousands of fine-grained ArcObjects calls, or the number of fined-grained calls is indeterminate based on user interaction with the application, you should consider moving some of the code into the server. If you design your application such that large volumes of fine-grained ArcObjects calls are not necessary, and your user interface is designed such that your users cannot make requests that result in a large volume of fine-grained ArcObjects calls, then extending the server using either of these techniques is not necessary.

The following is a summary of the different ArcObjects extensions that can be used in the GIS Server:

• Creating cartography

  You can extend ArcObjects to create custom mapping components that can be used with the MapServer, and with the ArcMap desktop application. These extensions include:

  Custom elements: maps consist of many elements, including data frames, north arrows, scale bars, and so on. You can create your own graphic elements and frame elements with their own custom properties. For example, you can create a custom graphic element that displays on a map or layout the name of the machine on which its being rendered.

  Custom map grids: your map's layout can include a grid that expresses the geographic location of the map's data on the earth. You can create your own custom map grids. For example, since grids are typically represented in rectangular format, you can create a custom grid that conforms to the shape of one or more geographic features.

  Custom layers: a layer is a thematic representation of geographic information that is stored in a database. ArcGIS includes a number of layer types, including feature layers, raster layers, TIN layers and so on. You can create your own custom layers to, for example, support a drawing a data format that is not natively supported by ArcGIS, or to extend the way an existing layer draws.

• Extending the display

  You can extend the display capabilities of the MapServer by creating one or more of the following extensions:

  Custom symbols: a symbol is a class that can draw things, such as points, lines and polygons, to a display. ArcGIS's display object model includes a number of symbols for drawing features and graphics that can be combined into multi-layered symbols. If none of the standard symbols can draw your features or graphics the way you require, you may find it useful to implement your own custom symbol. Custom symbols can be applied to any graphic element or feature, they can take part in other multilayer symbols and renderers.

  Custom renderers: a feature renderer is an object that is used to draw feature layers. There are several standard renders, such as the simple renderer, the class breaks renderer and so on. If none of the standard renderers satisfy your requirements, and you want complete control over the way features are drawn, you may find it useful to implement your own custom feature renderer.

• Extending the geodatabase

  You can extend the data management capabilities of the geodatabase in the following ways:

  Class extensions: class extensions allow you to customize geodatabase behavior in the following ways:

  • Custom validation rules - the geodatabase includes a number of standard validation rules. You can implement a class extension to add your own validation logic.
  • Custom handling of edit events - events are triggered when features are created, updated and modified in a geodatabase edit session, or when an area of a topology a feature class is participating in is validated. You can implement a class extension to include execution of additional custom logic as part of the edit operation.
  • Custom handling of related object events - your class extension can listed to events raised by the creation, deletion or modification of related objects to add your own logic for responding to such events.
  • Custom rendering of feature classes - used to specify custom drawing behavior in maps.
  • Specify advanced editing configurations - for an object class you can customize certain aspects of how the rows in that class behave during editing. This includes specifying whether feature can be edited while being projected, if the class requires a geodatabase edit session to be edited, and how relationships to other objects are managed when a feature is split.

  Plug-in data sources: a plug in data source is the mechanism by which ArcObjects is extended to directly read a variety of data sources, including SDC data, and the data sources made available through the Data Interoperability extension. You can create your own plug-in data source to your own data format which will allow ArcGIS to recognize it for read-only operations such as drawing, and as an input to a geoprocessing function.

  Workspace extensions: A workspace extension extends the functionality of a workspace in some way, for example, by managing a new type of custom dataset or by maintaining custom data dictionary information on datasets. A workspace extension is usually used in conjunction with an application that acts as the client of the workspace extension. Here are some of the things you can do with a workspace extension:

  • Filter out datasets that end users should not be able to see or edit. This is a common requirement for data dictionary tables that are specific to your application.
  • Implement your own interface on a workspace extension. The extension can be a useful place to cache geodatabasewide data or behavior.
  • Handle workspace editing events. A workspace extension provides a way of listening to made to the workspace.
  • Handle versioning events with versions, such as reconcile, refresh version, conflict detection.
  • Handle dataset creation and deletion events.

  Custom OLE-DB providers: Microsoft's OLE DB model enables external data to be served to ArcGIS applications by means of an OLE DB provider. You can implement your own OLE DB provider to serve spatial data from a custom data source to ArcGIS or any other application.

Server COM objects and .NET

You can develop utility COM objects in any COM language, specifically, VB, C++, or .NET. A server object extension, which is implemented as a COM object, can be developed in C++ or .NET. When using .NET to create a COM object for use in the GIS server (either utility COM objects or server object extensions), there are some specific guidelines you need to follow to ensure that you can use your object in a server context and that it will perform well in that environment. For an overview of how to create a COM object using .NET, refer to the .NET and ArcGIS topic. The guidelines below apply specifically to COM objects you create to run within the server.

• You must explicitly create an interface that your COM class implements. Unlike Visual Basic 6, .NET will not create an implicit interface for your COM class that you can use when creating the object in a server context.
• Your COM class should be marshalled using the Automation marshaller. You specify this by adding the AutomationProxyAttribute attribute to your class with a value of true.
• Your COM class should not generate an interface for you, instead you should define the interface to represent your COM class. You specify this by adding the ClassInterfaceAttribute attribute to your class with a value of ClassInterfaceType.None.

• To ensure that your COM object performs well in the server, it must inherit from ServicedComponent, which is in the System.EnterpriseServices assembly. This is necessary due to the current COM interop implementation of the .NET framework.
• Use the ComVisibleAttribute to define the accessibility of a COM class in an assembly.  If not specified, the default value for the attribute is true for all public types in an assembly.  New class library projects in Visual Studio set this value to false by default.  You can change it by modifying the AssemblyInfo class for the project or by ticking the Make assembly COM-Visible checkbox in the assembly properties dialog.    
• Clients use COM interfaces to work with COM classes.  COM interfaces implemented by custom COM classes can be included in a separate assembly for distribution to clients.  This permits the business logic in the custom COM classes to be separated from the interfaces used to consume them.  The assembly which contains only COM interface types must generate a type library (.tlb) when registered to be used.  In addition, the .NET class library project must be visible to COM and should define a unique type library guid.  Both properties can be set in the assembly information portion of the project properties dialog, or in the AssemblyInfo class for the project. 
  

Registering extensions

To use an ArcObjects extension with ArcGIS Server for .NET, the extension COM object must be registered on all the GIS server's container machines, and any appropriate component categories. Once this is done, the extension become available to any server application.

To register utility COM objects and server object extensions, some additional registration steps need to be taken. For more information, refer to the Application performance tuning section.