Issue 2876: WG: Attribute accessors and mutators (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: 1) Should the describe() and modify() operation available be on instance and class level interfaces? For class level attributes it is not necessarly needed because they probably will not be read and modified very often in a group. 2) The property set should be defined in a value-struct. Which attributes should the instance level value-struct contain? class level and instance level attributes. I would prefer only to have instance level attributes in the instance level modify() and describe() operations because of (hopefully) the separation of instance and class level interfaces (no inheritance anymore!). 3) Should the value-struct also contain multi-valued attributes. I would prefer, not to include multi-valued attributes in the value-struct because of the modify() operation. 4) How about read-only attributes. If the same value-struct is used for describe() and modify(), should the read-only attributes be included in the value-struct and ignored in the modify() operation? 5) To define the value-struct as a NamedValue sequence with the values of the type any (as available in the Reflective interface) is not optimal because this operation is untyped and requires the use of the any type. The value-struct should be typed. 6) In our work we have defined the value-struct, modify() and describe() operations as model-specific operations (this is fully MOF-compliant). This allows us to customize the value-struct as needed. However, because probably everybody has the same requirements there should be a way in the MOF-spec to defined such constructs in a standard way. Resolution: Revised Text: Actions taken: September 9, 1999: received issue Discussion: End of Annotations:===== From: "Werner Froidevaux" To: Subject: WG: Attribute accessors and mutators Date: Thu, 9 Sep 1999 19:27:27 +0200 Message-ID: <000301befae8$965349b0$0601010a@omex.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Loop-Detect: 1 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 52ea728b40ef7b756fbd1475a81e21cd All-- I fully agree. I already mentioned this topic in erlier mails but as far as I understood the answers I thought this will only be solved in MOF 1.4. The following things should be thought about: 1) Should the describe() and modify() operation available be on instance and class level interfaces? For class level attributes it is not necessarly needed because they probably will not be read and modified very often in a group. 2) The property set should be defined in a value-struct. Which attributes should the instance level value-struct contain? class level and instance level attributes. I would prefer only to have instance level attributes in the instance level modify() and describe() operations because of (hopefully) the separation of instance and class level interfaces (no inheritance anymore!). 3) Should the value-struct also contain multi-valued attributes. I would prefer, not to include multi-valued attributes in the value-struct because of the modify() operation. 4) How about read-only attributes. If the same value-struct is used for describe() and modify(), should the read-only attributes be included in the value-struct and ignored in the modify() operation? 5) To define the value-struct as a NamedValue sequence with the values of the type any (as available in the Reflective interface) is not optimal because this operation is untyped and requires the use of the any type. The value-struct should be typed. 6) In our work we have defined the value-struct, modify() and describe() operations as model-specific operations (this is fully MOF-compliant). This allows us to customize the value-struct as needed. However, because probably everybody has the same requirements there should be a way in the MOF-spec to defined such constructs in a standard way. -werner. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Werner Froidevaux, OMEX AG Object Middleware Experts Technoparkstr. 1, CH-8005 Zurich, Switzerland, http://www.omex.ch Mailto:werner.froidevaux@omex.ch, Voice: +41-1-445-2951, Fax: +41-1-445-2959 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > -----Urspr|ngliche Nachricht----- > Von: dfrankel@gendev.com [mailto:dfrankel@gendev.com] > Gesendet am: Mittwoch, 8. September 1999 17:14 > An: mof-rtf@omg.org > Betreff: Attribute accessors and mutators > > All-- > > Since there is a little more time now to complete MOF 1.3, I would > like to > raise an issue that I've mentioned to some of you before. If a MOF > Class > has N attributes, then a client of an instance needs to make N > accessor > calls to get all the attribute values and N mutator calls to set all > the > values. This is impractical in distributed systems because of the > large > volume of network traffic it generates. > > Recommendation: The MOF-IDL mapping template for a Class with N > attributes > should dictate the generation of an accessor operation that has an > out-parameter for each of the Class's attributes, i.e. N > out-parameters. > It should also dictate the generation of a mutator operation that > has an > in-parameter for each of the attributes, i.e. N in-parameters. I > also > recommend that the individual accessors and mutators for each > attribute > still be generated as they are today, since they are more efficient > when > just one attribute value needs to be accessed or changed. > > --David Frankel > > ============================= > David S. Frankel > Chief Scientist > Genesis Development Corporation > 741 Santiago Court > Chico, CA 95973-8781 U.S.A. > http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= X-Mailer: exmh version 2.0.2 2/24/98 To: "Werner Froidevaux" cc: mof-rtf@omg.org, David Frankel Subject: Re: WG: Attribute accessors and mutators In-reply-to: Your message of "Thu, 09 Sep 1999 19:27:27 +0200." <000301befae8$965349b0$0601010a@omex.ch> Mime-Version: 1.0 Date: Fri, 10 Sep 1999 10:35:38 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: 189e22f6231f346367efc7e9efde9dd2 Werner and Dave, I agree that under certain circumstances it would be nice to have combined accessor / mutator operations for all Attribute values for a Class. There are lots of other things that might be nice too: * combined accessor / mutators for the Reference values * iterators for multi-valued Attributes and References * iterators for results of Association queries * more complex Association queries * and so on. On the down side, each one of these new features makes the IDL larger. That in turn means bigger client side stubs, larger servers and more complexity in the IDL and server generation. We could address that by allowing the meta-modeller to enable or disable these new IDL mapping features using Tags or compiler switches. But that has its problems too: * If anything, it makes it harder to keep the IDL mapping coherent. * It makes IDL and server generation harder. * It creates potential interoperability problems; e.g. if my copy of the MOF Model has different IDL mapping Tags to yours, my MODL compiler may not be able to talk to your MOF repository. [You could address this by making the IDL mapping Tags part of the published meta-model ... but that doesn't feel right.] * It makes life harder for a client program that uses DII to access an M2-level repository. [OK ... this is a bit far fetched.] * It makes interoperability between MOF V1.3 and MOF V1.4 compliant products problematical. I'm not against changes in the IDL mapping. But before we start down this "slippery slope", we need to >>fully<< understand the consequences. -- Steve X-Sender: dfrankel@pop.usit.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 10 Sep 1999 09:34:04 -0700 To: "Cummins, Fred A" From: David Frankel Subject: RE: Attribute accessors and mutators Cc: mof-rtf@omg.org In-Reply-To: <1EBCB2C34E1ED2118D6900A02461EEA20501699E@usahm010.exmi01.e xch.eds.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: bab1237a98bc3d377c33e4a9e86a973f Fred-- The specialization issue does need to be thought through carefully, good point. --Dave At 09:44 AM 9/10/99 -0400, you wrote: >David, > >Using a list of out parameters that is different for each class >is cumbersome at best. It also makes specialization inconsistent >since a specialization could have more attributes. Use a >name-value sequence or similar mechanism. It also allows >a less than all list to be used. A request can identify those >attributes of interest. > >Fred > >> -----Original Message----- >> From: David Frankel [mailto:dfrankel@gendev.com] >> Sent: Wednesday, September 08, 1999 11:14 AM >> To: mof-rtf@omg.org >> Subject: Attribute accessors and mutators >> >> >> All-- >> >> Since there is a little more time now to complete MOF 1.3, I >> would like to >> raise an issue that I've mentioned to some of you before. If >> a MOF Class >> has N attributes, then a client of an instance needs to make >> N accessor >> calls to get all the attribute values and N mutator calls to >> set all the >> values. This is impractical in distributed systems because >> of the large >> volume of network traffic it generates. >> >> Recommendation: The MOF-IDL mapping template for a Class with >> N attributes >> should dictate the generation of an accessor operation that has an >> out-parameter for each of the Class's attributes, i.e. N >> out-parameters. >> It should also dictate the generation of a mutator operation >> that has an >> in-parameter for each of the attributes, i.e. N in-parameters. I also >> recommend that the individual accessors and mutators for each >> attribute >> still be generated as they are today, since they are more >> efficient when >> just one attribute value needs to be accessed or changed. >> >> --David Frankel >> >> ============================= >> David S. Frankel >> Chief Scientist >> Genesis Development Corporation >> 741 Santiago Court >> Chico, CA 95973-8781 U.S.A. >> >http://www.gendev.com >dfrankel@gendev.com >+1-530-893-1100 phone >+1-530-893-1153 fax >============================= > ============================= David S. Frankel Chief Scientist Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Attribute accessors and mutators Date: Thu, 9 Sep 1999 17:05:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ea7cc653dd52b9ed18d42a725bdf15b3 A better solution to this problem might come from CORBA objects-by-value which we need to address in the near future. Also, XMI provides a means for transferring several properties of an object (or group of objects) at one time. Let's reconsider this issue for MOF 1.4 or 2.0. Regards, Don Baisley Unisys -----Original Message----- From: David Frankel [mailto:dfrankel@gendev.com] Sent: Wednesday, September 08, 1999 8:14 AM To: mof-rtf@omg.org Subject: Attribute accessors and mutators All-- Since there is a little more time now to complete MOF 1.3, I would like to raise an issue that I've mentioned to some of you before. If a MOF Class has N attributes, then a client of an instance needs to make N accessor calls to get all the attribute values and N mutator calls to set all the values. This is impractical in distributed systems because of the large volume of network traffic it generates. Recommendation: The MOF-IDL mapping template for a Class with N attributes should dictate the generation of an accessor operation that has an out-parameter for each of the Class's attributes, i.e. N out-parameters. It should also dictate the generation of a mutator operation that has an in-parameter for each of the attributes, i.e. N in-parameters. I also recommend that the individual accessors and mutators for each attribute still be generated as they are today, since they are more efficient when just one attribute value needs to be accessed or changed. --David Frankel ============================= David S. Frankel Chief Scientist Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= X-Sender: dfrankel@pop.usit.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 10 Sep 1999 10:09:09 -0700 To: Stephen Crawley , "Werner Froidevaux" From: David Frankel Subject: Re: WG: Attribute accessors and mutators Cc: mof-rtf@omg.org In-Reply-To: <199909100035.KAA10969@piglet.dstc.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: caca298911c0da91f57e29879d0fc45b Steve-- Thanks for your very cogent analysis. I agree with you that this is only one of several things that need to be done. I am inclined to avoid going down the optionality route because interoperability would suffer, as you point out. You make a good case (and Fred Cummins' note too) for not rushing to squeeze this into MOF 1.3 and taking the time to make a coherent set of revisions. Ultimately we cannot avoid making a round of revisions to the MOF-IDL mapping to make it practical for distributed systems. Now that we have IDL valuetypes, this ought to be easier than it would have been in the past. --Dave At 10:35 AM 9/10/99 +1000, Stephen Crawley wrote: > >Werner and Dave, > >I agree that under certain circumstances it would be nice to have >combined accessor / mutator operations for all Attribute values >for a Class. There are lots of other things that might be nice too: > > * combined accessor / mutators for the Reference values > > * iterators for multi-valued Attributes and References > > * iterators for results of Association queries > > * more complex Association queries > > * and so on. > >On the down side, each one of these new features makes the IDL >larger. That in turn means bigger client side stubs, larger >servers and more complexity in the IDL and server generation. > >We could address that by allowing the meta-modeller to enable >or disable these new IDL mapping features using Tags or compiler >switches. But that has its problems too: > > * If anything, it makes it harder to keep the IDL mapping > coherent. > > * It makes IDL and server generation harder. > > * It creates potential interoperability problems; e.g. if my > copy of the MOF Model has different IDL mapping Tags to yours, > my MODL compiler may not be able to talk to your MOF repository. > [You could address this by making the IDL mapping Tags part of > the published meta-model ... but that doesn't feel right.] > > * It makes life harder for a client program that uses DII to > access an M2-level repository. [OK ... this is a bit far > fetched.] > > * It makes interoperability between MOF V1.3 and MOF V1.4 > compliant products problematical. > >I'm not against changes in the IDL mapping. But before we start >down this "slippery slope", we need to >>fully<< understand the >consequences. > >-- Steve > ============================= David S. Frankel Chief Scientist Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax =============================