ArcGIS 10.1 for Server的安装目录中，都会内置一个tomcat（Program Files\ArcGIS\Server\framework\runtime\tomcat\），无需单独的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工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpub\wwwroot\arcgis\Web.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方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回…
大家可以想一想，整个过程是否有不合理的地方呢？
WebGL Globe开源代码在这里，我做了两个小例子。一个是国内（台湾省数据暂缺）及美国每个县（郡）的人口数据，由于数据来源，统计方法不同，例子中两者间的绝对值没有可比性，可比性仅限于各自国家之内。美国人口最多的地方是Los Angeles，国内人口最多的地方是广东普宁及安徽临泉。可看出国内西部地区每个县面积较大，但人口相对少。国内数据来源于同学写论文时千辛万苦的收集（据说需要保密），美国数据是Esri自带的。 
建议在Chrome或IE10浏览器下观看。
命令行方式输入'start nginx'启动Nginx，然后发送请求到192.168.0.69机器的80端口： 
看到请求被转发到了247机器的IIS 7.5上，再次刷新， 
请求已经轮询到了244机器的IIS 6.0上。最后通过69机器来访问ArcGIS Server的Services Directory， 
此时Nginx会以轮询的方式访问247和244两台机器的Web Adaptor。 
一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。 
发送到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方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回… 
博文
