Bridging the REST gap for C++ M2M Frameworks

As a system architect when you have to design an Enterprise grade M2M Telematics framework your first quest starts with what is the right toolset available for the job and what are the gaps to fill?

From the software standpoint, M2M is all about inter-connectivity, and being so, Lightweight and Interoperability becomes two vital factors for any successful implementation. Towards this goal one would have to even make some unconventional trade-offs, such as having to choose between strong encryption and long battery-life.

C/C++ is known for its low-overhead output, which made it the defacto standard for embedded systems and real-time frameworks, but would it be able to retain its top position for M2M also by providing an interoperable connectivity ?

One can easily implement a high-throughput network layer with ZeroMQ in C/C++ , but if it means being isolated from the mainstream networks, then one has to think twice. Or a high-secure MQTT realtime distributed network in C/C++, but if it drains your device battery, then your device may not have much story to tell after its decay.

In a traditional web client-server architectures a HTTP protocol may look inferior to, say MQTT or Websocket, due to its handshake requirement for every request afresh, but in most remote sensing applications, one can achieve equal amount of performance with HTTP batching the data points (and more importantly conserving the network costs and battery life). Try maintaining a websocket connection over wifi while going on an average speed train to understand the importance of disconnected protocols in remote sensing applications. And try doing this communication as peer to peer across two trains in opposite direction crossing each other.

In a nutshell, each protocol has its role to play in the stack somewhere. For example, MQTT for CAN based OTMR devices on board the train, HTTP for relaying batched metrics at the station while it is stationary, ZYRE for peer-to-peer on-track communications etc., which means your M2M framework has to provide support for all those required protocols in an inter-operable manner.

MQTT, Websockets, ZMQ etc. all have very good client side libraries for C/C++. What about HTTP REST?

The REST Story

Currently consuming or producing REST services from C++ can be dealt with in two ways:

  1. hand-crafting the HTTP API calls directly with sdks such as CPPREST SDK;
  2. utilizing specifications such as Swagger, RAML etc.

The first method of hand-crafting gives more granular control, but

Specifications such as Swagger, RAML etc. try to address this problem. They allow REST functionality to be specified as a schema and tools to be built around them to auto-generate proxy/stub classes for that schema.

But how can one make this fit into C++?

C/C++ REST Requirements

Let us list our requirements:

For the producer side:

While these above requirements are basic, they are not sufficient to build distributed enterprise mode C++ REST applications. Because they are missing below features and a good C++ REST middleware should strongly consider supporting them too.

The additional requirements to make the above compliant with enterprise mode application are:

Parting words

REST apis are going to play prominent role, alongside with the real-time messaging protocols, in the M2M world. Designing an enterprise grade REST middleware for C/C++ to serve the needs of M2M is a challenging task and the gap to be filled by the open-source community is clearly laid out. With string_view, memory_resource pooling support on the horizon for C++17, and concepts somewhere nearby, one can soon expect this gap to be filled with best of the breed solutions.

Additional Study Material:

GK Palem, M2M Consultant
Published On: 21-Jul-2016

Keywords: GK, Blockchain Consultant, Artificial Intelligence, IOT, Open Source, CarMusTy, CFugue, C/C++ Music Library, Carnatic Music, Song, Notation, MIDI, Typesetting, PDF, Books, Maya, Visual Effects, DirectX, OpenGL, Simulation, Predictive Analytics, Big Data, M2M Telematics, Predictive Maintenance, Condition-based Maintenance, Research, Cryptography, Distributed Ledger, Mentor, CTO for Hire, Consulting CTO for MVP Building, CTO for Startups, CTO as a Service, Virtual CTO, CTO Advisory Services.