Context Providers registration and request forwarding

The register context operation (both in standard and convenience cases) uses a field named "providing application" which is a URL that identifies the source of the context information for the entities/attributes included in that registration. We call that source the "Context Provider" (or CPr, for short).

 ...                                                                           
 "providingApplication" : "http://mysensors.com/Rooms"
 ...

If Orion receives a query or update operation (either in the standard or in the convenience family) and it cannot find the targeted context element locally (i.e. in its internal database) but a Context Provider is registered for that context element, then Orion will forward the query/update request to the Context Provider. In this case, Orion acts as a pure "NGSI proxy" (i.e. doesn't cache the result of the query internally) and, from the poinf of view of the client issuing the original request, the process is mostly transparent. The Context Provider is meant to implement the NGSI10 API (at least partially) to support the query/update operation.

Let's illustrate this with an example.

  (curl localhost:1026/v1/registry/registerContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d @- | python -mjson.tool) <<EOF
  {
  "contextRegistrations": [
      {
      "entities": [
          {
          "type": "Street",
          "isPattern": "false",
          "id": "Street4"
          }
      ],
      "attributes": [
          {
          "name": "temperature",
          "type": "float",
          "isDomain": "false"
          }
      ],
      "providingApplication": "http://sensor48.mycity.com/v1"
      }
  ],
  "duration": "P1M"
  }
  EOF
  (curl localhost:1026/v1/queryContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d @- | python -mjson.tool) <<EOF
  {
  "entities": [
      {
      "type": "Street",
      "isPattern": "false",
      "id": "Street4"
      }
  ],
  "attributes": [
      "temperature"
  ]
  }
  EOF
  {
  "entities": [
      {
      "type": "Street",
      "isPattern": "false",
      "id": "Street4"
      }
  ],
  "attributes": [
      "temperature"
  ]
  }
  {
  "contextResponses": [
      {
      "contextElement": {
          "attributes": [
          {
              "name": "temperature",
              "type": "float",
              "value": "16"
          }
          ],
          "id": "Street4",
          "isPattern": "false",
          "type": "Street"
          },
      "statusCode": {
          "code": "200",
          "reasonPhrase": "OK"
      }
      }
  ]
  }

{ "contextResponses": [ { "contextElement": { "attributes": [ { "name": "temperature", "type": "float", "value": "16" } ], "id": "Street4", "isPattern": "false", "type": "Street" }, "statusCode": { "code": "200", "details": "Redirected to context provider http://sensor48.mycity.com/ngsi10", "reasonPhrase": "OK" } } ] }

The Context Providers and request forwarding functionality was developed in release 0.15.0. Previous version of Orion Context Broker just stores this field in the database. Thus, applications can access the Providing Application using the discover context availability operation and do whatever they want with it. This is typically the case when the Orion Context Broker is used just as a repository for NGSI9 registrations, but the actual management of context information is done by other components of the architecture. Although current versions support Context Providers and request forwarding functionaly, nothing precludes you from using Orion also in that way.

Some additional comments: