Using protocol adapters with node-red

One of the great tools available to developers who use the Data Service Exchange is the protocol adapter framework. The protocol adapters make it possible to take existing applications which speak a given protocol, and use them to generate new data products. The Data Bus allows for exchanging these data products across multiple protocols in real time, making it easy to share data across services and customers.

Currently, the Data Service Exchange protocol adapters have production support for HTTP, WebSockets, MQTT, CoAP, AMQP, TCP, and UDP. Labs also experimental support for JMS, ZeroMQ, STOMP, XMPP, DDSI-RTPS, and JDBC currently in development. In addition to the open standard protocols, the DSE also has application specific adapters for various databases, search engines, logging systems, and the like.

A sample applications

To see how these protocol adapters work in conjunction with applications, we'll create a simple node-red flow that will publish a stream of 5 messages per second across MQTT to the Data Bus. This feed with then be replicated and split into two separate output streams to clients using CoAP and WebSockets at the same time.

The node-red flow for our example application consists of five nodes:

  • an inject node to start the flow of messages
  • a function node which generate the message payload
  • a delay node in a feedback configuration to generate 5 messages per second
  • a debug node to display the output in the node-red console
  • a MQTT node to send the messages to the Data Bus

The data can be read off the Data Bus using off the shelf applications such as coap-cli and wscat. While I happened to use command line tools for this application, it is easy enough to use standard libraries like the CoAP libraries provided by ARM in mbed OS, or even your favorite web browser.

To see this application in action, please watch the following video:

In the above video, I show the creation of three Data Bus resources:

  • wot:/wot/narf
  • wot:/wot/coap
  • wot:/wot/ws

The names of these resources allow you to identify them across protocols. There is nothing intrinsically magical about any of these names, and any protocol can read or write to any of the resources. It is the URLs of each of the application connections:

  • mqtt://token@host:port/account/resource
  • coap://token@host:port/account/resource
  • ws://token@host:port/account/resource

that determines how the data is translated between encapsulation layers. The creation of resource bindings as demonstrated in the video, also provides a means to duplicate and route data between resources. The data bus routing supports filtering payloads based on regular expression matches, as well as hierarchical pattern matches. These advanced features are accessible through the protocol adapters, as well as, through the command line tools.

Since each Data Bus resource is addressable through all of the protocol adapters and the application adapters, it is possible to mix and match data making it both available to consumers of a data product, as well as, making it available for internal storage, processing, and analysis through applications made available as part of the Data Service Exchange. Each Data Bus resource has individualized access controls, with each type of resource operation (reading, writing, creating, deleting, binding, etc.) being controllable through policy. These access controls allows developers using the Data Service Exchange to make available some or all of their data to interested parties. With the protocol adapter framework in place, the Data Bus makes it easy to provide your customers with their data through what ever protocol they choose for their application.