CN110521188B - 网络服务层中的分布式事务管理 - Google Patents

Abstract

分布式服务层事务(DSLT)可以由通信网络的服务层处的DSLT服务支持，以卸载应用管理DSLT的处理的负担。

Description

网络服务层中的分布式事务管理

对相关申请的交叉引用

本申请要求于2017年3月17日提交的标题为“Methods to Enable DistributedTransaction Management at the IoT Service Layer”的美国临时专利申请No.62/472,851的权益，其内容通过引用整体并入本文。

背景技术

事务(transaction)可以是需要作为单元执行的操作集或操作序列。该操作集可以紧密相关(例如，出于功能或业务原因)并且作为单元，它们或者需要全部成功执行，或者都不执行。事务可以具有四个特征，即，原子性、一致性、隔离性和持久性(ACID)。原子性意味着无论事务有多少请求或步骤，它们都必须像执行单个请求一样被执行。它们必须都成功执行或都不执行。不允许部分执行。一致性是指在执行事务之前和之后，事务的目标的状态必须一致。一致性与原子性紧密相关。隔离意味着事务需要彼此隔离，并且它们不能相互干扰。持久性意味着一旦提交事务，系统就需要保证事务的结果是安全和持久的。结果能够承受突然的误动，并且能够在恢复后恢复到该结果。近来，已经做出努力来解决机器对机器(M2M)或物联网(IoT)网络中的事务处理。

发明内容

本文公开了用于在通信网络的服务层为分布式事务处理提供支持的方法、装置和系统。这些方法、装置和系统可以在支持DSLT处理能力的分布式服务层事务(DSLT)服务中实施，以便使应用摆脱管理DSLT自身处理的复杂性和负担。DSLT处理能力可以包括DSLT服务代表应用来管理DSLT的原子处理的能力；DSLT服务代表应用来管理DSLT序列的原子处理的能力；DSLT服务协调组成DSLT或DSLT序列的各个请求的调度的能力；DSLT服务使应用能够定义DSLT或DSLT序列的执行标准的能力；DSLT服务使应用能够定义DSLT或DSLT序列的重传策略的能力；DSLT服务使应用能够定义DSLT或DSLT序列的完成标准的能力；DSLT服务使应用能够定义DSLT或DSLT序列的优先级的能力；以及DSLT服务向应用提供发起DSLT或DSLT序列的简单RESTful API的能力。

在一个方面，实现DSLT服务的通信网络上的第一服务层实体可以从在通信网络上执行的应用接收对分布式事务的请求。该请求可以指定要在由通信网络的多个其它服务层实体托管的作为目标的资源集上原子执行的命令。响应于该请求，第一服务层实体可以向多个其它服务层实体中的每个服务层实体发送锁定由该其它服务层实体托管的任何目标资源的请求。然后，第一服务层实体可以从多个其它服务层实体中的每个服务层实体接收响应，该响应指示服务层实体是否能够锁定由那个服务层实体托管的目标资源。如果第一服务层实体接收到指示所有作为目标的资源都被锁定的响应，那么第一服务层实体然后可以向多个其它服务层实体发送请求，以对作为目标的资源集执行命令的原子执行。如果第一服务层实体接收到指示已对作为目标的资源集成功执行了命令的响应，那么第一服务层实体可以向多个其它服务层实体发送提交分布式事务的请求。然后第一服务层实体可以向应用发送指示已成功执行分布式事务的响应。

根据另一方面，第一服务层实体可以在从应用接收到对分布式事务的请求后在第一服务层实体的存储器中创建表示分布式事务并包括关于分布式事务的状态的信息的资源。资源可以经由通信网络让应用可访问，以使应用能够监视事务的状况。资源可以包括唯一地识别事务的事务标识符属性，以及其中存储与分布式事务的状态有关的信息的事务状态属性。资源还可以包括控制第一服务层实体何时发起对分布式事务的请求的处理的执行时间属性。

提供本发明内容是为了以简化的形式介绍一些概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或所有缺点的限制。

附图说明

可以从以下结合附图的示例给出的描述中获得更详细的理解，其中，其中：

图1是图示支持服务层的示例性协议栈的图。

图2是图示部署在各种类型的网络节点上的M2M/IoT服务层(SL)的图。

图3是图示oneM2M体系架构的图。

图4是图示oneM2M公共服务功能的图。

图5是图示oneM2M体系架构所支持的配置的图。

图6是图示oneM2M<transaction>资源的图。

图7是图示oneM2M事务处理(成功情况)的图。

图8是图示oneM2M事务处理(故障情况)的图。

图9是图示演示SL事务管理的有用性的智能工厂用例的图。

图10是图示用于分布式服务层事务(DSLT)的最小SL解决方案的图。

图11是图示用于DSLT的完整SL解决方案的图。

图12是图示DSLT部署选项的图。

图13是图示分布式服务层事务管理功能(DSLT-MF)的图。

图14是图示分布式服务层事务客户端功能(DSLT-CF)的图。

图15是图示针对个体DSLT的DSLT-TF处理的图。

图16是图示针对个体DSLT的DSLT-MF处理的图。

图17是图示针对个体DSLT-CF的DSLT-CF处理的图。

图18是图示针对DSLT序列的DSLT-TF处理的图。

图19是图示针对DSLT序列的DSLT-MF处理的图。

图20是图示针对DSLT序列的DSLT-CF处理的图。

图21是图示个体DSLT过程的图。

图22是图示DSLT序列化过程的图。

图23是图示OneM2M中的事务管理CSF的体系架构实施例的图。

图24是图示oneM2M资源的面向DSLT的属性的图。

图25是图示oneM2M DSLT序列资源的图。

图26是图示对oneM2M<group>资源的DSLT增强的图。

图27是图示oneM2M DSLT组扇出过程的图。

图28是图示oneM2M DSLT序列化过程的图。

图29是图示服务层事务用户界面的图。

图30A是包括通信网络的M2M/IoT/WoT通信系统的图。

图30B是在现场域中示出的M2M服务层的图，该M2M服务层为M2M应用、M2M网关设备、M2M终端设备和通信网络提供服务。

图30C是可以用于实现本文描述的任何逻辑实体的示例性装置的图。

图30D是可以用于实现本文描述的任何逻辑实体的计算机系统或服务器的框图。

具体实施方式

以下是在以下描述中可能出现的首字母缩写词列表。除非另有说明，否则本文中使用的首字母缩写词是指下面列出的相应术语：

ADN 应用专用节点

AE 应用实体

API 应用编程接口

ASN 应用服务节点

CSE 共同服务实体

CSF 共同服务功能

DSLT 分布式服务层事务

DSLT-CF 分布式服务层事务客户端功能

DSLT-MF 分布式服务层事务管理功能

DSLT-TF 分布式服务层事务触发功能

DSLT-REQ 分布式服务层事务请求

DSLT-TRIGGER 分布式服务层事务触发请求

IN 基础设施网络

IoT 物联网

IP 互联网协议

M2M 机器对机器

MN 中间节点

NoDN 非oneM2M节点

PoA 接入点

ROA 面向资源的体系架构

SL 服务层

URI 统一资源标识符

而且，以下术语可以在下面的描述中使用，并且除非另有说明，否则这些术语可以具有以下含义：

M2M/IoT服务层可以是软件中间件层，其通过应用编程接口(API)和底层网络接口的集合来支持针对M2M/IoT应用和设备的增值服务。

M2M/IoT应用可以是以特定的M2M/IoT用例(例如，eHealth、智能能源、家庭自动化)为目标的应用。

服务层实体可以是M2M/IoT应用或M2M/IoT服务层的实例。

服务层资源可以是由M2M/IoT服务层托管的唯一可寻址对象。

服务层请求可以是由服务层实体发布的以服务层资源为目标的操作。

服务层事务可以是服务层请求的集合或序列，其需要作为单元被原子地执行，使得它们全部被成功执行或都不被执行。

分布式服务层事务可以是服务层事务，其以由在不同网络节点上托管的多个服务层实体所托管的资源集为目标。

分布式服务层事务管理功能可以是能够与分布式服务层事务客户端功能交互并管理对这些功能的分布式服务层事务的原子处理的服务层功能。

分布式服务层事务客户端功能可以是能够与分布式服务层事务管理功能交互并接收和处理各个分布式服务层事务的服务层功能。

分布式服务层事务触发功能可以是能够与分布式服务层事务管理功能交互并发起分布式服务层事务的服务层功能。

分布式服务层事务触发请求可以是由分布式服务层事务触发功能向分布式服务层事务管理功能发送以发起分布式服务层事务的请求。

分布式服务层事务请求可以是由分布式服务层事务管理功能向分布式服务层事务客户端功能散布(disseminated)以执行分布式服务层事务的请求。

在机器对机器(M2M)或物联网(IoT)网络中，服务层(SL)是专门旨在为M2M/IoT设备和应用提供增值服务的技术。最近，若干行业标准机构(例如，oneM2M[oneM2M TS-0001oneM2M Functional Architecture-V-3.0.0.]、ETSI[ETSI TS 102690 Machine-to-Machine communications(M2M)Functional architecture V2.0.13.]、OCF[OCF–OICSpecifications，V1.1]和LWM2M[OMA LWM2M Specifications，V1.0])正在开发M2M/IoTSL，以解决与将M2M/IoT设备和应用集成到具有互联网/Web、蜂窝、企业和家庭网络的部署中相关联的挑战。

M2M/IoT服务层可以向应用和设备提供对面向M2M/IoT的能力的集合的访问。一些示例包括安全性、收费、数据管理、设备管理、发现、供应和连接性管理。这些能力经由应用编程接口(API)提供给应用，这些API利用M2M/IoT SL支持的消息格式、资源结构和资源表示。

从协议栈的角度来看，SL通常位于应用协议层之上，并为其支持的应用提供增值服务。因此，SL常常被归类为“中间件”服务。图1示出了在应用协议104和应用106之间的示例性服务层102。

从部署的角度来看，M2M/IoT SL 102可以部署在各种类型的网络节点上，包括如图2中所示的服务器、网关和设备。实现服务层功能或以其它方式结合服务层的实例的通信网络的任何此类节点、服务器、网关、设备、装置或其它逻辑实体在本文中可以被称为服务层实体。

oneM2M标准[oneM2M TS-0001]定义了M2M/IoT SL，其目的是提供可被不同的“垂直”M2M系统和应用(诸如e-健康、车队管理和智能家居)使用的“水平”服务。如图3中所示，oneM2M SL的体系架构定义了实施服务层并支持四个参考点的公共服务实体(CSE)302。Mca参考点与应用实体(AE)304接口。Mcc参考点与同一服务提供商域中的另一个CSE 306接口，并且Mcc参考点与不同服务提供商域中的另一个CSE接口。Mcn参考点与基础网络服务实体(NSE)接口。NSE 308向CSE提供底层网络服务，诸如设备管理、位置服务和设备触发。CSE包含多个称为“通用服务功能(CSF)”的逻辑功能，诸如“发现”、“数据管理&储存库”，它们共同构成服务层的功能。图4图示了由oneM2M支持的CSF。托管在通信网络的节点、服务器、网关、设备、装置或其它逻辑实体上的CSE的每个实例在本文中都可以被称为网络的服务层实体。

oneM2M体系架构是分布式体系架构并支持在以下类型的节点上以分布式方式部署M2M/IoT服务：

■应用服务节点(ASN)：ASN是包含一个CSE并包含至少一个应用实体(AE)的节点。例如，ASN可以驻留在M2M设备中。

■应用专用节点(ADN)：ADN是包含至少一个AE并且不包含CSE的节点。例如，应用专用节点可以驻留在受约束的M2M设备中。

■中间节点(MN)：MN是包含一个CSE且包含零个或多个AE的节点。例如，MN可以驻留在M2M网关中。

■基础设施节点(IN)：IN是包含一个CSE并且包含零个或多个AE的节点。IN中的CSE可以包含不适用于其它节点类型的CSE功能。例如，IN可以驻留在M2M服务基础设施中。

■非oneM2M节点(NoDN)：非oneM2M节点是不包含oneM2M实体(AE和CSE都不包含)的节点。此类节点表示出于互通目的(包括管理)而连接到oneM2M系统的设备。

在图5中图示了互连oneM2M系统内支持的各种实体的可能配置。

最近，oneM2M已经开始致力于定义对SL事务的支持。这项工作记载在oneM2M TR-0020中，Study of service transactions and re-usable service layer context，V0.6.0。迄今为止，已经定义了一种解决方案。以下是这种解决方案的摘要。

<transaction>资源可以是任何其它资源的孩子。它指示父资源是事务的目标。根据<transaction>资源的状态，在目标资源上执行oneM2M原语。<transaction>资源的结构如图6中所示，表1提供了其属性的描述。

表1–oneM2M<transaction>资源属性

图7和图8示出了在oneM2M系统中如何使用<transaction>资源处理事务的流程。图7示出了成功情况下的oneM2M事务处理。图8示出了故障情况下的oneM2M事务处理。这个处理涉及一个AE和多个CSE。AE负责发起并管理跨多个CSE的事务协调。每个步骤的详细描述如下。

在图7和8的步骤1中，AE 702在多个CSE上创建<transaction>资源。<transaction>被创建为每个作为目标的资源的子资源。<transaction>资源包含事务的执行时间以及要执行的原语。不同CSE的执行时间相同，以保证协调事务的提交。原语还包含要执行的原语的发起者的身份、操作和内容。

在图7和8的步骤2中，在已接收到<transaction>创建请求的每个CSE 704、706和708处，CSE 704、706和708检查<transaction>是否可以被成功执行。该检查可以包括访问权限检查、检查原语的格式正确，以及可以在指定的时间执行检查。

在图7的步骤3(成功)中，如果检查成功，那么CSE 704、706和708向AE 702响应创建了<transaction>资源并且<transaction>资源的父资源已被置于保留状态。在保留状态下，资源将拒绝任何其它可能在指定的执行时间破坏原语成功执行效果的请求。

在图7的步骤4(成功)中，在指定的执行时间，每个CSE 704、706和708将执行对应的原语。

在图8的步骤3(失败)中，如果对任何CSE的检查失败(在这个示例中为CSE 708)，那么CSE 708以失败响应对AE进行响应。在接收到任何失败的响应时，AE 702确定不能跨所有CSE自动执行事务。AE 702因此将向已成功创建<transaction>资源的每个CSE(在此示例中为CSE 704和706)发送删除请求，以便在计划的执行时间之前将其删除。这将取消事务。

在图8的步骤4(失败)中，已成功创建<transaction>的CSE(在这个示例中为CSE704和706)删除该事务。

以下用例有助于理解M2M/IoT网络中对事务处理能力的需求。考虑智能工厂用例，诸如具有多个机器人904、906和908的图9的生产装配线902。这些机器人904、906和908必须彼此保持紧密同步，以正确地组装由装配线生产的产品。如果修改了其中一个机器人的设置，那么通常需要对在同一装配线上操作的其它机器人进行对应的修改，以确保机器人保持彼此一致的操作状态。工厂中的所有装配线均由工程师从位于工厂控制室的对应远程管理站进行监视和控制。从这些工作站，可以由工程师远程监视并控制用于每条相应装配线的机器人。由于关闭装配线以对机器人执行维护非常昂贵，因此工厂正在寻找使停机时间最小化以及甚至在装配线仍运行时执行维护的方法。为此，工程师希望能够以紧密协调的方式修改机器人的设置。他们还希望能够基于检测到装配线机器人不再在指定正常范围内操作来触发这些更新的功能。当发生这种情况时，工程师希望触发对机器人904、906和908的设置配置的更新，以在情况变得更糟之前进行校正。这需要能够发送分布式事务以基于触发事件来修改机器人设置。还需要使这个事务以原子方式更新关于多个机器人904、906和908的设置，以使机器人保持一致操作并且装配线继续运行而不必将其取下来。在这样做时，可以确保工程师仅在所有机器人都能够成功改变其设置的情况下才对机器人904、906和908的设置进行改变。如果一个或多个机器人无法成功改变其设置，那么不会改变任何机器人设置。这有助于防止装配线在机器人不再一致运行的状态下结束。工程师不必开发复杂的应用来协调这些原子事务对机器人的管理，而是希望将这种复杂性卸载到IoT服务平台的事务管理能力。

迄今为止，执行以分布式资源集为目标的原子事务的复杂性和负担完全落在发起这些事务的应用以及构建和部署这些应用的开发人员的肩膀上。随着最近由大量分布式设备组成的IoT网络部署的规模和复杂性的增加，这些应用和开发人员将承受的负担越来越大。因此，诸如oneM2M之类的IoT/M2M服务层技术最近已经认识到需要协助应用来管理分布式事务的需求。

到目前为止，仅定义了用于分布式服务层事务(DSLT)管理的非常基本和最小的以SL为中心的解决方案。例如，oneM2M[oneM2M TR-0020]中定义的当前解决方案仍然严重依赖于应用来管理DSLT。应用仍然负责发起构成DSLT的每个单独请求，并将这些请求发送到各个作为目标的资源。应用仍然负责监视这些单独请求中的每一个的进展，以确定它们中的任何一个是否导致故障以及整个DSLT是否需要中止。如果需要中止DSLT，那么应用负责跟踪它需要向其发送取消请求的目标。应用还负责跟踪DSLT的执行时间并确保在这个定时器到期之前这些取消请求的发送发生，以使得构成DSLT的各个请求都在执行时间过去之前被取消。因此，在应用上仍然存在管理DSLT的相当大的开销和负担，如图10中所示。

在图10的步骤1中，应用1002将事务请求发送到多个设备1004、1006和1008。

在图10的步骤2中，设备1004、1006和1008检查以查看它们是否可以成功执行事务。

在图10的步骤3中，设备1004、1006和1008回复应用1002，指示它们是否可以执行事务。在这个示例中，设备1008无法执行事务。

在图10的步骤4中，由于其中一个设备(设备1008)无法执行事务，因此在其它设备(设备1004和1006)处中止事务。

