SOA项目实施白皮书

《SOA项目实施白皮书》由会员分享，可在线阅读，更多相关《SOA项目实施白皮书（42页珍藏版）》请在装配图网上搜索。

1、SOA项目实施白皮书目 录1SOA概念31.1与传统的建设方法不同41.2与传统的建设过程不同42SOA特点52.1以业务为中心52.2灵活适应变化52.3重用IT资源，提升开发效率52.4更强调标准53SOA效益及适用场景63.1SOA效益63.2SOA适用场景74SOA技术概述84.1SOA技术体系84.2SOA标准体系124.3面向服务方法与传统方法的区别145SOA 项目实施简介155.1SOA项目需求来源155.2服务生命周期(以服务为中心的实施过程)165.2.1实施过程关系图165.2.2业务与IT规划185.2.3需求规划195.2.4服务规划及设计205.2.5服务开发及测试

2、205.2.6服务部署215.2.7服务发布215.2.8服务运维及监控225.2.9治理过程225.3SOA项目阶段实施过程的关键点235.3.1规划阶段235.3.2分析阶段255.3.3设计阶段265.3.4实现、调试和部署阶段275.3.5运维阶段285.4SOA项目实施要素295.4.1用户原有IT资源295.4.2SOA项目实施组织295.4.3SOA项目实施支撑平台305.4.4SOA项目实施指导文档体系305.4.5用户信息化要求305.5用户在实施过程中的职责305.6产品选型建议325.7SOA项目实施与传统项目实施的比较331 SOA概念随着我国各行业信息化建设的不断深入

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

4、通常也称为“信息系统”、“应用系统”或“软件系统”等）要能快速响应用户业务发展和变化的需求，新系统必须能在充分利用用户原有IT资源基础上快速构建出来，同时要实现跨平台、跨组织的数据共享和业务协同。SOA（Service Oriented Architecture，面向服务的体系架构）是近年来软件规划和构建的一种新方法，其概念最早由国际咨询机构Gartner公司于1996年首次提出。由于其本身特性非常符合上述信息化需求和问题的解决思路，因此在2003年以后成为我国软件产业界和各行业用户的关注焦点，并在2006年逐步开始在多个行业信息化建设中被选择和应用。SOA概念自被提出之后，不少国内外机构、企

5、业均对SOA进行了定义和阐释，但目前还未形成权威、统一的定义。本书作为国内首部从用户角度对SOA概念和应用进行客观介绍的书籍，在全书中将对SOA做如下定义和说明，以便于用户从应用角度对SOA有直观理解：SOA不是一种技术，而是一种IT系统和软件的构建方法和过程，贯穿IT系统规划、设计、构建、运维的各个阶段。SOA与传统的IT系统建设方法和过程有较大区别，简要说明如下：1.1 与传统的建设方法不同基于SOA的IT系统建设更强调基于统一标准的快速开发和灵活组合。“服务”是SOA的核心元素，它对应于某个业务流程、业务功能或数据资源，按照统一的规格来组成信息系统。基于“服务”，SOA能显著缩小用户业务

6、需求与IT支持能力之间的鸿沟，指导IT团队开发出具有良好移植性、扩展性和兼容性的应用系统。SOA不仅仅站在单个信息系统或集成项目的角度，而是更强调站在用户IT建设全局或行业内信息化建设全局，从而规划并逐步建成统一的IT系统架构模式，并积累可重复使用的信息系统资源库，以实现用户组织内或全行业内的信息资源共享、信息系统协同、新系统的快速构建以及系统对业务变化的快速应变能力。1.2 与传统的建设过程不同SOA建设过程的重点是基于“服务”的IT系统规划和设计阶段，业务人员将不仅仅是提出需求，而是深入参与各类“服务”的规划和设计。“服务”间相互独立，所有“服务”的信息可被汇集到统一的服务资源库中，使得用

7、户、其他系统以及其他“服务”可通过服务资源库来访问和使用。SOA系统的具体开发阶段则是由技术人员依据每个“服务”的功能和范围要求来具体实现或选择已有可用服务，并进行合成与装配。在SOA系统的运维过程中，业务人员可以自行调整相应的服务，以使IT系统能满足新的业务规则和需求。此外，与SOA密切相关的还有一个概念业务流程管理（BPM，Business Process Management）。BPM来源于业务流程变革领域，如业务流程再造（BPR）、业务流程建模以及业务流程集成等。在技术方面，业务流程管理融合了许多相关技术，如流程建模、工作流技术、流程自动化以及业务流程监控等。借助BPM，通过对业务流程

8、的监控，用户可以及时发现问题，并对业务流程进行不断创新和优化。而SOA使得这种流程变化更加便捷，从而大大提高了业务的灵活性。因此，当前SOA系统中大多都包含了BPM的功能和可供用户来开发和管理的技术平台。近年来，随着SOA技术实现手段、特别是基于标准的互联网技术（如Web服务和XML）不断成熟，SOA发展势头迅猛。从2006年至今，SOA已经逐渐成为影响中国IT系统构建的主导方法和过程，在我国金融、电信、烟草、电子政务、医疗卫生、企业信息化、B2B、物流以及钢铁制造等行业和领域开始得到应用，关于各行业或领域的SOA应用情况，可参阅本书的第二篇相关内容。2 SOA特点基于SOA来构建的IT系统具

