重庆市某区城市管理执法信息系统可行性研究及概算方案

第1章 总体建设方案

1.1 总体设计原则

总体上按照统筹规划、整体推进、分级负责、分步实施的原则进行建设。

（1）先进性原则

系统建设要与当前的先进技术相结合，选用数据库、中间件的最新成果，从整体上体现方案的先进性。同时，由于系统的实施不只是一个技术问题，更重要的是会涉及组织协调和标准化，本方案在管理、技术、设计及实现等方面充分借鉴先进技术和同类系统的成熟经验，制定先进的解决方案，从源头保证系统技术领先和运行稳定。

（2）实用性和可操作性原则

实用性指设计方案符合重庆市綦江区县城市管理综合行政执法支队的业务现状，应用信息系统解决现有业务管理中存在的问题，提高行政执法工作效率。可操作性指方案的设计充分考虑重庆市法制业务管理、IT基础设施及用户使用水平，保证系统可实施和推广，能够将先进的技术方案真正为用户所用。

（3）标准性、开放性原则

采用的技术和设备的标准必须符合国际标准或“事实”上的国际标准，以便获得广泛的技术和厂商支持。同时考虑到投资的长期效益，系统应具有良好的开放性，能够实现与多种技术和软硬件平台的有机结合，确保满足系统未来的发展需求。

（4）可扩展性原则

由于政府信息化建设和应用系统具有快速发展、高速膨胀的特点，这就要求各个环节必须具有高扩展性。当用户数目增加、业务范围拓展时，系统亦有灵活的调整和扩充手段来适应其变化；同时还要考虑与现有业务系统的对接。

作为一个逐步发展的大系统，系统结构、设备都必须在标准性、开放性原则的基础上做到性能和功能的灵活扩展，以适应用户需求的不断增加和变化。因此，系统本身须具备高于其硬件组成及网络设备的扩展层次与扩展能力。

（5）安全保密性原则

高度重视信息安全保密工作，严格执行国家有关安全保密法律、法规的规定，注重安全保密系统和安全保密管理机制的建设，建立健全信息安全保障体系。综合采取技术和管理等措施，运用法律、行政、经济和技术手段，强化信息安全管理。信息安全是电子政务建设的前提，系统设计中首要考虑如何建立整个系统的安全性、保密性，而且这种考虑必须是整体的、全面的。

（6）应用可适应性原则

政务系统的另一个特点是应用需求较易发生变化，这就要求系统必须为应用提供一定程度的可适应性支持。提供充分的变更与扩展能力，以适用于机构、人员以及业务流程的调整。并充分利用业主方现有软、硬件和信息资源。在保证系统长期稳定使用的基础上，降低换代升级成本，从而提高系统投资的综合性价比，保护已有的设备和技术投资。

（7）高可用性和可靠性原则

为了体现“效率政府”的理念，也为了政府部门的高效工作提供技术保障，系统不仅需要稳定运行还需提供较高的性能支持，从而帮助政府部门高效处理各类日常事务的同时、及时响应关键事物。因此在系统设计之初就应该充分考虑如何高效的保证系统的可用性及可靠性问题。

（8）易管理性原则

系统的易管理性既能提高软件的使用效率又能给系统管理人员带来方便。应提供管理工具可以对系统进行全面的监控和管理、配置（包括对分布在机关大楼外的服务器及服务进行远程管理和监控），并能够帮助管理员对系统故障进行诊断、排错和分析与规划，从而充分发挥信息化优势、进一步扩展增值空间、降低总体使用成本。

（9）统筹规划、分步实施原则

城管执法是一项系统工程，涉及到城市管理的方方面面，建设之前需要进行统筹规划，进行顶层设计。同时综合考虑人、财、物等因素，根据城管实际工作需要，把总体目标具体分解为若干阶段性任务，分步实施。

（10）急用先行，由易到难，循序渐进，迭代推进原则

本项目平台覆盖功能较多、较全面，需要优先开发急用的、难度较小的模块，切忌力求“一步到位”，需要使用过程中不断迭代更新和开发。

1.2 总体目标

通过本项目的建设，拟达到如下目标：

对綦江区县综合行政执法业务形成有效的信息化支撑。

通过本项目的建设，融入先进的城市管理理念，运用先进的信息化技术，制定统一的系统建设技术导则和数据标准，打造城管执法指挥调度智能平台，实现执法办案业务和指挥调度工作电子化、自动化、智能化，提高重庆市城管执法办案各项业务能力和服务水平，提高办案效率和服务满意度，降低执法风险，实现执法办案规范化、指挥调度实时化、监督管理高效化、业务数据可视化、业务辅助智能化，有效落实和推进市委市政府提出的大城智管、大城细管、大城众管的管理要求。