本文描述的是一种分布式服务层事务(DSLT)服务，该服务支持DSLT处理能力，从而使应用摆脱必须自己管理DSLT的处理的复杂性和负担。DSLT处理能力可以包括让DSLT服务代表应用来管理DSLT的原子处理的能力；让DSLT服务代表应用来管理DSLT序列的原子处理的能力；让DSLT服务协调构成DSLT或DSLT序列的各个请求的调度的能力；让DSLT服务使应用能够定义用于DSLT或DSLT序列的执行标准的能力；让DSLT服务使应用能够为DSLT或DSLT序列定义重传策略的能力；让DSLT服务使应用能够定义DSLT或DSLT序列的完成标准的能力；让DSLT服务使应用能够定义DSLT或DSLT序列的优先级的能力；以及让DSLT服务向应用提供简单的RESTful API的功能以发起DSLT或DSLT序列的能力。

关于DSLT服务代表应用来管理DSLT的原子处理的能力，服务本身可以是分布式的，并且可以由可以跨托管在不同网络节点上的多个服务层实体部署的DSLT管理功能和DSLT客户端功能组成。当DSLT的处理完成时，应用可能只需要向服务发送单个请求来发起DSLT并从服务接收回响应。服务可能不需要应用与任何个体DSLT目标进行通信或在其生命周期内管理DSLT。服务可以在处理DSLT期间维持DSLT状态，该状态可以被用于提供处理状况并在发生故障的情况下启用DSLT的回滚。服务可以管理与DSLT相关联的各个请求的分布式集合的成功分发和执行，使得在发生任何故障的情况下，它可以执行各个请求的回滚和中止操作，使得可以满足DSLT的原子性要求。

关于DSLT服务代表应用来管理DSLT序列的原子处理的能力，DSLT序列可以由DSLT的集合组成，这些DSLT可以由服务代表应用以原子方式排序并执行。服务可以管理DSLT序列的成功执行，使得在发生任何故障的情况下，它可以执行序列的回滚和中止操作，使得可以满足序列的原子性要求。

关于DSLT服务支持可配置的DSLT策略引擎的能力，策略引擎可以由可编程的DSLT策略集合来配置。策略引擎可以支持DSLT策略，诸如调度策略、重试策略、优先化策略、执行标准策略、完成标准策略和排序策略。DSLT策略可以定义控制服务如何处理DSLT的规则。

关于DSLT服务协调构成DSLT或DSLT序列的各个请求的调度使得它们在满足应用的要求并且还满足DSLT目标(例如，仅具有间歇性网络连接的IoT设备)的要求的时间窗中执行的能力，服务可以协调作为DSLT目标的IoT设备的可达性时间表，以帮助确保所有必需的设备均在线且可用，使得可以对其所有作为目标的设备成功执行DSLT并满足DSLT的原子执行要求。服务可以确保以相同的(一个或多个)资源为目标的多个DSLT或DSLT序列不同时执行，因为每个DSTL都必须获得其(一个或多个)目标资源的锁以确保其对应的事务被隔离执行且不受到干扰。

关于DSLT服务使应用能够定义用于DSLT或DSLT序列的执行标准的能力。执行标准可以被服务用来触发以及限定是否以及何时执行(一个或多个)DSLT。执行标准可以包括用于一个或多个指定的SL属性或元数据的阈值/值、基于对历史以及当前条件(诸如一个或多个设备的状态或一个或多个资源状态的状态)的分析的SL定义的事件、SL从应用或第三方服务或底层网络接收或检测到的外部触发条件，或者另一个SL事务的成功完成。

关于DSLT服务使应用能够定义用于DSLT或DSLT序列的重传策略的能力。重传策略可以被服务用来限定是否以及何时执行(一个或多个)DSLT的失败的执行将导致服务重试(一个或多个)DSLT。

关于DSLT服务使应用能够定义用于DSLT或DSLT序列的完成标准的能力。完成标准可以被服务用来限定是否以及何时(一个或多个)DSLT的执行是成功的，这取决于构成(一个或多个)DSLT的各个请求的结果。例如，成功完成可以要求在某个时间窗口内完成，或者一些DSLT可以只要求部分请求成功完成，而其它DSLT可以要求所有请求都必须成功。

关于DSLT服务使应用能够定义DSLT或DSLT序列的优先级的能力，如果需要并且在需要时(例如，当DSLT共享相同的目标并且它们的执行必须被序列化时)，优先级可以被服务用来相对于彼此将(一个或多个)DSLT排名并基于这个排名对它们的执行进行排序。

关于DSLT服务向应用提供简单的RESTful API来发起DSLT或DSLT序列的能力，API可以为每个DSLT定义SL事务标识符。API可以为DSLT序列定义SL序列标识符。而且，API可以支持不阻塞来自应用的发起、查询状况或中止DSLT或DSLT序列的请求的能力。

图11从应用的角度图示了用所公开的DSLT服务可以实现的复杂性的降低。

在图11的步骤1中，应用1002将事务请求发送到服务器1102。服务器1102可以是具有包含DSLT服务的服务层的IoT服务器1102。服务器1102负责事务的管理。通过将事务的管理从应用1002转移到服务器1102(如图10中所做的那样)，可以简化应用1002处的操作。

在图11的步骤2中，服务器1102将DSLT请求散布到多个设备1004、1006和1008。

在图11的步骤3中，设备1004、1006和1008进行检查以查看它们是否可以成功执行事务。

在图11的步骤4中，设备1004、1006和1008回复服务器，指示它们是否可以执行事务。在这个示例中，设备之一(设备1008)无法执行事务。

在图11的步骤5中，由于一个设备(设备1008)无法执行事务，因此该事务在其它设备(设备1004和1006)处中止。

在图11的步骤6中，服务器1102将响应发送到应用1002。

将图11与图10进行比较，已大大降低了管理DSLT的IoT应用1002的开销和复杂性。利用所描述的DSLT服务，IoT应用1002可以用单个请求和响应来执行DSLT，而在现有解决方案中，它要求更多消息和更多内部逻辑来管理每个事务的状态。

下文描述所公开的DSLT服务的更多细节。

DSLT体系架构

在一个实施例中，DSLT服务可以包括分布式服务层事务触发功能(DSLT-TF)1202、分布式服务层事务管理功能(DSLT-MF)1204和1206以及分布式服务层事务客户端功能(DSLT-CF)1208、1210、1212和1214。

DSLT-TF 1202可以被用于向DSLT-MF 1204发起DSLT触发请求(DSLT-TRIGGER)1216，使得DSLT-MF 1204可以散布和管理DSLT-REQ 1218。DSLT-TF 1202是一种轻量级的瘦功能，其可以托管在各种类型的网络节点上，诸如IoT服务器、IoT网关、IoT设备和IoT应用。

DSLT-MF 1204(和1206)可以被实现为服务。服务可以或者是独立服务，或者被实现为IoT服务层的子服务。DSLT-MF服务1204可以托管在各种类型的网络节点上，诸如IoT服务器、IoT网关和IoT设备。DSLT-MF服务1204可以接收请求以触发DSLT向分布式DSLT-CF集合的散布和处理。由DSLT-MF 1204接收的每个DSLT-TRIGGER可以由以一个或多个目标为目标的一个或多个SL操作组成。DSLT-MF 1204通过以原子方式处理其所有相关联的SL请求来处理DSLT-TRIGGER 1216。如果需要，那么DSLT-MF 1204确保将由DSLT-TRIGGER 1216指定的(一个或多个)SL请求正确地散布到分布式SL实体集合并由所有作为目标的SL实体成功执行，或者在故障的情况下不由它们中的任何一个执行。为了清楚起见，将从DSLT-MF 1204散布到DSLT-CF 1208和1210的DSLT请求称为DSLT-REQ 1218。

DSLT-CF 1210用作目标并处理其从DSLT-MF 1204接收的已散布的DSLT-REQ1218。DSLT-CF 1208可以托管在各种类型的网络节点上，诸如IoT服务器、IoT网关、IoT设备和IoT应用。

例如，如图12中所示，支持DSLT-TF 1202的IoT应用1230可以向IoT服务器1232上托管的DSLT-MF 1204发送DSLT-TRIGGER 1216，以使其散布原子DSLT-REQ 1218和1219的集合，以更新IoT设备1234和1236的分布式集合上的致动器(例如，电子开关)。DSLT-MF 1204可以依次将DSLT-REQ 1218和1219散布到每个设备上托管的DSLT-CF 1208和1210，并且还确保它们或者全部成功执行DSLT-REQ 1218和1219以更新其致动器或者它们都不执行更新。在这样做时，所有设备上的设置将保持一致。

在多跳场景的情况下，诸如如图12中所示的涉及IoT网关以及IoT设备1238和1240的场景，IoT网关1242上的DSLT-MF 1206可以被用于接收从IoT服务器的DSLT-MF 1204散布的DSLT-TRIGGER 1222。在检测到DSLT-TRIGGER以IoT设备1238和1240托管的资源为目标后，IoT网关的DSLT-MF 1206可以被用于将DSLT-REQ 1224和1226散布到IoT设备的DSLT-CF1212和1214。这显示了DSLT服务的分布式性质，以及如何使用多个DSLT-MF来原子化处理整个系统中的DSLT。

DSLT-TF 1202可以支持向DSLT-MF 1204发起DSLT请求并作为回报从DSLT-MF1204接收DSLT响应的能力。不需要支持任何其它DLST处理功能。

DSLT-MF 1204可以支持用于处理DSLT的若干能力。DSLT-MF能力的集合在图13中示出。DSLT-MF 1204可以包括DSLT-MF API 1302、DSLT-MF处理1304、DSLT-MF序列处理1306、DSLT-MF策略引擎1308和DSLT-MF调度器1310。

类似地，如图14中所示，DSLT-CF 1210可以支持用于处理DSLT的能力集合。DSLT-CF 1210可以包括DSLT-CF API 1402、DSLT-CF处理1404和DSLT-CF序列处理1406。

以下小节提供了DSLT-MF 1204和DSLT-CF 1210能力中的每一个的进一步定义。

DSLT API

DSLT-MF 1204可以支持API 1302，该API 1302可以被DSLT-TF用以向DSLT-MF1204发起与DSLT相关的请求。被支持的请求的类型可以包括发起新的DSLT(即，DSLT-TRIGGER)、查询现有DSLT的状况(即，DSLT-QUERY)以及中止未完成的DSLT(DSLT-ABORT)。API 1302还可以被用于配置策略，该策略定义用于控制DSLT-MF如何处理和调度DSLT的规则。可以支持这个API 1302作为RESTful接口，该接口由DSLT相关消息参数和/或DSLT-MF1204托管的资源组成。

DSLT-CF 1210也可以支持API 1402。这个API 1402可以被DSLT-MF 1204用来向DSLT-CF 1210发送与DSLT相关的请求。被支持的请求的类型可以包括将新的DSLT转发到DSLT-CF 1210(即，DSLT-REQ)、查询现有DSLT的状况(DSLT-QUERY)以及中止DSLT-CF 1210正在处理的未完成DSLT(DSLT-ABORT)。可以支持这个API 1402作为RESTful接口，该接口由DSLT相关消息参数和/或DSLT-CF 1210托管的资源组成。

DSLT API资源：

在一个示例中，DSLT-MF 1204可以支持以下类型的资源。

表2–DSLT API资源类型

DSLT API消息参数

DSLT消息参数可以适用于各种类型的DSLT消息，诸如DSLT-TRIGGER、DSLT-SEQ-TRIGGER、DSLT-REQ、DSLT-QUERY和DSLT-ABORT。这些各种DSLT消息类型可以映射到RESTfulAPI，其中可以使用CRUD操作和一些DSLT消息参数来实现每种DSLT消息类型。

表3–DSLT消息参数

除了单个DSLT请求之外，两个或更多个DSLT还可以组合以形成DSLT序列。DSLT序列指定DSLT的有序列表。可以将多个DSLT一起批处理成单个SL请求，或者可以使用具有相同值的DSLT序列标识符将DSLT序列相互关联。DSLT-MF 1204以及(一个或多个)DSLT-CF1210和1208一起可以原子地处理和执行DSLT序列。处理包括各个DSLT的原子执行以及整个序列的原子处理。因此，如果任何个体DSLT未成功完成，那么DSLT-MF 1204以及DSLT-CF1210和1208可以支持该序列中所有DSLT的回滚，使得由DSLT序列作为目标的任何资源返回到它们在DSLT序列开始执行之前的相同原始状态。

以下是与DSLT序列相关的消息参数集合。

表4–DSLT序列消息参数

DSLT API标识符

在表7中示出了用于个体DSLT的SL标识符。在表6中示出了用于DSLT序列的标识符。这些DSLT标识符的结构可以由多个成分组成，如表5中所示。标识符可以由服务提供商成分(SP-ID)、DSLT-MF成分(DSLT-MF-ID)、DSLT序列成分(DSLT-SEQ-ID)、DSLT成分(DSLT-ID)和SL请求ID成分(SL-REQ-ID)。

取决于在系统中使用DSLT的位置，可以存在不同的格式和唯一性要求。例如，如果DSLT仅被用于将托管在与托管DSLT-MF 1204的相同IoT服务提供商域内的DSLT-CF作为目标，那么DSLT标识符的唯一性要求可以不要求SP-ID成分。而如果DSLT以托管在与DSLT-MF1204不同的IoT服务提供商域中的DSLT-CF作为目标，那么DSLT可以要求跨SL实例和跨服务提供商域唯一的标识符，并包括SP-ID。

表5–DSLT标识符成分

表6–DSLT序列标识符格式

DSLT序列ID格式	描述
		DSLT-MF相对	[DSLT-SEQ-ID]
服务提供商相对	[DSLT-MF-ID]/[DSLT-SEQ-ID]
		绝对	[SP-ID]/[DSLT-MF-ID]/[DSLT-SEQ-ID]

表7–DSLT标识符格式

DSLT ID格式	描述
		DSLT-MF相对	[DSLT-SEQ-ID]/[DSLT-ID]
服务提供商相对	[DSLT-MF-ID]/[DSLT-SEQ-ID]/[DSLT-ID]
		绝对	[SP-ID]/[DSLT-MF-ID]/[DSLT-SEQ-ID]/[DSLT-ID]

DSLT处理能力

下面描述用于处理个体DSLT的方法和用于处理DSLT序列的方法。这些方法中的每一个都具有由DSLT-TF 1202、DSLT-MF 1204和DSLT-CF 1210执行的动作。在下面的描述中阐明相应的动作。

个体DSLT处理

个体DSLT可以由一个DSLT组成，该DSLT通过DSLT-TF 1202向DSLT-MF 1204发送DSLT-TRIGGER请求1216来发起。然后，DSLT-MF 1204处理DSLT-TRIGGER请求1216。这个处理可以涉及DSLT-MF 1204将多个DSLT-REQ 1218和1219散布到作为DSLT的目标的分布式SL实体集合。接收DSLT-REQ的每个SL实体托管能够处理DSLT-REQ的DSLT-CF 1208和1210。DSLT-MF 1204管理散布的DSLT-REQ集1219和1218，以确保以原子的方式对其进行处理。当完成时，DSLT-MF 1204向发起DSLT-TRIGGER请求1216的DSLT-TF 1202返回响应。这个响应包括DSLT的结果。

用于处理个体DSLT的整体方法可以被细分为三个互补的方法，其由发起DSLT的DSLT-TF 1202、管理DSLT的处理的DSLT-MF 1204以及对作为目标的资源执行指定的DSLT的操作的DSLT-CF 1208和1210组成。在以下流程图中对这些方法中的每一个进行描述。

图15示出了针对个体DSLT的DSLT-TF处理，

在图15的步骤1中，DSLT触发条件(例如，特定于应用的事件)发生在托管DSLT-TF1202的SL实体(例如，应用)1230上。

在图15的步骤2中，DSLT-TF 1202生成DSLT-TRIGGER请求并将该请求发送到托管DSLT-MF 1204的SL实体，使得DSLT-MF 1204可以代表其执行DSLT处理。DSLT-TF 1202等待DSLT-MF 1204响应以指示DSLT处理已完成。

在图15的步骤3a中，DSLT-MF 1204向DSLT-TF 1202响应DSLT处理已完成并包括这个处理的状况。

在图15的步骤3b中，DSLT-TF 1202在等待来自DSLT-MF 1204的响应时超时。DSLT-TF 1202通过向DSLT-MF 1204重新发送DSLT-TRIGGER来重试DSLT。

在图15的步骤3c中，DSLT-TF 1202决定中止DSLT请求。这个决定可以是超时的结果，此后DSLT-TF 1202决定它不想重试。或者这个决定可以基于其它因素，诸如特定于应用的原因。

在图15的步骤4中，DSLT-TF 1202检查由DSLT-MF 1204返回给它的DSLT结果。

在图15的步骤5a中，DSLT由DSLT-MF 1204成功处理。DSLT-TF 1202可以认为DSLT已完成。

在图15的步骤5b中，未成功处理DSLT。DSLT-TF 1202决定通过向DSLT-MF 1204重新发出DSLT-TRIGGER请求来重试DSLT，以使其重新尝试再次进行DSLT的处理。

在图15的步骤5c中，未成功处理DSLT。DSLT-TF 1202决定中止DSLT请求，而不是重试。

在图15的步骤6中，成功处理了DSLT，并且DSLT-TF 1202将结果返回给调用DSLT触发请求的实体(例如，应用)。

在图15的步骤7中，DLST-TF已决定中止DSLT。取决于DSLT-TF 1202是否已从DSLT-MF 1204接收到响应，DSLT-TF 1202可以决定向DSLT-MF 1204发送中止请求，以通知它已决定中止DSLT。

图16示出了针对个体DSLT的DSLT-MF 1204处理。

在图16的步骤1中，托管DSLT-TF 1202的SL实体向托管DSLT-MF 1204的SL实体发送DSLT-TRIGGER请求，以发起DSLT。

在图16的步骤2中，DSLT-MF 1204处理该请求，并将DSLT-REQ散布到被DSLT-TRIGGER作为目标的DSLT-CF 1208和1210中的每一个。DSLT-MF 1204等待来自DSLT-CF1208和1210中的每一个的指示它们已经成功获得了关于作为目标的资源的锁的响应。

在图16的步骤3a中，DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或子集，取决于定义的完成标准)能够成功获得关于作为目标的资源的锁。

