实施SOA项目白皮书

1、soa项目实施白皮书1 soa概念41.1 与传统的建设方法不同41.2 与传统的建设过程不同52 soa特点52.1 以业务为中心62.2 灵活适应变化62.3 重用it资源，捉升开发效率62.4 更强调标准63 soa 效益及适用场景63.1 soa 效益63.2 soa适用场景74 soa技术概述94.1 soa技术体系94.2 soa标准体系124.3 面向服务方法与传统方法的区别145 soa项目实施简介165.1 soa项目需求來源165.2 服务生命周期(以服务为中心的实施过程)175.2.1 实施过程关系图175.2.2 业务与it规划19523需求规划205.2.4 服务规划

2、及设计21525服务开发及测试215.2.6 服务部署225.2.7 服务发布225.2.8 服务运维及监控235.2.9 治理过程235.3 soa项目阶段实施过程的关键点245.3.1 规划阶段245.3.2 分析阶段265.3.3 设计阶段275.3.4 实现、调试和部署阶段285.3.5 运维阶段295.4soa项目实施耍素305.4.1 用户原有it资源305.4.2 soa项目实施组织3()5.4.3 soa项目实施支撑平台315.4.4 soa项目实施指导文档体系31545 用户信息化要求315.5 用户在实施过程中的职责315.6 产品选型建议335.7 soa项h实施与传统项

3、h实施的比较341 soa概念随着我国各行业信息化建设的不断深入，企事业单位和政府部门逐步建立起的人批计算机信 息系统和各类数据信息因缺乏有效衔接，导致信息资源共享难、“信息孤岛”现象普遍存在。与此同时，对于企事业单位，随看经济全球化大坏境卜的市场竟争h益激烈，企业正在通过 加快管理转型、技术创新、新产品研发以及业务策略调整等方式来提升自己的核心竞争力、 持续占有并扩大市场份额。对于各级政府部门，在以“大部制”为核心的政府行政管理体制改 革的驱动下，以“管理”导向的政府职能正在向“服务”导向转变。企事业单位和政府部门的这些转型方式及过程的有效实施，一方面更需要信息技术和信息化 的手段来支撑，另

4、一方面，这些业务需求也对信息技术和信息化建设本身捉出了更高要求: it系统（通常也称为“信息系统”、“应用系统域“软件系统'等）要能快速响应用八业务发展 和变化的需求，新系统必须能在充分利用用户原有it资源基础上快速构建出來，同时要实 现跨平台、跨组织的数据共厚和业务协同。soa （service oriented architecture, rfri向服务的体系架构）是近年来软件规划和构建的 一种新方法，具概念最早由国际咨询机构gartner公司于1996年首次提岀。由于具本身特 性非常符合上述信息化需求和问题的解决思路，因此在2003年以后成为我国软件产业界和 各行业用户的关注焦点

5、，并在2006年逐步开始在多个行业信息化建设小被选择和应用。soa概念自被提出z后，不少国内外机构、企业均对soa进行了定义和阐释，但忖前还未 形成权威、统一的定义。木书作为国内首部从用户角度对soa概念和应用进行容观介绍的 书籍，在全书屮将对soa做如下定义和说明，以便于用户从应用角度对soa有直观理解: soa不是一种技术，而是一种it系统和软件的构建方法和过程，贯穿it系统规划、设计、 构建、运维的各个阶段。soal传统的it系统建设方法和过程有较大区别，简要说明如下:1.1与传统的建设方法不同基于soa的it系统建设更强调基于统一标准的快速开发和灵活纽合。“服务”是soa的核 心元素，

6、它对应于某个业务流程、业务功能或数据资源，按照统一的规格來组成信息系统。 基于“服务”，soa能显著缩小用户业务需求与it支持能力之间的鸿沟，指导it团队开发出 具冇良好移植性、扩展性和兼容性的应用系统。soa不仅仅站在单个倍息系统或集成项目的角度，而是更强调站在用八it建设全局或行业 内信息化建设全局，从1佃规划并逐步建成统一的it系统架构模式，并积累可重复使用的信 息系统资源库，以实现用户组织内或全行业内的信息资源共亨、信息系统协同、新系统的快 速构建以及系统对业务变化的快速应变能力。1-2与传统的建设过程不同soa建设过程的重点是基于“服务”的it系统规划和设计阶段，业务人员将不仅仅是提

7、出需 求，而是深入参与各类“服务”的规划和设计。“服务”间相互独立,所有“服务”的信息可被汇集 到统一的服务资源库中，使得用户、其他系统以及其他“服务”可通过服务资源库來访问和使 用。soa系统的具体开发阶段则是由技术人员依据每个“服务”的功能和范围要求來具体实现 或选择已冇可用服务，并进行合成与装配。在soa系统的运维过程中，业务人员可以自行 调整相应的服务，以使it系统能满足新的业务规则和需求。此外，与soa密切相关的还有一个概念业务流程管理（bpm, business process management）o bpm來源于业务流程变革领域，如业务流程再造（bpr）、业务流程建模 以及业务