1.3 建设任务及内容

本项目的总体建设任务就是重庆市綦江区县城市管理执法指挥调度智能平台的开发、测试、上线应用，最终实现本项目平台对綦江区县综合行政执法业务的有效支撑。

本项目的总体建设内容主要包括实现指挥调度、执法办案、监督管理、执法巡查、执法管理、系统管理等功能模块。

本项目分为两个阶段推进，在规划设计阶段主要是完成本项目的规划设计和招标准备等工作，在项目建设实施阶段，主要任务还是完成重庆市綦江区县城市管理执法指挥调度智能平台的开发、测试、上线应用。

1.4 系统总体架构和逻辑结构

1.4.1 总体设计思路

本项目设计总体遵循“一套标准、两级平台、三级管理、四级应用”的设计思路。

图5-1 项目总体设计思路图

1.4.1.1 一套标准

即实现全市执法办案平台的建设导则、接口规范及使用考核采用一套统一的标准，推进重庆城市管理执法工作的法制化、标准化。

1.4.1.2 两级平台

即市级执法指挥调度平台和区县执法指挥调度平台，本执法指挥调度平台建设完成后与市级执法指挥调度平台实现接口打通，相关业务数据交互共享。

1.4.1.3 三级管理

即构建一套清晰的“市-区县-街镇”三级执法管理机制，明确各级城管部门在各个业务领域的工作开展机制和联动职责，打造纵向一体化的城市管理综合行政执法组织，提升全市城市管理队伍总体的战斗力。

1.4.1.4 四级应用

即充分梳理市、区县、街镇、执法队员四个层级执法队伍的执法办案应用需求，整个系统的应用将覆盖“市-区县-街镇-单兵”四个层级。

同时，本项目平台的设计还以大城智管、大城细管、大城众管为核心，力求能够支撑城市管理的智慧化、精细化和社会化，有效落实市委市政府在城市管理方面的思路和要求Ø 大城“智”管

  重庆市大城智管主要体现在两个方面，即管理理念的先进性和管理手段的智能化。

  首先，城管管理的理念必须先进和智能，要突破传统的束缚，为此，需要到做的比较好的地区进行交流和学习，充分借鉴其他地区的管理经验和管理理念，并结合重庆市本地特点，形成重庆市的城市管理理念。

  其次，拟通过城管执法指挥调度智能平台的建设，提升重庆市城市管理的智慧化水平，就是改变传统的人海战术，更多运用信息技术手段，实现办案程序标准化、办案文书格式化、执法办案移动化、办案操作规范化、办案证据完整化、办案信息可追溯化、监管实时化，有效提高执法人员执法效率，增强对执法人员的管理效果，提升执法专业化水平，降低执法风险，推进城市的依法管理、依法治理。

Ø 大城“细”管

拟通过城管执法指挥调度智能平台的建设，提升重庆市城市管理的精细化水平，借助于信息化手段，推进城市管理工作的“七定”，即定级、定区域、定路线、定时、定人、定岗、定责。通过“七定”的实施实现城市管理能够全覆盖、全过程、全天候，把精细化管理要求覆盖到各个空间、各个领域和所有人群，贯穿城市管理全过程，体现在一年365天、一天24小时的每时每刻。

Ø 大城“众”管

拟通过城管执法指挥调度智能平台的建设，提升重庆市城市管理的社会化水平，所谓的社会化，就是老百姓、居民等对城市管理的参与程度，城市管理不仅是城管部门的事情，需要发动基层、发动群众，提升群众对城市管理的参与度和满意度，实现城市的共享共治。

1.4.2 总体架构

本项目的总体架构遵循“横向到边、纵向到底”的原则。

Ø 横向到边

“横向到边”指明确城管部门的权力和责任范围，精准定位和划分与其他相关单位（部门）的权责边界，对城管部门权责范围内的业务做到全覆盖，实现横向到边的无缝隙治理。同时，明确各项权责的主导单位（部门）以及协助单位（部门），实现相关单位（部门）的系统对接，联动、协作做好城市治理工作。在管理层面，本项目覆盖了城管部门在市政公用、市容环卫、城市供水排水、园林绿化、风景名胜、环境保护管理、工商管理、交通管理、水务管理、食品药品监管方面市直管及跨区域的各项行政处罚及相应的行政强制职能。在业务应用层面，本项目覆盖了执法办案系统、执法管理系统、指挥调度系统、监督管理系统、执法巡查系统、系统管理。