9、备如下特点：2.1 以业务为中心SOA更多关注于用户业务，通过业务人员参与SOA系统的规划、设计和管理，使得IT系统能在对业务的深刻理解的基础上进行构建，实现IT系统与用户业务的密切结合。在具体实施中，通过把完成实际业务流程中的一项任务所需的IT资源组织为服务进行封装，从而达到以业务为核心，通过业务选择技术，避免技术制约业务的问题。2.2 灵活适应变化IT系统围绕用户业务构建，用户业务在实现层通过表现为一系列松散耦合的“服务”来实现，这些服务可以根据用户需求随需组合，使得IT系统对于业务的适应能力明显提高。2.3 重用IT资源，提升开发效率SOA强调对“服务”的重用，对原有IT资源的重用度提升

10、是SOA带来的关键效果之一，大量具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得IT系统的开发和软件生产效率得到提升。同时，重用过程有利于保护用户前期的信息化投资和IT资产积累，节省IT系统开发成本，实现用户信息化的可持续性建设与发展。2.4 更强调标准SOA的实现强调基于统一的标准，SOA系统建立在大量的开放标准和协议之上，以实现系统及信息的互联互通和互操作。因此，SOA系统从规划到实施，标准都至关重要。3 SOA效益及适用场景3.1 SOA效益SOA效益主要体现在如下几个方面：1) 提高业务效率和用户满意度目前，我国企事业单位及政府部门都在强调“服务”能力，各类组织对如

11、何提高服务水平并使IT系统快速响应新业务需求的要求，已经超过了对于IT系统开发效率的要求。依托“服务”的松耦合性和重用性，通过现有“服务”和IT资产的组装，SOA减少了新业务应用开发的时间，提高了产品和服务的上市速度和开发效率，使得SOA系统中的“服务”和IT资产以更灵活的配置适应新的需求变化，提高了业务效率。SOA通过创建与具体技术和最终用户设备无关的服务，应用于各种用户服务渠道，以保证一致的用户体验，提高用户的满意度。2) 有利于整合IT资源，提高IT系统的对外协作能力不少行业的企事业单位实施了很多应用系统，比如金融、电信行业以及一些集团企业，如何在不同省市的子公司、分公司和多元化下属单位

12、整合原有系统和信息资源，都是目前面临的主要系统建设需求。SOA不仅仅是技术层面，同时提供了系统集成开发的主要方法及策略。SOA倡导遵循开放标准，并独立于厂商多样性的环境，为基于互联网的组织内和组织间的系统通信协作和资源共享提供了良好的互操作性和可用性。3) 提高投资回报率采用SOA的企业、机关部门，将基于服务规则和要求，构建下层IT架构，具有技术中立的特性，降低了对厂商的依赖和转换成本；其次，SOA系统以“服务”为中心，梳理和重组业务流程，使各个业务系统能够互联互通和资源共享，这种服务的松耦合及平台中立为机构降低了集成成本，松耦合和模块化简化了维护工作，降低了维护成本；因此，总体而言，SOA可

13、以保护原有IT投资，提高现有IT资产的投资回报率。单个企业或单位的力量是有限的，只有某个行业内或供应链上的多家企业和单位联合，共享“服务”资源，才能推动SOA的开发模式进程，收到良好效益。在推进SOA的同时，相应的标准化工作必须先行，用统一标准指导各家的服务开发、接口定义、通用数据格式定义、资源存储、服务注册与查询等SOA实践工作。3.2 SOA适用场景上述章节提到了SOA的特点以及能带来的效益，但是，SOA并不是在所有的情况和场景下都适用，只有在适宜SOA特性的场景下，并采用合适的实施策略来保障，才有可能逐步得到SOA带来的各项效益。从SOA特点来看，SOA在一些场景中能发挥其作用和优势，如

14、：n 企事业单位或者政府部门内部IT系统的整合由于业务重组、并购或者内部机制调整，而需要实现组织内的统一管理、协作和信息共享。需要对多个异构的IT系统进行整合，提高组织的整体决策、监控能力或业务流程效率。n 企事业单位和政府部门之间IT资源的共享和协同为了在业务和市场上合作，需要依赖业务合作伙伴提供其IT系统的非核心业务功能或信息。某项服务能力，需要多个组织和单位的IT系统需要共享信息，并联合处理，比如电子政务中的“一站式审批”服务、各级政务资源共享交换平台等。n 从头开始开发的新应用系统SOA将是未来IT新系统构建的主导方法，因此考虑到未来的扩展和重用能力，用户在业务允许的条件范围内、可选择

15、基于SOA来构建新应用系统。n 基于互联网的一些新的应用模式基于互联网的软件服务化平台，如SaaS等模式。在信息化建设中，除自己的IT系统之外，也同时希望集成互联网上的一些软件工具或Web服务的企事业单位，如采用“软件+服务”策略的单位。但是，也有一些应用场景不适合用SOA来实现，此时采用传统的技术、方法和过程来实施更为妥当，比如下述一些场景：n 用户业务涉及效率敏感及实时性要求较高的系统，如工业控制、核心交易系统。n 事务及安全性要求较高的业务系统。n 用户的业务系统没有集成的需求。n 当前的IT系统基于统一的平台和编程方法。对于大多数企事业单位和政府部门来说，如果采纳了SOA，还需要注意如

