SOA项目设计文档.doc

SOA项目设计文档

目 录

1 SOA概念 3
1.1 与传统的建设方法不同 4
1.2 与传统的建设过程不同 4
2 SOA特点 5
2.1 以业务为中心 5
2.2 灵活适应变化 5
2.3 重用IT资源，提高开发效率 5
2.4 更强调标准 5
3 SOA效益及合用场景 6
3.1 SOA效益 6
3.2 SOA合用场景 7
4 SOA技术概述 8
4.1 SOA技术体系 8
4.2 SOA标准体系 12
4.3 面向服务方法与传统方法的区别 14
5 SOA 项目实行简介 15
5.1 SOA项目需求来源 15
5.2 服务生命周期(以服务为中心的实行过程) 16
5.2.1 实行过程关系图 16
5.2.2 业务与IT规划 18
5.2.3 需求规划 19
5.2.4 服务规划及设计 20
5.2.5 服务开发及测试 20
5.2.6 服务部署 21
5.2.7 服务发布 21
5.2.8 服务运维及监控 22
5.2.9 治理过程 22
5.3 SOA项目阶段实行过程的关键点 23
5.3.1 规划阶段 23
5.3.2 分析阶段 25
5.3.3 设计阶段 26
5.3.4 实现、调试和部署阶段 27
5.3.5 运维阶段 28
5.4 SOA项目实行要素 29
5.4.1 用户原有IT资源 29
5.4.2 SOA项目实行组织 29
5.4.3 SOA项目实行支撑平台 30
5.4.4 SOA项目实行指导文档体系 30
5.4.5 用户信息化规定 30
5.5 用户在实行过程中的职责 30
5.6 产品选型建议 32
5.7 SOA项目实行与传统项目实行的比较 33

1 SOA概念
随着我国各行业信息化建设的不断进一步，企事业单位和政府部门逐步建立起的大批计算机信息系统和各类数据信息因缺少有效衔接，导致信息资源共享难、“信息孤岛”现象普遍存在。与此同时，对于企事业单位，随着经济全球化大环境下的市场竞争日益剧烈，公司正在通过加快管理转型、技术创新、新产品研发以及业务策略调整等方式来提高自己的核心竞争力、连续占有并扩大市场份额。对于各级政府部门，在以“大部制”为核心的政府行政管理体制改革的驱动下，以“管理”导向的政府职能正在向“服务”导向转变。
企事业单位和政府部门的这些转型方式及过程的有效实行，一方面更需要信息技术和信息化的手段来支撑，另一方面，这些业务需求也对信息技术和信息化建设自身提出了更高规定：IT系统（通常也称为“信息系统”、“应用系统”或“软件系统”等）要能快速响应用户业务发展和变化的需求，新系统必须能在充足运用用户原有IT资源基础上快速构建出来，同时要实现跨平台、跨组织的数据共享和业务协同。
SOA（Service Oriented Architecture，面向服务的体系架构）是近年来软件规划和构建的一种新方法，其概念最早由国际征询机构Gartner公司于1996年初次提出。由于其自身特性非常符合上述信息化需求和问题的解决思绪，因此在2023年以后成为我国软件产业界和各行业用户的关注焦点，并在2023年逐步开始在多个行业信息化建设中被选择和应用。
SOA概念自被提出之后，不少国内外机构、公司均对SOA进行了定义和阐释，但目前尚未形成权威、统一的定义。本书作为国内首部从用户角度对SOA概念和应用进行客观介绍的书籍，在全书中将对SOA做如下定义和说明，以便于用户从应用角度对SOA有直观理解：SOA不是一种技术，而是一种IT系统和软件的构建方法和过程，贯穿IT系统规划、设计、构建、运维的各个阶段。SOA与传统的IT系统建设方法和过程有较大区别，简要说明如下：
1.1 与传统的建设方法不同
基于SOA的IT系统建设更强调基于统一标准的快速开发和灵活组合。“服务”是SOA的核心元素，它相应于某个业务流程、业务功能或数据资源，按照统一的规格来组成信息系统。基于“服务”，SOA能显著缩小用户业务需求与IT支持能力之间的鸿沟，指导IT团队开发出具有良好移植性、扩展性和兼容性的应用系统。
SOA不仅仅站在单个信息系统或集成项目的角度，而是更强调站在用户IT建设全局或行业内信息化建设全局，从而规划并逐步建成统一的IT系统架构模式，并积累可反复使用的信息系统资源库，以实现用户组织内或全行业内的信息资源共享、信息系统协同、新系统的快速构建以及系统对业务变化的快速应变能力。
1.2 与传统的建设过程不同
SOA建设过程的重点是基于“服务”的IT系统规划和设计阶段，业务人员将不仅仅是提出需求，而是进一步参与各类“服务”的规划和设计。“服务”间互相独立，所有“服务”的信息可被汇集到统一的服务资源库中，使得用户、其他系统以及其他“服务”可通过服务资源库来访问和使用。SOA系统的具体开发阶段则是由技术人员依据每个“服务”的功能和范围规定来具体实现或选择已有可用服务，并进行合成与装配。在SOA系统的运维过程中，业务人员可以自行调整相应的服务，以使IT系统能满足新的业务规则和需求。
此外，与SOA密切相关的尚有一个概念——业务流程管理（BPM，Business Process Management）。BPM来源于业务流程变革领域，如业务流程再造（BPR）、业务流程建模以及业务流程集成等。在技术方面，业务流程管理融合了许多相关技术，如流程建模、工作流技术、流程自动化以及业务流程监控等。借助BPM，通过对业务流程的监控，用户可以及时发现问题，并对业务流程进行不断创新和优化。而SOA使得这种流程变化更加便捷，从而大大提高了业务的灵活性。因此，当前SOA系统中大多都包含了BPM的功能和可供用户来开发和管理的技术平台。
近年来，随着SOA技术实现手段、特别是基于标准的互联网技术（如Web服务和XML）不断成熟，SOA发展势头迅猛。从2023年至今，SOA已经逐渐成为影响中国IT系统构建的主导方法和过程，在我国金融、电信、烟草、电子政务、医疗卫生、公司信息化、B2B、物流以及钢铁制造等行业和领域开始得到应用，关于各行业或领域的SOA应用情况，可参阅本书的第二篇相关内容。