Ø 纵向到底

“纵向到底”指城管执法相关业务、数据、系统功能等从市执法总队依次纵向贯穿至区执法支队、街镇执法大队、一线执法人员，对四个层级的执法队伍做到全覆盖，实现纵向到底的无缝隙治理。以执法办案数据为例，本项目将统一总队的数据规范和接口，实现执法办案数据“市执法总队—区执法支队—街镇执法大队—一线执法人员”的纵向到底。执法办案数据将在集中存储，并实现实时交互。

图5-2 执法办案数据纵向到底示意图

图5-3 平台总体架构图

Ø 用户访问层

三大用户访问端，即计算机PC端、大屏指挥调度端、移动APP端。

Ø 业务应用层

执法办案系统：主要包括执法办案WEB、执法办案APP。

执法管理系统：主要包括机构管理、人员信息、法律规章、制度建设、信息公开、信用信息、卷宗管理。

指挥调度系统：主要包括勤务管理、诉件处置管理、执法管控、日常指挥、应急指挥、指挥调度移动应用等功能模块。

执法监督系统：主要包括案卷评查、考评管理等功能模块。

执法巡查系统：主要包括巡查计划管理、巡查任务管理、巡查任务下达、巡查任务过程结果跟踪、执法巡查统计、巡查日志管理、巡查终端应用等功能模块。

系统管理：主要包括用户管理、机构管理、权限管理、日志管理等功能模块。

Ø 应用支撑层

案件流程引擎、执法文书引擎、移动执法基础套件、语音识别引擎、人像识别引擎、图像识别引擎、操作系统及数据库。

Ø 基础数据层

违法行为库、案件信息库、执法人员信息库、违法对象信息库、裁量基准库、文书模板库、沿街商铺信息库、双随机抽查对象库。

Ø 数据交互层

主要包括与总队行政执法系统的纵向交互。

Ø 硬件支撑

云平台：主要包括VPN设备、应用服务器、数据库服务器、前置服务器、人像识别服务器、语音识别服务器、存储设备、交换机等。

前端：主要包括执法记录仪、记录仪数据管理终端、移动执法终端等。

1.4.3 总体网络架构

整个平台部署在重庆市电子政务外网中。

其中执法记录仪、执法终端等布置在移动互联网上。

服务器及存储、网络、安全等系统设备均通过租用政务云服务来实现，同时服务器采用x86服务器，便于云资源的扩展。

具体的网络拓扑如下图：

图5-4 网络拓扑图

1.4.4 平台运行机制建设

城管部门不同于公安、司法、工商等兄弟部门，其纵向管理线条和管理能力相对来说较弱，纵向一体化的能力不足，市级执法部门和区级执法部门对街镇的统筹协调和联动能力缺乏有效的管理体系的支撑。若想将重庆市的城管打造为一个整体，那么必须建立清晰的“市-区-街镇”三级执法管理体系，明确各级城管部门在各个业务领域的工作开展机制和联动职责，打造纵向一体化的城市管理组织，提升全市城市管理队伍总体的战斗力。

目前城管执法涉及到的业务主要有办案、勤务、督察、诉件以及考核。本项目拟从这五大业务角度来构建重庆市“市-区-街镇”三级执法管理体系。

1.4.4.1 执法办案管理机制

重庆市城管执法办案管理体系设计为“市-区-街镇”一体化办案流程机制。全市做到三个 “统一”，即统一办案程序、统一办案规范、统一办案数据。

5.4.6.1.1 统一办案程序

即全市只有一套统一的标准化办案程序，保证程序不出错。不仅办案的大程序统一，各个大程序下的小程序也必须统一。城市管理执法办案分为登记、立案、调查、告知、处罚、结案、归档7个大程序。

Ø 登记

根据执法措施的不同，配备不同的系统记录和登记流程。

图5-5 执法办案登记流程图

 

Ø 立案

图5-6 执法办案立案流程图

 

Ø 调查

图5-7 执法办案调查流程图

Ø 告知

图5-8 执法办案告知流程图

Ø 处罚

图5-9 执法办案处罚流程图

Ø 结案及归档

图5-10 执法办案结案及归档流程图

5.4.6.1.2 统一办案规范

即全市只有一套办案规范标准，诸如统一的法规案由库、统一的格式化文书、统一的执法装备配置标准等。

制定全市统一的法规案由库。针对市容环境卫生管理、市政工程管理、绿化管理、水务管理、工商管理等执法事权范围，梳理制定全市统一的法规案由，统一名称、编码、条款说明、处罚项及裁量标准等。

