ArcGIS Server connection method

ArcGIS Server Connections
ArcGIS Server services can be made accessible via Local and Internet connections. local connections are established by using ArcObjects within a client application to connect to the Server Object Manager (SOM ). internet connections are established by using native objects within a client application to connect to a Web service endpoint. "Native object" means an object managed solely in the native development environment, like. NET or Java. local connections offer the ability to work with services, namely server objects and server context, using the ArcObjects API and the soap api. stateful changes to a service (server object) can only be made using the ArcObjects API and thus require a local connection. internet connections only offer the ability to work with services using the soap api, so all service interaction is stateless. in general, ArcGIS Server connections in client applications can be summarized as follows:

Internet connections always use the soap api and define a connection using a url to a Web service endpoint. Internet connections can be used by both internal (LAN) and external (Internet) clients.
Local connections always use the ArcObjects API and may use the soap api, depending on the client application. connections are defined using the name of the SOM machine with optional identity credentials. local connections can only be used by internal (LAN) clients.

ArcGIS Server can be connected through Local and Internet. Local connections connect to SOM using AO on the client, while Internet connections connect to the Web service using Local proxy on the client, local proxy refers to the Local Development Environment (.. net, java.

Local connections allow you to use the ao api and soap api to operate services, that is, server objects and server context. If you need to permanently change the state of server objects (stateful), you can only use the ao api, of course, you also need to use the Local method to connect. The Local connection requires the server machine name and the service name to be connected, and the connection must use the user in the agsusers or agsadmin Group to add Identity verification; local data sources allows developers to operate fine-grained AO through server context, that is, they can use a wide range of AO functions in the Web ADF application, such as editing layers and network analysis. If you use Local data source programmatically, use the data resource library ESRI. arcGIS. ADF. web. dataSources. arcGISServer, map description can be obtained through MapFunctionality; while MapResourceLocal can also be obtained through ServerContextInfo. serverContext to get the context.

Internet connection only provides the ability to use SOAP APIs to access and operate services through WSDL, and all services are stateless. For Internet data source, context is invalid, and of course there is no fine-grained AO function. The Indentity verification of this connection is not required, because ArcGIS Server Web services can use web server-based verification, that is, multiple internet data sources in a web application can adopt different security authentication methods. The pool type is recommended for Internet-connected services, while the non-pool type only applies to a single user service, and must be explicitly destroyed after each use. If you connect to and use non-pool services over the internet, each map operation will create and destroy a process, which will greatly affect your work efficiency. If you use Internet data source programmatically, use the data resource library ESRI. arcGIS. ADF. web. dataSources. arcGISServer, which contains the functionality class and other fine-grained task classes for stateless use.

In short, you can select the connection mode of the client to the server according to the following rules:

1. Internet connection uses soap APIs and uses URLs to connect to the web service. internet connections can be applied to internal (LAN) and internet networks.

2. The Local connection method can use the ao api or the soap api. The Local connection can only be used in the LAN according to the customer service needs.

ArcGIS Server is a Server-side AO component set. Our programming operations on AS all mean operations on objects on the remote Server. This is a big difference. Using AE as an example, we create an object with the new Keyword. This is an operation to create a new object on the local machine. This operation is always encapsulated in a process. The development of AS means that a local object must call a remote object to implement a certain function. The local operation process and remote operation process are actually two different processes, how can we communicate between two processes?

AS uses the distributed object technology DOT to solve this problem. The ADF provides a series of so-called ArcObjects proxy objects. A proxy object is a local reference of a remote object, its interfaces and methods are exactly the same as the remote objects of the proxy object. Therefore, our operations on the proxy object will directly affect the remote objects of the proxy.

We have said that AS is a layer-3 model, where both WEB programs and WEB services accessed through Browsers are placed on the second layer, that is, WEB servers, to allow programs on the WEB server to interact with the AO component on the GIS server by operating the AO component, we need to install the ADF on the WEB server. If it is released, install the ADF Runtime. Therefore, AO's proxy objects are installed on the web server.

WEB programs or WEB services use Server APIs. These APIs are divided into Server APIs,. NET WebControl and Java WebControl.

When a WEB application is connected to the GIS Server, the Server API used by the WEB application calls a proxy object to access the SOM object on the remote Server, and find the Server Object managed by SOM through the SOM Object. It uses distributed object technology DOT. This process is as follows:

IGISServerConnection pGISServerConn = new GISServerConnectionClass ();
PGISServerConn. Connect ("nbjbt"); // Connect to the GIS server
IServerObjectManager SOM = pGISServerConn. ServerObjectManager; // locate the SOM on the GIS Server
IServerContext pServerContext = SOM. CreateServerContext ("nbserver", "MapServer"); // create the context of a server object through SOM
IServerObject pSO = pServerContext. ServerObject; // locate the server object from the context object
IMapServer pMapServer = (IMapServer) (pSO); // use the IMapServer interface to access server objects
......
PServerContext. ReleaseContext (); // release the context of the server object, that is, close the process.

ServerContext is essentially a process on the GIS server, and it is also the starting point of Server programming. Therefore, the CreateServerContext command is created on the server, instead of the NEW keyword. We access the server object nbserver through this process. Our work is also completed in this process.

Since it is programmed in a process, the keyword used to create an object in this process is not NEW, but the following method:
Create an object pSC. CreateObject ("esriGeometry. IPoint ")
Put an object into a process pSC. LoadObject (pPt)
Put an object in the process dictionary. pSC. SetObject ("a", pPt)
Retrieve the object from the process dictionary pNewPt = pSC. GetObject ("")

Pooling and non-pooling modes of ServerObject

When we access a Server Object, this Object already exists? Or is it newly created during access? It is possible, depending on how we choose. If we select the Shared Pool Mode, at the startup of SOM, SOM will establish several SO for external access. After one SO is accessed by A request, it will be released back to the shared pool, it can be accessed and used by B next time. Therefore, SO can be accessed by multiple users. In non-Shared Pool Mode, when a request is accessed, SOM creates a SO for it.

In this way, in pooled mode, the ratio of access to SO is not, and it supports more users. Instead, the pooled mode is, and it supports fewer users than the pooled mode.

SO is placed in a Server Context, that is, a process. An access connection to SO is a routine, which is placed in a process. We need to further set the features of this process, that is, the isolation of processes. If the Server Context is highly isolated, only one routine can be placed in a process to ensure security. If the Server Context is low, the four access connection routines can be placed in one process, which features resource saving. As for how to set up, it is necessary to consider our hardware devices.