Rework commands (and deprecate registration API)

[mapedraza]

Commands are currently based on Context Providers (CPr), sending command requests based on context updates forwarding (based on registrations). This mechanism has a lot of problems, as detailed in this issue.

The same sending of command request can be achieved using custom notifications (based on subscriptions). A subscription is a much more convenient way of sending requests to endpoints, widely used and without any existing important issue.

Once the new commands mechanism get implemented in IoT Agents, the registration API (and associated request forwarding) will be deprecated and eventually removed (that's part of issue #4402). Note that registries are also used to forward queries (out of the scope of the command use case) but this functionality is not actually used in relevant use cases, so its value is small and its deprecation/removal doesn't hurt.

[ArqamFarooqui110719]

Hi @fgalan, @mapedraza,

Is it correct to understand that this issue requires the following two actions?

1. Switch the cooperation between Orion and IoT Agent from forwarding based on registrations to notifications based on subscriptions.
2. Delete registrations as they will no longer be used.

If the above understanding is correct, regarding 2., there is a use case that uses registrations, so please do not delete it (To delete the registration API, github issue #4402 has been created).

Use case:
Use Orion (CB) as a point of contact for information held by companies and local governments (Using Orion for CPr) (see #4149 (comment))

Advantages of registrations in the above use case:

• Referenced data is centrally managed by CPr (with Subscription API, copies increase by the number of CBs)
• There is no need to prepare an area to store all referenced data in the CB DB.

[mapedraza]

Hi @ArqamFarooqui110719 your understanding is correct, the plans are:

1. IoT Agent will switch CB communication mechanism from forwarding based on registrations to notifications based on subscriptions. At this point, registration will be deprecated.
2. After that, at some point, registrations API support will be dropped. Consider this is going to take time, is not going to be imminent and you will have time to adapt systems to new IoTA Node Lib version

This would mean CB will no longer support registrations ("act as aggregator"), but, in any case, it will be able to act as context provider for another system.

For As I addressed in the issue you mention (see #4149 (comment)) we alternatively propose an external component that act as agregator. This component can be developed using other technologies (such as python or nodejs) to ease the development and also be part of the orion repo.

Being said that, we are open to listen in deep your uses cases and see how we can approach this