图5-11 重庆市城市管理统一法规条例

图5-12 重庆市城市管理行政执法行政处罚裁量基准

制定全市统一的格式化文书。根据办案的流程和阶段，梳理制定全市统一的各个流程环节的格式化文书。

图5-13 重庆市城市管理执法格式化文书

同时针对“案件登记—立案审批”、“案件调查—案件调查终结审批”、“告知阶段”、“处罚决定（审批）”、“执行阶段”、“结案—归档阶段”及“其他”7大阶段，明确哪些文书需要打印，在APP端和PC端的相关操作要求等。

图5-14 案件登记—立案审批阶段格式化文书操作要求

图5-15 案件调查—案件调查终结审批阶段格式化文书操作要求

图5-16 告知阶段格式化文书操作要求

图5-17 处罚决定（审批）阶段格式化文书操作要求

图5-18 执行阶段格式化文书操作要求

图5-19 结案—归档及其他阶段格式化文书操作要求

制定全市统一的执法装备配置标准和原则。包括配置原则、配置标准、采购要求、技术参数要求、管理要求等。

图5-20 执法装备配置标准图

5.4.6.1.3 统一办案数据

全市各区的案件数据必须统一数据规范和接口，并实时交互给本项目平台，实现执法办案数据市级集中存储，便于执法总队的分析研判。

图5-21 执法办案数据集中管理

1.4.4.2 执法勤务管理机制

5.4.6.2.1 全市统一勤务管理规范

制定全市统一的勤务管理规范。通过设立“八定”机制有效促进全市勤务管理工作模式以及规范的统一。

Ø 定级：勤务区域划分等级

对勤务区域范围进行定级，推进区域的差异化管控，诸如将全市分为一级区域、二级区域、三级区域，针对不同等级区域采用不同的勤务标准、配置不同的勤务资源。

Ø 定区域：勤务区域划分责任网格

勤务范围必须划分为多个明确的勤务区域、责任网格。勤务责任网格不同于传统的智慧化城管中的网格中心设置的网格，两者也没有直接的关系。

Ø 定路线：勤务区域设定勤务路线

系统根据每个区域的实际情况，为执法队员制订勤务路线（绿色线路），区域内有必到的点（红色标记），需要队员进行巡查，并且系统对巡查进行记录，实现全过程管理。

Ø 定岗：勤务区域设立明确岗位

系统根据每个勤务区域的实际情况，进行岗段责任划分，具体到每个队员负责哪一片区域，如文龙大队张三负责九龙大道1号至30实现具体岗位责任到个人，实现全方位精细化管理。

Ø 定人：勤务岗位配置具体人员

结合区域范围的大小，以及事件发生频率，对每个岗位进行人员合理化安排，每个岗位都可进行具体人员配置安排。

Ø 定责：岗位及人员明确职责

根据人员自身实际情况，对其进行岗位安排，并明确相应的职责，具体到区域负责人、责任人、所属部门等。

Ø 定时：既定的勤务频率和响应时限

系统可以根据区域实际情况，对全区的勤务频响应时限制定统一的标准和规定，在系统中实现标准规范化。

Ø 定量：各类资源定量配置

对每个区域配备的执法车辆、对讲机、制动执法终端、执法记录仪、制服、蓝牙打印机等资源进行合理配置，具体分配到每个队员，并划分责任人，合理分配，充分利用资源。

5.4.6.2.2 市-区-街镇三级日常勤务机制

市、区、街镇分别需要对其一线执法队员的执法勤务进行全过程记录。从勤务计划安排开始，一直到最后的勤务日志，形成全过程的执法勤务行为、勤务数据的全过程的记录。

图5-22 全过程留痕

将队员的全天行程串在一起，包括考勤信息、巡查信息、任务处理信息等，形成了队员的工作日志，直观、形象的展示了队员一天的工作轨迹、工作内容、工作成效。

图5-23 执法队员全天执勤相关功能图

5.4.6.2.3 全市一体化勤务指挥及应急响应协同机制

Ø 全市三级指挥调度机制

市级指挥调度中心除了能对下级指挥中心进行互动互动外，还能够直接与全市一线执法人员进行双向互动、发号指挥调度指令。

区级指挥调度中心除了能对本区所辖街镇指挥调度室进行互动指挥外，还能够直接与本区一线执法人员进行双向互动、发号指挥调度指令。

街镇指挥室能够对本街镇所辖人员进行指挥调度。

Ø 全市应急响应协同机制

制定城管执法应急响应机制，一旦出现突发事件、专项整治、重大保障等活动时，能够自动启动相应的应急机制。

