《GIS开发者》第八期

　　近年来，软件技术发展最突出的特点和趋势是：软件开发不仅仅靠开发语言和集成环境，而是要依赖于一个完整的开发平台。之所以称为“开发平台”，具体体现在以下几个方面：1）具有完备的分布式和企业级解决方案；2）具备软件从需求到设计、开发、重构、测试、文档到配置管理、安装发布部署等一整套功能；3）提供了庞大的、完整的类库支持。

　　目前两个主流开发平台是.NET和Java EE，由于上述特点，可以设想在不久的未来，大多数软件产品和工程项目都将在这两个主流平台上进行。对主流开发平台的支持给GIS软件带来了新的机遇和挑战。

　　1.2 .NET和Java EE平台对比和选择

　　.NET和Java EE平台的分析对比已经有很多相关研究，这里只作简单的对比并得出结论。

　　　　　　　　

　　根据上述比较，选择支持哪个平台对于具体项目而言并不困难，如果应用只部署在Windows操作系统上，.NET在集成度和运行效率、开发效率上都要略胜一筹；要支持Unix/Linux操作系统，Java EE则是不二选择。但对于软件，尤其是专业开发平台软件，则往往是一个艰难的抉择，因为需要关注软件产业长期的发展，初期选择失误会带来难以挽回的损失，而现在无法断定两个开发平台未来竞争的结果。选择.NET还是Java EE是许多GIS平台软件开发企业的两难问题。

　　对于GIS软件而言，更为现实的方法是同时支持J2EE和.NET。因为对于普通用户，Windows桌面GIS更普及和容易操作；而GIS服务更倾向于使用Unix和Linux服务器，两个不可或缺。那么GIS如何做到同时支持J2EE和.NET两个对立的阵营呢？又如何应对未来开发平台的新进展呢？下面对几种可能的实现模式分别进行分析对比。

　　1.3 几种实现模式

　　1.1.1 代码转换模式

　　代码转换模式指的是首先用C#（任一.NET开发语言）或Java完成.NET版本或Java版本的开发，然后采用代码转换工具把C#代码翻译为Java代码，或把Java代码翻译为C#代码。

　　代码转换模式看似最为彻底，在两个平台上都进行了完整的实现。实际上却行不通，因为两种平台各有自己的优势，这些优势互不相同，代码转换工具无法把一个平台的优势智能的在另一个平台上优化。此外，转换后的代码容易存在隐患，维护升级也困难。最重要的是Java还存在运行效率不高，无法满足GIS大数据量、高性能运算的要求，即不适合用于GIS平台核心功能的开发。

　　1.3.1 COM扩展模式

　　由于原有GIS组件几乎都采用COM技术，所以采用在现有COM组件的基础上通过各种桥接技术提供Java和.NET接口就成为一个很自然的想法。例如可以在COM基础上封装出.NET组件，通过第三方的Java-COM桥工具提供Java接口。

　　COM扩展模式可以在原有COM组件的基础上快速完成Java和.NET组件的封装，是一种比较现实的选择。但这种模式存在依赖于第三方技术、开发和维护困难、增加不必要的层次和复杂度等问题。另一个问题在于其技术基础COM从原理上虽然是可以跨操作系统的，但实际上仅在Windows操作系统上得到很好的实现，最终Java GIS组件的跨操作系统性严重依赖于其它操作系统对COM的支持，而仅支持Windows操作系统的Java组件则显得有些鸡肋。COM扩展模式可以说是为了满足对Java和.NET的紧迫需要而采取的一种临时性或过渡性的措施。

　　1.3.2 基于“共相”思想的C++扩展模式

　　哲学中用“共相”和“殊相”来分别指代普遍性和个别性的概念与事物。基于某种开发平台实现的GIS组件可以看作一个“殊相”，而具备支持任意开发平台能力的C++扩展模式则渗透着“共相”的思想。对于“共相”更多的分析可以参阅本期另一篇文章《哲学中的共相问题与共相式地理信息系统研究》。

　　C++扩展模式从GIS软件对高性能和跨平台的要求出发，充分考虑到以后对操作系统和开发平台的扩展能力，提出以标准C++构建一套高性能和跨平台的GIS核心类库，并以此为基础，通过各种开发语言自身所具备和C++语言的交互集成能力，来封装实现各个开发平台上的GIS组件。例如可以通过JNI技术实现Java组件，通过C++/CLI实现.NET组件，通过Python的C语言扩展接口实现Python组件等。值得说明的是，上述这些技术都是各个开发语言/开发平台与生俱来的，是成熟稳定的技术，并不会带来不稳定因素。

　　C++扩展模式的优点在于：1）采用标准C++作为内核，具备高度的可移植性；2）C++的内核带来运行时的高性能；3）各种开发平台自身几乎都提供了和C/C++集成的能力，具备无限的扩展能力。

