Issue 1088: ORB_init (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Page 4-9 of CORBA 2.2: ORBid strings other than the empty string are intended to be used to uniquely identify each ORB used within the same address space in a multi-ORB application. I don"t believe this is possible, mainly because the language mappings do not permit multiple ORB run-time libraries to be linked into the same address space. Resolution: Revised Text: Actions taken: March 20, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 20 Mar 1998 15:16:35 +1000 (EST) From: Michi Henning To: issues@omg.org, orb_revision@omg.org Subject: ORB_init Page 4-9 of CORBA 2.2: ORBid strings other than the empty string are intended to be used to uniquely identify each ORB used within the same address space in a multi-ORB application. I don't believe this is possible, mainly because the language mappings do not permit multiple ORB run-time libraries to be linked into the same address space. For one, how could I possibly run different ORBs in the same address space, both of which provide an ORB_init call? When I call ORB_init, which ORB's ORB_init will run? (not to mention the multiply defined external symbols...) Secondly, if I want to use two ORBs with two run-time libraries in the same address space, I'll get hundreds of multiply defined other symbols (at least). And that's not counting any of the symbols generated by the language binding. There are lots of other issues with this that don't even bear thinking about... Isn't this idea of running with multiple ORBs in the same address space simply a pipe dream? And besides, why would I want to do this given IIOP? I think this paragraph of the spec should be removed and the orb_identifier parameter should be deprecated. To me, it seems the spec promises something here that in reality just doesn't exist. Of course, I'd be happy to learn that my concerns are unfounded... ;-) Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 20 Mar 1998 01:12:28 -0500 To: Michi Henning From: Steve Vinoski Subject: Re: ORB_init Cc: issues@omg.org, orb_revision@omg.org At 03:16 PM 3/20/98 +1000, Michi Henning wrote: >Page 4-9 of CORBA 2.2: > > ORBid strings other than the empty string are intended to be used > to uniquely identify each ORB used within the same address space > in a multi-ORB application. > >I don't believe this is possible, mainly because the language mappings >do not permit multiple ORB run-time libraries to be linked into the same >address space. Actually, in a previous life I successfully linked two ORBs from separate vendors together, one written in C and the other written in C++. Worked just fine. >I think this paragraph of the spec should be removed and the orb_identifier >parameter should be deprecated. To me, it seems the spec promises something >here that in reality just doesn't exist. On the contrary, I think it should be left alone. It's a quality of implementation issue that can be very useful under certain circumstances. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 20 Mar 1998 17:20:13 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: issues@omg.org, orb_revision@omg.org Subject: Re: ORB_init On Fri, 20 Mar 1998, Steve Vinoski wrote: > Actually, in a previous life I successfully linked two ORBs from > separate vendors together, one written in C and the other written in > C++. Worked just fine. Yes, I can see how this would work, because it avoids all the issues of symbol clashes. However, the words in the spec seem to imply that I can take, for example, Visibroker for C++ and Orbix for C++ and use them both from within the same process. Clearly, this isn't going to work. > >I think this paragraph of the spec should be removed and the > orb_identifier > >parameter should be deprecated. To me, it seems the spec promises > something > >here that in reality just doesn't exist. > > On the contrary, I think it should be left alone. It's a quality of > implementation issue that can be very useful under certain > circumstances. Hmmm... Maybe some weasel words are necessary to clarify this? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: To: Michi Henning cc: Steve Vinoski , issues@omg.org, orb_revision@omg.org, crawley@dstc.edu.au Subject: Re: ORB_init Date: Fri, 20 Mar 1998 18:24:46 +1000 From: Stephen Crawley Michi wrote: > On Fri, 20 Mar 1998, Steve Vinoski wrote: > > > Actually, in a previous life I successfully linked two ORBs from > > separate vendors together, one written in C and the other written > in > > C++. Worked just fine. > > Yes, I can see how this would work, because it avoids all the issues > of symbol clashes. However, the words in the spec seem to imply that > I can > take, for example, Visibroker for C++ and Orbix for C++ and use them > both from within the same process. Clearly, this isn't going to > work. Envisage for a moment an operating system where multiple "programs" are run in the same address space; e.g. on a machine without virtual memory. When the program is run, the loader automatically relocates the program, and resolves references to resident libraries. Now, imagine that the Orbix / Visigenic ORB runtime libraries had been linked into two programs. If the corresponding symbol table entries were not "exported" by the program images, there is no reason why two or more ORBs couldn't co-exist in the same address space. Indeed, you could have two distinct copies of Orbix. Or even more weird, you could have a UNIX / C++ / Orbix application that needs to be part of two logically distinct Orbs! I can't immediately think why, but ... as Bob Coulomb says: "The world is an unimaginably weird place" :-) -- Steve Return-Path: Date: Fri, 20 Mar 1998 05:43:35 -0800 From: Jeff.Nisewanger@Eng.Sun.COM (Jeff Nisewanger) To: issues@omg.org, orb_revision@omg.org, michi@dstc.edu.au Subject: Re: ORB_init X-Sun-Charset: US-ASCII > Page 4-9 of CORBA 2.2: > > ORBid strings other than the empty string are intended to be > used > to uniquely identify each ORB used within the same address > space > in a multi-ORB application. > > I don't believe this is possible, mainly because the language > mappings > do not permit multiple ORB run-time libraries to be linked into the > same > address space. This actually works for the Java mapping but I'm dubious about it working for other language mappings except in highly controlled circumstances where the ORB instance naming and identification could be managed seperately from the ORB_init call anyway. We didn't include the ORBid string in the Java mapping of the ORB init method for related reasons and because of Java-specific security and implementation implications. > Isn't this idea of running with multiple ORBs in the same address space > simply a pipe dream? And besides, why would I want to do this given IIOP? One reason might be when building a bridge linking 2 different object domains of some kind. Jeff Return-Path: Date: Fri, 20 Mar 1998 10:06:15 -0500 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: issues@omg.org, orb_revision@omg.org Subject: Re: ORB_init References: Michi Henning wrote: > > Page 4-9 of CORBA 2.2: > > ORBid strings other than the empty string are intended to be > used > to uniquely identify each ORB used within the same address > space > in a multi-ORB application. Its not clear what exactly is meant by "ORB" in the preceding text. You seem to be trying to interpret "ORB" as a particular vendor's ORB implementation, but that is not the only useful interpretation. I agree with you that this interpretation is not very practical, at least in C++, since it would require the ORB implementations to share ORB_init(), avoid other symbol clashes, etc. But another interpretation is that "ORB" here simply means the ORB pseudo-object instance returned by ORB_init(). The folowing text from the end of section 4.4 of CORBA 2.2 seems to support this interpretation: "The ORB_init operation may be called any number of times and shall return the same ORB reference when the same ORBid string is passed, either explicitly as an argument to ORB_init or through the arg_list." I see no requirement that the different ORB references returned when different ORBIds are passed to ORB_init() refer to ORB instances belonging to different ORB vendors' ORB implementations. Now you might wonder why someone would want more than one instance of the same vendors' ORB in a process. This might not seem too useful given just the currently adopted specifications. But if you look closely at the CORBA Messaging RFP revised submission (orbos/98-01-04 or orbos/98-03-11) or corresponding presentation (orbos/98-01-20 or orbos/98-03-12), you'll see that APIs are being provided for setting client-side QoS at the ORB, thread, and object reference levels. Different ORB instances will be able to have different ORB-level client-side QoS settings. -Bob > > I don't believe this is possible, mainly because the language > mappings > do not permit multiple ORB run-time libraries to be linked into the > same > address space. > > For one, how could I possibly run different ORBs in the same > address space, both of which provide an ORB_init call? When I call > ORB_init, > which ORB's ORB_init will run? (not to mention the multiply defined > external > symbols...) > > Secondly, if I want to use two ORBs with two run-time libraries in > the same > address space, I'll get hundreds of multiply defined other symbols > (at least). > And that's not counting any of the symbols generated by the language > binding. > > There are lots of other issues with this that don't even bear > thinking about... > > Isn't this idea of running with multiple ORBs in the same address > space > simply a pipe dream? And besides, why would I want to do this given > IIOP? > > I think this paragraph of the spec should be removed and the > orb_identifier > parameter should be deprecated. To me, it seems the spec promises > something > here that in reality just doesn't exist. > > Of course, I'd be happy to learn that my concerns are > unfounded... ;-) > > Cheers, > > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA > http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Fri, 20 Mar 1998 08:44:27 -0800 From: Jonathan Biggar To: Michi Henning CC: issues@omg.org, orb_revision@omg.org, cxx_revision@omg.org Subject: Re: ORB_init References: Michi Henning wrote: > > Page 4-9 of CORBA 2.2: > > ORBid strings other than the empty string are intended to be > used > to uniquely identify each ORB used within the same address > space > in a multi-ORB application. > > I don't believe this is possible, mainly because the language > mappings > do not permit multiple ORB run-time libraries to be linked into the > same > address space. > > For one, how could I possibly run different ORBs in the same > address space, both of which provide an ORB_init call? When I call > ORB_init, > which ORB's ORB_init will run? (not to mention the multiply defined > external > symbols...) > > Secondly, if I want to use two ORBs with two run-time libraries in > the same > address space, I'll get hundreds of multiply defined other symbols > (at least). > And that's not counting any of the symbols generated by the language > binding. > > There are lots of other issues with this that don't even bear > thinking about... > > Isn't this idea of running with multiple ORBs in the same address > space > simply a pipe dream? And besides, why would I want to do this given > IIOP? > > I think this paragraph of the spec should be removed and the > orb_identifier > parameter should be deprecated. To me, it seems the spec promises > something > here that in reality just doesn't exist. > > Of course, I'd be happy to learn that my concerns are > unfounded... ;-) As has been mentioned previously, this is not a problem for the Java language binding, where specific work was done to resolve this issue. For C++ and Ada, a similar approach could be done, problably entirely within the respective RTFs. In C++, this could be fixed by doing the following, when namespaces are universal: 1. Mandate that each vendor package their implementation entirely within proprietarily named namespaces: "IONA", "Visigenic", etc. 2. The vendor then would provide two include files (much like the new C++ standard), and . would define everthing within the vendor's namespace, and would be: #include using Vendor_Specific_Namespace; 3. The final step would be to change the language binding for ORB_init, so that it binds into a different namespace, CORBA_INIT, and add additional functionality to this namespace so that each vendor can register their implementation. The current binding for ORB_init could remain for backwards compatibility, but would only be able to deliver ORBs from one vendor's implementation. Done this way, you have a backwards compatible way of accessing more than one ORB implementation within your address space. Of course this leaves C, COBOL, and Smalltalk out in the cold, but you can't have everything... -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Jeffrey Mischkinsky Subject: Re: ORB_init To: kukura@iona.com (Bob Kukura) Date: Fri, 20 Mar 1998 10:13:03 -0800 (PST) Cc: michi@dstc.edu.au, issues@omg.org, orb_revision@omg.org 'Bob Kukura' writes: > > > Now you might wonder why someone would want more than one instance > of > the same vendors' ORB in a process. This might not seem too useful > given just the currently adopted specifications. But if you look > closely at the CORBA Messaging RFP revised submission > (orbos/98-01-04 or > orbos/98-03-11) or corresponding presentation (orbos/98-01-20 or > orbos/98-03-12), you'll see that APIs are being provided for setting > client-side QoS at the ORB, thread, and object reference levels. > Different ORB instances will be able to have different ORB-level > client-side QoS settings. In Java there can, and usually are multiple orb instances. There is > the "crippled" one (the sort of default) that only serves as a factory for > things like typecodes, and then there are the "real" one(s). jeff > > -Bob > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@visigenic.com +1 650-312-5158 Return-Path: Sender: goldberg@corp.borland.com Date: Fri, 20 Mar 1998 11:36:18 -0800 From: Jon Goldberg To: Jeffrey Mischkinsky CC: Bob Kukura , michi@dstc.edu.au, issues@omg.org, orb_revision@omg.org Subject: Re: ORB_init References: <199803201813.KAA11314@wheel.dcn.davis.ca.us> Hi Folks- This mechanism of having a single vendor provide multiple distinct ORB instances is already used by at least one vendor I know of...deprecation would be a bad idea! We sell two C++ ORBs, SSL and IIOP. You can certainly get object references from either one of these in a given client. The ORBs are distinguished by ORBid. take care, Jon > 'Bob Kukura' writes: > > > > > > Now you might wonder why someone would want more than one instance > of > > the same vendors' ORB in a process. This might not seem too > useful > > given just the currently adopted specifications. But if you look > > closely at the CORBA Messaging RFP revised submission > (orbos/98-01-04 or > > orbos/98-03-11) or corresponding presentation (orbos/98-01-20 or > > orbos/98-03-12), you'll see that APIs are being provided for > setting > > client-side QoS at the ORB, thread, and object reference levels. > > Different ORB instances will be able to have different ORB-level > > client-side QoS settings. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sat, 21 Mar 1998 06:36:31 +1000 (EST) From: Michi Henning To: Bob Kukura cc: issues@omg.org, orb_revision@omg.org Subject: Re: ORB_init On Fri, 20 Mar 1998, Bob Kukura wrote: > Now you might wonder why someone would want more than one instance of > the same vendors' ORB in a process. This might not seem too useful > given just the currently adopted specifications. But if you look > closely at the CORBA Messaging RFP revised submission (orbos/98-01-04 or > orbos/98-03-11) or corresponding presentation (orbos/98-01-20 or > orbos/98-03-12), you'll see that APIs are being provided for setting > client-side QoS at the ORB, thread, and object reference levels. > Different ORB instances will be able to have different ORB-level > client-side QoS settings. Bob (and others), thanks for the comments, and yes, you win of course :-) I would still suggest though to add some words along the lines of what you said to the spec. They needn't be normative, but could be suggestive of the uses of the ORBid argument. The way the spec reads now, I think it is too vague and open to misinterpretation. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html