8、流程集成等。在技术方面，业务流程管理融合了许多相关技术，如流程建模、工作 流技术、流程自动化以及业务流程监控等。借助bpm,通过对业务流程的监控，用八可以 及时发现问题，并对业务流程进行不断创新和优化。而soa使得这种流程变化更加便捷， 从而大人捉高了业务的灵活性。因此，当前soa系统屮大多都包含了 bpm的功能和可供 用八來开发和管理的技术平台。近年来，随着soa技术实现手段、特别是基于标准的互联网技术（如web服务和xml） 不断成熟，soa发展势头迅猛。从2006年至今，soa已经逐渐成为影响中国it系统构建 的主导方法和过程，在我国金融、电信、烟草、电了政务、医疗卫生、企业信息化、b2

9、b、 物流以及钢铁制造等行业和领域开始得到应丿ij,关于各行业或领域的soa应川情况，可参 阅本书的笫二篇和关内容。2 soa特点基于soa来构建的it系统具备如下特点:2.1以业务为中心soa更多关注于用户业务，通过业务人员参与soa系统的规划、设计和管理，使得it系 统能在对业务的深刻理解的基础上进行构建，实现it系统为用户业务的密切结合。在具体 实施屮，通过把完成实际业务流程小的一项任务所需的it资源组织为服务进行封装，从而 达到以业务为核心，通过业务选择技术，避免技术制约业务的问题。2.2灵活适应变化it系统围绕川户业务构建，川户业务在实现层通过表现为一系列松散耦合的“服务”來实现，

10、这些服务可以根据用户需求随需组合，使得it系统对于业务的适应能力明显提高。2.3重用it资源，提升开发效率soa强调对“服务”的重用，对原冇it资源的重用度提升是soa带来的关键效果z-,大量 具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得it系统的开 发和软件牛产效率得到提升。同时，重用过程有利于保护用户前期的信息化投资和it资产 积累，节省it系统开发成木，实现用户信息化的可持续性建设与发展。2.4更强调标准soa的实现强调基于统一的标准，soa系统建立在人呆的开放标准和协议之上，以实现系 统及信息的互联互通和互操作。因此，soa系统从规划到实施，标准都至关重要。3

11、soa效益及适用场景3.1 soa效益soa效益主要体现在如下几个方面：i）提高业务效率和用户满意度目询，我国金事业单位及政府部门都在强调“服务”能力，各类组织对如何捉髙服务水平并使it系统快速响应新业务需求的要求，经超过了对丁 it系统开发效率的要求。依托“服 务”的松耦介性和重用性，通过现冇“服务”和it资产的组装，soa减少了新业务应用开发 的时间，提高了产品和服务的上市速度和开发效率，使得soa系统中的“服务”和it资产 以更灵活的配置适应新的需求变化，提高了业务效率。soa通过创建与具体技术和最终用户设备无关的服务，应用于各种用户服务渠道，以保 证一致的用户体验，提高用户的满意度。2

12、）有利于整合it资源，提高it系统的对外协作能力不少行业的企事业单位实施了很多应用系统，比如金融、电信行业以及一些集团企业，如 何在不同省市的了公司、分公司和多元化下属单位整合原冇系统和信息资源，都是冃前面 临的主要系统建设需求。soa不仅仅是技术层面，同时提供了系统集成开发的主要方法及策略。soa倡导遵循开 放标准，并独立于厂商多样性的环境，为基于互联网的组织内和组织间的系统通信协作和 资源共享提供了良好的互操作性和可用性。3）提高投资回报率采用soa的企业、机关部门，将基于服务规则和要求，构建下层it架构，具有技术中立 的特性，降低了对厂商的依赖和转换成本；其次，soa系统以“服务”为屮心

13、，梳理和重组 业务流程，使各个业务系统能够互联互通和资源共享，这种服务的松耦合及平台中立为机 构降低了集成成本，松耦合和模块化简化了维护工作，降低了维护成本；因此，总体而言, soa可以保护原有it投资，提高现有it资产的投资回报率。单个企业或单位的力量是有限的，只有某个行业内或供应链上的多家企业和单位联合，共 亨“服务”资源，才能推动soa的开发模式进程，收到良好效益。在推进soa的同时，相 应的标准化工作必须先行，用统一标准指导各家的服务开发、接口定义、通用数据格式定 义、资源存储、服务注册与査询等soa实践工作。3.2 soa适用场景上述章节提到了 soa的特点以及能带来的效益，但是，s

14、oa并不是在所有的悄况和场景下 都适用，只冇在适宜soa特性的场景下，并采用介适的实施策略来保障，才冇可能逐步得 到soa带来的各项效益。从soa特点来看，soa在一些场景中能发挥其作用和优势，如：金事业单位或者政府部门内部1t系统的整合 山于业务重组、并购或者内部机制调整，而需要实现组织内的统一管理、协作和信息共 享。需要对多个异构的it系统进行整合，捉高组织的整体决策、监控能力或业务流程效率。 金事业单位和政府部门zi'可it资源的共亨和协同为了在业务和市场上合作，需要依赖业务合作伙伴捉供其it系统的非核心业务功能或 信息。某项服务能力，需要多个组织和单位的it系统盂要共享信息，并