各相关单位建立业务和信息的交互联动机制。

通过指调系统能够实现执法人员可视化指挥调度、执法车辆可视化指挥调度、无人机视频调取、执法记录仪视频调取、车载记录仪视频调取等。

1.4.4.3 执法督察管理机制

根据全市执法实际情况，制定一套“市-区-街镇”三级督察机制，主要对各区局执法支队、街镇城管执法大队重点工作推进、依法履职、行为规范、执法服务以及内务管理队列训练等情况进行督查，各区执法支队在市执法总队的总体要求下进一步深化本区督察机制。

5.4.6.3.1 建立全市统一的市-区-街镇三级督察机制

三级督察机制主要分为市级督察、区级督察和街镇督察，分别职责和督察的内容如下：

Ø 市级督察：市级督察员对全市范围内的执法人员和执法活动进行行为规范督察、实效督察和专项督察。

Ø 区级督察：区级督察员对全区范围内的执法人员和执法活动进行行为规范督察、实效督察和专项督察。

Ø 街镇督察：街镇督察员对街镇范围内的执法人员和执法活动进行行为规范督察、实效督察和专项督察。

5.4.6.3.2 建立全市统一的督察规范

本着“公正、公平、客观、公开”的原则，以日常管理、执法业务及管理规范为核心，与现实工作相结合，以强化执行力为重点，以促进各项城市管理措施落实到实处为目的，制定全市统一的行政执法督察规范，由市城市管理局牵头制定统一的城管执法督察工作规范，对整体督察工作提出全方位的要求，各区局以及街镇执法大队在市城市管理综合行政执法总队统一督察规范的指导下，进一步细化自身的督察制度，有效推进督察工作。

1.4.4.4 诉件处置管理机制

5.4.6.4.1 建立诉件三级处置机制

目前诉件分为市级、区级和街镇，其中各级的诉件来源入口也有所不同，其中主要的来源具体如下：

Ø 市级：12345、12319、门户网站、微信、微博、采集员；

Ø 区县级：12319、采集员、短信；

Ø 街镇级：街镇热线、上门投诉。

市中心接到市民诉件后根据区域分拨之对应的区中心，区中心根据诉件信息分配之对应的所属街镇，街镇办根据诉件信息将任务安排至对应的区域的责任执法队员

汇聚多渠道采集的诉件信息，统一录入到案件平台中，通过设置能够实现案件的自动分拨，然后实现案件急速派遣，加快诉件信息传递效率。

通过为执法队员配备智能终端，整合对讲系统，安装手机app等多种技术手段，打通市区街镇的通道，用指挥调度的抓手实现统一的调派。规范化诉件办理过程，实现在诉件办理全过程留痕，便于实时监管诉件办理过程。

5.4.6.4.2 统一全市诉件处置规范和流程

坚持规范、便捷、高效的原则，实行“一口受理、分类处置、限时办结、规范答复、统一反馈”的工作规则，不断提高市民诉件办理质量，提升为民服务水平，制定全市统一诉件三级处置规范和流程。规范化诉件信息公示、诉件专人受理、诉件分类处理、诉件处理反馈、诉件处理流程、诉件责任追溯，明确处置部门分工，规范工作流程，提高办理效率。

图5-24 诉件处置流程图

1.4.4.5 执法考核管理机制

5.4.6.5.1 市-区-街镇三级执法考核机制

为了建立权责明确，行为规范、监督有效、保障有力的市容长效管理机制，进一步完善市-区-街镇三级执法考核体现建设，加强对各区城管执法工作进行考核，制定统一市-区-街镇三级执法考核机制。

Ø 市对区的考核：市只考核到区层级，建立全市统一的考核标准和考核机制。

Ø 区对街镇的考核：由各区在市统一规范要求和指导下自行开展。

5.4.6.5.2 全市统一的行政执法考核管理规范

由市城市管理综合行政执法总队牵头制定统一的行政执法考核管理规范，对考核工作的组织、考核主体、考核对象、考核的内容、考核标准、打分方式、考核结果的使用等提出指导性建议。各区及街镇在市执法总队的大框架下开展本辖区内的执法考核工作，打分考核指标的一级指标。

市执法总队负责对区执法支队进行考核；区执法支队负责对街镇执法大队进行考核；街镇执法大队负责对执法队员进行考核，区执法支队需要将执法考核结果数据同步至市执法总队数据库中。 

图5-25 执法考核指标示例

1.4.5 主要技术路线