2 SOA特点
基于SOA来构建的IT系统具有如下特点：
2.1 以业务为中心
SOA更多关注于用户业务，通过业务人员参与SOA系统的规划、设计和管理，使得IT系统能在对业务的深刻理解的基础上进行构建，实现IT系统与用户业务的密切结合。在具体实行中，通过把完毕实际业务流程中的一项任务所需的IT资源组织为服务进行封装，从而达成以业务为核心，通过业务选择技术，避免技术制约业务的问题。
2.2 灵活适应变化
IT系统围绕用户业务构建，用户业务在实现层通过表现为一系列松散耦合的“服务”来实现，这些服务可以根据用户需求随需组合，使得IT系统对于业务的适应能力明显提高。
2.3 重用IT资源，提高开发效率
SOA强调对“服务”的重用，对原有IT资源的重用度提高是SOA带来的关键效果之一，大量具有高重用的服务资源，为快速构建新的业务功能和业务系统奠定基础，使得IT系统的开发和软件生产效率得到提高。同时，重用过程有助于保护用户前期的信息化投资和IT资产积累，节省IT系统开发成本，实现用户信息化的可连续性建设与发展。
2.4 更强调标准
SOA的实现强调基于统一的标准，SOA系统建立在大量的开放标准和协议之上，以实现系统及信息的互联互通和互操作。因此，SOA系统从规划到实行，标准都至关重要。