在图16的步骤3b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF 1208和1210的响应时超时。DSLT-MF 1204通过将DSLT-REQ重新发送到一个或多个超时的DSLT-CF来重试DSLT。

在图16的步骤3c中，DSLT-MF 1204决定中止DSLT请求。这个决定可以是超时的结果，在此之后DSLT-MF 1204决定它不想重试(例如达到最大重试次数)。如果DSLT-MF 1204检测到一个或多个DSLT-CF无法成功获得关于作为目标的(一个或多个)资源的锁，那么DSLT-MF 1204可以选择中止DSLT(取决于定义的完成标准)，因为它无法在所有作为目标的DSLT-CF 1208和1210上原子地执行。DSLT-MF 1204可以通过选择不向每个DSLT-CF发送执行命令并让DSLT超时来中止DSLT，或者它可以显式向每个DSLT-CF发送中止命令。中止决定还可以基于其它因素，诸如一个或多个DSLT-CF不可达。

在图16的步骤4中，DSLT-MF 1204通过向DSLT-CF发送执行命令来指示DSLT-CF1208和1210执行由DSLT指定的操作。DSLT-MF 1204等待来自每个DSLT-CF的指示它们已成功对作为目标的资源执行了操作的响应。

在图16的步骤5a中，DSLT-MF 1204检测到所有DSLT-CF(或子集，取决于定义的完成标准)能够对作为目标的资源成功执行由DSLT指定的操作。

在图16的步骤5b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF 1208和1210的响应时超时。DSLT-MF 1204重试向一个或多个超时的DSLT-CF发送执行命令。

在图16的步骤5c中，DSLT-MF 1204决定中止DSLT请求。这个决定可以是超时的结果，在此之后DSLT-MF 1204决定它不想重试(例如达到最大重试次数)。或者，这个决定可以基于其它因素，诸如一个或多个DSLT-CF不可达。如果DSLT-MF 1204检测到一个或多个DSLT-CF无法在作为目标的(一个或多个)资源上成功执行操作，那么DSLT-MF 1204可以选择中止DSLT(取决于定义的完成标准)，因为它无法在所有作为目标的DSLT-CF 1208和1210上原子地执行。DSLT-MF 1204可以通过选择不向每个DSLT-CF 1208和1210发送执行命令并让DSLT超时来中止DSLT，或者它可以显式向每个DSLT-CF 1208和1210发送中止命令。

在图16的步骤6中，DSLT-MF 1204指示DSLT-CF 1208和1210提交由DSLT指定的操作。DSLT-MF 1204等待来自DSLT-CF 1208和1210中的每一个的指示它们已经成功提交对作为目标的资源的操作的响应。

在图16的步骤7a中，DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或者子集，取决于定义的完成标准)都能够对作为目标的资源成功提交由DSLT指定的操作的结果。

在图16的步骤7b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF 1208和1210的响应时超时。DSLT-MF 1204重试向一个或多个超时的DSLT-CF 1208和1210发送提交命令。

在图16的步骤7c中，DSLT-MF 1204决定中止DSLT请求。这个决定可以是超时的结果，在此之后DSLT-MF 1204决定它不想重试(例如达到最大重试次数)。或者这个决定可以基于其它因素，诸如一个或多个DSLT-CF 1208和1210不可达。

在图16的步骤8中，成功处理了DSLT，并且DSLT-MF 1204将结果返回给触发DSLT的DSLT-TF 1202。

在图16的步骤9中，DLST-MF已决定中止DSLT。取决于DSLT-MF 1204是否已从DSLT-CF 1208和1210接收到响应，DSLT-MF 1204可以决定向一个或多个DSLT-CF 1208和1210发送显式中止请求以通知它们它已决定中止DSLT，使得它们可以执行任何必要的处理，诸如中止DSLT的处理、将作为目标的资源的状态回滚到其原始状态或作为目标的资源的解锁。

图17示出了针对个体DSLT-CF的DSLT-CF处理。

在图17的步骤1中，托管DSLT-CF 1210的SL实体从DSLT-MF 1204接收DSLT-REQ。

图17的步骤2是初始化步骤，其中DSLT-CF 1210尝试锁定请求的资源。

在图17的步骤3a中，DSLT-CF 1210能够成功获得对被DSLT-REQ作为目标的(一个或多个)资源的锁定(如果需要)。可以使这种阻塞适用于来自其它DSLT-REQ的所有操作，因为甚至可能需要阻塞被锁定资源的检索，直到提交并解锁被锁定资源的状态为止。

在图17的步骤3b中，DSLT-CF 1210无法在超时时段过去之前获得对作为目标的资源的锁定，因此DSLT-CF 1210选择超时并中止DSLT-REQ。DSLT-CF 1210可以将这个超时通知给DSLT-MF 1204。在超时之后，DSLT-CF 1210可以从DSLT-MF 1204接收重试的DSLT-REQ，在这种情况下，DSLT-CF 1210可以重复从步骤1开始的流程。

在图17的步骤3c中，DSLT-CF 1210从DSLT-MF 1204接收显式中止命令，因此DSLT-CF 1210中止DSLT-REQ。如果DSLT-CF 1210能够获得关于任何作为目标的资源的锁，那么DSLT-CF 1210释放这些锁并中断DSLT的处理。DSLT-CF可以从DSLT-MF 1204接收重试的DSLT-REQ，在这种情况下，DSLT-CF可以重复从步骤1开始的流程。

在图17的步骤4中，由每个DSLT-CF获得关于作为目标的(一个或多个)资源的锁(如果需要)。每个DSLT-CF通知DSLT-MF 1204已获得或不需要锁。DSLT-CF 1210在这个状态下等待，直到它从DSLT-MF 1204接收到对作为目标的(一个或多个)资源执行DSLT指定的(一个或多个)操作的命令为止。

在图17的步骤5a中，DSLT-CF 1210从DSLT-MF 1204接收到执行命令，并且它能够成功完成对作为目标的(一个或多个)资源的DSLT指定的(一个或多个)操作的执行。

在图17的步骤5b中，DSLT-CF 1210在超时时段过去之前没有从DSLT-MF 1204接收到执行命令，因此DSLT-CF 1210使DSLT-REQ超时并解锁资源。DSLT-CF 1210可以DSLT-MF1204通知这个超时。在超时之后，DSLT-CF 1210可以从DSLT-MF 1204接收DSLT-REQ命令。

在图17的步骤5c中，DSLT-CF 1210中止DSLT-REQ的执行。这可以是由于从DSLT-MF1204接收到执行命令而无法对作为目标的(一个或多个)资源成功执行DSLT指定的(一个或多个)操作的结果。可替代地，这可以是DSLT-CF 1210从DSLT-MF 1204接收中止命令的结果。

在图17的步骤6中，DSLT-CF 1210成功完成了执行。DSLT向DSLT-MF 1204通知其执行状况并等待来自DSLT-MF 1204的提交命令。

在图17的步骤7a中，DSLT-CF 1210从DSLT-MF 1204接收到提交命令并且它能够成功提交作为目标的资源的状态，因此结果保持持久。

在图17的步骤7b中，DSLT-CF 1210在超时时段过去之前没有从DSLT-MF 1204接收到提交命令，因此DSLT-CF 1210使DSLT-REQ超时。DSLT-CF 1210仍然提交更新后的(一个或多个)资源的状态，而不是中止以与其它DSLT-CF保持一致。DSLT-CF 1210还解锁资源。

在图17的步骤7c中，DSLT-CF 1210中止DSLT-REQ的提交。这可以是由于从DSLT-MF1204接收到提交命令并且无法成功提交结果的结果。可替代地，这可以是DSLT-CF 1210从DSLT-MF 1204接收到中止命令的结果。

在提交之后，在图17的步骤8中，DSLT-CF 1210可以释放对被DSLT作为目标的(一个或多个)资源的锁。在这种情况下，DSLT-CF 1210还可以向DSLT-MF 1204发送提交的通知。

在图17的步骤9中，DSLT-CF 1210中止并回滚DSLT，并将对应的状况返回给DSLT-MF 1204。在中止之后，DSLT-CF应当释放对资源的锁。在这种情况下，DSLT-CF 1210还可以向DSLT-MF 1204发送中止的通知。

DSLT序列处理

DSLT序列由多个分布式服务层事务组成，这些事务必须作为原子和有序集合进行处理。DSLT序列通过DSLT-TF 1202向DSLT-MF 1204发送DSLT-SEQ-TRIGGER请求而被触发。然后，DSLT-MF 1204处理DSLT序列。这个处理可以涉及DSLT-MF 1204将DSLT-REQ散布到作为DSLT序列的目标的分布式SL实体集合。接收DSLT-REQ的每个SL实体都托管有能够处理DSLT-REQ的DSLT-CF 1208和1210。DSLT-MF 1204确保以原子和有序的方式处理序列中的所有DSLT-REQ。当完成时，DSLT-MF 1204返回对发起DSLT-SEQ-TRIGGER请求的DSLT-TF 1202的响应。这个响应包括DSLT序列的结果。

可以将用于处理DSLT序列的总体方法细分为三个互补的方法，其由发起DSLT序列的DSLT-TF 1202、管理DSLT序列的处理的DSLT-MF 1204以及对由序列中的各个DSLT指定的作为目标的资源执行操作的DSLT-CF 1208和1210组成。在以下流程图中对这些方法中的每一个进行描述。

图18示出了针对DSLT序列的DSLT-TF 1202处理。

在图18的步骤1中，DSLT序列触发条件(例如，特定于应用的事件)发生在托管DSLT-TF 1202的SL实体(例如，应用)上。

在图18的步骤2中，DSLT-TF 1202生成DSLT-SEQ-TRIGGER请求并将该请求发送给托管DSLT-MF 1204的SL实体，使得DSLT-MF 1204可以代表其上执行DSLT序列处理。DSLT-TF1202等待DSLT-MF 1204响应以指示DSLT序列处理已完成。

在图18的步骤3a中，DSLT-MF 1204向DSLT-TF 1202响应DSLT序列处理已完成并包括这个处理的状况。

在图18的步骤3b中，DSLT-TF 1202在等待来自DSLT-MF 1204的响应时超时。DSLT-TF 1202通过向DSLT-MF 1204重新发送DSLT-SEQ-TRIGGER请求来重试DSLT序列。

在图18的步骤3c中，DSLT-TF 1202决定中止DSLT-SEQ-TRIGGER请求。这个决定可以是超时的结果，在此之后DSLT-TF 1202决定它不想重试。或者这个决定可以基于其它因素，诸如特定于应用的原因。

在图18的步骤4中，DSLT-TF 1202检查由DSLT-MF 1204返回给它的DSLT序列结果。

在图18的步骤5a中，DSLT序列由DSLT-MF 1204成功处理。DSLT-TF 1202可以认为DSLT序列已完成。

在图18的步骤5b中，未成功处理DSLT序列。DSLT-TF 1202决定通过向DSLT-MF1204重新发出DSLT-SEQ-TRIGGER请求来重试DSLT序列，以使其再次重新尝试DSLT的处理。

在图18的步骤5c中，未成功处理DSLT序列。DSLT-TF 1202决定中止DSLT排序请求，而不是重试。

在图18的步骤6中，成功处理了DSLT序列，并且DSLT-TF 1202将结果返回给调用DSLT序列触发请求的实体(例如，应用)。

在图18的步骤7中，DLST-TF 1202已决定中止DSLT序列。取决于DSLT-TF 1202是否已接收到来自DSLT-MF 1204的响应，DSLT-TF 1202可以决定向DSLT-MF 1204发送中止请求，以向其通知它已决定中止DSLT序列。

图19示出了针对DSLT序列的DSLT-MF 1204处理。

在图19的步骤1中，托管DSLT-TF 1202的SL实体向托管DSLT-MF 1204的SL实体发送DSLT-SEQ-TRIGGER请求，以发起DSLT序列。

在图19的步骤2中，DSLT-MF 1204处理该请求，并将与该序列中的第一DSLT对应的DSLT-REQ散布到被DSLT-TRIGGER作为目标的DSLT-CF 1208和1210中的每一个。DSLT-MF1204等待来自DSLT-CF 1208和1210中的每一个的指示它们已经成功获得了关于作为目标的资源的锁的响应。

在图19的步骤3a中，DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或者子集，取决于定义的完成标准)都能够成功获得关于作为目标的资源的锁。

在图19的步骤3b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF 1208和1210的响应时超时。DSLT-MF 1204通过向超时的一个或多个DSLT-CF重新发送与序列中的第一DSLT对应的DSLT-REQ来重试DSLT。

在图19的步骤3c中，DSLT-MF 1204取决于序列完成标准而决定中止序列中的第一个DSLT请求，并且可能中止整个DSLT序列。这个决定可以是超时的结果，在此之后DSLT-MF1204决定它不想重试(例如达到最大重试次数)。如果DSLT-MF 1204检测到一个或多个DSLT-CF无法成功获得对作为目标的(一个或多个)资源的锁，那么DSLT-MF 1204可以选择中止DSLT(取决于定义的完成标准)，因为它无法对所有作为目标的DSLT-CF 1208和1210原子地执行。DSLT-MF 1204可以通过选择不向每个DSLT-CF 1208和1210发送执行命令并让DSLT超时来中止DSLT，或者它可以向每个DSLT-CF 1208和1210显式发送中止命令。中止决定还可以基于其它因素，诸如一个或多个DSLT-CF不可达。

在图19的步骤4中，DSLT-MF 1204通过向DSLT-CF 1208和1210发送执行命令来指示DSLT-CF 1208和1210执行由序列中第一个DSLT指定的操作。DSLT-MF 1204等待来自DSLT-CF 1208和1210中的每一个的指示它们已经成功地对作为目标的资源执行了操作的响应。

在图19的步骤5a中，DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或者子集，取决于定义的完成标准)都能够成功地对作为目标的资源执行由DSLT指定的操作。

在图19的步骤5b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF 1208和1210的响应时超时。DSLT-MF 1204重试向一个或多个超时的DSLT-CF发送执行命令。

在图19的步骤5c中，DSLT-MF 1204决定中止序列中的第一个DSLT请求，并可能中止整个DSLT序列，这取决于序列完成标准。这个决定可以是超时的结果，在此之后DSLT-MF1204决定它不想重试(例如达到最大重试次数)。或者这个决定可以基于其它因素，诸如一个或多个DSLT-CF 1208和1210不可达。如果DSLT-MF 1204检测到一个或多个DSLT-CF无法对作为目标的(一个或多个)资源成功执行操作，那么DSLT-MF 1204可以选择中止DSLT(取决于定义的完成标准)，因为它不能对所有作为目标的DSLT-CF 1208和1210原子地执行。DSLT-MF 1204可以通过选择不向每个DSLT-CF 1208和1210发送执行命令并让DSLT超时来中止DSLT，或者可以向每个DSLT-CF 1208和1210显式发送中止命令。

在图19的步骤6中，可以将与步骤2中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤7a中，可以将与步骤3a中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤7b中，可以将与步骤3b中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤7c中，可以将与步骤3c中定义的行为相同的行为应用于第二DSLT的处理

在图19的步骤8中，可以将与步骤4中定义的行为相同的行为应用于第二DSLT的处理

在图19的步骤9a中，可以将与步骤5a中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤9b中，可以将与步骤5b中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤9c中，可以将与步骤5c中定义的行为相同的行为应用于第二DSLT的处理。

在图19的步骤10中，可以将与步骤2中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤11a中，可以将与步骤3a中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤11b中，可以将与步骤3b中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤11c中，可以将与步骤3c中定义的行为相同的行为应用于第N DSLT的处理

在图19的步骤12中，可以将与步骤4中定义的行为相同的行为应用于第N DSLT的处理

在图19的步骤13a中，可以将与步骤5a中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤13b中，可以将与步骤5b中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤13c中，可以将与步骤5c中定义的行为相同的行为应用于第N DSLT的处理。

在图19的步骤14中，如果DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或者子集，取决于定义的序列完成标准)都能够对如由整个DSLT序列指定的所有作为目标的资源成功地执行所有操作，那么DSLT-MF 1204指示DSLT-CF 1208和1210中的每一个提交序列中所有适用的DSLT，使得结果的状态保持持久。

在图19的步骤15a中，DSLT-MF 1204检测到所有DSLT-CF 1208和1210(或者子集，取决于定义的完成标准)都能够对作为目标的资源成功提交由DSLT指定的操作的结果。

在图19的步骤15b中，DSLT-MF 1204在等待来自一个或多个DSLT-CF的响应时超时。DSLT-MF 1204重试向一个或多个超时的DSLT-CF发送提交命令。

在图19的步骤15c中，DSLT-MF 1204基于序列完成标准决定中止DSLT序列。这个决定可以是超时的结果，在此之后DSLT-MF 1204决定它不想重试(例如达到最大重试次数)。或者，这个决定可以基于其它因素，诸如一个或多个DSLT-CF不可达。如果DSLT-MF 1204检测到一个或多个DSLT-CF无法成功对作为目标的(一个或多个)资源的操作，那么DSLT-MF1204可以选择中止DSLT序列(取决于定义的完成标准)，因为它无法对所有作为目标的DSLT-CF 1208和1210原子地执行。DSLT-MF 1204可以通过向触发DSLT序列的DSLT-TF 1202返回错误来中止DSLT序列。

在图19的步骤16中，成功处理了DSLT序列，并且DSLT-MF 1204将结果返回到触发DSLT序列的DSLT-TF 1202。

在图19的步骤17中，DLST-MF已决定中止DSLT序列。取决于DSLT-MF 1204是否已从DSLT-CF 1208和1210接收到响应，DSLT-MF 1204可以决定向一个或多个DSLT-CF 1208和1210发送显式中止请求以向它们通知它决定中止序列中的一个或多个DSLT，使得它们可以执行任何必要的处理，诸如中断DSLT序列的处理、将作为目标的资源的状态回滚到其原始状态或作为目标的资源的解锁。

图20示出了针对DSLT序列的DSLT-CF处理。

在图20的步骤1中，托管DSLT-CF 1210的SL实体从与序列中的第一个DSLT对应的DSLT-MF 1204接收DSLT-REQ。可替代地，每个DSLT-CF 1208和1210可以接收在单个请求中一起批处理的序列中的所有DSLT。

