I am not sure we are looking at the same picture. Let us have more discussion offline.
Thanks, Lingli From: John Strassner [mailto:[email protected]] Sent: 2017年11月23日 9:43 To: 邓灵莉 <[email protected]>; John Strassner <[email protected]> Cc: MAYER, ANDREW J <[email protected]>; SCAGGS, KEVIN <[email protected]>; [email protected]; WECHSLER, CHESLA C <[email protected]> Subject: Re: [onap-discuss] Questions on the ONAP R2+ Resource IM 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] <mailto:[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] <mailto:[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, <mailto:[email protected]> John Strassner 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] <mailto:[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 <tel:(732)%20420-9945> | [email protected] <mailto:[email protected]> From: yangxu (H) [mailto:[email protected] <mailto:[email protected]> ] Sent: Thursday, November 16, 2017 10:29 AM To: MAYER, ANDREW J <[email protected] <mailto:[email protected]> >; FORSYTH, JAMES <[email protected] <mailto:[email protected]> >; SCAGGS, KEVIN <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Subject: [onap-discuss] Questions on the ONAP R2+ Resource IM Dear Jimmy, Andy and <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=> Kevin, 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] <mailto:[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