16、下事项：n 考虑SOA产品选型，重视业务流程的管理，使SOA成为其全面业务转型的实现手段。n 企事业单位和政府部门在进行业务规划时，应基于自身实际，不要盲从。n 采用SOA要从全局慎重规划，以循序渐进、逐步推进为宜。具体的规划和实施建议，可参见本书后续章节的相关内容。4 SOA技术概述4.1 SOA技术体系从技术层面来看，SOA并不是一项技术创新，传统的技术在构建SOA系统时同样能派上用场。实际上，在采用SOA进行系统整合的项目中很多被整合的系统本身就是基于传统技术开发的，但与传统构建系统的方法比较，SOA更强调标准化应用，更加重视系统的层次架构。SOA特性之一的互联互通性就体现在系统中任一个

17、服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要在开发过程中遵循SOA的理念，采用统一的标准，任何现有技术都能用来开发SOA系统。SOA与传统技术体系的区别在于系统均是基于“服务”构造，“服务”之间的交互和组合采用了一种基于“服务中介平台”的方式实现了松耦合，图1-1是“服务”被提供和使用过程的示意图。SOA系统中服务交互示意图在图1-1中，服务提供者是一个可以通过网络寻址到的实体，它提供的“服务”是基于IT系统的某个功能或流程；服务请求者调用和使用服务提供者提供的“服务”；服务中介平台类似代理的角色，以目录方式存

18、储了大量“服务”资源，一方面可以接受服务提供者提供的各类“服务”信息，另一方面可以通过协调机制把“服务”的请求分配给服务提供者。这样为服务请求者和服务提供者建立了中立的沟通渠道。上述对服务交互图的描述是为了解释SOA的核心元素“服务”的运行机制。便于对技术有兴趣的用户IT人员了解。下述内容将围绕SOA系统的整体技术体系来进行说明。在具体的项目中，SOA系统构建没有完全统一的模式，系统的体系架构需要根据用户现状进行分析设计。但在层次和内容上，SOA系统存在一些共性的特征。通常而言，SOA系统的技术体系包含如下几个层次及内容，如图1-2所示。SOA系统基本技术体系1) 基础设施层既包括服务器、网络

19、设备等硬件设施，也包括操作系统、数据库系统等基础软件，作为整个SOA系统运行的基础平台。2) 已有资源层指用户当前所拥有的IT资源。“已有应用系统资源”和“已有信息或数据资源”是指用户当前运行的应用系统及数据系统中，若干适合抽取出来作为为上层系统提供服务支持的资源。被抽取出来的资源可以是某个系统（指应用系统或数据系统）中的某个模块，可以是某个系统，可以是若干系统的合并及组合，也可以是各类格式的数据资源；“已有的组件/构件资源”即包括原先采用组件/构件系统的用户所拥有的组件/构件资源，例如基于COM/COM+、JavaBean/EJB或者是CORBA开发的技术功能组件或业务功能组件，也包括已有的

20、Web Services服务组件。“基础设施层”与“已有资源层”是服务的具体技术实现层，上层应用使用的服务最终都由这两层提供。3) 服务提供层本层主要职责是封装下面两层的资源，并以服务的形式展现出来，从而构建整体的应用系统。这是SOA系统最关键的一层，也是SOA系统设计最难的部分，难点在于服务的规划与设计该如何划分服务及服务的粒度。服务的规划与设计不仅直接影响到SOA系统的性能，也间接影响到SOA系统的扩展能力。但这不仅仅是技术问题，需要从企业战略目标的层次上考虑服务的划分，业务人员的参与也是设计出适合企业使用的服务的关键。具体方法和原则可参见本书第一篇第3章3.2节的相关内容。本层主要由三部

21、分组成服务、企业服务总线（ESB）、服务资源库，各部分内容说明如下：n 服务主要是与业务需求对齐的各类“业务服务”（与用户业务相关的、实现特定业务功能）、“流程服务”（与用户实际业务流程相关、包含人员与IT系统参与的一个处理过程）、“信息服务”（用于共享的各类数据和信息）、“交互服务”（为最终用户、其他IT系统或服务提供多渠道统一访问入口的服务）以及“其他服务”（包括实现安全规则、管理机制、质量策略等各类构建用户IT系统所需的服务）。n 企业服务总线（ESB）为服务之间间接和动态交互提供支持。ESB具体的功能包括：消息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位具体的服

22、务）、消息验证（检验服务发送的消息是否满足格式要求）、消息格式转换（把消息从一种格式转成另外一种格式）、消息操作（包括增加或删除字符，或把消息中的特定字符进行转换的操作）等。ESB包含了传统消息中间件的“消息代理”（MessageBroker）功能，但其增强了服务的动态路由和交换功能。通过把服务接入ESB，由ESB负责服务消息的流通，用户就可以把注意力全部集中在服务的构建上。此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接交换就变成了现在的间接交换，实现了松耦合。n 服务资源库服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。已注册的服务可以分成两大类，一类是

