IDD 5.0 review discussion - Service-registry-administration

[AlexChiquito]

In this Issue we will collect the comments about the service-registry-administration interface definition.

[emanuelpalm]

Link to reviewed document: eu.arrowhead.service-registry-administration-http-json.yml.

[emanuelpalm]

Administration or Management?

This IDD has a name including the term "administration". Does the word "administration" has a meaning that is distinct from the term "management" used for the eu.arrowhead.authorization-management-http-json service? If not, then I'd argue that being consistent is good and that both should use the same term. We have mostly used "management" historically, and unless there is a good argument against using that term instead of "administration", I'd say we go with it.

[borditamas]

AITIA review comments

roadmap/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml

Lines 6 to 7 in 5a4f4b2

	on top of either of the HTTP or HTTPS protocols with payloads encoded in JASON. The service allows for
	service providers or cloud administrators to list, register, or unregister services from the service

Normal application systems should not use this, only administrators and higher level supporting systems.

---

• In every management service the operations should support bulk type of inputs (multiple registrations/unregistrations/modifications etc...)
• Previously it was decided that Service Registry will handle the systems and optionally devices too, instead of having separated core systems for them.
  (For example you can't register a consumer (system only) with the service specified by this IDD)
• Operation names should be mentioned by the appropriate endpoint descriptions.
• Payload keys should not mix different formats. Use onlycamelCase or only kebab-case

---

roadmap/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml

Line 55 in 5a4f4b2

/service-registry/list:

• service-type: What is the purpose of this field? In the example, protocol and data format are present. If this field is really needed, then it should be interface independent.
• time-to-live: "2d12h": should be a moment in time, not an interval (also name should be expires-at)
• metadata: why ordered? Previously, we considered to support list and object values as well.
• interface: The example is using the old and simple (almost useless) interface definition.
• Interface related info should not appear in multiple places (etc addresses, basePath).
• Address representation is not user friendly enough, contains information that is too technical and irrelevant for consumers. To use this, you have to split, then change parts (tcp4 -> http or https), add some more (://), etc...
• auth-info: seems like security level (confusing name)
• The interface representation should be more detailed in general (to being useful). We previously proposed this:
  • The new interface consists of a unique name, a protocol, specifies a set of mandatory (and optional) fields (with types).
  • When a service supports an interface, it should provide the actual values for the specified mandatory fields.
    Example name: http-myservice1
    Example protocol: http [string]
    Example policy: unsecured [string]
    Example mandatory fields:
    accessAddress: 127.0.0.1 [string]
    accessPort: 6413 [number]
    basePath: /path [string]
    method: GET [enum (GET, POST, etc)]
    contentType: application/json [string]
    Example optional fields:
    inputModels: [{ operation: operation1, modelRef: xyz }] [object array]
    outputModels: [{ operation: operation1, modelRef: xyz }] [object array]

Example of how we think a service instance response payload should look like:

[
   {
      "serviceId":"provider01-myservice-1.4",
      "provider":{
         "name":"provider01",
         "metadata":{
            "key":"value"
         }
      },
      "serviceDefinition":"myservice",
      "version":"1.4",
      "expiresAt":"2023-07-14T14:46:47Z",
      "metadata":{
         "additionalProp1":"value1",
         "additionalProp2":[
            "value2a",
            "value2b"
         ],
         "additionalProp3":{
            "key":"value"
         }
      },
      "interfaces":[
         {
            "name":"http-myservice",
            "protocol":"http",
            "policy":"unsecured",
            "properties":{
               "accessAddress":"127.0.0.1",
               "accessPort":6413,
               "basePath":"/path",
               "method":"GET",
               "contentType":"application/json"
            }
         }
      ]
   }
]	

---

roadmap/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml

Line 96 in 5a4f4b2

/service-registry/delete:

DELETE operation: should not use request body, to delete a sr entry you need only the serviceID (or systemname, service def name, and optionally version)

---

Administration or Management?

We vote for "management" due to the historical aspect.

---

Typo:

• JASON => JSON (Introduction)

[borditamas]

@AlexChiquito @emanuelpalm @PerOlofsson-Sinetiq
Could you please provide Sinetiq's feedback before the next RoadMap (05.02) in order to being able to discuss it there?
As you know, last time the 14th of May (before AIMS 5.0 GA) was agreed to target the specification being finalized, so we don't have so much time.