CoAP Messaging In Depth

Eric J. Bruno - April 2016

CoAP is a protocol not unlike HTTP or REST communication where the messages generally fall into the category of GET, POST, PUT, and DELETE. CoAP is also more conversational by nature since it’s request/response driven, as opposed to the publish/subscribe nature of MQTT (for details, see our article on MQTT).

At a lower level, CoAP messages are sent and received over UDP, which by nature is unreliable, so a basic reliability scheme is built into CoAP’s communication protocol on top of UDP. For added security, messages can be sent using Datagram Transport Layer Security (DTLS) protocol instead of UDP. In either case, each CoAP message needs to fit into a single UDP/DTLS datagram packet. Further, CoAP supports datagram messaging over IPv4 and IPv6 networks and variants such as 6LoWPAN.

Although unicast UDP is used for the request/reply CoAP protocol, multicast UDP messaging is used to support CoAP device/sensor discovery. CoAP clients and servers support a special “All CoAP Nodes” multicast address, with port 5683, to discover other CoAP servers and their shared resources.


Java Message Service (JMS) 1.1 and 2.0 In Depth

Eric J. Bruno - April 2016

JMS is a specification that describes the properties and behavior of an information pipe for Java software. It also describes how Java client applications interact with the information pipe. This article will go into detail on messaging concepts, JMS application implementation, and some available JMS providers. It begins with a brief discussion on various types of inter-component messaging, quickly moving to the concepts of reliable messaging and JMS. Also covered are discussions on the two main revisions of the JMS specification, JMS 1.1 and JMS 2.0 All throughout, critical points will be explained with working code, with the differences between JMS specification revisions compared.

The concept of messaging begins with the goal of delivering data. Enterprise messaging forms the communication infrastructure between disparate components and devices in a distributed software system. The important components in a messaging system—producers, consumers, and the messages themselves—are abstracted through the use of interfaces. The result is a set of loosely-coupled components and devices that are part of a cohesive, efficient, reliable IoT system. Components that are loosely-coupled have as few direct interactions with one another as possible. This isolation leads to more robust software, as changes to one part of the system do not ripple through to other parts.

Most messaging systems consist of a broker component that is responsible for delivering messages to and from the various client applications. Messaging brokers generally treat messages as opaque. In fact, the broker doesn’t need to know the purpose or content of a message in order to deliver it. In turn, the software components that send and receive messages don’t need to know how the messages are delivered and, in most cases, which components sent them. The important part is that they are sent and received reliably.


Gartner warns of approaching apocalypse for IoT data management

Melissa Thompson - SmartDataCollective (linked by Eric J. Bruno) - March 2016

Data management in terms of capture and storage, analytics, and governance and compliance are rapidly becoming critical needs for IoT systems as they roll out. There’s a large possibility that many of the companies implementing IoT solutions, or integrating enterprise systems with new IoT systems may put their enterprise or users at risk if they’re not managing that data carefully. A recent Gartner survey shows that 43% of organizations are planning to use IoT in 2016. Be prepared to start your IoT solutions over if you don’t consider these issues early on.

The unprecedented expansion of the Internet of Things (IoT) has led to a rapidly expanding amount of generated data. Industry experts are warning that at the current rate of growth, unstructured data will inevitably become an unmanageable tsunami. Data management overload is a near-certainty.

Gartner states that information management must be a key core competency in the near future to avoid disaster. The capabilities of IT managers and others will be challenged by the new governance infrastructure -- this will also impact their tools, skills, and traditional processes.

The ability to handle data management overload is crucial.


Microsoft Azure goes open source in IoT, as Eurotech partners with IBM (linked by Eric J. Bruno) - March 2016

This multi-partnership between IBM and Microsoft, and IBM and Eurotech, enables an open IoT development platform using Eclipse, the Azure Cloud, and MQTT messaging. The Azure Toolkit for Eclipse represents Microsoft's intent to empower any developer on any OS. According to Bob Emmerson of

The Azure Toolkit for Eclipse provides templates and functions that allow developers to create, develop, test and deploy Azure applications using the development environment. The spin is a “developer mission is to deliver experiences that empower any developer, building any application, on any OS.” In addition, Microsoft is taking its relationship with the Eclipse community to the next level by joining the Eclipse Foundation as a Solutions Member.

