Message brokers are usually leveraged to support message collection and real-time dissemination of messages to IoT services and applications. To implement such data collection brokers, there are numerous message broker implementations. Mosquitto is a lightweight broker developed in C mainly used for prototype development. It supports data exchange with MQTT-based clients while it does not support clustering. RabbitMQ ****is the most widely deployed open source message broker developed in Erlang. It supports both MQTT and AMQP data exchange protocols and clustering functionalities. Apache Kafka ****is a centralized data pipeline that supports elastic scalability, durability and high-throughput (millions of messages). Producers publish data to the topics of their choice while consumers subscribe to a specific topic and partition.
NGSI-LD context brokers are brokers that allow for the management and requesting context of information in a structured manner based on linked data standards following the NGSI-LD specification of the ETSI standard, however the specification is a living, changing document (on version 1.5 as of July 2021), with features added in a pace that is hard for the NGSI-LD implementations to keep up. Currently there are 4 different NGSI-LD broker implementations, namely Scorpio, Orion-LD, Djane ****and Stellio. Orion-LD is the only context broker which can service both NGSI-v2 and NGSI-LD.
Stellio, Scorpio and Djane are pure NGSI-LD brokers which don't need the compromises of having to serve both syntaxes. Scorpio positions itself as the heavyweight broker, with a strong interest in federations. Stellio is somewhere in the middle between Scorpio and Orion. All of them are still in a development phase, with Djane and Stellio being the ones with the least ETSI specification compliant features. Scorpio implements the full NGSI-LD api and Orion-LD is in a fast development track, having recently implemented the temporal api (which is the main aspect of the NGSI-LD test suite that orion-ld failed to pass before) with their major release Beta 3 in june 2021. Thus, since Scorpio and Orion-LD are the only NGSI-LD brokers in a “working condition”, they are the ones presented in the following subsections.
Orion-LD
Orion-LD is a Context Broker which supports both the NGSI-LD and the NGSI-v2 APIs written in C++. It is a fork of the original Orion Context Broker**,** developed as a part of the FIWARE platform, which supports NGSI-v2 only. It is a standalone executable and therefore small, fast, lightweight and easy to handle. Orion-LD has been tested to be a stable and fast NGSI-LD broker with close compliance to the version 1.3.1 of the NGSI-LD API specification. The main feature that was missing until recently, as mentioned before, was the temporal representation of entities which was implemented with the addition of Fiware Mintaka and a timescaleDB database. Mintaka is an implementation of the NGSI-LD temporal retrieval api. It relies on the Orion-LD Context Broker to provide the underlying database and should be viewed as an extra component of Orion-LD. Since Orion-LD is based on the original ngsi-v2 orion broker, it has basically the same underlying base architecture (e.g same storage solution) thus the Orion-v2 architecture is a valuable point of reference for the inner workings of Orion-LD which is however too lengthy to describe in detail here. When specifying the ngsi-ld protocol, an attempt was made to not divert too much from the APIv2 protocol, so that a maximum of the implementation of the already implemented APIv2 orion could be reused. The end goal of the development of the broker is to achieve a fully functional and fully compliant with the NGSI-LD protocol broker, that supports all the existing ngsiv2 capabilities of the original Orion broker, and eventually merging Orion-LD back to the main branch of Orion. The main advantage of this approach is naturally having a broker that supports both ngsi-v2 (and consequently compatible with existing ngsi-v2 smart platforms) while having the roots of an existing robust and community supported context broker.
Scorpio
Scorpio is an NGSI-LD compliant context broker developed by NEC Laboratories Europe and NEC Technologies India. It is the first complete implementation of the NGSI-LD API, standardized by the ETSI Industry Specification Group on cross-cutting Context Information Management (ETSI ISG CIM) and has been recently accepted (18/12/2020) as a full Generic Enabler of FIWARE.
Basically Scorpio broker is a core component of FiWARE/IoT platform wherein IoT data-driven by dynamic context is collected, processed, notified & stored/ingested with different application usage perspectives . As said before , it provides an implementation of REST API endpoints for various data context operations that conform to NGSI-LD API specification.
Scorpio broker allows collecting, processing, notifying and storing of IoT data with dynamic context with the use of linked data concepts. This feature of Link data context provides self-contained (or referenced) dynamic schema definition (i.e. the context) for contained data in each message/entity. Thus allows the Scorpio Broker core processing to still remain unified even if it gets dynamic context-driven data as its input from different types of data sources coupled(or designed for) with different schemas.
It makes use of the microservice-based architecture built with the help of spring boot, which has its own advantages over the existing monolithic IoT brokers such as scalability, cross-technology integration, etc. The advantages of the microservices architecture over monolithic in various applications is still a hot topic in the IoT community.
In more detail Scorpio’s deployment architecture leverages the Spring Cloud framework that addresses lots of Micro-services concerns(e.g. scaling, monitoring, fault-tolerant, highly available, secure, decoupled, etc. ) and Kafka based distributed and scalable message queue infrastructure to provide high performance on message processing for a huge number of context requests which is usual in the IoT domain. The deployment architecture covers the high-level operations request flow from the external world to the Scorpio Broker system. The external request is served through a unified service API gateway interface that exposes a single IP/port combination to be used for all services that the Scorpio Broker system can provide. In reality, each of the Scorpio Broker services can be implemented as a micro-service that can be deployed as an independent standalone unit in a distributed computing environment. That API gateway routes all the incoming requests to the specific microservices with the help of registration & discovery service. Once the request reaches a microservice, based on the operation requirement, it uses(pub/sub) Kafka topics (message queues) for real-time storage and for providing intercommunication among different micro-services (based on requirement) over message queues.
Key advantages of Scorpio Broker, according to its developers, over other brokers: