很是失望！随便说几条

一、arcgis server的进一步推广

自从9.0推出arcgis server我就感觉不妙。那时rob的 without ejb 在国内正是火热，关于类似EJB的远程调用组件模型都值得我们思考。但ESRI却把宝压在这上面。

不但进一步完善COM恶心的组件模型，还通过java-com桥，.net对com的向下兼容，整合出了arcgis server。

增加的开发难度一会在说。”循证框架“的选择权利也不给我们了吗？sde/soc/som/webserver 我都装在一台机器上，还是远程访问，够郁闷。系统/平台的分层不一定都要物理分离吧！ 

二、关于开发平台和操作系统平台

     .net/j2ee 的比较会带来太多的争论。具我了解esri对于java/.net开发是两个项目组。所以公司的侧重，开发的难易程度很是明显。当然底层组件的开发更重要。

      据悉esri gis软件最早是在unix系统下运行。不知道什么时候靠拢到window了。估计MS资组esri了 。就arcgis server 最先发布的是window平台下的。然后才是linux/solaris。。。别的不敢说，arcims9.1在 window/solaris/ibm aix的表现相差很多。当然是window支持的最好。

    虽然我喜欢.net的简单、开发效率。但我更相信大的企业应用是unix的天下。也就是j2ee是首选。arcgis server /arcims虽然官方支持多了平台，但是让我选择的话，为了让自己能睡着觉，我会先给客户选择window 2003。真是悲哀，客户花100万买的ibm p570/aix 居然让在那躺的睡觉。

     esri的做法让我很是不爽。

三、esri烦乱的产品线

    作为gis界”老大“，让人琢磨不透的复杂的产品线，让国内gis行业不能很好的发展，把门槛提的这么老高，到底是为了多卖点钱，随意分割产品呢？还是要故作深沉呢？ 首推arc engine,卖老贵，还没什么东西还有gis portal/adf/webservice支持....什么GS玩意？把gis这部分做好就让人满意了，还老跟着it潮流，可怜我们这帮gis程序员。

可能这也不能怪美国老，可能他们用的不错，但esri中国也给我们过滤一下啊。

四、技术选择

 esri是个没有创新的公司，只能跟着规范走的弱弱。

1、应用iframe/frame无刷新的提交数据是什么时候提出了，可能这方面arcims 的htmlview算早了吧！看看现在的AJAX，官方文档只在9.2里出现过。但ajax还没出现，无刷新的技术当在javaeye讨论的时候，我这个新手就早在htmlview见识过。我想表达的是 为什么在我接触的arcims3.0/4.0/9.0 htmlview模板 丝毫没有变化过。这么好的思想n年都没有进步，还有模板例子中那些恶心，难懂的javascript代码？

 2、顺着ajax说下去。jsf/asp.net 这类 mvc框架天生不适合ajax的应用，而webgis天生就是ajax应用。 为什么选择这么恶心的官方标准。随便搜索一下ms ajax

http://searchwebservices.techtarget.com.cn/atlas/ 人家ms用ajax有atlas，

http://www.cnw.com.cn/news/news/htm2006/20060619_10C8P.htm  sun也不在jsf上搞ajax。 顺便在这推荐一下 dojo 。

esri不能这样落伍了，为什么jsf还没有正式发布的时候，你的arcgis server ADF for java 就选择的jsf。为什么那时不关注一下ms的atlas。 而还要自己写那些恶心的javascript代码， 用服务器端语言封装javascript。 我们是跟着你走，你跟这 sun/ms 走。

难道不知道 sun 提出规范/标准基本都是吗？强烈建议大家看 without ejb。

不知道跟ms合作的公司一般都会倒闭吗？

五、谁能给我解释AO如何在浏览器调用？

题目有些问题。

arcgis server 最想解决的问题是 让AO对象可以用浏览器调用。而不是象在arcims中，都是通过人可以识别的xml来描述。而是通过远程对象访问。

 到底是二进制远程对象访问好呢？还是象webservice 的xml协议好？我没能力说，但就开发难度，”性能“来说，arcims比arcgis server强很多。

