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可以通过Local和Internet两种方式连接，Local连接是在客户端利用AO连接到SOM的，而Internet连接是在客户端利用本地代理连接到Web service端，本地代理是指在本地开发环境(.net,java)中独立管理的对象。
Local方式的连接提供了利用AO API和SOAP API操作services,即server objects和server context，如果需要永久改变server object的状态(stateful)只能利用AO API,当然也就需要使用Local方式连接,Local连接需要提供server机器名和需要连接的service服务名，并且此连接必须利用agsusers或agsadmin组中的用户添加Identity验证；Local data sources使开发者可以通过server context操作细粒AO，即可以在Web ADF application中使用丰富的AO功能，例如编辑图层、网络分析等。如果以编程方式使用Local data source，利用数据资源库ESRI.ArcGIS.ADF.Web.DataSources.ArcGISServer,通过类MapFunctionality可以得到map description;而MapResourceLocal也可以通过ServerContextInfo.ServerContext得到context。
Internet方式连接仅提供利用SOAP API以通过WSDL来访问和操作services的能力，而所有的service也是无状态的。对Internet data source来说context是无效的，当然也没有细粒AO的功能，此种连接Indentity验证不是必须的，因为ArcGIS Server Web services可以使用基于web server的验证，即在一个web application中多个internet数据源可以采用各自不同的安全验证方式。对Internet方式连接的服务推崇使用pool类型，而non-pool类型只对单个用户服务，并且每次用完后都得显式的进行销毁。如果以internet方式连接并使用non-pool类型服务，每一次地图操作过程都会创建和销毁一个进程，这样将大大影响你的工作效率。如果以编程方式使用Internet data source,利用数据资源库ESRI.ArcGIS.ADF.Web.DataSources.ArcGISServer，此库中包含functionality类和其他一些用于在无状态下使用的细粒任务类。
总之，客服端连接server的方式可以按如下规则选取：
1、Internet连接方式使用soap api并且利用url连接到web service端，internet连接可以运用到internal(LAN)和internet网。
2、Local连接方式即可利用AO API也可以利用SOAP API，根据客服端的需要，而Local连接仅能用于局域网内。
ArcGIS Server是一个服务器端的AO组件集，我们对AS的编程操作，都意味着对远端服务器上对象的操作，这是一个很大的不同。以使用AE开发成为为例，我们新建一个对象，使用的是new关键字，这是在本地机器上新建一个对象的操作，这个操作一直封装在一个进程中。而AS的开发，意味着本地的一个对象，必须调用远端的一个对象来实现某种功能，本地的操作进程与远程的操作进程实际上是两个不同的进程，如何在两个进程之间进行通讯呢？
AS使用了分布式对象技术DOT来处理这个问题，ADF提供了一系列所谓的ArcObjects proxy对象，一个proxy对象就是一个远端对象在本地的引用，它的接口和方法与proxy对象的远端对象完全一致，这样，我们对proxy对象的操作，就会直接影响到它代理的远端对象。
我们说过，AS是一个三层模型，其中通过浏览器访问的WEB程序和WEB服务都是放在第二层，即WEB服务器上的，为了让WEB服务器上的程序能够通过操作AO组件来与GIS服务器上的AO组件进行交互，我们需要在WEB服务器上安装ADF，如果是发布的话，安装ADF Runtime就行了。因此，AO的proxy对象都是安装在web服务器上的。
WEB程序或WEB Service使用的组件是Server API，这些API分为三种：Server API，.NET WebControl和Java WebControl。
当一个WEB应用程序连接到GIS服务器的时候，WEB程序使用的Server API将调用一个代理对象去访问远程服务器上的SOM对象，并通过SOM对象寻找到SOM管理的Server Object对象。它使用了分布式对象技术DOT。这个过程是这样的：
IGISServerConnection pGISServerConn=new GISServerConnectionClass();
pGISServerConn.Connect("nbjbt");//连接到GIS服务器
IServerObjectManager SOM=pGISServerConn.ServerObjectManager;//找到GIS Server上的SOM
IServerContext pServerContext=SOM.CreateServerContext("nbserver","MapServer");//通过SOM创建一个服务器对象的上下文
IServerObject pSO=pServerContext.ServerObject; //从上下文对象找到服务器对象
IMapServer pMapServer=(IMapServer)(pSO);//使用IMapServer接口来访问服务器对象
。。。。。。
pServerContext.ReleaseContext();//释放服务器对象的上下文，即关闭该进程
ServerContext本质上是一个GIS服务器上的进程，它也是我们服务器端编程的起点。因此，我们是通过CreateServerContext命令在服务器端上创建的，而不是使用NEW关键字在本机上创建。我们是通过这个进程在访问服务器对象nbserver。我们的工作也是在这个进程中完成的。
既然是在一个进程中编程，那么，在这个进程中新建一个对象使用的关键字就不是NEW了，而是下面的方式：
新建对象 pSC.CreateObject("esriGeometry.IPoint")
将一个对象放入一个进程 pSC.LoadObject(pPt)
将一个对象放在进程的字典中pSC.SetObject("a",pPt)
将对象从进程字典取出pNewPt=pSC.GetObject("a")
ServerObject的池化和非池化模式
当我们访问一个服务器对象Server Object的时候，这个对象是已经存在的呢？还是在访问时新建的？都有可能，这取决于我们如何选择。如果我们选择共享池化模式，则在SOM启动的时候，SOM就建立了几个SO供外界访问，一个SO被A请求访问后，被释放回共享池中，还可以下次被B访问使用，因此，SO将可以被多个用户访问。如果是非共享池模式，当一个请求访问时，SOM专门为它新建一个SO。
这样，在池化模式下，访问与SO的比例不是1：1，它支持更多的用户；而非池化模式就是1：1的，它支持的用户比池化模式少。
SO放在什么地方，对，它就放在一个Server Context中，即一个进程中。一个访问连接到SO，是一个例程，这个例程是放置在一个进程中的。而对于这个进程的特征，我们还需要进一步设置，即进程的孤立性。如果Server Context是高孤立的(high isolation)，那么一个进程中只能放置一个例程，这样保障了安全性；如果是低孤立的，四个访问连接的例程都可以放置在一个进程中，它的特点是节约资源。至于如何设置，就有必要考虑我们的硬件设备了