在图20的步骤2中，DSLT-CF 1210处理DSLT-REQ并尝试锁定(如果需要)被DSLT-REQ作为目标的(一个或多个)资源，以确保事务被隔离地执行且不受任何其它DSLT-REQ的干扰。DSLT-CF 1210在这个状态下等待，直到获得锁为止(如果需要)。DSLT-CF 1210可以将这个锁与DSLT序列相关联，以允许同一序列中的DSLT对(一个或多个)资源操作，但不允许任何其它DSLT操作。这个锁可以视操作类型而定。例如，仅当操作是“更新”或“删除”时，才锁定作为目标的资源。但是，在一些用例中，对于检索也可能要保证锁定，以确保在执行检索的DSLT-REQ被执行之前，另一个DSLT-REQ不会修改或删除资源。一旦资源被一个DSLT-REQ锁定，就可以使用这个锁定来阻塞其它DSLT-REQ访问该资源。可以使这种阻塞适用于来自其它DSLT-REQ的所有操作，因为甚至被锁定资源的检索也可能需要被阻塞，直到被锁定资源的状态被提交并解锁为止。

在图20的步骤3a中，DSLT-CF 1210能够成功获得对被DSLT-REQ作为目标的(一个或多个)资源的锁定(如果需要)。可以使这种阻塞适用于来自其它DSLT-REQ的所有操作，因为甚至被锁定资源的检索也可能需要被阻塞，直到被锁定资源的状态被提交并解锁为止。

在图20的步骤3b中，DSLT-CF 1210无法在超时时段过去之前获得对作为目标的资源的锁，因此DSLT-CF 1210选择超时并中止DSLT-REQ。DSLT-CF 1210可以向DSLT-MF 1204通知这个超时。在超时之后，DSLT-CF可以从DSLT-MF 1204接收重试的DSLT-REQ，在这种情况下，DSLT-CF可以重复从步骤1开始的流程。

在图20的步骤3c中，DSLT-CF 1210从DSLT-MF 1204接收显式中止命令，因此DSLT-CF 1210中止DSLT-REQ。如果DSLT-CF 1210能够获得对任何作为目标的资源的锁，那么DSLT-CF 1210释放这些锁并中止DSLT的处理。DSLT-CF 1210可以从DSLT-MF 1204接收重试的DSLT-REQ，在这种情况下，DSLT-CF 1210可以重复从步骤1开始的流程。

在图20的步骤4中，由每个DSLT-CF 1208和1210获得(如果需要)对作为目标的(一个或多个)资源的锁。每个DSLT-CF向DSLT-MF 1204通知已获得或不需要锁。DSLT-CF在这个状态下等待，直到它从DSLT-MF 1204接收到对作为目标的(一个或多个)资源执行DSLT指定的(一个或多个)操作的命令为止。

在图20的步骤5a中，DSLT-CF 1210从DSLT-MF 1204接收到执行命令并且它能够成功完成对作为目标的(一个或多个)资源执行由DSLT指定的(一个或多个)操作。

在图20的步骤5b中，DSLT-CF 1210在超时时段过去之前没有从DSLT-MF 1204接收到执行命令，因此DSLT-CF 1210使DSLT-REQ超时并解锁资源。DSLT-CF 1210可以向DSLT-MF1204通知这个超时。在超时之后，DSLT-CF 1210可以从DSLT-MF 1204接收DSLT-REQ命令。

在图20的步骤5c中，DSLT-CF 1210中止DSLT-REQ的执行。这可以是从DSLT-MF1204接收到执行命令并且无法对作为目标的(一个或多个)资源成功执行由DSLT指定的(一个或多个)操作的结果。可替代地，这可以是DSLT-CF 1210从DSLT-MF 1204接收到中止命令的结果。

在图20的步骤6中，DSLT-CF 1210成功完成了执行。DSLT-CF 1210向DSLT-MF 1204通知其执行状况并等待序列中的下一个DSLT或来自DSLT-MF 1204的提交命令。如果接收到序列中的下一个DSLT，那么可以将与步骤2中定义的行为相同的行为应用于这下一个DSLT的处理。

在图20的步骤7a中，可以将与步骤3a中定义的行为相同的行为应用于第二DSLT的处理。

在图20的步骤7b中，可以将与步骤3b中定义的行为相同的行为应用于第二DSLT的处理。

在图20的步骤7c中，可以将与步骤3c中定义的行为相同的行为应用于第二DSLT的处理

在图20的步骤8中，可以将与步骤4中定义的行为相同的行为应用于第二DSLT的处理

在图20的步骤9a中，可以将与步骤5a中定义的行为相同的行为应用于第二DSLT的处理。

在图20的步骤9b中，可以将与步骤5b中定义的行为相同的行为应用于第二DSLT的处理。

在图20的步骤9c中，可以将与步骤5c中定义的行为相同的行为应用于第二DSLT的处理。

在图20的步骤10中，可以将与步骤6中定义的行为相同的行为应用于第N DSLT的处理。

在图20的步骤11a中，可以将与步骤3a中定义的行为相同的行为应用于第N DSLT的处理。

在图20的步骤11b中，可以将与步骤3b中定义的行为相同的行为应用于第N DSLT的处理。

在图20的步骤11c中，可以将与步骤3c中定义的行为相同的行为应用于第N DSLT的处理

在图20的步骤12中，可以将与步骤4中定义的行为相同的行为应用于第N DSLT的处理

在图20的步骤13a中，可以将与步骤5a中定义的行为相同的行为应用于第N DSLT的处理。

在图20的步骤13b中，可以将与步骤5b中定义的行为相同的行为应用于第N DSLT的处理。

在图20的步骤13c中，可以将与步骤5c中定义的行为相同的行为应用于第N DSLT的处理

在图20的步骤14中，DSLT-CF 1210成功完成了序列中第N DSLT的执行。DSLT-CF1210向DSLT-MF 1204通知其执行状况并等待序列中的下一个DSLT或来自DSLT-MF 1204的提交命令。

图20的步骤15a中，DSLT-CF 1210能够成功提交序列中的DSLT。

在图20的步骤15b中，DSLT-CF 1210在超时时段过去之前没有从DSLT-MF 1204接收到序列中的后续DSLT或提交命令，因此DSLT-CF 1210使DSLT序列超时。如果/当发生这种情况时，DSLT-CF不会提交序列中已更新的(一个或多个)资源的状态，而是中止它，使得作为目标的(一个或多个)资源的状态回滚到执行序列中的任何DSLT操作之前的初始状态。类似地，如果在对作为目标的(一个或多个)资源执行DSLT指定的操作之后DSLT-CF 1210从DSLT-MF 1204接收到显式中止命令，那么DSLT-CF 1210可以通过不提交更新后的(一个或多个)资源的状态来中止DSLT序列，而是代替地中止它，使得作为目标的(一个或多个)资源的状态回滚到在执行序列中的任何DSLT操作之前的初始状态。DSLT-CF 1210可以向DSLT-MF 1204通知这个中断。

在图20的步骤15c中，DSLT-CF 1210中止其已作为序列的一部分进行处理但尚未提交的所有DSLT的提交。这可以是从DSLT-MF 1204接收到提交命令并且无法成功提交结果的结果。可替代地，这可以是DSLT-CF 1210从DSLT-MF 1204接收到中止命令的结果。

在提交之后，在图20的步骤16中，DSLT-CF 1210可以释放关于被序列中任何DSLT作为目标的(一个或多个)资源的锁。在这种情况下，DSLT-CF还可以向DSLT-MF 1204发送提交的通知。

在图20的步骤17中，如果发生超时或中止，那么DSLT-CF可以中止并回滚它作为序列一部分进行处理的所有DSLT，并将对应的状况返回给DSLT-MF 1204。在中止之后，DSLT-CF 1210也应当释放对资源的锁。在这种情况下，DSLT-CF 1210还可以向DSLT-MF 1204发送中止的通知。

DSLT-MF策略引擎能力

DSLT-MF 1204可以支持DSLT策略引擎能力1308。通过其API，DSLT-MF 1204可以支持策略配置请求，以创建、检索、更新或删除DSLT处理策略。这些策略可以被用于配置DSLT-MF 1204内的DSLT处理规则，该规则控制DSLT-MF 1204如何处理DSLT以及与作为目标的DSLT-CF 1208和1210的交互。

可以使用以下类型的DSLT处理策略：

-DSLT调度策略–这些策略可以被用于配置控制DSLT-MF 1204如何调度DSLT或DSLT序列处理的规则。

-DSLT重试策略–这些策略可以被用于配置以控制DSLT-MF 1204是否以及何时重试处理失败的DSLT或DSLT序列的规则。规则可以包括DSLT可以重试的最大或最小重试次数限制。

-DSLT优先化策略–这些策略可以被用于配置控制DSLT-MF 1204如何相对于彼此对DSLT或DSLT序列的处理进行优先化和排名的规则。

-DSLT执行标准策略–这些策略可以被用于配置控制DSLT-MF 1204如何指派并处理针对DSLT或DSLT序列的执行标准的规则。

-DSLT完成标准策略–这些策略可以被用于配置控制DSLT-MF 1204如何指派并处理针对DSLT或DSLT序列的完成标准的规则。

可以配置以上每种类型的策略的适用性/范围。例如，策略的范围可以限于：

-源自具体源(例如某个DSLT-TF 1202或一组DSLT-TF 1202s)的DSLT

-以具体目标(例如某个DSLT-CF或一组DSLT-CF)为目标的DSLT

-具体类型的DSLT(例如操作等于“创建”的DSLT)

可以使用以下类型的策略引擎功能。DSLT-MF 1204可以将对应的策略规则(例如，调度、重试、优先化和完成标准规则)应用于其接收的传入的DSLT请求。这些规则可以被用作默认值，这些默认值可以应用于未为这些参数明确定义其自身对应值的DSLT请求(例如，它们不包括显式设置这些值的DSLT消息参数)。在DSLT请求确实包括这些参数中的一个或多个的显式值的情况下，可以将这些策略用作限制。DSLT-MF 1204可以将这些策略限制与DSLT请求中显式定义的参数进行比较，并在必要时通过改变显式值以遵守这些限制来强制实施这些限制。

用于资源预留的DSLT-MF调度能力

DSLT-MF 1204可以用作集中式DSLT调度功能1310。它可以支持调度对分布式SL实体集和由这些实体托管的资源的访问进行调度的能力，以便执行DSLT。通过提前主动进行这种调度，这可以帮助确保在需要时执行给定DSLT所需的资源可用并且对这些资源的争用被最小化。这可以导致第一次尝试时成功DSLT处理的可能性增加，这可以提高性能(例如减少重试尝试的发生)。集中式DSLT-MF调度能力可以检查每个DSLT中指定的作为目标的(一个或多个)资源和对应的(一个或多个)操作。然后，基于所有DSLT上的信息的这个聚合集合，DSLT-MF 1204可以做出明智的DSLT调度决定，并优化对跨所有出色DSLT的超集作为目标的资源的访问。

可以使用以下DSLT调度功能1310。

1)DSLT-MF 1204可以协调作为DSLT的目标的IoT设备的可达性时间表，以帮助确保所有所需的设备都联机且可用，使得可以对所有其作为目标的设备成功执行DSLT并满足DSLT的原子执行要求。这是至关重要的，因为如果其中一个设备不可用，那么由于缺少原子性，这将导致DSLT失败。DSLT-MF 1204可以与每个作为目标的设备进行协调以配置它们的连接性时间表，使得在向它们发出DSLT请求之前它们彼此对齐。对于本质上重复的那些类型的DSLT，这种对齐可以一次性/特设(ad-hoc)进行，或者也可以重复/常设(standing)进行。

2)DSLT-MF 1204可以确保以相同的(一个或多个)资源为目标的多个DSLT或DSLT序列不会同时执行，因为每个都必须获得关于其(一个或多个)目标资源的锁以确保其对应的事务被隔离地执行并且不干扰。尝试同时执行以相同的(一个或多个)资源为目标的DSLT会导致DSLT执行不理想(例如，延迟、超时、重试等)，或者甚至导致DSLT失败。DSLT-MF 1204可以检查每个DSLT及其配置的(一个或多个)目标。然后它可以正确地调度并排序DSLT相对于彼此的执行，以确保具有重叠目标的那些DSLT不同时执行，而没有重叠目标的那些DSLT可以同时执行。DSLT-MF 1204还可以考虑在每个DSLT内配置的优先级并将其包括在其调度算法中，以允许较高优先级的DSLT在较低优先级的DSLT之前执行。

DSLT过程

以下过程描述成功的DSLT处理场景。

个体DSLT过程

图21图示了个体DSLT过程。

图21的步骤1是可选步骤。在图21的步骤1中，IoT应用的DSLT-TF 1202将(一个或多个)请求发送到IoT服务器的DSLT-MF 1204以创建DSLT策略资源。每个策略资源可以包含控制DSLT-MF 1204如何处理DSLT请求的一个或多个规则。这些规则可以与DSLT调度、DSLT的重试、DSLT的优先化、DSLT的执行和完成标准相关。可替代地，IoT服务器的DSLT-MF 1204可以预先配置有DSLT策略。

图21的步骤2是可选步骤。在图21的步骤2中，IoT服务器的DSLT-MF 1204接收并处理创建DSLT策略资源的请求。DSLT-MF 1204创建策略资源，并且还用策略中指定的规则来配置其DSLT策略引擎1308。

图21的步骤3是可选步骤。在图21的步骤3中，IoT服务器的DSLT-MF 1204向IoT应用的DSLT-TF 1202返回响应，以通知其是否接受策略资源中定义的规则。如果不，那么DSLT-MF 1204可以提供由DSLT-MF 1204接受的规则的经修改的版本。

在图21的步骤4中，IoT应用的DSLT-TF 1202向IoT服务器的DSLT-MF 1204发送DSLT-TRIGGER请求。该请求可以包括若干参数，诸如作为目标的节点的集合(例如IoT设备1和IoT设备2)、要在这些节点上执行的操作、何时执行操作的时间表、执行标准的集合、优先级、在尝试处理事务失败的情况下重试的次数、完成标准的集合、DSLT标识符以及DSLT-MF1204可以用于以非阻塞方式处理事务的联系信息。

在图21的步骤5中，IoT服务器的DSLT-MF 1204接收并开始处理DSLT-TRIGGER请求。DSLT-MF 1204创建DSLT请求资源以在处理DSLT时跟踪状态。DSLT-MF 1204用步骤4中描述的DSLT-TRIGGER请求参数中包含的信息来配置资源的属性。

在图21的步骤6中，IoT服务器的DSLT-MF 1204通过向IoT应用的DSLT-TF 1202返回指示它已接收到请求并已经开始处理它的响应来以非阻塞方式处理DSLT-TRIGGER请求。可替代地，DSLT-MF 1204可以以阻塞的方式处理这个请求。

在图21的步骤7中，IoT服务器的DSLT-MF 1204解析DSLT-TRIGGER请求以查找作为目标的资源列表。DSLT-MF 1204检测到作为目标的资源不在IoT服务器上本地托管，而是由IoT设备1和2托管。因此，DSLT-MF 1204准备对应的DSLT-REQ，以散布到这些作为目标的设备。在散布请求之前，DSLT-CF 1210首先检查是否在DSLT-TRIGGER请求中或任何与DSLT调度相关的策略中明确配置了任何调度信息。DSLT-MF 1204还检查是否在DSLT-TRIGGER请求中或任何DSLT调度策略中显式配置了任何优先级。如果是这样，那么DSLT-MF 1204然后检查是否存在它接收到并需要处理的任何其它DSLT-TRIGGER请求。如果是这样，那么DSLT-MF1204使用优先级和调度信息来相对于彼此排名并排序DSLT-TRIGGER请求的执行。一旦调度和优先级允许，DSLT-MF 1204就将DSLT-REQ相应地散布到目标。取决于DSLT-MF 1204的优先化策略，如果接收到其优先级高于正被主动处理的DSLT-TRIGGER的新DSLT-TRIGGER，那么DSLT-MF 1204可以或者完成正被主动处理的DSLT-TRIGGER或者抢占它，以便处理新到达的优先级更高的DSLT-TRIGGER。在抢占的情况下，DSLT-MF 1204可以或者中止并回滚事务以利于稍后再次重新开始处理，或者DSLT-MF 1204可以在处理较高优先级事务时暂停处理并且稍后恢复它。这种中止与抢占的决定可以基于若干因素，诸如较高优先级的事务是否以与正被主动处理的较低优先级的事务相同的资源为目标。在这种情况下，DSLT-MF 1204可以决定中止较低优先级的事务，而对于两个事务以不同资源为目标的情况，DSLT-MF1204可以选择抢占较低优先级的事务或者，如果支持的话，并行地执行它们两者。

在图21的步骤8中，IoT设备1234和1236上的DSLT-CF 1208和1210各自接收其DSLT-REQ。两者都处理请求并创建本地DSLT资源，以在处理DSLT-REQ时跟踪事务状态。DSLT-CF 1208和1210用DSLT-REQ参数中包含的信息来配置其资源的属性。DSLT-CF 1208和1210通过首先检查作为目标的(一个或多个)资源的可用性来开始处理事务。如果(一个或多个)资源在IoT设备本地，那么DSLT-CF 1210检查执行资源的指定操作的可用性，并且没有当前预留并锁定该资源的其它事务。如果资源可用，那么DSLT-CF 1210可以锁定资源，使得它可以对其执行事务，而不会受到可能在当前事务处理期间到达的其它事务的干扰。在DSLT-CF 1210接收到DSLT-REQ并发现请求以不在本地设备上托管的资源为目标的情况下，DSLT-CF(可能与在本地设备上托管的本地DSLT-MF 1204合作)可以将DSLT-REQ请求重新定向到系统中的另一个设备，使得该另一个设备上的DSLT-CF 1210可以处理它。

在图21的步骤9中，每个IoT设备上的DSLT-CF 1210将状况返回到IoT服务器的DSLT-MF 1204，该状况指示已接收到DSLT-REQ、对事务的处理已开始、作为目标的资源可用且资源已被锁定以允许当前事务继续进行而不受其它事务的干扰。

