Issue 3587: ORB / client interceptor behaviour on location forwarded IORs (ots-rtf) Source: Oracle (Mr. Ram Jeyaraman, nobody) Nature: Uncategorized Issue Severity: Summary: With respect to the OTS changes introduced by the Messaging spec, In the case of persistent servers, the IOR will point to a Activation Service. When the client invokes the IOR the Activation service would in turn return a location forwarded IOR, which will point to the actual servant. Assuming that client has an active transaction and the client interceptor checks as specified by the Messaging spec are performed when the original IOR (which points to the Activation Service) was invoked, the interceptor hook would throw a INVALID_TRANSACTION. Thus the client side interceptor checks would not allow location forwarding at all to happen. So, the bigger question is : is it possible to remove client side checks, and propagate the transaction context unconditionally ? Resolution: Revised Text: Actions taken: April 27, 2000: received issue Discussion: End of Annotations:===== Date: Thu, 27 Apr 2000 11:44:49 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, ots-rtf@omg.org Subject: OTS issue : ORB / client interceptor behaviour on location forwarded IORs References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #35!!_(Ne9dS3e9f=Qd9 With respect to the OTS changes introduced by the Messaging spec, In the case of persistent servers, the IOR will point to a Activation Service. When the client invokes the IOR the Activation service would in turn return a location forwarded IOR, which will point to the actual servant. Assuming that client has an active transaction and the client interceptor checks as specified by the Messaging spec are performed when the original IOR (which points to the Activation Service) was invoked, the interceptor hook would throw a INVALID_TRANSACTION. Thus the client side interceptor checks would not allow location forwarding at all to happen. So, the bigger question is : is it possible to remove client side checks, and propagate the transaction context unconditionally ? thanks Ram X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 27 Apr 2000 13:36:10 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs In-Reply-To: <20000427130800.C18983@gemstone.com> References: <39088AA1.A45723F@eng.sun.com> <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: b<5e97\bd93G=e9=KN!! Comments included. At 01:08 PM 4/27/00 -0700, Blake Biesecker wrote: >On Thu, Apr 27, 2000 at 11:44:49AM -0700, Ram Jeyaraman wrote: >> With respect to the OTS changes introduced by the Messaging spec, >> >> In the case of persistent servers, the IOR will point to a Activation Service. When the client >> invokes the IOR the Activation service would in turn return a location forwarded IOR, which will >> point to the actual servant. >> > >I don't believe the Activation service is actually part of the OMG >standard. Isn't it just part of most vendor's implementations? > As I remember messaging (and it's been a while), the routers are part of the messaging architecture and, while they may have implementation specific activation daemons, the routers themself are part of the architecture and thus have normal CORBA references and, although it may not be specified clearly, these references need to have TransactionPolicy components with a value of shared (probably requires shared, but we could support allows shared as well). >> >> Assuming that client has an active transaction and the client interceptor checks as specified by the >> Messaging spec are performed when the original IOR (which points to the Activation Service) was >> invoked, the interceptor hook would throw a INVALID_TRANSACTION. >> > >Couldn't the original IOR (which points to the Activation Service) contain >transaction policy information? > >> >> Thus the client side interceptor checks would not allow location forwarding at all to happen. So, >> the bigger question is : is it possible to remove client side checks, and propagate the transaction >> context unconditionally ? >> > >Issue 3425 is currently discussing this (and many other) topic. There are two >issues that need to be addressed before we can consider the above (which ideally, >I'd like to be able to do): > >1) Client side checks eliminate the sending of messages which will fail >on the server. When there are not any 1.1 OTS servers involved, the client >side checks are really only for efficiency. Since it will be rare that >a run-time production environment will not have transaction policies >set up properly, I don't think it is worth complicating the spec for >the sole purpose of making an exceptional situation more efficient. (Plus, >client side checks can make the sort of thing you are describing above >more difficult for the normal case.) > >2) In a situation where there is a 1.1 OTS server and 1.2 OTS client, >the client check is important because the 1.1 server will not make >the checks as defined in section 10.5.2. > >I'd like to find a way to address 2 without client checks. Then this >issue is simply about whether the optimization of client side check >is more trouble than its worth. We should be able to do this if we >properly define what happens when the IOR doesn't have a transaction >policy. I'd like to consider whether it is feasible to require 1.2 >OTS servers to provide a transaction policy. Then the absence of >a transaction policy means that there is a 1.1 server. Then as long >as we decide that the absence of transaction policy does not mean >ALLOWS_NONE, client side checks are only needed for making exceptional >conditions more efficient. > >Does requiring a transaction policy in an IOR cause problems? > >Is propagating the transaction context when their is a 1.1 server >acceptable to everyone? > >Blake > > > > > > > > > > >> thanks >> Ram > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 27 Apr 2000 13:08:00 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs Message-ID: <20000427130800.C18983@gemstone.com> References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <39088AA1.A45723F@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Thu, Apr 27, 2000 at 11:44:49AM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ~e^!!eR(e9ekDe9pGhd9 On Thu, Apr 27, 2000 at 11:44:49AM -0700, Ram Jeyaraman wrote: > With respect to the OTS changes introduced by the Messaging spec, > > In the case of persistent servers, the IOR will point to a Activation Service. When the client > invokes the IOR the Activation service would in turn return a location forwarded IOR, which will > point to the actual servant. > I don't believe the Activation service is actually part of the OMG standard. Isn't it just part of most vendor's implementations? > > Assuming that client has an active transaction and the client > interceptor checks as specified by the > Messaging spec are performed when the original IOR (which points to > the Activation Service) was > invoked, the interceptor hook would throw a INVALID_TRANSACTION. > Couldn't the original IOR (which points to the Activation Service) contain transaction policy information? > > Thus the client side interceptor checks would not allow location > forwarding at all to happen. So, > the bigger question is : is it possible to remove client side > checks, and propagate the transaction > context unconditionally ? > Issue 3425 is currently discussing this (and many other) topic. There are two issues that need to be addressed before we can consider the above (which ideally, I'd like to be able to do): 1) Client side checks eliminate the sending of messages which will fail on the server. When there are not any 1.1 OTS servers involved, the client side checks are really only for efficiency. Since it will be rare that a run-time production environment will not have transaction policies set up properly, I don't think it is worth complicating the spec for the sole purpose of making an exceptional situation more efficient. (Plus, client side checks can make the sort of thing you are describing above more difficult for the normal case.) 2) In a situation where there is a 1.1 OTS server and 1.2 OTS client, the client check is important because the 1.1 server will not make the checks as defined in section 10.5.2. I'd like to find a way to address 2 without client checks. Then this issue is simply about whether the optimization of client side check is more trouble than its worth. We should be able to do this if we properly define what happens when the IOR doesn't have a transaction policy. I'd like to consider whether it is feasible to require 1.2 OTS servers to provide a transaction policy. Then the absence of a transaction policy means that there is a 1.1 server. Then as long as we decide that the absence of transaction policy does not mean ALLOWS_NONE, client side checks are only needed for making exceptional conditions more efficient. Does requiring a transaction policy in an IOR cause problems? Is propagating the transaction context when their is a 1.1 server acceptable to everyone? Blake > thanks > Ram Sender: jbiggar@corvette.floorboard.com Message-ID: <3908ABC4.83CCE4A6@floorboard.com> Date: Thu, 27 Apr 2000 14:06:12 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> <20000427130800.C18983@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GI0!!4K I don't believe the Activation service is actually part of the OMG > standard. Isn't it just part of most vendor's implementations? Yes, but pratically, they have to be considered. If the new OTS spec makes it impossible to deploy an OTS implentation that uses persistent IORs without modifying existing vendor activation services, that would not be a good thing. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 27 Apr 2000 14:42:40 -0700 From: Blake Biesecker To: Jonathan Biggar Cc: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs Message-ID: <20000427144240.G18983@gemstone.com> References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> <20000427130800.C18983@gemstone.com> <3908ABC4.83CCE4A6@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3908ABC4.83CCE4A6@floorboard.com>; from jon@floorboard.com on Thu, Apr 27, 2000 at 02:06:12PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: W;!e9@K\d9Y!Pe9AZ/e9 On Thu, Apr 27, 2000 at 02:06:12PM -0700, Jonathan Biggar wrote: > Blake Biesecker wrote: > > I don't believe the Activation service is actually part of the OMG > > standard. Isn't it just part of most vendor's implementations? > > Yes, but pratically, they have to be considered. If the new OTS spec > makes it impossible to deploy an OTS implentation that uses persistent > IORs without modifying existing vendor activation services, that would > not be a good thing. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org I completely agree. Persistent IORs need to be supported and we should avoid putting up road blocks that make them difficult to implement. Blake From: Jeffrey Mischkinsky Message-Id: <200004272143.OAA09235@wheel.dcn.davis.ca.us> Subject: Re: OTS issue : ORB / client interceptor behaviour on location To: ed.cobb@bea.com (Edward Cobb) Date: Thu, 27 Apr 2000 14:43:12 -0700 (PDT) Cc: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org In-Reply-To: <3.0.5.32.20000427133610.009ba3b0@svlhome2.beasys.com> from "Edward Cobb" at Apr 27, 2000 01:36:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: kQ^d9`iCe9)2Ke9[7"e9 'Edward Cobb' writes: > > Comments included. > > At 01:08 PM 4/27/00 -0700, Blake Biesecker wrote: > >On Thu, Apr 27, 2000 at 11:44:49AM -0700, Ram Jeyaraman wrote: > >> With respect to the OTS changes introduced by the Messaging spec, > >> > >> In the case of persistent servers, the IOR will point to a Activation > Service. When the client > >> invokes the IOR the Activation service would in turn return a location > forwarded IOR, which will > >> point to the actual servant. > >> > > > >I don't believe the Activation service is actually part of the OMG > >standard. Isn't it just part of most vendor's implementations? > > > As I remember messaging (and it's been a while), the routers are part of > the messaging architecture and, while they may have implementation specific > activation daemons, the routers themself are part of the architecture and > thus have normal CORBA references and, although it may not be specified > clearly, these references need to have TransactionPolicy components with a > value of shared (probably requires shared, but we could support allows > shared as well). I believe this is correct. The routers are defined as IDL interfaces and are hence are "normal" CORBA objects. Essentially all the important semantics are defined as what happens between the client and the "first" router, and what happens between the "final" router and the target. As is usual these can simply be CORBA wrappers to some other arbitrary messaging infrastructure, as long as they implement the specified semantics correctly.h. (Although of course the pictures show the IDL routers inbetween.) The assumption is that these routers have persistent IORs, but all the details of their activation, etc. are just standard CORBA stuff. So the fact that in reality persistent IORs usually point to some sort of activation service is an implementation detail. It is completely hidden from the client. I agree that that we probably do need to properly specify the tx policy for the router references. jeff > >> > >> Assuming that client has an active transaction and the client > interceptor checks as specified by the > >> Messaging spec are performed when the original IOR (which points > >> to the > Activation Service) was > >> invoked, the interceptor hook would throw a INVALID_TRANSACTION. > >> > > > >Couldn't the original IOR (which points to the Activation Service) > >> contain > >transaction policy information? > > > >> > >> Thus the client side interceptor checks would not allow location > forwarding at all to happen. So, > >> the bigger question is : is it possible to remove client side > >> checks, > and propagate the transaction > >> context unconditionally ? > >> > > > >Issue 3425 is currently discussing this (and many other) > >> topic. There are two > >issues that need to be addressed before we can consider the above > >> (which > ideally, > >I'd like to be able to do): > > > >1) Client side checks eliminate the sending of messages which will > >> fail > >on the server. When there are not any 1.1 OTS servers involved, the > >> client > >side checks are really only for efficiency. Since it will be rare > >> that > >a run-time production environment will not have transaction > >> policies > >set up properly, I don't think it is worth complicating the spec > >> for > >the sole purpose of making an exceptional situation more > >> efficient. (Plus, > >client side checks can make the sort of thing you are describing > >> above > >more difficult for the normal case.) > > > >2) In a situation where there is a 1.1 OTS server and 1.2 OTS > >> client, > >the client check is important because the 1.1 server will not make > >the checks as defined in section 10.5.2. > > > >I'd like to find a way to address 2 without client checks. Then > >> this > >issue is simply about whether the optimization of client side check > >is more trouble than its worth. We should be able to do this if we > >properly define what happens when the IOR doesn't have a > >> transaction > >policy. I'd like to consider whether it is feasible to require 1.2 > >OTS servers to provide a transaction policy. Then the absence of > >a transaction policy means that there is a 1.1 server. Then as long > >as we decide that the absence of transaction policy does not mean > >ALLOWS_NONE, client side checks are only needed for making > >> exceptional > >conditions more efficient. > > > >Does requiring a transaction policy in an IOR cause problems? > > > >Is propagating the transaction context when their is a 1.1 server > >acceptable to everyone? > > > >Blake > >> thanks > >> Ram > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Fri, 28 Apr 2000 11:30:39 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> <20000427130800.C18983@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W6j!!Am(!!3V8e9mAV!! Blake Biesecker wrote: > > On Thu, Apr 27, 2000 at 11:44:49AM -0700, Ram Jeyaraman wrote: > > With respect to the OTS changes introduced by the Messaging spec, > > > > In the case of persistent servers, the IOR will point to a Activation Service. When the client > > invokes the IOR the Activation service would in turn return a location forwarded IOR, which will > > point to the actual servant. > > > > I don't believe the Activation service is actually part of the OMG > standard. Isn't it just part of most vendor's implementations? The location forwarding mechanism in GIOP is there mainly to support location and activation services. Most commercial ORBs provide these services, but vary widely in the details (for good reasons - this is where ORB vendors get to innovate while still preserving portability and interoperability). The ability to do application level location forwarding in the POA came much later. > > > > > Assuming that client has an active transaction and the client interceptor checks as specified by the > > Messaging spec are performed when the original IOR (which points to the Activation Service) was > > invoked, the interceptor hook would throw a INVALID_TRANSACTION. > > > > Couldn't the original IOR (which points to the Activation Service) contain > transaction policy information? The key is for OTS to treat the original IOR and the forwarded IOR completely independently and to apply the same rules to each. An OTS interceptor should not have any reason to distinguish the original IOR from the forwarded one, nor to even try to correlate the two. An interceptor implementing OTS sees a forwarded request as two completely independent invocations, and should simply apply its propagation rules based on the OTS component in the profile being used for each of these invocations. Its up to vendors to make sure the "persistent" IOR advertized for the object has the proper OTS component for when the client talks to the location agent, and that the "forwarded" IOR has the proper OTS component for when the client talks to the actual server. The Portable Interceptors specification provides a mechanism for the OTS interceptor to add that component to the IOR used to talk to the actual server, but does not address portable implementation of whatever support is needed in a location agent. > > > > > Thus the client side interceptor checks would not allow location forwarding at all to happen. So, > > the bigger question is : is it possible to remove client side checks, and propagate the transaction > > context unconditionally ? All that is required from the client perspective is that each IOR have the right OTS component. The "persistent" IOR that points to the location agent should probably have an OTS component providing maximal flexibility to the client. -Bob Date: Fri, 28 Apr 2000 11:30:39 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs References: <3.0.5.32.20000426153729.00c7bc10@svlhome2.beasys.com> <39077927.787E6AB4@eng.sun.com> <39078106.19F42F42@eng.sun.com> <39088AA1.A45723F@eng.sun.com> <20000427130800.C18983@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W6j!!Am(!!3V8e9mAV!! Blake Biesecker wrote: > > On Thu, Apr 27, 2000 at 11:44:49AM -0700, Ram Jeyaraman wrote: > > With respect to the OTS changes introduced by the Messaging spec, > > > > In the case of persistent servers, the IOR will point to a Activation Service. When the client > > invokes the IOR the Activation service would in turn return a location forwarded IOR, which will > > point to the actual servant. > > > > I don't believe the Activation service is actually part of the OMG > standard. Isn't it just part of most vendor's implementations? The location forwarding mechanism in GIOP is there mainly to support location and activation services. Most commercial ORBs provide these services, but vary widely in the details (for good reasons - this is where ORB vendors get to innovate while still preserving portability and interoperability). The ability to do application level location forwarding in the POA came much later. > > > > > Assuming that client has an active transaction and the client interceptor checks as specified by the > > Messaging spec are performed when the original IOR (which points to the Activation Service) was > > invoked, the interceptor hook would throw a INVALID_TRANSACTION. > > > > Couldn't the original IOR (which points to the Activation Service) contain > transaction policy information? The key is for OTS to treat the original IOR and the forwarded IOR completely independently and to apply the same rules to each. An OTS interceptor should not have any reason to distinguish the original IOR from the forwarded one, nor to even try to correlate the two. An interceptor implementing OTS sees a forwarded request as two completely independent invocations, and should simply apply its propagation rules based on the OTS component in the profile being used for each of these invocations. Its up to vendors to make sure the "persistent" IOR advertized for the object has the proper OTS component for when the client talks to the location agent, and that the "forwarded" IOR has the proper OTS component for when the client talks to the actual server. The Portable Interceptors specification provides a mechanism for the OTS interceptor to add that component to the IOR used to talk to the actual server, but does not address portable implementation of whatever support is needed in a location agent. > > > > > Thus the client side interceptor checks would not allow location forwarding at all to happen. So, > > the bigger question is : is it possible to remove client side checks, and propagate the transaction > > context unconditionally ? All that is required from the client perspective is that each IOR have the right OTS component. The "persistent" IOR that points to the location agent should probably have an OTS component providing maximal flexibility to the client. -Bob Date: Sat, 29 Apr 2000 09:20:34 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs In-Reply-To: <20000427130800.C18983@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: LZZ!!]RAe9Z*g!!],-e9 On Thu, 27 Apr 2000, Blake Biesecker wrote: > Does requiring a transaction policy in an IOR cause problems? I think it does. Unless I misunderstand the intent, it would mean that *all* IORs would have to carry a transaction policy, even if their ORB has never heard of transactions and if the objects involved are non-transactional. I don't think this would be practical or desirable. > Is propagating the transaction context when their is a 1.1 server > acceptable to everyone? I'd like to explore Benard's option once more though... The suggestion was that, if an IOR doesn't contain a transaction policy, the sending side would (if a configuration attribute or ORB policy indicates so) try the narrow to TransactionalObject if an invocation is made as part of a transaction. The advantage of Bernard's suggestion would be that we wouldn't have to send the transaction context unconditionally with every call (even if the invocation is to a non-transactional object that doesn't have a policy). Bennard's suggestion is more efficient, at the cost of making interoperability between old and new OTS implementations slightly more complicated. However, long-term, it would appear to be the cleaner solution because, as old OTS implementations disappear, we wouldn't be burdened with the run-time cost of providing the interoperability behavior. 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: Sat, 29 Apr 2000 09:23:44 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on location forwarded IORs In-Reply-To: <3908ABC4.83CCE4A6@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fWX!!5gZd9]6Y!!*[F!! On Thu, 27 Apr 2000, Jonathan Biggar wrote: > Blake Biesecker wrote: > > I don't believe the Activation service is actually part of the OMG > > standard. Isn't it just part of most vendor's implementations? > > Yes, but pratically, they have to be considered. If the new OTS spec > makes it impossible to deploy an OTS implentation that uses persistent > IORs without modifying existing vendor activation services, that would > not be a good thing. I don't really see a problem here. Even if the reference that points at an IMR doesn't contain a transaction context, the forwarded reference may, and that's the one that counts. The only thing we can't do is to interpret the absence of a transaction policy as ALLOWS_NONE. Cheers, Michi. Date: Sun, 30 Apr 2000 19:36:17 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on locationforwarded IORs References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +>$"!#p]!!ck`!!9& > On Thu, 27 Apr 2000, Jonathan Biggar wrote: > > > Blake Biesecker wrote: > > > I don't believe the Activation service is actually part of the OMG > > > standard. Isn't it just part of most vendor's implementations? > > > > Yes, but pratically, they have to be considered. If the new OTS spec > > makes it impossible to deploy an OTS implentation that uses persistent > > IORs without modifying existing vendor activation services, that would > > not be a good thing. > > I don't really see a problem here. Even if the reference that points at > an IMR doesn't contain a transaction context, the forwarded reference > may, and that's the one that counts. The only thing we can't do is > to interpret the absence of a transaction policy as ALLOWS_NONE. > > Cheers, > > Michi. Date: Mon, 1 May 2000 10:29:24 -0700 From: Blake Biesecker To: Ram Jeyaraman Cc: Michi Henning , ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on locationforwarded IORs Message-ID: <20000501102924.D3737@gemstone.com> References: <390CEDA1.E89AA1D2@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <390CEDA1.E89AA1D2@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Sun, Apr 30, 2000 at 07:36:17PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: #~Wd9'D-e93o5!!]oVd9 On Sun, Apr 30, 2000 at 07:36:17PM -0700, Ram Jeyaraman wrote: > Michi is right. As long as absence of a transaction policy is not equated to ALLOWS_NONE policy, the > client side interceptor would not throw INVALID_TRANSACTION. > > Also it is possible to have the right target's transaction policy in the original IOR, which i > believe is dependent on the implementation of the location service. > > in summary there are two requirements to be included : > > 1) absence of a transaction policy is not equivalent to ALLOWS_NONE policy. > > 2) there should also be a requirement that the ORB call the client interceptors everytime it > receives a location forwarded IOR. > I'm not sure I understand the need for your second requirement. Could you elaborate? Thanks, Blake > Ram > > Michi Henning wrote: > > > > On Thu, 27 Apr 2000, Jonathan Biggar wrote: > > > > > Blake Biesecker wrote: > > > > I don't believe the Activation service is actually part of the > OMG > > > > standard. Isn't it just part of most vendor's implementations? > > > > > > Yes, but pratically, they have to be considered. If the new OTS > spec > > > makes it impossible to deploy an OTS implentation that uses > persistent > > > IORs without modifying existing vendor activation services, that > would > > > not be a good thing. > > > > I don't really see a problem here. Even if the reference that > points at > > an IMR doesn't contain a transaction context, the forwarded > reference > > may, and that's the one that counts. The only thing we can't do is > > to interpret the absence of a transaction policy as ALLOWS_NONE. > > > > Cheers, > > > > > Michi. Sender: jbiggar@corvette.floorboard.com Message-ID: <390DC53E.3FED6F67@floorboard.com> Date: Mon, 01 May 2000 10:56:14 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: Ram Jeyaraman , Michi Henning , ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on locationforwarded IORs References: <390CEDA1.E89AA1D2@eng.sun.com> <20000501102924.D3737@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7>1e9Nb1e9'k%!!fN-e9 Blake Biesecker wrote: > > On Sun, Apr 30, 2000 at 07:36:17PM -0700, Ram Jeyaraman wrote: > > Michi is right. As long as absence of a transaction policy is not equated to ALLOWS_NONE policy, the > > client side interceptor would not throw INVALID_TRANSACTION. > > > > Also it is possible to have the right target's transaction policy in the original IOR, which i > > believe is dependent on the implementation of the location service. > > > > in summary there are two requirements to be included : > > > > 1) absence of a transaction policy is not equivalent to ALLOWS_NONE policy. > > > > 2) there should also be a requirement that the ORB call the client interceptors everytime it > > receives a location forwarded IOR. > > > > I'm not sure I understand the need for your second requirement. > Could you elaborate? I guess he means that when the forwarded IOR comes back from the activation service that the ORB must rerun all of the client interceptors (and in particular the OTS interceptor) so that the correct transaction context can be established. This certainly must happen, and the Portable Interceptors spec already requires it. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 01 May 2000 11:57:31 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: OTS issue : ORB / client interceptor behaviour on locationforwarded IORs References: <390CEDA1.E89AA1D2@eng.sun.com> <20000501102924.D3737@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: M)+e9e,Ee9\'Nd9= > > in summary there are two requirements to be included : > > > > 1) absence of a transaction policy is not equivalent to ALLOWS_NONE policy. > > > > 2) there should also be a requirement that the ORB call the client interceptors everytime it > > receives a location forwarded IOR. > > > > I'm not sure I understand the need for your second requirement. > Could you elaborate? > The PI spec (i beleive) should require all the interceptor hooks be called on location forwarded IORs. I am not sure if it already does. This will ensure that the right client side checks are performed for location forwarded IORs as well. thanks Ram Date: Wed, 1 Nov 2000 18:14:50 -0800 From: Blake Biesecker To: ots-rtf@.omg.org Subject: Issue 3587: ORB / client interceptor behaviour on location forwarded IORs Message-ID: <20001101181449.I22453@gemstone.com> References: <4.2.0.58.20000428103423.00a9dab0@emerald.omg.org> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <4.2.0.58.20000428103423.00a9dab0@emerald.omg.org>; from juergen@omg.org on Fri, Apr 28, 2000 at 10:38:59AM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: MM(e9EX?e9X"Q!!!3J!! I think Matthew brought up a similar question (see his email with the subject: OTSPolicy & OTS internal operations). Is anyone interested in proposing a solution? Blake On Fri, Apr 28, 2000 at 10:38:59AM -0400, Juergen Boldt wrote: > This is issue # 3587 > > ORB / client interceptor behaviour on location forwarded IORs > > With respect to the OTS changes introduced by the Messaging spec, > > In the case of persistent servers, the IOR will point to a Activation > Service. When the client > invokes the IOR the Activation service would in turn return a location > forwarded IOR, which will > point to the actual servant. > > Assuming that client has an active transaction and the client interceptor > checks as specified by the > Messaging spec are performed when the original IOR (which points to the > Activation Service) was > invoked, the interceptor hook would throw a INVALID_TRANSACTION. > > Thus the client side interceptor checks would not allow location forwarding > at all to happen. So, > the bigger question is : is it possible to remove client side checks, and > propagate the transaction > context unconditionally ? > > Date: Wed, 01 Nov 2000 20:10:38 -0800 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: Issue 3587: ORB / client interceptor behaviour on location forwarded IORs References: <4.2.0.58.20000428103423.00a9dab0@emerald.omg.org> <20001101181449.I22453@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >cVd9eUA!!NeTd9I]X!! This issue alludes to a more general problem of how an Location Service provider would transcribe the original target's POA polices to the location forwarded IOR. Maybe the CORBA core RTF or another directly related to Location Service providers should attempt to solve this issue, and standardize the behaviour. When there is a standard way for Location Service provider to transcribe target POA policies into the location forwarded iors, that will aid the pluggability of location service providers. But for now, we will have to assume that the Location Service provider and the ORB vendor are the same, and thus the ORB would manufacture IORs (with appropriate OTSPolicy components) which would not break location forwarding mechanism. Note, this also needs some participation from the Location Service provider, which we shall assume is adhered to (since the ORB and the Location service comes from the same vendor). Proposed resolution : To resolve this issue, it will be worthwhile to mention the following in the OTS specification in Section 10.3.12 : "For persistent IORs (which use a Location Service), it is assumed that the IOR published by the server ORB and the IOR forwarded by the Location Service, will have appropriate OTSPolicy components in them, which will preserve the correct transactional behavior of the target object residing in the server." thanks, Ram Blake Biesecker wrote: > > I think Matthew brought up a similar question (see his email > with the subject: OTSPolicy & OTS internal operations). > > Is anyone interested in proposing a solution? > > Blake > > On Fri, Apr 28, 2000 at 10:38:59AM -0400, Juergen Boldt wrote: > > This is issue # 3587 > > > > ORB / client interceptor behaviour on location forwarded IORs > > > > With respect to the OTS changes introduced by the Messaging spec, > > > > In the case of persistent servers, the IOR will point to a Activation > > Service. When the client > > invokes the IOR the Activation service would in turn return a location > > forwarded IOR, which will > > point to the actual servant. > > > > Assuming that client has an active transaction and the client interceptor > > checks as specified by the > > Messaging spec are performed when the original IOR (which points to the > > Activation Service) was > > invoked, the interceptor hook would throw a INVALID_TRANSACTION. > > > > Thus the client side interceptor checks would not allow location forwarding > > at all to happen. So, > > the bigger question is : is it possible to remove client side checks, and > > propagate the transaction > > context unconditionally ? > > > > Date: Thu, 2 Nov 2000 22:55:48 -0330 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: Issue 3587: ORB / client interceptor behaviour on location forwarded IORs Message-ID: <20001102225547.K1077@ooc.com> References: <4.2.0.58.20000428103423.00a9dab0@emerald.omg.org> <20001101181449.I22453@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001101181449.I22453@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: kD6!!F2j!!P8ad9ROF!! Hi, On Wed, Nov 01, 2000 at 06:14:50PM -0800, Blake Biesecker wrote: > I think Matthew brought up a similar question (see his email > with the subject: OTSPolicy & OTS internal operations). > > Is anyone interested in proposing a solution? I think this is a totally different problem. The answer is this case is that the object-adapter that produced the reference that referred to the IMR should put the OTS policy in the IOR. After all the object-adapter that produced the reference "knows" the OTSPolicy -- it should have the responsibility to produce the correct reference. If the object-adapter doesn't do this then it's broken. > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725