23、可以直接被使用的、实现具体功能的服务，另一类是在运行时才进行组装的服务。服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面作出的规定等。4) 应用接入层用户在这一层里可以部署各种应用，例如图1-2中所示的在政府、金融、电信等行业的应用。应用依据业务流程，主要由业务人员设计，IT技术人员辅助。应用依靠下层提供的服务及服务的组合具体实现。5) 标准体系标准体系贯穿SOA系统从最底层到最上层全部四层结构，内容上由若干行业内公认的标准组成，是每层系统规划设计时建议采用的规范，为SOA系统的标准化实施确定了边界，同时便于实现SOA系统间的互操作。6) 开发平台及各类

24、工具集用于对SOA系统进行规划设计、实施测试、运维管理的软件平台及工具集，涵盖系统各个层次。从系统生命周期角度出发，可划分为如下平台及工具：n 规划平台及工具主要用于做出整个系统的分析与规划，需要进行的工作包括项目管理、需求分析、版本控制以及文档管理等。n 设计平台及工具协助相关人员完成整个系统的设计工作。具体的平台及工具应该包括“业务建模”（模型化企业的业务）、“流程建模”（把业务整理成流程）、“服务组装”（按照一定规则组装流程形成服务或应用）、“服务建模”（模型化整理出来的服务用于服务生成）。这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别，体现的是SOA的思想。n 开发平台

25、及工具用于实施SOA系统的开发，所采用的开发语言及开发平台没有限制。n 测试平台及工具用于实施SOA系统的测试。传统的测试平台及测试工具在SOA系统的测试工作中同样可以采用。n 注册部署平台及工具用于实施服务的注册发布以及SOA系统的部署。n 监控管理平台及工具用于SOA系统整个生命周期的监控及管理。这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段SOA系统的实施进展，便于用户及早对意外情况做出反应。以上是通用的SOA系统技术体系，可用于指导SOA项目的实施。各厂商在实际项目实施中可根据用户需求及产品选型情况，在此技术体系基础上提供个性化的解决方案。4.2 SOA标

26、准体系SOA标准体系是指SOA领域内多种类、多层次的SOA标准所组成的相互联系的有机整体。这套体系对统一用户与企业对SOA的理解，加快SOA项目实施的规范化，以及增强SOA系统间的互操作能力等方面具有重要意义。目前国际上尚未有被广泛认可与接受的SOA标准体系。一些国际标准协会组织（如W3C、OASIS、OMG、WS-I等）及国际主流企业发布了若干用于构建SOA系统的规范及标准（常见的是基于Web Services技术的一系列WS-*规范及标准），但这些规范及标准仅在各个标准化协会或企业内形成初步的体系，而且不同组织发布的规范及标准间存在重复甚至冲突的现象，因此，国际上统一的SOA标准体系短时间

27、内还不能成型。为让用户了解目前国际上各类规范及标准的研制与使用情况，使用户在做系统开发决策时有一定参考依据，同时抱着建设适合国内用户使用的SOA标准体系的目标，ISOL梳理了各个国际标准协会组织及国际主流企业发布的主流规范及标准，整理出84项关于SOA与Web Services的规范及标准，经过体系化分析，划分出14个标准域（见图1-3），形成当前主流SOA与Web Services规范及标准的全集，最终形成国际SOA标准体系研究报告的白皮书SOA标准体系V1.0（已发布在“中国SOA标准服务网”www.soa-上，详细论述可参阅该文档）。SOA及Web Services规范及标准域目前，我国

28、正在基于国内产业和用户需求，建立我国的SOA国家和行业标准体系，此工作已于2007年开始，目前已初步规划出我国SOA国家标准体系，如图1-4所示。此标准体系会在我国标准化专业机构、软件产业界、学术界以及用户的共同合作下进行细化及具体研制。中国SOA标准体系全景图我国SOA标准体系工作将围绕4个层次标准的研制工作展开：n SOA基础标准是支撑SOA系统实现的通用性基础标准，包括SOA术语、SOA总体技术要求、SOA标准化指南以及SOA集成开发标准，这一层次的标准将为SOA系统或产品的基本功能、性能作出限定，并为用户和软件厂商提供使用指导。n SOA支撑技术标准是SOA系统相关的基础技术标准，在图

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

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

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

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

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

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

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

36、企业的原有系统已经较庞大而复杂，面临新的业务需求，原有系统已远远不能满足这些新的业务需求。现有IT系统的相对刚性使很多CIO在面对频繁的业务变化时步履维艰、痛苦不堪。从技术层面来说，许多软件系统基本采用手工编码的方式，总体架构设计的缺乏注定无法全面适应系统需求变更的需要。因此许多单位在建设新的系统时，以柔性化敏捷化的业务应用系统为目标，希望能持续地支撑业务应用的变化及发展。SOA在基础架构上基于业务服务、标准化、平台无关的特性，使其成为这些新系统构建的首选。需要指出的是，上述两种需求来源均不是孤立的，在各行业的项目建设中，系统整合往往与新系统建设相互融合，但各项目所解决的问题会对整合或新系统的