15、联合处理，比如电了 政务中的“一站式审批,服务、各级政务资源共享交换平台等。 从头开始开发的新应用系统soa将是未来it新系统构建的主导方法，因此考虑到未来的扩展和重用能力，用户在 业务允许的条件范围内、可选择基于soa来构建新应用系统。 基于互联网的一些新的应用模式基于互联网的软件服务化平台，如saas等模式。在信息化建设屮，除h己的it系统z外，也同时希望集成互联网上的一些软件工具或 web服务的企事业单位，如采用“软件+服务”策略的单位。但是，也冇一些应川场景不适合用soa來实现，此时采用传统的技术、方法和过程來实丿施 更为妥当，比如下述一些场景： 用户业务涉及效率敏感及实时性要求较高的

16、系统，如工业控制、核心交易系统。 事务及安全性要求较高的业务系统。 用户的业务系统没有集成的需求。 当前的it系统基于统一的平台和编程方法。对于人多数企事业单位和政府部门来说，如果采纳了 soa,还需要注意如下事项： 考虑soa产品选型，重视业务流程的管理，使soa成为其全面业务转型的实现手段。 金事业单位和政府部门在进行业务规划时，应基于自身实际，不要廿从。 采用soa耍从全局慎重规划，以循序渐进、逐步推进为宜。具体的规划和实施建议，可参见木卩后续帝节的相关内容。4 soa技术概述4.1 soa技术体系从技术层面来看，soa并不是一项技术创新，传统的技术在构建soa系统时同样能派上用 场。实

17、际上，在采用soa进行系统整合的项目屮很多被整合的系统木身就是基于传统技术 开发的，但与传统构建系统的方法比较，soa更强调标准化应川，更加重视系统的层次架 构。soa特性之一的互联互通性就体现在系统中任一个服务能被其他服务共至是其他系统 的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统 一标准。因此，只要在开发过程中遵循soa的理念，采用统一的标准，任何现冇技术都能 用来开发soa系统。soa与传统技术体系的区别在于系统均是基于“服务”构造，“服务”之间的交互和纽合采川了 种基于“服务中介平台”的方式实现了松耦合，图1-1是“服务”被提供和使用过程的示意图。w

18、assoa系统中服务交互示意图在图中，服务提供者是一个町以通过网络寻址到的实体，它提供的“服务”是基丁 it系统 的某个功能或流程；服务请求者调用和使用服务提供者提供的“服务”；服务中介平台类似代 理的角色，以目录方式存储了人量“服务”资源，一方面可以接受服务提供者提供的各类“服务” 信息，另一方面可以通过协调机制把“服务”的请求分配给服务提供者。这样为服务请求者和 服务提供者建立了屮立的沟通渠道。上述对服务交互图的描述是为了解释soa的核心元素“服务”的运行机制。便r对技术有兴 趣的用户it人员了解。下述内容将围绕soa系统的整体技术体系来进行说明。在具体的项目屮，soa系统构建没有完全统一

19、的模式，系统的体系架构需要根据用户现状 进行分析设计。但在层次和内容上，soa系统存在一些共性的特征。通常而言，soa系统的技术体系包含如下儿个层次及内容，如图12所示。mam应用接入层金卸曲电侑汀*%*标准诈系卄发丫台-m各炎tn集soa系统基本技术体系1）基础设施层既包括服务器、网络设备等锁件设施，也包括操作系统、数据库系统等基础软件，作为整个 soa系统运行的基础平台。2）已有资源层指用八当询所拥有的it资源。“已有应用系统资源”和“已有信息或数据资源”是指用八当丽运 行的应用系统及数据系统中，若干适合抽取出来作为为上层系统提供服务支持的资源。被抽 取出來的资源可以是某个系统（指应用系统

20、或数据系统）中的某个模块，町以是某个系统, 可以是若干系统的合并及组合，也可以是各类格式的数据资源；“已有的组件/构件资源”即包 括原先采用组件/构件系统的用户所拥有的组件/构件资源，例如基于com/com+、 javabean/ejb或者是corba开发的技术功能组件或业务功能组件，也包括已有的web services服务组件。“基础设丿施层”与“已有资源层”是服务的具体技术实现层，上层应用使用 的服务最终都由这两层提供。3）服务提供层本层主要职责是封装下面两层的资源，并以服务的形式展现出來，从而构建整体的应用系统。 这是soa系统最关键的一层，也是soa系统设计最难的部分，难点在于服务的规

21、划与设 计该如何划分服务及服务的粒度。服务的规划与设计不仅直接影响到soa系统的性能, 也间接影响到soa系统的扩展能力。但这不仅仅是技术问题，需要从企业战略h标的层次 上考虑服务的划分，业务人员的参与也是设计出适合企业使用的服务的关键。具体方法和原 则可参见木书笫一篇笫3章3.2节的相关内容。本层主要由三部分组成服务、企业服务 总线（esb）、服务资源库，各部分内容说明如下： 服务主要是与业务需求对齐的各类“业务服务”（与用八业务相关的、实现特定业务 功能）、“流程服务”（与用户实际业务流程相关、包含人员与it系统参与的一个处理过 程）、“信息服务”（用于共享的各类数据和信息）、“交互服务”

22、（为最终用户、其他it系 统或服务提供多渠道统一访问入i的服务）以及“其他服务”（包括实现安全规则、管理 机制、质量策略等各类构建用户it系统所需的服务）。 金业服务总线（esb） 为服务之间间接和动态交互捉供支持。esb具体的功能包 括：消息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位 具体的服务）、消息验证（检验服务发送的消息是否满足格式要求）、消息格式转换（把 消息从一种格式转成另外一种格式）、消息操作（包括增加或删除字符，或把消息中的 特定字符进行转换的操作）等。esb包含了传统消息中间件的“消息代理”（messagebroker）功能，但其增强了服务的动态路山

23、和交换功能。通过把服务接入esb,由esb负责服务消息的流通，用户就町以把注意力全部集中在服务的构建上。 此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接交换就变成了 现在的间接交换，实现了松耦合。 服务资源库服务资源库里储存的是己注册的服务的描述信息及相关服务元数据描 述信息。已注册的服务可以分成两大类，一类是可以直接被使用的、实现具体功能的服 务，另一类是在运行时才进行组装的服务。服务的描述信息记录了服务实现的功能、服 务该如何调用、服务具体实体所在地以及服务在策略方面作出的规定等。4）应用接入层用户在这一层里可以部署各种应用，例如图小所示的在政府、金融、电信等行业的应用。

24、 应用依据业务流程，主要由业务人员设计，it技术人员辅助。应用依靠下层提供的服务及 服务的组合具体实现。5）标准体系标准体系贯穿soa系统从最底层到最上层全部四层结构，内容上由若干行业内公认的标准 组成，是每层系统规划设计时建议采用的规范，为soa系统的标准化实施确定了边界，同 吋便于实现soa系统间的互操作。6）开发平台及各类工具集用于对soa系统进行规划设计、实施测试、运维管理的软件平台及工具集，涵盖系统各个 层次。从系统生命周期角度出发，可划分为如下平台及工具： 规划平台及工具主要用于做出整个系统的分析与规划，需要进行的工作包括项目管 理、需求分析、版木控制以及文档管理等。 设计平台及工

25、具协助相关人员完成整个系统的设计工作。具体的平台及工具应该包 括“业务建模”（模型化企业的业务）、“流程建模”（把业务整理成流程）、“服务组装”（按 照一定规则组装流程形成服务或应用）、“服务建模”（模型化整理出来的服务用于服务 生成）。这个阶段的平台及工具与传统的开发方法所需的平台与工具有较人区别，体现 的是soa的思想。 开发平台及工具用于实施soa系统的开发，所采用的开发语言及开发平台没有限 制。 测试平台及工具用于实施soa系统的测试。传统的测试平台及测试工具在soa 系统的测试工作屮同样可以采用。 注册部署平台及工具用于实施服务的注册发布以及soa系统的部署。 监控管理平台及工具用于

26、soa系统整个生命周期的监控及管理。这类平台及工具 贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段soa系统的实 施进展,便于用户及早对意外情况做出反应。以上是通用的soa系统技术体系，可用于指导soa项目的实施。各厂商在实际项目实施 中可根据用八需求及产站选型情况，在此技术体系基础上提供个性化的解决方案。4.2 soa标准体系soa标准体系是指soa领域内多种类、多层次的soa标准所纽成的相互联系的有机整体。 这套体系对统一用八与企业対soa的理解，加快soa项目实施的规范化，以及增强soa 系统间的互操作能力等方面具有重耍意义。目询国际上尚未有被广泛认可与接受的soa标准体

27、系。一些国际标准协会组织（如w3c、 oasis、omg、ws-i等）及国际主流企业发布了若干用于构建soa系统的规范及标准（常 见的是基于web services技术的一系列ws规范及标准），但这些规范及标准仅在各个标 准化协会或企业内形成初步的体系，而口不同组织发布的规范及标准间存在重复甚至冲突的现象，因此，国际上统一的soa标准体系短吋间内还不能成型。为让用户了解冃前国际上各类规范及标准的研制与使用時况，使用户在做系统开发决策时有 一定参考依据，同时抱着建设适合国内用户使用的soa标准体系的冃标，isol梳理了各 个国际标准协会组织及国际主流企业发布的主流规范及标准,幣理出84项关于so

28、a与web services的规范及标准，经过体系化分析，划分出14个标准域（见图13）,形成当前主流 soa与web services规范及标准的全集，最终形成国际soa标准体系研究报告的口皮书 soa标准体系v1.0（已发布在“中国soa标准服务网”www.soa-上， 详细论述町参阅该文档）。应用基疏沁忑相矢杆礁崗矣典判阡谁s0a及web services规范及标准域冃前，我国正在基于国内产业和用户需求，建立我国的soa国家和行业标准体系，此工作 己于2007年开始，目前己初步规划出我国soa国家标准休系，如图14所示。此标准体 系会在我国标准化专业机构、软件产业界、学术界以及用户的共同

29、合作下进行细化及具体研 制。i1r1i£1-乂.尊nwvp 1r 4；l-.<mvwmrwj-4-4-卜j卜*iv 逹rk tr?yish.im 吕基-sr丄十 口川讯“一一討？rii17沁:卜、'mu川中国soa标准体系全景图我国soa标准体系工作将围绕4个层次标准的研制工作展开： soa基础标准是支撑soa系统实现的通用性基础标准，包括soa术语、soa 总体技术要求、soa标准化指南以及soa集成开发标准，这一层次的标准将 为soa系统或产品的基本功能、性能作出限定，并为用户和软件厂商提供使用指导。 soa支撑技术标准是soa系统相关的基础技术标准，在图14所示1

