（3）整合资源，建设“一站式”服务。
整合资源，推进公共服务：逐步增加服务内容、扩大网上办事的业务范围，开展政务公开、行政许可、社会保障、教育文化、环境保护、申报、办证、年检、查询等多项网上服务，为公民、法人和其他组织提供跨政府部门的“一站式”电子化服务，提高服务水平和质量。
“一站式”智慧公共服务建设模式：“一站式”智慧公共服务建设模式是指政府部门在统一的网络信息平台上实现社会管理和提供服务，公民、法人和其他组织可利用统一的网络信息平台获取政府信息和服务的智慧公共服务模式。具体包括：
①网上并联行政许可审批模式
网上并联行政许可审批模式是指公民、法人和其他组织的申请事项涉及若干行政许可部门和许可环节时，将与该申请事项有关的行政许可部门整合为同一网络成员，把与申请事项有关的行政许可业务整合到统一的信息平台上，在互联网上连为一体、同步进行的许可方式。该模式实现了跨政府部门的资源整合与共享。例如，公民、法人和其他组织在申请设立企业或进行变更登记时，将与企业登记、变更有关的行政许可部门、工商行政管理部门整合为同一网络成员，把与企业登一记、变更相关的行政许可业务整合到一个统一的信息平台上，在互联网上连为一体、同步进行许可。申请设立企业、变更登记事项是以工商部门为中心、以工商注册登记为核心业务，采取工商部门一家受理、网上转告相关、各部门并联许可、限时完成的便民流程，充分利用互联网技术，实施企业注册或变更登记一体化电子服务。
该模式的特点是：实现了网上并联许可、网上信息发布、资料查询、咨询服务、数据统计、过程监督、流转跟踪、数据分析等功能。网上并联行政许可审批模式有效地解决了企业、公众办事难、效率低等问题。
②以核心业务、核心部门为中心的“一站式”服务模式
该模式是指某一核心业务的处理会涉及其他业务处理，或者该核心业务的管理部门在处理该业务时会涉及其他部门，把核心业务的管理设计为一个流程，使涉及该事务处理的相关部门整合为这个流程上的一个节点或工作团队的一体化电子服务模式。如出入境的证照办理、网上报税、电子通关等模式。
该模式的特点是：在业务处理中，只有一个部门是核心业务部门、一个业务是核心业务；该模式业务流程的设计是以核心业务部门或者核心业务为中心。
③以事务处理过程为中心的“一站式”服务模式
它是指事务的处理过程涉及多个部门和多项事务，这些部门和事务不存在哪一个是主要的，把事务的处理过程设计为一个流程，把涉及事务处理的相关部门整合在该流程中的一体化电子服务模式。例如面向公民个人的便民服务系统，电子信访系统，电子投诉系统，呼叫中心，劳动、民政等社会保障系统，以及面向企业的网上采购系统、投资招商服务系统、联合年检系统、网上申报系统等。
该模式的特点是：处理过程涉及多项事务、多个部门；不存在明显的核心部门与核心业务。该模式的建设要注重行政业务流程的优化重组和政府结构调整，以及部门间的协调和信息共享。同时，可授权政府综合管理部门牵头进行协调和组织实施，政府一把手亲自抓落实，信息化主管部门负责具体业务、技术的设计与规划，并建立统一的部门工作规范。
14.3智慧公共服务的信息整合
面向公众服务的智慧公共服务必须解决信息孤岛问题，用户只需要同智慧公共服务的统一“前台”打交道，无须与具体的政府部门网站打交道。在具体业务办理过程中，用户似乎在通过一个门户网站面对一个“超级政府”。这就要求政府机构的业务职能部门作为“后台”实现整合，而系统集成技术就是连接智慧公共服务信息孤岛、实现整合的关键。
智慧公共服务“信息孤岛”问题已经成为发展的瓶颈问题，关键是要解决政府各部门不同的业务系统和办公系统之间的互操作。传统的解决方案采用用户界面集成模式、中央数据库模式、分布式对象模型。这些方法都存在实现上的困难。而用Web服务技术构建智慧公共服务数据交换综合平台〔以下简称综合平台〕可以方便地实现各部门不同系统之间的信息交互，实现跨部门的系统整合，解决信息孤岛问题。具体思路是：把各部门的业务系统包装为Web服务，并发布到公共服务注册中心供其他部门调用，建立一个智慧公共服务数据交换综合平台，对内调用各部门所提供的公共服务，对外提供统一的服务申请者使用界面。
14.3.1综合平台的设计原则
1.通用性原则
智慧公共服务是典型的异构系统，各部门现有的内部业务系统都是功能完善、紧密结合的，所采用的对象体系、运行环境、开发语言等都不同。综合平台需要在这种异构环境中实现数据交换和业务处理，就必须屏蔽这些网络、系统的差异。保证系统之间的互通性是设计综合平台的首要原则。通用性原则还包括用统一的规范来表示文档型数据、关系型数据、GIS数据、多媒体数据，减少数据在处理过程中因标准不统一而引发的问题。
2.可扩展性原则
第一是功能模型的可扩展性。综合平台能够支持各部门职能的调整；第二是信息模型的可扩展性。综合平台能够支持信息数据类型的变化。
3.可靠性、安全性原则
智慧公共服务系统关系到政务工作的权威性、严肃性，平台要保证信息交互是安全、可靠、完整和一致的。
4.易于实现的原则
无论采取哪种实现方法，应尽可能地简化实现，从而提高系统开发效率和系统的可重用性。
14.3.2综合平台的体系结构
综合平台系统的功能是：对内整合各政府机构所提供的不同职能服务，对外提供统一、便捷的使用界面。平台由政务综合信息平台、公共服务注册中心、公共服务实施方三部分组成，它们完全按照Web服务技术框架来搭建。
1.公共服务注册中心
公共服务注册中心是一个UDDI注册中心，它管理各服务实施方发布的政务Web服务。在综合平台中，政务综合信息平台负责发现需要的政务Web服务并与之交互。用公共服务注册中心来维护一个职能机构及其提供的政务Web服务的目录，包括职能机构的一些基本信息和调用政务Web服务所必需的技术信息，其中的信息描述格式是基于通用的XML格式的。这样，公共服务的使用者就能够方便地查找到所需要的政务Web服务。可以把公共服务注册中心设计为一个私有UDDI注册中心，以Web服务的方式提供统一的操作接口，政务实施方和政务综合信息平台通过这些操作接口进行公共服务的发布、查询。
2.公共服务实施方案
公共服务实施方是公共服务的提供者，它把各政府机构原有的业务职能封装为Web服务，或者开发新的Web服务系统，并把公共服务发布到公共服务注册中心供申请者查询、调用。公共服务不仅可以被综合信息平台调用，还可以被其他政府部门调用。
3.政务综合信息平台
政务综合信息平台对内从服务注册中心查找适合的公共服务，并与各服务实施方绑定后调用。它对外向政务申请者提供政务咨询、政务申请、办理结果查询等服务。政务综合信息平台是系统中最重要的组成部分。其中，公共服务申请者不仅是一般的个人和企业，还可以是其他政府部门。
公共服务实施方生成、部署Web服务有两种方式：一是开发全新的Web服务应用系统对外发布，这适合于新建设的应用系统。但实际情况更多采用的是第二种方式，把原有的应用系统转换成Web服务的形式。封装己有系统来提供Web服务的方式，可按如下步骤进行。
1.利用WSDL生成器组件根据已有的程序代码和一些辅助信息（如Web服务在应用服务器上的配置信息），生成描述该已有应用系统功能和调用方法的WSDL文件。
2.利用Web服务生成器组件生成服务器端的服务适配器，它主要用于将公共服务请求转化成应用系统能够理解的数据格式，并返回处理结果。服务适配器通常是一个连接到后台应用服务器的应用程序，可以采用任何后台服务器支持的通信与之连接。
3.在应用服务器上配置、部署相应的SOAP交互框架，包括序列化／反序列化组件、SOAP消息处理组件和SOAP消息传输组件，实现和服务请求者之间的消息交互。公共服务注册中心的设计公共服务注册中心（UDDI）存储描述了职能机构的信息以及它们所提供的政务Web服务的相关技术调用界面（或API），是一个私有的UDDI注册中心。它以Web服务的方式来提供统一的操作接口，公共服务实施方和政务综合信息台通过这些操作接口来进行公共服务的发布、发现。
（1）注册中心的实现模式
为了保证政务注册中心的可靠性，按照公共UDDI注册中心的模式来实现，LDDI注册中心操作入口站点，组成一个小的UDDI服务群。各站点之间采用P2P（对等网络）架构实施，实现在逻辑上是统一的，在物理上是分布的。当某个注册中心站点拒绝服务时，可以通过访问其他站点来获得信息，保证了注册中心的健壮性。注册信息在一个注册中心发布后，也被按照一定的规则同步复制到其他站点，每个UDDI注册中心都维护了一个注册信息的全集。这种实现方式比起查询分发和重定向的实现方式，只有必要的数据变更信息在UD-DI操作入口站点之间传输，大大减少了网络信息传输量。同时所有的发现查询都将在本地进行，对服务质量也有很大的提升。
（2）公共服务的发布
公共服务注册中心以Web服务的方式提供统一的操作接口，公共服务实施方通过这些接口来进行服务发布。UDDI用户在进行服务发布时需要进行身份验证。用户需要先到UDDI注册中心注册并得到用户名和密码，然后在发布服务时请求一个身份验证的令牌。如果身份验证成功，用户就可以使用发布API进行服务发布，并且在结束后丢弃这个令牌，当然用户只能修改或洲除自己发布的数据内容。
公共服务的发布一般可以按照以下步骤进行：
①连接和身份验证
公共服务实施方在发布公共服务时，先和公共服务注册中心建立连接，并且进行身份验证得到令牌供下面操作使用。
②发布一个接口的信息
公共服务接口定义了调用所需要的输入参数的具体格式、调用服务的协议及绑定方式、公共服务返回的响应格式等信息。接口中指定的信息一般是以WSDL文档的形式存在的，要将接口和WSDL文档的URL地址关联起来。发布成功后返回一个“主键”。
③发布一个职能机构的基本信息
职能机构相当于UDDI数据模型规范中的Business Entity，包含机构的一些基本信息，给公共服务使用者一个大概的了解。将机构名称、类别以及其他详细信息注册到UDD工。注册成功后也返回一个“主键”。每个公共服务属于某一个职能机构，所以根据职能机构的“主键”来发布公共服务。每个公共服务可以有一个或多个接口的实例，所以发布公共服务时要指定接口的“主键”。公共服务的调用信息在技术绑定信息中定义，在生成技术绑定信息对象时，要指定公共服务的访问入口地址和实现的接口的URL引用。发布公共服务也将返回服务的“主键”和技术绑定的“主键”。
（3）公共服务的发现
在政务注册中心站点上查找公共服务有两种方式，一种是按照职能机构查找，可以按照机构类别、机构名称等条件组合查询、模糊查询。找到职能机构之后，可以列出已经发布的所有公共服务，找到所需要的公共服务，取得公共服务描述文档的URL引用。另一种是按照接口查找，根据接口的分类以及其他一些细节信息找到特定的接口，然后查找到实现该接口的职能机构列表，然后再找到所需的公共服务。
14.3.3政务综合信息平台的设计
政务综合信息平台主要完成以下工作：
1.浏览公共服务注册中心，查找需要的服务，下载相应的服务描述文件（即WSDL文件），并利用Web服务生成器组件生成客户端代理程序。一个公共服务对应一个客户端代理程序。
2.收集公共服务申请者递交的请求信息，由公共服务路由器处理后，转发给相应公共服务的客户端代理程序，通过它来调用对应的职能机构所提供的公共服务。
3.提供一个专门的结果处理服务，供其他职能机构调用，以收集各个机构对公共服务申请的办理结果。
4.提供政务综合信息存储中心，保存公共服务请求信息以及请求处理状况信息，供公共服务申请者查询。
政务综合信息平台主要由五部分组成，详细模块结构如下：
1.SOAP交互框架
这是完成Web服务间调用的必需部分，由序列化／反序列化组件、SOAP消息处理组件和SOAP消息传输组件三部分组成，其中：
（1）SOAP消息处理组件完成根据服务调用请求生成SOAP消息以及从SOAP消息中还原对应信息的功能。
（2）SOAP消息传输组件负责完成通过一些消息传输协议（如HTTP，SMTP）发送和接收SOAP消息的功能。
（3）序列化／反序列化组件主要用于SOAP消息中传递复杂的数据类型。SOAP规范虽然对SOAP参数和返回值做了一些预先定义，但还是不能满足应用的需求。在实际应用中，往往要使用一些用Java Bean或类似形式编写的自定义的复合数据类型，这就需要序列化／反序列化的工具来把复合的数据类型转化为XML格式，或反之，从而完成消息的传递。