Eclipse-Kura, which is a Java/OSGi-based framework – with the initial contribution to the Kura project actually coming from Eurotech – is employed in Eurotech’s intelligent multi-service gateway, where Kura APIs enable access to the underlying embedded hardware and a lot more.

Eclipse-Kura is an application development environment that allows programmers to employ Linux and Java, open source technologies with which they are familiar. This means that extending access from Azure to and from this environment makes business sense, i.e. it should give MS a bigger slice of the IoT action. Extending access has been enabled by creating a plug-in, which is a relatively simple task.


MQTT Programming In Depth

Eric J. Bruno - March 2016

MQTT is an open message protocol for machine-to-machine (M2M) or Internet of Things (IoT) communications that enables the transfer of telemetry-style data (i.e. measurements collected in remote locations) in the form of messages from devices and sensors, along unreliable or constrained networks, to a server. Andy Stanford-Clark of IBM, and Arlen Nipper of Cirrus Link Solutions invented the protocol.

MQTT’s strengths are simplicity, a compact binary packet payload (compressed headers, much less verbose than HTTP), and it makes a good fit for simple push messaging scenarios such as temperature updates, stock price tickers, oil pressure feeds or mobile notifications. It also works well connecting constrained or smaller devices and sensors to the enterprise, such as connecting an Arduino device to a web service, for example.


IoT Development with a Raspberry Pi and Arduino

Eric J. Bruno - March 2016

Although originally created as an affordable learning computer for kids, it’s common to find people working with the Raspberry Pi as an IoT development and even a production device. The Raspbian Linux distribution available for it comes with multiple programming environments already setup, including Python, Java SE, and Scratch (for learning).

Kids, hobbyists, teachers, and others interested in making the most of cool and affordable technology have done some interesting things with the Pi. You can run Java on the Pi, and even use it to control an Arduino and other sensors via the serial (USB) port and the GPIO interface. Let's see what it takes to get up and running with your Raspberry Pi, install Java if it’s not already there, or upgrade it.


Defining the ISB

Eric J. Bruno - January 2016

All too often, IoT solutions contain a hodgepodge of components, devices and software at the remote end. This can include a gateway (or a smart phone or tablet in its place), Wifi connectivity (Mifi’s are sometimes used), and varying sensors and boards with a multitude of communication protocols. For instance, there may be Zigbee communication from electrical controllers to a specialized Zigbee gateway, then Ethernet connectivity to a second gateway that connects to the Internet, and possibly other smart devices on-site depending on the solution.

This might get the job done, but it’s not reasonably flexible or reusable. Instead, what’s needed is a standardized approach to device and sensor communication, where back-end server connectivity is seen as an extension of the remote solution. This is what we call the IoT Service Bus (ISB), and its enabled by IoT gateway software (and device libraries) that provide the following:

  • Secure, reliable, message-based communication between cloud/data center and the remote location (i.e. JMS, WebSockets, REST)
  • Device-specific protocol communications (MQTT, CoAP, Zigbee, RFID, and so on)
  • Multimedia support
  • An embedded database
  • Search capabilities
  • Logging facility
  • Edge analytics and machine learning
  • OSGi support


A Cloud-based Approach for the Internet of Things

Eric J. Bruno - March 2016

The Internet of Things (IoT) is part of a promising future where smart computing devices will communicate with one another, with people, and with the enterprise applications we use. But IoT value is in the data, reaching from the enterprise out to realize the tremendous potential at our fingertips. This data-centric view of IoT requires the integration of new data services, the injection of intelligence into our devices, and the interconnections with enterprise systems.

Soon, we’ll see growing numbers of devices and systems connected in ways we haven’t yet imagined, requiring us to handle a wider variety of data types with even greater volume and velocity. To use IoT to discover what’s truly important and relevant to your business and your users, you need to have the right IT capabilities. The technical requirements and data volumes introduced are best met by the cloud, which surpasses traditional data center implementations in multiple dimensions.

Devices and sensors are a means to acquire valuable data, and IoT applications often require a distributed set of services to act on that data. The timely, contextual data, along with the cloud, are so crucial to IoT, they essentially transform and extend enterprise architecture beyond what we know today. Although on-premise enterprise application infrastructure has much in common with IoT infrastructure requirements in terms of technology, it’s the cloud that solves many of the challenges head-on.