水务局水务信息服务中心系统建设项目530页（2024年修订版）.docx

水务局水务信息服务中心系统建设项 目录 第一章 功能的总体设计和实现的功能说明 7 第一节 设计原则 7 第二节 总体架构 9 第一条 基础支撑环境 10 第二条 水务数据中心 10 第三条 水务信息共享平台 11 第四条 业务应用集成框架 13 第五条 标准规范体系 13 第三节 系统开发技术路线 13 第一条 无缝对接数字XX地理空间框架信息平台 14 第二条 基于SOA的体系架构的系统设计 15 第三条 基于ServiceGIS实现水务信息共享 18 第四条 二三维一体化技术 26 第五条 移动GIS技术 28 第六条 综合集成化的业务服务模式 30 第四节 系统开发关键技术 32 第一条 服务式地理信息共享技术 32 第二条 高性能地理信息访问技术 34 第三条 富客户端(RIA)技术 39 第四条 知识可视化技术 40 第五条 综合集成方法与技术 42 第六条 云计算技术 46 第七条 模型驱动的空间与业务数据集成建库技术 48 第五节 系统集成方案设计 49 第一条 集成原则 49 第二条 系统集成边界 50 第三条 系统集成设计 51 第六节 公共平台 52 第一条 概述 52 第二条 公共平台 53 第三条 数据管理 70 第四条 数据字典 79 第五条 资源目录 80 第六条 数据汇集系统 81 第七节 服务注册系统设计 82 第一条 需求规定 82 第二条 环境要求 83 第三条 体系结构设计 85 第四条 功能部件划分 85 第五条 部件协作关系设计 91 第六条 功能部件设计 92 第八节 水利普查成果展示与查询子系统 146 第一条 建设目标 147 第二条 建设内容 148 第三条 功能框架 155 第四条 展示及功能设计 156 第五条 基本资料查询 160 第六条 主题成果查询 174 第七条 统计分析成果查询 180 第八条 空间分析成果查询 182 第九条 多维分析查询 183 第十条 子系统集成 191 第二章 软硬件环境及选型 192 第一节 硬件环境 192 第二节 软件环境 201 第一条 项目实施组织 207 第二条 项目团队管理 208 第三节 项目质量管控指标体系 212 第一条 质量保障组织 212 第二条 质量保障目标 216 第三条 质量保障计划 217 第四条 质量保障技术措施 221 第五条 质量保障管理措施 225 第六条 安全生产和保密措施 227 第七条 工程建设管理方案 231 第四节 标准规范说明 382 第一条 建设标准 382 第二条 保密标准规范 398 第三章 工程业务化运行及稳定性维护说明 399 第一节 工作内容 400 第一条 技术支持内容 400 第二条 执行情况 400 第三条 服务队伍 401 第四条 运行维护计划和方案 402 第二节 日常工作情况 405 第一条 系统日常维护记录 405 第二条 紧急事件应急处理 414 第三条 工作内容分析 415 第三节 问题和意见建议 416 第四章 工程社会经济效益及推广前景简要说明 417 第一节 工程社会经济效益 417 第一条 经济效益 417 第二条 社会效益 418 第二节 成果应用推广 418 第五章 工程受表彰证书复印件 419 第六章 工程主要文档目录 419 第七章 工程已有的长效机制(包括相应的组织机构、规章制度、运行经费、更新机制等) 424 第一节 工作内容 424 第一条 技术支持内容 424 第二条 执行情况 425 第三条 服务队伍 425 第四条 运行维护计划和方案 427 第五条 运行费用和协作事项 430 第二节 项目的质量管理与保障措施及实施的效果 430 第一条 组织和职责 430 第二条 质量管理工作 432 第三节 系统应急备份方案或措施 435 第一条 事件分级分类 435 第二条 应急响应人员及职责 437 第三条 应急处置 437 第四条 后期处置 439 第五条 保障措施 439 第八章 项目的工作报告和技术报告 440 第一节 项目的工作报告 440 第一条 项目概况 440 第二条 项目投标 445 第三条 合同管理 445 第四条 质量管理 445 第五条 进度管理 451 第六条 资金管理 456 第七条 经验与建议 456 第二节 项目的技术报告 457 第一条 设计原则 457 第二条 总体架构 459 第三条 系统开发技术路线 466 第四条 系统开发关键技术 483 第五条 系统运行模式设计 492 第六条 标准规范体系建设 497 第七条 应用系统集成 499 功能的总体设计和实现的功能说明 设计原则 水务信息服务中心的建设以应用和服务为导向，采用先进、成熟和实用的技术，建立安全可靠的管理机制，在平台建设中，应遵循下列原则： 1)标准化原则 为了确保水务信息服务中心的基础性和公用性，必须参照国际、国家、地方和行业的有关标准，建立统一的标准和共同遵守的规范，使公用性、基础性的数据库以及在此之上构建的公用信息服务和数据交换接口的能为水务局及下辖各区县及水务局业务部门等相关单位所接受和使用。 (1)数据规范化 系统对空间数据库和属性数据库的结构和内容分别进行规范化设计。数据分类与代码的规范化是系统扩充联网、实现信息交流与数据共享的基础。系统数据的分类与代码采用国家标准结合水利行业的实际情况，并根据本平台内容和特点，制定扩充代码。 数据质量检查规范化是数据库质量的保证。在本项目建设过程中，遵照统一制定的数字化规程、数据控制标准和精度要求，数字化过程中的每一工序均需接受质量检验。 (2)服务接口的标准化与规范化 要确保水务信息服务中心提供的信息服务接口的标准化与规范化，发挥该系统的基础性与公用性的作用。服务要基于标准的0GC和REST协议，服务接口参数要规范化，以确保应用系统开发时候调用服务的可控性。 2)开放性和扩展性原则 信息系统的开放性是系统生命力的表现，只有开放的系统才能够兼容和不断发展，才能保证前期投资持续有效，保证系统可分期逐步发展和整个系统的日益完善。系统在运行环境的软、硬件平台选择上要符合行业标准，具有良好的兼容性和可扩充性，能够较为容易地实现系统的升级和扩充，从而达到保护初期阶段投资的目的。 平台在设计上充分考虑系统的扩展性和开放性，必须能方便地实现其他信息的扩展，利用提供的标准接口，方便市水务局及其下辖区县、市相关水务业务部门通过专用网络在线获取水务信息服务，并快速应用于各自的专业系统中。 3)松散耦合 各个子系统之间应遵循松散耦合的原则，即在各个子系统之间不设置强制性的约束关系。一方面避免级联、嵌套的层次太多；另一方面避免不同子系统的同步问题。子系统之间的联系可以通过重新输入、查询、程序填入等方式建立，子系统之间的关联字段是冗余存储的。 总体架构 水务信息服务中心的总体架构包括基础支撑环境、水务数据中心、水务信息共享平台、业务应用集成框架和标准规范体系几部分，系统架构如下图所示： 图1-1总体架构图 系统建设总体上将采用面向S0A架构来组建，软件平台建设采用B/S和C/S两种混合架构模式。其中，服务共享平台和业务应用采用B/S架构模式；数据管理平台将采用C/S结构。 基础支撑环境 基础支撑环境主要包括信息中心运行需要的网络、服务器、存储设备、操作系统与数据库管理系统、空间及影像数据加工系统等。基础支撑环境的建设，将改变目前不同应用系统单独配置硬件的做法，在充分共用现有设施设备和基本软件基础上，重新规划统一的硬件资源平台，建设统一的应用发布和数据库服务器及集中存储设备，实施硬件及安全设备的统一管理，降低应用系统硬件建设成本，提高资源利用率。 水务数据中心 水务数据中心建设主要任务是整合水务局现有的各类数据和XX市水利普查数据，设计面向对象的水利空间与业务一体化数据模型，统一编码规范，建设水利综合数据库，并构建数据采集与汇聚，数据管理维护和数据交换等软件系统。 数据资源包括基础地理数据、水利基础空间数据、水利专题空间数据以及各类监测数据和业务应用数据等。其中基础地理数据包括基础矢量数据、基础地形数据、遥感影像数据；水利基础空间数据包括水系、流域分区、水功能区划、水利工程、水利行业单位等公用的空间数据；水利专题数据包括防汛抗旱数据、水资源管理数据、饮用水源地、水土保持、灌区等专题应用的空间数据；监测数据包括水情数据、雨情数据、工情数据、水质数据、取水量数据等。 水务数据中心建设以空间数据为框架，整合各类数据资源。水务空间数据库的建设是核心工作，本项目将构建基于面向对象空间数据模型的水利空间数据库，面向对象的空间数据管理模式，是当前国内外GIS发展的最新一代的数据结构。它在综合了上几代数据管理模式优点的基础上，进一步提高了空间数据管理的结构化程度，通过建立完整统一的数据模型，实现了对象几何图形特征与对象属性特征、对象个体特征与对象关系特征、对象当前时态特征和历史时态特征、对象实体数据和元数据的一体化管理，极大地提高了水利空间数据管理的结构化程度，可有效地满足未来数据管理维护便捷性和数据应用的灵活性的双重需要。在充分理解水利空间对象的内在关系和潜在应用需求的基础上，通过面向对象的空间数据模型设计，最大限度地将各水利业务对象按照地理要素分类和要素关系完整地组织在一起，不仅实现了对象的可视，而且能够很方便地实现各种对象地理分布关系乃至行为传递的追踪与分析，进一步实现了水利对象由直观地“看”到方便地“算”的转变，其优势是以往仅做到要素分层的GIS管理模式所无法企及的。 水务信息共享平台 水务信息共享平台对下实现水务数据中心的各类数据的服务发布，对上为各个业务系统集成提供基础性、公用性的公共服务，是整个项目建设的关键环节，公共服务平台包括水务一张图综合门户、基础信息服务、信息快速上报及发布服务、实景三维服务、视频监控服务、移动应用服务和系统运行维护服务。水务信息共享平台运行在数据中心和业务应用之间，统一向业务应用系统提供数据整合、共享、运行维护及其它公共应用服务。水务信息共享平台由基础支撑服务层和公共应用服务层两部分构成，其中基础支撑服务包括数据交换共享、运维管理服务、决策支持模型等，公共应用服务包括水务基础信息查询、移动应用、信息快速上报、视频浏览、三维实景展示等。 决策支持模型包括洪水预报模型、水污染扩散模型、给排水管网模型、溃坝分析模型、水量联合调度模型、干旱监测模型和地下水模型等，通过集成各种水利专业模型，并校正XX本地化的模型参数，争取预测分析水平，提供辅助决策能力。 水务信息共享平台不仅提供服务，还为应用系统的开发提供调用服务的二次开发API,以帮助应用系统开发人员基于水务信息共享平台快速的构建业务应用系统，同时，水务信息共享平台还提供一个应用开发的公共框架。水务信息共享平台建设将给应用系统的开发带来显著变化：一是避免过去针对一种应用配套建立一个数据库、开发一个转换程序的做法，起到一源多用、功能复用、综合展示的功效；二是业务系统开发只需考虑信息在页面中的具体展示，而不考虑信息获取的具体实现，系统开发将因此变得非常容易和快捷，建设成本显著降低。 业务应用集成框架 通过应用集成建设，集成各个业务应用，并检验和完善基础环境、数据中心和服务共享平台对业务应用建设的支持能力，为后续应用系统开发奠定基础。 一期开展已建成运行系统的集成应用建设，二期开展正建或新建系统的应用集成，包括水利普查成果查询与展示系统、水务信息移动查询系统、防汛应用系统、水资源管理系统、旱情监测系统等应用集成建设。 标准规范体系 标准规范体系是水务信息服务中心建设和运行的基础。在标准规范的指导和约束下，处理和集成数据资源并将数据产品发布成标准服务，将功能封装成标准服务接口。平台按标准规范进行建设和维护，用户按标准规范进行使用。另外，安全保障主要依托水务局现有的安全保障体系，项目建成后的运行维护纳入统一的运维管理工作。 系统开发技术路线 以面向服务的方式，对原有业务按照活动单元进行拆分，划分标准化数据处理单元，进行组件化封装。各组件之间建立标准的、中立的接口，方便灵活组合。在业务需要时按照业务流程与业务关系，对组件进行拼接组合，形成满足用户业务需求的服务。同时也实现了相关组件单元处理结果的共享，降低系统开销。组件化服务具有很强的适应性，随着业务的发展与变迁，只需对相关组件进行修改，就能提供新的服务，大幅降低对原有系统的破坏。不但节约了维护成本，并保证了系统的稳定、安全与运行效率。 图1-2业务组件化服务 无缝对接数字XX地理空间框架信息平台 数字XX地理空间框架信息平台，基于SuperMapServiceGIS等技术，采用统一规范整合和完善XX市现有地理信息资源，建成了多尺度空间框架数据库，在此基础上完成了信息共享与管理服务平台以及地理信息共享与分发机制的建设，通过地理信息共享服务模式为政府、公众和行业用户提供开放式的地理空间信息服务，解决了公共地理空间数据重复建设、格式坐标不统一，行业间数据不能共享的突出问题。为保证本项目与数字X平台的无缝对接，在系统设计方面，将充分考虑数字XX项目建设所采用的架构及关键技术。 基于SOA的体系架构的系统设计 水务信息服务中心的建设将基于S0A的技术架构进行设计，系统架构具备适应业务变化和未来发展需求的能力。系统架构中将采用遵循业界标准、开放成熟的产品，如采用符合J2EE技术标准的ESB产品和应用服务器。 SOA是一种粗粒度、松耦合的软件架构，其服务之间通过简单、自描述的服务接口进行通讯，不涉及底层编程接口和通讯模型。SOA具有以下几个特点： 松散耦合：松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言，每个系统都可以实现独立管理。松散耦合给服务提供者和服务请求者提供了独立性，服务实现的修改完全不会影响到服务使用者，但要求基于标准的接口和中间件来积极地管理和代理终端系统之间的请求。 粗粒度服务：服务粒度指的是服务所公开功能的范围，一般分为细粒度和粗粒度。其中细粒度服务是那些能提供少量商业流程可重用性的服务，粗粒度服务是那些能够提供高层商业逻辑的可重用性服务。选择正确的抽象级别是SOA建模的一个关键问题，设计中应该在不损失相关性、一致性和完整性的情况下，尽可能地进行粗粒度的建模。 可重用性：面向服务架构最基本的特点还在于它的软件可重用性，因为每一个服务在设计时就是相互独立的，与系统中别的部分之间没有依赖关系，所以同一系统内部的服务可以被其他服务所调用，不同系统之间也可以相互调用对方提供的服务，充分提高了软件的可重用性。 协议无关性：通过底层的适配器可以完成消息在多种协议上的传输，以及在多种协议上的协调管理。 快速的开发能力：通过Web服务组合可以快速的完成某项具体的业务操作，通过服务提供者与服务请求者之间的无干扰的开发，可以使得两者之间并行开发。 编码灵活性：可基于模块化的底层服务，采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。 一个完整的S0A架构由三个部分组成，如下图： 图1-3S0A三要素 服务提供者(ServiceProvider):服务提供者是一个可通过网络寻址的实体，它接受和执行来自消费者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。 服务消费者(ServiceConsumer):服务消费者可以是一个请求服务的应用、服务或者其它类型的软件模块，它从注册机制中定位其需要的服务，并通过传输机制来绑定该服务，然后通过传递契约规定格式的请求来执行服务功能。 服务注册管理者(ServiceReGISter):服务注册机制是一个包含可用服务的网络可寻址的目录，它是接收并存储服务契约的实体，供服务消费者查找和定位服务之用。 水务信息服务中心的建设将基于服务式GIS开发平台SuperMapiServer发布GIS服务和水利专业功能服务，是服务提供者。成果展示与查询子系统将基于RIA技术封装客户端开发组件，客户端开发组件提供可视化的开发方式，调用多维分析子系统、空间分析子系统发布的服务，因此客户端可视化组件是服务消费者。本项目中其他业务系统也可以直接调用服务进行开发，这些业务系统也是服务消费者。多维分析子系统、空间分析子系统与ESB产品进行集成，ESB产品实现服务的集成，路由，注册，发现等功能，承担了服务注册管理者的角色。 图1-4S0A三要素的实现 基于ServiceGIS实现水务信息共享 水务信息服务中心将基于SOA的技术架构进行开发，系统架构具备适应业务变化和未来发展需求的能力。系统架构中应采用遵循业界标准、开放成熟的产品。 ServiceGIS(服务式GIS)是一种基于SOA架构的GIS技术体系，它支持按照一定规范把GIS的全部功能以服务的方式发布出来，可以跨平台、跨网络、跨语言地被多种客户端调用，并具备服务聚合能力以集成来自其他服务器发布的GIS服务。 ServiceGIS能更全面地支持S0A,通过对多种S0A实践标准与空间信息服务标准的支持，可以使用于各种S0A架构体系中，与其它IT业务系统进行无缝的异构集成，从而可以更容易地让应用开发者快速构建业务敏捷应用系统。与基于面向组件软件工程方法的组件式GIS相比，服务式GIS继承了前者的技术优势，但同时又有一个质的飞跃。 ServiceGIS可以提供开放的、易于定制和扩充的、可复用和聚合的地理空间信息服务，具备很强的兼容性、适应性和业务敏捷性，能为水务信息服务中心提供一个理想的架构体系。 1)S0A架构的特点 SOA是一种粗粒度、松耦合的软件架构，其服务之间通过简单、自描述的服务接口进行通讯，不涉及底层编程接口和通讯模型。S0A具有以下几个特点： (1)松散耦合： 松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言，每个系统都可以实现独立管理。松散耦合给服务提供者和服务请求者提供了独立性，服务实现的修改完全不会影响到服务使用者，但要求基于标准的接口和中间件来积极地管理和代理终端系统之间的请求。 (2)粗粒度服务 服务粒度指的是服务所公开功能的范围，一般分为细粒度和粗粒度。其中细粒度服务是那些能提供少量商业流程可重用性的服务，粗粒度服务是那些能够提供高层商业逻辑的可重用性服务。选择正确的抽象级别是SOA建模的一个关键问题，设计中应该在不损失相关性、一致性和完整性的情况下，尽可能地进行粗粒度的建模。 (3)可重用性 面向服务架构最基本的特点还在于它的软件可重用性，因为每一个服务在设计时就是相互独立的，与系统中别的部分之间没有依赖关系，所以同一系统内部的服务可以被其他服务所调用，不同系统之间也可以相互调用对方提供的服务，充分提高了软件的可重用性。 (4)协议无关性 SOA架构通过底层的适配器可以完成消息在多种协议上的传输，以及在多种协议上的协调管理，从而保证系统的协议透明。由于协议无关性，服务提供者与服务请求者之间的开发是无干扰，使得两者之间可以并行开发。 2)服务式GIS的组成：服务器、客户端和服务规范ServiceGIS主要由三个要素组成，如下图所示： 图1-5服务式GIS三要素 (1)服务端 ServiceGIS的服务器是服务的提供者，可以遵循某一种或多种规范发布服务。服务规范可以是公认的服务标准，如WMS、WCS、WFS、WPS和GeoRSS等，同时GIS平台软件厂商也可以自定义服务规范。 (2)服务规范 服务规范可以是公认的服务标准，如WMS、WCS、WFS、WPS和GeoRSS等，同时GIS平台软件厂商也可以自定义服务规范。 图1-6基于服务规范的调用 (3)客户端 ServiceGIS的客户端是服务的接受者，一般地，可分为瘦客户端(ThinClient)和胖客户端(RichClient)两种，前者通常体现为浏览器中加载轻量级的插件，甚至无需任何插件，由浏览器直接执行来自服务器端的脚本实现；后者可以是通用的或专用的GIS桌面软件和组件开发平台，也可以是另一个服务器直接作为客户端，聚合前一个服务器发布的服务。 3)服务式GIS的服务规范 开放地理信息系统协会(简称OGC)致力于为地理信息系统间的数据和服务互操作提供统一标准，其推出了OpenGIS规范，包括WMS、WFS、WCS等。0GC引领着空间地理信息标准及定位基本服务的发展目前在空间数据互操作领域，基于公共接口访问模式的互操作方法是一种基本的操作方法。通过国际标准化组织(IS0/TC211)或技术联盟(如0GC)制定空间数据互操作的接口规范，GIS软件商开发遵循这一接口规范的空间数据的读写函数，可以实现异构空间数据库的互操作。基于http(Web)XML的空间数据互操作是一个很热门的研究方向，主要涉及WebService的相关技术0GC和IS0/TC211共同推出了基于Web服务(XML)的空间数据互操作实现规范WebMapService,WebFeatureService,WebCoverageService以及用于空间数据传输与转换的地理信息标记语言GML。 (1)WMS WMS即Web地图服务。WMS利用具有地理空间位置信息的数据制作地图。其中将地图定义为地理数据可视的表现。这个规范定义了三个操作：GetCapabitities返回服务级元数据，它是对服务信息内容和要求参数的一种描述；GetMap返回一个地图影像，其地理空间参考和大小参数是明确定义了的；GetFeatureInfo(可选)返回显示在地图上的某些特殊要素的信息。WMS提供了基于图像格式发布(JPG、PNG等)的能力，即可直接在客户端与异构GIS平台的数据叠加显示，也可以在服务端与异构GIS平台的数据叠加显示发布。基于WMS的地图服务发布适合于地图数据的静态显示，不能实现编辑、查询和选择等进一步的功能。WMS适合于发布那些仅用做背景的数据，特别是遥感影像数据，发布速度最快；WFS适合于发布那些需要在服务接收端需要进行查询、选择、空间分析和运算以及编辑(T-WFS)的数据，速度较WMS稍慢。在水利数据共享与服务系统中，可根据各类数据的应用特点，灵活应用这两种方式。WMS和WFS以及WCS的地图数据发布服务适合于各类桌面GIS软件、组件式GIS软件、ServerGIS、ServiceGIS等各种形态的GIS平台。 (2)WFS WFS即Web要素服务。WFS返回的是要素级的GML编码，并提供对要素的增加、修改、删除等事务操作，是对Web地图服务的进一步深入。0GCWeb要素服务允许客户端从多个Web要素服务中取得使用地理标记语言(GML)编码的地理空间数据，这个远东定义了五个操作：GetCapabilites返回Web要素服务性能描述文档(用XML描述); DescribeFeatureType返回描述可以提供服务的任何要素结构的XML文档；GetFeature为一个获取要素实例的请求提供服务；Transaction为事务请求提供服务；LockFeature处理在一个事务期间对一个或多个要素类型实例上锁的请求。WFS提供了基于矢量格式发布地图数据的能力，同样即可以在在客户端与异构GIS平台的数据叠加显示，也可以在服务端与异构GIS平台的数据叠加显示发布。基于WFS的地图服务发布适合于地图数据显示、查询、选择、空间分析等功能。基于T-WFS的地图数据发布还支持在其他异构客户端。 (3)WCS WCS即Web覆盖服务。WCS面向空间影像数据，它将包含地理位置值的地理空间数据作为“覆盖(C0verage)”在网上相互交换。网络覆盖服务由三种操作组成： GetCapabilities,GetCoverage和DescribeCoverageType。GetCapabilities操作返回描述服务和数据集的XML文档。网络覆盖服务中的GetCoverage操作是在GetCapabilities确定什么样的查询可以执行、什么样的数据能够获取之后执行的，它使用通用的覆盖格式返回地理位置的值或属性。DescribeCoverageType操作允许客户端请求由具体的WCS服务器提供的任一覆盖层的完全描述。 以上三个规范既可以作为Web服务的空间数据服务规范，又可以做为空间数据的互操作实现方法。只要某一个GIS软件支持这个接口，部署在本地服务器上，其他GIS软件就可以通过这个接口得到所需要的数据。从技术实现的角度，可以将Web服务理解为一个应用程序，它向外界暴露出一个能通过Web进行调用的接口，允许被任何平台、任何系统，用任何语言编写的程序调用。这个应用程序可以用现有的各种编程语言实现。Web服务最大的特点是可以实现跨平台、跨语言、跨硬件的互操作，正是Web服务中的SOAP、WSDL和UDDI保证了Web服务的跨平台互操作的特性，所以，如何使用SOAP、WSDL和UDDI来部署、描述、传输和注册一个Web服务是实现Web服务的关键。由于SOAP、WSDL和UDDI是一套标准，不同的厂商可以有实现这些标准的不同产品，例如SUN、APACHE、IBM、Borland等公司推出的基于JAVA平台的Web服务工具包，以及微软提出的.NET平台等，这些工具为实现Web服务的开发、部署、描述提供了方便的工具，极大的降低了开发Web服务的复杂度。 WPS和自定义WebService服务发布能力是基于ServiceGIS的服务共享平台的最为强大的能力。传统的组件式GIS软件只能在客户端运行，必须要在客户端布署运行环境，不能在客户端之间共享功能组件。而基于微软的COM+和OMG的CORBA规范虽然提供了远程组件调用的机制，但这种调用是基于“进程”调用的，客户端与服务器是采用紧耦合方式，开发和部署的难度比较大。而基于ServiceGIS平台的WPS和自定义WebService服务发布和调用则是采用基于WebService来实现的，是采用松耦合的方式进行，开发和部署都非常容易。 4)基于标准规范的服务聚合与发布 图1-7服务聚合发布示意图 广义的服务聚合是指在系统结构的服务层或客户层将服务层提供的不同来源的服务进行融合，形成新的服务能力。狭义的服务聚合仅指服务器端的服务，在服务器端聚合。此种服务聚合后形成的新服务还可以进一步进行聚合再发布，形成多级服务聚合模式。 服务聚合在设计上具有服务聚合器，它是服务聚合的容器，用于将不同的服务聚合。对于Supe