经常有朋友提到，SOA到底是个啥玩意，为了搞清楚SOA是什么，以及SOA怎么做？本篇文章给大家分享一下SOA的核心概念。
What 参考模型？
由于SOA相关的核心概念是在SOA参考模型中进行描述的，因此，我们先来看一下SOA参考模型是什么？文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型概念文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型是一个抽象框架，用于理解某些环境的实体之间的重要关系。文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型由特定问题域内的最小一组统一概念，公理和关系组成，并且独立于特定标准，技术，实现或其他具体细节。文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型属性文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型支持使用标准和规范来开发特定的参考架构或具体架构。文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型独立于特定标准、技术、实现和其他具体细节。文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
参考模型举例文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
为了说明参考模型与可以从参考模型派生的架构之间的关系，笔者这里以住宅的建模过程为例进行说明。如下图所示文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
上图中，参考模型就好比我们当前在图纸上划分出了一个餐区，一个休息区。但未具体说明这个餐区或休息区是什么，只是进行一个概念上的说明。文章源自线束工程师之家-https://www.suncve.com/what-exactly-is-soa/
根据参考模型给出的区域划分，给出一个参考架构：基于餐区这个概念，结合实际的一些情况，我们设定了做餐区和就餐区；基于休息区这个概念，结合实际的需求，我们设定了睡觉区和休闲区。这是一个抽象层面的设计，不跟实际物体进行绑定。
进一步，我们结合实际的需求，我们加上厨具等将做餐区实现为一个可以使用的厨房。而这个厨房可以理解为基于参考架构的一个具体实现。
从上述例子可以看出，参考模型的目的是提供一个概念框架，确保不同实现之间的相互一致性。
SOA核心概念
与SOA相关的核心概念主要包括三大方面：
- 服务
- 服务动态
- 服务自身相关概念
接下来笔者将会对上述核心概念进行详细说明。
服务
服务定义
SOA的全称是：面向服务的架构。
那面向服务的架构中的服务怎么理解？笔者认为服务是一种启用对一个或多个功能的访问的机制。
其中，服务的访问是使用规定的接口提供的，并且根据服务描述指定的约束和策略来执行。（后面会对服务描述、策略等概念进行详细说明）
服务说明
服务是由实体（服务提供者）提供的，供其他人使用。但是服务提供者可能并不知道服务的最终使用者（服务消费者）是谁。也将服务提供者与服务消费者统称为服务参与者。
这里需要说明的是，服务提供者和服务服务消费者的概念是基于服务这个概念的上下文环境存在的。
服务的访问是通过服务接口实现的，其中该接口包含有关如何访问基础功能的详细信息。对于什么构成基本功能或服务提供者如何实现访问没有任何限制。因此，服务可以通过自身可以调用其他可用服务的一个或多个自动或手动过程来执行其描述的功能。
服务是不透明的，因为它的实现通常对服务使用者隐藏。
调用服务的结果是实现了一个或多个真实世界效果（后文会详细说明）。
这些影响可能包括：响应请求而返回的信息或更改已定义的实体的共享状态等。
服务动态
从动态的角度，有三个概念对于理解与服务交互中涉及的内容很重要：
- 服务提供者和消费者之间的可见性
- 服务之间的交互
- 服务交互的真实世界效果
可见性
定义
为了使服务提供者和消费者彼此互动，他们必须能够“彼此见面”。
可见性是服务消费者和服务提供者之间能够进行交互时满足的关系。
举个代码中的例子：一个程序调用另一个程序，如果没有正确的库，则函数调用就无法完成。而正确的库就是服务可见性的一种表现。
实现可见性的前提是意识，意愿和可及性。 即服务交互中的发起者必须了解其他各方；参与者必须易于进行交互；并且参与者必须能够进行交互。
意识
意识是一种状态，是指一方了解另一方的存在，即服务提供者和服务使用者都必须具有使他们知道对方存在的信息。
意识并不意味着意愿或可及性。服务产品的意识通常受各种发现机制的影响。为了能够使服务消费者发现服务，服务提供者必须能够将服务的详细信息（尤其是服务描述和策略）提供给潜在的消费者。
从技术上讲，最主要的要求是服务交互的发起者必须具有响应者的信息。
意愿
意愿是指与所有服务交互相关联是有意图的–这是启动和参与服务交互的有意行为。
例如，如果服务消费者通过其在注册表中的描述发现了服务，并且消费者发起了交互，此时，如果服务提供者不合作，则可能没有交互。这就会导致服务无法响应。服务无法响应就是服务意愿的表现。
服务参与者参与服务交互的意愿程度可能是服务策略的内容，这些策略可能记录在服务描述中。
可达性
可达性是服务参与者之间能够交互的关系。
可达性是服务交互的必要先决条件 —— 即参与者必须能够相互通信。
服务之间的交互
在许多情况下，服务交互是通过发送和接收消息来完成的。当然，还有方式如，修改共享资源的状态等，但是简单起见，通常我们将消息交换称为与服务交互的主要方式。
如下图所示为服务交互相关的概念：
从上图中可以看出，服务交互主要包括：
- 信息模型
- 行为模型
信息模型
服务的信息模型是指可以与服务交换的信息的特征，通常只包含可能与服务交换的信息和数据。
信息模型的范围包括交换的信息的格式，信息内的结构关系以及所用语义的定义。
信息内的结构主要包括字符数据的编码、数据格式和与信息元素相关的结构数据类型。
语义主要用于保障信息的一致性解释。
需要注意的是服务消费者和服务提供者实际上不会在交互中交换语义的描述
行为模型
服务成功交互的关键要求是了解服务调用的操作、服务交互的过程或时间等，上述内容被表征为对服务行为、服务行为响应以及他们之间的时间依赖性。即行为模型。
例如在对数据库的安全控制访问中，服务消费者可用的操作包括提供凭证、请求数据库更新和读取查询结果等均为行为模型相关的内容。
行为模型包含两个子模型：
Action模型：针对服务调用的动作的表征。
Process模型：表征与服务相关的动作和时间的时间关系以及时间属性。
真实世界效果
真实世界效果是指试图让服务做某些事。
例如，可以使用航空公司预定服务来了解可用的航班、作为并最终成功订票。理想情况下的真实世界效果是乘坐上正确航班上的正确座位。
如前文所说，真实世界效果可以是对信息请求的响应；也可以是服务参与者共享某些已定义的实体的状态变化，这些状态不一定是保存在物理存在中的状态变量，也可以是受实体影响的共享信息。
当服务提供者和服务消费者进行交互时，会导致共享状态的修改。而这些共享状态变化的积累就是服务交互的真实世界效果。
服务自身相关
上述笔者从可见性、服务交互、真实世界效果等方面介绍了与服务动态相关的几个核心概念。接下来笔者将介绍一些与服务自身相关的核心概念。目的是为了支持服务交互的动态性。
与服务自身相关的概念主要包括：
- 服务描述
- 策略与合同
- 执行上下文
服务描述
下图所示为与服务描述相关的一些其他的概念
面向服务的体系结构的标志之一是大量相关的文档和描述。
服务描述表示使用服务所需的信息。在大多数情况下，没有一个“正确”的描述，而是所需的描述元素取决于上下文和使用关联实体的当事方的需求。
服务描述的目的是促进交互和可见性，尤其是当参与者在服务交互中的参与者之间处于不同所有权域时。通过提供描述，潜在参与者可以构建使用服务甚至提供兼容服务的系统。
例如可以进行以下描述：
描述服务参与者在服务交互的如何区分其他服务；
描述服务是否提供所需的能力：
描述如何访问服务，以及协商特定的服务功能。
虽然 SOA 的概念支持在服务消费者不需要知道服务实现的细节的情况下使用服务，但服务描述提供了消费者需要的关键信息，以便决定是否使用服务。服务消费者需拥有的信息项如下：
- 服务存在且可达
- 该服务执行某项功能或一组功能；
- 服务在一组指定的约束和策略下运行；
- 服务将（在某些隐含或明确的程度上）遵守服务消费者规定的策略；
- 如何与服务交互以实现所需目标，包括服务与消费者之间交换的信息的格式和内 容以及可能预期的信息交换顺序。
需要说明的是服务描述允许重用标准定义，例如功能和服务策略（后面会进行说明）等。
接下来笔者将从服务相关的属性等方便对服务描述进行深入说明。
服务可达性
可达性是服务提供者与服务消费者之间固有的关系。
服务描述应该包含足够的数据来启用服务，这可能包含元数据、如服务的位置以及服务提供和需要的信息；还可以包含有关服务的动态信息，如它当前是否可用等。
服务功能性
服务描述应该清楚地表达服务的功能和由它被调用产生的真实世界的效果。
功能描述可以包含旨在消费的文本描述或引用特定集齐可处理的标识符或关键字，部分功能描述可能包括基础技术假设，这些假设确定服务或基础能力公开的功能限制。
服务相关策略描述
服务描述可以包括支持将策略与服务相关联，并为潜在的消费者提供必要的信息，以评估服务是否以与消费者的约束一致的方式运行。
服务接口描述
服务接口是与服务交互的手段。
它包括特定的协议、命令和信息交换。通过这些特定的协议、命令和信息交换，可产生通过服务描述的服务功能部分指定的真实世界效果的操作。
需要注意的是，假设要使服务可用，其接口必须以允许其消费者解释接口信息的格式表示。
服务描述限制
完全和明确地指定服务的精确语义和所有相关信息是不可能的。因此，服务的描述者总是会做出一些未说明的假设，这些假设必须被描述的读者隐式共享。
策略与合同
服务策略
从概念上讲，策略包含三方面的内容：
策
- 略声明
- 策略所有者（策略主题）
- 策略执行
策略始终代表的是参与者的观点。
例如：服务消费者声明“所有消息都已加密”，这就反映了服务消费者的策略。该策略可由服务消费者独立于来自服务提供者的任何协议而声明。
从概念上讲，服务策略的执行就相当于确保策略声明与真实世界效果一致。策略执行是为了防止执行未经授权的操作或进入位置状态，这可能意味着检测到违反策略时启动补偿措施。
需要注意的是，不可执行的约束不是策略；服务参与者与服务策略之间的联系点在服务描述中体现。
服务策略主要分为两大类，一类是面向基础设施的策略，如安全性、隐私、可管理性、服务质量等。一类是面向业务的策略，如服务存在时间、服务回滚策略等。
服务合同
上述我们对服务策略进行了描述，服务策略一般与单个参与者有关，而服务合同一般是指两个或多个参与者之间的协议。
服务合同可以覆盖服务的多个方面：
- 服务质量协议
- 服务接口
- 服务编排协议
- 服务业务协议
需要说明的是，与服务参与者的策略执行不同，服务合同可能涉及解决各方之间的冲突与争端。
执行上下文
定义
执行上下文是基础结构元素、流程实体、策略声明和协议的集合，这些元素被标识为实例化服务交互的一部分。
执行上下文不限于交互的一侧；相反，它涉及交互的整体——包括服务提供者、服务消费者和调解交互所需的公共基础设施。
例如，可以将消费者和提供者设想为地图上的独立位置，并且要实际调用服务，必须在这两个位置之间建立路径。此路径是执行上下文。
说明
执行上下文是服务交互的许多方面的核心。
例如，它定义了与服务交互相关的策略实施的决策点。请注意，策略决策点不一定与执行点相同：即执行上下文本身并不适合执行。另一方面，策略的任何执行机制都可能考虑实际执行上下文的细节。
执行上下文还允许我们区分服务。
同一服务的不同实例（例如，表示给定服务提供者和不同服务消费者之间的交互）的区别在于它们的执行上下文不同。
最后，执行上下文也是交换数据的解释发生的上下文。特定字符串在特定上下文（执行上下文）中的服务交互中具有特定含义。
执行上下文通常在服务交互期间演变。例如，在交互的初始点，各方可能决定未来的通信应该加密。因此，执行上下文也会发生变化。
总结
SOA核心概念，要想搞清楚SOA，首先我们要先要知道SOA相关的一些概念。因此，笔者系统的分享了有关SOA的核心概念。总结如下：
服务
将服务消费者和服务提供者结合在一起的方法，是一个独立的，可重复的活动。
服务动态
可见性：服务交互的倾向与能力。
服务交互：服务需要进行的活动。
真实世界效果：服务交互产生的后果
服务本身相关的概念
服务描述：确定访问需求，即服务交互。包括服务接口，服务策略关联等。
策略与合同：参与者之间的约束或者其他使用的条件声明
执行上下文：为实现所描述的效果，需遵守的一致性协议
SOA实施
最后，我们来看一下SOA参考模型（核心概念）与其他分布式系统架构输入的关系。如下图所示。由于下图牵扯到了SOA参考架构的概念，笔者在图文这里先不做解释，留在SOA参考架构分享完成后进行解释。
SOA是什么？
基于SOA相关的核心概念，我们再来捋一下SOA的概念：
面向服务的架构SOA是一个范式，它不是一种真正的技术，它提供了一种通过一的方式来提供、发现、交互和使用功能。
实现SOA的方式有很多种，而Web服务只是其中一种。
本期分享就到这里，我们下期见。
推荐阅读：
一文看懂，Adaptive AUTOSAR从入门到精通（一）
