SOA复习大纲

发表于 分类于 阅读次数： Disqus： 本文字数： 8.5k 阅读时长 ≈ 31 分钟

SOA技术简述

为什么要引入SOA、SOA要解决的问题

为什么要引入SOA：需求拉动、技术推动

  1. Internet环境下的企业交互：现代企业已经不再是封闭的企业，市场分工的日益专业化使得企业之间可能存在大量频繁的交互行为，以发挥各自的竞争优势。这种业务上的交互体现为企业业务流程的交互/互操作，同时一定需要企业信息系统的支持，因此体现为软件系统之间的集成与互操作
  2. 异构系统的集成与互操作：技术平台不同、软件体系结构不同、数据格式不同
  3. 频繁变化的互操作与集成需求：企业的业务是频繁变化的，IT应用系统要能够快速支持这种变化的需求，需要迅速、敏捷、高效的调整业务应用系统

SOA要解决的问题：

  1. 分布式企业间业务的协同
  2. 通过Internet连接在一起的异构企业应用软件系统的集成、交互与互操作
  3. 当业务(Business)发生变化时，IT系统能够快速响应

什么是SOA、核心要素及其理解

SOA=Service(服务)+体系结构(Architecture)

  • 业务模型：企业向其客户暴露的一系列业务——服务
  • 体系结构：一组体系结构设计原则与模式，强调模块化、封装、松散耦合、分离关注点、可复用、可组合性、接口与实现分离等特性
  • 软件实现方式：一种编程模式，包括一系列的标准、开发工具、开发过程指南、运行时基础架构

SOA三要素：标准化封装、复用、松耦合可编排

SOA的典型优势

  1. 分布式异构系统的集成与互操作
  2. 完全的松散耦合
    • 位置透明
    • 与具体的实现细节无关(通过接口调用)
    • 标准化的通讯协议（XML-Based）
  3. 大数据量低频率访问
  4. 基于文本的消息传递：基于文本的消息本身不包含任何处理逻辑和数据类型，因此服务间只传递文本，双方不存在兼容性问题
  5. 上下文无关：在SOA中，在设计阶段，服务不需要了解它们将来可能被复用的环境，即独立于服务使用者的上下文
  6. 大粒度复用：更多的关注诸如业务过程/业务活动级别的复用，复用效率更高

SOA适合应用的场景

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

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

  • 硬连线(Hard-wired)
  • 点对点的服务发布与调用(P2P)
    • 发布(Publish)：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。
    • 发现(Find)：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
    • 绑定(Bind)和调用(invoke)：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。
  • 服务适配器(Service adaptor)
    • 企业中存在若干遗留系统(legacy system)采用较传统的技术开发，无法提供清晰的接口(interface)，但其他系统仍然需要访问这些遗留系统的功能。通过构造**适配器(adaptor)**，将遗留系统中的功能进行二次包装，从而开放出接口供其他系统使用。
  • 服务代理(Service proxy)
    1. 客户端直接绑定服务接口(WSDL/URI)
    2. 客户端通过“service registry”来访问服务，当希望访问其他服务时，只要手工修改该registry即可——相当于一个配置文件
    3. 客户端通过“service broker”来动态决定需访问那个服务。完全动态的服务选择，很困难，需要用到服务语义的相关技术
  • 远程服务策略(Remote service strategy)
  • 单点访问(Single point of access)
  • 虚拟服务提供者(Virtual provider)
  • 服务集成器(Service integrator)
    1. 将remote service strategy的思想进一步发挥，客户端不去逐一调用服务，而是首先将这些被调用的服务按逻辑关系集成起来，形成一个集成的、大粒度的服务
    2. 客户端只需调用这一个服务即可
    3. 当该服务执行时，集成器(integrator)依靠配置信息来分别调用一个个小粒度的服务
    4. 对这些配置信息进行修改，即可方便的做到变更
  • 企业服务总线(Enterprise service bus)
    • 路由服务间的消息
    • 转化请求者和服务之间的传输协议
    • 转换请求者和服务之间的消息格式
    • 处理分离资源间的业务事件
  • 集成化的服务生态系统(Integrated service ecosystem)

Web服务基础

Web服务概念