　　C++扩展模式的缺点在于：1）无法使用既有的开发成果，必须从头打造标准C++的GIS核心类库；2）开发技术难度大，开发水平要求高。因此，这一模式的实施代价非常昂贵。但一旦实施成功，却是最为彻底和完美的解决方案，其产品也将是最为稳定和成熟的。

　　1.4 C++扩展模式的实现技术

　　1.1.2 标准C++的GIS核心类库构建
C++扩展模式首先需要实现一套用标准C++构建的、跨平台的GIS核心类库，做到“一次编写，到处编译”。表2对开发中可能会遇到的问题及其应对要点做一个总结。

　　

　　1.1.3 Java组件实现技术

　　在C++类库的基础上，可以通过JNI（Java Native Interface）技术实现Java接口。通常来说，采用JNI技术在提升系统的运行效率的同时往往会丧失Java的跨平台特性。但由于标准C++构建底层类库具有“一次编写，到处编译”的特性，所以通过JNI技术实现的Java组件并没有丧失跨平台性。

　　通过JNI实现C++提供Java接口的步骤如图1所示。（以输出“Hello，World”为例。）

　　　　　　　　　　　　

　　JNI由于涉及到Java和C/C++两种开发语言，开发难度大，出现问题如果不清楚问题所在，往往会陷入被动。JNI开发中注意事项有数值类型的对应问题和字符编码问题等。

　　在用JNI技术提供Java接口之后，还应该经过再一次的封装，提供面向对象的Java组件。

　　1.1.4 .NET组件实现技术

　　在C++类库的基础上，实现.NET组件的最佳途径是采用C++/CLI。C++/CLI是在著名语言设计大师Stan Lippman和Herb Sutter主导设计的新一代C++。C++/CLI在完全支持C++标准的前提下，引入了一些新的语法和语义，对.NET环境提供了第一流的支持，对.NET CLR提供了更加灵活的控制方式。C++/CLI改革了Manager C++拙劣的语法，增强了其系统功能，针对传统C++遗留的一些问题进行了改进，使C++更好地扮演.NET平台上系统语言的角色。

　　C++/CLI是C++和CLI的结合体，C++被称为最复杂的系统语言之一，C++/CLI 的复杂度更是有过之而无不及。在使用C++/CLI中，需要注意的事项有：区分内部指针和顶指针，字符串处理等。

　　1.5 新一代SuperMap GIS组件的实现和特点

　　1.1.5 新一代SuperMap GIS组件的实现

　　新一代SuperMap GIS组件正是按照C++扩展模式的思路来构建的。首先用标准C++构建一套完整的、与具体操作系统无关的GIS核心类库――SuperMap Universal GIS Classes（简称UGC）。在UGC的基础之上，通过JNI技术提供SuperMap Objects Java组件，用于Java开发平台；通过C++/CLI技术提供SuperMap Objects .NET 组件，用于.NET开发平台。

　　　　　　　　　　

　　虽然SuperMap Objects Java组件和SuperMap Objects .NET组件的开发平台不同，但两者都基于统一的内核――SuperMap UGC构建，具有相同的对象模型和数据格式，是共相式GIS的重要组成部分。在共相式GIS框架下的新一代组件式GIS具备对开发平台和功能模块两个层面上的扩展性，例如在满足市场需求时，可以推出针对其他开发平台的GIS组件，如针对Python平台的Python GIS组件等；在增加新的功能模块时，可以增加新的功能组件。目前由四个可拆分的功能组件（程序集或Java包）组成，分别是数据访问组件、地图组件、分析组件和工具组件。

　　（1）数据组件（Data Component）

　　数据组件是核心组件，所有其他组件都直接或者间接的依赖于数据组件。数据组件由一系列和数据访问相关的对象组成，数据组件通过数据组件中的工作空间对象，用户可以轻松的访问到系统中的数据源（DataSource）、数据集（Dataset）、记录集（Recordset）和几何对象（Geometry）等数据内容，还可提取几何对象的所有坐标和属性数据。数据组件还包括投影信息的获取和空间坐标系的转换等功能。

　　（2）地图组件（Map Component）

　　地图组件依赖于数据组件，由地图控件和一系列与地图相关的对象组成。地图组件负责地图的显示以及地图上的交互式操作。地图控件还提供了一些事件（Events），用户可以根据自己的需求在这些事件中编写自己的代码，实现特定的功能。地图组件还负责图层、选择集、跟踪图层和专题图的制作与管理。地图组件后续版本会提供地图的交互式编辑，以及开放更多的事件。

　　（3）分析组件（Analyst Component）

