智慧城管平台总体设计方案.docx
《智慧城管平台总体设计方案.docx》由会员分享，可在线阅读，更多相关《智慧城管平台总体设计方案.docx（13页珍藏版）》请在冰点文库上搜索。
智慧城管平台总体设计方案
智慧城管平台总体设计方案
1总体设计原则
●整体规划、分步实施、重点突破
数字化城市管理系统涉及部门多、事项杂，系统建设内容丰富，应统一规划、整体设计。
在项目实施中应根据原有系统情况和不同部门的状况，划分阶段，先易后难。
●技术先进、功能使用、扩展性好
在系统设计和建设中尽可能采用先进的技术和设备，保证先进性、安全性、可靠性和可扩展性。
各项功能设计要方便实用，操作简单，便于修改，容易定制，满足个性化要求。
●借鉴国内已有经验，选用成熟设计
为缩短建设周期，避免项目风险，建设中要借鉴国内同类系统建设经验并有所创新，在经过使用检验、成熟的设计和软件产品基础上加以改造升级。
●利用、保护原有投资，提升原有系统功能
在项目建设重要充分利用现有信息化资源，包括网络、服务器、信息和审批业务系统等。
在设计方案重要充分注意保护各部门已有的业务系统，在不改变原有系统业务流程基础上实现系统互联和信息共享。
通过系统建设不但要实现统一管理功能，还要为各部门业务处理增添新的功能带来好处和便利。
●加强身份权限管理，注重系统安全和可靠运行
系统在于个行业部门连接及提取数据是要确保各行业部门的网络与信息安全，确保本系统内部用户身份的唯一性、可靠性、不可抵赖性。
2系统总体架构
总体框技术架图如下：
●数据层
通过建立城市基础数据库的设计。
建立数字城管系统的数据层，包含各类基础空间数据库、事件部件数据库、地理编码数据库、人员组织机构数据库、业务数据库、综合评价数据库以及其他资源的数据库等。
●支撑层
支撑层是系统应用层与数据层之间的桥梁，通过数据交换平台整合数据中心的所有数据库，形成统一的数据平台，供各应用系统进行方便的调研和管理。
●应用层
建设开发符合需求的各个应用子系统：
无线数据采集系统、监督受理子系统、协同工作子系统、地理编码子系统、监督指挥子系统、综合评价子系统、应用维护子系统、数据共享与交换子系统、基础数据资源管理子系统、视频监控整合分析子系统、外勤车辆及外勤人员管理子系统共11个应用系统。
●表现层
表现层分为数据采集和信息展现两部分，为公众、信息员、领导提供多种方式的展现：
数据采集部分包括城管通采集终端、外网门户、呼叫中心、摄像头等；
信息展现部分采用丰富的表现介质，包括移动终端设备、外网门户、内网办公桌面、领导办公桌面等。
3业务流程设计
数字化城市管理模式的工作流一般包括受理、立案、派遣、处理、督察、核查和结案等七个环节阶段。
由监督中心负责统一受理来自社会公众、监督员、领导批示等多种来源的城市管理问题，经甄别立案后，由指挥中心进行统一派单处理。
3.1信息采集（收集）阶段
信息采集阶段的主要业务流程：
相关领导、监督员、市民通过城管通手持终端、手机、电话、城市管理门户网站等手段向监督中心提交城市管理问题信息。
城市管理问题信息来源主要包括领导批示、市民投诉和监督员巡查采集三种。
（1）领导批示：
城市管理相关领导通过政府公务外网或移动督办子系统登陆数字化城市管理系统，直接对城市管理问题进行批示立案。
（2）市民投诉举报：
市民发现问题，通过电话、手机、城市管理门户网站等多种方式向监管中心举报，监督中心登记公众举报信息，通知监督员核实，监督员通过城管通手持终端上报监督中心。
（3）监督员巡查采集：
监督员在所负责的若干单元网格内发现问题后，通过城管通手持终端及时上报，上报内容包括发生问题的位置、图像、表单、音频等信息。
3.2案卷建立阶段
案卷建立阶段的主要业务流程：
监督中心接收监督员上报问题，审核立案后，批转到指挥中心。
监督中心首先对获得的问题信息判断其信息来源，对于监督员上报和领导批示的问题可直接进行立案，对于市民投诉举报的信息，则交给监督员进行现场核实；对于不属实的信息进行注销，不符合立案条件的信息也进行注销；属实的信息进行部件/事件判定，将事件信息直接进行立案判断，对部件信息判断其在部件数据库中是否存在，存在则进行立案判断，不存在则需要添加临时部件，等专业部门更新数据后，再将临时部件替换成更新后的部件。
3.3任务派遣阶段
任务派遣阶段的主要业务流程：
指挥中心接收监督中心批转的案卷，派遣至相关专业部门处理。
监督中心立案后，由指挥中心根据问题责任部门分派任务，交由责任部门进行处理，同时对责任部门进行计时考评。
任务派遣遵循“属地原则（即按问题所在区域认定责任主体的原则）”与“属主原则（即按问题主管部门认定责任主体的原则）”。
对于一般案件，由指挥中心分派专业部门进行处理；对于重大案件，指挥中心派遣专业部门进行处理同时报送领导督办。
3.4任务处理阶段
任务处理阶段的主要业务流程：
相关专业部门按照指挥中心的指令，处理问题，将处理结果反馈到指挥中心。
对于一般案件，由专业部门进行处理，并将处理结果反馈到指挥中心；对于重大案件，由专业部门进行处理，同时主管领导督办。
3.5任务反馈阶段
处理反馈阶段的主要业务流程：
指挥中心将相关专业部门送达的问题处理结果反馈到监督中心。
3.6核查结案阶段
核查结案阶段的主要业务流程：
监督中心将问题的处理结果通知监督员进行核查、上报，核查信息与处理信息一致则进行结案，否则要求专业部门重新处理。
如果核查结果为问题已解决，则进行结案；如果核查结果为问题没有解决，则将问题信息流转到轴，指挥中心将责成专业部门进一步进行处理或重新进行处理。
3.7综合考评阶段
综合考评阶段的主要业务流程：
系统根据预先设置的考评指标、考评指标权重（分值）、考评周期，结合来自城市管理门户网站的考评数据，对城市管理相关责任主体进行考评，生成考评结果，并将部分考评结果信息通过发布公共信息子系统向社会发布。
综合考评主要包括区域考评、部门考评和岗位考评。
区域考评按一定周期对社区、单元网格不同层面区域进行考评，根据区域考评模型，由系统自动生成考评结果。
部门考评按一定周期对专业部门和各责任主体进行考评，根据部门考评模型，由系统自动生成考评结果。
岗位考评按一定周期对监管中心、指挥中心、各岗位和监督员等进行考评，根据岗位考评模型，由系统自动生成考评结果。
4总体技术路线
4.1采用基于J2EE技术体系结构的整体优势
1、J2EE技术标准：
J2EE是一个基于JAVA的应用系统的运行标准，由于采用JAVA技术开发，具有JAVA语言固有的开放性和跨平台特性，很多系统平台厂商都对其全力支持，因此可以选择多种硬件平台、操作系统、数据库、中间件和应用系统，基本做到只开发一次，就可以在各种环境下运行，构成不同规模的应用解决方案。
J2EE技术采用组件模型，保证组件本身可重用，并规范了组件之间的通讯、交互功能，通过标准接口实现数据库的隔离，同时提供事务管理、配置管理等一系列规范。
使用遵循J2EE标准的平台，可以从根本上保证系统具有可扩展、可重用、易管理等能力。
J2EE网络服务的部署模式如下图所示：
2、安全性：
应用体系结构为三层结构的应用系统，客户机必须通过应用服务器才能访问数据库服务器，杜绝了客户机直接访问数据库服务器的可能；客户机对服务器的访问特权可以指定或内置于三层中的每一层，提供三个级别的安全性。
3、稳定性：
应用体系结构为三层结构的应用系统，其业务逻辑层与用户表示层、数据服务层完全分离，三层之间相对独立，使得其中某一层的改变根本不影响到其他两层。
因而，当用户需求发生变更时，系统维护人员可以很容易地控制变更范围，系统的稳定性特别高。
4、可适应性：
应用体系结构为三层结构的应用系统，应用服务器（即：
业务逻辑层）主要承载与管理应用系统的全部业务逻辑，每一个业务逻辑被封装成独立的应用组件，组件与组件之间只通过有限的、指定的接口进行通信，当某一业务逻辑发生变化时，仅须修改其相应的应用组件即可，对象的结构与交互方式、数据的结构与存取方式等不须作修改，有效地限制了一处修改而处处牵连的“波动效应”，系统具有很强的变化适应能力。
5、可移植性：
应用体系结构为三层用纯Java语言来实现的，应用业务逻辑的部署与应用服务器具体的机型、操作系统无关，应用系统可以任意移植、轻松实现跨平台运行，更可以支持异构平台之间的互连和紧密衔接。
结构的应用系统，业务逻辑层的应用组件的开发是采纯Java语言来实现的，应用业务逻辑的部署与应用服务器具体的机型、操作系统无关，应用系统可以任意移植、轻松实现跨平台运行，更可以支持异构平台之间的互连和紧密衔接。
6、可伸缩性：
应用体系结构为三层结构的应用系统，由于其所有的应用程序（即：
应用组件）全部置于应用服务器中，用户可以根据其系统的规模，来确定应用服务器的配置与数量，当系统的规模扩大时，仅需升级应用服务器的配置或增添应用服务器的数量，来满足日益增长的业务需求，系统的可伸缩性极强。
7、易维护性：
应用体系结构为三层结构的应用系统，由于三层之间相对独立，系统的变更范围容易控制；客户机不需要安装复杂的网络、数据库等连接和驱动程序，其维护工作和维护成本趋于“零”；应用服务器中的业务逻辑被封装成独立的应用组件，某一业务逻辑的变化仅仅影响到某一独立的应用组件，系统具有很强的适应能力；因此，应用体系结构为三层结构的应用系统，其系统的维护工作简单、维护成本较低。
4.2采用B/S构建数字化城市管理核心业务系统
为充分保证系统在安全性、跨平台性、易扩展性、易维护性等方面的要求，建议采用先进的基于JAVA平台的三层应用体系结构。
在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。
用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术，这种结构已成为当今应用软件的首选体系结构。
三层结构应用系统相对于C/S两层应用系统，具有许多内在的优点。
1、逻辑界限清晰：
中间层允许用户把全部逻辑函数从另外的两个层中移到中间层的一个组件中去定义实现，这样各层之间相对独立使得其中某一层的改变不影响其他层。
因而，当用户需求发生变化的时候，开发人员可以很容易地控制变更的范围，从而达到及时修改的目的。
2、资源的优化：
由于一个应用系统的功能被分为三个部分，因此可以根据各层负载情况，将它们分布到相应的硬件平台上。
并可根据业务扩大的需求及时增加，可升级相应的硬件平台来满足不断增加的负载需求，使得系统具有良好的可扩展性。
再有，可使应用系统较为方便地使用异种数据源。
3、系统的易维护性
由于B/S结构客户端只需要浏览器（InternetExplorer），既不需要安装复杂的网络、数据库等连接，更不用安装伴随开发工具的界面控制驱动程序，即便需要在浏览器中嵌入必要的界面控制内容，浏览器本身也会自动下载及安装，完全省去了人工干预，其维护工作和维护成本趋于“零”，因此，采用B/S应用体系结构系统的维护工作简单、维护成本较低，非常有利于“城市模块化管理系统”这样一个全市、业务应用广泛和需要随时根据需要进行功能方面、界面控制等内容更新的系统。
4、系统的安全性
整个系统由三个部分组成：
客户端、中间层应用服务器、数据库服务器。
应用系统的层次结构划分为：
用户表示层、业务逻辑层、数据服务层，在B/S三层结构应用系统中，由用户表示层向业务逻辑层发出请求，然后业务逻辑层决定使用哪个数源来满足其请求。
通过使用相同的调用接口，业务逻辑层就可以对任何可用的数据源访问。
最后，可以增强和提高信息的安全性。
访问特权可以指定和或内置于三个层次的每一个层次中，以便提供三个级别的安全性。
4.3采用基于WebServices技术实现系统对外接口
WebServices技术描述了一些操作的接口，通过标准化的XML消息传递机制，可以通过网络访问这些操作。
WebServices是用标准的、规范的基于XML的WSDL语言描述的，它隐藏了服务实现的细节，允许独立于硬件或软件平台、独立于编写服务所用的编程语言方式使用该服务。
这使得基于WebServices的应用程序具备松散耦合、面向组件和跨技术实现的特点。
采用基于WebServices技术实现系统对外接口具备以下特征：
1、完好的封装性
WebServices既然是一种部署在Web上的对象，自然具备对象的良好封装性。
对于使用者而言，它能且仅能看到该对象提供的功能列表。
2、松散耦合性
这一特征也是源于对象/组件技术，当一个WebServices的实现发生变更的时候，调用者是不会感到这一点的。
对于调用者来说，只要WebServices的调用接口不变，WebServices实现的任何变更对他们来说都是透明的，甚至当WebServices的实现平台从J2EE迁移到。
NET或者反向迁移时，用户都可以对此一无所知。
从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如Microsoft的分布式组件对象模型（DCOM）、对象管理集团（OMG）的公用对象请求代理程序体系结构（CORBA）或SUN的远程方法调用（RMI）。
通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。
这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上。
他们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。
这样的系统往往十分脆弱：
如果一端的执行机制发生变化，那么另一端便会崩溃。
例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。
对于松散耦合而言，尤其是在Internet环境下的WebServices而言，需要有一种适合Internet环境的消息交换协议。
而XML/SOAP正是目前最为适合的消息交换协议。
3、使用协约的规范性
这一特征从对象而来，但相比一般对象，其界面规范更加规范化并易于被机器理解。
首先，作为WebServices，对象界面所提供的功能应当使用标准的描述语言来描述（比如WSDL）。
其次，由标准描述语言描述的服务界面应当是能够被发现的，因此，这一描述文档需要被存储在私有的或公共的注册库里面。
同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到WebServices的聚合、跨WebServices的事务、工作流等，而这些又都需要服务质量（QoS）的保障。
我们知道安全机制对于松散耦合的对象环境的重要性，因此，需要对诸如授权认证、数据完整性（比如签名机制）、消息源认证以及事物的不可否认性等运用规范的方法进行描述、传输和交换。
最后，所有层次上的处理都应当是可管理的，因此，需要对管理协约运用同样的机制。
4、使用标准协议规范
作为WebServices，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。
这些标准协议具有完全免费的规范，以便由任意方进行实现。
一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。
5、高度可集成能力
由于WebServices采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，因此，无论是CORBA，DCOM还是EJB，都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。
城管系统涉及了多种集成方式，所以必须拥有一个全面的集成平台才能满足需求。
举例来讲，针对现有的“协同工作系统”及“GIS系统”来讲使用JCA模式会成为比较合理的集成方式。
由于这些系统都已经成为标准的完整应用拥有自己的逻辑与业务、安全等模式，如果只进行简单的数据集成则需要重新开发大量的原有系统中的逻辑，为集成带来很多工作量与复杂度。
同时该类集成还需要拥有统一的专用管理界面，以保证集成后的可维护性。
而针对同步建设的几个子系统，由于构建在同一平台下，架构构一致沟通便利，因此更多的利用JMS直接进行系统间通信将成为理想的集成模式，该方式即能保证集成系统间的独立性又能保证系统的灵活度与可定制性、可调整性。
还有一类集成属于针对外部相关机构的无关性集成任务，该类集成由于涉及的技术架构，应用体系等都有较大的不确定性，因此采用WebServices将能够提供更灵活的集成性。
借助WebServices的技术无关性与通信标准性可以保证针对未来的各种符合标准的系统都能够达到无关性集成，并且其系统间的相关性可以降到最低，使集成任务的工作量更少。
4.4利用XML作为系统接口数据交换标准
XML数据传输是不同系统之间日渐流行的标准数据传输方式，由于与平台和编程语言的无关性，因此，通过XML可以有效保证对各种异构系统的数据接口需要，以达到政府各系统数据资源的最优整合。
XML适于异构应用间的数据共享。
XML的灵活性和扩展性使其可以对不同应用甚至是差异很大的应用间的数据进行描述，尤其是对于那些专用于记录数据的应用。
另外，XML具有自我描述的特性，结果是数据可以在不同的应用间进行交换与处理而不必要求相应的应用程序是针对该数据定制的。
用于强大的数据检索
XML属于元标记语言，进一步讲，根据这一特性，用户只要在XML的文档类型定义文件中定义一系列有意义的标记，这样基于该文档类型定义文件所产生的XML文档就可以按照任意的条件进行查询和检索，甚至实现计算机自动检索，而相应的检索引擎可以是通用的而不必局限于具体的应用。
提供多语种支持
XML规范中提供了对多语种的支持，包括UTF-7、UFT-8、UNICODE、GB2312（简体中文）、BIG5（繁体中文）等等，这一特点使得XML非常有利于多语种的应用开发。
4.5面向对象（OOA）的设计与开发
根据不同的应用类型，采用面向对象或面向过程的系统分析与设计方法。
传统的软件工程以软件的工程化为目标，强调方法论，工具与环境，质量保证体系，项目管理，配置管理，但基本理念是基于具体需求、从零开始的开发。
这种开发模式显然已经不适合于现代软件系统开发的要求。
而面向对象的设计（OOA）以软件的组装式生产为目标，强调各种粒度的软件重用、接口与表示和实现分离、统一对象模型，继承和发展了传统软件工程。
面向对象技术将计算看成是一个系统的演变过程，系统由对象组成，通过一系列的状态变化来完成计算。
对象具有保持能力和自主计算能力。
面向对象设计和实现的重点是多个对象的网状组织结构和协同计算，而不是过程调用的层次结构，这样就在本质上适应了并发、分布系统及互联网的计算特征。
4.6工作流引擎技术
工作流技术适应于电子政务平台框架下的具体电子政务应用系统中各个政府职能部门之间的联办互动工作，公文流转，网上审批、信息传递等系统都要用到工作流技术。
采用工作流引擎技术将信任服务、授权服务和工作流等业务流程有机融合紧密结合在一起，构成安全的工作流业务系统，为不同业务系统集成提供实现的技术手段。
具体而言，工作流技术要达到以下目标：
支持跨平台、多种语言的接口，使用户的已有应用可以在不做改动或稍做改动的情况下应用到新的工作流上；
建立流程控制数据库，让适当的人在适当的时间通过适当的方式提醒从而以适当的手段完成适当的事情；
支持多种工作处理机制，例如工作人员外出时的远程办公机制、授权机制等等；
与消息中间件之间的有效结合，支持各种灵活的触发和提醒机制，例如界面提示功能、数据库触发机制和消息的存储转发等等。
在工作流引擎的设计上实现流程、信息和人的分离设计，各司其职，各成体系。
工作流的设计思想如下图所示。
图工作流引擎设计思想
4.7基于WebGIS构建地理信息与业务系统结合
海量地图数据的共享应用，对系统运行的网络环境提出非常高的要求，地图用户的不断增长，也对服务器和网络环境提出更高要求。
GIS技术与Web技术的结合形成的WebGIS技术，使地图数据在网上发布成为可能，用户可以通过浏览器进行地理信息的各种操作。
与C/S结构的GIS应用系统不同，WebGIS服务器向客户端发送的一般是最终生成的地图影像的图片，用户无法直接存取地图资源库，从而真正保证了原始地图数据的应用安全。
系统采用空间数据库技术，对空间数据进行有效组织，并通过负载均衡技术，在多服务器环境中实现最佳的系统运行效率。
通过WebGIS技术大大降低了对网络带宽的运行要求，从而满足政府部门在政务专网上对地图数据应用的要求。
升级会员 