Implementation Guide

The following sections outlines steps that should be considered when planning a full or partial implementation of the interfaces published here.

Clients

Many of the interfaces are client-side interfaces. They don’t require special implementation on the XMPP broker side. Any XMPP broker can be used as no special edge service is required from the broker. Before implementing the client-side interfaces you need to decide how to connect to the XMPP network.

XMPP Connections: Bindings

Directly connected entities need to connect and bind to the XMPP network. There are multiple ways, with their own pros and cons. XMPP supports an extensible architecture for bindings, which allows for different protocols to be used for the same purpose. It also permits the implementor to do custom binding mechanisms.

1. TCP/IP Socket Connection is the most common binding, and is the one used by most XMPP clients. It is simple to implement and widely supported. This binding is the default binding for XMPP as described in 6120, 6121 and 6122 and updates.

2. WebSocket Connection is also common, and permits connection to the XMPP network from web browsers and other applications that support WebSockets. XMPP over Websockets is available in most brokers and is standardized by the IETF in RFC 7395.

3. BOSH (Bidirectional streams over HTTP) is also available. It permits binding to the bidirection XMPP network by using a pair of HTTP connections. It is more costly to maintain, for the broker, but permits connections from web browsers and other applications that support HTTP, in cases firewalls and environment settings restrict communication to HTTP requests. BOSH is available in most standard XMPP brokers via XEP-0124.

4. QUIC is a newer protocol that can be used for binding to the XMPP network. It is designed to be more efficient than TCP/IP and can reduce latency. It is available in some brokers via an experimental extension XEP-0467.

Other brokers may contain other custom binding methods, such as via UDP/DTLS. Check broker documentation for details.

Via REST API: Ex. Neuron Agent API

Some brokers may provide a REST API for connecting to the XMPP network. This is not a standard XMPP binding, but it can be useful for web applications, as it is easier to implement for simple interactions. Bidirectional communication is trickier to implement using a REST interface however. As an example, check the Agent API available on the TAG Neuron®, used to host this site.

Client-side Interfaces

The following interfaces are client-only interfaces. They do not need a special XMPP broker to implement. It is sufficient to select an XMPP library and extend it (if not already extended) to support these interfaces. Any standard XMPP broker can be used.

• Sensor Data contains the conceptual model of how sensor data is represented. Sensor data is generic and can be used to represent and data generated by a thing, including meta-data.

• Sensor Operations include Sensor Data Request/Response communication pattern, Sensor Data Event Subscription communication pattern and Sensor Data Publish/Subscribe communication pattern, which are means to access, request or publish sensor data.

• Control Parameters contains the conceptual model of how control parameters are represented. Control parameters can be read to set by authorized entities and can be used to control thing output and operation.

• Control Operations include Simple Control Actions, which modify control parameters one at a time, and Data Form Control Actions, which control sets of control parameters at once in a way that can be used in human interfaces.

• Concentrators (“Things of Things”) are devices that embed other devices, either physically or logically. They extend addressing of things from the basic XMPP address (JID) to a quadruple (JID, Node ID, Source ID, Partition ID), where Source ID and Partition ID are optional, allowing for extending the concentrator to large and huge systems, including embedding and nesting systems and sub-systems to any depth.

• Peer-to-Peer communication allows directly connected things to communicate with each other, without going through a broker. This is sometimes also called server-less communication. Peer-to-peer communication is typically negotiated using brokers, and then the connected entities can connect directly and use the direct connection to exchange information. This increases performance, reduces latency and improves privacy and confidentiality.

• End-to-End encryption can be used with peer-to-peer communication, or with broker-based communication, to ensure that only the endpoints can read the information exchanged. This is useful for protecting very sensitive information.

Mixed interfaces

Mixed interfaces are such that require a client-side and a broker-side implementation. Broker-side implementations are typically edge services hosted by XMPP components. Each component identifies the services it supports using a set of features, which are namespaces supported. During discovery, each entity analyzes available components, and their features, to detect which component supports which service. Components can be integrated into the broker itself, or run as a separate process connecting to the broker via the Component protocol.

• Thing Registry & Discovery
• Provisioning & Decision Support
• Digital Identities
• Smart Contract Signatures
• Clock synchronization
• Publish/Subscribe
• Remote software updates
• Geo-spatial publish/subscribe

Existing libraries

The Implementations page contains existing libraries that support the interfaces defined here. These libraries can be used directly, or be ported to other libraries and languages.

Extending basic XMPP libraries

The are many XMPP libraries available in a variety of programming languages. Some of them (but far from all) are listed on the XSF web site.

Gateways/Bridges

A gateway & bridge, is a special type of XMPP client, with an additional set of interfaces:

• Concentrator

Brokers

Broker-side edge services for:

• Thing Registry & Discovery
• Provisioning & Decision Support
• Digital Identities
• Smart Contract Signatures
• Clock synchronization
• Remote software updates
• Geo-spatial publish/subscribe

Standard in XMPP brokers:

• Publish/Subscribe

(All other interfaces are purely client-side libraries)

Existing brokers with full support

Neuron

Extending basic XMPP brokers

cf. xmpp.org

Simulating Networks

ComSim

Functional and Stress Testing

Load Generation

Performance measurement

Example projects

Example projects can be found in the Implementations page. These projects are intended to demonstrate how to implement various types of applications using the harmonization interfaces.