37、建设各有偏重。5.2 服务生命周期(以服务为中心的实施过程) SOA既是对IT规划设计和基础设施方面的重大改革，也是应用开发和业务部门应用上的极大改进。SOA项目的实施不仅涉及IT部门，而且涉及企业从上到下、从业务到IT的全面参与。在项目实施的过程中，必须首先由企业或组织的最高层做出决策，对IT系统及各项目实施路线做出整体规划，然后由相关业务部门与IT部门深度合作并分步实施，逐步取得SOA项目的成功，并最终给企业带来效益。5.2.1 实施过程关系图SOA项目实施过程关系图如图3-1所示。SOA项目实施过程关系图整体而言，企业的IT系统建设是逐步进行的，对于一个具体的SOA项目，其实施过程总体上

38、由3个过程组成：1规划过程规划过程的目的是基于企业或组织的业务发展需求，确定信息IT系统建设的总体规划，并明确即将启动的具体SOA项目的范围及目标。此过程分为两个阶段：业务与IT规划阶段、需求规划阶段。具体各阶段说明见后续章节相关内容。2实施过程实施过程是SOA项目建设的执行阶段，此阶段需要用户的项目团队与指定的软件公司实施团队共同合作推进，在实施阶段应注意及时沟通，避免不必要的风险。如图3-1所示，SOA实施过程为一个持续更迭的阶段，包括：服务规划及设计、服务开发及测试、服务部署、服务注册发布、服务运维及监控5个阶段。具体各阶段说明见后续章节相关内容。3治理过程治理是贯穿规划过程和实施过程的

39、策略和工作指南，其过程在SOA项目中比在普通IT项目中更为重要。在SOA中，业务人、IT人员、服务使用者和服务提供者均处于不同环境中，由不同的部门开发和管理，无论从项目全过程中角度，还是服务全生命周期角度，均需要进行大量的协调工作，并且所有的协调工作必须基于统一的管理策略、原则和机制来实现。关于上述内容在后续章节中有详细阐释。5.2.2 业务与IT规划业务规划和IT规划的目标是面向用户的高层决策者、CIO和业务主管，在帮助其理解SOA的商业价值的基础上，对于组织采纳SOA来进行信息化建设的方向、目标、行动、任务、原则、策略、资源等进行综合分析，最终就是否采用SOA来进行信息化建设做出宏观决策，

40、并建立SOA总体规划蓝图，其关系图如图3-2所示。业务与IT规划关系图一方面，企事业单位或组织的决策部门和业务部门需要进行业务规划，通过对企业愿景、内外部环境、资源约束、风险等方面的梳理和分析，确定企业的业务策略及需要解决的业务问题；另一方面，在业务规划的驱动下，IT部门的CIO以及团队需要从信息化的角度，对当前组织已有IT系统的功能、性能、问题、基础架构、平台、标准以及需要满足的需求等各方面进行评估和规划，确定IT整体的建设策略、建设路线以及组织结构。在业务和IT规划过程中，在如下方面需要双方依次进行研究和磋商：1是否要采纳SOAn 业务当前问题和需求是什么，现阶段是否有必要、有条件在信息化

41、建设中采纳SOA？n 采纳SOA，到底可以解决什么关键问题？此处可参考本指南中的SOA效益及适用场景内容。n 采纳SOA，是否具备相应的基本条件？比如：高层决策者对SOA具有全面的理解和一致的认识，具有采纳SOA所需的预算，信息化建设水平较高，具有较高素质的信息化专业队伍等。2采纳何种SOA策略n 到底应该在什么层次、什么级别上采纳SOA？n 是在战略级别上还是战术级别上？是全面铺开还是局部试点？n 具体而言什么业务单元需要SOA？如何排定需求优先级？把哪个作为切入点和突破口？3需要如何投入资源n 采纳SOA需要哪些资源投入？n 现有的资源条件是否满足要求？n 采纳SOA需要哪些政策、制度、指

42、南、标准方面的配套？n 在此过程中，两方面人员在规划过程中经过反复沟通和协商并达成一致后，最后决策出是否采纳SOA以及总体采纳思路。5.2.3 需求规划需求规划阶段工作是：通过对业务及IT的目标进行综合分析，确定当前所要实施的SOA项目目标以及项目实施方案。SOA项目目标包括成果性目标和约束性目标两大类，主要是需要在一定的成本及时间限度内完成项目的建设内容并达到预期目标，包括SOA系统、子系统的功能、非功能和用户界面描述等。SOA项目实施方案主要包括项目的实施范围、进度规划、质量控制方法、成本预算、团队计划、风险管理计划、技术规划和产品选型方案等。在IT系统规划中需要考虑系统的规模，建议第一个

43、SOA项目要限定项目大小，不要选择太大，保证在一定时间内可以顺利实施完毕，确保项目的成功并使业务人员体会到SOA的特点和价值。通过项目经验的积累，为后续SOA项目开创一个良好的局面和环境。SOA本身特点支持项目的递进式实现，可以采用不断滚动改进的方式实施项目。同时需要强调的是，在SOA项目实施方案中需要特别考虑标准问题。SOA项目所涉及的标准包含两方面：业务标准和技术标准。确定和采纳合适的标准体系，将有利于保证IT系统的建设质量，同时提升其持续利用与扩展能力。项目具体的实施包括两方面内容：一方面要建设基础设施，另一方面围绕服务采用不断迭代的方式进行业务功能实现。由于SOA项目建设核心是“服务”