传统上，我们把计算机后台程序提供的功能，称为“服务”（service）。通俗地说，“服务”就是计算机可以提供的某一种功能。

  • 本地服务：使用同一台机器提供的服务，不需要网络。

  • 网络服务：使用另一台计算机提供的服务，必须通过网络才能完成

  • Web服务是一种面向服务的架构的技术，通过标准的Web协议提供服务，目的是保证不同平台的应用服务可以互操作

  • 根据W3C的定义，Web服务应当是一个软件系统，用以支持网络间不同机器的互动操作。网络服务通常是许多应用程序接口（API）所组成的，它们透过网络，例如国际互联网（Internet）的远程服务器端，执行客户所提交服务的请求

  • Web Service架构的基本思想，就是尽量把非核心功能交给其他人去做，自己全力开发核心功能。

简单来说，Web Service就是一个向外界暴露出接口的能够通过网络进行远程调用的应用程序。更准确地说：

  • 一方面Web Service是一种部署在Web上的对象
  • 另一方面Web Service是建立在以XML为主的、开放的Web标准协议规范的基础上的分布式应用新平台

Web Services（Web服务）定义：

  • Web Service是一种新的 Web 应用程序分支，它们是自包含、自描述、模块化的应用，可以在网络(通常为 Web)中被描述、发布、查找以及通过 Web 来调用
  • 使用标准的互联网协议，像超文本传输协议 HTTP 和 XML
  • Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service

SOAP

什么是SOAP？

  • SOAP 指简易对象访问协议(Simple Object Access Protocol)
  • SOAP 是一种通信协议
  • SOAP 用于应用程序之间的通信
  • SOAP 是一种用于发送消息的格式
  • SOAP 被设计用来通过因特网进行通信
  • SOAP 独立于平台
  • SOAP 独立于语言
  • SOAP 基于 XML
  • SOAP 很简单并可扩展
  • SOAP 允许您绕过防火墙
  • SOAP 将被作为 W3C 标准来发展

SOAP(Simple Object Access Protocol)：

  • 基于XML实现了一种消息格式以交换请求和使用，使用XML作为SOAP消息的基础使得任何实现基本的网络通信服务的系统都能处理和传送这类消息
  • SOAP的整个消息结构非常简单。除了消息结构外，SOAP没有定义额外的表述结构标准，没有定义自己的编码标准，没有定义自己的传输协议
  • SOAP可以使用任意的模式定义方式来定义内部传输内容的结构（编码方式一般使用XML Schema），可以与任意的网络传输方式来完成传

一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：

  • 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
  • 可选的 Header 元素，包含头部信息
  • 必需的 Body 元素，包含所有的调用和响应信息
  • 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息

SOAP消息基本结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
 ...
</soap:Header>

<soap:Body>
 ...
 <soap:Fault>
 ...
 </soap:Fault>
</soap:Body>

</soap:Envelope>
  • SOAP Envelop 元素：必需的 SOAP 的 Envelope 元素是 SOAP 消息的根元素。它可把 XML 文档定义为 SOAP 消息
    • xmlns:soap 命名空间：SOAP 消息必须拥有与命名空间 “http://www.w3.org/2001/12/soap-envelope“ 相关联的一个 Envelope 元素
    • encodingStyle 属性：定义在文档中使用的数据类型
  • SOAP Header 元素：可选的 SOAP Header 元素可包含有关 SOAP 消息的应用程序专用信息（比如认证、支付等）。如果 Header 元素被提供，则它必须是 Envelope 元素的第一个子元素
  • SOAP Body 元素：必需的 SOAP Body 元素可包含打算传送到消息最终端点的实际 SOAP 消息
  • SOAP Fault 元素：SOAP Fault 元素用于存留 SOAP 消息的错误和状态信息。如果已提供了 Fault 元素，则它必须是 Body 元素的子元素。在一条 SOAP 消息中，Fault 元素只能出现一次

HTTP请求方法：

  • GET 请求获取Request-URI所标识的资源
  • POST 在Request-URI所标识的资源后附加新的数据
  • HEAD 请求获取由Request-URI所标识的资源的响应消息报头
  • PUT 请求服务器存储一个资源，并用Request-URI作为其标识
  • DELETE 请求服务器删除Request-URI所标识的资源
  • TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
  • CONNECT 保留将来使用
  • OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

HTTP 在 TCP/IP 之上进行通信。HTTP 客户机使用 TCP 连接到 HTTP 服务器。在
建立连接之后，客户机可向服务器发送 HTTP 请求消息：

