ADF vs ArcGIS Server Javascript/Flex/Silverlight API
作者:Flyingis
ArcGIS Server已经当之无愧成为ArcGIS产品核心,Javascript/Flex API为GIS应用开发带来了极大的便利和震撼的用户体验,对于为ArcGIS Server开辟江山立下汗马功劳的ADF似乎在大会中慢慢淡出大家的视线,如果一定要说大会关于ADF有什么话题,那一定是ADF是否会被Javascript/Flex甚至马上推出的Silverlight API所代替。
过去大家对ArcGIS Server的印象,一部分停留在基于Web的Desktop,一部分认为是插上了翅膀的ArcIMS,最为贴近的是基于SOA架构的GIS服务软件,这是ESRI过去一直推广的概念之一,和IBM、Oracle一样,浓缩技术抽取精华在中国市场非常奏效,但我认为这个过程不仅需要市场去推广,还需要切实的技术体系作为保证,技术不一定是新技术,至少架构、逻辑、理念要是新颖的,ArcGIS Server不等于ArcEngine+ArcIMS,就是因为它的设计中包含了状态、池化、进程、对象回收、安全、服务架构组织、标准支持等等,ADF和基于Rest服务的客户端应用开发框架都是基于服务体系之上的产物,既然是基于SOA,那么这些产物应该是丰富多变,不论是过去的ADF、ArcExplorer、桌面应用、移动设备,还是js/flex/silverlight api、ArcGIS Image Server,甚至将来新的开发框架技术都可以置于ArcGIS Server根系之上,“Fusion-Center”是个不错的名字,过去一年我所参与的企业级GIS应用的方案设计中,已经在引导客户去架构整体GIS解决方案,将业务和GIS有机整合,熔合于一个服务中心,改进、完善业务流程,在此之前,国内外GIS项目有的可能已经在这样做了,现在将核心概念提出,算是一次归纳总结吧,和SOA的历程有相似之处。
千万不要雷我在炒作概念,所有概念炒作的主体应该是公司,个人只是在分析这些概念的支撑点,所以在市场层面,ADF和Javascript/Flex/Silverlight API之间没有任何冲突,反而共同起到了推波助澜的作用,在技术层面,不要说ADF和其他客户端API的优劣势,就是各种客户端应用开发框架之间选择,各个论坛里都有不少火热的水桶贴,争到最后大家都觉得没有意义了,因为每种API都有自己的位置。国外一些应用已经开始用Javascript/Flex API替代ADF,这是因为之前除了ADF没有更好的框架能够满足他们的要求,现在则有了更多的选择。
ADF相比ESRI推出的其他客户端应用开发框架,最大优势在于基于有状态的设计(客户端应用开发框架所基于的Rest服务是无状态服务),可以充分利用AO资源进行管理员角色的应用开发,适用于企业级的深度GIS应用,充分利用服务器端的资源(对于公众级别的应用,显然使用客户端API将压力分散到客户端更为合适)。GP工具为WebGIS应用提供了较大的扩展空间,但前提是必须使用桌面中已有的或自定义tbx工具,ADF可以不依赖于其他任何软件(不做Cache)通过ServerContext实现GP中所有功能,降低软件成本。当前的应用开发框架都有各自的优势,如何根据自己的应用选择合适的开发框架,才是我们要考虑的核心,宏观上来看,客户端应用开发框架和RIA应用会成为今后两年GIS发展的一个趋势。
Flyingis @ China
email: dev.vip#gmail.com
blog: http://flyingis.cnblogs.com/
posted on 2008-11-01 17:52 Flyingis 阅读(5432) 评论(14) 编辑 收藏 举报