浅析ArcIMS

几个要点：

• ArcIMS的定位是空间数据发布系统，虽然也可以做进一步定制和开发，但因为ArcIMS的定位，有些事情很难或无法实现，例如无法（很难）使用ArcIMS进行复杂的空间分析（嗯，可以调用AO或者MO，这个另当别论）。
• ArcIMS和目前的ArcGIS Server不是一个基础，后者基于由COM实现的AO，不过由于ArcIMS任务单一，所以效率较高，而且可以跨平台（核心代码应该是ArcInfo时代的纯C++？）。
• Web服务器的Application Server Connector和ArcIMS的应用服务器（Application Server）的通信是基于Servlet发送ArcXML，因此需要安装Java环境和Servlet运行环境。ArcIMS的Author和Design、Administrator也是基于Java实现。
• ArcIMS的几个主要部件：
  • Application Server Connectors，即ArcIMS定制开发的API，有Java、ActiveX、.net等API，但最终和Application Server通信，都需要将请求转换为ArcXML，由Servlet Connector发送给Application Server，这也是为什么ArcIMS需要一个Servlet运行环境的原因；
  • Application Server，应该是基于Java实现，主要用于维护Spatial Server的状态及其与Web服务器的交互。
  • Spatial Server，核心的地图渲染器，基于C++实现？主要用于根据请求渲染地图，即地图render。
• ArcIMS的开发模式：
  • 使用Author、Designer通过可视化方式来设计地图，发布，无须编程；
  • 使用Connectors来开发，目前可以使用ASP、.net、Java等等方式来开发。
• 闲话，记得有过ArcView IMS，MO IMS的产品，没有使用过，应该是类似MapXtreme for Windows的产品，这个东东是基于MapX实现的，而MapXtreme.net和MapXtreme for Java则是比较纯粹的产品。
• ArcIMS的核心是ArcXML，ArcXML是Web服务器的Application Server Connector，Application Server，Spatial Server之间的通讯协议（语言），其调用模式类似Web Service。

ArcIMS的架构

ArcIMS的体系结构如下图所示：

 

这个结构应该是在ArcIMS 3.0的时候就确定下来的，之后基本没有什么变化。ArcIMS 3.0的发布时间是2000年，而2000年正是3-tier架构开始成为主流的年代。

每层具体的说明可以查看ArcIMS的文档，早先的文档和资料一般把客户端归于表现层，Web Server、Application Server、Spatial Server归于逻辑层，空间数据归于数据层。其实与这些层次做一一对应也无大的必要。其中的Web Server及Application Server Connectors可以部署在一台计算机；Application Server可以部署在一台计算机；而Spatial Server可以部署于多台计算机，由Application Server管理；数据则可以是文件，SDE等格式。实际中，一般把Spatial Server安装于多台计算机，因为Spatial Server是整个系统中负荷最重的部分，执行了大部分的运算任务。

Application Server管理Spatial Server，处理ArcXML请求，并返回ArcXML的结果，对于不同的开发接口（Connector），或者也处理这样的XML，或者由 Connector封装了此类请求，然后在后台与Application Server交互。

运行于Application Server的地图服务（Service）是无状态的，也就是说他只是根据ArcXML请求，调度Spatial Server来不断的生成图片或者其他数据，然后以ArcXML的格式返回给Web Server的Application Server Connectors。因此，用户（地图）的状态，例如当前的缩放比例，位置等，或者在Web服务器端通过Seesion保留，或者在客户端通过某种方式保留（如表单的隐藏域，Url参数等等）。

对于WebGIS的架构和实现，可以参照笔者以前写过的几篇文章，应该对理解ArcIMS的架构有用处：

WebGIS系统的设计与实现
http://maweifeng.cnblogs.com/articles/210080.html

使用.net Remoting和SuperMap Object设计WebGIS系统
http://maweifeng.cnblogs.com/articles/250284.html

开发模式与运行机制

使用ArcIMS的设计工具Author、Designer来编辑Axl定义文件，增加地图服务，定制Html客户端或者Java客户端，发布地图服务，这种开发模式都属于客户端处理模式；而使用ActiveX Connector，.Net Link的方式开发，则属于服务器端处理模式。这里的处理是指处理ArcXML。

客户端处理模式，使用Html客户端或者定制Html客户端开发。系统的运行机制如下：

 

这种模式下，客户端的请求已经是ArcXML格式封装的，然后由Web服务器委托Application Server Connectors处理，由于请求已经是ArcXML格式，Connector的任务只是简单的把请求转发给Application Server。

这种模式下，发送和返回请求都需要在客户端来处理，因此，ArcIMS的Html客户端的JS代码行数达到万行级别，也就不奇怪了。另外，返回和发送ArcXML，其中很多数据都是无关紧要或者不需要的，对于网络通信，也是一个负担。

得到服务器端返回的ArcXML后，客户端JS负责解析，然后再在服务器下载需要的图片，显示在客户端。

相关的代码在HtmlViewer的Javascript代码的aimsMap.js这个文件内，一般的地图操作设置参数后调用sendMapXML函数，然后此函数再调用sendToServer函数，最后由htmlSendToServer通过表单方式发送请求（没有使用XMLHttpRequest对象，所有XML操作都是由JS完成）。ArcIMS文档中的“Customizing_the_HTML_Viewer.pdf”中对 HtmlViewer的结构、运行原理、定制有详细的说明，可以作为参考。

对于ArcExplorer，JavaViewer等都是使用客户端处理模式。

服务器端处理模式，包括使用Java、ASP、.net等开发的方式来定制开发的ArcIMS应用。其运行机制如下：

 

对于服务器处理模式，ArcXML的转换、解析在服务器端由Application Server Connector进行。客户端的代码由服务器端的ASP、JSP等程序动态生成。客户端发送地图服务请求后，由服务器端的API转换为ArcXML，然后由Servlet发送给Application Server。

与客户端处理模式比较，服务器端处理模式的优势有：更少的数据传输，更易与其他程序集成等。

采用服务器处理模式开发，客户端还是需要处理用户操作，例如放大缩小，要获得好的用户交互体验，这部分还是需要较强的JS才可以完成，好在ArcIMS的例子中提供的JS代码已基本够用。

总结

由本文的叙述，我们可以得出下面一些结论：

1. ArcXML，深入编程需要了解ArcXML，因为很多操作必须自己写ArcXML来请求Application服务器，特别是对于.net Link这样的API；

2. JavaScipt，其实对于所有的WebGIS开发，这点都必不可少；客户端操作，自定义的操作，和其他应用在UI的集成，都需要使用JS。

3. 服务器端开发技术，需要的不多，大概看看书就可以照猫画虎了。

4. 由于目前ESRI的主要精力在ArcGIS系列上，因此ArcIMS下一版本的.net Link等是否会得到加强，目前还不得而知。

5. 对于.net运行时，1.1和2.0笔者使用好像都可以，毕竟只是一个程序集的事情，而且要做的事情不多，估计是兼容的。

6. 最后，ESRI的很多产品，由于其历史“悠久”和用户众多，因此寻找有关问题的答案还是很容易的，只要可以上网，有Google可用，大多问题都有答案。