为了确保重庆市綦江区县城市管理综合行政执法支队管理需要的“重庆市綦江区县城市管理执法指挥调度智能平台”的正常运行，软件系统的搭建要有良好的支撑平台及相关研发技术工具，确保软件系统的稳定性与扩展性。

1.4.5.1 技术架构选择

系统架构采用B/S（Browser/Server 浏览器端/服务器端）的互联网应用模式，便于更新、维护和升级，目前兴起的前端展现新技术RIA（Rich Internet Application）将B/S应用的用户操作友好性和便捷性提高了行多，能够融合C/S模式的优点，已经成为了网络化信息系统的不二选择。

1.4.5.2 部署架构选择

云平台的基础是一系列存储服务，存储技术成熟度决定了云平台的发展前景。重庆市綦江区县城市管理执法指挥调度智能平台部署在重庆市政务云上，可根据访问用户量和并发需求适时实行应用服务集群，数据库实行双机RAC。重庆市綦江区县城市管理执法指挥调度智能平台建立与城管局智慧城管系统、区县级城市管理综合执法系统的数据交互接口。本项目系统采购云架构部署方式，部署在重庆市政务云中。

1.4.5.3 基于SOA的设计思想

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

SOA有以下特性：

SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web SOA蓝图ervices Description Language）是用于描述服务的标准语言。

SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。

④每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。

⑤不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

⑥一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。　

⑦服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

SOA基础结构：

要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。

WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将会讨论一些QoS服务和相关标准。

WEB服务安全：

Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。

SOA可靠性：

在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。

通信策略：

服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。

通信控制：

当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。

服务管理：

随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。

其它的qos特性，比如合作方之间的沟通和通讯，多个服务之间的事务处理，都在WS-Coordination 和 WS-Transaction 标准中描述， 这些都是OASIS 的工作。

SOA 不是Web服务：

在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。

SOA的优势：

SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的影响；SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

SOA发展出来的效益：

A. 平衡最初的旧系统投资(Leverage initial investment)：

组织过去所投资的系统、软硬体，如果能再利用等於赋予其新的价值，这也替组织降低成本并增加竞争力。

B. 基础建设的便利性(Infrastructure Commoditization)：

让所有的应用程式能相互沟通(互通性)。

C. 快速的接近市场(Faster time-to-market)：

服务的重复使用(再利用)，来缩短过去的组织流程，更快速的提供服务来接近市场。

D. 减少支出(Reduce Cost)：

服务的重复使用，可降低开发成本。因为开发新系统的成本，大部份比更新旧有系统来的花费大。

E. 减低风险(Risk mitigation)：

开发新系统的风险远大於更新旧系统。

F. 持续改善商业流程的循环(Continuous improvement cycle for business process)

G. 中心流程处理(Process-centric processing)

实施SOA可能带来的主要优势有5点：

一，SOA可通过互联网服务器发布，从而突破企业内网的限制，实现与供应链上下游伙伴业务的紧密结合。通过SOA架构，企业可以与其业务伙伴直接建立新渠道，建立新伙伴的成本得以降低。

二，SOA与平台无关，减少了业务应用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，对其业务伙伴具体采用什么技术没有限制。

三， SOA具有低耦合性特点，增加和减少业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关系不断发生变化的情况下，节省的费用会越来越多。

四， SOA具有可按模块分阶段进行实施的优势。可以成功一步再做下一步，将实施对企业的冲击减少到最小。

五， SOA的实施可能并不具有成本显著性。这要分三种情况加以讨论：

当企业从零开始构建业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。　　

当企业业务发展或发生企业重组等变化而原有系统不能满足需要，而需要重构业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。

当企业业务发生缓慢变化并可预见到将来需要重构业务系统时，由于可以按模块分阶段逐步实施SOA以适应变化的需要，这样企业不需一下投入一大笔经费进行系统改造，而是根据企业业务发展情况和资金情况逐步投入，缓解了信息投入的压力。

本设计方案中，采用SOA架构的设计思想，实现跨多个机构和部门的系统整合、数据共享及业务流程贯穿。

1.4.5.4 B/S和C/S架构相结合

这两种模式各有优缺点，C/S 模式的应用系统功能会相对更加完善，但是同时也可能会比较复杂，造价较高。B/S 模式的应用系统的使用会相对方便，用户可以直接使用IE浏览器来实现各种GIS 功能的操作，系统建设的成本较低。

1.4.5.5 XML

可扩展标记语言（Extensible Markup Language，XML）提供了一种标记内容的方式，是W3C定义的数据描述语言，可以添加关于数据用途的信息。信息使用 XML 存储之后，称为解析器的应用程序就能够可靠地提取相关信息，并根据不同的需要处理。