3 SOA效益及合用场景
3.1 SOA效益
SOA效益重要体现在如下几个方面：
1) 提高业务效率和用户满意度
目前，我国企事业单位及政府部门都在强调“服务”能力，各类组织对如何提高服务水平并使IT系统快速响应新业务需求的规定，已经超过了对于IT系统开发效率的规定。依托“服务”的松耦合性和重用性，通过现有“服务”和IT资产的组装，SOA减少了新业务应用开发的时间，提高了产品和服务的上市速度和开发效率，使得SOA系统中的“服务”和IT资产以更灵活的配置适应新的需求变化，提高了业务效率。
SOA通过创建与具体技术和最终用户设备无关的服务，应用于各种用户服务渠道，以保证一致的用户体验，提高用户的满意度。
2) 有助于整合IT资源，提高IT系统的对外协作能力
不少行业的企事业单位实行了很多应用系统，比如金融、电信行业以及一些集团公司，如何在不同省市的子公司、分公司和多元化下属单位整合原有系统和信息资源，都是目前面临的重要系统建设需求。
SOA不仅仅是技术层面，同时提供了系统集成开发的重要方法及策略。SOA提倡遵循开放标准，并独立于厂商多样性的环境，为基于互联网的组织内和组织间的系统通信协作和资源共享提供了良好的互操作性和可用性。
3) 提高投资回报率
采用SOA的公司、机关部门，将基于服务规则和规定，构建下层IT架构，具有技术中立的特性，减少了对厂商的依赖和转换成本；另一方面，SOA系统以“服务”为中心，梳理和重组业务流程，使各个业务系统可以互联互通和资源共享，这种服务的松耦合及平台中立为机构减少了集成成本，松耦合和模块化简化了维护工作，减少了维护成本；因此，总体而言，SOA可以保护原有IT投资，提高现有IT资产的投资回报率。
单个公司或单位的力量是有限的，只有某个行业内或供应链上的多家公司和单位联合，共享“服务”资源，才干推动SOA的开发模式进程，收到良好效益。在推动SOA的同时，相应的标准化工作必须先行，用统一标准指导各家的服务开发、接口定义、通用数据格式定义、资源存储、服务注册与查询等SOA实践工作。
3.2 SOA合用场景
上述章节提到了SOA的特点以及能带来的效益，但是，SOA并不是在所有的情况和场景下都合用，只有在适宜SOA特性的场景下，并采用合适的实行策略来保障，才有也许逐步得到SOA带来的各项效益。
从SOA特点来看，SOA在一些场景中能发挥其作用和优势，如：
n 企事业单位或者政府部门内部IT系统的整合
由于业务重组、并购或者内部机制调整，而需要实现组织内的统一管理、协作和信息共享。
需要对多个异构的IT系统进行整合，提高组织的整体决策、监控能力或业务流程效率。
n 企事业单位和政府部门之间IT资源的共享和协同
为了在业务和市场上合作，需要依赖业务合作伙伴提供其IT系统的非核心业务功能或信息。
某项服务能力，需要多个组织和单位的IT系统需要共享信息，并联合解决，比如电子政务中的“一站式审批”服务、各级政务资源共享互换平台等。
n 从头开始开发的新应用系统
SOA将是未来IT新系统构建的主导方法，因此考虑到未来的扩展和重用能力，用户在业务允许的条件范围内、可选择基于SOA来构建新应用系统。
n 基于互联网的一些新的应用模式
基于互联网的软件服务化平台，如SaaS等模式。
在信息化建设中，除自己的IT系统之外，也同时希望集成互联网上的一些软件工具或Web服务的企事业单位，如采用“软件+服务”策略的单位。

但是，也有一些应用场景不适合用SOA来实现，此时采用传统的技术、方法和过程来实行更为妥当，比如下述一些场景：
n 用户业务涉及效率敏感及实时性规定较高的系统，如工业控制、核心交易系统。
n 事务及安全性规定较高的业务系统。
n 用户的业务系统没有集成的需求。
n 当前的IT系统基于统一的平台和编程方法。
对于大多数企事业单位和政府部门来说，假如采纳了SOA，还需要注意如下事项：
n 考虑SOA产品选型，重视业务流程的管理，使SOA成为其全面业务转型的实现手段。
n 企事业单位和政府部门在进行业务规划时，应基于自身实际，不要盲从。
n 采用SOA要从全局慎重规划，以循序渐进、逐步推动为宜。
具体的规划和实行建议，可参见本书后续章节的相关内容。

4 SOA技术概述
4.1 SOA技术体系
从技术层面来看，SOA并不是一项技术创新，传统的技术在构建SOA系统时同样能派上用场。事实上，在采用SOA进行系统整合的项目中很多被整合的系统自身就是基于传统技术开发的，但与传统构建系统的方法比较，SOA更强调标准化应用，更加重视系统的层次架构。SOA特性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要在开发过程中遵循SOA的理念，采用统一的标准，任何现有技术都能用来开发SOA系统。
SOA与传统技术体系的区别在于系统均是基于“服务”构造，“服务”之间的交互和组合采用了一种基于“服务中介平台”的方式实现了松耦合，图1-1是“服务”被提供和使用过程的示意图。

SOA系统中服务交互示意图
在图1-1中，服务提供者是一个可以通过网络寻址到的实体，它提供的“服务”是基于IT系统的某个功能或流程；服务请求者调用和使用服务提供者提供的“服务”；服务中介平台类似代理的角色，以目录方式存储了大量“服务”资源，一方面可以接受服务提供者提供的各类“服务”信息，另一方面可以通过协调机制把“服务”的请求分派给服务提供者。这样为服务请求者和服务提供者建立了中立的沟通渠道。
上述对服务交互图的描述是为了解释SOA的核心元素“服务”的运营机制。便于对技术有爱好的用户IT人员了解。下述内容将围绕SOA系统的整体技术体系来进行说明。
在具体的项目中，SOA系统构建没有完全统一的模式，系统的体系架构需要根据用户现状进行分析设计。但在层次和内容上，SOA系统存在一些共性的特性。通常而言，SOA系统的技术体系包含如下几个层次及内容，如图1-2所示。

