Sorry, forgot one other thing. Looking at the Service diagram (11-08 version), you are NOT using the composite pattern. What you have is a recursive aggregation, which is NOT the same thing, and is prone to causing modeling problems if you have subclasses of ServiceComponentDesc.
If you need help on patterns, please let me know, and we can chat offline. regards, John On Wed, Nov 22, 2017 at 5:38 PM, John Strassner <[email protected]> wrote: > There are a number of reasons, but the most important are: > > 1) The Decorator enables attributes and/or methods to be used to > construct a new object dynamically at runtime; the composite is fixed at > design time > 2) The Decorator enables one to use all or part of an object to build a > new object. The composite, like the ONF spec pattern and the TMF spec > pattern, is restricted to using the entire object. > > > regards, > John > > On Wed, Nov 22, 2017 at 3:44 PM, 邓灵莉 <[email protected]> wrote: > >> I believe we are using the composite pattern currently. >> Why the decorator pattern would be better? >> >> Lingli >> >> >> 发自网易邮箱大师 >> On 11/23/2017 05:03, John Strassner <[email protected]> wrote: >> >> While I agree with the requirements that Andy said (e.g., a >> ServiceComponent should support multiple Services, and a ServiceComponent >> should exist independent of a Service), >> >> 1) this is assuming that a ServiceComponent is as defined in the MEF >> 2) I don't think the existing model works - you either need a >> composite pattern or a decorator pattern to do this correctly >> >> Of the two, I believe that a decorator pattern is better suited (that's >> how we modeled this in the MEF). >> >> regards, >> John >> >> On Wed, Nov 22, 2017 at 11:15 AM, MAYER, ANDREW J <[email protected]> wrote: >> >>> Xu, >>> >>> >>> >>> Thank you for the questions. I provided a partial answer in-line with >>> your questions. >>> >>> >>> >>> Best Regards, >>> Andy >>> >>> >>> >>> *Andy Mayer, Ph.D. *| PMTS, D2.0 Integration | AT&T Labs | Phone: +1 >>> (732) 420-9945 <(732)%20420-9945> | [email protected] >>> >>> >>> >>> *From:* yangxu (H) [mailto:[email protected]] >>> *Sent:* Thursday, November 16, 2017 10:29 AM >>> *To:* MAYER, ANDREW J <[email protected]>; FORSYTH, JAMES <[email protected]>; >>> SCAGGS, KEVIN <[email protected]> >>> *Cc:* [email protected] >>> *Subject:* [onap-discuss] Questions on the ONAP R2+ Resource IM >>> >>> >>> >>> Dear Jimmy, Andy and Kevin >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_-7Eks0567&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3UIWLh7P2rAFm1qdZ7jMYQ&m=DbssT-o1dpLv7XFdBf9mssaQbsxlSnlqaWzswYhP6ws&s=ZB3dq-yjpATtQpVg2ouQJGL7G0nAaG5DV3y5DUSS2F4&e=> >>> , >>> >>> As discussed in the modeling call, there’re several questions regarding >>> the resource IM that need to be answered. Please find them below: >>> >>> To Andy & Kevin, >>> >>> 1) Regarding the design time model (the figure shows the >>> relationship between ServiceDesc, ServiceComponentDesc, >>> ResourceCatalogItem, VNFDesc and VNFCDesc), the AID document states that "a >>> service component has a zero to many relationship to service while the vnf >>> component has is related to exactly one vnf". What's the case for a service >>> component to have zero relationship to service? Does it imply that a >>> service component can exist alone (without being involved in a service) in >>> design time? >>> >>> [AJM] Service Component Descriptors may exist independently from the >>> Service Descriptor since they may be created as “building blocks” >>> representing specific types of service functionality (e.g., firewall >>> functionality) used to construct Service Descriptors. Also, a Service >>> Component Descriptor may be employed by for than one Service Descriptor. >>> For VNFC Descriptors, the VNFC Descriptor is dependent on the containing >>> VNF Descriptor for its existence, and the VNFC Descriptor is not shared >>> across VNF Descriptors. >>> >>> 2) Regarding the vNF deployment diagram figure (the run time model): >>> >>> a) It seems it’s not updated like the design time model, do you >>> have any plan to align it to the design time model? >>> >>> [AJM] We are currently updating the Run-Time diagram to align. >>> >>> b) For the current figure, we want to know the answers for: >>> >>> i. What's the relationship between >>> VNFC instance and VNF module? What's the usage of VNF module? >>> >>> ii. Why does network only associate >>> with the VM, but not with Docker/LXC? Why is the cardinality 1:1? >>> >>> iii. Why does storage have no >>> association with VNFC instance? >>> >>> iv. Why does VNFImage have 1:1 >>> association with VNF instance, instead of VNFC instance? >>> >>> v. No model for network port? >>> >>> To Jimmy, >>> >>> First thank you and Pamela for the comments you provided last >>> time, I updated several questions afterwards, shown below: >>> >>> 1) Is the orchestration-status of the VNFC similar to the vnfcState >>> defined in ETSI? (vnfcState describes the state of a VNFC instance, >>> possible values are: STARTED, STOPPED. STARTED means the VNFC instance is >>> up and running, and STOPPED means the VNFC instance has been shut down (but >>> not terminated/deleted). Similar to the VM power on/off concept) >>> >>> 2) Please clarify more on the operational-status of VNF, are the >>> valid values “in-service-path” and “out-of-service-path”? and what do they >>> mean? >>> >>> 3) Orchestration-status of the VNF is also not clear to us, could >>> you elaborate more on the usage of it? For example, the valid values? >>> >>> >>> >>> Thank you all for the help! >>> >>> Best regards, >>> >>> Xu >>> >>> _______________________________________________ >>> onap-discuss mailing list >>> [email protected] >>> https://lists.onap.org/mailman/listinfo/onap-discuss >>> >>> >> >> >> -- >> regards, >> John >> >> > > > -- > regards, > John > -- regards, John
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