在图21的步骤10中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF1208和1210(即IoT设备1和2)都已响应它们已成功锁定作为目标的资源。因此，DSLT-MF1204确定它可以继续指示作为目标的DSLT-CF执行事务。在DSLT-MF 1204没有接收到来自所有目标的成功锁定响应的情况下，它可以检查是否为该事务配置了任何完成标准，或者在其任何策略中指定了完成标准。如果指定了完成标准，那么DSLT-MF 1204可以检查该标准是否允许DSLT-MF 1204继续进行(例如，标准可以指定仅需要对目标的子集而不是所有目标完成事务)。可替代地，在一个或多个事务未能锁定作为目标的资源的情况下，DSLT-MF1204可以经由其配置参数或经由策略设置来检查是否将事务被配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务。在这种情况下，DSLT-MF 1204可以将重试发送到失败的(一个或多个)DSLT-CF。在DSLT-MF 1204确定无法满足完成条件并且无法重试事务的情况下，DSLT-MF 1204可以选择中止事务。为了中止事务，DSLT-MF 1204将中止命令发送到每个事务目标(这个示例中的IoT设备1234和1236上的DSLT-CF 1208和1210)。在接收到中止后，DSLT-CF通过回滚对被事务作为目标的(一个或多个)资源进行的任何修改来中止事务，使得其返回到在事务开始之前所处的相同状态。DSLT-CF还可以释放对作为目标的(一个或多个)资源的锁定。

可替代地，如果DSLT-CF 1210在步骤8中不能锁定资源，那么它可以提供关于为什么资源不可用的指示(资源不存在、访问权限不足、资源已被锁定)。如果资源被锁定，那么DSLT-CF 1210还可以提供关于资源可以被解锁的时间的指示(基于与被锁定的资源相关联的超时)。在这种情况下，DSLT-MF 1204可以在稍后的某个时间尝试重试事务(基于由DSLT-CF 1210提供的信息)。

在图21的步骤11中，IoT服务器上的DSLT-MF 1204向每个作为目标的DSLT-CF1208和1210发送请求以命令其执行事务。这个命令可以通过DSLT-MF 1204更新在每个IoT设备上托管的DSLT资源内的command属性来发出，该command属性指示DSLT-CF 1208和1210执行事务。

在图21的步骤12中，在接收到执行事务的命令后，每个设备上的DSLT-CF 1210对作为目标的资源执行事务中指定的操作。作为对作为目标的资源的操作的结果，IoT设备中的多个资源的状态可以改变。DSLT-CF 1210保留操作前(即，在执行操作之前)状态的副本，以防如果DSLT-REQ被中止并需要回滚时需要。

在图21的步骤13中，一旦执行完成，每个DSLT-CF 1210就会以执行的结果以及执行是否成功来响应DSLT-MF 1204。

在图21的步骤14中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF(即，IoT设备1234和1236两者)都已响应它们已对作为目标的资源成功执行了事务。因此，DSLT-MF 1204确定它可以继续指示作为目标的DSLT-CF 1208和1210通过使其持久并且还释放对资源的锁以允许其它事务访问资源及其更新后的状态来提交结果(例如，更新后的资源表示)。在DSLT-MF 1204没有接收到来自所有目标的成功执行响应的情况下，它可以检查是否为该事务配置了任何完成标准，或者在其任何策略中指定了完成标准。如果指定了完成标准，那么DSLT-MF 1204可以检查该标准是否允许DSLT-MF 1204继续进行(例如，标准可以指定仅需要对目标的子集而不是所有目标完成事务)。可替代地，在其中一个或多个执行的事务失败的情况下，DSLT-MF 1204可以经由其配置参数或经由策略设置来检查是否将事务被配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务。在DSLT-MF1204确定无法满足完成标准并且它无法重试事务的情况下，DSLT-MF 1204可以选择中止事务。为了中止事务，DSLT-MF 1204向每个事务目标(在这个示例中为IoT设备1234和1236上的DSLT-CF)发送中止命令。在接收到中止后，DSLT-CF 1210通过回滚对被事务作为目标的(一个或多个)资源进行的任何修改来中止该事务，使得其返回到与事务开始之前相同的状态。DSLT-CF 1210还可以释放对作为目标的(一个或多个)资源的锁。

在图21的步骤15中，IoT服务器1230上的DSLT-MF 1204向每个作为目标的DSLT-CF1208和1210发送请求，以命令其提交事务。这个命令可以由DSLT-MF 1204发出，更新在每个IoT设备上托管的DSLT资源中的command属性，该command属性指示DSLT-CF 1208和1210提交事务。

在图21的步骤16中，在接收到提交事务的命令后，每个设备上的DSLT-CF 1208和1210保存在执行事务时可以对资源进行的任何更新，使得其状态持久。基于对已提交的资源的状态的任何更新，DSLT-CF 1208和1210还可以向系统中可能已订阅作为目标的资源的任何其它实体发送关于更新后的状态的通知。然后DSLT-CF 1208和1210释放对作为目标的资源的任何锁并且可以删除任何保存的操作前状态。

在图21的步骤17中，一旦完成提交，每个DSLT-CF 1208和1210就会以提交的结果以及是否成功来响应DSLT-MF 1204。

在图21的步骤18中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF1208和1210(即，IoT设备1234和1236两者)都已响应它们已成功提交对作为目标的资源的事务。在其中一个或多个提交失败的情况下，DSLT-MF 1204可以经由其配置参数或经由策略设置来检查是否将事务被配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务。在DSLT-MF 1204确定无法满足完成条件并且无法重试事务的情况下，DSLT-MF1204可以报告事务的错误条件。

在图21的步骤19中，DSLT-MF 1204更新其本地托管的DSLT资源，该资源与它从IoT应用的DSLT-TF 1202接收的DSLT对应。这个更新中包括的是散布到IoT设备的每个DSLT的状况，该状况指示事务是否成功并且如果不成功则还指示失败的原因或理由。

在图21的步骤20中，一旦已完成DSLT处理，IoT服务器上的DSLT-MF 1204就可以通知IoT应用上的DSLT-TF 1202并包括DSLT的结果。DSLT-MF 1204可以包括DSLT的整体状况，以及对各个目标执行的每个已散布事务的个体状况。这可以包括解释失败的原因的错误或调试信息。这可以允许技术人员和操作人员在重新尝试发出另一个DSLT之前检测问题并更换或维修发生故障的设备。

在图21的步骤21中，在接收到完成的DSLT的通知之后，IoT应用的DSLT-TF 1202可以用接收到通知的确认来响应DSLT-MF 1204。

在图21的步骤22中，如果在任何时候IoT应用的DSLT-TF 1202希望检查DSLT处理的状况，那么它可以查询DSLT-MF 1204以检查该状况。当接收到查询请求时，DSLT-MF 1204可以检查其在对应DSLT资源中维护的DSLT的状态。

在图21的步骤23中，DSLT-MF 1204将DSLT处理的状态返回给发起DLTS状况查询的DSLT-TF 1202。

DSLT排序过程

图22示出了DSLT排序过程。

图22的步骤1是可选步骤。在图22的步骤1中，IoT应用的DSLT-TF 1202向IoT服务器的DSLT-MF 1204发送创建DSLT排序策略资源的(一个或多个)请求。每个策略资源可以包含控制DSLT-MF如何处理DSLT排序请求的一个或多个规则。这些规则可以与DSLT序列调度、DSLT序列的重试、DSLT序列的优先化以及针对DSLT序列的执行和完成标准有关。可替代地，IoT服务器的DSLT-MF 1204可以预先配置DSLT排序策略。

图22的步骤2是可选步骤。在图22的步骤2中，IoT服务器的DSLT-MF 1204接收并处理创建DSLT排序策略资源的请求。DSLT-MF 1204创建策略资源并且还用策略中指定的规则来配置其DSLT策略引擎1308。

图22的步骤3是可选步骤。在图22的步骤3中，IoT服务器的DSLT-MF 1204将响应返回到IoT应用的DSLT-TF 1202，以通知其是否接受策略资源中定义的规则。如果不，那么DSLT-MF 1204可以提供由DSLT-MF 1204接受的规则的经修改的版本。

在图22的步骤4中，IoT应用的DSLT-TF 1202向IoT服务器的DSLT-MF 1204发送DSLT-SEQ-TRIGGER请求。该请求可以包括若干参数，诸如作为目标的节点的集合(例如IoT设备1和IoT设备2)、要在这些节点上执行的DSLT的列表、何时执行序列的时间表、序列执行标准的集合、优先级、在尝试处理事务序列失败的情况下重试的次数、序列完成标准的集合、DSLT序列标识符以及DSLT-MF 1204可以用来以非阻塞方式处理序列的联系信息。

在图22的步骤5中，IoT服务器的DSLT-MF 1204接收并开始处理DSLT-SEQ-TRIGGER请求。DSLT-MF 1204创建DSLT序列资源，以在它们处理DSLT序列时跟踪事务序列状态。DSLT-MF 1204用步骤4中描述的DSLT排序请求参数中包含的信息来配置资源的属性。

在图22的步骤6中，IoT服务器的DSLT-MF 1204通过向IoT应用的DSLT-TF 1202返回指示已接收到请求并且已开始处理它的响应来以非阻塞方式处理请求。可替代地，DSLT-MF 1204可以以阻塞方式处理这个请求。

在图22的步骤7中，IoT服务器的DSLT-MF 1204解析请求以查找被序列作为目标的资源的列表。DSLT-MF 1204检测到作为目标的资源不在IoT服务器上本地托管，而是由IoT设备1和2托管。因此，DSLT-MF 1204准备序列中的第一/下一个对应DSLT，以散布到这些作为目标的设备。在散布DSLT之前，DSLT-MF 1204首先检查在原始DSLT-SEQ-TRIGGER请求中或在任何调度相关的策略中是否明确配置了任何调度信息。DSLT-MF 1204还检查在原始DSLT-SEQ-TRIGGER请求中或在任何策略中是否显式配置了任何优先级。如果是，那么DSLT-MF 1204然后检查是否存在它已接收到并且需要处理的任何其它DSLT-SEQ-TRIGGER请求。如果是，那么DSLT-MF 1204使用优先级信息来相对于彼此对DSLT-SEQ-TRIGGER请求的执行进行排名和排序。一旦时间表和优先级允许，DSLT-MF 1204就将DSLT-REQ请求相应地散布到目标。

一旦时间表和优先级允许，DSLT-MF 1204就相应地将DSLT-REQ散布到目标。取决于DSLT-MF 1204的优先化策略，如果接收到其优先级高于正被主动处理的DSLT-SEQ-TRIGGER的新DSLT-SEQ-TRIGGER，那么DSLT-MF 1204可以或者完成正被主动处理的DSLT-SEQ-TRIGGER或者抢占它，以便处理新到达且优先级更高的DSLT-SEQ-TRIGGER。在抢占序列的情况下，DSLT-MF 1204可以或者中止并回滚序列以利于稍后再次重新开始处理，或者DSLT-MF 1204可以在处理较高优先级事务时暂停处理该序列及其相关联的DSLT并且稍后恢复它。这种中止与抢占的决定可以基于若干因素，诸如较高优先级的事务是否以与正被主动处理的较低优先级的事务相同的资源为目标。在这种情况下，DSLT-MF 1204可以决定终止较低优先级的序列，而对于两个序列以不同资源为目标的情况，DSLT-MF 1204可以选择抢占较低优先级的序列或者，如果支持的话，并行地执行它们两者。

在图22的步骤8中，IoT设备1234和1236上的DSLT-CF 1208和1210各自接收其DSLT-REQ。两者都处理请求并创建本地DSLT资源，以在它们处理DSLT时跟踪事务状态。DSLT-CF 1208和1210用DSLT-REQ参数中包含的信息来配置其资源的属性。DSLT-CF 1208和1210通过首先检查作为目标的(一个或多个)资源的可用性来开始处理事务。如果(一个或多个)资源在IoT设备的本地，那么DSLT-CF 1210检查执行资源的指定操作的可用性并且不存在具有当前预留并锁定该资源的其它事务。如果资源可用，那么DSLT-CF 1210可以锁定资源，使得它可以在其上执行事务，而不会受到在当前事务的处理期间可能到达的其它事务的干扰。在DSLT-CF 1210接收到DSLT-REQ并发现该请求以不在本地设备上托管的资源为目标的情况下，DSLT-CF 1210可以将DSLT-REQ的目标重定位到系统中的另一个设备(可能在本地托管在设备上的DSLT-MF 1204的帮助下)，使得另一个设备上的DSLT-CF可以对其进行处理。

在图22的步骤9中，每个IoT设备上的DSLT-CF 1210将状况返回到IoT服务器的DSLT-MF 1204，该状况指示已接收到请求、已开始事务的处理、作为目标的资源可用并且资源已被锁定以允许当前事务继续进行而不受其它事务的干扰。

在图22的步骤10中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF1208和1210(即，IoT设备1234和1236两者)都已响应它们已成功锁定了作为目标的资源。因此，DSLT-MF 1204确定它可以继续指示作为目标的DSLT-CF 1210执行事务。在DSLT-MF1204没有接收到来自所有目标的成功锁定响应的情况下，它可以检查是否为事务配置了任何完成标准，或者在其任何策略中指定了完成标准。如果指定了完成标准，那么DSLT-MF1204可以检查该标准是否允许DSLT-MF 1204继续进行(例如，标准可以指定仅要求对目标的子集而不是所有目标完成事务)。可替代地，在其中一个或多个事务未能锁定作为目标的资源的情况下，DSLT-MF 1204可以经由其配置参数或经由策略设置来检查是否将事务配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务。在DSLT-MF 1204确定无法满足完成标准并且无法重试事务的情况下，DSLT-MF 1204可以选择中止事务。为了中止事务，DSLT-MF 1204向每个事务目标(这个示例中IoT设备1234和1236上的DSLT-CF 1208和1210)发送中止命令。在接收到中止后，DSLT-CF 1210通过回滚对被事务作为目标的(一个或多个)资源进行的任何修改来中止该事务，以使其返回到与事务开始之前相同的状态。DSLT-CF 1210还可以释放对作为目标的(一个或多个)资源的锁。

可替代地，如果DSLT-CF 1210在步骤8中不能锁定资源，那么它可以提供关于为什么资源不可用的指示(资源不存在、访问权限不足、资源已经被锁定)。如果资源被锁定，那么DSLT-CF 1210还可以提供关于资源可以被解锁的时间的指示(基于与被锁定的资源相关联的超时)。在这种情况下，DSLT-MF 1204可以在稍后的某个时间尝试重试事务(基于由DSLT-CF 1210提供的信息)。

在图22的步骤11中，IoT服务器1230上的DSLT-MF 1204向每个作为目标的DSLT-CF1208和1210发送请求以命令其执行事务。这个命令可以由DSLT-MF 1204发出以更新在每个IoT设备1234和1236上托管的DSLT资源内的command属性，该command属性指示DSLT-CF1208和1210执行事务。

在图22的步骤12中，在接收到执行事务的命令后，每个设备上的DSLT-CF 1208和1210对作为目标的资源执行事务中指定的操作。作为对作为目标的资源的操作的结果，IoT设备中多个资源的状态可以改变。DSLT-CF 1208和1210保留操作前(即，在执行操作之前)状态的副本，以防如果DSLT-REQ被中止并需要回滚时需要。

在图22的步骤13中，一旦执行完成，每个DSLT-CF 1208和1210就会以执行的结果以及执行是否成功来响应DSLT-MF 1204。

在图22的步骤14中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF1208和1210(即，IoT设备1234和1236两者)都已响应它们已成功地对作为目标的资源执行了事务。然后DSLT-MF 1204检查序列中是否还有任何剩余的DSLT。如果存在，那么DSLT-MF1204准备下一个DSLT并重复步骤7-14。如果序列中没有剩余的DSLT，那么DSLT-MF 1204确定它可以继续指示作为目标的DSLT-CF 1208提交作为序列一部分被处理的所有DSLT的结果。通过使其持久并且还释放对资源的锁定，以允许其它事务访问该资源及其更新后的状态。在DSLT-MF 1204没有接收到来自所有目标的成功执行响应的情况下，它可以检查是否为该事务配置了任何完成标准，或者在其任何策略中指定了完成标准。如果指定了完成标准，那么DSLT-MF 1204可以检查该标准是否允许DSLT-MF 1204继续进行(例如，标准可以指定仅要求对目标的子集而不是所有目标完成事务)。可替代地，在其中一个或多个执行的事务失败的情况下，DSLT-MF 1204可以经由其配置参数或经由策略设置来检查是否将事务配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务。在DSLT-MF 1204确定无法满足完成标准并且无法重试事务的情况下，DSLT-MF 1204可以选择中止事务。为了中止事务，DSLT-MF 1204向每个事务目标(这个示例中IoT设备1234和1236上的DSLT-CF 1208和1210)发送中止命令。在接收到中止后，DSLT-CF 1208和1210通过中止序列中的每个事务来中止该序列。这导致回滚对被序列中的事务作为目标的(一个或多个)资源所做的任何修改，使得它们被返回到序列开始之前所处的相同状态。DSLT-CF 1208和1210还可以释放对作为目标的资源的锁。

在图22的步骤15中，IoT服务器1230上的DSLT-MF 1204针对被执行的每个DSLT向每个作为目标的DSLT-CF 1208和1210发送一系列提交请求。这个命令可以由DSLT-MF 1204发出以更新在每个IoT设备1234和1236上托管的DSLT资源内的command属性，该command属性指示DSLT-CF 1208和1210提交事务。

在图22的步骤16中，在接收到提交给定DSLT的每个命令后，每个设备上的DSLT-CF1208和1210保存对资源的任何更新，该更新可以在执行事务时已经进行，使得其状态持久。基于对已提交的资源的状态的任何更新，DSLT-CF 1208和1210还可以向系统中可能已订阅作为目标的资源的任何其它实体发送有关更新后的状态的通知。然后，DSLT-CF 1208和1210释放对作为目标的资源的所有锁并且可以删除任何已保存的操作前状态。

在图22的步骤17中，一旦完成每个提交，每个DSLT-CF 1208和1210就用提交的结果以及是否成功来响应DSLT-MF 1204。

在图22的步骤18中，IoT服务器上的DSLT-MF 1204检测到所有作为目标的DSLT-CF1208和1210(即，IoT设备1234和1236两者)都已响应对相应的作为目标的资源成功提交了序列中的所有事务。在其中一个或多个提交失败的情况下，DSLT-MF 1204可以经由其配置参数或经由策略设置来检查是否将相应的事务序列配置为重试。如果允许重试，那么DSLT-MF 1204可以重试失败的事务序列。在DSLT-MF 1204确定无法满足完成标准并且无法重试事务序列的情况下，DSLT-MF 1204可以选择报告事务序列的错误条件。

在图22的步骤19中，DSLT-MF 1204更新其本地托管的DSLT序列资源，该资源与它从IoT应用的DSLT-TF 1202接收到的DSLT-SEQ-TRIGGER请求对应。这个更新中包括的是序列中每个DSLT的状况，并将其散布到IoT设备。这个状况指示事务序列是否成功，并且如果不成功，那么指示失败的原因。DSLT-MF 1204还可以包括序列中任何失败的DSLT的个体状况和失败信息。

在图22的步骤20中，一旦完成了DSLT序列处理，IoT服务器上的DSLT-MF 1204就可以通知IoT应用上的DSLT-TF 1202，并包括DSLT序列的结果。DSLT-MF 1204可以包括DSLT序列的整体状况，以及序列中对各个目标执行的每个已散布事务的个体状况。这可能包括解释失败的原因的错误或调试信息。这可以允许技术人员和操作人员在重新尝试发出另一个DSLT之前检测问题并更换或维修发生故障的设备。

在图22的步骤21中，在接收到完成的DSLT序列的通知后，IoT应用的DSLT-TF 1202可以用它接收到通知的确认来响应DSLT-MF 1204。

在图22的步骤22中，如果在任何时候IoT应用的DSLT-TF 1202希望检查DSLT序列处理的状况，那么它可以查询DSLT-MF 1204以检查该状况。当接收到查询请求时，DSLT-MF1204可以检查其在对应的DSLT序列资源中维护的DSLT序列的状态。

在图22的步骤23中，DSLT-MF 1204将DSLT序列处理的状态返回到发起DLTS状况查询的DSLT-TF 1202。

OneM2M分布式服务层事务实施例

下文描述针对oneM2M体系架构[oneM2M TS-0001]的DSLT机制和过程的若干实施例。向oneM2M体系架构添加DSLT支持使得能够以原子方式执行以多个资源为目标的请求集合，使得或者成功执行所有请求或者不执行任何请求。

在oneM2M体系架构中，DSLT-MF 1204和/或DSLT-CF 1210可以被实现为公共服务实体(CSE)(即，服务层实体)的新事务管理公共服务功能(CSF)，如图23中所示。

这个事务管理CSF 2304可以被用于在oneM2M系统中启用DSLT支持。可替代地，DSLT-MF 1204还可以被实现为一个或多个现有的oneM2M CSF的能力。

DSLT-TF 1202和/或DSLT-CF 1210功能也可以由oneM2M应用实体(AE)2306支持。例如，AE 2306可以经由其DSLT-TF 1202发起DSLT请求，并将这个请求发送到由CSE 2302托管的DSLT-MF 2304。可替代地，AE 2306可以经由其DSLT-CF 1210从由CSE托管的DSLT-MF1204接收DSLT请求。

为了使CSE 2302和AE 2306能够支持DSLT功能，以下小节定义若干DSLT oneM2M实施例。

DSLT对oneM2M请求参数的增强

为了在oneM2M体系架构中支持DSLT，在表3和表4中定义了用于DSLT和DSLT序列消息参数中的每个参数的新oneM2M请求参数。在oneM2M请求中支持这些参数使得多个oneM2M请求彼此相关联，并作为oneM2M请求的集合被原子处理。

为了支持基于事务的处理，可以增强现有的oneM2M响应类型参数以添加对两个附加的非阻塞响应类型的支持，即，nonBlockingTransactionRequestSynch和nonBlockingTransactionRequestAsynch。这两种响应类型可以被发起者用来指定要由托管CSE作为非阻塞和原子事务进行处理的请求。当接收到具有设置为这些新值之一的响应类型的请求时，托管CSE可以支持在oneM2M<request>资源中添加新的面向事务的属性，如稍后部分中所描述的。这些新的面向事务的响应类型和<request>属性使托管CSE能够以面向原子事务的方式处理原语，这将在后面的部分中详细描述。可替代地，托管CSE也可以以其它方式支持DSLT。例如，通过支持<transaction>资源以及一些附加DSLT属性或<sequence>资源。

oneM2M DSLT资源

为了在oneM2M体系架构中支持DSLT，可以使用若干与DSLT相关的属性。这些属性可以被添加到现有的oneM2M资源中，诸如如图24中所示的<request>或<transaction>资源。可替代地，可以定义新的资源类型以支持这些属性。对于定义新资源类型的情况，可能还需要包括与<request>和/或<transaction>资源中已经定义的属性类似的附加属性，以提供完整的解决方案。为了简洁起见，未包括这些现有的oneM2M属性。一个示例是包含oneM2M请求原语的原语属性。这个属性存在于<request>和<transaction>资源中，因此未示出。

这些新属性允许发起者(例如AE或CSE)向作为目标的CSE发出DSLT请求，并使CSE以非阻塞和原子方式对其进行处理。

表8：oneM2M DSLT资源属性

oneM2M DSLT序列资源

为了在oneM2M体系架构中支持DSLT序列，图25中示出了具有若干DSLT序列属性的<sequence>资源。

这个新资源和属性允许发起者(例如AE或CSE)发出DSLT排序请求，并使托管CSE以非阻塞以及原子方式处理DSLT序列。这个处理可以包括由<sequence>托管CSE代表发起者对各个DSLT的序列进行处理，以确保序列中的各个DSLT以原子方式执行，并且整个DSLT序列也以原子方式执行(即，或者所有DSLT都成功执行，或者都不执行)。这可以卸载发起者处理DSLT序列的开销和负担。对于发起者进行发送DSLT序列的重复请求的情况，这个功能可以特别有用。发起者不必自己处理这些重复的DSLT序列，而是可以将这项工作卸载到<sequence>托管CSE来代表它执行。

如果序列中的任何DSLT以由<sequence>托管CSE托管的本地资源为目标，那么<sequence>托管CSE可以以原子方式处理这些DSLT。在这个处理期间，<sequence>托管CSE可以锁定这些本地资源并确保在主动处理由序列中的DSLT指定的操作之外不对它们执行其它操作。一旦成功完成并提交了活动序列的处理，就可以释放这个锁定。

如果序列中的任何DSLT都以远程CSE上托管的资源为目标，那么<sequence>托管CSE可以通过在具有DSLT属性的远程CSE上创建<request>或<transaction>资源来向远程CSE发送DSLT请求。然后<sequence>托管CSE可以管理远程CSE上这些<request>或<transaction>资源的状态，以确保以原子方式处理DSLT。<sequence>托管CSE可以等待来自远程CSE的它能够获得关于作为目标的资源的锁的通知。一旦接收到通知，<sequence>托管CSE然后就可以通过更新对应<request>或<transaction>资源中的command属性来指示远程CSE执行DSLT。然后远程CSE可以等待来自远程CSE的已成功执行事务的通知。一旦接收到通知，<sequence>托管CSE就可以通过再次更新对应<request>或<transaction>资源中的command属性来指示远程CSE提交事务处理的结果，使得结果是持久的。然后<sequence>托管CSE可以等待来自远程CSE的被成功提交的通知。一旦接收到提交成功的通知，<sequence>托管CSE就可以完成对排序请求的处理，并将响应返回给其发起者。这个响应可以以阻塞或非阻塞的方式返回。如果在这个处理期间中的任何步骤远程CSE无法成功锁定、执行或提交序列中的任何DSLT，那么<sequence>托管CSE可以通过再次更新对应<request>或<transaction>资源中的command属性来中止该序列并确保作为目标的资源被其托管CSE回滚。在这个回滚之后，资源可以反映DSLT序列处理开始之前所处的相同状态。

表9：oneM2M DSLT序列资源属性

(一个或多个)oneM2M DSLT策略资源

为了在oneM2M体系架构中支持DSLT策略配置，表10中定义了若干DSLT策略属性。这些属性可以被添加到现有的oneM2M资源中，诸如现有的(一个或多个)oneM2M<mgmtObj>规格，诸如为oneM2M CMDH功能定义的规范。可替代地，可以定义新的资源类型以支持这些属性，诸如特定于DSLT功能的新oneM2M<mgmtObj>规范。例如，可以为DSLT调度策略、DSLT重试策略、DSLT优先化策略、DSLT完成标准策略和DSLT排序策略定义新的规范。

这些新属性允许发起者(例如AE或CSE)在CSE中配置与DSLT相关的策略，以控制其如何处理DSLT请求。

表10：oneM2M DSLT策略资源属性

DSLT对oneM2M<group>资源的增强

为了支持DSLT向一个或多个CSE上托管的多个目标资源的原子散布和处理，可以对oneM2M<group>资源使用新的<transactionFanOutPoint>虚拟资源和新的transactionState属性，如图26中所示。这个新资源和属性可以可选地由DSLT请求的发起者使用。当使用这个资源时，组托管CSE可以代表发起者来处置DSLT请求的处理。这个处理可以包括将DSLT扇出到该组指定的每个成员资源。如果成员资源托管在远程CSE上，那么组托管CSE可以通过创建以成员资源为目标的<request>或<transaction>资源将DSLT扇出到远程CSE。该处理还可以包括组托管CSE管理针对每个对应成员资源的每个DSLT的状态。可以代表发起者来完成此操作，以确保相对于彼此以原子方式执行DSLT(即，或者全部成功执行，或者都不执行)。这可以从发起者卸载处理DSLT的开销和负担。对于发起者做出向大量目标发送DSLT的重复请求的情况下，这个功能可以特别有用。发起者不必自己对于大量作为目标的资源处理这些重复的DSLT，而是可以将这项工作卸载到组托管CSE来代表其执行。可替代地，如果DSLT的发起者宁愿自己管理DSLT，那么也可以这样做，而不使用这个新资源。

这个虚拟资源没有表示，而是它是<group>资源的子资源。每当将oneM2M请求原语发送到<transactionFanOutPoint>资源时，组托管CSE就可以通过将对应的DSLT CREATE请求扇出到由父<group>资源的memberIDs属性指定的每个成员来处理该请求。对于每个扇出到成员的DSLT CREATE请求，组托管CSE可以用它从发起者接收到的原始请求原语来配置属性，用“初始”值来配置state属性，用小于结果到期时间参数的值(如果由Originator指定)来配置executionTime属性，或者在组托管CSE处配置的本地策略。此后，组托管CSE可以协调对扇出的DSLT请求的处置，使得它们相对于彼此以原子方式进行处理(即，所有扇出的事务或者成功完成或者全部被中止)。对于扇出到成员托管CSE的DSLT CREATE请求，这些CSE可以检查它们是否可以在指定的执行时间对成员资源执行指定的原语。如果检查成功，那么成员托管CSE可以向组托管CSE响应已成功创建DSLT。如果不成功，那么成员托管CSE可以以失败响应。组托管CSE可以维护定时器以用于事务的处理。如果在定时器到期之前从每个成员托管CSE接收到成功的DSLT创建响应，那么允许事务继续执行。组托管CSE可以可选地将命令发送到每个成员托管CSE，以指示他们执行并提交事务。如果不允许进行事务，那么组托管CSE可以通过向任何成员托管CSE发送指示它们成功创建了DSLT的DSLT DELETE请求来中止事务。如果允许执行事务，那么可以将来自在成员上执行的每个请求原语的各个响应返回到组托管CSE。然后，组托管CSE可以聚合响应并将结果返回给发起者。组托管CSE还可以维护定时器，用于响应的聚合。如果已接收到所有响应或者当定时器到期时，响应被聚合。在时间到期后接收到的响应可以被丢弃。如果在这个处理期间的任何步骤中，组托管CSE未从每个组成员获得它们能够锁定、执行或提交DSLT的成功确认，那么组托管CSE可以中止DSLT并确保作为目标的成员资源被其相应的成员托管CSE回滚。在这个回滚之后，资源可以反映DSLT处理开始之前所处的相同状态。组托管CSE还可以用事务的处理状态(例如，初始、锁定、已执行、已提交或已中止)来更新transactionState属性。

在另一个实施例中，可以代替地将新属性(例如transactionFanOutEnable)添加到<group>资源。这个属性可以被用于限定以<group>的现有<fanOutPoint>虚拟资源为目标的请求是被处理为DSLT还是非DSLT请求。这个替代方案未在图26中示出。

在又一个实施例中，组托管CSE可以代替地依赖请求中一个或多个DSLT相关参数的存在来检测以oneM2M<group>资源的现有<fanoutPoint>为目标的请求是否要作为DSLT被处理。

oneM2M lock属性

可以使用向所有oneM2M资源添加oneM2M“lock”公共属性。这个新属性可以由托管CSE用来保持跟踪以及通告资源是否处于锁定状态。例如，当处理DSLT时，其作为目标的资源可以被锁定。当被锁定时，可以更新lock属性以反映资源被锁定。这个属性可以被配置有诸如true或false之类的值。可替代地，这个属性可以支持反映不同类型的锁的值(例如，仅针对更新被锁定)。

oneM2M DSLT标识符

为了支持DSLT功能，可以使用oneM2M DSLT标识符。由于对个体DSLT请求的处理可以要求多个oneM2M请求，每个oneM2M请求具有其自己独特的oneM2M请求标识符，因此DSLT标识符提供了将这些分开的oneM2M请求关联到单个DSLT中的机制。这种关联级别使得能够对构成DSLT的各个oneM2M请求进行分布式和原子处理。表11提供了oneM2M DSLT标识符格式的描述。表12提供了对基于oneM2M DSLT的请求标识符的结构的描述。

表11–oneM2M DSLT标识符格式

表12–基于oneM2M DSLT的请求标识符格式

为了支持DSLT序列功能，描述DSLT序列的oneM2M标识符。由于DSLT序列的处理可以要求多个DSLT的处理，并且每个DSLT的处理可以要求多个oneM2M请求的处理，每个oneM2M请求都具有其自己的独特oneM2M请求标识符，因此DSLT序列标识符提供了将这多个DSLT与oneM2M请求相关联到单个DSLT序列中的机制。这种关联级别使得能够对构成DSLT序列的各个DSLT和oneM2M请求进行分布式和原子处理。表13提供了oneM2M DSLT序列标识符格式的描述。表14提供了对基于oneM2M DSLT序列的DSLT标识符的结构的描述。表15提供了对基于oneM2M DSLT序列的请求标识符的结构的描述。

表13–DSLT序列标识符格式

表14–基于oneM2M DSLT序列的DSLT标识符格式

表15–基于oneM2M DSLT序列的请求标识符格式

oneM2M DSLT组扇出过程

图27示出了oneM2M DSLT组扇出过程。

在图27的步骤1中，创建oneM2M<group>资源。该组的成员被配置为托管在ASN-CSE1和ASN-CSE2上的容器资源。这个组可以由托管DSLT-TF 1202的AE或系统中的另一个AE创建。

在图27的步骤2中，托管DSLT-TF 1202功能的AE构建oneM2M DSLT请求，以便在由ASN-CSE1和ASN-CSE2托管的容器资源下原子地创建oneM2M<contentInstance>。这个DSLT请求可以被构造为oneM2M<contentInstance>CREATE原语，如图27中所示。可替代地，这个DSLT请求可以被构造为oneM2M<transaction>CREATE请求原语，其将<contentInstance>CREATE原语封装在其primitive属性内。虽然未在图27中示出，但该请求也可以包括附加参数，诸如执行操作的时间表、执行标准的集合、优先级、在尝试处理事务失败时重试的次数以及完成标准的集合。

在图27的步骤3中，托管DSLT-TF 1202功能的AE将DSLT请求发送到支持DSLT-MF1204能力的IN-CSE 2702。该请求被发送到在步骤1中创建的组资源的<transactionFanOutPoint>子资源，使得IN-CSE 2702可以通过以原子方式将其散布到成员来处理请求。可以使用非阻塞事务请求来发送这个请求，这是一种新类型的oneM2M非阻塞请求。在这个请求中，AE可以指定通知回调URI，当非阻塞请求的处理完成时通知它时，IN-CSE 2702将使用该通知回调URI。可替代地，AE可以代替地使用阻塞请求。

在图27的步骤4中，IN-CSE 2702接收DSLT请求。如果请求是作为非阻塞事务发送的，那么IN-CSE 2702将创建oneM2M<request>资源，该资源支持面向事务的属性并将state属性配置为“初始”。这个<request>资源可以被IN-CSE 2702用来在它处理DSLT时跟踪DSLT请求资源。

在图27的步骤5中，IN-CSE 2702向AE返回指示它已接收到请求并且已开始处理该请求的响应。可替代地，可以以阻塞的方式处理该请求。

在图27的步骤6中，IN-CSE 2702然后使用组事务扇出能力来处理DSLT。

在图27的步骤7中，IN-CSE 2702检测到组成员资源未在IN-CSE 2702上本地托管。因此IN-CSE 2702准备对应的DSLT请求(即，<contentInstance>CREATE原语)以向这些作为目标的设备散布(即，扇出)。这个DSLT可以被构造为非阻塞的oneM2M<contentInstance>CREATE原语，如图27中所示。可替代地，这个DSLT请求可以被构造为oneM2M<transaction>CREATE请求原语，该原语将<contentInstance>CREATE原语封装在其primitive属性内。

在图27的步骤8中，ASN-CSE 2704和1206上的DSLT-CF 1208和1210各自接收DSLT以创建<contentInstance>并通过创建<request>(或可替代地<transaction>)资源来处理请求，以在它们处理DSLT时跟踪事务状态。ASN-CSE 2704和2706用包含在DSLT中的事务信息来配置这个资源的状态。ASN-CSE 2704和2706通过首先检查作为目标的(一个或多个)资源的可用性来开始处理事务。ASN-CSE 2704和2706检查执行资源的指定操作的可用性以及不存在当前已预留并锁定资源的其它事务。如果资源可用，那么ASN-CSE 2704和2706锁定资源，使得它可以对其进行事务，而不会受到在当前事务的处理期间可能到达的其它事务的干扰。

