Issue 2970: Support of Interop Naming for Default Names is Not Scalable and is ineffici (naming_ftf) Source: Syracuse University (Mr. Polar Humenn, polar@adiron.com) Nature: Severity: Summary: The point I mean to make is on the resolution of corbanames beginning with "corbaname:///". The spec implies that name beginning with "corbaname:///" are basically resolved by a NamingContext found at "corbaloc://localhost:9999/NameService". Resolution: Agreed that the default localhost:9999 idea is problematic. To allow URLs to be used relative to the Revised Text: Modification to section 13.6.7.1 to introduce rir. New 13.6.7.2 corbaloc:rir section put before corbaloc:iiop section to describe rir details. corbaloc::iiop grammer modified to make an empty host name illegal. Section 13.6.7.5 added rir examples. Section 13.6.7.7 fixed description of corbaloc/corbaname to reference rir and not iiop default. Actions taken: October 11, 1999: received issue May 4, 2000: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 11 Oct 1999 10:50:47 -0400 (EDT) From: Polar Humenn To: issues@omg.org, naming_ftf@omg.org cc: orb_revision@omg.org, secsig@omg.org Subject: Re: ob: InteropNaming (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: #DL!!]AUd9Clo!!jfX!! Issue: Naming FTF Document: Interoperable Naming ptc/99-09-01 Severity: Critical, as always. Title: Support of Interop Naming for Default Names is Not Scalable and and is Inefficient Discussion: The point I mean to make is on the resolution of corbanames beginning with "corbaname:///". The spec implies that name beginning with "corbaname:///" are basically resolved by a NamingContext found at "corbaloc://localhost:9999/NameService". Firstly, let me state that I understand that a complete IOR can be obtained to the NameService by a "resolver", which is a mere location forwarder for an agent listening on the local machine. My problem with this architecture is that when this "default" case is noticed, why isn't the NameService that is configured with the ORB used, i.e. orb.resolve_initial_references("NameService"), and "-ORBInitRef NameService=IOR:2384284284039..." (page 3-1)???? Just because there is a way for resolution to be done (i.e. through this "resolver" agent), doesn't mean it's efficient or scalable. Let me explain why I think so. This is the "inefficient" point: In order to support the simple syntax of a name it requires *real* extraneous resources: not only an extra agent, but a designated port number on the local host. This is the "unscalable" point: In order to support interop naming in even a mere dribbly little client, that you need big "resolver" agent sitting on port 9999 of the *CLIENT's* machine! These points mean that you require every client that downloads a CORBA client must also before he executes that client to also run and configure a resolver on his local machine, and configure it with the NameService. Not good. These points also require that *every* ORB instance on a single machine use the same NameService (for default names), which ties everything to one particular machine. It would be "simple" to state in the spec that the syntax "corbaname:///..." resolves with ORB::resolve_initial_references("NameService") for use with the name component. Of course, we could cascade it down to the constructed name "corbaloc://localhost:9999/NameService", if the NameService is not configured for the ORB. Otherwise, initialization of a NameService object reference in the ORB is pretty much useless an may lead to inconsistency in resolution, which is explained below. Other problems: This architecture also breeds an inconsistency in the references obtained by the ORB for the name service. You end up with two *different* references to the name service. The one configured for the ORB and the constructed "corbaloc://localhost:9999/NameService" reference. Even with a "resolver" agent returning fully configured static IOR for a possibly "secured" NameService (i.e. one that contains SECIOP components), this situation breeds an inconsistency, especially, when the NameService object reference is configured with CORBA::Policy objects. For example, you may mandate that to the ORB that the object reference you want for the NameService is configured with client side policies, such as a SecurityLevel2::QOP policy, a SecurityLevel2::InvocationCredentialsPolicy, and a policy object stating that it doesn't rebind. Once you've configured that object reference for use with orb.resolve_initial_reference("NameService"), you'd like that reference to be continually used for resolutions. If every default name is mandated to locate the name service by "corbaloc://localhost:9999/NameService", it is a problem. Also, what if your client ORB doesn't speak plain old GIOP/IIOP/TCP, but GIOP/SECIOP/TCP? Then there is no way for the ORB to even contact this IIOP 1.0 "resolver". (there are security cases where you do not want the ORB instance performing any unprotected communication). However, if the ORB initialization configures the reference of the default NamingContext with a specific set of CORBA:Policies, then all names "corbaname:///..." will be resolved by the orb configured NameService reference. This revision would automatically solve most of the problems I've stated above. I hope you will consider the slight change for the FTF. Thanks and Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: "'naming_ftf@omg.org'" Cc: "Juergen Boldt (E-mail)" Subject: ReL Issue 2970: Support of Interop Naming for Default Names is No t Scalable and is ineffici Date: Fri, 19 Nov 1999 15:39:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: T:G!!d='!!m*l!!9LMe9 This is another issue for which there was considerable discussion that does not appear in the archive. I am inclined to agree with Polar that there ought to be a way to write a corbaname url that asks for a name to be resolved w/r/t the default nameservice for whoever does string_to_object on it. Even though the application could do this by getting the name service and calling resolve_str, that requires the application to do something special. The nice feature of url's is that whoever supplies the url gets to decide whether to use an ior, or a url. Being able to specify a name relative to the application allows the user to decouple from absolute names without forcing this. ____________________ Paul Kyzivat Rogue Wave Software paulk@roguewave.com