《SOA原理与技术》学习笔记（二）——SOA技术概述

文章目录

二、SOA技术概述

1. 为什么要引入SOA（需求拉动和技术推动）
2. SOA的三个核心要素
3. SOA的典型优势
4. SOA适合应用的场景
5. 10种SOA应用场景及相应体系结构模式

二、SOA技术概述

1. 为什么要引入SOA（需求拉动和技术推动）

需求拉动
- Internet环境下的企业交互
  
  市场分工的日益专业化使得企业之间可能存在大量频繁的交互行为，以发挥各自的竞争优势
- 异构系统的集成与互操作
  
  不同企业所应用的软件系统是不同的(异构的)，集成这些分布式的软件系统，在它们之间传递数据和消息，是一件非常困难的事情。
- 频繁变化的互操作与集成需求
  
  企业的业务是频繁变化的；
  企业间的协同关系也不是固定的，随着业务流程的变化而随之变化；
  企业的IT应用系统要能够快速支持这种变化的需求

SOA所要解决的问题
- 分布式企业间业务的协同。
- 通过Internet连接在一起的异构企业应用软件系统的集成、交互与互操作。
- 当业务(Business)发生变化时，IT系统能够快速响应。

技术推动
- 计算环境
  
  计算环境包含了一组计算机、软件平台、协议和相互联通的网络，在该环境中，计算机之间、软件平台之间可通过网络按照协议实现数据交换和信息处理。
- 软件体系结构
  
  软件体系结构是指构成软件系统的软件元素、软件元素外部可见的属性以及这些软件元素之间的关系
- 软件生产方式
  
  软件系统设计、开发、测试、运行、管理的理念、原则和方法
- 软件体系结构的改变
  
  集中式整体~ → 分布式~ → 面向服务~
- 软件工程的演变
  
  结构化设计、面向对象、面向构件、面向服务
- 软件技术发展过程中，一直在寻求解决四个基本问题的方法：质量问题、效率问题、互操作问题、柔性构造问题
  
  屏蔽异构性
  实现互操作
  共性凝练和复用
  
  软件技术发展内容，包括更好的程序设计语言、更好的平台和软件开发技术。这些技术推动因素，从本质上是通过复用、松耦合、互操作(标准)等机制来提高软件质量、加快软件研发效率、使研发出来的产品能够相互集成并灵活适应变化。
如何理解SOA

与印刷术类比的思想

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XVdJTNmg-1585222483466)(note_images\1.8理解SOA)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AxDQ6CbU-1585222483468)(note_images\0.1印刷术和SOA.png)]$

2. SOA的三个核心要素

三个途径来达到灵活性：

标准化封装

传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。

在软件的互操作方面，传统中间件只是实现了访问互操作，即通过标准化的API实现了同类系统之间的调用互操作，而连接互操作还是依赖于特定的访问协议，如JAVA使用RMI。

而SOA通过标准的、支持Internet、与操作系统无关的HTTP协议实现了连接互操作。而且，服务的封装是采用XML协议，具有自解析和自定义的特性，这样，基于SOA的中间件还可以实现语义互操作。
复用

从软件复用技术的发展来看，就是不断提升抽象级别，扩大复用范围。
松耦合可编排

在这里插入图片描述

3. SOA的典型优势

分布式异构系统的集成与互操作
松散耦合

服务接口作为与服务实现分离的实体而存在，从而服务实现能够在完全不影响服务使用者的情况下进行修改。
大数据量低频率访问
基于文本的消息传递

服务间只传递文本，双方不存在兼容性问题。
上下文无关

在SOA中，在设计阶段，服务不需要了解它们将来可能被复用的环境，即独立于服务使用者的上下文。
大粒度复用，复用效率更高

SOA中的服务是大粒度复用体，它更多的关注诸如业务过程/业务活动级别的复用，复用效率更高。
另外，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的信息交换。
SOA本质特征

将“服务”(自治的、平台独立的计算实体，可被描述、发布、发现、动态组装)作为基本的构造单元；
任何应用均可看作是一组协同运作的服务；
从而，以快速的、低成本的、容易组合的方式去创建高度分布式的、协同的、动态变化的、跨越组织与计算平台边界的服务系统。

4. SOA适合应用的场景

协同—交互—异构—分布式环境—可能频繁变化

5. 10种SOA应用场景及相应体系结构模式

“发布-查询-绑定”模式：点对点的服务发布与调用(P2P)

What：

How：

在这里插入图片描述
实现机制：Web Service

在这里插入图片描述

服务适配器模式：Service adaptor或Service Wrapper

What：

企业中存在若干遗留系统(legacy system)；
这些系统采用较传统的技术开发，无法提供清晰的接口(interface)；
但其他系统仍然需要访问这些遗留系统的功能

How：

通过构造适配器(adaptor)，将遗留系统中的功能进行二次包装，从而开放出接口供其他系统使用。
远程服务策略

What：

客户端为了使用服务，必须在自己的程序中写入调用服务的代码，即通过服务的URI地址来访问服务。
这导致客户端与服务之间的耦合度过大，系统的灵活性受到限制。

How：

将这种绑定关系从代码中抽取出来

① 客户端直接绑定服务接口(WSDL/URI);
② 客户端通过“service registry”来访问服务，当希望访问其他服务时，只要手工修改该registry即可——相当于一个配置文件；
③ 客户端通过“service broker”来动态决定需访问那个服务；——完全动态的服务选择，很困难，需要用到服务语义的相关技术。

在这里插入图片描述

服务集成器

What：

如果客户端需要同时或连续调用多个服务的功能，它必须在自己的系统中分别写出多个调用；——非常麻烦；
而且，对多个服务的调用次序也是容易发生变化的，需要频繁的修改；——难以做到

How：

降低耦合度
将remote service strategy的思想进一步发挥，客户端不去逐一调用服务，而是首先将这些被调用的服务按逻辑关系集成起来，形成一个集成的、大粒度的服务；
客户端只需调用这一个服务即可；
当该服务执行时，集成器(integrator)依靠配置信息来分别调用一个个小粒度的服务；
对这些配置信息进行修改，即可方便的做到变更。
企业服务总线(Enterprise Service Bus, ESB)

What：

SOA的重要目标就是要在分布式环境下实现多组织之间业务的交互与协同；因此独立存在的服务是没有意义的；
即使采用上面的service integrator，一个组织中存在的和使用的服务数量仍然是巨大的，它们之间的关系也很复杂。
必须提供一种手段，能够将多方提供的服务集成在一起，并试图构造一种通用的服务基础设施来管理它们。

How：

企业服务总线(Enterprise Service Bus)是一个整合应用和服务的灵活的连接基础组织，支持实现多个服务的编排。

ESB在请求者和服务之间实现了：
- 路由服务间的消息
- 转化请求者和服务之间的传输协议
- 转换请求者和服务之间的消息格式
- 处理分离资源间的业务事件
ESB体系结构：