44、，所以本书后续的阶段重点围绕第二方面进行介绍。 5.2.4 服务规划及设计服务规划及设计阶段的工作是：进行业务的分析和梳理，使业务流程能够映射到IT流程，并进行服务建模，以确定所需要的服务集和服务实现策略。在业务分析层面，目的是对业务及业务流程进行清晰的建模，此阶段具体实施中可依据一些国内外知名的业务分析方法论来完成。在IT层面，需要用服务建模方法来指导如何将业务模型转化为实现 SOA 所需要的模型，通过发现和定义与业务对齐的“服务”，使“服务”成为业务与IT之间的桥梁，从而让IT与业务能更好地互动。此过程中，需要用户的业务人员参与进来，共同完成业务服务定义、业务流程定义、业务数据分析和组织架

45、构确定等内容。对于相应的服务及流程，需要基于实际情况确定是利用已有IT系统进行服务化封装实现还是重新开发新的服务来实现。同时，用户方还需要与专业实施团队共同确定总体技术架构及所采用的技术、标准、工具和产品。主要规划和设计的内容如下：n 组织结构、业务布局分析。n 相关业务部门功能及需求分析，业务流程分析以及业务建模。n 服务规划，根据业务分析和建模结果，分析识别所需的服务，对服务的层级进行合理划分，对服务的分类和聚合进行设计。识别和规划服务过程中，基本原则是要确保基于标准的服务可以被重新组合和利用并成功地用于典型行业应用环境中的各种系统中。n 服务定义和描述，包含具体的服务名称、服务的操作、输

46、入消息、输出消息，业务目标、业务规则、业务事件，非功能性需求等服务的定义，服务之间关系的描述，服务之间的依赖关系和包含关系。n 服务实现策略，确定如何实现所需的服务，可以自行开发、外部采购或者集成遗留IT资源。5.2.5 服务开发及测试SOA项目中的服务开发即服务实现，其与传统IT项目开发有较大差别。“服务”是SOA项目开发阶段的核心概念，包括单个功能的服务，也包括流程类的服务。服务开发是将业务服务的定义进行真正的技术实现。在传统项目中几乎所有的代码都需要编写实现，而在SOA实现中，可以选择自行开发和手工编码，也可以调用或购买已有的内外部服务，实现过程更多采用参数配置、组装、流程定义等技术，代

47、码编程工作量会减少。在服务具体的技术定义、开发和组装中，用户可以基于现有基础设施情况以及服务设计阶段的业务服务定义，选择采用Web Service、SCA/SDO技术或其他传统技术逐步实现单业务功能服务、组合类服务或流程类服务。服务测试是保证服务开发正确有效的手段，与服务开发交叉进行。服务测试包括对单个服务的单元测试，也包括对于组装类服务或服务流程的集成测试。服务测试工作主要是基于服务定义和描述中的功能和性能指标，采用一定的测试工具、技术和标准规范，对服务进行质量测试和评估，并根据测试的结果来决定服务的开发是否合格。在SOA项目中，服务的测试与传统的测试也不同，为保证服务能与其他服务互联互通，

48、对服务的标准符合性测试及互操作性测试更为重要。5.2.6 服务部署此阶段是根据SOA项目目标、通过部署工具将所开发的各类服务及流程部署至用户的物理环境内，比如用户的应用服务器、流程服务器、门户服务器等。对于单个服务，部署后的服务可以被终端用户、其他IT系统或服务实际调用；对于多个基于服务的流程，部署后可形成完整应用系统，从而为用户业务提供相应的IT支持。服务部署包括静态和动态两种。静态部署是指服务之间的调用关系在运行前已确定，动态部署是指在应用系统运行中需要通过动态路由后确定服务调用关系。这两种部署类型需要在一定的基础设施基础之上进行。由于用户物理环境往往是基于网络的分布式环境，具体部署的类型

49、需要根据SOA项目实施的状况和需求来定。5.2.7 服务发布此阶段需要将已开发完成的服务发布在服务注册中心（或服务资源库）内，以便被其他服务发现和调用。服务发布也被称为服务注册，两者含义相同，均指将已有的服务描述信息提交至公共的服务注册中心（或服务资源库）中。服务注册中心（或服务资源库）是各类服务的统一登录目录，其功能分为两个方面：一方面，每个服务提供者可以发布其所提供的服务描述信息，供其他服务访问；另一方面，服务请求者可以迅速查找其所需的服务，以充分利用已有的服务来实现其IT系统构建目标。服务注册中心（或服务资源库）可以在单个企业或组织内部使用，可以供多个合作伙伴共享，也可以在整个行业内部或

50、特定区域内部共享；此外，服务注册中心（或服务资源库）与服务本身的运行节点之间可以是联机方式，也可以是脱机方式。具体的范围和方式根据用户的IT规划目标和策略来确定。需特别说明的是，服务的发布不一定在服务开发部署完成之后才进行，部分SOA项目实施过程中，服务在设计阶段被定义出来之后就可以发布在服务注册中心（或服务资源库）中，但此时的服务仅供其他服务在设计中参考，而不能被实际调用，在后续实际开发部署完成之后，服务的状态应改为真正的发布。这样做的原因是可以减少服务设计中的重复，减少后续一些不必要的开发成本，但需要配合相应服务治理策略和工具来保证对它的有效访问。5.2.8 服务运维及监控此阶段的运维监控

