Hello,
I presume that a service "hierarchy" can be built thanks to serviceRelationship(s):
"ServiceRelationship": {
"type": "object",
"description": "Describes links with services of the same category (useful for bundled services)",
"required": [
"relationshipType",
"service"
],
"properties": {
"relationshipType": {
"type": "string",
"description": "The type of relationship (e.g. depends on, enables)"
},
"service": {
"$ref": "#/definitions/ServiceRef",
"description": "The service being referred to"
},
"@baseType": {
"type": "string",
"description": "When sub-classing, this defines the super-class"
},
"@schemaLocation": {
"type": "string",
"description": "A URI to a JSON-Schema file that defines additional attributes and relationships",
"format": "uri"
},
"@type": {
"type": "string",
"description": "When sub-classing, this defines the sub-class entity name"
}
}
},
However, according to the standard, the relationshipType value is a free string (i.e. not an enumerated list). But if such values are not standard, how two applications can inter-operate correctly, without knowing upfront the semantics of the values?
For example, let's say that a service order is sent by application A towards application B. The ordered service is made of 2 sub-services (e.g. children) with a simple containment relation. Application A uses the relationshipType value "contains" to describe this containment. Note that it could use "child", "contain", "subservice" or whatever instead, as the value is not standard. Then application B, receiving the service order, to be able to understand the service structure must know the meaning of "contains" and know how to deal with it.
Also, I was not able to find any examples of service order request bodies to illustrate things like serviceRelationship, orderRelationship, supportingService, supportingRessource, etc... I think that a good set of examples would be very helpful.
Thanks
------------------------------
Alexandre Meynaud
Hewlett Packard Enterprise
------------------------------