国土空间信息化顶层设计应用系统架构分析.docx
《国土空间信息化顶层设计应用系统架构分析.docx》由会员分享,可在线阅读,更多相关《国土空间信息化顶层设计应用系统架构分析.docx(33页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、规划国土委信息化顶层设计应用系统架构分析目录规划国土委信息化顶层设计1应用系统架构分析1一、应用系统现状5(一)基于统一基础平台的应用系统建设5(二)、系统主要问题6二、应用系统架构设计13(一)、总体架构/应用系统蓝图13(二)、应用架构图16(三)、规划国土房产电子政务平台19(四)、应用部署参考模型图21(五)、系统运行架构21(六)、系统体系框架22(七)移动框架23三、基础平台架构设计25(一)、基础平台总体架构25(二)、基础平台应用保障29一、应用系统现状(一)基于统一基础平台的应用系统建设信息中心从2003年开始进行基础平台的建设,2005年组建平台研发组,专门从事电子政务基础
2、平台研发,经过信息中心技术团队的多年努力工作,基础平台建设和应用系统建设取得了丰硕的成果。在基础技术体系上,形成了以丰富实用的基础组件库为基础、以开发框架为支撑、相关开发工具为辅助的基于J2EE体系架构的基础应用开发技术体系,为各类应用系统的开发提供了一个稳定高效的基础开发环境,快速应用生成工具为基础技术体系的推广应用提供了有力保障;在基础服务体系上,相继建设了邮件服务、手机短信服务、即时消息服务、数据交换服务、图形服务、工作流引擎、集中认证服务、统一安全验证服务、业务数据服务、任务引擎等公共基础服务,为电子政务相关系统的开发和运行提供了良好的基础环境。在运行管理体系上,相继建设了用户管理、组
3、织机构管理、局管理、岗位管理、通用岗位管理、角色管理、权限管理、资源管理、GIS资源管理、群组管理、常用语管理、数据字典管理、主键生成配置管理、数据权限管理、节假日管理、菜单配置管理、用户委托代理管理、参数管理、密码强壮性管理、业务数据服务配置管理、套打管理、自定义查询报表管理、短信服务监控、系统运行异常监控等系统运行管理功能,为电子政务相关系统的运行提供了良好的基础环境。在安全保障体系上,相继建设了包括功能权限和数据权限的权限体系、集中认证服务、统一安全验证服务,为电子政务相关系统的开发和运行提供了良好的基础环境。在标准规范建设上,技术标准规范、开发规范、技术架构说明书等技术文档和相关评审制
4、度、验收流程等规范制度,为基础技术体系、基础服务体系、安全保障体系能够被很好的执行和发展提供了有力保障;在应用系统的建设上,信息中心积极的将基础平台在各个应用系统建设项目中进行广泛、深入的推广应用,先后在政务会议系统、国房局人力资源管理系统、国房局征地收地系统、国土所综合业务系统、车辆管理系统、接待管理系统、土地利用计划台帐系统、政策性住房管理系统、物业管理系统(外网),规划局规划电子政务平台(约30多个子系统),规划土地数字监察平台等多个应用项目的开发中取得了良好的效果。(二)、系统主要问题在基础平台和应用系统建设过程中,出现了一些问题,主要有:1、电子政务平台与业务系统的关系需要厘清电子政
5、务平台应该独立于各种业务应用系统,专注于满足业务应用系统共通的需求,比如业务流转、权限控制等等,而业务应用系统只负责某一类专门业务,两者的关系就像高速公路与运行其上的各种交通工具的关系一样。电子政务平台与业务应用之间应该有良好定义的调用接口API,这样业务开发人员可以很方便在电子政务平台基础上搭建各种业务应用,而电子政务平台的演变,也不会影响业务应用的正常运行。但是,我们目前的电子政务平台还达不到这样的要求,总的感觉就是平台该做的没做好,不该做的又做了很多。比如,规划很多应用都集成在办文系统中,如果要扩展这一部分业务应用,就可能动到办文系统,扩展工作非常复杂,开发完了还要进行回归测试,防止新模
6、块对办文系统造成不必要的影响;而一些新的应用如果要搭建在办文系统上,实现起来也非常困难。我们曾经开发过一个系统,业务处室要求处理过程必须使用办文,由于缺乏现成的通用接口,我们自行开发了启动办文、办文流转、办文确认等模块,开发和应用调试过程都很麻烦。为了避免这些麻烦,很多业务应用已经转向使用工作流,但有些业务流程根本没有明确的流程定义,需要按照业务人员的意见进行“自由流”,而且工作流系统目前还缺乏督办、挂起等功能,或者有些用户已经习惯于办文,对业务表格很抵触。这样许多业务应用还需要依赖办文系统,因此对办文系统进行提升,以更好的支持业务应用开发,还是有重要的意义。2、应用架构中缺少服务层业务应用系
7、统开发过程中不断出现的一个问题是:需要重复地开发对一些相同业务数据的读取模块。即使需求只有很小的变化,不同业务系统也要重新写一个自己的模块。这种现象不仅出现在业务数据获取,而且也出现在其他一些地方,如图形交互服务中在某一图层上进行要素维护操作,或者通过某一类要素主键,获取其基本属性信息或坐标数据等,都是各自业务系统自己开发自己的模块。如果我们有强大的服务层组件,很多业务应用开发就只需要在服务目录中,查询自己感兴趣的服务,直接调用这些服务即可,不用重复开发相关模块,也不用自己去确认数据源是哪个表,或者SQL语句的逻辑等等这些问题,而且这样业务逻辑的变化,只需要更新服务层组件,则所有调用该服务的业
8、务应用都可以获取最新的数据服务。服务层缺失另一个现象就是没有消息队列,很多业务数据如果用抽取(PULL)的方式会很麻烦,需要后台进程轮询,而且各自维护一套后台进程,服务器消耗很大,维护也很麻烦。如果有消息队列服务的话,各个业务系统将一些重要的业务信息,如一书三证核发、建设用地审批、土地交易、合同签发、产权登记变化,甚至是会议纪要下发等,都自动发送到队列中,感兴趣的业务应用只需要订阅这些服务,一旦消息产生,队列就推送(PUSH)到业务应用,业务应用再根据预定的逻辑进行处理,这样能实现很多业务的关联,解决现有很多业务互相脱节的问题。3、应用界面不统一,UI平台组件展现力不够规土委存在很多应用,每个
9、应用的界面布局和操作方式都不太一样,界面风格差异非常大,五花八门,缺少统一的界面设计标准,需要解决界面风格统一的问题,制定一套标准约定不同层次界面的布局、界面内元素(表格、按钮、图标、输入框等)的大小、颜色等,各项目组必须严格按此执行。还有一个问题,主要是一些UI平台组件展现力不够,使我们的业务应用开发出来像是老古董。很多管理局的业务人员不断反映我们的业务应用比较难用,不是说我们的应用系统没有那么花哨,相反是我们的应用系统操作不够简洁、在易用性方面存在很大的问题,用户体验很差。而且,我们的UI平台组件中,很多展现力不够直观丰富,界面也显陈旧,这一点希望平台人员能够注意,开发过程中注意用户体验问
10、题。建议在电子政务平台加强该功能,加大电子政务平台的投入,快速的更新和提升电子政务平台,提供更多的服务(建议把图形服务纳入到电子政务平台),支持应用系统快速开发。4、多套用户组织信息无法同步目前系统中存在多套用户组织信息,包括域控制器的用户组织、权限的用户组织、人事的用户组织、即时通讯的用户组织等等,这些用户组织无法及时和自动同步,导致用户组织信息不一致。外网平台也同样使用平台的权限体系,但是数据并不完全一致。5、应用部署粒度不一致在正式环境中部署的应用有些比较庞大,有些又粒度太细,最好能给出一个约定。6、应用系统中存在业务割裂房地产业务与规划、国土业务衔接目前还存在割裂现象,比如房地产登记与
11、地籍管理之间的同步,房屋测绘成果的相对独立,房屋拆迁与产权登记的衔接,土地交易和房产拍卖与产权登记的衔接,确权登记后规划调整情况等等。典型问题比如缺乏基本楼盘表管理。7、系统之间共享缺乏统一规划规划国土房产业务绝大部分均有相关信息系统支持,系统之间的信息共享不够,其中有业务层面因素,也有系统建设方面的因素,主要是缺乏统一资源管理。典型问题比如系统分散、业务数据多头录入。8、内外网应用模式对系统集成构成制约受内网应用为主模式影响,制约房地产应用系统在公共服务方面的扩展,制约房地产应用系统与外部系统之间的紧密联系,如与部、省的联网,与市内地税、银行等部门的信息共享。9、图形系统目前存在多套用户、多
12、套架构的问题国土图形系统使用的是vb语言,基于arcmap进行的二次开发,规划图形系统使用的是c#语言,基于arcgis engine进行的二次开发,空间信息平台使用java,基于arcgis server9.3进行二次开发,同样的功能要开发三次,同时需要多人进行维护,这对人力和时间的资源极大的浪费,目前电子政务部开发的规划国土一张图信息系统,监测技术部建设的监测技术平台、空间信息部即将进行的空间信息平台二期都已经确定使用flex作为开发语言,但是在系统的架构和细节上还没有完全达成一致,很可能还会造成各自的差异,希望能继续统筹考虑,将中心的gis技术架构统一,并制定出图形方面的开发规范,一方面
13、可以提高各个部门的工作效率,另一方面可以减少系统的维护工作量。10、目前中心缺乏一个可供系统开发和数据维护的字典通过最近的系统开发和数据维护的工作中发现最重要的一个问题是缺乏一个可以查找的数据中心的字段,当开发一个系统的时候需要设计调用业务数据的时候,不知道该去哪里查找需要的资源,当需要进行修改业务数据的时候,不知道修改后会对哪些业务数据造成影响,例如,宗地的业务数据和图形数据中都有一个字段lam_stage,表示宗地的状态,其中A表示产权合同、T表示合同、J表示产权,当产权系统给该宗地办证的时候会自动将该宗地的业务数据和图形数据的这个字段覆成J,而地政系统在重新开发的时候却没有注意到这个问题
14、,从而该改写成T和A的没有去改写,造成数据产生问题,这就是系统开发的时候没有一个数据标准造成的,此外宗地的图形数据中还有一个标志assem_flag,该标志在图形系统显示的宗地的时候设置了过滤,如果为5的时候则在图形系统中布显示该宗地,今日数据部在进行数据清理的时候将大量宗地的该表示设置成5,造成龙岗等分局的用户在查找宗地的时候发现该宗地在图形中已经丢失,这就是进行数据维护的时候没有考虑会对系统造成影响产生的结果。所以系统今后中心加大力量将数据中心的字典工作完善,如有涉及数据的工作首先进行查询,是否会对其他系统或工作造成影响。11、缺少完整的业务架构和技术架构指导应用系统设计开发系统顶层架构应
15、该从两个方面展示:业务视图、技术视图。当然还包括物理和部署视图。这里主要考虑业务和技术两个方面。业务架构按照大粒度的业务模块定义整个组织结构内部业务流转以及业务架构边界。同时还有相关与其他组织的业务活动接口。业务架构和技术架构设计时需要有一定的前瞻性,不能是设计好就是落后的。统一的业务架构和技术架构最大的作用就是指导应用系统设计开发,规范应用系统应关注的业务流程以及与其他业务模块之间的关系(数据流),规范采用的技术规范和架构等,防止走弯路和错路。目前的问题是做应用系统项目时,没有相应的技术或业务架构指导和规范业务系统设计,业务设计时没有考虑纳入到整个业务架构中,容易造成设计出的应用系统在业务层
16、面孤立,形成业务和数据孤岛。在技术上,没有统一的技术架构,容易造成技术的多样性,增加维护的运营的复杂度。12、缺少完整的系统运营管理规范规土委现有存量的应用系统和今后逐步开发的应用系统都面临庞大的运营管理问题。在现实运营管理中,缺少相应的规范的。例如:数据修改,功能维护等。这些维护工作缺少相应的审核过程。维护人员未必是应用系统开发设计人员,在维护工作中未必完整理解系统设计。因此需要一套管理规范保证应用系统在运营过程中的稳定性。二、应用系统架构设计(一)、总体架构/应用系统蓝图总体架构的目标在于:从管理层面,对规划国土委信息化建设的最终目标实体进行逻辑上的层次分解,在概念层面形成统一的定义,这些
17、定义是信息化组织实施体系与用户群体需要达成的统一共识。总体架构的实质是信息化组织实施体系向用户群体描述的、并获得用户群体认可的信息化应用系统蓝图。1、资源层资源层是面向硬件的基础设施,包括各类硬件、操作系统、各类网络资源(政务内网、政务外网、各种专线、无线网络)。资源层由信息化建设实施单位即规划国土房产信息中心进行维护,规划国土委的信息化服务对象都是其用户。2、支撑层支撑层是面向软件的基础设施,包括对软硬件资源运行状况、应用系统运行维护进行综合管理的IT管控平台,用于应用系统生产、运行维护的电子政务基础平台,服务于数字XX的空间基础信息平台,以及规划国土房产数据中心。支撑层由信息中心进行维护,
18、应用于应用系统生产、IT资源运行维护、地理信息应用。3、工作层工作层是面向工作人员开展日常业务、政务管理的软件系统,包括规划国土管理业务域(规划国土管理系统簇)、业务评价业务域(业务评价系统簇)、房产管理业务域(房产管理系统簇)、数字监察平台、政务管理业务域(政务管理系统簇)、数据管理系统。工作人员通过工作层的软件系统开展各项日常业务、政务管理、数据处理。4、监管层监管层是面向规划国土委监察部门的全业务、全过程、全生命周期的逻辑层,监管层只包含了一个系统:监测监管平台。监测监管平台提供给监察管理部门使用,同时可以延伸到规划国土委的委领导、处室及管理局的领导,部分功能可以延伸到市领导、省厅领导、
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 国土 空间 信息化 顶层 设计 应用 系统 架构 分析
限制150内