在图27的步骤9中，ASN-CSE 2704和2706向IN-CSE 2702返回状况，该状况指示已接收到DSLT、处理已对事务开始、作为目标的资源可用并且资源已被锁定以允许当前事务继续进行而不受其它事务的干扰。

在图27的步骤10中，IN-CSE 2702检测到所有成员已响应他们已成功锁定作为目标的资源。因此，IN-CSE 2702确定它可以继续指示作为目标的成员执行事务。

在图27的步骤11中，IN-CSE 2702向每个ASN-CSE 2704和2706发送请求，以更新其与事务相关联的对应<request>资源中的command属性。command属性用“Execute”值更新。可替代地，这个command属性可以是<transaction>资源的属性。

在图27的步骤12中，在接收到执行事务的命令后，每个ASN-CSE 2704和2706对作为目标的资源执行在事务中指定的操作。

在图27的步骤13中，一旦执行完成，每个ASN-CSE 2704和2706就会以执行的结果以及执行是否成功来响应IN-CSE 2702。

在图27的步骤14中，IN-CSE 2702检测到所有组成员都已响应它们已对作为目标的资源成功执行了事务。因此，IN-CSE 2702确定它可以继续指示成员通过使其持久并且还释放对资源的锁以允许其它事务访问资源及其更新后的状态(例如，更新后的资源表示形式)来提交结果。

在图27的步骤15中，IN-CSE 2702向每个组成员发送请求以命令其提交事务。这个命令可以由IN-CSE 2702发出，以更新在每个ASN-CSE 2704和2706上托管的<request>(或可替换地<transaction>)资源内的command属性，该command属性指示其提交事务。

在图27的步骤16中，在接收到提交事务的命令后，每个ASN-CSE 2704和2706保存在执行事务时可能已经进行的对资源的任何更新，使得其状态持久。然后ASN-CSE 2704和2706释放对作为目标的资源的任何锁。

在图27的步骤17中，一旦提交完成，每个ASN-CSE 2704和2706就会用提交的结果以及是否成功来响应IN-CSE 2702。

在图27的步骤18中，IN-CSE 2702检测到所有组成员(即，ASN-CSE 2704和2706两者)都已响应它们已对作为目标的资源成功提交了事务。

在图27的步骤19中，IN-CSE 2702更新其本地托管的与它从AE接收到的DSLT对应的<request>资源。这个更新中包括的是已散布到组成员的每个DSLT的状况，该状况指示事务是否成功以及失败的原因或理由。

在图27的步骤20中，一旦完成了DSLT处理，IN-CSE 2702就可以通知AE并包括DSLT的结果。IN-CSE 2702可以包括DSLT的总体状况以及对各个目标执行的每个已散布的事务的个体状态。这可以包括解释失败的原因的错误或调试信息。这可以允许技术人员和操作人员在重新尝试发出另一个DSLT之前检测问题并更换或维修发生故障的设备。

在图27的步骤21中，在接收到完成的DSLT的通知之后，AE可以用它接收到通知的确认来响应IN-CSE 2702。

在图27的步骤22中，如果AE在任何时候希望检查DSLT处理的状况，那么它可以查询由IN-CSE 2702托管的<request>资源以检查该状况。当接收到查询请求时，IN-CSE 2702可以检查其在这个资源中维护的DSLT的状态。

在图27的步骤23中，IN-CSE 2702将DSLT处理的状态返回给AE。

oneM2M DSLT排序过程

图28示出了oneM2M DSLT排序过程。

图28的步骤1是可选的。在图28的步骤1中，创建一个或多个oneM2M DSLT或DSLT排序策略资源。这些资源可以由托管DSLT-TF 1202的AE或系统中的另一个AE创建。每个策略资源可以包含控制由IN-CSE 2702托管的DSLT-MF 1204如何处理DSLT排序请求的一个或多个规则。这些规则可以与DSLT序列调度、DSLT序列的重试、DSLT序列的优先化以及针对DSLT序列的执行和完成标准有关。可替代地，可以用DSLT排序策略来预先配置IN-CSE 2702。

在图28的步骤2中，托管DSLT-TF 1202功能的AE构建oneM2M DSLT排序请求，以便在由ASN-CSE 2704和2706托管的容器资源下原子地创建一系列oneM2M<contentInstance>。这个DSLT排序请求可以被构造为oneM2M<sequence>CREATE原语。<sequence>资源可以将一系列<contentInstance>CREATE原语封装在其transactions属性内。每个<contentInstance>CREATE原语可以以IN-CSE 2702上托管的组资源为目标，其成员属性被配置为由ASN-CSE 2704和2706托管的容器资源。因此，每个<contentInstance>CREATE原语都是序列中分离的事务。虽然未在图27中示出，但可以将各个<contentInstance>CREATE原语创建为IN-CSE 2702上分离的<transaction>资源。可以用引用这些单独的<transaction>资源的标识符的列表来配置<sequence>资源的transactions属性。<sequence>CREATE原语还可以包括附加参数，诸如执行序列的时间表、执行标准的集合、优先级、在尝试处理序列失败的情况下重试的次数以及完成标准的集合。

在图28的步骤3中，托管DSLT-TF 1202功能的AE将DSLT排序请求发送到支持DSLT-MF 1204能力的IN-CSE 2702。这个请求可以使用阻塞或非阻塞请求发送到IN-CSE 2702。如果使用非阻塞，那么AE可以指定通知回调URI，当非阻塞请求的处理完成时通知它时，IN-CSE 2702将使用该通知回调URI。可替代地，AE可以代替地使用阻塞请求或现有的oneM2M非阻塞请求之一。

在图28的步骤4中，IN-CSE 2702接收DSLT排序请求。

在图28的步骤5中，IN-CSE 2702向AE返回指示它已接收到请求并且已开始处理该请求的响应。可替代地，可以以阻塞的方式处理请求。在图中未示出，但是AE可以创建对<sequence>资源的订阅，以便在发生对<sequence>的改变(例如，对序列状态的更新)时从IN-CSE 2702接收通知。

在图28的步骤6中，IN-CSE 2702然后开始处理DSLT序列。

在图28的步骤7中，IN-CSE 2702解析请求以获取序列中的第一个DSLT。IN-CSE2702检测到这个DSLT以由成员资源组成的组资源为目标，这些成员资源是在ASN-CSE 2704和2706上托管的容器。因此，IN-CSE 2702准备对应的DSLT请求(即，<contentInstance>CREATE原语)以向这些作为目标的设备散布(即，扇出)。这个SLT可以被构造为非阻塞的oneM2M<contentInstance>CREATE原语，如图27中所示。可替代地，这个DSLT请求可以被构造为oneM2M<transaction>CREATE请求原语，它将<contentInstance>CREATE原语封装在其primitive属性内。

在图28的步骤8中，IoT设备1234和1236上的DSLT-CF 1208和1210各自接收其DSLT-REQ。两者都处理请求并创建本地DSLT资源以在处理DSLT时跟踪事务状态。DSLT-CF用DSLT-REQ参数中包含的信息来配置其资源的属性。DSLT-CF通过首先检查作为目标的(一个或多个)资源的可用性来开始处理事务。如果(一个或多个)资源在IoT设备本地，那么DSLT-CF 1210检查执行资源的指定操作的可用性以及没有当前预留并锁定该资源的其它事务。如果资源可用，那么DSLT-CF可以锁定资源，使得它可以对其执行事务而不会受到在当前事务处理期间可能到达的其它事务的干扰。在DSLT-CF 12210接收到DSLT-REQ并发现该请求以未在本地设备上托管的资源为目标的情况下，DSLT-CF可以将DSLT-REQ的目标重定位到系统中的另一个设备(可能在本地托管在设备上的DSLT-CF 1204的帮助下)，使得另一个设备上的DSLT-CF 1208可以对其进行处理。

ASN-CSE 2704和2706上的DSLT-CF各自接收DSLT以创建<contentInstance>，并通过创建<request>(或可替代地<transaction>)资源来处理请求，以在它们处理DSLT时跟踪事务状态。ASN-CSE 2704和2706用包含在DSLT中的事务信息来配置这个资源的状态。ASN-CSE 2704和2706通过首先检查作为目标的(一个或多个)资源的可用性来开始处理事务。ASN-CSE 2704和2706检查执行资源的指定操作的可用性以及没有当前预留并锁定该资源的其它事务。如果资源可用，那么ASN-CSE 2704和2706锁定资源，使得它可以对其执行事务而不会受到在当前事务处理期间可能到达的其它事务的干扰。

在图28的步骤9中，ASN-CSE 2704和2706向IN-CSE 2702返回状况，该状况指示已接收到DSLT、处理已对事务开始、作为目标的资源可用并且资源已被锁定以允许当前事务继续进行而不受其它事务的干扰。

在图28的步骤10中，IN-CSE 2702检测到所有成员已响应它们已成功锁定作为目标的资源。因此，IN-CSE 2702确定它可以继续指示作为目标的成员执行事务。

在图28的步骤11中，IN-CSE 2702向每个ASN-CSE发送请求以更新其与事务相关联的对应<request>资源中的command属性。command属性用“Execute”值更新。可替代地，这个command属性可以是<transaction>资源的属性。

在图28的步骤12中，在接收到执行事务的命令后，每个ASN-CSE 2704和2706对作为目标的资源执行在事务中指定的操作。

在图28的步骤13中，一旦执行完成，每个ASN-CSE 2704和2706就会以执行的结果以及执行是否成功来响应IN-CSE 2702。

在图28的步骤14中，IN-CSE 2702检测到所有作为目标的成员(即，ASN-CSE 2704和2706)已响应它们已对作为目标的资源成功执行了事务。然后，IN-CSE 2702检查序列中是否还有任何剩余的DSLT。如果存在，那么IN-CSE 2702准备下一个DSLT并重复步骤7-14。如果序列中没有剩余的DSLT，那么IN-CSE 2702通过使其持久并且还释放对资源的锁以允许其它事务访问资源及其更新后状态来确定它可以继续指示成员提交作为序列的一部分被处理的所有DSLT的结果。

在图28的步骤15中，IN-CSE 2702针对已执行的每个DSLT向ASN-CSE 2704和2706发送一系列提交请求。每个命令可以由IN-CSE 2702发出，以更新<request>(或可替代地，在每个ASN-CSE 2704和2706上托管的<transaction>资源)内的command属性，该command属性指示其提交对应的事务。

在图28的步骤16中，在接收到提交给定DSLT的每个命令后，每个ASN-CSE 2704和2706保存在执行事务时可能已经对资源进行的任何更新，使得其状态持久。基于对已提交的资源的状态的任何更新，它还可以向系统中可能已订阅作为目标的资源的任何其它实体发送有关更新后的状态的通知。然后，每个ASN-CSE 2704和2706释放对作为目标的资源的任何锁并且可以删除任何保存的操作前状态。

在图28的步骤17中，一旦每个提交完成，每个ASN-CSE 2704和2706就会以提交的结果以及是否成功来响应IN-CSE 2702。

在图28的步骤18中，IN-CSE 2702检测到目标ASN-CSE 2704和2706中的每一个都已响应它们对相应的作为目标的资源已成功地提交了序列中的所有事务。

在图28的步骤19中，IN-CSE 2702更新其本地托管的DSLT序列资源。这个更新中包括的是序列中并且它散布的每个DSLT的状况。这个状况指示事务序列是否成功，并且如果失败，那么指示失败的原因。IN-CSE 2702还可以包括序列中任何失败的DSLT的个体状况和失败信息。

在图28的步骤20中，一旦DSLT序列处理完成，IN-CSE 2702就可以通知AE并包括DSLT序列的结果。IN-CSE 2702可以包括DSLT序列的整体状况以及对各个目标执行的序列中每个已散布事务的个体状况。这可以包括解释失败的原因的错误或调试信息。这可以允许技术人员和操作人员在重新尝试发出另一个DSLT之前检测问题并更换或维修发生故障的设备。

在图28的步骤21中，在接收到完成的DSLT序列的通知之后，AE可以用它接收到通知的确认来响应IN-CSE 2702。

在图28的步骤22中，如果AE在任何时候希望检查DSLT序列处理的状况，那么它可以查询IN-CSE 2702以检查该状况。当接收到查询请求时，IN-CSE 2702可以检查其在对应的DSLT序列资源中维护的DSLT序列资源的状态。

在图28的步骤23中，DSLT-MF 1204将DSLT序列处理的状态返回给发起DLTS状况查询的DSLT-TF 1202。

分布式服务层事务用户界面

诸如图形用户界面(GUI)之类的界面可以被用于帮助用户控制和/或配置与分布式事务管理相关的功能。诸如如图29中所示的界面2902、2904、2906和2908之类的用户界面可以被实现为允许用户向多个IoT设备发起基于DSLT的请求，使得可以原子方式执行请求。例如，为了在以协作方式操作的设备集上执行控制设置(诸如装配线部署)的原子更新。还可以实现用户界面，用于在设备、网关、服务器和应用中配置与DSLT相关的策略，以控制它们如何处理它们接收到的DSLT。应该理解的是，界面2902、2904、2906和2908可以使用诸如在下面描述的图30C-D中所示的显示器来产生。

示例M2M/IoT/WoT通信系统

本文描述的各种技术可以结合硬件、固件、软件或者，在适当的情况下，其组合来实现。这种硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置中。装置可以单独操作或彼此组合操作，以实现本文所描述的方法。如本文所使用的，术语“装置”、“网络装置”、“节点”、“设备”、“网络节点”等可以互换使用。

服务层可以是网络服务体系架构内的功能层。服务层通常位于应用协议层(诸如HTTP、CoAP或MQTT)之上，并为客户端应用提供增值服务。服务层还提供到位于较低资源层(诸如例如控制层和运输/接入层)的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层，以解决与M2M类型的设备和应用集成到诸如互联网/web、蜂窝、企业和家庭网络的部署中相关联的挑战。M2M服务层可以为各种设备提供对由服务层支持的上面提到的能力或功能集合的访问，服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、收费、数据管理、设备管理、发现、供应以及连接性管理，这些可以被各种应用共同使用。这些能力或功能经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API使这些各种应用可用。CSE或SCL是可以由硬件或软件实现的功能实体，并且提供暴露于各种应用或设备的(服务)能力或功能(即，这些功能实体之间的功能接口)，以便它们使用这样的能力或功能。

图30A是其中可以实现一个或多个公开的实施例的示例性机器对机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图。一般而言，M2M技术为IoT/WoT提供了构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台都可以是IoT/WoT以及IoT/WoT服务层等的组件或节点。通信系统10可以被用来实现所公开的实施例的功能，并且可以包括功能和逻辑实体，诸如DSLT-TF 1202、DSLT-MF 1204和1206；DSLT-CF 1208、1210、1212和1214；DSLT-MF API 1302；DSLT-MF处理1304；DSLT-MF序列处理1306；DSLT-MF策略引擎1308；DSLT-MF调度器1310；DSLT-CF API 1402；DSLT-CF处理1404；DSLT-CF序列处理1406；DSLT-MF CSF 2304；服务层102；应用协议104；应用106；CSE 302、306、306和2302；AE 304、704、706、708和2306，NSE 308，IoT应用1002和1230，IoT设备1004、1006、1008 1234、1236、1238和1240；IoT服务器1102和1232，IoT网关1242；IN-CSE 2702；ASN-CSE 2704和2706以及产生诸如接口2902、2904、2906和2908之类的接口的逻辑实体。

如图30A中所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以由向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网络组成。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。另外，例如，通信网络12可以包括其它网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或企业网络。

如图30A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域(FieldDomain)。基础设施域是指端到端M2M部署的网络侧，并且现场域是指通常在M2M网关后面的区域网络。现场域和基础设施域都可以包括各种不同网络节点(例如，服务器、网关、设备等)。例如，现场域可以包括M2M网关14和终端设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M终端设备18可以包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M终端设备18中的每一个被配置为使用通信电路系统经由通信网络12或直接无线电链路发送和接收信号。M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)或者通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M终端设备18可以经由通信网络12或直接无线电链路从M2M应用20或其它M2M设备18收集数据并向M2M应用20或其它M2M设备18发送数据。M2M终端设备18还可以从M2M应用20或M2M终端设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20接收，如下所述。M2M终端设备18和网关14可以经由各种网络进行通信，包括蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。

示例性M2M终端设备18包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。

参考图30B，域中所示的M2M服务层22为M2M应用20、M2M网关设备14、M2M终端设备18和通信网络12提供服务。M2M服务层22可以由一个或多个服务器、计算机、设备、虚拟机(例如，云/存储场等)等实现，包括例如以下描述的图30C和30D中所示的设备。M2M服务层22可以根据期望与任何数量的M2M应用、M2M网关14、M2M终端设备18和通信网络12进行通信。M2M服务层22可以由网络的一个或多个节点来实现，网络的节点可以包括服务器、计算机、设备等。M2M服务层22提供适用于M2M终端设备18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如，作为Web服务器、在蜂窝核心网络中、在云中等等。

与所示的M2M服务层22类似，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为现场域中的M2M网关14和M2M终端设备18提供服务。M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M设备通信。M2M服务层22'可以通过不同的服务提供商与服务层交互。M2M服务层22'可以由网络的一个或多个节点来实现，网络的节点可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。

还参考图30B，M2M服务层22和22'提供不同应用和行业(verticals)可以充分利用的核心服务递送能力集。这些服务功能使M2M应用20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。基本上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过网络12与服务层22和22'提供的服务相关联地进行通信。

本申请的方法可以被实现为服务层22和22'的一部分。服务层22和22'是软件中间件层，其通过应用编程接口(API)和底层网络接口的集合支持增值服务能力。ETSI M2M和oneM2M都使用可以包含本申请的连接方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在M2M设备(在其中被称为设备SCL(DSCL))、网关(在其中被称为网关SCL(GSCL))和/或网络节点(在其中被称为网络SCL(NSCL))中实现。oneM2M服务层支持通用服务功能(CSF)(即，服务能力)的集合。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。另外，本申请的连接方法可以被实现为M2M网络的一部分，该M2M网络使用面向服务的体系架构(SOA)和/或面向资源的体系架构(ROA)来访问服务(诸如本申请的连接方法)。