1
2
3
4
POST /item HTTP/1.1
Host: 189.123.345.239
Content-Type: text/plain
Content-Length: 200

随后服务器会处理此请求，然后向客户机发送一个 HTTP 响应。此响应包含了可指示请求状态的状态代码：

1
2
3
200 OK
Content-Type: text/plain
Content-Length: 200

在上面的例子中，服务器返回了一个 200 的状态代码。这是 HTTP
的标准成功代码。假如服务器无法对请求进行解码，它可能会返回
类似这样的信息：

1
2
400 Bad Request
Content-Length: 0

SOAP 方法指的是遵守 SOAP 编码规则的 HTTP 请求/响应（HTTP + XML = SOAP
）。SOAP 请求可能是 HTTP POST 或 HTTP GET 请求。HTTP POST 请求规定至少两个 HTTP 头：Content-Type 和 Content-Length。

  • Content-Type：SOAP 的请求和响应的 Content-Type 头可定义消息的 MIME 类型，以及用于请
    求或响应的 XML 主体的字符编码（可选）。
  • Content-Length：SOAP 的请求和响应的 Content-Length 头规定请求或响应主体的字节数。

SOAP请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
 <soap:Body xmlns:m="http://www.example.org/stock">
    <m:GetStockPrice>
        <m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
 </soap:Body>
 
</soap:Envelope>

SOAP 响应：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

    <soap:Body xmlns:m="http://www.example.org/stock">
        <m:GetStockPriceResponse>
            <m:Price>34.5</m:Price>
        </m:GetStockPriceResponse>
    </soap:Body>

</soap:Envelope>

客户发送请求时，不管客户是什么平台，首先把请求转换成XML格式，SOAP网关可自动执行这个转换。为了保证传送时参数、方法名、返回值的唯一性，SOAP协议使用了一个私有标记表，从而服务器的SOAP网关可以正确地解析；而使用XML作为编码表现形式，提供了更高层次上的抽象，从而实现与平台和环境的无关

WSDL

什么是WSDL：

  • WSDL 指网络服务描述语言(Web Service Description Language)
  • WSDL 使用 XML 编写
  • WSDL 是一种 XML 文档
  • WSDL 用于描述网络服务
  • WSDL 也可用于定位网络服务
  • 这种文档可描述某个 Web service，它可规定服务的位置，以及此服务提供的操作（或方法）

WSDL(Web Service Description Language)定义了一套基于XML的语法，将Web服务描述为能够进行消息交换的服务访问点的集合。是Web服务的接口描述语言，包含以下内容：

  • What：Web服务做什么——所提供的操作
  • Where：Web服务位于哪里——协议相关的地址，如URL
  • How：怎样调用——和服务交互的数据格式以及必要协议

WSDL主要元素：

WSDL文档实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?xml version="1.0">
<definitions name="urn:AddressFetcher2" ...>
    <types>
        //定义服务使用的任何复杂数据类型
    </types>
    <message name=" GetLastTradePriceInput ">
        //调用者和服务之间传递的一条消息，要用到前面定义的数据类型
    </message>
    <portType name=" StockQuotePortType ">
        //定义服务提供什么操作，要用到前面定义的消息
    </portType>
    <binding name="StockQuoteSoapBinding "
        //定义服务如何被调用
    </binding>
    <service name="StockQuoteService ">
        //描述服务位于哪里
    </service>
</definitions>

WSDL概念模型：

UDDI

什么是UDDI：

  • UDDI 是一个独立于平台的框架，用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。
  • UDDI 指的是通用描述、发现与集成服务
  • UDDI 是一种用于存储有关 web services 的信息的目录。
  • UDDI 是一种由 WSDL 描述的 web services 界面的目录。
  • UDDI 经由 SOAP 进行通信
  • UDDI 被构建入了微软的 .NET 平台

UDDI是统一描述、发现和集成（Universal Description, Discovery, and Integration）的缩写。它是一个基于XML的跨平台的描述规范，可以使世界范围内的企业在网络上发布自己所提供的服务。
UDDI计划是一个广泛的，开放的行业计划，它使得商业实体能够：

  • 彼此发现
  • 定义他们怎样在internet上互相作用，并在一个全球的注册体系架构中共享信息

UDDI数据表类型：

  • 白页：包含了基本的企业信息
  • 黄页：按分类法对企业信息进行分类
  • 绿页：包含了如何与企业进行电子交互的信息

UDDI的信息模型：

  1. businessEntity元素：支持对UDDI商业注册的商业信息发布和发现的核心XML元素都包含在该结构中，这个结构是商业实体专属信息集的最高层的数据容器，位于整个信息结构的最上层
  2. businessService元素：将一系列有关商业流程或分类目录的Web服务的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了”绿页”信息
  3. bindingTemplate元素：对于每一个businessService，存在一个或多个Web服务的技术描述bindingTemplate
  4. tModel元素：是一个技术规范的超类，tModel能够描述商业标示符数据库、分类方法、技术规范、网络协议等各类的技术规范，是UDDI Web服务元数据管理的基础

UDDI的工作原理：

Web服务实现【实验1指导书及任务】

如何开发自己的Web服务(Java平台为例)

如何访问调用已有的Web服务（生成代理类）

REST基础

REST是什么、有何关键特性、如何理解、无状态性的设计方式及优缺点

REST是英文REpresentational State Transfer的缩写，表象化状态转变，或者表述性状态转移

REST架构风格以资源为核心进行设计，从资源的角度来观察整个网络。网络上的所有事物都是资源，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表述。

  • 资源（Resources）：任何寄宿于Web可供操作的“事物”均可视为资源
  • 表现层（Representation）：把”资源”具体呈现出来的形式，叫做它的”表现层”
  • 状态转化（State Transfer）：互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。而这种转化是建立在表现层之上的，所以就是”表现层状态转化”

三者关联

  • 每一个URI代表一种资源
  • 客户端和服务器之间，传递这种资源的某种表现层
  • 客户端通过四个HTTP动词，对服务器端资源进行操作，实现“表现层状态转化”

REST的关键特性：

  • 采用URL标识资源：标志性、可读性、可寻址性（Addressability）
  • 使用统一的接口：是针对不同资源的Web API定义一致性的操作来操作它们
  • 使用标准的HTTP方法：Web API分别针对CRUD的操作只能接受具有对应HTTP方法的请求
  • 支持多种资源表示方式：我们一般利用请求的Content-Type报头携带的媒体类型来判断其采用的表示类型
    • 让请求URI包含资源表示类型
    • 采用“内容协商（Content Negotiation）”根据请求相关报头来判断它所希望的资源表示类型，比如“Accept”和“Accept-language”报头可以体现请求可以接受的响应媒体类型和语言

REST架构六个特点：客户端——服务器的、无状态的、可缓存的、统一接口、分层系统、按需编码

RESTful无状态性：

  1. 客户端-服务器通信中的每个请求必须包含所有必要信息：服务器不会存储关于客户端状态的信息（如会话信息）。这意味着每个请求都应当独立，服务器通过请求中的信息来理解并处理该请求。
  2. 服务器不保存任何客户端请求的历史记录：每个请求都是独立的，服务器不依赖之前的请求或响应来处理当前的请求。
  3. 认证和授权数据随每次请求发送：由于服务器不保存会话状态，所以每次请求都需要包含认证信息（如果需要的话），比如令牌或API密钥。
  • 优点：简化服务器设计、提高可伸缩性、改善可靠性和可用性、便于缓存处理
  • 缺点：可能增加网络负担、客户端复杂性增加、性能开销、安全风险

Why REST

为什么要基于API开发：

  • API让web，手机客户端，桌面多种操作成为可能，程序员分工更加明确，切降低了开发成本
  • 软件开发依赖解耦
  • 让编程语言发挥各自的优势

REST优势：

  • 将用户界面和数据存储分离，提高用户界面跨多个服务平台
  • 一个好的架构应该可以很轻松的为不同的请求返回不同格式的数据
  • 使用REST的最佳的场景是对外提供公开的服务，也就是所谓的OpenAPI，也有的人认为REST更适合资源导向的网站，像youtube这样的网站
  • REST 的真正价值在于 Web Services，而不是通过浏览器操作的应用程序
  1. 轻量级、HTTP
  2. 无状态请求可以由任何可用服务器回答，分布式、缓存、云计算
  3. 资源唯一URL、标准接口
  4. 基于成熟HTTP的安全模型
  5. 简单、人类友好…

REST与MVC的关联对比、与RPC的对比

