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. 

•  

  • There're 2 kinds of aspects we could model:

    • Aspect 1: function/operations

    • Aspect 2: structure of things

  • Nigel's argument is that composite pattern only applies to aspect 1

    • John gives an example that composite pattern is also used to model the structure of an organization (aspect 2)

  • Principle for using composite pattern:

    • using composite pattern when:

      • you want to represent part-whole hierarchies of objects

      • you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly

  • The question is which aspect (or both) we are trying to model. Do the patterns only apply to certain aspect(s)?

•  

  • Pro:

    • Distinguish things that are atomic vs things that are collections of things

    • For atomic object, it’s known that it will not have parts of the same type (less error-prone)

  • Con:

    • Different subclasses inherited from “composite” can contain each other when there’s no constraints

    • How to process different views, i.e., some object can be both atomic/composite based on usage:

    • E.g., a service is atomic to a customer (the details of a service is opaque to the customer)

    • the same service is composite to the operator (may compose of other services)

    • If an “atomic” object becomes “composite”, need to create new class, delete all old instances and create new instances based on new class (To be confirmed)

•  

  • Pro:

    • DON’T need to distinguish things that are atomic vs things that are collections of things (enable flexibility)

  • Con:

    • If a superclass has recursive relationship, all the subclasses need to support this relationship, and is very error-prone

    • Lacks consistency if adding recursive relationship to individual (leaf) classes

    • Need to define rules to clearly describe recursive relationship

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.