Happy to. Although please realize that there is NO instance of a composite pattern in "ONAP Service 2017-11-08" The same is true for "ONAP Resource 2017-11-08". Hence, I would like to know what diagram you are looking at...
...In fact, there are a LOT of recursive relationships, and in general, these cause problems in modeling. If that is unclear, please let me know. regards, John On Wed, Nov 22, 2017 at 5:47 PM, Lingli Deng <[email protected]> wrote: > 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]> > 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 > -- regards, John
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
