(软考）系统分析师——软件体系结构

最新推荐文章于 2024-06-25 15:56:50 发布

吃货小娃子

最新推荐文章于 2024-06-25 15:56:50 发布

阅读量1k

点赞数

分类专栏：软考系统分析师文章标签：经验分享

本文链接：https://blog.csdn.net/x12345_67890/article/details/109101105

版权

软考系统分析师专栏收录该内容

16 篇文章 7 订阅

订阅专栏

ps:本博客内容只针对博主复习期间对考点的一些总结，内容可能并不全面，还望海涵。也欢迎大家补充和指点错误~~

软件体系结构

软件体系结构(软件架构）是具有一定形式的结构化元素，即构件的集合，包括
- 处理构件：负责对数据进行加工，
- 数据构件：是被加工的信息；
- 连接构件：把体系结构的不同部分组合连接起来
对于复杂系统和大型系统的开发而言，设计好软件体系结构是保证软件质量的根本措施。
软件体系结构的作用：
- 软件体系结构是项目干系人进行交流的手段；
- 软件体系结构是早期设计决策的体现；
- 软件体系结构是可传递和可重用的模型。

软件体系结构建模

根据建模的侧重点不同，可以将软件体系结构的模型分成5种：
- 结构模型：是一个最直观、最普遍的建模方法；以体系结构的构件、连接件和其他概念来刻画结构，力图通过结构来反映系统的重要语义内容；研究结构模型的核心是体系结构描述语言；
- 框架模型：与结构模型相似，不太侧重细节而更侧重于整体的结构；主要以一些特殊的问题为目标建立只针对和适应该问题的结构；
- 动态模型：是结构模型和框架模型的补充，研究系统的大颗粒的行为性质
- 过程模型：研究构造系统的步骤和过程，因此结构是遵循某些过程脚本的结果；
- 功能模型：认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
  最常用的是结构模型和动态模型
5种模型有机统一形成完整的模型来刻画软件体系结构最合适；
“4+1”的视图模型
- 从5个不同的视角来描述软件体系结构；
  - 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务；
  - 进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求；
  - 物理视图：主要考虑如何把软件映射到硬件上
  - 开发视图（模块视图）：侧重于软件模块的组织和管理；
  - 场景：可以看作是那些重要系统活动的抽象，使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。
    逻辑视图和开发视图描述系统的静态结构，进程视图和物理视图描述系统的动态结构

软件体系结构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式
体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效的组织成一个完整的系统。
通用的体系结构风格的分类是：
- 数据流风格：批处理序列；管道/过滤器
- 调用/返回风格：主程序/子程序；面向对象风格；层次结构
- 独立构件风格：进程通信；事件系统
- 虚拟机风格：解释器；基于规则的系统
- 仓库风格：数据库系统；超文本系统；黑板系统

管道/过滤器

每个构件（过滤器）都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流；
这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入；
其中过滤器必须是独立的实体，不能与其他过滤器共享数据，而且一个过滤器不知道它上游和下游的标识；
典型的例子：UNIX shell编写的程序、传统的编译器
良好的特点：
- 使构件具有良好隐蔽性和高内聚、低耦合的特点；
- 允许设计者将整个系统的I/O行为看成是多个过滤器行为的简单合成；
- 支持软件重用
- 系统维护简单，可扩展性好；
- 允许对一些如吞吐量、死锁等属性的分析；
- 支持并行执行
不利因素：
- 通常导致进程成为批处理的结构；
- 不适合处理交互的应用；
- 由于数据传输没有通用标准，每个过滤器都增加了解析和合成数据的工作，导致性能下降，并增加了编写过滤器的复杂性

面向对象风格

建立在数据抽象和面向对象的基础上，
数据的表示方法和相应操作封装在一个抽象数据类型或对象中；
构件是对象/抽象数据类型的实例
优点：
- 对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他对象
- 可将一些数据存取操作的问题分解成一些交互的代理程序的集合
缺点：
- 为了使两个对象通过过程调用等进行交互，必须知道对象的标识；对象标识改变，必须修改所有明确调用它的对象；
- 必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用；例如A调用B，C调用B，C对B的使用所造成的对A的影响是预想不到的。

基于事件的隐式调用

思想：构件不直接调用一个过程，而是触发或广播一个或多个事件；
构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合；
主要特点是触发者并不知道哪些构件会被这些事件影响；不能假定构件的处理顺序，不知道哪些过程会被调用，因此，也包含显式调用作为补充形式。
优点：
- 为软件重用提供强大支持；
- 为改进系统带来方便；
缺点：
- 构件放弃了对系统计算的控制；
- 数据交换的问题；
- 关于正确性的推理存在问题

分层系统

层次系统组织成一个层次结构，每一层为上层服务，并作为下层的客户；
内部的层只对相邻的层可见，每一层最多只影响两层；
这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现；
最广泛的应用是分层通信协议，每一层提供一个抽象的功能，作为上层通信的基础，较低的层次定义底层交互，最低层通常只定义硬件物理连接。
可取的属性：
- 支持基于抽象程度递增的系统设计
- 支持功能增强
- 支持重用
不足之处：
- 不是所有系统都可以很容易划分为分层模式
- 很难找到一个合适的、正确的层次抽象方法。

仓库系统及知识库

在仓库风格中，有两种不同的构件：
- 传统型数据库：输入流中某类时间触发进程执行的选择
- 黑板系统：中央数据结构的当前状态触发进程执行的选择
  - 黑板系统的传统应用是信号处理领域；
  - 黑板系统主要由三部分组成：知识源、黑板数据结构、控制

C2风格

通过连接件绑定在一起的按照一组规则运作的并行构件网络；
系统组织规则如下：
- 系统中的构件和连接件都有一个顶部和一个底部；
- 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
- 一个连接件可以和任意数目的其他构件和连接件连接；
- 当两个连接件进行直接连接时，必须由其中一个底部到另一个的顶部。
C2风格的特点：
- 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；
- 所有构件之间的通信是通过以连接件为中介的异步消息交换机制来实现；
- 构件相对独立，构件之间依赖性较少

客户/服务器风格（二层C/S结构）

基于资源不对等，且为实现共享而提出来的，定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上；
由三个部分组成：
- 数据库服务器：负责有效地管理系统的资源
- 客户应用程序：提供用户与数据库交互的界面，向数据库服务器提交用户请求并接收来自数据库服务器的信息，对存在于客户端的数据执行应用逻辑要求；
- 网络：完成数据库服务器和客户应用程序之间的数据传输
主要优点：
- 系统客户应用程序和服务器构件分别运行在不同计算机上，每台服务器都可适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，易于对系统进行扩充和缩小
缺点：
- 开发成本较高；
- 客户端程序设计复杂；
- 信息内容和形式单一
- 用户界面风格不一，使用繁杂，不利于推广使用；
- 软件移植困难；
- 软件维护和升级困难；
- 新技术不能轻易应用。

多层体系结构风格（三层C/S结构）

三层C/S结构是将应用功能分成：
- 表示层：存在于客户机上，是应用的用户接口部分，担负着用户与应用间的对话功能，这种结构称为瘦客户机，负责处理用户的输入和向客户的输出。
- 功能层：相当于应用的本体（应用服务器），是将具体的业务处理逻辑编入程序中；负责建立数据库的连接，根据用户的请求生成访问数据库的SQL语句，并把结果返回给客户端；
- 数据层：数据层就是DBMS，负责管理对数据库数据的读写；负责实际的数据库存储和检索，响应功能层的数据处理请求，并将结果返回给功能层；
这三层明确的分割了出来，并在逻辑上独立；
优点：
- 能提高系统和软件的可维护性和可扩展性
- 允许更灵活有效的选用相应的平台和硬件系统，并且这些平台和各个组成部分可以具有良好的可升级性和开放性；
- 应用的各层可以并行开发，也可以各自选择最合适的开发语言；
- 利用功能层有效的隔离开表示层和数据层，为严格的安全管理奠定了基础，整个系统的管理层次更加合理和可控制。

B/S结构【浏览器/服务器]（三层C/S结构的一种实现方式）

具体结构为：浏览器/Web服务器/数据库服务器；
主要利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器实现原来需要复杂专用软件才能实现的强大功能，并节约开发成本；
基于B/S结构的软件，系统安装、修改和维护全在服务器端解决，用户在使用系统时，仅需要一个浏览器就可运行全部模块，很容易在运行时自动升级；
与C/S结构相比的不足之处：
- 缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
- 系统扩展能力差，安全性难以控制；
- 在数据查询等响应速度上，远低于C/S结构；
- B/S结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

富互联网应用（RIA)

