1-Background

• This page is used to discuss whether to use composite pattern or recursive pattern to describe the "nesting" capability of the "service" model

• Composite pattern was suggested by John to replace the recursive aggregation in December event

• Due to time limit for R2 development, the suggestion was postponed to R3 for further discussion at the first ONAP Modeling Workshop

• John further explained the suggestion and it was agreed in the room in LA Modeling Workshop, composite pattern suggestion should be submitted for broader community discussion

• There is no objection raised in the weekly ONAP modeling subcommittee call the following week, except Andy requested Nigel’s feedback and Kevin requested a comparison for pros and cons of each pattern (composite or recursive) for approval

• An offline email thread is initiated between stakeholders for further exchange of this topic in the next 2 weeks and still not concluded due to lack of attendance for conflict of SDO event

• This page is created after the request during the ONAP Service IM discussion call last week to expose the discussion points and status to the community and welcome further input/view points in this thread before conclusion

2-Discussion Points

Note: This is a summarized list of discussion points for the email discussion.

Please take a reference to the original email threads here. 

3-Latest Summary (from Lingli)

• First of all, as pointed out by Nigel, and I believe we would all agree that we want the model being developed would be able to both used as representing the design time descriptive structure of the objects being managed and also used as guiding the implementation of its runtime data structure and related operations (as we are including both design time and run time aspects from the very beginning). And from this discussion, both composite pattern and recursive aggregation are able to cover both cases. There is no convincing argument that either pattern is only applicable to one of the cases. However, it is agreed that neither of them is perfect for addressing all the potential problem space. Therefore, we need to take them both for our specific modeling scenario for further consideration.

• Secondly, for our specific modeling scenario, it is agreed from this discussion (by both John and Nigel) that recursive aggregation is not recommended to be used directly for high level abstract classes, which is unfortunately the current case for the service IM clean version (i.e. the three circles on the three abstract classes service, service component and resource). In particular, for both service component and resource classes, we have already identified WAN, network service, VNF, VL, PNF as subclasses. So we will have to choose to either using the composite pattern or moving recursive aggregation circles to each subclasses.

• Lastly but not the least, from the previous discussion, it seems that the composite pattern embeds the restriction that no aggregation relation between different subclasses to atomic in composition, while the recursive aggregation needs additional rules to specify those restrictions, and the relevant rules modeling is still a work-in-progress. IMHO, the restriction that one type of atomic service component is not composed of another atomic service component is important to ensure that the current ONAP architectural implementation of a logically centralized SO (takes care of the composite service and decompose it iteratively until the atomic level) on top of various potentially distributed controllers (take care of one or several self-contained atomic services component, e.g. SDNC for wan, VFC for network service, M-Cloud for VNFC and VL, etc.) is technically sound. In other words, the composite pattern uses the concept of atomic to define the functional boundaries and enables the separation of responsibility between various runtime modules that collaborate in end-to-end service orchestration workflow along the structural hierarchy of a service. While the recursive aggregation at each subclass level is more flexible in theory but also dictating more rules to be added for which we do not have any reference design or proposal on the table.