Reply-To: From: "Nick Sharman" To: "OMG Portable Interceptors FTF" , "OMG ORB Core RTF" , "OMG Issues" Subject: Policy management issues Date: Mon, 15 May 2000 17:52:58 +0100 Message-ID: <001b01bfbe8e$06231860$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: eS$"!6QTd9A>md9KT3!! I have a number of problems with the existing policy management stuff in the ORB core (first issue below) and a related issue with the Portable Interceptors spec. Policy Management in Portable Interceptors ------------------------------------------ (All document refs to ptc/00-04-05) Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in the IOR". Policies get translated to IOR components, but AFAIK there's no general way that a component can be unscrambled to give a Policy. This suggests that we need another interception point, effectively the inverse of the existing IORInterceptor (sec. 21.5), that allows an IOR component to be converted into a Policy on the client side. I suggest something like: local interface ReceiveIORInterceptor : Interceptor { void establish_policies (in ReceiveIORInfo info); }; local interface ReceiveIORInfo { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }; and an extra operation add_receive_ior_interceptor in ORBInitInfo. ReceiveIORInterceptor::establish_policies provides the opportunity for an interceptor to turn IOR components back into Policies, using the interceptor's Policy Factories directly or indirectly via ORB::create_policy. The ORB will call this method on all registered ReceiveIORInterceptor objects during or before the first call of Object::get_policy (we needn't be more specific - this would allow eager calls on unmarshalling or lazy calls within Object::get_policy). Regards Nick --------------------------------- Nick Sharman Architect, LiveContent BROKER PeerLogic UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@peerlogic.com Web: http://www.peerlogic.com --- Winners of the "e-commerce" category --- --- Software Technology Awards 1999 --- From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA25432 for ; Fri, 19 May 2000 11:22:05 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id LAA39078 for ; Fri, 19 May 2000 11:41:18 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E4.00562D01 ; Fri, 19 May 2000 11:41:16 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E4.0056291C.00@d54mta04.raleigh.ibm.com> Date: Fri, 19 May 2000 11:40:02 -0400 Subject: Re: issue 3615 -- Interceptors FTF issue Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 9bmd94\Q!!gfM!!`Y_d9 Should this be done via interceptors? Shouldn't it just be within the function of the ORB to extract all IOR policies and make them available? What does an interceptor give you? Russell Butek butek@us.ibm.com Juergen Boldt on 05/18/2000 10:37:14 AM To: issues@emerald.omg.org, interceptors-ftf@omg.org cc: Subject: issue 3615 -- Interceptors FTF issue This is issue # 3615 Policy Management in Portable Interceptors (All document refs to ptc/00-04-05) Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in the IOR". Policies get translated to IOR components, but AFAIK there's no general way that a component can be unscrambled to give a Policy. This suggests that we need another interception point, effectively the inverse of the existing IORInterceptor (sec. 21.5), that allows an IOR component to be converted into a Policy on the client side. I suggest something like: local interface ReceiveIORInterceptor : Interceptor { void establish_policies (in ReceiveIORInfo info); }; local interface ReceiveIORInfo { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }; and an extra operation add_receive_ior_interceptor in ORBInitInfo. ReceiveIORInterceptor::establish_policies provides the opportunity for an interceptor to turn IOR components back into Policies, using the interceptor's Policy Factories directly or indirectly via ORB::create_policy. The ORB will call this method on all registered ReceiveIORInterceptor objects during or before the first call of Object::get_policy (we needn't be more specific - this would allow eager calls on unmarshalling or lazy calls within Object::get_policy). ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ Reply-To: From: "Nick Sharman" To: , Subject: RE: issue 3615 -- Interceptors FTF issue Date: Fri, 19 May 2000 17:44:44 +0100 Message-ID: <001c01bfc1b1$89682820$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <852568E4.0056291C.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Friday, May 19, 2000 4:40 PM > To: interceptors-ftf@omg.org > Subject: Re: issue 3615 -- Interceptors FTF issue > > > > > Should this be done via interceptors? Shouldn't it just be within the > function of the ORB to extract all IOR policies and make them available? > What does an interceptor give you? > > Russell Butek > butek@us.ibm.com > If it needs to be done at, I think there has to be an interceptor. Only the service knows what's in the encapsulated part of a service-specific IORcomponent - especially if the service is not (yet) a standard. I don't think the situation changes if if all policies go into single a TAG_POLICIES component; the ORB knows where to look for them, but there's still an opaque octet stream in there somewhere. The real question is: does it need doing at all? The spec for Object::get_policy suggests it does. For example, can application code in a client legitimately ask whether a reference is transactional (ignoring the deprecated is_a("IDL:.../TransactionalObject:1.0") test)? Regards Nick > > Juergen Boldt on 05/18/2000 10:37:14 AM > > To: issues@emerald.omg.org, interceptors-ftf@omg.org > cc: > Subject: issue 3615 -- Interceptors FTF issue > > > > This is issue # 3615 > > Policy Management in Portable Interceptors > > (All document refs to ptc/00-04-05) > > Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as >specified in > the IOR". Policies get translated to IOR components, but AFAIK >there's no > general way that a component can be unscrambled to give a Policy. >This > suggests that we need another interception point, effectively the >inverse > of > the existing IORInterceptor (sec. 21.5), that allows an IOR > component to be > converted into a Policy on the client side. > > I suggest something like: > > local interface ReceiveIORInterceptor : Interceptor { > void establish_policies (in ReceiveIORInfo info); > }; > > local interface ReceiveIORInfo { > CORBA::Policy set_policy (in CORBA::Policy policy); > IOP::TaggedComponent get_ior_component (); > IOP::TaggedComponent get_ior_component_from_profile ( > in IOP::ProfileId profile_id); > }; > > and an extra operation add_receive_ior_interceptor in ORBInitInfo. > > ReceiveIORInterceptor::establish_policies provides the opportunity >for an > interceptor to turn IOR components back into Policies, using the > interceptor's Policy Factories directly or indirectly via > ORB::create_policy. > > The ORB will call this method on all registered >ReceiveIORInterceptor > objects during or before the first call of Object::get_policy (we >needn't > be > more specific - this would allow eager calls on unmarshalling or > lazy calls > within Object::get_policy). > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ > > > > Reply-To: From: "Nick Sharman" To: "Harold Carr" Cc: "OMG Issues" , "OMG Portable Interceptors FTF" Subject: RE: issue 3615 Date: Wed, 19 Jul 2000 12:28:14 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3973579A.C0A46BAA@sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /`M!!;Ckd95";e9-f1!! > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > Sent: Monday, July 17, 2000 8:00 PM > To: nick.sharman@peerlogic.com > Subject: issue 3615 > > > Please provide precise/complete chapter/verse changes to ptc/2000-04-05 > so we can vote on this issue. > > Thanks, > Harold > OK, here goes... To remind everyone, here's my initial problem statement: ------------------------------------------------------------- Issue 3615: Policy Management in Portable Interceptors (interceptors-ftf) Source: PeerLogic (Mr. Nick Sharman, nick.sharman@peerlogic.com) Nature: Uncategorized Issue Severity: Summary: (All document refs to ptc/00-04-05) Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in the IOR". Policies get translated to IOR components, but AFAIK there's no general way that a component can be unscrambled to give a Policy. This suggests that we need another interception point, effectively the inverse of the existing IORInterceptor (sec. 21.5), that allows an IOR component to be converted into a Policy on the client side. I suggest something like: local interface ReceiveIORInterceptor : Interceptor { void establish_policies (in ReceiveIORInfo info); }; local interface ReceiveIORInfo { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }; and an extra operation add_receive_ior_interceptor in ORBInitInfo. ReceiveIORInterceptor::establish_policies provides the opportunity for an interceptor to turn IOR components back into Policies, using the interceptor's Policy Factories directly or indirectly via ORB::create_policy. The ORB will call this method on all registered ReceiveIORInterceptor objects during or before the first call of Object::get_policy (we needn't be more specific - this would allow eager calls on unmarshalling or lazy calls within Object::get_policy). ------------------------------------------------------------- In response, Russell Butek asked whether the ORB shouldn't do this. I don't think it can, since in general it can't tell what's in the octest sequence inside an IOR component. However, I'm still not sure whether we need to translate policy-related IOR components (created by IORInterceptor::establish_components in the server) back into Policy objects available via Object::get_policy, as defined in Sec. 4.3.7.1 of ptc/00-04-05: The get_policy operation returns the policy object of the specified type (se e on page 4-31), which applies to this object. It returns the effective Policy for the object reference. The effective Policy is the one that would be used if a request were made. This Policy is determined first by obtaining the effective override for the * PolicyType as returned by get_client_policy. The effective override is * then compared with the Policy as specified in the IOR. The effective * Policy is the intersection of the values allowed by the effective * override and the IOR-specified Policy. If the intersection is empty, the standard system exception INV_POLICY is raised. Otherwise, a Policy with a value legally within the intersection is returned as the effective Policy. The absence of a Policy value in the IOR implies that any legal value may be used. ... Now, I'm not sure what "intersection" means here (can anyone clarify, please, or point me at the issue that introduced this stuff for CORBA 2.3?), but from the starred lines above, it seems that get_policy rummages through Policies picked out of the IOR, and might well return one of them. Is that the intent? For example, in the Transaction service use-case, can a CORBA application sensibly include code like: CORBA::Object_ptr someRef = ...; CORBA::Policy_ptr tp = someRef.get_policy (CosTransactions::TransactionPolicyType); Of course, this functionality isn't needed to write a Transaction service interceptor, since the client-side request interceptor can just look at the underlying IOR component via ClientRequestInterceptor::get_effective_component. OK, so the question is: * Is it intended that Object::get_policy return Policy objects for arbitrary server-side policies, represented in the IOR as IOR components established by an IORInterceptor? If the answer is YES, then I believe we need something like the proposal embedded in the original issue, and I'll be happy to fill that out. If the answer is NO, then this FTF or the core RTF should take a look at 4.3.7.1, since that section suggests otherwise (to me, at least!) If you've made it this far, thanks for your patience! Regards Nick X-Sent: 23 Jan 2001 09:47:25 GMT From: "Nick Sharman" To: "Matthew Newhook" Cc: "OMG Interceptors RTF" , Subject: RE: No portable way to turn IOR components into object-reference policies Date: Tue, 23 Jan 2001 09:51:59 -0000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <20010122125225.B14625@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: %9~e9/B@e9Gh3!!fM4!! Matthew, Comments inline... > -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Monday, January 22, 2001 4:22 PM > To: Nick Sharman > Cc: issues@omg.org; orb_revision@omg.org > Subject: Re: No portable way to turn IOR components into > object-reference policies > > > Hi, > > On Mon, Oct 30, 2000 at 11:29:57AM -0330, Matthew Newhook wrote: > > Hi, > > > > On Mon, Oct 30, 2000 at 03:00:44PM -0000, Nick Sharman wrote: > > > Hi Matthew, > > > > > > I think this is a duplicate, or at least a relative, of issue 3615 > > > (http://cgi.omg.org/issues/interceptors-rtf.html#Issue3615). > > > > Yes, I agree -- these are the same issues. I don't like the solution > > though. It strikes me as _very_ costly to have to call an interceptor > > every time an object-reference is imported into the ORB. > > What I think should rather happen is that an interceptor is called when > _get_client_policy() is called (that is when the policies are > interrogated and not when the reference is imported. Agreed; always doing this whenever an app. receives an object reference could be extremely costly (esp. for an implementation of the Trader or Name Service). I tried to phrase my proposal so that either approach would be legal. > I'd like to see some discussion on this important issue and a vote at > some point in the near future :) So would I. I think I've a better understanding of how client-side Policy access should work than when I raised the issue, but I still think the extra interceptor is necessary. (Point of order, though: this is mainly a PI issue, so I think the discussion should start on that list. It could well have Core implications, so all contributions welcome of course.) > > 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 > > 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 Regards Nick Date: Tue, 23 Jan 2001 09:10:56 -0330 From: Matthew Newhook To: Nick Sharman Cc: OMG Interceptors RTF , orb_revision@omg.org Subject: Re: No portable way to turn IOR components into object-reference policies Message-ID: <20010123091056.D30276@ooc.com> References: <20010122125225.B14625@ooc.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick.sharman@cp.net on Tue, Jan 23, 2001 at 09:51:59AM -0000 Content-Type: text/plain; charset=us-ascii X-UIDL: Sna!!O\Md9`$o!!K2Ge9 Hi, On Tue, Jan 23, 2001 at 09:51:59AM -0000, Nick Sharman wrote: > ... > (Point of order, though: this is mainly a PI issue, so I think the > discussion should start on that list. It could well have Core implications, > so all contributions welcome of course.) Yes, I mistakenly thought that the PI stuff had been moved to the core. Looks like I'm wrong ;) > Regards > Nick Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 13 Nov 2002 13:29:27 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Question about 3615 What should we do about this issue? How are people living without this facility for so long? Or has this been addressed in some other way? Unfortunately the archive appears to not contain any discussion on this. The entire archive file is missing, and it is not in the original list of issues for Interceptors RTF. So is it just a stray issue or is it serious? Thanks, Jishnu. __________________________________________________________________________ Issue 3615: Policy Management in Portable Interceptors (interceptors-rtf) Nature: Uncategorized Issue Severity: Summary: (All document refs to ptc/00-04-05) Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in the IOR". Policies get translated to IOR components, but AFAIK there's no general way that a component can be unscrambled to give a Policy. This suggests that we need another interception point, effectively the inverse of the existing IORInterceptor (sec. 21.5), that allows an IOR component to be converted into a Policy on the client side. I suggest something like: local interface ReceiveIORInterceptor : Interceptor { void establish_policies (in ReceiveIORInfo info); }; local interface ReceiveIORInfo { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }; and an extra operation add_receive_ior_interceptor in ORBInitInfo. ReceiveIORInterceptor::establish_policies provides the opportunity for an interceptor to turn IOR components back into Policies, using the interceptor's Policy Factories directly or indirectly via ORB::create_policy. The ORB will call this method on all registered ReceiveIORInterceptor objects during or before the first call of Object::get_policy (we needn't be more specific - this would allow eager calls on unmarshalling or lazy calls within Object::get_policy). Date: Wed, 13 Nov 2002 18:47:15 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Question about 3615 Hello Jishnu and all, Jishnu Mukerji wrote: > > What should we do about this issue? How are people living without this > facility for so long? > __________________________________________________________________________ > Issue 3615: Policy Management in Portable Interceptors > Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified > in the IOR". Policies get translated to IOR components, but AFAIK > there's no general way that a component can be unscrambled to give a > Policy. This suggests that we need another interception point, > effectively the inverse of the existing IORInterceptor (sec. 21.5), that > allows an IOR component to be converted into a Policy on the client > side. We see policies given to create_POA which then hands them to the IORInterceptor. I uses information in those policies to put one or more tagged components into the ORT. There is not necessarily a 1-1 mapping between policies and what gets added to the ORT. In other words, there is not necessarily a representation of a policy as a tagged component. On the client side, a ClientRequestInterceptor (working in conjunction with the IORInterceptor that added the tagged components) looks for certain tagged components in the effective_target. If present, it then may do it magic. Bottom line: it's the interceptors adding/examing tagged components that define the semantics. The policies passed into create_POA are just a convenient place to give the necessary info to the IORInteptors. In theory it's nice to think that policies given to create_POA can be seen on the object references created from that POA. In practice the action is elsewhere. ReceiveIOR is a nice idea architecturally - I'm just not sure how much it is needed. Cheers, Harold Date: Wed, 13 Nov 2002 14:01:31 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Juergen Boldt Subject: Re: Question about 3615 Ah yes, sorry about that. There was an error in the html file that I was using to try to access it. BTW, in the issues list each issue has this line which says: "Click here for this issue's archive. " And it contains a relative URL, which of course works only when the issue list is collocated with the archive files. The issues list could be made more universally usable if the URL in this was the absolute URL i.e. "http://cgi.omg.org/issues/issuexyz.txt", instead of "http://./issues/issuexyz.txt" or some such. As things are now, when I copy the Issue html, I have to modify each of those manually for them to work from those htmls attached to email messages or placed in other files. Can this be changed to make our lives a little easier? Thanks, Jishnu. Juergen Boldt wrote: > > 636 lines of text in the archive.... > > -Juergen > > At 01:29 PM 11/13/2002 -0500, you wrote: > >What should we do about this issue? How are people living without this > >facility for so long? Or has this been addressed in some other way? > >Unfortunately the archive appears to not contain any discussion on this. > >The entire archive file is missing, and it is not in the original list > >of issues for Interceptors RTF. So is it just a stray issue or is it > >serious? > > > >Thanks, > > > >Jishnu. > > > >__________________________________________________________________________ > >Issue 3615: Policy Management in Portable Interceptors > >(interceptors-rtf) > > > > > >Nature: Uncategorized Issue > >Severity: > >Summary: > >(All document refs to ptc/00-04-05) > > > >Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified > >in the IOR". Policies get translated to IOR components, but AFAIK > >there's no general way that a component can be unscrambled to give a > >Policy. This suggests that we need another interception point, > >effectively the inverse of the existing IORInterceptor (sec. 21.5), that > >allows an IOR component to be converted into a Policy on the client > >side. > > > >I suggest something like: > > > > local interface ReceiveIORInterceptor : Interceptor { > > void establish_policies (in ReceiveIORInfo info); > > }; > > > > local interface ReceiveIORInfo { > > CORBA::Policy set_policy (in CORBA::Policy policy); > > IOP::TaggedComponent get_ior_component (); > > IOP::TaggedComponent get_ior_component_from_profile ( > > in IOP::ProfileId profile_id); > > }; > > > >and an extra operation add_receive_ior_interceptor in ORBInitInfo. > > > >ReceiveIORInterceptor::establish_policies provides the opportunity for > >an interceptor to turn IOR components back into Policies, using the > >interceptor's Policy Factories directly or indirectly via > >ORB::create_policy. > > > >The ORB will call this method on all registered ReceiveIORInterceptor > >objects during or before the first call of Object::get_policy (we > >needn't be more specific - this would allow eager calls on unmarshalling > >or lazy calls within Object::get_policy). > > ================================= > J> Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Wed, 13 Nov 2002 14:10:34 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Cc: Harold Carr , Jonathan Biggar Subject: Re: Question about 3615 [and 4065] I should also point out that Jon has pointed out that issue 4065 is realted to this issue, and we should handle these two together. So what I would like to propose is that we merge 3615 into 4065, mainly because 4065 addresses a broader issue than 3615 and any resolution to 4065 automatically deals with the issue in 3615, and the discussion of a resolution of 4065 appears to be based on more upto date background material and context. So let me hereby propose that we close 3615 by merging it into 4065 and carry on further discussion in 4065. Harold's point is still relevant, and should be duscussed further as part of 4065. Thanks, Jishnu. Harold Carr wrote: > > Hello Jishnu and all, > > Jishnu Mukerji wrote: > > > > What should we do about this issue? How are people living without this > > facility for so long? > > > __________________________________________________________________________ > > Issue 3615: Policy Management in Portable Interceptors > > > Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified > > in the IOR". Policies get translated to IOR components, but AFAIK > > there's no general way that a component can be unscrambled to give a > > Policy. This suggests that we need another interception point, > > effectively the inverse of the existing IORInterceptor (sec. 21.5), that > > allows an IOR component to be converted into a Policy on the client > > side. > > We see policies given to create_POA which then hands them to the > IORInterceptor. I uses information in those policies to put one or more > tagged components into the ORT. There is not necessarily a 1-1 mapping > between policies and what gets added to the ORT. In other words, there > is not necessarily a representation of a policy as a tagged component. > > On the client side, a ClientRequestInterceptor (working in conjunction > with the IORInterceptor that added the tagged components) looks for > certain tagged components in the effective_target. If present, it then > may do it magic. > > Bottom line: it's the interceptors adding/examing tagged components that > define the semantics. The policies passed into create_POA are just a > convenient place to give the necessary info to the IORInteptors. > > In theory it's nice to think that policies given to create_POA can be > seen on the object references created from that POA. In practice the > action is elsewhere. > > ReceiveIOR is a nice idea architecturally - I'm just not sure how much > it is needed. > > Cheers, > Harold -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Sender: jon@floorboard.com Date: Wed, 13 Nov 2002 11:35:57 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Question about 3615 Harold Carr wrote: > > What should we do about this issue? How are people living without this > > facility for so long? > > > __________________________________________________________________________ > > Issue 3615: Policy Management in Portable Interceptors > > > Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified > > in the IOR". Policies get translated to IOR components, but AFAIK > > there's no general way that a component can be unscrambled to give a > > Policy. This suggests that we need another interception point, > > effectively the inverse of the existing IORInterceptor (sec. 21.5), that > > allows an IOR component to be converted into a Policy on the client > > side. > > We see policies given to create_POA which then hands them to the > IORInterceptor. I uses information in those policies to put one or more > tagged components into the ORT. There is not necessarily a 1-1 mapping > between policies and what gets added to the ORT. In other words, there > is not necessarily a representation of a policy as a tagged component. > > On the client side, a ClientRequestInterceptor (working in conjunction > with the IORInterceptor that added the tagged components) looks for > certain tagged components in the effective_target. If present, it then > may do it magic. > > Bottom line: it's the interceptors adding/examing tagged components that > define the semantics. The policies passed into create_POA are just a > convenient place to give the necessary info to the IORInteptors. > > In theory it's nice to think that policies given to create_POA can be > seen on the object references created from that POA. In practice the > action is elsewhere. > > ReceiveIOR is a nice idea architecturally - I'm just not sure how much > it is needed. Here's the use case. For the OTS, client code needs to be able to query the OTSPolicy and InvocationPolicy values embedded in an object reference in order to properly interact with an object. For example, the client needs to know whether the object supports SHARED or UNSHARED transactions (or both), so it can figure out whether it can (or must) use synchronous or TII invocations. The only way to do this query is to call Object::get_policy(), which means there needs to be a mechanism to extract the appropriate component from the IOR and generate the proper policy value. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 14 Nov 2002 16:55:48 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Question about 3615 Hello Jonathan, > > ReceiveIOR is a nice idea architecturally - I'm just not sure how much > > it is needed. > > Here's the use case. For the OTS, client code needs to be able to query > the OTSPolicy and InvocationPolicy values embedded in an object > reference in order to properly interact with an object. For example, > the client needs to know whether the object supports SHARED or UNSHARED > transactions (or both), so it can figure out whether it can (or must) > use synchronous or TII invocations. > > The only way to do this query is to call Object::get_policy(), which > means there needs to be a mechanism to extract the appropriate component > from the IOR and generate the proper policy value. That use case certainly makes sense. I do not know OTS so perhaps I need a little education - but I thought that for PI to even be accepted in the first place it needed to be shown to be complete in the sense that it could be used to portably implement CSIv2 and OTS? Do the OTSPolicy and InvocationPolicy have standard representations that Object::get_policy() can look for? Of course, if it has to be built into Object::get_policy() then it is clearly not portably plugged into any ORB - so I get your point. Anyway, I'm certainly not against a receiveIOR interceptor, just wanted to understand the use case more. Thanks, Harold Sender: jbiggar@Resonate.com Date: Thu, 14 Nov 2002 13:45:46 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Question about 3615 Harold Carr wrote: > > > ReceiveIOR is a nice idea architecturally - I'm just not sure how much > > > it is needed. > > > > Here's the use case. For the OTS, client code needs to be able to query > > the OTSPolicy and InvocationPolicy values embedded in an object > > reference in order to properly interact with an object. For example, > > the client needs to know whether the object supports SHARED or UNSHARED > > transactions (or both), so it can figure out whether it can (or must) > > use synchronous or TII invocations. > > > > The only way to do this query is to call Object::get_policy(), which > > means there needs to be a mechanism to extract the appropriate component > > from the IOR and generate the proper policy value. > > That use case certainly makes sense. I do not know OTS so perhaps I > need a little education - but I thought that for PI to even be accepted > in the first place it needed to be shown to be complete in the sense > that it could be used to portably implement CSIv2 and OTS? That's certainly the intent, but as we have clearly discovered, intent doesn't mean that every jot & tittle has been handled. That's why we have RTFs. > Do the > OTSPolicy and InvocationPolicy have standard representations that > Object::get_policy() can look for? Yes, there are Policy objects defined in the CosTransactions IDL module, and standard IOR components & tags defined in the CosTSInteroperation module. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org