REST与MVC：

  • MVC风格将模型、视图、控制解耦，其结构整洁、逻辑清晰，易于扩展和增强。MVC偏重于解决服务器端的逻辑分层问题，以及客户端是逻辑分层的延伸问题。但是MVC很难实现跨语言解耦。
  • REST风格偏重于统一接口，具体实现可以跨平台和跨语言。REST使用纯HTML作为客户端，没有服务器端和客户端的耦合。
  • MVC和REST并不是互斥的，如Spring的MVC模块已经开始支持REST式的开发，Jersery也实现了MVC的功能。

REST与RPC：

  • REST服务是一种ROA（Resource Oriented Architecture）应用，其主要特点是方法信息存在于HTTP协议的方法中，作用域存在于URI中，风格更轻量和快速。
  • 从方法信息角度，REST采用标准的HTTP方法，RPC请求都是HTTP协议的POST方法，其方法信息包含于SOAP协议包或HTTP协议包中，方法名称不具有通用性。
  • 从作用域角度看，REST采用URI显示定义作用域，而RPC这一信息同样包含于协议包中，不能直观呈现。
  • RPC风格的开发关注于服务器-客户端之间的方法调用，是面向方法调用过程的，而REST是面向资源状态的。
  • 备注：PRC风格的两个代表是XML-RPC和SOAP Service

REST API设计

统一接口、安全性幂等性

HTTP方法基本特性：安全性、幂等性

  • 安全性是指外系统对该接口的访问，不会使服务器资源的状态发生改变

  • 幂等性（Idempotent）是一个数学上的概念，在这里是指外系统对同一REST接口的多次访问，得到的资源状态是相同的。在网速不够快的情况下，客户端发送一个请求后不能立即得到响应，由于不能确定是否请求是否被成功提交，所以它有可能会再次发送另一个相同的请求，幂等性决定了第二个请求是否有效。

  • GET：HTTP的GET方法用于读取资源。GET方法是幂等的，因为读取同一个资源，总是得到相同的数据。GET方法也是安全的，因为读取资源不会对其状态做改动。JAX-RS2.0指出了@GET注释对资源方法的定义，使得该方法用于处理GET请求。

  • PUT：PUT方法是幂等的，即多次或者更新统一份数据，在服务器端对资源状态所产生的改变是相同的。PUT方法不是安全的，有写动作的HTTP方法都不是安全的。

  • DELETE：方法是幂等的，即多次删除同一份数据（通常请求中传递的参数是数据的主键值），在服务端产生的改变是相同的。JAX-RS 2.0定义了 @DELETE注释来定义相关资源方法。

  • POST：定义为POST的REST接口用于写数据。POST方法的特性是既不幂等也不安全。因为请求会改变服务器端资源的状态，因此不是安全的；每次请求对服务器资源状态的改变并不是相同的，因此不是幂等的

资源定位、资源路径设计

对外提供REST式的Web服务的接口就是公布一系列的URI及其参数

资源地址的设计过程是面向资源的，资源名称应是准确描述该资源的名词，资源地址应具有直观的描述性。比如一个班级的资源地址可以是：学校/学院/年级/班级。值得注意的是，一个URI资源地址唯一对应一个资源，但是一个资源可以拥有多个URI资源地址。比如Jersey最新版本的文档地址和Jersey2.9版本的文档地址指向同一个资源。

资源路径概览：

注意：资源地址相同，但HTTP方法不同的两个方法是两个不同的REST接口。HTTP方法和资源地址结合在一起才可以完成对资源的定位。

@RequestMapping：

  • 用来处理请求地址映射，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。
  • 默认请求方法是GET
    • @GetMapping 等同于 @RequestMapping(method =
    • RequestMethod.GET)
    • @PostMapping 等同于 @RequestMapping(method =
    • RequestMethod.POST)
    • @PutMapping 等同于 @RequestMapping(method =
    • RequestMethod.PUT)
    • @DeleteMapping 等同于 @RequestMapping(method =
      RequestMethod.DELETE)

@PathVariable：

  • 获取url中的数据
  • 通过@PathVariable注解来获取URL中的参数时的前提条件是我们知道url的格式时怎么样的。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    // 获取 url=localhost:8080/hello/id/name 中的id、name值
    @RestController
    public class HelloController {

        @RequestMapping(value="/hello/{id}/{name}",method= RequestMethod.GET)
        public String sayHello(@PathVariable("id") Integer id,@PathVariable("name") String name){
            return "id:"+id+" name:"+name;
        }
    }

