ArcGIS Server Inside 系列 （二）——Server组件

ArcGIS Server Inside ^TM 二

                         ——Server组件，SOM和SOC

在上一篇中，我主要给大家简单系统的阐释了一下ArcGIS Server技术以及GIS技术的发展趋势。在本节中，我将重点给大家介绍ArcGIS Server的各个组件、功用及它们之间相互的关系。我认为这些理论知识的学习对于一个搞ArcGIS Server系统开发的人员以及GIS项目经理来说都是非常有用的，相信这系列博文是对得起您宝贵时间的。

众所周知，ArcGIS主要基于ArcObjects组件模型构建，ArcObjects是一组微软COM组件，它是ArcGIS核心数据模型、制图表达、空间分析算法的核心实现。ArcObjects由一系列面向对象的编程元素，如接口、类、枚举、事件等组成。“针对接口编程”是COM编程核心的概念之一，其实也是面向对象的一种设计原则。正因为如此，我们在编写ArcGIS Engine、ArcGIS Server ArcObjects API程序时才会与ArcObjects的各种接口进行交互。例如，我想实现一个能够同时绘制Shapefile、Erdas Image图像的图层，并将绘制结果保存为bmp的图片，最后将它通过网络传递给客户端的程序，我该如何实现它呢？其实，我们可以把它分解为三个组成部分：1）创建一个Map（地图，地图是由一个或者多个图层组成，每个图层都是一个数据源的符号化表达）对象，并将Shapefile、Erdas Image等数据源作为图层添加到Map中，当然，您也可以设置不同图层的显示样式；2）将该Map绑定到一个视图设备上，其实就是将该Map与一个设备建立关联，并获得设备描述表句柄，然后使用IExportor接口将它输出到一个位图图片中；3）使用JAVA或者.NET技术封装成一个Web Service类，在该类中定义一个输出图片的ExportMap的方法，在该方法的实现中调用上面两步的程序，最终图片可以多种形式返回，如使用一个URL地址，它指向硬盘中图片的路径，或者直接返回图片的字节流。在这几个步骤中，其实处处都与ArcObjects接口打交道，你会发现自己在编码时会经常从一个接口跳转到另外一个接口，即接口查询。为什么要进行接口跳转呢，因为你所访问的对象方法都是定义在不同的接口中，你要调用这些方法就必须强制转换到那个接口下才行。比如MapClass类实现了IMap接口以及IActiveView接口，你要从IMap的接口变量访问IActiveView接口的方法就必须进行强制转换，代码形如：

IMap pMap=new MapClass();

pMap.AddLayer(createFeatureLayer());

IActiveView pAV=pMap as IActiveView;

pAV.Refresh();

到这里，很多读者可能会觉得有点糊涂，博主你不是要讲ArcGIS Server吗，怎么开始讲ArcObjects编程了。针对这点，我深有体会，因此与大家分享。其实不用我说，我想大多数读者都已经知道当前主流的Web GIS开发方式是采用RIA方式，因其速度快、体验好深得客户的偏爱。搞过RIA开发的人会发现，ArcGIS Server开发其实非常简单，比如使用Flex开发，ArcGIS Server Flex API一共才不到100个类，对于一个搞过GIS开发的人员来说，它的类图大概扫一眼就知道其编程模式了，再通过一两个示例代码很快就能上手。服务端使用ArcGIS Server发布几个地图服务，对于地图浏览、地图要素查询、路径分析等直接可以实现，再稍微复杂点的，使用ModleBuilder建立一个模型，发布成GeoprocessingService服务一切完事。似乎ArcGIS Server开发就是简单编写一些客户端代码。当然，如果读者您以前使用过ArcGIS Server ADF开发方式，特别是使用ADF开发Web Service，我觉得您很幸运，因为您了解了ArcGIS Server服务器端编程。在后面的博文中，我会使用单独的篇幅来描述如何使用ArcGIS Server ADF开发Web Service，我不会介绍ArcGIS Server ADF Web Application，即将淘汰的技术不提也罢。