XML用严格的嵌套标记表示数据信息，特别适合在Internet环境中的多点数据交换环境下使用。在G2G或B2B应用环境中，XML是一种非常优秀且极为适合的政务信息交换技术。G2G解决方案的软件提供商制订了用于G2G应用之间交换商务信息的XML格式。用XML来描述商务信息使得各种B2B应用在数据层上具有了开放集成的能力。

XML 可用于各种不同的应用程序，但其实质是：XML 是一种表示数据的方式。有时候数据是为数据库准备的，有些时候则是供人阅读的。与这两方面应用相关的技术，比如数据验证和 XML 转换也已经随着 XML 自身一起发展起来。

XML 包括验证或者确认的能力、文档结构和文档（在某种意义上的）内容。验证文档有助于防止数据与期望具有特定结构的应用程序进行交互时出现问题，当 XML 与非 XML 的遗留系统交互时这一点尤其有用。最初的 XML 1.0 推荐标准包括对文档类型定义（Document Type Definitions，DTD）的支持，DTD 提供了一些验证能力。W3C XML Schemas 扩展了这种功能，并提供了一种更加类似 XML 的语法。

可通过多种方式使用 XML 封装的数据。一种常见的处理方式是通过使用可扩展样式表语言转换（Extensible Stylesheet Language Transformations，XSLT），开发人员可以使用 XSLT 定义对 XML 文档的操作，以生成特定的结果。这种动态转换信息的能力允许从单个源文档产生多种输出，无论输出到不同的数据库还是输出到不同的浏览器。

XML主要有三个要素：Schema（模式）、XSL（eXtensible Stylesheet Language可扩展样式语言）和XLL（eXtensible Link Language可扩展链接语言）。Schema规定了XML文档的逻辑结构，定义了XML文档中的元素、元素的属性以及元素和元素的属性之间的关系，它能够帮助XML的解析器校验XML文档标记是否合法；XSL是用来规定XML文档表现形式的语言，同CSS类似；XLL则进一步地扩展了当前Web上已有的简单链接。

XML具有以下特点：

1.自我解释的数据。和传统数据库比较，XML数据不需要诸如关系纲要，文件描述列表，外部数据定义等附加信息，数据本身就包含这些信息。和更为广泛使用的Web格式HTML比较，不但提供了HTML正确显示数据的功能，还确保的数据的可用性。这对于不仅仅需要显示数据的应用来说，是极其关键的。

2.对所有传统数据库和格式的完全整合。XML文档能够包容可以想象的所有数据类型——从文本和数字这样的典型数据到如音频一样的多媒体对象，到ActiveX组件。

3.国际化。对电子商务而言，国际化时极其重要的。XML支持多语言文档和标准Unicode。

4.面向未来的技术。XML为World Wide Web Consortium（W3C）和其他一些主要的软件供应商支持，而且XML已经成为越来越多的领域的标准。

XML给基于Web的应用软件赋予了强大的功能和灵活性：

◆ 更有意义的搜索；

◆ 开发灵活的Web应用软件；

◆ 不同来源数据的集成；

◆ 多种应用得到的数据；

◆ 数据的本地计算和处理；

◆ 数据的多样显示；

◆ 粒状的更新；

◆ 在Web上发布数据；

◆ 升级性；压缩性；开放的标准；众多软件产品的支持；

◆ 在本方案中，XML技术主要用作不同应用系统之间信息交换的标准。

1.4.5.6 Web Service

Web Services是自包含的、模块化的应用程序，它可以在网络（通常为Web）中被描述、发布、查找以及调用。

Web Services是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。

所谓Web服务，它是指由企业发布的完成其特别商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项应用服务。

Web 服务的一个主要思想，就是未来的应用将由一组应用了网络的服务组合而成。只要两个等同的服务使用统一标准和中性的方法在网络上宣传自己，那么从理论上说，一个应用程序就可以根据价格或者性能的标准，从两个彼此竞争的服务之中选出一个。除此之外，一些服务允许在机器之间复制，因而可以通过把有用的服务复制到本地储存库，来提高允许运行在特定的计算机（群）上的应用程序的性能。

Web Services体系结构是面向对象分析与设计（OOAD）的一种合理发展，同时也是电子政务解决方案中，面向体系结构、设计、实现与部署而采用的组件化的合理发展。这两种方式在复杂的大型系统中经受住了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也是Web Services中的基本概念，而且，Web Services另外一个基本概念就是：所有东西都是服务，这些服务发布一个API供网络中的其他服务使用，并且封装了实现细节。

