Issue 7594: change ETF::Profile::marshal(), ETF::Factories::demarshal_profile() methods (etf-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: The issue revolves around the change to the ETF::Profile::marshal() and ETF::Factories::demarshal_profile() methods that occurred some time between the previous spec I'd seen (maybe last summer ?) and 04-01-04. Responsibility for separation of the AddressProfile data from the object key and tagged components in a IOP::TaggedProfile's data has moved from belonging to the Plug-in to the ORB. A similar shift has occurred when marshalling the ETF::Profile into a TaggedProfile. This is unworkable. An IIOP TaggedComponent's data is enclosed in a single encapsulation - there is no indication of the length of the AddressProfile data that the ORB could use to "perform any prior “unmarshaling” of the full Profile to access the address section for any plug-in" (as required in section 7.6.1 of the spec). A similar problem will exist when the Profile tries to compose AddressProfile bytes for the ORB to marshal. In IIOP the endianness of data items encoded within the AddressProfile is expected to be in accordance with that of the main encapsulation of the TaggedProfile. If the Profile is not creating the encapsulation it cannot know what this will be. It could maybe wing it with machine endianness but that's hardly satisfactory. Another highly significant, issue results from the removal of the capability of a plug-in to access TaggedComponents when a demarshalling or to add TaggedComponents to a TaggedProfile when marshalling. I think Steve Osselton may already have raised this in response to comments from Andre Spiegel of the JacORB project who has been an early adopter of a previous draft of the spec. Within IIOP there are a number of TaggedComponents that are relevant to characterising particular endpoints in an object reference. The SSL endpoint and supported modes tags and the alternate IIOP address tags are obvious examples. I am of the opinion that the signature of the marshal / demarshal methods needs to be changed to something like: void Profile::marshal(out sequence<octet> profile_data, in sequence<octet> object_key, in IOP::TaggedComponentSeq components); The out 'profile_data' parameter being the encapsulated TaggedProfile data, 'components' being the TaggedComponents the ORB wishes to see encoded in the object reference (to which the Profile may add transport specific components if it wishes). In earlier specs the object key was set on a profile prior to marshalling - this made a profile specific to a single object rather than an endpoint and presumably resulted in the requirement that the Listener endpoint attribute accessor return a copy of the Profile. If the object_key is passed in / received out by the ORB when marshalling / demarshalling then this requirement could be removed as the Profile's state would not be modified*. The corresponding demarshal operation would be: Profile demarshal_profile(in sequence<octet> profile_data, out sequence <octet> object_key, out IOP::TaggedComponentSeq components); * Incidentally I think this requirement could already be removed at 04-01-04 as there now exist no methods on the Profile interface that permit modification of its state. Resolution: Revised Text: Actions taken: July 7, 2004: received issue Discussion: change to ETF::Profile::marshal() and ETF::Factories::demarshal_profile() methods End of Annotations:===== te: Wed, 07 Jul 2004 11:32:06 +0100 From: Simon McQueen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us To: etf-ftf@omg.org Subject: Re: Extensible transport framework - 04-01-04 Hi Victor and Andreas, On 06/07/2004 18:23, Victor Giddings wrote: At 06:04 PM 7/6/2004 +0100, Simon McQueen wrote: On 06/07/2004 17:48, Victor Giddings wrote: [...] OK - thanks very much. I believe that with the spec as it stands in 04-01-04 it will be impossible to write a conforming implementation for IIOP or any other transport that relies on an IIOP style TaggedProfile. Before I potentially waste the lists time explaining why I think this is the case could the FTF let me know whether this is either already known or if it is something that would even qualify as a problem - maybe the spec intends to only be applicable to plugging in 'new' transports which will have to encapsulate their profile data differently in order to conform to the spec ? I don't think we ever had a discussion about this specific aspect of scope. My first reaction is that we should be able to define an IIOP plugin using ETF. Of course, that's an opinion based on no knowledge of your problem. I think you should submit this. Ok. Here goes. The issue revolves around the change to the ETF::Profile::marshal() and ETF::Factories::demarshal_profile() methods that occurred some time between the previous spec I'd seen (maybe last summer ?) and 04-01-04. Responsibility for separation of the AddressProfile data from the object key and tagged components in a IOP::TaggedProfile's data has moved from belonging to the Plug-in to the ORB. A similar shift has occurred when marshalling the ETF::Profile into a TaggedProfile. This is unworkable. An IIOP TaggedComponent's data is enclosed in a single encapsulation - there is no indication of the length of the AddressProfile data that the ORB could use to "perform any prior .unmarshaling. of the full Profile to access the address section for any plug-in" (as required in section 7.6.1 of the spec). A similar problem will exist when the Profile tries to compose AddressProfile bytes for the ORB to marshal. In IIOP the endianness of data items encoded within the AddressProfile is expected to be in accordance with that of the main encapsulation of the TaggedProfile. If the Profile is not creating the encapsulation it cannot know what this will be. It could maybe wing it with machine endianness but that's hardly satisfactory. Another highly significant, issue results from the removal of the capability of a plug-in to access TaggedComponents when a demarshalling or to add TaggedComponents to a TaggedProfile when marshalling. I think Steve Osselton may already have raised this in response to comments from Andre Spiegel of the JacORB project who has been an early adopter of a previous draft of the spec. Within IIOP there are a number of TaggedComponents that are relevant to characterising particular endpoints in an object reference. The SSL endpoint and supported modes tags and the alternate IIOP address tags are obvious examples. I am of the opinion that the signature of the marshal / demarshal methods needs to be changed to something like: void Profile::marshal(out sequence profile_data, in sequence object_key, in IOP::TaggedComponentSeq components); The out 'profile_data' parameter being the encapsulated TaggedProfile data, 'components' being the TaggedComponents the ORB wishes to see encoded in the object reference (to which the Profile may add transport specific components if it wishes). In earlier specs the object key was set on a profile prior to marshalling - this made a profile specific to a single object rather than an endpoint and presumably resulted in the requirement that the Listener endpoint attribute accessor return a copy of the Profile. If the object_key is passed in / received out by the ORB when marshalling / demarshalling then this requirement could be removed as the Profile's state would not be modified*. The corresponding demarshal operation would be: Profile demarshal_profile(in sequence profile_data, out sequence object_key, out IOP::TaggedComponentSeq components); * Incidentally I think this requirement could already be removed at 04-01-04 as there now exist no methods on the Profile interface that permit modification of its state. Cheers, -- Simon McQueen sm@prismtechnologies.com OpenFusion Total CORBA Solution Team www.prismtechnologies.com