在一台机器上安装ArcGIS 10.1 for Server后，它还无法立即工作，必须将其加入site（的cluster）之中才行。首次登录manager时，也会询问创建新的site还是加入已有的site；如果已经加入site，登录manager则会显示该site的管理目录。那么机器自身是如何判断出自己是否已经加入site了呢？
　　依据就在于Program FilesArcGISServerframeworketc目录下的两个xml文件，config-store-connection.xml和machine-config.xml。加入site时会在本机创建这两个文件，退出site时会删除之。前者记录site的公用信息，后者记录本机在site中的信息，具体内容大家可以自己查看。
　　登录manager时会读取这两个文件，如果找不到，则认为自己没有加入site，会询问创建新site还是加入已有site；如果有这两个文件，会首先访问site的config-store目录验证其内容，合法的情况下就打开site管理目录。 如果在一台机器关机时，从site中将其删除，开机后会根据config-store-connection.xml内容去site的config-store目录中验证，发现自己已经被从site中移除后，会自己删除本机的这两个xml文件。
　　此外，如果你的机器已经加入了site A，但现在需要临时加入site B去做一些工作，就不用在admin api去删除site A了，只需将上述两个xml文件先转移到别的地方，然后登录manager，选择加入site B即可；之前site A的config-store内容可以保留，以便将先前挪走的两个xml文件复原后（需要重启ArcGIS Server服务），登录manager即可直接返回site A。

　　ArcGIS 10.1 for Server的安装目录中，都会内置一个tomcat（Program FilesArcGISServerframeworkruntimetomcat），无需单独的Web Server即可发布各种GIS服务（对于熟悉.NET的朋友来说，更省去单独安装和配置IIS的步骤）；AGS应用程序的端口号也由之前版本的80（ArcGIS Server for .NET）和8099/8399（ArcGIS Server for Java）统一到了6080上，比如http://localhost:6080/arcgis/rest/services和http://localhost:6080/arcgis/manager等。但对于内置的这个tomcat，我们并不能进行过多的操作，如果需要部署Web应用或通过别的端口来访问ArcGIS for Server的服务，这时就需要用到新的组件：Web Adaptor了。
　　Web Adaptor实际上是安装在Web Server机器上的一个Web应用程序，负责将Web Server接收到的GIS请求转发到ArcGIS Server site内的GIS Server机器上去。通过Adaptor这个桥梁，我们就能使ArcGIS for Server利用到企业级Web Server的诸多优势。根据安装帮助中的解释，安装Web Adaptor后主要有以下好处：

• 将单独的企业级Web Server集成到ArcGIS for Server的部署架构中来。可以将利用ArcGIS for Server服务的Web应用部署到Web Server上去；可以为site内所有的GIS Server提供不含有6080端口及arcgis等字样的统一访问入口点；
• 可阻止最终用户通过Web Adaptor的访问地址连接到ArcGIS for Server的相关管理程序。比如用户如果得知了类似6080端口的GIS服务访问地址，就可通过固定的url地址访问到Manger，Admin api等涉及到整个站点操作的内置应用。而Web Adaptor给我们提供了选项，可禁止用户通过Web Adaptor暴露出的GIS服务地址访问到这些管理应用。

　　此外，相对于site内的多台GIS Server机器，Web Adaptor还可以再次（除了Web Server集群外）起到负载均衡的作用，这在大并发量的情况下会比较有效。假设一个site内有n台GIS Server，它们所能处理的最大并发请求是1w个；根据ArcGIS for Server中p2p的实时通信架构，当我们将1w个并发请求发送到任一GIS Server的tomcat上时，GIS Server之间会自动以轮询（默认设置）的方式处理这些请求，GIS Server们完全可以及时响应；但1w个Web请求会首先使接收请求的这个tomcat过载，产生瓶颈。如果有了Web Adaptor，当这1w个请求到达Web Server（集群）时，Adaptor会将这些请求轮询发送到每个可用的GIS Server去，这样每个tomcat就只需支持1w/n个并发即可，可最大限度利用硬件资源。
　　以IIS中的Web Adaptor为例（经过Java高手验证WebLogic和WebSphere的Adaptor工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpubwwwrootarcgisWeb.config文件得知，IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll（在GAC目录中）里。这个dll里首先找到两个类：
　　一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。
　　此外，最重要的是一个叫AGSHandler的类，它实现了IHttpHandler接口：
　　发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的，而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引：
　　Web Adaptor接收到发到Web Server的GIS请求后，首先会读取初始化时保存的WebAdaptor.config配置文件并查看里面存储的GIS Server机器列表，如果读取失败或者机器个数为0，都会响应500的错误。如1所示；接下来会利用try里的TransferRequest方法将请求转发到具体的GIS Server（的tomcat）上去，如果转发的这个机器没有响应，则会在catch中将此机器利用MarkUnHealthy方法标记为不可用；而不论当前节点是否成功接收请求，TransferRequest方法中都会将_currentNodeIndex节点加一，保证下一个请求发送到下一台GIS Server上去，以实现轮询请求的事实：
　　最后来看看Web Adaptor是如何根据配置文件的间隔时间去追询标记为下线机器的状态，在机器上线后又将它们加回可用机器列表的：
　　可以看出，Web Adaptor检测到没有响应的机器后，除了标记其为不可用，也会同时启动一个定时器，此定时器逝去配置文件中的检测下线机器状态时间间隔（分钟）后，会立即将这台机器重新标记为可用，而不会去检测它事实上是否可用。判断机器是否真正可用的过程还是通过前面TransferRequest方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回…
　　大家可以想一想，整个过程是否有不合理的地方呢？