SOA系统基本技术体系
1) 基础设施层
既涉及服务器、网络设备等硬件设施，也涉及操作系统、数据库系统等基础软件，作为整个SOA系统运营的基础平台。
2) 已有资源层
指用户当前所拥有的IT资源。“已有应用系统资源”和“已有信息或数据资源”是指用户当前运营的应用系统及数据系统中，若干适合抽取出来作为为上层系统提供服务支持的资源。被抽取出来的资源可以是某个系统（指应用系统或数据系统）中的某个模块，可以是某个系统，可以是若干系统的合并及组合，也可以是各类格式的数据资源；“已有的组件/构件资源”即涉及原先采用组件/构件系统的用户所拥有的组件/构件资源，例如基于COM/COM+、JavaBean/EJB或者是CORBA开发的技术功能组件或业务功能组件，也涉及已有的Web Services服务组件。“基础设施层”与“已有资源层”是服务的具体技术实现层，上层应用使用的服务最终都由这两层提供。
3) 服务提供层
本层重要职责是封装下面两层的资源，并以服务的形式展现出来，从而构建整体的应用系统。这是SOA系统最关键的一层，也是SOA系统设计最难的部分，难点在于服务的规划与设计——该如何划分服务及服务的粒度。服务的规划与设计不仅直接影响到SOA系统的性能，也间接影响到SOA系统的扩展能力。但这不仅仅是技术问题，需要从公司战略目的的层次上考虑服务的划分，业务人员的参与也是设计出适合公司使用的服务的关键。具体方法和原则可参见本书第一篇第3章3.2节的相关内容。本层重要由三部分组成——服务、公司服务总线（ESB）、服务资源库，各部分内容说明如下：
n 服务——重要是与业务需求对齐的各类“业务服务”（与用户业务相关的、实现特定业务功能）、“流程服务”（与用户实际业务流程相关、包含人员与IT系统参与的一个解决过程）、“信息服务”（用于共享的各类数据和信息）、“交互服务”（为最终用户、其他IT系统或服务提供多渠道统一访问入口的服务）以及“其他服务”（涉及实现安全规则、管理机制、质量策略等各类构建用户IT系统所需的服务）。
n 公司服务总线（ESB）——为服务之间间接和动态交互提供支持。ESB具体的功能涉及：消息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位具体的服务）、消息验证（检查服务发送的消息是否满足格式规定）、消息格式转换（把消息从一种格式转成此外一种格式）、消息操作（涉及增长或删除字符，或把消息中的特定字符进行转换的操作）等。ESB包含了传统消息中间件的“消息代理”（MessageBroker）功能，但其增强了服务的动态路由和互换功能。通过把服务接入ESB，由ESB负责服务消息的流通，用户就可以把注意力所有集中在服务的构建上。此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接互换就变成了现在的间接互换，实现了松耦合。
n 服务资源库——服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。已注册的服务可以提成两大类，一类是可以直接被使用的、实现具体功能的服务，另一类是在运营时才进行组装的服务。服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面作出的规定等。
4) 应用接入层
用户在这一层里可以部署各种应用，例如图1-2中所示的在政府、金融、电信等行业的应用。应用依据业务流程，重要由业务人员设计，IT技术人员辅助。应用依靠下层提供的服务及服务的组合具体实现。
5) 标准体系
标准体系贯穿SOA系统从最底层到最上层所有四层结构，内容上由若干行业内公认的标准组成，是每层系统规划设计时建议采用的规范，为SOA系统的标准化实行拟定了边界，同时便于实现SOA系统间的互操作。
6) 开发平台及各类工具集
用于对SOA系统进行规划设计、实行测试、运维管理的软件平台及工具集，涵盖系统各个层次。从系统生命周期角度出发，可划分为如下平台及工具：
n 规划平台及工具——重要用于做出整个系统的分析与规划，需要进行的工作涉及项目管理、需求分析、版本控制以及文档管理等。
n 设计平台及工具——协助相关人员完毕整个系统的设计工作。具体的平台及工具应当涉及“业务建模”（模型化公司的业务）、“流程建模”（把业务整理成流程）、“服务组装”（按照一定规则组装流程形成服务或应用）、“服务建模”（模型化整理出来的服务用于服务生成）。这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别，体现的是SOA的思想。
n 开发平台及工具——用于实行SOA系统的开发，所采用的开发语言及开发平台没有限制。
n 测试平台及工具——用于实行SOA系统的测试。传统的测试平台及测试工具在SOA系统的测试工作中同样可以采用。
n 注册部署平台及工具——用于实行服务的注册发布以及SOA系统的部署。
n 监控管理平台及工具——用于SOA系统整个生命周期的监控及管理。这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段SOA系统的实行进展，便于用户及早对意外情况做出反映。
以上是通用的SOA系统技术体系，可用于指导SOA项目的实行。各厂商在实际项目实行中可根据用户需求及产品选型情况，在此技术体系基础上提供个性化的解决方案。
4.2 SOA标准体系
SOA标准体系是指SOA领域内多种类、多层次的SOA标准所组成的互相联系的有机整体。这套体系对统一用户与公司对SOA的理解，加快SOA项目实行的规范化，以及增强SOA系统间的互操作能力等方面具有重要意义。
目前国际上尚未有被广泛认可与接受的SOA标准体系。一些国际标准协会组织（如W3C、OASIS、OMG、WS-I等）及国际主流公司发布了若干用于构建SOA系统的规范及标准（常见的是基于Web Services技术的一系列WS-*规范及标准），但这些规范及标准仅在各个标准化协会或公司内形成初步的体系，并且不同组织发布的规范及标准间存在反复甚至冲突的现象，因此，国际上统一的SOA标准体系短时间内还不能成型。
为让用户了解目前国际上各类规范及标准的研制与使用情况，使用户在做系统开发决策时有一定参考依据，同时抱着建设适合国内用户使用的SOA标准体系的目的，ISOL梳理了各个国际标准协会组织及国际主流公司发布的主流规范及标准，整理出84项关于SOA与Web Services的规范及标准，通过体系化分析，划分出14个标准域（见图1-3），形成当前主流SOA与Web Services规范及标准的全集，最终形成国际SOA标准体系研究报告的白皮书——《SOA标准体系V1.0》（已发布在“中国SOA标准服务网”上，具体论述可参阅该文档）。

