行政许可网上审批与监测平台总体建设方案Word文档格式.docx
- 文档编号:19455360
- 上传时间:2023-01-06
- 格式:DOCX
- 页数:66
- 大小:1.12MB
行政许可网上审批与监测平台总体建设方案Word文档格式.docx
《行政许可网上审批与监测平台总体建设方案Word文档格式.docx》由会员分享,可在线阅读,更多相关《行政许可网上审批与监测平台总体建设方案Word文档格式.docx(66页珍藏版)》请在冰豆网上搜索。
可以构建跨省的网上审批流转的业务。
推动各省政务公开和信息资源的内部开放,共享审批申报程序和结果信息,网上召集联合办理行政审批,实现审批业务全部上网处理。
系统另一方面构建电子监察平台,实现对审批事项实施全过程实时在线监督、及时发现和纠正问题,不断提高行政审批效率。
在整体思路上,项目建设以解决信息共享为核心,全面推动政务公开、网上审批和电子监察系统建设;
建立行政审批综合信息库,增强网上审批功能;
采用后台交换数据和前台嵌入协同应用等方法,彻底解决网上审批平台和各省审批业务系统的无缝衔接和单机操作问题。
系统远期可以扩展覆盖到街道办事处,支持有条件的街道办事处实现网上审批。
2.2项目设计原则
1、先进实用的原则。
新闻出版行政许可网上审批系统应尽可能采用先进的技术设备,确保系统的高可用性、高性能、高可靠、高安全和可扩充性。
同时要以实用为目标,针对实际问题,符合实际情况,解决实际问题,追求实际效果。
2、统一规划,重点先行,注重实效。
在统一规划下重点解决网上审批数据交换标准、方法等关键问题,注重电子政务建设的实际效果。
3、统一标准,统一应用。
按照国家、省、市有关标准,制定新闻出版行政许可网上审批数据交换标准、行政绩效测评量化标准、接口规范、访问规范、分类规范和发布规范。
整个系统统一系统管理,统一授权使用。
4、充分利用原有资源,避免重复投资。
新闻出版行政许可审批信息化和电子政务建设工作扎实、基础雄厚,在项目建设中应充分利用原有计算机和网络等系统资源,融合已有电子政务应用系统,节省系统建设投资。
注重总体规划,加强资源整合,巩固和发展以总局为主导、省局为主体、社会积极参与的信息化持续发展局面。
抓住关系全局的重大应用,通过应用推进信息化。
避免盲目跟风,把握信息化发展的主动权。
5、贴近市民,服务发展。
以便民利民为宗旨,把信息化建设的注意力和关注点放在满足市民需求和经济社会发展全局上,发挥信息化对增强区域综合竞争力和提高市民生活满意率的重要作用。
6、着眼需求,务实高效。
以需求为导向、以应用为中心推进信息建设,把经济效益和社会效益作为衡量信息化建设的重要标准,不搞不切实际没有效益的信息化,更不搞花架子的信息化。
2.3项目建设内容
本项目将建设新闻出版行政许可网上审批系统,建设统一的网上审批平台,对全国各省的行政许可和其他审批事项中尚未计算机处理的业务统一在网上实现审批处理,并在网上实现全国新闻出版行政许可审批业务的协同处理;
对所有行政许可的实施过程进行视频、实时、全程的监察和监督,对行政许可实现网上信息共享和联合审批,推动全国各省的政务公开工作的开展。
同时,新闻出版行政许可网上审批主要是为了提高行政审批办事效率,方便办事人员了解审批结果。
因此,我们将在审批环节过程中加入信息发布和信息查询功能。
发布环节主要包括将审批环节的结果性结果通过网站发布在互联网上,提供网上查询功能。
具体建设内容包括:
1.新闻出版广电总局网站的监察及审批扩展;
2.审批及监察数据交换平台(软件)开发;
3.政务电子监察平台(软件)开发;
4.网上审批平台(软件)开发;
5.安全保障平台(软件)开发;
6.网上审批数据交换标准的制定;
7.运行服务器系统建设;
8.实现系统同现场触摸屏、短信接口。
9.审批大厅现场图像监控系统(包括监控室)建设;
10.数据交换和共享实施的权责规则的制定;
2.4项目建设特点和突破
本项目建设充分结合XX区电子政务建设的实际、突出业务创新、技术创新和管理创新。
1、把政务公开、网上审批和电子监察系统建设统一规划、分步建设,追求项目建设的全局性和整体性效果。
根据多年的电子政务建设经验,各部门审批信息的共享,往往难以协调。
信息无法共享,建设跨部门网上审批系统就无从谈起。
把政务公开与跨部门网上审批和电子监察系统建设统一规划、分步建设,可以从根本上解决信息共享难的问题,促进网上审批平台的建设。
2、编制统一的网上审批数据交换标准,从总体上解决各部门在网上审批和电子监察等所要求的共享信息和采集数据的标准、方法等。
3、在技术设计上实现网上审批和电子监察一体化设计、统一管理和分级授权使用。
4、采用后台嵌入共享数据和前台嵌入协同应用的方法,彻底突破网上审批平台与部门审批业务系统之间的无缝联接和工作人员只需在一套系统上操作的难点。
5、电子监察的业务范围,从行政许可扩大到所有行政许可、其他审批和登记、备案、资格资质认可、政府公开采购及其后续监督检查等更大范围。
2.5项目实施计划
项目实施期限为8个月,具体工作进度:
1、需求分析并确认;
开发环境准备与改造、研发、测试环境搭建;
由三名技术工程师进行系统需求调研,调研周期为1个月。
2、系统研发;
系统的详细设计包括物理环境设计和系统功能设计系统改进和新功能实现,其主要任务是根据设计进行编码、单元测试,集成测试和试用。
由八名研发工程师共同参与该系统的研发工作,研发周期为6个月。
3、系统的测试;
主要任务是对整合后的系统进行整合测试及相应的模拟测试,测试其整体功能、性能、可靠性、可用性等一些质量、技术指标,对其BUG进行修正。
由两名测试工程师和三名技术工程师参与该系统的测试以及现场调试和部署,周期为1个月。
第三章项目建设需求分析
3.1业务分析
3.1.1行政审批事项繁多,差异大,环节多,时限长
目前现有的审批事项中有些审批事项是各省具有终审权,涉及社会管理的方方面面,构成行政机关日常工作的重要的组成部分。
每一项业务在流程没有统一的标准或模式,业务审批的内容也存在巨大的差异,申请人面对大量的行政审批茫然不知所措。
改进的措施是在目前行政审批梳理的基础上,对审批项目进行分类,已有计算机系统处理的审批项目,还是保留原来的处理方式,但是按照规范进行整改并向电子监察系统报送监察数据接受实时监察;
没有计算机系统处理的审批项目,按照规范在网上审批平台构建业务。
3.1.2行政审批事项相对孤立,造成申请条件复杂
由于管理上条块分割,总局对全国行政审批的管理以各省自律的方式为主,各省间缺乏相互交流,互相推诿的情况仍然存在。
依据法律、法规各事项间存在相互关联,各行政审批在实施过程应进行行政审批信息的相互校验,但由于各部门相对独立,使得信息的传递职责转移到申请人身上,为申请人带来不便,一部分申请人利用信息的不同步空档,躲避法规的监管,获得了行政审批。
3.1.3相对集中率低,信息化管理水平较低
由于办公场所的限制,目前总局已设立了行政服务大厅,各省也设立了各自的办证大厅,但是由于进入大厅的行政审批事项还是较少,协同办公集中办理的功能得不到较好的发挥。
同时各省在运用信息化手段管理行政审批起步较慢,使用系统管理的行政审批事项只有一部分,这其中的一些系统仍只是局限于登记和受理的管理功能上面。
通过建立网上并联审批系统,打破地域限制,通过信息网,把各省的业务系统互联,没有业务系统各省局统一在网上审批平台上构建业务,构建虚拟的办证大厅,结合原来的联办中心,发挥网上协同办公、协同审批的作用,更好的为人民服务。
通过网上并联审批系统,局领导可以实时的掌握全国审批项目的实施情况,实时监察各种审批项目的实施过程,更进一步,可以为出台相关的决策提供具体、有针对性的统计数据。
第四章系统总体方案
4.1软件总体技术框架
4.1.1系统应用体系结构
网上审批系统,是一个全国性的顶层系统,需要与全国各省行政审批系统进行互联,需要与全国协同办公自动化系统进行互联,必须考虑以后业务的变化与扩展,因此系统的体系结构必须先进、稳定、易扩展,既需要安全稳健的系统平台支持,又需要面向更广阔的业务支撑和更灵活的应用集成扩展能力。
4.1.2系统总体结构图
网上审批系统是基于太极统一应用软件平台来构造,该平台基于J2EE应用平台,采用JAVA、EJB、SERVLET、JSP、XML等JAVA2技术、以及组件技术、数据库技术,采用多层B/S应用结构体系,使整个应用系统建立在统一的平台上,充分体现了系统的先进性、可扩展性、可移植性等。
系统基础平台:
指为应用系统提供底层支持的部分,包括:
网络(内部网、政府专网和互联网)、硬件平台(服务器、存储备份设备等)、操作系统(Unix/Windows/Linux等)、数据库管理系统。
这些部分是应用系统运行的基础。
J2EE平台:
Java技术由于其跨平台特性、面向对象特性、安全特性等,使之已经成为构建企业级应用的事实上的标准。
J2EE(企业级Java)把数据库访问、企业级Java组件、命名和目录服务、动态页面生成、XML、事务服务等有机地集成在一起,并且提供集群等高级特性,使之特别适合构建复杂的大型应用,并保证系统具有很好的可扩展性。
系统结构图如下:
4.1.3J2EE架构
本系统采用J2EE架构实现应用体系结构,本系统设计采用基于J2EE的技术,完全采用MVC+DAO(Model+View+Control+DAO)应用设计模式,使得层之间相对松耦合,具有良好的扩展性和稳定性,如图所示应用设计结构图:
J2EE实现思路
客户端:
用户通过WEB浏览器与不同应用程序交互,浏览器作为应用程序的客户可以使用JSP页面和XHTML来呈现客户页面。
应用程序控制器:
应用程序控制器是主控制器Servlet,负责初始化委派请求和响应请求处理程序。
请求处理程序:
JAVA类,通过调用相应的请求执行程序完成要求的处理,并对请求进行预处理,这种调用采用命令模式。
请求执行程序:
完成具体的请求活动,例如与服务交互。
请求执行程序依靠业务定位程序发现相应的服务,然后通过这些服务访问需要的资源信息。
业务定位程序:
这些程序负责隐藏查找服务的复杂性,并提供缓存逻辑。
业务展现接口:
通过聚合来自多个系统或服务的方法,简化复杂对象的视图。
WEB服务:
提供WEB服务端点的业务逻辑。
DAO(数据访问接口):
封装数据库异构的复杂性,使得在应用服务层面独立于数据层面。
J2EE是一个基于组件-容器模型的系统平台,其核心概念是容器。
容器是指为特定组件提供服务的一个标准化的运行时环境,Java虚拟机就是一个典型的容器。
组件是一个可以部署的程序单元,它以某种方式运行在容器中,容器封装了J2EE底层的API,为组件提供事务处理、数据访问、安全性、持久性等服务。
在J2EE中组件和组件之间并不直接访问,而是通过容器提供的协议和方法来相互调用。
组件和容器间的关系通过“协议”来定义。
容器的底层是J2EE服务器,它为容器提供J2EE中定义的各种服务和API。
一个J2EE服务器(也叫J2EE应用服务器)可以支持一种或多种容器。
每个容器的服务包括两部分:
J2SE(Java2PlatformStandardEdition)和一组扩展的服务。
这是因为J2EE是以Java标准版为基础的,各容器在J2SE之上再根据需要提供一些扩展的服务,如目录服务、事务管理、数据访问、消息机制、安全性等。
EJB是J2EE平台的核心,也是J2EE得到业界广泛关注和支持的主要原因。
我们知道,J2EE的一个主要目的就是简化企业应用系统的开发,使程序员将主要精力放在商业逻辑的开发上。
EJB正是基于这种思想的服务器端技术,它本身也是一种规范,该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。
EJB的核心思想是将商业逻辑与底层的系统逻辑分开,使开发者只需关心商业逻辑,而由EJB容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。
企业级Java(Java2EnterpriseEdition)的示意图。
J2EE构架划分为表示层、业务层和数据层三个层次。
在表示层,支持Java应用、在浏览器中的小应用程序、Corba客户端、以及Web客户端;
在业务层,通过EJBBeans来实现业务逻辑,并运行在支持EJB的应用服务器中;
数据层同样支持各种数据库管理系统。
表示层和业务层之间主要通过RMI-IIOP进行通讯;
业务层和数据层则通过JDBC和SQL/J进行连结。
J2EE使用的是业界的标准,而不是一个厂商的标准。
特别是对OMG的Corba标准有很好的支持。
它能够在各种不同的硬件平台和操作系统上运行。
J2EE规范里包含了多种技术,并形成一个有机的整体:
●EJB:
企业级Java组件,能够封装复杂的业务逻辑,并在整个系统范围内重用,支持远程调用和集群;
●RMI-IIOP:
远程方法调用协议,支持Java程序象调用本地对象一样调用远程对象,该协议既支持Java本身的RMI调用,也支持CORBA的IIOP协议,因而能够与CORBA服务进行互访问;
●JDBC:
提供Java程序访问数据库的标准接口;
●Servlet:
支持动态地生成html页面,用于基于浏览器的应用开发;
●JSP:
能够通过混合编写java和html脚本,动态地生成html页面,比编写Servlet的开发效率更高;
●JTA:
Java事务接口提供对事务的支持,包括分布式事务;
●JavaIDL:
允许Java对象访问外部CORBA对象;
●JMS:
Java消息服务,支持可靠的点对点、发布/订阅方式的消息传输;
●JNDI:
Java命名和目录服务,支持按照名称来查找资源;
●JavaMail:
提供在Java里面发送和接收电子邮件的支持;
●JAF:
被JavaMail用来处理MIME数据;
●JAXP:
Java处理XML文件的标准接口,支持SAX和DOMAPI;
●JCA:
允许遗留的信息系统提供出适配器接口,与J2EE应用程序进行整合;
●JAAS:
支持基于用户的认证和授权模型;
J2EE的特点在于:
支持所有的硬件和操作系统平台,使用户在操作系统和硬件的选择上具有更大的自由度;
技术规范更全面,对企业级应用的支持更强大;
具有“编写一次,到处运行”的优点;
系统的可扩展性更强,后期维护费用较低;
适合大型的系统和关键的业务;
现有标准,后有实现,标准的设计很完善;
只需要用Java一种语言,开发效率高。
4.1.4MVC处理模式
MVC是Model/View/Control的缩写。
Model/View/Control是软件设计的典型结构。
在这种设计结构下,一个应用被分为三个部分:
Model、View和Controller,每个部分负责不同的功能。
Model是指对业务数据/信息的处理模块,包括对业务数据的存取、加工、综合等。
;
View是指用户界面,也就是面向用户的数据表示,Web的视图可以是HTML页面,也可以是图片或者其他媒体;
Controller则负责View和Model之间的流程控制,也就是完成两个方向的动作:
1.将用户界面(View)的操作映射到具体的Model,以完成具体的业务逻辑;
2.
将通过Model处理完的业务数据及时反应到用户界面(View)上。
具体地说,视图可以用JSP或者HTML来定义,模型可以用Java对象来定义(通常称为JavaBean),控制器可以通过Java对象的动作类来定义。
以下是MVC架构的处理流程:
MVC架构使得应用程序的结构更加清晰,通过将代码按照层次划分为业务逻辑/数据、用户界面和应用流程控制这三个层次,增强代码稳定性。
我们知道,对于Model、View、Controller这三部分功能来讲,View的实现一般是由界面设计人员和界面程序员来完成,Model则是由业务逻辑程序员来完成,Controller则一般由负责整体控制的程序员来完成。
Controller部分的代码比较稳定,一般会实现一个通用的架构;
而Model则跟随商务流程的变化而变化;
View的更改则是随着用户需求的更改而更改。
这种模块功能的划分有利于在代码修改过程中进行模块的隔离,而不需要把具有不同功能的代码混杂在一起造成混乱。
对于项目开发而言,有利于在项目小组内按照小组成员各自的擅长进行分工,有利于三个部分并行开发、加快项目进度。
4.1.5XML技术
XML即ExtensibleMarkupLanguage(可扩展标记语言)的缩写。
XML实际上是Web上表示结构化信息的一种标准文本格式,它没有复杂的语法和包罗万象的数据定义。
XML同HTML一样,都来自SGML(标准通用标记语言)。
SGML是一种在Web发明之前就早已存在的用标记来描述文档资料的通用语言。
但SGML十分庞大且难于学习和使用。
鉴于此,人们提出了HTML语言。
但近年来,随着Web应用的不断深入,HTML在需求广泛的应用中已显得捉襟见肘,有人建议直接使用SGML作为Web语言。
但SGML太庞大了,学用两难尚且不说,就是全面实现SGML的浏览器也非常困难。
于是Web标准化组织W3C建议使用一种精简的SGML版本--XML。
XML与SGML一样,是一个用来定义其他语言的元语言。
与SGML相比,XML规范不到SGML规范的1/10,简单易懂,是一门既无标签集也无语法的新一代标记语言。
系统在数据交换中采用XML技术。
4.1.6Struts
Struts最早是作为ApacheJakarta项目的组成部分,项目的创立者希望通过对该项目的研究,改进和提高JavaServerPages、Servlet、标签库以及面向对象的技术水准。
Struts这个名字来源于在建筑和旧式飞机中使用的支持金属架。
这个框架之所以叫"
Struts"
,是为了提醒我们记住那些支撑我们房屋,建筑,桥梁,甚至我们踩高跷时候的基础支撑。
这也是一个解释Struts在开发Web应用程序中所扮演的角色的精彩描述。
当建立一个物理建筑时,建筑工程师使用支柱为建筑的每一层提供支持。
同样,软件工程师使用Struts为业务应用的每一层提供支持。
它的目的是为了帮助我们减少在运用MVC设计模型来开发Web应用的时间。
我们仍然需要学习和应用该架构,不过它将可以完成其中一些繁重的工作。
如果想混合使用Servlets和JSP的优点来建立可扩展的应用,Struts是一个不错的选择。
4.1.7组件化系统设计
应用功能服务组件提供系统功能,从技术实现上看,功能组件虽然只提供单一方面的功能,而且这些功能和一般应用系统中所提供的功能并没有太大的差异。
但由于基于同一的平台进行构建、对外统一利用接口提供服务,因此在客户看来是一个完整的系统,而并非多个系统的有机集成。
从业务实现的角度看,每一项业务的实现将不再以主体功能要求为标准进行系统划分与设计。
因为平台上的功能组件已经基本包括了办公所需要的各种功能要求,对业务管理者来讲只需要根据业务本身的功能需求,选择合适的功能组件并加以组合使用,即可满足业务的功能要求。
因此业务需求的实现将始终以业务的实际运作为主线及基准,而不再需要调整业务以适应应用实现。
在系统中,业务的实现已经不再需要区分到底是由那一个子系统完成的,用户只需要关心实现功能的组件是否可以满足其要求即可。
当已有的功能组件不能满足业务的要求时,可以通过组件功能的扩展或者新增功能组件进行解决。
并且由于整个业务的处理过程在同一平台、同一系统中完成,因此也不再存在信息关系被分割的情况。
基于功能组件构建的三层结构应用子系统如下图所示。
从子系统结构可以看出,功能服务组件组合使用之后在其中担任着业务逻辑层的作用,这和功能服务组件本身是一个功能服务提供者的特性是相吻合的。
在多层分布式应用结构中,中间层即业务逻辑层担负着各种应用功能的提供;
而功能服务组件的功能服务提供者能力正是中间层所需要的。
此外,子系统结构中的显示层逻辑,可以通过提供对外应用程序接口的功能服务组件加以实现;
数据层连接及服务则可利用提供数据接口的功能服务组件加以实现。
因此,利用功能服务组件概念构建的系统应用无论在结构或实际运行效果上都是符合多层分布式应用要求的。
根据我们对电子政务应用系统需求的分析、现有系统应用情况的统计,综合总结得出系统所需的基础功能包括了数据管理、报表打印管理、权限管理、其他系统管理、工作流引擎等5个基础功能组件。
4.1.7.1数据管理组件
数据管理处理的对象包括各种类型的数据,以及数据处理界面。
在系统中,对数据的处理手段一般包括了数据的增加、修改、删除、排序、筛选等基础手段,以及定制查询、全文检索、数据统计、图表分析等高级手段。
针对处理手段的需要,数据管理组件除提供了包括以上手段在内的各种数据处理功能,还允许用户
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 行政许可 网上 审批 监测 平台 总体 建设 方案