Some notes taken in today's meeting with NEC team about the removal of this functionality:

• Independently what roadmaps says, registration removal is not going to happen soon. We are flexible with dates.
• Registration removal for update forwarding doesn't impact NEC deployments. NEC is going to double check
• Registration removal for query forwarding impacts NEC deployments. Alternatives
  • Keep registration query forwarding functionality in Orion by the moment (probably simplifying it to match NEC use case)
  • Rework registration query forwarding into a "getData" command
  • Split out registration functionality from Orion into a different component (a kind of proxy). That proxy could be a frozen version of Orion (e.g. 3.11.0) but security maintenance could be an issue.

@mapedraza @fgalan I can totally understand and appreciate the refactoring of commands in #4397 as it is really fragile. Once someone did something woring the complete commucation chain breaks. However, using Orion as Aggregator is quite useful in many sceanarios because in micro-service structures it is often a hassle to request data from the individual components and requires additional effort when implementing additional services.

Here a an additioanl use case from a smart building control:

Let's say we have a heater in a room and a temperatur sensor (IoT-devices)
Instead of the an actual weather station we use open weather map for forecasts. The latter is accessed via a leigtweight state-less NGSI-Proxy that holds is complete information in Orion.
With the current implementation our temperature controller can be easily connected to the context broker using MQTT-Subscription for receiving data and HTTP-Commands for control actions.
If the controller requires weather information it asks the Orion for the weather-station, which fowards to the request to the provider, which in turn, requests the data from open-weather-map using.

This scenario allows for total event-based communication with the OpenWeatherMap. Here we even control the allowed access rate to the OpenWeatherMap. Hence, we have total control of costs and reduction of management cost using the NGSI-Proxy.

The NGSI-Proxy, can also be used for any other additonal external service. Especially, in smart building where often a heteregenous IT-infrastructure is installed this is quite valuable and allows to integrate many different stakeholder-APIs

Issue without registations
The scenario above would not be possible taht easy and requires additonal services the, e.g. implement virtual devices.
However, these would require to regularly request and forward data even if not needed. This would also duplicate existing data.

In a nutshell, as @fgalan proposed at least something like a getData function should be available. However, maybe keeping query forwarding is even easier. As the enduser does not need to know where the actual data comes from. Nevertheless, probably there should be a mechanism to check for conflicting registration and harden attributes for that orion has a registration to prevent them from getting overwritten. As from my experience the latter often leads to trouble because developers forget to first delete old registrations before adding a new one. However, same applies to subscriptions.

PS: I hope I could make a point and also git the right issue :)