30、1个标准域 的若干标准中，我国将对国外已有的相关成熟技术标准(如部分ws标准)进行裁剪 和修改，并采纳为我国相应的国家标准，部分国内有特殊需求的标准将采取h主研制的 方式來制定。 soa测评标准包括两类：一类对soa相关的产品对于soa标准的符合性及互操 作性进行评测，第二类为用户提供soa建设成熟度评估的评测规范，包括相关评测方 法和指标。上述标准规范将作为相应的soa测评工具和平台的基本依据。 soa行业/领域标准将根据行业或领域特征及信息化现状来研究制定适合本行业或 本领域的soa标准体系。此部分标准的研制丄作将由我国各行业相关标准化委员会或 行业i办会來主导制定。冃前所列出的几个领域为

31、部分冇代表性的行业或领域，其他行业 或领域也会逐步扩展进来。目両，中国soa标准体系正逐步形成之中：基于xml的web服务描述语言(20030146-t-339)与基于xml的简单对彖访问协议(20030147t339)两项国家标 准已完成制定并发布；web服务可靠消息传递(20080478-t-469)与web服务互操作 框架(20080477469)已开始研制；soa术语、soa总体技术要求、soa标准 化指南与web服务管理标准4个标准处于国家标准公示阶段；web服务业务流程规 范等两个标准处于屮报阶段；金融行业soa标准化指南等处于计划阶段。4.3面向服务方法与传统方法的区别软件开发方

32、法历经数次变革，从结构化分析方法开始，经面向对象方法、面向构件方法，到 现在的血向服务方法，这些变革都是为满足客八需求的根本改变，以适应应用领域不断增加的复朵程度而提出的。1. 结构化分析方法结构化分析方法在20世纪70年代逐步形成，以算法为中心，按照逐层分解、逐步求精的 原则，给出一组帮助系统分析人员产生功能规约的原理与技术，方法简单、清晰，符合人们 认识世界、改造世界的一般规律，从而人人降低了求解问题的复杂程度。但其对需求变更的 适应能力很差，所需文档数据资料极大，也不适合用于解决复朵的大规模问题。2. 面向对彖方法面向对彖方法产生于20世纪80年代，以对彖（对彖二数据+算法）为中心，为软

33、件工业实 现工程化提供了强有力的支持。面向对象方法具有封装性、多态性和继承性，与人类习惯的 思维方法一致，加强了人们对问题域的理解，增强了适应需求变化的能力，且利于用户的参 与和各类人员的交流。但其需要依赖具体的编程语言，与业务存在鸿沟；封装粒度小，耦合 度高，难于实现大规模、高层次的重用。3面向构件方法面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。企业业务被映射成系统构件, 从整个金业的视角出发构思、设计系统，是面向对象方法更高一级的抽象，比面向对象方法 更切合金业的实际应用，重用度也进一步提高。但与开发语言紧密联系，导致接口标准不统 一，不同开发语言实现的系统z间很难实现互操作。

34、4.面向服务方法面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。面向服务方法关注 的是金业业务，它直接映射到业务，强调it与业务的对齐，以服务为核心元索來封装企业 的业务流程和金业已冇应用系统。服务的粒度更大，更加匹配金业级应用中的业务，可以实 现更高级别的重用。但冃前存在相关标准未统一、应用案例较少等一些问题。上述各类系统构建方法的比较如表所示。名称概述优点缺点结构化方法以算法为中心，乂称为结构化分析体现了逐层分解、逐步求耕的原则，冇严格的规则难于检验分析结果的正确与否；对需求变更的 适应能力很差；系统设计人员対分析结果的理 解存在障碍面向以对象（对象=数拥加強了对应用领域的

35、理解，纯技术导向，存在与业务的鸿沟；复杂度爲，对彖方法+算法）为中心，实现了对数据和算法的封装和继承改进了沟通和交流；适应需求变化的能力较强；支持分析和设计结果的复用抽彖程度低，难以实现人规模和高层次的重用面向构件方法以组件或构件封装可重用的功能单元重用度进一步捉高，提高了软件企业的开发效率和质量组件或构件封装方法和接口标准不统一，很难实现与外部应用系统z间的互操作面向服务方法以服务封装业务流程和应用系统业务驱动技术，以开放标准 实现应用系统z间服务的 相互访问，乃至复合应用的 组装，实现了更高级别重用处在概念导入期末尾，相关标准尚未统一，应用案例及工程实践刚起步5 soa项目实施过程5.1

36、soa项目需求来源当前soa项目的建设，需求来源主要分为两人类：系统整合驷动和新系统建设驱动，下面 分别介绍之。1. 系统整合驱动电信、金融、政府等以服务为导向的企业或组织中，为了更好地满足客户或公众需求，必须 提供一站式以及随盂应变的服务能力。不仅要对企业或组织内部系统进行整合，同时要与相 关的企业及组织进行信息系统协同，因此在整合及协同为主要需求推动下，基于soa的it 系统整体架构成为选样热潮。基于soa的整合范围包括3类：应用系统之间的数据整合、功能整合和流程整合。整合的 方式是通过对原有数据及it系统资源进行服务化的包装，从而使得各系统以统一的、标准 化的方式进行数据共享和业务协同。