所以arcims能解决的问题，没必要arcgis server。小道消息，arcims还有两年的生命力。

 关于arcgis server能实现的功能我们很想与人讨论。谁有兴趣可留言。

 我们可以从这个角度考虑。 arcmap是AO的实现。试问你arcmap的功能用了多少？没多少吧！因为很多人认为mapinfo比arcmap好用多了。　AO庞大的类库你熟悉吗？谁敢说熟悉，赶快通知我，我去拜师！

既然在桌面环境下，我们也没用AO的多少功能。更不用说我们二次开发商的客户了。所以我说：把AO搬到服务器端意义不大。

当然不是没意义，就象without EJB中说的。我们并不是在j2ee中不用ejb，但至少90%的j2ee项目不需要EJB，但我们却用了。

我现在就怕，arcgis server的宣传把国内那些所谓的“方案撰写者”迷失了。

前天和一朋友聊天，他说arcgis server可以实现严谨的浏览器采集（可能只拓扑关系，图形校验等）。但浏览器上的绘图限制已经让AO数据编辑没什么意义了。还是用arcsde for　java api.(不知道.net用户怎么办，用c的api?)

六、后记

一气呵成，大家看着开心一下就好。

Arcims应用服务器：管理虚拟服务器，地图服务（admin配置的），连接器请求线程管理等。连接器调用它，它在调用空间服务器。一个应用服务器可以连接多个空间服务器。
Arcims 空间服务器：把矢量书生成图片，或做空间分析，查询等。Arcims的核心。还好我们不要关注具体算法等。开源gis,mapxtreme,super map等也就这部分没arcims强。但空间服务器与别的组件的协议是arcxml。虽然arcxml规范比较全面，但这个高度的松散偶合也给 arcims的复杂开发带来些局限性。以后我会提到。
2、 arcXml的重要性
因为搞编程的人不是地理学专家、矢量数据结构专家、图象技术专家。至少不能共同关注这好些技术。所以arcXml规范的定义是极其重要的。也可以让外行人开发专业的程序。这叫好比VML.SVG标签语言一样，如果你不懂数学算法，不可能画一个椭圆。
　　　　以前我也说过，如果你掌握了arcxml，那你就基本知道arcims能做什么，能实现什么功能。至于做的好坏，那看你的行业知识、编程能力了。
3、 Introduction to ArcXML
上面说了一堆废话，现在看看arcXML到底是什么。
ArcXML 是为了与arcIMS空间服务器通信而定义的协议。而arcIMS空间服务器是arcims的核心，它把地图和数据打包成适当的格式，发送到它的客户端 （arcIMS应用服务器）。要懂arcxml,首先必须知道怎么样配置文件，建立arcims服务，请求和响应，以及怎么与空间服务器结合。
 
1、 建立一个axl为扩展名的配置文件。（xml格式）
2、 用 ArcIMS Administrator 建立并启动 ArcIMS Service
3、 接受请求
4、 响应请求

4、 arcims核心（ArcIMS Spatial）
  arcIMS 空间服务器是arcims的核心。Arcims软件也可以分布式部署ArcIMS Spatial.关于详细部署可以看arcims安装文档。有时间我写篇专门讲讲。如果是正版软件，你可以让esri公司来干这个事。

（1） 传输时间：接器的选择会影响
（2） 排队时间：以多建立虚拟服务器来解决。
（3） 渲染时间：比较费事，可以分布式部署空间服务器来解决）
（4） 查询时间：数据库调优，arcsde调优。（有时间再讨论）
5、 servletconnector与javaconnector的区别

arcims开发经验总结
arcIMS 客户端 连接器的选择
以前文章我也简单说了说。

用图表来分析。
Servletconnector:
 
上 图表示了servlet连接器的结构。注意，用这种连接器，把从arcims返回的arcxml直接传递给了浏览器，浏览器用字符串拆分技术或dom技术 来解析这个复杂的xml串。（还好htmlview的模板提供了这些代码，不过用javascript拆分字符串，没用dom标准）
    每次请求的arcxml字符串是很大的，arcxml包含的有些信息对用户是没用的，所以在web服务器与浏览器之间，浪费了许多带宽，对于二次开发人员，难度也加大不少。
