面向服务架构：SOA系统建模

参考架构概述

What 参考架构？

首先，第一个问题，什么是参考架构？

SOA 参考架构是对抽象架构元素进行建模，独立于特定的解决方案、技术、协议。所以SOA 参考架构不是具体的架构，是SOA这个范式的抽象实现，是以抽象的方式来实现SOA系统！

上期，我们分享了SOA 参考模型，那么SOA参考模型与SOA 参考架构有什么区别？

SOA 参考模型描述了SOA相关的元素重要概念及元素之间的关系。

SOA 参考架构主要阐述建模所涉及的内容，同时独立于任何特定解决方案，主要为SOA 系统建模提供一种通用的参考实现。

目标及关键因素

SOA参考架构的主要目标是解决以下问题：

1. 如何有效使服务消费者和服务提供者进行交互？

2. 如何让参与者在基于SOA系统进行交互时，清楚的了解对方？

实现上述目标的关键因素是：

1. 行为：对参与者在系统内的行为进行记录

2. 信任：对参与者行为的进行描述

3. 交互：对参与者之间如何进行交互的描述

4. 控制：对整个SOA系统的管理和治理的说明

为了实现上述关键因素，SOA参考架构主要从三个角度进行了描述：

1. 从参与SOA系统的角度：对系统约束和环境进行了相关说明。

2. 从实现SOA系统的角度：通过UML类图等描述了如何有效构建基于SOA的系统。

3. 从管理SOA系统的角度：对SOA系统治理、管理、测试流程等方面进行了说明。

本文主要关注的是如何对SOA系统进行建模，因此重点从实现SOA系统的角度进行说明。

SOA实现相关的模型元素

SOA实现侧重于解决以下问题：

什么是服务？

需要什么支持？

如何实现他们？

主要包括以下模型：

服务描述模型：用于告知参与者存在哪些服务以及可以使用它们的条件

服务可见性模型：指在服务交互之前，参与者需使用适当的方式相互可见

服务交互模型：描述了在定义的条件和协议下使用服务的过程

策略和合同模型：详细阐述了服务使用的条件和SOA系统参与者之间的协议

接下来会对上述四个模型进行详细说明。

服务描述模型

服务描述模型概述

服务描述是什么？

服务描述是一个工件，通常基于文档，可能是单个文档或一组文档。

服务描述用来干什么？

服务描述用于定义、使用、部署、管理（或以其他方式）控制服务所需的信息，这些信息包括：

1. 服务可达性

2. 服务接口

3. 服务功能  

4. 服务相关联的策略等信息

服务描述模型如下图所示：

需要注意的是：

1. 服务描述本质上是不完整的，但当参与者可以根据所提供的描述访问和使用所描述的服务时，即可认为服务是足够的

2.服务描述包含充分支持上下文所需的信息：如服务版本

服务接口描述

服务接口是什么？服务接口是与服务交互的手段。

服务接口描述模型如下图所示：

服务接口描述应包含行为模型和信息模型。

行为模型应包含Action模型与Process模型。

Process模型中应说明使用的信息交互模式MEP。

MEP属于服务交互模型的内容，我们在这进行说明如下。

MEP

MEP是指信息交互模式，MEP是Process模型中的关键元素。

MEP是逻辑视图，不是物理视图，MEP特性于实现，是实例化服务交互的一部分。

主要有两种信息交互模式：

1. 请求/响应

请求/响应MEP模型如下图所示，服务消费者代理（不强制要有代理的角色）发送请求，服务提供者代理响应请求，有关为什么有代理的原因，我们争取在后期给大家分享。

本篇文章的主要目的是分享SOA系统相关的模型，为实现SOA系统提供一种参考。

需要说明的是，请求/响应是一个操作，因此会导致真实世界效果。

2. Event通知

Event通知 MEP 如下图所示。

基于事件通知的MEP采用单向消息形式，由通知程序组件（上图中为服务提供者代理组件）发送，并由感兴趣的组件（上图中为服务消费者代理组件）接收。

之所以会有Mediator的原因是，发布/订阅消息可能会由于网络中断或通信中断而导致Event通知丢失，因此，常用第三方中介组件来解耦发送和接收组件。

交互信息相关的内容，应在信息模型中指定。

举个简单的示例如下：

上图中，我们建立一个名为  ' radarInterface1 '的服务接口模型。

描述Action模型为 ' Event订阅 '

在Process模型中，建立Event通知MEP，并定义一个名为 ' brakeEvent ' 的事件

定义该接口上交互的信息为 ' RadarObject '

定义该接口上交互的信息格式为 ' Structure '

服务可达性