在一些实施例中，M2M应用20和20'可以与所公开的系统和方法结合使用。M2M应用20和20'可以包括与UE或网关交互的应用，并且还可以与其它公开的系统和方法结合使用。

在一个实施例中，逻辑实体(诸如DSLT-TF 1202、DSLT-MF 1204和1206；DSLT-CF1208、1210、1212和1214；DSLT-MF API 1302；DSLT-MF处理1304；DSLT-MF序列处理1306；DSLT-MF策略引擎1308；DSLT-MF调度器1310；DSLT-CF API 1402；DSLT-CF处理1404；DSLT-CF序列处理1406；DSLT-MF CSF 2304；服务层102；CSE 302、306、306和2302；NSE 308；IoT服务器1102和1232，IoT网关1242；IN-CSE 2702；ASN-CSE 2704和2706)可以托管在由M2M节点(诸如M2M服务器、M2M网关或M2M设备)托管的M2M服务层实例内，如图30B中所示。例如，这些逻辑实体可以包括M2M服务层实例内的个体服务能力，或者作为现有服务能力内的子功能。

M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全性和监控。如上面所提到的，在系统的设备、网关、服务器和其它节点之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及遗留系统集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。

一般而言，服务层22和22'定义软件中间件层，该软件中间件层通过应用编程接口(API)和底层联网接口的集合来支持增值服务能力。ETSI M2M和oneM2M体系架构都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在ETSI M2M体系架构的各种不同节点中实现。例如，服务层的实例可以在M2M设备中实现(其中它被称为设备SCL(DSCL))、在网关中实现(其中它被称为网关SCL(GSCL))和/或在网络节点中实现(其中它被称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)的集合(即，服务功能)。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。第三代合作伙伴计划(3GPP)还已经定义了用于机器类型通信(MTC)的体系架构。在那种体系架构中，服务层及其提供的服务功能是作为服务能力服务器(SCS)的一部分实现的。无论是在ETSI M2M体系架构的DSCL、GSCL或NSCL中实施，在3GPP MTC体系架构的服务能力服务器(SCS)中实施，在oneM2M体系架构的CSF或CSE中实施，还是在网络的某个其它节点中实施，服务层的实例都可以被实现为或者在网络中的一个或多个独立节点(包括服务器、计算机以及其它计算设备或节点)上执行的逻辑实体(例如，软件、计算机可执行指令等)，或者被实现为一个或多个现有节点的一部分。作为示例，服务层或其组件的实例可以以在具有下述图30C或图30D中所示的一般体系架构的网络节点(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现。

另外，本文中描述和附图中示出的逻辑实体可以被实现为使用面向服务的体系架构(SOA)和/或面向资源的体系架构(ROA)访问本申请的服务的M2M网络的一部分。

图30C是网络装置30的示例硬件/软件体系架构的框图，网络装置诸如是M2M设备18、M2M网关14、M2M服务器22等。装置30的体系架构可以被用于实现本文中描述和附图中所示的任何上面提到的逻辑实体。装置30可以是如图30A-B中所示的M2M网络的一部分或者是非M2M网络的一部分。如图30C中所示，装置30可以包括处理器32、不可移动存储器44、可移动存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。装置30还可以包括通信电路系统，诸如收发器34和发送/接收元件36。将认识到的是，装置30可以包括前述元件的任何子组合，同时保持与实施例一致。这种装置可以是实现本文描述的功能的节点。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP内核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般而言，处理器32可以执行存储在装置的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行装置的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使装置30能够在无线或有线环境中操作的任何其它功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。例如，处理器32还可以执行安全操作，诸如认证、安全密钥协商和/或加密操作，诸如在接入层和/或应用层。

如图30C中所示，处理器32耦合到其通信电路系统(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统，以便使装置30经由其所连接的网络与其它网络装置进行通信。特别地，处理器32可以控制通信电路系统，以便执行本文和权利要求中描述的发送和接收步骤。虽然图30C将处理器32和收发器34描绘为分离的组件，但是将认识到的是，处理器32和收发器34可以一起集成在电子包装或芯片中。

发送/接收元件36可以被配置为向其它节点发送信号或从其它装置接收信号，包括M2M服务器、网关、设备等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置为例如发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。将认识到的是，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任意组合。

此外，虽然发送/接收元件36在图30C中被描绘为单个元件，但是装置30可以包括任何数量的发送/接收元件36。更具体而言，装置30可以采用MIMO技术。因此，在实施例中，装置可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置为调制将由发送/接收元件36发送的信号并且解调由发送/接收元件36接收的信号。如上所述，装置30可以具有多模式能力。因此，例如，收发器34可以包括多个收发器，用于使装置30能够经由多个RAT(诸如UTRA和IEEE 802.11)进行通信。

处理器32可以从任何类型的合适存储器(诸如不可移动存储器44和/或可移动存储器46)访问信息，并将数据存储在其中。例如，处理器32可以在其存储器中存储会话上下文，如上所述。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘，或任何其它类型的存储器存储设备。可移动存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从物理地位于装置30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为控制显示器上的视觉指示以反映系统的状况或从用户获得输入或向用户显示关于能力或设置的信息。可以在显示器上示出的图形用户界面可以在API之上分层，以允许用户交互地执行本文描述的功能。

处理器32可以从电源48接收电力，并且可以被配置为向装置30中的其它组件分配和/或控制电力。电源48可以是用于为装置30供电的任何合适的设备。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。

处理器32还可以耦合到GPS芯片组50，GPS芯片组50被配置为提供关于装置30的当前位置的位置信息(例如，经度和纬度)。将认识到的是，装置30可以通过任何合适的位置确定方法获取位置信息，同时保持与实施例一致。

处理器32还可以耦合到其它外围设备52，外围设备52可以包括提供附加特征、功能和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物测定(例如，指纹)传感器、电子罗盘、卫星收发器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等等。

装置30可以在其它装置或设备中实施，诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子卫生设备、机器人、工业装备、无人机、车辆(诸如小汽车、卡车、火车或飞机)。装置30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这种装置或设备的其它组件、模块或系统。可替代地，装置30可以包括装置或设备，诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或eHealth设备、机器人、工业设备、无人机、车辆(诸如汽车、卡车、火车或飞机)。

图30D是示例性计算系统90的框图，该示例性计算系统90也可以被用于实现M2M网络的一个或多个逻辑实体或节点，诸如M2M服务器、网关、设备或其它节点或装置。计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，其中计算机可读指令可以是软件的形式，不管这种软件在哪里或通过什么手段来存储或访问。计算系统90可以执行或包括逻辑实体，诸如DSLT-TF 1202、DSLT-MF 1204和1206；DSLT-CF 1208、1210、1212和1214；DSLT-MF API 1302；DSLT-MF处理1304；DSLT-MF序列处理1306；DSLT-MF策略引擎1308；DSLT-MF调度器1310；DSLT-CF API 1402；DSLT-CF处理1404；DSLT-CF序列处理1406；DSLT-MF CSF 2304；服务层102；应用协议104；应用106；CSE 302、306、306和2302；AE 304、704、706、708和2306，NSE 308，IoT应用1002和1230，IoT设备1004、1006、1008、1234、1236、1238和1240；IoT服务器1102和1232，IoT网关1242；IN-CSE 2702；ASN-CSE 2704和2706以及产生诸如接口2902、2904、2906和2908之类的接口的逻辑实体。例如，计算系统90可以是M2M设备、用户装备、网关、UE/GW，或包括移动核心网络、服务层网络应用提供商、终端设备18或M2M网关设备14的节点的任何其它节点。这种计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。

在操作中，CPU 91取出、解码并执行指令，并经由计算机的主数据传输路径，系统总线80，向其它资源传送信息和从其它资源传送信息。这种系统总线连接计算系统90中的组件并定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线，以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围组件互连)总线。

耦合到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路系统。ROM 93一般包含不能被容易地修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其它硬件设备读取或改变。对RAM 82和/或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，该地址翻译功能在执行指令时将虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，该存储器保护功能隔离系统内的进程并将系统进程与用户进程隔离。因此，以第一模式运行的程序只可以访问由其自己的进程虚拟地址空间映射的存储器；除非已设置进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。

此外，计算系统90可以包含外围设备控制器83，其负责将来自CPU 91的指令传送到外围设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85。

由显示器控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示器控制器96包括生成发送到显示器86的视频信号所需的电子组件。

另外，计算系统90可以包含通信电路系统，诸如例如网络适配器97，其可以用于将计算系统90连接到外部通信网络(诸如图30A和图30B的网络12)，以使得计算系统90能够与网络的其它节点通信。

用户装备(UE)可以是最终用户用来通信的任何设备。它可以是手持电话、配备移动宽带适配器的便携式计算机或任何其它设备。例如，UE可以被实现为图30A-B的M2M终端设备18或图30C的设备30。

应该理解的是，本文描述的任何或所有系统、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，所述指令在由机器(诸如M2M网络的节点或装置，包括例如M2M服务器、网关、设备等)执行时执行和/或实现本文描述的系统、方法和处理。具体而言，上述任何步骤、操作或功能，包括DSLT-TF 1202、DSLT-MF1204和1206；DSLT-CF 1208、1210、1212和1214；DSLT-MF API 1302；DSLT-MF处理1304；DSLT-MF序列处理1306；DSLT-MF策略引擎1308；DSLT-MF调度器1310；DSLT-CF API 1402；DSLT-CF处理1404；DSLT-CF序列处理1406；DSLT-MF CSF 2304；服务层102；应用协议104；应用106；CSE 302、306、306和2302；AE 304、704、706、708和2306，NSE 308，IoT应用1002和1230，IoT设备1004、1006、1008、1234、1236、1238和1240；IoT服务器1102和1232，IoT网关1242；IN-CSE 2702；ASN-CSE 2704和2706以及产生诸如接口2902、2904、2906和2908之类的接口的设备或实体的操作，可以以存储在计算机可读存储介质上的计算机可执行指令的形式实施。计算机可读存储介质包括以用于存储信息的任何非瞬态(即，有形或物理)方法或技术实现的易失性和非易失性介质，以及可移动和不可移动介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字通用盘(DVD)或其它光盘存储装置，磁带盒、磁带、磁盘存储装置或其它磁存储设备，或者可以用于存储期望信息并且可由计算机访问的任何其它有形或物理介质。

而且，应该理解的是，执行图11、12、15-22、27和28中所示的步骤的实体可以是可以以软件(即，计算机可执行指令)的形式实现的逻辑实体，其中软件存储在被配置用于无线和/或网络通信的装置或计算机系统(诸如在图30C或图30D中示出的那些)的存储器中并在其处理器上执行。即，图11、12、15-22、27和28中所示的(一个或多个)方法可以以软件(即，计算机可执行指令)的形式实现，其中软件存储在装置(诸如图30C或图30D中所示的装置或计算机系统)的存储器中，其中计算机可执行指令在由装置的处理器执行时执行图11、12、15-22、27和28中所示的步骤。还应该理解的是，图11、12、15-22、27和28中所示的一个或多个实体和相关联的功能可以以一个或多个虚拟化网络功能的形式实现。网络功能不一定必须直接通信，而是可以经由转发或路由功能进行通信。还应该理解的是，图11、12、15-22、27和28中所示的任何发送和接收步骤可以由装置或实体的通信电路系统在装置的处理器和它执行的计算机可执行指令(例如，软件)的控制下执行。

还应该理解的是，诸如“发送请求”、“发送响应”、“接收请求”、“接收响应”等之类的短语可以包括经由通信网络向通信网络上的实体发送或从通信网络上的实体接收消息(例如，以分组或其它定义的位序列的形式)，其中消息的内容或数据将通知接收方请求或响应什么。因此，例如，短语“发送请求”可以等同于短语“发送请求…的消息”、“发送包括请求的消息”等。

在描述本公开的主题的优选实施例时，如图所示，为了清楚起见而采用特定术语。但是，要求保护的主题并不旨在限于如此选择的具体术语，并且应该理解的是，每个具体元素包括以相似方式操作以实现相似目的的所有技术等同物。

本书面描述使用示例来公开本发明，包括最佳模式，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有与权利要求的字面语言没有不同的元件，或者如果它们包括与权利要求的字面语言无实质差别的等效元件，那么这些其它示例意图在权利要求的范围内。

Claims (20)

1.一种包括处理器和存储器的分布式服务层事务管理装置，所述装置还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使所述装置实现通信网络的分布式服务层事务DSLT服务的第一服务层实体，该DSLT服务提供RESTful应用编程接口API，并使第一服务层实体：

从在通信网络上执行的应用接收对分布式服务层事务的请求，所述请求指定要对作为目标的DSLT API资源集原子执行的命令，其中作为目标的DSLT API资源由通信网络的DSLT服务的多个其它服务层实体托管；

向所述多个其它服务层实体中的每个服务层实体发送锁定由该其它服务层实体托管的任何作为目标的DSLT API资源的请求；

从所述多个其它服务层实体中的每一个服务层实体接收指示该服务层实体是否能够锁定由该服务层实体托管的作为目标的DSLT API资源的响应；

基于接收到指示所述多个其它服务层实体能够锁定作为目标的DSLT API资源集的响应，向所述多个其它服务层实体发送对作为目标的DSLT API资源集执行命令的原子执行的请求；

从所述多个其它服务层实体接收指示该命令对作为目标的DSLT API资源集成功执行的响应；

基于接收到指示命令已对作为目标的DSLT API资源集成功执行的响应，向所述多个其它服务层实体发送提交分布式事务的请求；以及

向所述应用发送指示已成功执行分布式服务层事务的响应。

2.如权利要求1所述的分布式服务层事务管理装置，其中计算机可执行指令还使第一服务层实体在从所述应用接收到对分布式服务层事务的请求后在第一服务层实体的存储器中创建表示所述分布式服务层事务并且包括关于所述分布式服务层事务的状态的信息的资源，其中经由通信网络使得所述应用可访问所述资源。

3.如权利要求2所述的分布式服务层事务管理装置，其中所述资源包括唯一地识别事务的事务标识符属性以及其中存储与分布式服务层事务的状态有关的信息的事务状态属性。

4.如权利要求2所述的分布式服务层事务管理装置，其中所述资源包括控制第一服务层实体何时发起对分布式服务层事务的请求的处理的执行时间属性。

5.如权利要求1所述的分布式服务层事务管理装置，其中所述装置包括通信网络的服务器或网关之一。

6.如权利要求1所述的分布式服务层事务管理装置，其中计算机可执行指令还使第一服务层实体根据定义用于处理请求的规则的策略来处理对分布式服务层事务的请求。

7.如权利要求1所述的分布式服务层事务管理装置，其中计算机可执行指令还使第一服务层实体调度对分布式服务层事务的请求的处理。

8.如权利要求1所述的分布式服务层事务管理装置，其中对分布式服务层事务的请求是请求序列的一部分。

9.如权利要求1所述的分布式服务层事务管理装置，其中计算机可执行指令还使第一服务层实体向所述多个其它服务层实体发送指示对命令的执行的限制的标准。

10.如权利要求1所述的分布式服务层事务管理装置，其中计算机可执行指令还使第一服务层实体向所请求的分布式服务层事务指派优先级。

11.一种分布式服务层事务管理方法，包括：

在通信网络的分布式服务层事务DSLT服务的第一服务层实体处，从在通信网络上执行的应用接收对分布式服务层事务的请求，该DSLT服务提供RESTful应用编程接口API，所述请求指定要对作为目标的DSLT API资源集原子执行的命令，其中作为目标的DSLT API资源由通信网络的DSLT服务的多个其它服务层实体托管；

由第一服务层实体向所述多个其它服务层实体中的每个服务层实体发送锁定由该其它服务层实体托管的任何作为目标的DSLT API资源的请求；

由第一服务层实体从所述多个其它服务层实体中的每一个服务层实体接收指示该服务层实体是否能够锁定由该服务层实体托管的作为目标的DSLT API资源的响应；

基于接收到指示所述多个其它服务层实体能够锁定作为目标的DSLT API资源集的响应，由第一服务层实体向所述多个其它服务层实体发送对作为目标的DSLT API资源集执行命令的原子执行的请求；

由第一服务层实体从所述多个其它服务层实体接收指示该命令对作为目标的DSLTAPI资源集成功执行的响应；

基于接收到指示命令已对作为目标的DSLT API资源集成功执行的响应，由第一服务层实体向所述多个其它服务层实体发送提交分布式服务层事务的请求；以及

向所述应用发送指示已成功执行分布式服务层事务的响应。

12.如权利要求11所述的分布式服务层事务管理方法，还包括由第一服务层实体在从所述应用接收到对分布式服务层事务的请求后创建表示所述分布式服务层事务并且包括关于所述分布式服务层事务的状态的信息的资源，其中经由通信网络使得所述应用可访问所述资源。

13.如权利要求12所述的分布式服务层事务管理方法，其中所述资源包括唯一地识别事务的事务标识符属性以及其中存储与分布式服务层事务的状态有关的信息的事务状态属性。

14.如权利要求12所述的分布式服务层事务管理方法，其中所述资源包括控制第一服务层实体何时发起对分布式服务层事务的请求的处理的执行时间属性。

15.如权利要求11所述的分布式服务层事务管理方法，其中第一服务层实体在通信网络的服务器或网关之一上实现。

16.如权利要求11所述的分布式服务层事务管理方法，还包括根据定义用于处理请求的规则的策略来处理对分布式服务层事务的请求。

17.如权利要求11所述的分布式服务层事务管理方法，还包括调度对分布式服务层事务的请求的处理。

18.如权利要求11所述的分布式服务层事务管理方法，其中对分布式服务层事务的请求是请求序列的一部分。

19.如权利要求11所述的分布式服务层事务管理方法，还包括向所述多个其它服务层实体发送指示对命令的执行的限制的标准。

20.如权利要求11所述的分布式服务层事务管理方法，还包括向所请求的分布式服务层事务指派优先级。

Images