ArcGIS for Server 10.1智能支持云的架构(下)

三、服务基于统一的数据源格式

在ArcGIS for Server 10.1 Manager中发布服务时，使用了统一的GIS数据源格式.sd(service definition files)， .sd数据也是暂时Manager中唯一支持发布GIS服务的格式。此.sd服务文件可以来自于任何GIS资源，如：Geodatabase、Address Locator、地图文档、GP 模型、影像数据集等等，都可以将它们发布成对应的GIS服务。

.sd服务文件是基于7zip压缩的文件，里面包含了服务属性、服务类型以及服务所展现的capabilities等相关信息。当然根据不同的服务类型.sd的内容也有所不同，例如：MapService类型的.sd文件还可能包括切片信息、地图服务所依赖的数据源等；而其他类型的服务者没有这些信息。

3.1、统一的服务文件格式，给我们带来什么便利呢？

例如：在实际生产流程中，或许需要制作数据和发布服务需要由不同的人员来完成，这样统一的服务文件.sd就能满足需求。不同人员协作制作服务的过程如下：

· UserA人员使用Desktop等工具来制图，然后将map文档保存为.sd格式，该过程需要此.sd选择包含所依赖的数据源；

· 对于具有发布服务权限的UserB人员，就可以直接将包含数据源.sd发布成服务。

3.2、统一的服务文件格式，在Manager内部是如何发布成服务？

在ArcGIS for Server 10.1 Manager里提供了内置的GP服务 - PublishingTools，Manager使用者基于这个GP服务将.sd数据直接发布为对应的GIS服务。在应用程序中，开发者同样可以借助Rest SDK中这个GP服务，或者使用Admin API自定义流程来上传数据和发布GIS服务。

Manager 自带的上传数据和发布GIS服务的内部流程：

· 首先将.sd数据上传到Site定义的directories\arcgisuploads目录下。

· 然后Manager使用内置的解压缩工具将上传的.sd数据解压到directories\arcgisinput目录下，解压缩后的文件包含.msd文档,以及一些配置信息，例如：切片信息等等。

· 最后Manager使用Admin API将.msd发布为对应的GIS服务。

在基于ArcGIS Server Admin API的二次开发，内部流程和Manager完全相同，但对于某些流程属性是可以自定义的，如.sd数据存储/解压路径等。

3.3、统一的服务文件格式，给云架构带来了什么？

关于ArcGIS 10.1数据源对云架构的支持分为：公有云 和 私有云 两种方案。这种不同是依赖于公有云和私有云它们本身的不同性质，如：数据和服务托管的方式，是托管在Internet公有云提供商？还是企业私有的局域网内？等等。

正如前面所述，在ArcGIS 10.1外部是通过统一的.sd服务文件发布成对应的GIS服务：首先解压.sd文件，得到GIS资源文件，如MapService中的.msd，再使用Admin API将这个GIS资源文件发布为对应的GIS服务。.sd服务文件分为包含(chosen the option to copy the data)和不包含(not chosen the option to copy the data)依赖的GIS数据，其中包含的GIS数据是以File Geodatabase形式存在。

其中包含依赖的GIS数据对公有云的.sd服务文件来说是必须的；而不包含GIS数据，使用局域网内的GIS数据，是私有云区别于公有云的基本特征。

根据.sd是否包含依赖的GIS数据有如下两种方案：

· 依赖的GIS数据托管在Internet公有云的云端

如上所述，公有云方案中.sd文件务必包含依赖的GIS数据源，然后通过ArcGIS Server Manager内置的上传数据功能将数据上传，或者云端自定义的功能将其发布为GIS服务。

· 依赖的GIS数据托管在局域网的私有云内

在私有云方案中依赖的GIS数据源不一定非要打包在.sd中，可以来源于多种方式：

i、 每个服务逻辑单位的GIS Server在同样目录下都放置一份.sd所依赖的GIS数据。

ii、 .sd所依赖的GIS数据来源于网络共享目录(UNC)。当然需要保证每台GIS Server具有读写这个UNC文件的权限。