RIA是一个用户接口，比HTML能实现的接口更健壮、反应更灵敏和更具有令人感兴趣的可视化特性；
是为了弥补B/S结构的不足，提高用户体验而产生的，结合了C/S结构反应速度快、交互性强的优点与B/S结构传播范围以及容易传播的特性，简化并改进了B/S结构的用户交互，为用户开发的应用程序提供更丰富、更具有交互性的用户体验

软件体系结构评估

软件体系结构评估可针对一个体系结构，也可以针对一组体系结构；在评估过程中，关注的是系统的质量属性；
敏感点和权衡点是关键的体系结构决策；
敏感点：是一个或多个构件（和/或构件之间的关系）的特性；
权衡点：：影响多个质量属性的特性，是多个质量属性的敏感点。

主要的评估方式

基于调查问卷或检查表的评估方式

这一评估方法比较自由灵活，可评估多种质量属性，也可以在软件体系结构设计的多个阶段进行；
评估结果很大程度来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也可以成为评估结果是否正确的重要因素；
尽管这种方法相对主观，但由于系统相关人员的经验和知识是评估软件体系结构的重要信息来源，因此它仍是进行软件体系结构评估的重要途径之一。

基于场景的评估方式

场景是一系列有序的使用或修改系统的步骤；
基于场景的评估方式主要应用在ATAM评估方法和SAAM评估方法中；
一般采用3方面来对场景进行描述
- 刺激：场景中解释或描述项目干系人怎样引发与系统的交互部分；
- 环境：描述的是刺激发生时的情况；
- 响应：是指系统是如何通过体系结构对刺激作出反应的
基于场景的方式分析软件软件体系结构对场景的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度，考虑到所有与系统相关的人员对质量的要求；
由于不同系统对同一质量属性的理解可能不同，所以对一个领域适合的场景设计在另一个领域内未必合适，因此基于场景的评估方式是特定于领域的
该方法的实施者必须拥有丰富的领域知识，以对某一质量需求设计出合理的场景；必须对待评估的软件体系结构有一定了解，以准确判断它是否支持场景的描述的一系列活动。