Web Services以技术栈的形式规范了Web Services体系中的各类关键技术,包括服务的描述、发布、发现以及消息的传输等，

Work Flow WSFL

Universal Description, Discovery, and Integration UDDI

Services DescriptionWSDL

Messaging SOAP

Extensible Markup Language XML

Transport ProtocolsHTTP and others

Web Services技术栈：

1.XML和HTTP。这是Web Services最基本的平台。HTTP是一个在Internet上广泛使用的协议,为Web Services部件通过Internet交互奠定了协议基础，并具有穿透防火墙的良好特性。XML是一种元语言, 可以用来定义和描述结构化数据，它是Web Services得以实现的语言基础。Web Services的其它协议规范都是以XML形式来描述和表达的。

2.SOAP(Simple Object Access Protocol)。SOAP协议最先由Microsoft公司提交给W3C组织,并于2000年4月通过1.0版本。它是SOA架构实现的线缆级协议,定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息,用HTTP来承载消息。SOAP包括三部分:定义了描述消息和如何处理消息的框架的封包（SOAP封包）、表达应用程序定义的数据类型实例的编码规则（SOAP编码规则）以及描述远程过程调用和应答的协定（SOAPRPC表示）。

3.WSDL(Web Service Description Language)。WSDL由Microsoft, IBM, Ariba三家公司在2000年9月推出。它是Microsoft公司的SDL（Services Description Language）、IBM公司的NASSL（Network-Accessible Services Specification Language）合并后被Ｗ３Ｃ接纳所形成的标准。

WSDL为服务提供者提供以XML格式描述Web Services请求的标准格式，将网络服务描述为能够进行消息交换的通信端点的集合，以表达一个Web Services能做什么,它的位置在哪里,如何调用它等。

4.UDDI (Universal Discovery, Description, Integration)。UDDI规范由Microsoft, IBM, Ariba三家公司在2000年7月提出。它是在原有Microsoft提出的DISCO(Discovery of Web Services)和IBM的ADS(Advertisement and Discovery of Services)的基础上发展而来的。

UDDI是Web Services的信息注册规范,以便被需要该服务的用户发现和使用它。UDDI规范描述了Web Services的概念,同时也定义了一种编程接口。通过UDDI提供的标准接口,企业可以发布自己的Web Services供其它企业查询、调用;也可以查询特定服务的描述信息,并动态绑定到该服务上。通过UDDI，Web Services可以真正实现信息的“一次注册,到处访问”。

5.WSFL(Web Services Flow Language)。由IBM提出，使用WSDL和WSEL(Web Services Endpoint Language)来描述服务接口和它们的协议绑定。WSEL是用来描述非操作性的服务特征(如服务质量等)的一种语言。

系统的业务功能和基础支撑功能都可以按照服务来进行封装，为功能调用，系统集成，架构扩展打下了良好的基础。

在软件系统的开发过程中，系统集成主要实现系统的各部分（模块）之间的通讯和整合，将相对分散的子系统组成一个统一的整体，实现子系统间的功能控制和信息交互与共享。基于Web Service的集成技术作为一种新的面向函数和方法的应用集成技术，在很大程度上解决了原有集成技术在Internet远程通信方面的问题。Web Service基于XML文档进行服务描述，服务请求和反馈结果，可以在Internet上通过HTTP协议进行传递，很容易的被访问和返回结果。同时，由于Web Service的相关标准都是W3C的开放协议，与平台和操作系统无关，不同的平台和操作系统上的Web Service的实现在很大程度上可以做到互操作，这就使异构平台上应用的集成变得很容易。此外，过去使用的基于RPC（RPC - Remote Procedure Call，远程过程调用）和API（Application Programming Interface，程序编程接口）的集成技术都是一种函数级的静态解决方案（即使它们在客户机和服务器通讯时使用XML）；Web Service则是一种动态的集成方案，所有的服务都可以通过UDDI标准动态地被发现、绑定和使用，容易适应系统的变动，提高系统的灵活性和伸缩性。

使用Web Service技术进行系统集成和过去使用其它面向函数和方法的技术进行集成类似：在进行初始设计的时候主要考虑不同应用之间，系统不同模块之间消息及数据传递的需求；根据具体需求设置相应的接口，描述接口特性；针对不同应用的平台选择相应的Web Service组件，进行相应设置；实现不同应用的接口，进行相应调试；实际运行，应用程序间进行协同调试。

---

关注我的技术公众号，每个工作日都有优质技术文章推送和电子版方案下载。

微信扫一扫下方二维码即可关注：

---