@RequestParam：获取请求参数的值

1
2
3
4
5
6
7
8
9
// 获取 url=localhost:8080/hello?id=98 中的id值
@RestController
public class HelloController {

    @RequestMapping(value="/hello",method= RequestMethod.GET)
    public String sayHello(@RequestParam("id") Integer id){
        return "id:"+id;
    }
}

Controller请求与URL重构：

【实验2指导书和任务】：如何开发和调用Restful API services

服务组合技术

服务编排

服务编排（Orchestration）：将多个小粒度的Web服务按照特定的业务逻辑规则构造为一个可执行的业务过程，同时又可以看作是一个大粒度的复合Web服务。

  • 执行时需要有中心控制机制
  • 由一个组织所拥有
  • 侧重点：如何使用已有的服务来构造新的服务

BPEL能够实现基于WSDL的Web Services之间的流程编排和服务协同，它提供了一种XML注释和语义，用于指定对Web Services进行编排并确定Web服务之间的业务流程，实现Web Services之间的协同。

  • 过程中的基本功能单元：活动
  • 活动之间的次序关系：
    • 先后次序
    • 多分支
    • 循环
    • 并发与同步
    • 非确定性选择
  • 过程的相关数据：容器
  • 错误处理机制：、
  • 补偿机制：

运行模式：

  • 集中式的执行引擎
  • 基于Hub的分布式引擎
  • 无Hub的分布式引擎

服务协同

服务协同（Choreography）：将多个零散的、分别由多方提供的服务/业务流程按照彼此之间的协同关系组织起来，支持多方的交互行为。

  • 侧重于不同服务之间的消息传递的次序与规则，以保证期望的协同行为。
  • 无需中心控制；
  • 无需完全由一个组织所拥有；

分类：

  • 链式协同模式（Chained）
  • 同步协同模式（Synchronized）
  • 嵌套协同模式（Nested）
  • 复合模式

两者比较

二者在协议栈中的位置（协同位于编排之上）：

服务业务流程

BPEL规范

业务流程执行语言（Business Process Execution Language, BPEL, 发音为’bipple’或’bee-pell’），也叫业务过程执行语言，是一种基于XML的，用来描写业务流程的编程语言，被描写的业务流程的每个单一步骤则由Web服务来实现。

  • BPEL是基于Web服务的，并且依赖于WSDL。
  • 一个BPEL流程可以发布为一个WSDL定义的服务，并像其它Web服务一样被调用。而且，BPEL希望一个Web服务合成所包含的全部外部Web服务，都是用WSDL服务契约定义的，这令BPEL流程可以调用其它BPEL流程，甚至可以递归的调用自己。
  • 值得注意的是BPEL不直接支持人机对话，BPEL所描写的过程仅与Web服务通信，而这些Web服务却可以提供与用户的信息交换，但它们不是用户本身。
  • 用BPEL编写的流程可以在任何支持BPEL规范的平台或产品上运行。

协议基础：

  • WS—BPEL是基于XML定义的流程描述语言，它位于几个XML规范之上：WSDLl.1、XML Schemal.0和XPathl.0。
  • 其中WSDL消息和XML Schema类型定义提供了BPEL流程所用的数据模型;XPath为数据处理提供支持;所有的外部资源和伙伴被表示成WSDL服务。

BPEL包含的范围：

  • 处理活动的顺序，特别是网络服务互操作。
  • 消息和处理实例之间的关系。
  • 在发生错误和例外情况下的恢复行为。
  • 处理角色之间的基于网络服务关系的双面性

