TAPI icon indicating copy to clipboard operation
TAPI copied to clipboard

Identification of "intent" modeling items

Open amazzini opened this issue 6 years ago • 0 comments

Considering the attributes with complex data types (including the reference by value to other classes), how to code them into the name-value pairs of e.g. object creation notifications? It is proposed to fill the “value” string with the JSON dump of the complex type. This solution anyway opens some further considerations, e.g. in case of object creation notification of a ConnectivityService instance. ConnectivityService class has a number of composed classes: CSEP, TopologyConstraint, ResilienceConstraint, RoutingConstraint, ConnectivityConstraint. In theory, all these ancillary object instances shall be dumped into ConnectivityService Creation Notification parameters (or as result of "get" ConnectivityService). But e.g. "_corouteInclusion", refers to a ConnectivityService, which may be no longer existing. In general, it seems necessary to identify "intent" items, which may be meaningful only at provisioning time. Maybe is only necessary to have UUIDs for all the references to instances that may disappear during ConnectivityService lifecycle.

amazzini avatar Jun 12 '19 15:06 amazzini