服务可达性是服务可见性模型中的属性之一（这里对服务可见性模型进行说明）

服务可见性由意识、意愿和可达性组成。

服务可见性是什么？服务可见性是指在服务可以互操作之前，参与者必须使用适当的方式相互可见。

意识

在 SOA 系统中，可以通过交互或基于注册表/存储库中的服务描述来实现意识。

意愿

获得意识后，参与者使用服务描述来帮助确定他们与其他参与者互动的意愿。意识和意愿都是在消费者/供应商交互之前确定的。

服务可达性

服务可达性是为了使服务参与者能够相互定位和交互；

可达性涉及了解服务的端点、协议和存在行。

端点：表示行为的概念位置，对于服务描述，它指实际发送消息的实际地址。

协议：定义服务交互机制的细节，一种结构化的通信方法。

存在性：对服务在特定时间点的可达性的度量

可达性需要有服务位置和描述通信方式的协议等信息。服务可达性模型如下图所示：

举个例子如下：

上图中，我们使用SOME/IP这个协议，当然也可以自定义。

基于SOME/IP协议

定义服务ID为：99

服务版本为：1.0

事件ID为：1

传输层协议为：UDP

定义使用的IP地址为：192.168.2.1

定义服务实例ID为：19

服务功能

接下来，我们看一下服务功能相关的模型。

服务功能描述了与服务交互的预期结果，功能代表某些领域内的活动，可产生所需的真实世界效果。

需要注意的是服务功能可能受到技术假设/约束的限制，但是真实世界效果必须与技术假设/约束一致。

服务功能模型如下图所示：

举例说明如下：

上图中，我们定义该接口提供的功能为：提供雷达数据

技术假设为：一次调用后输出3组数据

服务级别真实世界效果应为：一次调用后会输出3组有效的雷达数据

当然，还有Action级别相关的真实世界效果等内容，比较容易理解，上图中没有体现。

服务策略与合同模型

服务策略规定了与服务交互的条件和约束

策略是约束的表达，由确保约束可行的利益相关者发布

合同是参与者之间的协议

策略与合同有一个共同特性是：必须强制执行约束

策略与合同相关的模型如下（下图中包含参与者的角色）

举个例子如下图所示：

上图中，我们描述了一个简单的服务策略：需要对服务访问者的身份进行识别，只有 ' fusion '服务查找时再响应。

需要注意的是，使用时，需要考虑策略冲突的问题，可以通过使用策略优先级来应对策略冲突的发生。

服务描述模型使用

上述，我们对服务描述建模进行了说明，接下来，我们从服务描述模型使用的角度进行分享。

服务描述使用的模型如下图所示

需要说明的是，Action 通常通过Message 调用的，调用Action的结果是一个或多个真实世界效果。任何Action级别的真实世界效果都必须反映在包含该Action的服务级别的真实世界效果中。

将参与者加入模型后，示例如下图所示：

上图中，服务提供者和服务消费者通过访问服务描述建立 '意识'。

套用我们前面例举的 ' radarInterface1 ' 的相关的服务描述，这里我们定义服务提供者为 'radar'，定义服务消费者为 'fusion'（当然需要开发相应的代码，这部分内容不属于建模实现的部分，这里不做说明）。

当 'radar' 和 ' fusion '完成交互时，会产生相应的真实世界效果（笔者做的demo实在虚拟机上完成的，交互的结果是，fusion输出接收到的三组数据，当然在此之前会设计相应的ARXML文件）。

当然，在设计的过程中，要对协议的一致性进行考虑，这属于执行上下文相关的内容，比较简单，一般不用特意考虑，因此这里也不做赘述。

还有为方便后期追溯，要对交互产生的结果进行日志记录，在设计时考虑即可。

上述便是对实现SOA系统建模相关的四个模型进行的分享。

服务组合模型

最后简单说明一下服务组合模型。

服务组合是从一个或多个其他服务组合单个服务的行为。

服务组合所涉及的原则是：

松耦合

选择性透明或不透明

动态交互

......

举个简单的例子，如下图所示

上图中，服务 'radar' 具有一个服务接口 'radarInterface' ，且依赖于其他两个服务。

但是对于 ' fusion '来说，它不知道服务 'radar_ipc' 跟 'radar_someip'被服务 'radar'使用，它只关心 'radar' 服务的成败。

'radar_ipc' 跟 'radar_someip' 服务被作为服务 'radar'组合的一部分。

当然，在 'fusion' 通过 'radar'服务访问 'radar_someip'时，需要设计相关的执行流程。

本期分享就到这里，我们下期见。

声明：本文内容及图片由BC-AUTO转载至网络, 信息来源于搞一下汽车电子。