Issue 3204: ORB Init problems (java-rtf) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: Being new to this game, what is the "Java ORB instance" problem that you > tried solving? There is another problem with the Java ORB that I'd also > like to bring up, but I don't know the proper place to do it. Would the > Java RTF address it? > > The problem: the spec talks about an ORB ID. The Java mapping, for some > reason, chose to ignore the ID. I'd like to understand the reason why. > Could you enlighten us? Resolution: see above Revised Text: Actions taken: December 6, 1999: received issue May 13, 2002: closed issue Discussion: ORBId is now provided as a result of the Object Reference Template spec. Close no change End of Annotations:===== Date: Mon, 06 Dec 1999 17:09:10 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors@ois.com, java-rtf@omg.org Subject: Re: ORB Init problems (was: Re: revised proposal for interceptorbootstrap framework) References: <8525683F.0057BAF9.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6k#"!a5>!!Xc#!!R;?e9 Russell, butek@us.ibm.com wrote: > > Simon, > > Being new to this game, what is the "Java ORB instance" problem that > you > tried solving? There is another problem with the Java ORB that I'd > also > like to bring up, but I don't know the proper place to do it. Would > the > Java RTF address it? > > The problem: the spec talks about an ORB ID. The Java mapping, for > some > reason, chose to ignore the ID. I'd like to understand the reason > why. > Could you enlighten us? > These are both aspects of the same problem. In Java, the model is > that every application or applet must have its own separate ORB instance (rule > 1), since application access to an ORB object implies the power to subvert the > working of that ORB in some nasty way, for example by denial of service > attacks (e.g., filling up the ORB's connection table), by registering interceptors > with the ORB, or possibly by snooping on data managed by the ORB and owned by > other applications that may be using the same ORB. Therefore, every application or applet must create its own ORB instance (rule 2) and must always pass this instance object around explicitly to any code that executes on its behalf (rule 3). The ability to obtain another ORB instance in the same JVM by calling ORB.init with an ORB ID would give one application the power to get hold of another application's ORB (if it correctly guessed the ORB ID) and this would violate rule 1. The requirement to always pass the ORB instance explicitly (rule 3) is what I was referring to as the ORB instance problem. In many cases it would be useful to allow an ORB instance to be implicitly associated with the current execution context that could be used when no explicit ORB instance was provided, for example when deserializing a stub or when converting an EJB handle to a CORBA object reference. However, we have not yet been able to come up with a model for doing such association in a guaranteed secure way so that application or applet code can never get improper access to someone else's ORB instance. An alternative approach is to make the ORB more secure so that just getting access to the ORB object doesn't imply the power to do bad things. This is essentially the model used by most core Java APIs - anyone can call them, but they are security privilege checked so that unauthorized callers can't do any harm. Yes, this problem should be addressed by the IDL to Java RTF. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 15 Feb 2000 22:22:03 -0330 From: Matthew Newhook To: Ken Cavanaugh Cc: java-rtf@omg.org, rip-dev@Eng.Sun.COM, Peter.Walker@Eng.Sun.COM Subject: Re: Discussion on issue 3204 Message-ID: <20000215222203.A18555@ooc.com> References: <200002151832.KAA04881@taller.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002151832.KAA04881@taller.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: bpD!!6SBe9Pd7!!;gB!! Hi Ken, On Tue, Feb 15, 2000 at 10:30:26AM -0800, Ken Cavanaugh wrote: > How is it then possible for the ORB to correctly dispatch requests > to > objects implemented by each of these persistent POAs? Sorry, but I simply don't see why this is a problem. We do this, with no issues that I'm aware of and we don't have any ORB id's to do this with. >[...] > The current Java mapping does not define a standard mechanism for > associating > any kind of ID with an ORB. Supporting persistent POAs also > requires > persistent ORB IDs, i.e. each time the server is restarted, Mmmm... where does say that in the spec? Along with that what's a server, and where can I find the definition of that in the spec? ;) > the same ID > must be assigned to the server, ORB, POAs, and anything else needed > to > define the object reference, particularly the object key in most > implementations. That assumes that you use the ORB id to do that. Since how this is done is not specified (ie: it's environment specific) I don't see why you would want to introduce something new into the Java mapping to meet your interpretation of how to implement this. >[...] > Thanks, > > Ken. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 16 Feb 2000 13:48:55 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: Ken Cavanaugh , java-rtf@omg.org, rip-dev@Eng.Sun.COM, Peter.Walker@Eng.Sun.COM Subject: Re: Discussion on issue 3204 In-Reply-To: <20000215222203.A18555@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \b\d9H-X!!~Hnd95U?e9 On Tue, 15 Feb 2000, Matthew Newhook wrote: > > the same ID > > must be assigned to the server, ORB, POAs, and anything else > needed to > > define the object reference, particularly the object key in most > > implementations. > > That assumes that you use the ORB id to do that. Since how this is > done > is not specified (ie: it's environment specific) I don't see why you > would want to introduce something new into the Java mapping to meet > your > interpretation of how to implement this. I agree with that. There is no need to standardize anything, as far as I can see. The client simply picks up an address and an object key out of the IOR and makes calls. No ORB ID is required on the client side. Similarly, the POA that creates the IOR simply puts an address and an object key into IOR and that's that. Again, no ORB ID is required. Further, if the issue were to fix any flaw in the spec, then I don't see how it could be specific to the Java mapping. If anything, it would be a POA issue and therefore belong in the core. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 24 Feb 2000 14:50:14 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Discussion on issue 3204 To: java-rtf@omg.org Cc: Ken.Cavanaugh@eng.sun.com MIME-Version: 1.0 Content-MD5: MtWP+pgXYIVaD55Q5Up8Lw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: $V;e9VTn!!#jj!!+8Ee9 OK, here is my additional discussion on 3204. Sorry about the delay, it's been a busy week. > From: Matthew Newhook > To: Ken Cavanaugh > Cc: java-rtf@omg.org, rip-dev@eng.sun.com, Peter.Walker@eng.sun.com > Subject: Re: Discussion on issue 3204 > Mime-Version: 1.0 > > Hi Ken, > > On Tue, Feb 15, 2000 at 10:30:26AM -0800, Ken Cavanaugh wrote: > > How is it then possible for the ORB to correctly dispatch requests > to > > objects implemented by each of these persistent POAs? > > Sorry, but I simply don't see why this is a problem. We do this, > with no > issues that I'm aware of and we don't have any ORB id's to do this > with. > Do you have distinct ORB instances for each call to ORB.init( ... ), or do you share POA namespaces between the ORB instances? > >[...] > > The current Java mapping does not define a standard mechanism for > associating > > any kind of ID with an ORB. Supporting persistent POAs also > requires > > persistent ORB IDs, i.e. each time the server is restarted, > > Mmmm... where does say that in the spec? Along with that what's a > server, > and where can I find the definition of that in the spec? ;) > Note that the POA spec (99-10-07 11.3.7.2) discusses "process" in the context of persistent POAs. "Process" is certainly not defined in the spec, but some such concept is necessary to discuss the Persistent LifeSpan policy. So, substitute "process" for "server" in my original discussion: the point is the same. > > the same ID > > must be assigned to the server, ORB, POAs, and anything else > needed to > > define the object reference, particularly the object key in most > > implementations. > > That assumes that you use the ORB id to do that. Since how this is > done > is not specified (ie: it's environment specific) I don't see why you > would want to introduce something new into the Java mapping to meet > your > interpretation of how to implement this. > I need to add a few points to this discussion: 1. As stated in the IDL to Java mapping spec (ptc/00-01-08 1.21.9 "application initialization") each time ORB.init is called a new fully functional ORB is returned. One interpretation of this statement is that each ORB is completely independent of all of the other ORBs created this way, even if ORBClass is the same for each ORB.init call. This is the way the Sun ORB works, so that each ORB has its own transport, POAs, etc. Perhaps not everyone that implements a Java ORB agrees with this interpretation, but this has always been the interpretation at Sun, going back to the first work we did on Java ORBs around 1995 or so. From some discussions I have had, it seems that the original intent for the Java mapping was that each Java ORB instance would be independent. For example, each ORB should provide an independent POA namespace. It was also believed that this architecture was necessary in order to avoid security problems. If the Java ORB.init() worked like the C++ ORB.init, different parts of the same application (or different applets in the same browser) could get an ORB reference by name even if the ORB reference was in a different context (e.g. applet). This might create cases where some aspects of the Java security model could be violated. For example, if applet 1 is loaded from host A, and applet 2 is loaded from host B, applet 1 should only be able to open connections to host A, and thus could only send information to host A. A shared transport easily violates this by sharing cached connections (although this could be checked). Unfortunately none of this early consideration has been reflected in the current IDL to Java mapping, except in one line about ORB.init returning a new ORB object. A typical C++ ORB does not need to do anything like this. In my previous experience with C++ ORBs, most of the ORB machinery is shared globally, so there is no question about creating multiple ORB instances. In some cases, the ORBid is simply not used, and is left to the default value, in which case every call to ORB_init returns the same ORB object. 2. I should not have used the term "ORB ID" in my previous email. This clearly has a somewhat different meaning than I intended. Chapter 4 seems to regard the ORB ID more as an indicator of which ORB implementation to use rather than a specific ORB instance of an ORB implementation. In Java, we use ORBClass to define the implementation. I think it would be better to simply call what I am discussing an "ORB name" to avoid confusion with ORB id in chapter 4 of the CORBA spec. So, the problem is simply this: I have orb1 and orb2 using different interceptors (for example), and I create persistent poa1 on orb1 and poa2 on orb2, each with the same adapter name "foo". If we agree that orb1 and orb2 are independent orbs, poa1 and poa2 are in fact different poas on the orbs, and any object references that poa1 and poa2 create are distinct. It may also be crucial to the correct functioning of the system that requests are always dispatched to the "same" orb that created the objects in the first place. This is where an ORB name is needed, as otherwise I see no way to create an ORB identity that can be used in the object and that stays the same each time the process implementing these objects is restarted. Ken. From: Jeffrey Mischkinsky Message-Id: <200002250336.TAA25021@wheel.dcn.davis.ca.us> Subject: Re: Discussion on issue 3204 To: Ken.Cavanaugh@Eng.Sun.COM Date: Thu, 24 Feb 2000 19:36:57 -0800 (PST) Cc: java-rtf@omg.org In-Reply-To: <200002242252.OAA21969@taller.eng.sun.com> from "Ken Cavanaugh" at Feb 24, 2000 02:50:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :@[d9do_d9INIe9"CY!! 'Ken Cavanaugh' writes: > I need to add a few points to this discussion: > > 1. As stated in the IDL to Java mapping spec (ptc/00-01-08 1.21.9 > "application initialization") each time ORB.init is called a new > fully > functional ORB is returned. One interpretation of this statement > is that each ORB is completely independent of all of the other > ORBs > created this way, even if ORBClass is the same for each ORB.init > call. > This is the way the Sun ORB works, so that each ORB has its own > transport, POAs, etc. > > Perhaps not everyone that implements a Java ORB agrees with this > interpretation, > but this has always been the interpretation at Sun, going back to > the first work we did on Java ORBs around 1995 or so. From some > discussions > I have had, it seems that the original intent for the Java > mapping was that each > Java ORB instance would be independent. For example, each ORB > should > provide an independent POA namespace. > > It was also believed that this architecture was necessary in > order to > avoid security problems. If the Java ORB.init() worked like the > C++ > ORB.init, different parts of the same application (or different > applets > in the same browser) could get an ORB reference by name even if > the > ORB reference was in a different context (e.g. applet). This > might create > cases where some aspects of the Java security model could be > violated. > For example, if applet 1 is loaded from host A, and applet 2 is > loaded from > host B, applet 1 should only be able to open connections to host > A, and thus > could only send information to host A. A shared transport easily > violates > this by sharing cached connections (although this could be > checked). Having been present at all of those discussions, I can confirm that Ken's description is consistent with my understanding. We spent a lot of moaning about the inefficiency of it, but decided that the semantic of "independent, different" orbs was needed to guarantee the Java security model for applets. Now, there was no POA when the original idl/java mapping was done, so we didn't have to (and couldn't) consider the implications of poa namespaces. > > Unfortunately none of this early consideration has been reflected > in the > current IDL to Java mapping, except in one line about ORB.init > returning > a new ORB object. I think that's what it has always said. I don't think any words have been deleted by previous RTFs. I don't think we ever felt like more needed to be said. But if someone wants to propose additional language explaining all the implications, that would be ok. > So, the problem is simply this: I have orb1 and orb2 using different > interceptors (for example), and I create persistent poa1 on orb1 and poa2 on orb2, > each with the same adapter name "foo". > If we agree that orb1 and orb2 are independent orbs, poa1 and poa2 are in fact > different poas on the orbs, and any object references that poa1 and poa2 > create are distinct. It may also be crucial to the correct functioning of the > system that requests are always dispatched to the "same" orb that created > the objects in the first place. This is where an ORB name is needed, as otherwise > I see no way to create an ORB identity that can be used in the object and > that stays the same each time the process implementing these objects is > restarted. I think the question comes down to meaning of same (identity) WRT poas. (sigh, there must be some corollary to the "all problems can be solved with an extra level of indirection" which claims that all knotty problems which need the extra level of indirection are really identity problems.) If i have 2 poas named "root/a" in 2 different orb instances, regardless of whether they are in the same process (capsule for odp people:-) are they the same or different? (i'm assuming that their object references have the same host/port.) Effectively if i have an object key with a poa name of root/a and the same oid, say 42, what are the identity semantics when i go to use the objref? jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: "David O`Riordan" To: "Jeffrey Mischkinsky" , Cc: References: <200002250336.TAA25021@wheel.dcn.davis.ca.us> Subject: Re: Discussion on issue 3204 Date: Fri, 25 Feb 2000 15:01:28 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: aS-e9AL(e9&;1!!VE$!! It seems to me there are two parts to this discussion:- (1) the behaviour of ORB.init() - I think we are agreed on the interpretation of the IDL/Java mapping here. (2) are POAs of the same name on two distinct orbs the same or different?. I believe the second question is first and foremost an issue for the core rather than any mapping, Java security notwithstanding. The semantics of persistent POAs in particular will generally be interpreted not just by the orb instance, but by various other parts of an orb infrastructure. The orbs using the infrastructure may be implemented in different languages. Differences in interpretations in mappings could easily break this. Regards, Dave ----- Original Message ----- From: Jeffrey Mischkinsky To: Cc: Sent: Friday, February 25, 2000 3:36 AM Subject: Re: Discussion on issue 3204 > 'Ken Cavanaugh' writes: > > I need to add a few points to this discussion: > > > > 1. As stated in the IDL to Java mapping spec (ptc/00-01-08 1.21.9 > > "application initialization") each time ORB.init is called a > new fully > > functional ORB is returned. One interpretation of this > statement > > is that each ORB is completely independent of all of the other > ORBs > > created this way, even if ORBClass is the same for each > ORB.init call. > > This is the way the Sun ORB works, so that each ORB has its own > > transport, POAs, etc. > > > > Perhaps not everyone that implements a Java ORB agrees with > this interpretation, > > but this has always been the interpretation at Sun, going back > to > > the first work we did on Java ORBs around 1995 or so. From > some discussions > > I have had, it seems that the original intent for the Java > mapping was that each > > Java ORB instance would be independent. For example, each ORB > should > > provide an independent POA namespace. > > > > It was also believed that this architecture was necessary in > order to > > avoid security problems. If the Java ORB.init() worked like > the C++ > > ORB.init, different parts of the same application (or different applets > > in the same browser) could get an ORB reference by name even if > the > > ORB reference was in a different context (e.g. applet). This > might create > > cases where some aspects of the Java security model could be violated. > > For example, if applet 1 is loaded from host A, and applet 2 is loaded from > > host B, applet 1 should only be able to open connections to > host A, and thus > > could only send information to host A. A shared transport > easily violates > > this by sharing cached connections (although this could be > checked). > > Having been present at all of those discussions, I can confirm that > Ken's > description is consistent with my understanding. We spent a lot of > moaning > about the inefficiency of it, but decided that the semantic of "independent, > different" orbs was needed to guarantee the Java security model for > applets. > > Now, there was no POA when the original idl/java mapping was done, > so we > didn't have to (and couldn't) consider the implications of poa > namespaces. > > > > > Unfortunately none of this early consideration has been > reflected in the > > current IDL to Java mapping, except in one line about ORB.init returning > > a new ORB object. > > I think that's what it has always said. I don't think any words have > been > deleted by previous RTFs. I don't think we ever felt like more > needed to be > said. But if someone wants to propose additional language explaining > all > the implications, that would be ok. > > > So, the problem is simply this: I have orb1 and orb2 using > different > > interceptors (for example), and I create persistent poa1 on orb1 > and poa2 on orb2, > > each with the same adapter name "foo". > > If we agree that orb1 and orb2 are independent orbs, poa1 and poa2 > are in fact > > different poas on the orbs, and any object references that poa1 > and poa2 > > create are distinct. It may also be crucial to the correct > functioning of the > > system that requests are always dispatched to the "same" orb that created > > the objects in the first place. This is where an ORB name is > needed, as otherwise > > I see no way to create an ORB identity that can be used in the > object and > > that stays the same each time the process implementing these > objects is > > restarted. > > I think the question comes down to meaning of same (identity) WRT > poas. > (sigh, there > must be some corollary to the "all problems can be solved with an > extra > level of indirection" which claims that all knotty problems which > need the > extra level of indirection are really identity problems.) > > If i have 2 poas named "root/a" in 2 different orb instances, > regardless > of whether they are in the same process (capsule for odp people:-) > are > they the same or different? (i'm assuming that their object > references > have the same host/port.) Effectively if i have an object key with > a poa name of root/a and the same oid, say 42, what are the identity > semantics when i go to use the objref? > > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 > Date: Mon, 28 Feb 2000 21:34:32 -0330 From: Matthew Newhook To: Ken Cavanaugh Cc: java-rtf@OMG.ORG Subject: Re: Discussion on issue 3204 Message-ID: <20000228213432.C20052@ooc.com> References: <200002242252.OAA21969@taller.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002242252.OAA21969@taller.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 1fIe9@j-e9X?R!!-;A!! Hi, On Thu, Feb 24, 2000 at 02:50:14PM -0800, Ken Cavanaugh wrote: > > Sorry, but I simply don't see why this is a problem. We do this, > with no > > issues that I'm aware of and we don't have any ORB id's to do this > with. > > > > Do you have distinct ORB instances for each call to ORB.init( ... ), > > or do you share POA namespaces between the ORB instances? No, we have a distinct ORB instance for each call to ORB.init (well, for the non dummy ORB). >[...] > > Mmmm... where does say that in the spec? Along with that what's a > server, > > and where can I find the definition of that in the spec? ;) > > > > Note that the POA spec (99-10-07 11.3.7.2) discusses "process" in > the context > of persistent POAs. > "Process" is certainly not defined in the spec, but some such > concept is necessary > to discuss the Persistent LifeSpan policy. So, substitute "process" > for "server" > in my original discussion: the point is the same. I don't think so. To me, unless the user is using an IMR (which is outside of the specification, and therefore not relevant to this discussion) then the lifespan of a persistent POA is the lifespan of the ORB. >[...] > A typical C++ ORB does not need to do anything like this. In my > previous > experience with C++ ORBs, most of the ORB machinery is shared > globally, > so there is no question about creating multiple ORB instances. I think that those ORBs are not compliant with the current state of CORBA. With the C++ mapping each call to ORB_init with a unique ORB id must return a new ORB. > 2. I should not have used the term "ORB ID" in my previous email. This clearly > has a somewhat different meaning than I intended. Chapter 4 seems to > regard the ORB ID more as an indicator of which ORB implementation to > use rather than a specific ORB instance of an ORB implementation. I have an issue with that. That's not my understand of what the purpose of an ORB id is... > In Java, > we use ORBClass to define the implementation. > > I think it would be better to simply call what I am discussing an > "ORB name" > to avoid confusion with ORB id in chapter 4 of the CORBA spec. > > So, the problem is simply this: I have orb1 and orb2 using different > > interceptors (for example), and I create persistent poa1 on orb1 and > poa2 on orb2, > each with the same adapter name "foo". > If we agree that orb1 and orb2 are independent orbs, poa1 and poa2 > are in fact > different poas on the orbs, and any object references that poa1 and > poa2 > create are distinct. It may also be crucial to the correct > functioning of the > system that requests are always dispatched to the "same" orb that > created > the objects in the first place. This is where an ORB name is > needed, as otherwise > I see no way to create an ORB identity that can be used in the > object and > that stays the same each time the process implementing these objects > is > restarted. Since this is discussing processes again, I think that this is "beyond the scope". I simply don't think we should have a standard way of defining this -- unless you want to start talkin about how Implementation Repositories work. > Ken. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: java-rtf@OMG.ORG Subject: RE: Discussion on issue 3204 Date: Wed, 1 Mar 2000 14:26:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: KGFe9;)\d9;2Od9=~Oe9 > From: Matthew Newhook [mailto:matthew@ooc.com] > > A typical C++ ORB does not need to do anything like > this. In my previous > > experience with C++ ORBs, most of the ORB machinery is > shared globally, > > so there is no question about creating multiple ORB instances. > > I think that those ORBs are not compliant with the current > state of CORBA. > With the C++ mapping each call to ORB_init with a unique ORB id must > return a new ORB. These two views aren't really in disagreement. Yes, each call with a unique ORB id must return a new ORB, if it succeeds. But the code implementing ORBinit need only support the ORB ids it wishes to support. > > 2. I should not have used the term "ORB ID" in my previous > email. This clearly > > has a somewhat different meaning than I intended. > Chapter 4 seems to > > regard the ORB ID more as an indicator of which ORB > implementation to > > use rather than a specific ORB instance of an ORB > implementation. > > I have an issue with that. That's not my understand of what > the purpose of > an ORB id is... It is my understanding that these *are* intended to reflect different orb implementations or packages of functionality, or something. For example, I could imagine that OOC might accept one ORB id for its older BOA based orb and a different ORB id for its newer POA based ORB. (Now, whether is is feasible for those to coexist in one library with a single implementation of var types and other things that aren't governed by the orb selection is another issue.) Conceptually, you might want to initialize one ORB with id "orbacus" and another with id "orbix" in the same process, but I don't think that is technically feasible in C++. (In Java the story is clearly different because there is a much higher level of standardization between implementations.) I am curious to hear how others have interpretted ORBid. Paul Date: Wed, 1 Mar 2000 16:25:43 -0330 From: Matthew Newhook To: Paul Kyzivat Cc: java-rtf@OMG.ORG Subject: Re: Discussion on issue 3204 Message-ID: <20000301162543.B2675@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BCA7@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BCA7@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ]6j!!Q?@e96~~e9~75e9 Hi Paul, On Wed, Mar 01, 2000 at 02:26:47PM -0500, Paul Kyzivat wrote: > It is my understanding that these *are* intended to reflect > different orb > implementations or packages of functionality, or something. > > For example, I could imagine that OOC might accept one ORB id for > its older > BOA based orb and a different ORB id for its newer POA based ORB. > (Now, whether is is feasible for those to coexist in one library > with a > single implementation of var types and other things that aren't > governed by > the orb selection is another issue.) > > Conceptually, you might want to initialize one ORB with id "orbacus" > and > another with id "orbix" in the same process, but I don't think that > is > technically feasible in C++. (In Java the story is clearly different > because > there is a much higher level of standardization between > implementations.) > > I am curious to hear how others have interpretted ORBid. Please see the discussion thread "Proposal for 3055" on the C++ revision RTF. This thread addressed this exact issue. > > Paul Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Reply-To: From: "Nick Sharman" To: "Paul Kyzivat" , Subject: RE: Discussion on issue 3204 Date: Thu, 2 Mar 2000 08:56:57 -0000 Message-ID: <003401bf8425$43f2b860$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BCA7@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Z$>!!d9?e9W?B!!:kF!! Paul, > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > From: Matthew Newhook [mailto:matthew@ooc.com] > > > > A typical C++ ORB does not need to do anything like > > this. In my previous > > > experience with C++ ORBs, most of the ORB machinery is > > shared globally, > > > so there is no question about creating multiple ORB instances. > > > > I think that those ORBs are not compliant with the current > > state of CORBA. > > With the C++ mapping each call to ORB_init with a unique ORB id must > > return a new ORB. > > These two views aren't really in disagreement. > Yes, each call with a unique ORB id must return a new ORB, > if it succeeds. > > But the code implementing ORBinit need only support the ORB ids > it wishes to > support. > > > > 2. I should not have used the term "ORB ID" in my previous > > email. This clearly > > > has a somewhat different meaning than I intended. > > Chapter 4 seems to > > > regard the ORB ID more as an indicator of which ORB > > implementation to > > > use rather than a specific ORB instance of an ORB implementation. > > > > I have an issue with that. That's not my understand of what > > the purpose of > > an ORB id is... > > It is my understanding that these *are* intended to reflect different orb > implementations or packages of functionality, or something. > > For example, I could imagine that OOC might accept one ORB id for > its older > BOA based orb and a different ORB id for its newer POA based ORB. > (Now, whether is is feasible for those to coexist in one library with a > single implementation of var types and other things that aren't > governed by > the orb selection is another issue.) > > Conceptually, you might want to initialize one ORB with id "orbacus" and > another with id "orbix" in the same process, but I don't think that is > technically feasible in C++. (In Java the story is clearly > different because > there is a much higher level of standardization between implementations.) > > I am curious to hear how others have interpretted ORBid. > > Paul > Well, our C/C++ ORB just ignores this parameter; there's only one ORB in the universe! However, sec 4.6 says that "ORBid strings other than the empty string are allocated by ORB administrators...". To me, the term "ORB administrator" suggests a role in the user organization, like "system administrator". So rather than ORB ids being used to distinguish different vendor products or even product versions, perhaps they should distinguish (say) the "testing" ORB from the "accounts" ORB from the ... That is, they distinguish some sort of top-level domains. Of course, given interoperability, these domains aren't necessarily isolated, so how might they be different? One way is that ORB::resolve_initial_references() yields the same objects everywhere in the same ORB (domain), unless overriden by -ORB parameters as per INS. Of course, we use "ORB" loosely in a number of ways - A. a complete product ("orbacus" vs. "orbix") B. a distinct implementations from a single vendor ("BOA ORB" vs. "POA ORB"), C. an instances of a progamming language type ("org.omg.CORBA.ORB anOrb = org.omg.CORBA.ORB.init();"), D. or the rather amorphous blob at the bottom of Fig 1.2 in the spec. To me, sec 4.6 appears to use "ORBid" to distinguish type-D entities. Are the authors of this section around to interpret it, or are we all just reading the runes? The "org.omg.CORBA.ORBClass" property would seem to be a separate issue, tho' each vendor's could support a different interpretation of any -ORBid parameter. If so, it's a pity the Java mapping doesn't support a separate "String orb_identifier" argument as in the PIDL, C and C++. Regards Nick Date: Tue, 15 Feb 2000 10:30:26 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Discussion on issue 3204 To: java-rtf@omg.org Cc: rip-dev@eng.sun.com, Peter.Walker@eng.sun.com MIME-Version: 1.0 Content-MD5: 4gtqZ5vn3Byfnp2Vewv0qw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: +XR!!~k8e9>BG!!d0ad9 Issue 3204 asks what should the Java mapping do about the ORB ID as defined in the CORBA 2.3.1 specification. I have an additional problem to consider related to this issue: Suppose an application creates two ORB instances by calling ORB init, call these orb1 and orb2. Further suppose that the application creates poa1 on orb1 and poa2 on orb2, each POA with the LifeSpan policy set to PERSISTENT. While this is a perfectly legal set of operations, it is questionable how useful it is with most current Java ORBs. However, it is a legal sequence of operations, and must therefore work correctly. Moreover, future CORBA standards will make the use of multiple ORBs more likely. First, the policy framework as defined and extended by messaging allows associating policies with ORBs that apply to all POAs and objects created within the ORB. Multiple ORBs may be useful for multiple policy support. Portable interceptors will also make multiple ORBs useful, since all interceptors are registered at the ORB level. An application needing different sets of interceptors may require different ORBs. How is it then possible for the ORB to correctly dispatch requests to objects implemented by each of these persistent POAs? The requirements of the Java mapping as already discussed for issue 3204 essentially require that poa1 and poa2 be completely independent of each other. In fact, even if both POAs have the same name, they should be indepedent and produce different object references. This essentially requires that each ORB have a unique ID. The current Java mapping does not define a standard mechanism for associating any kind of ID with an ORB. Supporting persistent POAs also requires persistent ORB IDs, i.e. each time the server is restarted, the same ID must be assigned to the server, ORB, POAs, and anything else needed to define the object reference, particularly the object key in most implementations. Since we cannot depend on initialization order, the only reasonable possibility seems to be to include the ORB ID concept in the Java mapping. I propose that we do this as follows in the current IDL to Java mapping as defined in ptc/00-01-08: 1. Define a new standard property in section 1.21.9.1 org.omg.CORBA.ORBID which can also be passed as an argument of the form -ORBID to orb.init( String[] args, Properties props ). While it would also work to define a new orb.init( String ID, String[] args, Properties props ) (and an equivalent applet form), this change is simpler and does not define new APIs. 2. Assign a default value of "DefaultORB" (or something else, so long as it's fixed) to ORBID. This would be the value that the ORBID would have if not explicitly set, as in all existing Java ORBs. 3. Permit the creation of multiple ORBs with the same ID, to be backward compatible with the current specification. Another alternative would be to only allow multiple ORBs with the default ORB ID. 4. If an attempt is made to create persistent POAs in multiple ORBs where the ORBs have the same ID, the ORB may (but the standard should probably not require this) detect and raise a standard exception OBJ_ADAPTER with some standard TBD minor code. I believe that it is useful to define this behavior in the standard, rather than to treat this as part of a proprietary implementation. Standardizing an ORBID mechanism for the Java mapping improves the portability of programs, as otherwise it is difficult to see how the multiple persistent POAs on multiple ORBs problem can be solved in a portable fashion. I think some discussion is required both for this problem and for my proposed change. Thanks, Ken. Date: Tue, 4 Dec 2001 13:21:53 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Proposed resolution for issue 3204 To: java-rtf@omg.org Cc: ken.cavanaugh@sun.com MIME-Version: 1.0 Content-MD5: PuuJeBPExgbKvpHcKmjvLQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: k9ad9G8Ud9;#4e9lhSd9 Issue 3204 was raised to ask for clarification of the meaning of the ORB id and the semantics of ORB.init in the java mapping. Quite a while ago I proposed a possible resolution for this issue. I think the time has come to close this issue, since the problems have been resolved elsewhere. The biggest part of my old proposal was to create a standard property for defining the ORB id in an ORB.init call. This has been addressed in the object reference template specification (see ptc/01-08-31 section 21.3.14.5, which calls out the special Java case since the Java mapping does not map the orb_identifier parameter in the CORBA::ORB_init operation). The other parts of my proposal were to address questions of creating multiple ORBs in Java with the same ID. Note that this is only possible in the Java mapping, since every call to ORB.init returns a new ORB. I think we can simply leave this undefined for now, as stated in the same section noted above in the ORT specification. At this point, I see no further need to address this issue. If there are no other comments on this, I will put a proposed resolution to close this issue no change in the next vote. Thanks, Ken.