BPEL引入元素：

  1. 伙伴链接
  • BPEL把与流程交互的其他服务称为伙伴。一个流程可以调用其他服务，也可以响应来自客户端的请求。一个流程既可以作为服务的请求者，也可以扮演服务的提供者。在异步通信环境中，流程与伙伴之间的会话可能是双向的，它们会扮演不同的角色。因此，为了消除在通信过程中的多义性，我们需要明确服务和流程所扮演的角色
  • 伙伴链接用于实现Web服务长期稳定的交互，描述伙伴之间的关联。这种动态伙伴关系为流程带来了极大的灵活性，也增强了流程的可复用性
  • 伙伴链接类型声明了两个或多个服务之间的关系
  • 伙伴链接类型定义了一组角色，其中每个角色指明一组Port Type，即明确了该角色所提供的服务接口，一边接收会话的上下文消息。 如果partnerLinkType仅有一个角色，那么将根据需要省略其中一个属性
  1. 变量
  • 在BPEL中，可以使用变量来保存和传递流程的状态信息。它们通常是从合作伙伴那里接收到消息，或者是被发送给合作伙伴的消息。同时，它们还有可能是与流程有关的状态消息，这些消息并不与合作伙伴进行交换
  • 由WSDL文件所定义的消息类型(message type)，表示允许变量包含WSDL定义的整个信息；由XML Schema所定义的简单类型(simple type)，表示一个XSD元素结构;由XML Schema所定义的元素(element)，表示一个XSD简单结构，比如：string ,integer
  • 变量是有作用域的。属于全局流程作用域的变量称为全局变量；属于流程作用域的变量称为局部变量
  1. 活动
  • BPEL是由一系列步骤组成，这些步骤称为活动
  • 基本活动描述了流程内的一个具体步骤，如接受请求、调用伙伴服务、变量赋值等，是与外界进行交互最简单的形式，活动内不会嵌套其它活动。它们是无序的个别步骤，与服务进行交互、操作、传输数据或者处理异常等
  • 结构化活动描述了如何组织和管理流程的控制流，规定了一组活动发生的顺序。他们描述了业务流程是怎样通过把它执行的基本活动组成结构而被创建的，这些结构表达了涉及业务协议的流程实例间的控制形式、数据流程、故障和外部事件的处理以及消息交换的协调。结构化的活动可以被任意地嵌套和组合
  • 关联集合
  • 事件处理程序
  • BPEL事务与补偿机制
  • BPEL异常管理

部分元素之间关系：

  • 流程是由一系列的活动组成的；
  • 流程通过伙伴链接来定义与流程交互的其他服务；
  • 服务中可以定义一些变量；
  • 流程可以是有状态的长时间运行过程，流程引擎可以通过关联集合将一条消息关联到特定的流程实现。

BPEL引擎

活动详解：Receive(接收)/Reply(回答)

活动从流程的外部伙伴那获得数据，并将其保存到流程变量。

  • 通常一个Receive是一个流程的初始点，它会阻塞执行直到匹配的消息的到达。
  • 在异步信息交换时，receive也可以接收回收信息。

元素有5个属性：

  • partnerLink:在通信过程中识别伙伴
  • portType:从伙伴方接收请求消息的接口
  • operation:接收请求消息
  • variable:用来存储接收到的请求消息
  • createInstance:当该属性设置为”yes”时，它指明了当前流程接收到匹配消息是会创建新的流程实例来处理该请求

活动发送消息给伙伴来应答通过Receive活动所接收到的消息。

  • Receive和Reply的组合对应着WSDL portType上定义的一个请求—响应操作。
  • 如果receive活动对应着一个单向操作，则不能在流程中定义对应的reply活动。

元素也有5个属性：

  • 其中，partnerLink，portType和operation含义同receive元素的属性含义相同。
  • variable:用来存储从伙伴返回的消息
  • messageExchange：这是一个WS-BPEL2.0新增加的可选的属性。它使得reply元素可以精确的关联到一个能够接收信息的活动（比如 receive元素）

包含receive/reply活动的片段：

1
2
3
4
5
6
7
8
9
10
<receive name="receiveInput" 
    partnerLink="client" 
    portType="tns:TimesheetSubmissionInterface" 
    operation="Submit" 
    variable="ClientSubmission" createInstance="yes"/>

<reply partnerLink="client" 
    portType="tns:TimesheetSubmissionInterface" 
    operation="Submit" 
    variable="TimesheetSubmissionResponse"/>

注意：

  1. 在实例4中：receive和reply活动中都是通过partnerLink来引导预定义伙伴关系的，而且需要设置portType和operation属性来声明流程实现的WSDL portType和操作
  2. 如果将receive活动作为流程的起始点，则需要将receive活动的createInstance属性设置为”yes”，它指明了当前流程接收到匹配消息是会创建系的流程实例来处理该请求

【实验3-4指导书及任务】编排微服务及运行监控实例流程