37、2. 新系统建设驱动随着信息化建设的进步一开展,部分金业的原有系统己经较庞人而复杂,面临新的业务需求, 原有系统己远远不能满足这些新的业务需求。现有it系统的相对刚性使很多cio在而对频 繁的业务变化时步履维艰、痛苦不堪。从技术层而来说，许多软件系统基本采用手丄编码的 方式，总体架构设计的缺乏注定无法全面适应系统需求变更的需要。因此许多单位在建设新的系统时，以柔性化敏捷化的业务应用系统为日标，希望能持续地支 撑业务应用的变化及发展。soa在基础架构上基于业务服务、标准化、平台无关的特性， 使其成为这些新系统构建的首选。需要指出的是，上述两种需求来源均不是孤立的，在各行业的项冃建设中，系统整合往

38、往与 新系统建设相互融合,但各项冃所解决的问题会对整合或新系统的建设各冇偏重。5.2服务生命周期（以服务为中心的实施过程）soa既是对it规划设计和基础设施方面的重大改革，也是应川开发和业务部门应川上的极 大改进。soa项目的实施不仅涉及it部门，而且涉及金业从上到下、从业务到it的全血 参与。在项目实施的过程中，必须首先由企业或组织的最高层做出决策，对it系统及各项 目实施路线做出整体规划，然后山相关业务部门与it部门深度合作并分步实施，逐步取得 soa项目的成功，并最终给企业带来效益。5.2.1实施过程关系图soa项f1实施过程关系图如图31所示。|业费规勾 hj»|soa项目实

39、施过程关系图整体而言，企业的it系统建设是逐步进行的，对于一个具体的soa项冃，其实施过程总体 上由3个过程组成：1. 规划过程规划过程的fi的是基于企业或组织的业务发展需求，确定信息it系统建设的总体规划，并 明确即将启动的具体soa项目的范围及目标。此过程分为两个阶段：业务与it规划阶段、 需求规划阶段。具体各阶段说明见后续章节相关内容。2. 实施过程实施过程是soa项目建设的执行阶段，此阶段需要用户的项日团队与指定的软件公司实施 团队共同合作推进，在实施阶段应注意及吋沟通，避免不必耍的风险。如图31所示，soa 实施过程为一个持续更迭的阶段，包括：服务规划及设计、服务开发及测试、服务部署

40、、服 务注册发布、服务运维及监控5个阶段。具体各阶段说明见后续章节相关内容。3. 治理过程治理是贯穿规划过程和实施过程的策略和工作指南，其过程在soa项目小比在普通it项目 中更为重要。在soap,业务人、it人员、服务使用者和服务捉供者均处于不同环境中， 由不同的部门开发和管理，无论从项冃全过程中角度，还是服务全生命周期角度，均需要进 行大量的i办调工作，并r所冇的协调工作必须基于统一的管理策略、原则和机制來实现。关 于上述内容在后续章节中有详细阐释。522业务与it规划业务规划和it规划的目标是血向用户的高层决策者、cio和业务主管，在帮助英理解soa 的商业价值的基础上，对于组织采纳so

41、a来进行信息化建设的方向、目标、行动、任务、 原则、策略、资源等进行综合分析，最终就是否采用soa來进行信息化建设做出広观决策, 并建立soa总体规划蓝图，其关系图如图3-2所示。业务与it规划关系图方血，企事业单位或组织的决策部门和业务部门需要进行业务规划，通过对企业愿景、内 外部环境、资源约束、风险等方面的梳理和分析，确泄金业的业务策略及需要解决的业务问 题；另一方面，在业务规划的驱动下，it部门的cio以及团队需要从信息化的角度，对当 前组织己有it系统的功能、性能、问题、基础架构、平台、标准以及需要满足的需求等各 方血进行评估和规划，确定it整体的建设策略、建设路线以及组织结构。在业务

42、和it规划过程中，在如下方面需要双方依次进行研究和磋商:1.是否要采纳soa业务肖前问题和需求是什么，现阶段是否有必要、有条件在信息化建设屮采纳soa?采纳soa,到底可以解决什么关键问题？一此处可参考本指南屮的soa效益及适川场景内容。采纳soa,是否具备相应的棊本条件？比如：高层决策者对soa具有全面的理解和一致的认识，具冇采纳soa所盂的预算，信息化建设水平较高，具冇较高索质的信息化专业队伍等。2.采纳何种soa策略 到底应该在什么层次、什么级别上采纳soa? 是在战略级别上还是战术级别上？是全面铺开还是局部试点？ 具体而言什么业务单元需要soa?如何排定需求优先级？把哪个作为切入点和突

43、破 口？3. 需要如何投入资源 采纳soa需要哪些资源投入？ 现冇的资源条件是否满足要求？ 采纳soa需要哪些政策、制度、指南、标准方面的配套？ 在此过程屮，两方面人员在规划过程中经过反复沟通和协商并达成一致后，最后决策出 是否采纳soa以及总体采纳思路。5.2.3需求规划需求规划阶段工作是：通过对业务及it的口标进行综合分析，确定当前所要实施的soa项 目目标以及项目实施方案。soa项口口标包括成果性f1标和约束性冃标两大类，主要是需耍在一定的成本及吋间限度 内完成项目的建设内容并达到预期目标，包括soa系统、子系统的功能、非功能和用八界 而描述等。soa项口实施方案主要包括项目的实施范围、