javaconnector:
 
使用javascnnector ，浏览器与web服务器之间传输的协议由二次开发人员定义，这可能会加大编程难度，但随着ajax技术的成熟，开源框架dwr,json等的完善，这部分工作会越来越简单。
但javaconnector 引来一个问题，它的Map java对象不是线程安全的，而这个对象的初始化比较费时间。它和jdbc中的数据库连接差不多。针对这个对象写了个Map池，从我们项目运行的情况看， 效果还不错。如果用javaconnector,对java编程需要一定的基础。
6、 业务的复杂度决定我们应该用哪种连接器
如 果你只是想简单的发布地图，htmlview就可以满足你的需求。如果有复杂的业务，gisporal定制，权限管理，那你用htmlview会让你面临 灾难。我选择javaconnector. Using_ActiveX_Connector, Using_NETLink也有文档。 但你要做大型，高性能的webgis,j2ee必定是受选，unix，arcims在j2ee的积累，arcims很多程序使用java实现的。（另外 arcinfo最早是在unix命令行形式运行的）。
A、 java语言比javascript高级多了。Htmlview大多数用javascritp实现。
B、 跨浏览器的支持。噩梦吧。
C、 ajax技术的成熟，客户端与服务器端交互容易多了。
D、 webgis无刷新更新数据是必须的，那必须下载足够多的数据。安全性是个问题。
E、 权限判断，业务定制等用javascript实现简直是噩梦。
   
7、 webgis开发人员的感想
开 发webgis系统，对程序员的要求太高了，可是工资水平一直很低，行业极其不成熟，国内也没什么发展前途，让我好多次有想法转行专门做j2ee去，但还 是坚持下来了。国内这帮搞gis的都是学院派出生，相对编程能力，计算机应用水平比较差，对it行业市场把握能力也较差，被别人抢的先机。现在以 google牵头各大搜索引擎都提供的 地图服务，另外国内 edushi等又有一批仿三维的地图服务出现，让我看到一思希望。做传统gis 的公司该收复失地的，毕竟我们是有优势的。

参考：
arcxmlguide.htm
arcims性能优化和调整  许晓辉

    其实这种解决办法不是很好，假如我们要做个房管GIS，要管理全市的楼房，如果把楼房当成业务数据的话，在图上没法显示，会挤到一块的，另外面状的楼块很难建模。如果作为图片显示的话，以中国建楼速度，累死你。
  
b、浏览器
   对于用户来讲，google maps 只能在IE上来用，它用了MS ie 特有的VML。有

些限制，但比要下在个SVG插件，或下在JRE强多了。
c、用户操作
   作为AJAX最早案例，用户操作体验当人不让。无刷新提交，很快的响应速度。
d、操作结果
   地图数据内容的单调。
   google maps能够提供给我们服务实在不多。如果把全世界所有的pizza在地图

上显示，估计没发看了。
e、展示
   google maps查询结果的展示继承google一贯做法，大家都习惯了。地图的显