iii、.sd所依赖的GIS数据来源于强大的ArcSDE。适用于大数据量、大并发操作的数据；同时对备份和迁移有很好的支持；也可很好的支持客户端edit功能等等。

无论在公有云中、还是在私有云中，支持统一的.sd服务文件有很多优势，特别是包含数据的.sd文件。

如：分离 生产Geodatabase库 和 web Geodatabase库。一般在生产库中很多数据是没有通过审批的、或者没有核对的、或者是临时数据，而不能将这类GIS数据通过服务展现给web 端用户。而可以定时/定任务的将通过审批的数据导出为.sd文件中的web库，并发布为GIS服务展现给Web用户。

四、多方位的安全机制 
在ArcGIS for Server 10.1中，提供了多种控制机制以保证ArcGIS Server服务和数据的正常运行。

4.1权限与安全

在ArcGIS Server 10.1中，权限机制更加简便和安全，除了上述的用户级别的使用权限的控制，还可以有另外两种：对服务使用的控制 以及 ArcGIS Server本身管理组件使用的权限控制。

对于本身管理组件控制。其权限分为三种：administrator、Publisher和user三种权限。这权限的不同主要体现在：manager页面展示功能的区别、site目录的访问权限 以及 是否能为某个特定Map服务创建cache等等。

对于服务使用的控制。对于某一特定用户，是通过该用户绑定的角色(Role) ，判断该Role是否有权限使用某服务，或者使用该服务的文件夹来确定的。

当然对于服务权限控制，ArcGIS Server根据权限信息的所在位置、或者控制级别不同，提供了四种验证和授权(authentication and anthorization)方式：ArcGIS Server built-in 内嵌型 、LDAP 服务器型、基于Windows Active Directory型 以及 用户自定义型。

对于安全型不是很高的用户，可以采用ArcGIS Server内嵌型，这也是安装ArcGIS Server默认的方式，比较简单。所有的安全控制由ArcGIS Server自己完成，权限信息被放置到Configuration Store中。

如果对于安全要求比较高的用户，可以使用LDAP或者是Windows AD方式。ArcGIS Server将安全访问控制将LDAP或者AD上，有其提供的安全机制进行验证与授权，这样权限信息将在控制的服务器上。

对于客户认证信息，提供了基于Token和Http认证（分为：Basic 与Digest）两种不同的验证模式，作为开发者需要有所关注。

除此之外，在10.1中还提供了一个额外的组件，名称为：Web Adaptor，也就是新架构图中在Site之前的GateWay。Adaptor需要依赖于web服务器，主要承担的功能有两个：

i、将客户端的ArcGIS Server操作的HTTP请求，默认用基于robin的负载均衡分配到Cluster的某台GIS Server中。

ii、安全认证。

还可以考虑将Adaptor置于反向代理容器中，以提供更加完善的性能和安全。

4.2容错与容灾

ArcGIS Server充分的考虑容灾和容错能力。主要从3个方面来说明：

i、新模型的架构

在容灾方面，新架构支持热插拔、松散型、点对点的GIS Server节点，当任何一个遇到问题，都可以不会导致应用的崩溃；如果添加上用户自定义的控制流程，可以让GIS Server节点自动恢复。对于提供重要信息的Site站点事先做好备份，当灾难发生时，可以自动的切换到备份的Site站点上。

ii、数据层

数据是GIS的核心。在ArcGIS Server 10.1中，数据要么来源于Site的Configuration Store；要么来源于远程的Geodatabase，如：ArcSDE的数据。

对于来源于文件型的Configuration Store数据，可以借助各种硬件备份存储和恢复技术，做一个存储备份以防不测之用。

对于ArcSDE的数据，可以借助ArcSDE的容灾策略。如: Oracle的Data Guard 等。

五、结束语

ArcGIS for Server 10.1将完美的支持基于云架构的应用，基于ArcGIS Server的云GIS应用将会遍地开花，让我们拭目以待

感谢云板块版主beniy388撰稿