44、进度规划、质量控制方法、成本预算、团队 计划、风险管理计划、技术规划和产甜选型方案等。在it系统规划中需耍考虑系统的规模，建议第一个soa项口要限定项口大小，不耍选择太 大，保证在一定时间内可以顺利实施完毕，确保项ii的成功并使业务人员体会到soa的特 点和价值。通过项冃经验的积累，为后续soa项冃开创一个良好的局而和坏境。soa本身 特点支持项目的递进式实现，可以采用不断滚动改进的方式实施项目。同时需要强调的是，在soa项目实施方案中需要特别考虑标准问题。soa项目所涉及的标 准包含两方面：业务标准和技术标准。确定和采纳合适的标准体系，将有利于保证it系统 的建设质虽，同时提升其持续利用与扩

45、展能力。项冃具体的实施包括两方而内容：一方面要建设基础设施，另一方面围绕服务采用不断迭代 的方式进行业务功能实现。由于soa项目建设核心是“服务”，所以本书后续的阶段重点围 绕第二方面进行介绍。524服务规划及设计服务规划及设计阶段的工作是：进行业务的分析和梳理，使业务流程能够映射到it流程， 并进行服务建模，以确定所需耍的服务集和服务实现策略。在业务分析层而，0的是对业务及业务流程进行清晰的建模，此阶段具体实施小可依据一些 国内外知名的业务分析方法论来完成。在it层面，需要用服务建模方法来指导如何将业务 模型转化为实现soa所需要的模型，通过发现和定义与业务对齐的“服务”，使“服务”成为 业

46、务与it之间的桥梁，从而让it与业务能更好地互动。此过程中，需要用户的业务人员参为进来，共同完成业务服务定义、业务流程定义、业务数 据分析和组织架构确定等内容。对于相应的服务及流程，需要基于实际情况确定是利用己有 it系统进行服务化封装实现还是重新开发新的服务来实现。同时，用八方还需要与专业实 施团队共同确定总体技术架构及所采用的技术、标准、工具和产品。主要规划和设计的内容如下： 组织结构、业务布局分析。 相关业务部门功能及需求分析，业务流程分析以及业务建模。 服务规划，根据业务分析和建模结果，分析识别所需的服务，对服务的层级进行合理划 分，对服务的分类和聚合进行设计。识别和规划服务过程小，基

47、本原则是要确保基于标 准的服务可以被重新组合和利川并成功地川于典型行业应川环境中的各种系统中。 服务定义和描述，包含具体的服务名称、服务的操作、输入消息、输出消息，业务目标、 业务规则、业务事件，非功能性盂求等服务的定义，服务z间关系的描述，服务z间的 依赖关系和包含关系。 服务实现策略，确定如何实现所需的服务，可以白行开发、外部采购或者集成遗留it 资源。5.2.5服务开发及测试soa项目小的服务开发即服务实现，其与传统it项目开发有较人差别。“服务”是soa项目 开发阶段的核心概念，包括单个功能的服务，也包括流程类的服务。服务开发是将业务服务的定义进行真正的技术实现。在传统项冃中几乎所有的

48、代码都需要编 写实现，而在soa实现中，可以选择自行开发和手工编码，也町以调川或购买已冇的内外 部服务，实现过程更多采用参数配置、组装、流程定义等技术，代码编程工作量会减少。在 服务具体的技术定义、开发和组装中，用八可以基于现有基础设施情况以及服务设计阶段的 业务服务定义，选择采用web service. sca/sd0技术或其他传统技术逐步实现单业务功 能服务、纽合类服务或流程类服务。服务测试是保证服务开发正确冇效的手段，与服务开发交叉进行。服务测试包括对单个服务 的单元测试，也包括对于组装类服务或服务流程的集成测试。服务测试工作主要是基于服务 定义和描述中的功能和性能指标，采用一定的测试工

49、具、技术和标准规范，对服务进行质量 测试和评估，并根据测试的结果来决定服务的开发是否合格。在soa项冃中，服务的测试 与传统的测试也不同，为保证服务能与具他服务互联互通，对服务的标准符合性测试及互操 作性测试更为重要。5.2.6服务部署此阶段是根据soa项目目标、通过部署工具将所开发的各类服务及流程部署至用户的物理 坏境内，比如用户的应用服务器、流程服务器、门户服务器等。对于单个服务，部署后的服 务可以被终端用八、其他it系统或服务实际调用；对于多个基于服务的流程，部署后可形 成完整应用系统，从而为用户业务提供相应的it支持。服务部署包括静态和动态两种。牌态部署是指服务z间的调用关系在运行前已

50、确定，动态部 署是指在应用系统运行屮需要通过动态路由示确定服务调用关系。这两种部署类型需要在一 定的基础设施基础之上进行。由于用户物理环境往往是基于网络的分布式坏境，具体部署的 类型需要根据soa项目实施的状况和需求來定。5.2.7服务发布此阶段需要将已开发完成的服务发布在服务注册屮心（或服务资源库）内，以便被其他服务 发现和调用。服务发布也被称为服务注册，两者含义相同，均指将己有的服务描述信息提交 至公共的服务注册中心（或服务资源库）中。服务注册中心（或服务资源库）是各类服务的统一登录冃录，其功能分为两个方面：一方面, 每个服务提供者可以发布其所提供的服务描述信息，供其他服务访问；另一方面，

