Issue 3568: Relax the restriction of 9.1.1 (interceptors-rtf) Source: (Mr. Nick Sharman, n.p.sharman(at)foxfield-sw.demon.co.uk) Nature: Uncategorized Issue Severity: Summary: Section 9 of orbos/99-12-02 describes the ORBInitInfo operations register_initial_reference and resolve_initial_reference, and places restrictions on when they can be used: 9.1.1 pre_init: "All calls to ORBInitInfo::register_initial_reference must be made at this point so that the list of initial references is complete for the post_init_point." 9.2.7 resolve_initial_references: "This operation is only valid during post_init." I assume that these restrictions are to remove ordering dependencies between interceptors - if A needs to use an initial service registered by B, then we can run the pre_inits for A and B in either order, and then the post_inits for A and B in either order. That's understandable, but I believe may be too restrictive in practice. For example, an interceptor may need to register an initial service but it will expect to find the object reference via a location service such as Naming or Trading -available as initial services "NameService" or "TradingService". I propose we relax the restriction of 9.1.1, and replace it by guidance such as: "If it is expected that initial services registered by an interceptor will be used by other interceptors, then those initial services should be registered at this point via calls to ORBInitInfo::register_initial_reference." Note that the same functionality will be available via the ORB after initialization anyway (11.1), so it seems a little arbitrary to forbid it only during the post_init phase. Resolution: In document ptc/00-04-05, make the recommended change. Revised Text: Replace the first paragraph in 21.7.1.1 pre_init: This operation is called during ORB initialization. All calls to ORBInitInfo::register_initial_reference must be made at this point so that the list of initial references is complete for the post_init point. with: This operation is called during ORB initialization. If it is expected that initial services registered by an interceptor will be used by other interceptors, then those initial services shall be registered at this point via calls to ORBInitInfo::register_initial_reference. Actions taken: April 19, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== eply-To: From: "Nick Sharman" To: "Portable Interceptors FTF" , "OMG Issues" Cc: "Martin Tonge" , "Kate Holt" Date: Wed, 19 Apr 2000 17:35:48 +0100 Message-ID: <008801bfaa1d$5121b400$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^XUd9%@(e9&pi!!G&md9 Section 9 of orbos/99-12-02 describes the ORBInitInfo operations register_initial_reference and resolve_initial_reference, and places restrictions on when they can be used: 9.1.1 pre_init: "All calls to ORBInitInfo::register_initial_reference must be made at this point so that the list of initial references is complete for the post_init_point." 9.2.7 resolve_initial_references: "This operation is only valid during post_init." I assume that these restrictions are to remove ordering dependencies between interceptors - if A needs to use an initial service registered by B, then we can run the pre_inits for A and B in either order, and then the post_inits for A and B in either order. That's understandable, but I believe may be too restrictive in practice. For example, an interceptor may need to register an initial service but it will expect to find the object reference via a location service such as Naming or Trading -available as initial services "NameService" or "TradingService". I propose we relax the restriction of 9.1.1, and replace it by guidance such as: "If it is expected that initial services registered by an interceptor will be used by other interceptors, then those initial services should be registered at this point via calls to ORBInitInfo::register_initial_reference." Note that the same functionality will be available via the ORB after initialization anyway (11.1), so it seems a little arbitrary to forbid it only during the post_init phase. Regards Nick --------------------------------- Nick Sharman Architect, LiveContent BROKER PeerLogic UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@peerlogic.com Web: http://www.peerlogic.com --- Winners of the "e-commerce" category --- --- Software Technology Awards 1999 --- From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA08842 for ; Fri, 28 Apr 2000 08:42:08 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA35976 for ; Fri, 28 Apr 2000 08:51:02 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568CF.00469282 ; Fri, 28 Apr 2000 08:50:50 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568CF.00461DA2.00@d54mta08.raleigh.ibm.com> Date: Fri, 28 Apr 2000 07:36:15 -0500 Subject: Re: Issue 3568 - Relax the restrictions of 9.1.1 (was: RE: Interceptor-ftf missed issue 3565) Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: :ib!!-MA!!:d@!!@c&!! Thanks for forwarding this, Nick. Sorry for missing it. We had a fair bit of discussion about this. It could always be argued that, in order to register a reference, a service needs another reference; but to make any guarantees we would need a post_post_init, and then a post_post_post_init, ad infinitum. The spec does not satisfy all possible scenarios, but in practice we considered it unlikely that these scenarios will ever occur. But even so, you make another point worth discussing. If we ever DO address issue 3403 (hint hint folks) and get the ORB in IDL, we will probably make it available in post_init, in which case register_initial_reference will be available via the ORB. So we lose the restriction we've set up. I still prefer the restriction, but if we can't enforce it, it's meaningless. I suspect the best we can do is apply something like your proposed replacement text, suggesting the protocol rather than mandating it. When we address 3403, the text will probably have to be changed again, but until then I like your proposal (with the possible change of "should" to "shall" though I'm not sure we can really justify that word in this context). Russell Butek butek@us.ibm.com "Nick Sharman" on 04/28/2000 06:30:18 AM > > This is issue # 3568 > > Relax the restriction of 9.1.1 > > Section 9 of orbos/99-12-02 describes the ORBInitInfo operations > register_initial_reference and resolve_initial_reference, and places > restrictions on when they can be used: > > 9.1.1 pre_init: > > "All calls to ORBInitInfo::register_initial_reference must be made at this > point so that the list of initial references is complete for the > post_init_point." > > 9.2.7 resolve_initial_references: > > "This operation is only valid during post_init." > > I assume that these restrictions are to remove ordering dependencies between > interceptors - if A needs to use an initial service registered by B, then we > can run the pre_inits for A and B in either order, and then the post_inits > for A and B in either order. > > That's understandable, but I believe may be too restrictive in practice. > For example, an interceptor may need to register an initial service but it > will expect to find the object reference via a location service such as > Naming or Trading -available as initial services "NameService" or > "TradingService". > > I propose we relax the restriction of 9.1.1, and replace it by guidance such > as: > > "If it is expected that initial services registered by an interceptor will > be used by other interceptors, then those initial services should be > registered at this point via calls to > ORBInitInfo::register_initial_reference." > > Note that the same functionality will be available via the ORB after > initialization anyway (11.1), so it seems a little arbitrary to forbid it > only during the post_init phase. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================