ArcGIS Server虽然核心基于ArcObjects技术，但是它在上层封装了一系列粗粒度的COM接口，这些接口通过DCOM机制能够实现跨进程调用。例如IMapServer接口主要用于操作MapService，它的ExportMapImage就是我们在Flex中使用ArcGISDynamicMapService浏览地图时调用的主要方法。通过查看IMapServer接口的实现类我们发现，它还实现了ITiledMapServer接口，该接口的GetMapTile方法就是我们在Flex中使用ArcGISTiledMapService进行地图浏览时系统在ArcGIS Server后台调用的主要接口。除此之外还有IGeocodeServer、IGeometryServer、IGeometryServer、IGPServer、IImageServer等所有这些服务式COM接口在内部封装了细粒度的ArcObjects接口。（后文我会给大家演示如何使用ArcObjects接口从底层实现一个MapServer，我还会演示如何实现池化和非池化技术）我经常听到一些朋友抱怨ArcObjects接口封装的粒度太细，导致开发难度加大，我想说的就是：1）粒度太细能够增大系统的灵活性，便于扩展，ArcObjects的扩展性是有目共睹的，不但在地图展示层（如ILayer、ISymbol、IRenderer接口）很容易实现扩展，而且支持Geodatabase的扩展。这是一项伟大的设计，Geodatabase数据模型扩展了传统矢量、栅格数据模型，它不仅是一种存储机制，而且能够定义数据模型的行为，即通过规则（拓扑规则、关系规则、连通性规则、自定义类扩展机制的规则）、子类、域等实现对象行为以及维护数据库的完整性；2）如果粒度封装的过粗，开发难度必然大大降低，这样势必造成GIS开发门槛太低，技术人员没有竞争力。我一开始学的MapObjects，后来学ArcObjects，大学临毕业时学的MapX，我学ArcObjects花了一年时间入门，学MapX用了不到一个星期就知道编程思路，并基本能熟练编码了。我打个不太恰当的比方，学ArcGIS，其实不仅仅是学它的接口编程方法，而是学ArcGIS软件设计的理念，学它的数据模型以及它对GIS的理解。这种思想一旦形成，就像打通了学习GIS的仁督二脉，学什么都非常快。

好像说到现在都没说到正题上，希望读者保持耐心，待我叙叙道来。

ArcGIS Server主要由两个重要的组件组成，一个是SOM，全名叫ArcGIS Server Object Manager，一个是SOC，全名叫ArcGIS Server Object Container。从名称我们也可以很容易猜测的出它们的意思。在讲他们之间区别和联系之前，我首先讲一下ArcGIS Server的部署架构，我们最经常使用的部署就是单层部署架构，就是Web服务器、GIS服务器（也叫应用服务器）和数据库服务器在一台物理计算机上。如果将数据库服务器单独拿出来部署，我们称之为双层部署架构。如果再将GIS服务器单独部署，也就是Web服务器、GIS服务器和数据库服务器使用三台计算机部署，这就是三层部署架构。（详细信息请参考《ArcGIS系统设计策略》）

那么ArcGIS Server的SOM和SOC一般如何安装呢，第一种我们可以将其安装在一起，也可以将其分开部署，常见的部署方法就是将SOM安装在Web服务器上，SOC部署在应用服务器上。SOC通过SDE DC（直连）机制连接ArcSDE数据库服务器。不管是单层部署、双层部署还是三层部署都很容易出现单点故障，就是整个系统中不管是Web服务器、GIS服务器以及数据库服务器出现宕机都会导致系统无法运行。因此，在实际项目中，我们大都采用高可用性部署策略，避免单点故障。例如，首先使用两台物理Web服务做集群，在这两台Web服务器上安装SOM组件，并使用四台SOC物理计算机，每个SOM都挂接到这四个SOC，实现SOM的负载均衡，数据库也使用两台物理计算机使用数据库集群软件，如Oracle RAC。这种部署策略能够大大提高系统的可用性，缺点就是两台Web服务器上SOM配置的内容完全一致，存在一定的冗余。详细的部署方式请参考我的博客上的《ArcGIS Server 性能优化与高可用性部署》文档。

这里，我详细介绍一下SOM和SOC的关系。我们安装ArcGIS Server组件后会发现在计算机服务列表中多出两个服务，一个是ArcGIS Server Object Manager，一个是 ArcGIS SOC Monitor。如果您安装是ArcGIS Server for Java版本，还会有一个ArcGIS Server Manager Service服务，如下图所示：

 

 

