浅析ArcGIS Server开发

浅析ArcGISServerArcGISServerArcGISServerArcGISServer开发-ArcGISServer项目中的基础问题和决策难点袁满ESRI软件进化史未来：由GISer一起创造最新解决方案-ArcGISServer9.3•资源：数据、代码片段、文档•服务：ImageService、GeometryService•工具：RESTAPI，JavascriptAPI•功能：动态缓存、地理编码投影•安全，开放，友好••一切为了帮助用户创造更大价值但是如何做到？典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能•用户的核心价值-常见于测绘、国土、军事等行业•为用户价值的提升提供支撑-常见于决策支持、资源管理等行业•作为用户展现价值的工具和背景-常见于应急指挥、公共决策等行业•大多数情况下，“地理价值”是上述三种价值的混合。确定需求-地理信息对于用户的价值确定需求专业GIS系统融合GIS的信息系统以地理信息为中心地理数据的创建、维护地理数据的分析、建模由GIS专家和IT专家共同维护使用地理信息的业务系统地理数据挖掘导航追踪地理编码富有表现力的专题图由IT专家维护核心价值为用户价值提供支撑展现价值的背景和工具典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能准备数据-根据价值划分地理数据•业务数据-核心价值•业务相关数据-核心价值的支撑•背景数据-展现工具和背景•不同类型的数据在处理、存储、优化等环节应该采取不同的策略准备数据-业务数据•数据来源：内部/专业供应商•更新周期：已知•处理过程：专业性强，复杂度高•处理人员：GIS专家和专门的GIS团队准备数据-背景数据•数据来源：公共数据/专业供应商•更新周期：未知/已知•处理过程：相对简单•处理人员：无/GIS专家准备数据-业务相关数据•数据来源：临时采集/专业供应商•更新周期：无/未知•处理过程：–专业性强、复杂度高–数据标准、格式众多，集成难度大–和业务数据的关联信息需要同时采集•处理人员：IT专家/GIS专家准备数据-地理数据处理工作应先行•GIS应用完全解耦地理数据的成本很高–地理数据的空间参考和存储方式对技术路线选择有很大影响–地理数据的数据量往往很大，数据变更时间很长–地理数据的显示、分析往往耗时，需要做预处理来优化，预处理时间往往很长•开发中的很多难点可以划归为数据和配图的问题–ArcGISDesktop本身提供了许多强大的功能典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能选择技术路线-我们现在有更多的选择•开发工具–ADF–JavascriptAPI–SOAPAPI–RESTAPI•互操作–KML–WMS–WFS–WCS选择技术路线-复杂的专业GIS系统•服务器端：需要多种服务协作–MapService,GlobeService–GeodataService,ImageService–GeoprocessingService,GeocodeService•客户端：对性能和交互能力要求高–ArcMap,ArcCatalog–ArcGISEngine开发的客户端系统–ArcExplorer选择技术路线-融合GIS的信息系统•服务器端：展示和简单的空间操作–MapService,GlobeService–GeometryService–RESTAPI,KML,WMS•客户端：快速开发，表现力–ADF–FlexAPI–OpenLayers,uDig选择技术路线-Mashup•Mashup–混搭，利用供应商提供的简单API，在客户端整合多个不同来源的服务。•通过多种API提供Mashup能力–JavascriptAPI–GoogleEarth-KML–GoogleMap-RESTAPI+JavascriptExtensionfortheGoogleMapsAPI–VirtualEarth-RESTAPI+JavascriptExtensionforMicrosoftVirtualEarth–OpenLayers,uDig-WMS,WFS选择技术路线-Mashup的特点•优点–上手简单–代码量小–学习资源丰富•缺点–没有付费的支持保障–不适于在内网使用–在某些情况下扩展性有限选择技术路线-ADF仍然是快速项目开发的首选•历史•功能•支持•同时支持.NET和Java选择技术路线-.NETADF/JavaADF?演绎自DaveFischer作品(),遵循CC-BY协议选择技术路线-FlexAPI：新选择•10月25日正式发布1.0版•友好的界面•代码量较小•接近ADF的功能•紧密联系RESTAPI•比JavascriptAPI更适合项目开发选择技术路线-FlexAPI的效果选择技术路线-FlexAPI与ADF相似的对象模型典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能开发与实施-Local连接/Internet连接(.NET)•Local连接–使用DCOM通信–更加快速和稳定：部署–支持更多的服务器端功能•Internet连接–使用SOAPAPI通信–对网络的要求较少：开发开发与实施-权限与安全(.NET)开发与实施-权限与安全(.NET)•Local连接–ArcGISCatalog–agsusers,agsadmin–AddArcGISIdentity:ArcGISWebServices–ArcGISSOC需要对多处目录有较高权限•ASP.NET临时目录•地图文档所在目录•工具箱所在目录•arcgisserver目录•……开发与实施-权限与安全(.NET)•Internet连接–角色与验证机制(=9.3)–IIS或ASP.NET托管–ADFWebMappingApplication中集成了验证机制–考虑是否将Output文件夹映射到虚拟目录开发与实施-ASP.NETAJAX(.NET)•.NETADF9.3的新基础架构•大量的AJAX控件•鼓励使用WebService分离业务逻辑开发与实施-池化与非池化服务•要求数据编辑的专业GIS系统–非池化服务–客户端要求较高计算能力•融合GIS的信息系统–一般不要求空间数据编辑能力–空间观测点类数据可以划归为非空间数据–使用池化服务提高性能典型项目流程•确定需求•准备数据•选择技术路线•开发与实施•优化性能优化性能•应该从开始就考虑GIS的性能优化–用户需求–地理数据–技术路线•优化性能的策略–增加计算能力–减少计算量优化性能-改善基础设施•增加服务器性能–增加CPU以支持更多的实例–增大内存，换用更快速的磁盘提高IO速度–调整地图缓存目录所在分区的磁盘簇大小–换用更加快速的文件系统•优化基础设施架构–改善网络基础设施–找出用户-应用-数据三者之间的通信瓶颈–在性能-可靠-经济三者之间做出平衡优化性能-缓存•缓存的主要思路是：在用户访问前完成耗时计算–ArcGISDesktop–Geodatabase–MapService–GlobeService•每个环节都已经使用了缓存技术优化性能-地图服务缓存优化性能-不同的数据使用不同的缓存策略•业务数据–数据更新频繁–不使用缓存–简化符号化和标注–设置可见比例尺优化性能-不同的数据使用不同的缓存策略•业务相关数据–根据业务划分主题–根据主题划分组图层–根据组图层使用MultiLayer缓存–需要动态改变图层内容的图层不做缓存–设置可见比例尺优化性能-不同的数据使用不同的缓存策略•背景数据–使用缓存–使用Fused方式最小化开销优化性能-地图缓存的地图投影与分级•缓存建成后地图投影变无法更改•开始时就应确定整体地图投影•与外部服务集成时需要注意地图投影–GoogleMaps,MicrosoftVirtualEarth•WGS84WebMercator•又称EPSG:900913–如果是地图层次的集成投影必须一致–使用RESTAPI可以在客户端投影优化性能-地图缓存的地图投影与分级•缓存建成后地图投影的分级无法改变•开始时就应确定整体地图分级策略•ESRI推荐的分级策略–250000000–125000000...•ArcGISOnline分级–147748799.285417–73874399.642709...•GoogleMapsVirtualEarth分级–591657550.500000–295828775.300000...•可见比例尺应参照分级比例尺•分级比例尺限制了Extent的可能变化优化性能-减少空间查询•空间查询总是比属性查询耗时•考虑使用属性查询代替空间查询–服务器端的空间查询–服务器端属性查询+客户端事件•使用GeometryService–结合RESTAPI优化性能-减少进程间通信开销•ServerObjectExtension–ArcGISServer的“插件”–注册为服务的Capability的COM对象–随服务一起启动–受内部缓存机制影响–开发COM对象并注册•IServerObjectExtension•注册到COM•注册到ArcGISServer–部署较繁琐•所有SOM、SOC所在计算机•所有使用Catalog管理ArcGISServer的计算机谢谢！欢迎到培训中心进一步交流！联系我们邮箱：[e-mail]电话:[phone]传真:[phone]博客：