浅析ArcIMS

引言

最早使用的ArcIMS是3.5还是4.0忘记了,很久前的事情了。当时是做一个简单的系统,包括地图的 显示,点击显示一个点对象的属性信息,对这些属性的查询,以及添加点对象到一个图层。显示和界面的东西都不需要编程实现,使用ArcIMS的Author 和Design就可以了,然后简单调整一下布局和颜色,由于是内部使用,这部分无所谓。而添加点对象到某个图层,就需要使用其他方法了,当时的做法是使用 MO封装了一个ActiveX EXE(MO无法封装为ActiveX DLL),然后通过ASP调用。

这次重拾ArcIMS,安装、试用,第一感觉是很熟悉,毕竟这么多版本以来,ArcIMS变化不大,或者说,没有什么变化。第二是ArcIMS速度挺快,这2年也用过MapXtreme、MapServer,一直以为ArcIMS慢,这次安装后发现其实挺快。因为没有测试数据,一台计算机也不好做测试,不过感觉上,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代码已基本够用。

下面将分别以ActiveX Connector和.net Link为例来分析ArcIMS的开发。

使用.net Link

.net Link是使用.net Framework来开发ArcIMS应用程序的API。使用.net Link的步骤为:

1. 增加.NET Link的程序集引用到项目,程序集位于目录:
<ArcIMS Installation Directory>\ArcIMS\Connectors\NET_Link

2. 连接到Application Server,可以使用HTTP或者TCP连接,例如下面的代码建立一个TCP连接:

using ESRI.ArcIMS.Server;
..
ServerConnection connection= new ServerConnection();
connection.Host="localhost";
connection.AppServerPort=5300;
connection.Scheme=Scheme.TCP;

3. 发送一个ArcXML request。

4. 处理返回的ArcXML response。

和HTML下的JS相比,.net Link只是把XML操作使用.net程序集封装了,并不是一个很面向对象的封装,还需要开发者处理“机器友好,人类不友好”的XML。这也是笔者对.net Link比较失望的原因。

下面来看看随ArcIMS一起安装的.net Link的例子“BlueViewer”。工程的设置,数据安装,ArcIMS的设置请参考例子目录下的readme.htm。

设置好以后就可以在浏览器中打开这个站点,是一个包括了放大缩小等简单功能的地图服务,如下图所示:



用VS 2003打开工程,其解决方案如下图所示:



其中的核心是js代码和MakeMap.aspx这个文件,我们来做一个分析。

程 序的default.aspx中除了界面元素,定义了hvMinX、hvMinY、hvMaxX、hvMaxY、hvMapPage,为 HtmlControls.HtmlInputHidden类型(表单的隐藏域),前4个对象的值指示当前地图的范围,最后一个则用来获取地图的url。

在Page_Load过程中,有如下的语句:

hvMapPage.Value = "MakeMap.aspx"

也 就是说,hvMapPage对象的值最终由MakeMap.aspx来返回。我们先看看MakeMap.aspx这个文件。这个文件的逻辑很简单,在 Page_Load过程中根据地图范围发送一个ArcXML请求,并获得Response,解析这个XML,最终如果成功,则定向到生成的图片文件 url,或者返回错误信息:

If bRequestFailed Then
     ...
Else
     Response.Redirect(imageURL)
End If

这样,通过重定向,最终由ArcIMS生成的图片的地址被赋值给default.aspx中hvMapPage的值,我们再回到default.aspx,看这个图片最终是如何显示出来的。

在default.aspx中,在页面的load事件中调用了js函数startUp():

<BODY onload="startUp()" MS_POSITIONING="GridLayout" style="MARGIN: 0px">

startUp()定义在main.js中。在startUp()中通过一系列的初始化,然后显示Loading图片(加载地图的那段动画),并指定事件:

m_imgMapCanvas.onload = hideWaitImage;

即当m_imgMapCanvas(最终显示的地图的图片)显示以后,调用hideWaitImage过程,隐藏Loading图片(NC需要特殊处理)。

最 后调用submit函数。submit函数根据目前的地图范围,发送一个submit,这时候,服务器端MakeMap.aspx就会运行,最后把结果 (图片的url)保存在hvMapPage的值中。我们在default.aspx中也看到,MakeMap.aspx也必须是提交表单后才运行,就是这 个道理。

请求(submit)返回后,替换显示图片的url:

m_imgMapCanvas.src = sURL;

而m_imgMapCanvas就是default.aspx中中间显示地图的区域,为一个<img>。

对于NC需要特殊处理以隐藏Loading图片,对于IE则自动调用hideWaitImage函数来隐藏之。最后调用persistExtent函数把地图范围保存在hvMinX等几个隐藏的表单域中。

这样,我们就对这个例子的运行机制和过程做了一个纵向的剖析,从中我们也看到,.net或者ASP.net的工作其实很少,仅仅是发送和解析ArcXML请求,地图的显示和操作都集中在JS代码中。

使用ActiveX Connector来开发

ActiveX Connector应该是ArcIMS里比较成熟的一个API,另外的应该是Java的API。

ArcIMS的例子在Samples的ActiveX目录下,ActiveX_Samples是使用ASP来操作ArcIMS的一些例子,例如获得一幅地图:

Set mConnector = Server.CreateObject("aims.ArcIMSConnector")
mConnector.ServerName = "localhost"   
mConnector.ServerPort = 5300
Set mMap = Server.CreateObject("aims.Map")   
resultInit = mMap.InitMap( mConnector, "SanFrancisco" )
mMap.Width = 500   
mMap.Height = 300
mMap.BackColor = 15130848
urlImage = mMap.GetImageAsUrl()
Response.write "<IMG SRC=" + urlImage + ">"

创建aims.ArcIMSConnector对象,与Application Server的连接,创建Map对象,并与一个Service绑定,然后设置大小,调用GetImageAsUrl返回一个图片的Url。

ActiveX_Template目录下有图层、地图、选择操作等一些模版,可以在自己的程序中使用。大多程序都通过Session来保存地图对象,然后通过该对象来运行。

和.net Link比较,ActiveX Connector是一个比较成熟的API,但由于ASP本身的限制,使用ASP来开发ArcIMS应用的会越来越少。

Ajax及其他

目前流行的地图应用是Ajax客户端,比较“老土”的ArcIMS似乎已经很落后了。但如果了解现今网络地图的基本原理,也了解WebGIS的架构和原理,那么,使用ArcIMS作为后端,开发一个类似的应用也不是难事。国外已经有人在做了,推荐一个站点:

http://www.mapdex.org/blog/

本文的后续版本也许也会涉及这个话题。

总结

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

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可用,大多问题都有答案。

原文地址:https://www.cnblogs.com/maweifeng/p/462417.html