51、分为两个方面，包括用户方的业务人员对业务流程运行状况和绩效的监控，也包括系统维护人员从IT层面对基于系统服务的管理和部署模型、对SOA系统运行状态以及服务调用状态进行整体管理、控制和监测，从而保障SOA系统稳定可靠的运行。用户可将此过程的服务运维及监控结果与规划阶段的仿真情况进行对比，并对业务流程及服务进行功能和性能优化。如果用户的业务需求发生变化时，用户的业务人员可在系统维护人员的协助下，对SOA系统的各类服务（包括流程服务）进行可视化调整。如果变化程度较大，原有服务及流程无法满足时，则需要重新开发新的服务，并重复整个实施过程。但此过程主要涉及的工作量是新的服务或流程，因此并不影响原有的系统

52、运行。5.2.9 治理过程SOA治理是基于传统IT治理（IT Governance）的基础之上，针对SOA所特有的服务生命周期定制的SOA治理管制。它通过制定人员和角色、管理流程及决策，帮助企业管理整个SOA的生命周期。SOA治理需要采纳相应的方法论和最佳实践，通常需要有工具辅助企业最后定制并管治符合企业自身需要的治理决策。对于用户而言，要实现SOA的效益，开展SOA治理非常关键。治理不同于管理。治理规划需要制定什么决策，而管理是制定和实施决策的过程。治理重在建立决策，而管理重在贯彻执行决策。SOA治理强调更多的是政策、方法和策略问题，而不是技术或业务问题。治理贯穿规划和实施全过程，涉及的不仅

53、仅是一个项目，而是更多的是从IT全局来看，横跨多个应用系统、各类流程、信息及人力资源。因此需要用户高层的重视。SOA治理主要包括如下内容：n 高层的领导决策者指导组织建立满足其目标的策略，包括确定谁负责制定决策、需要制定什么决策以及使决策制定保持一致的决策。 n 建立SOA的组织机制以及授权机制，同时保证项目实施各阶段按预定目标推进的有效控制机制。n 建立沟通计划、流程或协议，保证各相关方都对服务获得一致信息。比如，必须在服务提供者和服务使用者之间建立一个协议，告知使用者可以希望得到什么功能、提供者应该提供什么功能。n 涉及服务全生命周期，包括指导可重用资产的开发，确立如何设计和开发服务，服务

54、的版本和质量管理，以及这些服务如何随时间增长进行更改。n 建立评估SOA项目成熟度以及各项性能测试的评估方法，并在SOA项目实施过程中进行监控和调整。5.3 SOA项目阶段实施过程的关键点SOA项目如同其他IT项目一样，也有类似的实施过程，一个可能的实施过程如下图所示：从表面的几个过程看SOA项目的实施没有什么特别的地方，能够体现SOA特点的是在项目实施过程中的每一个具体环节中，如规划阶段对标准的考虑，分析阶段对业务的详细描述和定义，设计阶段技术架构(包括逻辑架构和物理架构)的定义，实现阶段更多依赖于定义而不是编码，以及运维阶段对服务运行情况的重点关注。下面介绍实施过程中的主要关键点。5.3.

55、1 规划阶段在这一阶段有许多重要的事情需要做，这将决定SOA项目实施的成败。首先是需要确定目标，对于系统的功能目标应该是明确的，除此之外我们需要重点关注的是为什么要采用SOA思想，是为了达到什么目的。在这时我们需要了解SOA能够给我们带来什么，我们希望得到什么，这两者是否匹配;也需要了解SOA适合什么，不适合什么，我们建设项目与SOA适合是否适配。如果这些匹配一致我们就可以放心进行下一步骤了，否则就得考虑是否一定要采用SOA，是否采用其他的思想和技术架构也足以解决问题。在此我们再看一下SOA特点：强调业务服务的复用支持业务灵活重构强调松耦合强调标准的采用我们也需要了解SOA不适合的地方：开发简

56、单单个应用时，不要使用SOA构建高吞吐量应用或实时应用是，不要使用SOA如果网络速度慢，网络不可靠时，不要使用SOA当服务接口不确定时(即业务服务功能本身不稳定时)，不要使用SOA当安全性极为重要时，暂时不要考虑SOA业务处理有严格的事务完整性要求时，建议暂时不用SOA其次需要考虑系统的规模，建议第一个SOA项目不要选择太大，需要限定项目的大小，保证在不长的时间内可以顺利实施完毕，确保项目的成功。通过项目经验的积累，为后续SOA项目开创一个良好的局面和环境。SOA本身特点支持项目的递进式实现，可以采用不断滚动改进的方式实施项目。接着是考虑标准问题，这里的标准包含两方面：业务标准和技术标准。标准

57、的确定是过程中一直需要考虑的问题，在分析和设计阶段都需要对标准加以考虑，并最终确定项目需要采用和制定的标准。业务标准可以规范服务、流程和数据;技术标准可以帮助确定技术架构，确定采用的技术，可以确保服务/组件的复用、组装和运行维护。最后是组建团队，要实施好SOA项目，需要确保合理的团队成员。首先领导的参与是项目成功的保证，SOA项目一般会涉及多个部门，或企业之间的协作，没有领导的参与和重视，这类项目成功的可能性会非常的低。业务人员参与也是一个重要因素，SOA中强调的服务是业务的服务，而不是技术实现的服务。业务服务的定义、分类，业务流程的确定，业务数据的分析等，如果没有业务人员参与，这些工作基本上