SOA及Web Services规范及标准域
目前，我国正在基于国内产业和用户需求，建立我国的SOA国家和行业标准体系，此工作已于2023年开始，目前已初步规划出我国SOA国家标准体系，如图1-4所示。此标准体系会在我国标准化专业机构、软件产业界、学术界以及用户的共同合作下进行细化及具体研制。

中国SOA标准体系全景图

我国SOA标准体系工作将围绕4个层次标准的研制工作展开：
n SOA基础标准——是支撑SOA系统实现的通用性基础标准，涉及《SOA术语》、《SOA总体技术规定》、《SOA标准化指南》以及《SOA集成开发标准》，这一层次的标准将为SOA系统或产品的基本功能、性能作出限定，并为用户和软件厂商提供使用指导。
n SOA支撑技术标准——是SOA系统相关的基础技术标准，在图1-4所示11个标准域的若干标准中，我国将对国外已有的相关成熟技术标准（如部分WS-*标准）进行裁剪和修改，并采纳为我国相应的国家标准，部分国内有特殊需求的标准将采用自主研制的方式来制定。
n SOA测评标准——涉及两类：一类对SOA相关的产品对于SOA标准的符合性及互操作性进行评测，第二类为用户提供SOA建设成熟度评估的评测规范，涉及相关评测方法和指标。
上述标准规范将作为相应的SOA测评工具和平台的基本依据。
n SOA行业/领域标准——将根据行业或领域特性及信息化现状来研究制定适合本行业或本领域的SOA标准体系。此部分标准的研制工作将由我国各行业相关标准化委员会或行业协会来主导制定。目前所列出的几个领域为部分有代表性的行业或领域，其他行业或领域也会逐步扩展进来。

目前，中国SOA标准体系正逐步形成之中：《基于XML的Web服务描述语言》（20230146-T-339）与《基于XML的简朴对象访问协议》（20230147-T-339）两项国家标准已完毕制定并发布；《Web服务可靠消息传递》（20230478-T-469）与《Web服务互操作框架》（20230477-T-469）已开始研制；《SOA术语》、《SOA总体技术规定》、《SOA标准化指南》与《Web服务管理标准》4个标准处在国家标准公示阶段；《Web服务业务流程规范》等两个标准处在申报阶段；《金融行业SOA标准化指南》等处在计划阶段。
4.3 面向服务方法与传统方法的区别
软件开发方法历经数次变革，从结构化分析方法开始，经面向对象方法、面向构件方法，到现在的面向服务方法，这些变革都是为满足客户需求的主线改变，以适应应用领域不断增长的复杂限度而提出的。
1．结构化分析方法
结构化分析方法在20世纪70年代逐步形成，以算法为中心，按照逐层分解、逐步求精的原则，给出一组帮助系统分析人员产生功能规约的原理与技术，方法简朴、清楚，符合人们结识世界、改造世界的一般规律，从而大大减少了求解问题的复杂限度。但其对需求变更的适应能力很差，所需文档数据资料极大，也不适合用于解决复杂的大规模问题。
2．面向对象方法
面向对象方法产生于20世纪80年代，以对象（对象=数据+算法）为中心，为软件工业实现工程化提供了强有力的支持。面向对象方法具有封装性、多态性和继承性，与人类习惯的思维方法一致，加强了人们对问题域的理解，增强了适应需求变化的能力，且利于用户的参与和各类人员的交流。但其需要依赖具体的编程语言，与业务存在鸿沟；封装粒度小，耦合度高，难于实现大规模、高层次的重用。
3．面向构件方法
面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。公司业务被映射成系统构件，从整个公司的视角出发构思、设计系统，是面向对象方法更高一级的抽象，比面向对象方法更切合公司的实际应用，重用度也进一步提高。但与开发语言紧密联系，导致接口标准不统一，不同开发语言实现的系统之间很难实现互操作。
4．面向服务方法
面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。面向服务方法关注的是公司业务，它直接映射到业务，强调IT与业务的对齐，以服务为核心元素来封装公司的业务流程和公司已有应用系统。服务的粒度更大，更加匹配公司级应用中的业务，可以实现更高级别的重用。但目前存在相关标准未统一、应用案例较少等一些问题。
上述各类系统构建方法的比较如表1-1所示。

名称
概述
优点
缺陷
结构化
方法
以算法为中心，又称为结构化分析
体现了逐层分解、逐步求精的原则，有严格的规则
难于检查分析结果的对的与否；对需求变更的适应能力很差；系统设计人员对分析结果的理解存在障碍
面向
对象
方法
以对象（对象=数据＋算法）为中心，实现了对数据和算法的封装和继承
加强了相应用领域的理解，改善了沟通和交流；适应需求变化的能力较强；支持分析和设计结果的复用
纯技术导向，存在与业务的鸿沟；复杂度高，抽象限度低，难以实现大规模和高层次的重用
面向
构件
方法
以组件或构件封装可重用的功能单元
重用度进一步提高，提高了软件公司的开发效率和质量
组件或构件封装方法和接口标准不统一，很难实现与外部应用系统之间的互操作
面向
服务
方法
以服务封装业务流程和应用系统
业务驱动技术，以开放标准实现应用系统之间服务的互相访问，乃至复合应用的组装，实现了更高级别重用
处在概念导入期末尾，相关标准尚未统一，应用案例及工程实践刚起步

5 SOA 项目实行过程
5.1 SOA项目需求来源
当前SOA项目的建设，需求来源重要分为两大类：系统整合驱动和新系统建设驱动，下面分别介绍之。
1．系统整合驱动
电信、金融、政府等以服务为导向的公司或组织中，为了更好地满足客户或公众需求，必须提供一站式以及随需应变的服务能力。不仅要对公司或组织内部系统进行整合，同时要与相关的公司及组织进行信息系统协同，因此在整合及协同为重要需求推动下，基于SOA的IT系统整体架构成为选择热潮。
基于SOA的整合范围涉及3类：应用系统之间的数据整合、功能整合和流程整合。整合的方式是通过对原有数据及IT系统资源进行服务化的包装，从而使得各系统以统一的、标准化的方式进行数据共享和业务协同。
2．新系统建设驱动
随着信息化建设的进步一开展，部分公司的原有系统已经较庞大而复杂，面临新的业务需求，原有系统已远远不能满足这些新的业务需求。现有IT系统的相对刚性使很多CIO在面对频繁的业务变化时步履维艰、痛苦不堪。从技术层面来说，许多软件系统基本采用手工编码的方式，总体架构设计的缺少注定无法全面适应系统需求变更的需要。
因此许多单位在建设新的系统时，以柔性化灵敏化的业务应用系统为目的，希望能连续地支撑业务应用的变化及发展。SOA在基础架构上基于业务服务、标准化、平台无关的特性，使其成为这些新系统构建的首选。
需要指出的是，上述两种需求来源均不是孤立的，在各行业的项目建设中，系统整合往往与新系统建设互相融合，但各项目所解决的问题会对整合或新系统的建设各有偏重。

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

SOA项目实行过程关系图
整体而言，公司的IT系统建设是逐步进行的，对于一个具体的SOA项目，其实行过程总体上由3个过程组成：
1．规划过程
规划过程的目的是基于公司或组织的业务发展需求，拟定信息IT系统建设的总体规划，并明确即将启动的具体SOA项目的范围及目的。此过程分为两个阶段：业务与IT规划阶段、需求规划阶段。具体各阶段说明见后续章节相关内容。
2．实行过程
实行过程是SOA项目建设的执行阶段，此阶段需要用户的项目团队与指定的软件公司实行团队共同合作推动，在实行阶段应注意及时沟通，避免不必要的风险。如图3-1所示，SOA实行过程为一个连续更迭的阶段，涉及：服务规划及设计、服务开发及测试、服务部署、服务注册发布、服务运维及监控5个阶段。具体各阶段说明见后续章节相关内容。
3．治理过程
治理是贯穿规划过程和实行过程的策略和工作指南，其过程在SOA项目中比在普通IT项目中更为重要。在SOA中，业务人、IT人员、服务使用者和服务提供者均处在不同环境中，由不同的部门开发和管理，无论从项目全过程中角度，还是服务全生命周期角度，均需要进行大量的协调工作，并且所有的协调工作必须基于统一的管理策略、原则和机制来实现。关于上述内容在后续章节中有具体阐释。
5.2.2 业务与IT规划
业务规划和IT规划的目的是面向用户的高层决策者、CIO和业务主管，在帮助其理解SOA的商业价值的基础上，对于组织采纳SOA来进行信息化建设的方向、目的、行动、任务、原则、策略、资源等进行综合分析，最终就是否采用SOA来进行信息化建设做出宏观决策，并建立SOA总体规划蓝图，其关系图如图3-2所示。