　　分析组件依赖于数据组件，由一系列分析相关的对象组成。分析组件负责在数据集层次上的空间分析功能。分析组件目前提供缓冲区分析、叠置分析和网络分析，后续版本会提供栅格分析、动态分段等分析功能。

　　（4）工具组件（Utility Component）

　　工具组件依赖于数据组件，由一系列实用工具对象组成。工具组件负责在GIS应用中需要用到的一些工具性质的功能。工具组件目前提供配准和拓扑构建功能，后续版本会提供数据接边、数据转换等功能。

　　由于篇幅所限，这里仅提供Data和Map中一部分对象的结构简图。完整的对象结构简图可以参见SuperMap的用户文档。

　　　　　　　

　　1.1.6 新一代SuperMap组件式 GIS的特点

　　SuperMap Objects经过多年的发展，具备了许多优秀的特点，如易于开发、可独立分发运行、功能强大、高度的可伸缩性、内嵌大型空间数据库引擎、面向对象与面向拓扑相结合、GIS与CAD相结合、易与其它系统集成、适度的封装“粒度”，大型GIS开发平台等。这些特点的详细介绍可以参阅SuperMap Objects的相关文档。

　　新一代SuperMap组件式 GIS从原有SuperMap Objects继承和发展而来，在充分继承原有特点的同时，还具备以下特点：

　　(1) 兼容性好

　　完全兼容SuperMap GIS 5的数据格式和XML工作空间。经过多年发展，SuperMap GIS已经得到广泛的认可，拥有众多用户，并产生了大量SuperMap GIS格式的数据。SuperMap Objects.NET完全兼容SuperMap GIS 5系列产品的数据格式以及XML工作空间，最大程度的保证了原有SuperMap用户的投资，SuperMap GIS 5系列产品的用户可以很方便的过渡到SuperMap Objects Universal下使用原有数据。

　　(2) 完全融入两大主流开发平台，开发更加便捷

　　SuperMap Objects.NET采用微软即将推出的最新技术C++/CLI和开发工具Visual Studio.NET 2005开发，全面支持.NET 2.0；SuperMap Objects Java采用JBuilder 2005开发。两者的推出意味着SuperMap GIS又一次站在了IT技术发展的制高点，SuperMap GIS和其他系统的融合将更加方便快捷。

　　(3) 更加合理的组件划分

　　新一代SuperMap组件式 GIS在延续SuperMap Objects组件划分的基础上，根据用户的实际需要，采用了更加合理的组件划分方式，具体体现在：1）把数据组件从地图组件中分离，作为一个独立的组件，也就是说，纯粹的数据访问和处理可以不需要地图组件；这将更加方便使用者开发各种数据处理工具；2）把工具类的功能集成在工具组件中，工具类功能和其他功能相比较，最大的特点在于对一个项目或一批数据只需要处理一次，如配准、构建拓扑、数据转换等，工具组件分离出来；这既可以节省用户经济成本，又降低了数据组件、地图组件等的运行负担，还便于以后功能的扩充。

　　(4) 高效运行和高效开发的完美结合

　　众所周知，C++作为系统级开发语言，具有运行效率高的特性，但其学习开发的难度都很大，不便于用户的二次开发。而Java语言，包括C#语言虽然易学易用，并有很好的集成开发环境辅助开发，但由于语言本身的限制，运行效率总不及C++。新一代SuperMap 组件式GIS的内核采用C++构建，具有高效的运行效率，对用户提供Java和.NET组件，方便用户学习使用和充分利用集成开发环境的能力，是高效运行和高效开发的完美结合。

　　(5) 具有完整的解决方案

　　新一代SuperMap 组件式GIS是SuperMap GIS Universal（SuperMap共相式GIS）的一部分。共相式GIS是可以支持任意硬件、任意操作系统、任意数据库、任意数据格式、任意开发语言、任意网络结构乃至任意GIS之间互操作的GIS软件平台发展的新的构思和理念，是解决GIS复杂异构问题的完整解决方案。SuperMap GIS已经形成了共相式GIS的构架，新一代SuperMap组件式GIS是这一构架的重要组成部分。

　　1.6 结论

　　IT技术，尤其是主流软件开发技术的快速发展，要求GIS软件必须紧跟技术发展的潮流和趋势。本文在介绍和分析几种可同时支持两大主流开发平台的实现模式后，提出基于共相思想的C++扩展模式是最为彻底和完美的解决方案。并通过SuperMap Objects.NET和SuperMap Objects Java两个新一代GIS组件的研究和开发验证了这一解决思路的可行性。

　　作者简介：
　　曾志明（1978－），男，湖南衡阳人。2000年毕业于北京师范大学资源与环境科学系，获地理科学学士学位，2005年毕业于中国科学院地理科学与资源研究所，获理学博士学位。目前工作于北京超图地理信息技术有限公司，主要从事SuperMap GIS软件底层技术开发。