Issue 2457: Unknown parts of an IOR and interoperability (interop) Source: (, ) 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: issue split into issues 3234 and 3235 Revised Text: Actions taken: February 19, 1999: received issue August 18, 1999: moved from core revision to interop February 4, 2000: issues 3234 and 3235 replace this one February 4, 2000: closed issue Discussion: The interop 1.1 RTF added the following "clarifications": Page 13-16 - " Object references have at least one tagged profile. Each profile supports one or more protocols and encapsulates all the basic information the protocols it supports need to identify an object. Any single profile holds enough information to drive a complete invocation using any of the protocols it supports; the content and structure of those profile entries are wholly specified by these protocols. A bridge between two domains may need to know the detailed content of the profile for those domains’ profiles, depending on the technique it uses to bridge the domains [see footnote 1] . ----------- footnote 1. 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. " page 13-18 subclause 13.6.2.3 " Specifications of components must include the following information: • Component ID: The compound tag that is obtained from OMG. • Structure and encoding: The syntax of the component data and the encoding rules. If the component value is encoded as a CDR encapsulation, the IDL type that is encapsulated and the GIOP version which is used for encoding the value, if different than GIOP 1.0, must be specified as part of the component definition. • Semantics: How the component data is intended to be used. • Protocols: The protocol for which the component is defined, and whether it is intended that the component be usable by other protocols. • At most once: whether more than one instance of this component can be included in a profile. Specification of protocols must describe how the components affect the protocol. The following should be specified in any protocol definition for each TaggedComponent that the protocol uses: • Mandatory presence: Whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). • Droppable: For optional presence component, whether component, if present, must be retained or may be dropped. " The issue was agreed to be replaced with two, more precisely worded issues. End of Annotations:===== Date: Fri, 19 Feb 1999 09:01:17 +1000 (EST) From: Michi Henning Reply-To: orb_revision@omg.org To: orb_revision@omg.org cc: issues@omg.org Subject: Unknown parts of an IOR and interoperability Organization: Triodia Technologies Hi, 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. In particular, if the above guarantees are not maintained, I cannot expect to store a perfectly compliant IOR that carries only DCE-CIOP protocol information in a Naming Service -- the Naming Service would be entitled to reject storing the IOR because it lacks IIOP information. To me, this is clearly ridiculous because it destroys protocol transparency and interoperability. I looked at the spec, and I cannot find precise words that would settle the matter one way or the other. In particular, there are no words that would oblige an ORB to preserve parts of an object reference it doesn't understand during marshalling. Conversely, I cannot find words that would permit an ORB to drop anything it doesn't understand inside an IOR at will. The only words I could find that appear relevant are for string_to_object and object_to_string, which require an ORB with IOP support to preserve the reference contents for these two operations. However, that only settles point (c) above, not the other two. I think it would be nice to settle this. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 18 Feb 1999 17:56:49 PST Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org Subject: Re: Unknown parts of an IOR and interoperability References: I've heard many debates about these points over the last 6 years. I think we can all agree that ORB A and ORB B cannot be expected to interoperate unless they have some protocol in common. The interesting case Michi is posing is that of ORB A understanding only protocol X, ORB B understanding X and Y, and ORB C understanding only Y. Is it valid for C to refuse to unmarshal an object reference from A that's passed to it by B? Or perhaps a stringified IOR is passed directly from A to C via some non-CORBA mechanism. I tend to believe that it should be legal for C to refuse to incarnate an object for the reference, and present that object to the application code. Note that this is really different from strictly unmarshalling the object reference, which could be done at some internal layer which deals in the data structures of protocol Y (say, IIOP). By presenting the object to the application layer, I feel that the ORB is making a tacit but very real guarantee that certain operations (like "is_a") are invocable on that object. Since the ORB *can't* invoke those operations, it shouldn't present a broken object to the application code, or at least should be allowed not to. What does this mean with regard to the CosNaming name service? My original argument in comp.object.corba was really about implementation techniques for standard object services. We could always implement services underneath the covers; that is, instead of using CORBA to implement them, we could descend to the level of GIOP toolkits. Using a GIOP toolkit (at least, with my GIOP toolkit), you can indeed unmarshal references `from the wire' even if you can't use any of the communication profiles in the IOR. And you can carry the data around in a data structure, and send it out again at some later time. But at some point we need to draw the line and say, One should be able to implement this service in CORBA without resorting to special under-the-covers tricks. Why should anyone else use CORBA for services if we can't even use it for a simple naming service? And if we say that about the standard COS services, that, combined with my argument about unmarshalling objects, means implementations of CosNaming services may validly reject objects which with they cannot communicate. But Michi is also right in saying that this is less than optimal for a name service. That's why ILU's non-CosNaming name service, `simple binding', uses stringified IORs instead of object references. We thereby take the name service out of the path of the decision about communication between the two ORBs. But we are still able to implement the service in standard ILU, because it's just manipulating strings. However, let's not get too bent out of shape about CosNaming not being the best possible way to bind names. We could always specify and provide other naming services that remove some of these constraints. In fact, I wouldn't even be unhappy about saying that every object reference bound in CosNaming must be reachable via IIOP. Except that there's no way to enforce this with standard CORBA mechanisms, so again we'd be forced to use `under-the-covers' implementation techniques. Bill Date: Fri, 19 Feb 1999 12:44:10 +1000 (EST) From: Michi Henning To: Bill Janssen cc: orb_revision@omg.org Subject: Re: Unknown parts of an IOR and interoperability Organization: Triodia Technologies On Thu, 18 Feb 1999, Bill Janssen wrote: > I've heard many debates about these points over the last 6 years. > > I think we can all agree that ORB A and ORB B cannot be expected to > interoperate unless they have some protocol in common. The > interesting > case Michi is posing is that of ORB A understanding only protocol X, > ORB > B understanding X and Y, and ORB C understanding only Y. Is it > valid > for C to refuse to unmarshal an object reference from A that's > passed to > it by B? Or perhaps a stringified IOR is passed directly from A to > C > via some non-CORBA mechanism. > > I tend to believe that it should be legal for C to refuse to > incarnate > an object for the reference, and present that object to the > application > code. Bill, here is another scenario. I would like to know whether the behavior I describe is considered acceptable. (The behavior I describe is legal according to your interpretation.) I am a client holding a valid reference to an object that is alive and well, and I can successfully invoke operations on that object. I also have a valid reference to a working context in my Naming Service, on which I also can invoke operations. I now call bind on my context with the name "A/B/C" (both A and B are valid contexts to which I can talk successfully). The bind call succeeds and does the right thing. Now I go and call bind a second time, this time with the name "A/X/C". Again, X is a context that is valid and I can talk to it. However, the second call to bind raises an exception and refuses to bind the reference. Why? Because I've crossed a federation boundary. Assume that A and B are both implemented in my Naming Service, which of course understands the protocols in my references. However, X might be a context in another vendor's Naming Service. I can talk to that context just fine, no problem either. However, the ORB implementing context X may not like one of the protocols in the reference I want to advertise, or may insist that some protocol that isn't in the reference must be present. This scenario, as far as I am concerned, is totally and utterly unacceptable. All hell breaks loose if we allow this behavior. I cannot federate naming, trading, event, and all sorts of other services. I cannot, in fact, rely on being able to pass any object reference to anything, whether the receiver wants to use the reference or not. I really have to ask what we have IOP and IORs for when something like this cannot work. In addition, I do not see any technical reason for allowing this broken behavior. An ORB can unmarshal, stringify, destringify, and remarshal any IOR without having to understand all the protocol details, so why would we allow it to reject doing these things on a whim? > Note that this is really different from strictly unmarshalling > the object reference, which could be done at some internal layer > which > deals in the data structures of protocol Y (say, IIOP). By > presenting > the object to the application layer, I feel that the ORB is making a > tacit but very real guarantee that certain operations (like "is_a") > are > invocable on that object. Since the ORB *can't* invoke those > operations, it shouldn't present a broken object to the application > code, or at least should be allowed not to. No, I strongly disagree with this view. There are plenty of other reasons why the reference may not work and no guarantee is implied by merely having passed the reference to the application. For example, the reference may be nil, it may point at a non-existent object, it may point at an unreachable server, it may point to an object that is secured and to which I do not have access, etc. Mere absence of support for the protocol indicated by the reference is not a reason to not let the application see the reference. > What does this mean with regard to the CosNaming name service? My > original argument in comp.object.corba was really about > implementation > techniques for standard object services. We could always implement > services underneath the covers; that is, instead of using CORBA to > implement them, we could descend to the level of GIOP toolkits. > Using a > GIOP toolkit (at least, with my GIOP toolkit), you can indeed > unmarshal > references `from the wire' even if you can't use any of the > communication profiles in the IOR. And you can carry the data > around in > a data structure, and send it out again at some later time. But at > some > point we need to draw the line and say, One should be able to > implement > this service in CORBA without resorting to special under-the-covers > tricks. Why should anyone else use CORBA for services if we can't > even > use it for a simple naming service? And if we say that about the > standard COS services, that, combined with my argument about > unmarshalling objects, means implementations of CosNaming services > may > validly reject objects which with they cannot communicate. Again, I strongly disagree with this. If CORBA services cannot be built using the standard APIs, you might as well kiss CORBA good-bye, including the component spec. I really don't understand what's so special about an unsupported protocol. It's just yet one more thing that can go wrong in a distributed environment. If clients are expected to be able to deal with loss of connectivity, dangling references, nil references, and a whole lot of other failure scenarios, why can't they be expected to deal with object references that indicate a protocol that isn't supported by the client? The only question is what system exception should be raised if a client invokes an operation on a reference for which it has no protocol support. Looking at the list of system exceptions, none seems particularly suitable. INV_OBJREF is probably closest, but we could easily add something like NO_PROTOCOL to deal with this especially. > But Michi is also right in saying that this is less than optimal for a > name service. Well, that's a huge understatement. What I'm saying is that this is a total disaster for any notion of interoperability or transparent federation. > That's why ILU's non-CosNaming name service, `simple > binding', uses stringified IORs instead of object references. We > thereby take the name service out of the path of the decision about > communication between the two ORBs. But we are still able to > implement > the service in standard ILU, because it's just manipulating strings. Well, in that case, we could universally get rid of all parameters and values of type Object and replace them with type string. After all, it's the only way for me to be sure that when I make a call and pass a reference, that the reference will actually be accepted. I somehow doubt though that this would be a step in the right direction... > However, let's not get too bent out of shape about CosNaming not being > the best possible way to bind names. We could always specify and > provide other naming services that remove some of these constraints. In > fact, I wouldn't even be unhappy about saying that every object > reference bound in CosNaming must be reachable via IIOP. Except that > there's no way to enforce this with standard CORBA mechanisms, so again > we'd be forced to use `under-the-covers' implementation techniques. Bill, this is about a lot more than CosNaming. It's about any and all kinds of transparent federation. With your interpretation, it's just too bad if I have an event channel in a federation that doesn't understand the protocol in my reference -- the events just happen to never make it across to the other side, no matter whether or not what's on the other side understands my references. This is *SERIOUS*. If we go down this path, we might as well throw all pretense of protocol independence and interoperability out the window. It also begs the question why we bother to carefully define an information model for object references, carefully come up with representations for that model that permit opaque data and cater for protocol extensions if, at the end of the day, we simply state that "It's too bad -- if you send an object reference to another ORB that happens not to understand your protocol, that's tough!" I think we also had better inform everyone who wants to emit events containing object references that putting a reference inside the event is not safe. Instead, they should put stringified references in there. Frankly, I believe that if we allow an ORB to refuse to even touch an object reference just because it doesn't contain that ORB's preferred protocol, we might as well give up and all go home. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 18 Feb 1999 19:12:12 PST Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Michi Henning Subject: Re: Unknown parts of an IOR and interoperability CC: orb_revision@omg.org References: Excerpts from direct: 18-Feb-99 Re: Unknown parts of an IOR.. Michi Henning@triodia.co (8923*) > This scenario, as far as I am concerned, is totally and utterly unacceptable. I find it not only unacceptable but unavoidable. This, in my mind, has always been a defect of OMG services like Naming and Trading. They treat Objects as Anys or as strings, but Objects really are a different kind of value. To really do Naming or Trading without the kinds of hiccups you so graphicly describe would require a better understanding of the differences between the Object type and the string type. > I really have to ask what we have IOP and IORs for when something like this > cannot work. In addition, I do not see any technical reason for allowing > this broken behavior. An ORB can unmarshal, stringify, destringify, and > remarshal any IOR without having to understand all the protocol details, > so why would we allow it to reject doing these things on a whim? But the ORB can't really effectively unmarshal such a reference, for the reasons I've previously described. Yes, some GIOP toolkit could, but that's different. > Again, I strongly disagree with this. If CORBA services cannot be built > using the standard APIs, you might as well kiss CORBA good-bye, including > the component spec. Actually, I think we agree on this point. > Looking at the list of system exceptions, none seems particularly suitable. > INV_OBJREF is probably closest, but we could easily add something like > NO_PROTOCOL to deal with this especially. Yes, I agree. Or COMM_FAILURE with a particular subcode. > Well, that's a huge understatement. What I'm saying is that this is a total > disaster for any notion of interoperability or transparent federation. Oh, nonsense. Simply require any interoperable service to support IIOP, which is really what it's for. > Well, in that case, we could universally get rid of all parameters and values of type Object and replace them with type string. It certainly seems appropriate for these intermediate services like Naming and Trading. Or package them in an Any, or some other less active data type. The chief problem with CORBA services, in my opinion, is that we attempt to treat non-opaque active data (Objects) as opaque data. The models really don't mesh. You seem to be attempting to re-opacify Objects, which isn't automatically a bad idea. I just think we've gone a bit far down the road of making them active and alive to do that at this stage. Bill Date: Thu, 18 Feb 1999 19:17:39 PST Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Michi Henning , Bill Janssen Subject: Re: Unknown parts of an IOR and interoperability CC: orb_revision@omg.org References: <4qnBOAsB0KGWIcxMAZ@holmes.parc.xerox.com> Excerpts from local.omg: 18-Feb-99 Re: Unknown parts of an IOR.. Bill Janssen@parc.xerox. (2502) > I find it not only unacceptable but unavoidable. Should read, of course, ``not only acceptable but unavoidable''. One of the standard problems with federation is that different pieces fail in different ways at different times. Bill Date: Fri, 19 Feb 1999 13:28:38 +1000 (EST) From: Michi Henning To: Bill Janssen cc: orb_revision@omg.org Subject: Re: Unknown parts of an IOR and interoperability Organization: Triodia Technologies On Thu, 18 Feb 1999, Bill Janssen wrote: > I find it not only unacceptable but unavoidable. This, in my mind, has > always been a defect of OMG services like Naming and Trading. They > treat Objects as Anys or as strings, but Objects really are a different > kind of value. To really do Naming or Trading without the kinds of > hiccups you so graphicly describe would require a better understanding > of the differences between the Object type and the string type. Bill, if what you say is correct, then we already have an inconsistency. The current spec requires that, for IOP compliant ORBs, when I pass an IOR through string_to_object(object_to_string(IOR)), I just get the same string. If what you say is correct, then that is impossible because converting a stringified reference into an object is the same thing as unmarshaling it. > > I really have to ask what we have IOP and IORs for when something like this > > cannot work. In addition, I do not see any technical reason for allowing > > this broken behavior. An ORB can unmarshal, stringify, destringify, and > > remarshal any IOR without having to understand all the protocol details, > > so why would we allow it to reject doing these things on a whim? > > But the ORB can't really effectively unmarshal such a reference, for the > reasons I've previously described. Yes, some GIOP toolkit could, but > that's different. That's something I really don't understand. My impression was that, no matter what unknown components or profiles are in an IOR, an ORB can always preserve the unknown bits exactly. Everything that's potentially unknown is encapsulated, or preceded with a length count. So, where is the marshaling problem? > > Well, that's a huge understatement. What I'm saying is that this is a total > > disaster for any notion of interoperability or transparent federation. > > Oh, nonsense. Simply require any interoperable service to support IIOP, > which is really what it's for. I don't think it's quite that simple. There is a difference between IIOP and IOP. If I want to talk to someone, I must have protocol support for one the protocols they support, no argument. But to pass a reference, why would both parties have to have support for all the protocols in the reference? This doesn't make sense to me. In fact, the reference is no more than an ordinary value while it is merely being passed around. It turns into an active thing only when I use to make an invocation. > > Well, in that case, we could universally get rid of all parameters and values > of type Object and replace them with type string. > > It certainly seems appropriate for these intermediate services like > Naming and Trading. Or package them in an Any, or some other less > active data type. I don't understand the active type argument here. As long as its not being used to make an invocation, a reference is just a blob of data. After all, if I can pass it around as a string, why shouldn't I be able to pass it around as type Object? After all, a stringified reference is no more than a string representation of what is marshaled on the wire anyway. If what you say were correct, I shouldn't be able to pass stringified references around either, because they are just as active as any other reference. The fact that its represented as a string is just coincidental and a mere detail of representation, no? > The chief problem with CORBA services, in my opinion, is that we attempt > to treat non-opaque active data (Objects) as opaque data. The models > really don't mesh. You seem to be attempting to re-opacify Objects, > which isn't automatically a bad idea. I just think we've gone a bit far > down the road of making them active and alive to do that at this stage. Hmmm... To me, the entire issue is quite simple. We've stumbled across an ORB that gets a bit carried away in the way it instantiates references. The particular ORB in question isn't smart enough to delay instantiating the transport specific parts of a reference until they are actually needed. That's a naive implementation, and probably fixed quite easily. The discussion we are having here is not so much about what should happen (at least there is no doubt in *my* mind :-) but about whether the spec adequately captures the intent (again, about which I have no doubts ;-) Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 18 Feb 1999 22:29:15 -0800 From: Jonathan Biggar Organization: Floorboard Software X-Accept-Language: en To: Bill Janssen CC: orb_revision@omg.org Subject: Re: Unknown parts of an IOR and interoperability References: Bill Janssen wrote: > I've heard many debates about these points over the last 6 years. > > I think we can all agree that ORB A and ORB B cannot be expected to > interoperate unless they have some protocol in common. The interesting > case Michi is posing is that of ORB A understanding only protocol X, ORB > B understanding X and Y, and ORB C understanding only Y. Is it valid > for C to refuse to unmarshal an object reference from A that's passed to > it by B? Or perhaps a stringified IOR is passed directly from A to C > via some non-CORBA mechanism. Actually, I think the case is more like this: ORB A supports protocol X & Y, ORB B (with the CosNaming service) only supports protocol X. Doesn't ORB A have a reasonable expectation that it can store an IOR for protocol Y (or both X & Y) in ORB B's naming service and retrieve it? If it can't, then a lot of transparency and interoperability is broken without ORB A being able to figure out why. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Date: Fri, 19 Feb 1999 14:48:25 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Juergen Boldt CC: issues@emerald.omg.org, orb_revision@emerald.omg.org Subject: Re: issue 2457 -- Core RTF issue References: <3.0.32.19990219100158.0072fc74@emerald.omg.org> > This is issue # 2547 > > Unknown parts of an IOR and interoperability > > 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. OK folks, I need your advice. Is this a Core issue or and Interop issue? On the face of it, it seems to me that it is mostly an interoperability issue, having to do with what an ORB is supposed to do while marshaling and unmarshaling object references relative to the protocol bits that are present in the IOR. The resolution of this issue is more likely to affect the interoperability chapters than the core chapters. Am I incorrect in thinking this way? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Karsten-Oliver.Starr@ubs.com X-OpenMail-Hops: 1 Date: Wed, 18 Aug 1999 09:27:44 +0200 Message-Id: In-Reply-To: <37B49287.A9157A71@fpk.hp.com> Subject: Re: Quick take on Core RTF 2K... Issue 2457 MIME-Version: 1.0 TO: jis@fpk.hp.com CC: orb_revision@omg.org Content-Disposition: inline; filename="UNAUTHENTICATED:" Content-Transfer-Encoding: 7bit X-Processed-By: BrianWare hpomsmf V2.3.40, 19 May 1999 Content-Type: text/plain; charset=us-ascii X-UIDL: b9bff282311a13e095360c8e16970060 Jishnu, actually it does affect both areas. In my opinion it should be addressed as a core issue first. The initial problem was a cross-vendor CosNaming method call 'bind(in Name, in Object)' from ORB A's client to ORB B's NameService. The IOR of ORB A's object is represented by a proprietary ProfileID which has been registered to the OMG. It did NOT contain the TAG_INTERNET_IOP. When ORB A's client tried to invoke the 'bind (in Name, in Object)' of ORB B's Naming Service via IIOP, we received an exception which told us that ORB B wasn't able to handle the object because of the missing TAG_INTERNET_IOP. The whole discussion afterwards resulted in the question: Do interoperable ORBs have the right to reject Objects which ought to be reprocessed (like stored in a 3'rd party NameService or TraderService, registered to a 3'rd party EventService, ... - I counted 8 effected CosServices which behaviour is up to the vendor in this case) ? I think Mr Soley would answer this question with a clear "No". Cheers, Karsten --------------------------------------------------- Karsten-Oliver.Starr@ubs.com --------------------------------------------------- ______________________________ Reply Separator _________________________________ Subject: UNAUTHENTICATED: Quick takes on Core RTF 2K Issues Author: jis at unix,mime/DD.RFC-822=jis@fpk.hp.com Date: 13.08.99 23:47 Issue 2457: Unknown parts of an IOR and interoperability (orb_revision) Will someone please remind me again why this is a core issue and not an interop issue? X-Sender: soley@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 18 Aug 1999 08:43:07 -0400 To: Karsten-Oliver.Starr@ubs.com From: Richard Mark Soley Subject: Re: Quick take on Core RTF 2K... Issue 2457 Cc: jis@fpk.hp.com, orb_revision@omg.org, andrew@omg.org, wayne@omg.org, juergen@omg.org In-Reply-To: References: <37B49287.A9157A71@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: d9b0ff9307dad4a66676e84581a6892d At 09:27 AM 8/18/99 +0200, Karsten-Oliver.Starr@ubs.com wrote: > The initial problem was a cross-vendor CosNaming method > call 'bind(in Name, in Object)' from ORB A's client to > ORB B's NameService. > > The IOR of ORB A's object is represented by a > proprietary ProfileID which has been registered > to the OMG. It did NOT contain the TAG_INTERNET_IOP. > > When ORB A's client tried to invoke the > 'bind (in Name, in Object)' of ORB B's Naming Service > via IIOP, we received an exception which told us that > ORB B wasn't able to handle the object because of the > missing TAG_INTERNET_IOP. > > The whole discussion afterwards resulted in the > question: Do interoperable ORBs have the right to > reject Objects which ought to be reprocessed > (like stored in a 3'rd party NameService or > TraderService, registered to a 3'rd party > EventService, ... - I counted 8 effected > CosServices which behaviour is up to the vendor > in this case) ? > > I think Mr Soley would answer this question with > a clear "No". I do love it when people make authoritative claims in my name :-) First: I agree with Mr. Starr, Mr. Soley would indeed answer the most general form of the most derived question above (!) "No." And, assuming the two ORB's were indeed both using IIOP, I am wondering why there *wasn't* a TAG_INTERNET_IOP profile. But regardless of the answer to either question, I have to agree with Jishnu that this is an *interop* issue -- specifically, definition of IIOP and what claimed IIOP-compliant ORB's may or may not do with particular IOR's they do not understand. That's precisely the sort of issue the interop RTF handles (the core RTF concentrates on IDL, CORBA API's, etc.). -- Richard Sender: jon@floorboard.com Message-ID: <384C8606.9648084A@floorboard.com> Date: Mon, 06 Dec 1999 19:59:02 -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: Juergen Boldt CC: interop@emerald.omg.org Subject: Re: Interop vote 1 References: <4.1.19991203114200.00aa3d00@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Mp5e9%:(e93N#"!&_[!! Issue 2457: No The proposed resolution isn't detailed enough for me to be sure what I am voting on. It's not clear exactly what circumstances the UnsupportedPortocol minor code would be used, and it's still not clear whether ORBs are allowed to drop profiles that they don't understand. Issue 2486: No The proposed resolution is not sufficient to fix the problem. The only long-term solution is a callback mechanism to inform application code of object identity changes. Issue 2507: Yes Issue 2509: No An application can explicitly create an any containing a tk_null or tk_void TypeCode. We need to document explicit behavior of CDR for this case, either encoding the any with a non-existent value, or rejecting the any with a MARSHAL exception. I prefer the former. Issue 2521: Yes Issue 2548: No I agree in principal that the current situation is correct: GIOP can use an empty string to specify that no type information is available in the IOR. However, this obviously needs clarification in the text. Issue 2620: Yes Issue Polar: Yes I don't care what name we decide on. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'Jishnu Mukerji'" , "Rutt, T E (Tom)" Cc: "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , Paul Kyzivat , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Wed, 5 Jan 2000 18:32:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VAo!!Of[d9:odd9W:od9 I have a problem with using TRANSIENT for this. Normally I would expect that with a transient exception there is some chance that a retry with the same object reference will work. That is not the case here. (Unless there was a protocol that the orb didn't support, but suddenly learns how to support - while the client is running.) I can't think of an exception that is clearly appropriate, but NO_IMPLEMENT seems at least slightly better. Of course the old standby BAD_PARAM is as applicable as ever. > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Wednesday, January 05, 2000 6:17 PM > To: Rutt, T E (Tom) > Cc: 'Bill Janssen '; 'michi@ooc.com.au'; > 'ed.cobb@beasys.com'; 'jon@floorboard.com'; 'kukura@iona.com'; > 'jmischki@dcn.davis.ca.us'; 'butek@us.ibm.com'; > 'paulk@roguewave.com'; > 'ken.cavanaugh@eng.sun.com'; 'honi@fsc.fujitsu.com'; > 'bill.beckwith@ois.com'; 'interop@omg.org'; 'juergen@omg.org' > Subject: Re: Announcement for interop 2000 vote 4 > > > In the resolution for issue 2457: > > "Proposed Resolution: > a) add minor code "NoProtocol" to standard system > exception TRANSIENT, for orbs to signal to a > client application that the Object reference used by the > client contains no protocol profiles (or > components for profiles) that it supports. > b) Add explanation text to footnote 1 (quoted above): > " To avoid problems which could cause inability for an orb > receiving an object reference to bind > using that object reference, an ORB which passes an object > reference it has recieved from one orb > to another orb, should preserve all the IOR information it > originally received." " > > > Don't we also need to add a sentance somewhere stating that > this TRANSIENT exception should be > raised when the said condition occurs? Merely sticking the > definition of a standard minor code in > Chapter 4 does not give any indication in any reasonable > form, of where it should be used. I think > an appropriate sentence somewhere in Chapter 13 is called for. > > 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. > Sender: jis@fpk.hp.com Message-ID: <3873D0F3.D62D588A@fpk.hp.com> Date: Wed, 05 Jan 2000 18:17:07 -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: "Rutt, T E (Tom)" Cc: "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'paulk@roguewave.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p6md9]PL!!F)F!!p?e!! In the resolution for issue 2457: "Proposed Resolution: a) add minor code "NoProtocol" to standard system exception TRANSIENT, for orbs to signal to a client application that the Object reference used by the client contains no protocol profiles (or components for profiles) that it supports. b) Add explanation text to footnote 1 (quoted above): " To avoid problems which could cause inability for an orb receiving an object reference to bind using that object reference, an ORB which passes an object reference it has recieved from one orb to another orb, should preserve all the IOR information it originally received." " Don't we also need to add a sentance somewhere stating that this TRANSIENT exception should be raised when the said condition occurs? Merely sticking the definition of a standard minor code in Chapter 4 does not give any indication in any reasonable form, of where it should be used. I think an appropriate sentence somewhere in Chapter 13 is called for. 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: Thu, 06 Jan 2000 08:24:33 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ';d!!1`md9lG4e9VT!!! Paul Kyzivat wrote: > > I have a problem with using TRANSIENT for this. > Normally I would expect that with a transient exception there is > some chance > that a retry with the same object reference will work. That is not > the case > here. (Unless there was a protocol that the orb didn't support, but > suddenly > learns how to support - while the client is running.) > > I can't think of an exception that is clearly appropriate, but > NO_IMPLEMENT > seems at least slightly better. Of course the old standby BAD_PARAM > is as > applicable as ever. > I agree with Paul and Michi. The exception should not be TRANSIENT. 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: Thu, 06 Jan 2000 11:10:20 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> <38745141.3AEA58FE@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: llMe9fcA!!nPY!!-hf!! My vote is to use TRANSIENT. That is what Orbix 2000 does right now, as no other existing system exception made sense. Although TRANSIENT isn't perfect, I don't think a new system exception is justified. One reason TRANSIENT makes sense in Orbix 2000, which may or may not be the case with other ORBs, is that this exception, with a vendor specific CANNOT_BIND minor code, is the result of no available transport and related ORB services being able to establish a binding, given the information in the IOR, the effective client side policies, and the current network connectivity and state of the server environment. So for us, the actual reason the binding can't be established may be very short term (broken network connectivity) or longer term (no IOR information for the available transports). Different transports may even have different reasons for not being able to bind. In fact, with Orbix 2000, the situation where no IOR information exists for available transports really is potentially transient, as new transports can be dynamically made available while a process is running. I don't see much advantage in using a different system exception, or even a different minor code, to distinguish between no IOR info for available transports, and the various other reasons that a binding can't be established, and am concerned that attempts to get too specific with these kinds of exceptions will break down in ORBs that support multiple transports. I'm also concerned about how cases are handled where the original IOR has profiles supporting available transports, but a location forwarded IOR doesn't. In this case, Orbix 2000 will continue trying to bind using other transports and/or profiles from the original IOR, which might result in other types of failures, making it extremely difficult to know which specific condition should be reported in an exception. In my opinion, trying to get too specific with these kinds of exceptions is going to conflict with CORBA's transparency of ORB implementation. If others are convinced it really is needed, I could probably live with a standard minor code to be used with TRANSIENT to indicate explicitly that no transports recognized usable IOR information. We'd have to leave it up to ORB implementations whether this same minor code was used when a location forwarded IOR supports no available transports. Other failures to bind will need to be left to vendor specific minor codes, or else a standard catch-all (CANNOT_BIND) minor code could be added. I am particularly opposed to using NO_IMPLEMENT, since that is often raised by method implementations that have not really been implemented. -Bob Simon Nash wrote: > > Paul Kyzivat wrote: > > > > I have a problem with using TRANSIENT for this. > > Normally I would expect that with a transient exception there is > some chance > > that a retry with the same object reference will work. That is not > the case > > here. (Unless there was a protocol that the orb didn't support, > but suddenly > > learns how to support - while the client is running.) > > > > I can't think of an exception that is clearly appropriate, but > NO_IMPLEMENT > > seems at least slightly better. Of course the old standby > BAD_PARAM is as > > applicable as ever. > > > I agree with Paul and Michi. The exception should not be TRANSIENT. > > 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 From: Paul Kyzivat To: "'Bob Kukura'" , Simon Nash > Cc: Paul Kyzivat , "'Jishnu Mukerji'" > , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Thu, 6 Jan 2000 11:51:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: F09!!W`_d9/G0!!Eh`!! Bob makes some good points. (The issue of what to do if a LocationForward contains no usable profiles is especially interesting.) After further thought, I think I could live with TRANSIENT in this case. This transient will originate in the client orb, so there really isn't any ambiguity about whether to retry, as would be the case if it came from the server. But I am not going to change my vote yet. The issue being addressed was the discarding of unknown profiles, not the reporting that happens after they have been discarded. Paul > -----Original Message----- > From: Bob Kukura [mailto:kukura@iona.com] > Sent: Thursday, January 06, 2000 11:10 AM > To: Simon Nash > Cc: Paul Kyzivat; 'Jishnu Mukerji'; Rutt, T E (Tom); 'Bill Janssen > '; 'michi@ooc.com.au'; 'ed.cobb@beasys.com'; > 'jon@floorboard.com'; 'jmischki@dcn.davis.ca.us'; > 'butek@us.ibm.com'; > 'ken.cavanaugh@eng.sun.com'; 'honi@fsc.fujitsu.com'; > 'bill.beckwith@ois.com'; 'interop@omg.org' > Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 > > > My vote is to use TRANSIENT. That is what Orbix 2000 does > right now, as > no other existing system exception made sense. Although > TRANSIENT isn't > perfect, I don't think a new system exception is justified. > > One reason TRANSIENT makes sense in Orbix 2000, which may or > may not be > the case with other ORBs, is that this exception, with a > vendor specific > CANNOT_BIND minor code, is the result of no available transport and > related ORB services being able to establish a binding, given the > information in the IOR, the effective client side policies, and the > current network connectivity and state of the server environment. > So > for us, the actual reason the binding can't be established may be > very > short term (broken network connectivity) or longer term (no IOR > information for the available transports). Different transports may > even have different reasons for not being able to bind. In fact, > with > Orbix 2000, the situation where no IOR information exists for > available > transports really is potentially transient, as new transports can be > dynamically made available while a process is running. I > don't see much > advantage in using a different system exception, or even a different > minor code, to distinguish between no IOR info for available > transports, > and the various other reasons that a binding can't be established, > and > am concerned that attempts to get too specific with these kinds of > exceptions will break down in ORBs that support multiple > transports. > > I'm also concerned about how cases are handled where the original > IOR > has profiles supporting available transports, but a location > forwarded > IOR doesn't. In this case, Orbix 2000 will continue trying to bind > using other transports and/or profiles from the original IOR, which > might result in other types of failures, making it extremely > difficult > to know which specific condition should be reported in an > exception. In > my opinion, trying to get too specific with these kinds of > exceptions is > going to conflict with CORBA's transparency of ORB implementation. > > If others are convinced it really is needed, I could probably > live with > a standard minor code to be used with TRANSIENT to indicate > explicitly > that no transports recognized usable IOR information. We'd have to > leave it up to ORB implementations whether this same minor > code was used > when a location forwarded IOR supports no available transports. > Other > failures to bind will need to be left to vendor specific > minor codes, or > else a standard catch-all (CANNOT_BIND) minor code could be added. > > I am particularly opposed to using NO_IMPLEMENT, since that is often > raised by method implementations that have not really been > implemented. > > -Bob Sender: jis@fpk.hp.com Message-ID: <3874C76F.5D2BBA38@fpk.hp.com> Date: Thu, 06 Jan 2000 11:48:47 -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: Bob Kukura Cc: Simon Nash , Paul Kyzivat > , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> <38745141.3AEA58FE@hursley.ibm.com> <3874BE6C.519C078B@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FI0e9#1,!!"lZd9(?Ie9 Bob Kukura wrote: > > My vote is to use TRANSIENT. That is what Orbix 2000 does right > now, as > no other existing system exception made sense. Although TRANSIENT > isn't > perfect, I don't think a new system exception is justified. I agree that a new system exception is not justified, but I do not agree that in general TRANSIENT makes any sense at all, although in specific instances of ORBs that happen to provide mechanisms for autoloading new protocols it might. In general, when a TRANSIENT exception is raised, the general expectation is that there has been a transient fault which hopefully will disappear on its own, and a subsequent attempt to make the same invocation will succeed. The case here is very different for all normal mortal ORBs:-). When an invocation cannot be made becasue the ORB does not implement a particular protocol, there should be no expectation that that fault will disappear as a result of the passage of time. The fault is precisely that the ORB does not implement any of the protocols present. Hence the only standard system exception that makes sense to me is NO_IMPLEMENT. > One reason TRANSIENT makes sense in Orbix 2000, which may or may not be > the case with other ORBs, is that this exception, with a vendor specific > CANNOT_BIND minor code, is the result of no available transport and > related ORB services being able to establish a binding, given the > information in the IOR, the effective client side policies, and the > current network connectivity and state of the server environment. So > for us, the actual reason the binding can't be established may be very > short term (broken network connectivity) or longer term (no IOR > information for the available transports). Different transports may > even have different reasons for not being able to bind. In fact, with > Orbix 2000, the situation where no IOR information exists for available > transports really is potentially transient, as new transports can be > dynamically made available while a process is running. I don't see much > advantage in using a different system exception, or even a different > minor code, to distinguish between no IOR info for available transports, > and the various other reasons that a binding can't be established, and > am concerned that attempts to get too specific with these kinds of > exceptions will break down in ORBs that support multiple transports. I would agree with that line of argument in support of standardizing on using TRANSIENT if all of that dynamism was part of the standard. But it is not, and as I recall the august AB member from IONA has been fighting tooth and nail all attempts to issue an RFP to make such things standard.:-( So for now I think we need to go with NO_IMPLEMENT rather than TRANSIENT. It should be noted that a NO_IMPLEMENT with a specific minor code (vendor specific or otherwise) will still allow a specific vendor to whatever they can using TRANSIENT isntead. 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: Thu, 06 Jan 2000 17:11:53 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> <38745141.3AEA58FE@hursley.ibm.com> <3874BE6C.519C078B@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 56bd9VI[!!c:\d9nCdd9 Bob, If TRANSIENT is the correct exception for architectural reasons, then we should use it. If not, we shouldn't use it just because one specific implementation has already used it. I think there is a difference between not supporting a protocol and supporting it but temporarily being unable to connect (e.g., because the required transport is not currently loaded). It is confusing to use the same exception for both cases. I looked through the list of existing system exceptions and the one that seems closest, though not an exact match, is INV_OBJREF. If we don't want to overload the meaning of this, then we could define a new system exception. Simon Bob Kukura wrote: > > My vote is to use TRANSIENT. That is what Orbix 2000 does right > now, as > no other existing system exception made sense. Although TRANSIENT > isn't > perfect, I don't think a new system exception is justified. > > One reason TRANSIENT makes sense in Orbix 2000, which may or may not > be > the case with other ORBs, is that this exception, with a vendor > specific > CANNOT_BIND minor code, is the result of no available transport and > related ORB services being able to establish a binding, given the > information in the IOR, the effective client side policies, and the > current network connectivity and state of the server environment. > So > for us, the actual reason the binding can't be established may be > very > short term (broken network connectivity) or longer term (no IOR > information for the available transports). Different transports may > even have different reasons for not being able to bind. In fact, > with > Orbix 2000, the situation where no IOR information exists for > available > transports really is potentially transient, as new transports can be > dynamically made available while a process is running. I don't see > much > advantage in using a different system exception, or even a different > minor code, to distinguish between no IOR info for available > transports, > and the various other reasons that a binding can't be established, > and > am concerned that attempts to get too specific with these kinds of > exceptions will break down in ORBs that support multiple transports. > > I'm also concerned about how cases are handled where the original > IOR > has profiles supporting available transports, but a location > forwarded > IOR doesn't. In this case, Orbix 2000 will continue trying to bind > using other transports and/or profiles from the original IOR, which > might result in other types of failures, making it extremely > difficult > to know which specific condition should be reported in an > exception. In > my opinion, trying to get too specific with these kinds of > exceptions is > going to conflict with CORBA's transparency of ORB implementation. > > If others are convinced it really is needed, I could probably live > with > a standard minor code to be used with TRANSIENT to indicate > explicitly > that no transports recognized usable IOR information. We'd have to > leave it up to ORB implementations whether this same minor code was > used > when a location forwarded IOR supports no available transports. > Other > failures to bind will need to be left to vendor specific minor > codes, or > else a standard catch-all (CANNOT_BIND) minor code could be added. > > I am particularly opposed to using NO_IMPLEMENT, since that is often > raised by method implementations that have not really been > implemented. > > -Bob > > Simon Nash wrote: > > > > Paul Kyzivat wrote: > > > > > > I have a problem with using TRANSIENT for this. > > > Normally I would expect that with a transient exception there is > some chance > > > that a retry with the same object reference will work. That is > not the case > > > here. (Unless there was a protocol that the orb didn't support, > but suddenly > > > learns how to support - while the client is running.) > > > > > > I can't think of an exception that is clearly appropriate, but > NO_IMPLEMENT > > > seems at least slightly better. Of course the old standby > BAD_PARAM is as > > > applicable as ever. > > > > > I agree with Paul and Michi. The exception should not be > TRANSIENT. > > > > 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 -- 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 Sender: jis@fpk.hp.com Message-ID: <3874CE3A.CDF39337@fpk.hp.com> Date: Thu, 06 Jan 2000 12:17:46 -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: "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'paulk@roguewave.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 References: <3873D0F3.D62D588A@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `0:!!DgG!!V7kd9_)=e9 Jishnu Mukerji wrote: > > In the resolution for issue 2457: > > "Proposed Resolution: > a) add minor code "NoProtocol" to standard system exception > TRANSIENT, for orbs to signal to a > client application that the Object reference used by the client > contains no protocol profiles (or > components for profiles) that it supports. > b) Add explanation text to footnote 1 (quoted above): > " To avoid problems which could cause inability for an orb receiving > an object reference to bind > using that object reference, an ORB which passes an object reference > it has recieved from one orb > to another orb, should preserve all the IOR information it > originally received." " > > Don't we also need to add a sentance somewhere stating that this > TRANSIENT exception should be > raised when the said condition occurs? Merely sticking the > definition of a standard minor code in > Chapter 4 does not give any indication in any reasonable form, of > where it should be used. I think > an appropriate sentence somewhere in Chapter 13 is called for. OK, Here is what I would like to see as far as TRANSIENT is concerned. I'd like to see NO_IMPLEMENT used instead because fterall, the fact that the ORB in question has no implementation of the protocol is what is causing this failure, and no amount of retrying without fixing the ORB will cause this failure to go away. Suggest that the following be done: 1. A new standard minor code be added to NO_IMPLEMENT that says: "The object reference used by the client contains no protocol profiles (or components for profiles) that is implemented by the ORB." 2. In the first paragraph on page 13-16 (the para that begins with "Object references have at least one tagged profile..."), insert the following sentence immediately preceding the last sentence: "If an attempt is made to do an operation invocation using an IOR that contains no protocol profiles (or components for profiles) that specifies a protocol that is implemented by the ORB, a NO_IMPLEMENT standard system exception with the standard minor code shall be raised." Comments? Now for Michi's comment on the changing of conformance. > > Issue 2457: Unknown parts of an IOR and interoperability (interop) > > > > Based on the non-ambiguous conformance statements as quoted above, > it is > > beyond RTF to change the conformance requirements for retention of > non-IIOP > > profiles or non-standard components in IIOP profiles. > > I strongly disagree with this. In reality, it means that if I pass a > reference > to a server and have the server return me the same reference, it may > no > longer work for me because some essential protocol information was > dropped > by the server. I presume you disagree more with the consequences of following the current practice of not changing confromance statements in an RTF in this case, than with the general practice of restricting RTFs to not changing conformance statements. There really is very good reason for maintenance of stability to keep the restriction in place. > We carefully crafted the IOR data structures such that an ORB can preserve > protocol information for which it has no support itself. There are good > reasons for this. In particular, it preserves protocol transparency. It seems to me that the technical position is accurate, although, disallowing dumping of random non-standard profiles from an IOR opens up an interesting vector for a denial of service attack that cannot be blocked while being compliant with the standard. But then nothing prevents an attacker from putting the same bad stuff in a standard profile, so this is a weak argument at best. Now then, as far as OMG process is concerned, I think Tom is correct in his stand that changing this in an RTF would be inappropriate. However, I think what can be legitimately and immediately done is to add verbiage which says that "ORB implementations that wish to enhance the probability of universal interoperability should not drop any profile information from an IOR." or some such. Meanwhile, be on the lookout for an appropriate RFP, a submission to which can legitimately fix the compliance language. 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. From: Paul Kyzivat To: "'Simon Nash'" , Bob Kukura Cc: Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Thu, 6 Jan 2000 12:59:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: CQU!!pj,e9KKj!!\oXd9 > From: Simon Nash [mailto:nash@hursley.ibm.com] > I looked through the list of existing system exceptions and the one > that seems closest, though not an exact match, is INV_OBJREF. If we > don't want to overload the meaning of this, then we could define a > new > system exception. I like that! Date: Thu, 06 Jan 2000 17:55:10 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402BD@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: eT4!!dAYd92&?e9FeW!! Paul, Paul Kyzivat wrote: > > Bob makes some good points. (The issue of what to do if a > LocationForward > contains no usable profiles is especially interesting.) > > After further thought, I think I could live with TRANSIENT in this > case. > This transient will originate in the client orb, so there really > isn't any > ambiguity about whether to retry, as would be the case if it came > from the > server. > That's fine unless the retry code is on a common path that's executed > for both local and remote exceptions. Also, how does the application know that it originated locally? Might it not attempt to retry whenever it gets a TRANSIENT exception? 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 To: Simon Nash cc: Paul Kyzivat , "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: Your message of "Thu, 06 Jan 2000 10:15:21 PST." <3874D6FE.4620D65D@hursley.ibm.com> From: Bill Janssen Message-Id: <00Jan6.113044pst."3992"@watson.parc.xerox.com> Date: Thu, 6 Jan 2000 11:31:54 PST Content-Type: text X-UIDL: hQNe95H-!!6NP!!#62!! I've long wanted to have a local/remote bit for system exceptions. But that's another RTF :-). Bill Sender: jis@fpk.hp.com Message-ID: <3875033D.35046ED7@fpk.hp.com> Date: Thu, 06 Jan 2000 16:03:57 -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: Re: Announcement for interop 2000 vote 4 - issue 2457 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;U5e9Ahe9~h(e9 Paul Kyzivat wrote: > > Jishnu, > > INV_OBJREF only means the objectref is structurally unsound because > that is > what we say it means. We can broaden the meaning if we wish. That is generally true of any exception that we happen to choose to use.:-) > With a suitable > minor code, I think this is more intuitive and less confusing than > TRANSIENT, NO_IMPLEMENT, IMPL_LIMIT, or BAD_PARAM. I still think the what is causing the problem is the lack of an implementation of a protocol in the ORB and therefore NO_IMPLEMENT is more intuitive than INV_OBJREF as per its current definition. Of course, if one is free to change definitions, then we could change the definition of TRANSIENT instead so that it becomes more intuitive and that would make at least Bob Kukura very happy. So if we wish to go for changing definition of the exceptions I would vote for doing so to TRANSIENT rather than to INV_OBJREF.:-) Actually, at the end of the day I don't really care that much which one is used as long as its usage is consistent with its description in Chapter 3/4. I would prefer not adding a new standard system exception just for this case. It should be noted however that if the description in Chapter 3/4 needs to be changed or if a new exception needs to be added, then this issue cannot be resolved in this RTF since it requires a change of the Core. Cheers, 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: Fri, 7 Jan 2000 08:29:06 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: "Rutt, T E (Tom)" , "'Jishnu Mukerji '" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'paulk@roguewave.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Floorboard's votes for interop 2000 vote 4 In-Reply-To: <38750831.8C270BA1@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: g6m!!!c7!!1iT!!"1_d9 On Thu, 6 Jan 2000, Jonathan Biggar wrote: > 2457: No > > I want to outlaw dropping profiles entirely, and I disagree that > this is > out of scope of the RTF. Clearly interoperability is broken if an > intermediate event, notification, naming or trader service is > allowed to > drop profiles in an IOR that it retransmits. If interoperability is > broken, then it behooves the Interop RTF to fix it. Hear, hear! > 2708: NO! > > I don't think the Interop RTF has any business specifying what > codeset > that a stringified IOR should use for object_to_string or > string_to_object. It is clear to me that the local native codeset > is > completely appropriate to use here. Jon, I don't think this is right. Consider: I pass you a file with a stringified IOR inside it. That's all you know. You have no idea what codeset I used to write the IOR, so you can't unstringify it unless I tell you what codeset I used as well. Stringified IORs, as far as I can see, must be written using a defined codeset; otherwise, they are no longer exchangeable between different environments. > This proposal breaks source code portability, since clients must handle > stringified IORs differently depending on whether their locale is > compatible with 8859-1 or not. No, I don't think this is correct. string_to_object() can simply accept a string and assume that it is written in ISO Latin-1. The translation code required to extract the CDR from that string is trivial, even if the native codeset isn't ISO Latin-1. (There is free source code to do this at http://www.ooc.com.au/staff/michi/ior2/ior_doc.html There is no impact on the client application code at all because all the work is done by the ORB, both for string_to_object() and for object_to_string(). > when that string is given to > Environments that are not using an > 8859-1 compatible locale already have mechanisms for interchange > with > 8859-1 compatible locales, and can use them when transmitting > stringified IORs. My whole point is that stringified IORs must be stand-alone because, otherwise, I don't know how to decode them. Allowing IORs to be written in arbitrary codesets makes it significantly harder to move them around, so I would strongly prefer that we simply define ISO Latin-1 as the codeset for stringified IORs. There is no technical difficulty with doing this, as far as I can see, and it makes life easier for everyone. 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 From: Paul Kyzivat To: "'Simon Nash'" , Paul Kyzivat Cc: "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Thu, 6 Jan 2000 14:24:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &,&!!PA!"!3g_!!4a=e9 > From: Simon Nash [mailto:nash@hursley.ibm.com] > Paul Kyzivat wrote: > > After further thought, I think I could live with TRANSIENT > > in this case. > That's fine unless the retry code is on a common path that's > executed for > both local and remote exceptions. > > Also, how does the application know that it originated > locally? Might it not > attempt to retry whenever it gets a TRANSIENT exception? I just said that I could live with it, not that I like it. Sender: jbiggar@corvette.floorboard.com Message-ID: <387503F3.30B887DC@floorboard.com> Date: Thu, 06 Jan 2000 13:06:59 -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: Simon Nash , Paul Kyzivat , "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <00Jan6.113044pst."3992"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L'7!!j%(e9Z*e!!bS8e9 Bill Janssen wrote: > > I've long wanted to have a local/remote bit for system exceptions. > But that's another RTF :-). I like the idea, and I agree that iterop isn't the right place to do it. If we are careful, this can be added without changing the wire format for exceptions at all. All we have to specify is that an exception, when first created has the local bit, but when it is unmarshalled from the wire, it has the remote bit instead. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 7 Jan 2000 07:25:08 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Simon Nash , Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <3874BE6C.519C078B@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: If others are convinced it really is needed, I could probably live with > a standard minor code to be used with TRANSIENT to indicate explicitly > that no transports recognized usable IOR information. We'd have to > leave it up to ORB implementations whether this same minor code was used > when a location forwarded IOR supports no available transports. Other > failures to bind will need to be left to vendor specific minor codes, or > else a standard catch-all (CANNOT_BIND) minor code could be added. Bob, I'm really not happy with TRANSIENT. For example, it is possible that a client gets a reference that doesn't have *any* transport that the client understands. (This can happen via string_to_object().) Raising TRANSIENT for this case really is wrong. There are two cases here: - The client doesn't understand any of the transports in the IOR. - The client understands only some of them. > I am particularly opposed to using NO_IMPLEMENT, since that is often > raised by method implementations that have not really been > implemented. I would suggest IMP_LIMIT for the first case with an appropriate minor code. For the second case, I think it's all a non-issue. The ORB tries to bind using those transports it understands. If one or more of those aren't working, the ORB can raise whatever exceptions is appropriate if all of them fail, including TRANSIENT (if there is a chance that the failure really *is* TRANSIENT). 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 From: Jeffrey Mischkinsky Message-Id: <200001062250.OAA29478@wheel.dcn.davis.ca.us> Subject: Re: Floorboard's votes for interop 2000 vote 4 To: michi@ooc.com.au (Michi Henning) Date: Thu, 6 Jan 100 14:49:53 -0800 (PST) Cc: jon@floorboard.com, terutt@lucent.com, jis@fpk.hp.com'" '", , ed.cobb@beasys.com, kukura@iona.com, jmischki@dcn.davis.ca.us, butek@us.ibm.com, paulk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, honi@fsc.fujitsu.com, bill.beckwith@ois.com, interop@omg.org, juergen@omg.org In-Reply-To: from "Michi Henning" at Jan 7, 0 08:29:06 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-UIDL: +@Ce9#V&!!RLT!!0nS!! 'Michi Henning' writes: > > On Thu, 6 Jan 2000, Jonathan Biggar wrote: > > > 2457: No > > > > I want to outlaw dropping profiles entirely, and I disagree that > this is > > out of scope of the RTF. Clearly interoperability is broken if an > > intermediate event, notification, naming or trader service is > allowed to > > drop profiles in an IOR that it retransmits. If interoperability > is > > broken, then it behooves the Interop RTF to fix it. > > Hear, hear! My $.0002 on this: I don't understand the interoperability argument here. What is required for interoperability (a standard which enables ALL orbs to communicate and understand each other regardless of whatever else they may or may not support) is a preceise specification of things that are REQUIRED by all. My understanding is that all that is required is the iiop profile and it's required components. While it may not be particularly friendly behavior, interoperability is not broken if a an intermediary drops stuff that either it doesn't understand or is not required to understand. If you are counting on non-mandatory, proprietary, or otherwise optional information, then by definition you are not interoperable. flame shields up, so fire away :-) (Seriously we should talk about this face to face over a higher bandwidth channel and see if we can agree on a common understanding of the requirements and assumptions behind the use of the term interoperability.) cheers, jeff And BTW, what are the security implications of allowing me to stuff in (potentially unlimited sizes) of bags of bits, and then forcing everyone to transmit and carry it? -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 ***** NOTE NEW phone/email ****** jeff@persistence.com +1 650-372-3604 Date: Fri, 7 Jan 2000 07:40:24 +1000 (EST) From: Michi Henning To: Simon Nash cc: Bob Kukura , Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <3874CCD9.6F52500E@hursley.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !)5!!8JY!!-@/!!O%Me9 On Thu, 6 Jan 2000, Simon Nash wrote: > I looked through the list of existing system exceptions and the one > that seems closest, though not an exact match, is INV_OBJREF. If we > don't want to overload the meaning of this, then we could define a > new > system exception. INV_OBJREF isn't really appropriate because it is meant to indicate an internally malformed reference. I would opt for IMP_LIMIT, because the ORB doesn't implement protocol X. I could also be swayed to Jishnu's suggestion of NO_IMPLEMENT but, as Bob pointed out, that is a bit problematic because people are used to seeing this exception when an operation body isn't implemented. 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: Fri, 7 Jan 2000 07:42:19 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'Simon Nash'" , Bob Kukura , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91402BE@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,gNe98$[d9bTf!!2=@e9 On Thu, 6 Jan 2000, Paul Kyzivat wrote: > > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > > I looked through the list of existing system exceptions and the > one > > that seems closest, though not an exact match, is INV_OBJREF. If > we > > don't want to overload the meaning of this, then we could define a > new > > system exception. > > I like that! Like what? INV_OBJREF or a new system exception? I wouldn't be opposed to adding a TRANSPORT exception or some such. 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 To: "Rutt, T E (Tom)" cc: "'Jishnu Mukerji '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'paulk@roguewave.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 In-Reply-To: Your message of "Wed, 05 Jan 2000 14:47:41 PST." From: Bill Janssen Message-Id: <00Jan6.112351pst."3992"@watson.parc.xerox.com> Date: Thu, 6 Jan 2000 11:25:21 PST Content-Type: text X-UIDL: 3!Pe9l^=!!SEOe9^03e9 Tom, These votes are really coming a bit too fast and furious. In particular, you've included some large and controversial resolutions in Vote 4 which I think deserve a lot more comment and consideration than this week in which a lot of us are still recovering from holiday vacations. For instance, the proposed resolution to 2457, I think, proposes that we do away with all ideas of droppability of information in IORs. That's clearly not what we want; I don't want my event service to have to carry all the banner ads that my competitors want to swamp it with, smuggled through in their proprietary IOR profiles. It's a bit hard to understand these resolutions, too; they're filled with grammar and spelling mistakes. Perhaps you could get whoever proposed them to clean them up a bit. I think I'll urge everyone to vote NO on all of these issues, till we can discuss them some more. Bill Sender: jis@fpk.hp.com Message-ID: <3874EF3F.BCCF5A9A@fpk.hp.com> Date: Thu, 06 Jan 2000 14:38:39 -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: Simon Nash Cc: Bob Kukura , Paul Kyzivat , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> <38745141.3AEA58FE@hursley.ibm.com> <3874BE6C.519C078B@iona.com> <3874CCD9.6F52500E@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EWi!!9Uj!!c];e9!4~e9 Simon Nash wrote: > > Bob, > If TRANSIENT is the correct exception for architectural reasons, > then we should use it. If not, we shouldn't use it just because one > specific implementation has already used it. > > I think there is a difference between not supporting a protocol and > supporting it but temporarily being unable to connect (e.g., because > the required transport is not currently loaded). It is confusing to > use the same exception for both cases. > > I looked through the list of existing system exceptions and the one > that seems closest, though not an exact match, is INV_OBJREF. If we > don't want to overload the meaning of this, then we could define a > new > system exception. IMHO INV_OBJREF is inappropriate. INV_OBJREF is uspposed to be used to signal that the object reference in question is structurally unsound. The case here is that the objref is structurally fine, it is just that none of the protocols specified by the objref are implemented by the ORB. 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. From: Paul Kyzivat To: "'Jishnu Mukerji'" , Simon Nash Cc: Bob Kukura , Paul Kyzivat , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Thu, 6 Jan 2000 14:47:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^)>e9i)6e9;8O!!FS>e9 Jishnu, INV_OBJREF only means the objectref is structurally unsound because that is what we say it means. We can broaden the meaning if we wish. With a suitable minor code, I think this is more intuitive and less confusing than TRANSIENT, NO_IMPLEMENT, IMPL_LIMIT, or BAD_PARAM. Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Thursday, January 06, 2000 2:39 PM > To: Simon Nash > Cc: Bob Kukura; Paul Kyzivat; Rutt, T E (Tom); 'Bill Janssen > '; 'michi@ooc.com.au'; 'ed.cobb@beasys.com'; > 'jon@floorboard.com'; 'jmischki@dcn.davis.ca.us'; > 'butek@us.ibm.com'; > 'ken.cavanaugh@eng.sun.com'; 'honi@fsc.fujitsu.com'; > 'bill.beckwith@ois.com'; 'interop@omg.org' > Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 > > > Simon Nash wrote: > > > > Bob, > > If TRANSIENT is the correct exception for architectural reasons, > > then we should use it. If not, we shouldn't use it just because > one > > specific implementation has already used it. > > > > I think there is a difference between not supporting a protocol > and > > supporting it but temporarily being unable to connect (e.g., > because > > the required transport is not currently loaded). It is confusing > to > > use the same exception for both cases. > > > > I looked through the list of existing system exceptions and the > one > > that seems closest, though not an exact match, is INV_OBJREF. If > we > > don't want to overload the meaning of this, then we could > define a new > > system exception. > > IMHO INV_OBJREF is inappropriate. INV_OBJREF is uspposed to > be used to signal that the object > reference in question is structurally unsound. The case here > is that the objref is structurally > fine, it is just that none of the protocols specified by the > objref are implemented by the ORB. > > 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. > From: Paul Kyzivat To: "'Michi Henning'" , Paul Kyzivat > Cc: "'Simon Nash'" , Bob Kukura > , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: RE: Announcement for interop 2000 vote 4 - issue 2457 Date: Thu, 6 Jan 2000 17:11: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: ?;K!!=AWd9Sgk!!k > I like that! > > Like what? INV_OBJREF or a new system exception? I wouldn't > be opposed to adding a TRANSPORT exception or some such. I like INV_OBJREF, with a new minor code. If somebody is deciding what to do next based on the major code alone, then this is as good or better than the others. If they look at both major and minor to decide, then it probably doesn't matter much. My second choice is IMP_LIMIT, third is BAD_PARAM, and fourth choice is TRANSIENT. Sender: jis@fpk.hp.com Message-ID: <38751D62.4BDB0683@fpk.hp.com> Date: Thu, 06 Jan 2000 17:55:30 -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: Michi Henning Cc: Bob Kukura , Simon Nash , Paul Kyzivat , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Uoh!!NILe9oQG!!DLFe9 Michi Henning wrote: > > On Thu, 6 Jan 2000, Bob Kukura wrote: > > > If others are convinced it really is needed, I could probably live > with > > a standard minor code to be used with TRANSIENT to indicate > explicitly > > that no transports recognized usable IOR information. We'd have > to > > leave it up to ORB implementations whether this same minor code > was used > > when a location forwarded IOR supports no available transports. > Other > > failures to bind will need to be left to vendor specific minor > codes, or > > else a standard catch-all (CANNOT_BIND) minor code could be added. > > Bob, I'm really not happy with TRANSIENT. For example, it is > possible that > a client gets a reference that doesn't have *any* transport that the > client > understands. (This can happen via string_to_object().) Raising > TRANSIENT for > this case really is wrong. There are two cases here: > > - The client doesn't understand any of the transports in the > IOR. > > - The client understands only some of them. > > > I am particularly opposed to using NO_IMPLEMENT, since that is > often > > raised by method implementations that have not really been > implemented. > > I would suggest IMP_LIMIT for the first case with an appropriate > minor code. > > For the second case, I think it's all a non-issue. The ORB tries to > bind > using those transports it understands. If one or more of those > aren't > working, the ORB can raise whatever exceptions is appropriate if all > of them > fail, including TRANSIENT (if there is a chance that the failure > really > *is* TRANSIENT). I could live with that. Actually, I kind of like it, because it works even in case of dynamically extensible ORBs. Think of a non-extensible ORB as one that has a single slot for protocols, whereas a dynamically extensible one has n-slots. I am particularly opposed to INV_OBJREF because that was never the purpose of the INV_OBJREF exception, and it is quite a stretch to change it to fit that shoe now. So here is the modified text: 1. A new standard minor code be added to IMP_LIMIT that says: "The object reference used by the client contains no protocol profiles (or components for profiles) that is implemented by the ORB." 2. In the first paragraph on page 13-16 (the para that begins with "Object references have at least one tagged profile..."), insert the following sentence immediately preceding the last sentence: "If an attempt is made to do an operation invocation using an IOR that contains no protocol profiles (or components for profiles) that specifies a protocol that is implemented by the ORB, an IMP_LIMIT standard system exception with the standard minor code shall be raised." 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: Thu, 06 Jan 2000 14:20:22 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <9B164B713EE9D211B6DC0090273CEEA91402B8@bos1.noblenet.com> <38745141.3AEA58FE@hursley.ibm.com> <3874BE6C.519C078B@iona.com> <3874CCD9.6F52500E@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :CMe9Mm9!!G*e!!M`Ud9 Simon Nash wrote: > > Bob, > If TRANSIENT is the correct exception for architectural reasons, > then we should use it. If not, we shouldn't use it just because one > specific implementation has already used it. Agreed. I did state that the reasoning may or may not apply to other ORBs. But we also have to keep in mind that the CORBA architecture supports things that are not implemented in lots of ORBs. For example, even if IIOP was the only standard transport protocol (ignoring DCE-CIOP and SECIOP, and SSL-IOP for a moment), the CORBA architecture does allow ORBs to use different protocols. > > I think there is a difference between not supporting a protocol and > supporting it but temporarily being unable to connect (e.g., because > the required transport is not currently loaded). It is confusing to > use the same exception for both cases. In Orbix 2000, there isn't really a difference. Protocols are implemented in plug-ins, which can be dynamically reconfigured into running ORBs at any time. Theoretically, its possible for a new protocol specification to be written and the plug-in implemented and dynamically loaded, all while the application is running. There is no way to prove that the running ORB will never be able to support any particular protocol. > > I looked through the list of existing system exceptions and the one > that seems closest, though not an exact match, is INV_OBJREF. If we > don't want to overload the meaning of this, then we could define a > new > system exception. Again, I don't think a new system exception is justified, one reason being that these could get propagated to older ORBs as UNKNOWN. But my issue really isn't about which exception to use, it is that I don't think we should be trying to specify specific exceptions to raise for various reasons why a binding could not be established. Architecturally, this is due to the fact that, particularly in ORBs supporting multiple protocols, there are situations where there is not one single well defined reason why a binding could not be established. For example, what if the IOR supports IIOP but the client ORB has a policy in effect that disables IIOP? Even if you would say that is not INV_OBJREF, what if the IOR also has some unknown profile or component? I know I'm having difficulty expressing my issue here, but the point is that failure to bind can often be due to a combination of reasons, each eliminating one possible way that a binding could have been established. Why is no known protocol in the IOR so important to treat specially? I guess we could implement that easily enough, but its the slippery slope I'm worried about. -Bob > > Simon > > Bob Kukura wrote: > > > > My vote is to use TRANSIENT. That is what Orbix 2000 does right > now, as > > no other existing system exception made sense. Although TRANSIENT > isn't > > perfect, I don't think a new system exception is justified. > > > > One reason TRANSIENT makes sense in Orbix 2000, which may or may > not be > > the case with other ORBs, is that this exception, with a vendor > specific > > CANNOT_BIND minor code, is the result of no available transport > and > > related ORB services being able to establish a binding, given the > > information in the IOR, the effective client side policies, and > the > > current network connectivity and state of the server environment. > So > > for us, the actual reason the binding can't be established may be > very > > short term (broken network connectivity) or longer term (no IOR > > information for the available transports). Different transports > may > > even have different reasons for not being able to bind. In fact, > with > > Orbix 2000, the situation where no IOR information exists for > available > > transports really is potentially transient, as new transports can > be > > dynamically made available while a process is running. I don't > see much > > advantage in using a different system exception, or even a > different > > minor code, to distinguish between no IOR info for available > transports, > > and the various other reasons that a binding can't be established, > and > > am concerned that attempts to get too specific with these kinds of > > exceptions will break down in ORBs that support multiple > transports. > > > > I'm also concerned about how cases are handled where the original > IOR > > has profiles supporting available transports, but a location > forwarded > > IOR doesn't. In this case, Orbix 2000 will continue trying to > bind > > using other transports and/or profiles from the original IOR, > which > > might result in other types of failures, making it extremely > difficult > > to know which specific condition should be reported in an > exception. In > > my opinion, trying to get too specific with these kinds of > exceptions is > > going to conflict with CORBA's transparency of ORB implementation. > > > > If others are convinced it really is needed, I could probably live > with > > a standard minor code to be used with TRANSIENT to indicate > explicitly > > that no transports recognized usable IOR information. We'd have > to > > leave it up to ORB implementations whether this same minor code > was used > > when a location forwarded IOR supports no available transports. > Other > > failures to bind will need to be left to vendor specific minor > codes, or > > else a standard catch-all (CANNOT_BIND) minor code could be added. > > > > I am particularly opposed to using NO_IMPLEMENT, since that is > often > > raised by method implementations that have not really been > implemented. > > > > -Bob > > > > Simon Nash wrote: > > > > > > Paul Kyzivat wrote: > > > > > > > > I have a problem with using TRANSIENT for this. > > > > Normally I would expect that with a transient exception there > is some chance > > > > that a retry with the same object reference will work. That is > not the case > > > > here. (Unless there was a protocol that the orb didn't > support, but suddenly > > > > learns how to support - while the client is running.) > > > > > > > > I can't think of an exception that is clearly appropriate, but > NO_IMPLEMENT > > > > seems at least slightly better. Of course the old standby > BAD_PARAM is as > > > > applicable as ever. > > > > > > > I agree with Paul and Michi. The exception should not be > TRANSIENT. > > > > > > 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 > > -- > 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 To: Jonathan Biggar cc: Simon Nash , Paul Kyzivat > , "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: Your message of "Thu, 06 Jan 2000 13:07:09 PST." <387503F3.30B887DC@floorboard.com> From: Bill Janssen Message-Id: <00Jan6.141529pst."3426"@watson.parc.xerox.com> Date: Thu, 6 Jan 2000 14:17:14 PST Content-Type: text X-UIDL: 9mc!!EB!e9\ If we are careful, this can be added without changing the wire > format for exceptions at all. All we have to specify is that an > exception, when first created has the local bit, but when it is > unmarshalled from the wire, it has the remote bit instead. Right. Bill Sender: jis@fpk.hp.com Message-ID: <38751E85.2CAE8E91@fpk.hp.com> Date: Thu, 06 Jan 2000 18:00:21 -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: Jonathan Biggar Cc: Bill Janssen , Simon Nash , Paul Kyzivat , "'Bob Kukura'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <00Jan6.113044pst."3992"@watson.parc.xerox.com> <387503F3.30B887DC@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "NY!!~Wcd9;jL!!&DA!! Jonathan Biggar wrote: > > Bill Janssen wrote: > > > > I've long wanted to have a local/remote bit for system exceptions. > > But that's another RTF :-). > > I like the idea, and I agree that iterop isn't the right place to do > it. If we are careful, this can be added without changing the wire > format for exceptions at all. All we have to specify is that an > exception, when first created has the local bit, but when it is > unmarshalled from the wire, it has the remote bit instead. But the question is where do you put that bit? Can this be done without changing the language mapping of system exceptions? I can think of a particularly odious kludge or two to do that, but am too ashamed to talk about it.:-) 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. Sender: jbiggar@corvette.floorboard.com Message-ID: <38752012.CB9BCFD7@floorboard.com> Date: Thu, 06 Jan 2000 15:06:58 -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: Jishnu Mukerji CC: Bill Janssen , Simon Nash , Paul Kyzivat , "'Bob Kukura'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <00Jan6.113044pst."3992"@watson.parc.xerox.com> <387503F3.30B887DC@floorboard.com> <38751E85.2CAE8E91@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GP > Jonathan Biggar wrote: > > > > Bill Janssen wrote: > > > > > > I've long wanted to have a local/remote bit for system > exceptions. > > > But that's another RTF :-). > > > > I like the idea, and I agree that iterop isn't the right place to > do > > it. If we are careful, this can be added without changing the > wire > > format for exceptions at all. All we have to specify is that an > > exception, when first created has the local bit, but when it is > > unmarshalled from the wire, it has the remote bit instead. > > But the question is where do you put that bit? Can this be done > without changing the language > mapping of system exceptions? I can think of a particularly odious > kludge or two to do that, but am > too ashamed to talk about it.:-) The language mappings would have to change, certainly, but at least the solution wouldn't break interoperability or require GIOP 1.3. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 7 Jan 2000 09:06:41 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Bob Kukura , Simon Nash , Paul Kyzivat , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <38751D62.4BDB0683@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: aO&e9cN]!!6OGe9a'ed9 On Thu, 6 Jan 2000, Jishnu Mukerji wrote: > So here is the modified text: I like that, with two very minor editorial comments: > 1. A new standard minor code be added to IMP_LIMIT that says: "The object reference used by > the client contains no protocol profiles (or components for profiles) that *are* > implemented by the > ORB." > > 2. In the first paragraph on page 13-16 (the para that begins with "Object references have at least > one tagged profile..."), insert the following sentence immediately preceding the last sentence: > > "If an attempt is made to do an operation invocation using an IOR that contains no protocol profiles > (or components for profiles) that specifies a protocol that *are* > implemented by the ORB, an IMP_LIMIT > standard system exception with the standard minor code shall be raised." 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, 06 Jan 2000 18:40:29 -0500 From: Marc Laukien Organization: Object Oriented Concepts, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Simon Nash , Paul Kyzivat , "'Bob Kukura'" , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'michi@ooc.com.au'" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: <00Jan6.113044pst."3992"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: LF > I've long wanted to have a local/remote bit for system exceptions. > But that's another RTF :-). I second this. We already have this as a proprietary extension for our ORB. It's very useful for multi-tier applications. Cheers, Marc > > Bill -- Marc Laukien Phone: (978) 439 9285 x 245 Object Oriented Concepts, Inc. FAX: (978) 439 9286 44 Manning Rd. WWW: http://www.ooc.com Billerica, MA 01821 E-Mail: mailto:ml@ooc.com Sender: Stefan.Wengi@adnovum.com Message-ID: <38752AF5.A4D01A00@adnovum.com> Date: Thu, 06 Jan 2000 15:53:25 -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: Michi Henning Cc: Bob Kukura , Simon Nash , Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms22BD92679A0392DEEF401CC1" X-UIDL: d:$e90jFe9(FR!![+2e9 Michi Henning wrote: > Bob, I'm really not happy with TRANSIENT. For example, it is possible that > a client gets a reference that doesn't have *any* transport that the client > understands. (This can happen via string_to_object().) Raising TRANSIENT for > this case really is wrong. There are two cases here: > > - The client doesn't understand any of the transports in the IOR. > > - The client understands only some of them. > > > I am particularly opposed to using NO_IMPLEMENT, since that is often > > raised by method implementations that have not really been implemented. > > I would suggest IMP_LIMIT for the first case with an appropriate minor code. I would suggest INV_OBJREF although the objref is not 'malformed' the orb cannot extract the information needed to establish a connection. I.e. it cannot decode the objref. > For the second case, I think it's all a non-issue. The ORB tries to bind > using those transports it understands. If one or more of those aren't > working, the ORB can raise whatever exceptions is appropriate if all of them > fail, including TRANSIENT (if there is a chance that the failure really > *is* TRANSIENT). agree. Stefan -- Stefan Wengi, AdNovum Software Inc. 1400 Fashion Island Blvd. #309, San Mateo, CA 94404 650 525-9322, fax 650 525-9324, mailto:sgw@acm.org [] smime.p7s Date: Fri, 7 Jan 2000 11:16:04 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: "Rutt, T E (Tom)" , "'Jishnu Mukerji '" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'kukura@iona.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'paulk@roguewave.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" , "'juergen@omg.org'" Subject: Re: Floorboard's votes for interop 2000 vote 4 In-Reply-To: <38750831.8C270BA1@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: m\ 2457: No > > I want to outlaw dropping profiles entirely, and I disagree that > this is > out of scope of the RTF. Clearly interoperability is broken if an > intermediate event, notification, naming or trader service is > allowed to > drop profiles in an IOR that it retransmits. If interoperability is > broken, then it behooves the Interop RTF to fix it. I fully agree. In addition, I am not happy to see political arguments based around conformance points. This is an issue that affects the viability of the platform. RTFs are supposed to act in accordance with the overall architectural goals of the OMG, unless I'm severely mistaken. So I am not happy to see arguments here that propose to permit dropping proprietary profiles, especially in absence of solid technical evidence for the desirability of doing this, and even more so if they center around some technical argument about not changing conformance points. Do we want ORBs that work and do the job of our customers, or do we want self-gratifying products that satisfy mainly the marketing and political goals of their respective companies? 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: Fri, 7 Jan 2000 10:33:52 +1000 (EST) From: Michi Henning To: Stefan Wengi cc: Bob Kukura , Simon Nash , Paul Kyzivat , "'Jishnu Mukerji'" , "Rutt, T E (Tom)" , "'Bill Janssen '" , "'ed.cobb@beasys.com'" , "'jon@floorboard.com'" , "'jmischki@dcn.davis.ca.us'" , "'butek@us.ibm.com'" , "'ken.cavanaugh@eng.sun.com'" , "'honi@fsc.fujitsu.com'" , "'bill.beckwith@ois.com'" , "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <38752AF5.A4D01A00@adnovum.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-ID: Content-Type: MULTIPART/SIGNED; PROTOCOL="application/x-pkcs7-signature"; MICALG=sha1; BOUNDARY=------------ms22BD92679A0392DEEF401CC1 X-UIDL: bP9e9m@\!!MV2!!"_id9 On Thu, 6 Jan 2000, Stefan Wengi wrote: > Michi Henning wrote: > > > Bob, I'm really not happy with TRANSIENT. For example, it is > possible that > > a client gets a reference that doesn't have *any* transport that > the client > > understands. (This can happen via string_to_object().) Raising > TRANSIENT for > > this case really is wrong. There are two cases here: > > > > I would suggest IMP_LIMIT for the first case with an appropriate > minor code. > > I would suggest INV_OBJREF although the objref is not 'malformed' > the > orb cannot extract the information needed to establish a connection. > I.e. it cannot decode the objref. No. Using INV_OBJREF is clearly in violation of what's in the spec now. 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 [] smime1.p7s Date: Fri, 7 Jan 2000 10:42:16 +1000 (EST) From: Michi Henning To: Bob Kukura cc: "'interop@omg.org'" Subject: Re: Announcement for interop 2000 vote 4 - issue 2457 In-Reply-To: <3874EAF6.53FC257D@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3~^d9(Xg!!j/Rd9pe)e9 On Thu, 6 Jan 2000, Bob Kukura wrote: > But my issue really isn't about which exception to use, it is that I > don't think we should be trying to specify specific exceptions to > raise > for various reasons why a binding could not be established. > Architecturally, this is due to the fact that, particularly in ORBs > supporting multiple protocols, there are situations where there is > not > one single well defined reason why a binding could not be > established. > For example, what if the IOR supports IIOP but the client ORB has a > policy in effect that disables IIOP? Even if you would say that is > not > INV_OBJREF, what if the IOR also has some unknown profile or > component? I appreciate your reasoning. > I know I'm having difficulty expressing my issue here, but the point is > that failure to bind can often be due to a combination of reasons, each > eliminating one possible way that a binding could have been > established. Why is no known protocol in the IOR so important to treat > specially? I guess we could implement that easily enough, but its the > slippery slope I'm worried about. I'm concerned about the case where an ORB isn't built to drag in new protocols on the fly. In that case, there is no way that an invocation will ever succeed. Also, with Orbix 2000, even though you can configure new protocols on the fly, I think it's a bit drastic to raise TRANSIENT. After all, you have to make quite a major effort to add the new protocol in terms of configuration. I would classify that as somewhat more than just a transient failure (but I admit that the boundary is vague and not easily defined). We could leave it to each implementation as to what the most appropriate exception would be (as long as it agrees with the general definition of the exception semantics in the spec; for example, I would probably not be happy with an ORB that raised OBJECT_NOT_EXIST in this case ;-) 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