Issue 7640: section 6.3.3, p.31, example IDL (mof2idl-ftf) Source: Vanderbilt University (Mr. Jeff Parsons, j.parsons@vanderbilt.edu) Nature: Uncategorized Issue Severity: Summary: section 6.3.3, p.31, example IDL The operations shown in the example for mapping of associations don't seem to gibe with the operations described section 7.6.3, pp.59-61. The CCM version of the mapping has components supporting abstract interfaces. There is some discussion where I work about whether or not this will have dire consequences. Such a case was throwing an error in our IDL compiler - someone must have thought it was a no-no. For the record, it seems ok to me for components to do this, but I wanted to get some more input on the matter. I guess it boils down to the question of whether it would ever be necessary to narrow to a component's supported interface, or to pass one over the wire as a CORBA::Object. Resolution: Revised Text: Resolution: This issue addresses a "forgot-to-change" bug in the final submission document. Revised Text: Change the example IDL to: module MyPackage { abstract interface ACommon : MOFObject {}; abstract interface BCommon : MOFObject {}; struct ABLink { ACommon the_a; BCommon the_b; }; typedef sequence < ABLink > ABLinkSet; abstract interface ABCommon : MOFObject { ABLinkSetIterator all_ab_links() raises (MofError); void create_link_in_ab( in ABLink new_link ) raises (MofError); boolean link_exists( in ABLink link ) raises (MofError); void remove_link( in ABLink link ) raises (MofError, NotFound); BCommon linked_objects_the_a( in A the_a ) raises (MofError); ACommon linked_objects_the_b( in B the_b ) raises (MofError); }; valuetype ABState : truncatable MOFState supports ABCommon { private ABLinkSet ab_links; }; component AB supports ABCommon { attribute ABState ab_state; }; }; Actions taken: August 19, 2004: received issue August 1, 2005: closed issue Discussion: End of Annotations:===== ubject: mapping questions Date: Thu, 19 Aug 2004 12:14:48 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mapping questions Thread-Index: AcSGEAfpYhJY+XFITWinW6OkBAEQEQ== From: "Jeff Parsons" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JHRelj029185 Hi, I understand that there will be some changes to the mapping in the finalization process. However, I'm starting work on a MOF model repository based on the IDL mapping (CMOF, CCM version) so it would be great if I could at least get a sense of where things might be headed. I'm sure I'll have a long list of questions before this project is done, but here are a few to start with: (All the following questions refer to ptc/04-07-01) section 6.3.3, p.31, example IDL The operations shown in the example for mapping of associations don't seem to gibe with the operations described section 7.6.3, pp.59-61. The CCM version of the mapping has components supporting abstract interfaces. There is some discussion where I work about whether or not this will have dire consequences. Such a case was throwing an error in our IDL compiler - someone must have thought it was a no-no. For the record, it seems ok to me for components to do this, but I wanted to get some more input on the matter. I guess it boils down to the question of whether it would ever be necessary to narrow to a component's supported interface, or to pass one over the wire as a CORBA::Object. thanks, This issue # 7640 >> >section 6.3.3, p.31, example IDL > The operations shown in the example for mapping of > associations don't seem to gibe with the operations > described section 7.6.3, pp.59-61. > Good issue. The example IDL comes from a previous version of the document, wherefore the operations described in section 7.6.3 are normative (In general, section 7 contains the more up-to-date sections of the mapping). > >The CCM version of the mapping has components supporting abstract >interfaces. There is some discussion where I work about whether or not this >will have dire consequences. Such a case was throwing an error in our IDL >compiler - someone must have thought it was a no-no. For the record, it >seems ok to me for components to do this, but I wanted to get some more >input on the matter. I guess it boils down to the question of whether it >would ever be necessary to narrow to a component's supported interface, or >to pass one over the wire as a CORBA::Object. Well, this is worth a discussion, because the CORBA3.x spec does not make any statement about using abstract interfaces in conjunction with components. We need to align this fundamental issue with the CCM spec, but since this will take more time, here is my first appraisement of the situation: >From the way of not capturing abstract interfaces and other statements in the spec, me (and my colleagues) draw the following conclusions for CCM components: (1) A component can support abstract interfaces (2) A component can provide abstract interfaces (3) A component can use abstract interfaces To (1): This shouldn't be a problem, because in most cases components will >provide< interfaces and do not >support< them (except the common interfaces). We see no conceptual problem, because at least from the derived equivalent IDL interface point of view there is no clash with the IDL spec. To (2): Even Object is allowed to be provided by a component. Furthermore, the standard allows to provide (so to say: sneaking) a reference to a more derived interfaces as declared by the facet. Conceptually, the inheritance of the equivalent IDL is - again - no problem. Further, it is in a way sound that the interface is no longer "abstract" in the sense that it cannot "live" for itself, since it is surrounded by a component. To (3): Usage of abstract interface-types makes sense, since components are usual clients of other interfaces interfaces. If you have do not agree with me, let me know. I'll try to figure out whether our view on the CCM spec as outlined is correct or not. Kind regards, Subject: RE: issues 7639 - 7640 -- abstract interfaces and components Date: Fri, 27 Aug 2004 11:44:42 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issues 7639 - 7640 -- abstract interfaces and components Thread-Index: AcSJHFO1XOHAdPyUTwWdT/X86v111QDNtJvA From: "Jeff Parsons" To: "Michael Soden" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7RGwV1U029618 Hi, > -----Original Message----- > From: Michael Soden [mailto:soden@fokus.fraunhofer.de] > Sent: Monday, August 23, 2004 9:20 AM > To: Jeff Parsons > Cc: mof2idl-ftf@omg.org > Subject: Re: issues 7639 - 7640 -- abstract interfaces and components > > > Hi Jeff, > > sorry for answering your questions/issues that late, but I've been on > vacations for three weeks and my eMail stack is rather high;) > > First of all, I'm happy that someone can give us feedback, > since our group > is rather small and only a few people seems to be interested > in what we are > doing - so I appreciate every comment, remark, bug you can report. > > To your issues: > > > ===================================================== > > This is issue # 7639 > > > >section 7.3, p.44, example IDL > > > > forward declared exception (MofError) > > > > For now I have instead forward declared MOFObject so I can > > fully define MofError before the full definition of > MOFObject. > > > > > > abstract valuetype (MOFState) has a state member > > > > For now I have removed the 'abstract' qualifier. > > In principle, the IDL in ad/04-01-17 (extra IDL sources for > MOF2CMM) should > be correct and compile-able (we tested it with the QEDO (www.qedo.org > OpenSource CCM implementation). > > > > >===================================================== > > > >This issue # 7640 > >> > >section 6.3.3, p.31, example IDL > > The operations shown in the example for mapping of > > associations don't seem to gibe with the operations > > described section 7.6.3, pp.59-61. > > > > Good issue. The example IDL comes from a previous version of > the document, > wherefore the operations described in section 7.6.3 are normative (In > general, section 7 contains the more up-to-date sections of > the mapping). > > > > >The CCM version of the mapping has components supporting abstract > >interfaces. There is some discussion where I work about > whether or not this > >will have dire consequences. Such a case was throwing an > error in our IDL > >compiler - someone must have thought it was a no-no. For the > record, it > >seems ok to me for components to do this, but I wanted to > get some more > >input on the matter. I guess it boils down to the question > of whether it > >would ever be necessary to narrow to a component's supported > interface, or > >to pass one over the wire as a CORBA::Object. > > Well, this is worth a discussion, because the CORBA3.x spec > does not make > any statement about using abstract interfaces in conjunction with > components. We need to align this fundamental issue with the > CCM spec, but > since this will take more time, here is my first appraisement of the > situation: > > From the way of not capturing abstract interfaces and other > statements in > the spec, me (and my colleagues) draw the following > conclusions for CCM > components: > > (1) A component can support abstract interfaces > (2) A component can provide abstract interfaces > (3) A component can use abstract interfaces > > To (1): This shouldn't be a problem, because in most cases > components will > >provide< interfaces and do not >support< them (except the common > interfaces). We see no conceptual problem, because at least > from the derived > equivalent IDL interface point of view there is no clash with > the IDL spec. > > To (2): Even Object is allowed to be provided by a component. > Furthermore, > the standard allows to provide (so to say: sneaking) a > reference to a more > derived interfaces as declared by the facet. Conceptually, > the inheritance > of the equivalent IDL is - again - no problem. Further, it is > in a way sound > that the interface is no longer "abstract" in the sense that it cannot > "live" for itself, since it is surrounded by a component. Number 2 might be tricky. How does the standard allow a more derived interface to 'sneak' in? It seems the Navigation operations will be a problem, since they would usually be implemented in the (generated) servant. If the facet interface was actually a more derived one than in the IDL, wouldn't the servant then have to delegate these to the executor instead? Although I guess the CIDL compiler could be smart enough to figure that out for each facet. The problems don't end there, however. How would the client (who knows only what's in the IDL, or less) know what to narrow to when it gets one or more CORBA::Objects in a reply to a Navigation operation? > > To (3): Usage of abstract interface-types makes sense, since > components are > usual clients of other interfaces interfaces. > > If you have do not agree with me, let me know. I'll try to figure out > whether our view on the CCM spec as outlined is correct or not. It seems right to me, modulo the questions I have about (2) mentioned above. Jeff