示也大方，注意赢眼效果很好，有移动的效果。
3、总结
    google maps是个很类似webgis的东西,由google推出,反响不小,但我感觉它提供的服务并不是很多.从程序员角度,这套系统扩展起来还是比较麻烦的.比如数据更新维护,大量关注点数据在MIS中,当量大时,如何在图上展示有些麻烦.
   另外矢量分析也不能通过矢量数据处理.比如我想查某饭店旁边500米的停车场,脱离传统GIS实现这些功能我觉得还是比较复杂的.

   抛开arcgis9 的 arcgis Server.先说arcIms开发。（以Image Services为例，ArcMap Image Services我估计在arcgis9中，着重在arcGIS Server体现）

    arcIms的核心是AcrXML，也可以说是围绕着ArcXML进行的开发，如果熟悉了ArcXML,估计关于arcIms的开发就掌握了60%. 象htmlview,javaconnect,Activex等各种连接，只是对ArcXML的一个封装。

  ArcIMS服务器，其实相当于一个webservice.我们输入一定格式的参数，他处理后就返回相应的结果。而这个格式就是ArcXML。（其实 ArcXML还是ims的配置文件,由author生成。）ARCXML包括内容丰富，还在不断增强。 我们常用的请求为Using GET_IMAGE and IMAGE with Image Services，Using GET_FEATURES and FEATURES 分别得到图象和属性值。
 
     对于我们二次开发来说，我们只是不断的组合请求的ArcXML,得到我们想要的结果。然后显示这些结果。 我把这个开发过程分为 GIS业务应用 和 WEB编程。 比如：北京工交网： 其实就是组合了几个ARCXML ,然后显示出来。IT公司WEB编程肯定没问题，所以现在GIS行业焦点在如何最大的挖掘需求，挖掘行业应用。如何把行业需求用GIS软件提供的功能表达 出来。（难啊！）作了两年GIS,做的基本都是放大，缩小。业务上，在中国政府机构，公司很难提出什么应用来。（急需一些标准）。估计以后是个方向。（我 要有钱，专门做GIS应用行业标准）
 
   我较喜欢htmlview, 用他可以作出很漂亮的界面（有段时间我认为做GIS和做美工性质一样）。很多工作在客户端。但安全性低，都用javascript实现。至于 javaConnect等，更符合OOP，但是1、因为webGIS系统有很多状态，比如地图的比例，活动层的选择等要保持，要保持这些状态，必须把这些 放到缓冲中，那对于大用户量来说，性能是个大问题。2、javaconnect和mapxtreme很类似， 改变地图要刷新MAP对象，把MAP对象放到SESSION中。（急剧影响性能，访问量大了） 所以状态要保持，对web服务器也是个挑战。对很酷的地图操作也是个挑战。3、个人觉得javaconnector类库的设计好象不是面向开发人员的，完 全以地理分类的概念分组，打包。（package  Map对象应该分成几个对象，弄的太复杂了，对不同的请求，有些属性是空的。）
（现在我正在研究用javaconnector开发高性能ims webGIS）

在ArcGIS9 中，ESRI公司有了新的webGIS编程模型，地理分析可以在web上实现（当然IMS还有），主要针对J2ee 和 .Net平台。 新内容有 1、由arcgis   Server管理AO对象 2、可以远程调用这些AO对象3、有个ArcObject Develop FrameWork(ADF) 和 运行时,支持J2ee,.net平台，可以开发webgis.4、webservice,EJB支持
看了一下 文档，焦点在对象的远程调用 和 对象状态的保持 两方面。 第一点，性能问题，没用过，但估计悬， 但AO对象强大的功能通过远程对象访问搬到web上来了，值得期待。 第二点：对象状态保持， 和mapxtreme一样，有对象池了概念。和EJB的有状态bean 无状态Bean类似。和有状态Bean一样，对象状态保持问题好象解决的不好。但gis大多为有状态对象。麻烦啊。状态保持方案 好象有  shallowly stateful application 和 deeply stateful Web application。需要很大的编程技巧。 个人感觉，.net在这开发还好。J2ee的JSF不知道什么时候能成熟啊。

   HTML Viewer：AJAX的成熟。随着web程序的流行，xhtml,javascript,css的成熟（对不同浏览器有统一标准就完美了，不过客户端 IE就现在还是老大）。arcgis server的客户端也是html view（没办法.net,j2ee还是以浏览器为主要客户端的）。另外html,xhtml是如此的轻便，页面是可以如此的漂亮，扩展，维护也不用编译 什么的。虽然不支持Feature MapService，但Feature MapService的应用可以由arcgis server实现。http://maps.google.com

连接器选择。
.NET Link 、ActiveX 、AppServerLink 、ColdFusion 、General、Java 、Servlet 、WMS
思想就是把ArcXML封装了，再向ArcIMS发送请求，客户端展示。
下面以arcIMS提供了例子探讨一下Servlet Connector ，javaconnector。请自行配置htmlview和javasconnector的例子。

Servlet Connector：修改viewer.htm，使jsForm.htm 可以在页面中看到。（<FRAMESET ROWS="30,*,30,50"—）

