ArcIMS二次开发,关注最多的无非是它的连接器(connector)和ArcXML。在这些连接器中,Servlet Connector通过纯粹的ArcXML文件来传输请求和响应,ColdFusion Connector在其自身的运行环境中使用自定义tags来产生ArcXML请求和响应,Java Connector和ActiveX Connector比较类似,通过一组API(Java Connector还有标签库)来产生ArcXML请求和响应,它们是面向对象的开发方式,比较符合一般程序员的思维习惯。.NET Link比较特殊,最初我认为它和Java Connector、ActiveX Connector一样,通过一系列API来定义、生成ArcXML文件中的节点与属性,但事实上并非如此,简单来说,它仅仅是对XML文件的一种搭配与组装,使用.NET Framework中对XML文件的操纵方式拼装出所需的ArcXML请求,并接受ArcIMS应用服务器的响应,其参考手册中只有服务连接和AxlRequest相关的几个类的说明,也难怪ESRI为什么要给它要取名为.NET Link,而不是.NET Connector。
离ArcGIS 9.2正式发布已经没有多长时间,.NET Link能否得到改进至少像它的前辈ArctiveX Connector一样还不清楚。.NET Link的这种开发方式使得开发人员需要更多的关注ArcXML_reference,下面将简单说明.NET Link的使用方法。
首先,需要将.NET Link的程序集引用到开发环境中,我使用的是Visual Studio 2005,需要说明的是ArcIMS 9/9.1 的.NET Link在VS2003和VS2005中都能工作的很好,兼容性不错。这样ESRI.ArcIMS.Server.dll就加入了项目中。
第二步,建立到ArcIMS应用服务器的连接。
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
如果需要建立一个HTTP连接,端口为80,可以将以上语句改为
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
第三步,发送一个ArcXML请求。在.NET Link中发送ArcXML请求,其实质就是对ArcXML文件的一种拼装。
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
最后,需要处理ArcXML响应。
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093820585.gif)
![](/Article/UploadFiles/200612/20061203093822626.gif)
![](/Article/UploadFiles/200612/20061203093822249.gif)
![](/Article/UploadFiles/200612/20061203093823747.gif)
![](/Article/UploadFiles/200612/20061203093823577.gif)
![](/Article/UploadFiles/200612/20061203093823577.gif)
![](/Article/UploadFiles/200612/20061203093823577.gif)
![](/Article/UploadFiles/200612/20061203093823577.gif)
![](/Article/UploadFiles/200612/20061203093823124.gif)
最后获得的imageURL就是之前客户端用户发送请求需要服务器返回的图片地址,用户每次对地图操作后看到的结果,其本质就是一张张图片。
现在思路比较清晰了,ArcIMS地图服务发布后,其展现的内容主要是由开发中所定制的ArcXML文件的内容所决定,开发人员需要面对大量ArcXML中的子元素及其属性设置,对于面向对象的开发而言显然是笨了一些,但从原理上来说,还是比较简单的,关键就是要看开发人员对ArcXML文档的熟悉程度了。
使用.NET Link进行ArcIMS二次开发的过程中,对ArcXML的子元素和属性进行操纵与设置不是一件令人愉快的事,但其中真正的困难还要数客户端大量javascript脚本的应用和数据传递,有机会拿一两个简单例子讨论一下。