SOA项目实施白皮书

目 录 1 . 4 传统的建设方法不同 . 5 传统的建设过程不同 . 5 2 . 6 业务为中心 . 6 活适应变化 . 6 用 源，提升开发效率 . 6 强调标准 . 7 3 . 7 . 7 . 8 4 . 9 . 9 . 14 向服务方法与传统方法的区别 . 16 5 目实施简介 . 18 . 18 务生命周期 (以服务为中心的实施过程 ) . 19 施过程关系图 . 19 务与 划 . 20 求规划 . 22 务规划及设计 . 23 务开发及测试 . 23 务部署 . 24 务发布 . 25 务运维及监控 . 25 理过程 . 26 . 27 划阶段 . 27 析阶段 . 28 计阶段 . 29 现、调 试和部署阶段 . 31 维阶段 . 32 . 33 户原有 源 . 33 . 33 . 34 . 34 户信息化要求 . 34 户在实施过程中的职责 . 34 品选型建议 . 38 . 39 1 随着我国各行业信息化建设的不断深入，企事业单位和政府部门逐步建立起的大批计算机信息系统和各类数据信息因缺乏有效衔接，导致信息资源共享难、“信息孤岛 ”现象普遍存在。与此同时，对于企事业单位，随着经济全球化大环境下的市场竞争日益激烈，企业正在通过加快管理转型、技术创新、新产品研发以及业务策略调整 等方式来提升自己的核心竞争力、持续占有并扩大市场份额。对于各级政府部门，在以 “大部制 ”为核心的政府行政管理体制改革的驱动下，以 “管理 ”导向的政府职能正在向 “服务 ”导向转变。 企事业单位和政府部门的这些转型方式及过程的有效实施，一方面更需要信息技术和信息化的手段来支撑，另一方面，这些业务需求也对信息技术和信息化建设本身提出了更高要求： 常也称为 “信息系统 ”、 “应用系统 ”或 “软件系统 ”等）要能快速响应用户业务发展和变化的需求，新系统必须能在充分利用用户原有 源基础上快速构建出来，同时要实现跨平台、 跨组织的数据共享和业务协同。 向服务的体系架构）是近年来软件规划和构建的一种新方法，其概念最早由国际咨询机构 司于 1996年首次提出。由于其本身特性非常符合上述信息化需求和问题的解决思路，因此在 2003 年以后成为我国软件产业界和各行业用户的关注焦点，并在 2006 年逐步开始在多个行业信息化建设中被选择和应用。 少国内外机构、企业均对 目前还未形成权威、统一的定义。本书作为国内首 部从用户角度对 全书中将对 便于用户从应用角度对 直观理解： 是一种技术，而是一种 统和软件的构建方法和过程，贯穿 统规划、设计、构建、运维的各个阶段。要说明如下： 传统的建设方法不同 基于 统建设更强调基于统一标准的快速开发和灵活组合。 “服务 ”是 对应于某个业务流程、业务功能或数据资源，按照统一的规格来组成信息系统。基于 “服务 ”， 显著缩小 用户业务需求与 持能力之间的鸿沟，指导 队开发出具有良好移植性、扩展性和兼容性的应用系统。 仅仅站在单个信息系统或集成项目的角度，而是更强调站在用户 而规划并逐步建成统一的 统架构模式，并积累可重复使用的信息系统资源库，以实现用户组织内或全行业内的信息资源共享、信息系统协同、新系统的快速构建以及系统对业务变化的快速应变能力。 传统的建设过程不同 设过程的重点是基于 “服务 ”的 统规划和设计阶段，业务人员将不仅仅是提出需求，而是深入参与各类 “服务 ”的规划和设计。 “服务 ”间相互独立，所有 “服务 ”的信息可被汇集到统一的服务资源库中，使得用户、其他系统以及其他 “服务 ”可通过服务资源库来访问和使用。 服务 ”的功能和范围要求来具体实现或选择已有可用服务，并进行合成与装配。在 务人员可以自行调整相应的服务，以使 此外，与 业务流程管理（ 源于业务流程变革 领域，如业务流程再造（ 业务流程建模以及业务流程集成等。在技术方面，业务流程管理融合了许多相关技术，如流程建模、工作流技术、流程自动化以及业务流程监控等。借助 过对业务流程的监控，用户可以及时发现问题，并对业务流程进行不断创新和优化。而 而大大提高了业务的灵活性。因此，当前 统中大多都包含了 功能和可供用户来开发和管理的技术平台。 近年来，随着 别是基于标准的互联网技术（如 断成熟， 2006年至今， T 系统构建的主导方法和过程，在我国金融、电信、烟草、电子政务、医疗卫生、企业信息化、 流以及钢铁制造等行业和领域开始得到应用，关于各行业或领域的 参阅本书的第二篇相关内容。 2 基于 业务为中心 过业务人员参与 计和管理，使得 现 具体实施中，通过把完成实际业务流程中的一项任 务所需的源组织为服务进行封装，从而达到以业务为核心，通过业务选择技术，避免技术制约业务的问题。 活适应变化 统围绕用户业务构建，用户业务在实现层通过表现为一系列松散耦合的 “服务 ”来实现，这些服务可以根据用户需求随需组合，使得 用 升开发效率 服务 ”的重用，对原有 量具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得 统的开发和软件生产效率得到提升。同时，重用过程有 利于保护用户前期的信息化投资和 省 现用户信息化的可持续性建设与发展。 强调标准 实现系统及信息的互联互通和互操作。因此， 准都至关重要。 3 1) 提高业务效率和用户满意度 目前，我国企事业单位及政府部门都在强调 “服务 ”能力，各类组织对如何提高服务水平并使 经超过了对于 发效率的要求。依托 “服务 ”的松耦合性和重用性，通过现有 “服务 ”和 产的组装， 少了新业务应用开发的时间，提高了产品和服务的上市速度和开发效率，使得 统中的 “服务 ”和 产以更灵活的配置适应新的需求变化，提高了业务效率。 过创建与具体技术和最终用户设备无关的服务，应用于各种用户服务渠道，以保证一致的用户体验，提高用户的满意度。 2) 有利于整合 源，提高 统的对外协作能力 不少行业的企事业单位实施了很多应用系统，比如金融、电信行业以及一些集团企业，如何在不同省市的子公司、分公司和 多元化下属单位整合原有系统和信息资源，都是目前面临的主要系统建设需求。 仅仅是技术层面，同时提供了系统集成开发的主要方法及策略。导遵循开放标准，并独立于厂商多样性的环境，为基于互联网的组织内和组织间的系统通信协作和资源共享提供了良好的互操作性和可用性。 3) 提高投资回报率 采用 关部门，将基于服务规则和要求，构建下层 有技术中立的特性，降低了对厂商的依赖和转换成本；其次， 服务 ”为中心，梳理和重组业务流程，使各个业务系统能够互联互通和资源共享，这种服务的松耦合 及平台中立为机构降低了集成成本，松耦合和模块化简化了维护工作，降低了维护成本；因此，总体而言， 高现有 单个企业或单位的力量是有限的，只有某个行业内或供应链上的多家企业和单位联合，共享 “服务 ”资源，才能推动 开发模式进程，收到良好效益。在推进 同时，相应的标准化工作必须先行，用统一标准指导各家的服务开发、接口定义、通用数据格式定义、资源存储、服务注册与查询等 上述章节提到了 是， 有在适宜 采用合适的实施策略来保障，才有可能逐步得到 从 ： 企事业单位或者政府部门内部 统的整合 由于业务重组、并购或者内部机制调整，而需要实现组织内的统一管理、协作和信息共享。 需要对多个异构的 统进行整合，提高组织的整体决策、监控能力或业务流程效率。 企事业单位和政府部门之间 源的共享和协同 为了在业务和市场上合作，需要依赖业务合作伙伴提供其 统的非核心业 务功能或信息。 某项服务能力，需要多个组织和单位的 统需要共享信息，并联合处理，比如电子政务中的 “一站式审批 ”服务、各级政务资源共享交换平台等。 从头开始开发的新应用系统 是未来 系统构建的主导方法，因此考虑到未来的扩展和重用能力，用户在业务允许的条件范围内、可选择基于 构建新应用系统。 基于互联网的一些新的应用模式 基于互联网的软件服务化平台，如 在信息化建设中，除自己的 统之外，也同时希望集成互联网上的一些软件工具或 采用 “软件 +服务 ”策 略的单位。 但是，也有一些应用场景不适合用 时采用传统的技术、方法和过程来实施更为妥当，比如下述一些场景： 用户业务涉及效率敏感及实时性要求较高的系统，如工业控制、核心交易系统。 事务及安全性要求较高的业务系统。 用户的业务系统没有集成的需求。 当前的 对于大多数企事业单位和政府部门来说，如果采纳了 需要注意如下事项： 考虑 品选型，重视业务流程的管理，使 为其全面业务转型的实现手段。 企事业单位和政府部门在进行业务规划时，应基于自身实际 ，不要盲从。 采用 循序渐进、逐步推进为宜。 具体的规划和实施建议，可参见本书后续章节的相关内容。 4 从技术层面来看， 统的技术在构建 际上，在采用 与传统构建系统的方法比较， 强调标准化应用，更加重视系统的层次架构。 性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而 满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要在开发过程中遵循 用统一的标准，任何现有技术都能用来开发 服务 ”构造， “服务 ”之间的交互和组合采用了一种基于 “服务中介平台 ”的方式实现了松耦合，图 1 “服务 ”被提供和使用过程的示意图。 在图 1，服务提供者是一个可以通过网络寻址到的实体，它提供的 “服务 ”是基于 务请求者调用和使用服务提供者提供的“服务 ”；服务中介平台类似代理的角色，以目录方式存储了大量 “服务 ”资源，一方面可以接受服务提供者提供的各类 “服务 ”信息，另一方面可以通过协调机制把“服务 ”的请求分配给服务提供者。这样为服务请求者和服务提供者建立了中立的沟通渠道。 上述对服务交互图的描述是为了解释 核心元素 “服务 ”的运行机制。便于对技术有兴趣的用户 述内 容将围绕 在具体的项目中， 统构建没有完全统一的模式，系统的体系架构需要根据用户现状进行分析设计。但在层次和内容上， 统存在一些共性的特征。通常而言， 统的技术体系包含如下几个层次及内容，如图 1示。 1) 基础设施层 既包括服务器、网络设备等硬件 设施，也包括操作系统、数据库系统等基础软件，作为整个 2) 已有资源层 指用户当前所拥有的 “已有应用系统资源 ”和 “已有信息或数据资源 ”是指用户当前运行的应用系统及数据系统中，若干适合抽取出来作为为上层系统提供服务支持的资源。被抽取出来的资源可以是某个系统（指应用系统或数据系统）中的某个模块，可以是某个系统，可以是若干系统的合并及组合，也可以是各类格式的数据资源； “已有的组件 /构件资源 ”即包括原先采用组件 /构件系统的用户所拥有的组件 /构件资源，例如基于 者是包括已有的 “基础设施层 ”与 “已有资源层 ”是服务的具体技术实现层，上层应用使用的服务最终都由这两层提供。 3) 服务提供层 本层主要职责是封装下面两层的资源，并以服务的形式展现出来，从而构建整体的应用系统。这是 统最关键的一层，也是 统设计最难的部分，难点在于服务的规划与设计 该如何划分服务及服务的粒度。服务的规划与设计不仅直接影响到 间接影响到 这不仅仅是技术问 题，需要从企业战略目标的层次上考虑服务的划分，业务人员的参与也是设计出适合企业使用的服务的关键。具体方法和原则可参见本书第一篇第 3章 层主要由三部分组成 服务、企业服务总线（ 服务资源库，各部分内容说明如下： 服务 主要是与业务需求对齐的各类 “业务服务 ”（与用户业务相关的、实现特定业务功能）、 “流程服务 ”（与用户实际业务流程相关、包含人员与 “信息服务 ”（用于共享的各类数据和信息）、“交互服务 ”（为最终用户、其他 服务）以及 “其他服务 ”（包括实现安全规则、管理机制、质量策略等各类构建用户 企业服务总线（ 为服务之间间接和动态交互提供支持。息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位具体的服务）、消息验证（检验服务发送的消息是否满足格式要求）、消息格式转换（把消息从一种格式转成另外一种格式）、消息操作（包括增加或删除字符，或把消息中的特定字符进行转换的操作）等。 消息代理 ”（ 能， 但其增强了服务的动态路由和交换功能。通过把服务接入 户就可以把注意力全部集中在服务的构建上。此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接交换就变成了现在的间接交换，实现了松耦合。 服务资源库 服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。已注册的服务可以分成两大类，一类是可以直接被使用的、实现具体功能的服务，另一类是在运行时才进行组装的服务。服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面 作出的规定等。 4) 应用接入层 用户在这一层里可以部署各种应用，例如图 1融、电信等行业的应用。应用依据业务流程，主要由业务人员设计， 用依靠下层提供的服务及服务的组合具体实现。 5) 标准体系 标准体系贯穿 容上由若干行业内公认的标准组成，是每层系统规划设计时建议采用的规范，为 时便于实现 6) 开发平台及各类工具集 用于对 施测试、运维管理的软件平台及工具集，涵盖 系统各个层次。从系统生命周期角度出发，可划分为如下平台及工具： 规划平台及工具 主要用于做出整个系统的分析与规划，需要进行的工作包括项目管理、需求分析、版本控制以及文档管理等。 设计平台及工具 协助相关人员完成整个系统的设计工作。具体的平台及工具应该包括 “业务建模 ”（模型化企业的业务）、 “流程建模 ”（把业务整理成流程）、 “服务组装 ”（按照一定规则组装流程形成服务或应用）、 “服务建模 ”（模型化整理出来的服务用于服务生成）。这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别，体现的是 开发平台及工具 用于实施 采用的开发语言及开发平台没有限制。 测试平台及工具 用于实施 统的测试平台及测试工具在 注册部署平台及工具 用于实施服务的注册发布以及 统的部署。 监控管理平台及工具 用于 统整个生命周期的监控及管理。这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段 于用户及早对意外情况做出反应。 以上是通用的 统技术体系，可用于指导 目的实 施。各厂商在实际项目实施中可根据用户需求及产品选型情况，在此技术体系基础上提供个性化的解决方案。 层次的 套体系对统一用户与企业对 理解，加快 目实施的规范化，以及增强 目前国际上尚未有被广泛认可与接受的 些国际标准协会组织（如 ）及国际主流企业发布了若干用于构建 统的规范及标准（常见的是基于 术的一系列 范及标准），但这些规范及标准仅在各个标准化协会或企业内形成初步的体系，而且不同组织发布的规范及标准间存在重复甚至冲突的现象，因此，国际上统一的 为让用户了解目前国际上各类规范及标准的研制与使用情况，使用户在做系统开发决策时有一定参考依据，同时抱着建设适合国内用户使用的 理了各个国际标准协会组织及国际主流企业发布的主流规范及标准，整理出 84项关于 过体系化分析，划分 出 14个标准域（见图 1形成当前主流 终形成国际 已发布在 “中国 准服务网 ”，详细论述可参阅该文档）。 目前，我国 正在基于国内产业和用户需求，建立我国的 工作已于 2007年开始，目前已初步规划出我国 图 1标准体系会在我国标准化专业机构、软件产业界、学术界以及用户的共同合作下进行细化及具体研制。 中国 我国 个层次标准的研制工作展开： 础标准 是支撑 统实现的通用性基础标准，包括 语、 体技术要求、 准化指南以及 成开发标准，这一层次的标准将为 能作出限定，并为用户和软件厂商提供使用指导。 是 图 11 个标准域的若干标准中，我国将对国外已有的相关成熟技术标准（如部分 准）进行裁剪和修改，并采纳为我国相应的国家标准，部分国内有特殊需求的标准将采取自主研制的方式来制定。 包 括两类：一类对 二类为用户提供 设成熟度评估的评测规范，包括相关评测方法和指标。 上述标准规范将作为相应的 业 /领域标准 将根据行业或领域特征及信息化现状来研究制定适合本行业或本领域的 准体系。此部分标准的研制工作将由我国各行业相关标准化委员会或行业协会来主导制定。目前所列出的几个领域为部分有代表性的行业或领域，其他行业或领域也会逐步扩展进来。 目前，中国 准体系正逐步形成之中：基于 务描述语言（ 20030146基于 20030147项国家标准已完成制定并发布； 20080478 20080477开始研制； 准化指南与 务管理标准 4 个标准处于国家标准公示阶段； 务业务流程规范等两个标准处于申报阶段；金融行业 处于计划阶段。 向服务方法与传统方法 的区别 软件开发方法历经数次变革，从结构化分析方法开始，经面向对象方法、面向构件方法，到现在的面向服务方法，这些变革都是为满足客户需求的根本改变，以适应应用领域不断增加的复杂程度而提出的。 1结构化分析方法 结构化分析方法在 20 世纪 70 年代逐步形成，以算法为中心，按照逐层分解、逐步求精的原则，给出一组帮助系统分析人员产生功能规约的原理与技术，方法简单、清晰，符合人们认识世界、改造世界的一般规律，从而大大降低了求解问题的复杂程度。但其对需求变更的适应能力很差，所需文档数据资料极大，也不适合用于解决复杂的大规 模问题。 2面向对象方法 面向对象方法产生于 20世纪 80年代，以对象（对象 =数据 +算法）为中心，为软件工业实现工程化提供了强有力的支持。面向对象方法具有封装性、多态性和继承性，与人类习惯的思维方法一致，加强了人们对问题域的理解，增强了适应需求变化的能力，且利于用户的参与和各类人员的交流。但其需要依赖具体的编程语言，与业务存在鸿沟；封装粒度小，耦合度高，难于实现大规模、高层次的重用。 3面向构件方法 面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。企业业务被映射成系统构件，从整个企业的视角出发构思 、设计系统，是面向对象方法更高一级的抽象，比面向对象方法更切合企业的实际应用，重用度也进一步提高。但与开发语言紧密联系，导致接口标准不统一，不同开发语言实现的系统之间很难实现互操作。 4面向服务方法 面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。面向服务方法关注的是企业业务，它直接映射到业务，强调 业务的对齐，以服务为核心元素来封装企业的业务流程和企业已有应用系统。服务的粒度更大，更加匹配企业级应用中的业务，可以实现更高级别的重用。但目前存在相关标准未统一、应用案例较少等一些问题。 上述各类系统构建方法的比较如表 1 名称 概述 优点 缺点 结构化 方法 以算法为中心，又称为结构化分析 体现了逐层分解、逐步求精的原则，有严格的规则 难于检验分析结果的正确与否；对需求变更的适应能力很差；系统设计人员对分析结果的理解存在障碍 面向 对象 方法 以对象（对象 =数据算法）为中心，实现了对数据和算法的封装和继承 加强了对应用领域的理解，改进了沟通和交流；适应需求变化的能力较强；支持分析和设计结果的复用 纯技术导向，存在与业务的鸿沟；复杂度高，抽象程度低，难以实现大规模和高层 次的重用 面向 构件 方法 以组件或构件封装可重用的功能单元 重用度进一步提高，提高了软件企业的开发效率和质量 组件或构件封装方法和接口标准不统一，很难实现与外部应用系统之间的互操作 面 以服务封 业务驱动技术， 处在概念导入期末尾，相关标向 服务 方法 装业务流程和应用系统 以开放标准实现应用系统之间服务的相互访问，乃至复合应用的组装，实现了更高级别重用 准尚未统一，应用案例及工程实践刚起步 5 目实施 过程 当前 求来源主要分为两大类：系统整合驱动和新系统建设驱动，下面分别介绍之。 1系统整合驱动 电信、金融、政府等以服务为导向的企业或组织中，为了更好地满足客户或公众需求，必须提供一站式以及随需应变的服务能力。不仅要对企业或组织内部系统进行整合，同时要与相关的企业及组织进行信息系统协同，因此在整合及协同为主要需求推动下，基于 基于 类：应用系统之间的数据整合、功能整合和流程整合。整合的方式是通过对原有数据及 统资源进行服务化的包装，从而使得各系统以统一的、标准化的方式进行数据共享和业务协同。 2新系统建设驱动 随着信息化建设的进步一开展，部分企业的原有系统已经较庞大而复杂，面临新的业务需求，原有系统已远远不能满足这些新的业务需求。现有 统的相对刚性使很多 面对频繁的业务变化时步履维艰、痛苦不堪。从技术层面来说，许多软件系统基本采用手工编码的方式，总体架构设计的缺乏注定无法全面适应系统需求变更的需要。 因此许多单位在建设新的系统时，以柔性化敏捷化的业务应用系统为目标，希望能持续地支撑业务应用的变化及发展。 基础架构上基于业务服务、标准化、平台无关的特性，使其成为这些新系统构建的首选 。 需要指出的是，上述两种需求来源均不是孤立的，在各行业的项目建设中，系统整合往往与新系统建设相互融合，但各项目所解决的问题会对整合或新系统的建设各有偏重。 务生命周期 (以服务为中心的实施过程 ) 是应用开发和业务部门应用上的极大改进。 且涉及企业从上到下、从业务到 全面参与。在项目实施的过程中，必须首先由企业或组织的最高层做出决策，对 统及各项目实施路线做出整体规划，然后 由相关业务部门与 步取得 最终给企业带来效益。 施过程关系图 整体而言，企业的 于一个具体的 实施过程总体上由 3个过程组成： 1规划过程 规划过程的目的是基于企业或组织 的业务发展需求，确定信息 统建设的总体规划，并明确即将启动的具体 过程分为两个阶段：业务与 划阶段、需求规划阶段。具体各阶段说明见后续章节相关内容。 2实施过程 实施过程是 阶段需要用户的项目团队与指定的软件公司实施团队共同合作推进，在实施阶段应注意及时沟通，避免不必要的风险。如图 3示， 施过程为一个持续更迭的阶段，包括：服务规划及设计、服务开发及测试、服务部署、服务注册发布、服务运维及监控 5个阶段。具体各阶段说明见后续章节相关内容。 3治理过程 治理是贯穿规划过程和实施过程的策略和工作指南，其过程在 T 项目中更为重要。在 ，业务人、 员、服务使用者和服务提供者均处于不同环境中，由不同的部门开发和管理，无论从项目全过程中角度，还是服务全生命周期角度，均需要进行大量的协调工作，并且所有的协调工作必须基于统一的管理策略、原则和机制来实现。关于上述内容在后续章节中有详细阐释。 务与 业务规划和 划的目标是面向用户的高层决策者、 业务主管，在帮助其理解 商业价值的基础上，对于组织采纳 进行信息化建设的方向、目标、行动、任务、原则、策略、资源等进行综合分析，最终就是否采用 进行信息化建设做出宏观决策，并建立 体规划蓝图，其关系图如图 3 业务与 一方面，企事业单位或组织的决策部门和业务部门需要进行业务规划，通过对企业愿景、内外部环境、资源约束、风险等方面的梳理和分析，确 定企业的业务策略及需要解决的业务问题；另一方面，在业务规划的驱动下， 当前组织已有 统的功能、性能、问题、基础架构、平台、标准以及需要满足的需求等各方面进行评估和规划，确定 设路线以及组织结构。 在业务和 如下方面需要双方依次进行研究和磋商： 1是否要采纳 业务当前问题和需求是什么，现阶段是否有必要、有条件在信息化建设中采纳 采纳 底可以解决什么关键问题？ 此处可参考本指南中的 采纳 否具备相应的基本条件？比如：高层决策者对 有采纳 需的预算，信息化建设水平较高，具有较高素质的信息化专业队伍等。 2采纳何种 到底应该在什么层次、什么级别上采纳 是在战略级别上还是战术级别上？是全面铺开还是局部试点？ 具体而言什么业务单元需要 何排定需求优先级？把哪个作为切入点和突破口？ 3需要如何投入资源 采纳 现有的资源条件是否满足要求？ 采纳 度、指南、标准方面的配套？ 在此过程中，两方面人员在规划过程中经过反复沟通和协商并达成一致后，最后决策出是否采纳 求规划 需求规划阶段工作是：通过对业务及 目标进行综合分析，确定当前所要实施的 目目标包括成果性目标和约束性目标两大类，主要是需要在一定的成本及时间限度内完成项目的建设内容并达到预期目标，包括 系统的功能、非功能和用户界面描述等。 目实施方案主要包括项目的实施范围、进度规划、质量控制方法、成本预算、团队计划、风险管理计划、技术规划和产 品选型方案等。 在 议第一个 要选择太大，保证在一定时间内可以顺利实施完毕，确保项目的成功并使业务人员体会到 特点和价值。通过项目经验的积累，为后续 目开创一个良好的局面和环境。 身特点支持项目的递进式实现，可以采用不断滚动改进的方式实施项目。 同时需要强调的是，在 务标准和技术标准。确定和采纳合适的标准体系，将有利于保证 时提升其持续 利用与扩展能力。 项目具体的实施包括两方面内容：一方面要建设基础设施，另一方面围绕服务采用不断迭代的方式进行业务功能实现。由于 目建设核心是 “服务 ”，所以本书后续的阶段重点围绕第二方面进行介绍。 务规划及设计 服务规划及设计阶段的工作是：进行业务的分析和梳理，使业务流程能够映射到 进行服务建模，以确定所需要的服务集和服务实现策略。 在业务分析层面，目的是对业务及业务流程进行清晰的建模，此阶段具体实施中可依据一些国内外知名的业务分析方法论来完成。在 面，需要用服务建模方法来指导如何将业 务模型转化为实现 需要的模型，通过发现和定义与业务对齐的 “服务 ”，使 “服务 ”成为业务与 间的桥梁，从而让 业务能更好地互动。 此过程中，需要用户的业务人员参与进来，共同完成业务服务定义、业务流程定义、业务数据分析和组织架构确定等内容。对于相应的服务及流程，需要基于实际情况确定是利用已有 统进行服务化封装实现还是重新开发新的服务来实现。同时，用户方还需要与专业实施团队共同确定总体技术架构及所采用的技术、标准、工具和产品。 主要规划和设计的内容如下： 组织结构、业务布局分析。 相关业务部门 功能及需求分析，业务流程分析以及业务建模。 服务规划，根据业务分析和建模结果，分析识别所需的服务，对服务的层级进行合理划分，对服务的分类和聚合进行设计。识别和规划服务过程中，基本原则是要确保基于标准的服务可以被重新组合和利用并成功地用于典型行业应用环境中的各种系统中。 服务定义和描述，包含具体的服务名称、服务的操作、输入消息、输出消息，业务目标、业务规则、业务事件，非功能性需求等服务的定义，服务之间关系的描述，服务之间的依赖关系和包含关系。 服务实现策略，确定如何实现所需的服务，可以自行开发、外部采购或者集 成遗留 务开发及测试 与传统 “服务 ”是 括单个功能的服务，也包括流程类的服务。 服务开发是将业务服务的定义进行真正的技术实现。在传统项目中几乎所有的代码都需要编写实现，而在 以选择自行开发和手工编码，也可以调用或购买已有的内外部服务，实现过程更多采用参数配置、组装、流程定义等技术，代码编程工作量会减少。在服务具体的技术定义、开发和组装中，用户可以基于现有基础设施情况以及服务设计阶段的业务服务定 义，选择采用合类服务或流程类服务。 服务测试是保证服务开发正确有效的手段，与服务开发交叉进行。服务测试包括对单个服务的单元测试，也包括对于组装类服务或服务流程的集成测试。服务测试工作主要是基于服务定义和描述中的功能和性能指标，采用一定的测试工具、技术和标准规范，对服务进行质量测试和评估，并根据测试的结果来决定服务的开发是否合格。在 务的测试与传统的测试也不同，为保证服务能与其他服务互联互通，对服务的标准符合性测试 及互操作性测试更为重要。 务部署 此阶段是根据 过部署工具将所开发的各类服务及流程部署至用户的物理环境内，比如用户的应用服务器、流程服务器、门户服务器等。对于单个服务，部署后的服务可以被终端用户、其他 统或服务实际调用；对于多个基于服务的流程，部署后可形成完整应用系统，从而为用户业务提供相应的 服务部署包括静态和动态两种。静态部署是指服务之间的调用关系在运行前已确定，动态部署是指在应用系统运行中需要通过动态路由后确定服务调用关系。这两种部署类型需要在一定的基础设施基础之上进行 。由于用户物理环境往往是基于网络的分布式环境，具体部署的类型需要根据 务发布 此阶段需要将已开发完成的服务发布在服务注册中心（或服务资源库）内，以便被其他服务发现和调用。服务发布也被称为服务注册，两者含义相同，均指将已有的服务描述信息提交至公共的服务注册中心（或服务资源库）中。 服务注册中心（或服务资源库）是各类服务的统一登录目录，其功能分为两个方面：一方面，每个服务提供者可以发布其所提供的服务描述信息，供其他服务访问；另一方面，服务请求者可以迅速查找其所需的服务，以充分利 用已有的服务来实现其 统构建目标。服务注册中心（或服务资源库）可以在单个企业或组织内部使用，可以供多个合作伙伴共享，也可以在整个行业内部或特定区域内部共享；此外，服务注册中心（或服务资源库）与服务本身的运行节点之间可以是联机方式，也可以是脱机方式。具体的范围和方式根据用户的 划目标和策略来确定。 需特别说明的是，服务的发布不一定在服务开发部署完成之后才进行，部分目实施过程中，服务在设计阶段被定义出来之后就可以发布在服务注册中心（或服务资源库）中，但此时的服务仅供其他服务在设计中参考，而不能被实际调用，在后续实际开发部署完成之后，服务的状态应改为真正的发布。这样做的原因是可以减少服务设计中的重复，减少后续一些不必要的开发成本，但需要配合相应服务治理策略和工具来保证对它的有效访问。