Issue 5576: 69.3 AssemblyFactory Interface (components-ftf) Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com) Nature: Uncategorized Issue Severity: Summary: Suggested changes to the AssemblyFactory interface. AssemblyFactory Issues. 1. Ease of use Issue. After the create operation is performed, one is force to call lookup to get the Assembly that just got just created. Why is a cookie returned by the create operation instead of an Assembly? Is the reason because of security? If the interface were more open this would still allow a secure implementation to be implemented. Suggested change is to return an Assembly instead of a Cookie. Change destroy operation to take in an Assembly parameter instead of Cookie. Change lookup operation to take in a name parameter. These changes make it consistent with the other CCM interfaces, such as Container, KeyLessCCMHome, ComponentServer, and ServerActivator. 2. Multiple users Issue. For multiple users, how does a client know what assemblies are created. Add a get_assemblies operation that returns a list of assemblies. These changes make it consistent with other CCM interfaces, such as Container, ComponentServer, and ServerActivator. 3. User-friendly identifier for Assembly Instance issue. Add an input name parameter that can be assigned to the Assembly instance that gets created. Add a read only name or label attribute to the Assembly interface. Resolution: Revised Text: Actions taken: August 8, 2002: received issue Discussion: Resolution: None as this is deferred to the final report of the Components 1.1 RTF. Revised Text: None as this is deferred to the final report of the Components 1.1 RTF End of Annotations:===== From: Gerald_L_Bickle@raytheon.com Subject: AssemblyFactory Interface Changes To: issues@omg.org, components-rtf@omg.org Cc: "Mike McClimens" , "Smith, Jeff" , Edwin.Wrench@ITT.COM, mike.mcclimens@saalt.army.mil, "Mike McClimens" , David Fitkin , jeffrey.olynick@baesystems.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Date: Thu, 8 Aug 2002 16:40:54 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.8 |June 18, 2001) at 08/08/2002 04:40:53 PM Document ptc/2001-11-03, CORBA Component Model ************************ Title : 69.3 AssemblyFactory Interface Suggested changes to the AssemblyFactory interface. AssemblyFactory Issues. 1. Ease of use Issue. After the create operation is performed, one is force to call lookup to get the Assembly that just got just created. Why is a cookie returned by the create operation instead of an Assembly? Is the reason because of security? If the interface were more open this would still allow a secure implementation to be implemented. Suggested change is to return an Assembly instead of a Cookie. Change destroy operation to take in an Assembly parameter instead of Cookie. Change lookup operation to take in a name parameter. These changes make it consistent with the other CCM interfaces, such as Container, KeyLessCCMHome, ComponentServer, and ServerActivator. 2. Multiple users Issue. For multiple users, how does a client know what assemblies are created. Add a get_assemblies operation that returns a list of assemblies. These changes make it consistent with other CCM interfaces, such as Container, ComponentServer, and ServerActivator. 3. User-friendly identifier for Assembly Instance issue. Add an input name parameter that can be assigned to the Assembly instance that gets created. Add a read only name or label attribute to the Assembly interface. X-Sender: evans@mail.cpi.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Aug 2002 18:35:04 -0400 To: Gerald_L_Bickle@raytheon.com, issues@omg.org, components-rtf@omg.org From: "J. Scott Evans" Subject: Re: AssemblyFactory Interface Changes Hi Gerald, I've been dissatisfied with the AssemblyFactory API as well. I'd like to suggest a slight modification of your approach, however. Why not reverse the roles of the Cookie creation so that the client must create the Cookie and pass the Cookie to the create operation? I think a Cookie is a slightly better way to encapsulate an identifier for an Assembly object than a named attribute (a Cookie can contain this identifier) and the lookup operation can remain. In my applications it could be a considerable time between building of an Assembly and tearing down of an Assembly so I can persist the Cookie for later use and shut down the client and then later restore the Cookie, lookup the Assembly, and destroy it. So, we can replace The AssemblyFactory interface is used to create Assembly objects. A single AssemblyFactory object must be present on each host where Assembly objects are to be created. At least, one AssemblyFactory object must be present on a deployment domain. exception InvalidLocation { }; exception InvalidAssembly { }; interface AssemblyFactory { Cookie create(in string Location assembly_loc) raises (InvalidLocation, CreateFailure); Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Cookie c) raises (InvalidAssembly, RemoveFailure); }; create The create operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location for of the an assembly descriptor package and returns a Cookie that may be used to reference the assembly later on. The Cookie is the same as specified in Section 61.5.2.4, "Cookie type," on page 61-233, of this document. The operation raises an InvalidLocation exception if the assembly descriptor package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. etc, etc, with exception InvalidLocation { }; exception InvalidAssembly { }; typedef sequence Assemblies; interface AssemblyFactory { Assembly create( in string Location assembly_loc, in Cookie identifier) raises (InvalidLocation, CreateFailure); Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Assembly the_assembly) raises (InvalidAssembly, RemoveFailure); Assemblies get_assemblies(); }; create The create operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location for of the an assembly descriptor package and a Cookie that identifies the Assembly object and returns an Assembly object. The Cookie is the same as specified in Section 61.5.2.4, "Cookie type," on page 61-233, of this document. The operation raises an InvalidLocation exception if the assembly descriptor package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. destroy The destroy operation destroys the input assembly. If the assembly is active it will first tear down the assembly. The operation returns true if the assembly was successfully destroyed, false otherwise. The operation raises an InvalidAssembly exception if the Assembly does not reference an existing assembly that was previously created by this AssemblyFactory. The operation raises a RemoveFailure exception if the Assembly was not properly and completely removed for any internal reasons. get_assemblies The get_assemblies operation returns a sequence of all Assembly objects created by this AssemblyFactory. What do you think? Scott At 04:40 PM 8/8/02 -0500, Gerald_L_Bickle@raytheon.com wrote: Document ptc/2001-11-03, CORBA Component Model ************************ Title : 69.3 AssemblyFactory Interface Suggested changes to the AssemblyFactory interface. AssemblyFactory Issues. 1. Ease of use Issue. After the create operation is performed, one is force to call lookup to get the Assembly that just got just created. Why is a cookie returned by the create operation instead of an Assembly? Is the reason because of security? If the interface were more open this would still allow a secure implementation to be implemented. Suggested change is to return an Assembly instead of a Cookie. Change destroy operation to take in an Assembly parameter instead of Cookie. Change lookup operation to take in a name parameter. These changes make it consistent with the other CCM interfaces, such as Container, KeyLessCCMHome, ComponentServer, and ServerActivator. 2. Multiple users Issue. For multiple users, how does a client know what assemblies are created. Add a get_assemblies operation that returns a list of assemblies. These changes make it consistent with other CCM interfaces, hme User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020517 X-Accept-Language: de-de, en-us To: Gerald_L_Bickle@raytheon.com CC: Bertram Neubauer , components-rtf@omg.org, Frank Stoinski , "Smith, Jeff" , Edwin.Wrench@itt.com, mike.mcclimens@saalt.army.mil, David Fitkin , jeffrey.olynick@baesystems.com Subject: Re: AssemblyFactory Interface Changes Gerald_L_Bickle@raytheon.com wrote: Document ptc/2001-11-03, CORBA Component Model ************************ Title : 69.3 AssemblyFactory Interface Suggested changes to the AssemblyFactory interface. AssemblyFactory Issues. 1. Ease of use Issue. After the create operation is performed, one is force to call lookup to get the Assembly that just got just created. Why is a cookie returned by the create operation instead of an Assembly? Is the reason because of security? If the interface were more open this would still allow a secure implementation to be implemented. Suggested change is to return an Assembly instead of a Cookie. Change destroy operation to take in an Assembly parameter instead of Cookie. Change lookup operation to take in a name parameter. These changes make it consistent with the other CCM interfaces, such as Container, KeyLessCCMHome, ComponentServer, and ServerActivator. Please remeber that it is ture if two object refrences are ident. they refer to the same object but if two object refernces are not idet. it dosen't mean they refer to distinct object in CORBA. This basicaly mean you have no identity in CORBA. For the pair of operation like create/destroy it is essentail to have identity. For that reason we normaly use cookies in interfaces, they are one way for obtaining identity. 2. Multiple users Issue. For multiple users, how does a client know what assemblies are created. Add a get_assemblies operation that returns a list of assemblies. These changes make it consistent with other CCM interfaces, such as Container, ComponentServer, and ServerActivator. It looks like there is no navigation at the AssemblyFactory, question is who will use it and for what reason. 3. User-friendly identifier for Assembly Instance issue. Add an input name parameter that can be assigned to the Assembly instance that gets created. Add a read only name or label attribute to the Assembly hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> interface. The question is: in which context are the names "unique". So what is if two clients like to use the same name ? If clients like to have names for Assemblies they could easy implement an dictionary, which maps names to cookies. Regards, Harald -- <<<< Harald Bsuch as Container, ComponentServer, and ServerActivator. 3. User-friendly identifier for Assembly Instance issue. Add an input name parameter that can be assigned to the Assembly instance that gets created. Add a read only name or label attribute to the Assembly interface. Date: Fri, 09 Aug 2002 13:54:56 +0200 From: Harald B From: Gerald_L_Bickle@raytheon.com Subject: Re: AssemblyFactory Interface Changes To: "J. Scott Evans" Cc: components-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Date: Fri, 9 Aug 2002 07:04:13 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.8 |June 18, 2001) at 08/09/2002 07:04:14 AM Using Cookie as an input parameter instead of string is okay with me. The suggested AssemblyFactory IDL changes are okay too. Jerry "J. Scott Evans" To: Gerald L Bickle/US/Raytheon@HDC, issues@omg.org, cc: Subject: Re: AssemblyFactory Interface Changes 08/08/2002 05:35 PM Hi Gerald, I've been dissatisfied with the AssemblyFactory API as well. I'd like to suggest a slight modification of your approach, however. Why not reverse the roles of the Cookie creation so that the client must create the Cookie and pass the Cookie to the create operation? I think a Cookie is a slightly better way to encapsulate an identifier for an Assembly object than a named attribute (a Cookie can contain this identifier) and the lookup operation can remain. In my applications it could be a considerable time between building of an Assembly and tearing down of an Assembly so I can persist the Cookie for later use and shut down the client and then later restore the Cookie, lookup the Assembly, and destroy it. So, we can replace The AssemblyFactory interface is used to create Assembly objects. A single AssemblyFactory object must be present on each host where Assembly objects are to be created. At least, one AssemblyFactory object must be present on a deployment domain. exception InvalidLocation { }; exception InvalidAssembly { }; interface AssemblyFactory { Cookie create(in string Location assembly_loc) raises (InvalidLocation, CreateFailure); Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Cookie c) raises (InvalidAssembly, RemoveFailure); }; create The create operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location for of the an assembly descriptor package and returns a Cookie that may be used to reference the assembly later on. The Cookie is the same as specified in Section 61.5.2.4, "Cookie type," on page 61-233, of this document. The operation raises an InvalidLocation exception if the assembly descriptor package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. etc, etc, with exception InvalidLocation { }; exception InvalidAssembly { }; typedef sequence Assemblies; interface AssemblyFactory { Assembly create( in string Location assembly_loc, in Cookie identifier) raises (InvalidLocation, CreateFailure); Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Assembly the_assembly) raises (InvalidAssembly, RemoveFailure); Assemblies get_assemblies(); }; create The create operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location for of the an assembly descriptor package and a Cookie that identifies the Assembly object and returns an Assembly object. The Cookie is the same as specified in Section 61.5.2.4, "Cookie type," on page 61-233, of this document. The operation raises an InvalidLocation exception if the assembly descriptor package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. destroy The destroy operation destroys the input assembly. If the assembly is active it will first tear down the assembly. The operation returns true if the assembly was successfully destroyed, false otherwise. The operation raises an InvalidAssembly exception if the Assembly does not reference an existing assembly that was previously created by this AssemblyFactory. The operation raises a RemoveFailure exception if the Assembly was not properly and completely removed for any internal reasons. get_assemblies The get_assemblies operation returns a sequence of all Assembly objects created by this AssemblyFactory. What do you think? Scott At 04:40 PM 8/8/02 -0500, Gerald_L_Bickle@raytheon.com wrote: >Document ptc/2001-11-03, CORBA Component Model >************************ > >Title : 69.3 AssemblyFactory Interface >Suggested changes to the AssemblyFactory interface. > >AssemblyFactory Issues. > >1. Ease of use Issue. After the create operation is performed, one is >force to call lookup to get the Assembly that just got just created. Why is >a cookie returned by the create operation instead of an Assembly? Is the >reason because of security? If the interface were more open this would >still allow a secure implementation to be implemented. > Suggested change is to return an Assembly instead of a Cookie. Change > destroy operation to take in an Assembly parameter instead of Cookie. > Change lookup operation to take in a name parameter. These changes > make it consistent with the other CCM interfaces, such as hme User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020517 X-Accept-Language: de-de, en-us To: components-rtf@omg.org Subject: Re: AssemblyFactory Interface Changes Gerald_L_Bickle@raytheon.com wrote: Hi Using Cookie as an input parameter instead of string is okay with me. The suggested AssemblyFactory IDL changes are okay too. The problem with client side cookies and names are the same, how did you provide identity to Assemblies in this case ? So one solution for make create more handy is: have an additional out parameter for returning the Assembly reference. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> Please have in minde that we first have to provide the functionality and semantic and second handy interfaces. Regards, Harald -- <<<< Harald BContainer, > KeyLessCCMHome, ComponentServer, and ServerActivator. >2. Multiple users Issue. For multiple users, how does a client know what >assemblies are created. Add a get_assemblies operation that returns a list >of assemblies. These changes make it consistent with other CCM interfaces, >such as Container, ComponentServer, and ServerActivator. >3. User-friendly identifier for Assembly Instance issue. Add an input >name parameter that can be assigned to the Assembly instance that hme , components-rtf@omg.org From: "J. Scott Evans" hme wrote: Gerald_L_Bickle@raytheon.com wrote: Hi Using Cookie as an input parameter instead of string is okay with me. The suggested AssemblyFactory IDL changes are okay too. The problem with client side cookies and names are the same, how did you provide identity to Assemblies in this case ? This is no more of a problem then a client creating a Key for an Entity component. The Entity Key is entirely client-side oriented. An input Cookie can easily be associated with an Assembly object implementation and the AssemblyFactory implementation can use this association to locate an Assembly object using a Cookie. I don't quite see why you believe there is any ambiguity here. So one solution for make create more handy is: have an additional out parameter for returning the Assembly reference. This would work also and preserve server-side Cookie management. I'd be interested if you can present an argument for why server-side Cookie management is intrinsically better than client-side Cookie management. Because it makes your life easier as a vendor? ;^) In the present case, I argue that client side deployment tools might prefer more control over the identity label associated with an Assembly simply for display purposes. A randomly generated octet sequence produced by a server is not very helpful in a graphical display tool that a user has previously used to create an Assembly, IMHO. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> Scott Please have in minde that we first have to provide the functionality and semantic and second handy interfaces. Regards, Harald -- <<<< Harald BSubject: Re: AssemblyFactory Interface Changes X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g79FTWX22672 Hi Harald, At 04:37 PM 8/9/02 +0200, Harald Bgets >created. Add a read only name or label attribute to the Assembly interface. Date: Fri, 09 Aug 2002 16:37:23 +0200 From: Harald B hme User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020517 hme wrote: Gerald_L_Bickle@raytheon.com wrote: Hi Using Cookie as an input parameter instead of string is okay with me. The suggested AssemblyFactory IDL changes are okay too. The problem with client side cookies and names are the same, how did you provide identity to Assemblies in this case ? This is no more of a problem then a client creating a Key for an Entity component. The Entity Key is entirely client-side oriented. An input Cookie can easily be associated with an Assembly object implementation and the AssemblyFactory implementation can use this association to locate an Assembly object using a Cookie. I don't quite see why you believe there is any ambiguity here. This is ok for Entity component, becaus it is explicitly stated in the IDL that this is a key. Values for keys are well defined by the types and the semantic is clear; same value (subvalues) for a key identifies the component. Assemblies have no keys and the AssemblyFactory is now free to has an own semantic for all the bytes in the cookie, which may server best for the own functionality. If the Client select a cookie this is not possible. More over what happens if two clients select the same cookie, name or ... So one solution for make create more handy is: have an additional out parameter for returning the Assembly reference. This would work also and preserve server-side Cookie management. I'd be interested if you can present an argument for why server-side Cookie management is intrinsically better than client-side Cookie management. Because it makes your life easier as a vendor? ;^) In the present case, I argue that client side deployment tools might prefer more control over the identity label associated with an Assembly simply for display purposes. A randomly generated octet sequence produced by a server is not very helpful in a graphical display tool that a user has previously used to create an Assembly, IMHO. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> s.o. Even if the client provides the cookie and we dosen't allow double use at which point in time we can reuse the same cookie ? Regards, Harald -- <<<< Harald BX-Accept-Language: de-de, en-us To: components-rtf@omg.org Subject: Re: AssemblyFactory Interface Changes Hi Scott J. Scott Evans wrote: Hi Harald, At 04:37 PM 8/9/02 +0200, Harald B Date: Fri, 09 Aug 2002 18:35:53 +0200 hme , components-rtf@omg.org From: "J. Scott Evans" Subject: Re: AssemblyFactory Interface Changes X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g79H0cX24898 Hi Harald, You raise interesting arguments although I don't happen to subscribe to all of them ;) In the interest of a timely compromise how about the following changes to Gerald's and my original posts? exception InvalidLocation { }; exception InvalidAssembly { }; typedef sequence Assemblies; interface AssemblyFactory { Assembly create( in string Location assembly_loc, out Cookie c) raises (InvalidLocation, CreateFailure); Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Assembly the_assembly) raises (InvalidAssembly, RemoveFailure); Assemblies get_assemblies(); }; create The create operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location of the assembly package and has an out parameter of type Cookie that identifies the Assembly object and returns an Assembly object. The Cookie is the same as specified in Section 61.5.2.4, From: Harald B X-Sender: evans@mail.cpi.com X-Mailer: Windows QUALCOMM on page 61-233, of this document. The operation raises an InvalidLocation exception if the assembly descriptor package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. destroy The destroy operation destroys the input assembly. If the assembly is active it will first tear down the assembly. The operation returns true if the assembly was successfully destroyed, false otherwise. The operation raises an InvalidAssembly exception if the Assembly does not reference an existing assembly that was previously created by this AssemblyFactory. The operation raises a RemoveFailure exception if the Assembly was not properly and completely removed for any internal reasons. get_assemblies The get_assemblies operation returns a sequence of all Assembly objects created by this AssemblyFactory. hme wrote: Gerald_L_Bickle@raytheon.com wrote: Hi Using Cookie as an input parameter instead of string is okay with me. The suggested AssemblyFactory IDL changes are okay too. The problem with client side cookies and names are the same, how did you provide identity to Assemblies in this case ? This is no more of a problem then a client creating a Key for an Entity component. The Entity Key is entirely client-side oriented. An input Cookie can easily be associated with an Assembly object implementation and the AssemblyFactory implementation can use this association to locate an Assembly object using a Cookie. I don't quite see why you believe there is any ambiguity here. This is ok for Entity component, becaus it is explicitly stated in the IDL that this is a key. Values for keys are well defined by the types and the semantic is clear; same value (subvalues) for a key identifies the component. Assemblies have no keys and the AssemblyFactory is now free to has an own semantic for all the bytes in the cookie, which may server best for the own functionality. If the Client select a cookie this is not possible. More over what happens if two clients select the same cookie, name or ... So one solution for make create more handy is: have an additional out parameter for returning the Assembly reference. This would work also and preserve server-side Cookie management. I'd be interested if you can present an argument for why server-side Cookie management is intrinsically better than client-side Cookie management. Because it makes your life easier as a vendor? ;^) In the present case, I argue that client side deployment tools might prefer more control over the identity label associated with an Assembly simply for display purposes. A randomly generated octet sequence produced by a server is not very helpful in a graphical display tool that a user has previously used to create an Assembly, IMHO. s.o. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> Even if the client provides the cookie and we dosen't allow double use at which point in time we can reuse the same cookie ? Regards, Harald -- <<<< Harald B (other operation descriptions remain the same). Here, the focus is on the Assembly object rather than the Cookie but hme wrote: Hi Scott J. Scott Evans wrote: Hi Harald, At 04:37 PM 8/9/02 +0200, Harald Bthe Cookie is available for later use if necessary. If we wish to add some label to an Assembly object and/or add an operation to get a Cookie from an Assembly object we can discuss that in a separate thread. Scott At 06:35 PM 8/9/02 +0200, Harald BEudora Version 5.1 Date: Fri, 09 Aug 2002 13:06:05 -0400 To: Harald B From: Gerald_L_Bickle@raytheon.com Subject: Re: AssemblyFactory Interface Changes To: "Juergen Boldt" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Date: Fri, 9 Aug 2002 14:16:49 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.8 |June 18, 2001) at 08/09/2002 02:16:49 PM No this is still an issue. He agrees with my issue, but not the total solution. I agree with his suggested change to the submitted issue. Makes any sense? Jerry "Juergen Boldt" To: Gerald L Bickle/US/Raytheon@HDC Subject: Re: AssemblyFactory Interface Changes 08/09/2002 08:52 AM Jerry, so is this a non-issue? -Juergen At 07:04 AM 8/9/2002 -0500, you wrote: >Using Cookie as an input parameter instead of string is okay with me. >The suggested AssemblyFactory IDL changes are okay too. > >Jerry > > > > > "J. > Scott > > Evans" To: Gerald L > Bickle/US/Raytheon@HDC, issues@omg.org, > > > cc: > > Subject: Re: >AssemblyFactory > Interface Changes > 08/08/2002 > > 05:35 > PM > > > > > > > > > > > >Hi Gerald, > >I've been dissatisfied with the AssemblyFactory API as well. I'd >like to >suggest a slight modification of your approach, however. Why not >reverse >the roles of the Cookie creation so that the client must create the >Cookie >and pass the Cookie to the create operation? I think a Cookie is a >slightly better way to encapsulate an identifier for an Assembly >object >than a named attribute (a Cookie can contain this identifier) and the >lookup operation can remain. In my applications it could be a considerable >time between building of an Assembly and tearing down of an Assembly >so I >can persist the Cookie for later use and shut down the client and >then >later restore the Cookie, lookup the Assembly, and destroy it. So, we >can >replace > >The AssemblyFactory interface is used to create Assembly objects. A >single >AssemblyFactory object must be present on each host where Assembly >objects >are >to be created. At least, one AssemblyFactory object must be present >on a >deployment domain. > >exception InvalidLocation { }; >exception InvalidAssembly { }; > >interface AssemblyFactory { > Cookie create(in string Location assembly_loc) > raises (InvalidLocation, CreateFailure); > Assembly lookup(in Cookie c) > raises (InvalidAssembly); > boolean void destroy(in Cookie c) > raises (InvalidAssembly, RemoveFailure); >}; > >create >The create operation creates an Assembly object on the host on which >the >AssemblyFactory is located. It takes a string denoting the location >for of >the an >assembly descriptor package and returns a Cookie that may be used to >reference the >assembly later on. The Cookie is the same as specified in Section 61.5.2.4, >"Cookie >type," on page 61-233, of this document. The operation raises an >InvalidLocation >exception if the assembly descriptor package could not be found. The >operation raises >a CreateFailure exception if an Assembly object could not be created >for >internal >reasons such as insufficient resources. > >etc, etc, > >with > >exception InvalidLocation { }; >exception InvalidAssembly { }; > >typedef sequence Assemblies; > >interface AssemblyFactory { > Assembly create( > in string Location assembly_loc, > in Cookie identifier) > raises (InvalidLocation, CreateFailure); > Assembly lookup(in Cookie c) > raises (InvalidAssembly); > boolean void destroy(in Assembly the_assembly) > raises (InvalidAssembly, RemoveFailure); > Assemblies get_assemblies(); >}; > >create >The create operation creates an Assembly object on the host on which >the >AssemblyFactory is located. It takes a string denoting the location >for of >the an >assembly descriptor package and a Cookie that identifies the Assembly >object and >returns an Assembly object. The Cookie is the same as specified in >Section >61.5.2.4, >"Cookie type," on page 61-233, of this document. The operation raises >an >InvalidLocation >exception if the assembly descriptor package could not be found. The >operation raises >a CreateFailure exception if an Assembly object could not be created >for >internal >reasons such as insufficient resources. >destroy >The destroy operation destroys the input assembly. If the assembly is >active it will first tear >down the assembly. The operation returns true if the assembly was >successfully destroyed, >false otherwise. The operation raises an InvalidAssembly exception if >the >Assembly does >not reference an existing assembly that was previously created by >this >AssemblyFactory. The >operation raises a RemoveFailure exception if the Assembly was not properly >and completely >removed for any internal reasons. >get_assemblies >The get_assemblies operation returns a sequence of all Assembly >objects >created by >this AssemblyFactory. > >What do you think? > >Scott > >At 04:40 PM 8/8/02 -0500, Gerald_L_Bickle@raytheon.com wrote: > >Document ptc/2001-11-03, CORBA Component Model > >************************ > > > >Title : 69.3 AssemblyFactory Interface > >Suggested changes to the AssemblyFactory interface. > > > >AssemblyFactory Issues. > > > >1. Ease of use Issue. After the create operation is performed, >one is > >force to call lookup to get the Assembly that just got just >created. Why >is > >a cookie returned by the create operation instead of an Assembly? >Is the > >reason because of security? If the interface were more open this >would > >still allow a secure implementation to be implemented. > > Suggested change is to return an Assembly instead of a >Cookie. >Change > > destroy operation to take in an Assembly parameter instead of >Cookie. > > Change lookup operation to take in a name parameter. These >changes > > make it consistent with the other CCM interfaces, such as Container, > > KeyLessCCMHome, ComponentServer, and ServerActivator. > >2. Multiple users Issue. For multiple users, how does a client >know >what > >assemblies are created. Add a get_assemblies operation that returns >a list > >of assemblies. These changes make it consistent with other CCM interfaces, > >such as Container, ComponentServer, and ServerActivator. > >3. User-friendly identifier for Assembly Instance issue. Add an >input > >name parameter that can be assigned to the Assembly instance that >gets > >created. Add a read only name or label attribute to the Assembly >interface. ================================= Juergen Boldt Director, Member Services Object Management Group hme User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020517 X-Accept-Language: de-de, en-us To: components-rtf@omg.org Subject: Re: AssemblyFactory Interface Changes Hi Scott Please refer allway to ptc/01-11-03. J. Scott Evans wrote: Hi Harald, You raise interesting arguments although I don't happen to subscribe to all of them ;) In the interest of a timely compromise how about the following changes to Gerald's and my original posts? exception InvalidLocation { }; exception InvalidAssembly { }; typedef sequence Assemblies; interface AssemblyFactory { Assembly create( in string Location assembly_loc, out Cookie c) raises (InvalidLocation, CreateFailure); This should be: Cookie create(in Location assembly_loc, out Assembly new_assembly) raise(IncalidLocation, CreateFailure); Here we have to provide more informations about Location. The primary identity for the Assembly is still the cookie. Assembly lookup(in Cookie c) raises (InvalidAssembly); boolean void destroy(in Assembly the_assembly) raises (InvalidAssembly, RemoveFailure); void destroy(in Cookie the_assembly) raises(InvalidAssemvly,RemoveFailure); Here we use the primary identity for the Assembly. Please remeber that if you use bridges there is no identical object referenc, becaus each bridge will establish a mapping for the object references. Assemblies get_assemblies(); }; That is fine, but Assemblies has to be defined. It might be good as a sequence of valuetypes containig the cookie an the object referenc. Here, the focus is on the Assembly object rather than the Cookie but the Cookie is available for later use if necessary. If we wish to add some label to an Assembly object and/or add an operation to get a Cookie from an Assembly object we can discuss that in a separate thread. So again to focus on Assembly object references may be more handy for the user, but if you remove the semantic of primary identity hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> via cookies you will brake with some other parts in CORBA, where they are introduced for primary identity reasons. Change the parameter in destroy express this. Regrads, Harald PS: I'm will make compromises, but not for the identity issue. -- <<<< Harald B250 First Avenue, Suite 201 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Date: Mon, 12 Aug 2002 12:23:35 +0200 From: Harald B hme , components-rtf@omg.org Subject: Re: AssemblyFactory Interface Changes Doesn't the destroy operation still need the cookie since reference lifetimes can be shorter? I know other specs with this identity issue use the cookie/id to destroy even though the create operation returns the object as well as the cookie. (GenericFactory in Fault Tolerant CORBA, Unreliable Multicast, Data Parallel, etc.). A client-supplied (non-unique) label may still be useful as an input parameter that becomes an attribute of the assembly. Then a tool can retrieve assemblies (get_assemblies), and display such a label, without being the same client that created the assembly. So, I would add a creating-client-label string as an input and as an attribute, and change the destroy argument back to the cookie. The version of the spec I am looking at (01-11-03) doesn't have the boolean return value to destroy. It was struck out. Jim "J. Scott Evans" wrote: > Hi Harald, > > You raise interesting arguments although I don't happen to subscribe >to all > of them ;) In the interest of a timely compromise how about the >following > changes to Gerald's and my original posts? > > exception InvalidLocation { }; > exception InvalidAssembly { }; > > typedef sequence Assemblies; > > interface AssemblyFactory { > Assembly create( > in string Location assembly_loc, > out Cookie c) > raises (InvalidLocation, CreateFailure); > Assembly lookup(in Cookie c) > raises (InvalidAssembly); > boolean void destroy(in Assembly the_assembly) > raises (InvalidAssembly, RemoveFailure); > Assemblies get_assemblies(); > }; > > create > The create operation creates an Assembly object on the host on which >the > AssemblyFactory is located. It takes a string denoting the location >of the > assembly package and has an out parameter of type Cookie that >identifies the > Assembly object and returns an Assembly object. The Cookie is the >same as > specified in Section 61.5.2.4, X-Dreamscape-Track-Mars-A: hosth30.tachyon.net [63.119.199.30] X-Dreamscape-Track-Mars-B: Mon, 12 Aug 2002 08:39:08 -0400 (EDT) Date: Mon, 12 Aug 2002 07:42:39 -0400 From: Jim Kulp X-Mailer: Mozilla 4.{C-UDP; EBM-APPLE} 79C-CCK-MCD on page 61-233, of this > document. > The operation raises an InvalidLocation exception if the assembly descriptor > package could not be found. The operation raises a CreateFailure exception > if an Assembly object could not be created for internal reasons such as > insufficient > resources. > destroy > The destroy operation destroys the input assembly. If the assembly is > active it will first tear > down the assembly. The operation returns true if the assembly was > successfully destroyed, > false otherwise. The operation raises an InvalidAssembly exception if the > Assembly does > not reference an existing assembly that was previously created by this hme wrote: > >> > >>>Gerald_L_Bickle@raytheon.com wrote: > >>> > >>>Hi > >>> > >>>>Using Cookie as an input parameter instead of string is okay with me. > >>>>The suggested AssemblyFactory IDL changes are okay too. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>The problem with client side cookies and names are the same, > >>>how did you provide identity to Assemblies in this case ? > >> > >> > >>This is no more of a problem then a client creating a Key for an Entity > >>component. The Entity Key is entirely client-side oriented. > >>An input Cookie can easily be associated with an Assembly object > >>implementation and the AssemblyFactory implementation can use this > >>association to locate an Assembly object using a Cookie. I don't quite > >>see why you believe there is any ambiguity here. > > > >This is ok for Entity component, becaus it is explicitly stated in the IDL > >that this is a key. Values for keys are well defined by the types and the > >semantic > >is clear; same value (subvalues) for a key identifies the component. > >Assemblies have no keys and the AssemblyFactory is now free to has an own > >semantic > >for all the bytes in the cookie, which may server best for the own > >functionality. If the Client select a cookie this is not possible. More > >over what happens > >if two clients select the same cookie, name or ... > > > >> > >>>So one solution for make create more handy is: > >>>have an additional out parameter for returning the Assembly reference. > >> > >> > >>This would work also and preserve server-side Cookie management. I'd be > >>interested if you can present an argument for why server-side Cookie > >>management is intrinsically better than client-side Cookie > >>management. Because it makes your life easier as a vendor? ;^) In the > >>present case, I argue that client side deployment tools might prefer more > >>control over the identity label associated with an Assembly simply for > >>display purposes. A randomly generated octet sequence produced by a > >>server is not very helpful in a graphical display tool that a user has hme, Berlin 12489 >>>> > > <<<< Radickestr. 52 >>>> > > <<<< boehme@informatik.hu-berlin.de >>>> > >> >>previously used to create an Assembly, IMHO. > > > >s.o. > > > >Even if the client provides the cookie and we dosen't allow double use at > >which point in time we can reuse the same cookie ? > > > >Regards, > > Harald > > > >-- > > <<<< Harald B> AssemblyFactory. The > operation raises a RemoveFailure exception if the Assembly was not properly > and completely > removed for any internal reasons. > get_assemblies > The get_assemblies operation returns a sequence of all Assembly objects hme wrote: > >Hi Scott > > > >J. Scott Evans wrote: > > > >> > >>Hi Harald, > >> > >>At 04:37 PM 8/9/02 +0200, Harald B> created by > this AssemblyFactory. > > (other operation descriptions remain the same). > > Here, the focus is on the Assembly object rather than the Cookie but the > Cookie is available for later use if necessary. If we wish to add some > label to an Assembly object and/or add an operation to get a Cookie from an > Assembly object we can discuss that in a separate thread. > > Scott > > At 06:35 PM 8/9/02 +0200, Harald B(Macintosh; U; PPC) X-Accept-Language: en To: "J. Scott Evans" hme" Cc: components-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Date: Mon, 12 Aug 2002 08:11:24 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.8 |June 18, 2001) at 08/12/2002 08:11:25 AM X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7CD9WX25417 I don't disagree on the issue about the identifier being needed, The other interfaces that I referenced have the same problem (separate issue needs to be submitted). The only issue that remains is the create behavior. What is still an issue is as follows: What actor is the primary user of the AssemblyFactory interface? The actor in our system use cases is an Operator and there are multiple different roles for operators in the system. The actor assigns meaningful label/identifier to the Assembly instances that get created. The Assembly instance should have an identifier attribute created by the AssemblyFactory, which is assigned to the Assembly, along with a name/label attribute that is given by the actor and assigned to the Assembly. The create should be: Cookie create(in Location assembly_loc,in String name, out Assembly new_assembly) raise(IncalidLocation, CreateFailure); Addtional readonly attributes for the Assembly should be: hme" cc: (bcc: Gerald L Bickle/US/Raytheon) Subject: Re: AssemblyFactory Interface Changes 08/12/2002 05:23 AM Hi Scott Please refer allway to ptc/01-11-03. J. Scott Evans wrote: > > Hi Harald, > > You raise interesting arguments although I don't happen to subscribe > to all of them ;) In the interest of a timely compromise how about > the following changes to Gerald's and my original posts? > > exception InvalidLocation { }; > exception InvalidAssembly { }; > > typedef sequence Assemblies; > > interface AssemblyFactory { > Assembly create( > in string Location assembly_loc, > out Cookie c) > raises (InvalidLocation, CreateFailure); This should be: Cookie create(in Location assembly_loc, out Assembly new_assembly) raise(IncalidLocation, CreateFailure); Here we have to provide more informations about Location. The primary identity for the Assembly is still the cookie. > > Assembly lookup(in Cookie c) > raises (InvalidAssembly); > boolean void destroy(in Assembly the_assembly) > raises (InvalidAssembly, RemoveFailure); void destroy(in Cookie the_assembly) raises(InvalidAssemvly,RemoveFailure); Here we use the primary identity for the Assembly. Please remeber that if you use bridges there is no identical object referenc, becaus each bridge will establish a mapping for the object references. > Assemblies get_assemblies(); > }; That is fine, but Assemblies has to be defined. It might be good as a sequence of valuetypes containig the cookie an the object referenc. > > Here, the focus is on the Assembly object rather than the Cookie but > the Cookie is available for later use if necessary. If we wish to >add > some label to an Assembly object and/or add an operation to get a > Cookie from an Assembly object we can discuss that in a separate >thread. > So again to focus on Assembly object references may be more handy for the user, but if you remove the semantic of primary identity via cookies you will brake with some other parts in CORBA, where they are introduced for primary identity reasons. Change the parameter in destroy express this. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> Regrads, Harald PS: I'm will make compromises, but not for the identity issue. -- <<<< Harald B Interface Assembly { readonly attribute Cookie identifier; readonly attribute String name; etc. Jerry hme User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020517 X-Accept-Language: de-de, en-us To: components-rtf@omg.org Subject: Re: AssemblyFactory Interface Changes Hi Gerald Gerald_L_Bickle@raytheon.com wrote: I don't disagree on the issue about the identifier being needed, The other interfaces that I referenced have the same problem (separate issue needs to be submitted). The only issue that remains is the create behavior. What is still an issue is as follows: What actor is the primary user of the AssemblyFactory interface? The actor in our system use cases is an Operator and there are multiple different roles for operators in the system. The actor assigns meaningful label/identifier to the Assembly instances that get created. The Assembly instance should have an identifier attribute created by the AssemblyFactory, which is assigned to the Assembly, along with a name/label attribute that is given by the actor and assigned to the Assembly. The create should be: Cookie create(in Location assembly_loc,in String name, out Assembly new_assembly) raise(IncalidLocation, CreateFailure); That is ok with me. But you have to provide the semantic part for transfering cookies and name to the Assembly object. hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> Addtional readonly attributes for the Assembly should be: Interface Assembly { readonly attribute Cookie identifier; readonly attribute String name; etc. Regrads, Harald -- <<<< Harald B "Harald BCC: Harald B From: Gerald_L_Bickle@raytheon.com Subject: Re: AssemblyFactory Interface Changes To: "Harald B Date: Mon, 12 Aug 2002 16:14:20 +0200 From: Harald B From: ritter@fokus.gmd.de X-Authentication-Warning: saturn.fokus.gmd.de: nobody set sender to tri@fokus.fhg.de using -f To: Philippe.Merle@lifl.fr, Philippe Merle , Gerald_L_Bickle@raytheon.com, components-rtf@omg.org Subject: Re: Meeting for discuting about CCM DTD issues Date: Sun, 01 Sep 2002 20:06:44 +0200 (MET DST) User-Agent: IMP/PHP IMAP webmail program 2.2.7 Zitiere Philippe Merle : > > Unfortunatly, some other issues are very specific to > your requirements/applications and I think that the CCM spec > should not be increased with specific domain solutions. In this point I want to back up Philippe. And I want to refresh the discussion about issue 5576. I think it is ok to add an out parameter that holds the reference of the assembly instead of make another lookup call. But the cookie shall be the return parameter because the cookie is used for identity of the assembly. To add a user-friendly identifier is a domain specific solution and I would suggest not to enhance the interfaces in that way. Cheers, Tom Sender: merle@lifl.fr Date: Sat, 14 Sep 2002 19:01:59 +0200 From: Philippe Merle Reply-To: Philippe.Merle@lifl.fr Organization: Laboratoire d'Informatique Fondamentale de Lille X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686) X-Accept-Language: fr To: ritter@fokus.gmd.de CC: Gerald_L_Bickle@raytheon.com, components-rtf@omg.org Subject: Re: Meeting for discuting about CCM DTD issues X-MailScanner: Found to be clean Hello, ritter@fokus.gmd.de wrote: > > Zitiere Philippe Merle : > > > > > Unfortunatly, some other issues are very specific to > > your requirements/applications and I think that the CCM spec > > should not be increased with specific domain solutions. > > In this point I want to back up Philippe. And I want to refresh the discussion > about issue 5576. > I think it is ok to add an out parameter that holds the reference of the > assembly instead of make another lookup call. But the cookie shall be the return > parameter because the cookie is used for identity of the assembly. > To add a user-friendly identifier is a domain specific solution and I would > suggest not to enhance the interfaces in that way. I fully agree with your proposal for this issue. Could you prepare the resolution and revised text for this issue? Perhaps you could work on this with Harald from HU. After the Helsinki meeting, I will continue to collect issue resolutions to prepare next votes and report. So every RTF member is welcome to propose resolutions allowing us to discuss them before starting votes. Last but not least, thanks you to refer now the official CORBA Components Specification (formal/02-06-65) in our debate instead of the finalized one (ptc/01-11-03). > Cheers, > Tom A+ Philippe Merle -- __________________________________________________ Dr. Philippe Merle - INRIA Researcher at Laboratoire d'Informatique Fondamentale de Lille UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3 Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq CEDEX France Phone: (33) (0)3 20 33 70 24 Fax: (33) (0)3 20 43 65 66 E-Mail: Philippe.Merle@lifl.fr Home Page: http://www.lifl.fr/~merle See also: http://www.objectweb.org/ http://corbaweb.lifl.fr/ __________________________________________________ Date: Tue, 15 Apr 2003 14:23:05 +0200 From: Tom Ritter Reply-To: ritter@fokus.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: de-de, de To: components-rtf@omg.org Subject: issue 5576 Hello RTF, Together with Harald I have prepared a resolution for the issue 5576. The second point of the issue is still open. I tend to not add such a get_assemblies operation since the knowledge about the created assemblies is related to the client that created this assembly. The client can propagate it if needed. But in this point I'm open to accept a modification. If we think that this information should be of general visibility. What is the opinion of other RTF members? Philippe, you can take this solution in the report if there are no further comments from the RTF. The solution for the other two issues I took over follow soon. Cheers, Tom >>> Source: Raytheon (Mr. Gerald Lee Bickle, gerald_l_bickle@raytheon.com jerrybickle@kconline.com) Nature: Uncategorized Issue Severity: Summary: Suggested changes to the AssemblyFactory interface. AssemblyFactory Issues. 1. Ease of use Issue. After the create operation is performed, one is force to call lookup to get the Assembly that just got just created. Why is a cookie returned by the create operation instead of an Assembly? Is the reason because of security? If the interface were more open this would still allow a secure implementation to be implemented. Suggested change is to return an Assembly instead of a Cookie. Change destroy operation to take in an Assembly parameter instead of Cookie. Change lookup operation to take in a name parameter. These changes make it consistent with the other CCM interfaces, such as Container, KeyLessCCMHome, ComponentServer, and ServerActivator. 2. Multiple users Issue. For multiple users, how does a client know what assemblies are created. Add a get_assemblies operation that returns a list of assemblies. These changes make it consistent with other CCM interfaces, such as Container, ComponentServer, and ServerActivator. 3. User-friendly identifier for Assembly Instance issue. Add an input name parameter that can be assigned to the Assembly instance that gets created. Add a read only name or label attribute to the Assembly interface. Resolution: ------------ 1. To avoid another call to the Assembly Factory interface an out parameter has been added to the create operation that provides a reference to the newly create Assembly. The use of cookie values is not related to security. The lookup operation will not be changed since the cookie is the identity of an Assembly. 2. To discuss!!! The knowledge about installed assemblies is related to the client that has installed the assemblies. The client can propagate this knowledge to other clients if needed. 3. The problem of a user friendly identifier is a domain specific problem. The client of the assembly interface could use a dictionary to associate names and cookies of Assemblies. Revised Text: ------------ The create_assembly operation of the AssemblyFactory interface gets a new out parameter. Cookie create_assembly(in Location assembly_loc, out Assembly assembly_ref) raises (InvalidLocation, CreateFailure); 1. The description for the create operation is modified in the following form. The create_assembly operation creates an Assembly object on the host on which the AssemblyFactory is located. It takes a string denoting the location of an assembly package and returns a Cookie that may be used to reference the assembly later on. As out parameter an object reference of the created Assembly interface is return. The Cookie is the same as specified in Section 1.5.2.4, RCookie type,S on page 1-18 of this document. The operation raises an InvalidLocation exception if the assembly package could not be found. The operation raises a CreateFailure exception if an Assembly object could not be created for internal reasons such as insufficient resources. 2. No revision 3. No revision Disposition: 1. accepted 2. not accepted 3. not accepted -- =========================================================== Fraunhofer FOKUS Research Institute for Open Communication Systems Tom Ritter Room: 5005 Fraunhofer FOKUS Phone: +49 30 34 63 - 7278 Kaiserin-Augusta-Allee 31 FAX: +49 30 34 63 - 8000 D-10589 Berlin, Germany E-mail: ritter@fokus.fraunhofer.de or tom@users.berlios.de CCM (Open Source CORBA Components) http://qedo.berlios.de FOKUS UMTS Testbed umts@fokus.fhg.de ===========================================================