The sum is greater than the parts: Orchestration for the Internet of Things
There are many developments that require new approaches to system architectures. On the one hand, the complexity of products is increasing, making it essential to encapsulate as much as possible. To this end, I had a few thoughts recently published. However, this primarily concerned products that do not change at maturity.
Today we are talking about the architectures for products that are expected to change at runtime. Without wanting to overuse the term, this applies in particular to the Internet of Things (IoT). It is therefore about independent, loosely coupled systems that communicate at runtime. Examples range from home automation to collaborating vehicles, for example for parking lot searches or platoon driving. Orchestration of the parts is necessary here.
Encapsulation is also required for such systems. But there is more to it than that: the interaction of the systems must be orchestrated. The foundations for this were laid over 20 years ago.
Service-Oriented Architectures
One possible architecture for loosely coupled systems sees these as providers of services. Accordingly, these are referred to as "service-oriented architectures". The idea of coupling services has been around for a long time. One of the oldest and often cited implementations is CORBAwhich was developed in the early 90s and is still in use today.
In keeping with the times, CORBA was developed for software components. Even if the interface definitions were independent of a specific programming language, the architecture was still strongly influenced by C++, in keeping with the times.
Even with CORBA, a distinction was made between interface definition and infrastructure. Today, the importance of the interface definition is increasingly receding into the background, as it is easy to translate from one form to the other.
Interface definitions: REST, SOAP, IDL
The interface definition describes in machine-readable form how a request to a service must be formulated and what the response from the service may look like. Popular today is RESTwhich can be understood as a machine-readable website.
A concrete example: A temperature sensor allows a request without parameters and returns the current temperature. But this immediately raises the question: How does a system that wants to know the temperature know how to reach the sensor?
Services for orchestration
In order for the sensor to be found, there must be an infrastructure into which it can be integrated. All SOAs have such infrastructure services. The following image shows the services of the Arrowhead framework (2nd generation). Some of the services are optional.
Image from: Making System of Systems Interoperable - the Core Components of the Arrowhead Framework
To return to the example of the temperature sensor: as soon as the sensor is connected to the system, it is activated via the Service Registry report his presence. The Orchestration system configure it - for example, set the location.
If another system now requires temperature data, it can obtain it from the Service Registry to get the list of all sensors and select a suitable one. This can then be addressed directly.
Standardization of orchestration
In the hotly contested IoT market, it is not surprising that no standard for orchestration has yet been established: Because a lot of influence is at stake here. The paper "A survey of commercial frameworks for the internet of things". You can see the usual suspects operating there: Google, Microsoft, Cisco, and many similar big names.
The Arrowhead project attempts to provide a framework within which the various architectures can at least be kept interoperable. On the one hand, certain architectural framework conditions are specified in order to be "Arrowhead compliant". Furthermore, various strategies are outlined as to how incompatible services can be integrated into an architecture via wrappers or translators.
And the mechanics?
I think it's a shame that comparatively little is said about the interoperability of the physical components. After all, we are talking about the Internet of Things. This is probably not so critical in many applications: for example, the vehicles are not connected to each other when driving in platoons. But if this aspect is not at least fundamentally taken into account, this could again lead to unsightly incompatibilities. Or even worse, accidents.
Conclusion
Anyone working in the IoT sector should at least have a basic understanding of the concept of service-oriented architectures. Even if there are still many unresolved issues, there is no need to reinvent the wheel here.
Photo by Manuel Nägeli on Unsplash