业务与IT规划关系图
一方面，企事业单位或组织的决策部门和业务部门需要进行业务规划，通过对公司愿景、内外部环境、资源约束、风险等方面的梳理和分析，拟定公司的业务策略及需要解决的业务问题；另一方面，在业务规划的驱动下，IT部门的CIO以及团队需要从信息化的角度，对当前组织已有IT系统的功能、性能、问题、基础架构、平台、标准以及需要满足的需求等各方面进行评估和规划，拟定IT整体的建设策略、建设路线以及组织结构。
在业务和IT规划过程中，在如下方面需要双方依次进行研究和磋商：
1．是否要采纳SOA
n 业务当前问题和需求是什么，现阶段是否有必要、有条件在信息化建设中采纳SOA？
n 采纳SOA，到底可以解决什么关键问题？—此处可参考本指南中的SOA效益及合用场景内容。
n 采纳SOA，是否具有相应的基本条件？比如：高层决策者对SOA具有全面的理解和一致的结识，具有采纳SOA所需的预算，信息化建设水平较高，具有较高素质的信息化专业队伍等。
2．采纳何种SOA策略
n 到底应当在什么层次、什么级别上采纳SOA？
n 是在战略级别上还是战术级别上？是全面铺开还是局部试点？
n 具体而言什么业务单元需要SOA？如何排定需求优先级？把哪个作为切入点和突破口？
3．需要如何投入资源
n 采纳SOA需要哪些资源投入？
n 现有的资源条件是否满足规定？
n 采纳SOA需要哪些政策、制度、指南、标准方面的配套？
n 在此过程中，两方面人员在规划过程中通过反复沟通和协商并达成一致后，最后决策出是否采纳SOA以及总体采纳思绪。
5.2.3 需求规划
需求规划阶段工作是：通过对业务及IT的目的进行综合分析，拟定当前所要实行的SOA项目目的以及项目实行方案。
SOA项目目的涉及成果性目的和约束性目的两大类，重要是需要在一定的成本及时间限度内完毕项目的建设内容并达成预期目的，涉及SOA系统、子系统的功能、非功能和用户界面描述等。
SOA项目实行方案重要涉及项目的实行范围、进度规划、质量控制方法、成本预算、团队计划、风险管理计划、技术规划和产品选型方案等。
在IT系统规划中需要考虑系统的规模，建议第一个SOA项目要限定项目大小，不要选择太大，保证在一定期间内可以顺利实行完毕，保证项目的成功并使业务人员体会到SOA的特点和价值。通过项目经验的积累，为后续SOA项目开创一个良好的局面和环境。SOA自身特点支持项目的递进式实现，可以采用不断滚动改善的方式实行项目。
同时需要强调的是，在SOA项目实行方案中需要特别考虑标准问题。SOA项目所涉及的标准包含两方面：业务标准和技术标准。拟定和采纳合适的标准体系，将有助于保证IT系统的建设质量，同时提高其连续运用与扩展能力。
项目具体的实行涉及两方面内容：一方面要建设基础设施，另一方面围绕服务采用不断迭代的方式进行业务功能实现。由于SOA项目建设核心是“服务”，所以本书后续的阶段重点围绕第二方面进行介绍。
5.2.4 服务规划及设计
服务规划及设计阶段的工作是：进行业务的分析和梳理，使业务流程可以映射到IT流程，并进行服务建模，以拟定所需要的服务集和服务实现策略。
在业务分析层面，目的是对业务及业务流程进行清楚的建模，此阶段具体实行中可依据一些国内外知名的业务分析方法论来完毕。在IT层面，需要用服务建模方法来指导如何将业务模型转化为实现 SOA 所需要的模型，通过发现和定义与业务对齐的“服务”，使“服务”成为业务与IT之间的桥梁，从而让IT与业务能更好地互动。
此过程中，需要用户的业务人员参与进来，共同完毕业务服务定义、业务流程定义、业务数据分析和组织架构拟定等内容。对于相应的服务及流程，需要基于实际情况拟定是运用已有IT系统进行服务化封装实现还是重新开发新的服务来实现。同时，用户方还需要与专业实行团队共同拟定总体技术架构及所采用的技术、标准、工具和产品。
重要规划和设计的内容如下：
n 组织结构、业务布局分析。
n 相关业务部门功能及需求分析，业务流程分析以及业务建模。
n 服务规划，根据业务分析和建模结果，分析辨认所需的服务，对服务的层级进行合理划分，对服务的分类和聚合进行设计。辨认和规划服务过程中，基本原则是要保证基于标准的服务可以被重新组合和运用并成功地用于典型行业应用环境中的各种系统中。
n 服务定义和描述，包含具体的服务名称、服务的操作、输入消息、输出消息，业务目的、业务规则、业务事件，非功能性需求等服务的定义，服务之间关系的描述，服务之间的依赖关系和包含关系。
n 服务实现策略，拟定如何实现所需的服务，可以自行开发、外部采购或者集成遗留IT资源。
5.2.5 服务开发及测试
SOA项目中的服务开发即服务实现，其与传统IT项目开发有较大差别。“服务”是SOA项目开发阶段的核心概念，涉及单个功能的服务，也涉及流程类的服务。
服务开发是将业务服务的定义进行真正的技术实现。在传统项目中几乎所有的代码都需要编写实现，而在SOA实现中，可以选择自行开发和手工编码，也可以调用或购买已有的内外部服务，实现过程更多采用参数配置、组装、流程定义等技术，代码编程工作量会减少。在服务具体的技术定义、开发和组装中，用户可以基于现有基础设施情况以及服务设计阶段的业务服务定义，选择采用Web Service、SCA/SDO技术或其他传统技术逐步实现单业务功能服务、组合类服务或流程类服务。
服务测试是保证服务开发对的有效的手段，与服务开发交叉进行。服务测试涉及对单个服务的单元测试，也涉及对于组装类服务或服务流程的集成测试。服务测试工作重要是基于服务定义和描述中的功能和性能指标，采用一定的测试工具、技术和标准规范，对服务进行质量测试和评估，并根据测试的结果来决定服务的开发是否合格。在SOA项目中，服务的测试与传统的测试也不同，为保证服务能与其他服务互联互通，对服务的标准符合性测试及互操作性测试更为重要。
5.2.6 服务部署
此阶段是根据SOA项目目的、通过部署工具将所开发的各类服务及流程部署至用户的物理环境内，比如用户的应用服务器、流程服务器、门户服务器等。对于单个服务，部署后的服务可以被终端用户、其他IT系统或服务实际调用；对于多个基于服务的流程，部署后可形成完整应用系统，从而为用户业务提供相应的IT