51、服务请求 者可以迅速杏找其所需的服务，以充分利用已有的服务来实现其it系统构建目标。服务注 册中心（或服务资源库）可以在单个企业或纽织内部使用，可以供多个合作伙伴共亨，也可 以在整个行业内部或特定区域内部共享；此外，服务注册中心（或服务资源库）与服务本身 的运行节点之间可以是联机方式，也可以是脱机方式。具体的范围和方式根据用八的it规 划冃标和策略来确定。需特别说明的是，服务的发布不一定在服务开发部署完成z后才进行，部分soa项冃实施 过程中，服务在设计阶段被定义出来之后就可以发布在服务注册屮心（或服务资源库）屮， 但此时的服务仅供其他服务在设计小参考，而不能被实际调用，在后续实际开发部署完成

52、z 后，服务的状态应改为真正的发布。这样做的原因是可以减少服务设计中的匝复，减少后续 一些不必要的开发成本，但需要配合相应服务治理策略和工具来保证对它的有效访问。5.2.8服务运维及监控此阶段的运维监控分为两个方面，包括用户方的业务人员对业务流程运行状况和绩效的监 控，也包括系统维护人员从it层面对基于系统服务的竹理和部署模型、对soa系统运行状 态以及服务调用状态进行整体管理、控制和监测，从而保障soa系统稳定可靠的运行。川户口 j将此过程的服务运维及监控结果与规划阶段的仿真情况进行对比，并对业务流程及服 务进行功能和性能优化。如果用户的业务需求发生变化时，用户的业务人员可在系统维护人员的协

53、助下，对soa系 统的各类服务（包括流程服务）进行可视化调整。如果变化程度较大，原冇服务及流程无法 满足时，则需要重新开发新的服务，并重复整个实施过程。但此过程主要涉及的工作量是新 的服务或流程，因此并不影响原有的系统运行。5.2.9治理过程soa治理是基于传统it治理（it governance）的基础z上，针对soa所特冇的服务生命 周期定制的soa治理管制。它通过制定人员和角色、管理流程及决策，帮助企业管理整个 soa的生命周期。soa治理需要采纳相应的方法论和最佳实践，通常需要有丄具辅助企业 最后定制并管治符合金业自身需要的治理决策。对于用户而言，要实现soa的效益，开展soa治理非常

54、关键。治理不同于管理。治理规 划需要制定什么决策，而管理是制定和实施决策的过程。治理重在建立决策，而管理重在贯 彻执行决策。soa治理强调更多的是政策、方法和策略问题，阳不是技术或业务问题。治理贯穿规划和 实施全过程，涉及的不仅仅是一个项冃，而是更多的是从it全局來看，横跨多个应用系统、 各类流程、信息及人力资源。因此需要用八高层的重视。soa治理主要包括如下内容： 高层的领导决策者指导组织建立满足其1=1标的策略，包括确定谁负责制定决策、需要制 定什么决策以及使决策制定保持-致的决策。 建立soa的组织机制以及授权机制，同吋保证项目实施各阶段按预定目标推进的有效 控制机制。 建立沟通计划、流

55、程或协议，保证各相关方都对服务获得一致信息。比如，必须在服务 提供者和服务使用者之间建立一个协议，告知使用者可以希望得到什么功能、提供者应 该提供什么功能。 涉及服务全纶命周期，包括指导可重用资产的开发，确立如何设计和开发服务，服务的 版本和质量管理，以及这些服务如何随时间增长进行更改。 建立评佔soa项冃成熟度以及各项性能测试的评估方法，并在soa项冃实施过程中 进行监控和调整。5.3 soa项目阶段实施过程的关键点soa项目如同其他it项目一样，也有类似的实施过程，一个可能的实施过程如卜图所示：从表而的儿个过程看soa项目的实施没有什么特别的地方，能够体现soa特点的是在项 目实施过程屮的

56、每一个具体环节屮，如规划阶段对标准的考虑，分析阶段对业务的详细描述 和定义，设计阶段技术架构（包括逻辑架构和物理架构）的定义，实现阶段更多依赖于定义而 不是编码，以及运维阶段对服务运行情况的重点关注。下面介绍实施过程中的主耍关键点。5.3.1规划阶段在这一阶段有许多重要的事情需耍做，这将决定soa项0实施的成败。首先是需要确定目标，対于系统的功能目标应该是明确的，除此之外我们需要重点关注的是 为什么要采用soa ）&想，是为了达到什么h的。在这时我们需要了解soa能够给我们带 来什么，我们希望得到什么，这两者是否匹配;也需耍了解soa适合什么，不适合什么，我 们建设项冃与soa适合是否适配。如果这些匹配一致我们就町以放心进行下一步骤了，否 则就得考虑是否一定要采用soa,是否采用其他的思想和技术架构也足以解决问题。在此我们再看一下soa特点：强调业务服务的复用支持业务灵活重构强调松耦合强调标准的采用我们也需要了解soa不适合的地方：开发简单单个应用时，不要使用soa构建高吞吐量应用或实时m用是，不要使用soa如果网络速度慢，网络不可靠时，不要使用soa当服务接口不确定时（即业务服务功能木身不稳定时），不要使用soa当安全性极为重要