基于度量的评估方式

度量是指为软件产品的某一属性所赋予的数值（如：代码行数、方法调用层数、构件个数等）；
基于度量的评估方式涉及3个基本活动：
- 首先需要建立质量属性和度量之间的映射原则，即从度量结果中推出系统的质量属性；
- 从软件体系结构文档中获取度量信息；
- 根据映射原则分析推导出系统的某些质量属性；
基于度量的评估方式提供更客观和量化的质量评估

比较

评估方式	调查问卷	检查表	场景	度量
通用性	通用	特定领域	特定系统	通用或特定领域
评估者对体系结构的了解程度	粗略了解	无限制	中等了解	精确了解
实施阶段	早	中	中	中
客观性	主观	主观	较主观	较客观

ATAM评估方法（体系结构权衡分析方法）

是评价软件构架的一种综合全面的方法，不但揭示了体系结构如何满足特定的质量目标，而且还提供了这些质量目标是如何交互的，即它们之间是如何权衡的；
ATAM评估9个过程(顺序不固定，可跳转和迭代）
- 描述ATAM方法
- 描述业务动机
- 描述体系结构
- 确定体系结构方法
- 生成质量属性效用树
- 分析体系结构方法
- 讨论和对场景分级
- 分析体系结构方法
- 描述评估结果
两个阶段：
- 以体系结构为中心，重点是获取体系结构信息并进行分析；
- 以项目干系人为中心，重点是获取项目干系人的观点，验证上一个阶段的结果

SAAM评估方法（软件体系结构分析方法）

是最早形成文档并得到广泛使用的软件体系结构分析方法；
以ATAM方法相比，比较简单，易学易用
SAAM评估的6个步骤：
- 形成场景
- 描述体系结构
- 对场景进行分类和确定优先级
- 对间接场景的单个评估
- 评估场景的相互作用
- 形成总体评估

分布式系统设计

难点：组件的异构性、开放性、安全性、可伸缩性、故障处理以及组件的并发性和透明性

分布式系统设计的方式

分布式系统进行协同和合作的两种不同方式：
- 基于实例的协作
  - 所有实例都处理自己范围内的数据，对象实例地位相同；但一个对象实例需要处理不属于它自己范围内的数据时，可使用称为“代理”的方法与数据归宿的对象实例通信，请求另一个对象实例进行处理；
  - 实例的协作具有良好灵活性；
  - 实例间紧密联系复杂，使得开发成本提高；
  - 由于实例需要通过网络找到，所以通信协议必须包括实例的生存周期管理，使得实例的协作只限于统一网络，对于复杂跨平台系统难以应付
  - 综上，基于实例的协作适合比较小范围内网络情况良好的环境（近连接）
- 基于服务的协作
  - 这种方法试图解决基于实例的协作的困难；
  - 只提供远程对象的接口，用户可以调用这些方法，却无法远程创建和销毁远程对象实例，减少交互，简化编程，是跨平台协作成为可能；
  - 只提供接口导致对象间会话状态难以确定，通信数据类型有所限制，基本上难以使用自定义的类型；
  - 适合于跨平台的网络，网络响应较慢的情况（远连接）
  - 通常采用层次式体系结构，高层依赖低层，低层细节没必要暴露给高层，使高层实现不受低层影响，低层修改不影响高层服务；

基于Web的分布式系统设计

传统B/S结构的不足
- 普通的Web应用程序一般都运行在Web服务器上，Web服务器负载繁重；
- 由于HTTP协议不是面向连接的协议，是无状态、无连接、以文档描述为基础和基于页面的协议，一次连接只能实现单项的数据浏览，不能进行双向的数据传输；
- 目前的HTTP存在着客户端在一次TCP连接中不能实现多次访问，只能进行一次访问；
- 基于HTML和ASP等脚本语言的页面文档浏览技术不能保存已经浏览过的页面；
- 基于HTML和ASP等脚本语言的Web页面一般只能让用户和浏览器端进行较为简单的交互，不能完成用户和浏览器的复杂交互
因为上述缺点，所以B/S结构的系统难以进行大规模的事务处理以及大量的实时的用户交互。
分布式对象技术
- 是指采用面向对象技术开发的两个或多个软件互相共享信息，这些软件既可以在同一台计算机上运行，也可以通过网络连接起来在几台不同的计算机上运行，主要解决如何在分布系统中集成各组件的问题；
- 优点：
  - 通过分布式环境动态配置，带来软件框架结构的可扩充性；
  - 通过分布式方式共同完成一项复杂的任务，在多个不同计算机上实现平衡负载；
  - 使软件开发各部分更高效、可靠，并且透明地进行合作；
  - 通过请求与服务的分离提高软件的模块性、可移植性；
  - 能使多项软件紧密合作，有利于其他系统进行集成
- 将分布式对象技术和传统B/S结构合起来，利用分布式对象技术分布开发特性和Web集中管理的特征，充分发挥分布对象技术和B/S结构的优势，构建分布网络环境下的系统
- 国际上分布式对象技术的3大流派：CORBA、COM/DCOM、EJB

软件产品线

软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。
软件产品线主要由两个部分组成：
- 核心资源：是领域工程的所有结果的集合，是产品线中产品构造的基础；
- 产品集合
软件产品线开发4个基本技术特点：
- 过程驱动
- 特定领域
- 技术支持
- 以体系结构为中心

产品线的过程模型

双生命周期模型：是最初的、最简单的，分成两个重叠的生命周期：
- 领域工程：构造产品线共有部分
  - 领域分析：利用现有系统的设计、体系结构、需求建立领域模型；
  - 领域设计：用领域模型确定领域/产品线的共性和可变性，为产品线设计体系结构；
  - 领域实现：基于领域体系结构开发领域可重用资源
- 应用工程：在领域工程结果基础上构造新产品，制作差异化部分
  - 需求分析：将系统需求与领域需求比较，划分成领域公共需求和独特需求两部分，得出系统说明书；
  - 系统设计：在领域体系结构基础上，结合系统独特需求设计应用的软件体系结构；
  - 系统实现按照应用体系结构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构件新的系统。
SEI模型
将产品线的基本活动划分为：
- 核心资源开发（领域工程）
- 产品开发（应用工程）
- 管理
- 特点：
  - 核心资源开发和产品开发没有先后之分，可同时进行，也可交叉进行；
  - 循环重复是产品线开发过程、核心资源开发、产品开发以及核心资源和产品之间协作的特征；
  - 管理活动协调整个产品线开发过程的各个活动，对产品线的成败负责；
  - 核心资源开发和产品开发是两个互动的过程，3个活动和整个产品线开发之间也是双向互动的；
三生命周期模型
- 在双生命周期模型的基础上进行改进，为有多个产品线的大型企业增加企业工程流程，以便在企业范围内对所有资源的创建、设计和重用提供合理的规划。

产品线的组织结构

对应于软件产品线开发过程中的领域工程和产品工程，其软件开发的组织结构有两个基本组成部分：
- 负责核心资源的小组
- 负责产品的小组
以上也是产品线开发与独立系统开发的区别
软件产品线的组织结构归纳为4种组织模型：
- 开发部门：所有软件开发集中在一个部门，每个人承担领域过程和应用工程中适合的任务；简单，利于沟通，适合不超过30人
- 商务部门：每个部门负责产品线中一个或多个相似的系统，共性资源几个部门协作开发，资源更容易共享，适合30~100人；缺点：各部门更注重自己的产品，将产品线整体利益放在第二位
- 领域工程部门：一个专门的单位负责核心资源库的开发和维护，有效降低通信的复杂度、保证资源的通用性，适合超过100人；缺点：难以管理和需求冲突导致开发周期增长的问题
- 层次领域工程部门：设立多层（一般为两层）领域工程部门对非常巨大和复杂的产品线进行开发，不同层服务范围不同；缺点：趋向臃肿，对新需求响应慢

产品线的建立方式

划分依据：
- 该组织是用演化方式还是革命方式引入产品线开发过程
- 基于现有产品还是开发全新的产品线
产品线的建立方式通常有4种：
- 将现有产品演化为产品线（基于现有产品集的演化式）
- 用软件产品线替代现有产品集（基于现有产品集的革命式）
- 全新软件产品线的演化（全新产品线演化式）
- 全新软件产品线的开发（全新产品线革命式）
软件产品线建立方式基本特征

/	演化方式	革命方式
基于现有产品集	基于现有产品体系结构开发产品线的体系结构，经演化现有构件的文件一次开发一个产品线构件	产品线核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求的产品线核心资源

Web服务

服务提供者完成一组工作，为服务使用者交付所需的最终结果；
是解决应用程序之间相互通信的一项技术
Web服务是描述一系列操作的接口，使用标准、规范的XML描述接口，包括与服务进行交互所需的全部细节，包括消息格式、传输协议和服务位置；

Web服务模型

服务提供者（服务器）：Web服务的所有者，负责定义并实现Web服务，使用WSDL（Web服务描述语言）对Web服务进行详细、准确、规范的描述，并将该描述发布到服务注册中心供服务请求者查找并绑定使用；
服务请求者（客户端）：Web服务的使用者，服务请求者查找、绑定并调用服务或与服务进行交互，可以由浏览器担当，由人或程序来控制；
服务注册中心（可选）：连接服务提供者和服务请求者的纽带；在某些情况下，如使用静态绑定的Web服务，服务提供者可直接把描述发送给请求者，所以是可选的。

Web服务协议堆栈

SOAP（简单对象访问协议）：
- SOAP是基于HTTP和XML，用于Web Service的简单对象访问协议
- 是一种基于XML的协议，用来在Web服务系统中发送和接收数据，并使用XML“承载”数据；
- 通过SOAP，应用程序可以在网络中进行数据交换和远程调用；
- 用XML进行编码，是一个开放式协议，与应用平台无关；
- 可以理解为HTTP（网络通信）+XML（数据格式的协议）+RPC（远程过程调用）
WSDL（Web服务描述语言）：
- 用来描述如何使用程序来调用Web服务
- 包含一套基本XML的语法；
- 定义了可被机器识别的SDK（软件开发工具包）文档
UDDI（统一描述、发现和集成）：
- 提供了一种Web服务的发布、查找和定位方法；
- UDDI提供目录服务，Web服务提供者使用UDDI将服务发布到服务注册中心，Web服务使用者通过UDDI查找并定位服务；
- UDDI定义了一个用XML表示的服务描述标准
- UDDI定义了一种Web服务的发布方式

Web服务体系结构的优势

高度的通用性和易用性
完全的平台、语言独立性
高度的集成性
容易部署和发布

面向服务的体系结构（SOA)

