【转帖】ArcGIS Server Inside 系列(二)

 

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性能优化的前提,希望我今天的博文对大家有一定的帮助。今天我们就谈到这里吧,实在太晚了,下次我会给大家介绍服务配置参数,如池化、非池化、最大最小实例数、进程隔离以及回收等参数与系统性能到底有何具体关系。
原文地址:https://www.cnblogs.com/goed/p/1850713.html