ADF vs ArcGIS Server Javascript/Flex/Silverlight API

http://www.cnblogs.com/flyingis/archive/2008/11/01/1324338.html 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发展的一个趋势。