其中，ArcGIS Server Object Manager即服务管理器服务，对应进程中的ArcSOM.exe，由ArcGISSOM账户启动。ArcGIS SOC Monitor即SOC监控进程，该进程负责监控SOC进程状态，该服务由ArcGISSOC账户启动，当SOC与SOM连接中断时，该服务会让SOM重启SOC进程。ArcGIS Server Manager Service是ArcGIS Server for Java内置的Tomcat服务。例如我们访问http://localhost:8399/arcgis/rest/service就是通过该服务承载的Rest Application或者http://localhost:8399/arcgismanager进入的ArcGIS Manager页面。我们可以通过http://localhost:8099/manager/html地址进入该Tomcat管理页面，启动或者停止由该Tomcat管理的Web Application，例如停止REST Application，在这里，我们也可以看出ArcGIS Server REST其实是一种Web Application，因此其可以管理Session,它对很多数据都做了http缓存，这就是我们为什么每次更改ArcGIS Server的服务状态时需要重启该Server并且需要清空REST缓存的真正原因。您可以通过http://localhost:8399/arcgis/rest/admin 进入REST管理器页面清空REST缓存。在ArcGIS Server 9.3\9.3.1时，安装ArcGIS Server会发现进程中有两个ArcSOC.exe的进程和一个ArcSOM.exe的进程，两个ArcSOC.exe进程一个用于清空ArcGIS Server的缓存目录临时动态地图图片文件，即您安装ArcGIS Server指定的arcgisserver缓存目录文件，一个用于记录ArcGIS Server的日志，该日志主要在%ArcGIS Server Home%\server\user\log下。ArcGIS 10使用一个ArcSOC.exe执行者两项任务。

我们最后分析一下SOM和SOC在服务端到底是如何处理客户请求的。SOM是服务对象管理器，主要负责服务对象的创建、启动、停止、删除等操作。服务对象就是我们前面提的MapServer地图服务、GeocodeServer地理编码服务、GeoprocessingServer地理处理服务、ImageServer影像服务、GeometryServer几何服务、GlobeServer三维球体服务等。SOC主要是服务对象的容器，也就是说这些服务对象都“托管”运行在SOC的机器上，并不是运行在SOM的机器上。每个服务对象根据它们的配置信息，如池化、非池化、最大实例数、最小实例数、隔离机制、实例回收机制等由SOM创建并运行在SOC上。当客户端向Web服务器请求一张动态地图图片时，Web服务器首先接受该请求，然后根据Web.config文件配置信息找到处理该请求的ArcGIS Server ADF类（一个DCOM或者SOAP的MapServer代理类），该类首先连接到ArcGIS Server SOM，由SOM创建服务器上下文即CreateServerContext，并得到服务对象(该对象运行在SOC机器上，并实现IMapServer接口)，调用该对象的ExportMapImage方法，调用完毕将结果返回给Web服务器，最后由Web服务器将结果发送给客户端。在整个过程中，SOM只起到了一个请求调度的作用，并不负责执行具体的请求，所有的请求最终由SOC完成。这里，我们就能够很容易理解SOM的负载均衡机制，当一个SOM挂接多个SOC时，SOM创建的服务对象到底承载在哪台SOC机器上是由SOM来控制的，它可能会根据SOC机器的CPU资源、内存资源利用率等因素来控制。其实在SOM内部有一个线程运行在ArcSOM.exe中，该线程每个1秒钟会ping一次SOC机器，当SOC由于网络原因或者其他因素导致与SOM连接失败时，SOM会监控到这种连接失败，那么就会在其他SOC机器上创建服务对象，并且SOM也会试图重启SOC进程。这就实现了SOM的负载均衡机制。

理解ArcGIS Server的SOM和SOC是我们开发服务器端程序以及做Server性能优化的前提，希望我今天的博文对大家有一定的帮助。今天我们就谈到这里吧，实在太晚了，下次我会给大家介绍服务配置参数，如池化、非池化、最大最小实例数、进程隔离以及回收等参数与系统性能到底有何具体关系。