In this topic
- ArcGIS Server APIs
- ArcGIS Server APIs in the Web ADF
- Value objects
- Proxy objects
- Using ArcGIS Server Proxy and Value objects in the Web ADF
- Working with the Web ADF Map control
- Managing server context
ArcGIS Server APIs
As a developer, you can work with ArcGIS Server services using the following application programming interfaces (APIs):
- ArcGIS Server ArcObjects API
- ArcGIS Server Simple Object Access Protocol (SOAP) API
The ArcObjects API utilizes the ArcObjects primary interop assemblies (PIAs) and object libraries on the client to work with ArcObjects remotely on the geographic information system (GIS) server. It is only available for ArcGIS Server services accessed directly via the server object manager (SOM) and is designed for stateless and stateful interaction. This API exposes the comprehensive and rich functionality available in ArcObjects.
The SOAP API is an Extensible Markup Language (XML) structured language for communicating with ArcGIS Server services based on the SOAP standard. Server objects and some server object extensions have a defined set of SOAP tags and attributes they can process to handle SOAP requests and generate SOAP responses. Since this capability is enabled at the server object level, as a developer you can interact with a server object using SOAP without using a Web service.
ArcGIS Server Web services expose this capability via a Web service endpoint, but the SOAP request and response are still handled by the server object or extension directly. The easiest way to work with the SOAP API is to use a SOAP toolkit to generate proxies and value objects in the native development environment. Instead of managing SOAP strings directly, you can use the native proxy and value objects to work with ArcGIS Server services via a Web service endpoint or via the SOM (server object). The SOAP API is designed to be shallowly stateful, meaning the client application is responsible for maintaining state, not the server.
ArcGIS Server APIs in the Web ADF
The Web Application Developer Framework (ADF) contains ArcGIS Server implementation classes and supporting content in the ESRI.ArcGIS.ADF.ArcGISServer.dll and ESRI.ArcGIS.ADF.Web.DataSources.ArcGISServer.dll libraries. The ESRI.ArcGIS.ADF.Web.DataSources.ArcGISServer.dll assembly contains the Web ADF Common API implementation classes for ArcGIS Server local and Internet data sources. ArcGIS Server local data sources connect to the ArcGIS Server SOM and work with a server object directly. ArcGIS Server Internet data sources connect to an ArcGIS Server Web service endpoint. Both are implemented in the Web ADF using the ArcGIS Server SOAP API.
A number of base classes (for example, MapResourceBase and GISDataSourceBase) define shared members for both ArcGIS Server data source types, but different implementation and proxy classes are used to initiate and manage the connection with an ArcGIS Server service. In addition, an ArcGIS Server local data source can work with server context to create and work with objects on the server via ArcObjects Component Object Model (COM) proxies on the client (same as 9.0 and 9.1). See the following illustration that shows the components of the MapResourceBase and GISDataSourceBase classes:
The ArcGIS Server SOAP API can be utilized via a set of value objects and proxies available in the ESRI.ArcGIS.ADF.ArcGISServer.dll assembly. Both data source types share the stateless based Value objects, but use different proxies to manage interaction with the server using SOAP. ArcGIS Server local data sources use Distributed Component Object Model (DCOM) proxies to communicate with a server object directly. ArcGIS Server Internet data sources use Web service proxies to communicate with an ArcGIS Server Web service endpoint.
Value objects
Value objects are native objects on the client that use properties to store values. Value objects are native to the client environment; therefore, in .NET, they are .NET objects and in Java, they are Java objects.
Proxy objects
Proxy objects manage communication with a remote resource. Proxy objects can use Value objects to define properties of an action, often by serializing Value objects in a format the remote resource understands (for example, SOAP). The proxy object initiates the action and manages the results by deserializing the response and creating the appropriate Value object to work with on the client.
A Web Service Description Language (WSDL) can be used to generate Value objects and a Web service proxy object. A Web service toolkit is often used to generate native objects from WSDL defined Value objects and proxies. For example, Visual Studio 2005 and the .NET software development kit (SDK) include the wsdl.exe process to accomplish this task. See the following illustration that shows the client and server application:
-
ArcGIS Server Proxy and Value objects—Each ArcGIS Server service type maintains a separate and distinct WSDL that describes how to work with the service via SOAP. The Web service proxy works with the ArcGIS Server Web service in a stateless manner. It is up to the developer to manage state on the client, known as a shallowly stateful application. On the client, the ArcGIS Server Web service proxy manages SOAP serialization and deserialization for you. On the Web server, the ArcGIS Server Web service manages server context for you, via a .NET Hypertext Transfer Protocol (HTTP) handler or Java servlet. From the Web service perspective, all communication is stateless; therefore, it creates server context when processing an HTTP request and releases context when the HTTP response is sent to the client.
ArcGIS Server Value objects can be used with an ArcGIS Server server object, but the communication is more complex since COM proxies are now required. The WSDL does not define a DCOM proxy to work with a server object directly, as a result, the developer will need to manage the communication process. If a server object implements the IRequestHandler interface, use the HandleStringRequest method to send and receive SOAP requests and responses. The developer will be responsible for initiating the connection and serialization and deserialization SOAP. If Value objects are used, manage their serialization and deserialization. The Web ADF provides a DCOM proxy and set of supporting classes to do this. See the following illustration:
Using ArcGIS Server Proxy and Value objects in the Web ADF
As a shallowly stateful application, the Web ADF controls and Common API use the inherently stateless Value and Proxy objects to maintain state in session on the client. An ArcGIS Server local data source uses a DCOM proxy to serialize Value objects to SOAP and work with a server object via the IRequestHandler interface. For example, to work with an ArcGIS Server local data source in a Web ADF Map control, a MapResourceLocal instance uses the MapServerDcomProxy class to communicate via SOAP with an ArcGIS Server server object.
An ArcGIS Server Internet data source uses a Web service proxy to serialize Value objects to SOAP and work with a Web service endpoint over HTTP. For example, to work with an ArcGIS Server Internet data source in a Web ADF Map control, a MapResourceInternet instance uses the MapServerProxy class to communicate via SOAP with an ArcGIS Server Web service. See the following illustration:
Working with the Web ADF Map control
In the multi-source Web ADF, each Map control creates a MapFunctionality to work with a Value object MapDescription on the client. The MapFunctionality uses this MapDescription to interact with the mapping capability of the ArcGIS Server map server object, such as drawing a new map image. The MapFunctionality MapDescription stores the Map control's state, while the MapResourceLocal MapDescription stores resource state, which can be shared by any MapFunctionality that uses the resource.
By default, each MapFunctionality uses its own MapDescription to manage state. In either case, the MapResourceLocal instance uses the MapServerDcomProxy class to create server context and manage stateless interaction with the map server object via the IRequestHandler interface. MapResourceLocal also provides access to fine-grained ArcObjects on the server. A reference to the MapServer object via a COM proxy is available via the MapServer property. Server context is available via the ServerContextInfo class. For more information, see Data source-specific APIs.
Managing server context
ArcGIS Server local connections, and local data sources and resources in the Web ADF, work directly with a server object via server context. Services can be deployed as pooled or non-pooled. When working with ArcGIS Server server objects as resources in Web ADF resource managers, server context creation and management is handled for you. Explicitly releasing server context for pooled server objects is not required (the Web ADF handles it for you). However, if working with non-pooled server objects, server context needs to be explicitly released. Until the server context is released, the server object instance remains in use and is unavailable for other clients.
The following are the options for explicitly releasing server context on a non-pooled server object in a Web ADF application:
- Server context is released explicitly during the session—This option is not frequently used because server context is usually needed for the duration of the user session. Releasing context is a simple one line operation. The servercontext variable is a type of ESRI.ArcGIS.Server.IServerContext. See the following code example:
servercontext.ReleaseContext();
-
Server context is released at the end of the session—This option involves adding the necessary code to release server context to the OnSessionEnd (Session_End) event for a Web application. This code executes when the session timeout for the Web application is reached. The default timeout for an ASP.NET Web application is 20 minutes. This value can be modified, but it changes the session behavior for the Web application. For more information, see Time-out settings in the Web ADF. See the following code example that shows the Session_End event:
protected void Session_End(Object sender, EventArgs e)
{
IServerContext context;
for (int i = 0; i < Session.Count; i++)
{
context = Session[i] as IServerContext;
if (context != null)
{
context.ReleaseContext();
}
}
Session.RemoveAll();
}
- Server context is released when the Web browser is closed or the user navigates from the page—In ASP.NET 2.0, the callback framework can be leveraged to provide a more intuitive and performing solution for releasing server context. To implement this solution, handle the onunload event of the form on the Web page to generate a callback to the Web application. The callback iterates through the existing ArcGIS Server map resources and explicitly releases context for non-pooled services.
Server context for a non-pooled service is released with the process hosting a reference to the context when terminated. However, with an ASP.NET Web application, this usually means terminating the ASP.NET worker process shared or managed by Internet Information Services (IIS), which is often not an option in a production environment.
See Also:
Map controlData source-specific APIs
Time-out settings in the Web ADF