ArcGIS Server Inside TM 一
——Server概览
在这个系列中，我将会为各位提供一系列博文，该系列博文将专注于ArcGIS Server技术核心。希望各位多提宝贵意见。
纵观当今GIS技术发展热潮，服务式GIS与3D GIS无疑是当今最为广大用户群体推崇的技术。从目前市场上各大主流GIS厂商的产品体系中可以看出，每个厂商都在这两个方向使足了劲，新产品的宣传也着力倾向这两个方面。其实，服务式技术本身我们早已接触，例如我们平时使用的水、电、气，这些都是通过“服务”的方式为城市里每个人服务的，正是这种“服务”方式使得我们可以很简单的就能使用它们，只需要我们家里安装一些管线和设备，就能实现水、电、气的接入。使用服务最主要的就是需要遵循“服务接口”，在它们的使用当中，我们家里安装的设备都是遵循这些“服务接口”的。
将生活中的这种经验照搬到IT架构上来，便诞生了SOA架构，即面向服务的架构。由平台软件提供基础服务（如GIS中的地图浏览服务、地图查询服务、空间操作服务等），客户端只需要遵循它的标准，按照“服务接口”的契约去使用服务即可。如果世界上只有一家公司提供这种服务，大家都遵守它提供的“服务接口”或者叫服务契约将不会有任何问题。问题是各个厂商都研发自己的平台，发布独立的服务，这可就给客户端造成了极大的麻烦。
举个例子来说，如果某个城市有两家电力公司A和B，A给用户提供的是220v的电压，B给用户提供的是380v的电压，如果客户想要同时接入这两家公司的电力网络，那么客户接入线必须使用两套电缆线，并且需要安装变压器。试想一下，这是多么麻烦的事情。所以，SOA架构需要解决的首要问题就是服务的标准，各大IT厂商都遵循该标准就能实现异构平台的相互通讯，如基于j2ee开发的系统可以无缝与.net企业级应用程序通信。我想这可能是SOAP协议（基于XML消息）提出个根本原因。在详细分析SOA架构之前，我们先看看SOA架构的系统组成。
实现SOA架构最主要的技术之一就是WebService技术，SOA架构主要由服务提供者（平台服务提供方，如ArcGIS Server）和服务消费者（平台服务使用方，如ADF Web Application）组成。服务提供方主要提供各种服务，如ArcGIS Server提供的MapServer、GeoprocessiongServer、GeometryServer、GeodataServer等等，这些服务都被称为服务器对象，当ArcGIS Server服务管理器进程启动时(一个ArcSOM.exe的进程)，它会根据各种服务的配置文件创建一个或者多个服务器对象实例（其实就是由SOM管理器在SOC机器中创建了一个或者多个对象，这些对象实例是运行在SOC的机器上的），每个服务实例都暴露了一系列的方法，如MapServer的ExportMapImage、ComputeDistance、QueryFeatureData等方法。详细方法请参考ArcObjects的IMapServer接口。当然，在这里，我们把MapServer的ExportMapImage方法就定义为服务，客户端可以请求这个服务，获得地图图片。多次地图图片的请求和客户端绘制就构成了客户端丰富、平滑地图浏览体验。当然，使用缓存地图服务能够带来更好的用户体验，后面我会详细阐述。
获得一个基于Web Service的服务契约非常简单，只需要在服务的地址上加上?wsdl后缀即可。例如我们可以通过如下方式访问ArcGIS Server 发布的一个名叫arcgis的MapServer。http://zxb-esri:8399/arcgis/services/arcgis/MapServer?wsdl
知道一个服务的wsdl，我们就很容易获得WebService的本地代理，例如在.NET中添加Web引用就可以创建本地代理对象，本地代理对象提供了直接访问服务器对象方法的技术，客户端程序使用本地代理对象和使用其他对象没有任何区别，方法参数以及方法返回结果的序列化处理、HTTP传递都封装在.NET或者JAVA的框架之中，它们对客户端是透明的。
基于SOAP协议的WebService技术主要盛行在ArcGIS9.0\9.1\9.2的版本之中，但是在ArcGIS9.3的版本中，我们发现ArcGIS推出了基于REST（表述性状态转移）架构风格的服务。REST架构是有XX博士在2000年的博士论文中提出的，REST是一种架构风格，XX博士认为，在B/S系统中，各种服务器端的资源都可以通过一个唯一的URI来引用和访问，即服务器端的各种资源都是通过URI表述的，客户端对一个资源的访问过渡到另外一个资源（从一个资源的URL跳转到另外一个资源的URL）是通过状态转移来实现的。REST架构风格特别适合于构建服务式GIS。
原因主要在于：① REST是纯粹基于HTTP协议的，任何编程语言都支持，如JAVA、.NET、Flex、Javascript、Python、C\C++、VB等，所以很容易实现多语言平台；② REST架构风格消息主要基于JSON，JSON相比SOAP 的XML消息要更加精简；③ REST基于HTTP协议，因此可以使用HTTP缓存技术。所以，ArcGIS Server REST SDK的设计统一了多语言的RIA平台，如Flex、SilverLight、javascript。
既然有了REST SDK，是否就可以摒弃SOAP SDK呢，我觉得这是不可能的。为什么呢？因为ArcGIS Server REST SDK主要基于SOAP SDK 开发的，它是在SOAP SDK基础上按照REST HTTP架构设计做了二次封装。服务器端程序目前主流的技术主要是.NET和JAVA版本，所以ArcGIS Server有For .NET和For JAVA两个安装版本。实现REST架构的核心是要能处理各种HTTP请求，例如处理形如下面的HTTP请求：http://zxb-esri:8399/arcgis/rest/services/arcgis/MapServer/export?bbox=-223.9352882233539,-109.1292841402999,111.62342381635405,100.05715653830005
服务器程序（REST Application）接受到该请求，将该请求转发给ArcGIS Server ADF中封装的服务的Proxy，例如MapServerProxy，MapServerProxy有两个子类，一个是MapServerSoapProxy，主要基于SOAP消息实现Web服务器与GIS服务器通讯，一个是MapServerDcomProxy，主要基于DCOM 消息实现Web服务器与GIS服务器通讯。.NET中实现REST架构的核心是实现IHttpModule和IHttpHandler接口。即Asp.NET中的HTTP管道处理模型。Java中实现REST架构的核心是实现Filter和Servlet接口。.NET和JAVA都根据Web Application设计REST，在Web Application中访问ArcGIS Server ADF类库，最后由ADF类库调用底层COM接口实现各种服务的处理。我为什么要说ArcGIS的REST是按照Web Application来设计的呢，这是因为在REST的核心当中，其可以管理Session，可以实现HTTP缓存，这大大加速了动态地图服务获取的时间。这也是为什么我们每次修改服务需要清空REST缓存的原因。
暂时打住吧，一开始就说的这么细，我想大家可能觉得很难接受，留着后面再细说吧。我们把话题拉回来，前面主要讲到SOA架构的标准问题，我们引入了两个实现SOA架构的技术，一个是WebService技术，主要基于SOAP协议，XML格式消息；一个是REST技术，主要基于纯HTTP协议，使用JSON格式的消息。目前这两种标准是主流的IT标准，目前大多数GIS平台都支持这两种标准。只不过ArcGIS Server走在了最前头。谈GIS标准，我们不能不谈OGC啊，OGC劳苦功高，推出了一些标准WMS（WEB地图服务）、WFS（WEB要素服务）、WCS（WEB栅格数据服务）、WPS（WEB处理服务）。这些服务本身都是基于HTTP协议的，因此很容易在GIS平台中得到支持。WMS可能是大家最为熟悉的国际标准GIS服务，由于其本身对每个客户端请求都动态处理，访问空间数据、渲染地图图片，因此大都花费较长时间，很难得到普遍应用。近期，OGC又推出了WMS-C的服务，即缓存的WMS瓦片服务，从响应速度上得到极大提升。就目前来看，支持WMS-C的平台还很少。大都是一些开源GIS先驱。
关于服务式GIS，我们可以很容易引入云GIS。云计算目前炒得比较热，国内很多大型的商业机构和集团公司也在规划要建立自己的云计算平台。云计算是一种从分布式建设到集中式建设的过渡。有点类似数字城市或者数字省份的共享服务平台，从过去的各个委办局独立建设系统过渡到由城市信息办、城市规划局、省测绘局等单位牵头集中建设共享服务平台，提供基础地理信息服务，供各个厅局、委办单位使用。他们只负责基础地理信息的维护，各个委办单位可以使用该服务平台结合自己的业务数据搭建各自独立的系统，还可以将他们搭建的系统的服务地址注册到共享服务平台上，以供其他委办单位调用、查询。这种模式能够带来很大的好处，一方面避免了重复投资，催进了各个委办局各类系统互连，为城市综合应急指挥调度管理打下了坚实的基础；另一方面集中管理，权责分明，保证了基础数据持续有效更新，能够真正使得各个委办单位的系统发挥作用，因为过去委办局各类系统因为缺乏有效的数据更新机制导致系统成了摆设。云GIS可以提供云端GIS服务计算能力，可以很容易在企业里得到应用，例如电信网络资源信息共享平台，电力网络资源信息共享平台等。值得高兴的是，目前ArcGIS已经全面支持云计算，是目前国际唯一一个支持云计算的平台，即Saas。
好了，我们再侃侃三维GIS吧，二维GIS技术逐渐走向成熟和稳定必然趋势三维GIS技术蓬勃的发展。为什么三维GIS如此受人追捧，我想最主要的原因是三维的表现更加适合人类的认知水平，人本身就生活在三维的空间当中。二维GIS强制将地理空间通过制图综合技术扭曲到二维笛卡尔平面，必然带来认知水平上的跳跃。其实，三维GIS发展也有10几年的历史，为什么到现在还如此追捧，我想可能还是受制于技术瓶颈。如果不是GoogleEarth的推出，GIS行业的大佬们可能也不会重金打造各种Earth平台。三维GIS进步因一方面要满足仿真、速度、用户体验的提升，另一方还要满足三维海量数据管理、三维分析、二三维数据一体化等GIS问题，所以很难得到技术突破。
作为本次博客的小结，我再侃侃自己对GIS发展方向的一点理解，与各位分享。我把GIS技术的发展趋势总结为这样几个方面：（1）传统的基于地学的GIS理论技术的技术化、产品化，这是GIS的根基和血液，GIS的目的就是对地理现象的建模和分析。这也是地学工作者为什么会把GIS当做工具来辅助研究各种地理现象，或者更加准确的说应该是空间地学规律。人类的各种活动、自然界的各种现象大都与空间相关，因此，可以借助GIS方法挖掘各种不同现象的本质规律，从而辅助人类决策活动。例如，区域洪水爆发因子大都与当地的地形要素、土壤因子、植被覆盖、气候（降雨）、周边环境因素等空间相关，建立这些因子之间的相关关系以及对研究他们对洪水的贡献率是我们利用GIS工具进行层次分析常用的方法。（2）紧跟主流IT方向发展，如SOA架构、REST架构、云计算、物联网，GIS已经走出实验室，不仅仅是科学家手中的利器，已经成为人类社会资源、设施管理的一种方法，它已经走向政府管理层，因其本身是基于空间位置的技术，人类大都的出行参考都基于位置信息，所以它和普通用户大众密不可分。（3）三维、四维数据一体化管理，三维空间分析、三维高效可视化、三维海量数据管理和显示技术等。三维技术一直都是人们的宠儿，就像我们爱玩3D版的游戏一样。另外，基于三维的空间分析功能能够大大提高分析的精度，提高人类的认识水平。（4）数据模型的标准化，或者说会形成各行各业的标准数据模型。国内建设GIS系统，很少会认真研究行业标准和行业业务，从而设计数据模型，业务规则都是通过软件来实现。如果项目一开始就认真研究数据模型，将大多数规则用数据模型本身解决将极大提高系统的可用性。例如形成标准电力数据模型、供水数据模型、长输管道数据模型、水利数据模型等。这样这个GIS开发商都基于这些模型进行系统开发，将极大提高系统后期的集成、互联和扩展。