jsForm.htm加载地图前代码
......
function passXML() {
}
......  
加载地图后代码
......
function passXML() {
var XMLResponse='<?xml version="1.0" encoding="UTF-8"?><ARCXML
version="1.1"><RESPONSE><IMAGE><ENVELOPE minx="116.325273231549" miny="39.9126536248245"
maxx="116.741417757427" maxy="40.08" /><OUTPUT url="http://zhangkj:8080/Output/txzy_ZHANGKJ188425841.jpg" /></IMAGE></RESPONSE></ARCXML>';
parent.MapFrame.processXML(XMLResponse);
}
........
在aimsXML.js中看函数function htmlSendToServer(URLString,XMLRequest,theType)和function
processXML(theReplyIn) 一目了然了，htmlSendToServer把我们组合的arcXML发送到com.esri.esrimap.Esrimap?ServiceName，返回的XMLResponse由processXML显示出来。
核 心代码就这些，你在javascript文件夹中的大部分js文件是 组合请求的arcXML字符串 和 解析从arcIMS返回的arcXML字符串。其他js文件是DHTML，参数，公有函数等。看上去挺吓人的。我个人觉得htmlview例子里的js代 码可重用性很高。但必须很熟悉这些代码，函数。和其他连接器比较，htmlview可以说是最简单的了。 熟悉html,熟悉javascript,有arcXML文档，这就够了。

剩下的是用 javascript构造不同的arcXML,请求arcIms, 用dhtml,javascript显示返回arcXML.
(大家可以看一下jspForm.jsp，用com.esri.aims.mtier.io.ConnectionProxy类来请求IMS服务。和上面的流程差不多。http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.gateway&p=16&pf=217上面讲的都不错，从更深的角度讲了各个连接）

javaconnector:把arcXML文档用java对象封装起来。组合arcXML的工作由纯面向对象的java语言来做，
com.esri.aims.mtier.io.ConnectionProxy 对象请求ims服务器，返回java对象的响应。servlet connector 是字符串，而java connector是java对象。这样java语言的优势，java对象的可操作性，易用性，方便性就显露出来拉。javaconnector对 arcIMS服务动态增加等。

Map map=new Map();
map.initMap(mapCon,750,false,false,false,false);
map.setHeight(500);
map.setWidth(400);
map.refresh();  
String url=map.getMapOutput().getURL();
Map对象封装ArcXML,map.refresh() 请求IMS服务。 请求完了Map对象包括响应的内容。（其实map.initMap也触发了一次请求 GET_SERVERINFO。javaconnector的类库设计的有问题。）

servlet connector 和 javaconnector比较

一、性能
   servlet connector: 用户下载javascript文件。组合arcXML在客户端执行。如果用户机器不是太慢的话，性能应该是最好的，服务器压力也小。据说ims 群集安装，系统配置的好的话，可以支持几百万用户。
   javaconnector:比不上servlet connector。1、java对象的封装，在服务器端运行。（不过可忽略）2、Map对象建立的性能损耗。map.initMap()， map.refresh()都要触发请求ims。操作一次地图 新建一个map对象的做法是不可能的。有两个解决 把map对象放到Session中 和 map对象池。 把map对象放到Session，用户多的时候，web服务器压力很大，多用户时不可行。 map对象池 ，map对象的 钝化，激活（EJB的提法）操作复杂。因为不同用户当前操作状态不一样（在arcgis9 server中，状态保存是个值得研究的地方）。 运用javaconnector 性能问题得考虑。 （个人觉得javaconnector类库建立的有问题，用反编译工具看，代码设计有改进的地方，可以解决map对象初始化问题）。

二、功能：
   servlet connector: arcXML的所有功能。 问题在 组合arcXML和显示响应的arcXML的环节上。 因为这些用javascript实现。有一定局限性。 比如，我要把 响应arcXML 的查询结果排序。实现起来费事。（arcXML查询不支持order by ）.不可以对ims服务操作。
   javaconnector:arcXML的所有功能。可以用java语言的优势处理很多问题。比如前面排序。动态图层、与遥感影象图的叠加实现起来都比较方便。还可以结合arcSDE的java接口处理元数据。

待续.....