Issue 3234: What should an ORB do when it does not find any profile in an IOR (interop) Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com) Nature: Uncategorized Issue Severity: Summary: As per the discussion in the Interop RTF meeting in Mesa, it was decided to split up 2457 into two parts as follows: Part 1: What should an ORB do when it does not find any profile in an IOR that it is able to use? This should usually not happen in a CORBA interoperability compliant ORB, but the possibility should be covered in the spec anyway. Resolution: to close with agreed resolution Revised Text: 1. In Chapter 4 of Core in the table of standard minor codes add the following: a. Under TRANSIENT add the line (OMG staff needs to use the next available minor code as <j>: --- <j> No usable profile in IOR b. Under IMP_LIMIT add line (OMG staff needs to use the next available minor code as <k>: --- <k> Unable to use any profile in IOR 2. Immediately following the first paragraph after the module IOP IDL in section 13.6.2, starting with "Object references have at least one tagged profile.", insert the following paragraph: "An ORB may be unable to use any of the profiles provided in an IOR for various reasons which may be broadly categorized as transient ones like temporary network outage, and non-transient ones like unavailability of appropriate protocol software in the ORB. The decision about the category of outage that causes an ORB to be unable to use any profile from an IOR is left up to the ORB. At an appropriate point, when an ORB discovers that it is unable to use any profile in an IOR, depending on whether it considers the reason transient or non-transient, it should raise the standard system exception TRANSIENT with standard minor code <j>, or IMP_LIMIT with the standard minor code <k>." Actions taken: January 18, 2000: received issue October 4, 2000: closed, approved in vote 1 October 4, 2000: closed issue Discussion: There is no way for an ORB to know theintended use of an IOR when it is received. indeed, it may even be difficult for an application to know whether it wants to use an IOR to invoke an operation or it simply wants to pass it on as a parameter in another operation invocation a-priori. There potentially are two parts to this issue: (i) What should an ORB do when it receives an IOR that contains no profile that it knows anything about. (ii) What should an ORB do when an attempt is made to invoke an operation using an IOR which contains no profiles that the ORB understands at the point the invocation is attempted. The primary focus of this issue in my opinion should be (ii), since (i) is covered by issue 3303. You can either accept and stash away such an IOR or you can reject it, and the resolution of 3303 will cover that. There was an extended discussion on what standard exception should be raised when an attempt is made to invoke an operation using an IOR that contains no understandable profiles/components, in which TRANSIENT, INV_OBJREF, IMP_LIMIT, etc. were considered. The bottom line here is that not finding a working profile is one of several possible reasons why an attempt to do an invocation might fail. The other reasons could be temporary outage in network, or permanently bad IP address in the IOR, or a bunch of other things, many of which are not even clearly recognizable at a given point in time. Perhaps, it is reasonable to see if one can clearly divide the failure causes into those that the ORB believes are recoverable (e.g. I know the profile, but can't raise the target), and those that it definitely knows are not recoverable (e.g. no understandable profile/component in IOR), and based on that raise either a TRANSIENT or a IMP_LIMIT standard exception respectively, with specific new standard minor code. End of Annotations:===== Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, interop@omg.org Subject: Issue 2457 redux Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gAA!!Ul#e9(*H!!%*e!! As per the discussion in the Interop RTF meeting in Mesa, it was decided to split up 2457 into two parts as follows: Part 1: What should an ORB do when it does not find any profile in an IOR that it is able to use? This should usually not happen in a CORBA interoperability compliant ORB, but the possibility should be covered in the spec anyway. Sender: jis@fpk.hp.com Message-ID: <389F3929.5DA6FB40@fpk.hp.com> Date: Mon, 07 Feb 2000 16:29:13 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: interop@omg.org Subject: Issue 2457 part a proposed resolution Content-Type: multipart/mixed; boundary="------------D0DCC56170DFB7EFC6D6C396" X-UIDL: [f%e9^=\!!@@ad9!o[!! Folks, I took away an action item from the Mesa Interop RTF meeting, to (1) propose a split of issue 2457 into the two distinct issues that it contains. I have represented this in the attached in the form of part (a) and part (b) of the issue, and (2) to come up with a proposed resolution for part (a). Attached is a proposed resolution that we put together for your consideration and further discussion. Please take a look at it and post your comments on the Interop RTF mailing list. Thanks, Michi and Jishnu Issue 2457: Unknown parts of an IOR and interoperability (interop) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: Summary: There is currently a heated discussion in comp.object.corba about interoperability (Subject: Naming Service Interoperability). In a nutshell, the argument is about whether, if I send an object reference created by ORB A as a parameter to ORB B, whether or not ORB B is a) obliged to accept that reference as a valid parameter b) obliged to return me the same reference I sent (in the sense that the reference is functionally equivalent) when it returns that reference as a parameter to me c) obliged to preserve the contents of the reference if it goes though a cycle of object_to_string/string_to_object in ORB B. Now, my argument in this thread is that if an ORB doesn"t behave in line with the above three points, interoperability is completely lost because I could never be guaranteed that I can, for example, expect to be able to store an IOR in a Naming Service and have that work. Resolution: This issue has two parts: a) Whether an ORB that is compliant with CORBA Interoperability is allowed to drop any profile from an IOR that passes through it. b) If the ORB does not support any of the protocols contained in an IOR that it is trying to invoke an operation on, what does it do. For part (a) we need to look at the original interoperability architecture in Chapter 12. GIOP/IIOP is intended to connected enclaves in an interoperable way. The protocol used within the enclave can be GIOP/IIOP or anything else. The idea is that the bridges into/out of the enclaves maintain enough information to be able to transmit full GIOP/IIOP protocol in the inter-enclave communications. The only way in which this inter-enclave communication can provide transparent interoperability is if the bridges into and out of the enclaves preserve all elements of a message received over the inter-enclave link and a message sent out over the inter-enclave link. An important element in a GIOP message are the IORs that carry information about objects that may be invoked by the recepients of the message. Object references carry information about the contract that the creator of the IOR is willing to enter into with a client the terms of which will govern the interaction between the client and the creator of the IOR. Any modification of the contents of an IOR amounts to changing the terms of the offered contract, which is something that no one should be allowed to do unilaterally, at least in a universal interoperability domain. A common form of such change is dropping or modifying profiles contained in the IOR. The stricture against changing contracts unilaterally implies not dropping profiles from IORs and, further, not even change the order in which the profiles appear in the IOR. This does not preclude such a bridge from transmitting a modified IOR into its own private enclave or domain, but it must maintain enough information about the original IOR so that when an outbound message is sent, from within the enclave onto an inter-enclave link, containing said IOR, it looks exactly the same as the one that was originally received. Currently there are all sorts of confusing words in Chapters 13 and 15 that appear to allow dropping of profiles. This should be clearly disallowed in order to ensure that seamless interoperability is preserved when GIOP/IIOP is used in an inter-enclave connection role, going into the future. Resolution for part (b) is yet to be provided. Revised Text: Resolution for part (a) The most contentious para appears to be the footnote on page 13-16: Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. This has one obvious error: ... might remove all profiles except ones that make such profiles... That sentence doesn't make sense to me. Anyone know what it means? (Which *whats* that make *what* such profiles?) I can see a point in allowing a firewall to rewrite profiles, including adding and dropping them. However, that's no longer just an ORB; it's a bridge of some kind. I think the way around this is that, if I give an object reference to an ORB and ask it to return it to me, that reference must look the same as when I sent it. For now, I would suggest to replace the footnote text with the following text: Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. However, even then when a bridge includes a IOR in a message sent into a domain from which said IOR was received at an earlier point in time, it must ensure that the IOR sent out is exactly the same IOR that was received. In particular, this implies that an ORB that is not acting as a bridge is not permitted to drop profiles at will (see 13.6.2.1), since typically such an ORB sends and receives messages to/from a single domain. Page 13-17, last para of 13.6.2.1: Add the following at the end of the para. An ORB must preserve all profiles of an object reference even if it doesn't not understand the contents of one or more profiles. (This is possible because profiles are encapsulated inside object references and can be treated as an opaque datum by an ORB.) For example, consider an echo operation for object references: interface Echoer { Object echo(in Object o); }; When a client invokes the echo operation and sends an arbitrary object reference, the reference returned by the operation is guaranteed to have all its profiles intact and in the same order as they were present when the reference was sent.(1) This requirements guarantees that, for example, a client can safely store an object reference in a naming service and get that reference back again later without losing information inside the reference. (1) Obviously, this requirement does not apply to bridges, which must be able to add or change profiles in order to bridge between different domains. However, bridging goes beyond merely receiving and retransmitting an IOR as an opaque value. [ I've used (1) here to indicate a footnote. ] Page 13-18, section 13.6.2.3, last bullet: Replace last two bullet points and their preceding paragraph with: Specifications of protocols must describe how the components affect the protocol. In addition, a protocol definition must specify, for each TaggedComponent, whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). Note that optional components, once they have been added to a profile, cannot be dropped by an ORB (see 13.6.2.1). Page 13-18, first para of 13.6.3: Delete the last sentence of this para. Page 13-19, last sentence of 13.6.3.1: Change last sentence to read: The TAG_ORB_TYPE component can appear at most once in any IOR profile. For profiles supporting IIOP 1.1 or greater, it is optionally present. Page 15-51, first nested bullet: Change These rules specify which components are mandatory presence, which are optional presence, and which can be dropped. to read: These rules specify which components are mandatory and which are optional. Page 15-51, 17.7.3, first para: Change first para to read: The following components are part of IIOP 1.1 and 1.2 conformance. All these components are optional. Page 15-52, first para: Change para to read: The following components are part of IIOP 1.2 conformance. All these components are optional. Revised text for resolution of part (b) yet to be provided Actions taken: February 19, 1999: received issue August 18, 1999: moved from core revision to interop To: Paul Kyzivat cc: karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Tue, 25 Jan 2000 14:42:28 PST." <9B164B713EE9D211B6DC0090273CEEA9140312@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Feb7.165924pst."3624"@watson.parc.xerox.com> Date: Mon, 7 Feb 2000 16:59:30 PST Content-Type: text X-UIDL: "J?e9K2[d9CPRd9n)fd9 > Bill, > > Could you explain further? Why would an orb "always *potentially* > need to > touch the object"? If an orb is hosting a name service > implementation, why > would it need to ever touch an object that is only used via bind and > resolve? > > Paul Let's get back to this, now that I'm partially unpacked. There's a difference between `live' and `dead' values in CORBA. Most types, like integers, are dead; all of their operations are agreed upon from their semantics. The only really live type of data we have is the object; all useful operations on objects are performed by calling back to their implementation; even the so-called attributes are really method calls, even narrowing typically includes an "is_a" call. When my ORB receives an object reference, it is going to instantiate a proxy object to pass to arbitrary application code. It has no idea what that application code implements. The only reasonable expectation for an ORB to have is that the application code will have to call methods on the object. If an IOR for the object contains no useful profiles, there is no way to call methods on the object. Any call will fail with COMM_FAILURE. My ORB won't even create a proxy for such an object; instead, it will reject the object reference with an INV_OBJREF error, which I think is the only sane thing to do. Remember, it doesn't know that the application code is an implementation of CosNaming, only that it's an application that expects to receive a working object. It's actually even worse for ILU. ILU really implements a bridge between ILU objects and CORBA objects. It depends on having accurate, up-to-date type information for an object reference, which the IOR doesn't necessarily provide. So it depends on being able to interrogate the object via is_a. With no useful profiles, that interrogation can't be done. It's a shame that the Naming Service was specified to work with `live' objects, instead of `dead' stringified IORs, which would have avoided this problem. However, it's not really such a big problem. Any system which is going to register objects from one ORB with a naming service provided by another ORB, should indeed be using Interoperability, and IIOP, even if it uses another more efficient protocol within its own domain. Another possibility would be to put CosNaming `inside the ORB', which means that it wouldn't be implemented as a standard CORBA application. Bill From: "Carlos O'Ryan" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <14495.30450.254641.103423@kelvar.ece.uci.edu> Date: Mon, 7 Feb 2000 17:52:50 -0800 (PST) To: Bill Janssen Cc: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: <00Feb7.165924pst."3624"@watson.parc.xerox.com> References: <9B164B713EE9D211B6DC0090273CEEA9140312@bos1.noblenet.com> <00Feb7.165924pst."3624"@watson.parc.xerox.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Sender: "Carlos O'Ryan" Content-Type: text/plain; charset=us-ascii X-UIDL: 1[]d97+8e9,f-e9*5(!! Hi Bill, Bill Janssen writes: > > When my ORB receives an object reference, it is going to instantiate a > proxy object to pass to arbitrary application code. It has no idea > what that application code implements. The only reasonable > expectation for an ORB to have is that the application code will have > to call methods on the object. Nope, the application *may* call methods on the object, but it may also send the object reference to a third party that invokes the methods. > If an IOR for the object contains no > useful profiles, there is no way to call methods on the object. Any > call will fail with COMM_FAILURE. Sure. > My ORB won't even create a proxy > for such an object; instead, it will reject the object reference with > an INV_OBJREF error, which I think is the only sane thing to do. I don't think so, the ORB can store all the profiles (as sequences of octets) and pass those object references around without using them. > Remember, it doesn't know that the application code is an > implementation of CosNaming, only that it's an application that > expects to receive a working object. It doesn't know that the application expects a working object either. Only that an object reference is needed, if the object reference is used or not that is another story. > It's actually even worse for ILU. ILU really implements a bridge > between ILU objects and CORBA objects. It depends on having accurate, > up-to-date type information for an object reference, which the IOR > doesn't necessarily provide. So it depends on being able to > interrogate the object via is_a. With no useful profiles, that > interrogation can't be done. That is an ILU specific problem, right? Some people may even call that a bug... > It's a shame that the Naming Service was specified to work with `live' > objects, instead of `dead' stringified IORs, which would have avoided > this problem. Many other services work that way, Trading is another one. > However, it's not really such a big problem. Any > system which is going to register objects from one ORB with a naming > service provided by another ORB, should indeed be using > Interoperability, and IIOP, even if it uses another more efficient > protocol within its own domain. Right, but it would be nice (and i don't know if the spec actually requires this or not) that when the object is fetched back from the Naming service the ORB can use the best protocol available. -- Carlos O'Ryan (coryan@uci.edu) #include #include // "Speak softly and carry a megawatt laser" 1024D/46936992 33B3 C4ED AA90 FA0F E8D1 D509 FE5E 8F79 4693 6992 To: "Carlos O'Ryan" cc: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Mon, 07 Feb 2000 17:54:19 PST." <14495.30450.254641.103423@kelvar.ece.uci.edu> From: Bill Janssen Message-Id: <00Feb7.182020pst."3624"@watson.parc.xerox.com> Date: Mon, 7 Feb 2000 18:20:31 PST Content-Type: text X-UIDL: ;\Xd9pLnd9CV\d9jGLe9 > That is an ILU specific problem, right? Some people may even call > that a bug... Wow! ...and here I was thinking that supporting IIOP was the bug :-). Bill Sender: jon@corvette.floorboard.com Message-ID: <389FAB94.F7955E0C@floorboard.com> Date: Mon, 07 Feb 2000 21:37:24 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux References: <00Feb7.165924pst."3624"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =Zm!!\ogd9,&hd9iNIe9 Bill Janssen wrote: > > > Bill, > > > > Could you explain further? Why would an orb "always *potentially* > need to > > touch the object"? If an orb is hosting a name service > implementation, why > > would it need to ever touch an object that is only used via bind > and > > resolve? > > > > Paul > > Let's get back to this, now that I'm partially unpacked. > > There's a difference between `live' and `dead' values in CORBA. > Most > types, like integers, are dead; all of their operations are agreed > upon from their semantics. The only really live type of data we > have > is the object; all useful operations on objects are performed by > calling back to their implementation; even the so-called attributes > are really method calls, even narrowing typically includes an "is_a" > call. > > When my ORB receives an object reference, it is going to instantiate > a > proxy object to pass to arbitrary application code. It has no idea > what that application code implements. The only reasonable > expectation for an ORB to have is that the application code will > have > to call methods on the object. If an IOR for the object contains no > useful profiles, there is no way to call methods on the object. Any > call will fail with COMM_FAILURE. My ORB won't even create a proxy > for such an object; instead, it will reject the object reference > with > an INV_OBJREF error, which I think is the only sane thing to do. > Remember, it doesn't know that the application code is an > implementation of CosNaming, only that it's an application that > expects to receive a working object. No, I disagree. Your implementation precludes useful behavior by assuming that the receiving ORB will always invoke an operation on any given object reference. > It's actually even worse for ILU. ILU really implements a bridge > between ILU objects and CORBA objects. It depends on having > accurate, > up-to-date type information for an object reference, which the IOR > doesn't necessarily provide. So it depends on being able to > interrogate the object via is_a. With no useful profiles, that > interrogation can't be done. Why must it depend on up to date information? If it can't interpret any of the profiles, it should just accept whatever RepositoryId is in the IOR and live with it. What difference would doing that be over getting a valid is_a response with the same RepositoryId? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Tue, 8 Feb 2000 08:22:10 +0100 Message-Id: In-Reply-To: <00Feb7.165924pst."3624"@watson.parc.xerox.com> Subject: Re: Issue 2457 redux MIME-Version: 1.0 TO: janssen@parc.xerox.com CC: interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com, karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Tue, 8 Feb 2000 07:46:47 +0100" ;Modification-Date="Tue, 8 Feb 2000 08:22:10 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 8 Feb 2000 07:46:47 +0100" ;Modification-Date="Tue, 8 Feb 2000 08:22:10 +0100" X-UIDL: pim!!l5dd9UW)!!W2[!! > > When my ORB receives an object reference, it is going to > instantiate > a proxy object to pass to arbitrary application code. It has no idea ...when your ORB behaves less interoperable than other ORBs why should I decide to buy yours? (...and there are many other ORBs around which do NOT touch the object in case they don't need to touch it). > what that application code implements. The only reasonable > expectation for an ORB to have is that the application code will > have > to call methods on the object. Actually there is NO common expectation to call methods on an object which does not need to be invoked. > If an IOR for the object contains no > useful profiles, there is no way to call methods on the object. Any > call will fail with COMM_FAILURE. My ORB won't even create a proxy > for such an object; instead, it will reject the object reference > with > an INV_OBJREF error, which I think is the only sane thing to do. You are right, it's the only sane thing to do for objects which your ORB should touch. > Remember, it doesn't know that the application code is an > implementation of CosNaming, only that it's an application that > expects to receive a working object. > It's actually even worse for ILU. ILU really implements a bridge > between ILU objects and CORBA objects. It depends on having > accurate, > up-to-date type information for an object reference, which the IOR > doesn't necessarily provide. So it depends on being able to > interrogate the object via is_a. With no useful profiles, that > interrogation can't be done. > Change ILU. > It's a shame that the Naming Service was specified to work with `live' > objects, instead of `dead' stringified IORs, which would have avoided > this problem. However, it's not really such a big problem. Any > system which is going to register objects from one ORB with a naming > service provided by another ORB, should indeed be using > Interoperability, and IIOP, even if it uses another more efficient > protocol within its own domain. > > Another possibility would be to put CosNaming `inside the ORB', which > means that it wouldn't be implemented as a standard CORBA application. > > Bill > I guess you know that it does... * neither make sense changing parts of the specification back in order to conform to specific ORBs * nor not changing the specification at all. If this issue won't be resolved in the 'right' direction (IMO the direction of customers' needs) we can kiss all interoperability goodbye. Karsten From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 2457 part a proposed resolution Date: Tue, 8 Feb 2000 09:16:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: hiJ!!6&$!!67R!!$p7!! Nice job! Barring some major new argument from the other side, I can support this. Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Monday, February 07, 2000 4:29 PM > To: interop@omg.org > Subject: Issue 2457 part a proposed resolution > > > Folks, > > I took away an action item from the Mesa Interop RTF meeting, > to (1) propose a split of issue 2457 > into the two distinct issues that it contains. I have > represented this in the attached in the form > of part (a) and part (b) of the issue, and (2) to come up > with a proposed resolution for part (a). > > Attached is a proposed resolution that we put together for > your consideration and further > discussion. Please take a look at it and post your comments > on the Interop RTF mailing list. > > Thanks, > > Michi and Jishnu > Date: Tue, 08 Feb 2000 15:23:42 +0000 From: Owen Rees Cc: interop@omg.org Subject: Re: Issue 2457 redux Message-ID: <835650444.950023422@localhost> In-Reply-To: <00Feb7.165924pst."3624"@watson.parc.xerox.com> X-Mailer: Mulberry/2.0.0b8 (Win32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: +]5!![do!!5\=!!D;3e9 --On 07 February 2000 16:59 +0000 Bill Janssen wrote: > It's a shame that the Naming Service was specified to work with `live' > objects, instead of `dead' stringified IORs, which would have avoided > this problem. However, it's not really such a big problem. Any > system which is going to register objects from one ORB with a naming > service provided by another ORB, should indeed be using > Interoperability, and IIOP, even if it uses another more efficient > protocol within its own domain. > > Another possibility would be to put CosNaming `inside the ORB', which > means that it wouldn't be implemented as a standard CORBA application. > I am dredging up some ancient memories here, but I seem to remember that the whole point about object-based distributed computing, that distinguished it from the plain RPC that we had before, was that "object references" were first-class values that could be passed around as parameters. It was no longer necessary for application code to perform some magic on 'dead' data to invoke something remote. The naming service no longer needed to be wired into the infrastucture by some special mechanism, but could be implemented as an application. Passing "object references" explicitly rather than indirectly through some 'dead' type is also what makes it possible for a bridge to replace a reference to an object that works in the enclave on one side, with a reference to the same object that works on the other. It is unfortunate that this was (and under the proposed revision will still be) described in terms of changing profiles with the implication that the reference is in some sense the same, rather than it being a different reference to the same object. It seems to me that it should be acceptable for an ORB to alter profiles it understands provided that the functionality is preserved - e.g. updating stale data if it becomes aware that the referenced object has moved - but it should not modify or remove profiles it does not understand. I think that the proposed revision would prohibit the kind of behaviour I have just suggested, but that may be necessary to ensure that compliant ORBs do not have behaviour that restricts interworking in heterogeneous environments. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: jis@fpk.hp.com Message-ID: <38A049D9.11C6BB12@fpk.hp.com> Date: Tue, 08 Feb 2000 11:52:41 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Owen Rees Cc: interop@omg.org Subject: Re: Issue 2457 redux References: <835650444.950023422@localhost> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J7Ud9PRBe9Y-%!!@5*!! Owen Rees wrote: > > --On 07 February 2000 16:59 +0000 Bill Janssen > > wrote: > > > It's a shame that the Naming Service was specified to work with > `live' > > objects, instead of `dead' stringified IORs, which would have > avoided > > this problem. However, it's not really such a big problem. Any > > system which is going to register objects from one ORB with a > naming > > service provided by another ORB, should indeed be using > > Interoperability, and IIOP, even if it uses another more efficient > > protocol within its own domain. > > > > Another possibility would be to put CosNaming `inside the ORB', > which > > means that it wouldn't be implemented as a standard CORBA > application. > > > > I am dredging up some ancient memories here, but I seem to remember > that > the whole point about object-based distributed computing, that > distinguished it from the plain RPC that we had before, was that > "object > references" were first-class values that could be passed around as > parameters. It was no longer necessary for application code to > perform some > magic on 'dead' data to invoke something remote. The naming service > no > longer needed to be wired into the infrastucture by some special > mechanism, > but could be implemented as an application. > > Passing "object references" explicitly rather than indirectly > through some > 'dead' type is also what makes it possible for a bridge to replace a > reference to an object that works in the enclave on one side, with a > reference to the same object that works on the other. It is > unfortunate > that this was (and under the proposed revision will still be) > described in > terms of changing profiles with the implication that the reference > is in > some sense the same, rather than it being a different reference to > the same > object. Coming to think of it, I don't think the proposal that Michi and I put out yesterday actually prevents anyone from publishing an entirely different IOR to the same object with different things in it. For example a bridge can insert itself in the invocation path by publishing a new IOR pointing to itself, and all invocation through that IOR will then bounce through the bridge. The only thing we are trying to ensure is that something that claims to be the *same* IOR is actually the same IOR. We tried to capture this using the notion of interoperability domains or enclaves in the proposal. > It seems to me that it should be acceptable for an ORB to alter profiles it > understands provided that the functionality is preserved - e.g. updating > stale data if it becomes aware that the referenced object has moved - but > it should not modify or remove profiles it does not understand. Agreed. But the real problem standing in the way of achieving this is characterizing what "preservation of functionality" means in a universally testable way. It may be possible to allow specific such changes, like updating location etc., but that is a slightly different discussion. Any ideas on how to fine tune the proposal would be most welcome. > I think > that the proposed revision would prohibit the kind of behaviour I > have just > suggested, but that may be necessary to ensure that compliant ORBs > do not > have behaviour that restricts interworking in heterogeneous > environments. It is possible that the proposal goes further than it needs to. That is why it has been put out for discussion. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. To: Jonathan Biggar cc: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Mon, 07 Feb 2000 21:51:12 PST." <389FAB94.F7955E0C@floorboard.com> From: Bill Janssen Message-Id: <00Feb8.181528pst."3635"@watson.parc.xerox.com> Date: Tue, 8 Feb 2000 18:15:36 PST Content-Type: text X-UIDL: KSNe938K!!d4/!!(`D!! > Why must it depend on up to date information? If it can't interpret any > of the profiles, it should just accept whatever RepositoryId is in the > IOR and live with it. What difference would doing that be over getting > a valid is_a response with the same RepositoryId? What's happening (and this is just an ILU thing, it's not a CORBA thing) is that ILU attempts, fairly strenuously, to preserve eq-ness of object references. It believes in strong identities for objects. One of the consequences of this design is that you do not want to hand out two different proxies for the same object. So when you have an object that provides multiple interfaces, you want to create a proxy for that object which has the most-derived type. So you'd be unhappy with the limp information possible in IORs. Bill Sender: jon@corvette.floorboard.com Message-ID: <38A0CE08.804AE537@floorboard.com> Date: Tue, 08 Feb 2000 18:16:41 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux References: <00Feb8.181528pst."3635"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4CS!!;a]d9SQ*!!R@d!! Bill Janssen wrote: > > > Why must it depend on up to date information? If it can't > interpret any > > of the profiles, it should just accept whatever RepositoryId is in > the > > IOR and live with it. What difference would doing that be over > getting > > a valid is_a response with the same RepositoryId? > > What's happening (and this is just an ILU thing, it's not a CORBA > thing) is that ILU attempts, fairly strenuously, to preserve eq-ness > of object references. It believes in strong identities for objects. > One of the consequences of this design is that you do not want to > hand > out two different proxies for the same object. So when you have an > object that provides multiple interfaces, you want to create a proxy > for that object which has the most-derived type. So you'd be > unhappy > with the limp information possible in IORs. Sure, but I don't see what the harm is in living with the "limp" information in an IOR that you can't contact anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: karsten-oliver.starr@ubs.com cc: interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Mon, 07 Feb 2000 23:29:23 PST." From: Bill Janssen Message-Id: <00Feb8.181833pst."3635"@watson.parc.xerox.com> Date: Tue, 8 Feb 2000 18:18:36 PST Content-Type: text X-UIDL: [^@e9O]1!![EE!!~$)!! > > If an IOR for the object contains no > > useful profiles, there is no way to call methods on the object. > Any > > call will fail with COMM_FAILURE. My ORB won't even create a > proxy > > for such an object; instead, it will reject the object reference > with > > an INV_OBJREF error, which I think is the only sane thing to do. > You are right, it's the only sane thing to do for objects which your > ORB should touch. But that's the key problem. My ORB has no way of knowing whether that application code will need to make calls on the object -- there's no way of knowing whether or not the ORB should touch it. > If this issue won't be resolved in the 'right' direction (IMO the > direction of customers' needs) we can kiss all interoperability > goodbye. Now that's just nonsense. Interoperability works fine, with the following rule: If you want to mix two ORBs, use IIOP. That's the CORBA design for interoperability, in fact. So whatever side `customer's needs' fall on, interoperability is assured. Bill To: Owen Rees cc: ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Tue, 08 Feb 2000 07:32:49 PST." <835650444.950023422@localhost> From: Bill Janssen Message-Id: <00Feb8.182159pst."3635"@watson.parc.xerox.com> Date: Tue, 8 Feb 2000 18:22:07 PST Content-Type: text X-UIDL: >6G!!m8V!!8?A!!\=@!! > I am dredging up some ancient memories here, but I seem to remember that > the whole point about object-based distributed computing, that > distinguished it from the plain RPC that we had before, was that "object > references" were first-class values that could be passed around as > parameters. It was no longer necessary for application code to perform some > magic on 'dead' data to invoke something remote. The naming service no > longer needed to be wired into the infrastucture by some special mechanism, > but could be implemented as an application. I'm appreciative of this. My point is that CORBA has a working interoperability architecture which achieves this. My view of intent of the resolution under discussion is to change that architecture so that things work together even when they don't support the interoperability architecture. In my mind, that move would weaken the kinds of productive variants of CORBA that could be produced, and generally *degrade* the architecture, rather than strengthen it. Bill From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Wed, 9 Feb 2000 13:43:31 +0100 Message-Id: In-Reply-To: <00Feb8.181833pst."3635"@watson.parc.xerox.com> Subject: Re: Issue 2457 redux MIME-Version: 1.0 TO: janssen@parc.xerox.com CC: interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com, karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Wed, 9 Feb 2000 12:50:26 +0100" ;Modification-Date="Wed, 9 Feb 2000 13:43:30 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 9 Feb 2000 12:50:26 +0100" ;Modification-Date="Wed, 9 Feb 2000 13:43:30 +0100" X-UIDL: p1@e9MkU!!d]De9&NGe9 >>> If an IOR for the object contains no >>> useful profiles, there is no way to call methods on the object. >>> Any >>> call will fail with COMM_FAILURE. My ORB won't even create a >>> proxy >>> for such an object; instead, it will reject the object reference >>> with >>> an INV_OBJREF error, which I think is the only sane thing to do. >> You are right, it's the only sane thing to do for objects which >>> your >> ORB should touch. > > But that's the key problem. My ORB has no way of knowing whether >>> that > application code will need to make calls on the object -- there's no > way of knowing whether or not the ORB should touch it. > No, that's definitely NOT the key problem. The key problem in this discussion is that you do not want to change your ORB. >> If this issue won't be resolved in the 'right' direction (IMO the >> direction of customers' needs) we can kiss all interoperability >> goodbye. > > Now that's just nonsense. Interoperability works fine, with the > following rule: If you want to mix two ORBs, use IIOP. That's the > CORBA design for interoperability, in fact. So whatever side > `customer's needs' fall on, interoperability is assured. I think you did not get the point. This issue is more than just nonsense. Interoperability is more than just IIOP. Interoperability in this case means I am able to use a different ORB's Service. Mixing two ORB does not necessarily mean having a 'nice-weather-interopera- bility' just because both parties speak IIOP. IIOP won't help, if the server-side's ORB rejects proprietary profiles. One of the main aims of CORBA was and hopefully is interoperability. When it really was OMG's purpose to reach this aim - why is this problem a) currently existent and b) not resolved yet ? Bill, let me state the following question to you: Do interoperable ORBs have the right to reject 3'rd party Objects which ought to be reprocessed and which do not need to be invoked (like beeing stored in a 3'rd party Naming- or Trader Service)? Karsten From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 2457 redux Date: Wed, 9 Feb 2000 09:19:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E_Je9+66e9 From: Bill Janssen Message-Id: <00Feb9.122825pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 12:28:28 PST Content-Type: text X-UIDL: N$-!!(l~e9-Tfd9^o+e9 > No, that's definitely NOT the key problem. The key problem in this > discussion is that you do not want to change your ORB. Sorry, I have no qualms about changing my ORB. My concern is about whether Xerox (and other non-ORB-vendors) can build quality systems with CORBA. Bill To: karsten-oliver.starr@ubs.com cc: interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 04:43:59 PST." From: Bill Janssen Message-Id: <00Feb9.123041pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 12:30:48 PST Content-Type: text X-UIDL: \`P!!bb2e9*?2e9X2^!! > Do interoperable ORBs have the right to reject > 3'rd party Objects which ought to be reprocessed > and which do not need to be invoked (like beeing > stored in a 3'rd party Naming- or Trader Service)? Karsten, that's exactly the point I've been trying to make. I think that we should explicitly say in the Interoperability spec that an ORB *must* reject any object reference which does not contain any profiles usable by that ORB. The particular application code involved is immaterial. Bill To: Paul Kyzivat cc: interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 06:15:32 PST." <9B164B713EE9D211B6DC0090273CEEA914034D@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Feb9.124113pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 12:41:21 PST Content-Type: text X-UIDL: OR~e9aKfd9~U?!!/T8!! > I am sure ILU has some valuable characteristics. > But based on this discussion, I surely would not want to use it to > implement > any sort of server that is expected to act as an intermediary, > holding > objects that it does not itself use. > > A reasonable orb for this purpose must in general not make > gratuitous calls > on objects that its applications do not explicitly invoke. > To do so can incur major performance degradation. Absolutely, and ILU has some clever ways of avoiding those problems. But I think discussing specifics of ILU is a red herring here; the problem I'm attempting to raise is generic for all ORBs. Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <38A1E22A.39853B1F@floorboard.com> Date: Wed, 09 Feb 2000 13:54:50 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux References: <00Feb9.124113pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pSC!!R-Ke90dbd980I!! Bill Janssen wrote: > > > I am sure ILU has some valuable characteristics. > > But based on this discussion, I surely would not want to use it to > implement > > any sort of server that is expected to act as an intermediary, > holding > > objects that it does not itself use. > > > > A reasonable orb for this purpose must in general not make > gratuitous calls > > on objects that its applications do not explicitly invoke. > > To do so can incur major performance degradation. > > Absolutely, and ILU has some clever ways of avoiding those problems. > > But I think discussing specifics of ILU is a red herring here; the > problem I'm attempting to raise is generic for all ORBs. Yes, but most of the other ORB vendors (or at least several) are rejecting your position. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 10 Feb 2000 07:54:08 +1000 (EST) From: Michi Henning To: Bill Janssen cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <00Feb9.123041pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9*l!!`g4!!%?Fe9<8U!! On Wed, 9 Feb 2000, Bill Janssen wrote: > > Do interoperable ORBs have the right to reject > > 3'rd party Objects which ought to be reprocessed > > and which do not need to be invoked (like beeing > > stored in a 3'rd party Naming- or Trader Service)? > > Karsten, that's exactly the point I've been trying to make. I think > that we should explicitly say in the Interoperability spec that an > ORB > *must* reject any object reference which does not contain any > profiles > usable by that ORB. The particular application code involved is > immaterial. That's like saying that an English database should reject all Japanese strings that are sent to it, even though the database never needs to understand those strings... If I'm implementing a naming service, which never uses the IORs it stores, I see no reason to reject an IOR just because it contains no profile I understand. After all, I'm never using the IOR and, if I don't reject it, everything works just fine. So, there is no reason to reject it. 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 Sender: Stefan.Wengi@adnovum.com Message-ID: <38A1E049.229D4855@adnovum.com> Date: Wed, 09 Feb 2000 13:46:49 -0800 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.123041pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S@`!!MFid9:RWd9We*e9 Bill Janssen wrote: > > > Do interoperable ORBs have the right to reject > > 3'rd party Objects which ought to be reprocessed > > and which do not need to be invoked (like beeing > > stored in a 3'rd party Naming- or Trader Service)? > > Karsten, that's exactly the point I've been trying to make. I think > that we should explicitly say in the Interoperability spec that an > ORB > *must* reject any object reference which does not contain any > profiles > usable by that ORB. The particular application code involved is > immaterial. I totally agree with Karsten on this one. E.g. it should be possible for one ORB to use another ORBs NamingService even when object references do not contain an IIOP profile. This feature is very important for integration and migration in real enterprises. Stefan Date: Wed, 09 Feb 2000 17:17:30 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.123041pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FP5e907%!!7ood9m\~!! Bill Janssen wrote: > > Do interoperable ORBs have the right to reject > > 3'rd party Objects which ought to be reprocessed > > and which do not need to be invoked (like beeing > > stored in a 3'rd party Naming- or Trader Service)? > > Karsten, that's exactly the point I've been trying to make. I think > that we should explicitly say in the Interoperability spec that an > ORB > *must* reject any object reference which does not contain any > profiles > usable by that ORB. The particular application code involved is > immaterial. If we say that, then it would imply that any ORB that provides name services can store only such IORs that contains at least one profile usable by that ORB. Why would that be desirable? I can understand an ORB raising an exception when an attempt is made to invoke an operation through an IOR that does not contain any profiles that are usable, but I am somewhat dubious about an requirement for rejection of an IOR that contains no profile that the ORB can use at the point it receives the IOR. Seems like the issue is one of whether an eager binding regime is being used or a lazy binding regime is being used. it seems that the rejection at receipt of an IOR is an issue only if an eager binding regime is used. This seems to preclude reception of IORs that the ORB could use in the future due to addition of protocol facilities, and it also seems to make the ORB less than useful as a host for a general naming or trading service. Unless I hear some extremely persuasive argument to convince me otherwise, my tendency would be to vote against such a rejection requirement. I would like to see a clarification made about what exception raising action the ORB should take at the point of invocation of an operation if it finds no usable profile at that point. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. To: Jonathan Biggar cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 13:55:16 PST." <38A1E22A.39853B1F@floorboard.com> From: Bill Janssen Message-Id: <00Feb9.180231pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:02:43 PST Content-Type: text X-UIDL: *_6@!!>Oa!! > Yes, but most of the other ORB vendors (or at least several) are > rejecting your position. Actually, I'm not sure I've heard from many ORB vendors. And I'm not sure they've really thought through the impact of this on their customers. Bill Sender: jon@corvette.floorboard.com Message-ID: <38A2251B.297F7343@floorboard.com> Date: Wed, 09 Feb 2000 18:40:27 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.180132pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ajEe9i35!!CK3!!eK/!! Bill Janssen wrote: > > > That's like saying that an English database should reject all > Japanese > > strings that are sent to it, even though the database never needs > to > > understand those strings... > > I think I'd agree with that position. > > > If I'm implementing a naming service, which never uses the IORs it > stores, > > I see no reason to reject an IOR just because it contains no > profile I > > understand. After all, I'm never using the IOR and, if I don't > reject it, > > everything works just fine. So, there is no reason to reject it. > > That would be fine, if there was some way to tell the ORB that the > application had that peculiarity. Bill, you still haven't answered the fundamental question, which is to tell us what harm it does for an ORB to accept an uninvocable profile, given that applications already have to deal with objects that suddenly don't exist or have unreachable servers? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38A22422.4770C477@floorboard.com> Date: Wed, 09 Feb 2000 18:36:18 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: jis@fpk.hp.com, karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.180426pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^KE!!ihO!!?Z3e9a71e9 Bill Janssen wrote: > > > If we say that, then it would imply that any ORB that provides > name services can > > store only such IORs that contains at least one profile usable by > that ORB. Why > > would that be desirable? > > It's not, for name services, but it's a side-effect of a more > generally desirable principle. Perhaps name services shouldn't be > implemented as simple applications. And why in the world would we want to complicate the CORBA model by requiring name services to be magic? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Jonathan Biggar cc: jis@fpk.hp.com, karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 18:45:05 PST." <38A22422.4770C477@floorboard.com> From: Bill Janssen Message-Id: <00Feb10.151016pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 15:10:18 PST Content-Type: text X-UIDL: (jNd9B^2e9V-i!!e8g!! > And why in the world would we want to complicate the CORBA model by > requiring name services to be magic? It may be the lesser of two evils. Bill From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Tue, 15 Feb 2000 19:41:34 +0100 Message-Id: In-Reply-To: <38A827E2.C0BC760A@fpk.hp.com> Subject: Issue 3234 MIME-Version: 1.0 TO: interop@omg.org CC: karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Tue, 15 Feb 2000 19:11:01 +0100" ;Modification-Date="Tue, 15 Feb 2000 19:41:34 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 15 Feb 2000 19:11:01 +0100" ;Modification-Date="Tue, 15 Feb 2000 19:41:34 +0100" X-UIDL: leT!!='"!!!"]!!8Obd9 My proposal for issue 3234 ("What should an ORB do when it does not find any profile in an IOR?"): In cases where an interoperable ORB is not intended to invoke methods on a specific object it must not reject the object - regardless of whether the IOR contains profiles which the ORB is able to process or not. Any comments on that one? Karsten To: karsten-oliver.starr@ubs.com cc: interop@omg.org Subject: Re: Issue 3234 In-Reply-To: Your message of "Tue, 15 Feb 2000 10:42:31 PST." From: Bill Janssen Message-Id: <00Feb15.110939pst."3731"@watson.parc.xerox.com> Date: Tue, 15 Feb 2000 11:09:47 PST Content-Type: text X-UIDL: 2SA!!\_S!!OAM!!eoSd9 > In cases where an interoperable ORB is not intended > to invoke methods on a specific object it must not > reject the object - regardless of whether the IOR > contains profiles which the ORB is able to process > or not. There's no way to know, from the ORB's perspective, whether or not it is 'not intended to invoke methods on a specific object'. Bill From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Tue, 15 Feb 2000 20:52:59 +0100 Message-Id: In-Reply-To: <00Feb15.110939pst."3731"@watson.parc.xerox.com> Subject: Re: Issue 3234 MIME-Version: 1.0 TO: janssen@parc.xerox.com CC: interop@omg.org, karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Tue, 15 Feb 2000 20:35:32 +0100" ;Modification-Date="Tue, 15 Feb 2000 20:52:59 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 15 Feb 2000 20:35:32 +0100" ;Modification-Date="Tue, 15 Feb 2000 20:52:59 +0100" X-UIDL: @bd!!n,-e9$%A!!@Gjd9 > > In cases where an interoperable ORB is not intended > > to invoke methods on a specific object it must not > > reject the object - regardless of whether the IOR > > contains profiles which the ORB is able to process > > or not. > > There's no way to know, from the ORB's perspective, whether or not > it > is 'not intended to invoke methods on a specific object'. > > Bill > > Well, there is a way: IORs that are beeing passed as a parameter (eg. 'in object') do not necessarily need to be invoked. It's not the ORB's primary intention. It's intention is to pass the object to another one. What about changing the statement into a more generic form: "Interoperable ORBS must not reject objects without having to invoke them - regardless of whether the IOR contains profiles which the ORB is able to process or not." Any comments on that? Karsten Date: Tue, 15 Feb 2000 15:43:56 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: karsten-oliver.starr@ubs.com Cc: interop@omg.org Subject: Re: Issue 3234 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: B_'e9>:>!!f<+!!-a:!! karsten-oliver.starr@ubs.com wrote: > My proposal for issue 3234 ("What should an ORB do > when it does not find any profile in an IOR?"): > > In cases where an interoperable ORB is not intended > to invoke methods on a specific object it must not > reject the object - regardless of whether the IOR > contains profiles which the ORB is able to process > or not. > > Any comments on that one? It is not a workable solution since there is no way for an ORB to know the intended use of an IOR when it is received. indeed, it may even be difficult for an application to know whether it wants to use an IOR to invoke an operation or it simply wants to pass it on as a parameter in another operation invocation a-priori. There potentially are two parts to this issue: (i) What should an ORB do when it receives an IOR that contains no profile that it knows anything about. (ii) What should an ORB do when an attempt is made to invoke an operation using an IOR which contains no profiles that the ORB understands at the point the invocation is attempted. The primary focus of this issue in my opinion should be (ii), since (i) is covered by issue 3303. You can either accept and stash away such an IOR or you can reject it, and the resolution of 3303 will cover that. There was an extended discussion on what standard exception should be raised when an attempt is made to invoke an operation using an IOR that contains no understandable profiles/components, in which TRANSIENT, INV_OBJREF, IMP_LIMIT, etc. were considered. The bottom line here is that, as Bob pointed out, not finding a working profile is one of several possible reasons why an attempt to do an invocation might fail. The other reasons could be temporary outage in network, or permanently bad IP address in the IOR, or a bunch of other things, many of which are not even clearly recognizable at a given point in time. Perhaps, it is reasonable to see if one can clearly divide the failure causes into those that the ORB believes are recoverable (e.g. I know the profile, but can't raise the target), and those that it definitely knows are not recoverable (e.g. no understandable profile/component in IOR), and based on that raise either a TRANSIENT or a IMP_LIMIT standard exception respectively, with specific new standard minor code. Does this form a reasonable basis for constructing a resolution for this issue? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 16 Feb 2000 07:20:13 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: karsten-oliver.starr@ubs.com, interop@omg.org Subject: Re: Issue 3234 In-Reply-To: <38A9BA8B.608D6BA2@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2%%!!jMZd90M>!!SYg!! On Tue, 15 Feb 2000, Jishnu Mukerji wrote: > Perhaps, it is reasonable to see if one can clearly divide the failure causes > into those that the ORB believes are recoverable (e.g. I know the profile, but > can't raise the target), and those that it definitely knows are not recoverable > (e.g. no understandable profile/component in IOR), and based on that raise > either a TRANSIENT or a IMP_LIMIT standard exception respectively, with specific > new standard minor code. > > Does this form a reasonable basis for constructing a resolution for this issue? Most definitely! :-) Cheers, Michi. From: Jeffrey Mischkinsky Message-Id: <200002152202.OAA05301@wheel.dcn.davis.ca.us> Subject: Re: Issue 3234 To: michi@ooc.com.au (Michi Henning) Date: Tue, 15 Feb 2000 14:02:54 -0800 (PST) Cc: jis@fpk.hp.com (Jishnu Mukerji), karsten-oliver.starr@ubs.com, interop@omg.org In-Reply-To: from "Michi Henning" at Feb 16, 2000 07:20:13 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m(>e9IEld9"dR!!4C&!! 'Michi Henning' writes: > > On Tue, 15 Feb 2000, Jishnu Mukerji wrote: > > > Perhaps, it is reasonable to see if one can clearly divide the > failure causes > > into those that the ORB believes are recoverable (e.g. I know the > profile, but > > can't raise the target), and those that it definitely knows are > not recoverable > > (e.g. no understandable profile/component in IOR), and based on > that raise > > either a TRANSIENT or a IMP_LIMIT standard exception respectively, > with specific > > new standard minor code. > > > > Does this form a reasonable basis for constructing a resolution > for this issue? > > Most definitely! :-) > ditto, jeff > Cheers, > > Michi. > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3234 Date: Tue, 15 Feb 2000 18:23:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (9Wd9~Jnd95L$e9-oh!! ok with me. > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Tuesday, February 15, 2000 5:03 PM > To: michi@ooc.com.au > Cc: jis@fpk.hp.com; karsten-oliver.starr@ubs.com; interop@omg.org > Subject: Re: Issue 3234 > > > 'Michi Henning' writes: > > > > On Tue, 15 Feb 2000, Jishnu Mukerji wrote: > > > > > Perhaps, it is reasonable to see if one can clearly > divide the failure causes > > > into those that the ORB believes are recoverable (e.g. I > know the profile, but > > > can't raise the target), and those that it definitely > knows are not recoverable > > > (e.g. no understandable profile/component in IOR), and > based on that raise > > > either a TRANSIENT or a IMP_LIMIT standard exception > respectively, with specific > > > new standard minor code. > > > > > > Does this form a reasonable basis for constructing a > resolution for this issue? > > > > Most definitely! :-) > > > ditto, > jeff > > Cheers, > > > > Michi. > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 > To: karsten-oliver.starr@ubs.com cc: interop@omg.org Subject: Re: Issue 3234 In-Reply-To: Your message of "Tue, 15 Feb 2000 11:53:42 PST." From: Bill Janssen Message-Id: <00Feb15.182411pst."3731"@watson.parc.xerox.com> Date: Tue, 15 Feb 2000 18:24:18 PST Content-Type: text X-UIDL: B$hd9)<_d9MoV!!24Pd9 The problem is that it's not the ORB which does the invoking -- it's the application code. Unless we add a way to let the application code tell the ORB whether or not it intends to invoke methods on an object, the ORB can't know whether to reject the object till it's too late. Bill To: jis@fpk.hp.com cc: karsten-oliver.starr@ubs.com, interop@omg.org Subject: Re: Issue 3234 In-Reply-To: Your message of "Tue, 15 Feb 2000 12:44:44 PST." <38A9BA8B.608D6BA2@fpk.hp.com> From: Bill Janssen Message-Id: <00Feb15.184251pst."3731"@watson.parc.xerox.com> Date: Tue, 15 Feb 2000 18:42:58 PST Content-Type: text X-UIDL: 2Qld9HF=!!paA!!XJ[d9 > Does this form a reasonable basis for constructing a resolution for this issue? Well, I'd prefer to simply make it an impossible condition, and therefore outside the scope of this group. But with that understanding, I think you've described it concisely. Bill From: "Rutt, T E (Tom)" To: interop@omg.org Subject: RE: Issue 3234 Date: Wed, 16 Feb 2000 13:24:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: lTp!!d0l!!9* ---------- > From: Jishnu Mukerji[SMTP:jis@fpk.hp.com] > Reply To: jis@fpk.hp.com > Sent: Tuesday, February 15, 2000 3:43 PM > To: karsten-oliver.starr@ubs.com > Cc: interop@omg.org > Subject: Re: Issue 3234 > > There was an extended discussion on what standard exception should > be > raised > when an attempt is made to invoke an operation using an IOR that > contains > no > understandable profiles/components, in which TRANSIENT, INV_OBJREF, > IMP_LIMIT, > etc. were considered. The bottom line here is that, as Bob pointed > out, > not > finding a working profile is one of several possible reasons why an > attempt to > do an invocation might fail. The other reasons could be temporary > outage > in > network, or permanently bad IP address in the IOR, or a bunch of > other > things, > many of which are not even clearly recognizable at a given point in > time. > Perhaps, it is reasonable to see if one can clearly divide the > failure > causes > into those that the ORB believes are recoverable (e.g. I know the > profile, > but > can't raise the target), and those that it definitely knows are not > recoverable > (e.g. no understandable profile/component in IOR), and based on that > raise > either a TRANSIENT or a IMP_LIMIT standard exception respectively, > with > specific > new standard minor code. > > Does this form a reasonable basis for constructing a resolution for > this > issue? > I think it does, since there is a natural distinction between "not connectable" versus "cannot connect" . The former is a definative > statement to not try again, while the latter leaves open the possibility to be able to connect in the future. -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com . > Thanks, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > >