soa项目实施白皮书

soa项目实施白皮书内容摘要：

这是 SOA 系统最关键的一层，也是 SOA 系统设计最难的部分，难点在于服务的规划与设计 ——该如何划分服务及服务的粒度。 服务的规划与设计不仅直接影响到 SOA系统的性能，也间接影响到 SOA系统的扩展能力。 但这不仅仅是技术问 题，需要从企业战略目标的层次上考虑服务的划分，业务人员的参与也是设计出适合企业使用的服务的关键。 具体方法和原则可参见本书第一篇第 3章 节的相关内容。 本层主要由三部分组成 ——服务、企业服务总线（ ESB）、服务资源库，各部分内容说明如下：  服务 ——主要是与业务需求对齐的各类 “业务服务 ”（与用户业务相关的、实现特定业务功能）、 “流程服务 ”（与用户实际业务流程相关、包含人员与 IT 系统参与的一个处理过程）、 “信息服务 ”（用于共享的各类数据和信息）、 “交互服务 ”（为最终用户、其他 IT 系统或服务提供多渠道统一访问入口 的服务）以及 “其他服务 ”（包括实现安全规则、管理机制、质量策略等各类构建用户 IT 系统所需的服务）。  企业服务总线（ ESB） ——为服务之间间接和动态交互提供支持。 ESB 具体的功能包括：消息寻址路由（根据请求对服务的描述以及服务在服务资源库中的注册信息，定位具体的服务）、消息验证（检验服务发送的消息是否满足格式要求）、消息格式转换（把消息从一种格式转成另外一种格式）、消息操作（包括增加或删除字符，或把消息中的特定字符进行转换的操作）等。 ESB 包含了传统消息中间件的 “消息代理 ”（ MessageBroker）功能， 但其增强了服务的动态路由和交换功能。 通过把服务接入ESB，由 ESB负责服务消息的流通，用户就可以把注意力全部集中在服务的构建上。 此外，由于消息的发送不再在服务间点对点地进行传送，消息原先的直接交换就变成了现在的间接交换，实现了松耦合。  服务资源库 ——服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。 已注册的服务可以分成两大类，一类是可以直接被使用的、实现具体功能的服务，另一类是在运行时才进行组装的服务。 服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面 作出的规定等。 4) 应用接入层 用户在这一层里可以部署各种应用，例如图 12 中所示的在政府、金融、电信等行业的应用。 应用依据业务流程，主要由业务人员设计， IT 技术人员辅助。 应用依靠下层提供的服务及服务的组合具体实现。 5) 标准体系 标准体系贯穿 SOA系统从最底层到最上层全部四层结构，内容上由若干行业内公认的标准组成，是每层系统规划设计时建议采用的规范，为 SOA系统的标准化实施确定了边界，同时便于实现 SOA系统间的互操作。 6) 开发平台及各类工具集 用于对 SOA系统进行规划设计、实施测试、运维管理的软件平台及工具集，涵盖 系统各个层次。 从系统生命周期角度出发，可划分为如下平台及工具：  规划平台及工具 ——主要用于做出整个系统的分析与规划，需要进行的工作包括项目管理、需求分析、版本控制以及文档管理等。  设计平台及工具 ——协助相关人员完成整个系统的设计工作。 具体的平台及工具应该包括 “业务建模 ”（模型化企业的业务）、 “流程建模 ”（把业务整理成流程）、 “服务组装 ”（按照一定规则组装流程形成服务或应用）、 “服务建模 ”（模型化整理出来的服务用于服务生成）。 这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别，体现的是 SOA的思想。  开发平台及工具 ——用于实施 SOA系统的开发，所采用的开发语言及开发平台没有限制。  测试平台及工具 ——用于实施 SOA 系统的测试。 传统的测试平台及测试工具在 SOA系统的测试工作中同样可以采用。  注册部署平台及工具 ——用于实施服务的注册发布以及 SOA系统的部署。  监控管理平台及工具 ——用于 SOA系统整个生命周期的监控及管理。 这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段，监测各个阶段 SOA系统的实施进展，便于用户及早对意外情况做出反应。 以上是通用的 SOA 系统技术体系，可用于指导 SOA 项目的实 施。 各厂商在实际项目实施中可根据用户需求及产品选型情况，在此技术体系基础上提供个性化的解决方案。 SOA标准体系 SOA标准体系是指 SOA领域内多种类、多层次的 SOA标准所组成的相互联系的有机整体。 这套体系对统一用户与企业对 SOA的理解，加快 SOA项目实施的规范化，以及增强 SOA系统间的互操作能力等方面具有重要意义。 目前国际上尚未有被广泛认可与接受的 SOA标准体系。 一些国际标准协会组织（如 W3C、OASIS、 OMG、 WSI等）及国际主流企业发布了若干用于构建 SOA系统的规范及标准（常见的是基于 Web Services 技术的一系列 WS*规范及标准），但这些规范及标准仅在各个标准化协会或企业内形成初步的体系，而且不同组织发布的规范及标准间存在重复甚至冲突的现象，因此，国际上统一的 SOA标准体系短时间内还不能成型。 为让用户了解目前国际上各类规范及标准的研制与使用情况，使用户在做系统开发决策时有一定参考依据，同时抱着建设适合国内用户使用的 SOA 标准体系的目标， ISOL 梳理了各个国际标准协会组织及国际主流企业发布的主流规范及标准，整理出 84项关于 SOA与 Web Services 的规范及标准，经过体系化分析，划分 出 14 个标准域（见图 13），形成当前主流SOA与 Web Services 规范及标准的全集，最终形成国际 SOA标准体系研究报告的白皮书——《 SOA标准体系 》（已发布在 “中国 SOA标准服务网 ” 上，详细论述可参阅该文档）。 SOA及 Web Services 规范及标准域 目前，我国 正在基于国内产业和用户需求，建立我国的 SOA国家和行业标准体系，此工作已于 2020 年开始，目前已初步规划出我国 SOA国家标准体系，如图 14 所示。 此标准体系会在我国标准化专业机构、软件产业界、学术界以及用户的共同合作下进行细化及具体研制。 中国 SOA标准体系全景图 我国 SOA标准体系工作将围绕 4 个层次标准的研制工作展开：  SOA基础标准 ——是支撑 SOA系统实现的通用性基础标准，包括《 SOA术语》、《 SOA总体技术要求》、《 SOA 标准化指南》以及《 SOA 集成开发标准》，这一层次的标准将为 SOA系统或产品的基本功能、性能作出限定，并为用户和软件厂商提供使用指导。  SOA支撑技术标准 ——是 SOA系统相关的基础技术标准，在图 14 所示 11 个标准域的若干标准中，我国将对国外已有的相关成熟技术标准（如部分 WS*标准）进行裁剪和修改，并采纳为我国相应的国家标准，部分国内有特殊需求的标准将采取自主研制的方式来制定。  SOA测评标准 ——包 括两类：一类对 SOA相关的产品对于 SOA标准的符合性及互操作性进行评测，第二类为用户提供 SOA建设成熟度评估的评测规范，包括相关评测方法和指标。 上述标准规范将作为相应的 SOA测评工具和平台的基本依据。  SOA行业 /领域标准 ——将根据行业或领域特征及信息化现状来研究制定适合本行业或本领域的 SOA标准体系。 此部分标准的研制工作将由我国各行业相关标准化委员会或行业协会来主导制定。 目前所列出的几个领域为部分有代表性的行业或领域，其他行业或领域也会逐步扩展进来。 目前，中国 SOA 标准体系正逐步形成之中：《基于 XML 的 Web 服务描述语言》（ 20200146T339）与《基于 XML 的简单对象访问协议》（ 20200147T339）两项国家标准已完成制定并发布；《 Web 服务可靠消息传递》（ 20200478T469）与《 Web 服务互操作框架》（ 20200477T469）已开始研制；《 SOA术语》、《 SOA总体技术要求》、《 SOA标准化指南》与《 Web 服务管理标准》 4 个标准处于国家标准公示阶段；《 Web 服务业务流程规范》等两个标准处于申报阶段；《金融行业 SOA标准化指南》等处于计划阶段。 面向服务方法与传统方法 的区别 软件开发方法历经数次变革，从结构化分析方法开始，经面向对象方法、面向构件方法，到现在的面向服务方法，这些变革都是为满足客户需求的根本改变，以适应应用领域不断增加的复杂程度而提出的。 1．结构化分析方法 结构化分析方法在 20 世纪 70 年代逐步形成，以算法为中心，按照逐层分解、逐步求精的原则，给出一组帮助系统分析人员产生功能规约的原理与技术，方法简单、清晰，符合人们认识世界、改造世界的一般规律，从而大大降低了求解问题的复杂程度。 但其对需求变更的适应能力很差，所需文档数据资料极大，也不适合用于解决复杂的大规 模问题。 2．面向对象方法 面向对象方法产生于 20 世纪 80 年代，以对象（对象 =数据 +算法）为中心，为软件工业实现工程化提供了强有力的支持。 面向对象方法具有封装性、多态性和继承性，与人类习惯的思维方法一致，加强了人们对问题域的理解，增强了适应需求变化的能力，且利于用户的参与和各类人员的交流。 但其需要依赖具体的编程语言，与业务存在鸿沟；封装粒度小，耦合度高，难于实现大规模、高层次的重用。 3．面向构件方法 面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。 企业业务被映射成系统构件，从整个企业的视角出发构思 、设计系统，是面向对象方法更高一级的抽象，比面向对象方法更切合企业的实际应用，重用度也进一步提高。 但与开发语言紧密联系，导致接口标准不统一，不同开发语言实现的系统之间很难实现互操作。 4．面向服务方法 面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。 面向服务方法关注的是企业业务，它直接映射到业务，强调 IT 与业务的对齐，以服务为核心元素来封装企业的业务流程和企业已有应用系统。 服务的粒度更大，更加匹配企业级应用中的业务，可以实现更高级别的重用。 但目前存在相关标准未统一、应用案例较少等一些问题。 上述各类系统构建方法的比较如表 11 所示。 名称 概述 优点 缺点 结构化 方法 以算法为中心，又称为结构化分析 体现了逐层分解、逐步求精的原则，有严格的规则 难于检验分析结果的正确与否；对需求变更的适应能力很差；系统设计人员对分析结果的理解存在障碍 面向 以对象（对象 =数据 加强了对应用领域的理解， 纯技术导向，存在与业务的鸿沟；复杂度高，对象 方法 ＋算法）为中心，实现了对数据和算法的封装和继承 改进了沟通和交流；适应需求变化的能力较强；支持分析和设计结果的复用 抽象程度低，难以实现大规模和高层 次的重用 面向 构件 方法 以组件或构件封装可重用的功能单元 重用度进一步提高，提高了软件企业的开发效率和质量 组件或构件封装方法和接口标准不统一，很难实现与外部应用系统之间的互操作 面向 服务 方法 以服务封装业务流程和应用系统 业务驱动技术，以开放标准实现应用系统之间服务的相互访问，乃至复合应用的组装，实现了更高级别重用 处在概念导入期末尾，相关标准尚未统一，应用案例及工程实践刚起步 5 SOA 项目实施 过程 SOA项目需求来源 当前 SOA项目的建设，需求来源主要分为两大类：系统整合驱动和新系统 建设驱动，下面分别介绍之。 1．系统整合驱动 电信、金融、政府等以服务为导向的企业或组织中，为了更好地满足客户或公众需求，必须提供一站式以及随需应变的服务能力。 不仅要对企业或组织内部系统进行整合，同时要与相关的企业及组织进行信息系统协同，因此在整合及协同为主要需求推动下，基于 SOA的 IT系统整体架构成为选择热潮。 基于 SOA的整合范围包括 3 类：应用系统之间的数据整合、功能整合和流程整合。 整合的方式是通过对原有数据及 IT 系统资源进行服务化的包装，从而使得各系统以统一的、标准化的方式进行数据共享和业务协同。 2．新系统建设驱动 随着信息化建设的进步一开展，部分企业的原有系统已经较庞大而复杂，面临新的业务需求，原有系统已远远不能满足这些新的业务需求。 现有 IT 系统的相对刚性使很多 CIO 在面对频繁的业务变化时步履维艰、痛苦不堪。 从技术层面来说，许多软件系统基本采用手工编码的方式，总体架构设计的缺乏注定无法全面适应系统需求变更的需要。 因此许多单位在建设新的系统时，以柔性化敏捷化的业务应用系统为目标，希望能持续地支撑业务应用的变化及发展。 SOA 在基础架构上基于业务服务、标准化、平台无关的特性，使其成为这些新系统构建的首选。 需要指出的是，上述两种需求来源均不是孤立的，在各行业的项目建设中，系统整合往往与新系统建设相互融合，但各项目所解决的问题会对整合或新系统的建设各有偏重。 服务生命周期 (以服务为中心的实施过程 ) SOA既是对 IT 规划设计和基础设施方面的重大改革，也是应用开发和业务部门应用上的极大改进。 SOA 项目的实施不仅涉及 IT 部门，而且涉及企业从上到下、从业务到 IT 的全面参与。 在项目实施的过程中，必须首先由企业或组织的最高层做出决策，对 IT 系统及各项目实施路线做出整体规划，然后 由相关。