ICS
备案号：
Q/CSG
Q/CSG11817-2010 中国南方电网责任有限公司企业标准
面向服务的信息技术架构（SOA）框架规范
2010-04-20 发布 2010-05-01 实施 中国南方电网责任有限公司 发 布 Q/CSG11817-2010
目 次
前 言 ............................................................................ III 1 范围 ............................................................................... 1 2 规范性引用文件 ..................................................................... 1 3 术语与定义 ......................................................................... 1 3.1 面向服务的体系结构 ............................................................... 1 3.2 服务 ............................................................................. 1 3.3 企业服务总线 ..................................................................... 1 3.4 企业资源规划 ..................................................................... 1 3.5 企业应用集成 ..................................................................... 1 3.6 企业信息门户 ..................................................................... 1 3.7 SOA项目 .......................................................................... 1 4 总则 ............................................................................... 1 4.1 持续发展原则 ..................................................................... 1 4.2 先进性原则 ....................................................................... 2 4.3 实用性原则 ....................................................................... 2 4.4 操作性原则 ....................................................................... 2 5 SOA架构模型 ........................................................................ 2 5.1 服务体系 ......................................................................... 2 5.1.1 服务体系设计依据 ............................................................... 2 5.1.2 服务体系图 ..................................................................... 2 5.1.3 服务体系各层定义 ............................................................... 3 5.2 应用体系 ......................................................................... 4 5.3 服务部署体系 ..................................................................... 5 5.4 技术标准规范体系 ................................................................. 6 5.4.1 技术标准规范体系图 ............................................................. 6 5.4.2 服务开发技术标准规范 ........................................................... 9 5.4.3 服务集成技术标准规范 .......................................................... 13 5.5 SOA架构模型特征 ................................................................. 14 6 SOA服务设计与开发 ................................................................. 14 6.1 服务识别 ........................................................................ 14 6.2 服务定义 ........................................................................ 14 6.3 服务设计 ........................................................................ 16 6.3.1 总体设计原则 .................................................................. 16 6.3.2 访问服务 ...................................................................... 16 6.3.3 数据服务 ...................................................................... 17 6.3.4 业务服务 ...................................................................... 17 6.3.5 流程服务 ...................................................................... 17 6.3.6 综合服务 ...................................................................... 17 6.3.7 展现服务 ...................................................................... 17 6.4 服务实现 ........................................................................ 18 6.4.1 服务封装原则 .................................................................. 18 6.4.2 服务封装方式 .................................................................. 18 7 SOA服务集成 ....................................................................... 18
I
Q/CSG11817-2010
7.1 企业服务总线 .................................................................... 18 7.2 服务描述 ........................................................................ 19 7.3 服务注册/发布 ................................................................... 19 7.4 服务发现/调用 ................................................................... 19 7.5 服务编排 ........................................................................ 19 7.6 服务管理 ........................................................................ 19 7.6.1 管理内容 ...................................................................... 19 7.6.2 参考流程 ...................................................................... 20 8 SOA项目管理 ....................................................................... 24 8.1 项目实施方法 .................................................................... 24 8.2 项目实施策略 .................................................................... 24 8.3 项目实施路线 .................................................................... 25 8.4 项目实施步骤 .................................................................... 26 8.4.1 项目准备 ...................................................................... 26 8.4.2 项目需求分析 .................................................................. 27 8.4.3 项目设计与实现 ................................................................ 27 8.5 项目验收 ........................................................................ 28 8.5.1 总体要求 ...................................................................... 28 8.5.2 验收文档规范 .................................................................. 28
II
Q/CSG11817-2010
前 言
随着中国南方电网有限责任公司（以下简称为南方电网公司）企业信息化应用的不断发展和信息资源的不断积累，公司在探讨与实践企业信息技术架构时认识到：多元化的信息技术架构不利于企业信息化应用的发展和企业信息资源的积累与共享。多年来信息化建设的实践证明：不同信息技术架构造成了技术体系复杂混乱、技术标准不兼容、IT系统间互操作性差、上下信息交换不通畅、IT管理不规范等弊端。
企业的业务的不断发展变化需要多套应用系统同时支撑业务运行和管理，一个好的信息技术架构不应割裂IT与实际业务之间的联系，而是应更好、更快地适应业务的变化。通过前期对“ERP套装软件”、专业开发+应用集成/信息门户”、及“面向服务的架构（SOA）”三种具有代表性的应用系统建设模式进行分析表明：SOA代表了应用系统建设模式及信息技术架构的发展方向，无论是ERP厂商还是应用集成/信息门户（EAI/EIP）平台厂商，都在逐步采用SOA的理念和技术。SOA使得IT能够更好地提供业务价值，更灵活、更易于重用。因此，南方电网公司选择SOA架构作为未来信息化建设统一的技术路线。
本规范立足于南方电网公司“十一五”信息化规划的战略发展高度，定义统一、先进与实用的面向服务的信息技术架构（以下简称：SOA架构）框架规范，以实现南方电网公司信息一体化体系中“构建南方电网公司开放的、集成的、一体化的信息化应用环境”的目标，健全南方电网公司信息化标准体系。
本规范旨在为南方电网公司统一实施SOA架构提供通用性的指导，各分、子公司可根据各自应用系统建设的实际需求，在不违背本规范原则的前提下，对其进行不同深度与广度的扩展。
本标准由中国南方电网公司信息中心提出、归口并解释。
本标准主要起草单位：南网信息中心、超高压公司、调峰调频公司、广东电网公司、广西电网公司、云南电网公司、贵州电网公司、海南电网公司。
本标准主要起草人：王志英、张建民、张诗军、蔡徽、徐兵元、萧展辉、解文艳、刘杰、朱永虎、汪浩、郭玮、陈俊、朱金所、王波、翁小云、曹建海、李小福、朱震宇
本标准由中国南方电网有限责任公司标准化委员会批准。 本标准自颁发之日起实施。
III
Q/CSG11817-2010
面向服务的信息技术架构（SOA）框架规范
1
范围
本规范适用于南方电网公司基于SOA架构的应用系统开发和企业应用集成、SOA项目咨询以及SOA项目监理。
2
规范性引用文件
下列文件中的条款通过本标准的引用而构成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，但鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
《中国南方电网公司“十一五”信息化规划》 《中国南方电网公司信息分类与编码标准》
3
术语与定义
3.1 面向服务的体系结构
面向服务的体系结构（Service-Oriented Architecture），即SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期。SOA以服务为核心，来实现的IT系统更灵活、更易于重用、更好（也更快）地应对变化。 3.2 服务
在SOA架构中，服务是最核心的抽象手段，它具有明确的功能，通常封装着业务功能或者数据。一个服务包括接口（Interface）、契约（Contract）和实现（Implementation）三个部分。服务的接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互。 3.3 企业服务总线
企业服务总线(Enterprise Service Bus) ，以下简称ESB,是一种在松散耦合的服务和应用之间标准的集成方式，提供简单、快速、基于标准的多点集成，类似硬件中的总线结构。 3.4 企业资源规划
企业资源规划(Enterprise Resource Planning) ，即ERP是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。狭义的ERP仅仅局限在制造业的企业资源规划方面，广义的ERP随着供需链管理（SCM）和企业业务流程重组（BPR）等管理理论的引入，实现了企业人、财、物、信息等所有的资源和产、供销等所有业务。 3.5 企业应用集成
企业应用集成(Enterprise Application Integration) ，即EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其它重要的内部系统之间无缝地共享和交换数据的需要。 3.6 企业信息门户
企业信息门户(Enterprise Information Portal) ，即EIP是一个应用系统，它使企业能够释放存储在内部和外部的各种信息，让用户能够从单一的渠道访问其所需的个性化信息。 3.7 SOA项目
本规范中的SOA项目是指南方电网公司基于SOA架构的应用系统建设或集成项目。
4
总则
信息技术架构是指导信息化建设的技术框架，信息化应用项目的建设必须遵从这个框架的要求，以促进信息化应用项目建设的高效率、高质量、高标准和可持续发展。南方电网公司SOA架构设计遵循下述原则：
4.1 持续发展原则
1
Q/CSG11817-2010
基于目前南方电网公司信息技术架构模型的现状，站在南方电网公司企业发展以及信息化发展的战略高度，统一南方电网公司信息技术架构模型，以实现信息化建设的高效率、高质量、高标准和可持续发展为原则。 4.2 先进性原则
必须坚持与世界先进技术发展水平同步，遵循相关的技术规范及标准，保证能满足目前与未来信息化建设的需求。 4.3 实用性原则
以重用、协作和资源共享为基础，确立信息技术架构模型和技术部署的最佳实践，为实施信息技术架构模型制定策略与方法，以利于引导信息化建设项目的实施。 4.4 操作性原则
综合考虑目前南方电网公司信息化建设的实际，使多元化的信息技术架构模型能逐步过渡到统一的信息技术架构模型。
5
SOA架构模型
参考国际结构化信息标准促进组织（OASIS）发布的SOA参考模型，结合南方电网公司信息化建设的实际，在上述总体设计原则的指导下，本章定义了南方电网公司SOA架构模型，以下从四个不同的角度描述的子模型进行说明。 5.1 服务体系
5.1.1 服务体系设计依据
（一）SOA架构的核心理念是打破传统面向各个业务领域的、僵化的垂直应用构建模式，将应用分解为可重用、松耦合、互操作的服务体系结构，通过服务的编排组合来实现业务的组合，通过服务的松耦合来满足业务变化和调整，通过服务的重用来降低软件开发的成本。
（二）南方电网公司SOA架构之服务体系采用组件化的分层结构设计思想，使其具有预制性、封装性、透明性、互操作性、通用性等特征，便于快速地组装新的应用。上层的服务依赖于下层的服务来实现，而不需要了解下层的实现逻辑，通过服务的分层，降低服务之间的耦合度，提高可重用性。
5.1.2 服务体系图
南方电网公司SOA架构之服务体系建立在企业的信息资源层之上，包括但不限于下述六层：访问服务层、数据服务层、业务服务层、流程服务层、综合服务层、展现服务层。信息资源层为上层提供应用资源（应用系统模块）与数据资源，它包括传统的封闭的应用系统、已经打包好的应用程序、业务系统数据库、数据仓库、非结构化数据等。。
2
Q/CSG11817-2010
展现服务层综合服务层流程服务层业务服务层数据服务层访问服务层门户组件人机交互组件网页组件报表组件...跨业务域综合服务跨部门综合服务跨单位综合服务...自动流程服务人工交互流程服务流程引擎流程监控...工程业务服务...数据同步...营销业务服务生产业务服务财务业务服务数据转换数据映射数据聚合适配器 用户API JDBC 消息... 信息资源层图1 遗留系统打包应用业务数据数据仓库非结构化数据...图5.1 SOA服务体系图
南方电网公司基于SOA架构的应用至少应包括数据服务层和业务服务层，为了更好地实现个性化和灵活的表现形式，通常还应包括展现服务层。针对某些具体的应用，可以根据实际情况对六层服务体系架构进行简化与合并，例如：当只需要访问关系型数据库时，可以考虑将访问服务层与数据服务层合并；当应用系统比较简单时，可能不需要流程服务层及综合服务层。 5.1.3 服务体系各层定义
（一）访问服务层：访问服务层实现与底层数据资源、应用资源的通信功能，使用通用标准接口，定义整合企业信息资源（数据资源与应用资源）的各种访问服务，例如：不同类型的适配器以及专用的API等等。访问服务屏蔽了企业信息资源（现在的或未来的）的技术和实现方式，访问服务层之上的开发者无需知道数据的位置、类型以及应用程序的编程语言等。
（二）数据服务层：数据服务层定义的服务支持把异构的、孤立的企业数据转变成集成的、双向的、可重复使用的信息资源。数据服务通过访问服务层以统一的方式访问企业的所有数据，数据服务层之上的开发者可以集中精力处理数据的加工问题，而不必关注访问不同来源的数据的实现细节。
（三）业务服务层：业务服务层定义那些可重用的业务处理过程，用于支持复合的业务处理需求。这层定义的业务处理过程服务可能是单个原子事务的无状态处理操作服务，也可能是多个业务应用或异步服务之间交互的有状态处理操作服务。业务服务层之上的开发者无需知道具体某项业务的逻辑处理过程。
（四）流程服务层：业务流程是一组服务的集合，服务按照特定的顺序并使用一组特定的规则进行调用，其本身也可视为服务。流程服务层定义有状态的（长期运行或需要人工参与）、完整的业务流程。流程服务通过对下层的数据服务、业务服务的编排来实现，流程编排的规则在该层内定义。
（五）综合服务层：综合服务层以提升企业综合管理职能、优化企业价值链为出发点，规划跨系统、跨业务管理职能域、跨单位的服务。综合服务层定义的服务是由下层的访问服务、数据服务、业务服务、流程服务组合而成的服务，目的是通过服务的简单编排就可以快速搭建出新的业务应用系统。
3
Q/CSG11817-2010
（六）展现服务层，展现服务层定义企业信息门户（EIP）中可配置、可重用的门户组件（Portlets），用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件实现对不同客户接入方式的支持，并提供丰富的客户端展现方式。 5.2 应用体系
基于SOA架构的应用系统由服务库中的各类服务，通过ESB组合而成。服务库中的服务既包括新开发的服务，也包括将已有的应用系统资源中需要共享的内容封装而成的服务。
1、通过ESB对SOA服务库的各类“服务”的定义、注册、使用、维护、弃用与退役实现全生命周期的规范管理。
2、ESB接入的数据源类型包括：关系型数据库、Web服务、XML文件、文本文件、JAVA函数等。业务系统数据可直接抽取到数据中心，数据中心本身也可以作为一个数据源接入到ESB，供业务系统共享使用。
3、对于生产系统中的自动化控制类等对性能要求较高的实时应用系统，建议采用传统的技术路线包括：直接访问业务系统数据库、文件或者网页的方式，但其中某些业务功能也允许被封装为业务服务供其它应用集成者调用。
SOA应用系统服务流程服务综合服务企业服务总线ESB服务目录服务编排数据服务访问服务业务服务展现服务服务库 封装 配置/开发组件<<接口>>适配器 开发 开发组件非SOA应用系统数据源系统1系统2系统3...图5.2 SOA应用体系视图
4
Q/CSG11817-2010
5.3 服务部署体系
（一）服务部署架构：在还未全部实现应用系统省级大集中的情况下，允许按“南网总部—省公司—地市供电局”的三级管理体系部署服务，并依据“服务资产”的归属权、共享范围以及维护责任分别部署在各自的服务目录与服务库中。最终目标是要实现按“南网总部---省公司”的两级服务部署。ESB是实现服务集成与管理的枢纽，调用者只能看到总线提供的代理服务，总线后台真正的服务对调用者来说是透明的。
（二）服务部署与调用策略规范如下：
1、在应用系统省级大集中情况下：服务目录、服务库和ESB分别部署在南方电网公司总部、省公司（或分公司）两级；在未实现应用系统省级大集中的情况下：服务目录、服务库和ESB分别部署在南方电网公司总部、省公司（或分公司）及地市供电局三级。
2、无论是南方电网公司总部、省公司（或分公司）还是地市供电局，对本地服务的调用只须经过本地的ESB。
3、南方电网公司总部开发的、经过审批的服务登记到总部的服务目录中，对这些服务的调用都必须经过南方电网公司总部的ESB。
4、省公司（或分公司）开发的全南网范围内共享的服务，在经过南方电网公司审批后也被登记到南方电网公司总部的服务目录中，省公司（或分公司）的ESB通过访问南方电网公司总部的服务目录查找全网范围内共享的服务。
5、省公司（或分公司）之间服务的异地调用，必须经过南方电网公司总部的ESB实现。
6、省公司（或分公司）开发的、经过审批的、提供给自己及下属单位调用的服务登记到省公司（或分公司）的服务目录中，对这些服务的调用都必须经过省公司（或分公司）的ESB。
7、地市供电局开发的全省网范围内共享的服务，在经过省公司审批后也被登记到省公司的服务目录中，各地市供电局的ESB通过访问省公司的服务目录查找全省范围内共享的服务。
8、地市供电局的服务目录只登记本地市开发的、经过审批的、提供给自己调用的服务。 9、地市供电局之间服务的异地调用，必须经过省公司的ESB实现。
5
Q/CSG11817-2010
服务提供者注册/发布服务消费者发现/调用服务管理者配置/管理/监控服务目录服务库服务管理服务注册服务报废服务监控服务维护服务策略服务水平南网总部服务总线省级集中非省级集中服务提供者注册/发布服务消费者发现/调用服务管理者配置/管理/监控服务提供者注册/发布服务消费者发现/调用服务提供者配置/管理/监控...服务目录服务库服务管理服务注册服务报废服务监控服务维护服务策略服务水平服务目录服务库服务管理服务注册服务报废服务监控服务维护服务策略服务水平注册/发布省公司服务总线服务提供者服务消费者发现/调用服务管理者配置/管理/监控省公司服务总线服务目录服务库服务管理服务注册服务报废服务监控服务维护服务策略服务水平...地市供电局服务总线
图2 图5.3 SOA服务部署视图
5.4 技术标准规范体系
（一）本节从IT技术实现的角度，定义了SOA服务开发与集成必须遵循的标准或规范，以保证南网电网公司内部共享服务的一致性和可重用性。各分子公司可结合各自现有应用系统建设情况和集成需求，制定相关的数据集成、流程集成、服务集成等建设规范。
（二）SOA服务开发与集成技术标准规范的选择必须满足但不限于下述指导原则：
1、以Web Service技术作为SOA服务开发技术的首选技术，并要求遵循WS-I Basic Profile 1.0的有关指引；
2、以Java技术作为Web Service开发的优先选择技术；
3、为了最大限度地复用现有应用系统的业务功能，在选择SOA技术标准规范时，必须考虑现有业务功能封装对技术标准规范的支持能力；
4、在选择SOA技术标准规范时，应重点定义“服务接口”和消息协议标准或规范，对服务内部功能实现所采用的技术标准规范可不加限制；
5、凡与SOA重用性密切相关的组件，如服务接口，必须采用成熟的技术标准规范；
6、对还没有最后定案的事实标准或规范（这类标准通常不是被所有软件平台和开发商支持，或者还不是很成熟，或者产品的支持与产品之间的兼容性差），作为可选技术参考使用；
7、为了充分利用企业现有的IT资产，降低开发难度和成本，可以考虑采用现有系统已经支持或采用的技术标准规范；
8、IT部门员工目前熟悉并掌握的技术标准规范也可作为选用依据之一，SOA服务的实现通常不限制采用何种技术，因此，服务的“实现”可采用IT部门员工目前熟悉的技术或规范开发。 5.4.1 技术标准规范体系图
6
Q/CSG11817-2010
（一）SOA架构之服务体系各层以及层与层之间必须遵循相关的技术标准规范，这些标准规范包括：访问服务、数据服务 、业务服务、流程服务、展现服务的技术标准规范，以及贯穿各层之间的消息交换、消息传输、安全管理、服务描述、注册与发现等技术标准规范。
（二）SOA架构技术标准规范体系如下图所示：
展现服务(JSR186、WSRP、HTML、JSP、AJAX)消息交换(XML,XML Schema、SOAP、SDO)消息传输(HTTP/S、RMI、JMS、FTP)综合服务(BPEL、BPMN、WS-CDL)流程服务(BPEL、BPMN)业务服务(EJB、SCA)数据服务(JDBC、Xquery)安全管理(WSDM，SSL/TSL,WS-系列、)服务描述、注册与发现（WSDL、UDDI)访问服务(JCA、JDBC、专用API)图5.4 SOA技术标准规范体系图
（三）SOA架构技术标准规范体系内容： 1、访问服务
JCA(Java Connector Architecture)：JCA定义了一套标准的接口，用于让连接器把兼容的应用程序服务器无缝地整合起来，以及提供标准接口允许客户(或者应用程序服务器的应用程序主机）用一种统一的方法使用连接器。
JDBC（Java Data Base Connectivity，java数据库连接）：JDBC是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC为程序开发提供标准的接口，并为数据库厂商及第三方中间件厂商实现与数据库的连接提供了标准方法。
专用API(Application Programming Interface)：专用API是针对某个具体软件产品（例如：Louts Notes、SAP）提供的编程接口。
2、数据服务
XQuery（XML Query）：XQuery是W3C所制定的一套标准，用来从类XML文档中提取信息，类XML文档可以理解成一切符合XML数据模型和接口的实体，他们可能是文件或关系型数据库。
3、业务服务
SCA(Service Component Architecture)：SCA即服务组件架构，它提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA支持实现服务组件的各种技术及连接服务组件的各种存取方法。
EJB(Enterprise JavaBean)：EJB是一个可重用的，可移植的J2EE组件。EJB由封装了业务逻辑的多个方法组成。EJB运行在一个容器里，多个远程和本地客户端可以调用这个方法，允许开发者只关注与bean中的业务逻辑而不用考虑事务支持、安全性和远程对象访问等复杂和容易出错的事情。
4、流程服务
BPMN（Business Process Modeling Notation）：BPMN是一个业务流程建模和Web服务标准，其首要目标是提供一个通俗易懂的标注体系，另外一个重要目标是提供内部模型，便于下一代XML语言对业务流程的执行。
BPEL（Business Process Execution Language）：BPEL也被称为BPELWS或BPEL4WS（Web服务业务流程执行语言）。它是一种可执行语言，能够与各种业务流程自动化的软件系统相兼容，通过说明性
7
Q/CSG11817-2010
的方式(而不是编程的方式)表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，BPM产品基于此规范实现。
WS-CDL（Web Services Choreography Definition Language）：WS-CDL 即Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点(endpoints)都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排。
5、展现服务
JSR168（Java Specification Request 168）：JSR168是java 规范要求，主要应用在Portal软件的开发。它为创建Portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其它web应用程序之间的互操作性而设计的。
WSRP（Web Services for Remote Portlets）：WSRP定义了如何利用基于SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 Portlet，而不需要门户开发人员进行任何编程。WSRP是由OASIS组织制定的。
HTML（HyperTextMark-upLanguage）：HTML即超文本标记语言或超文本链接标示语言，是WWW的描述语言。
JSP(JavaServer Pages)：JSP是一种动态网页技术标准，JSP将网页逻辑与网页设计和显示分离，由HTML代码和嵌入其中的Java代码所组成，支持可重用的基于组件的设计。JSP页面是跨平台的，即能在Windows下运行，也能在Linux等其它操作系统上运行。
AJAX（Asynchronous JavaScript and XML）：AJAX是一种创建交互式网页应用的网页开发技术。AJAX仅向服务器发送并取回必需的数据，它使用SOAP或其它一些基于XML的web service接口，并在客户端采用JavaScript处理来自服务器的响应。
6、消息传输
HTTP（Hypertext Transfer Protocol）：HTTP即超文本传输协议是用于从Web服务器传输超文本到本地浏览器的传送协议。HTTPS（Secure Hypertext Transfer Protocol），又称安全超文本传输协议，其安全基础是SSL，使用40 位关键字作为RC4流加密算法。
RMI(Remote Method Invocation)：RMI即远程对象访问传输协议，用于JAVA EJB对象之间通信。 JMS（Java Messaging Service）：JMS是Java平台上有关面向消息中间件的技术规范，用于和面向消息的中间件相互通信的应用程序接口。
FTP（File Transfer Protocol）：FTP是文件传输协议的简称，用于Internet上的文件的双向传输。
7、消息交换
XML（Extensible Markup Language）：XML即扩展标识语言。是通用标识语言标准(SGML)的一个子集，是描述网络上的数据内容和结构的标准。
XML Schema：XML Schema为XML文档提供明确的语义限制，确保每一个XML文档都是结构完整、语义合法、内容有效的。
SOAP（Simple Object Access Protocol ）：SOAP即简单对象访问协议，是基于XML的在分布式的环境中交换信息的简单的协议。
SDO(Service Data Object)：SDO即服务数据对象，是一种针对在不同的数据源之间使用统一的数据编程模型的规范说明。它统一和简化了应用程序处理数据的方式，是服务及组件之间传输的标准数据格式。使用SDO，应用编程人员可以用一致的方法操作异构数据源，包括关系型数据库，XML数据源，Web services和企业信息系统。
WS-Addressing：WS-Addressing规范定义了一种将消息寻址信息综合到Web services消息中的标准。WS-Addressing为以同步和/或异步方式传输的SOAP消息提供了一种统一的寻址方法。此外，它还提供了寻址功能来帮助Web service开发人员在请求和响应的典型交换之外，围绕各种消息传递模式构建应用程序。
WS-ReliableMessaging：WS-ReliableMessaging规范定义了一种协议和一套机制，使 Web 服务的开发人员能够确保在两个端点之间可靠地传递消息，该规范还具有各种传递保证和健壮性特征。
8、安全管理
WSDM（Web Services Distributed Management）：WSDM即分布式Web服务管理标准。WSDM由两个不同的标准组成的：使用 Web 服务的管理 (WSDM-MUWS)与Web 服务的管理 (WSDM-MOWS) 。WSDM-MUWS
8
Q/CSG11817-2010
提供了如何表示和访问 MUWS 资源的接口的定义。例如，MUWS 标准提供了用于公布服务、服务功能所必需的结构、以及管理资源所需要提供和接收的信息。WSDM-MOWS 提供了管理 Web 服务的定义。MOWS 使用了许多由 MUWS 标准定义的概念和系统，同时也添加了管理 Web 服务特别需要的资源和功能。MOWS 组件提供了支持远程管理 Web 服务的方法和系统。
WS-Management：WS-Management定义了企业级SOA平台统一的管理接口，让不同企业级SOA平台可以被任何符合标准的管理界面操作。
WS-Security：WS-Security描述通过消息完整性、消息机密性和单独消息认证，提供保护质量的 SOAP 消息传递增强。这些机制可以用于提供多种安全模型和加密技术。它是构建在现有安全技术的基础之上的，提供一种工业标准来保证Web services消息的安全性。
WS-Policy(Web Services Policy Framework)：Web服务策略框架规范提供了一种灵活、可扩展的语法，用于表示基于XML Web services的系统中实体的能力、要求和一般特性。WS-Policy定义了一个框架和一个模型，将这些特性表示为策略。
WS-PolicyAttachment：WS-PolicyAttachment 为通过现有的 XML Web服务技术使用策略表达式指定了三个特定的附件机制。包括：如何从WSDL定义中引用策略；如何将策略与部署的Web服务端点关联起来；如何将策略与UDDI实体关联起来。
WS-Trust：WS-Trust使用WS-Security 安全的消息传递机制为安全性令牌交换定义额外的原语和扩展，以使得凭证能够在不同的信任域中签发和传播。
SSL/TLS：SSL/TLS利用密钥算法在互联网上提供端点身份认证与通讯保密，其基础是公钥基础设施（PKI）。
9、服务描述、注册与发现
WSDL(Web Services Description Language)：WSDL即Web服务描述语言，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型(Data type)、消息(Message)、方法(Operation)和访问端口(PortType)。WSDL只提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。
UDDI（Universal Description Discovery and Integration）：UDDI注册内容包括Web服务的技术模型和业务模型，本身可扩展，目前主要用于Web服务的注册和查找。
（四）SOA架构技术标准规范按技术的成熟度区分为：必须，已经获得相关国际组织批准，而必须遵循的标准；推荐，虽未获得相关国际组织批准，但已经是成熟的标准；可选，处在标准草案阶段，在主流平台产品中没有得到广泛的应用，但在SOA中有其技术优势，在特定情况下才可采用。 5.4.2 服务开发技术标准规范
SOA服务各层的开发技术必须遵循但不限于下表列出的技术规范： 分类 标准/规范 必要性 用法 JCA 1.5或以上版本 访问服务 JDBC 2.0 或以上版本 JDBC 2.0 或以上版本 数据服务 XQuery 1.0或以上版本 业务服务 SCA 1.0或以上版本 必须 推荐 可选 用于集成现有J2EE应用系统，在不能提供基于Web service的适配器的情况下，可考虑采用JCA。 用于后台数据库的访问。 数据服务可以向消费者提供JDBC和Web service两种形推荐 式的接口。JDBC应局限于和BI应用系统进行互联的数据服务接口。 用于查询以 XML 形式表达的数据。 用于服务封装与组装。SCA提供了一种统一的面向服务组件的调用方式，从而使得客户可以把不同的软件模块通 9
推荐 Q/CSG11817-2010
过服务组件的标准化而统一地封装起来和被调用访问。 EJB 3.0或以上版本 BPMN 2.0或以流程服务 上版本 WS-BPEL 2.0或以上版本 BPMN 2.0或以上版本 综合服务 WS-BPEL 2.0或以上版本 WS-CDL 1.0或以上版本 WSRP 1.0或以上版本 JSR 168 HTML JSP AJAX 可选 在Web service 接口不能满足业务要求的情况下，对于J2EE平台，EJB是一种可选方案。 用于流程设计，它提供了设计和绘制业务流程图所需的标推荐 准符号。提供业务流程设计环境的流程建模工具，应支持该标准。 推荐 用于流程引擎。 用于流程设计，它提供了设计和绘制业务流程图所需的标推荐 准符号。提供业务流程设计环境的流程建模工具，应支持该标准。 推荐 用于流程引擎。 可选 用于跨多个（三个及以上）单位间的流程服务编排 在Web 门户中用于访问和显示驻留在远程服务器上的推荐 Portlet的技术标准 。它是唯一成熟的用于展现服务的技术协议，同时也被业界广泛支持。 展现服务 推荐 推荐 推荐 推荐 用于门户Portlet开发。 用于静态WEB页面。 用于动态WEB页面。 用于WEB页面交互。 该标准描述了服务注册的数据模型以及访问模型的API。UDDI 2.0或以上版本 服务描述、注册与发现 WSDL 1.1或以上版本 XML 1.1或以上版本 必须 它不仅仅用于Web service，也可以用于其它类型的服务。 UDDI 是服务注册这一领域目前唯一成熟并被广泛支持的技术标准。 WSDL 用于描述 Web service 接口。它是唯一成熟的，必须 并受到广泛支持的Web service 接口标准。在使用SOAP-based Web service时，必须使用这一标准。 消息交换 必须 由于SOAP是基于XML的，所以在Web service采用XML是最自然的选择。在其它形式的数据交换场合，它也是最10
Q/CSG11817-2010
适宜的。 由于SOAP本身是使用XML Schema定义的，并且SOAPXML Schema 必须 1.1或以上版本 中任何的类型的定义也是使用XML Schema的，所以采用XML Schema是最合理的选择。在其它形式的数据交换场合，它也是最适宜的。 SOAP 是Web service 调用过程中的标准编码协议。它SOAP 1.1 或以上版本 (“Document / 必须 被业界绝大多数主流厂商和工具所支持，也被不同的平台支持。 当然，考虑到兼容性，SOAP消息不应采用RPC-oriented和SOAP encoding ，WSDL内的SOAP绑定只可以采用document/literal style。当采用HTTP协议作SOAP的传输时，SOAP错误消息应采用HTTP 500状态返回。 WS-Addressing 1.0或以上版可选 本 用于Web service 的传输透明寻址能力。它规定了如何在SOAP header中定义各种类型的地址。 该标准用于保证在web service 的消费者和提供者之间“可靠地”进行数据交换。WS-ReliableMessaging虽然WS-ReliableMessaging 1.0或以上版本 可选 现在还不完全是一个成熟的标准，但它对消息传递的可靠性作出了一个全面的支持架构，当中包括了「最少一次」（At-least-once），「最多一次」（At-most-once），「只能一次」（Exactly-once）的语义。 用于定义服务及组件之间传输的标准数据格式。SDO则SDO 2.1或以上版本 推荐 作为一种数据编程架构和API，它统一了不同数据源类型的数据编程，让开发人员可以以统一的方式访问和操作不同的数据源。 EJB 3.0或以上版本 可选 在Web service 接口不能满足业务要求的情况下，对于J2EE平台，EJB是一种可选方案。 同步模式下，Web Service使用HTTP/S作为指定的传输消息传输 HTTP/S 必须 协议。 当采用HTTP协议作SOAP的传输时，应采用HTTP POST方法； Literal” style) 11
Q/CSG11817-2010
JMS RMI FTP 可选 可选 在使用EJB的情况下，可以使用 RMI-JRMP 或 RMI-IIOP。 在传输大文件时，考虑到执行效率，可以采用FTP。 WSDM 标准实际上是由两个不同的标准组成的： 使用 Web 服务的管理 (WSDM-MUWS) ； Web 服务的管理 (WSDM-MOWS) 。WSDM-MUWS 提供了如何表示和访问 MUWS 资源的接口的定义。例如，MUWS WSDM 1.1或以上版本 可选 标准提供了用于公布服务、服务功能所必需的结构、以及管理资源所需要提供和接收的信息。WSDM-MOWS 提供了管理 Web 服务的定义。MOWS 使用了许多由 MUWS 标准定义的概念和系统，同时也添加了管理 Web 服务特别需要的资源和功能。MOWS 组件提供了支持远程管理 Web 服务的方法和系统。 用于保障HTTP通信安全的协议。它可保证两端点间通信SSL 3.0 / TLS 必须 1.0或以上版本 安全管理 的保密性和完整性。它可以用于SOAP over HTTP通信安全和其它HTTP-based通信安全 。目前还没有其它更为合适的用于传输层安全的协议。 在Web service 调用过程中，该标准是保证信息层安全的最佳选择. 它描述如何强化SOAP消息，以提供消息的完WS-Security 必须 1.1或以上版本 整性和机密性。同时，它还提供了将安全令牌与消息内容相关联的机制。消息层安全比传输层安全提供了更多的安全选择。加密与签名等安全措施可以被应用于任意的消息元素，消息层安全可以提供真正的“端到端”安全。 WS-Policy 1.2或以上版本 在描述和沟通web service 安全规则时，该标准提供了通推荐 用的目的模型和相应的语法。它是在定义web service安全需求时可用的唯一成熟标准.。 WS-PolicyAttachment 1.2或推荐 以上版本 12 可选 在异步模式下，可采用JMS为标准 它提供了将主体以及应用其上的安全规则进行关联的机制，同时它也提供了将WS-Policy与WSDL and UDDI描述相关联的机制。如果希望使用WS-Policy定义一个SOAP-based Web service的安全需求，应使用该标准。
Q/CSG11817-2010
用于SOAP-based Web service 的消息层安全。它是WS-Trust 1.3或以上版本 推荐 WS-Security 的扩展，定义了一个用于请求和发布安全令牌的框架，并可以代理信任关系。它是此领域唯一成熟的标准。 表1 表5.1 SOA服务开发技术标准规范 5.4.3 服务集成技术标准规范
SOA各服务层之间的相互调用必须遵循但不限于下述的技术标准规范： 服务层 标准/规范 必要性 用法 SOAP-based Web Services 推荐 Web service是首选接口，并支持WSDL1.1。即使是异步服务，也应选择使用Web service，此时它返回空结果。 在web services不能满足业务要求时使用。 EJB 可选 当后端系统已经给消费者提供了EJB服务，并且证明使用 web-service封装会严重损害性能，此时，可以使用EJB。 访问服务 如果服务是异步调用的，首选是使用Web Services的异步模式（即不立即返回结果）。如果评估Web Services不能JMS 可选 满足业务要求，则考虑使用JMS。 当后端系统已经给消费者提供了JMS服务，此时，可以直接使用JMS。 FTP JDBC 数据服务 SOAP-based Web Services SOAP-based Web Services 业务服务 JMS 推荐 可选 传输大文件时使用 推荐：用于数据服务应支持通过JDBC接口查询数据，主要的消费对BI应用访问 象是BI应用。 推荐 数据服务首先应提供SOAP-based Web Services接口，并支持WSDL1.1。 如果服务是同步调用的，它应该提供Web Services接口，并支持WSDL1.1。 如果服务是异步调用的，首选是使用Web Services的异步模式（即不立即返回结果）。如果评估Web Services不能满足业务要求，则考虑使用JMS。 推荐 BPMN 流程服务 WS-BPEL 综合服务 BPMN 推荐 业务流程设计工具应当支持BPMN标准，用于描述业务流程。 流程服务的实现是在流程引擎上完成的，所以以BPEL标准输入流程定义是首选方案。 业务流程设计工具应当支持BPMN标准，用于描述业务流13
推荐 推荐 Q/CSG11817-2010
程。 WS-BPEL WS-CDL 展现服务 WSRP 推荐 可选 推荐 流程服务的实现是在流程引擎上完成的，所以以BPEL标准输入流程定义是首选方案。 跨单位的流程服务编排。 远程Portlet开放的接口应遵循WSRP标准。 表2 表5.2 SOA服务集成技术标准规范 5.5 SOA架构模型特征
南方电网公司SOA架构模型的特征可以概括为以下三点：
1、 应用系统开发以“服务”为核心，服务体系分为：访问服务层、数据服务层、业务服务层、流程服务层、综合服务层以及展现服务层等六个层次；
2、 以ESB作为集成“服务”的纽带，实现“服务”的全生命周期管理；并通过ESB提供的服务组合与编排方式实现应用系统的开发；
3、 通过ESB互连，实现“南网总部---省公司本部---地市供电局”的“服务”灵活部署，以及全网范围内的“服务”资源共享。
6
SOA服务设计与开发
6.1 服务识别
（一）服务识别是指对业务进行分析和梳理，抽象出业务实现所需的服务，并按照南方电网公司SOA服务体系对服务进行合理划分。
（二）服务识别必须分析与业务功能或业务数据相关的接口以及约束该接口的契约，接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。
（三）服务识别基于应用需求来表达服务的需求，服务识别应包含但不限于下述考虑因素： 1、服务功能：满足企业当前及未来业务发展需求的业务处理与管理功能。 2、共享范围：跨企业级、企业级、业务职能域级或应用程序级； 3、可重用度：长期可重用、短期可重用或不可重用； 4、敏捷性：适应战略发展需求、适应业务发展需求；
5、可操作性：全部、部分功能已在应用系统中实现或需要重新开发； 6、开发技术：全部掌握、部分掌握或未掌握现有技术； 7、工具支持：现有工具全面支持、部分支持或不能支持； 8、项目规模：大规模、中等规模或小规模； 9、服务质量：容易实现或难以实现。
（四）服务识别应从业务的角度出发，包括但不限于下述切入点：
1、业务流程切入点：通过梳理、优化企业业务流程，将业务流程转化为可重用、更具有灵活性的流程服务。
2、信息资源切入点：通过梳理企业的数据资源环境，实现企业级数据交换与共享，为管理者提供各类企业经营管理信息。
3、用户体验切入点：关注客户体验需求，为终端用户提供增值、个性化、多渠道的服务，并据此来优化整合内部的应用和流程。 6.2 服务定义
（一）服务定义是在服务识别的基础上定义服务的各项属性，描述服务的信息。
（二）服务的属性包括：基本属性、技术属性、安全属性、配置属性。服务的各项属性定义必须分阶段进行、逐步细化。服务识别阶段定义服务的基本属性；服务设计阶段定义服务的技术属性与安全属性；服务的部署阶段定义服务的配置属性。
（三）服务的基本属性包括但不限于下述信息：
14
Q/CSG11817-2010
序号 属性 说明 标识服务的唯一编码 服务的英文概要名称，描述应简洁准确 服务的中文概要名称，描述应简洁准确 描述服务的特性 取值说明 详见《中国南方电网公司信息分类与编码标准-公共编码》（另行下发） 如：CreateCustomer 如：新建用电户档案 如：关键任务服务、机密任务服务、高容量服务、高水平服务、标准服务，详见《中国南方电网公司信息分类与编码标准-公共编码》（另行下发） 如： 创建一个新的用电户档案信息。 云电云电同方 1 服务编码 2 服务英文名称 3 服务中文名称 4 服务性质编码 5 服务功能描述 6 服务开发单位 对服务功能规格的详细描述。 实现服务的开发厂家 表3 表6.1服务基本属性 （四）服务的技术属性包括但不限于下述信息： 序号 属性 说明 1 版本号 2 注册时间 3 依赖的服务 4 实现方式 5 服务类型 服务的版本号 服务的正式注册时间 本服务需要调用的其它服务的编号列表 具体技术实现方式 属于服务体系中的哪种类型 取值说明 如：V1.0 如：2009-01-01 10:00 如：服务编码1；服务编码2； 如：.NET 如：访问服务、数据服务、业务服务、流程服务、综合服务、展现服务，详见《中国南方电网公司信息分类与编码标准-公共编码》（另行下发） 是/否 如：服务同步调用、服务异步无返回调用、服务异步有返回调用，详见《中国南方电网公司信息分类与编码标准-公共编码》（另行下发） 如：Create() 如：http 2009-01-10 8:00 2009-12-31 18:00 6 交互属性 7 服务调用方式 是否需要人工交互 客户端调用服务的具体方式 8 接口方法 9 接口协议 1服务启用时间 0 11 服务停用时间 服务提供的接口方法列表 调用服务的通讯协议 服务的正式启动时间 服务的正式停用时间 表4 表6.2服务技术属性 （五） 服务的安全属性包括但不限于下述信息： 序号 属性 说明 1 安全要求 调用服务时，是否需要进行安全认证 取值说明 是/否 15
Q/CSG11817-2010
2 3 允许调用的角色 服务自行安全认证 允许调用该服务的角色列表 服务被调用时，是否还进行自身的安全认证 表5 表6.3服务安全属性 如：Operator；Manager 是/否 （六） 服务的配置属性包括但不限于下述信息： 序号 属性 说明 1 服务部署IP地址 2 服务接口定义文件 3 可以使用的时间 4 是否支持重试 提供服务功能的网络IP地址 描述服务接口定义的文件路径 可以使用该服务的时间段 服务调用失败后，是否支持重发调用 表6 表6.4服务配置属性 取值说明 如：127.0.0.1 如：http://webserver/ CreateCustomer.wsdl 如：0：00－24：00 是/否 6.3 服务设计
6.3.1 总体设计原则
（一）无论是新建、改造或扩建的SOA应用系统，服务设计原则上应遵循本规范定义的六层服务体系结构，可根据实际情况对SOA服务体系进行合并或简化。
（二）无论是新建、改造或扩建的SOA应用系统，服务设计应遵循“可重用、松耦合与互操作”的原则，以便于实现跨平台的集成应用。
（三）服务的安全性应从传输级安全性、消息级安全性、应用程序级安全性等三个方面来考虑： 1、传输级安全性是指在客户端和服务器之间的传输通道提供点对点的安全性，Web服务传输级安全应采用 SSL 协议保证消息的完整性和机密性。
2、消息级安全性是指不依赖于传输协议，保证消息的完整性、机密性、不可否认性以及消息身份验证，Web服务消息级安全应遵循WS-Security 规范。
3、应用程序级安全性是指应用程序负责提供安全性并使用自定义的安全功能。例如：当需要利用在现有应用程序中的用户权限体系，可以使用自定义的 SOAP header传递用户凭证，以便根据每个 Web 服务请求对用户进行身份验证；或者应用程序可以有选择地加密消息的一部分，而不是整个消息。
（四）服务的调用方式可分为：同步调用、异步无返回调用、异步有返回调用。如果业务上要求必须阻塞进程同步等待返回结果，则采用同步调用方式；否则应采用异步调用方式，避免因并发数太多而导致服务调用阻塞。同步调用方式对服务的性能有一定的要求，应避免长时间的等待。 6.3.2 访问服务
（一）访问服务用于提供访问各种数据资源以及套装软件、定制软件和遗留应用系统的手段。访问服务设计原则包括但不限于：
1、访问服务为数据服务提供访问相关系统数据资源的通用功能； 2、访问服务必须是无状态的；
3、访问服务允许转换数据的表示方式，如在XML和非XML格式之间的转换；但不应进行基于业务规则的转换，或者对多个数据源进行操作；
4、访问服务不允许包含业务逻辑； 5、访问服务一般采用异步通信机制。
（二）访问服务必须适应调用者的应用（这些应用可以是基于Java的、非Java的、基于集成开发环境的或基于JDBC/ODBC的），可选的访问机制包括但不限于：
1、Java API访问：允许调用者调用访问服务的读和写函数；
2、控件访问：允许调用者在IDE（集成开发环境）中开发Web应用、门户、工作流和Web服务时使用访问服务控件；
3、Web服务访问：允许访问服务作为Web服务进行发布，以便于被任何使用标准WSDL和SOAP接口的调用者访问；
16
Q/CSG11817-2010
4、SQL/JDBC访问：通过SQL/JDBC接口，访问服务以关系数据库表的形式被访问，参数化的访问服务以存储过程的形式被访问。 6.3.3 数据服务
（一）数据服务通过调用访问服务访问企业的各种数据资源。 （二）数据服务设计原则包括但不限于：
1、数据访问和业务逻辑处理必须清晰地分离，数据服务通过访问服务从各种数据源收集和返回相关的数据；
2、数据在企业范围内流动与共享，其准确性、一致性、完整性应由数据的生成者保证；
3、数据服务应与南方电网企业信息资源规划定义的数据模型保持一致，使得数据在应用层面具有语义标准化的特性，便于复用；并保证数据使用者与生成者的松耦合，使得数据源模型变化不会影响到数据的使用者；
4、当需要进行大批量的数据复制、移动或转换时，允许将批处理作业的控制操作发布成一个数据服务，而大量数据的批处理操作仍然采用ETL或专用接口等效率更高的方式来实现；
5、当数据服务需要交换大量数据时，允许通过FTP或消息中间件（可提供数据压缩、传输安全、分组传输、缓存等高级功能）以附件的形式进行交换。 6.3.4 业务服务
（一）业务服务是指满足特定业务处理需求的服务，业务服务包含一个或多个业务处理功能，业务服务包含的业务功能数目决定了业务服务的“粒度”以及可重用性。业务服务的“粒度”大，则服务集成成本低，但业务服务的可重用性也低；业务服务的“粒度”小，则服务集成成本高，但业务服务的可重用性也高。业务服务的“粒度”应该在服务集成成本与服务可重用性之间取得合理的平衡。
（二）业务服务设计要求遵循但不限于下述原则： 1、业务服务操作是非长时间的动作；
2、业务服务表达一定的业务逻辑和业务规则，并具有完整业务事务处理的功能； 3、业务服务安全的认证和授权等控制逻辑必须与业务逻辑分开； 4、事务处理必须在服务内部完成，事务不能跨越服务的边界； 5、业务服务的操作重复执行时其结果是相同的。 （三）业务服务是管理与决策应用功能的基础，业务服务设计应保证业务服务能力的高可用与高性能等质量要求。
（四）业务服务除了满足其所在的业务职能域的业务处理功能外，还应同时考虑便于满足集成跨业务职能域的业务处理功能的需求。 6.3.5 流程服务
（一）流程服务封装完整的业务流程或独立定义的子流程，流程服务设计要求遵循但不限于下述原则：
1、所有需要保存服务调用之前的状态和调用结束之后的状态，并最终向客户应答的服务，都应该设计为流程服务；
2、流程服务的状态在任何一个时间点都应该是能够监控的；
3、流程服务可以长期处于运行状态，可涉及到人工工作流，并包含多个原子事务； 4、流程服务遵循BPEL，BPMN等规范。 6.3.6 综合服务
综合服务分为两大类：
（一）以提升企业综合管理职能为导向的、基于业务系统的跨系统、跨业务管理职能域、跨单位的组合服务，这类综合服务可由访问服务、数据服务、业务服务及流程服务组合而成。
（二）以企业价值链为导向的、基于数据仓库综合分析功能而封装的跨业务管理职能域、跨时间过程域的服务，这类综合服务一般由各类综合分析模型功能封装而成。 6.3.7 展现服务
（一）展现服务处理应用信息的表示，服务体系所有底层的服务都可以通过展现服务暴露给最终用户使用。
（二）展现服务必须将数据和其表现格式区分开。
17
Q/CSG11817-2010
（三）展现服务包括：企业信息门户中可配置、可重用的门户组件，用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件等，以实现对不同客户接入方式的支持。
（四）展现服务可以集成商品化的前端展现工具，以满足丰富、灵活的客户端展现需求。 6.4 服务实现
6.4.1 服务封装原则
（一）服务封装是SOA服务实现的手段，服务封装将应用系统可重用的功能或数据“剥离”出来，对外以相关的接口方式以及约束这个接口的契约提供给消费者调用。接口和契约的定义是中立的及基于标准的，并独立于实现服务的硬件平台、操作系统与编程语言。
（二）服务封装必须遵循包括但不限于下述原则：
1、无状态原则：最大限度减少服务管理的状态信息的内容以及状态的期限； 2、单一实例原则：避免功能冗余； 3、接口定义原则：使用WSDL定义服务接口，使用WS-Policy描述服务契约，使用XML模式 （Schema）定义服务交换的消息格式（即服务的公共数据）。服务消费者依赖服务契约调用服务。服务定义必须相对稳定，修改必须通过审核批准；
4、自包含和模块化原则：服务封装的是那些在业务上稳定的、重复出现的活动和组件，组成服务的功能实体是完全独立自主的，可以独立进行部署、版本控制、自管理和恢复；
5、粗粒度原则：服务粒度指抽象级别或者服务包含的功能。确定服务粒度时需要考虑性能需求，以及未来可能进行的更改对服务实现的影响。应尽可能使用粗粒度模式隐藏其中的细粒度服务，这样有利于将服务与其实现的更改隔离开来。服务数量太多会带来服务管理的复杂性；
6、松耦合性原则：服务消费者使用服务接口调用服务，服务的位置、实现技术、当前状态以及服务的私有数据对服务消费者是透明的；
7、可重用原则：服务是可重用的；
8、策略声明原则：应利用策略声明描述对服务的期望，例如：安全性方面的要求、与业务有关的语义方面的要求以及服务级别方面的要求等。 6.4.2 服务封装方式
（一）对于技术实现方式和接口不能满足或难以满足本规范服务定义与服务封装要求的现有应用系统，建议通过适配器对现有应用系统进行集成，利用适配器对外提供的各类接口的方式实现服务封装。
（二）对于采用J2EE或.NET等支持Web服务开发的现有应用系统，可以在不改变现有应用系统的技术实现方式与现有接口的前提下，通过增加对外接口以支持标准的服务接口协议的方式，直接实现现有应用系统功能模块的服务封装。
（三）对于新建的应用系统，必须按本规范的服务定义与服务封装的要求，直接采用支持SOA的开发工具进行服务封装。
7
SOA服务集成
7.1 企业服务总线
（一）ESB提供了一种开放的，基于标准的消息机制，通过标准的适配器和接口，来完成服务之间的互操作。ESB提供了多协议的服务调用接入、服务路由、服务访问控制和服务适配器等核心功能。ESB是服务提供者和服务消费者之间的一个中介，避免了点对点的集成，是实现SOA服务松藕合的重要机制。例如：服务消费者可以不关心服务提供者的接口（消息格式的不同）、地域（服务部署位置的变化）、调用方式（同步/异步）、传输协议（服务提供者和消费者可以使用不同的通讯协议）、技术实现（编程语言/部署环境）等。ESB功能包括但不限于：
1、服务接入：服务接入是调用服务的统一入口。包括：接收服务请求消息和调用者使用的通信协议与ESB内部通信协议之间转换功能。
2、访问控制：访问控制包括：身份鉴别与权限控制。
3、消息转换：消息转换提供不同格式的消息之间的转换，包括输入消息转换和输出消息转换。 4、服务路由：根据消息的内容和预先配置好的规则，将服务请求传递给某个具体的服务处理。 5、适配转换：负责ESB内部通信协议与被调用的服务使用的通信协议之间的转换，并调用服务，获得服务返回结果。
（二）ESB必须包括但不限于下述特性：
18
Q/CSG11817-2010
1、与操作系统和编程语言无关；并能在Java和.Net应用程序之间工作； 2、使用XML作为标准通信语言； 3、支持Web服务标准；
4、支持多种传输协议，例如：HTTP(S)、JMS、RMI、FTP或其他消息中间件； 5、支持多种消息传递方式，包括：同步、异步、点对点、发布-订阅等； 6、包含基于标准的适配器，例如：JCA、文件适配器、JDBC适配器等； 7、包含基于内容的智能路由功能；
8、包含标准安全模型，用于ESB的认证、授权和审计；
9、包含消息转换功能,使用可视化映射工具定义XSLT规则，在发送应用和接收应用之间能够进行格式转换、语义转换；
10、包含基于模式（schema）的消息验证；
11、支持服务管理，比如服务的注册、维护、报废和版本管理；监控服务的运行情况，包括时延、吞吐量、错误率等；
12、提供对中文的全面支持，包括对GB2312/GBK/UTF8的完善支持；
（三）ESB应具有良好的可扩展性，能够充分利用硬件系统的资源，支持垂直扩展和水平扩展，支持负载均衡，满足日益增长的服务数量的需求。 7.2 服务描述
（一）服务使用WSDL描述其使用的抽象消息操作、具体的网络协议和端点地址。
（二）服务使用XML模式（XML Schema）描述其接收和发送的基于XML的消息的结构和内容。 （三）服务使用Web服务策略（Web Services Policy）规范来描述Web服务的能力、需求和一般特征，包括但不限于安全性策略。 7.3 服务注册/发布
（一）基于SOA松耦合特性，需要对各种服务进行注册，以方便服务提供者发布自己的服务、服务消费查找所需的服务。
（二）服务注册中心需要提供分类管理能力，实现对服务的搜索。 （三）服务注册应该提供服务审批的功能，保证对敏感注册数据的任何变动都能够传递到适合的审批流程中。同时，还应该提供服务变更管理功能，支持变更的通知和订阅，能够实现将注册数据的变动主动地通知到管理员或者相应的流程。 7.4 服务发现/调用
（一）ESB应具有自动发现服务的功能，ESB中可以通过图形化界面及参数配置的方式调用服务。 （二）Java客户端应用程序中使用UDDI API，以编程方式查找服务目录，并调用服务。 （三）SOA服务应优先采用Web服务方式实现，并符合WS-I国际标准。 （四）服务间互操作的协议为简单对象访问协议（SOAP）。 （五）服务间数据交换的格式为可扩展标记语言(XML)。 7.5 服务编排
（一）复杂的服务需要通过若干个简单的服务组合而成，这时候就需要对服务进行编排。
（二）轻量级服务编排在ESB中完成，通过ESB的服务路由、消息格式转换功能，实现多个服务组合成一个更粗粒度的服务。
（三）需要长期运行的业务流程，可利用BPM工具进行服务编排。 7.6 服务管理 7.6.1 管理内容
（一）SOA服务管理贯穿于服务的全生命周期，包括：服务需求分析、服务识别、服务定义、服务设计、服务实现、服务测试、服务部署、服务使用、服务运维、服务退役等。
（二）SOA服务管理包括：服务资产管理、服务运行监控、版本管理、服务动态更新、服务质量管理、服务水平管理、安全管理等，通常通过规则配置来应用管理功能。
（三）SOA服务管理应按照服务体系的层次划分进行分类管理。
（四）服务的资产管理由服务库完成；服务库存储服务全生命周期过程的详细元数据，包括：服务的定义、服务的依赖关系、服务的文档、实现代码、服务的权限信息、服务运行质量控制信息以及服务的治理规则和策略等。
19
Q/CSG11817-2010
（五）服务目录存储服务运行时所关注的元数据，是服务库存储的元数据的一个子集；主要用于服务部署时的服务注册、发现和查找，以及提供变更通知功能。
（六）无状态的服务（例如：数据服务、业务服务）通过ESB和服务目录对其进行运维管理，管理内容包括但不限于：
1、服务监控：提供对服务运行指标的监控，包括服务节点的吞吐量和可用性等，以图形化的方式来评估服务相关性和中断造成的影响。监控指标包括但不限于：最小响应时间、最大响应时间、平均执行时间、处理的总消息数和错误数、成功/错误率、违反安全的消息数、校验错误的消息数等。
2、服务水平管理：通过设置服务水平协议（SLA）提示，向服务运行管理团队通知服务运行的状况，或提供与服务质量有关的问题报告等。触发提示时，服务管理平台能按预先制定的策略通知服务运行管理团队的管理人员（通过电子邮件或短信息等）。
3、服务自动发现：通过自动发现实际运行的服务或查找新部署的服务，减少配置管理中的人工操作，还可以通过发现其它隐藏或恶意的服务来应用更加严格的监管策略。
4、服务异常管理：跟踪、检测分布式或异构系统间服务的消息流异常情况。
5、服务策略实施：通过将系统的行为作为策略指定(而非过程代码)，系统的适应性将更强。例如，如果改变用户的身份验证方式，从原有的输入用户名和密码更改为提供一个证书验证，在基于策略的管理模式下，安全性策略与应用程序彼此分离，可以通过声明的方式来描述这种更改，并动态实施。
（七）有状态的服务（例如：流程服务）除了上一点无状态的服务的管理内容以外，还需要结合BPM工具对其过程进行管理，管理内容包括但不限于：
1、图形化业务流程建模。
2、流程的终止、暂停、恢复、事务补偿、回退等。
3、允许与运行中的业务流程交互，以便处理流程异常、审批和状态跟踪。
4、通过图形化界面查看流程服务实例的状态、执行过程、节点信息或用户设定的KPI指标等实时数据。
7.6.2 参考流程
（一）服务的注册流程规范如下：
1、服务提供者向信息部门提出服务注册申请。
2、信息部门对申请进行审批：如果审批通过，服务管理平台的管理员将该服务注册到服务目录；如果审批不通过，向该服务提供者发送申请失败的通知（包括审批意见），并结束流程。
3、服务注册成功后，向服务提供者及潜在的服务消费者发送注册成功通知。
4、服务提供者接收注册成功通知后，根据实际情况，判断是否不需要订阅申请，而直接对潜在的服务消费者进行授权。
20
Q/CSG11817-2010
开始服务提供者申请注册信息部门审批 通过不通过服务管理者进行服务注册发送注册成功通知发送申请失败通知是否不需要订阅是服务提供者进行服务授权否结束图3 图7.1 服务注册流程
（二）服务的消费申请流程规范如下：
1、服务消费者向服务提供者提出服务消费申请。
2、服务提供者对申请进行审批：如果审批通过，则给该服务申请者分配使用该服务的权限；如果审批不通过，则向该服务申请者发送申请失败的通知（包括审批意见）。
21
Q/CSG11817-2010
开始服务消费者申请订阅服务提供者审批 不通过通过服务管理者进行权限分配申请失败通知申请成功通知否结束图4 图7.2 服务消费申请流程
（三）服务的维护流程规范如下：
1、服务提供者向信息部门提出维护某项服务的申请及最新版本的服务。
2、信息部门对申请进行审批：如果审批通过，则向该服务的消费者发出服务维护通知；如果审批不通过，则向该服务申请者发送申请失败的通知（包括审批意见），并结束流程。
3、服务管理平台的管理员进行服务更新、维护操作。 4、向该服务的消费者发出服务维护完成通知。
22
Q/CSG11817-2010
开始服务提供者申请维护信息部门审批 不通过通过发出服务维护通知申请失败通知服务管理者进行服务维护发出服务维护完成通知结束图5 图7.3 服务维护流程
（四）服务的报废流程规范如下：
1、服务提供者向信息部门提出报废某项服务的申请；
2、信息部门对申请进行审批：如果审批通过，则向该服务的消费者发出服务即将报废的信息（提示消费者该服务将在什么时候报废）。如果审批不通过，则向该服务申请者发送申请失败的通知（包括审批意见），并结束流程。
3、到了预定报废时间，服务管理平台取消该服务消费者的权限，向该服务消费者发出服务报废通知，并在服务目录中删除该服务。
23
Q/CSG11817-2010
开始服务提供者申请报废信息部门审批 不通过通过发出服务即将报废通知服务管理者进行服务退役处理发出服务退役通知发送申请失败通知结束图6 图7.4 服务报废流程
8
SOA项目管理
8.1 项目实施方法
（一）自顶向下的实施方法：“自顶向下”是在企业发展战略指导下实施SOA的方法，其核心思想就是从企业层面做SOA实施的整体规划。它的好处是从企业整体进行考虑，面向业务，企业可以根据其业务的发展情况以及现有的IT水平做一个SOA实施的整体规划。这样做可以推动整个企业的标准化，所有的服务模块都基于相同的标准，方便今后的重用。但是它的风险也不小：一方面是范畴涵盖大，周期长，初期的投资大；另一方面是它要求企业有一套完整的组织架构和管理流程，有比较高的纪律性和技能。
（二）自底向上的实施方法：“自底向上”的实施办法则是战术性的，它强调从小处着手，从一个部门级应用开始实施SOA。这种方式本质上是鼓励创建服务来实现以应用为中心的需求。服务是建立在“按需”的基础上的，并通过对应用逻辑的封装提供给SOA的解决方案使用。“集成”是“自底向上”的主要动力，通过简单地添加遗留系统的封装服务来满足SOA开放式的需求。这种方法的好处是见效快，风险小，初期的投资也不大。不过这种实施方式的弹性相对比较差，特别是当企业需要在更大层面实施SOA时，可能会产生一些衔接问题。
（三）中间相交的实施方法：“中间相交”又称为“混合方法”或“敏捷方法”，它是指SOA的实施中结合“自顶向下”和“自底向上”的方法，寻求两者之间的最佳结合点，最有效和成功地实施SOA。在应用系统实施的初期，存在很多不确定性，包括业务需求和项目所选择的开发技术、平台等都存在不确定性。遵循“中间相交”的原则，业务人员和开发者都各自循序渐进地做事，在过程中不断沟通，这样就能够使得业务的改变得到最快的响应，并且不会影响开发效率，最终两者能够在某一点相遇，从而搭建起符合需求的系统。通俗地说，“中间相交”的原则就是我们常说的“大处着眼，小处着手”，在做项目时，并不仅仅把眼光局限在正在进行的项目，同时也兼顾企业IT系统和业务发展的整体规划。 8.2 项目实施策略
24
Q/CSG11817-2010
（一）实施SOA应采用面向服务的集成策略，在SOA环境下应用Web服务进行集成，并逐步过渡到SOA架构的实施技术路线。实施SOA并不鼓励推倒重来，与构建全新的面向服务的业务应用系统相比，从构建复合应用入手实施SOA，能够降低创新的风险和构建成本，使业务能迅速见到SOA的投资回报，有助于得到业务部门的支持。并且，随着一个接一个应用的成功交付，现有遗留应用系统不断服务化，SOA基础架构不断扩容，必将加速推动SOA从小规模试用到大规模普及。
（二）实施SOA应该根据应用系统的实际情况灵活地把握，如果具有下述情形之一时，可考虑采用SOA架构新建或改造应用系统：
1、系统之间缺乏互联互通，为了最大限度消灭或减少信息孤岛，整合现有系统，通过SOA帮助企业实现系统之间的互联互通。
2、面对市场的快速变化和激烈竞争，需要提高企业应用的灵活性，通过SOA帮助企业实现业务流程的快速灵活变化。
3、已建设了很多应用系统，但系统之间有很多共性，造成重复建设，重复投资，通过SOA帮助企业把原来的IT资产整合起来，提高重用性。
4、建设新的应用系统时，要求具有很好的扩展性，将上下游伙伴之间很好地整合在一起。可以直接利用SOA架构来规划和建设系统，这对企业将来业务发展有很大帮助。
5、既要整合信息孤岛，又要很快让新的应用系统上线，通过SOA能够很好地衔接新老系统，顺畅地提供各种业务服务。
（三）如果应用系统具有下述情形之一时，应用系统的建设或改造可以暂缓选择SOA架构： 1、绝对要求实时性能的业务处理系统（例如：电力自动化控制系统）。
2、相对封闭、对灵活性要求不高的应用系统。（例如：不需要跨组织的、有固定的标准化产品、业务流程已经确定的应用系统）。 8.3 项目实施路线
（一）实施SOA架构是一项IT战略目标，是一个持续改进的过程，必须在充分保护现有应用系统信息资源的基础上分阶段实施，迭代式推进，最终达到全网范围内信息技术架构模型的规范与统一，实现全网范围内信息资源（“服务”）的共享和重用。
南方电网公司实施SOA架构的路线图：
成熟期过渡期基础期图8.1SOA架构实施路线图
1、基础期
南方电网公司目前主要还是以“烟囱式”的应用系统为主，数据分散在各个系统之中，系统与系统之间主要是点对点的连接和集成，Web服务数量很少，且没有统一的定义，基本上实现了门户的统一接入和访问。因此，基础期是以面向服务的应用集成为主，重点放在利用已有的应用系统资源，封装已有
25
Q/CSG11817-2010
的数据和业务逻辑，积累可重用的服务资产和SOA项目建设经验，统一应用集成的技术路线和ESB；同时开展新建应用系统的SOA试点项目工作。这一时期推荐采用“自底向上的实施方法”，工作任务包括但不限于：
（1）推广和应用企业信息资源规划成果，逐步统一企业的数据资源环境； （2）建设数据中心，开发和管理共享和交换的数据服务； （3）按照SOA服务体系规范，开发各种应用集成的服务功能； （4）统一对服务进行描述定义、注册和查找；
（5）通过ESB对服务进行统一管理，统一对服务的调用方式、数据格式。 （6）选定ESB，实现基于ESB的应用系统建设； （7）实现简单的服务组合与编排。 2、过渡期
完成基础期工作后，在SOA的基本特性的基础上，加入一些企业级的高级特性。同时启动核心应用系统的改造，重新开发基于SOA架构的应用系统，逐步替换掉原有的应用系统，实现从多种信息技术架构模型并存，逐步过渡到以SOA架构模型为主。这一时期推荐采用“中间相交的实施方法”，工作任务包括但不限于：
（1）按照统一的SOA架构规范，改造或重新开发核心应用系统； （2）扩展服务描述定义，增加服务质量（Qos）的属性和要求；
（3）按照SOA架构规范，对服务的安全性、消息传递的可靠性、事务的完整性进行完善和管理； （4）对服务的全生命周期进行管理，提供过程管理的流程；
（5）持续的业务流程梳理，使用集成开发工具定义流程，使用流程管理引擎运行流程，并监控流程的执行；
（6）持续的数据分析，提供数据深加工的能力，提供数据挖掘，辅助决策分析的服务。 3、成熟期
在过渡期工作的基础上，通过持续不断的SOA治理，提高企业的SOA能力成熟度，使得SOA架构能够快速适应业务的变化，通过对服务的组装和编排，能够快速搭建新的应用系统。这一时期推荐采用“自顶向下的实施方法”，工作任务包括但不限于：
（1）提供更完善的系统运行监控、分析管理工具，帮助各级人员更好的使用和管理SOA系统； （2）建立SOA能力成熟度评价模型，并执行评价和持续改进； （3）建立与业务部门的回馈与交互机制； （4）对服务元数据进行统一管理；
（5）服务和流程仿真，通过模拟优化服务与流程。 8.4 项目实施步骤 8.4.1 项目准备
（一）做好SOA项目实施前的规划工作，是SOA项目实施的基础。SOA项目规划可参考下述方法： 1、一步到位法：全面梳理业务流程，进行业务优化，建立服务模型；调整业务机构，建立组织规范；统一构建ESB。规划要点包括但不限于：
（1）组织规范：建立战略机构，统一优化业务，并根据优化业务调整机构； （2）服务建模：以业务优化思想为主导； （3）平台选择：选择功能全面的ESB。
2、核心扩展法：对核心业务系统进行SOA改进，建立若干核心SOA服务，优化核心业务的流程和组织机构；通过核心业务的使用，引导其向全业务域SOA扩展。规划要点包括但不限于：
（1）组织规范：前期以调整核心业务的组织和规范为主；后期逐步调整其它业务组织，并制定规范；
（2）服务建模：以核心业务系统改造为主导，逐步建立其它服务； （3）平台选择：选择功能适用的ESB。
3、逐级建设法：从公共服务入手（例如：数据共享、代码转换等），建立公共服务；通过公共服务的使用，提高组织应用SOA的积极性，积累SOA的实施经验；逐步引导组织向业务的组件化转变。规划要点包括但不限于：
（1）组织规范：前期不涉及组织调整；后期逐步调整组织，并制定规范；
26
Q/CSG11817-2010
（2）服务建模：以公共服务重用为主导，逐步建立其它服务； （3）平台选择：选择功能满足最小要求的ESB。
（二）基于SOA架构进行应用系统的建设是南方电网公司一项长期的信息化建设目标，SOA信息化建设目标的实现必须有长期稳定的组织保障措施配合。可以在目前的信息管理部门架构下，常设一个SOA架构工作小组，其工作职责包括但不限于：
1、跟踪SOA信息技术的发展方向，学习成熟的SOA信息技术标准规范，把握本单位SOA项目实施的方向与正确路线；
2、负责组织与管理SOA项目实施前的项目规划，做好SOA项目的立项、可行性论证与项目招标准备工作；
3、负责组织对于涉及企业核心业务或管理的SOA项目招标前的POC（概念验证）验证工作，提交SOA项目POC验证报告；
4、负责组织SOA平台产品与技术的选型工作； 5、参与SOA项目实施过程的管理与质量监控工作； 6、参与SOA项目的验收工作。 8.4.2 项目需求分析
（一）以“服务”为核心，应用SOA的分析方法，确定SOA项目的目标以及建设需求。SOA项目需求分析的工作包括但不限于：
1、业务或管理需求分析：调查SOA项目涉及的数据分布、数据处理流程、业务或管理功能以及业务或管理布局等，明确SOA项目的目标、内容、范围以及已有的项目资源；
2、“服务”需求分析：以“服务”为工作主线，规划SOA项目应用系统的服务体系架构、定义服务功能、服务接口以及服务关系等；
3、“服务”实现方案分析：重用已有“服务”资源以及开发新的“服务”资源，以满足项目应用的需求；
4、“服务”集成需求分析；
5、“服务”管理需求分析：“服务”的质量、权限、安全性等； 6、制定SOA项目测试计划。
（二）SOA需求分析明确了SOA项目的目标、内容、范围以及应用系统的功能、性能、资源等基本成分的规格，必须按SOA需求分析文档规范的要求整理成文档，并提交给项目建设单位批准。
（三）SOA需求分析结束后，项目建设单位必须组织专家评审小组对项目实施单位提交的SOA项目需求文档进行评审。评审通过并经过项目建设单位批准后的SOA项目需求文档作为SOA项目实施的里程碑，是SOA项目下一阶段实施和项目验收的依据。 8.4.3 项目设计与实现
（一）SOA设计与实现的目标是：提高服务的重用性和降低服务实现的成本，SOA项目服务设计与实现的工作包括但不限于：
1、对SOA需求分析定义的服务体系架构、服务功能、服务接口以及服务关系等，从实现的角度进行调整与扩充，完善SOA服务体系架构的服务功能、服务接口与服务关系，使服务的重用性更高，且服务的实现成本更低；
2、设计服务实现的名称、操作、输入消息、输出消息以及服务的封装规格与调用接口；
3、选择合适的方法实现封装在服务内的功能，可以通过自行编码的方式实现，也可以通过调用或购买已有的内外部服务功能的方式实现。服务实现过程一般采用参数配置、组装、流程定义等技术，而手工代码编程的工作量较少。在服务实现的技术定义、开发和组装中，可以基于现有基础设施情况以及服务设计的业务服务定义，选择采用Web Service、SCA/SDO技术或其它传统技术逐步实现单个业务功能服务、组合类服务或流程类服务；
4、服务测试是保证服务开发正确有效的手段，与服务开发交叉进行。服务测试包括对单个服务的单元测试，也包括对于组装类服务或服务流程的集成测试。服务测试工作主要是基于服务定义和描述中的功能和性能指标，采用一定的测试工具、技术和标准规范，对服务进行质量测试和评估，并根据测试的结果来决定服务的开发是否合格。在SOA项目中，服务的测试与传统的测试不同，为保证服务能与其它服务互联互通，应更加注重对服务的标准符合性测试及互操作性测试工作；
27
Q/CSG11817-2010
5、服务部署通过部署工具将所开发的各类服务及流程部署至用户的物理环境内，如用户的应用服务器、流程服务器、门户服务器等。对于单个服务，部署后的服务可以被终端用户、其它IT系统或服务调用。服务部署包括静态和动态两种。静态部署是指服务之间的调用关系在运行前已确定，动态部署是指在应用系统运行中需要通过动态路由后确定服务调用关系。由于用户物理环境往往是基于网络的分布式环境，具体部署的类型需要根据SOA项目实施的状况和需求确定；
6、服务发布也被称为服务注册，是将已开发完成的服务发布在服务目录（或服务库）内，以便被其它服务发现和调用。服务目录（或服务库）是各类服务的统一管理目录：每个服务提供者可以发布其所提供的服务描述信息，供其它服务访问；此外，服务请求者可以迅速查找其所需的服务，以充分利用已有的服务来实现其应用系统的构建目标；
7、设计服务应用方案，服务应用方案是SOA项目应用系统的服务应用场景；
8、服务编排应用是在ESB的支持下，通过服务编排方式实现SOA项目应用系统的服务应用场景； 9、服务运维及监控分为两个方面，包括用户方的业务人员对业务流程运行状况和绩效的监控，也包括系统维护人员从IT层面对基于系统服务的管理和部署模型、对SOA系统运行状态以及服务调用状态进行整体管理、控制和监测，从而保障SOA系统稳定可靠的运行。
10、SOA服务的持续改进是建立在SOA治理的基础之上的，它通过制定人员和角色、管理流程及决策，帮助企业管理整个SOA的生命周期。SOA治理包括但不限于下述内容：
（1）高层的领导决策者指导组织建立满足其目标的策略，包括确定谁负责制定决策、需要制定什么决策以及使决策制定保持一致的决策；
（2）建立SOA的组织机制以及授权机制，同时保证项目实施各阶段按预定目标推进的有效控制机制；
（3）建立沟通计划、流程或协议，保证各相关方都对服务获得一致信息。比如，必须在服务提供者和服务消费者之间建立一个协议，告知消费者可以希望得到什么功能、提供者应该提供什么功能；
（4）涉及服务全生命周期，包括指导可重用资产的开发，确立如何设计和开发服务，服务的版本和质量管理，以及这些服务如何随时间增长进行更改；
（5）建立评估SOA项目成熟度以及各项性能测试的评估方法，并在SOA项目实施过程中进行监控和调整。
（二）SOA项目设计与实现任务完成后，必须按SOA项目设计与实现文档规范的要求整理成文档，并提交给项目建设单位批准。项目建设单位必须组织专家评审小组对项目实施单位提交的SOA项目设计与实现文档进行评审。评审通过并经过项目建设单位批准后的SOA项目设计与实现文档成为SOA项目实施的里程碑，是SOA项目验收的依据。 8.5 项目验收 8.5.1 总体要求
（一）SOA项目按照南方电网公司信息化项目管理办法组织验收，同时必须遵循本规范之技术架构、技术标准规范与验收文档的要求。
（二）SOA项目验收必须提交但不限于下述必要的文档： 1、SOA项目需求分析文档； 2、SOA项目设计与实现文档； 3、SOA项目服务测试报告； 4、SOA项目试运行报告。 8.5.2 验收文档规范
（一）SOA项目需求分析文档包括但不限于下述内容： 1、前言
1.1项目背景 1.2预期目标 1.3项目内容
1.4项目范围（涉及的业务域、管理职能部门/岗位以及它们之间的关系等） 1.5项目资源（现有数据资源及应用系统资源等） 1.6术语与参考文献 2、“服务”需求规划
28
Q/CSG11817-2010
2.1业务需求分析（数据分布、处理流程、处理功能、业务布局等） 2.2“服务”规划
2.2.1“服务”体系架构
2.2.2 “服务”功能（各服务的业务目标、业务规则、业务事件，非功能性特征等） 3、“服务”接口（各服务的名称、操作、输入与输出等） 4、“服务”关系（依赖与包含等）
5、“服务”实现策略（封装已有的IT资源或重新开发等） 6、“服务”管理与应用（权限与安全等） 7、“服务”测试计划
7.1“服务”功能与性能测试需求 7.2“服务”集成测试需求 7.3“服务”安全测试需求 8、问题与改进方向
（二） SOA项目设计与实现文档包括但不限于下述内容： 1、前言
1.1实现背景 1.2实现目标 1.3实施内容
1.4实施范围（涉及的业务域、管理职能部门/岗位以及它们之间的关系等） 1.5实施依据（原则与现有资源等） 1.6术语与参考文献 2、“服务”实现方案 2.1各“服务”封装规格 2.2各“服务”接口规格
2.3各“服务”实现技术路线与技术标准规范 3、“服务”集成方案 3.1“服务”集成平台 3.2 涉及的“服务”清单 4、“服务”管理方案 4.1“服务”管理平台
4.2“服务”管理策略（元数据） 4.3“服务”治理 5、“服务”应用方案 5.1“服务”应用场景 5.2“服务”编排方案 6、问题与改进方向
（三） SOA项目服务测试报告包括但不限于下述内容： 1、SOA项目测试目标、内容与范围 2、SOA项目“服务”之功能测试 2.1测试功能点
例如：流程补偿交易测试、服务失效性测试、事件响应测试、业务规则测试、策略测试等。2.2测试方案（输入、预期输出、实际输出等） 2.3测试方法、技术与工具
3、SOA项目“服务”之性能测试
3.1测试性能指标（例如：响应时间、资源消耗情况等） 3.2测试方案
3.3测试方法、技术与工具
4、SOA项目“服务”之集成测试
4.1服务集成测试方案（包括：静态互操作性与动态互操作性等）
29
Q/CSG11817-2010
4.2测试方法、技术与工具
5、SOA项目“服务”之安全测试
5.1服务安全测试方案（包括：传输级安全、消息级安全与应用级安全等） 5.2测试方法、技术与工具
例如：拒绝服务测试(DOS)、安全漏洞测试等。
（四） SOA项目试运行报告包括但不限于下述内容： 1、SOA项目上线内容与范围 2、SOA项目运行环境
3、SOA项目应用部门与反馈意见 4、SOA项目应用总体效益评价 5、SOA项目的不足与改进
30
因篇幅问题不能全部显示，请点此查看更多更全内容