W3C将SOA定义为
- 一种应用程序体系结构，该体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务形成业务流程
Service-architecture.com将SOA定义为
- 本质上是服务集合，服务彼此通信，可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间通过某些方法连接。
Gartner将SOA定义为：
- 客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成，与大多数通用客户端/服务器模型不同点是它着重强调软件构件的松散耦合，并使用独立的标准接口。
SOA概述
- 在SOA体系结构模型中，所有功能都定义成了独立的服务，服务之间通过交互、协调作业从而完成业务的整体逻辑；
- 所有服务通过服务总线或流程管理器来连接服务和提高服务请求的路径；
- 是一种粗粒度、松耦合的服务体系结构，其服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型；
SOA特性：
- 松散耦合
- 粗粒度服务
- 标准化接口
Web服务实现SOA
- Web服务实现SOA，该系统应该至少分为6个层次：
  - 底层传输层：负责消息的传输机制；消息传输协议：HTTP（使用最广）、JMS、SMTP
  - 服务通信协议层：描述并定义服务之间进行消息传递所需的技术标准；常用标准：SOAP协议，新出标准：REST(表述性状态转移)协议
  - 服务描述层：以一种统一的方式描述服务的接口与消息交换方式；相关标准：WSDL
  - 服务层：将遗留系统进行包装，并通过发布的WSDL接口描述被定位和调用；
  - 业务流程层：支持服务发现，服务调用和点到点的服务调用，并将业务流程从Web服务底层调用抽象出来；相关标准：WS-BPEL(Web服务业务流程执行语言)
  - 服务注册层：使得服务提供者能够通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息；相关标准：UDDI