1.4 SOA技术概述

1.4.1 SOA技术体系

从技术层面来看，SOA并不是一项技术创新，传统的技术在构建SOA系统时同样能派上用场。实际上，在采用SOA进行系统整合的项目中很多被整合的系统本身就是基于传统技术开发的，但与传统构建系统的方法比较，SOA更强调标准化应用，更加重视系统的层次架构。SOA特性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解，而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。因此，只要在开发过程中遵循SOA的理念，采用统一的标准，任何现有技术都能用来开发SOA系统。

SOA与传统技术体系的区别在于系统均是基于“服务”构造，“服务”之间的交互和组合采用了一种基于“服务中介平台”的方式实现了松耦合，图1-1是“服务”被提供和使用过程的示意图。

图1-1 SOA系统中服务交互示意图

在图1-1中，服务提供者是一个可以通过网络寻址到的实体，它提供的“服务”是基于IT系统的某个功能或流程；服务请求者调用和使用服务提供者提供的“服务”；服务中介平台类似代理的角色，以目录方式存储了大量“服务”资源，一方面可以接受服务提供者提供的各类“服务”信息，另一方面可以通过协调机制把“服务”的请求分配给服务提供者。这样为服务请求者和服务提供者建立了中立的沟通渠道。

上述对服务交互图的描述是为了解释SOA的核心元素“服务”的运行机制。便于对技术有兴趣的用户IT人员了解。下述内容将围绕SOA系统的整体技术体系来进行说明。

在具体的项目中，SOA系统构建没有完全统一的模式，系统的体系架构需要根据用户现状进行分析设计。但在层次和内容上，SOA系统存在一些共性的特征。通常而言，SOA系统的技术体系包含如下几个层次及内容，如图1-2所示。

图1-2 SOA系统基本技术体系

1．基础设施层

既包括服务器、网络设备等硬件设施，也包括操作系统、数据库系统等基础软件，作为整个SOA系统运行的基础平台。

2．已有资源层

指用户当前所拥有的IT资源。“已有应用系统资源”和“已有信息或数据资源”是指用户当前运行的应用系统及数据系统中，若干适合抽取出来作为为上层系统提供服务支持的资源。被抽取出来的资源可以是某个系统（指应用系统或数据系统）中的某个模块，可以是某个系统，可以是若干系统的合并及组合，也可以是各类格式的数据资源；“已有的组件/构件资源”即包括原先采用组件/构件系统的用户所拥有的组件/构件资源，例如基于COM/COM+、JavaBean/EJB或者是CORBA开发的技术功能组件或业务功能组件，也包括已有的Web Services服务组件。“基础设施层”与“已有资源层”是服务的具体技术实现层，上层应用使用的服务最终都由这两层提供。

3．服务提供层

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

• 服务——主要是与业务需求对齐的各类“业务服务”（与用户业务相关的、实现特定业务功能）、“流程服务”（与用户实际业务流程相关、包含人员与IT系统参与的一个处理过程）、“信息服务”（用于共享的各类数据和信息）、“交互服务”（为最终用户、其他IT系统或服务提供多渠道统一访问入口的服务）以及“其他服务”（包括实现安全规则、管理机制、质量策略等各类构建用户IT系统所需的服务）。
• 企业服务总线（ESB）——为服务之间间接和动态交互提供支持。ESB具体的功能包括：消息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位具体的服务）、消息验证（检验服务发送的消息是否满足格式要求）、消息格式转换（把消息从一种格式转成另外一种格式）、消息操作（包括增加或删除字符，或把消息中的特定字符进行转换的操作）等。ESB包含了传统消息中间件的“消息代理”（MessageBroker）功能，但其增强了服务的动态路由和交换功能。通过把服务接入ESB，由ESB负责服务消息的流通，用户就可以把注意力全部集中在服务的构建上。此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接交换就变成了现在的间接交换，实现了松耦合。
• 服务资源库——服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。已注册的服务可以分成两大类，一类是可以直接被使用的、实现具体功能的服务，另一类是在运行时才进行组装的服务。服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面作出的规定等。

5．应用接入层

用户在这一层里可以部署各种应用，例如图1-2中所示的在政府、金融、电信等行业的应用。应用依据业务流程，主要由业务人员设计，IT技术人员辅助。应用依靠下层提供的服务及服务的组合具体实现。

6．标准体系

标准体系贯穿SOA系统从最底层到最上层全部四层结构，内容上由若干行业内公认的标准组成，是每层系统规划设计时建议采用的规范，为SOA系统的标准化实施确定了边界，同时便于实现SOA系统间的互操作。

7．开发平台及各类工具集

用于对SOA系统进行规划设计、实施测试、运维管理的软件平台及工具集，涵盖系统各个层次。从系统生命周期角度出发，可划分为如下平台及工具：

• 规划平台及工具——主要用于做出整个系统的分析与规划，需要进行的工作包括项目管理、需求分析、版本控制以及文档管理等。
• 设计平台及工具——协助相关人员完成整个系统的设计工作。具体的平台及工具应该包括“业务建模”（模型化企业的业务）、“流程建模”（把业务整理成流程）、“服务组装”（按照一定规则组装流程形成服务或应用）、“服务建模”（模型化整理出来的服务用于服务生成）。这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别，体现的是SOA的思想。
• 开发平台及工具——用于实施SOA系统的开发，所采用的开发语言及开发平台没有限制。
• 测试平台及工具——用于实施SOA系统的测试。传统的测试平台及测试工具在SOA系统的测试工作中同样可以采用。
• 注册部署平台及工具——用于实施服务的注册发布以及SOA系统的部署。
• 监控管理平台及工具——用于SOA系统整个生命周期的监控及管理。这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段SOA系统的实施进展，便于用户及早对意外情况做出反应。

以上是通用的SOA系统技术体系，可用于指导SOA项目的实施。各厂商在实际项目实施中可根据用户需求及产品选型情况，在此技术体系基础上提供个性化的解决方案。

1.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标准服务网”www.soa-china.org.cn上，详细论述可参阅该文档）。

图1-3 SOA及Web Services规范及标准域

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

图1-4 中国SOA标准体系全景图

我国SOA标准体系工作将围绕4个层次标准的研制工作展开：

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

目前，中国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标准化指南》等处于计划阶段。

1.4.3 面向服务方法与传统方法的区别

软件开发方法历经数次变革，从结构化分析方法开始，经面向对象方法、面向构件方法，到现在的面向服务方法，这些变革都是为满足客户需求的根本改变，以适应应用领域不断增加的复杂程度而提出的。

1．结构化分析方法

结构化分析方法在20世纪70年代逐步形成，以算法为中心，按照逐层分解、逐步求精的原则，给出一组帮助系统分析人员产生功能规约的原理与技术，方法简单、清晰，符合人们认识世界、改造世界的一般规律，从而大大降低了求解问题的复杂程度。但其对需求变更的适应能力很差，所需文档数据资料极大，也不适合用于解决复杂的大规模问题。

2．面向对象方法

面向对象方法产生于20世纪80年代，以对象（对象=数据+算法）为中心，为软件工业实现工程化提供了强有力的支持。面向对象方法具有封装性、多态性和继承性，与人类习惯的思维方法一致，加强了人们对问题域的理解，增强了适应需求变化的能力，且利于用户的参与和各类人员的交流。但其需要依赖具体的编程语言，与业务存在鸿沟；封装粒度小，耦合度高，难于实现大规模、高层次的重用。

3．面向构件方法

面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。企业业务被映射成系统构件，从整个企业的视角出发构思、设计系统，是面向对象方法更高一级的抽象，比面向对象方法更切合企业的实际应用，重用度也进一步提高。但与开发语言紧密联系，导致接口标准不统一，不同开发语言实现的系统之间很难实现互操作。

4．面向服务方法

面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。面向服务方法关注的是企业业务，它直接映射到业务，强调IT与业务的对齐，以服务为核心元素来封装企业的业务流程和企业已有应用系统。服务的粒度更大，更加匹配企业级应用中的业务，可以实现更高级别的重用。但目前存在相关标准未统一、应用案例较少等一些问题。

上述各类系统构建方法的比较如表1-1所示。

表1-1 各类系统构建方法的比较