Issue 4065: How does an ORB implement Object::get_policy for PI defined policies? (corba-rtf) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: The description for Object::get_policy (in the Core, section 4.3.7.1) states: "The get_policy operation returns the policy object of the specified type (see Policy Object on page 4-32), 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." For a policy defined by PI, I don't see anyway for the ORB to implement this operation correctly, since there isn't any way for it to know how to properly resolve any client override policies with the policy information stored in the IOR. When a invocation is actually in process, the ClientRequestInterceptor can use the information available in the ClientRequestInfo interface to get the client override and the IOR policy data and do the correct resolution before continuing with the request. However, Object::get_policy() needs to do the same type of thing, but it has no invocation context to do it in. I think the same problem also applies to the implementation of ClientRequestInfo::get_request_policy(). I think we need a new interception point to do this work. Something like: local interface PolicyInterceptor { any determine_effective_policy(in PolicyInfo pi); }; local interface PolicyInfo { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }; If this turns out to be an acceptable solution, then we should also change ClientRequestInfo to: local interface ClientRequestInfo : RequestInfo, PolicyInfo { ... }; and remove the redundant operations. Resolution: Revised Text: Actions taken: November 18, 2000: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== Sender: jon@corvette.floorboard.com Message-ID: <3A174FDC.91446D79@floorboard.com> Date: Sat, 18 Nov 2000 19:58:20 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, interceptors-rtf@omg.org Subject: How does an ORB implement Object::get_policy for PI defined policies? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H&8!!>4%e94`E!!D~:!! The description for Object::get_policy (in the Core, section 4.3.7.1) states: "The get_policy operation returns the policy object of the specified type (see Policy Object on page 4-32), 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." For a policy defined by PI, I don't see anyway for the ORB to implement this operation correctly, since there isn't any way for it to know how to properly resolve any client override policies with the policy information stored in the IOR. When a invocation is actually in process, the ClientRequestInterceptor can use the information available in the ClientRequestInfo interface to get the client override and the IOR policy data and do the correct resolution before continuing with the request. However, Object::get_policy() needs to do the same type of thing, but it has no invocation context to do it in. I think the same problem also applies to the implementation of ClientRequestInfo::get_request_policy(). I think we need a new interception point to do this work. Something like: local interface PolicyInterceptor { any determine_effective_policy(in PolicyInfo pi); }; local interface PolicyInfo { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }; If this turns out to be an acceptable solution, then we should also change ClientRequestInfo to: local interface ClientRequestInfo : RequestInfo, PolicyInfo { ... }; and remove the redundant operations. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 11 Nov 2002 18:36:19 -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: Issue 4065 Question Summary: The description for Object::get_policy (in the Core, section 4.3.7.1) states: "The get_policy operation returns the policy object of the specified type (see Policy Object on page 4-32), 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." For a policy defined by PI, I don't see anyway for the ORB to implement this operation correctly, since there isn't any way for it to know how to properly resolve any client override policies with the policy information stored in the IOR. When a invocation is actually in process, the ClientRequestInterceptor can use the information available in the ClientRequestInfo interface to get the client override and the IOR policy data and do the correct resolution before continuing with the request. However, Object::get_policy() needs to do the same type of thing, but it has no invocation context to do it in. I think the same problem also applies to the implementation of ClientRequestInfo::get_request_policy(). This seems like a very legitimate issue that we need to fix in order for PI to be truly P. What do people think of the proposed reoslution in the archive which is excerpted below: ..... snip snip ...... local interface PolicyInterceptor { any determine_effective_policy(in PolicyInfo pi); }; local interface PolicyInfo { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }; The change proposed below may cause certain problems in the Java language mapping in terms of backward compatibility I think. We need to figure out a way of doing this cleanly and backward compatibly. Any thoughts? If this turns out to be an acceptable solution, then we should also change ClientRequestInfo to: local interface ClientRequestInfo : RequestInfo, PolicyInfo { ... }; Sender: jbiggar@Resonate.com Date: Mon, 11 Nov 2002 16:38:56 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 4065 Question Jishnu Mukerji wrote: > > Summary: The description for Object::get_policy (in the Core, section > 4.3.7.1) > states: > > "The get_policy operation returns the policy object of the specified > type (see Policy Object on page 4-32), 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." > > For a policy defined by PI, I don't see anyway for the ORB to implement > this operation correctly, since there isn't any way for it to know how > to properly resolve any client override policies with the policy > information stored in the IOR. > > When a invocation is actually in process, the ClientRequestInterceptor > can use the information available in the ClientRequestInfo interface to > get the client override and the IOR policy data and do the correct > resolution before continuing with the request. However, > Object::get_policy() needs to do the same type of thing, but it has no > invocation context to do it in. > > I think the same problem also applies to the implementation of > ClientRequestInfo::get_request_policy(). > > This seems like a very legitimate issue that we need to fix in > order for PI to be truly P. What do people think of the proposed > reoslution in the archive which is excerpted below: > 3615 also addresses this issue, and should be merged with 4065 when we solve the problem. There is also a proposed solution there that that we could consider. It is different but achieves a similar effect. > ..... snip snip ...... > > local interface PolicyInterceptor { > any determine_effective_policy(in PolicyInfo pi); > }; After two further years of experience, it's also clear that this needs a bit of tweaking: local interface PolicyInterceptor { CORBA::Policy determine_effective_policy(in PolicyInfo pi); }; and we also need to document how it would be registered: local interface ORBInitInfo { ... void add_policy_interceptor(in CORBA::PolicyType pt, in PolicyInterceptor interceptor); ... }; attempting to register more than one interceptor for the same PolicyType results in a BAD_INV_ORDER with minor code XXX (perhaps 16, like register_policy_factory). > local interface PolicyInfo { > readonly attribute Object target; > readonly attribute Object > effective_target; > readonly attribute IOP::TaggedProfile effective_profile; > > IOR::TaggedComponent get_effective_component (in > IOP::ComponentId > id); > IOP_N::TaggedComponentSeq get_effective_components (in > IOP::ComponentId id); > }; > > > The change proposed below may cause certain problems in the Java > language mapping in terms of backward compatibility I think. We need > to > figure out a way of doing this cleanly and backward compatibly. Any > thoughts? > The following change isn't strictly necessary, but could allow for some code reuse. > If this turns out to be an acceptable solution, then we should also > change ClientRequestInfo to: > > local interface ClientRequestInfo : RequestInfo, PolicyInfo { > ... > }; -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org 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