U.S. patent application number 17/171312 was filed with the patent office on 2021-12-30 for transaction resources for stateless message protocol.
The applicant listed for this patent is Intel Corporation. Invention is credited to Gregory Burns, Ned M. Smith, Ravi Subramaniam.
Application Number | 20210409498 17/171312 |
Document ID | / |
Family ID | 1000005839872 |
Filed Date | 2021-12-30 |
United States Patent
Application |
20210409498 |
Kind Code |
A1 |
Smith; Ned M. ; et
al. |
December 30, 2021 |
TRANSACTION RESOURCES FOR STATELESS MESSAGE PROTOCOL
Abstract
A communications device, such as an Internet-of-Things device,
includes an entity resource to originate or consume data, and core
resources to facilitate stateless messaging with a remote device,
with the messaging being associated with the entity resource.
Transaction resources are provided to manage a transaction with the
remote device. The transaction includes a sequence of messages
associated with the entity resource. The transaction resources
include a transaction state machine to represent a current
intra-transactional ephemeral state from among a plurality of
intra-transactional ephemeral states representing progression of
the transaction, a commit handler to institute a persistent state
change related to the entity resource in response to a successful
completion of the transaction, and a transaction communicator to
conduct intra-transaction communications via the core resources
directed to corresponding transactional resources of the remote
device.
Inventors: |
Smith; Ned M.; (Beaverton,
OR) ; Burns; Gregory; (Seattle, WA) ;
Subramaniam; Ravi; (San Jose, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Intel Corporation |
Santa Clara |
CA |
US |
|
|
Family ID: |
1000005839872 |
Appl. No.: |
17/171312 |
Filed: |
February 9, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16473597 |
Jun 25, 2019 |
10924555 |
|
|
PCT/US2017/014915 |
Jan 25, 2017 |
|
|
|
17171312 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/466 20130101;
H04L 67/40 20130101; H04L 67/142 20130101 |
International
Class: |
H04L 29/08 20060101
H04L029/08; G06F 9/46 20060101 G06F009/46; H04L 29/06 20060101
H04L029/06 |
Claims
1. A communications device, comprising: a computing platform,
including a processor, a data store, and communication facilities,
the computing platform to implement: an entity resource to
originate or consume data; core resources to facilitate stateless
messaging with a remote device associated with the entity resource;
and transaction resources to manage a transaction with the remote
device that includes a sequence of messages associated with the
entity resource, the transaction resources including: a transaction
state machine to represent a current intra-transactional ephemeral
state from among a plurality of intra-transactional ephemeral
states representing progression of the transaction; a commit
handler to institute a persistent state change related to the
entity resource in response to a successful completion of the
transaction; and a transaction communicator to conduct
intra-transaction communications via the core resources directed to
corresponding transactional resources of the remote device.
Description
TECHNICAL FIELD
[0001] This application is a continuation of U.S. patent
application Ser. No. 16/473,597, filed Jun. 25, 2019, which is a
U.S. National Stage Application Under 35 U.S.C. 371 from
International Application No. PCT/US2017/014915, filed Jan. 25,
2017, published as WO 2018/140006, all of which are incorporated
herein by reference in their entirety.
TECHNICAL FIELD
[0002] Embodiments described herein generally relate to data
communications and, more particularly, to facilitating low-latency
transactions in communication systems utilizing stateless messaging
protocols.
BACKGROUND
[0003] The Internet of Things (IoT) is the networking of physical
objects, such as sensors and actuators, vehicles, building
automation systems, information devices, and other items, which are
embedded with electronics, software, and network connectivity that
enables these objects to collect and exchange data. IoT as a new
communications and interaction paradigm is rapidly developing to
offer many new and useful features in applications such as smart
home, smart city, industrial control, and smart transportation.
[0004] IoTivity is an IoT framework that implements Open
Connectivity Foundation (OCF) standards to ensure interoperability
of IoT devices. IoTivity features a declarative model for
describing resource interactions among IoT devices. It is
well-suited for using a representational state transfer (RESTful)
approach to distributed computing. RESTful behavior allows servers,
or devices responding to messages, to remain stateless as a
strategy for improved scalability. However, some interactions
involve maintaining the protocol state, such as provisioning
devices into a network, establishing or adjusting operational
settings or polices, exchanging credentials, and the like. An
incomplete configuration leaves the device in an undefined
operational state where either the configuration is to be
completed, or rolled back to a previous state.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] In the drawings, which are not necessarily drawn to scale,
like numerals may describe similar components in different views.
Like numerals having different letter suffixes may represent
different instances of similar components. Some embodiments are
illustrated by way of example, and not limitation, in the figures
of the accompanying drawings.
[0006] FIG. 1 is a high-level diagram illustrating examples of
various types of computing platforms, including IoT platforms, on
which aspects of the subject matter may be implemented according to
some embodiments.
[0007] FIG. 2 is a block diagram illustrating a computer system in
the example form of a general-purpose machine.
[0008] FIG. 3A is a diagram illustrating an exemplary hardware and
software architecture of a computing device such as the one
depicted in FIG. 2, in which various interfaces between hardware
components and software components are shown.
[0009] FIG. 3B is a block diagram illustrating examples of
processing devices that may be implemented on a computing device
according to some embodiments.
[0010] FIG. 3C is a block diagram illustrating example components
of a processing device, according to various embodiments.
[0011] FIG. 4A is a diagram illustrating an example IoT device
architecture according to some embodiments, at a high level of
abstraction.
[0012] FIG. 4B illustrates an example set of components that are
included in transaction resources according to some
embodiments.
[0013] FIG. 5 is a diagram illustrating an example state graph data
structures according to an embodiment.
[0014] FIG. 6 is a diagram illustrating a transaction message
collection according to an example.
[0015] FIG. 7 is a block diagram illustrating the transaction
resources of an IoT device according to an embodiment utilizing an
IoT framework such as OCF/IoTivity.
[0016] FIG. 8 is a flow diagram illustrating the progress of an
example transaction between two IoT devices, each utilizing its
respective transaction resources.
[0017] FIG. 9 is a system architecture and data flow diagram
illustrating example interactivity between a pair of IoT devices
utilizing principles of some embodiments.
DETAILED DESCRIPTION
[0018] Aspects of the embodiments are directed to communications
between devices using stateless protocols. In general, a stateless
protocol is a communications protocol that treats each request as
an independent transaction that is unrelated to any previous
request so that the communication is composed of independent pairs
of request and response. A stateless protocol does not require the
server, or responsive entity, to retain session information or
status about each communications partner for the duration of
multiple requests. For ease of illustration, various examples are
described herein in the context of IoTivity protocols, and RESTful
architecture. However, it will be understood that principles of the
embodiments may be applicable in various other contexts or
applications, particularly those utilizing a stateless
communications paradigm.
[0019] According to some aspects of the embodiments, each
transaction, which in the present context, refers to a series of
exchanged messages between entities to achieve a particular result,
may involve a sequence of messages to be communicated. Accordingly,
different states may be maintained by an initiating entity,
responsive entity, or both. Example use cases involving sequences
of operations include, without limitation, key exchange protocols,
provisioning, setup and manageability, key and certificate
management, access policy provisioning, on-boarding, and the
like.
[0020] In a conventional RESTful paradigm, multi-state transactions
invite various challenges. For one, there is no effective
coordination between each initiator and responder. There is no
guarantee the protocol will progress as intended, and there is no
provision for data cleanup if the protocol aborts.
[0021] To facilitate management of such transactions, a
transactional resource is instantiated for each transaction that
coordinates multiple RESTful message exchanges. The transaction
resource is discoverable by other devices; hence they may interact
with the resource--effectively invoking the transaction.
[0022] In some examples, the various message exchanges involved in
a given transaction are modeled using a resource property state
machine that specifies the sequence in which the various RESTful
messages may be applied. Message contents or protocol data units
(PDUs) are defined as resources such that RESTful commands (e.g.
GET, PUT, POST, etc.) may be applied to effect the information
exchange. By applying OBSERVE over the transaction resource's state
property it is possible for both communicating entities to
determine when it is appropriate to continue to the next step (even
if connection is lost/re-established) or to perform cleanup if the
transaction aborts or commits, for example.
[0023] Advantageously, the use of transaction resources enable IoT
applications to implement transactional interaction protocols such
as device provisioning, key exchange, multi-phase commit and the
like, using a declarative object model (such as OCF/IoTivity).
[0024] In various examples, the transaction resource allows an IoT
framework layer to optimize message delivery using any available
messaging methodology (e.g. pub/sub, req/resp, event/notify etc.)
using MQ Telemetry Transport (MQTT), Extensible Messaging and
Presence Protocol (XMPP), Extensible Markup Language (XML),
Constrained Application Protocol (COAP), Data Distribution Service
(DDS) and others may be used by the framework layer.
[0025] FIG. 1 is a high-level diagram illustrating some examples of
various types of computing platforms that may be incorporated in
IoT devices. The computing platforms include servers or personal
computers, such as PC 102, laptop 104, smartphone/tablet 106, and
the like. Other types of information devices, such as networking
appliance 108, which represents a switch, router, access point,
etc., are computing platforms that are also contemplated.
Industrial equipment 110, such as control systems, automated
tooling, motor/robotics controls, programmable logic controllers,
are also types of computing platforms on which aspects of the
embodiments may be implemented. Computing platforms may also be
implemented as consumer-electronic devices, such as smart glasses
112, smartwatch 114, digital camera 116, and media device 118, such
as a set-top box as depicted, audio playback system, etc. Appliance
120 may also contain a computing system such as, for instance, an
Internet-of-Things (IoT) node. Medical device 122 may contain an
embedded computing platform. Likewise vehicle 124 may also contain
one or more computing platforms. Each computing platform may
include a processor-based system, e.g., a machine capable of
executing instructions (sequential or otherwise) that specify
actions to be taken by that machine.
[0026] FIG. 2 is a block diagram illustrating a computer system 200
in the example form of a general-purpose machine. In certain
embodiments, programming of the computer system 200 according to
one or more particular algorithms produces a special-purpose
machine upon execution of that programming. In a networked
deployment, the computer system may operate in the capacity of
either a server or a client machine in server-client network
environments, or it may act as a peer machine in peer-to-peer (or
distributed) network environments. As will be discussed in some
examples below, a device may operate in a client mode or a server
mode in alternating fashion, depending on whether it is an
initiator, or responder, to a transaction or message.
[0027] Example computer system 200 includes at least one processor
202 (e.g., a central processing unit (CPU), a graphics processing
unit (GPU) or both, processor cores, compute nodes, etc.), a main
memory 204 and a static memory 206, which communicate with each
other via a link 208 (e.g., bus). The computer system 200 may
further include a video display unit 210, an alphanumeric input
device 212 (e.g., a keyboard), and a user interface (UI) navigation
device 214 (e.g., a mouse). The video display unit, according to
various embodiments, may include a complex, user-interactive
display, or a simple numerical or alpha-numerical display. In one
embodiment, the video display unit 210, input device 212 and UI
navigation device 214 are incorporated into a touch screen display.
The computer system 200 may additionally include a storage device
216 (e.g., a drive unit), a signal generation device 218 (e.g., a
speaker), a network interface device (NID) 220, and one or more
sensors (not shown), such as a global positioning system (GPS)
sensor, compass, accelerometer, or other sensor.
[0028] The storage device 216 includes a machine-readable medium
222 on which is stored one or more sets of data structures and
instructions 224 (e.g., software) embodying or utilized by any one
or more of the methodologies or functions described herein. The
instructions 224 may also reside, completely or at least partially,
within the main memory 204, static memory 206, and/or within the
processor 202 during execution thereof by the computer system 200,
with the main memory 204, static memory 206, and the processor 202
also constituting machine-readable media.
[0029] While the machine-readable medium 222 is illustrated in an
example embodiment to be a single medium, the term
"machine-readable medium" may include a single medium or multiple
media (e.g., a centralized or distributed database, and/or
associated caches and servers) that store the one or more
instructions 224. The term "machine-readable medium" shall also be
taken to include any tangible medium that is capable of storing,
encoding or carrying instructions for execution by the machine and
that cause the machine to perform any one or more of the
methodologies of the present disclosure or that is capable of
storing, encoding or carrying data structures utilized by or
associated with such instructions. The term "machine-readable
medium" shall accordingly be taken to include, but not be limited
to, solid-state memories, and optical and magnetic media. Specific
examples of machine-readable media include non-volatile memory,
including but not limited to, by way of example, semiconductor
memory devices (e.g., electrically programmable read-only memory
(EPROM), electrically erasable programmable read-only memory
(EEPROM)) and flash memory devices; magnetic disks such as internal
hard disks and removable disks; magneto-optical disks; and CD-ROM
and DVD-ROM disks.
[0030] NID 220 according to various embodiments may take any
suitable form factor. In one such embodiment, NID 220 is in the
form of a network interface card (NIC) that interfaces with
processor 202 via link 208. In one example, link 208 includes a PCI
Express (PCIe) bus, including a slot into which the NIC form-factor
may removably engage. In another embodiment, NID 220 is a network
interface circuit laid out on a motherboard together with local
link circuitry, processor interface circuitry, other input/output
circuitry, memory circuitry, storage device and peripheral
controller circuitry, and the like. In another embodiment, NID 220
is a peripheral that interfaces with link 208 via a peripheral
input/output port such as a universal serial bus (USB) port. NID
220 transmits and receives data over transmission medium 226, which
may be wired or wireless (e.g., radio frequency, infra-red or
visible light spectra, etc.), fiber optics, or the like.
[0031] FIG. 3A is a diagram illustrating an exemplary hardware and
software architecture of a computing device such as the one
depicted in FIG. 2, in which various interfaces between hardware
components and software components are shown. As indicated by HW,
hardware components are represented below the divider line, whereas
software components denoted by SW reside above the divider line. On
the hardware side, processing devices 302 (which may include one or
more microprocessors, digital signal processors, etc., each having
one or more processor cores, are interfaced with memory management
device 304 and system interconnect 306. Memory management device
304 provides mappings between virtual memory used by processes
being executed, and the physical memory. Memory management device
304 may be an integral part of a central processing unit which also
includes the processing devices 302.
[0032] Interconnect 306 includes a backplane such as memory, data,
and control lines, as well as the interface with input/output
devices, e.g., PCI, USB, etc. Memory 308 (e.g., dynamic random
access memory--DRAM) and non-volatile memory 309 such as flash
memory (e.g., electrically-erasable read-only memory--EEPROM, NAND
Flash, NOR Flash, etc.) are interfaced with memory management
device 304 and interconnect 306 via memory controller 310. This
architecture may support direct memory access (DMA) by peripherals
in some embodiments. I/O devices, including video and audio
adapters, non-volatile storage, external peripheral links such as
USB, Bluetooth, etc., as well as network interface devices such as
those communicating via Wi-Fi or LTE-family interfaces, are
collectively represented as I/O devices and networking 312, which
interface with interconnect 306 via corresponding I/O controllers
314.
[0033] On the software side, a pre-operating system (pre-OS)
environment 316, which is executed at initial system start-up and
is responsible for initiating the boot-up of the operating system.
One traditional example of pre-OS environment 316 is a system basic
input/output system (BIOS). In present-day systems, a unified
extensible firmware interface (UEFI) is implemented. Pre-OS
environment 316, is responsible for initiating the launching of the
operating system, but also provides an execution environment for
embedded applications according to certain aspects of the
invention.
[0034] Operating system (OS) 318 provides a kernel that controls
the hardware devices, manages memory access for programs in memory,
coordinates tasks and facilitates multi-tasking, organizes data to
be stored, assigns memory space and other resources, loads program
binary code into memory, initiates execution of the application
program which then interacts with the user and with hardware
devices, and detects and responds to various defined interrupts.
Also, operating system 318 provides device drivers, and a variety
of common services such as those that facilitate interfacing with
peripherals and networking, that provide abstraction for
application programs so that the applications do not need to be
responsible for handling the details of such common operations.
Operating system 318 additionally provides a graphical user
interface (GUI) that facilitates interaction with the user via
peripheral devices such as a monitor, keyboard, mouse, microphone,
video camera, touchscreen, and the like.
[0035] Runtime system 320 implements portions of an execution
model, including such operations as putting parameters onto the
stack before a function call, the behavior of disk input/output
(I/O), and parallel execution-related behaviors. Runtime system 320
may also perform support services such as type checking, debugging,
or code generation and optimization.
[0036] Libraries 322 include collections of program functions that
provide further abstraction for application programs. These include
shared libraries, dynamic linked libraries (DLLs), for example.
Libraries 322 may be integral to the operating system 318, runtime
system 320, or may be added-on features, or even remotely-hosted.
Libraries 322 define an application program interface (API) through
which a variety of function calls may be made by application
programs 324 to invoke the services provided by the operating
system 318. Application programs 324 are those programs that
perform useful tasks for users, beyond the tasks performed by
lower-level system programs that coordinate the basis operability
of the computing device itself.
[0037] FIG. 3B is a block diagram illustrating processing devices
302 according to some embodiments. In one embodiment, two or more
of processing devices 302 depicted are formed on a common
semiconductor substrate. CPU 340 may contain one or more processing
cores 342, each of which has one or more arithmetic logic units
(ALU), instruction fetch unit, instruction decode unit, control
unit, registers, data stack pointer, program counter, and other
essential components according to the particular architecture of
the processor. As an illustrative example, CPU 340 may be a
x86-type of processor. Processing devices 302 may also include a
graphics processing unit (GPU) 344. In these embodiments, GPU 344
may be a specialized co-processor that offloads certain
computationally-intensive operations, particularly those associated
with graphics rendering, from CPU 340. Notably, CPU 340 and GPU 344
generally work collaboratively, sharing access to memory resources,
I/O channels, etc.
[0038] Processing devices 302 may also include caretaker processor
346 in some embodiments. Caretaker processor 346 generally does not
participate in the processing work to carry out software code as
CPU 340 and GPU 344 do. In some embodiments, caretaker processor
346 does not share memory space with CPU 340 and GPU 344, and is
therefore not arranged to execute operating system or application
programs. Instead, caretaker processor 346 may execute dedicated
firmware that supports the technical workings of CPU 340, GPU 344,
and other components of the computer system. In some embodiments,
caretaker processor is implemented as a microcontroller device,
which may be physically present on the same integrated circuit die
as CPU 340, or may be present on a distinct integrated circuit die.
Caretaker processor 346 may also include a dedicated set of I/O
facilities to enable it to communicate with external entities. In
one type of embodiment, caretaker processor 346 is implemented
using a manageability engine (ME) or platform security processor
(PSP). Input/output (I/O) controller 348 coordinates information
flow between the various processing devices 340, 344, 346, as well
as with external circuitry, such as a system interconnect.
[0039] FIG. 3C is a block diagram illustrating example components
of CPU 340 according to various embodiments. As depicted, CPU 340
includes one or more cores 352, cache 354, and CPU controller 356,
which coordinates interoperation and tasking of the core(s) 352, as
well as providing an interface to facilitate data flow between the
various internal components of CPU 340, and with external
components such as a memory bus or system interconnect. In one
embodiment, all of the example components of CPU 340 are formed on
a common semiconductor substrate.
[0040] CPU 340 includes non-volatile memory 358 (e.g., flash,
EEPROM, etc.) for storing certain portions of foundational code,
such as an initialization engine, and microcode. Also, CPU 340 may
be interfaced with an external (e.g., formed on a separate IC)
non-volatile memory device 360 that stores foundational code that
is launched by the initialization engine, such as system BIOS or
UEFI code.
[0041] Examples, as described herein, may include, or may operate
on, logic or a number of components, circuits, modules, or engines,
which for the sake of consistency are termed engines, although it
will be understood that these terms may be used interchangeably.
Engines may be hardware, software, or firmware communicatively
coupled to one or more processors in order to carry out the
operations described herein. Engines may be hardware engines, and
as such engines may be considered tangible entities capable of
performing specified operations and may be configured or arranged
in a certain manner. In an example, circuits may be arranged (e.g.,
internally or with respect to external entities such as other
circuits) in a specified manner as an engine. In an example, the
whole or part of one or more hardware processors may be configured
by firmware or software (e.g., instructions, an application
portion, or an application) as an engine that operates to perform
specified operations. In an example, the software may reside on a
machine-readable medium. In an example, the software, when executed
by the underlying hardware of the engine, causes the hardware to
perform the specified operations. Accordingly, the term hardware
engine is understood to encompass a tangible entity, be that an
entity that is physically constructed, specifically configured
(e.g., hardwired), or temporarily (e.g., transitorily) configured
(e.g., programmed) to operate in a specified manner or to perform
part or all of any operation described herein.
[0042] Considering examples in which engines are temporarily
configured, each of the engines need not be instantiated at any one
moment in time. For example, where the engines comprise a
general-purpose hardware processor core configured using software;
the general-purpose hardware processor core may be configured as
respective different engines at different times. Software may
accordingly configure a hardware processor core, for example, to
constitute a particular engine at one instance of time and to
constitute a different engine at a different instance of time.
[0043] According to various examples, an IoT devices are compliant
with standards promulgated by the Open Connectivity Foundation,
such as the Open Interconnect Consortium (OIC) Core Specification
V1.1.1 (2016), for example. The Core Specification documents
specify the Framework, i.e., the OCF core architecture, interfaces,
protocols and services to enable OCF profiles implementation for
IoT usages and ecosystems. As a general principle, entities in the
physical world (e.g., temperature sensor, an electric light or a
home appliance) are represented as resources. Interactions with an
entity are achieved through its resource representations using
operations that adhere to Representational State Transfer (REST)
architectural style, e.g., RESTful interactions.
[0044] The architecture defines the overall structure of the
Framework as an information system and the interrelationships of
the entities that make up OCF. Entities are exposed as resources,
with their unique identifiers (URIs) and support interfaces that
enable RESTful operations on the resources. Every RESTful operation
has an initiator of the operation (also referred to as the client
role) and a responder to the operation (also referred to as the
server role).
[0045] In the framework, the notion of the client and server is
realized through roles. Any device may act as a client and initiate
a RESTful operation on any device acting as a server. Likewise, any
device that exposes entities as resources acts as a server.
Conformant to the REST architectural style, each RESTful operation
contains all the information to represent the context of the
interaction and is driven using a small set of generic operations,
e.g., Create, Read, Update, Delete, Notify (CRUDN), which include
representations of resources.
[0046] The architecture is organized conceptually into three major
aspects that provide overall separation of concern: resource model,
RESTful operations and abstractions. The resource model provides
the abstractions and concepts to logically model, and logically
operate on the application and its environment. The core resource
model is common and agnostic to any specific application domain
such as smart home, industrial or automotive. For example, the
resource model defines a resource which abstracts an entity and the
representation of a resource maps the entity's state. Other
resource model concepts may be used to model other aspects, for
example behavior. The generic CRUDN operations are defined using
the RESTful paradigm to model the interactions with a resource in a
protocol and technology agnostic way.
[0047] The abstractions in the resource model and the RESTful
operations are mapped to concrete elements using abstraction
primitives. An entity handler is used to map an entity to a
resource and connectivity abstraction primitives are used to map
logical RESTful operations to data connectivity protocols or
technologies. Entity handlers may also be used to map resources to
entities that are reached over protocols that are not natively
supported by OCF.
[0048] FIG. 4A is a diagram illustrating an example IoT device
architecture according to some embodiments, at a high level of
abstraction. As illustrated, IoT device 400 includes communication
facilities 402, core resources 404, entity resource 406, and
transaction resources 408. Communication facilities 402 include
hardware, and instructions executable on the hardware, that
facilitate message exchange between device 400 and a peer device.
Communication facilities 402 may include wireless or wired
networking architecture (e.g., WiFi, Long-term Evolution (LTE),
personal-area networking (PAN) such as Bluetooth, home-area
networking such as Zigbee, and the like, as well as wired
networking architecture such as Ethernet, Fieldbus, or the like,
along with corresponding firmware and software drivers to
facilitate the hardware's operation).
[0049] Core resources 404 include a set of defined resources to
enable functional interactions such as resource discovery, device
management, GET operation, PUT operation, OBSERVE operation, and
the like. Core resources 404 may include a resource access manager
that implements various security policies such as firewall
functionality.
[0050] Entity resources 406 represents one or more data sources or
data sinks (e.g., data originators or data consumers) such as a
data storage device, data capture device, computing platform,
sensor, actuator, or the like. In general, entity resources 406
include the operability that is sought when device 400 is accessed.
Entity resources 406 may also include an application that seeks to
obtain information from, or send information or commands to, an
entity resource of a peer device.
[0051] According to some embodiments, transaction resources 408
include resources to handle transactions in which sequences of
multiple related messages may be communicated to achieve a common
objective or result, with one or more intermediate state changes
taking place between the initiation and conclusion of a given
transaction. FIG. 4B illustrates an example set of components that
are included in transaction resources 408 according to some
embodiments. Transaction resources 408 include a transaction state
machine 412 to represent the current intra-transactional ephemeral
state, a commit handler 414 to institute a persistent state change
at the successful conclusion of a transaction, and a cleanup
handler 416 to abort a transaction and clear out any pre-committed
intermediate state changes in response to a transaction failure.
Also, transaction communicator 418 is included to conduct
intra-transaction communications with the transaction resources of
a peer device.
[0052] In a related embodiment, transaction resources 408 include
one or more discoverable state graph data structures 420,
discoverable by peer devices, each of which represents the process
flow of a corresponding transaction type, including messages and
allowed intra-transaction states, which are supported by IoT device
400. In another related embodiment, transaction resources 408
include a collection 422 of transaction message resources that are
supported.
[0053] As an example, transaction resources 408 may include the
following properties and attributes: [0054] Resource Attributes
[0055] Resource Type: "rt"="ocf.tx.<tx_name> [0056]
Discoverable: YES--allows a peer device to initiate transaction
[0057] Interfaces: "baseline"13 CR-N (observe) [0058] Resource
Properties [0059] "txs"--current state of the transaction [0060]
"txg"--graph defining reachable states and transitions [0061]
"txi"--Tx instance identifier [0062] "txh"--hash of Tx messages
exchanged [0063] "txc"--Collection resource with references to
transaction message resources.
[0064] In an example, intra-transaction state changes are achieved
through the exchange of RESTful messages between one or more peer
devices. Message encoding may vary for the various states defined
in a given transaction. Hence, it is possible for an IoT core layer
to optimize message delivery (e.g., mixing multiple messaging
models such as request/response, pub/sub, event/notify etc.)
without impacting the transaction resources or the logic contained
in the transaction communicator.
[0065] FIG. 5 is a diagram illustrating an example state graph data
structures 420 according to an embodiment. As depicted, start
states may include initiation INIT and response RESP states.
Protocol states to carry out a transaction may include messages
MSG-A-MSG-X as shown. Error states include RESTART and ABORT
states, and a success state includes DONE.
[0066] To ensure progress is achieved the protocol state
dependencies are non-circular in this example. The responder may
observe the state property of the Initiator's Tx resource
specifying the state value(s) that trigger notification responses.
For instance, observing the MSG-B state subsequent to posting a
MSG-A message would allow the Responder to take an extended period
of time processing MSG-A. The initiator may return to doing other
tasks, or going to sleep, knowing that when the responder is ready
to post MSG-B it will receive a notification to wake up or listen
for activity from the Responder.
[0067] Notifications may also be used to signal when it is
appropriate to free computing resources allocated to perform the
transaction. For example, DONE or ABORT notification might cause
the device to free memory used to contain message buffers and
temporary files. Whatever the reason for observation of a state
property, the transaction communicator may ensure a valid sequence
of messages is processed.
[0068] FIG. 6 is a diagram illustrating transaction message
collection 422 according to an example. As depicted, the
transaction resource TX RSRC contains a collection property
comprising a list of message resources MSG-A_RSRC=MSG-C_RSRC that
describe the objects to be exchanged during the course of the
transaction.
[0069] FIG. 7 is a block diagram illustrating the transaction
resources of an IoT device according to an embodiment utilizing an
IoT framework such as OCF/IoTivity. In this example, device 700 is
shown with transaction resources provisions for initiator role 702,
and for responder role 704. As described above, the initiator and
responder roles may be performed by the same device, often times in
alternating fashion, during transaction communications and message
processing. To carry out initiator role 702, transaction
communicator 706 is provided. Transaction communicator 706 performs
posting of messages directed to the transaction communicator of a
peer device (which would be configured as a responder role to
receive the posted messages). Transaction communicator 706 is
informed by state graph 710, which represents the proper sequence
of states throughout the course of the transaction, and transaction
state machine 712, which represents the current state. The state
graph 710 indicates the action (e.g., message type) to be sent by
transaction communicator 706; whereas transaction state machine 712
indicates when, or whether, the action is to be taken.
[0070] Also instantiated in the responder role 704 are transaction
message collection 708, which contains the set of messages
associated with the transactions supported by device 700, cleanup
handler 716, and commit handler 718. The transaction resources of
responder role 704 receive and respond to various messages. In the
example depicted, DISCOVER, OBSERVE, PUT, and POST messages may be
received and processed. As shown, device 700 may be externally
programmed to operate in its initiator role to start a
transaction.
[0071] The transaction resources access entity 720 may include
sensor 722, actuator 724, and data store 726. As illustrated, the
transaction resources access the resources of entity 720 via commit
handler 718, which exercises the responsibility of calling for a
persistent state change of device 700.
[0072] FIG. 8 is a flow diagram illustrating the progress of an
example transaction between two IoT devices, each utilizing its
respective transaction resources. As depicted, the initiator device
has transaction resources 802, and the responder device has
transaction resources 804 which correspond to transaction resources
802. In this example, the fact that the initiator and responder
devices have matching transaction resources is a precondition for
their ability to carry out the transaction. In a related
embodiment, the initiator device may have previously used a
supported discovery or inquiry protocol to check whether the
responder device possesses the resources needed for the
transaction.
[0073] The transaction starts with the initiator device posting the
message A resource MSG-A RSRC at 806. The responder responds with a
response code RESP CODE, and processes message A at 808. At 810,
the responder posts message B, to which the initiator responds with
a response code RESP CODE. At 812, the initiator devices processes
message B. Thereafter, in accordance with the transaction's
predefined protocol, the initiator posts message C at 814, to which
the responder device responds with the response code, and processes
received message C at 816.
[0074] Messages A-C in this example are RESTful message exchanges
controlled by a state property that ensures the transaction
progresses in a predefined way. The response codes sent by each
recipient of a message in turn are indicative of the forward
progress of the transaction protocol. In the absence of receipt of
a response code, the transmitting device may retry after a period
of time, or abort the transaction after some number of retry
failures, for example.
[0075] Once processing of message C is complete, the responder
device may perform an OBSERVE operation at 818 to check for the
completion state, DONE. The initiator device in this case provides
a DONE state notification observable by the responder device. In
response to the successful completion of the transaction, each
device may update its persistent state to reflect completion of the
transaction. Accordingly, at 822, the responder device commits the
transaction by updating its persistent state. Likewise, at 824, the
initiator device commits the transaction by updating its persistent
state accordingly. In the event of a failure of the transaction, no
persistent state change is made in either device.
[0076] FIG. 9 is a system architecture and data flow diagram
illustrating example interactivity between a pair of IoT devices
utilizing principles of some embodiments. Device A 900 and Device B
920 are respectively configured with entity resources ER1 902 and
ER2 922, and transaction resources TR1 and TR2, including
respective transaction state machines 904 and 924, transaction
state graphs 906 and 926, and transaction communicators 908 and
928. Core resources of the devices include resource access manager
910 for device A 900, and resource access manager 930 for device B
920. Each device also includes communications facilities, as
indicated respectively at 912 and 932. In the example illustrated,
device B 920 also includes application 918, which in the following
operational use case initiates a transaction to access entity
resource ER1 902.
[0077] As indicated, resource access manager 910 includes an access
control entry that denies direct access to entity resource ER1 902
from device B 920, but allows device B 920 to access transaction
resources TR1. Accordingly, in operation, interaction A directed
from application 918 to entity resource ER1 902 is blocked by
resource access manager 910.
[0078] However, interaction B, originating at application 918 and
directed to transaction resources TR1 of device A 900, is permitted
by resource access manager 910. Interaction B may be a DISCOVER
request, for instance, that explores whether device A 900 or, more
particularly, whether transaction resources TR1 contain a matching
transaction configuration (e.g., message collection, state graph)
to the transaction intended by device B. In response to device A
having a suitable set of transaction resources, transaction
resources TR1 and TR2, via transaction communicators 908 and 928
respectively, exchange messages according to TX state graphs 906
and 926. Transaction state machines 904 and 924 advance through
their configured finite-state automata in interactions C and D,
which may include different messages in the appropriate sequence.
Transaction state machines 904 and 924 maintain ephemeral states
within the confines of the current transaction. At the successful
conclusion of the transaction, the entity resource ER1 902 is
updated at E to institute a persistent state change to commit the
transaction. If the transaction were to fail, no persistent state
change at E would be instituted.
[0079] According to another embodiment, multiple IoT devices with
transaction resources are configured to implement a workflow
process that has distributed sequencing control. A workflow process
orchestration engine configured as part of the transaction
resources describes a workflow process model, and then partitions
the model according to the respective node devices such that the
workflow operations between any two workflow neighbors forms a
transaction. A workflow node maintains two instances of a
transaction resource such that the results of an A-to-B transaction
may feed a B-to-C transaction, for example.
[0080] According to a related embodiment, the transaction resource
includes a template that defines a second resource as a derived
type of the transaction resource such that a resource type of the
second resource is contained in the resource type value of the
transaction resource. For example if the transaction resource has a
type designation of "rt"="ocf.r.tx" then a second derived resource
(dr) type may be designated by "rt"="ocf.r.tx.dr".
[0081] In an example, the semantics of template derivation are such
that all the properties defined by the template are available to
the derived resource as if they were originally defined by the
derived resource. This approach may differ from a first resource
referencing a second resource in that the realization of a template
resource has a single resource instance, whereas a first resource
referencing a second resource will have two resource instances.
[0082] Resource template semantics may further be defined to have
property overloading such that if a derived resource defines a
property named the same as a property named by the template
resource. The data structure defined by the template may be hidden
from the initiator device seeking to introspect the derived
resource. Nevertheless, the derived resource may reference the
template defined property using a localized reference. (E.g. if the
template resource defines a property "tx1" and the derived resource
also defines a property "tx1" a local reference may be constructed
using name mangling such that the resource name is pre-pended to
the property name; e.g., "tx_tx1". The mangled property has CRUDN
permissions of "-----" such that only local references may be
constructed, for instance.
[0083] Advantageously, in overloading of the property name the
temporality of the property may be variable. This may allow the
hidden property value to remain unchanged (e.g., its state may
persist while a new state is being negotiated by the transaction
protocol). When the protocol commits, or rolls-back the new state
may be established quickly. This facilitates safer operation.
[0084] Property overloading also offers certain security and
privacy benefits where a sensitive property value may be hidden
during an exchange that may result in a decision not to disclose
the hidden property value. Hence, the sensitive value is not at
risk of disclosure during the negotiation phase. A security policy
may require substitution with a less sensitive value until the FSA
commits.
ADDITIONAL NOTES & EXAMPLES
[0085] Example 1 is a communications device, comprising: a
computing platform, including a processor, a data store, and
communication facilities; an entity resource to originate or
consume data; core resources to facilitate stateless messaging with
a remote device associated with the entity resource; and
transaction resources to manage a transaction with the remote
device that includes a sequence of messages associated with the
entity resource, including: a transaction state machine to
represent a current intra-transactional ephemeral state from among
a plurality of intra-transactional ephemeral states representing
progression of the transaction; a commit handler to institute a
persistent state change related to the entity resource in response
to a successful completion of the transaction; and a transaction
communicator to conduct intra-transaction communications via the
core resources directed to corresponding transactional resources of
the remote device.
[0086] In Example 2, the subject matter of Example 1 optionally
includes wherein the device is an Internet-of-Things (IoT)
device.
[0087] In Example 3, the subject matter of any one or more of
Examples 1-2 optionally include
[0088] In Example 4, the subject matter of any one or more of
Examples 1-3 optionally include wherein the stateless messaging
includes RESTful messaging.
[0089] In Example 5, the subject matter of any one or more of
Examples 1-4 optionally include a cleanup handler to abort the
transaction and remove any remaining ephemeral state indicia in
response to a failure of the transaction.
[0090] In Example 6, the subject matter of any one or more of
Examples 1-5 optionally include wherein the core resources include
a set of defined resources to enable functional interactions
selected from the group consisting of: resource discovery, device
management, GET operation, PUT operation, OBSERVE operation, or any
combination thereof.
[0091] In Example 7, the subject matter of any one or more of
Examples 1-6 optionally include wherein the core resources include
a resource access manager to implement security a policy that
limits direct access to the entity resource but permits access to
the entity resource via the transaction resources.
[0092] In Example 8, the subject matter of any one or more of
Examples 1-7 optionally include wherein the transaction resources
include a state graph data structure that represents a process flow
of the transaction as a sequence of the ephemeral states.
[0093] In Example 9, the subject matter of Example 8 optionally
includes wherein the state graph data structure is discoverable by
the remote device.
[0094] In Example 10, the subject matter of any one or more of
Examples 1-9 optionally include wherein the transaction resources
include a collection resource that represents transaction message
resources associated with the transaction.
[0095] In Example 11, the subject matter of Example 10 optionally
includes wherein the collection resource is discoverable by the
remote device.
[0096] In Example 12, the subject matter of any one or more of
Examples 1-11 optionally include wherein the entity resource
includes an application resource to initiate the transaction and to
undergo a persistent state change in response to successful
completion of the transaction.
[0097] In Example 13, the subject matter of any one or more of
Examples 1-12 optionally include wherein the entity resource
includes at least one data source selected from the group
consisting of: a sensor, an actuator, a data store.
[0098] Example 14 is a method for operating a communications
device, the method comprising: interfacing with an entity resource
that originates or consumes data; communicating stateless messaging
with a remote device, the stateless messaging being associated with
the entity resource; and managing a transaction with the remote
device, the transaction including a sequence of messages associated
with the entity resource, wherein the managing of the transaction
includes: representing a current intra-transactional ephemeral
state from among a plurality of intra-transactional ephemeral
states representing progression of the transaction; instituting a
persistent state change related to the entity resource in response
to a successful completion of the transaction; and conducting
intra-transaction communications via the core resources directed to
corresponding transactional resources of the remote device.
[0099] In Example 15, the subject matter of Example 14 optionally
includes wherein the communications device is an Internet-of-Things
(IoT) device.
[0100] In Example 16, the subject matter of any one or more of
Examples 14-15 optionally include
[0101] In Example 17, the subject matter of any one or more of
Examples 14-16 optionally include wherein the stateless messaging
includes RESTful messaging.
[0102] In Example 18, the subject matter of any one or more of
Examples 14-17 optionally include aborting the transaction and
removing any remaining ephemeral state indicia in response to a
failure of the transaction.
[0103] In Example 19, the subject matter of any one or more of
Examples 14-18 optionally include wherein the stateless messaging
facilitates functional interactions selected from the group
consisting of: resource discovery, device management, GET
operation, PUT operation, OBSERVE operation, or any combination
thereof
[0104] In Example 20, the subject matter of any one or more of
Examples 14-19 optionally include implementing a security a policy
that limits direct access to the entity resource but permits access
to the entity resource via the transaction resources.
[0105] In Example 21, the subject matter of any one or more of
Examples 14-20 optionally include wherein managing the transaction
includes storing a state graph data structure that represents a
process flow of the transaction as a sequence of the ephemeral
states.
[0106] In Example 22, the subject matter of Example 21 optionally
includes wherein the state graph data structure is discoverable by
the remote device.
[0107] In Example 23, the subject matter of any one or more of
Examples 14-22 optionally include wherein managing the transaction
includes storing a collection resource that represents transaction
message resources associated with the transaction.
[0108] In Example 24, the subject matter of Example 23 optionally
includes wherein the collection resource is discoverable by the
remote device.
[0109] In Example 25, the subject matter of any one or more of
Examples 14-24 optionally include wherein the entity resource
includes an application resource to initiate the transaction and to
undergo a persistent state change in response to successful
completion of the transaction.
[0110] In Example 26, the subject matter of any one or more of
Examples 14-25 optionally include wherein the entity resource
includes at least one data source selected from the group
consisting of: a sensor, an actuator, a data store.
[0111] Example 27 is at least one machine-readable medium
containing instructions that, when executed on a communications
device, cause the communications device to carry out the method
according to any one of Examples 14-27.
[0112] Example 28 is a communications system device comprising
means for carrying out the method according to any one of Examples
14-27.
[0113] Example 29 is at least one machine-readable medium
comprising instructions that, when executed on a computing platform
of a communications device, cause the communications device to
perform operations including: interfacing with an entity resource
that originates or consumes data; communicating stateless messaging
with a remote device, the stateless messaging being associated with
the entity resource; and managing a transaction with the remote
device, the transaction including a sequence of messages associated
with the entity resource, wherein the managing of the transaction
includes: representing a current intra-transactional ephemeral
state from among a plurality of intra-transactional ephemeral
states representing progression of the transaction; instituting a
persistent state change related to the entity resource in response
to a successful completion of the transaction; and conducting
intra-transaction communications via the core resources directed to
corresponding transactional resources of the remote device.
[0114] In Example 30, the subject matter of Example 29 optionally
includes wherein the communications device is an Internet-of-Things
(IoT) device.
[0115] In Example 31, the subject matter of any one or more of
Examples 29-30 optionally include
[0116] In Example 32, the subject matter of any one or more of
Examples 29-31 optionally include wherein the stateless messaging
includes RESTful messaging.
[0117] In Example 33, the subject matter of any one or more of
Examples 29-32 optionally include instructions for causing the
communications device to abort the transaction and remove any
remaining ephemeral state indicia in response to a failure of the
transaction.
[0118] In Example 34, the subject matter of any one or more of
Examples 29-33 optionally include wherein the stateless messaging
facilitates functional interactions selected from the group
consisting of: resource discovery, device management, GET
operation, PUT operation, OBSERVE operation, or any combination
thereof.
[0119] In Example 35, the subject matter of any one or more of
Examples 29-34 optionally include instructions for implementing a
security a policy that limits direct access to the entity resource
but permits access to the entity resource via the transaction
resources.
[0120] In Example 36, the subject matter of any one or more of
Examples 29-35 optionally include wherein managing the transaction
includes storing a state graph data structure that represents a
process flow of the transaction as a sequence of the ephemeral
states.
[0121] In Example 37, the subject matter of Example 36 optionally
includes wherein the state graph data structure is discoverable by
the remote device.
[0122] In Example 38, the subject matter of any one or more of
Examples 29-37 optionally include wherein managing the transaction
includes storing a collection resource that represents transaction
message resources associated with the transaction.
[0123] In Example 39, the subject matter of Example 38 optionally
includes wherein the collection resource is discoverable by the
remote device.
[0124] In Example 40, the subject matter of any one or more of
Examples 29-39 optionally include wherein the entity resource
includes an application resource to initiate the transaction and to
undergo a persistent state change in response to successful
completion of the transaction.
[0125] In Example 41, the subject matter of any one or more of
Examples 29-40 optionally include wherein the entity resource
includes at least one data source selected from the group
consisting of: a sensor, an actuator, a data store.
[0126] Example 42 is a system for a communications device, the
system comprising: means for interfacing with an entity resource
that originates or consumes data; means for communicating stateless
messaging with a remote device, the stateless messaging being
associated with the entity resource; and means for managing a
transaction with the remote device, the transaction including a
sequence of messages associated with the entity resource, wherein
the means for managing of the transaction include: means for
representing a current intra-transactional ephemeral state from
among a plurality of intra-transactional ephemeral states
representing progression of the transaction; means for instituting
a persistent state change related to the entity resource in
response to a successful completion of the transaction; and means
for conducting intra-transaction communications via the core
resources directed to corresponding transactional resources of the
remote device.
[0127] In Example 43, the subject matter of Example 42 optionally
includes wherein the communications device is an Internet-of-Things
(IoT) device.
[0128] In Example 44, the subject matter of any one or more of
Examples 42-43 optionally include
[0129] In Example 45, the subject matter of any one or more of
Examples 42-44 optionally include wherein the stateless messaging
includes RESTful messaging.
[0130] In Example 46, the subject matter of any one or more of
Examples 42-45 optionally include means for aborting the
transaction and removing any remaining ephemeral state indicia in
response to a failure of the transaction.
[0131] In Example 47, the subject matter of any one or more of
Examples 42-46 optionally include wherein the stateless messaging
facilitates functional interactions selected from the group
consisting of: resource discovery, device management, GET
operation, PUT operation, OBSERVE operation, or any combination
thereof.
[0132] In Example 48, the subject matter of any one or more of
Examples 42-47 optionally include means for implementing a security
a policy that limits direct access to the entity resource but
permits access to the entity resource via the transaction
resources.
[0133] In Example 49, the subject matter of any one or more of
Examples 42-48 optionally include wherein the means for managing
the transaction include means for storing a state graph data
structure that represents a process flow of the transaction as a
sequence of the ephemeral states.
[0134] In Example 50, the subject matter of Example 49 optionally
includes wherein the state graph data structure is discoverable by
the remote device.
[0135] In Example 51, the subject matter of any one or more of
Examples 42-50 optionally include wherein the means for managing
the transaction include means for storing a collection resource
that represents transaction message resources associated with the
transaction.
[0136] In Example 52, the subject matter of Example 51 optionally
includes wherein the collection resource is discoverable by the
remote device.
[0137] In Example 53, the subject matter of any one or more of
Examples 42-52 optionally include wherein the entity resource
includes an application resource to initiate the transaction and to
undergo a persistent state change in response to successful
completion of the transaction.
[0138] In Example 54, the subject matter of any one or more of
Examples 42-53 optionally include wherein the entity resource
includes at least one data source selected from the group
consisting of: a sensor, an actuator, a data store.
[0139] The above detailed description includes references to the
accompanying drawings, which form a part of the detailed
description. The drawings show, by way of illustration, specific
embodiments that may be practiced. These embodiments are also
referred to herein as "examples." Such examples may include
elements in addition to those shown or described. However, also
contemplated are examples that include the elements shown or
described. Moreover, also contemplated are examples using any
combination or permutation of those elements shown or described (or
one or more aspects thereof), either with respect to a particular
example (or one or more aspects thereof), or with respect to other
examples (or one or more aspects thereof) shown or described
herein.
[0140] Publications, patents, and patent documents referred to in
this document are incorporated by reference herein in their
entirety, as though individually incorporated by reference. In the
event of inconsistent usages between this document and those
documents so incorporated by reference, the usage in the
incorporated reference(s) are supplementary to that of this
document; for irreconcilable inconsistencies, the usage in this
document controls.
[0141] In this document, the terms "a" or "an" are used, as is
common in patent documents, to include one or more than one,
independent of any other instances or usages of "at least one" or
"one or more." In this document, the term "or" is used to refer to
a nonexclusive or, such that "A or B" includes "A but not B," "B
but not A," and "A and B," unless otherwise indicated. In the
appended claims, the terms "including" and "in which" are used as
the plain-English equivalents of the respective terms "comprising"
and "wherein." Also, in the following claims, the terms "including"
and "comprising" are open-ended, that is, a system, device,
article, or process that includes elements in addition to those
listed after such a term in a claim are still deemed to fall within
the scope of that claim. Moreover, in the following claims, the
terms "first," "second," and "third," etc. are used merely as
labels, and are not intended to suggest a numerical order for their
objects.
[0142] The above description is intended to be illustrative, and
not restrictive. For example, the above-described examples (or one
or more aspects thereof) may be used in combination with others.
Other embodiments may be used, such as by one of ordinary skill in
the art upon reviewing the above description. The Abstract is to
allow the reader to quickly ascertain the nature of the technical
disclosure. It is submitted with the understanding that it will not
be used to interpret or limit the scope or meaning of the claims.
Also, in the above Detailed Description, various features may be
grouped together to streamline the disclosure. However, the claims
may not set forth every feature disclosed herein as embodiments may
feature a subset of said features. Further, embodiments may include
fewer features than those disclosed in a particular example. Thus,
the following claims are hereby incorporated into the Detailed
Description, with a claim standing on its own as a separate
embodiment. The scope of the embodiments disclosed herein is to be
determined with reference to the appended claims, along with the
full scope of equivalents to which such claims are entitled.
* * * * *