58、是无法开展的。在现阶段让业务人员直接参与设计和实现还不是特别的现实，但随着SOA技术和产品的成熟，业务人员一直参与到设计，甚至实现阶段也是可能的，只有这样才能更好保证SOA项目实施的成功，才能更好体现SOA的价值。5.3.2 分析阶段分析阶段主要进行业务的分析和梳理，包括：业务服务定义，业务流程定义、业务数据分析和组织架构。在这一阶段需要确定SOA项目中需要实现哪些业务，业务如何复用，业务如何串接在一起完成一个工作流程，在执行业务和业务流程过程中需要使用哪些数据，以及这些数据的关系。业务定义时需要考虑下列因素谁拥有业务服务谁需要使用业务服务，如何进行授权管理业务的基本标识信息业务服务的功能描述

59、业务服务的使用约束条件业务服务使用到的数据信息业务服务的质量特性，如可靠性、安全性和事务性等业务服务的服务等级信息，如服务响应时间，可提供服务时间，是否收费等业务服务的生命周期业务服务运行时需要关注的信息组织架构分析时需要考虑下列因素实际的组织架构组织架构中有哪些角色角色管理和使用服务、流程和数据的权限。可以使用一个表格进行描述和定义接着需要结合组织架构和服务，定义业务流程，确定一个业务流程中有哪些服务，这些服务由哪个部门/角色来使用，这可以通过一个图形描述方式来加以定义。同时需要定义业务的流程过程，业务规则等内容。5.3.3 设计阶段设计阶段实际上就进入了技术范畴了，在设计阶段首先需要确定采

60、用的技术体系架构，准备采用的具体技术、工具和产品，准备采用和需要制定的技术标准，也需要定义SOA项目的物理环境，以及逻辑架构到物理环境之间的映射，最后需要细化整个项目的设计细节。在确定技术体系架构时，可以参考长风联盟SOA-RA-TF工作组制定的“SOA的参考架构规范”。在确定技术架构时需要考虑下列因素服务描述如何存储，如何使用服务如何实现，是将已有业务系统进行服务化封装，还是重新实现，或者将若干服务进行组装形成新的服务定义的服务如何使用，如何组装成新的服务或在一个业务流程中应用服务之间通讯如何实现，使用什么通讯协议，是否需要可靠，是否关注效率在整个项目中需要考虑哪些安全因素如何获取服务运行信

61、息，如何应用服务运行信息在设计阶段需要确定采用的具体技术。在实现SOA项目时可以采用传统技术，也可以采用Web Services技术，具体如何采用需要进行综合考虑。SOA中的服务与Web Services并不用划等号，采用Web Services一般更多是从标准化角度进行考虑，为了实现异构系统互联，并且更多应用于多部门系统之间，或企业系统之间的互联互通。实现SOA也可以采用已有成熟技术，如通过JMS实现消息通讯，可以保证效率和传输可靠性。实现技术第二个方面是考虑业务流程实现是否需要使用BPM系统，还是通过服务组装技术，将若干服务通过编码方式进行组合应用。BPM方式一般应用于实时性要求不高的业务

62、流程处理;而对于需要连续加以运行处理的业务过程，则可以通过服务组装方式加以实现。实现技术第三个方面需要考虑服务如何实现，是利用已有IT系统，通过服务化封装实现，还是重新实现。对已有系统进行服务化封装时不一定要封装成Web serivces，服务描述一般是统一的，具体实现可以是Web Serivces，或EJB，或BPEL，或一般的JAVA或C/C+程序。在设计阶段需要实现逻辑架构与物理架构之间的映射。在总体体系架构设计时一般更多的从逻辑角度进行考虑，需要将业务转化为IT技术架构。同时也需要进行物理架构的规划，同时确定逻辑架构到物理架构的映射。物理架构需要考虑整个系统中有多少独立的运行节点，有多

63、少已有的业务系统以及需要建立的新的业务系统，需要考虑这些已有或新的业务系统都在哪些节点上运行。其次需要考虑业务系统之间如何进行通讯，以及业务系统之间的通讯转换到节点之间的通讯。在业务流程实现时需要考虑是否需要BPM系统，需要多少个。一般一个BPM系统有一个独立的服务器引擎，在服务器引擎上可以运行多个业务流程。在现有技术条件下，一般一个业务流程的执行都在一个服务器引擎上运行，如果需要跨多个服务器引擎，则需将某一流程定义为一个子流程，同时封装为一个服务，供另一个业务流程使用。在物理架构中需要考虑是否有一个独立的服务注册中心，需要确定服务注册中心与运行节点之间是联机的还是脱机的。在设计阶段最主要的工作是进行系统设计的细化工作。在细化工作中包括：服务定义的细化，包括服务接口、质量属性、服务等级等信息，另外的部署信息可以在实现和部署阶段加以定义。服务的细分和组装，在设计阶段需要确定哪些是原子服务(不可拆分)，哪些服务是组装服务，哪些是流程服务。同时需要定义服务的实现方式(原有系统封装，重新实现，服务组织，服务流程)定义业务流程，通过工具详细定义业务流程，包括异常处理。定义服务应